[fedora-arm] uImage-2.6.30-sheevaplug is definitely broken

[Dan Horák]

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