Kernel doesn't boot when using the kernel uncompressor

[mickey@…]

It displays the splash screen and then hangs forever. Booting via Boot-Menu
always works. On serial:

DRAM: 128 MB
NAND: 64 MiB
Found Environment offset in OOB..
Video: 640x480x8 31kHz 59Hz

NAND read: device 0 offset 0x244000, size 0x5000

20480 bytes read: OK

USB: S3C2410 USB Deviced

[mickey@…]

U-Boot 1.3.0-rc1-moko11_r0 (Sep 17 2007 - 14:12:38)

DRAM: 128 MB
NAND: 64 MiB
Found Environment offset in OOB..
Video: 640x480x8 31kHz 59Hz

NAND read: device 0 offset 0x244000, size 0x5000

20480 bytes read: OK

USB: S3C2410 USB Deviced
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0

NAND read: device 0 offset 0x44000, size 0x200000

2097152 bytes read: OK

## Booting image at 32000000 ...

Image Name: OpenMoko?/2.6.22.5-moko11+svnr293
Created: 2007-09-15 23:14:52 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1653876 Bytes = 1.6 MB
Load Address: 30008000
Entry Point: 30008000
Verifying Checksum ... OK

OK

Starting kernel ...

Uncompressing
Linux........................................................................................................................
done, booting the kernel.

[alphaone@…]

I have seen that a while back, too. It doesn't happen with
U-Boot 1.2.0-moko9_r1 (Aug 23 2007 - 03:49:09)

On U-Boot 1.3.0-rc1-moko11_r0 (Sep 17 2007 - 15:07:24) that problem seems to
occur only if there is no USB cable attached. If I power up the phone and then
immediately attach a USB cable the kernel boots.

[laforge@…]

the boot log seems perfectly normal. the "booting the kernel" printout is
actually already inside the linux kernel image and past u-boot.

[mickey@…]

Right. We actually have two independent problems. One is with trying to use the
kernel uncompressor instead of the U-boot one (because the latter one is much
slower), one is about USB hanging w/ recent U-Boots. I'll therefore change this
bug and will add another one.

[mickey@…]

Using printascii() I get some more information:

Uncompressing
Linux........................................................................................................................
done, booting the kernel.
<5>Linux version 2.6.22.5-moko11 (mickey@localhost) (gcc version 4.1.2) #1
PREEMPT Mon Sep 17 16:31:41 CEST 2007
CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0007177
Machine: GTA01
Memory policy: ECC disabled, Data cache writeback
<7>On node 0 totalpages: 32768
<7> DMA zone: 256 pages used for memmap
<7> DMA zone: 0 pages reserved
<7> DMA zone: 32512 pages, LIFO batch:7
<7> Normal zone: 0 pages used for memmap
CPU S3C2410A (id 0x32410002)
S3C2410: core 266.000 MHz, memory 133.000 MHz, peripheral 66.500 MHz
<6>S3C24XX Clocks, (c) 2004 Simtec Electronics
CLOCK: Slow mode (1.500 MHz), fast, MPLL on, UPLL on
CPU0: D VIVT write-back cache
CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets
CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets
Built 1 zonelists. Total pages: 32512
<5>Kernel command line: rootfstype=jffs2 root=/dev/mtdblock4
console=ttySAC0,115200 console=tty0 loglevel=8
mtdparts=neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash),0x03d1c000(rootfs)
irq: clearing pending ext status 00000280
irq: clearing subpending status 00000002
PID hash table entries: 512 (order: 9, 2048 bytes)
timer tcon=00500000, tcnt d877, tcfg 00000200,00000000, usec 00001719

[koen@…]

The printascii shows that the decompressor isn't at fault, otherwise you
wouldn't see 'done, booting the kernel. This looks awfully like a race that is
avoided when using the slow uboot decompressor

[andy@…]

Maybe this race is the same one that can cause death coming back from suspend,
#887?

Is this problem still seen on GTA-02?

[andy]

This issue doesn't happen on GTA02. It didn't seem to be the decompressor since the kernel started OK, but timing as koen suggested. Either way I don't see this GTA01-only issue with no movement for 9 months will get fixed by us so marking as Wontfix while hoping it is fixed already.