@ in this case seperates the type of resources (pci) from the instance
of it (device, function).
So @ is a seperator. Using _ will add ambiguity as it is NOT a
seperator. same problem for -.
Stepan, will the OFW guys kill us if we allow ':' as well as @.
The general syntax of a pathname
Segher Boessenkool wrote:
@ in this case seperates the type of resources (pci) from the instance
of it (device, function).
So @ is a seperator. Using _ will add ambiguity as it is NOT a
seperator. same problem for -.
Stepan, will the OFW guys kill us if we allow ':' as well as @.
We are
We are of course free to go away from the ePAPR flat device tree (we
did already to some extent).
I am not talking about the ePAPR flat tree. I am talking about the
flat tree as used in PowerPC Linux for many years now.
I agree with Segher we should stay close to the original. That's why
Thanks for the notes. We did in the end resolve in favor of '@'.
ron
On Thu, Feb 14, 2008 at 2:01 PM, Segher Boessenkool
[EMAIL PROTECTED] wrote:
We are of course free to go away from the ePAPR flat device tree (we
did already to some extent).
I am not talking about the ePAPR flat tree.
On Thu, Feb 14, 2008 at 07:12:54PM +0100, Segher Boessenkool wrote:
The general syntax of a pathname component in OF is:
[EMAIL PROTECTED]:args
Thanks for the insight!
unit-addr is (the text representation of) the address for the
node, in the parent's address space.
This statement
On 13.02.2008 18:18, ron minnich wrote:
On Feb 13, 2008 9:17 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
In that case I'd retract my opposition to @, but only if the v3 design
doc gets an additional paragraph specifying the syntax with a hint to
potential misunderstandings with
On 13.02.2008 18:11, ron minnich wrote:
On Feb 13, 2008 9:05 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
Alternatives are - (used by memreserve and inside names) or : (used
by memreg) or _ (used inside names). I hope at least one of them is
considered as reasonable alternative.
On Feb 13, 2008 9:05 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
Alternatives are - (used by memreserve and inside names) or : (used
by memreg) or _ (used inside names). I hope at least one of them is
considered as reasonable alternative.
@ in this case seperates the type of resources
On 13.02.2008 04:58, ron minnich wrote:
On Feb 12, 2008 3:02 PM, Corey Osgood [EMAIL PROTECTED] wrote:
On Feb 12, 2008 3:15 PM, ron minnich [EMAIL PROTECTED] wrote:
On Feb 12, 2008 11:13 AM, Peter Stuge [EMAIL PROTECTED] wrote:
mainboard-vendor = Emulation;
On Feb 13, 2008 9:17 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
In that case I'd retract my opposition to @, but only if the v3 design
doc gets an additional paragraph specifying the syntax with a hint to
potential misunderstandings with @.
OK, I'll wait on an ack and commit and
Committed revision 593.
I want to once again thank you all for your thoughtful comments.
ron
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Feb 12, 2008 11:13 AM, Peter Stuge [EMAIL PROTECTED] wrote:
mainboard-vendor = Emulation;
mainboard-name = QEMU x86;
enabled;
Again, is this enabled still needed?
no, it is the default, I keep forgetting to yank it. Fixed.
constructor =
On Feb 12, 2008 3:15 PM, ron minnich [EMAIL PROTECTED] wrote:
On Feb 12, 2008 11:13 AM, Peter Stuge [EMAIL PROTECTED] wrote:
mainboard-vendor = Emulation;
mainboard-name = QEMU x86;
Can we possibly pull this info (or defaults for this info) from Kconfig?
let's get the dts right before I submit any more code. I want us all
to be happy with this.
Let's start with this dts:
/{
mainboard-vendor = Emulation;
mainboard-name = QEMU x86;
enabled;
constructor = qemuvga_constructors;
cpus {};
[EMAIL
On Feb 11, 2008 5:46 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
How do you handle the case where two identical PCI devices need
different settings?
That's actually very easy. The patch differentiates each device, while
the id identifies what kind of device they are.
I have the patch
here is the proposed patch.
Comments welcome.
ron
Implement new path syntax for the dts.
The old syntax, where we had special property names for paths, is deprecated (well, removed, actually).
So, instead of what we had before, a pathname property in
a node, e.g.
pcipath = 0xf, 1;
Now you
On 12.02.2008 01:14, ron minnich wrote:
On Feb 11, 2008 4:00 PM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
I like the new structure, but there is one thing that irritates me to no
end: @
When I first read the dts without the accompanying discussion, I
completely misunderstood the
On Feb 11, 2008 4:00 PM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
I like the new structure, but there is one thing that irritates me to no
end: @
When I first read the dts without the accompanying discussion, I
completely misunderstood the structure because of the @. I thought the
@
On 11.02.2008 22:26, ron minnich wrote:
On Feb 11, 2008 5:46 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
How do you handle the case where two identical PCI devices need
different settings?
That's actually very easy. The patch differentiates each device, while
the id
On Feb 10, 2008 9:32 PM, Peter Stuge [EMAIL PROTECTED] wrote:
On Sun, Feb 10, 2008 at 01:35:01PM -0800, ron minnich wrote:
southbridge/intel/i82371eb
That doesn't help. PCI gives you two 16-bit numbers. From those two
16-bit numbers, you have to find a constructor.
Doh. We have to use
On Sat, Feb 09, 2008 at 09:35:49PM -0800, ron minnich wrote:
It should be simple enough to get the type if struct property had
a struct node *node; member so that the owner-parent node could
be reached from within the property foreach loop.
it's there.
Hmm. How?
but that doesn't
On Feb 10, 2008 8:27 AM, Stefan Reinauer [EMAIL PROTECTED] wrote:
Ron suggested to make this [EMAIL PROTECTED] { ... } and [EMAIL
PROTECTED],0,0 { ... }
I like that idea a lot.
I think that would be the way to go.. It means we can not call the apic
node my_weird_apic anymore, which is an
On Sun, Feb 10, 2008 at 10:17:01AM -0800, ron minnich wrote:
What would such a global identifier be used for?
You have found a type of a thing (e.g. southbridge) and you want
to find the operations for that thing. You need an ID to do that.
Ah! Of course.
One option is we just adopt a
This patch adds more path support to coreboot and to the dtc.
This support in turn reduces annoying warning messages as coreboot comes up.
ron
These changes extend support for paths for devices.
path.h: add superio path
alix1c/dts: add paths for each component.
device/device_util.c: add
On Feb 9, 2008 9:21 PM, Peter Stuge [EMAIL PROTECTED] wrote:
It should be simple enough to get the type if struct property had
a struct node *node; member so that the owner-parent node could
be reached from within the property foreach loop.
it's there. but that doesn't totally tell you what
25 matches
Mail list logo
