coreboot January 2016

coreboot@coreboot.org

38 participants
74 discussions

how to route IRQ4 (COM1) on LPC bus for bayleybay_fsp
by benoit 15 Jan '16

15 Jan '16

Hi all, I am currently running coreboot + fsp on a E3837 cpu based platform. My platform has serial line in a LPC device. Firstly, I activated the SERIRQ in continous mode. Nevertheless under operating system, the IRQ4 for COM1 is not available. I checked out the file src/mainboard/intel/bayleybay_fsp/irqtable.h And I saw that for the LPC interface : PCI_DEV_PIRQ_ROUTE(PCU_DEV, H, G, B, C) ... #define PIRQ_PIC_ROUTES \ PIRQ_PIC(A, 4), \ PIRQ_PIC(B, 5), \ PIRQ_PIC(C, 7), \ PIRQ_PIC(D, 10), \ PIRQ_PIC(E, 11), \ PIRQ_PIC(F, 12), \ PIRQ_PIC(G, 14), \ PIRQ_PIC(H, 15) I know that this configuration is available from the ILB_BASE_ADDRESS (0xfed08000). But I don't really understand, how to route the IRQ4 from LPC dev. Is someone can explain to me how to do it properly? Many thanks in advance Benoit

3 3

Re: [coreboot] Using eMMC on Baytrail with FSP
by David Popeck 15 Jan '16

15 Jan '16

Hi Ben, I've had some success now. Once I knew that you had it working with eMMC without any real fiddling, I went on the assumption that an older version of coreboot would be worth trying. I had been using the latest version from github but have now gone back to the version of code that Intel supplied with FSP Gold 4, which works! So either something didn't get integrated into the official coreboot source or its broken between then and now. When I get some time I will try and track down exactly where the difference is. For now I'm just glad I'm not spending the weekend in the office! Thanks David On Thu, Jan 14, 2016 at 5:36 PM, Ben Gardner <gardner.ben(a)gmail.com> wrote: > Hi David, > > I've been using eMMC with the baytrail FSP on the E3800 CPU without issue. > I don't recall doing anything special to get it to work under Linux. > > Comparing my devicetree.cb with bayleybay_fsp shows these differences > related to eMMC. > I don't know if any of those are important. > > register "PcdEMMC45DDR50Enabled" = "EMMC45_DDR50_DISABLE" > register "PcdEMMC45HS200Enabled" = "EMMC45_HS200_DISABLE" > register "PcdEMMC45RetuneTimerValue" = "EMMC45_RETURN_TIMER_DEFAULT" > > I also have devices 0x11 and 0x12 turned off. > > By "relevant" pins, I assume you mean GPIO_S0_SC[016] thru GPIO_S0_SC[026]. > > Ben > > On Wed, Jan 13, 2016 at 9:16 AM, David Popeck <david(a)justaride.org> wrote: > > Hi all, > > > > I've been trying to get Coreboot going on a custom Baytrail based board > that > > I have. > > > > Pretty much everything is working with one major exception - eMMC. > > > > I've enabled eMMC in BCT. > > In devicetree.cb I've switched off device 10 (eMMC 4.1 controller) and > > switched on device 17 (eMMC 4.5 controller). > > And finally I've switched the relevent pins to GPIO_FUNC3 in gpio.c. > > > > Linux sees device 17.0 in lspci and loads the module but doesn't show any > > mmcblk devices. > > > > I was supplied the board with an Insyde systems EFI firmware which I > really > > don't want to use. > > This does recognise the eMMC, boots the same kernel I used with coreboot > and > > now I can access the eMMC. > > So I know there is nothing electrically wrong here. > > > > > > Should this configuration work with coreboot? > > If I look in the non-fsp baytrail directory I can see emmc.c which > appears > > to contain explicit code to initialise the controller. > > There is no equivelent code in the fsp_baytrail directory that I can see. > > Is FSP supposed to initialise the controller or is there something > missing > > here? > > > > > > Thanks for any help > > > > David > > > > > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

ASUS KGPE-D16 Automated Test Failure
by Raptor Engineering Automated Coreboot Test Stand 14 Jan '16

14 Jan '16

The ASUS KGPE-D16 fails verification as of commit 485225e0a382fe398a5e8283a00fc99670306b1e The following tests failed: BOOT_FAILURE Commits since last successful test: 485225e cbfstool: reorder help text See attached log for details This message was automatically generated from Raptor Engineering's ASUS KGPE-D16 test stand Want to test on your own equipment? Check out https://www.raptorengineeringinc.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification

2 1

Re: [coreboot] Using eMMC on Baytrail with FSP
by Ben Gardner 14 Jan '16

14 Jan '16

Hi David, I've been using eMMC with the baytrail FSP on the E3800 CPU without issue. I don't recall doing anything special to get it to work under Linux. Comparing my devicetree.cb with bayleybay_fsp shows these differences related to eMMC. I don't know if any of those are important. register "PcdEMMC45DDR50Enabled" = "EMMC45_DDR50_DISABLE" register "PcdEMMC45HS200Enabled" = "EMMC45_HS200_DISABLE" register "PcdEMMC45RetuneTimerValue" = "EMMC45_RETURN_TIMER_DEFAULT" I also have devices 0x11 and 0x12 turned off. By "relevant" pins, I assume you mean GPIO_S0_SC[016] thru GPIO_S0_SC[026]. Ben On Wed, Jan 13, 2016 at 9:16 AM, David Popeck <david(a)justaride.org> wrote: > Hi all, > > I've been trying to get Coreboot going on a custom Baytrail based board that > I have. > > Pretty much everything is working with one major exception - eMMC. > > I've enabled eMMC in BCT. > In devicetree.cb I've switched off device 10 (eMMC 4.1 controller) and > switched on device 17 (eMMC 4.5 controller). > And finally I've switched the relevent pins to GPIO_FUNC3 in gpio.c. > > Linux sees device 17.0 in lspci and loads the module but doesn't show any > mmcblk devices. > > I was supplied the board with an Insyde systems EFI firmware which I really > don't want to use. > This does recognise the eMMC, boots the same kernel I used with coreboot and > now I can access the eMMC. > So I know there is nothing electrically wrong here. > > > Should this configuration work with coreboot? > If I look in the non-fsp baytrail directory I can see emmc.c which appears > to contain explicit code to initialise the controller. > There is no equivelent code in the fsp_baytrail directory that I can see. > Is FSP supposed to initialise the controller or is there something missing > here? > > > Thanks for any help > > David > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

1 0

FOSDEM deadlines now!
by Carl-Daniel Hailfinger 13 Jan '16

13 Jan '16

Hi, we obviously want to participate in FOSDEM. https://fosdem.org/2016/news/2015-09-24-call-for-participation/ ACT NOW! Some deadlines already expired. Some can still be managed. Main track talks: Deadline 2015-10-30 (10 days left) One hour of entertainment, huge audience. Anyone up for the challenge? Stands: Deadline 2015-11-13 (24 days left) I can send in the proposal if I'm not going to be alone there. How many tables do we want for our stand/booth(s)? Who is coming? Lightning talks: Deadline 2015-11-27 (38 days left) Short and to the point. Your 15-minute elevator pitch. Can you sell the project? All deadlines are at 23.59 UTC Developer room proposal: Deadline EXPIRED Maybe some developer room will accept talks/demos from us. Regards, Carl-Daniel

3 4

Using eMMC on Baytrail with FSP
by David Popeck 13 Jan '16

13 Jan '16

Hi all, I've been trying to get Coreboot going on a custom Baytrail based board that I have. Pretty much everything is working with one major exception - eMMC. I've enabled eMMC in BCT. In devicetree.cb I've switched off device 10 (eMMC 4.1 controller) and switched on device 17 (eMMC 4.5 controller). And finally I've switched the relevent pins to GPIO_FUNC3 in gpio.c. Linux sees device 17.0 in lspci and loads the module but doesn't show any mmcblk devices. I was supplied the board with an Insyde systems EFI firmware which I really don't want to use. This does recognise the eMMC, boots the same kernel I used with coreboot and now I can access the eMMC. So I know there is nothing electrically wrong here. Should this configuration work with coreboot? If I look in the non-fsp baytrail directory I can see emmc.c which appears to contain explicit code to initialise the controller. There is no equivelent code in the fsp_baytrail directory that I can see. Is FSP supposed to initialise the controller or is there something missing here? Thanks for any help David

1 0

Building the toolchain automatically
by Martin Roth 12 Jan '16

12 Jan '16

coreboot already detects whether the toolchain is built, and already has targets to build the toolchain for each individual architecture. It would be trivial to connect these together and simply build the toolchain for the current architecture if it doesn't exist. Is this something that is desirable to the coreboot community? Please vote in the poll if you have an opinion about whether the toolchain should be built automatically: http://doodle.com/poll/tu65vbvt9snfcn8p Poll options are: - coreboot should build the toolchain for the current architecture if it doesn't exist. - coreboot should offer to build the toolchain, but let the user choose not to build it. - Leave it as it currently is - someone should update the docs. - Leave it as it currently is - I volunteer to update the docs. - Rip out the current toolchain make targets - Building the toolchain belongs elsewhere. Additionally, since we are about to detect the version of the toolchain, and can tell the user if the toolchain needs to be updated, if we automatically build it, should it automatically be rebuilt when the build detects that the toolchain is out of date? Arguments for automatically building the toolchain: - The docs are always out of date, and nobody updates them when they change options. - We're frequently answering questions on how to build the toolchain. Arguments against automatically building the toolchain: - "It's feature creep. The build system should just build coreboot." I'd really like to know how others feel about this. To me it's a trivial thing to add and I feel like it would be very helpful to beginning coreboot users, but it doesn't really matter to me either way. I'm reasonably good at rebuilding the toolchain. :) Martin

1 0

Re: [coreboot] Minnowmax: Has anyone used the XDP debug port with coreboot?
by Ben Gardner 11 Jan '16

11 Jan '16

Brett, Thanks for your input. Using the SLIM TXE binary did the trick and the Intel System Debugger now connects to the target without complaint. Ben On Thu, Dec 17, 2015 at 2:23 PM, Testerman, Brett (US COM) <Brett.Testerman(a)cobham.com> wrote: > Ben, > > You are fighting all the things I had to go through 5 months ago. Not fun. Learned the hard way things like the first steppings of the processor would boot in non-descriptor mode the later ones will not. Even the docs state it one way then correct themselves a few sentences later. And that the processor will boot without a TXE image but like I said before, XDP is disabled. And good luck getting information on writing a SPI driver. The register map is there but nothing on how to use it. Closest equivalent I could find was a PXA270 which is an ARM chip but they obviously reused the IP for the silicon. > > We are an embedded product so things like Secure Boot does nothing but get in our way. Was finally able to get it down to just loading the 'SLIM' TXE but making no other changes. Pretty much just zeroed all the TXE setting in the FITC tool for things like the UUID and ODM ID. I did not have to configure any hash's nor do I have to issue any FMI commands. Like you say, by the time you could issue a command coreboot has long since completed. I use an Asset XDP debugger and it catches a power cycle perfectly, halting the CPU as it is about to fetch the reset vector. > > I didn't do the hardware design so it would take me quite a while to figure out which GPIO get mapped to the XDP port, especially since they go through a bunch of muxes. If you had something specific I could look early next week as I am out tomorrow. I know the hardware guy did try to follow all the Intel recommendations for the Hooks and such. > > We did not make any changes to the GPIO settings the Coreboot defaults to. We do that in the custom payload we load. > > Brett > > > > > > -----Original Message----- > From: Ben Gardner [mailto:gardner.ben@gmail.com] > Sent: Thursday, December 17, 2015 10:30 AM > To: Testerman, Brett (US COM) > Cc: coreboot > Subject: Re: [coreboot] Minnowmax: Has anyone used the XDP debug port with coreboot? > > ** Please note that the Sender of this email is from outside the Cobham NA IT Hub ** > > Hi Brett, > > If you don't mind, I have a few more questions about your setup. > > On Thu, Dec 17, 2015 at 10:25 AM, Testerman, Brett (US COM) <Brett.Testerman(a)cobham.com> wrote: >> I have a custom E38xx design (Baytrail) that I ported Coreboot on to. >> XDP works fine but you must install the TXE image in the boot flash >> else the port is locked out. > > We don't need secure boot, so we are chose the 'SLIM' TXE image. > Did you have to do anything to configure the TXE image, like setting FUSE_FILE_OEM_KEY_HASH_1? > > The Intel System Debugger indicates that the "JTAG connection was established but the target appears to have security-restricted JTAG. > Please try disabling JTAG security in the platform firmware." > (That was with FSP Gold v3. I haven't yet tested with FSP Gold v4. The XDP hardware is at another location, so testing is a bit difficult.) > > Out Intel rep says that we have to send the "Set Debug State" FMI command to the TXE engine to enable debug. > The problem I ran into with that is that the FspInitEntry (Goldv4) call hides the TXE PCI device (1a.0) and it doesn't seem like I can send a FMI command without RAM first being initialized. > > Does any of that sound familiar? Or did it "just work" for your board? > I would expect it to "just work" if secure boot was disabled. > > Last question about your gpio.c file: > It looks like GPIO_S5[22-30] are used for XDP. > Minnowmax has GPIO_S5[22] as GPIO_NC and GPIO_S5[23-30] set as GPIO_FUNC(0, PULL_UP, 20K). > > Is that how you configured the XDP-related pins? > If not, would you mind sending you gpio.c file so I can compare? > > Thanks, > Ben >

1 0

Re: [coreboot] [regression] Increased romstage boot time on ASRock E350M1 (AMD Family 14h)
by Aaron Durbin 11 Jan '16

11 Jan '16

On Mon, Jan 11, 2016 at 7:33 AM, Aaron Durbin <adurbin(a)google.com> wrote: > On Sun, Jan 10, 2016 at 4:40 AM, Paul Menzel > <paulepanter(a)users.sourceforge.net> wrote: >> Dear coreboot folks, >> >> >> on the ASRock E350M1, I lately noticed that the SeaBIOS banner takes >> longer to appear. And looking at the logs board status [1], the time >> stamps stored in CBMEM confirm this. >> > > What were your typical times like? > >> ``` >> $ grep 1st asrock/e350m1/4.2-*/*/coreboot_timestamps.txt >> asrock/e350m1/4.2-33-g42444f6/2015-10-30T17:54:28Z/coreboot_timestamps.txt: 0:1st timestamp 368,199 >> asrock/e350m1/4.2-36-g0ace013/2015-10-31T13:22:12Z/coreboot_timestamps.txt: 0:1st timestamp 368,416 >> asrock/e350m1/4.2-37-gab35575/2015-10-31T18:23:47Z/coreboot_timestamps.txt: 0:1st timestamp 367,904 >> asrock/e350m1/4.2-41-g3c47e8a/2015-10-31T20:39:02Z/coreboot_timestamps.txt: 0:1st timestamp 367,829 >> asrock/e350m1/4.2-42-g0746452/2015-10-31T21:11:04Z/coreboot_timestamps.txt: 0:1st timestamp 368,081 >> asrock/e350m1/4.2-43-g160ad6a/2015-10-31T21:12:09Z/coreboot_timestamps.txt: 0:1st timestamp 368,290 >> asrock/e350m1/4.2-44-gbabb2e6/2015-10-31T21:14:48Z/coreboot_timestamps.txt: 0:1st timestamp 368,023 >> asrock/e350m1/4.2-53-gf6dc544/2015-11-01T13:27:02Z/coreboot_timestamps.txt: 0:1st timestamp 368,470 >> asrock/e350m1/4.2-58-g65eec4d/2015-11-02T15:41:33Z/coreboot_timestamps.txt: 0:1st timestamp 679,462 >> asrock/e350m1/4.2-628-g62c0276/2015-12-29T17:17:01Z/coreboot_timestamps.txt: 0:1st timestamp 1,528,198 >> asrock/e350m1/4.2-701-gb95a074/2016-01-08T01:44:15Z/coreboot_timestamps.txt: 0:1st timestamp 1,298,841 >> asrock/e350m1/4.2-702-gfecc24a/2016-01-08T16:21:59Z/coreboot_timestamps.txt: 0:1st timestamp 1,289,489 >> asrock/e350m1/4.2-703-g8846382/2016-01-09T21:18:59Z/coreboot_timestamps.txt: 0:1st timestamp 1,289,756 >> ``` >> >> Unfortunately, there was a time, where I had forgotten to select this >> option, so I am still bisecting this. >> >> I thought, it might have been fixed with the commit 4.2-630-g65e33c0 >> below [1], but it’s not. >> >> ``` >> commit 65e33c08a9a88c52baaadaf515b9591856115a77 >> Author: Nico Huber <nico.huber(a)secunet.com> >> Date: Mon Dec 28 20:17:13 2015 +0100 >> >> x86: Align CBFS on top of ROM >> >> Since the introduction of the new (interim?) master header, coreboot >> searches the whole ROM for CBFS entries. Fix that by aligning it on top >> of the ROM. >> >> Change-Id: I080cd4b746169a36462a49baff5e114b1f6f224a >> […] >> ``` >> >> Do you know, which commit the commit message referred to? >> >> Looking more into it, Nico’s commit was reverted in commit 4.2-673- >> g12c55ed [3] and the logic reworked. >> >> ``` >> commit 12c55eda11453ed1e7a24e218338831f67cd5de6 >> Author: Aaron Durbin <adurbin(a)chromium.org> >> Date: Mon Jan 4 13:57:07 2016 -0600 >> >> Revert "x86: Align CBFS on top of ROM" >> >> This reverts commit 65e33c08a9a88c52baaadaf515b9591856115a77. >> This was the wrong logic to fix the master header. >> >> Change-Id: I4688034831f09ac69abfd0660c76112deabd62ec >> […] >> ``` >> >> If you have any suggestions, please tell me. Otherwise, I’d continue >> trying to bisect this. >> >> And unfortunately, I am unable to provide romstage messages, as I still >> haven’t got the serial header for the board. >> >> So if somebody else, Stefan, Martin, Kevin, could provide that, that >> would be awesome. > > Did you rebuild cbfstool that contains this patch? > https://review.coreboot.org/12825 It was the one I said fixed the > logic when you asked in https://review.coreboot.org/#/c/12824/. > Additionally, there's also the comments I left in > https://review.coreboot.org/12810 that explained how that patch was > incorrect. > > Please provide a hexdump snippet (hexdump -C image.rom) that shows the > "ORBC" section. That's the master header, and we can analyze if you > did indeed build w/ an updated cbfstool as well as determine if there > are other issues. > I just looked at the 703-* log: CBFS: 'Master Header Locator' located CBFS at [100:3fffc0) That corresponds w/ your config: CONFIG_CBFS_SIZE=0x400000 CONFIG_ROM_SIZE=0x400000 So that's all correct. It's not cbfs as far as I can tell (seems unlikely). I suspect that your timestamps are just more correct. Where does your first timestamp original from? Is that in ramstage? >> >> >> Thanks, >> >> Paul >> >> >> PS: I’ll try to create a ticket for this issue in the bug tracker [4] >> this evening. >> >> >> [1] https://review.coreboot.org/gitweb?p=board-status.git;a=summary >> [2] https://review.coreboot.org/12810 >> [3] https://review.coreboot.org/12824 >> [4] https://ticket.coreboot.org/ >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Where is the first instrucion?
by ron minnich 10 Jan '16

10 Jan '16

One thing I think you'd enjoy doing is building the qemu target, setting up qemu with gdb, and just watching what happens, instruction by instruction, as the system boots. ron On Sun, Jan 10, 2016 at 3:28 AM Rafael Machado < rafaelrodrigues.machado(a)gmail.com> wrote: > Hi Peter and Rudolf. > Thanks for the answers and tips. They are realy helpfull ! > I'll take a look. > > Rafael R. Machado > > Em Sáb, 9 de jan de 2016 17:19, Rudolf Marek <r.marek(a)assembler.cz> > escreveu: > >> Hi, >> >> I guess your question is more general than the coreboot related right? >> >> If you have a firmware image dump of the flash (not the file you download >> from >> board vendor) then yes, first location to be executed is the instruction >> located >> 16 bytes before end of the image. >> >> In coreboot see in build/ bootblock_inc.S which also has reset16.inc and >> entry16.inc which is a real start. Consult the Intel or AMD manual to see >> the >> CPU state after reset. The CPU starts in real mode, but CS base is >> shifted to >> last 64KB before end of 4GB address space. In general your CPU starts in >> compatible mode with 8086 manufactured in 1978. >> >> Thanks >> Rudolf >> > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot January 2016