Load a binary from SD card?

ItsAFeatureNotaBug

Hi all, long time developer but first time poster on this community, so go easy on me!

I've been working with the Propeller Board of Education with Spin for a while. I found the ability to load at runtime different eeprom binaries from the sd card useful. When I switched over to GCC, I have struggled to replicate this functionality. Despite searching this forum and the GCC wiki, I haven't found any clues.

Can someone point me in the right direction?

Thanks in advance for your help.
Brendan

Electrodude

You can load PropGCC binaries from an SD card from a spin program. Do you want to load a binary with a PropGCC program? I doubt this is possible. If you can get PropGCC to use Kye's SD block driver (it might already) or modify the block driver you use to have the same bootloader functionality, then it should be pretty easy, just a matter of porting spin to C. Otherwise, it is definitely impossible with LMM or CMM, because those modes fetch their code out of hubram, and hubram isn't usable during a reload because it's being reloaded. You might be able to do it with a cogc program that talks to the SD cog.

Many will disagree with me and I don't feel like arguing and you don't have to take my advice, but I really think Spin is an infinitely better language for the propeller than C is, especially if you've already gotten past the hurdle of learning Spin.

jazzed

PropellerGCC is an embedded system tool chain. There is no operating system specifically associated with it.

Dave Hein's Spinix system allows starting propeller programs from a command line interface. There are other monitor systems that allow running programs.

Electrodude

jazzed wrote: »

PropellerGCC is an embedded system tool chain. There is no operating system specifically associated with it.

Dave Hein's Spinix system allows starting propeller programs from a command line interface. There are other monitor systems that allow running programs.

I think you misunderstood his question. Kye's SD driver, and probably others, can boot .binary and/or .eeprom (at least one, not sure if both) files without an operating system, just a normal spin program.

jazzed

Electrodude wrote: »

I think you misunderstood his question. Kye's SD driver, and probably others, can boot .binary and/or .eeprom (at least one, not sure if both) files without an operating system, just a normal spin program.

I don't use Kye's SD driver so I don't understand your context, but Spinix and other monitor programs can run .binary files.

PropellerGCC produces .elf binaries. The propeller-load program can convert .elf binaries to spin-like .binary files.

Dave Hein

Loading a binary from SD to hub RAM requires that the loader either runs from a cog or from the high end of memory. Any hub RAM that is used for a mailbox or data buffer must also be in high memory. Spinix uses a loader cog written in PASM in addition to the SPI driver cog. The mailbox resides within the last 512 bytes of hub RAM. I don't know how Kye's driver works, but the SPI driver cog may also run the loader as well.

The problem with doing this with PropGCC is that the SD mailbox is located in an arbitrary location in hub RAM. Even if the loader was in a PASM cog, the mailbox would eventually be clobbered by the program being loaded from SD. In spinix, I use a special file driver with PropGCC that uses the same SPI driver and mailbox as the Spin code.

So the solution for PropGCC is to use a special SPI driver that uses a mailbox at the high end of hub RAM. If you are interested in pursuing this I could provide a bare-bones version of spinix that provides that functionality.

EDIT: This only works with LMM programs because it has the capability to protect the high end of memory from being overwritten. CMM programs don't have that capability, though it can probably being done at some point. I also haven't figured out how to load and run XMM/XMMC programs from SD, but that is doable as well.

DavidZemon

This is all theoretical - I've no idea how the Spin programs currently work so I'm not basing off that.

Since EEPROM is loaded via SPI or I2C (right?), a program could read blocks from the SD card and write them to the EEPROM then force itself to do a reset. It would cost a few pins (don't know how many pins are used in the current implementations) but should work. It's also not dependent on any one implementation of the low-level drivers.

EDIT
Nevermind... not a very reusable method is it?

jazzed

Dave Hein wrote: »

Loading a binary from SD to hub RAM requires that the loader either runs from a cog or from the high end of memory. Any hub RAM that is used for a mailbox or data buffer must also be in high memory. Spinix uses a loader cog written in PASM in addition to the SPI driver cog. The mailbox resides within the last 512 bytes of hub RAM. I don't know how Kye's driver works, but the SPI driver cog may also run the loader as well.

The problem with doing this with PropGCC is that the SD mailbox is located in an arbitrary location in hub RAM. Even if the loader was in a PASM cog, the mailbox would eventually be clobbered by the program being loaded from SD. In spinix, I use a special file driver with PropGCC that uses the same SPI driver and mailbox as the Spin code.

So the solution for PropGCC is to use a special SPI driver that uses a mailbox at the high end of hub RAM. If you are interested in pursuing this I could provide a bare-bones version of spinix that provides that functionality.

EDIT: This only works with LMM programs because it has the capability to protect the high end of memory from being overwritten. CMM programs don't have that capability, though it can probably being done at some point. I also haven't figured out how to load and run XMM/XMMC programs from SD, but that is doable as well.

Doesn't the __stack_end parameter work for any memory model? I.E. propeller-elf-gcc [blah...] -Wl,--defsym,__stack_end=0x7000

See this forum post as an example.


I forgot to mention that recent versions of SimpleIDE automatically generate .binary copies of programs created by propeller-gcc by issuing the required propeller-load command. Also, the "-Wl,--defsym,__stack_end=0x7000" parameter can be set by copy/paste into the Project Manager -> Compiler -> Other Options field.

Dave Hein

I've never used the __stack_end parameter, but that would work when the protected area is fixed. In spinix, the protected area can change depending on which drivers or background processes are loaded. LMM allows the end of stack to be overridden by the value of PAR. I don't think CMM has that feature. I need to look into it some day.

jazzed

Dave Hein wrote: »

I've never used the __stack_end parameter, but that would work when the protected area is fixed. In spinix, the protected area can change depending on which drivers or background processes are loaded.

Sorry Dave, I just assumed Spinix worked like the other loader systems preceding it where a simple rendezvous mailbox can be put at end of memory and provide an interface to PASM or other drivers.

Anyway, we accommodate the rendezvous system with propeller-gcc binaries by specifying the __stack_end. Any memory above __stack_end will remain intact, and programs with appropriate libraries can use the rendezvous system resources for device driver communications, services management, and program parameters/exit codes. All of that is theoretical though.

Some propeller users have implemented such systems, but the clarity of service implementation description for replication or the simplicity has never been really acceptably recognized by more than a few people at a time (I.E. those who designed these things are happy with the results, but no one else seems to care or be willing to adopt such things in masse).

Parallax Education only ever wanted an embedded system (in this case, a simple monolithic program that loads and runs from RAM or EEPROM without special requirements) and that's what they got. I have made some inroads on and off at convincing them of the benefits of using loader/monitor systems, but they have never been considered important enough or simple enough to be implemented as a Parallax product.

doggiedoc

@Brendan - I don't know the answer to your question, but I wanted to take a moment to welcome you to the forums!

Welcome!

Doc

Mike Green

The loader from FemtoBasic (sdspiFemto.spin) can be used without the rest of FemtoBasic and runs in its own cog to load from either an EEPROM or SD card. It doesn't have any code to look up files on the SD card, so that has to be done by something else and a sector address (on a 512 byte boundary) has to be provided. It communicates with other cogs via an 8 byte "mailbox". There's no PropGCC version, but it's mostly PASM and could be easily ported to work as a PropGCC library routine.

The bottom line is that there's no ready-to-go solution that I'm aware of, but there are several partial solutions that can be adopted.

jazzed

Mike Green wrote: »

The loader from FemtoBasic (sdspiFemto.spin) can be used without the rest of FemtoBasic and runs in its own cog to load from either an EEPROM or SD card. It doesn't have any code to look up files on the SD card, so that has to be done by something else and a sector address (on a 512 byte boundary) has to be provided. It communicates with other cogs via an 8 byte "mailbox". There's no PropGCC version, but it's mostly PASM and could be easily ported to work as a PropGCC library routine.

The bottom line is that there's no ready-to-go solution that I'm aware of, but there are several partial solutions that can be adopted.

Mike's loader is one of the most popular judging by users on these forums. OBC and others have used variations of it.

I will support Q&A for anyone willing to use Mike's loader (or other simple mailbox systems) with PropellerGCC. However, I don't have time to start such a project.