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