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

[Gordan Bobic]

On 01/08/2011 05:20 PM, Chris Tyler wrote:
> 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?

I do seem to remember running into this issue of the 2.6.30 kernel 
linked on the wiki.

> (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.

I'd be careful with that. U-boot has a very tentative understanding of 
the ext2 file system. For example, I know for a fact that if you use 
block alignment mkfs parameters (-E 
stride=[blocks],stripe-width=[blocks]) it ceases to be able to handle it.

I'm not sure if that includes any weirdness around hard-links. A 
straight copy might be safer.

> We also need to do an inventory to
> figure out the smallest number of kernels necessary to support common
> hardware).

If you're interested, I can provide you with a 2.6.36.2 .config I use 
that is designed to be used with minimal changes on the Sheeva Plug and 
the Toshiba AC100. I'm hoping I can get away with the only build change 
being the target hardware (Tegra 2 vs. Feroceon).

Another thing worth mentioning that I've found is that the latest u-boot 
is a bit broken when handling high-speed MMC cards. With a normal 
no-name card it was fine, but with a high-speed SanDisk Class 10, it 
fails to initialize properly the first time, and the kernel load fails. 
The bodge solution I've applied is to run mmc_init twice - that makes it 
work, but it is probably something that needs fixing in uboot sooner 
rather than later.

Gordan