SD Card as EEPROM Substitute or Replacable Power-On Boot Medium with Extra Data

he1957 · 2009-08-15 16:24

Apologies for the longish Subject line.

I have been examining the circuit diagrams/schematics/printsets and power-up sequences for the Propeller chip and observe the connections and boot sequences for power-up ROM code that uses P28 and P29 for SCL and SDA respectively.· This prompts me to ask the following:

1. Any reason why an SD card could not be used as a substitute for·the "dedicated" EEPROM

Given the specific size of·the "default" EEPROM is "fixed" at 32KB (to match the Prop's internal memory size) and references are made to the ability to use larger EEPROM sizes:

2. What would be the memory size limit of either an EEPROM or some "other" (SD Card) device?

The FemtoBasic Interpreter (with LOTS of thanks and enormous gratitude to those contributors [noparse][[/noparse]it is an absolutely _fantastic_ piece of work!]) contains commands that reference both EEPROM and an SD card so:

3. How does one (easily?) keep track of the use of the EEPROM use [noparse][[/noparse]either at or greater than 32KB] (when not using the simple "save" command (in FemtoBasic) [noparse][[/noparse]or other {SPIN perhaps?} methods which I have yet to discover]?

Thanks in advance,

HarryE.
·

localroger · 2009-08-15 16:28

You have to use the EEPROM to boot the Prop because it's hardcoded, as in the silicon, to use I2C protocol for that part (or one compatible which might be larger). It's matched to the Prop's ram size, but you can use a larger EEPROM and the Prop will just load from the lower 32K.

SD cards use SPI protocol, totally different, plus need an initialization process to get them into SPI mode. However, it is possible to boot to a bootloader that can read SD, then boot again from the SD card from whatever of many files you want (see the OBEX femtobasic, PropDOS, and my own PropCMD).

On keeping track of EEPROM use, you have to do that yourself; there's no fixed protocol except that the lower 32K will boot the Prop.· I tend to favor leaving the EEPROM to its own devices and using SD for all mass storage, as it's much more versatile.

MagIO2 · 2009-08-15 21:14

Having a small PIC or AVR microcontroller that translates SPI to I2C would be cool for the boot-process. After boot the uC only works as repeater. Thus the propeller can takeover full control over the SD card after boot.

Advantage:
1. You only have to boot once - having a bootloader means to load the prop twice
2. You save 2 PINs

Rayman · 2009-08-15 22:12

Is it possible to use an EEPROM smaller than 32kB? I wonder... If you could and the Prop didn't choke, you might be able to put a little SD boot loader into a much smaller EEPROM...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

localroger · 2009-08-16 00:57

Rayman, it wouldn't be worth it; smaller EEPROMs see the high bits as "don't cares" and the Prop will load 32K whether it's there or not. It really doesn't take that long (programming the EE takes a lot longer) and the nice thing about using a bootloader is that once it's done, you can leave it alone as you do development on other more conveniently edited images. And how much is a 32Kx8 EEPROM anyway? I think Parallax chose that approach since they couldn't put flash on the Prop (process doesn't allow it) because it was a cheap way to deal with booting.

Cluso99 · 2009-08-16 03:35

I was intending to use a MC9S08 to replace the eeprom. But my time has had to be elsewhere. The cost would be roughly the same for a small bootstrap memory. The MC9S08 would just fill the remaining 32KB with blanks. A small PIC could do the same job.

I have been looking at the PIC10F2xx in SOT23 6pin packages but I do not think there is enough space for prop bootstrap code after the I2C protocol program in the pic. see the PIC Programming thread.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Mike Green · 2009-08-16 04:30

1) It's possible (easy) to just have a small program in an EEPROM that boots off an SD card. You could even do it with FemtoBasic since that has an autostart capability. If you don't need the keyboard or display, you could use DongleBasic to do the same thing. It's just a version of the same Basic interpreter that makes minimal use of the Prop's I/O.

2) There was a version of FemtoBasic that used the last 16 bytes of each 32K area in EEPROM to store a file name. In the interest of code space, this facility was removed, also because an SD card would furnish the same functionality.

Cluso99 · 2009-08-16 07:25

Mike, I used PropDos and Femto to do exactly that (boot from an SD card). Works great

I used it to boot ZiCog, but of course can boot any prop binary on the SD card.

When I have time, I (or anyone up to the task) can/will write (extract) the minimum code (for the eeprom or to be loaded by something else simulating an eeprom) to boot PropDos which would then be capable of asking for a binary to run. This would mean that the eeprom code could be a "standard" object which only requires the pin to the SD card to be provided. Although this boot process would be a two stage process, I am sure it would be a worthwhile project.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

localroger · 2009-08-16 13:11

@Cluso99, all we really need is for the bootsd routine from sdspifemto to be grafted into the block driver rockiki and lonesock are using for the new fsrw, and you'd have a solution that needs like 10 lines of spin to complete it.

Cluso99 · 2009-08-16 13:28

localroger: What I am after is a minimum footprint boot code, so it will most likely be slower and all spin.

PropDos and PropCMD and sdspiFemto already does this process and the new fsrw would be even better. I would really like to see if it could be done in 0.5KB but have no idea if it can be done this small yet.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Mike Green · 2009-08-16 14:13

Booting cannot be done with Spin. You can't really control where in hub memory the various bits and pieces of your program reside and the new program that's being loaded will likely overwrite parts of your boot program. The best you could do would be to have a Spin program that's quite small and reads the new program into the high (unused) end of hub ram, then starts a small assembly routine to copy the newly loaded code into its proper position and starts a new Spin interpreter. Both the boot routine and the loaded program would have to fit in 32K at the same time. The system clock speed and mode may change and the assembly routine would have to take care of that.

localroger · 2009-08-16 15:19

@Cluso99 -- as well as what Mike said, why is minimum footprint important? The bootloader will be in EE, which if you have SD you don't need for anything else, and the Prop firmware is going to load 32K of bytes whether they're there in the EEPROM or not. I personally wouldn't waste the code space for EE access in my SD-capable application so the bootloader doesn't even need to be on the SD card once you get it working. Even sdspifemto, which has a lot of unnecessary I2C EEprom code in it, fits in a cog, and the bootloader would amount to fsrw + block driver + PUB fsrw.start / popen file / bootsd. It would be even smaller if you grafted the bootsd routine from sdspifemto into the new fsrw blockloader which lacks the i2c overhead and is also sdhc and fat32 capable.

Ziggy252 · 2009-08-16 15:30

It does raise the question of how we're going do this with the Prop II. 4Mbit I2C EEPROMs are not nearly as easy to come by.

Cluso99 · 2009-08-16 15:39

Mike: Yes, I must confess I missed that point.
localroger: The reason I want minimum code space is that I am trying to replace the eeprom with a miniature micro (pic or mc9s08). Once the prop boots from the SD card, I don't want the eeprom present as I am using the pins for a data bus.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Mike Green · 2009-08-16 15:48

I don't think Chip has made any particular commitment to I2C EEPROM for booting the Prop II and there's no particular reason why the Prop II has to load all 256K of hub ram on an initial boot. There have been hints dropped that the Prop II could load from several different kinds of media. There's no particular reason why the Prop II couldn't boot from an SD/uSD card or SPI flash. There's no file system needed. Just start reading a program from location zero on the device. The program stored there has the information needed on its length and the loader could clear the variable area as the current sdspiFemto loader does.

Mike Green · 2009-08-16 15:56

Cluso99,
If you use the "bootblock" convention of the FAT file system, you could easily store a 32K Spin program in the MSDOS compatible boot area of the FAT volume. The assembly loader function in sdspiFemto can easily be stripped out and, with a small Spin prefix, could easily fit in 1K in some little micro that's emulating an I2C EEPROM that disconnects itself completely after doing its job (until the next reset).

Jimmy W. · 2009-08-16 17:26

Hm, this sounds cool, I just got done playing with OTA zigbee updates, using a pic to talk to the SD card and have it talk i2c actually never crossed my mind, it would prevent double booting, would enable direct debug booting, an extra download verification, and you could use the PIC as a watchdog in case something bad happened to the prop.
Jimmy

Cluso99 · 2009-08-17 04:40

Mike: Yes, that sounds like a good idea to use the FAT boot sectors. Can the PC place code in this area on the SD card? We have to get it there somehow without special hardware.

Jimmy: This sounds even better

Boot straight off the SD.

It would need a larger micro with more pins, but certainly would be doable, but it would need to jump out of the way after initial booting, and back in again on reset. In this instance, it would also be possible to use the download pins and protocol of SI/SO (pins 30/31) instead of the eeprom emulation. Not sure which would be faster or more compact.

Thinking a little further, it may not be fast enough to get the code from the SD card and be ready to emulate the eeprom in the time the prop is ready for it, so downloading may have to be used.

Anyone care to comment??

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Mike Green · 2009-08-17 05:05

Getting the data into the boot sectors is a formatting task. I think we really need an SD card formatting program that runs on the Propeller and can format an MSDOS compatible card suitable for this kind of bootloading.

The idea is that booting would be a multistep process. The boot mini-micro would emulate an I2C EEPROM containing a small (<1K) SD card bootloader that would load (and start) a Spin program up to 32K off an SD card beginning at a fixed location. This Spin program could be the complete application or might be an operating system or file loader that would load a FAT file with a specific name from the SD card.

Once the mini-micro is done, it could drop into a mode where it uses one of the I2C lines (like SCL - pin 28) for the SD card select and just copies it to the SD card select line. It would leave the SD card unselected until then so the SD card could be connected to I/O pins 28-31.

BradC · 2009-08-17 05:39

Cluso99 said...
Mike: Yes, that sounds like a good idea to use the FAT boot sectors. Can the PC place code in this area on the SD card? We have to get it there somehow without special hardware.

dd is your friend. Provided the space on the card is unused (like sectors 1-63 on a partitioned card) you can use dd to copy your binary wherever you like. You could comfortably hide a bootloader in there and have a very small fixed-location booter load it and run it.

I have one here that simply looks in the root of the card for boot.bin. If it finds it, it simply loads it and boots into it. If it does not then it falls through to a routine that lets you know it's panicing for a while before re-booting and re-trying. The SD card stuff I'm using is an unmodified copy of sdspiFemto.spin

PUB Boot_SD
  sd.start(@iocontrol)
  if \sd.mount(24,25,26,27) < 0
     abort
  if \sd.popen(String("boot.bin"),"r")
     abort
  sd.bootSDCard

There is really not a lot to it [noparse]:)[/noparse]
If that routine returns then we've failed and so go into the panic loop before restarting the processor.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?

Cluso99 · 2009-08-17 06:50

Thanks Brad. I already use that method (from PropCmd/PropDos) on the TriBlade to boot into ZiCog. However, my code is not minimal. I am working on this now and will use the new SD driver (stripped down) from rokicki and lonesock. Unfortunately, I cannot test - left my hardware 800km away :-(
Currently using the femto drivers is about 6KB. Fortunately, still a bit of code to carve out.

I presume dd is easy to use as we will need to make instructions for it's use if we go this way (boot sectors 1-63 would be 31.5KB) which is almost the complete hub space.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

he1957 · 2009-08-17 07:33

Wow,

What a great buch of creative and thoughtfull comments and ideas. (Aside: dd if=input_file of=/device/outfile (which can be raw devices [noparse][[/noparse]yes, easy])

Of course I had neglected to "remember" the serial protocols used for EEPROM and SD Card when I asked the original question - duh! None-the-less, Amazing what you people have thought of. OK, similar in theme but either:

1. A minimal EEPROM loader that either prompts for an SD Card filename (assuming it finds one) to load (into RAM) or
2. Same but loads a secondary loader from SD Card and asks or defaults to some image

If no SD Card, the EEPROM routing defaults to the EEPROM.

I guess this prompts the question; can such an EEPROM routine load the target above itself to preserve it from being overwritten (or relocate itself) ? Along same, could such images be loaded elswhere; ie: are Propeller images relocatable?

It looks like PropDOS can do what I was originally thinking of; Boot (loads PropDOS) from EEPROM then allows you to either auto-launch some image into RAM or manually select same.

Cheers,

HarryE.

Cluso99 · 2009-08-17 12:16

he1957: PropDos and PropCmd both do #1 & #2 already. It boots a binary file "autoexec.bat" if found and you don't hit a key quickly, otherwise it will ask what you want allowing you to load a different named binary.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

dMajo · 2009-08-17 15:05

Have a read

chers

SD Card as EEPROM Substitute or Replacable Power-On Boot Medium with Extra Data

Comments