newconfig to Kconfig for Dummies

[Joseph Smith]

> -->  Please help porting all boards from newconfig to Kconfig<--
>
> This is a lot of janitor work and we can use your helping hands.
> The sooner we can get rid of Kbuild, the better. The KBuild report
> on the mailing list shows the config differences between newconfig
> and Kconfig. In theory, all Kconfig configs should be equal to their
> newconfig pendant. In practice it's better to come close but stay
> clean.
>
> -->  Please help porting all boards from newconfig to Kconfig<--

Hello,
I really want to get my boards up to date, but I really don't know where 
to start. I ran the kbuildall util on my boards, stared at the the files 
it created for about an hour and then walked away. Being new to Kconfig 
and all I am a bit lost. If someone could please write a brief 
"newconfig to Kconfig for Dummies" I would be truly grateful.

[Patrick Georgi]

Am 04.02.2010 05:47, schrieb Joseph Smith:
> Hello,
> I really want to get my boards up to date, but I really don't know where
> to start. I ran the kbuildall util on my boards, stared at the the files
> it created for about an hour and then walked away. Being new to Kconfig
> and all I am a bit lost. If someone could please write a brief
> "newconfig to Kconfig for Dummies" I would be truly grateful.

The simplest test of all is to build boards and try to run the images
generated by it (build/coreboot.rom)

Then, kbuildall compares the configuration between newconfig and kconfig
- it's printed in our kbuild reports on the list, and by kbuildall after
every build. It's also stored in
kbuildall.results/vendor_board.variables.txt

With that list in hand, you can edit the board's Kconfig file to match
up differences between newconfig (prefixed with "-" in the report) and
kconfig (prefixed with "+").

We generally have two methods of setting variables:

Normally you'll need the 4-liner as commonly used:
config WHATEVER (for CONFIG_WHATEVER)
    int (or hex, string, bool)
    default the_default_for_this_board
    depends on BOARD_VENDOR_MAINBOARD (as stated in the first entry)

The type is normally already defined in some global Kconfig file, and
should match it (src/Kconfig, src/arch/i386/Kconfig, or for northbridge
specific stuff in the respective northbridge directory)

For boolean values that default to false, you can set them with the
"select" statement in the board's entry as a shortcut (eg.
"select UDELAY_LAPIC")

Now the thing is that some values shouldn't end up in the board's
Kconfig, but in the Kconfig file of the component that is really
affected. For example, we set IOAPIC use per southbridge (as these have
to setup IOAPICs in our code)

Unfortunately, this decision is nothing we can easily define in a "for
Dummies" set of rules. But having all boards match the newconfig config
(and be boot-tested, sometimes newconfig is wrong, too!), even if that
information is stuffed into boards when it doesn't belong there is
better than the current state where values vary wildly.

So, having newconfig and kconfig match (ie. only have values differ in
the report that don't affect booting, eg. DEFAULT_LOGLEVEL), and have
them boot-tested with kconfig is a very useful goal for now.

We can still shuffle items around later, but for now, newconfig is still
the gold standard. Once both match, we can kick out newconfig and move on.

Regards,
Patrick

[Joseph Smith]

On 02/04/2010 05:55 AM, Patrick Georgi wrote:
> Am 04.02.2010 05:47, schrieb Joseph Smith:
> > Hello,
> > I really want to get my boards up to date, but I really don't know where
> > to start. I ran the kbuildall util on my boards, stared at the the files
> > it created for about an hour and then walked away. Being new to Kconfig
> > and all I am a bit lost. If someone could please write a brief
> > "newconfig to Kconfig for Dummies" I would be truly grateful.
>
> The simplest test of all is to build boards and try to run the images
> generated by it (build/coreboot.rom)
>
> Then, kbuildall compares the configuration between newconfig and kconfig
> it's printed in our kbuild reports on the list, and by kbuildall after
>
> every build. It's also stored in
> kbuildall.results/vendor_board.variables.txt
>
> With that list in hand, you can edit the board's Kconfig file to match
> up differences between newconfig (prefixed with "-" in the report) and
> kconfig (prefixed with "+").
>
> We generally have two methods of setting variables:
>
> Normally you'll need the 4-liner as commonly used:
> config WHATEVER (for CONFIG_WHATEVER)
>    int (or hex, string, bool)
>    default the_default_for_this_board
>    depends on BOARD_VENDOR_MAINBOARD (as stated in the first entry)
>
> The type is normally already defined in some global Kconfig file, and
> should match it (src/Kconfig, src/arch/i386/Kconfig, or for northbridge
> specific stuff in the respective northbridge directory)
>
> For boolean values that default to false, you can set them with the
> "select" statement in the board's entry as a shortcut (eg.
> "select UDELAY_LAPIC")
>
> Now the thing is that some values shouldn't end up in the board's
> Kconfig, but in the Kconfig file of the component that is really
> affected. For example, we set IOAPIC use per southbridge (as these have
> to setup IOAPICs in our code)
>
> Unfortunately, this decision is nothing we can easily define in a "for
> Dummies" set of rules. But having all boards match the newconfig config
> (and be boot-tested, sometimes newconfig is wrong, too!), even if that
> information is stuffed into boards when it doesn't belong there is
> better than the current state where values vary wildly.
>
> So, having newconfig and kconfig match (ie. only have values differ in
> the report that don't affect booting, eg. DEFAULT_LOGLEVEL), and have
> them boot-tested with kconfig is a very useful goal for now.
>
> We can still shuffle items around later, but for now, newconfig is still
> the gold standard. Once both match, we can kick out newconfig and move on.

Awsome. Thank you Patrick :-)

[Joseph Smith]

On 02/04/2010 05:55 AM, Patrick Georgi wrote:
> Am 04.02.2010 05:47, schrieb Joseph Smith:
> > Hello,
> > I really want to get my boards up to date, but I really don't know where
> > to start. I ran the kbuildall util on my boards, stared at the the files
> > it created for about an hour and then walked away. Being new to Kconfig
> > and all I am a bit lost. If someone could please write a brief
> > "newconfig to Kconfig for Dummies" I would be truly grateful.
>
> The simplest test of all is to build boards and try to run the images
> generated by it (build/coreboot.rom)
>
> Then, kbuildall compares the configuration between newconfig and kconfig
> it's printed in our kbuild reports on the list, and by kbuildall after
>
> every build. It's also stored in
> kbuildall.results/vendor_board.variables.txt
>
> With that list in hand, you can edit the board's Kconfig file to match
> up differences between newconfig (prefixed with "-" in the report) and
> kconfig (prefixed with "+").
>
> We generally have two methods of setting variables:
>
> Normally you'll need the 4-liner as commonly used:
> config WHATEVER (for CONFIG_WHATEVER)
>    int (or hex, string, bool)
>    default the_default_for_this_board
>    depends on BOARD_VENDOR_MAINBOARD (as stated in the first entry)
>
> The type is normally already defined in some global Kconfig file, and
> should match it (src/Kconfig, src/arch/i386/Kconfig, or for northbridge
> specific stuff in the respective northbridge directory)
>
> For boolean values that default to false, you can set them with the
> "select" statement in the board's entry as a shortcut (eg.
> "select UDELAY_LAPIC")
>
> Now the thing is that some values shouldn't end up in the board's
> Kconfig, but in the Kconfig file of the component that is really
> affected. For example, we set IOAPIC use per southbridge (as these have
> to setup IOAPICs in our code)
>
> Unfortunately, this decision is nothing we can easily define in a "for
> Dummies" set of rules. But having all boards match the newconfig config
> (and be boot-tested, sometimes newconfig is wrong, too!), even if that
> information is stuffed into boards when it doesn't belong there is
> better than the current state where values vary wildly.
>
> So, having newconfig and kconfig match (ie. only have values differ in
> the report that don't affect booting, eg. DEFAULT_LOGLEVEL), and have
> them boot-tested with kconfig is a very useful goal for now.
>
> We can still shuffle items around later, but for now, newconfig is still
> the gold standard. Once both match, we can kick out newconfig and move on.

Ok, so here is what the Thomson IP1000 looks like (see notations):

-CONFIG_DCACHE_RAM_BASE  = 0xc0000 - I have no idea what this is for???
-CONFIG_DCACHE_RAM_SIZE  = 0x1000 - I have no idea what this is for???
+CONFIG_HAVE_HARD_RESET  = 0x0
+CONFIG_HAVE_HIGH_TABLES  = 0x1
+CONFIG_HAVE_PIRQ_TABLE  = 0x1
-CONFIG_HYPERTRANSPORT_PLUGIN_SUPPORT  = 0x1 - Why would newconfig 
enable this for an Intel P3 processor? Is it enabled by default?
+CONFIG_HYPERTRANSPORT_PLUGIN_SUPPORT  = 0x0
+CONFIG_I830_VIDEO_MB_1MB  = 0x0
+CONFIG_I830_VIDEO_MB_512KB  = 0x0
+CONFIG_I830_VIDEO_MB_8MB  = 0x1
+CONFIG_I830_VIDEO_MB_OFF  = 0x0
-CONFIG_LOGICAL_CPUS  = 0x0 - Why would newconfig specify 0 cpus???
+CONFIG_LOGICAL_CPUS  = 0x1
-CONFIG_PCI_OPTION_ROM_RUN_REALMODE  = 0x0 - I want this to be enabled 
by default (0x1), so should I just change it in Options.lb?
+CONFIG_PCI_OPTION_ROM_RUN_REALMODE  = 0x1
+CONFIG_PCI_OPTION_ROM_RUN_X86EMU  = 0x0
+CONFIG_PCI_OPTION_ROM_RUN_YABEL  = 0x0
-CONFIG_PCI_ROM_RUN  = 0x0 - I want this to be enabled by default (0x1), 
so should I just change it in Options.lb?
+CONFIG_PCI_ROM_RUN  = 0x1
-CONFIG_RAMBASE  = 0x4000 - What is the correct value?
+CONFIG_RAMBASE  = 0x100000 - It seems to work fine ether way?
-CONFIG_VGA_ROM_RUN  = 0x0 - I want this to be enabled by default (0x1), 
so should I just change it in Options.lb?
+CONFIG_VGA_ROM_RUN  = 0x1

Help.

[Myles Watson]

> Ok, so here is what the Thomson IP1000 looks like (see notations):
>
> -CONFIG_DCACHE_RAM_BASE  = 0xc0000 - I have no idea what this is for???
> -CONFIG_DCACHE_RAM_SIZE  = 0x1000 - I have no idea what this is for???

If your board doesn't use CAR it doesn't matter.  It's the address and size
for  Cache-As-RAM.
> +CONFIG_HAVE_HARD_RESET  = 0x0
> +CONFIG_HAVE_HIGH_TABLES  = 0x1
> +CONFIG_HAVE_PIRQ_TABLE  = 0x1
> -CONFIG_HYPERTRANSPORT_PLUGIN_SUPPORT  = 0x1 - Why would newconfig
> enable this for an Intel P3 processor? Is it enabled by default?

Yes.
> +CONFIG_HYPERTRANSPORT_PLUGIN_SUPPORT  = 0x0
> +CONFIG_I830_VIDEO_MB_1MB  = 0x0
> +CONFIG_I830_VIDEO_MB_512KB  = 0x0
> +CONFIG_I830_VIDEO_MB_8MB  = 0x1
> +CONFIG_I830_VIDEO_MB_OFF  = 0x0
> -CONFIG_LOGICAL_CPUS  = 0x0 - Why would newconfig specify 0 cpus???

LOGICAL_CPUS is code for multiple cores.  In this case I'm assuming that
your CPU is single-core.
> +CONFIG_LOGICAL_CPUS  = 0x1
> -CONFIG_PCI_OPTION_ROM_RUN_REALMODE  = 0x0 - I want this to be enabled
> by default (0x1), so should I just change it in Options.lb?

newconfig is going away.  I wouldn't bother.
> +CONFIG_PCI_OPTION_ROM_RUN_REALMODE  = 0x1
> +CONFIG_PCI_OPTION_ROM_RUN_X86EMU  = 0x0
> +CONFIG_PCI_OPTION_ROM_RUN_YABEL  = 0x0
> -CONFIG_PCI_ROM_RUN  = 0x0 - I want this to be enabled by default (0x1),
> so should I just change it in Options.lb?

Same thing.
> +CONFIG_PCI_ROM_RUN  = 0x1
> -CONFIG_RAMBASE  = 0x4000 - What is the correct value?
> +CONFIG_RAMBASE  = 0x100000 - It seems to work fine ether way?

If it works either way, then leave it at 0x100000.  It's "safer" for things
like SMI to have Coreboot run above 1MB.
> -CONFIG_VGA_ROM_RUN  = 0x0 - I want this to be enabled by default (0x1),
> so should I just change it in Options.lb?

Same thing.
> +CONFIG_VGA_ROM_RUN  = 0x1

Does it boot with Kconfig?  If yes, you're done.

Thanks,
Myles

[Joseph Smith]

On 02/04/2010 11:28 PM, Myles Watson wrote:
> > Ok, so here is what the Thomson IP1000 looks like (see notations):
> >
> > -CONFIG_DCACHE_RAM_BASE  = 0xc0000 - I have no idea what this is for???
> > -CONFIG_DCACHE_RAM_SIZE  = 0x1000 - I have no idea what this is for???
>
> If your board doesn't use CAR it doesn't matter.  It's the address and size
> for  Cache-As-RAM.
> > +CONFIG_HAVE_HARD_RESET  = 0x0
> > +CONFIG_HAVE_HIGH_TABLES  = 0x1
> > +CONFIG_HAVE_PIRQ_TABLE  = 0x1
> > -CONFIG_HYPERTRANSPORT_PLUGIN_SUPPORT  = 0x1 - Why would newconfig
> > enable this for an Intel P3 processor? Is it enabled by default?
>
> Yes.
> > +CONFIG_HYPERTRANSPORT_PLUGIN_SUPPORT  = 0x0
> > +CONFIG_I830_VIDEO_MB_1MB  = 0x0
> > +CONFIG_I830_VIDEO_MB_512KB  = 0x0
> > +CONFIG_I830_VIDEO_MB_8MB  = 0x1
> > +CONFIG_I830_VIDEO_MB_OFF  = 0x0
> > -CONFIG_LOGICAL_CPUS  = 0x0 - Why would newconfig specify 0 cpus???
>
> LOGICAL_CPUS is code for multiple cores.  In this case I'm assuming that
> your CPU is single-core.
> > +CONFIG_LOGICAL_CPUS  = 0x1
> > -CONFIG_PCI_OPTION_ROM_RUN_REALMODE  = 0x0 - I want this to be enabled
> > by default (0x1), so should I just change it in Options.lb?
>
> newconfig is going away.  I wouldn't bother.
> > +CONFIG_PCI_OPTION_ROM_RUN_REALMODE  = 0x1
> > +CONFIG_PCI_OPTION_ROM_RUN_X86EMU  = 0x0
> > +CONFIG_PCI_OPTION_ROM_RUN_YABEL  = 0x0
> > -CONFIG_PCI_ROM_RUN  = 0x0 - I want this to be enabled by default (0x1),
> > so should I just change it in Options.lb?
>
> Same thing.
> > +CONFIG_PCI_ROM_RUN  = 0x1
> > -CONFIG_RAMBASE  = 0x4000 - What is the correct value?
> > +CONFIG_RAMBASE  = 0x100000 - It seems to work fine ether way?
>
> If it works either way, then leave it at 0x100000.  It's "safer" for things
> like SMI to have Coreboot run above 1MB.
> > -CONFIG_VGA_ROM_RUN  = 0x0 - I want this to be enabled by default (0x1),
> > so should I just change it in Options.lb?
>
> Same thing.
> > +CONFIG_VGA_ROM_RUN  = 0x1
>
> Does it boot with Kconfig?  If yes, you're done.
>
> Thanks Myles, yes it does boot with Kconfig, so I guess I am done.

[Myles Watson]

> > Does it boot with Kconfig?  If yes, you're done.
>
> Thanks Myles, yes it does boot with Kconfig, so I guess I am done.

Great!  Thanks for testing it.  Maybe we need some way to mark a board as
boot tested so the Kconfig settings don't get changed without a boot test
from here.

Myles

[Stefan Reinauer]

On 2/5/10 5:28 AM, Myles Watson wrote:
> > -CONFIG_LOGICAL_CPUS  = 0x0 - Why would newconfig specify 0 cpus???
>
> LOGICAL_CPUS is code for multiple cores.  In this case I'm assuming that
> your CPU is single-core.

Also, despite what the name implies, this is a "boolean" type of value,
0 meaning no and 1 meaning yes. It's not a number.

Stefan

[ron minnich]

On Fri, Feb 5, 2010 at 1:29 AM, Stefan Reinauer  wrote:
> On 2/5/10 5:28 AM, Myles Watson wrote:
> > > -CONFIG_LOGICAL_CPUS  = 0x0 - Why would newconfig specify 0 cpus???
> >
> > LOGICAL_CPUS is code for multiple cores.  In this case I'm assuming that
> > your CPU is single-core.
>
> Also, despite what the name implies, this is a "boolean" type of value,
> 0 meaning no and 1 meaning yes. It's not a number.

I wish we could change that name.

Doesn't it really mean cores?

ron

[Joseph Smith]

On 02/05/2010 11:17 AM, ron minnich wrote:
> On Fri, Feb 5, 2010 at 1:29 AM, Stefan Reinauer  wrote:
> > On 2/5/10 5:28 AM, Myles Watson wrote:
> > > > -CONFIG_LOGICAL_CPUS  = 0x0 - Why would newconfig specify 0 cpus???
> > >
> > > LOGICAL_CPUS is code for multiple cores.  In this case I'm assuming that
> > > your CPU is single-core.
> >
> > Also, despite what the name implies, this is a "boolean" type of value,
> > 0 meaning no and 1 meaning yes. It's not a number.
>
> I wish we could change that name.
>
> Doesn't it really mean cores?

yes something like CPU_CORES would be better.

[Patrick Georgi]

Am 05.02.2010 17:22, schrieb Joseph Smith:
> yes something like CPU_CORES would be better.

What about MULTICORE_SUPPORT?

Patrick

[Joseph Smith]

On 02/05/2010 11:39 AM, Patrick Georgi wrote:
> Am 05.02.2010 17:22, schrieb Joseph Smith:
> > yes something like CPU_CORES would be better.
>
> What about MULTICORE_SUPPORT?

Yes, that is much better :-)

[Stefan Reinauer]

On 2/5/10 5:40 PM, Joseph Smith wrote:
> On 02/05/2010 11:39 AM, Patrick Georgi wrote:
> > Am 05.02.2010 17:22, schrieb Joseph Smith:
> > > yes something like CPU_CORES would be better.
> >
> > What about MULTICORE_SUPPORT?

Or should we just re-unite it under CONFIG_SMP?

MULTICORE is about as wrong for hyperthreading as LOGICAL_CPUS

No matter what, I think the number of config variables around this area
should be reduced. Then bad names don't hurt so much.

[ron minnich]

On Fri, Feb 5, 2010 at 9:32 AM, Stefan Reinauer  wrote:
> Or should we just re-unite it under CONFIG_SMP?

really, it never makes sense to make it an option anyway. In what
context is it ever right to not enable
multicore and SMP? If you don't want them, linux can turn them off. If
you do want them, why would you ever build a bios that
disables their use?

In the early days it made some limited sense for these to be config
variables but I don't think it makes sense any more.

To put it another way, I think you are right about having too many
options of this type. They no longer make sense.

thanks

ron

[Myles Watson]

> > Or should we just re-unite it under CONFIG_SMP?
>
> really, it never makes sense to make it an option anyway. In what
> context is it ever right to not enable
> multicore and SMP? If you don't want them, linux can turn them off. If
> you do want them, why would you ever build a bios that
> disables their use?

They're good for testing.  There have been problems in initializing multiple
CPUs and multiple cores that were easier to debug with some of them turned
off.  It's way before you get to Linux.
> In the early days it made some limited sense for these to be config
> variables but I don't think it makes sense any more.

I agree that the user shouldn't ever have to decide whether his board is
needs CONFIG_LOGICAL_CPUS, but we have lots of Kconfig options that aren't
for users.  CONFIG_SOUTHBRIDGE_* etc.

Thanks,
Myles

[ron minnich]

On Fri, Feb 5, 2010 at 9:56 AM, Myles Watson  wrote:
> They're good for testing.  There have been problems in initializing multiple
> CPUs and multiple cores that were easier to debug with some of them turned
> off.  It's way before you get to Linux.

OK, then it makes sense to keep them in. You're right.

ron

[Stefan Reinauer]

On 2/5/10 5:17 PM, ron minnich wrote:
> On Fri, Feb 5, 2010 at 1:29 AM, Stefan Reinauer  wrote:
> > On 2/5/10 5:28 AM, Myles Watson wrote:
> > > > -CONFIG_LOGICAL_CPUS  = 0x0 - Why would newconfig specify 0 cpus???
> > >
> > > LOGICAL_CPUS is code for multiple cores.  In this case I'm assuming that
> > > your CPU is single-core.
> >
> > Also, despite what the name implies, this is a "boolean" type of value,
> > 0 meaning no and 1 meaning yes. It's not a number.
>
> I wish we could change that name.
>
> Doesn't it really mean cores?

I think it means CONFIG_SMP while CONFIG_SMP means "create an IRQ table" ;-)

Yes, cores is right. but also "threads" of hyperthreading. My
hyperthreading dual core atom shows four logical cpus :-)

[Myles Watson]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Stefan Reinauer
> Sent: Friday, February 05, 2010 9:44 AM
> To: ron minnich
> Cc: [e-mail]
> Subject: Re: [coreboot] newconfig to Kconfig for Dummies
>
> On 2/5/10 5:17 PM, ron minnich wrote:
> > On Fri, Feb 5, 2010 at 1:29 AM, Stefan Reinauer
>
> wrote:
> > > On 2/5/10 5:28 AM, Myles Watson wrote:
> > > > > -CONFIG_LOGICAL_CPUS  = 0x0 - Why would newconfig specify 0 cpus???
> > > >
> > > > LOGICAL_CPUS is code for multiple cores.  In this case I'm assuming
>
> that
> > > > your CPU is single-core.
> > >
> > > Also, despite what the name implies, this is a "boolean" type of value,
> > > 0 meaning no and 1 meaning yes. It's not a number.
> >
> > I wish we could change that name.
> >
> > Doesn't it really mean cores?
>
> I think it means CONFIG_SMP while CONFIG_SMP means "create an IRQ table"

It's close to SMP, but if you have a dual K8 with single-core processors,
you can set LOGICAL_CPUS=0.  For testing, you could do that with dual-core
processors to disable the siblings... right?

I guess it comes down to the fact that we should document it.  If we can't
define it succinctly on the mailing list, the chance that we're going to be
able to come up with a descriptive CONFIG_ name is small.

Myles

[Peter Stuge]

Myles Watson wrote:
> > > > > LOGICAL_CPUS is code for multiple cores.
> > >
> > > I wish we could change that name.
>
> It's close to SMP, but if you have a dual K8 with single-core
> processors, you can set LOGICAL_CPUS=0.

So it's what Ron says: support for multicore CPUs.

How about CONFIG_MULTICORE_CPU then?

//Peter