[Arm-netbook] First stab at a custom kernel

[Luke Kenneth Casson Leighton]

On Wed, Mar 3, 2010 at 5:03 PM, Frans Pop <elendil at planet.nl> wrote:

> 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.

 ok - by "cheaper" i assume you mean "less NAND flash writes" and also
"overall quicker _if_ things go well".

 however, i do not expect things to go well, initially :)

 if the kernel being written was "good, with occasional chance of
failure", then yes i would (and will) use the method you came up with,
in the future (particularly when we get the linux kernel source code
from chitech)

 however, as the kernel being written is "risky, bad, and little
chance of success", you're adding extra NAND writes to the procedure.
both procedures are the same number of NAND writes (they both involve
firmware reflashes) _except_ for the extra kernel writes involved in
the dd step.  it's not a lot, percentage-wise, so *shrug* dunno why
i'm mentioning it really *rueful* :)