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.
#define POST_STAGE2_ARCH_WRITE_TABLES_MIDDLE 0x96
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 http://www.amd.com/files/connectivitysolutions/geode/geode_lx/amd_vsa_lx_1.0... 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.
//Peter