[LinuxBIOS] patch: dtc now emits constructor array

[ron minnich]

in the previous version of dtc, to set up the constructor array, one
had to declare it by hand
in the mainboard dts, viz:
%%

struct constructor *all_constructors[] = {
      i440bx_constructors, i82371eb_constructors, qemuvga_constructors, 0
};

This change eliminates that requirement. In the new version, if a node
in the dts has a
constructor property, e.g.:
        domain0 {
                enabled;
                config = "northbridge,intel,i440bxemulation";
                constructor="i440bx_constructors";

Then the dtc will emit the initialization automatically, adding a
pointer to the all_constructors array for each constructor.

Should we allow this?
constructor=["i440bx_constructors", "i440gx_constructors"];
so we can allow lots of things? We're still not sure.

Note that with this change, and the other dts change that is
committed, the need to put C in the dts file is now removed. This
should make you all happier. Peter?

This builds fine, but remains to be done, and, also, we need to fix
device directories and add a dts to each one.

SIgned-off-by: Ronald G. Minnich

p.s. Should I move all patch mail to main list at this time?

[Uwe Hermann]

On Mon, Jun 25, 2007 at 10:34:36AM -0700, ron minnich wrote:
> in the previous version of dtc, to set up the constructor array, one
> had to declare it by hand
> in the mainboard dts, viz:
> %%
>
> struct constructor *all_constructors[] = {
>      i440bx_constructors, i82371eb_constructors, qemuvga_constructors, 0
> };
>
> This change eliminates that requirement.

Nice, this is a great improvement!
> In the new version, if a node
> in the dts has a
> constructor property, e.g.:
>        domain0 {
>                enabled;
>                config = "northbridge,intel,i440bxemulation";
>                constructor="i440bx_constructors";
>
> Then the dtc will emit the initialization automatically, adding a
> pointer to the all_constructors array for each constructor.
>
> Should we allow this?
> constructor=["i440bx_constructors", "i440gx_constructors"];
> so we can allow lots of things? We're still not sure.

Yes, I think we should allow it, looks pretty flexible and some very
similar chipsets can be handled with the same code... Are there any
drawbacks if we allow that?
> Note that with this change, and the other dts change that is
> committed, the need to put C in the dts file is now removed. This
> should make you all happier. Peter?
>
> This builds fine, but remains to be done, and, also, we need to fix
> device directories and add a dts to each one.

What needs to be done to make this fully work? Can you fix the patch
so the tree remains compilable after applying?

I get compile errors currently:

CC      build/mainboard/emulation/qemu-x86/statictree.o
/tmp/v3_foo/build/mainboard/emulation/qemu-x86/statictree.c:71: error: redefinition of ‘all_constructors’
/tmp/v3_foo/build/mainboard/emulation/qemu-x86/statictree.c:17: error: previous definition of ‘all_constructors’ was here
make: *** [/tmp/v3_foo/build/mainboard/emulation/qemu-x86/statictree.o] Error 1

The patch itself looks good to me.

Uwe.

[ron minnich]

On 6/27/07, Uwe Hermann  wrote:
> What needs to be done to make this fully work? Can you fix the patch
> so the tree remains compilable after applying?
>
> I get compile errors currently:
>
> CC      build/mainboard/emulation/qemu-x86/statictree.o
> /tmp/v3_foo/build/mainboard/emulation/qemu-x86/statictree.c:71: error: redefinition of 'all_constructors'
> /tmp/v3_foo/build/mainboard/emulation/qemu-x86/statictree.c:17: error: previous definition of 'all_constructors' was here
> make: *** [/tmp/v3_foo/build/mainboard/emulation/qemu-x86/statictree.o] Error 1

This patch will lose backward compatibility. Stefan and I will need to
fix qemu target today. It's one the list :-)

ron

[ron minnich]

On 6/27/07, Uwe Hermann  wrote:
> What needs to be done to make this fully work? Can you fix the patch
> so the tree remains compilable after applying?

Compatibility is not going to be easy and it makes no sense to do (I
just tried it).

one option is we go ahead and break the tree for a bit while we
upgrade. I could use the help, since vga is not quite right; could we
do this?

The attached *might* get you back compiling.

thanks

ron

[ron minnich]

OK, as things stand, my tree with new dts etc. boots into vga mode in
qemu just fine.

I think it's time to really push to move forward. I am walking over to
OLS but will be checking mail all day.

ron

[Stefan Reinauer]

* ron minnich  [070627 14:46]:
> On 6/27/07, Uwe Hermann  wrote:
> > What needs to be done to make this fully work? Can you fix the patch
> > so the tree remains compilable after applying?
>
> Compatibility is not going to be easy and it makes no sense to do (I
>  just tried it).
>
> one option is we go ahead and break the tree for a bit while we
>  upgrade. I could use the help, since vga is not quite right; could we
>  do this?
>
> The attached *might* get you back compiling.

Ok, we need to get started. Let's commit this one. Right direction.

Acked-by: Stefan Reinauer

Stefan

[ron minnich]

On 6/27/07, Stefan Reinauer  wrote:
> Ok, we need to get started. Let's commit this one. Right direction.
>
> Acked-by: Stefan Reinauer

Commited in a series of revs ending in 373.

qemu builds.

ron