r3138 build service

[coreboot information]

Dear coreboot readers!

This is the automated build check service of coreboot.

The developer "uwe" checked in revision 3138 to
the coreboot source repository and caused the following 
changes:

Change Log:
Also print the required -m option in --list-supported output (trivial).

Signed-off-by: Uwe Hermann 
Acked-by: Uwe Hermann

Build Log:
Compilation of amd:serengeti_cheetah_fam10 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3138&device=serengeti_c...
Compilation of rca:rm4100 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3138&device=rm4100&...

If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

Best regards,
     coreboot automatic build system

> Compilation of rca:rm4100 is still broken
> See the error log at   
> http://qa.coreboot.org/log_buildbrd.php?revision=3138&device=rm4100&...
>
> If something broke during this checkin please be a pain
> in uwe's neck until the issue is fixed.

Why is this failing?? The log looks like there is an error in  
rom_stream.c?? And it is in the "normal" directory? But I don't have a  
"normal" build just "fallback"?? Could this be one of the changes you  
made Uwe?
I'm a little confused by this??

Thanks - Joe

[Uwe Hermann]

On Thu, Mar 13, 2008 at 04:34:02PM -0400, [e-mail] wrote:
> > Compilation of rca:rm4100 is still broken
> > See the error log at   
> > http://qa.coreboot.org/log_buildbrd.php?revision=3138&device=rm4100&...
> >
> > If something broke during this checkin please be a pain
> > in uwe's neck until the issue is fixed.
>
> Why is this failing?? The log looks like there is an error in  
> rom_stream.c?? And it is in the "normal" directory? But I don't have a  
> "normal" build just "fallback"?? Could this be one of the changes you  
> made Uwe?

Don't think so. I've seen this before, I just don't remember what the
fix was. Will look into it.

The symptom is that -DPAYLOAD_SIZE='0x-17000' is passed somewhere, but I
haven't yet found out why exactly this happens and what the root cause is.

Uwe.

Quoting Uwe Hermann :
> On Thu, Mar 13, 2008 at 04:34:02PM -0400, [e-mail] wrote:
> > > Compilation of rca:rm4100 is still broken
> > > See the error log at
> > > http://qa.coreboot.org/log_buildbrd.php?revision=3138&device=rm4100&...
> > >
> > > If something broke during this checkin please be a pain
> > > in uwe's neck until the issue is fixed.
> >
> > Why is this failing?? The log looks like there is an error in
> > rom_stream.c?? And it is in the "normal" directory? But I don't have a
> > "normal" build just "fallback"?? Could this be one of the changes you
> > made Uwe?
>
> Don't think so. I've seen this before, I just don't remember what the
> fix was. Will look into it.
>
> The symptom is that -DPAYLOAD_SIZE='0x-17000' is passed somewhere, but I
> haven't yet found out why exactly this happens and what the root cause is.

Yeh that is very strange. According to the log it is happening in the  
beginning, even before romcc.c, and it is the oppasite of  
-DROM_IMAGE_SIZE='0x17000' -DPAYLOAD_SIZE='0x-17000'

Very strange. It built locally just fine for me....

Thanks - Joe

[Corey Osgood]

On Thu, Mar 13, 2008 at 10:09 PM,  wrote:
> Quoting Uwe Hermann :
> > On Thu, Mar 13, 2008 at 04:34:02PM -0400, [e-mail]:
> > > > Compilation of rca:rm4100 is still broken
> > > > See the error log at
>
> http://qa.coreboot.org/log_buildbrd.php?revision=3138&device=rm4100&...
> > > > If something broke during this checkin please be a pain
> > > > in uwe's neck until the issue is fixed.
> > >
> > > Why is this failing?? The log looks like there is an error in
> > > rom_stream.c?? And it is in the "normal" directory? But I don't have a
> > > "normal" build just "fallback"?? Could this be one of the changes you
> > > made Uwe?
> >
> > Don't think so. I've seen this before, I just don't remember what the
> > fix was. Will look into it.
> >
> > The symptom is that -DPAYLOAD_SIZE='0x-17000' is passed somewhere, but I
> > haven't yet found out why exactly this happens and what the root cause
>
> is.
> >
>
> Yeh that is very strange. According to the log it is happening in the
> beginning, even before romcc.c, and it is the oppasite of
> -DROM_IMAGE_SIZE='0x17000' -DPAYLOAD_SIZE='0x-17000'
>
> Very strange. It built locally just fine for me....
>
> Thanks - Joe

The problem is right here:

from src/rca/rm4100/Config.lb:
if USE_FALLBACK_IMAGE
    default ROM_SECTION_SIZE = FALLBACK_SIZE
    default ROM_SECTION_OFFSET = (ROM_SIZE - FALLBACK_SIZE)
else
    default ROM_SECTION_SIZE = (ROM_SIZE - FALLBACK_SIZE)
    default ROM_SECTION_OFFSET = 0
end
default CONFIG_ROM_PAYLOAD_START = (0xffffffff - ROM_SIZE +
ROM_SECTION_OFFSET + 1)
default PAYLOAD_SIZE = (ROM_SECTION_SIZE - ROM_IMAGE_SIZE)

and from src/rca/rm4100/Options.lb:
default ROM_SIZE = 512 * 1024
default ROM_IMAGE_SIZE = 128 * 1024
default HAVE_FALLBACK_BOOT = 1
default FALLBACK_SIZE = 512 * 1024

abuild ignores the target/*/Config.lb and makes its own, with both a normal
and a fallback image. Since the normal image has USE_FALLBACK_IMAGE = 0, it
uses ROM_SECTION_SIZE = (ROM_SIZE - FALLBACK_SIZE), and since they're both
512k, it comes out to 0. PAYLOAD_SIZE is then (0 - ROM_IMAGE_SIZE). There
are two possible fixes, the first to set FALLBACK_SIZE here to 256k and then
set it to ROM_SIZE in target/'s Config.lb, the second to create a
Config-abuild.lb with just the fallback image. I'm leaning towards the
latter, because this system doesn't have a battery-backed CMOS, so it'd
never boot a normal image anyways.

-Corey

Quoting Corey Osgood :
> On Thu, Mar 13, 2008 at 10:09 PM,  wrote:
> > Quoting Uwe Hermann :
> > > On Thu, Mar 13, 2008 at 04:34:02PM -0400, [e-mail]:
> > > > > Compilation of rca:rm4100 is still broken
> > > > > See the error log at
> >
> > http://qa.coreboot.org/log_buildbrd.php?revision=3138&device=rm4100&...
> > > > > If something broke during this checkin please be a pain
> > > > > in uwe's neck until the issue is fixed.
> > > >
> > > > Why is this failing?? The log looks like there is an error in
> > > > rom_stream.c?? And it is in the "normal" directory? But I don't have a
> > > > "normal" build just "fallback"?? Could this be one of the changes you
> > > > made Uwe?
> > >
> > > Don't think so. I've seen this before, I just don't remember what the
> > > fix was. Will look into it.
> > >
> > > The symptom is that -DPAYLOAD_SIZE='0x-17000' is passed somewhere, but I
> > > haven't yet found out why exactly this happens and what the root cause
> >
> > is.
> > >
> >
> > Yeh that is very strange. According to the log it is happening in the
> > beginning, even before romcc.c, and it is the oppasite of
> > -DROM_IMAGE_SIZE='0x17000' -DPAYLOAD_SIZE='0x-17000'
> >
> > Very strange. It built locally just fine for me....
> >
> > Thanks - Joe
>
> The problem is right here:
>
> from src/rca/rm4100/Config.lb:
> if USE_FALLBACK_IMAGE
>     default ROM_SECTION_SIZE = FALLBACK_SIZE
>     default ROM_SECTION_OFFSET = (ROM_SIZE - FALLBACK_SIZE)
> else
>     default ROM_SECTION_SIZE = (ROM_SIZE - FALLBACK_SIZE)
>     default ROM_SECTION_OFFSET = 0
> end
> default CONFIG_ROM_PAYLOAD_START = (0xffffffff - ROM_SIZE +
> ROM_SECTION_OFFSET + 1)
> default PAYLOAD_SIZE = (ROM_SECTION_SIZE - ROM_IMAGE_SIZE)
>
> and from src/rca/rm4100/Options.lb:
> default ROM_SIZE = 512 * 1024
> default ROM_IMAGE_SIZE = 128 * 1024
> default HAVE_FALLBACK_BOOT = 1
> default FALLBACK_SIZE = 512 * 1024
>
> abuild ignores the target/*/Config.lb and makes its own, with both a normal
> and a fallback image. Since the normal image has USE_FALLBACK_IMAGE = 0, it
> uses ROM_SECTION_SIZE = (ROM_SIZE - FALLBACK_SIZE), and since they're both
> 512k, it comes out to 0. PAYLOAD_SIZE is then (0 - ROM_IMAGE_SIZE). There
> are two possible fixes, the first to set FALLBACK_SIZE here to 256k and then
> set it to ROM_SIZE in target/'s Config.lb, the second to create a
> Config-abuild.lb with just the fallback image. I'm leaning towards the
> latter, because this system doesn't have a battery-backed CMOS, so it'd
> never boot a normal image anyways.

Thanks Corey, good catch:-)

Thanks - Joe