MODPOST section mismatches

MODPOST section mismatches

[Steve Heflin]

while building vmlinux.o the MODPOST warns about 8 section mismatches.
WARNING: modpost: Found 8 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'

After modifying the make launch to include the recommended option 
shown above, I see that the section mismatch warning is due to data 
structures containing the address of initialization modules which 
have the __init attribute. Since the memory model is FLAT, is this a problem?

thanks,
Steve
  

Re: MODPOST section mismatches

[Steve Heflin]

To reproduce the problem and see the details on section mismatches:

     make ARCH=powerpc sequoia_defconfig

     make ARCH=powerpc CONFIG_DEBUG_SECTION_MISMATCH=y

At 04:33 PM 2/21/2008, Steve Heflin wrote:
>while building vmlinux.o the MODPOST warns about 8 section mismatches.
>WARNING: modpost: Found 8 section mismatch(es).
>To see full details build your kernel with:
>'make CONFIG_DEBUG_SECTION_MISMATCH=y'
>
>After modifying the make launch to include the recommended option
>shown above, I see that the section mismatch warning is due to data
>structures containing the address of initialization modules which
>have the __init attribute. Since the memory model is FLAT, is this a problem?
>
>thanks,
>Steve
>
>
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: MODPOST section mismatches

[Josh Boyer]

On Fri, 22 Feb 2008 11:12:47 -0500
Steve Heflin <sheflin@newagemicro.com> wrote:

> To reproduce the problem and see the details on section mismatches:
> 
>      make ARCH=powerpc sequoia_defconfig
> 
>      make ARCH=powerpc CONFIG_DEBUG_SECTION_MISMATCH=y

All of those warnings are in drivers or common code.  And yes, they
should eventually all be fixed.

> >After modifying the make launch to include the recommended option
> >shown above, I see that the section mismatch warning is due to data
> >structures containing the address of initialization modules which
> >have the __init attribute. Since the memory model is FLAT, is this a problem?

What do you mean by "the memory model is FLAT"?

josh

Re: MODPOST section mismatches

[Steve Heflin]

FLAT_MEM is one of the configuration options:
       CONFIG_ARCH_FLATMEM_ENABLE=y

At 03:52 PM 2/22/2008, Josh Boyer wrote:
>On Fri, 22 Feb 2008 11:12:47 -0500
>Steve Heflin <sheflin@newagemicro.com> wrote:
>
> > To reproduce the problem and see the details on section mismatches:
> >
> >      make ARCH=powerpc sequoia_defconfig
> >
> >      make ARCH=powerpc CONFIG_DEBUG_SECTION_MISMATCH=y
>
>All of those warnings are in drivers or common code.  And yes, they
>should eventually all be fixed.
>
> > >After modifying the make launch to include the recommended option
> > >shown above, I see that the section mismatch warning is due to data
> > >structures containing the address of initialization modules which
> > >have the __init attribute. Since the memory model is FLAT, is 
> this a problem?
>
>What do you mean by "the memory model is FLAT"?
>
>josh
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: MODPOST section mismatches

[Josh Boyer]

On Fri, 22 Feb 2008 17:26:52 -0500
Steve Heflin <sheflin@newagemicro.com> wrote:

> FLAT_MEM is one of the configuration options:
>        CONFIG_ARCH_FLATMEM_ENABLE=y

That has to do with NUMA stuff.  It really doesn't have much bearing on
the section warnings.

josh

Re: MODPOST section mismatches

[Steve Heflin]

At 05:36 PM 2/22/2008, you wrote:
>On Fri, 22 Feb 2008 17:26:52 -0500
>Steve Heflin <sheflin@newagemicro.com> wrote:
>
> > FLAT_MEM is one of the configuration options:
> >        CONFIG_ARCH_FLATMEM_ENABLE=y
>
>That has to do with NUMA stuff.  It really doesn't have much bearing on
>the section warnings.

ah, thanks for setting me straight. I thought it meant that 
everything existed in a flat address space and existed in memory at 
the same time, and therefore the different section warnings might not apply. 

Re: MODPOST section mismatches

[Josh Boyer]

On Fri, 22 Feb 2008 18:07:37 -0500
Steve Heflin <sheflin@newagemicro.com> wrote:

> At 05:36 PM 2/22/2008, you wrote:
> >On Fri, 22 Feb 2008 17:26:52 -0500
> >Steve Heflin <sheflin@newagemicro.com> wrote:
> >
> > > FLAT_MEM is one of the configuration options:
> > >        CONFIG_ARCH_FLATMEM_ENABLE=y
> >
> >That has to do with NUMA stuff.  It really doesn't have much bearing on
> >the section warnings.
> 
> ah, thanks for setting me straight. I thought it meant that 
> everything existed in a flat address space and existed in memory at 
> the same time, and therefore the different section warnings might not apply. 

Nah.  The section warnings come about because if something is marked
__init but referenced in a function that isn't then an oops could occur
because the __init sections are discarded after a certain point in the
kernel boot.  The same is true for __devinit, etc.

So the section warnings are still bugs that need fixing, but they're
orthogonal to the memory model for the most part.

josh

Re: MODPOST section mismatches

[Steve Heflin]

At 07:30 PM 2/22/2008, you wrote:
>On Fri, 22 Feb 2008 18:07:37 -0500
>Steve Heflin <sheflin@newagemicro.com> wrote:
>
> > At 05:36 PM 2/22/2008, you wrote:
> > >On Fri, 22 Feb 2008 17:26:52 -0500
> > >Steve Heflin <sheflin@newagemicro.com> wrote:
> > >
> > > > FLAT_MEM is one of the configuration options:
> > > >        CONFIG_ARCH_FLATMEM_ENABLE=y
> > >
> > >That has to do with NUMA stuff.  It really doesn't have much bearing on
> > >the section warnings.
> >
> > ah, thanks for setting me straight. I thought it meant that
> > everything existed in a flat address space and existed in memory at
> > the same time, and therefore the different section warnings might 
> not apply.
>
>Nah.  The section warnings come about because if something is marked
>__init but referenced in a function that isn't then an oops could occur
>because the __init sections are discarded after a certain point in the
>kernel boot.  The same is true for __devinit, etc.
>
>So the section warnings are still bugs that need fixing, but they're
>orthogonal to the memory model for the most part.
>
>josh

Isn't there a way to keep the __init sections from being discarded 
such that I can run it without an oops occurring?

thanks for your help!
Steve

Sequoia build with KDBG

[Steve Heflin]

I attempted to enable the kernel debugger on my Sequoia board, and I 
get build errors:
  /linux-2.6.25-rc3/arch/powerpc/kernel/setup_32.c:254: undefined 
reference to `set_debug_traps'
  /linux-2.6.25-rc3/arch/powerpc/kernel/setup_32.c:259: undefined 
reference to `breakpoint'

Josh: I assume you have used the kernel debugger with your 44x 
boards, how did you build it?

thanks so much,
Steve

Re: Sequoia build with KDBG

[Josh Boyer]

On Fri, 29 Feb 2008 16:34:09 -0500
Steve Heflin <sheflin@newagemicro.com> wrote:

> I attempted to enable the kernel debugger on my Sequoia board, and I 
> get build errors:
>   /linux-2.6.25-rc3/arch/powerpc/kernel/setup_32.c:254: undefined 
> reference to `set_debug_traps'
>   /linux-2.6.25-rc3/arch/powerpc/kernel/setup_32.c:259: undefined 
> reference to `breakpoint'
> 
> Josh: I assume you have used the kernel debugger with your 44x 
> boards, how did you build it?

Why would you assume that?  I've never used kgdb on arch/powerpc
kernels, nor have I ever tried to build it.

I don't think kgdb is ported to powerpc at the moment.

josh

Re: Sequoia build with KDBG

[Steve Heflin]

At 04:35 PM 2/29/2008, Josh Boyer wrote:
>On Fri, 29 Feb 2008 16:34:09 -0500
>Steve Heflin <sheflin@newagemicro.com> wrote:
>
> > I attempted to enable the kernel debugger on my Sequoia board, and I
> > get build errors:
> >   /linux-2.6.25-rc3/arch/powerpc/kernel/setup_32.c:254: undefined
> > reference to `set_debug_traps'
> >   /linux-2.6.25-rc3/arch/powerpc/kernel/setup_32.c:259: undefined
> > reference to `breakpoint'
> >
> > Josh: I assume you have used the kernel debugger with your 44x
> > boards, how did you build it?
>
>Why would you assume that?  I've never used kgdb on arch/powerpc
>kernels, nor have I ever tried to build it.
>
>I don't think kgdb is ported to powerpc at the moment.
>
>josh

I assumed that because I've always needed a debugger when 
implementing kernel level components. Since you've implemented kernel 
level support for several 44x processors, I just assumed that you 
needed kdbg at some point. So you're saying that your additions 
worked right out of the gate and you never needed a debugger?  You're my hero!

Re: Sequoia build with KDBG

[Josh Boyer]

On Fri, 29 Feb 2008 17:31:10 -0500
Steve Heflin <sheflin@newagemicro.com> wrote:

> At 04:35 PM 2/29/2008, Josh Boyer wrote:
> >On Fri, 29 Feb 2008 16:34:09 -0500
> >Steve Heflin <sheflin@newagemicro.com> wrote:
> >
> > > I attempted to enable the kernel debugger on my Sequoia board, and I
> > > get build errors:
> > >   /linux-2.6.25-rc3/arch/powerpc/kernel/setup_32.c:254: undefined
> > > reference to `set_debug_traps'
> > >   /linux-2.6.25-rc3/arch/powerpc/kernel/setup_32.c:259: undefined
> > > reference to `breakpoint'
> > >
> > > Josh: I assume you have used the kernel debugger with your 44x
> > > boards, how did you build it?
> >
> >Why would you assume that?  I've never used kgdb on arch/powerpc
> >kernels, nor have I ever tried to build it.
>
> I assumed that because I've always needed a debugger when 
> implementing kernel level components. Since you've implemented kernel 
> level support for several 44x processors, I just assumed that you 
> needed kdbg at some point. So you're saying that your additions 

Nope.  I did the poor man's method of manually poking characters out of
the serial port.

> worked right out of the gate and you never needed a debugger?  You're my hero!

I largely stood on the shoulders of those that came before me.  Porting
has become trivial lately, mostly due to the collective work lots of
people have put in.

That all being said, I'm not opposed to having kgdb work on 4xx.  I
just have never personally looked at it yet.  Patches welcome :).

josh

Re: Sequoia build with KDBG

[Scott Wood]

Steve Heflin wrote:
> I assumed that because I've always needed a debugger when 
> implementing kernel level components. Since you've implemented kernel 
> level support for several 44x processors, I just assumed that you 
> needed kdbg at some point. So you're saying that your additions 
> worked right out of the gate and you never needed a debugger?  You're my hero!

There are ways of debugging that don't involve a debugger.

-Scott

Re: Sequoia build with KDBG

[Jon Loeliger]

Scott Wood wrote:

> There are ways of debugging that don't involve a debugger.

I suppose we could get all tautological and start claiming
that anything that helped one debug something might be, by
definition, a debugger. :-)

(de-)buggering off,
jdl

Re: Sequoia build with KDBG

[Wolfgang Denk]

In message <20080229223046.1B332DDE0A@ozlabs.org> you wrote:
>
> I assumed that because I've always needed a debugger when 
> implementing kernel level components. Since you've implemented kernel 
> level support for several 44x processors, I just assumed that you 
> needed kdbg at some point. So you're saying that your additions 
> worked right out of the gate and you never needed a debugger?  You're my hero!

Many people working on this stuff use a BDI2000 / BDI3000. Makes life
much easier...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I have the simplest tastes.  I am always satisfied with the best.
                                                       -- Oscar Wilde

Re: Sequoia build with KDBG

[Steve Heflin]

At 07:16 PM 2/29/2008, Wolfgang Denk wrote:
>In message <20080229223046.1B332DDE0A@ozlabs.org> you wrote:
> >
> > I assumed that because I've always needed a debugger when
> > implementing kernel level components. Since you've implemented kernel
> > level support for several 44x processors, I just assumed that you
> > needed kdbg at some point. So you're saying that your additions
> > worked right out of the gate and you never needed a 
> debugger?  You're my hero!
>
>Many people working on this stuff use a BDI2000 / BDI3000. Makes life
>much easier...

Wolfgang, you hit the nail on the head. Trying to debug a target 
without a JTAG debugger is a pain.

Re: Sequoia build with KDBG

[Josh Boyer]

On Fri, 29 Feb 2008 19:23:40 -0500
Steve Heflin <sheflin@newagemicro.com> wrote:

Putting the list back on CC because I'm sure you won't be the only
person to have this issue.

> poor man's debugging works fine if a serial port is available, but my 
> Sequoia platform doesn't get that far!  I use u-boot to download and 
> boot my image, and I don't get any serial output after the boot completes:

By "poking characters out the serial port" I meant I literally coded up
assembly functions to setup MMU translations and poke hex values at hard
coded addresses.  That's why it's "poor man's".  If you had a working
serial port out of the box, that would be a luxury ;).

> => bootm 0x500000
> ## Booting image at 00500000 ...
>     Image Name:   Kernel and Ramdisk
>     Created:      2008-03-01   0:09:57 UTC
>     Image Type:   PowerPC Linux Multi-File Image (gzip compressed)
>     Data Size:    2430248 Bytes =  2.3 MB
>     Load Address: 00000000
>     Entry Point:  00000000
>     Contents:
>     Image 0:  1471523 Bytes =  1.4 MB
>     Image 1:   958712 Bytes = 936.2 kB
>     Verifying Checksum ... OK
>     Uncompressing Multi-File Image ... OK
>     Loading Ramdisk to 07e42000, end 07f2c0f8 ... OK
> ------
> console port is now dead.
> ------

What image type are you using?  If this is an older U-Boot, you'll need
to use the cuImage.sequoia file that is produced when you compile your
kernel with 'make zImage'.  Sequoia (and I'm assuming you mean the
AMCC Sequoia Eval Board, not some custom hardware that's based on it)
has been working fine for a long time.

It seems you have some kind of other uImage, so try using the one
that's built with the kernel and go from there.

josh

Re: Sequoia build with KDBG

[Steve Heflin]

At 09:30 PM 2/29/2008, Josh Boyer wrote:
>On Fri, 29 Feb 2008 19:23:40 -0500
>Steve Heflin <sheflin@newagemicro.com> wrote:
>
>Putting the list back on CC because I'm sure you won't be the only
>person to have this issue.
>
> > poor man's debugging works fine if a serial port is available, but my
> > Sequoia platform doesn't get that far!  I use u-boot to download and
> > boot my image, and I don't get any serial output after the boot completes:
>
>By "poking characters out the serial port" I meant I literally coded up
>assembly functions to setup MMU translations and poke hex values at hard
>coded addresses.  That's why it's "poor man's".  If you had a working
>serial port out of the box, that would be a luxury ;).
>
> > => bootm 0x500000
> > ## Booting image at 00500000 ...
> >     Image Name:   Kernel and Ramdisk
> >     Created:      2008-03-01   0:09:57 UTC
> >     Image Type:   PowerPC Linux Multi-File Image (gzip compressed)
> >     Data Size:    2430248 Bytes =  2.3 MB
> >     Load Address: 00000000
> >     Entry Point:  00000000
> >     Contents:
> >     Image 0:  1471523 Bytes =  1.4 MB
> >     Image 1:   958712 Bytes = 936.2 kB
> >     Verifying Checksum ... OK
> >     Uncompressing Multi-File Image ... OK
> >     Loading Ramdisk to 07e42000, end 07f2c0f8 ... OK
> > ------
> > console port is now dead.
> > ------
>
>What image type are you using?  If this is an older U-Boot, you'll need
>to use the cuImage.sequoia file that is produced when you compile your
>kernel with 'make zImage'.  Sequoia (and I'm assuming you mean the
>AMCC Sequoia Eval Board, not some custom hardware that's based on it)
>has been working fine for a long time.
>
>It seems you have some kind of other uImage, so try using the one
>that's built with the kernel and go from there.
>
>josh

thank you so much for your helpful reply. No, I don't have a serial 
port that works "out of the box", and your hint of setting up the MMU 
translations and poking characters at hard coded addresses, is a big help.

My hardware is NOT a Sequoia eval, it is a custom board derived from 
the Sequoia platform back at 2.6.14. In a previous message when you 
said that ECC should be handled by the NAND driver, I figured out 
that our AMCC-440EPx board was not a standard Sequoia.  Ours has DDR 
ECC and the setup code writes to several registers to enable it.  I 
still offer this code to you.

I've used the zImage, the uImage, and the vmlinux image, all with the 
same results. My last attempt was a uImage, so I'll switch to the 
zImage and try again.

thanks so much for your help,
Steve 

Re: Sequoia build with KDBG

[Olof Johansson]

On Fri, Feb 29, 2008 at 08:30:15PM -0600, Josh Boyer wrote:

> > poor man's debugging works fine if a serial port is available, but my 
> > Sequoia platform doesn't get that far!  I use u-boot to download and 
> > boot my image, and I don't get any serial output after the boot completes:
> 
> By "poking characters out the serial port" I meant I literally coded up
> assembly functions to setup MMU translations and poke hex values at hard
> coded addresses.  That's why it's "poor man's".  If you had a working
> serial port out of the box, that would be a luxury ;).

Does 4xx have support for udbg and xmon? That would be a good first step
in getting an in-kernel debugger facility going.



-Olof

Re: Sequoia build with KDBG

[Josh Boyer]

On Fri, 29 Feb 2008 23:02:50 -0600
Olof Johansson <olof@lixom.net> wrote:

> On Fri, Feb 29, 2008 at 08:30:15PM -0600, Josh Boyer wrote:
> 
> > > poor man's debugging works fine if a serial port is available, but my 
> > > Sequoia platform doesn't get that far!  I use u-boot to download and 
> > > boot my image, and I don't get any serial output after the boot completes:
> > 
> > By "poking characters out the serial port" I meant I literally coded up
> > assembly functions to setup MMU translations and poke hex values at hard
> > coded addresses.  That's why it's "poor man's".  If you had a working
> > serial port out of the box, that would be a luxury ;).
> 
> Does 4xx have support for udbg and xmon? That would be a good first step
> in getting an in-kernel debugger facility going.

Yes.  Or at least it did as of a few kernel releases ago when I last
tested it.  It's helpful for a number of thing, but debugging extremely
early stuff isn't possible with it.

josh

Re: Sequoia build with KDBG

[Olof Johansson]

On Sat, Mar 01, 2008 at 07:13:15AM -0600, Josh Boyer wrote:
> On Fri, 29 Feb 2008 23:02:50 -0600
> Olof Johansson <olof@lixom.net> wrote:
> 
> > On Fri, Feb 29, 2008 at 08:30:15PM -0600, Josh Boyer wrote:
> > 
> > > > poor man's debugging works fine if a serial port is available, but my 
> > > > Sequoia platform doesn't get that far!  I use u-boot to download and 
> > > > boot my image, and I don't get any serial output after the boot completes:
> > > 
> > > By "poking characters out the serial port" I meant I literally coded up
> > > assembly functions to setup MMU translations and poke hex values at hard
> > > coded addresses.  That's why it's "poor man's".  If you had a working
> > > serial port out of the box, that would be a luxury ;).
> > 
> > Does 4xx have support for udbg and xmon? That would be a good first step
> > in getting an in-kernel debugger facility going.
> 
> Yes.  Or at least it did as of a few kernel releases ago when I last
> tested it.  It's helpful for a number of thing, but debugging extremely
> early stuff isn't possible with it.

Right, most in-kernel debuggers will be useless for that, so I doubt kgdb will
help in those cases either.


-Olof

Re: Sequoia build with KDBG

[Wolfgang Denk]

In message <20080301025528.AE450DDE98@ozlabs.org> you wrote:
>
> thank you so much for your helpful reply. No, I don't have a serial 
> port that works "out of the box", and your hint of setting up the MMU 
> translations and poking characters at hard coded addresses, is a big help.

Also remember that you can often get a lot of useful information from
a post-mortem dump of the lug buffer - see
http://www.denx.de/wiki/view/DULG/LinuxPostMortemAnalysis

Finally a wild guess - did you include a "-b 0" option when compiling
your device tree?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Anyone who isn't confused here doesn't really know what's going on.