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 stat
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
> 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 wh
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 of
> @ 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 pathn
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 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 misunderstand
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
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 reasonab
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
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-vendo
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";
> > > > mainboard-name = "QEMU
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
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.
>
>
> > constr
On Tue, Feb 12, 2008 at 06:17:57AM -0800, ron minnich wrote:
> let's get the dts right before I submit any more code. I want us
> all to be happy with this.
Cool.
> Let's start with this dts:
> /{
> mainboard-vendor = "Emulation";
> mainboard-name = "QEMU x86";
> enabled;
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 PROT
On Mon, Feb 11, 2008 at 08:03:11PM -0800, ron minnich wrote:
> So, instead of what we had before, a pathname property in
> a node, e.g.
> pcipath = "0xf, 1";
> Now you label the node with the path, e.g.
> [EMAIL PROTECTED],1
>
> This results in a far cleaner and simpler dts.
I still think it is
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 mis
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
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
>
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 pa
On 11.02.2008 14:05, ron minnich wrote:
> 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
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.
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 the PCI ids then.
//Peter
--
coreboot mailing list
corebo
On Feb 10, 2008 12:08 PM, Peter Stuge <[EMAIL PROTECTED]> 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.
The current ID system, for all its flaws, does this job very well.
ron
--
coreboo
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 adop
On Feb 10, 2008 8:42 AM, Peter Stuge <[EMAIL PROTECTED]> wrote:
> What would such a global identifier be used for? One way to identify
> something is by position in the dt, but you're asking for a new
> "namespace" right?
You have found a type of a thing (e.g. southbridge) and you want to
find t
On Sun, Feb 10, 2008 at 08:35:18AM -0800, ron minnich wrote:
> > Ron suggested to make this [EMAIL PROTECTED] { ... } and [EMAIL
> > PROTECTED],0,0 { ... }
> >
> > I like that idea a lot.
Are there enough common cases to make @ optional?
For superio it's required.
For cpu and apic on LX boards
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,
Peter Stuge wrote:
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.
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 does
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 w
On Sat, Feb 09, 2008 at 11:03:47AM -0800, ron minnich wrote:
> How should this really be done? I'd be happier (much) if we could
> just say "path" in any given node and somehow have Magic
> figure out what the path type was. This is really easy to fix
> as soon as some smart person figures it out,
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 support
35 matches
Mail list logo
