On 1/11/07, Segher Boessenkool <[EMAIL PROTECTED]> wrote:
Depends. The kernel _can_ shut down OF; in that case, it
becomes responsible for passing the device tree along to
the kexec'd kernel.
so we will need the non-callback support anyway, it seems?
thanks
ron
-
To unsubscribe from this l
On 1/11/07, Stefan Reinauer <[EMAIL PROTECTED]> wrote:
This works fine for just passing the device tree, but it will fail for
the next step of being able to use the firmware in the OS, and returning
sanely to the firmware.
And why is it we need to do that, presently? And how, in a virtualized
I'd like to put in my $.02 in favor of having a way to pass the OF
device tree to the kernel, in much the same way we pass stuff like
ACPI and PIRQ and MP tables now.
This works fine for just passing the device tree, but it will fail for
the next step of being able to use the firmware in the OS,
Segher has a modification to the devtree patch that creates a lower
level ops vector that can be implemented with callback or
non-callback.
It is still being tested.
It currently only hooks up OLPC, and I don't have any of
those [hint hint], so I need external testers. I'll send
the patch to
* ron minnich <[EMAIL PROTECTED]> [070111 18:39]:
> I'd like to put in my $.02 in favor of having a way to pass the OF
> device tree to the kernel, in much the same way we pass stuff like
> ACPI and PIRQ and MP tables now.
This works fine for just passing the device tree, but it will fail for
the
On 1/11/07, Mitch Bradley <[EMAIL PROTECTED]> wrote:
Segher has a modification to the devtree patch that creates a lower
level ops vector that can be implemented with callback or non-callback.
It is still being tested.
Wonderful! If the non-callback version works out, then we can greatly
widen
Segher has a modification to the devtree patch that creates a lower
level ops vector that can be implemented with callback or non-callback.
It is still being tested.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Mitch Bradley wrote:
Request for comments.
Sorry to revive this thread, I just ran through the discussion. I'm
about 50% in agreement with the idea.
I'd like to put in my $.02 in favor of having a way to pass the OF
device tree to the kernel, in much the same way we pass stuff like
ACPI and PI
From: Segher Boessenkool <[EMAIL PROTECTED]>
Date: Wed, 3 Jan 2007 16:23:53 +0100
> >>> therefore you can't let multiple CPUs call
> >>> into OFW at one time. You must use some kind of locking mechanism,
> >>> and that locking mechanism is not simple because it has to not just
> >>> stop the othe
In fact, the 'ok' prompt is an ENORMOUS pain in the ass to support
on machines with USB keyboards, because sharing the USB host
controller is beyond non-trivial. I've never implemented support
for that on sparc64 and I frankly have no desire to do the work
necessary to support that. It simply is
Kill OF? sparc does not want that IMO, how else should I return to
the 'ok' prompt?
PowerPC kills OF because it really has to,
No it doesn't. It has to on some (very common, heh) subarchs.
that's one of numerous
reasons that it started sucking the device tree into a kernel copy
early in the
therefore you can't let multiple CPUs call
into OFW at one time. You must use some kind of locking mechanism,
and that locking mechanism is not simple because it has to not just
stop the other cpus, it has to be able to stop the other cpus yet
still allow them to receive SMP cross-calls from the
> In fact, the 'ok' prompt is an ENORMOUS pain in the ass to support
> on machines with USB keyboards, because sharing the USB host
> controller is beyond non-trivial. I've never implemented support
> for that on sparc64 and I frankly have no desire to do the work
> necessary to support that. It
From: Jan Engelhardt <[EMAIL PROTECTED]>
Date: Wed, 3 Jan 2007 02:13:39 +0100 (MET)
>
> On Jan 3 2007 01:52, Segher Boessenkool wrote:
> >> > Leaving aside the issue of in-memory or not, I don't think
> >> > it is realistic to think any completely common implementation
> >> > will work for this -
From: Segher Boessenkool <[EMAIL PROTECTED]>
Date: Wed, 3 Jan 2007 02:14:34 +0100
> [snipping a bit for now]
>
> > and then, "fix"
> > that so that it works on x86 :-)
>
> That works, if the goal is to just add x86/OLPC to the list of
> platforms that have a device tree fs. I thought the plan w
From: Segher Boessenkool <[EMAIL PROTECTED]>
Date: Wed, 3 Jan 2007 01:52:06 +0100
> >> Leaving aside the issue of in-memory or not, I don't think
> >> it is realistic to think any completely common implementation
> >> will work for this -- it might for current SPARC+PowerPC+OLPC,
> >> but more stu
From: Segher Boessenkool <[EMAIL PROTECTED]>
Date: Wed, 3 Jan 2007 01:48:02 +0100
> > therefore you can't let multiple CPUs call
> > into OFW at one time. You must use some kind of locking mechanism,
> > and that locking mechanism is not simple because it has to not just
> > stop the other cpus,
On Jan 3 2007 01:52, Segher Boessenkool wrote:
>> > Leaving aside the issue of in-memory or not, I don't think
>> > it is realistic to think any completely common implementation
>> > will work for this -- it might for current SPARC+PowerPC+OLPC,
>> > but more stuff will be added over time...
>>
>
[snipping a bit for now]
It's easier to start merging powerpc and sparc I reckon
Well it won't hurt to merge and clean up these two first, sure.
and then, "fix"
that so that it works on x86 :-)
That works, if the goal is to just add x86/OLPC to the list of
platforms that have a device tree
Leaving aside the issue of in-memory or not, I don't think
it is realistic to think any completely common implementation
will work for this -- it might for current SPARC+PowerPC+OLPC,
but more stuff will be added over time...
I see nothing supporting this IMHO bogus claim.
Please keep in mind
Not single thread -- but a "global OF lock" yes. Not that
it matters too much, (almost) all property accesses are init
time anyway (which is effectively single threaded).
Not that true anymore. A lot of driver probe is being threaded
nowadays,
either bcs of the new multithread probing bits, or
> The biggest problem is the huge collection of workarounds we have
> for PowerPC alone already -- if that can be moved into some
> quirk collection thing, where certain quirks are only run on some
> systems, it might scale.
Well, if you notice, I've been moving most of such workarounds to
prom_i
Leaving aside the issue of in-memory or not, I don't think
it is realistic to think any completely common implementation
will work for this -- it might for current SPARC+PowerPC+OLPC,
but more stuff will be added over time...
And ? I don't see why a mostly common implementations wouldn't work,
p
From: Segher Boessenkool <[EMAIL PROTECTED]>
Date: Tue, 2 Jan 2007 22:40:17 +0100
> >> The kernel doesn't care if one CPU is in OF land while the others
> >> are doing other stuff -- well you have to make sure the OF won't
> >> try to use a hardware device at the same time as the kernel, true.
> >
From: Segher Boessenkool <[EMAIL PROTECTED]>
Date: Tue, 2 Jan 2007 22:37:32 +0100
> Leaving aside the issue of in-memory or not, I don't think
> it is realistic to think any completely common implementation
> will work for this -- it might for current SPARC+PowerPC+OLPC,
> but more stuff will be a
From: Segher Boessenkool <[EMAIL PROTECTED]>
Date: Tue, 2 Jan 2007 22:28:21 +0100
> >> Not single thread -- but a "global OF lock" yes. Not that
> >> it matters too much, (almost) all property accesses are init
> >> time anyway (which is effectively single threaded).
> >
> > Not that true anymore
From: Segher Boessenkool <[EMAIL PROTECTED]>
Date: Tue, 2 Jan 2007 22:15:50 +0100
> We also can keep the old names as compatibility accessors for
> PowerPC only for a while, until everything is converted -- SPARC
> can do the same then. You can't really keep the old PowerPC names
> in kernel-wide
> All should converge on the same interface. That does not
> ab initio mean we should converge on what you currently
> have (although that might eventually be that case).
Well, Dave and I will happen to be in the same place in a few weeks for
LCA so we might spend some time having a look there i
The kernel doesn't care if one CPU is in OF land while the others
are doing other stuff -- well you have to make sure the OF won't
try to use a hardware device at the same time as the kernel, true.
That statement alone hides an absolute can of worms btw ;-)
Oh I know. With a sane OF implement
I do object basically to having something that doesn't also provide
in-kernel interfaces to access the device nodes & properties.
That's the wrong way around. Work is underway to instead
have the devicetreefs *use* the in-kernel interfaces. Would
that be acceptable?
I don't
agree with the re
> The kernel doesn't care if one CPU is in OF land while the others
> are doing other stuff -- well you have to make sure the OF won't
> try to use a hardware device at the same time as the kernel, true.
That statement alone hides an absolute can of worms btw ;-)
> I'm a bit concerned about the
Not single thread -- but a "global OF lock" yes. Not that
it matters too much, (almost) all property accesses are init
time anyway (which is effectively single threaded).
Not that true anymore. A lot of driver probe is being threaded
nowadays,
either bcs of the new multithread probing bits, o
Are you really suggesting that using a kernel copy of the
device tree is the correct thing to do, and the only correct
thing to do -- with the sole argument that "that's what the
current ports do"?
Well, there are reasons why that's what the current ports do :-)
Sure. It might have been a goo
On Tue, 2007-01-02 at 10:11 -1000, Mitch Bradley wrote:
>
> > We could of course have the interface work either on a copy of the tree
> > or on a real OF (though that means changing things like get_property on
> > powerpc and fixing the gazillions of users) but I tend to think that
> > working on
We could of course have the interface work either on a copy of the tree
or on a real OF (though that means changing things like get_property on
powerpc and fixing the gazillions of users) but I tend to think that
working on a copy always is more efficient.
The patch that I posted creates a
On Tue, 2007-01-02 at 13:22 +0100, Segher Boessenkool wrote:
> > Except that none of the powerpc platforms can keep OF alive after the
> > kernel has booted, which is why we do an in-memory copy of the tree.
>
> Adding that functionality hasn't gotten easier at all since
> we use the flattened tre
On Tue, 2007-01-02 at 12:37 +0100, Segher Boessenkool wrote:
> >> So please do this crap right.
> >
> > I strongly agree. Nowadays, both powerpc and sparc use an in-memory
> > copy
> > of the tree (wether you use the flattened format during the trampoline
> > from OF runtime to the kernel or not i
On Tue, 2007-01-02 at 12:45 +0100, Segher Boessenkool wrote:
> > In addition, I haven't given on the idea one day of actually merging
> > the
> > powerpc and sparc implementation of a lot of that stuff. Mostly the
> > device-tree accessors proper, the of_device/of_platform bits etc...
> > into
>
Benjamin Herrenschmidt wrote:
This is a trivial implementation that suits it's purpose.
It's simple. I'm not sure what more is needed for this
project when it's pretty clear that i386 will never need
any additional support for open firmware.
I don't agree. It's definitely not clear to me E
* Segher Boessenkool <[EMAIL PROTECTED]> [070102 12:37]:
> Are you really suggesting that using a kernel copy of the
> device tree is the correct thing to do, and the only correct
> thing to do -- with the sole argument that "that's what the
> current ports do"?
There might also be a speed advanta
Simple system tools should not need to interpret binary data in
order to provide access to simple structured data like this, that's
just stupid.
I would agree with you if the data was properly typed in the first
place
but it's not,
OF device tree properties are "properly typed" just fine --
IMHO, the directory entries in the filesystem
should be in the form "[EMAIL PROTECTED]" (eg: /[EMAIL PROTECTED],0,
"pci" is the node name, "@" is the separator character defined
by IEEE 1275, and "1f,0" is the unit-address,
which are always guaranteed to be unique.
They should be. The problem is
Except that none of the powerpc platforms can keep OF alive after the
kernel has booted, which is why we do an in-memory copy of the tree.
Adding that functionality hasn't gotten easier at all since
we use the flattened tree for everything, heh.
We have well defined interfaces to access that c
In addition, I haven't given on the idea one day of actually merging
the
powerpc and sparc implementation of a lot of that stuff. Mostly the
device-tree accessors proper, the of_device/of_platform bits etc...
into
something like drivers/of1394 maybe.
1394? :-)
Thus if i386 is going to have
So please do this crap right.
I strongly agree. Nowadays, both powerpc and sparc use an in-memory
copy
of the tree (wether you use the flattened format during the trampoline
from OF runtime to the kernel or not is a different matter, we created
that for the sake of kexec and embedded devices w
There is one big problem: text representation is useless
(to scripts etc.) unless it can be transformed back to binary;
i.e., it has to be possible to reliably detect _how_ some
property is represented into text, something that cannot be
done with how openpromfs handles it.
Text is text is text
It has proved a good idea in general as I can easily get an exact
device-tree dump from users by asking for a tarball of
/proc/device-tree
and in some case, the data in there -is- binary (For example, the EDID
properties for monitors left by video drivers, or things like that).
Yes and with o
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Tue, 02 Jan 2007 16:09:14 +1100
> Probably. The question now is that if we want to somewhat converge, what
> to do... either change sparc habits or change powerpc habits :-) I'll
> let that fight happen between you and paulus and watch while h
On Mon, 2007-01-01 at 21:01 -0800, David Miller wrote:
> From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> Date: Tue, 02 Jan 2007 15:57:05 +1100
>
> > I like being able to have a simple way (ie. tar /proc/device-tree) to
> > tell user to send me their DT and have in the end an exact binary
> > re
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Tue, 02 Jan 2007 15:57:05 +1100
> I like being able to have a simple way (ie. tar /proc/device-tree) to
> tell user to send me their DT and have in the end an exact binary
> representation so I can actually dig for problems, like a wrong phand
> I think there is high value in an OFW filesystem representation
> that gives you _EXACTLY_ what the OFW command line prompt does
> when you try to traverse the device tree from there, and that
> is what openpromfs tries to do.
Except that every OFW implementation I have here shows you different
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Tue, 02 Jan 2007 15:05:59 +1100
> It has proved a good idea in general as I can easily get an exact
> device-tree dump from users by asking for a tarball of /proc/device-tree
> and in some case, the data in there -is- binary (For example, the
> The filesystem bit is for groveling around and getting information
> from the shell prompt, or shell scripts. Text processing.
>
> If you want the binary bits, export it with something like
> /dev/openprom. We don't generally export binary representation
> files out of /proc or /sys, in fact
On Sun, 2006-12-31 at 19:37 -0800, David Kahn wrote:
> Folks,
>
> If we reused the current code in fs/proc/proc_devtree.c
> and re-wrote the underlying of_* routines for i386 only,
> (in the hope of removing the complexity not needed for
> this implementation) would that be an acceptable
> impleme
> This is a trivial implementation that suits it's purpose.
> It's simple. I'm not sure what more is needed for this
> project when it's pretty clear that i386 will never need
> any additional support for open firmware.
I don't agree. It's definitely not clear to me Especially as open
source
> The base interface function is callofw(), which is effectively identical
> to call_prom_ret() in arch/powerpc/kernel/prom_init.c . So it seems
> that PowerPC could use it. I suppose I could change the name of
> callofw() to call_prom_ret(), thus making the base interface identical
> to Po
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Tue, 02 Jan 2007 14:45:31 +1100
> In addition, I haven't given on the idea one day of actually merging the
> powerpc and sparc implementation of a lot of that stuff. Mostly the
> device-tree accessors proper, the of_device/of_platform bits etc
> I would strongly suggest looking at things like
> arch/{sparc,sparc64,powerpc}/kernel/prom.c and
> include/asm-{sparc,sparc64,powerpc}/prom.h and
> arch/{sparc,sparc64,powerpc}/kernel/of_device.c and
> include/asm-{sparc,sparc64,powerpc}/of_device.h
> since we've already invested a lot of though
> I'm incredibly surprised how much resistence there is from the
> i386 OFW folks to do this right. It would be like 80 lines of
> code to suck the device tree into kernel memory, or if they don't
> want to do that they can use inline function wrappers to provide
> the clean C-language interface
From: David Kahn <[EMAIL PROTECTED]>
Date: Mon, 01 Jan 2007 17:40:25 -0800
> If that doesn't fit the model of /sys or /proc,
> I suppose it could be done in a separate file
> system, but that's overkill, isn't it?
Or by a device driver, which is what OFW systems have
been doing for years, and we
From: Segher Boessenkool <[EMAIL PROTECTED]>
Date: Tue, 2 Jan 2007 00:52:36 +0100
> There is one big problem: text representation is useless
> (to scripts etc.) unless it can be transformed back to binary;
> i.e., it has to be possible to reliably detect _how_ some
> property is represented into t
David Miller wrote:
We have some extensive code in fs/openpromfs/inode.c that
determines whether a property is text or not. I can't
guarentee it works %100, but it's very context dependant
(only the driver "knows") but it works for all the cases
I've tried.
The problem with guessing, as you
If you *really* want (the option of) showing things as text
in the filesystem, you better make it so that there is a
one-to-one translation back to binary. For example, what
does this mean, is it a text string or two bytes:
01.02
Yes you as a user can guess, but scripts can't (reliably).
We h
From: Segher Boessenkool <[EMAIL PROTECTED]>
Date: Mon, 1 Jan 2007 18:48:33 +0100
> If you *really* want (the option of) showing things as text
> in the filesystem, you better make it so that there is a
> one-to-one translation back to binary. For example, what
> does this mean, is it a text stri
On Jan 1 2007 08:10, Mitch Bradley wrote:
>>
>> We don't generally export binary representation
>> files out of /proc or /sys, in fact this rule I believe is layed
>> our precisely somewhere at least in the sysfs case.
>>
> pci-sysfs exports PCI config space in binary.
cat /sys/bus/pci/devices/
David Miller wrote:
We don't generally export binary representation
files out of /proc or /sys, in fact this rule I believe is layed
our precisely somewhere at least in the sysfs case.
pci-sysfs exports PCI config space in binary.
-
To unsubscribe from this list: send the line "unsubscr
Not the same exact thing -- using a text representation for
the property contents is a very different thing (and completely
braindead).
The filesystem bit is for groveling around and getting information
from the shell prompt, or shell scripts. Text processing.
If you want the binary bits, expo
From: Segher Boessenkool <[EMAIL PROTECTED]>
Date: Mon, 1 Jan 2007 04:33:13 +0100
> >>> All we've done is created a trivial implementation for exporting
> >>> the device tree to userland that isn't burdened by the powerpc
> >>> and sparc legacy code that's in there now.
> >>
> >> So now we'll have
From: David Kahn <[EMAIL PROTECTED]>
Date: Sun, 31 Dec 2006 19:37:52 -0800
> IMHO, the directory entries in the filesystem
> should be in the form "[EMAIL PROTECTED]" (eg: /[EMAIL PROTECTED],0,
> "pci" is the node name, "@" is the separator character defined
> by IEEE 1275, and "1f,0" is the unit-
Some comments, mostly coding style:
- 0xb0 - 0x13f Free. Add more parameters here if you really need them.
+ 0xb0 16 bytes Open Firmware information (magic, version, callback,
idt)
Is there an OF ISA binding for x86 somewhere? And don't
point me to the source code, I'd like to see
I would not exactly call what we have for powerpc
"exporting the OFW device tree". I don't quite know
what it is, but it isn't as simple as exporting the
OFW device tree. I don't think we really wanted to
get into any of that here.
The Linux PowerPC port uses an OF-like device tree on
*every* pl
Folks,
If we reused the current code in fs/proc/proc_devtree.c
and re-wrote the underlying of_* routines for i386 only,
(in the hope of removing the complexity not needed for
this implementation) would that be an acceptable
implementation?
In other words, the of_* routines continue to define th
+A regular file in ofwfs contains the exact byte sequence that
+comprises the OFW property value. Properties are not reformatted
+into text form, so numeric property values appear as binary
+integers. While this is inconvenient for viewing, it is generally
+easier for programs that read property
All we've done is created a trivial implementation for exporting
the device tree to userland that isn't burdened by the powerpc
and sparc legacy code that's in there now.
So now we'll have _3_ different implementations of exporting
the OFW device tree via procfs. Your's, the proc_devtree
of pow
On Dec 31 2006 12:45, David Miller wrote:
>From: Jan Engelhardt <[EMAIL PROTECTED]>
>
>> BUT, the eeprom utility may be used to modify values, and if used, I
>> would like to see ofwfs show the updated value. openpromfs does it
>> today:
>>
>> 15:09 ares:/proc/openprom/options # cat oem-banner?
>
From: Christoph Hellwig <[EMAIL PROTECTED]>
Date: Sun, 31 Dec 2006 15:41:03 +
> On Sun, Dec 31, 2006 at 02:49:17AM -0800, David Miller wrote:
> > Am I the only person who sees something very wrong with this?
>
> No, I completely agree with you on this.
>
> If firmworks really wants to have a
From: Jan Engelhardt <[EMAIL PROTECTED]>
Date: Sun, 31 Dec 2006 15:12:26 +0100 (MET)
> BUT, the eeprom utility may be used to modify values, and if used, I
> would like to see ofwfs show the updated value. openpromfs does it
> today:
>
> 15:09 ares:/proc/openprom/options # cat oem-banner?
> false
I made all the changes Pekka suggested, except:
+ security = strncmp(propname, "security-", 9) == 0;
+ len = 0;
Redundant assignment, no?
+ if (!security)
+ (void)callofw("getproplen", 2, 1, node,
propname, &len);
That assig
On Sun, Dec 31, 2006 at 02:49:17AM -0800, David Miller wrote:
> From: David Kahn <[EMAIL PROTECTED]>
> Date: Sun, 31 Dec 2006 02:11:53 -0800
>
> > All we've done is created a trivial implementation for exporting
> > the device tree to userland that isn't burdened by the powerpc
> > and sparc legac
On Dec 30 2006 15:38, Mitch Bradley wrote:
>
> Request for comments.
>
> It is similar in some respect to fs/proc/proc_devtree.c , but does
> not use procfs, nor does it require an intermediate layer of code
> to create a flattened representation of the device tree.
NB: openpromfs does not use pr
On 12/31/06, Mitch Bradley <[EMAIL PROTECTED]> wrote:
diff --git a/arch/i386/kernel/ofw_fs.c b/arch/i386/kernel/ofw_fs.c
new file mode 100644
index 000..30ca359
--- /dev/null
+++ b/arch/i386/kernel/ofw_fs.c
@@ -0,0 +1,261 @@
+/* 1275 in little-endian ASCII (for IEEE 1275 - the Open Firmware S
Hi,
On Sunday 31 December 2006 11:49, David Miller wrote:
> From: David Kahn <[EMAIL PROTECTED]>
> Date: Sun, 31 Dec 2006 02:11:53 -0800
>
> > All we've done is created a trivial implementation for exporting
> > the device tree to userland that isn't burdened by the powerpc
> > and sparc legacy co
David Miller wrote:
From: David Kahn <[EMAIL PROTECTED]>
Date: Sun, 31 Dec 2006 02:11:53 -0800
All we've done is created a trivial implementation for exporting
the device tree to userland that isn't burdened by the powerpc
and sparc legacy code that's in there now.
So now we'll have _3_ dif
From: David Kahn <[EMAIL PROTECTED]>
Date: Sun, 31 Dec 2006 02:11:53 -0800
> All we've done is created a trivial implementation for exporting
> the device tree to userland that isn't burdened by the powerpc
> and sparc legacy code that's in there now.
So now we'll have _3_ different implementatio
Responding to two replies in one email ...
Mitch Bradley wrote:
David Miller wrote:
...
Can we please not have N different interfaces to the open-firmware
calls so that perhaps powerpc and Sparc have a chance of using this
code too?
David,
I helped Mitch do this "port", so I'd like to chi
From: Mitch Bradley <[EMAIL PROTECTED]>
Date: Sat, 30 Dec 2006 23:36:45 -1000
> The base interface function is callofw(), which is effectively identical
> to call_prom_ret() in arch/powerpc/kernel/prom_init.c . So it seems
> that PowerPC could use it. I suppose I could change the name of
> c
David Miller wrote:
...
Can we please not have N different interfaces to the open-firmware
calls so that perhaps powerpc and Sparc have a chance of using this
code too?
The base interface function is callofw(), which is effectively identical
to call_prom_ret() in arch/powerpc/kernel/prom_in
From: Mitch Bradley <[EMAIL PROTECTED]>
Date: Sat, 30 Dec 2006 15:38:46 -1000
> Request for comments.
>
> This patch creates a virtual filesystem that represents an Open Firmware
> device tree. It has been tested on an OLPC x86 system, but the code is
> not processor-specific (apart from its cur
Request for comments.
This patch creates a virtual filesystem that represents an Open Firmware
device tree. It has been tested on an OLPC x86 system, but the code is
not processor-specific (apart from its current location under arch/i386).
It requires an Open Firmware implementation that can st
89 matches
Mail list logo
