P2 SD Card Boot code for ROM

Cluso99

I just posted code and sample output on the Prop2 FPGA Files thread.

Please post any SD card test results here, to save clogging the FPGA thread.

Note that I am not using any SmartPins or complex instructions. If all proves successful, as it did in P1, then we have the basis for the simple boot code (excluding the actual checksum validation and pass for execution).

This code follows the latest SD Card info, and fixes for the issues found in P1. I have not found card that will not work.

This code tests for FAT32, and if found, it locates the VOL label sector.

My thoughts are that booting from SD Card would be as follows (slightly different to previous discussion, but permits support of FAT32 as an option as well as MBR booting)....

1. Check for SD Card Type (SDHC as a minimum)

2. If FAT32, then find VOL sector, and locate a file called "P2BOOT.BIN". If found, read the first 512 byte sector into COG-0 and execute it.

3. If not FAT32 or P2BOOT.BIN not found, then read MBR (sector 0) into COG-0, verify checksum of bytes 128-383 (256 bytes) = "PROP" (or whatever Chip decided), and if so, JMP #128 to execute loaded code.

ozpropdev

Here's my test results

ozpropdev

and another one

Electrodude

There should be a way to indicate whether the MBR code is PASM or TAQOZ bytecode. Since TAQOZ bytecode is much denser than PASM, it should be possible to do much more with it in the available space. Both PASM and TAQOZ bootloaders should have access to a function or bytecode already in RAM to load blocks off the SD card.

Also, why restrict the bootloader to 256 bytes? Why not load the whole 512 byte cluster and start execution right after the magic number at the beginning? That way, if the card isn't formatted with MBR (i.e. the last two bytes aren't 0x55, 0xAA, and there's a GPT table later on, or the user just has his own format), the bootloader code will have more space.

msrobots

Maybe I am wrong, but as far as I could follow, the current plan for the boot rom is to

1. try serial
2. try flash
3. try boot sd via cluso
4. run TAQOZ and TAQOZ will read SD on its own, reading some start script.

loading from serial or flash can load the complete HUB including ROM area
loading from sd-boot can overwrite TAQOZ rom area, but maybe not itself. (buffers?)
loading from TACOZ might need to keep the rom area to have TAQOZ stay alive

A sd boot via cluso will require a second stage loader to load a complete image, but allows for any variation like own partition, just x sectors from somewhere, whatever you can cram into 256 bytes. But you already have a initialized SD card and should have a callable routine at a fixed rom address to load sector x to hub address y.

At the time cluso-boot runs TAQOZ is not alive yet, TAQOZ byte codes in the boot sector make no sense and are not needed since TAQOZ will read the sd by itself.

But maybe I am completely wrong here,

Mike

David Betz

msrobots wrote: »

1. try serial
2. try flash
3. try boot sd via cluso
4. run TAQOZ and TAQOZ will read SD on its own, reading some start script.

Why is there a need for two SD boot options? Why not just skip 3?