[PATCH]unify types in kconfig

[Patrick Georgi]

Hi,

attached patch makes PCI_ROM_RUN a boolean (like it is elsewhere), which
is the correct choice, too. Avoids type problems in kconfig

Signed-off-by: Patrick Georgi

[Myles Watson]

> attached patch makes PCI_ROM_RUN a boolean (like it is elsewhere), which
> is the correct choice, too. Avoids type problems in kconfig

I agree with the type change.  I think setting it in a mainboard Kconfig is
a mistake.  I tried to build Serengeti_cheetah without VGA to test something
and it was a pain.
> Signed-off-by: Patrick Georgi

Acked-by: Myles Watson

Thanks,
Myles

[Uwe Hermann]

On Tue, Aug 25, 2009 at 10:58:44AM -0600, Myles Watson wrote:
> > attached patch makes PCI_ROM_RUN a boolean (like it is elsewhere), which
> > is the correct choice, too. Avoids type problems in kconfig
>
> I agree with the type change.

Ditto, I was going to post the same patch also :)

Acked-by: Uwe Hermann
> I think setting it in a mainboard Kconfig is
> a mistake.  I tried to build Serengeti_cheetah without VGA to test something
> and it was a pain.

Hm, you could be right. This was per-mainboard in Config.lb, but in
kconfig it should be a global/common option, and not set in each board.

Uwe.

[ron minnich]

On Tue, Aug 25, 2009 at 10:14 AM, Uwe Hermann wrote:
> Hm, you could be right. This was per-mainboard in Config.lb, but in
> kconfig it should be a global/common option, and not set in each board.

yes, we really need to start using the power of Kconfig now. Let's
make it so people can choose this in menuconfig.

ron

[Myles Watson]

On Tue, Aug 25, 2009 at 11:37 AM, ron minnich wrote:
> On Tue, Aug 25, 2009 at 10:14 AM, Uwe Hermann wrote:
> > Hm, you could be right. This was per-mainboard in Config.lb, but in
> > kconfig it should be a global/common option, and not set in each board.
>
> yes, we really need to start using the power of Kconfig now. Let's
> make it so people can choose this in menuconfig.

Here's my attempt.  It doesn't build yet due to my util confusion.

Signed-off-by: Myles Watson

Thanks,
Myles

[Myles Watson]

On Tue, Aug 25, 2009 at 12:41 PM, Myles Watson wrote:
> On Tue, Aug 25, 2009 at 11:37 AM, ron minnich wrote:
> > On Tue, Aug 25, 2009 at 10:14 AM, Uwe Hermann wrote:
> > > Hm, you could be right. This was per-mainboard in Config.lb, but in
> > > kconfig it should be a global/common option, and not set in each board.
> >
> > yes, we really need to start using the power of Kconfig now. Let's
> > make it so people can choose this in menuconfig.

Here's another attempt.
 Signed-off-by: Myles Watson

It doesn't link.  The errors I'm getting look familiar, but the past
solution isn't working for me:
    CC         coreboot_ram
/home/myles/try/buildrom-devel/work/coreboot/svn/build/coreboot_ram.o:
In function `div_long':
(.text+0x11c79): undefined reference to `__umoddi3'
/home/myles/try/buildrom-devel/work/coreboot/svn/build/coreboot_ram.o:
In function `div_long':
(.text+0x11c92): undefined reference to `__udivdi3'
/home/myles/try/buildrom-devel/work/coreboot/svn/build/coreboot_ram.o:
In function `idiv_long':
(.text+0x11dca): undefined reference to `__moddi3'
/home/myles/try/buildrom-devel/work/coreboot/svn/build/coreboot_ram.o:
In function `idiv_long':
(.text+0x11de3): undefined reference to `__divdi3'
collect2: ld returned 1 exit status
make: *** [/home/myles/try/buildrom-devel/work/coreboot/svn/build/coreboot_ram]
Error 1

These errors look like the same ones that can be fixed with
gcc-multilib, but I have that installed.  I'm not sure how these files
should be built now.

Thanks,
Myles

[Cristi Magherusan]

On Tue, 2009-08-25 at 15:41 -0600, Myles Watson wrote:
> On Tue, Aug 25, 2009 at 12:41 PM, Myles Watson wrote:
> > On Tue, Aug 25, 2009 at 11:37 AM, ron minnich wrote:
> > > On Tue, Aug 25, 2009 at 10:14 AM, Uwe Hermann wrote:
> > > > Hm, you could be right. This was per-mainboard in Config.lb, but in
> > > > kconfig it should be a global/common option, and not set in each board.
> > >
> > > yes, we really need to start using the power of Kconfig now. Let's
> > > make it so people can choose this in menuconfig.
>
> Here's another attempt.
>  Signed-off-by: Myles Watson
>
> It doesn't link.  The errors I'm getting look familiar, but the past
> solution isn't working for me:
>     CC         coreboot_ram
> /home/myles/try/buildrom-devel/work/coreboot/svn/build/coreboot_ram.o:
> In function `div_long':
> (.text+0x11c79): undefined reference to `__umoddi3'
> /home/myles/try/buildrom-devel/work/coreboot/svn/build/coreboot_ram.o:
> In function `div_long':
> (.text+0x11c92): undefined reference to `__udivdi3'
> /home/myles/try/buildrom-devel/work/coreboot/svn/build/coreboot_ram.o:
> In function `idiv_long':
> (.text+0x11dca): undefined reference to `__moddi3'
> /home/myles/try/buildrom-devel/work/coreboot/svn/build/coreboot_ram.o:
> In function `idiv_long':
> (.text+0x11de3): undefined reference to `__divdi3'
> collect2: ld returned 1 exit status
> make: *** [/home/myles/try/buildrom-devel/work/coreboot/svn/build/coreboot_ram]
> Error 1
>
> These errors look like the same ones that can be fixed with
> gcc-multilib, but I have that installed.  I'm not sure how these files
> should be built now.

Hello,

I stumbled upon these errors when porting to Asus M2V-MX-SE, and they
are related to libgcc. Coreboot needs to be linked against libgcc when
using 64bit arithmetic in 32bit code.

There are a few approaches for fixing this, like:
-link against libgcc (statically)
-implement the needed functions ourselves (copied from libgcc)
-avoid using 64bit arithmetic

I'm in inclined to vote for the first approach.

Cristi

[ron minnich]

On Wed, Aug 26, 2009 at 1:01 AM, Cristi
Magherusan wrote:
> There are a few approaches for fixing this, like:
> -link against libgcc (statically)

Won't work on FC11.
> From a note on 9fans:

=============
also, i discovered something new today:

"... decided to link everything dynamically. To enforce this (allmost)
all static libraries are removed (or not even build)..."

$ gcc t.c -static
/usr/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
==============
> -implement the needed functions ourselves (copied from libgcc)

I vote for this one. Every time we count on stable (or even sane)
behavior from all linux distros or gnu toolchain, we get burned. I
think we need to be as standalone as possible.

There are, what, four functions at issue?

What really amazes me is that with all the inlining that is done
nowadays, these trivial functions are not inlined!

ron

[Cristi Magherusan]

On Wed, 2009-08-26 at 08:27 -0700, ron minnich wrote:
> On Wed, Aug 26, 2009 at 1:01 AM, Cristi
> Magherusan wrote:
> > There are a few approaches for fixing this, like:
> > -link against libgcc (statically)
>
> Won't work on FC11.
>
> From a note on 9fans:
>
> =============
> also, i discovered something new today:
>
> "... decided to link everything dynamically. To enforce this (allmost)
> all static libraries are removed (or not even build)..."
>
> $ gcc t.c -static
> /usr/bin/ld: cannot find -lc
> collect2: ld returned 1 exit status
> ==============
> > -implement the needed functions ourselves (copied from libgcc)
>
> I vote for this one. Every time we count on stable (or even sane)
> behavior from all linux distros or gnu toolchain, we get burned. I
> think we need to be as standalone as possible.
>
> There are, what, four functions at issue?
>
> What really amazes me is that with all the inlining that is done
> nowadays, these trivial functions are not inlined!
>
> ron

Hello,

This issue will be decided and fixed in time, maybe even cleaner,
but now we need to have as much boards as possible work with
kconfig/Kbuild and the workaround I submitted makes it possible, not to
mention it was already done the same way in the older buildsystem.

Cristi

[ron minnich]

On Wed, Aug 26, 2009 at 9:01 AM, Cristi
Magherusan wrote:
> This issue will be decided and fixed in time, maybe even cleaner,
> but now we need to have as much boards as possible work with
> kconfig/Kbuild and the workaround I submitted makes it possible, not to
> mention it was already done the same way in the older buildsystem.

Agreed. You all made the right decision.

ron

[Myles Watson]

> Here's another attempt.
>  Signed-off-by: Myles Watson

Ping.  Now it builds.

Thanks,
Myles