How to bootload off an SD card using only one EEPROM?

Ravenkallen

Well, once again, the title pretty much sums it up. My current project(Propeller PDA) uses two eeproms for boot loading. One EEPROM holds the main control program and the other holds the new program booted up from the SD card. This method is unorthodox at best and very impractical at worst...So i guess my question is. How(In theory) can one boot off an SD card using only a single 64kilobyte eeprom? How would it work? Is there someway that one could just directly write the SD data to the ram?

I am not looking for step by step instructions, i am just looking for a general theory. I was thinking that one could load the new program into the EEPROM and before shutting off, it would load the main program back into the EEPROM. The only problem with this is that if power was removed before the system shut off correctly, the whole system would cease to function..I know a lot of people on here only use a single EEPROM, but i just can't figure out how it would work....ANY ideas

yeti

Mayhaps SDLoader yields further inspiration: http://obex.parallax.com/objects/620/

prof_braino

Ravenkallen wrote: »

How can one boot off an SD card someway that one could just directly write the SD data to the ram?
general theory....ANY ideas

I'm planning to have a FORTH kernel in EEPROM. The kernel can be set such that the an application can be executed instead of the interactive command line.

For this case, the executed application would be the word that starts loading an executable image from a predetermined area of the SD card, similar to booting from a floppy.

I'm pretty sure one could load any executable image (forth or spin or assembler, etc) into ram, launch it on a cog, and turn off the forth boot launcher cog. FORTH disappears and the target application runs as if it were always the only program present.

Its pretty straight forward, or did I miss the point of your question?

jazzed

Dave Hien's Spinix supports a shell program that can start other applications.
I'm sure other file-systems can do it too. No need to learn RPN.

Dr_Acula

KyeDOS can do this too. It boots up with a startup menu that displays all files on the SD card that end in .BIN (images of compiled spin/pasm files.) At the moment you type in which one you want to run, but you could easily add one line of SPIN to auto run one.

The only catch with the version of KyeDOS I'm using is that it is a bit slow (3-4 seconds) to do this load, but I think Kye has a more updated version that is a lot faster.

vettezr1

DR-A where can I get a copy of that

Dr_Acula

An attachment is buried away in this discussion thread http://forums.parallax.com/showthread.php?t=122991 It is an interesting thread to read through.

This is set up for a version similar to the demoboard, with VGA on pins 16-23, keyboard, no mouse, and sd card on pins 11-15. You can change those in the software.

If you do use this program, maybe take a look at merging in Kye's faster code.

I'm a big fan of Kye's code as it can use FAT32 and also works with all my SD cards, even the smaller ones.

Nick McClick

The Propeller Platform SD's bootloader will load up a 32k image to RAM or load it to the upper half of a 64k eeprom based on filename. If no SD card is present, It will load whatever's in the upper half of eeprom. I did a video demo here.

Requirements are a 2gb or less SD card and 5Mhz xtal. You can grab the MIT licensed code from the project page. You can also take a look at the code for a better understanding of how it works.

Ravenkallen

Forgive my ignorance, but how is a prop able to boot from the upper 32K of a EEPROM? I thought it could only boot from the lower 32K. Is there some kind of command that you can make you do that?

Nick McClick

The lower 32k of eeprom is always the bootloader, the prop will always load that before anything else. That program loads and checks for an SD card. If it isn't found, it reads the upper 32k of eeprom into ram and starts running it, overwriting itself.

If an SD card is found, it reads the filenames, and depending on the filename it will load it directly to ram and start running it, or copy it to the upper 32k of eeprom.

Ravenkallen

AHHH, i am beginning to get it now, but how does the system write the data to the ram without accidentally overwriting the part of the RAM that is executing? And how does one even go about writing the whole ram? Thanks for the help. this question has been bugging me for a while

Dr_Acula

AHHH, i am beginning to get it now, but how does the system write the data to the ram without accidentally overwriting the part of the RAM that is executing?

That is the clever bit about parallel processing. The bit that is 'executing' is in a cog that has its own local 2k of memory. Each cog can access the main hub ram. You could have up to 8 cogs all overwriting the main hub ram.

How to explain this the best? (I've rewritten the following paragraphs 4 times now).

Ok, conventional program on a conventional micro - of course it can't overwrite itself (unless we are talking self modifying code)

Consider though a small program written largely in pasm. You wrap it up with its spin loader into a .bin file, maybe it is 3k, and then download it to eeprom. On bootup, the propeller puts 3k from eeprom to ram and runs it. When it gets to the instruction that starts a cog, the prop moves the next 2k into a cog. It then starts that cog.

Once that cog is started, the program is now in the cog, so it can go ahead and overwrite the entire hub ram. The program in the cog might be something simple like flashing a led, but it could also be complicated like an sd card reader that reads 32k off an sd card into hub and runs it. Thus the code in that cog can spawn other code.

For me, the most complex one to explain is the common scenario where there is a cog that loads a spin interpreter. Because spin is written in an environment that fits into the 32k of hub memory it is possible to assume it is actually running in hub, but it actually is running in the first cog. Theoretically, the spin cog interpreter could be fetching bytes from external ram rather than hub ram (this has been discussed in other threads, as it could potentially lead to Big Spin programs that can be bigger than 32k).

I think the above explanation is correct. If not, hopefully someone will jump in and correct me!

Ravenkallen

AHH, thank Dr_acula... I am starting to understand now, but one more thing. How can you access a I2C function or sd function(that is in SPIN/PASM) if it is going to be erased by the overwrite? Could you use a i2c driver that is written entirely in PASM and somehow communicate with it?
Maybe my understanding of the Propeller and cogs is not as firm as i believed...

jazzed

Ravenkallen wrote: »

How can you access a I2C function or sd function(that is in SPIN/PASM) if it is going to be erased by the overwrite? Could you use a i2c driver that is written entirely in PASM and somehow communicate with it?

That's how it's done. PASM can load from almost any source to HUB RAM and run a new SPIN program in a COG ... even with recycling the PASM loader COG. Mike Green cut that trail long ago.

Edit: Added more of Ravenkallen's quote. My comment was not referring to inter-cog communications, but to the load/boot process. Mailboxes (semaphores) and handshaking in many cases are used for inter-cog communications for *any* language that can reference the mailboxes.

Dr_Acula

A pure pasm program running in a cog can communicate with other cogs via hub. If you keep the protocol very simple, eg one byte for data, one for a flag to say data is present, then you can do all the comms in 2 bytes each way, or 4 bytes (one long). You can reserve a long (4 bytes) in hub as a postbox location for intercog communication.

You might put an I2C driver in one cog. You might have a keyboard driver in another cog. Keep the protocols simple and they can all chat to each other.

However, if you look through the Obex, not many objects are coded like this. Most are a mix of Spin and PASM, and it is the spin part that causes problems with overwriting, as that does have to stay in hub ram.

If you go hunting though, you can find objects that are pure PASM. Pullmoll wrote a few that are buried in the CPM emulation, for instance. The only bit of Spin is the bit that loads the cog, and that can be overwritten. All you need then is for the postbox location to be fixed (or known as part of the load process and passed when the cog is loaded).

I think there are some pure PASM drivers in the Catalina project as well. And some objects are almost pure PASM, eg the 4 port UART and keyboard objects.

Mike Green

The sdspiFemto.spin object in FemtoBasic does just what you're asking about (and some of the other objects mentioned do this as well). There's a PASM program that contains low level SD card I/O routines that read a 512 byte sector at a time from the SD card directly into RAM. There are higher level Spin routines that call the PASM low level routines to read the SD card partition table and directory to find the location of the file you want on the SD card. These eventually supply a starting sector number and file length (in sectors). They call the PASM low level read routine with a special option that indicates that this is a boot operation. The PASM routine stops the current cog with the Spin interpreter in it (so reading into RAM won't mess things up), reads the whole program into RAM starting at location zero, sets up the stack area and zeroes out the VAR area (since that's not saved in the file), then starts up a new copy of the Spin interpreter which starts executing the newly loaded program.

sdspiFemto can also boot from EEPROM including beyond 32K or EEPROM on other I/O pins than 28/29. It does it the same way, just reading from the specified area of EEPROM instead of an SD card. There's a similar routine for booting from a file on an SPI flash chip. Look at the Winbond/SRAM driver in the OBEX. These are all derived from the same EEPROM boot loader.

Nick McClick

Very interesting - I didn't know exactly how it worked, either, because I was thinking of a traditional single core ucontroller. Running the loader in pasm makes perfect sense.

groggory

I was planning on moving to a 6.25Mhz XTAL for my future boards due to the apparently free boost in performance. Is this feature really limited to the 5MHZ Xtal?

Thanks.

Mike Green

I can't speak for the other boot loaders, but the one in sdspiFemto calculates its delays using CLKFREQ during its initialization, so it's independent of the system clock frequency used. I2C is clocked so it's relatively insensitive to clock speed variations. There may be some minimum clock speeds for some devices and, for most devices, the maximum I2C clock speed is 400KHz. The Winbond driver works at 6.25MHz, but its SPI clock is close to the minimum clock high time in the flash datasheets at that system clock speed. I plan to add a NOP in the appropriate places in the next version so there'll be plenty of leeway, even at 100MHz. I think the same thing is true for the sdspiFemto SPI driver, so I'll be updating that in the future. It also seems to work fine at 6.25MHz.

Nick McClick

What Mike said - the Propeller Platform SD's bootloader is based on his sdspi Femto.

I just mention the 5Mhz xtal caveat because the bootloader that's flashed on the board is expecting a 5Mhz xtal. But you could update the eeprom with another value.