> Things start going wrong right after the "calibrating delay loop":
> [ 6.455145] Calibrating delay loop...
> [ 6.460464] Unable to handle kernel NULL pointer dereference at virtual
> address 00000000
>
> I think that's the root cause ...
> I'm not sure on this but I suppose the kernel aint looking at the device tree
> yet so it may not be something to do with the flattened device tree.
The issue seems to be that they've migrated all of the Sheevaplug support
in to Flattened Device Tree - which is fine because there's a newer u-Boot
available that supports it. However, if I use a kernel with FTD support
compiled in, it crashes on the OpenRD client. I'm seeing if there's any
combination of options that will make it work on both before mailing the
kernel list. I suspect nobody has tested it since 3.12 is new.
I'm also thinking about how best to proceed with ARMv7 since to support a
multitude of devices using the current method, we'd end up with massive
initrd's and installers (Although the installer is probably less of a
concern or interest if you can't boot it anyway ;-) ). Debian have
'flash-kernel' which determines the type of device and (I assume, from the
name) flashes the kernel to NAND if possible, and creates an appropriate
initrd for that device.
The other option is if Eric has time to complete and work on his port,
apart from the Trimslice I'll leave the ARMv7 support alone and let
Slackware ARM focus on the soft float devices.
Hmm. Time will tell.
_______________________________________________
ARMedslack mailing list
ARMedslack@lists.armedslack.org
http://lists.armedslack.org/mailman/listinfo/armedslack