PDA

View Full Version : Booting into an image in HUB-RAM?



Nick Mueller
07-06-2009, 03:13 AM
Hi!

I'm at the last step of booting from different EEPROM-locations. And now I'm lost. http://forums.parallax.com/images/smilies/lol.gif

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 (http://www.yadro.de)

CounterRotatingProps
07-06-2009, 04:45 AM
> 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.

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

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

CounterRotatingProps
07-06-2009, 04:54 AM
http://forums.parallax.com/forums/default.aspx?f=25&m=365256

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Nick Mueller
07-06-2009, 05:14 AM
> http://forums.parallax.com/forums/default.aspx?f=25&m=365256

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. http://forums.parallax.com/images/smilies/smile.gif (Edit: I meant to use the LEDs for debugging).
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 (http://www.yadro.de)

Post Edited (Nick Mueller) : 7/5/2009 9:35:56 PM GMT

CounterRotatingProps
07-06-2009, 05:17 AM
> Never use force, just go for a bigger hammer!

or more LED's and shift registers ? http://forums.parallax.com/images/smilies/lol.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Nick Mueller
07-06-2009, 05:28 AM
> 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 (http://www.yadro.de)

mctrivia
07-06-2009, 06:56 AM
Nick the load from serial on reset is part of rom. You can however simulate a reset without actually resting like I do in my bootloader object(mike actually wrote all code needed to simulate reset)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30 (http://propmodule.com/?x=products). PCB available for $5

Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd (http://www.gadgetgangster.com/160) and propmod-1x1 (http://www.gadgetgangster.com/161) 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 (http://uploader.propmodule.com) for free.

Nick Mueller
07-06-2009, 07:38 AM
> You can however simulate a reset without actually resting like I do in my bootloader object

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 http://forums.parallax.com/images/smilies/smile.gif )

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 (http://www.yadro.de)

BradC
07-06-2009, 07:40 AM
Nick Mueller said...

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)?



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!

mctrivia
07-06-2009, 08:05 AM
For my object search obex for boot

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30 (http://propmodule.com/?x=products). PCB available for $5

Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd (http://www.gadgetgangster.com/160) and propmod-1x1 (http://www.gadgetgangster.com/161) 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 (http://uploader.propmodule.com) for free.

Mike Green
07-06-2009, 08:39 AM
Nick,
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.

Nick Mueller
07-06-2009, 05:00 PM
Thank you guys!

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 http://forums.parallax.com/images/smilies/mad.gif )

Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO (http://www.yadro.de)

Nick Mueller
07-06-2009, 05:21 PM
OK, finally found the "booter.spin" and Brad's SpinStart.
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 (http://www.yadro.de)

Post Edited (Nick Mueller) : 7/6/2009 10:23:05 AM GMT

Nick Mueller
07-07-2009, 02:54 AM
OK guys, doesn't work and I'm close to going nuts!

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 (http://www.yadro.de)

jazzed
07-07-2009, 03:00 AM
@Nick, If you show your sources, you will get more help.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

Nick Mueller
07-07-2009, 03:07 AM
The source is this:




CON
_clkmode = xtal1 + pll16x
_xinfreq = 5000000

OBJ
i2cObject : "sdspiFemto"

PUB Main | i
dira[18]:= 1
dira[19]:= 1
outa[18]:= 1

repeat i from 1 to 100000
outa[18]:= cnt[23]

if i2cObject.BootEEPROM($8000) <> 0
outa[19]:= 1

repeat
outa[18]:= 1




That'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 (http://www.yadro.de)

Post Edited (Nick Mueller) : 7/6/2009 7:19:25 PM GMT

jazzed
07-07-2009, 04:02 AM
Apparently, you have to call BootEEPROM like this:

i2cObject.bootEEPROM(i2cObject#bootAddr + $8000) ' bootAddr specifies the SCL first of 2 EEPROM pins ... eeeeek :)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

Mike Green
07-07-2009, 04:03 AM
Nick,
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[control] := 0 ' Check for the presence of EEPROM
long[control][0] := (ioReadCmd | ioLowSpeed) << 24 | (addr & $FFFFFF)
repeat while long[control][0] & ioTestRdy ' Wait for check to complete and
if long[control][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[control] := size << 16 ' into HUB RAM after stopping
long[control][0] := (t << 24) | (addr & $FFFFFF) ' this calling cog
repeat while long[control][0] & ioTestRdy ' Wait for this to finish
return (long[control][0] & ioTestErr) <> 0 ' Return any error code

Nick Mueller
07-07-2009, 04:06 AM
> i2cObject.bootEEPROM(i2cObject#bootAddr + $8000) ' bootAddr specifies the SCL first of 2 EEPROM pins ... eeeeek :)

That'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 (http://www.yadro.de)

Nick Mueller
07-07-2009, 04:23 AM
OK, and booting into C works too, with the C-Image at EEPROM 0x1000 and only the necessarry bytes writen (not all 32k), so there is garbage behind both images (I intentionally loaded some garbage in behind) that doesn't make a difference.

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? http://forums.parallax.com/images/smilies/wink.gif

Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO (http://www.yadro.de)

CounterRotatingProps
07-07-2009, 05:05 AM
Prost!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔