Booting into an image in HUB-RAM?
Nick Mueller
Posts: 815
Hi!
I'm at the last step of booting from different EEPROM-locations. And now I'm lost.
Here is what I do:
I patched Mike Green's i2cRotines so that I can inject commands. This is basically done by setting a flag when the i2c-driver receives a bootToEEPROM command. This breaks the normal command-fetch cycle and jumps into an sequencer who is building the next commands, stuffs them into the normal i2c-command-routines, and takes back control after they have finished. Or does other actions.
Now my (wrong?) sequence is this:
1.) Kill all cogs, except the one running the i2c (me, myself and I)
2.) Read from the EEPROM address (passed with the boot command) + 14 the word giving the length of the image
3.) With this length-information and the address in the EEPROM, fill the HUB-RAM starting at address 0
4.) and now!? A reset would be stupid, because it would load from EEPROM 0x00 and overwrite what I just did.
Important note:
This is all from within a C-program. There is no SPIN-interpreter running that I could convince to take the image in RAM.
What is further puzzling me, is a description in ICC7Prop's documentation that says:
"... you can download the program to the Prop's memory ... When creating the .binary, the linker adds magic 32 bytes to the beginning of the image and an other 32 to the end" Thus far, it actually is that way. Next, it says "On reset, the Propeller copies the SPIN interpreter to to Cog0 and starts executing the interpreter. The purpose of the magic bytes is to make SPIN overwrite the Cog0 code with the code from HUB RAM".
I always thought, that a reset (at least that's what the Parallax-manuals say) first tries to read from serial, then reads from EEPROM. But that would overwrite the HUB-RAM image.
Or do I simply have to write a 1 to the CLK-register's bit 7 (RESET) and then kill the last COG (me) running and shut up?
I'd like to know how that works, because I'm absolutely programming in the dark, with no chance for debugging.
TIA for any insights!
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
I'm at the last step of booting from different EEPROM-locations. And now I'm lost.
Here is what I do:
I patched Mike Green's i2cRotines so that I can inject commands. This is basically done by setting a flag when the i2c-driver receives a bootToEEPROM command. This breaks the normal command-fetch cycle and jumps into an sequencer who is building the next commands, stuffs them into the normal i2c-command-routines, and takes back control after they have finished. Or does other actions.
Now my (wrong?) sequence is this:
1.) Kill all cogs, except the one running the i2c (me, myself and I)
2.) Read from the EEPROM address (passed with the boot command) + 14 the word giving the length of the image
3.) With this length-information and the address in the EEPROM, fill the HUB-RAM starting at address 0
4.) and now!? A reset would be stupid, because it would load from EEPROM 0x00 and overwrite what I just did.
Important note:
This is all from within a C-program. There is no SPIN-interpreter running that I could convince to take the image in RAM.
What is further puzzling me, is a description in ICC7Prop's documentation that says:
"... you can download the program to the Prop's memory ... When creating the .binary, the linker adds magic 32 bytes to the beginning of the image and an other 32 to the end" Thus far, it actually is that way. Next, it says "On reset, the Propeller copies the SPIN interpreter to to Cog0 and starts executing the interpreter. The purpose of the magic bytes is to make SPIN overwrite the Cog0 code with the code from HUB RAM".
I always thought, that a reset (at least that's what the Parallax-manuals say) first tries to read from serial, then reads from EEPROM. But that would overwrite the HUB-RAM image.
Or do I simply have to write a 1 to the CLK-register's bit 7 (RESET) and then kill the last COG (me) running and shut up?
I'd like to know how that works, because I'm absolutely programming in the dark, with no chance for debugging.
TIA for any insights!
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Comments
> But that would overwrite the HUB-RAM image.
Hi Nick,
how does it 'know' how and where to do that first try at reading from the serial pins? That's not burned into the chip is it? I've always understood that a very small loader loads another SPIN loader - even if you're doing pure ASM... just groping in the dark too... hoping you get this to work as it's a very useful idea.
- H
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Thanks for the link. Admittedly, I don't want to investigate into this path right now.
First, I don't know how to use this tool. So it takes some time to get that working for me.
Second, and most of all, I am sure that there are people here that actually do know how it works.
I also would like to bet that this information is already given somewhere in the forum. But where? I can't find it. :-(
I'm really puzzled how the boot works. If I do have a serial monitor running, I see that the prop is reset after the RAM has been loaded. But is that all? How's that SPIN-interpreter started and most of all, how does he know that there is a working image in RAM and that he has to second-stage boot into that? By the checksum (byte 5 in the first 32 magic bytes)?
Admittedly, one could argue that I just have to try until it works. But I prefer to know how it's *supposed* to work before I start. My way of working.
It came to my mind, that I can use a 64 bit shift-register with LEDs that is already connected to the system.
This kind of work is so funny!
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Post Edited (Nick Mueller) : 7/5/2009 9:35:56 PM GMT
or more LED's and shift registers ?·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
LOL!
Yes, life could be so funny, if it wouldn't be so real!
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
And how's that done? Where can I have a look at that object?
Mike does have a boot in his spiFemtoBasic (not the exact name) rotines. I had a look at it. But I didn't understand what is going on there. Anyhow, the SPIN-part of his routines is very simple and I translated that to C. But I already was aware while translating it, that it won't work. Because it relies (to my understanding) on the fact that a SPIN-interpreter is running. But that's not the case with C. Also, C needs a second COG for some support. And expectedly, it hangs (doesn't even crash
So I need to know in detail, how the boot process works in detail.
* When/how is the first SPIN-interpreter loaded from ROM into a COG (Reset? What does that actually do?)
* How does that code decide that he has to boot from RAM (that must work somehow, or you coulnd't "load to RAM and run" from PropTool and not just from serial or EEPROM.
Unfortunately, the Parallax-docs are not specific enough abot that. The way they describe it, I get the impression that booting from RAM wouldn't work at all. But shure enough, this is my misunderstanding!
And maybe I'm completely on the wrong track.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Search around for a copy of "booter.spin". It's the bootloader in the propeller mask rom. It will give you every detail you wish to know about how the propeller boots. I re-posted it less than a week ago in another thread, but there are a number of copies flying about.
-Power on reset
-Propeller hardware loads booter.spin into cog 0 and starts it up.
-bootloader loads image to ram from serial or eeprom
-bootloader starts spin interpreter on first object.
-bootloader stops itself
If you are running C, then I'd wager the next sequence goes like this.
Spin program in Cog 0 executes Cognew(@C_code,0), Cogstop(cogid)
From then on all spin interpreters have ceased and it's all C baby.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Missed it by ->" "<- that much!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
I've been working and unable to respond. The boot routine in sdspiFemto.spin does what you want. It's only about 35 lines of assembly and starts around line 725. This routine takes control after the code is read into hub memory and it uses the Spin header in locations 0-15, two words particularly ... dbase at $000A and vbase at $0008. It places a stack marker (for the bottom of the stack) at dbase, then clears the variable space between the stack and the end of the program because it's expected to be initialized to zero. If the clock frequency and mode of the new program (stored in the long at $0000 and the byte at $0004) are different from what's currently being used, they're changed after switching to RCFAST. Lastly a Spin interpreter is started which uses the Spin header and PAR to initialize itself.
The problem seems to be, that your solutions assume a SPIN-interpreter running. But there is none.
Now I came up with a simple (not to say crude) idea (not yet testet):
Have a little boot-loader in SPIN sitting in the bottom of the EEPROM.
That SPIN-bootloader decides which EEPROM-image to load (with Mike's rotines).
The information where to boot from can be either directly patched into the SPIN-bootloader while it is in the EEPROM, or by using some defined location in EEPROM.
Will do that now ... (after having brought *both* cats to the doc
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
This seems to be the solution.
Edit:
What I *completely* missed in that process was "coginit"!
booter.spin opened my eyes.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Post Edited (Nick Mueller) : 7/6/2009 10:23:05 AM GMT
The BootLoader.SPIN is so simple, that it is hard to do it wrong.
It is more or less just this line (plus LED-setup, plus LED-blinkblinkblink):
i2cObject.BootEEPROM($8000)
i2cObject is "sdspiFemto", made sure that it is the most current version.
It starts (blinking yellow LED) and BootEEPROM returns 0 (no red LED).
At EEPROM-location 0x8000 is a simple SPIN-program that opens the serial and writes the famous "Hello World". At least, it should write. But it doesn't get startet.
After a reset, the BootLoader starts (blinkblinkblink) and then finishes (there's also a blink-loop behind the call).
I verified that my 3DClient is writing the contents to the right place. I almost know the bytes of the images by hard now.
That Hello World-programm written to EEPROM at 0x0000 either by Propeller Tool or my 3PClient is running. Verified that several times in all variations.
I can't see what I'm doing wrong.
Any ideas?
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
CON _clkmode = xtal1 + pll16x _xinfreq = 5000000 OBJ i2cObject : "sdspiFemto" PUB Main | i dira[noparse][[/noparse]18]:= 1 dira[noparse][[/noparse]19]:= 1 outa[noparse][[/noparse]18]:= 1 repeat i from 1 to 100000 outa[noparse][[/noparse]18]:= cnt[noparse][[/noparse]23] if i2cObject.BootEEPROM($8000) <> 0 outa[noparse][[/noparse]19]:= 1 repeat outa[noparse][[/noparse]18]:= 1That's all
Just verified a second time, that I do have the current version of sdspiFemto. And that it is the one compiled into (forcing an error in that file).
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Post Edited (Nick Mueller) : 7/6/2009 7:19:25 PM GMT
i2cObject.bootEEPROM(i2cObject#bootAddr + $8000) ' bootAddr specifies the SCL first of 2 EEPROM pins ... eeeeek [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Try this modified version of bootEEPROM (Add it to sdspiFemto). The standard one expects to load a full 32K and will fail if there's anything else in the 32K section other than the Spin program and zeroes. This version just allows you to explicitly specify a program size (in bytes).
PUB bootPartialEEPROM(addr,size) | t, c0, c1 '' Load and run a new SPIN program if not start(@c0) ' Start up the I/O routines using a abort ' local control block long[noparse][[/noparse]control] := 0 ' Check for the presence of EEPROM long[noparse][[/noparse]control][noparse][[/noparse]0] := (ioReadCmd | ioLowSpeed) << 24 | (addr & $FFFFFF) repeat while long[noparse][[/noparse]control][noparse][[/noparse]0] & ioTestRdy ' Wait for check to complete and if long[noparse][[/noparse]control][noparse][[/noparse]0] & ioTestErr ' abort if there's an error abort repeat t from 0 to 7 ' Stop all COGs except this one and if (t <> cogid) and (t <> (cog-1)) ' the one with the I2C driver in it cogstop(t) t := ioBootCmd | ioLowSpeed | ioStopLdr | cogid ' Tell the I2C driver to load long[noparse][[/noparse]control] := size << 16 ' into HUB RAM after stopping long[noparse][[/noparse]control][noparse][[/noparse]0] := (t << 24) | (addr & $FFFFFF) ' this calling cog repeat while long[noparse][[/noparse]control][noparse][[/noparse]0] & ioTestRdy ' Wait for this to finish return (long[noparse][[/noparse]control][noparse][[/noparse]0] & ioTestErr) <> 0 ' Return any error codeThat's exactly what I found right a moment before and wanted to post. I forgot the EEPROM's device-addr.
RELIEEEEEF!
Thank you all!
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
If one works, two should work the same.
And now for a beer ... Prost!
(from the brewery founded 1328 <http://augustinerbraeu.de/>) Ya call that tradition, right?
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔