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.