[Arm-netbook] First stab at a custom kernel

[Luke Kenneth Casson Leighton]

On Wed, Mar 3, 2010 at 4:12 PM, Frans Pop <elendil at planet.nl> wrote:
> On Wednesday 03 March 2010, Luke Kenneth Casson Leighton wrote:
>> On Wed, Mar 3, 2010 at 3:39 PM, Frans Pop <elendil at planet.nl> wrote:
>>  frans... think about it: if the kernel you replace with is
>> non-successful, how are you going to get access to the NAND flash, in
>> order to put on the former kernel? :)
>
> What exactly are you saying? That replacing the kernel on mmcblk0p1 is not
> enough?

 no that's not it: it's "enough".  think it through.  think through
the consequences.

 you're booting from NAND flash.  the kernel to be loaded is on NAND
flash.  you boot up the machine, you do that dd trick, and thus you've
_just_ replaced the kernel which is the _only_ way that you will be
able to boot up the machine.

 there's _nothing_ else that you have control over (except by
press-and-hold both mouse buttons, following the chitech firmware
"replace" procedure).

> I've been assuming so far that when u-boot is doing inand or movi stuff,
> it's simply reading and writing from/to mmcblk0p1.

 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]

 thus, you have ONE shot at using that dd trick, to replace the very
kernel which, if it happens not to work, you can ONLY replace by using
the chitech firmware replacement procedure which is binary-burned into
u-boot right now (until we get the u-boot source code from chitech).

 in other words, if you FAIL to replace the kernel with a working
kernel, i.e. it happens not fire up and does not give you ethernet
access or keyboard/mouse/framebuffer access, you can ONLY recover the
machine by doing the chitech firmware update procedure.

 on that basis, why bother with the dd trick in the first place, when
you're pretty much guaranteed to mess up at least once, and have to
use the chitech firmware update procedure in order to recover?  why
not get used to going round the loop by placing the replacement kernel
that you want to try out into the chitech firmware update procedure?

 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.