I was wondering if anyone could help me with a couple problems I'm having building Coreboot at the moment. Foremost, since I upgraded to SVN revision 4426, I've been unable to generate the stripped form of my BIOS in this or a previously working very old edition (circa revision 2539 when things were still LinuxBIOS). What happens is the build is dying at the objcopy step which is meant to strip the coreboot binary before appending the boot loader binary. Specifically, here is what I see from the generation of the CRT0 file to the end:
-------- gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld crt0.o /usr/bin/ld: warning: dot moved backwards before `.text' /usr/bin/ld: warning: dot moved backwards before `.id' /usr/bin/ld: warning: dot moved backwards before `.text' /usr/bin/ld: warning: dot moved backwards before `.id' /usr/bin/ld: warning: dot moved backwards before `.text' /usr/bin/ld: warning: dot moved backwards before `.id' nm -n linuxbios | sort > linuxbios.map objcopy --gap-fill 0xff -R .note.gnu.build-id -O binary linuxbios linuxbios.strip objcopy: linuxbios.strip: Bad value objcopy: linuxbios.strip: Bad value make[1]: *** [linuxbios.strip] Error 1 make[1]: Leaving directory `/home/jacobs/LinuxBIOS-v2-GRUB-PTR/targets/arcom/apollo/apollo/image' make: *** [image/linuxbios.rom] Error 1 --------
Clearly, the objcopy is failing with some generic error of "Bad Value". So, I ran a strace on this command which I've edited for space and appended to this message below.
Secondly, I'm having a problem with the latest romcc. First of all, I cannot pass simple_test26 (I'll spare you the verbose error message here except to say that the final error is "too few registers". I changed the first line in romcc/tests/simple_test26.c from defining COUNT as 23 to 15 and that seems to work; I take it my platform only has 15 free registers; any more than that and I get the same error. Secondly, I can't seem to build simple_test87. There is no romcc/tests/simple_test87.c file and so when I try to compile romcc, I get the following message:
make: *** No rule to make target `tests/simple_test87.c', needed by `tests/simple_test87.S-O2-mmmx'. Stop.
Anyway, so those are the issues I'm seeing with the latest Coreboot. Am I alone in this? Can anyone help me here? I'm ignoring the problems with the romcc tests since I'm guessing that's okay as long as the register count is no more than 15. But the problem with objcopy is very mysterious so any and all help would be greatly appreciated. Thanks in advance.
Jeffrey.
----Transcript of strace performed on `objcopy ... coreboot.strip`---- execve("/usr/bin/objcopy", ["objcopy", "--gap-fill", "0xff", "-O", "binary", "coreboot", "coreboot.strip"], [/* 187 vars */]) = 0 brk(0) = 0x9999000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=53996, ...}) = 0 mmap2(NULL, 53996, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fde000 close(3) = 0 open("/usr/lib/libbfd-2.17.50.0.6-9.el5.so", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240\3760\0004\0\0\0"..., 512) = 512 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fdd000 fstat64(3, {st_mode=S_IFREG|0755, st_size=597048, ...}) = 0 mmap2(0x2fc000, 615280, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2fc000 mmap2(0x388000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x8b) = 0x388000 mmap2(0x38f000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x38f000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\277\34\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1606808, ...}) = 0 mmap2(0x1b6000, 1324452, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x1b6000 mmap2(0x2f4000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13e) = 0x2f4000 mmap2(0x2f7000, 9636, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2f7000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fdc000 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7fdc6c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 mprotect(0x2f4000, 8192, PROT_READ) = 0 mprotect(0x1b2000, 4096, PROT_READ) = 0 munmap(0xb7fde000, 53996) = 0 brk(0) = 0x9999000 brk(0x99ba000) = 0x99ba000 stat64("coreboot", {st_mode=S_IFREG|0755, st_size=94174, ...}) = 0 open("coreboot", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0755, st_size=94174, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7feb000 _llseek(3, 0, [0], SEEK_SET) = 0 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\260&\0\0004\0\0\0"..., 4096) = 4096 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 _llseek(3, 69632, [69632], SEEK_SET) = 0 read(3, "\0.symtab\0.strtab\0.shstrtab\0.ram\0"..., 4096) = 4096 _llseek(3, 73728, [73728], SEEK_SET) = 0 _llseek(3, 73728, [73728], SEEK_SET) = 0 _llseek(3, 0, [0], SEEK_SET) = 0 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\260&\0\0004\0\0\0"..., 4096) = 4096 _llseek(3, 69632, [69632], SEEK_SET) = 0 read(3, "\0.symtab\0.strtab\0.shstrtab\0.ram\0"..., 4096) = 4096 stat64("coreboot.strip", 0xbfc24900) = -1 ENOENT (No such file or directory) open("coreboot.strip", O_RDWR|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 4 _llseek(3, 73728, [73728], SEEK_SET) = 0 read(3, "]\5\0\0\250\6\0\0\0\0\0\0\0\0\2\0c\5\0\0\257\6\0\0\0\0\0\0\0\0\2\0"..., 8192) = 8192 read(3, "]\21\0\0\265 \0\0\0\0\0\0\0\0\2\0c\21\0\0\304 \0\0\0\0\0\0\0\0\2\0"..., 4096) = 4096 read(3, "36\0L1038\0L1766\0L1039\0L1767\0L1044"..., 4096) = 4096 read(3, "1712\0L1717\0L1713\0L1714\0L1715\0L17"..., 4096) = 4062 brk(0x99e4000) = 0x99e4000 _llseek(3, 8192, [8192], SEEK_SET) = 0 read(3, "\30\371\1\0\177\373\366\377\372.\17\1\0257A\0\0\352\20@\4\20\0\270\30\5\0\216\330\216\300\216"..., 45056) = 45056 read(3, "(B|\304c\273u:Q\216\2621\0211 2Xl\305\"S\326i\207^\304\370\260ZFi"..., 4096) = 4096 fstat64(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fea000 _llseek(4, 4294905856, [4294905856], SEEK_SET) = 0 read(4, "", 2384) = 0 _llseek(4, 2384, [4294908240], SEEK_CUR) = 0 write(4, "\30\371\1\0\177\373\366\377\372.\17\1\0257A\0\0\352\20@\4\20\0\270\30\5\0\216\330\216\300\216"..., 45056) = 45056 brk(0x99d9000) = 0x99d9000 read(3, "\275\302$\0\0\353'f\272\375\3\354\17\266\370\203\347 \205\377t\361f\272\370\3\211\350\356f\272\375"..., 8192) = 8192 read(3, "\17n\307\203\3779~\17\203\307'f\17n\307f\17\333\5\200#\0\0f\272\375\3\354\17\266\370\203"..., 4096) = 4096 write(2, "objcopy: coreboot.strip: Bad val"..., 35) = 35 write(4, "(B|\304c\273u:Q\216\2621\0211 2Xl\305\"S\326i\207^\304\370\260ZFi"..., 2917) = 2917 _llseek(4, 0, [0], SEEK_SET) = 0 read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 _llseek(4, -1298, [2798], SEEK_CUR) = 0 write(4, "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., 8192) = 8192 write(4, "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., 4096) = 4096 ----Repeat 1,048,558 times (including the one above)---- write(2, "objcopy: coreboot.strip: Bad val"..., 35) = 35 write(4, "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., 3682) = 3682 close(4) = 0 munmap(0xb7fea000, 4096) = 0 stat64("coreboot.strip", {st_mode=S_IFREG|0644, st_size=4294956213, ...}) = 0 umask(0) = 022 umask(022) = 0 chmod("coreboot.strip", 0755) = 0 close(3) = 0 munmap(0xb7feb000, 4096) = 0 brk(0x99ca000) = 0x99ca000 lstat64("coreboot.strip", {st_mode=S_IFREG|0755, st_size=4294956213, ...}) = 0 unlink("coreboot.strip") = 0 exit_group(1) = ? --------
On Thu, Jul 16, 2009 at 6:55 AM, Jeffrey C. Jacobs jacobs@itd.nrl.navy.milwrote:
I was wondering if anyone could help me with a couple problems I'm having building Coreboot at the moment. Foremost, since I upgraded to SVN revision 4426, I've been unable to generate the stripped form of my BIOS in this or a previously working very old edition (circa revision 2539 when things were still LinuxBIOS). What happens is the build is dying at the objcopy step which is meant to strip the coreboot binary before appending the boot loader binary. Specifically, here is what I see from the generation of the CRT0 file to the end:
gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld crt0.o /usr/bin/ld: warning: dot moved backwards before `.text' /usr/bin/ld: warning: dot moved backwards before `.id' /usr/bin/ld: warning: dot moved backwards before `.text' /usr/bin/ld: warning: dot moved backwards before `.id' /usr/bin/ld: warning: dot moved backwards before `.text' /usr/bin/ld: warning: dot moved backwards before `.id'
I haven't seen these warnings. Are they the cause?
nm -n linuxbios | sort > linuxbios.map objcopy --gap-fill 0xff -R .note.gnu.build-id -O binary linuxbios linuxbios.strip objcopy: linuxbios.strip: Bad value objcopy: linuxbios.strip: Bad value make[1]: *** [linuxbios.strip] Error 1 make[1]: Leaving directory `/home/jacobs/LinuxBIOS-v2-GRUB-PTR/targets/arcom/apollo/apollo/image' make: *** [image/linuxbios.rom] Error 1
I haven't seen anything like this myself. Do all boards fail for you, or is it just this one? Abuild still passes all the boards for me.
Thanks, Myles
Thanks for your reply, Myles!
Myles Watson wrote:
On Thu, Jul 16, 2009 at 6:55 AM, Jeffrey C. Jacobs <jacobs@itd.nrl.navy.mil mailto:jacobs@itd.nrl.navy.mil> wrote:
-------- gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld crt0.o /usr/bin/ld: warning: dot moved backwards before `.text' /usr/bin/ld: warning: dot moved backwards before `.id' /usr/bin/ld: warning: dot moved backwards before `.text' /usr/bin/ld: warning: dot moved backwards before `.id' /usr/bin/ld: warning: dot moved backwards before `.text' /usr/bin/ld: warning: dot moved backwards before `.id'I haven't seen these warnings. Are they the cause?
Well, I just tried to build the Tyan S1846 board and got these warnings for CRT0:
/usr/bin/ld: warning: dot moved backwards before `.id' /usr/bin/ld: warning: dot moved backwards before `.id' /usr/bin/ld: warning: dot moved backwards before `.id'
So I guess that may be a red herring since...
nm -n linuxbios | sort > linuxbios.map objcopy --gap-fill 0xff -R .note.gnu.build-id -O binary linuxbios linuxbios.strip objcopy: linuxbios.strip: Bad value objcopy: linuxbios.strip: Bad value make[1]: *** [linuxbios.strip] Error 1 make[1]: Leaving directory `/home/jacobs/LinuxBIOS-v2-GRUB-PTR/targets/arcom/apollo/apollo/image' make: *** [image/linuxbios.rom] Error 1I haven't seen anything like this myself. Do all boards fail for you, or is it just this one? Abuild still passes all the boards for me.
... the Tyan S1846 DOES pass the objcopy step so it looks to be specific to my target (the arcom/apollo board). The funny thing is, this was all working before I updated to the latest version (though I could never boot past the jump to boot loader step before). I should also note in the strace I originally attached that objcopy literally tries to write like 4GB of 0xFF before dying if that helps. In fact, it prints one Bad value before the massive write, and one after. Also, to be clear, the strace I attached was for my build of the latest Coreboot, not from my old LinuxBIOS and that I get the same error for both the old and current edition.
Thanks again!
Jeffrey.
On Thu, Jul 16, 2009 at 8:33 AM, Jeffrey C. Jacobs jacobs@itd.nrl.navy.milwrote:
Thanks for your reply, Myles!
No problem.
Myles Watson wrote:
On Thu, Jul 16, 2009 at 6:55 AM, Jeffrey C. Jacobs < jacobs@itd.nrl.navy.mil mailto:jacobs@itd.nrl.navy.mil> wrote:
gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld crt0.o /usr/bin/ld: warning: dot moved backwards before `.text' /usr/bin/ld: warning: dot moved backwards before `.id' /usr/bin/ld: warning: dot moved backwards before `.text' /usr/bin/ld: warning: dot moved backwards before `.id' /usr/bin/ld: warning: dot moved backwards before `.text' /usr/bin/ld: warning: dot moved backwards before `.id'
I haven't seen these warnings. Are they the cause?
Well, I just tried to build the Tyan S1846 board and got these warnings for CRT0:
/usr/bin/ld: warning: dot moved backwards before `.id' /usr/bin/ld: warning: dot moved backwards before `.id' /usr/bin/ld: warning: dot moved backwards before `.id'
No .text warnings, though.
So I guess that may be a red herring since...
Could be, but they still look suspicious to me.
... the Tyan S1846 DOES pass the objcopy step so it looks to be specific to my target (the arcom/apollo board). The funny thing is, this was all working before I updated to the latest version (though I could never boot past the jump to boot loader step before). I should also note in the strace I originally attached that objcopy literally tries to write like 4GB of 0xFF before dying if that helps.
I would say that sounds like a negative number. So if you're telling it to fill a negative amount of space with 0xff...
Maybe start by comparing ldscripts and offsets between the S1846 and your board? Try removing the gap-fill parameter to narrow it down?
Good luck, Myles
Myles Watson wrote:
On Thu, Jul 16, 2009 at 8:33 AM, Jeffrey C. Jacobs <jacobs@itd.nrl.navy.mil mailto:jacobs@itd.nrl.navy.mil> wrote:
Myles Watson wrote: On Thu, Jul 16, 2009 at 6:55 AM, Jeffrey C. Jacobs <jacobs@itd.nrl.navy.mil <mailto:jacobs@itd.nrl.navy.mil> <mailto:jacobs@itd.nrl.navy.mil <mailto:jacobs@itd.nrl.navy.mil>>> wrote: Well, I just tried to build the Tyan S1846 board and got these warnings for CRT0:No .text warnings, though.
So I guess that may be a red herring since...Could be, but they still look suspicious to me.
I'll keep that in mind, thanks...
I would say that sounds like a negative number. So if you're telling it to fill a negative amount of space with 0xff... Maybe start by comparing ldscripts and offsets between the S1846 and your board? Try removing the gap-fill parameter to narrow it down?
I tried turning off the gap fill and got past the "Bad value" error and was able to produce a coreboot.strip file which turned out to be EXACTLY 2**32 bytes in size. I like your accidental negative idea though given that it is exactly 2**32, I think it may actually be an accidental 0. I wonder, were any new CONFIG_* parameters added in the last couple months? When I converted over, I searched all my old .lb parameters for any reference to the non-CONFIG form and am pretty sure I got them all, but if any were added that I didn't take into account, that may be the cause of my error in the latest Coreboot, though it wouldn't explain why I'm getting the same "Bad value" error on the older LinuxBIOS build. Also, what happens when I set CONFIG_ROM_IMAGE_SIZE to 0x0C000 if the coreboot ROM turns out to be bigger than 49152? What is a typically size for the coreboot ROM? I made the ROM Image Size so small because I only have a 256kB flash and GRUB2 with modules turned out to be a bit over 128kB (153900 Bytes). So, have I made a nubie mistake? I could have sworn this was working before I updated but if tweaking sizes here and there is the solution, that's what I'll try.
Thanks again Myles!
Jeffrey.
The cause of a 2^32 file can be that gcc has been upgraded and is generating new section names that are not covered in our ldscripts. I fixed this problem recently in another context. The new sections will get linked at address 0.
I think your accidental 0 idea is correct. Can you do a readelf on the various coreboot files and look for a section name that is not in the ldscripts?
ron
ron minnich wrote:
The cause of a 2^32 file can be that gcc has been upgraded and is generating new section names that are not covered in our ldscripts. I fixed this problem recently in another context. The new sections will get linked at address 0.
I think your accidental 0 idea is correct. Can you do a readelf on the various coreboot files and look for a section name that is not in the ldscripts?
ron
Actually, I solved this by just making the BIOS a little bigger. Myles was right to be suspicious of the missing text sections as they were getting chopped off due to the BIOS not fitting in the space I alloted it in the Config.ld script. I just upped it from like 48k to 64k and it linked just fine. Thanks for your help though Ron!
Take care,
Jeffrey.
-
Jeffrey C. Jacobs -
Myles Watson -
ron minnich