Turns out the E3 does obey the same sort of PBL format as the E2, but there's some sort of timing issue with pblq I think. I've hacked up something that does the job and rewritten my boot parameters to drop to /bin/sh and I'm in! Some files from /proc can be seen at:
http://www.earth.li/~noodles/files/delta-proc.txt
J.
Jonathan,
On 1 May 2005, at 12:38, Jonathan McDowell wrote:
Turns out the E3 does obey the same sort of PBL format as the E2, but there's some sort of timing issue with pblq I think. I've hacked up something that does the job and rewritten my boot parameters to drop to /bin/sh and I'm in! Some files from /proc can be seen at:
What good news :) Is there a certain flash offset that contains just the boot string? Or is that wrapped into a block of a certain format? Could you share any specific info on this? I'd like to give it a try.
What was the pblq issue? IIRC it recognised the ESC on boot, but then gave up listening & carried on booting - does it just have a very short timeout at this point waiting for a packet command?
Great work, would like to give it a go myself :)
Cheers,
Matt
On Sun, May 01, 2005 at 01:49:34PM +0100, Matt Evans wrote:
Turns out the E3 does obey the same sort of PBL format as the E2, but there's some sort of timing issue with pblq I think. I've hacked up something that does the job and rewritten my boot parameters to drop to /bin/sh and I'm in! Some files from /proc can be seen at:
What good news :) Is there a certain flash offset that contains just the boot string? Or is that wrapped into a block of a certain format? Could you share any specific info on this? I'd like to give it a try.
In my flash there's a PARMS "Q;Q;" block at 0x4400 into NAND, so I changed that.
What was the pblq issue? IIRC it recognised the ESC on boot, but then gave up listening & carried on booting - does it just have a very short timeout at this point waiting for a packet command?
I gave up on pblq and wrote my own stuff, though probably I should have just fixed pblq. I think what actually happens is the first command times out but when you try again it works; I sit and wait for a successful version command response before proceeding.
I've put what I'm using up at:
http://www.earth.li/~noodles/files/pbltool.c
This can and will break your E3; don't use it unless you're really sure you know what you're doing. Very rough and ready.
"pbltool read 0x0 0x10000 pbl.rom"
should give you a dump of the PBL. You probably want to let it print "Prodding..." before powering on the E3. Or comment out the initial version check.
J.
On Sunday 01 May 2005 15:48, Jonathan McDowell wrote: [...]
I gave up on pblq and wrote my own stuff, though probably I should have just fixed pblq. I think what actually happens is the first command times out but when you try again it works; I sit and wait for a successful version command response before proceeding.
pblq does ping the board with a get-version packet after the handshake's complete, and wait for the result, so that shouldn't be the problem...
I suspect the major culprit is probably the bit of code that tries to be clever and changes the baud rate after handshaking. The E3 uses a different default baud rate, IIRC.
Unfortunately I don't have an E3, and I've just moved house and my E2 and interface board is somewhere in a box, so I probably won't be doing much development for a while...
On Tue, May 03, 2005 at 10:48:23AM +0100, David Given wrote:
On Sunday 01 May 2005 15:48, Jonathan McDowell wrote: [...]
I gave up on pblq and wrote my own stuff, though probably I should have just fixed pblq. I think what actually happens is the first command times out but when you try again it works; I sit and wait for a successful version command response before proceeding.
pblq does ping the board with a get-version packet after the handshake's complete, and wait for the result, so that shouldn't be the problem...
It doesn't try sending it again once it's timed out though, which my code does and I've seen it have to do several times.
I suspect the major culprit is probably the bit of code that tries to be clever and changes the baud rate after handshaking. The E3 uses a different default baud rate, IIRC.
Reading pblq it seems to talk at 9600 until it does the baud rate change; this is the same as the E3 - although the kernel/loader messages are all at 115200 by default it talks (and listens) at 9600 for pbl debug control messages. I'd told pblq not to change the baud rate when I'd been playing with it, but that still wasn't successful.
It would be interesting to know if pbltool did anything with an E2 actually.
J.
Hi Jonathan,
On 1 May 2005, at 15:48, Jonathan McDowell wrote:
On Sun, May 01, 2005 at 01:49:34PM +0100, Matt Evans wrote:
Turns out the E3 does obey the same sort of PBL format as the E2, but there's some sort of timing issue with pblq I think. I've hacked up something that does the job and rewritten my boot parameters to drop to /bin/sh and I'm in! Some files from /proc can be seen at:
What good news :) Is there a certain flash offset that contains just the boot string? Or is that wrapped into a block of a certain format? Could you share any specific info on this? I'd like to give it a try.
In my flash there's a PARMS "Q;Q;" block at 0x4400 into NAND, so I changed that.
Yesterday I had a play with pbltool and the E3 for the first time, and tried to re-create your shell joy. :)
I've some changes to pbltool, if you're interested - making it work on my big-endian machine; also the serial fd needs to be mostly* non-blocking. (Also changes speed to 115200.) I'll tidy it up and send a patch IYL.
So I was eventually able to read bits of stuff... it seems my E3 is peculiar in that LDR reports that it finds two PARMS chunks, and two LINUXes; the second of each is used to boot, normally. So I've read out the second PARMS and altered the command line; I was unsure what to do about checksums (whether it's checked or not?) but used pblq's 'bless' function, hoping it'd be the same checksum as the E2... But the problems start earlier than this - I can erase the flash but my E3 doesn't appear to respond to 'writeflash':
$ ./pbltool eraseflash 0x14000 1 Talking to PBL v4.9 Build 1311 Switching baudrate to 115200: Now re-getting version: Talking to PBL v4.9 Build 1311, quickly
$ ./pbltool writeflash 0x14400 args-custom2 Talking to PBL v4.9 Build 1311 Switching baudrate to 115200: Now re-getting version: Talking to PBL v4.9 Build 1311, quickly Trying to program 1024 bytes starting 51 at 0x00414400. sendpacket: 0 8E 00 01 00
$ ./pbltool readflash 0x14400 0x400 foo Talking to PBL v4.9 Build 1311 Switching baudrate to 115200: Now re-getting version: Talking to PBL v4.9 Build 1311, quickly readflashblock: 0x414400 +0x400
0x00414400 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 0x00414410 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 0x00414420 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF .... etc.
Have you any ideas why this doesn't write? (The result code for the command 0E is '01' - does this indicate good or bad, do you know?)
(I'm wondering if there's some sort of block read-only flagging or something I may need to undo first..)
Will start having a look at LDR; am intrigued by the "Linux start-up params (Any key to edit)" line, and want to see if this is telling the truth (i.e. the params could be edited without requiring a PARMS reflash).
Cheers,
Matt
Sorry. I think I was at DebConf when I read this and so left it until a later date but then forgot all about it.
On Mon, Jul 11, 2005 at 10:39:36AM +0100, Matt Evans wrote:
On Sun, May 01, 2005 at 01:49:34PM +0100, Matt Evans wrote:
Turns out the E3 does obey the same sort of PBL format as the E2, but there's some sort of timing issue with pblq I think. I've hacked up something that does the job and rewritten my boot parameters to drop to /bin/sh and I'm in! Some files from /proc can be seen at:
What good news :) Is there a certain flash offset that contains just the boot string? Or is that wrapped into a block of a certain format? Could you share any specific info on this? I'd like to give it a try.
In my flash there's a PARMS "Q;Q;" block at 0x4400 into NAND, so I changed that.
Yesterday I had a play with pbltool and the E3 for the first time, and tried to re-create your shell joy. :)
I've some changes to pbltool, if you're interested - making it work on my big-endian machine; also the serial fd needs to be mostly* non-blocking. (Also changes speed to 115200.) I'll tidy it up and send a patch IYL.
Patches always welcome.
So I was eventually able to read bits of stuff... it seems my E3 is peculiar in that LDR reports that it finds two PARMS chunks, and two LINUXes; the second of each is used to boot, normally.
I think I've seen updates that look like they do this.
So I've read out the second PARMS and altered the command line; I was unsure what to do about checksums (whether it's checked or not?) but used pblq's 'bless' function, hoping it'd be the same checksum as the E2...
It's the same checksum; it's a Fletcher's 8bit IIRC.
But the problems start earlier than this - I can erase the flash but my E3 doesn't appear to respond to 'writeflash':
$ ./pbltool eraseflash 0x14000 1 Talking to PBL v4.9 Build 1311 Switching baudrate to 115200: Now re-getting version: Talking to PBL v4.9 Build 1311, quickly
$ ./pbltool writeflash 0x14400 args-custom2 Talking to PBL v4.9 Build 1311 Switching baudrate to 115200: Now re-getting version: Talking to PBL v4.9 Build 1311, quickly Trying to program 1024 bytes starting 51 at 0x00414400. sendpacket: 0 8E 00 01 00
$ ./pbltool readflash 0x14400 0x400 foo Talking to PBL v4.9 Build 1311 Switching baudrate to 115200: Now re-getting version: Talking to PBL v4.9 Build 1311, quickly readflashblock: 0x414400 +0x400
0x00414400 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 0x00414410 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 0x00414420 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF .... etc.
Have you any ideas why this doesn't write? (The result code for the command 0E is '01' - does this indicate good or bad, do you know?)
Bah. It's ages since I touched this. ISTR having to reflash the entire block starting at the xxx000 boundary, so I had to dump it and get the other bits that are around the PARAMS, then patch my params in and reflash.
(I'm wondering if there's some sort of block read-only flagging or something I may need to undo first..)
Pretty sure there isn't. I've found the flash stuff can be temperamental. I've been meaning to look at writing support into pbltool for loading a kernel into ram and running it, so it's possible to try new kernels without having to reflash. There's a bunch of OMAP related bits that have gone into mainline 2.6 recently that could hopefully make it easier to get that up and running. As ever my issue is free time.
Will start having a look at LDR; am intrigued by the "Linux start-up params (Any key to edit)" line, and want to see if this is telling the truth (i.e. the params could be edited without requiring a PARMS reflash).
I think Cliff's since said this unfortunately isn't possible. :(
J.
-
David Given -
Jonathan McDowell -
Matt Evans