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

[Andy Green]

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.

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.

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.

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


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

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.

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.

One big thing working in our favour is that Linux usually has 
standardized access to all the storage assets by mtd, usually 
partitioned up nicely if the kernel is just stuck in somewhere raw.

-Andy