* Re: Request review of device tree documentation
From: Benjamin Herrenschmidt @ 2010-06-14 9:36 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Nicolas Pitre, microblaze-uclinux, devicetree-discuss,
Olof Johansson, linuxppc-dev, Mitch Bradley, Dan Malek,
Jeremy Kerr, linux-arm-kernel
In-Reply-To: <20100614092559.GA7881@n2100.arm.linux.org.uk>
On Mon, 2010-06-14 at 10:25 +0100, Russell King - ARM Linux wrote:
> On Sun, Jun 13, 2010 at 09:45:50PM -1000, Mitch Bradley wrote:
> > None of this is a deal-breaker for the kind of debugging tasks that are
> > the primary use case for the callback.
>
> Would you mind explaining what kind of tasks these callbacks will
> be used for?
That's one of the thing I'm "touching" on in my previous reply...
(For those who didn't quite follow, the discussion here is about
allowing a real Open Firmware implementation on ARM with the feature of
leaving OF alive while the OS is up, which is something sparc does but
we never supported on ppc).
Ideally, if you keep open firmware alive, you can drop into it when the
kernel crashes for example, or in some other circumstances.
However, there's a lot of room for abuse here and I'm worried that if it
becomes widespread, we'll start seeing vendors use that as a way to do
some kind of HAL and hide various platform methods in there (clock
control, nvram, etc...).
Another option Mitch mentioned is to have the f-code interpreter (f-code
is OF tokenized forth format) in the kernel, but that doesn't completely
solve the problem of providing it with appropriate virtual mappings,
arbitrating access to HW resources, etc etc etc
OF as a FW/bootloader is great. OF alive along with the OS can be a nice
debugging tool under some circumstances but I am a bit more dubious as
to whether that's going to work out in practice. But I'd like to -not-
see it abused as some kind of HAL.
Cheers,
Ben.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Russell King - ARM Linux @ 2010-06-14 9:25 UTC (permalink / raw)
To: Mitch Bradley
Cc: Nicolas Pitre, devicetree-discuss, linuxppc-dev,
microblaze-uclinux, Olof Johansson, Dan Malek, Jeremy Kerr,
linux-arm-kernel
In-Reply-To: <4C15DE2E.1050905@firmworks.com>
On Sun, Jun 13, 2010 at 09:45:50PM -1000, Mitch Bradley wrote:
> None of this is a deal-breaker for the kind of debugging tasks that are
> the primary use case for the callback.
Would you mind explaining what kind of tasks these callbacks will
be used for?
^ permalink raw reply
* Re: Port Linux to ML510
From: srikanth krishnakar @ 2010-06-14 8:56 UTC (permalink / raw)
To: kostas padarnitsas; +Cc: linuxppc-dev
In-Reply-To: <BAY152-w58B66B551376FF621F6E4DBCD80@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 2354 bytes --]
If any changes w.r.t board then John Linn (XILINX) should be able to provide
some pointers.
2010/6/11 kostas padarnitsas <kpada84@hotmail.com>
> Hi Srikant,
>
> Thanks for your help. I checked the driver versions and they seem ok. The
> problem is that when I download the linux image the program counter is not
> set to the address of boot sector of linux kernel, so linux doesn't boot. On
> the other hand with the ML507 everything works perfectly. Any idea??
>
> Thanks in advance,
> Kostas
>
> ------------------------------
> Date: Thu, 10 Jun 2010 12:34:56 +0530
> Subject: Re: Port Linux to ML510
> From: skrishnakar@gmail.com
> To: kpada84@hotmail.com
> CC: linuxppc-dev@lists.ozlabs.org
>
>
> Hi kostas,
>
> You need to verify that the driver version of serial and Ethernet (probably
> X-LLTEMAC) provided in the virtex440.dts matches version used in kernel.
> Look for "compatible = <version>" in the drivers. You can probably use EDK
> 11.2 as it is the latest from Xilinx.
>
> Have you generated your own DTS and Bitstream (download.bit) files ?
>
> If not then you should look for suitable download.bit for you kernel.
>
> -Srikant
>
> 2010/6/10 kostas padarnitsas <kpada84@hotmail.com>
>
> Hello,
>
> I am trying to port Linux to PowerPC on the ML510 Xilinx board. I am using
> EDK 10.1.3 to build the hardware and also device tree generator and the
> linux kernel from xilinx git. I followed the tutorial from
> http://xilinx.wikidot.com/powerpc-linux but I have no output. I have
> attached my .mhs file and the .dts. Any ideas what may cause this problem
> because I did the same thing with ML507 and it was working perfectly?
>
> Thanks in advance,
> Kostas
>
> ------------------------------
> Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. Sign up
> now. <https://signup.live.com/signup.aspx?id=60969>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
>
>
> --
> "The Good You Do, The Best You GET"
>
> Regards
> Srikanth Krishnakar
> **********************
>
> ------------------------------
> Hotmail: Free, trusted and rich email service. Get it now.<https://signup.live.com/signup.aspx?id=60969>
>
--
"The Good You Do, The Best You GET"
Regards
Srikanth Krishnakar
**********************
[-- Attachment #2: Type: text/html, Size: 3537 bytes --]
^ permalink raw reply
* Re: Request review of device tree documentation
From: Russell King - ARM Linux @ 2010-06-14 7:38 UTC (permalink / raw)
To: Grant Likely
Cc: Mitch Bradley, Nicolas Pitre, devicetree-discuss, linuxppc-dev,
microblaze-uclinux, Olof Johansson, Dan Malek, Jeremy Kerr,
linux-arm-kernel
In-Reply-To: <AANLkTinwL0XtMNG13inr_1UliOlqZkyr4dlvG-ZGL9JT@mail.gmail.com>
On Sun, Jun 13, 2010 at 11:23:45PM -0600, Grant Likely wrote:
> >> 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...
We've had these kinds of questions in the past. Doing what you're asking
above is not really an option - it requires:
1. disable all IRQs
2. setup 1:1 MMU mappings for code to turn off MMU
(requires new page table)
3. disable imprecise exceptions
4. flush caches and TLBS
5. jump to 1:1 mapping area for code to disable MMU
6. disable caches and mmu
7. call function
8. flush caches and TLBs
9. re-enable caches and mmu
10. re-enable imprecise exceptions
11. switch back to original MMU mappings
12. re-enable all IRQs
This is fine if you don't care at all about interrupt latency.
Unfortunately, most people do care about interrupt latency because
that directly affects interactivity and system performance. The
called function could not enable interrupts or exceptions - as the
CPU vectors are in virtual space, disabling the MMU effectively
makes them disappear.
Moreover, with the MMU and caches disabled, the CPU performance is
extremely poor, so the called function will run slowly.
So, disabling the MMU isn't really viable.
Now, if the external code was fully PIC, we could then run it with
the MMU enabled. However, this wouldn't really help - the external
code could not access any devices without knowledge of how the kernel
setup the V:P translations.
So you'd need to pass some kind of data structure giving locations of
devices to the called code - but then what if the kernel doesn't have
the device mapped?
^ permalink raw reply
* Re: Request review of device tree documentation
From: Mitch Bradley @ 2010-06-14 7:45 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Nicolas Pitre, devicetree-discuss, linuxppc-dev,
microblaze-uclinux, Olof Johansson, Dan Malek, Jeremy Kerr,
linux-arm-kernel
In-Reply-To: <20100614073828.GA6095@n2100.arm.linux.org.uk>
Russell King - ARM Linux wrote:
> On Sun, Jun 13, 2010 at 11:23:45PM -0600, Grant Likely wrote:
>
>>>> 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...
>>>>
>
> We've had these kinds of questions in the past. Doing what you're asking
> above is not really an option - it requires:
>
> 1. disable all IRQs
> 2. setup 1:1 MMU mappings for code to turn off MMU
> (requires new page table)
> 3. disable imprecise exceptions
> 4. flush caches and TLBS
> 5. jump to 1:1 mapping area for code to disable MMU
> 6. disable caches and mmu
> 7. call function
> 8. flush caches and TLBs
> 9. re-enable caches and mmu
> 10. re-enable imprecise exceptions
> 11. switch back to original MMU mappings
> 12. re-enable all IRQs
>
> This is fine if you don't care at all about interrupt latency.
> Unfortunately, most people do care about interrupt latency because
> that directly affects interactivity and system performance. The
> called function could not enable interrupts or exceptions - as the
> CPU vectors are in virtual space, disabling the MMU effectively
> makes them disappear.
>
> Moreover, with the MMU and caches disabled, the CPU performance is
> extremely poor, so the called function will run slowly.
>
> So, disabling the MMU isn't really viable.
>
None of this is a deal-breaker for the kind of debugging tasks that are
the primary use case for the callback.
> Now, if the external code was fully PIC, we could then run it with
> the MMU enabled. However, this wouldn't really help - the external
> code could not access any devices without knowledge of how the kernel
> setup the V:P translations.
>
> So you'd need to pass some kind of data structure giving locations of
> devices to the called code - but then what if the kernel doesn't have
> the device mapped?
>
>
^ permalink raw reply
* Re: Request review of device tree documentation
From: Mitch Bradley @ 2010-06-14 6:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Nicolas Pitre, microblaze-uclinux, devicetree-discuss,
linuxppc-dev, Olof Johansson, Dan Malek, Jeremy Kerr,
linux-arm-kernel
In-Reply-To: <1276495772.2552.22.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Sun, 2010-06-13 at 23:13 -0600, Grant Likely wrote:
>
>>> We use that to suck the device-tree, which we flatten, and then
>>>
>> re-enter
>>
>>> the kernel with the "common" entry interface.
>>>
>> I don't think I want to do the same on ARM. I'd rather have the
>> prom_init stuff in a boot wrapper, or have OFW itself generate the
>> flat representation before booting the kernel.
>>
>
> But then it's no longer OF. IE. A compliant OF implementation provides a
> client interface API :-)
>
> This is going to be especially important if Mitch wants to keep OF
> alive.
>
> I suppose it could be done via a wrapper like prom_init, which flattens
> the tree, and sticks somewhere in a property the address of the OF
> client interface callback though it's a tad awkward. If well defined, I
> suppose Mitch might even be able to make his OF natively boot kernels
> that way but that's of course up to him.
>
I'm willing to create a flattened tree. I can provide both a client
interface and a flattened tree. The kernel probably won't use the
client interface to any significant extent.
Way back in the misty annals of history, I dreamed of having a common
interface between firmware and OSs. That didn't happen. Every OS
insisted on defining its own interface and creating a custom bootloader,
or in some cases a half dozen of them.
>
>> I'm trying to constrain the number of things that could go wrong by
>> defining only one way for getting the device tree data into the
>> kernel.
>>
>
> I understand, and the flattened method is the most versatile, I'm just
> pointing out the situation here :-)
>
>
>> Right. We don't need to use OFW/RTAS to handle this use case.
>>
>
> Definitely not. It will depend on whatever hypervisor interface is
> implemented in a given environment. Though I do like the idea of passing
> precompiled bits of .dtb around for hotplug :-) We could make that a
> standard way of KVM to do things in embedded space.
>
> Cheers,
> Ben.
>
>
>
^ permalink raw reply
* Re: Request review of device tree documentation
From: Benjamin Herrenschmidt @ 2010-06-14 6:09 UTC (permalink / raw)
To: Grant Likely
Cc: linuxppc-dev, microblaze-uclinux, devicetree-discuss,
Nicolas Pitre, Olof Johansson, Mitch Bradley, Dan Malek,
Jeremy Kerr, linux-arm-kernel
In-Reply-To: <AANLkTikBjwuVvij8I91XaQgLfn8r_lZDrAsIBfJrHDBF@mail.gmail.com>
On Sun, 2010-06-13 at 23:13 -0600, Grant Likely wrote:
> > We use that to suck the device-tree, which we flatten, and then
> re-enter
> > the kernel with the "common" entry interface.
>
> I don't think I want to do the same on ARM. I'd rather have the
> prom_init stuff in a boot wrapper, or have OFW itself generate the
> flat representation before booting the kernel.
But then it's no longer OF. IE. A compliant OF implementation provides a
client interface API :-)
This is going to be especially important if Mitch wants to keep OF
alive.
I suppose it could be done via a wrapper like prom_init, which flattens
the tree, and sticks somewhere in a property the address of the OF
client interface callback though it's a tad awkward. If well defined, I
suppose Mitch might even be able to make his OF natively boot kernels
that way but that's of course up to him.
> I'm trying to constrain the number of things that could go wrong by
> defining only one way for getting the device tree data into the
> kernel.
I understand, and the flattened method is the most versatile, I'm just
pointing out the situation here :-)
> Right. We don't need to use OFW/RTAS to handle this use case.
Definitely not. It will depend on whatever hypervisor interface is
implemented in a given environment. Though I do like the idea of passing
precompiled bits of .dtb around for hotplug :-) We could make that a
standard way of KVM to do things in embedded space.
Cheers,
Ben.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Grant Likely @ 2010-06-14 5:54 UTC (permalink / raw)
To: stephan; +Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev
In-Reply-To: <4C13C4D9.2030108@gatzka.org>
On Sat, Jun 12, 2010 at 11:33 AM, Stephan Gatzka <stephan@gatzka.org> wrote=
:
> Hi Grant,
>
>> I've been doing a bit of work on some introductory level documentation
>> of the flattened device tree. =A0I've got a rough copy up on the
>> devicetree.org wiki, and I could use some feedback. =A0If 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.
Hi Stephan,
I see that you started drafting some of this on the wiki. Thanks for
the draft you've done so far. Some comments:
- Instead, of using an MPC5200 example, add a pci bus to the sample
Coyote's Revenge system used in the rest of the page and describe
that. The goal of this document is to lead a user step-by-step how
each part of the device tree works. So, instead of plopping down the
complete PCI bus node, the document should gradually build it up, and
talk about each element as it is added. Focus on how it all works
together.
- It would be userful to also show a PCI-to-PCI bridge, and maybe a
fixed PCI device as children of the host bridge node.
- The current PCI nodes on all powerpc boards depend on a device_type
=3D "PCI" property, but I'd like to look at moving away from that for
new PCI controllers (device_type describes facilities in real open
firmware. It shouldn't have any meaning in the flattened device
tree). I need to look into the details though to see if it is
feasible or not.
- Describing the interrupt-map property will be particularly fiddly.
It could have a section all to itself before you even get to talking
about PCI irq swizzling.
Thanks again for the help!
g.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Grant Likely @ 2010-06-14 5:40 UTC (permalink / raw)
To: Jeremy Kerr
Cc: linuxppc-dev, devicetree-discuss, Olof Johansson,
microblaze-uclinux
In-Reply-To: <201006132112.36728.jeremy.kerr@canonical.com>
On Sun, Jun 13, 2010 at 7:12 AM, Jeremy Kerr <jeremy.kerr@canonical.com> wrote:
> hi Ben,
>
>> Maybe a paragraph on the new proposed clock binding that Jeremy is
>> working would be of use btw.
>
> Here's one I prepared earlier:
>
> http://devicetree.org/ClockBindings
Yup, but the documents have difference purposes. ClockBindings is the
formal description. Device_Tree_Usage leads someone step by step how
everything actually fits together. I think it would be useful to add
a clock binding section, especially with how important it is shaping
up to be for the ARM SoC work we're doing.
g.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Grant Likely @ 2010-06-14 5:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, microblaze-uclinux, devicetree-discuss,
Nicolas Pitre, Olof Johansson, Mitch Bradley, Dan Malek,
Jeremy Kerr, linux-arm-kernel
In-Reply-To: <1276417792.1962.731.camel@pasglop>
On Sun, Jun 13, 2010 at 2:29 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Sat, 2010-06-12 at 20:45 -1000, Mitch Bradley wrote:
>
>> Either fought or embraced. =A0To the extent that it is possible to focus
>> solely on Linux and ARM, one could image doing a good HAL.
>
> That will come with a huge amount of comunity resistance sadly, but I
> can imagine distros liking it.
>
> In general, I much prefer having all the necessary native drivers in the
> kernel, and the device-tree to provide the right representation, and
> avoid trying to abstract "methods" via a HAL. It's the Linux philosophy
> as much as possible (even when defeated by ACPI).
>
> But if we're going to be forced by vendors into HALs, we can also make
> sure that whatever they come up with is half reasonable :-)
I think there is more to be concerned about regarding binary blobs
than HALs. Many of the new SoCs require closed binaries to use all
the hardware right now (graphics cores in particular).
Board vendors seem to be taking the plunge and modifying the kernel
rather than trying to create a HAL for driving board specific
features.
>> (The reason I say ARM-only is =A0because the
>> only other non-x86 architecture that has any "legs" left is PowerPC, and
>> PPC already has a coherent story.)
>
> Well, ppc story isn't that coherent as far as this goes :-) We don't
> keep OF alive, we have RTAS which is a pile of poo... etc...
>
> But yeah, we are fine without a HAL, so if we stick to OF as a
> bootloader and provider of the device-tree, we are fine.
>
>> > To some extent, in fact, doing that sort of stuff in OF or even in RTA=
S
>> > 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 interpreter that can live inside the OS. =A0It's
>> considerably simpler than the ACPI interpreter.
>
> That's the one thing I purposefully avoided mentioning :-)
>
> It's an interesting idea, I've though about it. If course, there's all
> sort of things to be careful about, such as who provides the f-code with
> virtual->physical mappings to devices, how they are represented, how
> much of the OF "forth" environment is accessible to such f-code, locking
> between f-code and kernel use of shared resources (especially true when
> dealing with things like i2c devices, plls, etc...).
>
> IE. THe base idea is simple. The implementation can be a huge can of
> worms.
>
> Cheers,
> Ben.
>
>> > =A0With 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.
>> >
>> >
>> >
>
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Grant Likely @ 2010-06-14 5:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, microblaze-uclinux, devicetree-discuss,
Nicolas Pitre, Olof Johansson, Mitch Bradley, Dan Malek,
Jeremy Kerr, linux-arm-kernel
In-Reply-To: <1276408773.1962.574.camel@pasglop>
[cc'ing linux-arm-kernel]
On Sat, Jun 12, 2010 at 11:59 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> 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.
>
> 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.
This sounds reasonable to me.
>> 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. =A0Maybe 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 ?
cc'ing linux-arm-kernel in all my replies
>> Also, for debugging, OFW typically needs access to a UART. =A0If the OS =
is
>> using the UART, it's often possible for OFW to use it just by turning of=
f 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.
With a stout 2x4 if needed. I'm going to try very hard to dissuade
this. Yet another reason why I only what one method for passing the
device tree into the kernel.
> 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.
Unfortunately, on the newer ARM SoCs, binary blobs are all over the
place anyway. :-(
g.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Grant Likely @ 2010-06-14 5:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, microblaze-uclinux, devicetree-discuss,
Nicolas Pitre, Olof Johansson, Mitch Bradley, Dan Malek,
Jeremy Kerr, linux-arm-kernel
In-Reply-To: <1276408087.1962.552.camel@pasglop>
On Sat, Jun 12, 2010 at 11:48 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Sat, 2010-06-12 at 23:07 -0600, Grant Likely wrote:
>>
>> What is needed to keep OFW alive? =A0I'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.
I don't think I want to do the same on ARM. I'd rather have the
prom_init stuff in a boot wrapper, or have OFW itself generate the
flat representation before booting the kernel. I'm trying to
constrain the number of things that could go wrong by defining only
one way for getting the device tree data into the kernel.
> 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? =A0I 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. =A0(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.
Right. We don't need to use OFW/RTAS to handle this use case.
g.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Grant Likely @ 2010-06-14 5:02 UTC (permalink / raw)
To: Mitch Bradley
Cc: Nicolas Pitre, devicetree-discuss, linuxppc-dev,
microblaze-uclinux, Olof Johansson, Dan Malek, Jeremy Kerr,
linux-arm-kernel
In-Reply-To: <4C146F18.9030008@firmworks.com>
[cc'ing linux-arm-kernel because we're discussing ARM issues]
On Sat, Jun 12, 2010 at 11:39 PM, Mitch Bradley <wmb@firmworks.com> wrote:
> Grant Likely wrote:
>>
>> On Sat, Jun 12, 2010 at 4:52 PM, Benjamin Herrenschmidt
>> <benh@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. =A0On the x86 OLPC machi=
nes,
>>>> the ability to
>>>> dive into OFW via a SysRq key combo was very helpful for debugging som=
e
>>>> difficult
>>>> problems. =A0The 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? =A0I'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. =A0O=
FW on
> ARM
> is position-independent, so it can be tucked up at the top of memory fair=
ly
> 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=
.
> =A0Maybe next week...
Remapping the MMU could be hairy, but I see no issue with marking
OFW's memory as reserved. How does OFW currently tell the OS what
memory it should not touch because OFW is using it? Is it device tree
data or another mechanism?
> Also, for debugging, OFW typically needs access to a UART. =A0If the OS i=
s
> using the UART,
> it's often possible for OFW to use it just by turning off interrupts and
> polling the UART.
This doesn't sound onerous.
>> 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. =A0The OS didn't have to know the storage layout nor the hardwa=
re
> details of the storage device. =A0Convenient, but not hugely important.
I think the assumption can be made that this will not be a use case on ARM.
>> =A0I 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. =A0If the OS doesn't trust the
> firmware, there is no pressure for the firmware to "get it right".
Firmware will not get it right. Period. There will always be
something wrong. It is never right on PCs. It will never be right on
the other architectures. That goes for OSes too, but upgrading an OS
isn't as risky as upgrading firmware. That isn't to say that it can't
be close, but every firmware feature that the OS depends on is a
feature that could force a risky firmware upgrade when the bug in it
is discovered.
I'm also convinced that the economics are all wrong for "getting it
right" when talking about firmware. Manufactures don't care about
firmware; they care about selling boxes. Customers don't care about
firmware, they care about the operating system (well, that's not true
either, they care about applications). For manufactures, once it can
boot the real operating system, there is little to no incentive to
spend any more money on firmware when the money can be better spent on
either the next product or the adding features to the operating system
of the existing product. In fact, spending money on firmware is
actually *more risky* one a product ships, because if a firmware
upgrade goes bad, then that means product returned for repair at the
factory.
For me, this leads to two conclusions;
- That the OS should have little to no dependencies on the firmware
after it is booted so that bug fixes remain entirely in the realm of
the operating system.
- That the description of the hardware (ie Device Tree or ACPI) should
be decoupled enough from firmware that bugs in the data do not force a
firmware upgrade. The data must always be updatabie. Even if
configuration or data is completely corrupt, it must still be simple
to recover.
Note: I'm not critiquing OFW on either of these points. These are
just some of my base requirements when I approach system design.
> 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. =A0Microsoft did a thorough job of creating certification tests an=
d
> enforcing their use. =A0I'm not praising ACPI, just pointing out the dyna=
mics
> that result from assignment of responsibility.
Yet how many boards are shipped with broken ACPI tables? Just
bringing up ACPI in the presence of a kernel developer seems to bring
about the onset of Tourette's. Bios provides enough data to be able
to boot the operating system, but in my experience it still requires
extra drivers to be added after installation for everything to work
right.
OTOH, I'm not had to deal with ACPI personally, so I may also be
talking out of my backside on this point. :-)
> That said, I'm not interested in pushing the issue. =A0It's okay with me =
if
> the device tree is static as far as the kernel is concerned, and callback=
s
> to OFW are only used for debugging purposes.
The current intent is to only accept the flat tree representation when
booting the kernel. So we'll need to encode the callback pointer into
the tree somewhere.
Cheers,
g.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Jeremy Kerr @ 2010-06-13 13:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: microblaze-uclinux, devicetree-discuss, Olof Johansson,
linuxppc-dev
In-Reply-To: <1276312071.1962.175.camel@pasglop>
hi Ben,
> Maybe a paragraph on the new proposed clock binding that Jeremy is
> working would be of use btw.
Here's one I prepared earlier:
http://devicetree.org/ClockBindings
:)
Cheers,
Jeremy
^ permalink raw reply
* Re: Request review of device tree documentation
From: Benjamin Herrenschmidt @ 2010-06-13 8:57 UTC (permalink / raw)
To: Mitch Bradley
Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev,
Olof Johansson, Dan Malek, Jeremy Kerr
In-Reply-To: <4C147EA5.3060500@firmworks.com>
On Sat, 2010-06-12 at 20:45 -1000, Mitch Bradley wrote:
> > 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?
Forgot to reply to that one ... I'd say
linux-arm-kernel@lists.infradead.org
For now. If the discussion starts taking too much bandwidth, it might be
worth creating a special list for ARM device-tree / OF.
Cheers,
Ben.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Benjamin Herrenschmidt @ 2010-06-13 8:29 UTC (permalink / raw)
To: Mitch Bradley
Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev,
Olof Johansson, Dan Malek, Jeremy Kerr
In-Reply-To: <4C147EA5.3060500@firmworks.com>
On Sat, 2010-06-12 at 20:45 -1000, Mitch Bradley wrote:
> 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.
That will come with a huge amount of comunity resistance sadly, but I
can imagine distros liking it.
In general, I much prefer having all the necessary native drivers in the
kernel, and the device-tree to provide the right representation, and
avoid trying to abstract "methods" via a HAL. It's the Linux philosophy
as much as possible (even when defeated by ACPI).
But if we're going to be forced by vendors into HALs, we can also make
sure that whatever they come up with is half reasonable :-)
> (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.)
Well, ppc story isn't that coherent as far as this goes :-) We don't
keep OF alive, we have RTAS which is a pile of poo... etc...
But yeah, we are fine without a HAL, so if we stick to OF as a
bootloader and provider of the device-tree, we are fine.
> > 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 interpreter that can live inside the OS. It's
> considerably simpler than the ACPI interpreter.
That's the one thing I purposefully avoided mentioning :-)
It's an interesting idea, I've though about it. If course, there's all
sort of things to be careful about, such as who provides the f-code with
virtual->physical mappings to devices, how they are represented, how
much of the OF "forth" environment is accessible to such f-code, locking
between f-code and kernel use of shared resources (especially true when
dealing with things like i2c devices, plls, etc...).
IE. THe base idea is simple. The implementation can be a huge can of
worms.
Cheers,
Ben.
> > 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.
> >
> >
> >
^ permalink raw reply
* Re: [PATCH] device-tree: Drop properties with "/" in their name
From: Michael Ellerman @ 2010-06-13 8:15 UTC (permalink / raw)
To: Christian Kujau; +Cc: monstr, LKML, linuxppc-dev, microblaze-uclinux
In-Reply-To: <alpine.DEB.2.01.1006130045230.3964@bogon.housecafe.de>
[-- Attachment #1: Type: text/plain, Size: 1612 bytes --]
On Sun, 2010-06-13 at 00:47 -0700, Christian Kujau wrote:
> On Wed, 19 May 2010 at 22:32, Michael Ellerman wrote:
> > Some bogus firmwares include properties with "/" in their name. This
> > causes problems when creating the /proc/device-tree file system,
> > because the slash is taken to indicate a directory.
> >
> > We don't care about those properties, and we don't want to encourage
> > them, so just throw them away when creating /proc/device-tree.
> >
> > Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> > ---
> >
> > Hi Christian, if you could test this new patch that'd be great, thanks!
>
> I've tested the patch, the Badness is gone and the system is stable as
> ever. Will this be pushed to 2.6.35?
Hopefully yes :)
Looks like Ben has deferred it to Grant in patchwork, and he is pretty
busy I think with other OF patches ATM. Maybe he'll grab it or Ben can
pick it up .. guys ? :)
http://patchwork.ozlabs.org/patch/52978/
cheers
> > fs/proc/proc_devtree.c | 3 +++
> > 1 files changed, 3 insertions(+), 0 deletions(-)
> >
> > diff --git a/fs/proc/proc_devtree.c b/fs/proc/proc_devtree.c
> > index ce94801..d9396a4 100644
> > --- a/fs/proc/proc_devtree.c
> > +++ b/fs/proc/proc_devtree.c
> > @@ -209,6 +209,9 @@ void proc_device_tree_add_node(struct device_node *np,
> > for (pp = np->properties; pp != NULL; pp = pp->next) {
> > p = pp->name;
> >
> > + if (strchr(p, '/'))
> > + continue;
> > +
> > if (duplicate_name(de, p))
> > p = fixup_name(np, de, p);
> >
> > --
> > 1.7.0.4
> >
> >
> >
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] device-tree: Drop properties with "/" in their name
From: Christian Kujau @ 2010-06-13 7:47 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, monstr, LKML, microblaze-uclinux
In-Reply-To: <0958c243b32f5f77028a794a9ce0d55f9a12121e.1274272289.git.michael@ellerman.id.au>
On Wed, 19 May 2010 at 22:32, Michael Ellerman wrote:
> Some bogus firmwares include properties with "/" in their name. This
> causes problems when creating the /proc/device-tree file system,
> because the slash is taken to indicate a directory.
>
> We don't care about those properties, and we don't want to encourage
> them, so just throw them away when creating /proc/device-tree.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> ---
>
> Hi Christian, if you could test this new patch that'd be great, thanks!
I've tested the patch, the Badness is gone and the system is stable as
ever. Will this be pushed to 2.6.35?
Thanks,
Christian.
> fs/proc/proc_devtree.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/fs/proc/proc_devtree.c b/fs/proc/proc_devtree.c
> index ce94801..d9396a4 100644
> --- a/fs/proc/proc_devtree.c
> +++ b/fs/proc/proc_devtree.c
> @@ -209,6 +209,9 @@ void proc_device_tree_add_node(struct device_node *np,
> for (pp = np->properties; pp != NULL; pp = pp->next) {
> p = pp->name;
>
> + if (strchr(p, '/'))
> + continue;
> +
> if (duplicate_name(de, p))
> p = fixup_name(np, de, p);
>
> --
> 1.7.0.4
>
>
>
--
BOFH excuse #334:
50% of the manual is in .pdf readme files
^ permalink raw reply
* Re: Anyone using "PowerPC" little-endian mode?
From: Brad Boyer @ 2010-06-13 6:37 UTC (permalink / raw)
To: Gary Thomas; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <4C079F1D.7000707@mlbassoc.com>
On Thu, Jun 03, 2010 at 06:25:01AM -0600, Gary Thomas wrote:
> I don't know about today, but my recollection is that the only
> use of little-endian mode on PowerPC was during the early days
> attempt to run Windows-NT.
You could potentially hit this case by running Mac on Linux. A handful
of Mac programs (like early versions of VirtualPC) used this mode. Any
that did had to get fixed to run on a PowerMac G5, obviously. I haven't
personally tried this, and I wouldn't be shocked to find that MoL
chokes on this case for some other reason.
I do know that VirtualPC did this because it was G3/G4 only for a while
until they rewrote it to not use the little-endian mode.
Brad Boyer
flar@allandria.com
^ permalink raw reply
* Re: [microblaze-uclinux] Re: Request review of device tree documentation
From: Edgar E. Iglesias @ 2010-06-13 6:47 UTC (permalink / raw)
To: microblaze-uclinux
Cc: linuxppc-dev, devicetree-discuss, Mitch Bradley, Olof Johansson,
Dan Malek, Jeremy Kerr
In-Reply-To: <AANLkTimgvKoCBOkhVeLX-uHtRzFPMWpVtZNipKvekOJv@mail.gmail.com>
On Sat, Jun 12, 2010 at 05:09:36PM -0600, Grant Likely wrote:
> On Sat, Jun 12, 2010 at 4:15 PM, Olof Johansson <olof@lixom.net> 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
^ permalink raw reply
* Re: Request review of device tree documentation
From: Mitch Bradley @ 2010-06-13 6:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev,
Olof Johansson, Dan Malek, Jeremy Kerr
In-Reply-To: <1276408773.1962.574.camel@pasglop>
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 interpreter that can live inside the OS. It's
considerably simpler than
the ACPI interpreter.
> 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.
>
>
>
^ permalink raw reply
* Re: Request review of device tree documentation
From: Benjamin Herrenschmidt @ 2010-06-13 5:59 UTC (permalink / raw)
To: Mitch Bradley
Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev,
Olof Johansson, Dan Malek, Jeremy Kerr
In-Reply-To: <4C146F18.9030008@firmworks.com>
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.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Benjamin Herrenschmidt @ 2010-06-13 5:48 UTC (permalink / raw)
To: Grant Likely
Cc: linuxppc-dev, microblaze-uclinux, devicetree-discuss,
Olof Johansson, Mitch Bradley, Dan Malek, Jeremy Kerr
In-Reply-To: <AANLkTimRV8u3gDNCAIlROJoPcKs7jFwj2na3ZDFOg3O0@mail.gmail.com>
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.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Mitch Bradley @ 2010-06-13 5:39 UTC (permalink / raw)
To: Grant Likely
Cc: devicetree-discuss, linuxppc-dev, microblaze-uclinux,
Olof Johansson, Dan Malek, Jeremy Kerr
In-Reply-To: <AANLkTimRV8u3gDNCAIlROJoPcKs7jFwj2na3ZDFOg3O0@mail.gmail.com>
Grant Likely wrote:
> On Sat, Jun 12, 2010 at 4:52 PM, Benjamin Herrenschmidt
> <benh@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.
>
>
^ permalink raw reply
* Re: Request review of device tree documentation
From: Grant Likely @ 2010-06-13 5:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, microblaze-uclinux, devicetree-discuss,
Olof Johansson, Mitch Bradley, Dan Malek, Jeremy Kerr
In-Reply-To: <1276383132.1962.195.camel@pasglop>
On Sat, Jun 12, 2010 at 4:52 PM, Benjamin Herrenschmidt
<benh@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. =A0On the x86 OLPC machine=
s,
>> the ability to
>> dive into OFW via a SysRq key combo was very helpful for debugging some
>> difficult
>> problems. =A0The 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.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox