Loading .binary files from SD card

David Betz

Off and on there are questions in the forum about how to load programs from SD card. I believe there are various OS-like options for doing this but I'm thinking it might be nice to have a C runtime library function to do this. The idea would be to have functions like ChainToPEX or ChainToBinary that would replace hub memory with a program from an SD card and start it. This would be like the old "chain" command that used to be in old versions of Basic. It is also similar to what Unix/Linux does with the exec() functions. In fact, maybe it would be better to name the new library functions after those. In any case, I'm wondering if anyone has done anything like this using propgcc. I know Dave Hein created Spinix which has a shell that performs this function. There is also the PropWare library that I'm not very familiar with that might have something like this. Can anyone say what has been done in this area so I don't end up going off to reinvent the wheel?

Thanks,
David

Dr_Acula

Hi David,

http://forums.parallax.com/showthread.php/128779-KyeDOS-an-operating-system-for-the-Propeller?highlight=kyedos

Hopefully there is something in there that you can use. It can load binaries off an SD card and run them. Type "Help" to get the commands. This is Kye's SD driver code with lots of tweaks as documented in the comments section.

I'm not sure about how easy it would be to run through Spin2C. Last time I tried (which was admittedly a couple of years ago) it couldn't process a couple of commands Kye used in his code. But if it does go through spin2cpp that would make your job pretty easy

David Betz

Dr_Acula wrote: »

Hi David,

http://forums.parallax.com/showthread.php/128779-KyeDOS-an-operating-system-for-the-Propeller?highlight=kyedos

Hopefully there is something in there that you can use. It can load binaries off an SD card and run them. Type "Help" to get the commands. This is Kye's SD driver code with lots of tweaks as documented in the comments section.

I'm not sure about how easy it would be to run through Spin2C. Last time I tried (which was admittedly a couple of years ago) it couldn't process a couple of commands Kye used in his code. But if it does go through spin2cpp that would make your job pretty easy

Thanks for the pointer. I know how to do this, I mostly wanted to find out if someone had already written a propgcc function to do it.

Dave Hein

I think the issue with loading a binary using C is that the code would need to execute from the high 512-bytes in hub RAM. This also means that the mailbox for communicating with the SD-SPI driver cog would need to be in the high 512 bytes. That would allow for loading a binary as large as 31.5K in size. Any program that would have less than 512 bytes left for the stack and heap space probably wouldn't be practical, so the 31.5K limit shouldn't really be a problem.

Another approach is to start a cog with a snippet of PASM code to load the program. That's the way spinix works, and I assume most loaders work that way. You still need the mailbox to be in the upper 512 bytes, but you don't have to worry about a stack for the loader. The spinix loader assumes that all of the sectors in the file are sequential, so it requires that the cluster size must be at least 32K, or at least it must use sequential clusters.

EDIT: Here's the runprog.spin object that I use in spinix. It assumes that the calling program has stopped all of the cogs except for the SD-SPI cog, and has freed and cleared all of the locks. This program also handles passing argc and argv to C and Spin apps. So you can ignore the code that handles that, and only look at the "stand_alone" code. It also handles programs that may have different values for clkfreq and clkmode than are currently being used, so it treats the first sector with special care to avoid over-writing locations 0 to 4. If that's not an issue you can just read the first sector directly into location zero.

David Betz

Dave Hein wrote: »

I think the issue with loading a binary using C is that the code would need to execute from the high 512-bytes in hub RAM. This also means that the mailbox for communicating with the SD-SPI driver cog would need to be in the high 512 bytes. That would allow for loading a binary as large as 31.5K in size. Any program that would have less than 512 bytes left for the stack and heap space probably wouldn't be practical, so the 31.5K limit shouldn't really be a problem.

Another approach is to start a cog with a snippet of PASM code to load the program. That's the way spinix works, and I assume most loaders work that way. You still need the mailbox to be in the upper 512 bytes, but you don't have to worry about a stack for the loader. The spinix loader assumes that all of the sectors in the file are sequential, so it requires that the cluster size must be at least 32K, or at least it must use sequential clusters.

EDIT: Here's the runprog.spin object that I use in spinix. It assumes that the calling program has stopped all of the cogs except for the SD-SPI cog, and has freed and cleared all of the locks. This program also handles passing argc and argv to C and Spin apps. So you can ignore the code that handles that, and only look at the "stand_alone" code. It also handles programs that may have different values for clkfreq and clkmode than are currently being used, so it treats the first sector with special care to avoid over-writing locations 0 to 4. If that's not an issue you can just read the first sector directly into location zero.

My plan was to have a C function that loads the cluster map of the file into a COG image that could read the clusters into hub memory without using any hub buffers or mailboxes. That, of course, assumes that this program and the cluster map would fit in COG memory along with the SD sector driver. That might not be possible so it could be necessary, as you say, to have the SD sector driver running in another COG using a hub memory mailbox to communicate with the loader COG.