[Arm-netbook] First stab at a custom kernel

[Frans Pop]

On Wednesday 03 March 2010, Luke Kenneth Casson Leighton wrote:
>  yes, that's correct.  which is NAND flash.  over which you have no
> control.  press-and-hold both buttons is _it_ right now.  [unless you
> are proposing to modify the u-boot commands in-place by using dd which
> i reaally seeriously advise that you don't: one mistake and you're
> looking at JTAG for recovery as your only option]

Well, we have limited control. What we cannot do is e.g. add a small D-I 
initrd on mmcblk0p1 and have u-boot load that. What we also cannot do is 
change the u-boot configuration or the offsets at which u-boot and kernel 
are located.

But we *do* have write access to mmcblk0p1, so we can overwrite the kernel 
with a different version. With all due care to avoid bricking the system.

> [unless you are proposing to modify the u-boot commands in-place by using
> dd which i reaally seeriously advise that you don't: one mistake and
> you're looking at JTAG for recovery as your only option]

No, I'm definitely NOT going to touch the u-boot installation in mmcblk0p1.
I might have considered that if the u-boot config was very cleanly 
separated from u-boot itself (as on my QNAP NAS), but as it is: no way.

>  i mean, sure: after you test a kernel which happens not to work, if
> you prefer to re-flash the chitech firmware and _then_ log in and
> _then_ use the dd trick, and _then_ reboot yet another time, go ahead,
> but it's another step in the process, writing yet again to the NAND
> flash, which has a limited number of write cycles.

That's exactly why I prefer my procedure.

For me the alternatives are:

Your way:
- create a custom root tarball including custom kernel modules
- copy that root tarball + custom kernel image + standard u-boot to
  external SD disk
- use the chitech boot procedure which will proceed to
  - rewrite most of mmcblk0p1
  - erase and rewrite mmcblk0p2
- reboot
- assume my kernel fails, so I need to recover
- copy the standard firmware files to my external SD disk
- use the chitech boot procedure which will proceed to
  - rewrite most of mmcblk0p1
  - erase and rewrite mmcblk0p2
- reboot

My way:
- scp my kernel deb to the netbook
- unpack it in a temp location
- copy modules into place in existing root FS
- dd the zImage into the correct location on mmcblk0p1, overwriting
  only *that* region and leaving everything else unchanged
- reboot
- assume my kernel fails, so I need to recover
- copy the standard firmware files to my external SD disk
- use the chitech boot procedure which will proceed to
  - rewrite most of mmcblk0p1
  - erase and rewrite mmcblk0p2
- reboot

With either method the original kernel gets overwritten. With either method 
the only option available for recovery is the chitech boot procedure with 
original firmware.

So the recovery procedure in both cases is exactly the same, but my method 
to do the initial installation of the custom kernel is much, much cheaper.

What am I missing here?
Are you saying that I can run my custom kernel directly from the external 
SD card, *without* rewriting mmcblk0p1?