[arm] iop32x panics instead of starting d-i from initrd

Bug Description

Hi

Trying to start d-i from the netboot images at http://ports.ubuntu.com/ubuntu-ports/dists/jaunty/main/installer-armel/current/images/iop32x/netboot/ with these redboot commands:
ip_address -l 192.168.0.106 -h 192.168.0.103
load -r -v -b 0x00800000 -m http /initrd
load -r -v -b 0x00200000 -m http /vmlinux
exec -c "console=ttyS0,115200 root=/dev/ram0 initrd=0xa0800000,42M mem=128M@0xa0000000"

the kernel starts but panics instead of starting d-i from initrd:
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
XScale DSP coprocessor detected.
rtc-rs5c372 0-0032: setting system clock to 2009年03月26日 18:07:31 UTC (1238090851)
RAMDISK: Compressed image found at block 0
List of all partitions:
0800 244198584 sda driver: sd
0801 248976 sda1
0802 243947025 sda2
0810 244198584 sdb driver: sd
0811 248976 sdb1
0812 243947025 sdb2
1f00 256 mtdblock0 (driver?)
1f01 13312 mtdblock1 (driver?)
1f02 1408 mtdblock2 (driver?)
1f03 1152 mtdblock3 (driver?)
1f04 4 mtdblock4 (driver?)
1f05 128 mtdblock5 (driver?)
No filesystem could mount root, tried: ext3 ext2 vfat fuseblk
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Dumping ftrace buffer:
(ftrace buffer empty)

I also tried without root=/dev/ram0 but it didn't work more than with it.

Bye

I thought it was again an issue with CONFIG_BLK_DEV_RAM_SIZE=8192 but wget -O - http://ports.ubuntu.com/ubuntu-ports/dists/jaunty/main/installer-armel/current/images/iop32x/netboot/initrd.gz | gunzip -c | wc -c
3727360

so should be enough.

Loic,

Is the kernel config of the netbook version iop32x kernel the same as the debian/config/armel/config.iop32x? and what is the filesystem type of the initrd? I guess it is ext2, right?

Thanks
-Bryan

It's the same kernel binary, the FS is cromfs I think:
wget http://ports.ubuntu.com/ubuntu-ports/dists/jaunty/main/installer-armel/current/images/iop32x/netboot/initrd.gz -O - | gunzip -c | file -
Linux Compressed ROM File System data, little endian size 3727360 version #2 sorted_dirs CRC 0xc381c7b, edition 0, 2083 blocks, 504 files

it is cromfs or cramfs? We need compile cramfs in the kernel instead of a module.
From the config of the iop32x, I think this should be the problem.

Do you want me to provide a patch to merge and then you test that kernel?

-Bryan

Loic,

I thinkt the initrd is cramfs, so I am going to submit a patch for review.
I tried to mount the initrd on my PC.
http://pastebin.ubuntu.com/141674/

And one more thing is the initrd size is bigger than 8M using df. Maybe we need to expand the size of the RAM_SIZE to 16M. But firstly I will try to compile cramfs to the kernel.

Thanks
-Bryan

Fix committed.

This bug was fixed in the package linux - 2.6.28-11.39

---------------
linux (2.6.28-11.39) jaunty; urgency=low

[ Alan Tull ]

* SAUCE: mx51: fix to1.1 in mxc_iomux_set_input
- LP: #348333

[ Andy Whitcroft ]

* SAUCE: acer: rfkill disable quirk for ACER Aspire One
- LP: #319825

[ Brad Figg ]

* ARM: Increase CONFIG_BLK_DEV_RAM_SIZE for imx51 flavour.
- LP: #349842
* ARM: Enable rtl8187 for imx51
- LP: #349526
* ARM: Unset CONFIG_USB_STORAGE_DEBUG for imx51
- LP: #348504

[ Bryan Wu ]

* build CRAMFS into kernel to support mounting CRAMFS initrd on iop32x
machine
- LP: #349104

[ Michael Casadevall ]

* [lpia] Change ATA, SCSI, SD, ext2-4 modules into compiled-in components
- LP: #347458

[ Rob Herring ]

* SAUCE: imx51: fec: fix cache operations for receive
- LP: #348333

[ Sam Yang ]

* SAUCE: Revert ENGR00103870 FEC reopening causes network wdog timeout
- LP: #348333
* SAUCE: imx51: fec cache flush functions are incorrect
- LP: #348333

[ Upstream Kernel Changes ]

* Bluetooth: Add fine grained mem_flags usage to btusb driver
- LP: #268502
* Bluetooth: Handle bulk URBs in btusb driver from notify callback
- LP: #268502
* Bluetooth: Submit bulk URBs along with interrupt URBs
- LP: #268502

-- Tim Gardner <email address hidden> 2009年4月01日 17:37:32 -0600

I confirm this bug was fixed, but the netboot image is useless as the network driver is too flaky to allow an install.