Boot mechanism from SD card - ideas ??

Cluso99

I am currently defining a boot mechanism for my RamBlade board. I have mentioned this previously.

I intend to use a small loader in eeprom that only knows the location (propeller pins) of the SD card (or microSD card). It will perform the following...

1. The SD card will be checked for FAT16 (maybe also·FAT32 later)
   • If not found the propeller will stop
2. The SD card will be searched for a filename "AUTOEXEC.BAT"
   • If AUTOEXEC.BAT is not found, continue at Step 5
3. The first sector of AUTOEXEC.BAT will be read
   • It should contain a "filename.BIN" and·optional·parameters (filename = valid file name)
   • If a valid filename.BIN is not found, or the file does not exist, continue at Step 5
4. The·binary file "filename.BIN" will be located
   • The file will be·loaded into hub ram
   • The parameters (32 bytes) will be loaded into hub ram at $7FE0
   • The prop will then execute the binary in hub ram
5. Otherwise, the binary file "BOOTPROP.BIN" will be located, loaded into hub ram, and executed
6. It "BOOTPROP.BIN" was not found, the propeller will stop

Why have I included some parameters? So that I can pass options such as...

• If a serial port exists, what pins they are on, and baudrate
• If a keyboard exists, what pin(s) they are on
• If a video exists, what pin(s) they are on
• Xtal frequency

I have a specific case in my RamBlade as the pins are not the normal serial P30/P31. I also want to be able to load files directly to the SD card from the PC, so that a USB or PropPlug is not required. Therefore, I have to be able to tell the prop via configuration parameters on the SD card, what to do. Obviously, the parameters will be specific to the binary being loaded.
I do not have the luxury of knowing what is attached to the RamBlade for I/O when the SD card is being loaded.
Are there any comments on this method? Any flaws? Does this sound like it is usable for other projects? Any suggestions (without unnecessarily complicating the boot proceedure)?

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

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

Coley

Cluso,

I think this is fine as it is.

Regards,

Coley

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX - The home of the Hybrid Development System and PropGFX Lite

heater

That all sounds just fine to me as well Cluso.

However if I understand correctly the full EEPROM is loaded to the Prop no matter how much of it is used. So the need for a "small" boot loader seems moot. Looks like it could hold the full FAT driver plus plus combinations of serial, keyboard, video drivers. Customized for the available environment of course. So a full up mini DOS could be available from the get go complete with simple command shell or menu driven program selection.
Certainly have an AUTOEXEC possibility.

Edit: Scratch all that, I think I'm just catching up with the problem. Is it so that users cannot get to the EEPROM to program any customizations into it? There for it has to be hardware layout agnostic.

Not sure of the need for parameters in the AUTOEXEC though. Surly bin files one creates with the Prop Tool, or whatever, already have clock frequency, pins etc configured into them. Just like they do normally.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Post Edited (heater) : 12/22/2009 10:32:05 AM GMT

Cluso99

heater: I have a few reasons to make the eprom boot code minimal...

1. I never want to change it the eeprom boot code. The eeprom is disabled from being written by default.
2. It is my aim to subsequently replace the eeprom with a cheap micro, so minimal code size is required.
3. The environment is unknown at eeprom programming time.
4. All code changes are done on (to) the SD card.

It is possible the first binary loaded from the SD card may be a version of Propeller DOS or some such system. It will then permit loading of other binaries by a menu selection (e.g. ZiCog).

Initially ZiCog would be the binary loaded from the SD card, although I am thinking longer term. This method would also allow ZiCog to be passed parameters which could be used to determine if CPM2 or CPM3 is loaded, etc. This would allow us to release ZiCog binaries for those who do not wish to compile their own versions.

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

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

heater

Ah yes. I was wondering what happened to the "boot micro" idea.

All in all you have a sound plan there.

Wish we could get away from the "AUTOEXEC.BAT" name though, it's too DOSy for my tastes. But as we are using FAT I guess that's it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Dr_Acula

Sounds a great idea. Just a thought re the config files, will these be in text that can be edited easily? I'm just thinking of down the track you are out in the field, don't have access to the special program that made the config files, but you could always edit them in notepad. Eg like the config.sys file in DOS where you could even work out what the syntax was from other commands.

I like the idea that you don't necessarily need a prop editor to get this working.

@heater, if AUTOEXEC.BAT is too Dossy, what about ZICOG.SYS (or anything ZICOG.*)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller

heater

Cluso seems to be aiming to read that autoexec.bat file without the use of FAT just the SD block driver. As stated only the first sector. It could well be edited with any text editor provided it is short (err...The file that is not the editor)

Don't forget that FAT is using clusters, or whatever they are called there, so there will be many kilobytes stored in consecutive sectors. The length limit on the AUTOEXEC.BAT is not just one 512 byte block.

It's not going to be ZICOG.SYS, this is more general purpose than just CP/M. I'd go for just "INIT" or some such. But as long as it works who cares what it's called.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Cluso99

Any text editor will do. The original PropDos (IIRC) allowed you to create a text file, so creating or editting AUTOEXEC.BAT would be entirely possible from within the prop.

Autoexec.bat was used in PropDos/ProCmd and it is readily recognisable from Dos days, hence I thought it was a easy choice.

I think the ZiCog/CPM "HALT" program should possibly allow for booting alternate binaries, one of which could be a simple editor for autoexec.bat.

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

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

localroger

You need to go ahead and write the parameters to Hub RAM at $7FE0 in step 4, then guard against overwriting them with a length limit when loading the file to execute in step 5. Otherwise, unless your filesystem is written entirely in PASM, the act of loading in the file will overwrite the code and data you need to go back to autoexec.bat and get them. Otherwise, looks like a sound plan; my PropCMD does everything but the parameters.

heater

Isn't is so that you only need some small remnant of a file system at boot time to discover the starting SD block of AUTOEXEC.BAT and the starting block of whatever it says should be loaded. Once you have those two pieces of info the "remnant" of a file system can be over written nonchalantly because you only need to do low level block I/O to read the file being booted. Which can probably be done in PASM.

I'm not sure but it isn't it the case that the "cluster size" used in FAT is big enough an entire Prop program can be read from contiguous sectors once you have found the start sector. No more FAT code required.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

localroger

heater, the low level block I/O loads blocks directly into Hub RAM. You would have to cache the starting sector of autoexec.bat in cog RAM, then after copying all the sectors of the load file go back and load the first 32 bytes of the cached sector at the end of Hub RAM before restarting the prop. That is do-able, but considerably more of a nuisance than writing the arguments out while you still have all the Spin logic and limiting the run load.

heater

Yes, except if Cluso is intending to create his own specialist SD block reader in PASM that just drops the blocks into their final resting place in HUB. Then it just needs to drop the, previously read, parameters at the top of HUB somewhere.

bootloader code space might be very tight if he is not using an EEPROM but some dinky 2 cent micro controller instead.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Cluso99

localroger is correct. The actual loading must be done in pasm as once you start overwriting the hub ram you cannot call spin routines. The parameters will be held in cog and copied after the rest of hub is loaded. This will of course overwrite anything loaded in hub at $7FE0..

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

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

jazzed

Cluso99 said...
The parameters will be held in cog and copied after the rest of hub is loaded. This will of course overwrite anything loaded in hub at $7FE0..

How long do the parameters need to stay at $7FE0 ... after boot? Is there value in keeping them there?

Cluso99

I have the mechanism working to locate the files, read the parameters.

I am using the new fsrw from lonesock/rokicki so I will need to do the actual binary load section (not difficult as I understand what is required).

I just editted a file "autoexec.bat" in Notepad and copied it to the SD card. Works fine.

In doing this I had a thought... (dangerous I know!)
Since we have the SD card, it is almost certain we will be using an SD driver. We could just get the parameters from the file using the newly booted code. Comments??

jazzed: once used, they are not required - depends on the application, but the app could copy the parameters somewhere as soon as it starts (for later use).

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

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

jazzed

Cluso99 said...

Since we have the SD card, it is almost certain we will be using an SD driver. We could just get the parameters from the file using the newly booted code. Comments??

We had a long thread about this kind of thing last year with various ideas being tossed around.
If a defines.spin file could be used for the program, that would be simplest as a compile-time option.
A config.sys file with pin names and definitions as Key::Value pairs would be attractive for run-time.

Cluso99

Here is some sloppy code (requires bst or remove the #ifdefs) to indicate where I am today. Note currently I am using fdx to output debugging, but this will not be present in the final version. Later, I will strip the whole thing down to a minimum. but for now I need something working.

It does not load and execute the binary, but it does locate the files (in the order I set above) and if there are parameters, it extracts them.

jazzed: I know there were previous discussions. I am after something small and simple for starters. It could be expanded later.

I do like the idea of being able to specify the hardware (pins, uart, keyboard, video, etc) for runtime. This is the essential point in my parameters. I need to be able to determine for RamBlade if serial or keyboard/video are being used.


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

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

Cluso99

While searching for the latest fsrw in the Obex I came across mctrivia's Boot Loader http://obex.parallax.com/objects/473/

mctrivia's Boot Loader

Small program that sits on eeprom allowing for code update through sd card attached to pins p0-p3

requirements:
512kbit EEPROM instead of normal 256kbit
SD or uSD card reader on p0-p3
sd or uSD card to store your program

how it works:
when the program first starts up it looks to see if there is an sd card with code.bin on it. If not present it will load whatever code is stored in top half of eeprom. If the file is found then the code is copied to the top half of eeprom. deletes the update code file and then starts the code.

While this does not satisfy my ultimate requirements (because I want to replace the eeprom with a much cheaper micro and other reasons), it is a very smart idea, and worthy of mentioning here for future reference. I am still considering this in conjunction with my work above.


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

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

Leon

I've tested it, it works OK.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM

Cluso99

Ok, here is an untested version of an extended PropCommand. It is a concoction of code from localroger, oldbitcollector, mctrivia, Mike Green, lonesock, rokicki, and others plus my own for good measure.

• Check for SD card - if none, execute PropCommand
• Check for "EEPROM_H.BIN"
  • If found, copy to the upper 32KB of eeprom
  • If "NODELETE.TXT" not found, delete "EEPROM_H.BIN"
• Check for "EEPROM_L.BIN"
  • If found, copy to the lower 32KB of eeprom
  • If "NODELETE.TXT" not found, delete "EEPROM_L.BIN"
• Check for "AUTOEXEC.BAT"
  • If found, read the first sector
  • If the beginning has a "filename.BIN"
    • If found use this to boot the binary (later use the parameters also)
    • If not found, then boot file "BOOTPROP.BIN"
    • If "BOOTPROP.BIN" not found, run PropCmmand

Currently I am not booting from eeprom but this code could be in eeprom.

The autoexec.bat section works.

I would like to change the fsrwFemto code to the latest fsrw26 code, but this will have to be later.

BTW There is another thread for a minimal version...

Simple SD Card Bootstrap Loader· http://forums.parallax.com/showthread.php?p=868757

IIRC there is PropCmd code in there that allows you to output a text file from the keyboard. You can also delete a file. So, you can create your own autoexec.bat and edit it.

localroger: I didn't know what to call it as I didn't want to confuse people from your original PropCmd, but as you can see a large part of it is yours unchanged. Any ideas? Or would you like to take it on as V2?

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

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

Post Edited (Cluso99) : 1/1/2010 6:09:16 PM GMT

localroger

Cluso, I don't mind callling it "propcmd+something" as I have about a dozen versions with special commands for testing various things. So how about something like propcmd-bootdemo?

Cluso99

The way the OS topics are headed, I think we are headed for a PropOS (if it hasn't been used already) with apended " (function) - iiiii.xxx" to indicate the variant & version.

For now I will use PropCmd (SD boot) - cluso.056 if that's ok with you.

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

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

evanh

What on earth is the script file for? Doesn't Mr Steele's module cover it all already?

Cluso99

@evanh: What do you mean by the script file? Do you mean the autoexec.bat parameters?

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

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

evanh

Yes

Cluso99

Answer in the original post. I have hardware that may vary, so when launching the compiled program it needs to know what options to start.

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

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

evanh

Ah, I see, you want command line options instead of a parameter file.

localroger

Cluso, that's fine; I find that my Prop projects tend to become very fine-grained, with special versions of all the objects as I hack out unneeded functionality to free up precious Hub RAM. I think a practical PropOS (particularly for single Prop systems) is going to involve a loader in EEPROM that supports something like PropDOS / PropCMD / etc. which can launch apps with some way of informing those apps where the pins are. I am working on a project which I was hoping to put in the design contest but I probably won't make even the extended deadline (DAMN WORK) to propellerize a NEC PC8201A, which was contemporary clone of the Tandy Model 100. It will use two Props, with one providing all the I/O and through-reset scratchpad RAM (not external, just some Hub RAM) so that the other can run apps that can communicate with one another and maintain state for things like the SD filesystem while chaining through.

I was working myself on a much more advanced PropCMD that could redirect I/O, and it was just taking too much RAM (even in Spin, which is an extremely memory efficient language). On the Prop, it is critical to get anything that isn't used out of Hub RAM. This means chopping unneeded functionality out of OBEX objects, overwriting PASM code once it's been launched in a cog, and taking seriously the mantra of one of the gurus of the Atari 2600 forums I used to haunt, that "every bit is sacred."

Cluso99

localroger: I just put PropCMD on the RamBlade to get an OS of some sort while I get Sphinx fully operational. I added a few features from other places as well as the file transfer that Sphinx uses (it's not debugged yet).

Here is the link (3rd post)· http://forums.parallax.com/showthread.php?p=849265



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

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