[fedora-arm] uImage-2.6.30 / updating kernels on arbitrary boards

[Gordan Bobic]

On 01/09/2011 11:18 AM, Andy Green wrote:
> On 01/08/11 19:48, Somebody in the thread at some point said:
>> On 01/08/2011 07:33 PM, Chris Tyler wrote:
>>> On Sat, 2011-01-08 at 19:05 +0000, Gordan Bobic wrote:
>>>> 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.
>>>
>>> Well, there's a huge difference between putting / on NAND and the kernel
>>> on NAND. Assuming just a 10,000-write-cycle durability, updating the
>>> kernel every 3-4 days (100x/year) gives you 100 years of life.
>>
>> Assuming you actually get your 10,000 erase cycles out of it - and that
>> is a big assumotion. I have seen a lot of consumer grade MLC flash fail
>> after a few dozen erases (USB sticks, CF cards). In general, if it
>
> Actually with USB Sticks and CF cards you have no idea what you saw
> "fail", since you are not talking to the flash directly, but through a
> controller handling ECC and wear levelling.

Sure, so the bad sector might actually move around, which makes it 
harder to detect. I have, however, seen an issue where some sectors 
simply will not accept further writes - the data always remains the same.

> If in fact an erase sector going bad is the problem it should be swapped
> out by the controller with a spare sector logically mapped in place of it.

Most cheap CF/SD cards and USB sticks don't actually come with any spare 
sectors.

> In the typical emebedded Linux case with raw NAND people are using jffs2
> or yaffs to take care of that, hiding individual sectors on the raw nand
> from the filesystem.

Except that flashing a kernel image to raw NAND won't be on top of yaffs.

> Raw NAND is very ugly to work with, but with ECC and bad block lists and
> remapping by the time Linux gets to see it as a block device it is fine
> for updating the kernel how you like... otherwise just running the
> rootfs would be so fragile it would all turn to crap in minutes and my
> android phone with its many updates would be impractical ^^

Sure, but in that intensive an environment it'd be picked up well within 
the warranty period. :)

And as I said, I don't think the discussion here was about having a 
kernel on a file system but on the raw NAND.

> There is a variety of ways of storing the kernel in embedded systems
> though, not always in /boot on the same filesystem as /.
>
> For example, I have done it myself with at least
>
> - stick it in RAW NAND at a magic offset after the bootloader
> - stick it in Serial NOR flash at a magic offset after the bootloader
> - stick it on its own VFAT partition on sd card
> - stick it on the rootfs partition on sd card

Sure - I always use a seaprate /boot partition, especially on flash 
media, because of the block alignment issues and bootloader issues.

1) The first partition loses 16KB, so everything after that is 
misaligned if you are trying to make thing optimal for erase block sizes 
 > 16KB (and no consumer grade device I've heard of uses erase block 
sizes that small). Typically I align things to 512KB (mkfs.ext[234] -b 
4096 -E stripe-width=128), except where the erase block size is known 
(IIRC Intel disks use 128KB erase blocks).

> Also, it may not make sense to use an initrd in many cases, and if you
> do use it you also have the problem of what to do with it to store it
> accessibly to the bootloader.

I don't that's more of a problem than with the kernel itself. Is it?

> Maybe a plan is just have the kernel package stick it in /boot as usual,
> and as part of its %post look for and if it exists run a script like
> "local-kernel-update.sh" or whatever. It can copy the newly installed
> kernel file down /boot using whatever means are appropriate for that
> particular board.

Personally I think just putting the kernel, initrd and boot.scr (for 
uboot) in /boot and having /boot on a separate partition is the way 
forward. The majority of ARM devices in use today seem to either be 
already well supported by uboot (Sheeva/Guru Plugs, Egika Genesi MX), or 
at least have rudimentary support that is being further worked on 
(Toshiba AC100). Can anyone think of any ARMv5 or later devices that 
have no uboot support and are unlikely to have uboot support in the 
future that would be plausible candidates for running Fedora on?

Gordan