Thanks, Gordan. I tried this last night. U boot reads the uImage and uInitrd made from the vmlinuz and initrmfs and echos "booting linux kernel". That's as far as it gets, so I suspect you are right. One bit of extra oddness is that (as per the Fedora docs) I creaed my boot partition as fat32 and it won't mount. To work on the boot partition, I have to boot to the old card and mount the new card from a usb card reader, it is a small issue and probably has the salutatory effect of keeping me from messing with it without conscious effort ;) I'll check the u boot docs regarding variables. It may be as simple as adjusting the boot.scr script to work with the vanilla kernel.
I'll keep the kernel installed and try again periodically. Admittedly, I got the u boot kernel files from a link on Solid Run's wiki. Not sure what tools were used to make them, but it was the same user who put together the binaries for the rc8 version of zfs I was using. On Fri, Jul 20, 2012 at 3:44 AM, Gordan Bobic <[email protected]> wrote: > 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<http://lists.redsleeve.org/mailman/listinfo/users> > -- Thanks, Ian M Perkins
_______________________________________________ users mailing list [email protected] http://lists.redsleeve.org/mailman/listinfo/users
