Gordan Bobic pÃÅe v So 08. 01. 2011 v 19:05 +0000: > On 01/08/2011 05:36 PM, Dan HorÃk wrote: > > Chris Tyler pÃÅe v So 08. 01. 2011 v 12:20 -0500: > >> On Sat, 2011-01-08 at 12:28 +0000, Richard W.M. Jones wrote: > >>> Just a note to say that I'm having the precise same problem described > >>> here: > >>> > >>> http://lists.fedoraproject.org/pipermail/arm/2010-December/thread.html#786 > >>> > >>> 'Mojibake' after the kernel is uncompressed. No tty settings seem to > >>> fix it[*]. > >>> > >>> The wiki links to the uImage-2.6.30-sheevaplug image all over, but it > >>> is definitely broken either inherently or just with the latest > >>> SheevaPlug hardware. > >> > >> We should probably update these wiki links to point to a common 'ARM > >> Kernel' page, which we can then use as a trampoline to a > >> currently-recommended kernel or a collection of kernels, and later > >> change to point to an RPM-based kernel solution. Any takers for this bit > >> of wiki gardening? > >> > >> (Speaking of kernels, I'm going to get a couple students looking at > >> doing RPM-based kernels for ARM this semester. Some things from primary > >> archs won't apply, e.g., updating grub boot menus -- I think ARM with > >> uBoot will probably need some ugly pieces like a hard link to the > >> "current" kernel, at least to start. We also need to do an inventory to > >> figure out the smallest number of kernels necessary to support common > >> hardware). > > > > We have a student in Red Hat Brno who will work on RPM-based kernels as > > his bachelor thesis and it should include an improvement in grubby to > > use the flash-kernel utility > > (https://bugzilla.redhat.com/show_bug.cgi?id=548422) Debian is > > developing and using to actually flash the kernel to a supported range > > of devices. We think the kernel installation workflow could be very > > similar to the one used on x86. > > So what exactly do you do when the flashed kernel turns out to be broken > and doesn't boot? The commercial devices that are our target (like NAS made by QNAP) have a documented recovery process without the need for a serial console. And when someone wants to replace the original image with Fedora (or Debian), then he should be aware what is he doing. Dan _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
