coreboot April 2018

coreboot@coreboot.org

68 participants
128 discussions

Problem about GPIO
by 王翔 18 Apr '18

18 Apr '18

I try to porting coreboot to msi's Motherboard(H110 chipset). I read GPIO config from PCR config space under linux. But the value I got was very strange. eg: //DW0 and DW1 cannot be 0xffffffff according to the data sheet PIN:GPP_C6 DW1,DW0:ffffffff,ffffffff FUNC:(null) PULL:NATIVE RESET:RSMRST TX_DISABLE:1 RX_DISABLE:1 RXINV:INVERT TRIG:EDGE_BOTH ROUTE:NMI SMI SCI IOACPI PIN:GPP_C7 DW1,DW0:ffffffff,ffffffff FUNC:(null) PULL:NATIVE RESET:RSMRST TX_DISABLE:1 RX_DISABLE:1 RXINV:INVERT TRIG:EDGE_BOTH ROUTE:NMI SMI SCI IOACPI //TX_DISABLE and RX_DISABLE should be 0 ,if a GPIO is configured as NFx. PIN:GPP_A0 DW1,DW0:00000018,84000502 FUNC:NF1 PULL:NONE RESET:PLTRST TX_DISABLE:1 RX_DISABLE:0 RXINV:NONE TRIG:OFF ROUTE: PIN:GPP_A1 DW1,DW0:00003019,84000402 FUNC:NF1 PULL:UP_20K RESET:PLTRST TX_DISABLE:0 RX_DISABLE:0 RXINV:NONE TRIG:OFF ROUTE: PIN:GPP_A2 DW1,DW0:0000301a,84000402 FUNC:NF1 PULL:UP_20K RESET:PLTRST TX_DISABLE:0 RX_DISABLE:0 RXINV:NONE TRIG:OFF ROUTE: PIN:GPP_A3 DW1,DW0:0000301b,84000402 FUNC:NF1 PULL:UP_20K RESET:PLTRST TX_DISABLE:0 RX_DISABLE:0 RXINV:NONE TRIG:OFF ROUTE: PIN:GPP_A4 DW1,DW0:0000301c,84000402 FUNC:NF1 PULL:UP_20K RESET:PLTRST TX_DISABLE:0 RX_DISABLE:0 RXINV:NONE TRIG:OFF ROUTE: PIN:GPP_A5 DW1,DW0:0000001d,84000600 FUNC:NF1 PULL:NONE RESET:PLTRST TX_DISABLE:0 RX_DISABLE:1 RXINV:NONE TRIG:OFF ROUTE: Thank you very much，if you can help me. Wang Xiang

1 0

Apollo Lake new hardware bring-up
by Tahnia Lichtenstein 18 Apr '18

18 Apr '18

Hi all, I am wondering if anyone here has experience in bringing up newly assembled hardware based on Apollo Lake SoC, and if so, if they can share how to boot the hardware for the first time? Is there a special binary (other than normal bootloader) that I need to load into the TXE ROM, or do I need to strap special resistors (needed only for first boot in order to load something into TXE ROM) or anything else that differs from normal boot flow? I am trying to boot brand new hardware (i.e. it has not gone through any firmware programming yet), using a coreboot+SeaBIOS combination (adapted for the hardware), and stitched as per Intel specifications for hardware that has already undergone the manufacturing process (loading development keys as per Intel instructions, adding CSE image, PMC image, microcode, etc.), and disabling verified boot. (Flash map of generated binary attached). I tried to load the SPI flash-based bootloader binary on the Leaf Hill CRB and also on the Apollo Island CRB, and both attempts run successfully up to the RAM initialization phase, where execution stops (because the binary is intended for a different RAM type as required by my platform). However, when I try to run my bootloader binary on my brand new platform straight from assembly, the SPI flash device is only read up until the end of the flash descriptor, at address 0x14B (i.e. including SoC straps region, but excluding padding). Then all SPI transactions stop. In other words, the SPI flash device is not read far enough for boot partition 1 to be loaded into the SoC, and therefore I conclude the problem is not strictly related to my coreboot implementation, but related either to (1) hardware, (2) SoC soft-strapping contained in flash descriptor 4KB region, or (3) new hardware bring-up procedure. (1) While I am not discounting a hardware flaw (e.g. incompatible SPI flash muxing method, or incompatible flash device type, or wrong resister straps), it seems unlikely at this point. The hardware has proved to work to some extent, as witnessed on an oscilloscope/logic analyzer - the flash descriptor region is read correctly (verified byte-by-byte compared to the hex values in the binary), changes frequency when required to do so by SoC softstrapping options, and has undergone some limited XJTAG boundary scanning, and multiple reviews to ascertain designs, layouts and manufacturing. (2) As for SoC softstraps, I have picked all the values applicable to my platform, but have not been successful to enable "Firmware ROM bypass" option in the FIT tool as this option is grayed out and disabled in the tool (not sure if this is necessary for first boot?) (3) As for bring-up procedure (before or during first boot), it is unclear to me what this procedure is. My understanding is there is a special TXE-related binary I need to load into the TXE ROM before first "normal" boot, but am not sure how to do this, and not sure if this is necessary (or possible). Therefore this is my most likely candidate culprit. To solve this, I tried to load the CSE image (stand-alone, not stitched together with coreboot outputs or anything else) on the flash and then run the binary, hoping it would load whatever firmware needs to be loaded into TXE before first boot. This attempt failed miserably, as this binary's flash descriptor signature is "24 46 50 54", which differs from the normal descriptor mode signature of "5A A5 F0 0F" (little endian for 0FF0A55A). Thus when observing the run-time behaviour, the SPI flash is now only read up till the signature (at address 0x10 - 0x13), thereafter all SPI transactions stop. We tried asserting different combinations of resistors while programming and/or booting (specifically the flash descriptor override pin and ROM bypass pin) - with normal bootloader binary and CSE image, makes no difference to initial problem. I am very sorry if this is the wrong forum to ask, but I have been struggling with this problem for many weeks, and have not been able to find answers through the correct channels. I am just hoping someone here might be able to help point me in the right direction for the procedures of bringing up new Apollo Lake platforms. Best regards, Tahnia

1 0

Runtime config
by bartek.pastudzki 3mdeb.com 17 Apr '18

17 Apr '18

Hi We have runtime configuration arguments implemented for our platform in out fork. This is very simple, we just add few lines in SeaBIOS configuration file on CBFS (https://bit.ly/2qmX9nT — config example, https://bit.ly/2v5Era6 — handling code). There are only boolean values, no syntax, config file of constant size. Perhaps too simple, but it serves its purpose. We use it to enable/disable additional UART, EHCI and other features. Configuration is done in a payload, but it is supposed to affect hardware initialization in coreboot. We would like to have this functionality in mainline coreboot. We expect that this proof-of-concept is not good enough to incorporate it, but the question is how much better we have to do that. We have read some discussion on this topic on mailing list and we have found many ideas how this should be done, however we haven't found any definite answer. IMHO, a simple solution is the best one as long as it works well. It's also certainly better than nothing, especially that question appears again and again. A single fixed-size CBFS file seems to be enough for most applications. In fact, whole coreboot configuration is just 686 lines, in my configuration, 602 of them are boolean or disabled, so they could be packed in ceil(602/8)=76 bytes. I think 8 bytes for each other is quite safe to assume (most of them needs less, some needs more). 76+8*82=748 b. So even if we'd like to pack the whole configuration into a binary file we'd need 1kB or less. No moving, no resizing, just fixed schema binary file, it could be easily done with CBFS. To make it easy we'd prepare build system so that we could mark some options runtime-configurable in menuconfig. Based on those choices runtime-config structure would be generated as C header so that it can be easily used in source files. On the other hand, we have seen quite advanced considerations in the discussion so we've decided to ask for your opinion before we prepare final implementation.

3 3

Re: [coreboot] AMD Family 15h and 16h: ASSERTION ERROR
by Mike Banon 17 Apr '18

17 Apr '18

Regarding Lenovo G505S - also AMD family 15h : the very recent (April 08/09) build of coreboot (for which I have submitted a board status) - gave me the assertion errors as well: ... BS: BS_DEV_INIT times (us): entry 0 run 718163 exit 0 Finalize devices... Devices finalized APIC 00: ** Enter AmdInitLate [00020004] [1] ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187 [2] ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776 ^^^ these two lines repeat 9 times, one after another. FILE at [1] : Line 181 - * ASSERT if this routine is called. Line 182 - * Line 183 - */ Line 184 - VOID Line 185 - CommonAssert ( VOID ) Line 186 - { Line 187 - ASSERT (FALSE); Line 188 - } FILE at [2] : Line 775: InitApicIdCpuIdLo = FamilyServices->CoreIdPositionInInitialApicId (FamilyServices, StdHeader); Line 776: ASSERT (InitApicIdCpuIdLo < CoreIdPositionMax); ^^^ What does it mean, and why is it failing? After 18 assertion errors described above, there is a small log with one more error at the end: AmdInitLate() returned AGESA_SUCCESS APIC 00: Heap in SystemMem (4) at 0x10000014 APIC 00: ** Exit AmdInitLate [00020004] APIC 00: ** Enter AmdS3Save [0002000b] Manufacturer: 1c SF: Unsupported EON ID 0x7016 SF: Unsupported manufacturer! Manufacturer: 1c SF: Unsupported EON ID 0x7016 SF: Unsupported manufacturer! AmdS3Save() returned AGESA_SUCCESS [3] ASSERTION ERROR: file 'src/drivers/amd/agesa/state_machine.c', line 309 FILE at [3] : Line 308: status = amd_release_struct(&aip); Line 309: ASSERT(status == AGESA_SUCCESS); Could you please tell, why these errors are happening? Just in case, my full coreboot console log is at https://review.coreboot.org/cgit/board-status.git/tree/lenovo/g505s/4.7-662… On Mon, Apr 16, 2018 at 6:30 PM, Marshall Dawson <marshalldawson3rd(a)gmail.com> wrote: > Hey Paul, > > I don't have either of these two systems, and have only quickly scanned the > Kabini AGESA source. > > But if I had to make a guess, I believe the GetDmiInfoMain() likely has a > problem with its return value. Look at how it returns Flag, but the > function starts by setting Flag=TRUE. Since Flag is an AGESA_STATUS and > gets downgraded as necessary, it should've been initialized with > AGESA_SUCCESS instead. The same idea applies to GetType4Type7Info() too. > > It's not immediately apparent to me where the apu2 board picks up its > buildOpts, but most systems are configured for BUILDOPT_REMOVE_CDIT TRUE. I > seem to recall CDIT causing an error to be returned if the option wasn't > removed (as in imb-a180/buildOpts.c). > > Thanks, > Marshall > > > > On Mon, Apr 16, 2018 at 1:50 AM, Paul Menzel > <paulepanter(a)users.sourceforge.net> wrote: >> >> Dear coreboot folks, >> >> >> Looking through the board status uploads, the AMD Family 15h and 16h >> uploads contain lines with *ASSERTION ERROR*. For example: >> >> >> asrock/imb-a180/4.6-812-g4a1d450/2017-07-22T05_25_01Z/coreboot_console.txt:ASSERTION >> ERROR: file 'src/vendorcode/amd/agesa/f16kb/Proc/CPU/cpuGeneralServices.c', >> line 779 >> >> >> pcengines/apu2/4.6-1904-ga547e40/2017-10-26T06_40_33Z/coreboot_console.txt:ASSERTION >> ERROR: file 'src/northbridge/amd/pi/agesawrapper.c', line 279 >> >> Has somebody analyzed those yet? >> >> >> Kind regards, >> >> Paul >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] asrock-B75-pro3-m
by Iru Cai 17 Apr '18

17 Apr '18

Just ignore the CPU socket thing, it stands for a type of CPU which may not be using the socket. --ifd of flashrom means reading the IFD to get the layout, but coreboot.rom's fake IFD doesn't have the BIOS region, are you sure you're doing it correctly? If the firmware is executed, you can use the serial port (as I can remember, B75 Pro3-M's serial port is a 9-pin pinout on board) to see the console output. On Mon, Apr 16, 2018 at 12:52 PM, CarlosGonzalez <carlosgonz(a)protonmail.com> wrote: > HI coreboot > I have an 'Asrock B75-Pro3-m socket 1155', But coreboot motherboard > support page show that 'Asrock B75-Pro3-m socket 989' is compatible but > this do not exist,only socket 1155. can you check this? > I am trying many time install coreboot on my motherboard , But not > success, I compiled coreboot with minimun configuration like ,Motherboard > Name/Model, Chipset size 8 mb, only this then i flashed with: sudo > flashrom -p ch341a_spi --ifd -i bios -w coreboot.rom , but in this way my > computer not boot onle fans get turn on but i do not see any verbose on the > screen. > I really want coreboot on my system...Any help is much appreciate > Once Thanks... > /carlosgonz > -- My website: https://vimacs.lcpu.club Please do not send me Microsoft Office/Apple iWork documents. Send OpenDocument instead! http://fsf.org/campaigns/opendocument/

1 0

Re: [coreboot] AMD Family 15h and 16h: ASSERTION ERROR
by Marshall Dawson 16 Apr '18

16 Apr '18

Hey Paul, I don't have either of these two systems, and have only quickly scanned the Kabini AGESA source. But if I had to make a guess, I believe the GetDmiInfoMain() likely has a problem with its return value. Look at how it returns Flag, but the function starts by setting Flag=TRUE. Since Flag is an AGESA_STATUS and gets downgraded as necessary, it should've been initialized with AGESA_SUCCESS instead. The same idea applies to GetType4Type7Info() too. It's not immediately apparent to me where the apu2 board picks up its buildOpts, but most systems are configured for BUILDOPT_REMOVE_CDIT TRUE. I seem to recall CDIT causing an error to be returned if the option wasn't removed (as in imb-a180/buildOpts.c). Thanks, Marshall On Mon, Apr 16, 2018 at 1:50 AM, Paul Menzel < paulepanter(a)users.sourceforge.net> wrote: > Dear coreboot folks, > > > Looking through the board status uploads, the AMD Family 15h and 16h > uploads contain lines with *ASSERTION ERROR*. For example: > > asrock/imb-a180/4.6-812-g4a1d450/2017-07-22T05_25_01Z/coreboot_console.txt:ASSERTION > ERROR: file 'src/vendorcode/amd/agesa/f16kb/Proc/CPU/cpuGeneralServices.c', > line 779 > > pcengines/apu2/4.6-1904-ga547e40/2017-10-26T06_40_33Z/coreboot_console.txt:ASSERTION > ERROR: file 'src/northbridge/amd/pi/agesawrapper.c', line 279 > > Has somebody analyzed those yet? > > > Kind regards, > > Paul > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] How to handle vbt.bin
by Patrick Rudolph 16 Apr '18

16 Apr '18

On 2018-04-15 11:30 PM, Nico Huber wrote: > On 15.04.2018 17:12, Patrick Rudolph wrote: >> On Sun, 2018-04-15 at 13:43 +0200, Nico Huber wrote: >>> On 15.04.2018 12:48, Patrick Rudolph wrote: >>>> On Thu, 2018-04-05 at 11:34 -0500, Matt DeVillier wrote: >>>>> On Thu, Apr 5, 2018 at 11:29 AM, Nico Huber <nico.h(a)gmx.de> wrote: >>>>>> On 05.04.2018 18:15, Matt DeVillier wrote: >>>>>>> my instinct is to put it in the 3rd party blobs repo, since it's added to >>>>>>> the CBFS w/o modification (ie, is treated like a blob), unlike the SPD hex >>>>>>> files which are selectively ordered and assembled into the spd.bin (ie, >>>>>>> treated as source). >>>> >>>> I would like to see them in 3rd party repo, as we don't process them, >>>> as Matt pointed out. >>>> >>>>>> Files are concatenated, I don't see how this is treating sth. as >>>>>> source. >>>>>> >>>> >>>> They are changed from ASCII/text to binary format, so yes it's a source >>>> file. >>> >>> lol. I had that discussion before, and no: hexdumping something doesn't >>> make it source (code). >>> >>> Is this really where you want to draw the line? can I put my ME firmware >>> into the main repo too if I hexdump it? >>> >>> Btw. there is no reason to have SPDs as hex. Should we move them to >>> 3rdparty/blobs too? >>> >> For SPDs: No. As you can't extract them from vendor image, can you ? > > Sure I can, in some cases even with cbfstool. > >> >> For VBT: Why not. A user is free to choose to use the blob from blobs >> repo, extract it his own from vendor image, use a VGA option ROM or use >> the fake VBT mechanism. > > Yeah, same when we add the VBT to the main repo. > >> >> The benefit of having it in blobs repo is that it increases compability >> and user friendliness. Just tick the Kconfig option, done. > > Not true, you'd also have to tick USE_BLOBS (and wonder why it's neces- > sary in case your platform doesn't need real (code) blobs). The benefit > of having it in the main repo is that it increases sanity and user- > friendliness. Just leave the default, done. > I guess the solution is simple. Let's not call VBT a BLOB. 1) It's not that large ~3-7KiB in times of mobile devices that have multiple GiB of storage. 2) In coreboot BLOB is considered to contain code. VBT is only data. 3) One could argue that it's basically a key value file, where the keys are predefined through VBT version and section IDs. Such a file is called configuration file. If it's a configuration file, it should *not* be placed in blobs repo. We should also update the Kconfig option USE_BLOBS and explain that it is only for files that contain executable code. It's not clear for me reading the current help message. >> >> It is independed from a free tool to generate a VBT (which would be >> nice to have). > > Ack. > > Nico Regards, Patrick

3 2

[RFH] Testers with Intel devices for common SMM/SMI handler
by Paul Menzel 16 Apr '18

16 Apr '18

Dear coreboot folks, Arthur did great work and unified and improved a lot of code under the topic *common_smm_smihandler* [1]. To avoid regressions, could everyone with the appropriate hardware please test [2], and comment on the change-set with the test result? The instructions below should build fetch the required changes, and build a new image. ``` $ git fetch https://review.coreboot.org/coreboot refs/changes/06/25606/6 && git checkout -b common_smm_smihandler FETCH_HEAD $ make olddefconfig $ make clean $ make ``` Kind regards Paul [1] https://review.coreboot.org/#/q/status:open+project:coreboot+branch:master+… [2] https://review.coreboot.org/#/c/coreboot/+/25606/

1 0

[RFH] Status of the Lenovo X201
by Paul Menzel 16 Apr '18

16 Apr '18

Dear coreboot users, There is some uncertainty about the state of latest coreboot on the Lenovo X201. Does the most recent commit from coreboot work on it, or are there problems or regressions? Kind regards, Paul

1 0

AMD Family 15h and 16h: ASSERTION ERROR
by Paul Menzel 16 Apr '18

16 Apr '18

Dear coreboot folks, Looking through the board status uploads, the AMD Family 15h and 16h uploads contain lines with *ASSERTION ERROR*. For example: asrock/imb-a180/4.6-812-g4a1d450/2017-07-22T05_25_01Z/coreboot_console.txt:ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f16kb/Proc/CPU/cpuGeneralServices.c', line 779 pcengines/apu2/4.6-1904-ga547e40/2017-10-26T06_40_33Z/coreboot_console.txt:ASSERTION ERROR: file 'src/northbridge/amd/pi/agesawrapper.c', line 279 Has somebody analyzed those yet? Kind regards, Paul

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot April 2018