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!
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.
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?
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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jonathan McDowell wrote: [...]
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?
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 name.)
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'...
[...]
I've updated the prebuilt kernel to include the palette fixing patch and 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-+ | dg@cowlark.com | "Those that repeat truisms, are also forced to | (dg@tao-group.com) | repeat them." --- Anonymous from Slashdot +- www.cowlark.com --+
--- David Given dg@cowlark.com wrote:
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?
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
-- | .-. en4rab@yahoo.com | / \ .-. | / \ / \ .-. .-. _ _ +--/------------/----------/------/------/--/-//--- | / \ / \ / '-' '-' |/ '-' '-' -END OF TRANSMISSION-
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Wed, Mar 29, 2006 at 02:46:05PM +0100, David Given wrote:
Jonathan McDowell wrote: [...]
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?
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.
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.
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.
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.
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?
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.
(Also, you may be interested to know that the kernel seems to be 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.
Jonathan McDowell wrote: [...]
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.
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.
[...]
(Also, you may be interested to know that the kernel seems to be 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
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.
David Given wrote: [...]
ADDENDUM: I've figured out the keymap on the keypad; the important keys are VIDEO (which is RETURN) and MOBILE MSG (which is BACKSPACE).
Correction: EMAIL is backspace.
Do we have any documentation for this yet?
-
David Given -
en4rab -
Jonathan McDowell