[Arm-netbook] Dissecting mmcblk0p1 and the boot process

[Frans Pop]

On Sunday 14 March 2010, Frans Pop wrote:
> There are two kernel images in the firmware tarball:
> - zImage_dt
> - zImage_dt_update
>
> The first we know is the kernel copied to flash and what is booted
> during a normal system boot.
>
> The second is quite a bit larger. I suspect that it's a kernel with an
> initramfs initrd piggybacked on top of it.
> This initrd would then contain a simple Linux system that partitions the
> flash, creates file systems on the 2nd and 3rd partition and extracts
> the root FS.

I've verified this by doing a flash boot with only:
- a dummy datang-epc.tar.gz file
- a custom built kernel as zImage_dt_update (without initrd piggybacked)

The kernel on mmcblk0p1 at that time was the original ChiTech kernel.

This resulted in:
- the zImage_dt_update was booted
- the normal root FS getting mounted
- at the next reboot the *original* kernel gets booted again

So this means we can test custom kernels *without* flashing them!

The next problem is how exactly to piggyback an initrd on top of the 
kernel. There are various alternatives, but I've not yet found something 
that works. Any help would be much appreciated.

1) Peter Anvin's "wraplinux" utility: is only for x86
2) The kernel's "bootpImage" make target: requires that "initrd_phys-y"
   is defined for the machine type in arch/arm/mach-*/Makefile.boot,
   but that file does not exist for smdk6410; and to create it, what
   would be the correct value for initrd_phys-y?
3) Using mkimage: strange thing is that the netbook's u-boot does not
   seem to understand kernels created using mkimage...
4) Any other options?

For the third option I've tried
   mkimage -A arm -O Linux -T multi -C gzip -a 0x00008000 -e 0x00008000 \
           -d zImage:initrd.gz zImage_dt_update
And also with '-a 0 -e 0'. Both without success; the kernel is simply not 
booted.

Would anybody be able to dissect the zImage_dt_update provided by ChiTech 
to see how they may have done it?

Cheers,
FJP