aboutsummaryrefslogtreecommitdiff
path: root/drivers/mtd/redboot.c
AgeCommit message (Collapse)Author
2006-05-16[MTD] Fix build warnings in RedBoot MTD partition parser.Ben Dooks
Fix build warnings from drivers/mtd/redboot.c due to use of `unsigned long` in `struct fis_image_desc` for fields being passed to swab32s() which expects __u32 * Change the entries to uint32_t to make them compatible with the swab32s() function Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-03-31[PATCH] mtd/redboot: Handle holes in fis tablePeter Korsgaard
Redboot simply sets the first character of a fis entry to 0xff on "fis delete". The kernel redboot parser stops parsing on such an entry, and without this patch any entries after a deleted image would not be detected. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> Cc: Thomas Gleixner <tglx@linutronix.de> Acked-by: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-02[PATCH] "drivers/mtd/redboot.c: recognise a foreign byte sex partition ↵John Bowler
table" update Sync up the recent redboot fix with MTD CVS. It uses the correct swab() functions. Cc: John Bowler <jbowler@acm.org> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Martin Michlmayr <tbm@cyrius.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-28[PATCH] drivers/mtd/redboot.c: recognise a foreign byte sex partition tableJohn Bowler
The RedBoot boot loader writes flash partition tables containing native byte sex 32 bit values. When booting an opposite byte sex kernel (e.g. an LE kernel from BE RedBoot) the current MTD driver fails to handle the partition table and therefore is unable to generate the correct partition map for the flash. So far as I am aware this problem is ARM specific, because only ARM supports software change of the CPU (memory system) byte sex, however the partition table parsing is in generic MTD code. The patch below has been tested on NSLU2 (an IXP4XX based system) with a patch, 10-ixp4xx-copy-from.patch (submitted to linux-arm-kernel - it's ARM specific) required to make the maps/ixp4xx.c driver work with an LE kernel. Builds of the patched system are in the 'unstable' release of OpenSlug and UcSlugC available from www.nslu2-linux.org. These builds are BE, the archives at www.nslu2-linux.org and www.handhelds.org (see monotone.vanille.de) can be built LE (currently DISTRO targets nslu-ltu.conf for LE thumb uclibc (32 bit kernel) and nslu2-lau.conf, nslu2-lag.conf for LE arm uclibc/glibc) and this patch has been tested extensively will both BE and LE systems on the NSLU2 (including swapping between BE and LE by reflashing from both RedBoot and Linux). The patch recognises that the FIS directory (the partition table) is byte-reversed by examining the partition table size, which is known to be one erase block (this is an assumption made elsewhere in redboot.c). If the size matches the erase block after byte swapping the value then byte-reversal is assumed, if not no further action is taken. The patched code is fail safe; should redboot.c be changed to support a partition table with a modified size field the test will fail and the partition table will be assumed to have the host byte sex. If byte-reversal is detected the patch byte swaps the remainder of the 32 bit fields in the copy of the table; this copy is then used to set up the MTD partition map. Signed-off-by: John Bowler <jbowler@acm.org> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Martin Michlmayr <tbm@cyrius.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-07[MTD] core: Clean up trailing white spacesThomas Gleixner
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!