On 07/20/2012 01:54 AM, Ian Perkins wrote:
Finally figured out both why my working card would only boot to the kernel in nvram and why the new high performance card was wonky. U boot had a problem with the boot partition and would default back to the kernel stored in nvram. Trying to copy this partition caused some really weird results. I have the new card up and running with a Fedora F17 (kirkwood) 3.3.8 kernel, booting from the microsd card :) Unfortunately, this kernel is compiled with PREEMPTIVE flag set, so I cannot build ZFS. The good news is that I can try to build the RSEL kerne. I am starting off with a clean rootfs, with networking configs copied in from the other card, so maybe I can document stuff ;)
I'm not 100% sure but I have a suspicion that Armada support was added after 2.6.32, so you might find that you cannot enable support for the CuBox SoC.
It might be worth trying getting the vanilla RSEL kirkwood kernel to work, though. On a SheevaPlug, you can cheat the kernel into thinking it's on a different machine by setting the machid uboot variable, so rather than panicking, the kernel will have a go at booting. Later uboot uses the arcNumber environment variable rather than machid for the same purpose, IIRC. Google it, I'm sure you'll find the relevant information. Before you embark on a multi-day exercise of rebuilding the kernel, it might be worth trying to cheat the standard kernel into booting. If that boots (or at least boots reasonably far before panicking), then it might be worth a try. If it doesn't boot at all, it likely won't work without SoC specific support patches.
Note: I've found that uboot tools tend to do something weird when it comes to making uimage from vmliuz. It _SHOULD_ work according to the documentation, and it should be possible to extract zImage from vmlinuz (they are not the same, despite documentation apparently claiming they should be in a few places). But I don't recall ever getting it to work. One of the things on my todo list is modifying the kernel src.rpm to build uimage during kernel build time to work around that (and produce a kernel-uimage additional package). I'm hoping uboot tools have been fixed to handle this correctly since the last time I tried it, but it's worth bearing in mind. Ironically, it also means that if it doesn't work you might still be able to get it to work by using the zImage file created during the kernel build - which means rebuilding the kernel from source.
Gordan _______________________________________________ users mailing list [email protected] http://lists.redsleeve.org/mailman/listinfo/users
