[fedora-arm] uImage-2.6.30 / updating kernels / /etc/kernel-update.d

[Peter Robinson]

On Sun, Jan 9, 2011 at 2:30 PM, Andy Green <andy at warmcat.com> wrote:
> On 01/09/11 12:23, Somebody in the thread at some point said:
>
>>>> 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.
>
> No, if the bad sector is found (by erase failure, or uncorrectable ecc)
> then these schemes put it out of circulation permanently, google "nand
> BBT" to learn more.
>
>>> 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.
>
> And you know that to state it as a fact because...?
>
>>> 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.
>
> It can perfectly well be on top of VFAT, ext2, or jffs2 in the U-Boot
> case though, which is much more common than yaffs outside of Android, in
> which case it is not relevant for Fedora.
>
> And in any event, as was done at Openmoko where I was kernel maintainer
> for over a year, nothing stops the bootloader particpating in the same
> EEC and BBT schemes are the mtd layer in Linux when pulling from raw NAND.
>
>>> 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. :)
>
> In case it wasn't clear, I am saying we can indeed bank on 10,000 writes
> to a sector where that is what the datasheet promises.
>
>> 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.
>
> The bit of the discussion is about how to have fedora arm kernels deal
> with the wide variety of boards out there.  Kernels in raw NAND is just
> one scheme that is used there are plenty of others  -->
>
>>> 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.
>
> Other people don't; sometimes choices are forced by the hardware.
>
>>> 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?
>
> Sorry your question can't be understood.
>
> The initrd is brought in by the bootloader and handed to the kernel
> already in-memory.  It means that in addition to needing to be flexible
> with where and how to copy the kernel image itself it assumes that
> everything has the storage and wants to use an initrd.  It'd be better
> if the initrd was not mandatory like it is in normal Fedora.
>
> There's a good reason to not use Fedora initrd + init on slower devices,
> bootup time can be cut to a few seconds with a custom boot script
> instead.  So it'd be good if the initrd was optional in the sense it's
> not required if you're not going to boot via the Fedora path.
>
>>> 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
>
> How does that even fit the case where the kernel is written to raw NAND
> that you were preoccupied about at the start of this mail?
>
> Most of the stuff I use does not use U-Boot.
>
>
> What'd solve this really nicely is a /etc/kernel-update.d/ which has a
> bunch of scripts that try to match based on /proc/cpuinfo.  For example
> on the board I am working on right now, it says in there

I believe the utils that the x86 kernels use already have the ability
to do something like that so it shouldn't be too hard to extend those
utils to be able to update particular files based on arch/machine like
OFW (XO-1.75 will be arm but with openfirmware for eg), uboot, uEFI
etc.

Peter