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

[Dennis Gilmore]

"Gordan Bobic" <gordan at bobich.net> wrote:

>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?

Yes the olpc xo it will be using openfirmware not uboot and will probably ship more units than those you mentioned 

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.