On Thu, Jun 07, 2007 at 07:34:17PM +0200, svn@openbios.org wrote:
+void ram_initialize(int controllers, void *ctrl);
I never got any comment on that void * - why was it memory controllers could not have a unified struct?
//Peter
On 6/7/07, Peter Stuge stuge-linuxbios@cdy.org wrote:
On Thu, Jun 07, 2007 at 07:34:17PM +0200, svn@openbios.org wrote:
+void ram_initialize(int controllers, void *ctrl);
I never got any comment on that void * - why was it memory controllers could not have a unified struct?
I will try to sum it up but ... there is no way to unify it, short form. I contains very chip-dependent stuff, ranging from the simple array of longs up to a very complex multi-channel, mult-i devfn, multi-address, etc. etc. mess.
There's no good way to do it that I can see.
ron
On Thu, Jun 07, 2007 at 10:45:30AM -0700, ron minnich wrote:
I will try to sum it up but ... there is no way to unify it, short form. I contains very chip-dependent stuff, ranging from the simple array of longs up to a very complex multi-channel, mult-i devfn, multi-address, etc. etc. mess.
There's no good way to do it that I can see.
How does everyone feel abot unions?
I'm fine with them but a bit annoyed that they need a name. :)
Is there already a generic struct for each MC or is there just the per-type struct?
Also, can there be more than one MC on a northbridge?
Sorry if this is confusing. I'm not sure I have my head around the struct layout in v2 or v3 - but I know I want it to be a nice tree in v3.
//Peter
* Peter Stuge stuge-linuxbios@cdy.org [070607 19:55]:
On Thu, Jun 07, 2007 at 10:45:30AM -0700, ron minnich wrote:
I will try to sum it up but ... there is no way to unify it, short form. I contains very chip-dependent stuff, ranging from the simple array of longs up to a very complex multi-channel, mult-i devfn, multi-address, etc. etc. mess.
There's no good way to do it that I can see.
How does everyone feel abot unions?
Bad. I dont think we need them. (Well if we did, it would be an idea)
People have been copying auto.c from K8 and modifying it. And if their mem controller was simple, the complicated parts were not always removed. So we ended up with something complex, and in addition it might be different on all platforms.
I think what we want is a generic MC structure. BUT we also want a platform specific sysinfo structure.
And sysinfo is what we want to pass there, not MC. I think the object model is wrong at the moment.
Also, can there be more than one MC on a northbridge?
In theory. But the meminit code would know that. No need to define it every time.
Stefan
I'm fine if somebody wants to work out a MC controller fix.
Weirdly enough, it will look like the device model. But that's ok.
ron
On Thu, Jun 07, 2007 at 11:25:06AM -0700, ron minnich wrote:
I'm fine if somebody wants to work out a MC controller fix.
Ah yes - the code. This is where it ended last time too. :p
Weirdly enough, it will look like the device model. But that's ok.
You mean how it is in v2? Is that so wrong then? (Except that it's a list and not a tree right?)
//Peter
On Thu, Jun 07, 2007 at 08:14:57PM +0200, Stefan Reinauer wrote:
How does everyone feel abot unions?
Bad. I dont think we need them. (Well if we did, it would be an idea)
Agreed, if no need then no reason.
I think what we want is a generic MC structure.
Yes, this sounds good.
BUT we also want a platform specific sysinfo structure.
What would it hold? Is it the initial device tree in code?
And sysinfo is what we want to pass there, not MC. I think the object model is wrong at the moment.
Quite possible. I'm not sure how things are right now, just what I think I'd like:
A device tree (not list) in code that * is seeded by the mainboard dts, which lists all devices * has device options set from defaults in device dts * has device option overrides from mainboard dts * has device option overrides from Kconfig * can be translated to (if it isn't already) a device tree for consumption by the kernel
Sorry if you've already had to get me to drop this once, but it's the nice and neat structure that I imagined at the symposium when we started talking about dts and so on. Is my thinking wrong?
Also, can there be more than one MC on a northbridge?
In theory. But the meminit code would know that. No need to define it every time.
How would it know?
I think the tree should have several ctrl nodes - one per MC. Right?
//Peter
* Peter Stuge stuge-linuxbios@cdy.org [070607 20:25]:
BUT we also want a platform specific sysinfo structure.
What would it hold? Is it the initial device tree in code?
./src/northbridge/amd/amdk8/amdk8_f.h
or is this what should go in the mc structure instead?
Sorry if you've already had to get me to drop this once, but it's the nice and neat structure that I imagined at the symposium when we started talking about dts and so on. Is my thinking wrong?
No. It will just be hard to get this done right and in time.
In theory. But the meminit code would know that. No need to define it every time.
How would it know?
Well, meminit code knows what memory controller it is written for. AMD wont start building CPUs using 2:23.0 instead of 0:18.0
On most systems the mem controller is 0:0.0 anyways.
I think the tree should have several ctrl nodes - one per MC. Right?
yes. It has but they are "ordinary pci devices" in the tree. we dont have a tree at raminit time (yet?)
On 6/7/07, Stefan Reinauer stepan@coresystems.de wrote:
yes. It has but they are "ordinary pci devices" in the tree. we dont have a tree at raminit time (yet?)
yes, but it hit me that dts can build two trees, one very limited one for raminit.
ron
* ron minnich rminnich@gmail.com [070607 21:16]:
On 6/7/07, Stefan Reinauer stepan@coresystems.de wrote:
yes. It has but they are "ordinary pci devices" in the tree. we dont have a tree at raminit time (yet?)
yes, but it hit me that dts can build two trees, one very limited one for raminit.
yeah. how would that tree be used?
On 6/7/07, Stefan Reinauer stepan@coresystems.de wrote:
yeah. how would that tree be used?
to describe the device-independent and device-dependent data. To provide pointers to functions. Pretty much how it is used now.
ron
* ron minnich rminnich@gmail.com [070607 21:29]:
yeah. how would that tree be used?
to describe the device-independent and device-dependent data. To provide pointers to functions. Pretty much how it is used now.
Of the memory controller?
So far all that memory init had to do was implement some hooks. Do we want to change this?
Where do you want to put that device tree? in cache? Or RO in rom?
On Thu, Jun 07, 2007 at 08:25:24PM +0200, Peter Stuge wrote:
Quite possible. I'm not sure how things are right now, just what I think I'd like:
A device tree (not list) in code that
- is seeded by the mainboard dts, which lists all devices
All _static_ devices, correct?
- has device options set from defaults in device dts
- has device option overrides from mainboard dts
- has device option overrides from Kconfig
- can be translated to (if it isn't already) a device tree for consumption by the kernel
* Can automatically translated into a kconfig-style menu structure and data structure for consumption by lbmenu, the yet to be written tool for run-time configuration of LinuxBIOS.
Full ack. This is just about how I'd like it to work in the end. Now, _how_ we achieve this is yet to be determined, though ;)
Uwe.
On 6/7/07, Peter Stuge stuge-linuxbios@cdy.org wrote:
A device tree (not list) in code that
- is seeded by the mainboard dts, which lists all devices
- has device options set from defaults in device dts
- has device option overrides from mainboard dts
I have this almost done, just FYI.
ron
On 6/12/07, ron minnich rminnich@gmail.com wrote:
On 6/7/07, Peter Stuge stuge-linuxbios@cdy.org wrote:
A device tree (not list) in code that
- is seeded by the mainboard dts, which lists all devices
- has device options set from defaults in device dts
- has device option overrides from mainboard dts
I have this almost done, just FYI.
it seems to work, but the error checking is incomplete.
But you can have something like this:
/{ north{ /config/("northbridge/intel/i440bxemulation"); }; };
The /config/ keyword (there has to be a better way to do keywords?) means: suck in northbridge/intel/i440bxemulation/dts. That file has a list of properties, well, currently only one: { dram = "no"; };
The "no" value for the dram property will provide a reasonable default if the dram property is not spec'ed. A mainboard value can override it. You probably want a number there.
The dtc generates the struct as described by the northbridge/intel/i440bxemulation/dts file: struct north { u32 dram; }; /*north*/ (i.e. this struct generation came ENTIRELY from the chip dts, and was emitted by the device tree compiler (dtc))
and, as it generates the initializations, you see this: struct north { .dram = {0|(0x6e<<24)|(0x6f<<16)|(0x00<<8)}, }; /*north*/
i.e. you only get u32's at present and, until we're sure we need something else, that's all you get. I hope people aren't going to start asking for types ...
So you can spec that a chip dts is to be used; that chip dts will cause a struct to be generated; the struct members in there can have a default value, set for that chip; and, the defaults can be over-ridden by mainboard settings.
Pretty much what we said we wanted, I think. But your Kconfig request is not in there, as supporting it will require: 1) dtc pass 2) kconfig pass 3) dtc pass again
I think.
The changes are backwards-compatible; current qemu target builds just fine.
Peter, is this it?
I can generate a patch if people want to look at the code. I admit it is rough, but gives us a starting point.
ron
On Tue, Jun 12, 2007 at 09:37:27PM -0700, ron minnich wrote:
On 6/12/07, ron minnich rminnich@gmail.com wrote:
On 6/7/07, Peter Stuge stuge-linuxbios@cdy.org wrote:
A device tree (not list) in code that
- is seeded by the mainboard dts, which lists all devices
- has device options set from defaults in device dts
- has device option overrides from mainboard dts
I have this almost done, just FYI.
it seems to work, but the error checking is incomplete.
Awesome! Really great work!
[..]
Pretty much what we said we wanted, I think.
Yes indeed.
But your Kconfig request is not in there, as supporting it will require:
- dtc pass
- kconfig pass
- dtc pass again
I think.
2 is user doing make *config, right?
Hmm - why the second dtc pass? Maybe it could be run from the Makefile automatically?
The changes are backwards-compatible; current qemu target builds just fine.
Peter, is this it?
I think so!
I can generate a patch if people want to look at the code. I admit it is rough, but gives us a starting point.
I'd love to take a look at it!
//Peter
* ron minnich rminnich@gmail.com [070607 19:45]:
I will try to sum it up but ... there is no way to unify it, short form. I contains very chip-dependent stuff, ranging from the simple array of longs up to a very complex multi-channel, mult-i devfn, multi-address, etc. etc. mess.
Saving devfns in the mem ctrl struct is one of the stupid things in v2.
The mem init code could easily know that the 1st ram controller is 0:18.x, the second one 0:19.x etc.
And that was a complex platform.
We dont win any flexibility by letting the board supporter write that in auto.c. it just looks like something you should know, but in fact you should not need to.
All it should ever be is: * number of controller * channel on controller * spd position and mux config on i2c bus.
What else?
OK peter you win :-)
I am going to try a simple experiment on my tree, which is to have a 'dts' in each directory, with a spec of the chip and optional defaults -- I do not like the defaults in the dts, I really feel they belong in kconfig but -- and I will try to GENERATE the .h file from the pre-chip dts.
That will be my homework for next week, will report back.
I will pause LX port until I test this.
ron
-
Peter Stuge -
ron minnich -
Stefan Reinauer -
Uwe Hermann