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

[Andy Green]

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

[root at ivmon ~]# cat /proc/cpuinfo
Processor	: ARM926EJ-S rev 4 (v5l)
BogoMIPS	: 103.42
Features	: swp half thumb fastmult vfp edsp java
CPU implementer	: 0x41
CPU architecture: 5TEJ
CPU variant	: 0x0
CPU part	: 0x926
CPU revision	: 4

Hardware	: Embedded Artists LPC3250 OEM board with the LPC3250 
Microcontroller
Revision	: 0001
Serial		: 0000000000000000

Based on the board ID and its revision, that script can take care of 
"doing the right thing" to update the kernel from the one in /boot.  The 
arm kernel packages can take care of packaging most of these scripts but 
local ones can be kept or vendors can package others.

-Andy