Grant Likely wrote:
On Sat, Jun 12, 2010 at 4:52 PM, Benjamin Herrenschmidt
<b...@kernel.crashing.org> 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
