Subject: [E3-hacking] Shell

From: Jonathan McDowell <[email-masked]>
Date: Sun, 1 May 2005 12:38:11 +0100

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.

-- 
                 /------------------------------------\
                 |           Make friends.            |
                 \------------------------------------/

---

From: Matt Evans <[email-masked]>
Date: Sun, 1 May 2005 13:49:34 +0100

Jonathan,

> http://www.earth.li/~noodles/files/delta-proc.txt

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

---

From: Jonathan McDowell <[email-masked]>
Date: Sun, 1 May 2005 15:48:17 +0100

> 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.

> 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.

-- 
 [                    Beware of exploding fridges.                    ]

---

From: David Given <[email-masked]>
Date: Tue, 3 May 2005 10:48:23 +0100

On Sunday 01 May 2005 15:48, Jonathan McDowell wrote:
[...]
> 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...

-- 
+- David Given --McQ-+ "...you could wire up a *dead rat* to a DIMM
|  [email-masked]    | socket, and the PC BIOS memory test would pass it
| ([email-masked]) | just fine." --- Ethan Benson
+- www.cowlark.com --+

---

From: Jonathan McDowell <[email-masked]>
Date: Tue, 3 May 2005 11:19:02 +0100

> 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.

-- 
If this isn't war, why is CNN massing on the border?
This .sig brought to you by the letter A and the number 17
Product of the Republic of HuggieTag

---

From: Matt Evans <[email-masked]>
Date: Mon, 11 Jul 2005 10:39:36 +0100

Hi Jonathan,

> In my flash there's a PARMS "Q;Q;" block at 0x4400 into NAND, so I

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

---

From: Jonathan McDowell <[email-masked]>
Date: Tue, 16 Aug 2005 21:26:15 +0100

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.

> non-blocking.  (Also changes speed to 115200.)  I'll tidy it up and 

Patches always welcome.

> 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':

> 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.

> 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.

> truth (i.e. the params could be edited without requiring a PARMS

I think Cliff's since said this unfortunately isn't possible. :(

J.

-- 
Avoid temporary variables and strange women.
This .sig brought to you by the letter A and the number  2
Product of the Republic of HuggieTag