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
> 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
And you know that to state it as a fact because...?
> In the typical emebedded Linux case with raw NAND people are
> 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
> 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
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
> 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
> 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
> 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@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
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.