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 _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
