[coreboot] #164: Building Coreboot v4 r5555/5554 fails mysteriously on Debian lenny and etch (x86)
#164: Building Coreboot v4 r/5554 fails mysteriously on Debian lenny and
etch (x86)
+---
Reporter: j...@… | Owner: ste...@…
Type: defect |Status: new
Priority: major| Milestone:
Component: coreboot | Keywords: makefile, debian
Dependencies: | Patchstatus: there is no patch
+---
I am trying to build Coreboot v4 from SVN with default settings, but I get
build failures. The build environment is Debian Linux on x86.
Process goes as follows:
{{{
- check out coreboot trunk from SVN as per wiki instructions
- run make menuconfig, select QEMU hardware (default), ROM size either
256K or 1M
- run make:
}}}
{{{
coreboot.r5554$ make
HOSTCC util/romcc/romcc (this may take a while)
ROMCC mainboard/emulation/qemu-x86/bootblock.inc
GENbootblock/bootblock.c
CC mainboard/emulation/qemu-x86/bootblock.s
CC mainboard/emulation/qemu-x86/bootblock.o
GENbootblock/ldscript.ld
LINK bootblock.elf
OBJCOPYcoreboot.bootblock
HOSTCC cbfstool/common.o
[..cut..]
HOSTCC util/options/build_opt_tbl
OPTION option_table.h
GENbuild.h
ROMCC romstage.inc
GENromstage/crt0.S
CC mainboard/emulation/qemu-x86/crt0.s
CC mainboard/emulation/qemu-x86/crt0.initobj.o
make: *** No rule to make target `/optbuild/lib/uart8250.initobj.o',
needed by `build/coreboot.romstage'. Stop.
}}}
I have tried this on two separate Debian/lenny machines with the same
results. Is Debian somehow broken or Coreboot build scripts? Or am I
making some mistake? What is this directory /optbuild and why coreboot
build is trying to create/access it? I tried to grep optbuild from the
sources, but it does not seem to exist there.
Trying the same on Debian/etch (older release):
{{{
% make
mkdir: cannot create directory `/optbuild': Permission denied
mkdir: cannot create directory `/optbuild': Permission denied
mkdir: cannot create directory `/optbuild': Permission denied
mkdir: cannot create directory `/optbuild': Permission denied
mkdir: cannot create directory `/optbuild': Permission denied
mkdir: cannot create directory `/optbuild': Permission denied
mkdir: cannot create directory `/optbuild': Permission denied
ROMCC mainboard/emulation/qemu-x86/bootblock.inc
GENbootblock/bootblock.c
CC mainboard/emulation/qemu-x86/bootblock.s
CC mainboard/emulation/qemu-x86/bootblock.o
GENbootblock/ldscript.ld
LINK bootblock.elf
collect2: ld terminated with signal 11 [Segmentation fault]
make: *** [build/bootblock.elf] Error 1
}}}
This looks like broken ld in Debian, or something going wrong in the build
process.
--
Ticket URL: https://tracker.coreboot.org/trac/coreboot/ticket/164
coreboot http://www.coreboot.org/
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [commit] r5525 - in trunk: src/mainboard/a-trend/atc-6220 src/mainboard/a-trend/atc-6240 src/mainboard/abit/be6-ii_v2_0 src/mainboard/amd/db800 src/mainboard/amd/dbm690t src/mainboard/a
On 5/14/10 11:42 PM, Uwe Hermann wrote: On Wed, May 05, 2010 at 03:12:42PM +0200, repository service wrote: Modified: trunk/src/mainboard/a-trend/atc-6220/devicetree.cb == --- trunk/src/mainboard/a-trend/atc-6220/devicetree.cb Wed May 5 14:05:25 2010(r5524) +++ trunk/src/mainboard/a-trend/atc-6220/devicetree.cb Wed May 5 15:12:42 2010(r5525) @@ -1,7 +1,7 @@ chip northbridge/intel/i440bx # Northbridge - device apic_cluster 0 on # APIC cluster + device lapic_cluster 0 on # APIC cluster chip cpu/intel/slot_1 # CPU - device apic 0 on end # APIC + device lapic 0 on end # APIC Shouldn't the comments also read LAPIC cluster and LAPIC here? The comments? I think we should remove them. device lapic_cluster # LAPIC cluster has about the same value as i++; // Post increment i. ie. it does not help the reader in any way that is not written there without the comment. On the contrary, it makes changing the code more effort at no gain. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] #164: Building Coreboot v4 r5555/5554 fails mysteriously on Debian lenny and etch (x86)
#164: Building Coreboot v4 r/5554 fails mysteriously on Debian lenny and etch (x86) +--- Reporter: j...@… | Owner: ste...@… Type: defect |Status: new Priority: major| Milestone: Component: coreboot | Keywords: makefile, debian Dependencies: | Patchstatus: there is no patch +--- Comment(by stepan): This is odd, for some reason $(obj) seems to be set to /optbuild on your system. LD is definitely broken, since it segfaults. But it's something else that reconfigures your build directory to a directory you don't have write permissions to. You need to fix this first - probably the segfault will go away then, too. As for the broken toolchain please use the reference toolchain in coreboot/util/crossgcc. -- Ticket URL: https://tracker.coreboot.org/trac/coreboot/ticket/164#comment:1 coreboot http://www.coreboot.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] #164: Building Coreboot v4 r5555/5554 fails mysteriously on Debian lenny and etch (x86)
#164: Building Coreboot v4 r/5554 fails mysteriously on Debian lenny and etch (x86) +--- Reporter: j...@… | Owner: ste...@… Type: defect |Status: new Priority: major| Milestone: Component: coreboot | Keywords: makefile, debian Dependencies: | Patchstatus: there is no patch +--- Comment(by j...@…): Ok, now I got it. The system is set up so that /home is not a directory but a symlink to /opt/home , which is the real location of home directories. I was doing the build under my home directory and the shell (pwd command) believed it was operating under /home rather than /opt/home. The Coreboot Makefile seems to do some computation on pathnames and in this case it was confused by the symlink along the path. So the end result was in some cases adding an extra prefix /opt to path names, e.g. /optbuild/foo/bar instead of build/foo/bar. As the Makefile seems quite complicated for me, I fixed this by doing a chdir from /home/juhe to /opt/home/juhe, i.e. the same place via a different name, and everything works fine. Thanks for providing the missing clue to solving this! -- Ticket URL: https://tracker.coreboot.org/trac/coreboot/ticket/164#comment:2 coreboot http://www.coreboot.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [flashrom] flashrom command line syntax change
On 13.05.2010 22:26, David Hendricks wrote: On Tue, May 11, 2010 at 10:16 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net wrote -r/-w/-v are followed by a filename. make the accepted command line syntax conform to the man page I like the suggestion. Committed in r998. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] mkelfImage newer kernels
This applies to 2.6.31 2.6.32 kernels for certain, but probably other newer kernels as well. I'm a user of mkelfImage; I am currently unable to get an .ebi generated by mkelfImage to boot properly - I can't load it directly, or via a mechanism like kexec. The moment the command (be it etherboot/gpxe, or kexec) tries to load the kernel, the system immediately reboots. If I directly kexec a kernel (minus mkelfImage), the kernel loads correctly, so it appears the problem is in mkelfImage. Unfortunately, I don't know how to fix it, and I _have_ to use mkelfImage to generate .ebi images for my systems. I've tried 2.6.27, 2.6.31, 2.6.32; of those, 2.6.27 (and older kernels, work fine. 2.6.31 32 results in an .ebi that causes the system to reboot. Any help!? Thanks, Troy Telford -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] mkelfImage newer kernels
Troy Telford wrote: Any help!? 2.6.30 introduced more sections in vmlinux that mkelfImage didn't deal with. Yinghai sent a patch, which was committed to mkelfImage trunk. See if it works for you. svn://coreboot.org/coreboot/trunk/util/mkelfImage http://www.coreboot.org/Mkelfimage //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] mkelfImage newer kernels
On Saturday, May 15, 2010 04:26:03 pm you wrote: On Saturday, May 15, 2010 03:57:52 pm Peter Stuge wrote: Troy Telford wrote: and then kexec it, the system immediately reboots. Just a quick clarification: By immediately reboots, I mean I'm sent back to the BIOS/POST screen, instead of the kernel loading. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH][again] 440BX raminit cleanup
A number of cleanups for 440BX raminit code. Resolves a number of TODOs items within, and clarified a number of other TODOs. Change register_values[] from long to u8 (byte). For what we are doing this is sufficient and makes it only 1/4 the size. Remove a hard-coding of SDRAMC register that is redundant and now incorrect, now that SDRAMC is conditioned on SDRAMPWR_4DIMM Kconfig and set through register_values[]. RPS registers are now set in runtime code; remove it from register_values[] table. Bring DUMPNORTH() back. The code it refers to is still there. Move #define of NB up so the DUMPNORTH() macro can use it. Signed-off-by: Keith Hui buu...@gmail.com 440bxraminitcleanup.patch Description: Binary data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] mkelfImage newer kernels
On Saturday, May 15, 2010 03:57:52 pm Peter Stuge wrote: Troy Telford wrote: Any help!? 2.6.30 introduced more sections in vmlinux that mkelfImage didn't deal with. Yinghai sent a patch, which was committed to mkelfImage trunk. See if it works for you. svn://coreboot.org/coreboot/trunk/util/mkelfImage http://www.coreboot.org/Mkelfimage I'm aware of the patch; in fact, I was hoping that it would solve the problem. I downloaded the svn tree, built mkelfImage, and then tested it. Unfortunately, when I ran: ../mkelfImage vmlinuz-2.6.32.12-0.6-default --initrd=initrd-2.6.32.12-0.6- default newtest.ebi and then kexec it, the system immediately reboots. So it seems that more needs to be done. I _wish_ I knew how to do it, but it's well above my current skill level. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] FILO bug disk not seen at ata-0 (Doesn't try to detect on ATA only SIL3114)
Hi Rudolf, Awesome! This fixes booting from SATA on the s2881 for me with Seabios. Before, even with the sii3114 option rom, Seabios never showed the disk as a boot option in the boot menu. Now I don't even need that sii3114 option rom anymore. If you add a Signed-off-By line, this is Acked-by: Ward Vandewege w...@gnu.org Thanks! Ward. On Sun, May 09, 2010 at 12:33:50AM +0200, Rudolf Marek wrote: The sil3114 chip has a class code set to something else then IDE by strap resistor. It took me long time to figure out that this chip is otherwise IDE compatible ;) Try attached patch for coreboot which reprograms it back to IDE mode ;) It should start to work - booting from FILO and from Seabios. Rudolf -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH][again] 440BX raminit cleanup
2010/5/16 Keith Hui buu...@gmail.com A number of cleanups for 440BX raminit code. Resolves a number of TODOs items within, and clarified a number of other TODOs. Change register_values[] from long to u8 (byte). For what we are doing this is sufficient and makes it only 1/4 the size. Remove a hard-coding of SDRAMC register that is redundant and now incorrect, now that SDRAMC is conditioned on SDRAMPWR_4DIMM Kconfig and set through register_values[]. RPS registers are now set in runtime code; remove it from register_values[] table. Bring DUMPNORTH() back. The code it refers to is still there. Move #define of NB up so the DUMPNORTH() macro can use it. Signed-off-by: Keith Hui buu...@gmail.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot Bootlog: http://coreboot.pastebin.com/3WEzs1Jq -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
