P2 SD Card Boot code for ROM

Cluso99Cluso99 Posts: 13,132
edited December 2017 in Propeller 2 Vote Up0Vote Down
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.
My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
Website: www.clusos.com
Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)

Comments

  • 5 Comments sorted by Date Added Votes
  • Here's my test results
    Melbourne, Australia
  • and another one
    Melbourne, Australia
  • ElectrodudeElectrodude Posts: 1,134
    edited December 2017 Vote Up0Vote Down
    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.
  • 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
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • 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?

Sign In or Register to comment.