Subject: [E3-hacking] PBL and flash access on the E3

From: David Given <[email-masked]>
Date: Tue, 28 Mar 2006 23:37:23 +0100

Hurrah! I have my shiny new E3 up and running, and am getting pblq back up
to speed.

It would appear that the reason pblq doesn't work on the E3 is primarily
due to the NOP packet not working (it appears to cause pbl to hit an
assertion and go into an infinite loop). There are also a few other gotchas
that cause the handshaking procedure to go wrong. I've fixed these, mostly
by copying the relevant bits of logic from pbltool --- ta.

Next thing is to try and get the flash code up and running; but I'm a
little hesitant to play because I don't want to overwrite anything crucial
and brick the device. *Is* there anything crucial in the NAND flash? I
notice that the MTD partition table has a chunk marked 'Amstrad Block'.
Does it matter if I overwrite this? Plus, am I right in that the e3's NAND
flash pseudoaddress is 0x400000, instead of the e2's 0x8001000?

I've also got Jonathon's prebuilt kernel running, which appears to work
nicely --- at least, it produces a palette-mangled penguin and vast numbers
of error messages (in pink) as the JFFS driver fails miserably to find a
JFFS filesystem on the flash. I need to try a filesystem on a compact flash
device and see if that works. But it's definitely getting somewhere!

-- 
+- David Given --McQ-+ "If you're up against someone more intelligent
|  [email-masked]    | than you are, do something insane and let him think
| ([email-masked]) | himself to death." --- Pyanfar Chanur
+- www.cowlark.com --+

---

From: Jonathan McDowell <[email-masked]>
Date: Wed, 29 Mar 2006 14:11:26 +0100

On Tue, Mar 28, 2006 at 11:37:23PM +0100, David Given wrote:
> Hurrah! I have my shiny new E3 up and running, and am getting pblq
> back up to speed.

Cool.

> little hesitant to play because I don't want to overwrite anything
> crucial and brick the device. *Is* there anything crucial in the NAND
> flash? I notice that the MTD partition table has a chunk marked
> 'Amstrad Block'.  Does it matter if I overwrite this? 

You can completely nuke the NAND flash and PBL will still run ok I
believe. The Amstrad Block is where the MEM and LDR blocks exist by
default. I've been thinking about what the final MTD layout will be and
I'm currently leaning towards something like:

kernel		2M
u-boot		256K
u-boot params	256K
LDR etc		512K
JFFS2 partition	29M

I'm not entirely sure if PBL will read a LDR block earlier than 4M into
flash; need to test that. And I seemed to be getting issues with the
tail end of flash, so I need to have a look and see if PBL writes
anything there that I might have to avoid. Aside from that does this
seem sane to people?

> Plus, am I right in that the e3's NAND flash pseudoaddress is
> 0x400000, instead of the e2's 0x8001000?

I /think/ so, but it's been a long time since I've used PBL to
read/write the NAND.

> I've also got Jonathon's prebuilt kernel running, which appears to work

Jonath*a*n. (I'm on a mission to educate the world about how to spell my
name.)

> nicely --- at least, it produces a palette-mangled penguin and vast
> numbers of error messages (in pink) as the JFFS driver fails miserably
> to find a JFFS filesystem on the flash. I need to try a filesystem on
> a compact flash device and see if that works. But it's definitely
> getting somewhere!

I've updated the prebuilt kernel to include the palette fixing patch and
also enable the internal modem.

J.

-- 
 [     101 things you can't have too much of : 18 - Roleplaying.      ]
 [ http://www.blackcatnetworks.co.uk/ - IPv6 enabled ADSL/dialup/colo ]

---

From: David Given <[email-masked]>
Date: Wed, 29 Mar 2006 14:46:05 +0100

Jonathan McDowell wrote:
[...]
> anything there that I might have to avoid. Aside from that does this

PBL on the E2 certainly has a rather small limit as to the size of an
executable block (too small to use for a Linux kernel, maybe too small
for u-boot --- I forget the exact size). I don't know if the E3 has the
same issue.

Thanks to Cliff for the detailed explanation of how the flash metadata
works. From that, it seems to me that the view of the flash that PBL
sees (after bad-block remapping) is *not* the same as the view that
Linux sees (talking directly to the chip). Which means that while I'm
safe and won't be able to trash the metadata using PBL, I *will* be able
to trash the metadata using Linux --- and if I trash the metadata, I
won't be able to use PBL to boot from the flash.

Could the strange issues at the end of the flash be this metadata?

[...]
> Jonath*a*n. (I'm on a mission to educate the world about how to spell my

Oops --- sorry!

I'm reminded of Iain Banks talking about how to spell his name. 'Iain',
he says, is a totally different name from 'Ian'. 'Iain' is the correct
version. 'Ian', however, is simply an erroneous abbreviation for
'Cyclopian', which as everybody knows means 'to have only one I'...

[...]
> also enable the internal modem.

Ta, I will fetch it. Is there any chance of uploading the kernel
configuration file, as well, so I can try to build my own?

(Also, you may be interested to know that the kernel seems to be
ignoring the boot parameters passed to it by u-boot.)

- --
+- David Given --McQ-+
|  [email-masked]    | "Those that repeat truisms, are also forced to
| ([email-masked]) | repeat them." --- Anonymous from Slashdot
+- www.cowlark.com --+

---

From: en4rab <[email-masked]>
Date: Wed, 29 Mar 2006 06:26:52 -0800 (PST)

> Could the strange issues at the end of the flash be this metadata?

I dont know if it will be of any help but I found a copy of the toshiba
data sheet for that nand device and put it on my website for download
here:
http://www.en4rab.dsl.pipex.com/TC58DVAM82AF1FT_030129.pdf
The metadata (crc's for ECC and other stuff) is stored at the end of
eack page.
A page is 528 bytes, 512 bytes are for user data and 16 bytes for ECC or
other metadata.
There is a small note at the end of the datasheet (page32) about
checking for bad pages on a new chip.
en4rab

--
|     .-.   [email-masked]
|    /   \         .-.
|   /     \       /   \       .-.     .-.     _   _
+--/-------\-----/-----\-----/---\---/---\---/-\-/-\/\/---
| /         \   /       \   /     '-'     '-'
|/           '-'         '-'  -END OF TRANSMISSION-

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: Jonathan McDowell <[email-masked]>
Date: Wed, 29 Mar 2006 19:36:13 +0100

> for u-boot --- I forget the exact size). I don't know if the E3 has the

It won't run more than a 16K block, which is too small for u-boot. I
think it might run a bigger compressed block (LDR is bigger, for
example), but I'm not quite sure it'll stretch to the 80 or so K my
current u-boot image is.

> safe and won't be able to trash the metadata using PBL, I *will* be
> able to trash the metadata using Linux --- and if I trash the
> metadata, I won't be able to use PBL to boot from the flash.

FWIW my dmesg seems to show Linux picking up badblocks just fine, though
I can't confirm they're the same as what PBL sees.

> > I've updated the prebuilt kernel to include the palette fixing patch
> > and also enable the internal modem.

make ams_delta_defconfig

with the patches that are there will give you a default .config which I
think is exactly what I used to build the image, or certainly not wildly
different.

> ignoring the boot parameters passed to it by u-boot.)

Really? It picks them up fine for me. If I do:

setenv bootargs mem=32M console=ttyS0,115200n8 root=/dev/ram0 initrd=0x11c00000,4M
bootm 11d00000

then I find the image uses the supplied initrd as expected.

J.

-- 
/-\                             |    I'm not popular enough to be
|@/  Debian GNU/Linux Developer |             different.
\-                              |

---

From: David Given <[email-masked]>
Date: Thu, 30 Mar 2006 00:28:53 +0100

Jonathan McDowell wrote:
[...]
> example), but I'm not quite sure it'll stretch to the 80 or so K my

That's annoying, but I think we understand enough of the PBL entrypoints to
write a quick and dirty bootstrap loader that's enough to boot u-boot.

[...]
> setenv bootargs mem=32M console=ttyS0,115200n8 root=/dev/ram0 initrd=0x11c00000,4M

Yes, I was using the wrong syntax --- setenv bootargs=..., which appears to
work, but just does the wrong thing.

I now have it working fine, using a USB mass storage device as its root
filesystem! The only gotcha is that the kernel doesn't understand /dev/sd?
naming, so you have to use root=8:1.

I've been experimenting with various off-the-shelf ARM root filesystems,
more out of interest to see what would happen than any real expectation
that it would work. Yours works, of course. A Familiar GPE install image
doesn't, unfortunately; it seems to hang immediately after mounting the
root filesystem. (This was after I repacked the JFFS2 image as an ext2
image.) I tried again with init=/bin/sh, but that hung too.

A Debian unstable initrd (stable won't work because of the 2.6 kernel), to
my total surprise, actually runs fine! It complains bitterly about having
to go into low-memory mode, but it ran, with dialogues and everything, up
to the point where it was trying to download package files. I currently
don't have any networking, but I think I'll try to scrounge a USB ethernet
dongle and see what happens.

debian-installer claims to use about 8MB in low-memory mode, with about
20MB free. It's very sluggish over the serial port, but much snappier on
the real console (Debian looks *weird* on that little screen).
Unfortunately the mailboard's not working yet, and there aren't enough keys
on the main keypad to interact with debian-installer.

I'm disappointed and a bit puzzled that Familiar wouldn't work. It would be
far more suitable than Debian, and I reckon most of the hardware
functionality is there to run GPE or Opie. I don't know what's going wrong.
I'll have to investigate that tomorrow.

ADDENDUM: I've figured out the keymap on the keypad; the important keys are
VIDEO (which is RETURN) and MOBILE MSG (which is BACKSPACE). This means I
can now make debian-installer work sufficiently to allow me to get to a
shell and enter commands. It feels weird.

---

From: David Given <[email-masked]>
Date: Thu, 30 Mar 2006 00:36:08 +0100

David Given wrote:
[...]
> VIDEO (which is RETURN) and MOBILE MSG (which is BACKSPACE).

Correction: EMAIL is backspace.

Do we have any documentation for this yet?