Shop OBEX P1 Docs P2 Docs Learn Events
Porting FSRW SD Reading routines to P2: Now boots from SD! — Parallax Forums

Porting FSRW SD Reading routines to P2: Now boots from SD!

RaymanRayman Posts: 14,641
edited 2015-12-24 12:47 in Propeller 2
I've been working on this for fun, although I think others could do it better.
Almost finished.

This will eventually load images (or maybe boot code) from SD to HUB RAM

Right now, it does everything that "mount_explicit" does in FSRW.

What's left isn't very complicated.

This is rigged for P123-A9 with the uSD card on my 4.3" LCD adapter board, but setttings can be changed.
It outputs a lot of info about the SD and FAT over serial interface.

I'm thinking that once I remove the serial stuff, the whole file loading code can fit in one cog, we'll see...



Update: See post on 24Dec15 for fully functional boot from SD code.

spin
spin
fsrw_comms2c.spin
30K
«1

Comments

  • TubularTubular Posts: 4,702
    Nice work Ray

    Your displays arrived - thanks. Took me a little while to find that micro sd socket. Its neatly hidden

  • RaymanRayman Posts: 14,641
    edited 2015-12-13 22:56
    Glad you got it!

    Almost there... This version lists the contents of the root directory.
    (also I added CRC reading for blocks, which new cards seem to require).

    Still fits in one cog, but running out of room... Have to remove serial output stuff soon...

    spin
    spin
    fsrw_comms2d.spin
    32K
  • RaymanRayman Posts: 14,641
    edited 2015-12-13 23:09
    I see how long filenames work now, looking at directory contents and info here:
    https://technet.microsoft.com/en-us/library/cc776720(v=ws.10).aspx

    Doesn't look like it'd be too hard to support long filenames. But, so close to having it fit in a cog that won't touch it for now...
  • RaymanRayman Posts: 14,641
    This version boots P2 from file on SD called, P2BOOT.BIN

    I'm cheating here and not using FAT though. This one assumes that file is in consecutive sectors, which may not be true, except for freshly formatted disks.

    Still fits in one cog.

    spin
    spin
    fsrw_comms3b.spin
    33K
  • mindrobotsmindrobots Posts: 6,506
    Dang, Ray!

    Good job!!

    On my need to try list.
  • RaymanRayman Posts: 14,641
    I'm using the serial output code that you posted. It was very helpful in getting this going...

    I think I have a plan for FAT... There can only be 64 sectors at most in a 512kB file.
    So, I'll just use LUT to create a list of sectors used by the file.
    Will then just load from those sectors until filesize is reached.

    Think I can still squeeze this into one cog, but it's going to be close.
  • Cluso99Cluso99 Posts: 18,069
    Rayman,
    Glad you are doing the FSRW version.

    I am tackling Kye's version (pasm code only) on P1 at the moment, trying to minimise code space and simplify, plus understand the boot procedure too. Then I can convert to P2 and see how it compares.
  • rjo__rjo__ Posts: 2,114
    Very nice. Worth a study. Can't test til my A9 arrives.
  • RaymanRayman Posts: 14,641
    The big difference with Kye's version is that it supports long filenames and sub-directories.
    With, P2 there's plenty of room to include those functions, so it would be great to have it ported to P2.
  • Cluso99Cluso99 Posts: 18,069
    edited 2015-12-16 17:55
    While Kye's version supports sub-directories, I didn't think it supports long filenames.
    It does support two SPI speeds.

    BTW I am only looking at the PASM routine which provides minimal SPI support plus initialisation commands and read/write blocks. It uses the whole cog space but I am currently shrinking that code at the slight expense of speed.
  • RaymanRayman Posts: 14,641
    That's funny, I thought it did support long filenames.

    But now, I just looked at his appnote and his code and there is no mention of long filenames.
    Actually, there is no mention of 8.3 limit either.
    But, I guess you know better as you're looking at the code.

    It's pretty trivial to add long filename support, btw.
  • jmgjmg Posts: 15,173
    Rayman wrote: »
    It's pretty trivial to add long filename support, btw.

    Does that include support for spaces in file names ?
    8.3 is (just) tolerable, but if it can fit, a more tolerant file system would save a lot of novice issues & be great.

  • Cluso99Cluso99 Posts: 18,069
    edited 2015-12-17 04:37
    I believe a license from MS is required to use long filenames. I cannot believe how they got a patent on it!
  • potatoheadpotatohead Posts: 10,261
    That was invalidated. Atari did it before MS, and did not patent. It was discovered in some Linux research.
  • Cluso99Cluso99 Posts: 18,069
    potatohead wrote: »
    That was invalidated. Atari did it before MS, and did not patent. It was discovered in some Linux research.

    Excellent news! Not that I am concerned with supporting long filenames, just that I didn't believe a patent should have been granted on this. It is like being able to patent a 128-bit processor. It is just a logical step.
  • RaymanRayman Posts: 14,641
    I guess it depends on how much ROM space Chip wants to give this then...

    The boot file could be a long filename in a subdirectory.

    What I posted is probably the most minimal thing that would work. It takes about 2 kB of ROM, maybe a bit less. Heard the ROM is 16kB.
  • potatoheadpotatohead Posts: 10,261
    edited 2015-12-17 17:20
    I just did some research. The patent may still be a factor. It was upheld in Germany... I was not able to verify the status in the US this morning.

    But, infringement consists of creating a file, it does not appear to be related to reading a file.

    Before we include any support beyond 8.3, more work should be done to verify and perhaps clarify the above.

    Given code length, I still much prefer either Peter's method or a partition. Code length is a small fraction of any filesystem support. Heck, including both doesn't even move the needle, and it's robust. Once we've got a couple really basic things sorted, it's gonna always work. Just saying... :)



  • msrobotsmsrobots Posts: 3,709
    In the Obex(Ithink) I found a version of Fat_Engine supporting reading the long filename for display or so.

    But for boot purpose in the rom I do not see the need to support long filenames. The name of the boot file has to be in ROM so it will be static. So something like p2boot.bin would do it.

    Enjoy!

    Mike
  • jmgjmg Posts: 15,173
    msrobots wrote: »
    But for boot purpose in the rom I do not see the need to support long filenames. The name of the boot file has to be in ROM so it will be static. So something like p2boot.bin would do it.
    That's true, however, often ROM code is loaded and used by other user calls.
    In that case, being a little smarter is very useful.
    Of course, this presumes the feature can fit into a COG

  • RaymanRayman Posts: 14,641
    Can we access rom after boot?
    I thought it was hidden...
  • msrobotsmsrobots Posts: 3,709
    As far as I remember ROM gets copied to RAM on boot time.

    Then your program has to decide if it overwrites/reuses the RAM locations or not.

    Enjoy!

    Mike
  • potatoheadpotatohead Posts: 10,261
    It all will be in RAM. The ROM doesn't stay mapped.

    Sure wish we could write lock the lower 16K so it is harder to trash.
  • RaymanRayman Posts: 14,641
    edited 2015-12-18 00:39
    Hmm... I'm not sure if you'd want to reuse ROM or just load your own code then...

    If it's just 16k out of 512kB, seems just as easy to load your own SD code...
  • potatoheadpotatohead Posts: 10,261
    A protect would prevent the ROM shipped code from getting trashed by programs being developed on it.

    Any other use means just loading your own code.

    ROM gets copied to RAM. Then booting happens. Once boot is done, user code does whatever the user wants.
  • msrobotsmsrobots Posts: 3,709
    Yes, the Idea came from P2-hot, not having much ROM. Basically the goal was to have the encryption and the monitor code available at boot time.

    In the current iteration @chip said that 16k are possible/planned. Some people talk about a build in assembler or even spin compiler. @Chip mentioned a lot of time the wish for a self hosted system.

    But IMHO that would make more sense with some real executable ROM available always. Since we have hubexec we could jump into any ROM routine from any COG. What about objects that would reuse the ROM in RAM like @jmg mentioned? Say jump into the monitor or use encryption for own purposes?

    They will fail if the lower 16k are used for other purposes. So nobody really can use the space for other purposes. Not without the risk of not being able to use object xyz from the OBEX.

    Sure you might be able to say 'I do not use encryption' and can reuse that part of the ROM in RAM as buffer or for variables. But what a pain for the programmer or compiler writer to handle this?

    OBEX object x can not be used with object y because it uses lower HUB routines RAM space and object y also?

    Either we have some very small boot code in RAM not needed after boot/secure boot or we need real ROM to reuse some of the code in ROM.

    Or all ROM code is able to relocate and there is some instruction to load a block of ROM to some given HUB location.

    Enjoy!

    Mike

  • jmgjmg Posts: 15,173
    msrobots wrote: »
    Or all ROM code is able to relocate and there is some instruction to load a block of ROM to some given HUB location.
    That's a good question - I think chip made COG/HUB/LUT binary compatible, and there are relative jumps, so code could be made relocatable.
    That leads to the question of what code size impact does relocatable code cause ?

  • msrobotsmsrobots Posts: 3,709
    jmg wrote: »
    msrobots wrote: »
    Or all ROM code is able to relocate and there is some instruction to load a block of ROM to some given HUB location.
    That's a good question - I think chip made COG/HUB/LUT binary compatible, and there are relative jumps, so code could be made relocatable.
    That leads to the question of what code size impact does relocatable code cause ?
    A relative jump is not bigger in code size as a absolute one, I guess.

    But building a code library to load blocks of code somewhere via a instruction just to use it is a pain also.

    IMHO real ROM would make more sense to me.

    At least some way to write protect the lower 16k and some way to find out if write attempts are made.

    Enjoy!

    Mike


  • potatoheadpotatohead Posts: 10,261
    Seconded.
  • jmgjmg Posts: 15,173
    msrobots wrote: »
    At least some way to write protect the lower 16k and some way to find out if write attempts are made.

    Agreed.
    msrobots wrote: »
    IMHO real ROM would make more sense to me.
    Not sure what you meant ?
    The ROM is real ROM - or did you mean memory mapped ROM ?
    I think that structure is harder to compile and meet speed/size specs on, whilst the planned small serial ROM is an OnSemi IP block, tightly optimised for size and likely top-mask changeable.


  • potatoheadpotatohead Posts: 10,261
    Yeah, that is what Chip told us. There is a little state machine that just blasts the contents of the ROM into RAM at boot.

    I was thinking, since COG ID is where some chip configuration is done, like fuse access, etc, maybe it could also write mask that 16k for the "treat it like ROM" use case.

    Ram copy is fine, but can get trashed pretty easy.
Sign In or Register to comment.