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? It also sounds ill advised to be burning things that are supposed to get updated relatively frequently (kernels DO get updated) to non-replaceable flash. Keeping the kernel with the rest of the distro on the easily removable/replaceable flash media is probably a more reasonable long-term solution. Using built in flash is fine for embedded appliances that only see 1-2 updates/year, but not necessarily for bleeding edge desktop distributions like Fedora. Gordan _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
