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), \
I know that this configuration is available from the ILB_BASE_ADDRESS
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
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
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
For now I'm just glad I'm not spending the weekend in the office!
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 thru GPIO_S0_SC.
> 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
> > 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
> > don't want to use.
> > This does recognise the eMMC, boots the same kernel I used with coreboot
> > 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
> > 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
> > here?
> > Thanks for any help
> > David
> > --
> > coreboot mailing list: coreboot(a)coreboot.org
> > http://www.coreboot.org/mailman/listinfo/coreboot
by Raptor Engineering Automated Coreboot Test Stand
The ASUS KGPE-D16 fails verification as of commit 485225e0a382fe398a5e8283a00fc99670306b1e
The following tests failed:
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
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 thru GPIO_S0_SC.
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
> Thanks for any help
> coreboot mailing list: coreboot(a)coreboot.org
we obviously want to participate in FOSDEM.
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.
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
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
Thanks for any help
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:
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
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
- 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. :)
Thanks for your input.
Using the SLIM TXE binary did the trick and the Intel System Debugger
now connects to the target without complaint.
On Thu, Dec 17, 2015 at 2:23 PM, Testerman, Brett (US COM)
> 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.
> -----Original Message-----
> From: Ben Gardner [mailto:email@example.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 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?
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 , 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 , 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  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
> 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:
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?
>> PS: I’ll try to create a ticket for this issue in the bug tracker 
>> this evening.
>>  https://review.coreboot.org/gitweb?p=board-status.git;a=summary
>>  https://review.coreboot.org/12810
>>  https://review.coreboot.org/12824
>>  https://ticket.coreboot.org/
>> coreboot mailing list: coreboot(a)coreboot.org
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.
On Sun, Jan 10, 2016 at 3:28 AM Rafael Machado <
> 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>
>> 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
>> board vendor) then yes, first location to be executed is the instruction
>> 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
>> 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.
> coreboot mailing list: coreboot(a)coreboot.org