rminnich@lb:~/src/bios/coreboot-v3$ lar l build/bios.bin normal/option_table (1776 bytes @0x50);loadaddress 0x0 entry 0x0 normal/initram/segment0 (24404 bytes @0x790);loadaddress 0x0 entry 0x0x4 normal/stage2/segment0 (195156 bytes, zeroes compressed to 1 bytes @0x6740);loadaddress 0x0xd360 entry 0x0x2000 normal/stage2/segment1 (33781 bytes, lzma compressed to 18404 bytes @0x67a0);loadaddress 0x0x2000 entry 0x0x2000 normal/stage2/segment2 (9036 bytes, lzma compressed to 559 bytes @0xafe0);loadaddress 0x0xb000 entry 0x0x2000 normal/payload/segment0 (30944 bytes, lzma compressed to 18142 bytes @0xb260);loadaddress 0x0x10000 entry 0x0x100b0 bootblock (263635550 bytes @0x6e192) Total size = 263699172 bytes (0xfb7bae4)
Note the size of the bootbock ... is this related to global variables in any way?
ron
rminnich@lb:~/src/bios/coreboot-v3$ lar l build/bios.bin normal/option_table (1776 bytes @0x50);loadaddress 0x0 entry 0x0 normal/initram/segment0 (24404 bytes @0x790);loadaddress 0x0 entry 0x0x4 normal/stage2/segment0 (195156 bytes, zeroes compressed to 1 bytes @0x6740);loadaddress 0x0xd360 entry 0x0x2000 normal/stage2/segment1 (33781 bytes, lzma compressed to 18404 bytes @0x67a0);loadaddress 0x0x2000 entry 0x0x2000 normal/stage2/segment2 (9036 bytes, lzma compressed to 559 bytes @0xafe0);loadaddress 0x0xb000 entry 0x0x2000 normal/payload/segment0 (30944 bytes, lzma compressed to 18142 bytes @0xb260);loadaddress 0x0x10000 entry 0x0x100b0 bootblock (263635550 bytes @0x6e192) Total size = 263699172 bytes (0xfb7bae4)
Note the size of the bootbock ... is this related to global variables in any way?
This looks like a lar -l error to me, or a load address problem. Did you look at the files that got put in there to make sure the bootblock was really 256MB?
Myles
On Mon, Aug 25, 2008 at 3:50 PM, Myles Watson mylesgw@gmail.com wrote:
This looks like a lar -l error to me, or a load address problem. Did you look at the files that got put in there to make sure the bootblock was really 256MB?
The bootblock is 32k. The bios.bin is 512k. It's just the len in the lar that's bogus.
ron
On 26.08.2008 00:51, ron minnich wrote:
On Mon, Aug 25, 2008 at 3:50 PM, Myles Watson mylesgw@gmail.com wrote:
This looks like a lar -l error to me, or a load address problem. Did you look at the files that got put in there to make sure the bootblock was really 256MB?
The bootblock is 32k. The bios.bin is 512k. It's just the len in the lar that's bogus.
LAR bug, then. Can you upload the binary somewhere (or mail it privately) so we can have a look?
Regards, Carl-Daniel
it's easy to recreate actually. Just make the serengeti target with latest v3 release.
lar l build/bios.bin
ron
On 26.08.2008 01:22, ron minnich wrote:
it's easy to recreate actually. Just make the serengeti target with latest v3 release.
lar l build/bios.bin
compiler@p35:/sources/tmptrees/corebootv3-tmp2> build/util/lar/lar -l build/bios.bin normal/option_table (1776 bytes @0x50);loadaddress 0x0 entry 0x0 normal/initram/segment0 (24060 bytes @0x790);loadaddress 0x0 entry 0x0x4 normal/stage2/segment0 (195004 bytes, zeroes compressed to 1 bytes @0x65e0);loadaddress 0x0xe21c entry 0x0x2000 normal/stage2/segment1 (36364 bytes, lzma compressed to 19703 bytes @0x6640);loadaddress 0x0x2000 entry 0x0x2000 normal/stage2/segment2 (8744 bytes, lzma compressed to 563 bytes @0xb390);loadaddress 0x0xbff4 entry 0x0x2000 bootblock (20480 bytes @0x3b000) Total size = 67031B 65KB (0x105d7)
Serengeti, latest svn HEAD. Works for me.
Regards, Carl-Daniel
On Mon, Aug 25, 2008 at 4:26 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
compiler@p35:/sources/tmptrees/corebootv3-tmp2> build/util/lar/lar -l build/bios.bin normal/option_table (1776 bytes @0x50);loadaddress 0x0 entry 0x0 normal/initram/segment0 (24060 bytes @0x790);loadaddress 0x0 entry 0x0x4 normal/stage2/segment0 (195004 bytes, zeroes compressed to 1 bytes @0x65e0);loadaddress 0x0xe21c entry 0x0x2000 normal/stage2/segment1 (36364 bytes, lzma compressed to 19703 bytes @0x6640);loadaddress 0x0x2000 entry 0x0x2000 normal/stage2/segment2 (8744 bytes, lzma compressed to 563 bytes @0xb390);loadaddress 0x0xbff4 entry 0x0x2000 bootblock (20480 bytes @0x3b000) Total size = 67031B 65KB (0x105d7)
Serengeti, latest svn HEAD. Works for me.
oh great. More binutils version madness? OK, I'll try to track this down.
ron
On Mon, Aug 25, 2008 at 4:35 PM, ron minnich rminnich@gmail.com wrote:
oh great. More binutils version madness? OK, I'll try to track this down.
relief. I had an old version of lar in /usr/local/bin .... pilot error.
The bootblock is fine. I still don't see why it's not finding the other LAR entries but will look later.
ron
On 26.08.2008 06:14, ron minnich wrote:
On Mon, Aug 25, 2008 at 4:35 PM, ron minnich rminnich@gmail.com wrote:
oh great. More binutils version madness? OK, I'll try to track this down
relief. I had an old version of lar in /usr/local/bin .... pilot error.
The bootblock is fine. I still don't see why it's not finding the other LAR entries but will look later.
Fill up the LAR with lots of small uncompressed consecutively numbered members. Then you can see from the boot log which member is first to be seen. Try this script:
#!/bin/bash dd if=/dev/zero bs=512 count=1 of=build/blob for ((i=0; i<400; i++)); do build/util/lar/lar -a build/coreboot.rom build/blob:blob$i done
And then look at the boot log for the name of the first visible member. Look up that name with lar -l build/coreboot.rom and you have the address of the first visible member. Simple.
Regards, Carl-Daniel
turns out it is still simnow not seeing any but the last 64k of flash.
ron
-
Carl-Daniel Hailfinger -
Myles Watson -
ron minnich