coreboot November 2013

coreboot@coreboot.org

53 participants
117 discussions

Firmware Test Suite (fwts) on Abit BF6 coreboot v4 (ACPI)
by Gelip 06 Nov '13

06 Nov '13

Hi. I make Firmware Test Suite (fwts-live) on Abit BF6 coreboot v4 (ACPI) (http://odm.ubuntu.com/fwts-live/) Please check results.html file and write suggestions what fix coreboot code. Thx.

1 0

Re: [coreboot] Help required to boot DUET (Seabios floppy mechanism)
by Scott Duplichan 06 Nov '13

06 Nov '13

Anthony Ross wrote: ]Dear Folks ] ]Thanks for the suggestions. Well this is how I debug ] ]qemu-system-x86_64 -no-kvm -net none -bios build/coreboot.rom ] -s -global isa-serial.iobase=0x3f8 -serial file:/new/serial8.log ] -monitor stdio ] ] (Don' t consider the 8) ] ] ]Please correct me if Im mistaken ] ]By the way by freeze I meant is that the DUET BIOS page gets displayed but it does not ]allow to select anything. If I use the down arrow key there is no effect.......So still ]facing the same problem. ] ] ]Any suggestions... UEFI is not easy to debug. I do see that both PS/2 and USB keyboard support module load messages in your log file: Loading driver at 0x000173D5000 EntryPoint=0x000173D52C0 UsbKbDxe.efi Loading driver at 0x000173C7000 EntryPoint=0x000173C72C0 Ps2KeyboardDxe.efi Though bdsdxe loads... Loading driver at 0x00017428000 EntryPoint=0x000174282C0 BdsDxe.efi ... I do not see its debug messages. You could would step through the code of PlatformBdsInit to see why the messages from UpdateMemoryMap() are not displayed. Thanks, Scott ] ] ]Neo... ] ] ](Attached serial log) ] ] ] ] ]On Wed, Nov 6, 2013 at 4:58 AM, Scott Duplichan <spambucket(a)notabs.org> wrote: ]Anthony Ross wrote: ] ]]Hello Coreboot Folks, ]] ]]Well Thanks for the suggestions. It seems that DUET boots but now a major problem has ]]cropped up. It freezes at the main ]DUET-BIOS page not allowing to perform any further ]operations, like booting a HDD image ]or fingering around the EFI BIOS options. ]Similarly ]If I had the .lzma to the cbfs file name I face the same problem like earlier ]so having ]it as myfloppy.img makes it take ]effect. ]] ]] ]]Any further Ideas about these problems..... ]] ]] ]]Regards.. ]] ]] ]]Neo ]For your freeze problem, how are you debugging? The usual way ]is to enable and capture debug messages written to a serial ]port. I believe the standard Duet settings make it write ]debugging messages to a serial port at 3F8 (115200,8,N,1). ]Because halt for assert is enabled by default on Duet, an ]assert is the most likely reason for a freeze. The assert ]will log details to the serial port. ] ]If your hardware doesn't have a serial port, you can use ]an emulator such as simnow or qemu. A good thing about ]Duet is that it is generic and in theory can run on ]different systems without porting. If I remember correctly, ]the current Duet project can boot to the UEFI shell and ]menu system on AMD simnow using the Solo board model. ] ]I am working on a project to allow Duet to run as a ]coreboot payload, and to fix the major Duet problems. ]It will also continue to support bootable image form. ]It may take me a few weeks to reach the goal of booting ]operating systems in UEFI mode on real hardware though. ] ]Thanks, ]Scott ] ]On Sat, Oct 26, 2013 at 8:01 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote: ]On Thu, Oct 24, 2013 at 12:17:33AM -0500, Scott Duplichan wrote: ]> Scott Duplichan wrote: ]> ]> <..snip..> ]> ]> ]I have no experience with making SeaBIOS boot an embedded floppy ]> ]image. I may be able to give this a try, but I would have to first overcome ]> ]Windows build problems that have crept into both SeaBIOS and coreboot. ]> ]> I tested the SeaBIOS virtual floppy boot with EDK2 Duet and it worked ]> for me. I tested with the ASRock e350M1 project. Here is the cbfstool ]> output: ]Thanks for confirming. ] ]> scott@p67-2600k /D/coreboot/win-build-env-011/coreboot/build ]> $ cbfstool.exe coreboot.rom print ]> coreboot.rom: zd kB, bootblocksize 4096, romsize 1008, offset 0x400000 ]> alignment: 0 bytes ]> ]> Name Offset Type Size ]> cmos_layout.bin 0x0 cmos_layout 1776 ]> pci1002,9802.rom 0x740 optionrom 57856 ]> fallback/romstage 0xe980 stage 345432 ]> fallback/coreboot_ram 0x62f40 stage 203312 ]> fallback/payload 0x949c0 payload 53738 ]> config 0xa1c00 raw 3831 ]> (empty) 0xa2b40 null 3526744 ]> ]> scott@p67-2600k /D/coreboot/win-build-env-011/coreboot/build ]> $ cbfstool.exe coreboot.rom add -f /d/duetfloppy.img -n floppyimg/duetfloppy.img -t ]raw ]FYI, it's also possible to add an lzma compressed image (make sure the ]cbfs filename ends in ".lzma" then). ] ]-Kevin

1 0

Geode VSA bin
by Oliver Schinagl 06 Nov '13

06 Nov '13

Hey list, I'm slowly trying to find time to get coreboot running again on one of my Wyse S10 thinclients. I've found Fijam's blog indicating that a VSA binary was required and that Nils Jacobs was working on them and planning on submitting his work to be upstreamed. What is the status of this? Can we build the Geode target that relies on GX2 VSA or are there still external dependancies that can be obtained somewhere. The sources and toolchains are listed in Fijam's post but he says it's a huge pain to get working. Oliver

1 0

Re: [coreboot] CDIT table is not created
by Prop 395 05 Nov '13

05 Nov '13

Pastebin of log: http://pastebin.com/xjANhWts On Tue, Nov 5, 2013 at 2:32 PM, Prop 395 <prop395(a)gmail.com> wrote: > On a Parmer motherboard, I am hitting the following debug message: > ASSERTION FAILED: file 'src/mainboard/amd/parmer/agesawrapper.c', line > 431 > DmiTable:100123c3, AcpiPstatein: 10010126, AcpiSrat:0,AcpiSlit:0, > Mce:10010988, Cmc:10010a4a,Alib:1001ccd4, AcpiIvrs:0 in > agesawrapper_amdinitlate > agesawrapper_amdinitlate failed: 5 > > I believe this is in CreateDmiRecords() > > What is this and how to fix it? >

1 0

CDIT table is not created
by Prop 395 05 Nov '13

05 Nov '13

On a Parmer motherboard, I am hitting the following debug message: ASSERTION FAILED: file 'src/mainboard/amd/parmer/agesawrapper.c', line 431 DmiTable:100123c3, AcpiPstatein: 10010126, AcpiSrat:0,AcpiSlit:0, Mce:10010988, Cmc:10010a4a,Alib:1001ccd4, AcpiIvrs:0 in agesawrapper_amdinitlate agesawrapper_amdinitlate failed: 5 I believe this is in CreateDmiRecords() What is this and how to fix it?

1 0

Re: [coreboot] Chromebook coreboot sources
by Kyösti Mälkki 05 Nov '13

05 Nov '13

On 05.11.2013 22:11, Duncan Laurie wrote: > On Tue, Nov 5, 2013 at 10:56 AM, Aaron Durbin <adurbin(a)chromium.org> wrote: >> On Tue, Nov 5, 2013 at 12:52 PM, Stefan Reinauer >> <stefan.reinauer(a)coreboot.org> wrote: >>> * Aaron Durbin <adurbin(a)chromium.org> [131105 18:00]: >>>> On Tue, Nov 5, 2013 at 10:55 AM, Kyösti Mälkki <kyosti.malkki(a)gmail.com> wrote: >>>>> Hi >>>>> >>>>> A recent discussion I had about google/stout suggested that with the sources >>>>> from coreboot git, this board is unable to resume from S3 suspend. >>>>> (Argumentation: no EARLY_CBMEM_INIT, no MRC cache, no memory training >>>>> results). >>>>> >>>>> I find it hard to believe this problem would affect production units and I >>>>> tried to locate the sources where this is fixed from chromium git, without >>>>> success. >>>>> >>>>> So this question pops on the surface once again: how do I track down, locate >>>>> and download the specific revision of coreboot sources for a Chromebook >>>>> production unit? I'd like to see fixes like this upstreamed to coreboot git. >>>>> >>>>> As a related topic: Sandy/ivybridge boards have some low-memory writes on S3 >>>>> resume, see use of CBMEM_RESUME_BACKUP and CBMEM_BOOT_MODE in romstage.c. Is >>>>> there some argumentation why these writes are safe and do not corrupt OS >>>>> memory? >>>> >>>> It's my understanding that things are just lucky because Linux >>>> reserves that low memory from its use. >>> >>> Last I checked that memory was marked reserved by coreboot, so Linux >>> should not use it. Did this change? >> >> I think it's up to the chipset code to mark it as reserved. I don't >> recall seeing anything in the sandy/ivy codebase which makes that >> happen. Anyone have a boot log of stout? It'd be really easy to check. >> > > > The kernel will trim this first 4K even if it does not have an > explicit e820 entry, so it ends up looking like it is reserved in > dmesg even if coreboot is (incorrectly) not marking it reserved. > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/x8… > > static void __init trim_bios_range(void) > { > /* > * A special case is the first 4Kb of memory; > * This is a BIOS owned area, not kernel ram, but generally > * not listed as such in the E820 table. > * > * This typically reserves additional memory (64KiB by default) > * since some BIOSes are known to corrupt low memory. See the > * Kconfig help text for X86_RESERVE_LOW. > */ > e820_update_range(0, PAGE_SIZE, E820_RAM, E820_RESERVED); > > /* > * special case: Some BIOSen report the PC BIOS > * area (640->1Mb) as ram even though it is not. > * take them out. > */ > e820_remove_range(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_RAM, 1); > > sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); > } > > This should probably be added to the sandybridge/ivybridge resource > allocation to make it explicit and not rely on the kernel to do it for > us. > > -duncan > Sorry for the noise, I was fooled by dmesg output: e820: BIOS-provided physical RAM map: BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable Only after scrolling bit further I find: e820: update [mem 0x00000000-0x00000fff] usable ==> reserved Table from coreboot is already correct, although I do not understand how that first entry got extended from 0x500 to 0x1000-1. 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM Kyösti

1 0

Re: [coreboot] Chromebook coreboot sources
by Duncan Laurie 05 Nov '13

05 Nov '13

On Tue, Nov 5, 2013 at 10:56 AM, Aaron Durbin <adurbin(a)chromium.org> wrote: > On Tue, Nov 5, 2013 at 12:52 PM, Stefan Reinauer > <stefan.reinauer(a)coreboot.org> wrote: >> * Aaron Durbin <adurbin(a)chromium.org> [131105 18:00]: >>> On Tue, Nov 5, 2013 at 10:55 AM, Kyösti Mälkki <kyosti.malkki(a)gmail.com> wrote: >>> > Hi >>> > >>> > A recent discussion I had about google/stout suggested that with the sources >>> > from coreboot git, this board is unable to resume from S3 suspend. >>> > (Argumentation: no EARLY_CBMEM_INIT, no MRC cache, no memory training >>> > results). >>> > >>> > I find it hard to believe this problem would affect production units and I >>> > tried to locate the sources where this is fixed from chromium git, without >>> > success. >>> > >>> > So this question pops on the surface once again: how do I track down, locate >>> > and download the specific revision of coreboot sources for a Chromebook >>> > production unit? I'd like to see fixes like this upstreamed to coreboot git. >>> > >>> > As a related topic: Sandy/ivybridge boards have some low-memory writes on S3 >>> > resume, see use of CBMEM_RESUME_BACKUP and CBMEM_BOOT_MODE in romstage.c. Is >>> > there some argumentation why these writes are safe and do not corrupt OS >>> > memory? >>> >>> It's my understanding that things are just lucky because Linux >>> reserves that low memory from its use. >> >> Last I checked that memory was marked reserved by coreboot, so Linux >> should not use it. Did this change? > > I think it's up to the chipset code to mark it as reserved. I don't > recall seeing anything in the sandy/ivy codebase which makes that > happen. Anyone have a boot log of stout? It'd be really easy to check. > The kernel will trim this first 4K even if it does not have an explicit e820 entry, so it ends up looking like it is reserved in dmesg even if coreboot is (incorrectly) not marking it reserved. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/x8… static void __init trim_bios_range(void) { /* * A special case is the first 4Kb of memory; * This is a BIOS owned area, not kernel ram, but generally * not listed as such in the E820 table. * * This typically reserves additional memory (64KiB by default) * since some BIOSes are known to corrupt low memory. See the * Kconfig help text for X86_RESERVE_LOW. */ e820_update_range(0, PAGE_SIZE, E820_RAM, E820_RESERVED); /* * special case: Some BIOSen report the PC BIOS * area (640->1Mb) as ram even though it is not. * take them out. */ e820_remove_range(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_RAM, 1); sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); } This should probably be added to the sandybridge/ivybridge resource allocation to make it explicit and not rely on the kernel to do it for us. -duncan

1 0

Re: [coreboot] Chromebook coreboot sources
by Stefan Reinauer 05 Nov '13

05 Nov '13

* Aaron Durbin <adurbin(a)chromium.org> [131105 18:00]: > On Tue, Nov 5, 2013 at 10:55 AM, Kyösti Mälkki <kyosti.malkki(a)gmail.com> wrote: > > Hi > > > > A recent discussion I had about google/stout suggested that with the sources > > from coreboot git, this board is unable to resume from S3 suspend. > > (Argumentation: no EARLY_CBMEM_INIT, no MRC cache, no memory training > > results). > > > > I find it hard to believe this problem would affect production units and I > > tried to locate the sources where this is fixed from chromium git, without > > success. > > > > So this question pops on the surface once again: how do I track down, locate > > and download the specific revision of coreboot sources for a Chromebook > > production unit? I'd like to see fixes like this upstreamed to coreboot git. > > > > As a related topic: Sandy/ivybridge boards have some low-memory writes on S3 > > resume, see use of CBMEM_RESUME_BACKUP and CBMEM_BOOT_MODE in romstage.c. Is > > there some argumentation why these writes are safe and do not corrupt OS > > memory? > > It's my understanding that things are just lucky because Linux > reserves that low memory from its use. Last I checked that memory was marked reserved by coreboot, so Linux should not use it. Did this change? Stefan

2 1

#191: Coreboot:libpayload-size_t conflicting types compiler error
by coreboot 05 Nov '13

05 Nov '13

#191: Coreboot:libpayload-size_t conflicting types compiler error ---------------------------+---------------------------------- Reporter: Pradish | Owner: uwe@… Type: defect | Status: new Priority: blocker | Milestone: Component: libpayload | Keywords: Dependencies: | Patch Status: there is no patch ---------------------------+---------------------------------- Hi I have question related to libpayload, which I am trying to solve, but not able to. I have successfully build the coreboot.rom for QEMU x86. Now when I try to build the libpayload project it throws error. System configuration: Virtual Box –Ubuntu 11.10 version Building for X86 Paltform Earlier I have run the cross toolchain using the command ‘make crossgcc’ and it was succcessfull Error information: /coreboot/payloads/libpayload$ make install CC libpci/libpci.libpci.o In File included from include/libpayload.h:54:0, from libpci/libpci.c:30: include/x86/arch/types.h:56:22: error: conflicting types for 'size_t' In file included from include/libpayload.h:49:0, from libpci/libpci.c:30: /home/pradish/coreboot/util/crossgcc/xgcc/lib/gcc/i386-elf/4.7.2/include/stdded.h:213:23: note: previous declaration of 'size_t' was here make: ***[build/libpci/libpci.libpci.o] Error 1 pradish@pradish-VrtualBox:~/coreboot/paylaods/libpayload$ can you tell me, how to resolve this , I have not done any changes to the source code. Just performed ‘make’ regards pradish -- Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/191> coreboot <http://www.coreboot.org/>

1 2

Chromebook coreboot sources
by Kyösti Mälkki 05 Nov '13

05 Nov '13

Hi A recent discussion I had about google/stout suggested that with the sources from coreboot git, this board is unable to resume from S3 suspend. (Argumentation: no EARLY_CBMEM_INIT, no MRC cache, no memory training results). I find it hard to believe this problem would affect production units and I tried to locate the sources where this is fixed from chromium git, without success. So this question pops on the surface once again: how do I track down, locate and download the specific revision of coreboot sources for a Chromebook production unit? I'd like to see fixes like this upstreamed to coreboot git. As a related topic: Sandy/ivybridge boards have some low-memory writes on S3 resume, see use of CBMEM_RESUME_BACKUP and CBMEM_BOOT_MODE in romstage.c. Is there some argumentation why these writes are safe and do not corrupt OS memory? Regards, Kyösti

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot November 2013