Shop OBEX P1 Docs P2 Docs Learn Events
Code to boot from SD (updated for V27) — Parallax Forums

Code to boot from SD (updated for V27)

RaymanRayman Posts: 14,643
edited 2017-11-19 18:42 in Propeller 2
This was not so easy actually, but I just managed to update this boot from SD code to V27.
Been lots of changes to P2...

It is more or less a port of FSRW.
I think I posted for V10 before, but can't find where...

It loads code in a regular file and puts it at the beginning of RAM and then runs it.

Code all fits in 1 cog (but had to comment out a lot of status messages to do this).
spin
spin
fsrw_comms6a.spin
38K

Comments

  • cgraceycgracey Posts: 14,152
    Super, Rayman.
  • RaymanRayman Posts: 14,643
    This document gives a pretty good description of initialization process:

    https://www.infineon.com/dgdl/AP1612510_XE166_SDCard_FAT16.pdf?fileId=db3a30431ce5fb52011d298d7fc91b6d
  • tritoniumtritonium Posts: 543
    Ray,

    That pdf is for Fat16 which only supports up to 4 Gbyte.
    You sure that's a standard to aim for? It wont be long before SD cards of this size will disappear.
    For our purposes 4 Gbyte is huge, but getting them might be a problem soon.
    I certainly haven't seen anything that small recently in the shops, although plenty available on-line.
    Fat32 can manage up to 2 Tbyte cards with files up to 4 Gbyte, which should last a bit longer before becoming obsolete!
    The disc format is not too much different from Fat16, just a few adjustments.

    Dave
  • msrobotsmsrobots Posts: 3,709
    @tritonium,

    @Rayman's code takes this in account and supports FAT16 and FAT32. I personally think that support for FAT16 could be dropped.

    I see some other problem here, because in opposite to @Lonesocks driver the sector buffer is in HUB ram. That implies that it is not able to load the complete HUB ram without overwriting itself or its buffers.

    @Kye's Fat_Engine and the original FSRW are both a mix of SPIN and PASM and thus where able to reduce the COG-footprint. @Kyes FAT_Engine can load a complete HUB image of the P1 by keeping the sector-list in the COG (like Ray does in the LUT on the P2 currently) and 'moving' its sector buffer address, FSRW on the P1 does not really has a boot function, but the COG driver contains the sector buffer and is quite self contained.

    What Ray did here is to translate the Spin-Part of FSWR (doing the SD initialization) into PASM2 (great work!) the PASM to PASM2 part seems quite different. But that is OK, @Lonesocks sector driver is quite P1 specific providing read-ahead and write-behind with a sector buffer in the COG. There is some very nice code in there to transfer fast from HUB to COG or vice versa. The SPI routines are also quite P1 specific, but very, very cool code.

    @Ray,

    I really like it. You condensed it down to the absolutely needed steps to read a file. Very impressive. And quite readable for me, even if I am still at PASM1 level.

    Nice work.

    I will study it some more, a couple of years ago I went deep into FSRW and Kyes Fat_Engine and made some client-server RAID array able to use both engines alternative on both ends..

    Kye does the initialization already in PASM, so I want to compare the steps taken...

    Mike
  • RaymanRayman Posts: 14,643
    Hmmm... Maybe I could use LUT ram to store sector buffer?

    I guess I was thinking that boot would be a minimal thing, but maybe you would want to use all of HUB RAM.

    Then again, we may get an extra 16k at the top of 1MByte boundary that can be used for this?
  • msrobotsmsrobots Posts: 3,709
    thinking about it, just adjusting the buffer-address would do it, when loading start at 0 and then increment buffer address.

    or is that cheating?

    Mike
  • kwinnkwinn Posts: 8,697
    msrobots wrote: »
    thinking about it, just adjusting the buffer-address would do it, when loading start at 0 and then increment buffer address.

    or is that cheating?

    Mike

    No, not cheating, just trying hard enough!
Sign In or Register to comment.