coreboot July 2011

coreboot@coreboot.org

52 participants
244 discussions

#179: Coreboot on GigaByte GA-8IEXP ver. 1.2

by coreboot

#179: Coreboot on GigaByte GA-8IEXP ver. 1.2 ------------------------------+---------------------------------- Reporter: BlackSheep0@… | Owner: stepan@… Type: enhancement | Status: new Priority: minor | Milestone: Going mainstream Component: coreboot | Keywords: Dependencies: | Patch Status: there is no patch ------------------------------+---------------------------------- Hi, I know the main goal is to bring coreboot on most systems and I don't need to open an extra Call for that :) But I have not the programming skills to do that by myself... If someone can do that for me, I can do a lot of testing because this Mainboard has a Dual BIOS and I can quick switch between Normal BIOS and Coreboot and of course recover if something dosn't work correct ;-) Thanks and Regards -- Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/179> coreboot <http://www.coreboot.org/>

9 years, 8 months

#177: Not compiling coreBoot

by coreboot

#177: Not compiling coreBoot -----------------------------+---------------------------------- Reporter: darkshvein@… | Owner: stepan@… Type: defect | Status: new Priority: major | Milestone: Component: coreboot | Keywords: compile error Dependencies: | Patch Status: there is no patch -----------------------------+---------------------------------- Вылетает с такой ошибкой CC lib/cbfs.ramstage.o cc1: warnings being treated as errors src/southbridge/amd/rs780/rs780.c: In function ‘rs780_enable’: src/southbridge/amd/rs780/rs780.c:193:8: error: ‘pcie_mmio_save$lo’ may be used uninitialized in this function src/southbridge/amd/rs780/rs780.c:193:8: error: ‘pcie_mmio_save$hi’ may be used uninitialized in this function make: *** [build/southbridge/amd/rs780/rs780.driver.o] Ошибка 1 I tried also CC=gcc-4.4 and 4.3 и 4.5 .config: http://pastebin.com/iLVM9u80 OS ubuntu 11.04, last updates. -- Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/177> coreboot <http://www.coreboot.org/>

9 years, 8 months

#178: linux kernel hang while boot from SATA SSD on EPIA CN

by coreboot

#178: linux kernel hang while boot from SATA SSD on EPIA CN -------------------------------+---------------------------------- Reporter: ryzhovsergey@… | Owner: stepan@… Type: defect | Status: new Priority: major | Milestone: Component: coreboot | Keywords: SATA SSD EPIA CN Dependencies: | Patch Status: there is no patch -------------------------------+---------------------------------- I use seabios as payload. After grub2 continue booting process, linux kernel cannot boot from SATA SSD (OCZ Vertex Turbo 32Gb)on EPIA CN Errors with IRQ I try 2.6.33 and 2.6.38 kernels, but with original BIOS all works. -- Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/178> coreboot <http://www.coreboot.org/>

9 years, 8 months

#162: Move SYSTEM_TYPE to Kconfig

by coreboot

#162: Move SYSTEM_TYPE to Kconfig ----------------------------+----------------------------------------------- Reporter: oxygene | Owner: oxygene Type: enhancement | Status: new Priority: minor | Milestone: Component: coreboot | Keywords: Dependencies: | Patchstatus: there is no patch ----------------------------+----------------------------------------------- SYSTEM_TYPE is used to tell coreboot if the board is "server", "desktop" or "laptop". It's only used for AMD for now, but could also be used elsewhere to tweak configuration (and there's a flag in some table, maybe ACPI, that tells the OS about the system type, too). It's defined for some boards, there's a default defined somewhere in the code, that looks a lot like a good match for Kconfig. -- Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/162> coreboot <http://www.coreboot.org/>

9 years, 8 months

Re: [coreboot] DL145 G1 with dual dualcore CPU using coreboot ?

by Oskar Enoksson

Oskar Enoksson wrote: > Myles Watson wrote: > >>> I think Myles was right, there is a i2c mux in this server that somehow >>> multiplexes DIMM devices on the i2c bus. I was able to guess which i2c >>> ports contain the DIMM info, and which port is the mux, then added the >>> mux to devicetree.cb and the DIMM ports under it. Now I'm able to use >>> memory from both CPU's, at least for the combination of DIMM's I have >>> (2x2x1GB and 2x2x512MB). >>> >>> >> I'm glad it worked out! >> >> >>> So I'm basically able to use these servers now. I would love to have >>> ACPI and Cool'nQuiet of course, perhaps I'll try to do that later. >>> >>> Thanks very much for all help! If you want me to commit the new >>> mainboard to your svn repository let me know. >>> >>> >> Yes, please. If you'll send your latest patch with a Signed-off-by: line, >> I'll take it from there. >> >> Thanks, >> Myles >> >> > I hope this file is the way you want it. I did "svn cp > src/mainboard/tyan/s2881 src/mainboard/hp/dl145_g1" and then modified > the files, then "svn diff src/mainboard" so I assume you should do the > same svn cp operation, then apply my patch, then commit to retain the > original files' history. > I have fixed several problems and now it boots reliably for both and older dual Opteron 248 server and an upgraded dual Opteron 280 server. memtest86+ doesn't work, but according to another mailinglist thread memtest cannot handle tables in high memory, so that seems to be a memtest issue. Attached is a cleaned-up patch. Thanks to Myles and others for excellent help and support. I hope someone finds the result useful.

9 years, 10 months

I865 memory controller status

by James Wall

Hello all, What is the status of the i865 memory controller? I have a board that all the other chips are supported but the memory controller is a big question mark.

9 years, 10 months

Reference stub for CB signature detection?

by Philip Prindeville

I'm writing a Linux platform driver for a couple of Geode based boards, and was thinking that it would be nice if there was a canonical/prototypical stub routine that came with coreboot that detected the signature on a target system. That is, I could paste this code into a platform driver (for instance) in Linux that would locate the mainboard vendor and model, and I could use that to confirm that I'm running on the correct target and not a mismatched kernel configuration. I looked at flashrom's coreboot_init() and find_lb_table() and it looks like something could be cobbled from there. Can someone please piece that together? Thanks, -Philip

9 years, 11 months

Breakage in building traverse/geos

by Philip Prindeville

I'm seeing breakage when building traverse/geos. Is this a known issue? [philipp@builder ~/coreboot]$ make V=1 ... CC romstage.inc gcc -m32 -Wa,--divide -fno-stack-protector -Wl,--build-id=none -MMD -Isrc -Isrc/include -Ibuild -Isrc/arch/x86/include -Isrc/devices/oprom/include -include /home/philipp/coreboot/build/config.h -Os -pipe -g -nostdinc -nostdlib -Wall -Wundef -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -Wredundant-decls -Wno-trigraphs -Wstrict-aliasing -Wshadow -Werror -fno-common -ffreestanding -fno-builtin -fomit-frame-pointer -D__PRE_RAM__ -Isrc -I. -Ibuild -c -S src/mainboard/traverse/geos/romstage.c -o build/mainboard/traverse/geos/romstage.pre.inc POST romstage.inc sed -e 's/\.rodata/.rom.data/g' -e 's/\.text/.section .rom.text/g' build/mainboard/traverse/geos/romstage.pre.inc > build/mainboard/traverse/geos/romstage.inc.tmp mv build/mainboard/traverse/geos/romstage.inc.tmp build/mainboard/traverse/geos/romstage.inc GEN crt0.S printf '#include "config.h"\n #include "src/arch/x86/init/prologue.inc"\n #include "src/cpu/x86/16bit/entry16.inc"\n #include "src/cpu/x86/32bit/entry32.inc"\n #include "src/cpu/x86/16bit/reset16.inc"\n #include "src/arch/x86/lib/id.inc"\n #include "src/cpu/x86/fpu_enable.inc"\n #include "src/cpu/amd/model_lx/cache_as_ram.inc"\n #include "mainboard/traverse/geos/romstage.inc"\n' > build/crt0.S CC mainboard/traverse/geos/crt0.s gcc -m32 -Wa,--divide -fno-stack-protector -Wl,--build-id=none -MMD -x assembler-with-cpp -E -Isrc/include -Isrc/arch/x86/include -Ibuild -include build/config.h -I. -Isrc build/crt0.S -o build/mainboard/traverse/geos/crt0.s CC mainboard/traverse/geos/crt0.romstage.o gcc -m32 -Wa,--divide -fno-stack-protector -Wl,--build-id=none -MMD -Ibuild -Wa,-acdlns -c -o build/mainboard/traverse/geos/crt0.romstage.o build/mainboard/traverse/geos/crt0.s > build/mainboard/traverse/geos//crt0.disasm build/mainboard/traverse/geos/crt0.s: Assembler messages: build/mainboard/traverse/geos/crt0.s:444: Error: junk at end of line, first unrecognized character is `.' build/mainboard/traverse/geos/crt0.s:4287: Error: junk at end of line, first unrecognized character is `.' make: *** [build/mainboard/traverse/geos/crt0.romstage.o] Error 1 [philipp@builder ~/coreboot]$ sed -n -e 444p -e 4287p build/mainboard/traverse/geos/crt0.s .section .section .rom.text.unlikely,"ax",@progbits .section .section .rom.text.startup,"ax",@progbits [philipp@builder ~/coreboot]$ which means that we're seeing: .section .text.unlikely,"ax",@progbits .section .test.startup,"ax",@progbits in the input stream before transformation.

9 years, 12 months

Where can I get CMC of us15w?

by bbsbill

hi, everyone. my motherboard is uefi-based, not legacy bios, how to dump cmc from the bios file? And what size of the cmc? thanks.

9 years, 12 months

#180: ASRock E350M1 Gigabit Ethernet Problem

by coreboot

#180: ASRock E350M1 Gigabit Ethernet Problem -------------------------+------------------------------------------- Reporter: HowardK | Owner: stepan@… Type: defect | Status: new Priority: major | Milestone: Component: coreboot | Keywords: e350m1, ethernet, family14 Dependencies: | Patch Status: there is no patch -------------------------+------------------------------------------- I see slow data reception with the onboard gigabit ethernet NIC on the ASRock E350M1 with coreboot. Using SeaBios payload to boot Debian testing with 2.6.29 kernel. To reproduce, try the following data transmission test (with a gigabit switch obviously). Note that for speed this is all done in memory -- the transmitted data is not read from or written to HDD which might slow things down. 1) First on the receiving computer (the e350m1) do user@e350m1:~ $ nc -l -p 3640 | cat > /dev/null 2) Then on the sending computer (other) do: user@other:~ $ dd if=/dev/zero bs=1M count=1024 | nc e350m1 3640 The data reception rate is only 5.0 to 11 MB/s rather than around 100MB/s expected for gigabit ethernet. Transmission in the other direction seems to work at the full rate. The vendor firmware works as expected. After this test I seem to require a complete power off (i.e. PSU off) to recover. (Aside: is the NIC not being properly reset on boot I wonder?). dmesg shows the messages below. (NOHZ messages from kernel/time/tick- sched.c and rate limit messages are from lib/ratelimit.c). Does anyone know what is wrong? [ 361.320382] r8169 0000:03:00.0: eth0: link up [ 361.320404] NOHZ: local_softirq_pending 08 [ 361.348378] r8169 0000:03:00.0: eth0: link up [ 361.348912] NOHZ: local_softirq_pending 08 [ 361.560381] r8169 0000:03:00.0: eth0: link up [ 361.560403] NOHZ: local_softirq_pending 08 [ 361.660383] r8169 0000:03:00.0: eth0: link up [ 361.660406] NOHZ: local_softirq_pending 08 [ 361.736372] r8169 0000:03:00.0: eth0: link up [ 361.736395] NOHZ: local_softirq_pending 08 [ 361.760380] r8169 0000:03:00.0: eth0: link up [ 361.760400] NOHZ: local_softirq_pending 08 [ 361.816372] r8169 0000:03:00.0: eth0: link up [ 361.816395] NOHZ: local_softirq_pending 08 [ 361.884372] r8169 0000:03:00.0: eth0: link up [ 361.884395] NOHZ: local_softirq_pending 08 [ 361.980380] r8169 0000:03:00.0: eth0: link up [ 361.980399] NOHZ: local_softirq_pending 08 [ 362.000383] r8169 0000:03:00.0: eth0: link up [ 362.000401] NOHZ: local_softirq_pending 08 [ 366.396372] net_ratelimit: 75 callbacks suppressed [ 366.396383] r8169 0000:03:00.0: eth0: link up [ 366.492373] r8169 0000:03:00.0: eth0: link up [ 366.560257] r8169 0000:03:00.0: eth0: link up [ 366.656147] r8169 0000:03:00.0: eth0: link up [ 366.680373] r8169 0000:03:00.0: eth0: link up [ 366.748156] r8169 0000:03:00.0: eth0: link up [ 366.800379] r8169 0000:03:00.0: eth0: link up [ 366.868371] r8169 0000:03:00.0: eth0: link up [ 366.928372] r8169 0000:03:00.0: eth0: link up [ 367.024373] r8169 0000:03:00.0: eth0: link up [ 371.548370] net_ratelimit: 77 callbacks suppressed [ 371.548381] r8169 0000:03:00.0: eth0: link up [ 371.604370] r8169 0000:03:00.0: eth0: link up ... ... -- Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/180> coreboot <http://www.coreboot.org/>

9 years, 12 months

Jump to page:

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot July 2011