Re: Request review of device tree documentation
Grant Likely wrote: I also changed the property in the cpu nodes from model to compatible so that the exact CPU version can be specified. This isn't actually in any spec anywhere, but I need something to properly identify the different ARM cores. Mitch, I know you were working on a draft ARM binding a while ago, have you resurrected it at all? As it turns out, today I re-began ARM OFW work in earnest, after a hiatus of something like 10 years. I haven't thought much about a binding yet. I'm still getting my head around the current state of the ARM art. How do you think the core should be identified? When I was last working on ARM, few ARM devices had enough resources to run a general purpose OS. To first approximation, StrongARM was the only game in town - so there wasn't much need to address the identification question. It seems that many of the differences at the CPU level can be determined by looking at "coprocessor" registers. For what purpose(s) do we need to identify the core? That will inform our choice of a core ID schema. Cheers, g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
On Fri, 2010-06-11 at 22:19 -1000, Mitch Bradley wrote: > It seems that many of the differences at the CPU level can be determined > by looking at "coprocessor" registers. For what purpose(s) do we need > to identify the core? That will inform our choice of a core ID schema. The primary thing I see would be architecture version compliance, though this is better carried additionally via a binary field in the header or a GPR at the entry point, to help the initial asm code to setup the MMU etc... before getting into C code. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
On Sat, 2010-06-12 at 20:45 +1000, Benjamin Herrenschmidt wrote: > On Fri, 2010-06-11 at 22:19 -1000, Mitch Bradley wrote: > > It seems that many of the differences at the CPU level can be determined > > by looking at "coprocessor" registers. For what purpose(s) do we need > > to identify the core? That will inform our choice of a core ID schema. > > The primary thing I see would be architecture version compliance, > though this is better carried additionally via a binary field in > the header or a GPR at the entry point, to help the initial asm > code to setup the MMU etc... before getting into C code. Also, if you're going to revive a "real" OF port to ARM (with client interface etc...), should we start considering moving some of powerpc's prom_init.c to a generic place ? IE. prom_init is a trampoline that uses the client interface to essentially create a flatten device-tree and enter the kernel via the common "epapr" style entry point. The main drawback is that it doesn't allow to keep OF alive along with the OS, but then, only sparc does that successfully and I'm not sure it's something that would be practical to do on ARM either. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: fix obsolete device tree code for the UPM NAND driver.
Commit 58f9b0b02414062eaff46716bc04b47d7e79add5 removed of_device->node.
This driver was apparently overlooked in the processes.
Signed-off-by: Richard Cochran
---
drivers/mtd/nand/fsl_upm.c | 18 ++
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/nand/fsl_upm.c b/drivers/mtd/nand/fsl_upm.c
index 00aea6f..81ec87a 100644
--- a/drivers/mtd/nand/fsl_upm.c
+++ b/drivers/mtd/nand/fsl_upm.c
@@ -232,7 +232,7 @@ static int __devinit fun_probe(struct of_device *ofdev,
if (!fun)
return -ENOMEM;
- ret = of_address_to_resource(ofdev->node, 0, &io_res);
+ ret = of_address_to_resource(ofdev->dev.of_node, 0, &io_res);
if (ret) {
dev_err(&ofdev->dev, "can't get IO base\n");
goto err1;
@@ -244,7 +244,8 @@ static int __devinit fun_probe(struct of_device *ofdev,
goto err1;
}
- prop = of_get_property(ofdev->node, "fsl,upm-addr-offset", &size);
+ prop = of_get_property(ofdev->dev.of_node,
+ "fsl,upm-addr-offset", &size);
if (!prop || size != sizeof(uint32_t)) {
dev_err(&ofdev->dev, "can't get UPM address offset\n");
ret = -EINVAL;
@@ -252,7 +253,8 @@ static int __devinit fun_probe(struct of_device *ofdev,
}
fun->upm_addr_offset = *prop;
- prop = of_get_property(ofdev->node, "fsl,upm-cmd-offset", &size);
+ prop = of_get_property(ofdev->dev.of_node,
+ "fsl,upm-cmd-offset", &size);
if (!prop || size != sizeof(uint32_t)) {
dev_err(&ofdev->dev, "can't get UPM command offset\n");
ret = -EINVAL;
@@ -260,7 +262,7 @@ static int __devinit fun_probe(struct of_device *ofdev,
}
fun->upm_cmd_offset = *prop;
- prop = of_get_property(ofdev->node,
+ prop = of_get_property(ofdev->dev.of_node,
"fsl,upm-addr-line-cs-offsets", &size);
if (prop && (size / sizeof(uint32_t)) > 0) {
fun->mchip_count = size / sizeof(uint32_t);
@@ -276,7 +278,7 @@ static int __devinit fun_probe(struct of_device *ofdev,
for (i = 0; i < fun->mchip_count; i++) {
fun->rnb_gpio[i] = -1;
- rnb_gpio = of_get_gpio(ofdev->node, i);
+ rnb_gpio = of_get_gpio(ofdev->dev.of_node, i);
if (rnb_gpio >= 0) {
ret = gpio_request(rnb_gpio, dev_name(&ofdev->dev));
if (ret) {
@@ -292,13 +294,13 @@ static int __devinit fun_probe(struct of_device *ofdev,
}
}
- prop = of_get_property(ofdev->node, "chip-delay", NULL);
+ prop = of_get_property(ofdev->dev.of_node, "chip-delay", NULL);
if (prop)
fun->chip_delay = *prop;
else
fun->chip_delay = 50;
- prop = of_get_property(ofdev->node, "fsl,upm-wait-flags", &size);
+ prop = of_get_property(ofdev->dev.of_node, "fsl,upm-wait-flags", &size);
if (prop && size == sizeof(uint32_t))
fun->wait_flags = *prop;
else
@@ -315,7 +317,7 @@ static int __devinit fun_probe(struct of_device *ofdev,
fun->dev = &ofdev->dev;
fun->last_ctrl = NAND_CLE;
- ret = fun_chip_init(fun, ofdev->node, &io_res);
+ ret = fun_chip_init(fun, ofdev->dev.of_node, &io_res);
if (ret)
goto err2;
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix obsolete device tree code for the UPM NAND driver.
On Sat, 12 Jun 2010 14:39:43 +0200 Richard Cochran wrote: > Commit 58f9b0b02414062eaff46716bc04b47d7e79add5 removed of_device->node. > This driver was apparently overlooked in the processes. > > Signed-off-by: Richard Cochran > --- > drivers/mtd/nand/fsl_upm.c | 18 ++ > 1 files changed, 10 insertions(+), 8 deletions(-) This is already fixed in 2.6.35-rc2, please update your tree. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: rtas_flash cannot be a module
Hi,
> So we should use that rtas_data_buf with its lock ...
>
> Oh look, the driver already uses that buffer for the call to verify_flash
>
> untested patch to follow
Thanks, it built and tested OK with the following patch. Will send a
complete patch with these changes in a minute.
Anton
--- build/arch/powerpc/kernel/rtas_flash.c~ 2010-06-12 09:06:43.0
-0400
+++ build/arch/powerpc/kernel/rtas_flash.c 2010-06-12 09:08:30.0
-0400
@@ -613,9 +613,9 @@
* the kernel data segment.
*/
spin_lock(&rtas_data_buf_lock);
- flist = (struct rtas_flash_list *)&rtas_data_buf[0];
- flist.num_blocks = 0;
- flist.next = rtas_firmware_flash_list;
+ flist = (struct flash_block_list *)&rtas_data_buf[0];
+ flist->num_blocks = 0;
+ flist->next = rtas_firmware_flash_list;
rtas_block_list = virt_to_abs(flist);
if (rtas_block_list >= 4UL*1024*1024*1024) {
printk(KERN_ALERT "FLASH: kernel bug...flash list header addr
above 4GB\n");
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: rtas_flash needs to use rtas_data_buf
From: Milton Miller
When trying to flash a machine via the update_flash command, Anton received the
following error:
Restarting system.
FLASH: kernel bug...flash list header addr above 4GB
The code in question has a comment that the flash list should be in
the kernel data and therefore under 4GB:
/* NOTE: the "first" block list is a global var with no data
* blocks in the kernel data segment. We do this because
* we want to ensure this block_list addr is under 4GB.
*/
Unfortunately the Kconfig option is marked tristate which means the variable
may not be in the kernel data and could be above 4GB.
Instead of relying on the data segment being below 4GB, use the static
data buffer allocated by the kernel for use by rtas. Since we don't
use the header struct directly anymore, convert it to a simple pointer.
Reported-By: Anton Blanchard
Signed-Off-By: Milton Miller
---
Index: powerpc.git/arch/powerpc/kernel/rtas_flash.c
===
--- powerpc.git.orig/arch/powerpc/kernel/rtas_flash.c 2010-05-05
16:17:00.883456148 +1000
+++ powerpc.git/arch/powerpc/kernel/rtas_flash.c2010-06-12
23:44:25.973458269 +1000
@@ -94,12 +94,8 @@ struct flash_block_list {
struct flash_block_list *next;
struct flash_block blocks[FLASH_BLOCKS_PER_NODE];
};
-struct flash_block_list_header { /* just the header of flash_block_list */
- unsigned long num_blocks;
- struct flash_block_list *next;
-};
-static struct flash_block_list_header rtas_firmware_flash_list = {0, NULL};
+static struct flash_block_list *rtas_firmware_flash_list;
/* Use slab cache to guarantee 4k alignment */
static struct kmem_cache *flash_block_cache = NULL;
@@ -108,13 +104,14 @@ static struct kmem_cache *flash_block_ca
/* Local copy of the flash block list.
* We only allow one open of the flash proc file and create this
- * list as we go. This list will be put in the
- * rtas_firmware_flash_list var once it is fully read.
+ * list as we go. The rtas_firmware_flash_list varable will be
+ * set once the data is fully read.
*
* For convenience as we build the list we use virtual addrs,
* we do not fill in the version number, and the length field
* is treated as the number of entries currently in the block
- * (i.e. not a byte count). This is all fixed on release.
+ * (i.e. not a byte count). This is all fixed when calling
+ * the flash routine.
*/
/* Status int must be first member of struct */
@@ -201,16 +198,16 @@ static int rtas_flash_release(struct ino
if (uf->flist) {
/* File was opened in write mode for a new flash attempt */
/* Clear saved list */
- if (rtas_firmware_flash_list.next) {
- free_flash_list(rtas_firmware_flash_list.next);
- rtas_firmware_flash_list.next = NULL;
+ if (rtas_firmware_flash_list) {
+ free_flash_list(rtas_firmware_flash_list);
+ rtas_firmware_flash_list = NULL;
}
if (uf->status != FLASH_AUTH)
uf->status = flash_list_valid(uf->flist);
if (uf->status == FLASH_IMG_READY)
- rtas_firmware_flash_list.next = uf->flist;
+ rtas_firmware_flash_list = uf->flist;
else
free_flash_list(uf->flist);
@@ -593,7 +590,7 @@ static void rtas_flash_firmware(int rebo
unsigned long rtas_block_list;
int i, status, update_token;
- if (rtas_firmware_flash_list.next == NULL)
+ if (rtas_firmware_flash_list == NULL)
return; /* nothing to do */
if (reboot_type != SYS_RESTART) {
@@ -610,20 +607,25 @@ static void rtas_flash_firmware(int rebo
return;
}
- /* NOTE: the "first" block list is a global var with no data
-* blocks in the kernel data segment. We do this because
-* we want to ensure this block_list addr is under 4GB.
+ /*
+* NOTE: the "first" block must be under 4GB, so we create
+* an entry with no data blocks in the reserved buffer in
+* the kernel data segment.
*/
- rtas_firmware_flash_list.num_blocks = 0;
- flist = (struct flash_block_list *)&rtas_firmware_flash_list;
+ spin_lock(&rtas_data_buf_lock);
+ flist = (struct flash_block_list *)&rtas_data_buf[0];
+ flist->num_blocks = 0;
+ flist->next = rtas_firmware_flash_list;
rtas_block_list = virt_to_abs(flist);
if (rtas_block_list >= 4UL*1024*1024*1024) {
printk(KERN_ALERT "FLASH: kernel bug...flash list header addr
above 4GB\n");
+ spin_unlock(&rtas_data_buf_lock);
return;
}
printk(KERN_ALERT "FLASH: preparing saved firmware image for flash\n");
Re: Request review of device tree documentation
Benjamin Herrenschmidt wrote: On Sat, 2010-06-12 at 20:45 +1000, Benjamin Herrenschmidt wrote: On Fri, 2010-06-11 at 22:19 -1000, Mitch Bradley wrote: It seems that many of the differences at the CPU level can be determined by looking at "coprocessor" registers. For what purpose(s) do we need to identify the core? That will inform our choice of a core ID schema. The primary thing I see would be architecture version compliance, though this is better carried additionally via a binary field in the header or a GPR at the entry point, to help the initial asm code to setup the MMU etc... before getting into C code. Also, if you're going to revive a "real" OF port to ARM (with client interface etc...), should we start considering moving some of powerpc's prom_init.c to a generic place ? IE. prom_init is a trampoline that uses the client interface to essentially create a flatten device-tree and enter the kernel via the common "epapr" style entry point. The main drawback is that it doesn't allow to keep OF alive along with the OS, but then, only sparc does that successfully and I'm not sure it's something that would be practical to do on ARM either. I'm certainly going to try keeping OFW alive. On the x86 OLPC machines, the ability to dive into OFW via a SysRq key combo was very helpful for debugging some difficult problems. The team has asked me to support the feature on ARM. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
Hi Grant, > I've been doing a bit of work on some introductory level documentation > of the flattened device tree. I've got a rough copy up on the > devicetree.org wiki, and I could use some feedback. If anyone has > some time to look at it, you can find it here: > > http://devicetree.org/Device_Tree_Usage > > Thanks, > g. > this looks good. Maybe an example of a complete host/PCI bridge might be helpful. Probably I can write something during the next week. Regards, Stephan smime.p7s Description: S/MIME Cryptographic Signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
On Sat, Jun 12, 2010 at 12:53:59AM -0600, Grant Likely wrote: > I also changed the property in the cpu nodes from model to compatible > so that the exact CPU version can be specified. This isn't actually > in any spec anywhere, but I need something to properly identify the > different ARM cores. I don't see why this has to be in the device tree. It's not there on PPC. The exact CPU version is found through the PVR register on PPC, ARM also has cpu version and feature registers for runtime probing. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
On Sat, 2010-06-12 at 06:30 -1000, Mitch Bradley wrote: > I'm certainly going to try keeping OFW alive. On the x86 OLPC machines, > the ability to > dive into OFW via a SysRq key combo was very helpful for debugging some > difficult > problems. The team has asked me to support the feature on ARM. Oh well, if you can and can convince the ARM kernel folks to do the necessary changes ... :-) One thing tho, you will only benefit from the whole infrastructure we have created accross platforms in linux if the device-tree is "sucked" into linux at boot. IE. Linux will not do constant accesses to OF for the DT. Even sparc converted to that now. That means that if your device-tree has a dynamic nature, we'll need to come up with a way to inform the kernel of changes in it so it can update it's copy accordingly. We also don't have much mechanisms within Linux to notify users that things have changed either. It only really happens on IBM pseries for hotplug, which uses a private notifier. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
On Sat, Jun 12, 2010 at 4:15 PM, Olof Johansson wrote: > On Sat, Jun 12, 2010 at 12:53:59AM -0600, Grant Likely wrote: > >> I also changed the property in the cpu nodes from model to compatible >> so that the exact CPU version can be specified. This isn't actually >> in any spec anywhere, but I need something to properly identify the >> different ARM cores. > > I don't see why this has to be in the device tree. It's not there on PPC. > The exact CPU version is found through the PVR register on PPC, ARM also > has cpu version and feature registers for runtime probing. I had been told that they runtime registers weren't reliable. If I'm misinformed, then yes the compatible value can be dropped from the cpu nodes. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
That would be great. Thank you. On 12 Jun 2010 11:44, "Stephan Gatzka" wrote: Hi Grant, > I've been doing a bit of work on some introductory level documentation > of the flattened device... this looks good. Maybe an example of a complete host/PCI bridge might be helpful. Probably I can write something during the next week. Regards, Stephan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Fix mpic_resume on early G5 macs
mpic_resume() on G5 macs blindly dereferences mpic->fixups, but
it may legitimately be NULL (as on PowerMac7,2). Add an explicit
check.
This fixes suspend-to-disk with one processor (maxcpus=1) for me.
Signed-off-by: Alastair Bridgewater
---
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 4fd57ab..28668ba 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1666,7 +1666,7 @@ static int mpic_resume(struct sys_device *dev)
mpic->save_data[i].dest);
#ifdef CONFIG_MPIC_U3_HT_IRQS
- {
+ if (mpic->fixups) {
struct mpic_irq_fixup *fixup = &mpic->fixups[i];
if (fixup->base) {
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
On Sat, Jun 12, 2010 at 4:52 PM, Benjamin Herrenschmidt wrote: > On Sat, 2010-06-12 at 06:30 -1000, Mitch Bradley wrote: > >> I'm certainly going to try keeping OFW alive. On the x86 OLPC machines, >> the ability to >> dive into OFW via a SysRq key combo was very helpful for debugging some >> difficult >> problems. The team has asked me to support the feature on ARM. > > Oh well, if you can and can convince the ARM kernel folks to do the > necessary changes ... :-) What is needed to keep OFW alive? I've got no problem with doing so if it isn't invasive, and as long as the same boot entry interface can be used. > One thing tho, you will only benefit from the whole infrastructure we > have created accross platforms in linux if the device-tree is "sucked" > into linux at boot. IE. Linux will not do constant accesses to OF for > the DT. Even sparc converted to that now. > > That means that if your device-tree has a dynamic nature, we'll need to > come up with a way to inform the kernel of changes in it so it can > update it's copy accordingly. What is the use-case for having a dynamic device tree? I can see keeping OFW alive being useful for some debug facilities, but once the kernel has started, I'm really not interested in relying on firmware to manage the hardware. (but then again it's no secret that I'm suspicious of anything that depends on runtime interaction with firmware). g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
Grant Likely wrote: On Sat, Jun 12, 2010 at 4:52 PM, Benjamin Herrenschmidt wrote: On Sat, 2010-06-12 at 06:30 -1000, Mitch Bradley wrote: I'm certainly going to try keeping OFW alive. On the x86 OLPC machines, the ability to dive into OFW via a SysRq key combo was very helpful for debugging some difficult problems. The team has asked me to support the feature on ARM. Oh well, if you can and can convince the ARM kernel folks to do the necessary changes ... :-) What is needed to keep OFW alive? I've got no problem with doing so if it isn't invasive, and as long as the same boot entry interface can be used. Minimally, OFW needs to own some memory that the kernel won't steal. OFW on ARM is position-independent, so it can be tucked up at the top of memory fairly easily. To call back into OFW, the virtual mapping for that memory needs to be reestablished. Or perhaps the MMU and caches can be turned off for the duration of the callback. I don't have the details of ARM MMUs and caches reloaded into my head yet. Maybe next week... Also, for debugging, OFW typically needs access to a UART. If the OS is using the UART, it's often possible for OFW to use it just by turning off interrupts and polling the UART. One thing tho, you will only benefit from the whole infrastructure we have created accross platforms in linux if the device-tree is "sucked" into linux at boot. IE. Linux will not do constant accesses to OF for the DT. Even sparc converted to that now. That means that if your device-tree has a dynamic nature, we'll need to come up with a way to inform the kernel of changes in it so it can update it's copy accordingly. What is the use-case for having a dynamic device tree? The use case for a dynamic device tree is not compelling. In SPARC / Solaris land, Open Boot managed the non-volatile configuration variables, which the OS could access and modify dynamically as properties in /options. The OS didn't have to know the storage layout nor the hardware details of the storage device. Convenient, but not hugely important. I can see keeping OFW alive being useful for some debug facilities, but once the kernel has started, I'm really not interested in relying on firmware to manage the hardware. That's sort of a self-fulfilling prophecy. If the OS doesn't trust the firmware, there is no pressure for the firmware to "get it right". In PC land, the current status quo is that Windows depends on ACPI so heavily that BIOS vendors pretty much have to get that part of the puzzle right. Microsoft did a thorough job of creating certification tests and enforcing their use. I'm not praising ACPI, just pointing out the dynamics that result from assignment of responsibility. That said, I'm not interested in pushing the issue. It's okay with me if the device tree is static as far as the kernel is concerned, and callbacks to OFW are only used for debugging purposes. (but then again it's no secret that I'm suspicious of anything that depends on runtime interaction with firmware). g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
On Sat, 2010-06-12 at 23:07 -0600, Grant Likely wrote: > > What is needed to keep OFW alive? I've got no problem with doing so > if it isn't invasive, and as long as the same boot entry interface can > be used. Well, no. OF has a well defined "client interface" which is what gets us in prom_init.c on powerpc when r5 is non NULL. You can use it to do things like access devices or the device-tree. We use that to suck the device-tree, which we flatten, and then re-enter the kernel with the "common" entry interface. If you want to keep OF alive, you -can- probably do that too, but it's more tricky. You need to keep the memory where OF resides reserved, OF might need special MMU translations, you maybe need to install hooks in OF itself for it to be able to manipulate some of those, etc... > What is the use-case for having a dynamic device tree? I can see > keeping OFW alive being useful for some debug facilities, but once the > kernel has started, I'm really not interested in relying on firmware > to manage the hardware. (but then again it's no secret that I'm > suspicious of anything that depends on runtime interaction with > firmware). As we all are :-) I see one genuine use of dynamic device-tree though, which is in a virtualized environment (where the host can be Linux itself). Hotplug can then be a matter of getting new nodes & properties fed down to the OS by the hypervisor/firmware. pSeries somewhat works like that, but using weirdo rtas calls. We could do something saner for kvm or whatever other hypervisors we have some amount of control onto, where bits of compiled dtb can be handed down representing a sub-hierarchy of the tree. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
On Sat, 2010-06-12 at 19:39 -1000, Mitch Bradley wrote: > Minimally, OFW needs to own some memory that the kernel won't steal. > OFW on ARM is position-independent, so it can be tucked up at the top of > memory > fairly easily. Amen :-) > To call back into OFW, the virtual mapping for that memory needs to be > reestablished. That's a nasty part unless ARM provides a usable "real mode" which allows MMIO accesses, which I -think- it does. I don't remember the details that much. Maybe we could define a binding tho where we could somewhat standardize the portion of the virtual address space used by OF. IE. from the top of the address space down to the max size it requires. It might require some games to play with the fixmap on ARM side tho... Another option would be something more RTAS-like where a specific call can be done by the OS itself to 'relocate' (not physically but virtually in this case) OF into the OS preferred location. Be prepared to have multiple of these called though as kernels kexec into one another. > Or perhaps the MMU and caches can be turned off for the duration of the > callback. > I don't have the details of ARM MMUs and caches reloaded into my head > yet. Maybe next week... Forgot most of it too. Looks like it's about time I read the ARM architecture again, this sounds like fun :-) BTW. I notice no ARM list is CCed on this discussion ... maybe we should fix that ? > Also, for debugging, OFW typically needs access to a UART. If the OS is > using the UART, it's often possible for OFW to use it just by turning off > interrupts and > polling the UART. That might not be a big deal unless the OS plays with the clocks which it -does- tend to do. It might be worth defining some kind of property OF puts in the UART node to inform the OS not to play games and keep that one enabled, though that could affect power management, so might need to be conditional on some nvram option (debug-enabled?) > The use case for a dynamic device tree is not compelling. Right, generally not, except in virtualized environments (see my other response). Now, the -one- thing that WILL happen if we have something like OF that remains alive is of course vendors will try to use it as a HAL. You know as well as I do that it -will- happen :-) There's two reasons that typically happen. The misguided "good" one which is to think it helps keeping a single/more maintainable kernel image by stuffing the horrible details of nvram, rtc, etc.. access, poweron/off GPIOs, clock control, etc... in there. The "bad" one which is to stash code you don't want to show the source code for (codec control, etc...). This is bad for so many reasons that I don't think I need to even start listing them :-) So that's something that will have to be strongly kept in check and fought I suspect. To some extent, in fact, doing that sort of stuff in OF or even in RTAS like we do on power is even worse than ACPI-like tables. At least with those tables, the interpreter is in the operating system, thus can run with interrupts on, scheduling on, etc... With RTAS, or client interface calls, you'll end up with potentially huge slumps of CPU time "lost" into the bowels of the firmware. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
Benjamin Herrenschmidt wrote: On Sat, 2010-06-12 at 19:39 -1000, Mitch Bradley wrote: Minimally, OFW needs to own some memory that the kernel won't steal. OFW on ARM is position-independent, so it can be tucked up at the top of memory fairly easily. Amen :-) To call back into OFW, the virtual mapping for that memory needs to be reestablished. That's a nasty part unless ARM provides a usable "real mode" which allows MMIO accesses, which I -think- it does. I don't remember the details that much. IIRC - and I could be wrong - ARM does have a "real mode", but the catch is that you must have the MMU on in order to use the caches, to distinguish between memory and MMIO. So you take a fairly hefty performance hit. I'm running my test build right now with caches off, and the performance is okay for interactive work, but I'll want to have them on for startup and bootloading, so as not to negatively impact the boot time. Maybe we could define a binding tho where we could somewhat standardize the portion of the virtual address space used by OF. IE. from the top of the address space down to the max size it requires. It might require some games to play with the fixmap on ARM side tho... That would be okay as far as I'm concerned. Another option would be something more RTAS-like where a specific call can be done by the OS itself to 'relocate' (not physically but virtually in this case) OF into the OS preferred location. Be prepared to have multiple of these called though as kernels kexec into one another. That might be a bit harder, but still do-able. Or perhaps the MMU and caches can be turned off for the duration of the callback. I don't have the details of ARM MMUs and caches reloaded into my head yet. Maybe next week... Forgot most of it too. Looks like it's about time I read the ARM architecture again, this sounds like fun :-) BTW. I notice no ARM list is CCed on this discussion ... maybe we should fix that ? Sounds like a good idea. Do you know which list(s) would be good candidates? Also, for debugging, OFW typically needs access to a UART. If the OS is using the UART, it's often possible for OFW to use it just by turning off interrupts and polling the UART. That might not be a big deal unless the OS plays with the clocks which it -does- tend to do. It might be worth defining some kind of property OF puts in the UART node to inform the OS not to play games and keep that one enabled, though that could affect power management, so might need to be conditional on some nvram option (debug-enabled?) The use case for a dynamic device tree is not compelling. Right, generally not, except in virtualized environments (see my other response). Now, the -one- thing that WILL happen if we have something like OF that remains alive is of course vendors will try to use it as a HAL. You know as well as I do that it -will- happen :-) I tried to be very clear when I was developing OFW that is is not a HAL. I knew that it would be impractical to pin down a coherent set of assumptions in the face of the many different OSs - and versions of the "same" OS - that were extant at the time. Digital was fairly committed to the HAL approach on Alpha, but they had two different HAL ABIs, one for VMS and a different one for Ultrix! So they were unable to solve the problem for N=2, where both OSs were under their control. There's two reasons that typically happen. The misguided "good" one which is to think it helps keeping a single/more maintainable kernel image by stuffing the horrible details of nvram, rtc, etc.. access, poweron/off GPIOs, clock control, etc... in there. Whether or not it is "misguided" depends on your cost structure. For hardware companies that don't control (and don't want to control) the OS, it is one of only two possible ways to ship product. Either you make hardware that is 100% compatible with something that the OS already supports, or you have a HAL at some level. The PC industry, of course, has played both games, and by and large has been economically successful. The "bad" one which is to stash code you don't want to show the source code for (codec control, etc...). This is bad for so many reasons that I don't think I need to even start listing them :-) So that's something that will have to be strongly kept in check and fought I suspect. Either fought or embraced. To the extent that it is possible to focus solely on Linux and ARM, one could image doing a good HAL. (The reason I say ARM-only is because the only other non-x86 architecture that has any "legs" left is PowerPC, and PPC already has a coherent story.) To some extent, in fact, doing that sort of stuff in OF or even in RTAS like we do on power is even worse than ACPI-like tables. At least with those tables, the interpreter is in the operating system, thus can run with interrupts on, scheduling on, etc... I have an FCode
Re: [microblaze-uclinux] Re: Request review of device tree documentation
On Sat, Jun 12, 2010 at 05:09:36PM -0600, Grant Likely wrote: > On Sat, Jun 12, 2010 at 4:15 PM, Olof Johansson wrote: > > On Sat, Jun 12, 2010 at 12:53:59AM -0600, Grant Likely wrote: > > > >> I also changed the property in the cpu nodes from model to compatible > >> so that the exact CPU version can be specified. This isn't actually > >> in any spec anywhere, but I need something to properly identify the > >> different ARM cores. > > > > I don't see why this has to be in the device tree. It's not there on PPC. > > The exact CPU version is found through the PVR register on PPC, ARM also > > has cpu version and feature registers for runtime probing. > > I had been told that they runtime registers weren't reliable. If I'm > misinformed, then yes the compatible value can be dropped from the cpu > nodes. Hi all, If it's not too painful to keep, I think it will be valuable if one want's to instantiate HW based/from this same device tree. For example for emulators. Cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
