| Message ID | 1231601482-28123-1-git-send-email-adrian@lisas.de (mailing list archive) |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
On Sun Jan 11 at 02:31:22 EST in 2009, Adrian Reber wrote: > This adds support for a simple character device to access the > flash for SLOF based systems like the PowerStation, QS2x and > PXCAB. In the SLOF git there is a user space program with > which the content of the flash for SLOF based systems can > be displayed and modified. This can be used to add a Linux > image to the flash and then directly boot the kernel from the > flash. > > Signed-off-by: Adrian Reber <adrian at lisas.de> > --- > > This is based on the mmio NVRAM driver. I am not sure how useful this > is for anybody else but I am posting it anyway, hoping to get some > feedback. Also hoping it can be included at one point. Normally such drivers are written and mtd drivers. If slof were not an of implementation I would just say put the right properties on the node in the device tree, but the kernel should adapt to real OF. It should be easy to write a driver to hook up a mtd platform device if this is a direct mapped flash. > + > +static void __iomem *slof_flash_start; > +static long slof_flash_len; > +static DEFINE_SPINLOCK(slof_flash_lock); > + > + > +static ssize_t slof_flash_read(struct file *file, char __user *buf, > + size_t count, loff_t *ppos) > +{ > + unsigned long flags; > + char *tmp; > + int rc; > + > + spin_lock_irqsave(&slof_flash_lock, flags); > + > + memcpy_fromio(tmp, slof_flash_start + *ppos, count); > + > + spin_unlock_irqrestore(&slof_flash_lock, flags); > + Why do you need a spinlock? Why does it need to be irq safe? This decision is also driving the malloc of the temporary buffer, and you are intentionally returning a short read to userspace. > + > +const struct file_operations slof_flash_fops = { > + .owner = THIS_MODULE, > + .llseek = slof_flash_llseek, > + .read = slof_flash_read, > +}; > + You mentioned userspace reflashing the image, but this driver seems to be read only access. > +static struct miscdevice slof_flash_dev = { > + SLOF_FLASH_MINOR, > + "slof_flash", > + &slof_flash_fops > +}; > + > + > +static int __init slof_flash_init(void) > +{ > + struct device_node *slof_flash; > + struct device_node *compatible; > + struct resource r; > + int rc; > + unsigned long slof_flash_addr; > + /* SLOF is known to run on systems with following values > + * for the compatible property: */ > + char *compstrs[] = {"IBM,Bimini", "IBM,JS21", "IBM,JS20", > "IBM,CBEA" }; > + int i; > + > + for (i = 0; i < ARRAY_SIZE(compstrs); i++) { > + compatible = of_find_compatible_node(NULL, NULL, > compstrs[i]); > + > + if (compatible) > + break; > + } Can you identify slof from the information in the /openprom node? I don't think all js20 and 21 use slof, although the IBM provided firmware may also work with this driver. > + > + /* not a system with a SLOF flash */ > + if (!compatible) > + return -ENODEV; > + > + of_node_put(compatible); > + > + slof_flash = of_find_node_by_type(NULL, "flash"); > + if (!slof_flash) { > + printk(KERN_WARNING "SLOF FLASH: " > + "no flash node found in device-tree\n"); > + return -ENODEV; > + } > + rc = of_address_to_resource(slof_flash, 0, &r); > + if (rc) { > + printk(KERN_WARNING "SLOF FLASH: " > + "failed to get address (err %d)\n", rc); > + goto out; > + } > + > + slof_flash_addr = r.start; > + slof_flash_len = r.end - r.start + 1; > + > + if ((slof_flash_len <= 0) || (!slof_flash_addr)) { > + printk(KERN_WARNING "SLOF FLASH: address or length is > 0\n"); > + rc = -EIO; > + goto out; > + } Why are these warnings? again, debug is more approprate > + > + slof_flash_start = ioremap(slof_flash_addr, slof_flash_len); > + if (!slof_flash_start) { > + printk(KERN_WARNING "SLOF FLASH: failed to ioremap\n"); > + rc = -ENOMEM; > + goto out; > + } > + > + printk(KERN_INFO "SLOF FLASH: %luk at 0x%lx mapped to %p\n", > + slof_flash_len >> 10, slof_flash_addr, > slof_flash_start); This looks to be a debug message at most. > + > + rc = misc_register(&slof_flash_dev); And as I said, this should be a mtd driver. Thanks, milton
On Sat, Jan 10, 2009 at 11:52:56AM -0600, Milton Miller wrote: > On Sun Jan 11 at 02:31:22 EST in 2009, Adrian Reber wrote: >> This adds support for a simple character device to access the >> flash for SLOF based systems like the PowerStation, QS2x and >> PXCAB. In the SLOF git there is a user space program with >> which the content of the flash for SLOF based systems can >> be displayed and modified. This can be used to add a Linux >> image to the flash and then directly boot the kernel from the >> flash. >> >> Signed-off-by: Adrian Reber <adrian at lisas.de> >> --- >> >> This is based on the mmio NVRAM driver. I am not sure how useful this >> is for anybody else but I am posting it anyway, hoping to get some >> feedback. Also hoping it can be included at one point. > > > Normally such drivers are written and mtd drivers. > > If slof were not an of implementation I would just say put the right > properties on the node in the device tree, but the kernel should adapt > to real OF. It should be easy to write a driver to hook up a mtd > platform device if this is a direct mapped flash. The reason why I did not use mtd is that part of the flash is used by the firmware image and I do not know if that works with mtd, if only a part of the flash can be used. SLOF does also a "CRC" check over the firmware image, so that image must have valid SLOF "CRC". The flash is a direct mapped flash, but the size of the firmware can vary. >> + >> +static void __iomem *slof_flash_start; >> +static long slof_flash_len; >> +static DEFINE_SPINLOCK(slof_flash_lock); >> + >> + >> +static ssize_t slof_flash_read(struct file *file, char __user *buf, >> + size_t count, loff_t *ppos) >> +{ >> + unsigned long flags; >> + char *tmp; >> + int rc; >> + >> + spin_lock_irqsave(&slof_flash_lock, flags); >> + >> + memcpy_fromio(tmp, slof_flash_start + *ppos, count); >> + >> + spin_unlock_irqrestore(&slof_flash_lock, flags); >> + > > Why do you need a spinlock? Why does it need to be irq safe? I must confess I copied that code from the nvram driver and I do not know if it is necessary. > This decision is also driving the malloc of the temporary buffer, and > you are intentionally returning a short read to userspace. > >> + >> +const struct file_operations slof_flash_fops = { >> + .owner = THIS_MODULE, >> + .llseek = slof_flash_llseek, >> + .read = slof_flash_read, >> +}; >> + > > You mentioned userspace reflashing the image, but this driver seems to > be read only access. This driver is read only. I am writing the new flash image using the RTAS functionality to update the firmware flash. Using this device I can use a userspace tool to add a file to the flash. The tool puts the result on the local filesystem. Then using the normal RTAS flash update it can be rewritten. That way I can add a kernel (with a ramdisk) to the flash and then let SLOF boot that kernel. This is especially interesting for the PXCAB Cell based PCI Express card. >> +static struct miscdevice slof_flash_dev = { >> + SLOF_FLASH_MINOR, >> + "slof_flash", >> + &slof_flash_fops >> +}; >> + >> + >> +static int __init slof_flash_init(void) >> +{ >> + struct device_node *slof_flash; >> + struct device_node *compatible; >> + struct resource r; >> + int rc; >> + unsigned long slof_flash_addr; >> + /* SLOF is known to run on systems with following values >> + * for the compatible property: */ >> + char *compstrs[] = {"IBM,Bimini", "IBM,JS21", "IBM,JS20", >> "IBM,CBEA" }; >> + int i; >> + >> + for (i = 0; i < ARRAY_SIZE(compstrs); i++) { >> + compatible = of_find_compatible_node(NULL, NULL, >> compstrs[i]); >> + >> + if (compatible) >> + break; >> + } > > > Can you identify slof from the information in the /openprom node? I Yes I can identify SLOF from the model property in the /openprom node. I did not do it because there is almost no code accessing the /openprom node and therefore I did not read it. > don't think all js20 and 21 use slof, although the IBM provided firmware > may also work with this driver. There are probably only very few js20/js21 which are using SLOF. I do not think the original IBM product firmware for those blades mentions anything about js20/js21 in the compatible node. I do not have access to such a system but the compatible node usually has some product number, if I remember it correctly. I am pretty sure that the original js20/js21 firmware does not have the flash in the device tree, because RTAS is supposed to be the only valid way to access the flash. >> + >> + /* not a system with a SLOF flash */ >> + if (!compatible) >> + return -ENODEV; >> + >> + of_node_put(compatible); >> + >> + slof_flash = of_find_node_by_type(NULL, "flash"); >> + if (!slof_flash) { >> + printk(KERN_WARNING "SLOF FLASH: " >> + "no flash node found in device-tree\n"); >> + return -ENODEV; >> + } >> + rc = of_address_to_resource(slof_flash, 0, &r); >> + if (rc) { >> + printk(KERN_WARNING "SLOF FLASH: " >> + "failed to get address (err %d)\n", rc); >> + goto out; >> + } >> + >> + slof_flash_addr = r.start; >> + slof_flash_len = r.end - r.start + 1; >> + >> + if ((slof_flash_len <= 0) || (!slof_flash_addr)) { >> + printk(KERN_WARNING "SLOF FLASH: address or length is >> 0\n"); >> + rc = -EIO; >> + goto out; >> + } > > Why are these warnings? again, debug is more approprate Copied from the NVRAM driver. Will change it to debug. >> + >> + slof_flash_start = ioremap(slof_flash_addr, slof_flash_len); >> + if (!slof_flash_start) { >> + printk(KERN_WARNING "SLOF FLASH: failed to ioremap\n"); >> + rc = -ENOMEM; >> + goto out; >> + } >> + >> + printk(KERN_INFO "SLOF FLASH: %luk at 0x%lx mapped to %p\n", >> + slof_flash_len >> 10, slof_flash_addr, >> slof_flash_start); > > This looks to be a debug message at most. Also copied from the mmio NVRAM driver. I can also change that. >> + >> + rc = misc_register(&slof_flash_dev); > > And as I said, this should be a mtd driver. Thanks for the review. Should it also be a mtd driver with the firmware at the beginning of the flash with an unknown size? I would also prefer to continue to use the RTAS flash update functionality to write the flash instead of reimplementing it in the operating system. My main motivation for this code was to have a way to access the firmware image. The firmware image is using some kind of simple filesystem. I want to be able to modify that filesystem and flash it again. The advantage if I put something in SLOF's filesystem is that I can access that file (in my case boot it) with existing functionality provided by SLOF. Adrian
On Jan 10, 2009, at 1:50 PM, Adrian Reber wrote: > On Sat, Jan 10, 2009 at 11:52:56AM -0600, Milton Miller wrote: >> On Sun Jan 11 at 02:31:22 EST in 2009, Adrian Reber wrote: >>> This adds support for a simple character device to access the >>> flash for SLOF based systems like the PowerStation, QS2x and >>> PXCAB. In the SLOF git there is a user space program with >>> which the content of the flash for SLOF based systems can >>> be displayed and modified. This can be used to add a Linux >>> image to the flash and then directly boot the kernel from the >>> flash. >>> >>> Signed-off-by: Adrian Reber <adrian at lisas.de> >>> --- >>> >>> This is based on the mmio NVRAM driver. I am not sure how useful this >>> is for anybody else but I am posting it anyway, hoping to get some >>> feedback. Also hoping it can be included at one point. >> >> >> Normally such drivers are written and mtd drivers. >> >> If slof were not an of implementation I would just say put the right >> properties on the node in the device tree, but the kernel should adapt >> to real OF. It should be easy to write a driver to hook up a mtd >> platform device if this is a direct mapped flash. > > The reason why I did not use mtd is that part of the flash is used by > the firmware image and I do not know if that works with mtd, if only a > part of the flash can be used. SLOF does also a "CRC" check over the > firmware image, so that image must have valid SLOF "CRC". The flash is > a direct mapped flash, but the size of the firmware can vary. But you later say you will only be using this driver to read the flash. >>> + spin_lock_irqsave(&slof_flash_lock, flags); >>> + >>> + memcpy_fromio(tmp, slof_flash_start + *ppos, count); >>> + >>> + spin_unlock_irqrestore(&slof_flash_lock, flags); >>> + >> >> Why do you need a spinlock? Why does it need to be irq safe? > > I must confess I copied that code from the nvram driver and I do not > know if it is necessary. I'm not sure which driver you ar referring to here. Which file name? Its not required for memcpy_fromio. If you have no indirect indexing or writing to require exclusing against concurrent access ... > >> This decision is also driving the malloc of the temporary buffer, and >> you are intentionally returning a short read to userspace. >> >>> + >>> +const struct file_operations slof_flash_fops = { >>> + .owner = THIS_MODULE, >>> + .llseek = slof_flash_llseek, >>> + .read = slof_flash_read, >>> +}; >>> + >> >> You mentioned userspace reflashing the image, but this driver seems to >> be read only access. > > This driver is read only. I am writing the new flash image using the > RTAS functionality to update the firmware flash. Using this device I > can > use a userspace tool to add a file to the flash. The tool puts the > result on the local filesystem. Then using the normal RTAS flash update > it can be rewritten. That way I can add a kernel (with a ramdisk) to > the > flash and then let SLOF boot that kernel. This is especially > interesting > for the PXCAB Cell based PCI Express card. Ok you need to highlight that you will be using the platform support to write the image. Reading the patch (again) it would appear that you are just reading the size of the node from the device tree. Regardless even if you are trying to cover the whole rom or a portion, read-ony access should be safe, if not secure. >> >> >> Can you identify slof from the information in the /openprom node? I > > Yes I can identify SLOF from the model property in the /openprom node. > I > did not do it because there is almost no code accessing the /openprom > node and therefore I did not read it. > >> don't think all js20 and 21 use slof, although the IBM provided >> firmware >> may also work with this driver. > > There are probably only very few js20/js21 which are using SLOF. I do > not think the original IBM product firmware for those blades mentions > anything about js20/js21 in the compatible node. I do not have access > to > such a system but the compatible node usually has some product number, > if I remember it correctly. > > I am pretty sure that the original js20/js21 firmware does not have the > flash in the device tree, because RTAS is supposed to be the only valid > way to access the flash. > >>> + if ((slof_flash_len <= 0) || (!slof_flash_addr)) { >>> + printk(KERN_WARNING "SLOF FLASH: address or length is >>> 0\n"); >>> + rc = -EIO; >>> + goto out; >>> + } >> >> Why are these warnings? again, debug is more approprate > > Copied from the NVRAM driver. Will change it to debug. Thanks. These would still apply to a mtd driver. >>> + >>> + rc = misc_register(&slof_flash_dev); >> >> And as I said, this should be a mtd driver. > > Thanks for the review. Should it also be a mtd driver with the firmware > at the beginning of the flash with an unknown size? > > I would also prefer to continue to use the RTAS flash update > functionality to write the flash instead of reimplementing it in the > operating system. I don't have a problem with that, but it should have been mentioned up front. > > My main motivation for this code was to have a way to access the > firmware image. The firmware image is using some kind of simple > filesystem. I want to be able to modify that filesystem and flash it > again. The advantage if I put something in SLOF's filesystem is that I > can access that file (in my case boot it) with existing functionality > provided by SLOF. Is SLOF just exposing the user image part of the flash device? Or is it the raw flash device? I need to keep this quick, but am intrested in a few more details. My first reaction is its yet another random misc-device, but I confess to having written one for internal consumption. But as a misc device it will need to go through lkml review to be merged. milton
Adrian Reber wrote: > On Sat, Jan 10, 2009 at 11:52:56AM -0600, Milton Miller wrote: >> Normally such drivers are written and mtd drivers. >> >> If slof were not an of implementation I would just say put the right >> properties on the node in the device tree, but the kernel should adapt >> to real OF. It should be easy to write a driver to hook up a mtd >> platform device if this is a direct mapped flash. > > The reason why I did not use mtd is that part of the flash is used by > the firmware image and I do not know if that works with mtd, if only a > part of the flash can be used. SLOF does also a "CRC" check over the > firmware image, so that image must have valid SLOF "CRC". The flash is > a direct mapped flash, but the size of the firmware can vary. > It can. MTD can create "partitions" within the flash, for an example see lines 84-110 of arch/powerpc/bootdts/sbc8641d.dts (http://tinyurl.com/7k2kym) Partitions can also be labeled as read-only, I guess the CRC could be checked from userspace as necessary. HTH, Martyn
On Monday 12 January 2009, Martyn Welch wrote: > Adrian Reber wrote: > > The reason why I did not use mtd is that part of the flash is used by > > the firmware image and I do not know if that works with mtd, if only a > > part of the flash can be used. SLOF does also a "CRC" check over the > > firmware image, so that image must have valid SLOF "CRC". The flash is > > a direct mapped flash, but the size of the firmware can vary. > > It can. MTD can create "partitions" within the flash, for an example > see lines 84-110 of arch/powerpc/bootdts/sbc8641d.dts (http://tinyurl.com/7k2kym) > > Partitions can also be labeled as read-only, I guess the CRC could be > checked from userspace as necessary. Murali has also done a modified firmware for experiments in the past where he added the device tree entry for the flash on a PxCAB. As I recall, he did not see any problems with that. Arnd <><
On Mon, Jan 12, 2009 at 09:51:23AM -0600, Milton Miller wrote: > Is SLOF just exposing the user image part of the flash device? Or is it > the raw flash device? SLOF is exposing the raw flash device. > I need to keep this quick, but am intrested in a few more details. My > first reaction is its yet another random misc-device, but I confess to > having written one for internal consumption. But as a misc device it > will need to go through lkml review to be merged. I had a look at mtd and it was pretty easy to get it to do the same thing as my misc-device was doing with only 5 lines changed in drivers/mtd/maps/physmap_of.c So thanks for pointing me in that direction. What would be now the best way to include the SLOF flash properly into the mtd driver? Should I add additional code to physmap_of.c to detect the flash and then use a hardcoded layout for the partition? Because SLOF is missing all the necessary properties in the flash device node. Or should I add the missing properties in prom_init.c in a fixup_device_tree_slof() function? Both versions would lead to the same result but I am unsure about which approach is the better one. Adrian
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig index 47fe2be..7f436e0 100644 --- a/arch/powerpc/platforms/Kconfig +++ b/arch/powerpc/platforms/Kconfig @@ -301,6 +301,14 @@ config OF_RTC Uses information from the OF or flattened device tree to instatiate platform devices for direct mapped RTC chips like the DS1742 or DS1743. +config SLOF_FLASH + bool "SLOF flash device" + depends on PPC_MAPLE || PPC_IBM_CELL_BLADE + default y + help + Provide a read-only device to read out the flash + for SLOF based systems. + source "arch/powerpc/sysdev/bestcomm/Kconfig" config MPC8xxx_GPIO diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile index b33b28a..298485d 100644 --- a/arch/powerpc/sysdev/Makefile +++ b/arch/powerpc/sysdev/Makefile @@ -50,3 +50,5 @@ obj-$(CONFIG_UCODE_PATCH) += micropatch.o ifeq ($(CONFIG_SUSPEND),y) obj-$(CONFIG_6xx) += 6xx-suspend.o endif + +obj-$(CONFIG_SLOF_FLASH) += slof_flash.o diff --git a/arch/powerpc/sysdev/slof_flash.c b/arch/powerpc/sysdev/slof_flash.c new file mode 100644 index 0000000..bc94d48 --- /dev/null +++ b/arch/powerpc/sysdev/slof_flash.c @@ -0,0 +1,174 @@ +/* + * SLOF flash access + * + * (C) Copyright MATRIX VISION GmbH 2009 + * + * Authors : Adrian Reber <adrian@lisas.de> + * + * Based on mmio NVRAM driver + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2, or (at your option) + * any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + + +#include <linux/miscdevice.h> +#include <asm/uaccess.h> +#include <asm/prom.h> +#include <asm/machdep.h> + +static void __iomem *slof_flash_start; +static long slof_flash_len; +static DEFINE_SPINLOCK(slof_flash_lock); + +static loff_t slof_flash_llseek(struct file *file, loff_t offset, int origin) +{ + switch (origin) { + case 1: + offset += file->f_pos; + break; + case 2: + offset += slof_flash_len; + break; + } + if (offset < 0) + return -EINVAL; + file->f_pos = offset; + return file->f_pos; +} + + +static ssize_t slof_flash_read(struct file *file, char __user *buf, + size_t count, loff_t *ppos) +{ + unsigned long flags; + char *tmp; + int rc; + + if (*ppos >= slof_flash_len) + return 0; + if (*ppos + count > slof_flash_len) + count = slof_flash_len - *ppos; + + count = min(count, PAGE_SIZE); + tmp = kzalloc(count, GFP_KERNEL); + + if (!tmp) + return -ENOMEM; + + spin_lock_irqsave(&slof_flash_lock, flags); + + memcpy_fromio(tmp, slof_flash_start + *ppos, count); + + spin_unlock_irqrestore(&slof_flash_lock, flags); + + rc = count; + if (copy_to_user(buf, tmp, count)) { + rc = -EFAULT; + goto out; + } + + *ppos += count; +out: + kfree(tmp); + return rc; +} + +const struct file_operations slof_flash_fops = { + .owner = THIS_MODULE, + .llseek = slof_flash_llseek, + .read = slof_flash_read, +}; + +static struct miscdevice slof_flash_dev = { + SLOF_FLASH_MINOR, + "slof_flash", + &slof_flash_fops +}; + + +static int __init slof_flash_init(void) +{ + struct device_node *slof_flash; + struct device_node *compatible; + struct resource r; + int rc; + unsigned long slof_flash_addr; + /* SLOF is known to run on systems with following values + * for the compatible property: */ + char *compstrs[] = {"IBM,Bimini", "IBM,JS21", "IBM,JS20", "IBM,CBEA" }; + int i; + + for (i = 0; i < ARRAY_SIZE(compstrs); i++) { + compatible = of_find_compatible_node(NULL, NULL, compstrs[i]); + + if (compatible) + break; + } + + /* not a system with a SLOF flash */ + if (!compatible) + return -ENODEV; + + of_node_put(compatible); + + slof_flash = of_find_node_by_type(NULL, "flash"); + if (!slof_flash) { + printk(KERN_WARNING "SLOF FLASH: " + "no flash node found in device-tree\n"); + return -ENODEV; + } + rc = of_address_to_resource(slof_flash, 0, &r); + if (rc) { + printk(KERN_WARNING "SLOF FLASH: " + "failed to get address (err %d)\n", rc); + goto out; + } + + slof_flash_addr = r.start; + slof_flash_len = r.end - r.start + 1; + + if ((slof_flash_len <= 0) || (!slof_flash_addr)) { + printk(KERN_WARNING "SLOF FLASH: address or length is 0\n"); + rc = -EIO; + goto out; + } + + slof_flash_start = ioremap(slof_flash_addr, slof_flash_len); + if (!slof_flash_start) { + printk(KERN_WARNING "SLOF FLASH: failed to ioremap\n"); + rc = -ENOMEM; + goto out; + } + + printk(KERN_INFO "SLOF FLASH: %luk at 0x%lx mapped to %p\n", + slof_flash_len >> 10, slof_flash_addr, slof_flash_start); + + rc = misc_register(&slof_flash_dev); + if (rc != 0) + printk(KERN_ERR "SLOF FLASH: failed to register device\n"); + +out: + of_node_put(slof_flash); + return rc; +} + +void __exit slof_flash_cleanup(void) +{ + misc_deregister(&slof_flash_dev); +} + +module_init(slof_flash_init); +module_exit(slof_flash_cleanup); +MODULE_LICENSE("GPL"); diff --git a/include/linux/miscdevice.h b/include/linux/miscdevice.h index a820f81..0887042 100644 --- a/include/linux/miscdevice.h +++ b/include/linux/miscdevice.h @@ -19,6 +19,7 @@ #define SUN_OPENPROM_MINOR 139 #define DMAPI_MINOR 140 /* DMAPI */ #define NVRAM_MINOR 144 +#define SLOF_FLASH_MINOR 145 #define SGI_MMTIMER 153 #define STORE_QUEUE_MINOR 155 #define I2O_MINOR 166
This adds support for a simple character device to access the flash for SLOF based systems like the PowerStation, QS2x and PXCAB. In the SLOF git there is a user space program with which the content of the flash for SLOF based systems can be displayed and modified. This can be used to add a Linux image to the flash and then directly boot the kernel from the flash. Signed-off-by: Adrian Reber <adrian@lisas.de> --- This is based on the mmio NVRAM driver. I am not sure how useful this is for anybody else but I am posting it anyway, hoping to get some feedback. Also hoping it can be included at one point. arch/powerpc/platforms/Kconfig | 8 ++ arch/powerpc/sysdev/Makefile | 2 + arch/powerpc/sysdev/slof_flash.c | 174 ++++++++++++++++++++++++++++++++++++++ include/linux/miscdevice.h | 1 + 4 files changed, 185 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/sysdev/slof_flash.c