On Sat, Jul 28, 2007 at 02:12:37AM +0200, Juergen Lock wrote:
> On Sat, Jul 28, 2007 at 12:27:33AM +0200, andrzej zaborowski wrote:
> > On 28/07/07, andrzej zaborowski <[EMAIL PROTECTED]> wrote:
> > > On 26/07/07, Juergen Lock <[EMAIL PROTECTED]> wrote:
> > > > and now I get lots of
> > > > nand ecc errors and mount failures, I guess the mtdparts= arg isnt right
> > > > yet and/or the raw2flash.c source needs fixing...
Okay the first reason for this was the terrier kernel doing long reads
from the nand flash io port, expecting to get 2 bytes at a time.
(enabled by CONFIG_ARCH_PXA_TERRIER at least in the sharp kernel),
see patch-nand-terrier (attached).
> > >
> > > Likely the input to raw2flash.c was not what it expected. It expects a
> > > 1:1 image of the entire flash chip (but excluding oob - only data that
> > > can be normally read from /dev/mtblock* and in the same order), and
> >
> > (/dev/mtdblock*)
> >
> > > with a 10 byte header at the start of the file, which is discarded.
> >
> > (rather 16)
> >
Yeah I hat removed that, but was overlooking the fact that it
repeats the first PARTITION_START (0x00700000) bytes in the output,
because it didnt expect this data in the input, and so it just fills
it out. Added another #ifndef which fixed that, see attached
patch-raw2flash-fullimage.
> > > The partitions layout also matters. This format is the one that
> > > OpenEmbedded outputs, but maybe the original format is also the same,
> > > I don't know.
>
> Guess not, at least my zaurus uses
> mtdparts=sharpsl-nand:[EMAIL PROTECTED](smf),[EMAIL
> PROTECTED](root),-(home)
> and the 44032k is filled in by the sharp firmware as you can see when
> you do a `strings -a' on the image. (It would be interesting to know
> how it finds out that value btw...)
Found a table that seems to define that, example in the terrier image:
00644000 00 00 00 00 00 00 70 00 42 4F 4F 54 00 00 00 00 ......p.BOOT....
00644010 00 00 70 00 00 00 20 03 46 53 52 4F 00 00 00 00 ..p... .FSRO....
00644020 00 00 20 03 00 00 00 08 46 53 52 57 00 00 00 00 .. .....FSRW....
(entries of 1 long offset, 1 long length, 4 chars type, 1 long 0, so
the [EMAIL PROTECTED](root) above is indeed right. The akita image has a
similar table at 0x00660000.)
Anyway, boot now fails with:
qemu: fatal: pxa2xx_gpio_read: Bad offset 0x1c
i.e. it is apparently expecting something there that is not yet
emulated. And when i boot with init=/bin/sh I can't do much because
the keymap seems to be wrong or the fn key otherwise gets lost.
(similar effect with the poky image btw, I wonder is this a qemu
problem or is just noone using the terminal there? :)
Okay enough for today...
Juergen
Index: qemu/hw/spitz.c
+++ work-arm3/qemu-snapshot-2007-07-02_05/hw/spitz.c Sun Jul 29 00:33:34 2007
@@ -78,6 +78,23 @@
return 0;
}
+static uint32_t sl_readl(void *opaque, target_phys_addr_t addr)
+{
+ struct sl_nand_s *s = (struct sl_nand_s *) opaque;
+ int ryby;
+ addr -= s->target_base;
+
+ switch (addr) {
+ case FLASH_FLASHIO:
+ return ecc_digest(&s->ecc, nand_getio(s->nand)) |
+ (ecc_digest(&s->ecc, nand_getio(s->nand)) << 16);
+
+ default:
+ spitz_printf("Bad register offset " REG_FMT "\n", addr);
+ }
+ return 0;
+}
+
static void sl_writeb(void *opaque, target_phys_addr_t addr,
uint32_t value)
{
@@ -139,7 +156,7 @@
CPUReadMemoryFunc *sl_readfn[] = {
sl_readb,
sl_readb,
- sl_readb,
+ sl_readl,
};
CPUWriteMemoryFunc *sl_writefn[] = {
sl_writeb,
--- orig/raw2flash.c Wed May 2 00:35:49 2007
+++ new/raw2flash.c Sun Jul 29 01:56:50 2007
@@ -203,12 +203,14 @@
}
*partition = 1;
case 1:
+#ifndef FULLIMAGE
if (count - PARTITION_START < PARTITION_START) {
memcpy(buffer, jffs_buffer + count - PARTITION_START,
ecc->style->eccbytes);
*len = ecc->style->eccbytes;
break;
}
+#endif
while (*len < ecc->style->eccbytes) {
ret = TFR(read(0, buffer + *len, 0x800 - *len));
@@ -254,8 +256,10 @@
fprintf(stderr, "[");
# endif
+#ifndef FULLIMAGE
/* Skip first 10 bytes */
TFR(read(0, buffer, 0x10));
+#endif
len = 0;
jffs = (uint8_t *) malloc(PARTITION_START);
