[coreboot] alix.2c3 stops at mainboard_pre_payload: done

Peter Stuge peter at stuge.se
Wed Oct 8 01:16:44 CEST 2008

Hi Roman,

Mail Lists wrote:
> I'm experimenting with alix.2c3 here, but have no luck.
> I tried coreboot v3 (r870, r898) with filo (r64, r80) and coreinfo
> (r3640) payloads (with libpayload r3640). All ends up with following:
> last n-lines snippet (can do full log if it's needed)

Please do send the full log.

> LAR: File not found!
> LAR: load_file: No such file 'normal/payload/segment2'

This can look ominous but v3 does not know how many segments there
are in the payload and will try to load them in order until one can't
be found.

> Don't know what this actually means.

coreboot seems to stop in the middle of writing tables to RAM.

> Did anybody have this kind of problem?

I haven't seen this particular problem before.

> Is there any know-how to make it work? Or does it actually work at
> all?

I successfully use v3 on alix1c and several others have used at least
some version on 2c boards.

How are you building coreboot?

If you're not using buildrom, you need some LAR know-how because the
v3 build process is a bit broken in that it does not include the VSA
into the resulting larball (coreboot.rom) automatically. The magic
command is:

lar -C lzma -a build/coreboot.rom amd_vsa_lx_1.01.bin:blob/vsa

amd_vsa_lx_1.01.bin needs to be 57504 bytes, if it is smaller you
need to uncompress it. Downloading
and renaming it to exclude the .gz extension produces the correct
file here.

$ md5sum amd_vsa_lx_1.01.bin 
0f4fd87b3eef78bd90b56a39646f5845  amd_vsa_lx_1.01.bin

It seems AMD's web server is decompressing .gz files before they are
sent to the client, without changing the filename.


More information about the coreboot mailing list