coreboot June 2018

coreboot@coreboot.org

40 participants
105 discussions

Re: [coreboot] Bayley Bay FSP-based CRB
by Zvi Vered 21 Jun '18

21 Jun '18

Hello, Thank you very much for the detailed reply. Vendor's BIOS contains few peripherals initialization. For example: PCIe enumeration, SATA controller, USB etc. In case of PCIe enumeration, the generation of PCIe (1,2,3) can be set. Should vendor supply code for this ? or any other information ? How can I write it from scratch ? Can Intel provide information on how to implement this initialization ? Thank you, Zvika On Mon, Jun 18, 2018 at 11:22 AM Jose Trujillo via coreboot < coreboot(a)coreboot.org> wrote: > Hello Zvika: > 1.- Usually it is not necessary to change the CBFS size unless the > compiler complain of lack of space. > 2.- You should not worry about this setting to make your system to work. > 3.- You should not use FSP_PACKAGE_DEFAULT if your plan is to use SIO > because it will enable SOC internal COM1, instead (if your plan is to use > FSP) enable FSP and add a VGA bios bin manually.... (The use of FSP is > optional but I never tried without FSP). > 4.- You need to add them yourself, there are examples to follow in this > mail list. > Good luck! > J.Trujillo > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On June 18, 2018 6:24 AM, Zvi Vered <veredz72(a)gmail.com> wrote: > > Hello, > I inspected the "Bayley Baay FSP-based CRB" sample in coreboot. after make > distclean I chose: > Mainboard vendor: Intel > Mainboard model: Bayley Bay FSP-based CRB > 1. The size of CBFS is: 0x200000. Is it a fix size or should I change it > according to my board (which is also bay trail) ? > 2. According to "dmidecode" I ran on my target, "Address: 0xE0000" > Should I set this address in coreboot configuration ? How ? > > 3. In this board default configuration, "Configure defaults for the Intel > FSP package" is not selected. Is it possible that this board does not use > Intel FSP at all ? > Under "Generic Drivers", "Use Intel firmware Support Package' is also not > selected. > > 4. Under "chipset", there is no option to set "Super I/O". Can you please > tell why ? > 5. I noticed that the minimum ROM size is 2MB. If I set 4MB, the size of > coreboot.rom is also 4MB. > > Thank you in advance, > Zvika > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Thinkpad SD card controller DMA
by Thomasheidler 20 Jun '18

20 Jun '18

Hello, I noticed that all Lenovo Thinkpads supported by coreboot have a SD card controller that is connected as a PCI device. I assume that the controller runs non-free firmware from its own ROM and because it is a PCI device it should have DMA, which seems like a security risk, right? If so, is there a way to prevent the SD card controller from turning on when the computer is booted, by changing some code in the source (maybe in devicetree.cb) or at least to stop the controller from having DMA? Thanks a lot, Thomas

1 0

Re: [coreboot] Problem with W83627DHG in Baytrail I (Possible IRQ conflict or overlapped SOC legacy COM1)
by Jose Trujillo 19 Jun '18

19 Jun '18

Dear coreboot developers: The problems with SIO devices were resolved: I will give you a brief explanation of what I did after my previous mail just for the record, thinking this might be useful for someone else in the future. The problem was that ttyS0 from W83627DHG was not working properly (details on previous mail). I did the following: 1.- Did some fixes on my superio.asl that I use. (Did not fixed my problem) 2.- Remove IRQs 3 and 4 from irqlinks.asl devices. (Did not fixed my problem) After this I gave up on this issue and decided to add my second SIO on 0x4e FINTEK_F81803 that I modified based on F81866D. 3.- Added FINTEK_F81803 on 0x4e and compiled it. (Those ports didn't even appear in the OS and I didn't know why) I ran superiotool to check the state of the registers and discovered that the Fintek SIO had the default values. 4.- Checked the code in devicetree, and superio.c of both SIO devices but everything looked fine. 5.- In terminal I entered into "make menuconfig" and without making any change to the configuration I selected "Save" then enter, exit, exit and recompiled again and flashed and Voila! Fintek UART ports worked fine and ttyS0 from Winbond is just working fine too. I just need to do some fine tuning on the UART ports and configure correctly HWMon and Fan control in Fintek. Thank you All, J. Trujillo ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On June 15, 2018 6:30 PM, Jose Trujillo via coreboot <coreboot(a)coreboot.org> wrote: > Dear All, > > After following the recommendations from Rudolf and other people on this mail list I was able to make the following to make my LPC SIO to work (with issues). > > 1.- Enable SERIRQ in CONTINUOUS_MODE > > 2.- Add SUPERIO_WINBOND_W83627DHG driver to the Konfig file. > > 3.- Add the SIO parametrization in devicetree with 0x3f8,4 and 0x2f8,3 for UARTS. > > 4.- Add the PNP-ACPI information for SIO. > > 5.- Change SOC's 8259 trigger to EDGE. > > 6.- Disable internal (SOC) COM1 with the following code in romstage: > > void late_mainboard_romstage_entry() > > { > > /* Disable the internal COM1 */ > > pci_write_config32(PCI_DEV(0, LPC_DEV, 0), UART_CONT, 0); > > u32 *irqen = (u32 )(ILB_BASE_ADDRESS + 0x88);write32(irqen, 0); / Unbind IRQ4 */ > > } > > 7.- Release IRQ4 from the PIRQ_PIC_ROUTES in irqroute.h and set IRQ6 instead. > > After all this: > > COM2 (0x2f8,3) works fine > > But: > > I still have an issue: > > COM1 (0x3f8,4) can transmit data correctly but at receiving the port hangs and not showing received string. > > When I make DMESG in terminal i get: > > "do_IRQ: 2.39 No irq handler for vector" > > "serial8250: too much work for irq4" > > What could be wrong? > > What could be missing? > > Let me know if you require more info, > > Any advise on the issue will be highly appreciated, > > Thank you, > > J. Trujillo > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On June 6, 2018 11:46 PM, Rudolf Marek r.marek(a)assembler.cz wrote: > > > Hi, > > > > In general I would check ELCR (I/O port register 0x4d0) to check if it is correctly programmed to EDGE/LEVEL (it should be edge) > > > > Also, how the Linux is supposed to detect the I/O port irq? I think you need some PNP device in ACPI to let linux infer the IRQ. > > > > I would also try to disable the IRQ from SoC, you just need to check how they are enabled (sorry not an expert here) > > > > and also I would use the legacy 0x3f8 instead. > > > > Thanks > > > > Rudolf > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Bayley Bay FSP-based CRB
by Jose Trujillo 18 Jun '18

18 Jun '18

Hello Zvika: 1.- Usually it is not necessary to change the CBFS size unless the compiler complain of lack of space. 2.- You should not worry about this setting to make your system to work. 3.- You should not use FSP_PACKAGE_DEFAULT if your plan is to use SIO because it will enable SOC internal COM1, instead (if your plan is to use FSP) enable FSP and add a VGA bios bin manually.... (The use of FSP is optional but I never tried without FSP). 4.- You need to add them yourself, there are examples to follow in this mail list. Good luck! J.Trujillo ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On June 18, 2018 6:24 AM, Zvi Vered <veredz72(a)gmail.com> wrote: > Hello, > I inspected the "Bayley Baay FSP-based CRB" sample in coreboot. after make distclean I chose: > Mainboard vendor: Intel > Mainboard model: Bayley Bay FSP-based CRB > 1. The size of CBFS is: 0x200000. Is it a fix size or should I change it according to my board (which is also bay trail) ? > 2. According to "dmidecode" I ran on my target, "Address: 0xE0000" > Should I set this address in coreboot configuration ? How ? > > 3. In this board default configuration, "Configure defaults for the Intel FSP package" is not selected. Is it possible that this board does not use Intel FSP at all ? > Under "Generic Drivers", "Use Intel firmware Support Package' is also not selected. > > 4. Under "chipset", there is no option to set "Super I/O". Can you please tell why ? > 5. I noticed that the minimum ROM size is 2MB. If I set 4MB, the size of coreboot.rom is also 4MB. > > Thank you in advance, > Zvika

1 0

Bayley Bay FSP-based CRB
by Zvi Vered 18 Jun '18

18 Jun '18

Hello, I inspected the "Bayley Baay FSP-based CRB" sample in coreboot. after make distclean I chose: Mainboard vendor: Intel Mainboard model: Bayley Bay FSP-based CRB 1. The size of CBFS is: 0x200000. Is it a fix size or should I change it according to my board (which is also bay trail) ? 2. According to "dmidecode" I ran on my target, "Address: 0xE0000" Should I set this address in coreboot configuration ? How ? 3. In this board default configuration, "Configure defaults for the Intel FSP package" is not selected. Is it possible that this board does not use Intel FSP at all ? Under "Generic Drivers", "Use Intel firmware Support Package' is also not selected. 4. Under "chipset", there is no option to set "Super I/O". Can you please tell why ? 5. I noticed that the minimum ROM size is 2MB. If I set 4MB, the size of coreboot.rom is also 4MB. Thank you in advance, Zvika

1 0

Re: [coreboot] proposal: coreboot docs in separate repo
by Branden Waldner 16 Jun '18

16 Jun '18

>> git bundles available over resumable http(s) can help a lot with that, >> but they are almost never provided. >I think this is a fair enough request, and maybe quite straightforward >to arrange. Do you already have some scripts to create a bundle every >now and then, that you could contribute? Sorry, I don't have any scripts to contribute. It seems like it doable with just a cron job running a git bundle create command and having it put it on a file server. I'm sure there would be more involved then that though. >> Board status was particularly bad, over 200 MB to clone, >Was that with git clone --depth=1 or did you clone complete history? The board_status.sh script does a full clone and I didn't want to mess with it and have it end up trying to upload an invalid commit. Maybe it would have worked with an empty initilized local repo? There is actually a fixme note in board_status.sh about it (line 419): # FIXME: the board-status directory might get big over time. # Is there a way we can push the results without fetching the # whole repo? >//Peter //Branden

1 0

Re: [coreboot] proposal: coreboot docs in separate repo
by Peter Stuge 16 Jun '18

16 Jun '18

Branden Waldner wrote: > git bundles available over resumable http(s) can help a lot with that, > but they are almost never provided. I think this is a fair enough request, and maybe quite straightforward to arrange. Do you already have some scripts to create a bundle every now and then, that you could contribute? > some weird git commands .. > Board status was particularly bad, over 200 MB to clone, Was that with git clone --depth=1 or did you clone complete history? //Peter

1 0

Re: [coreboot] proposal: coreboot docs in separate repo
by Branden Waldner 16 Jun '18

16 Jun '18

Not everyone has access to decent reliable internet and git is pretty much useless if it gets interrupted. I would prefer to be able to clone the source code[1] without the documentation without having to resort to some weird git commands to get it done. Of course, having git bundles available over resumable http(s) can help a lot with that, but they are almost never provided. Just about any use case is going to pull other repos for payloads, etc. anyway, so I don't see why having the documentation seperate would be a problem. [1] I already have the coreboot and board status repos cloned, but that doesn't change the fact that I had issues getting it done at first. Board status was particularly bad, over 200 MB to clone, over a gig as uncompressed text. all just for the script to upload a new commit - it shouldn't need all that to do it's job.

1 0

Re: [coreboot] [RFH] Native AMD fam10-15 support
by qtux 15 Jun '18

15 Jun '18

On 15/06/18 13:51, Kyösti Mälkki wrote: > On Fri, Jun 15, 2018 at 2:14 PM, qtux <mail(a)qtux.eu> wrote: > >> >>>> Coreboot did work well, but froze sometimes when booting during the >>>> assigning resources step (more or less exactly after assigning the PCI >>>> 14.3 or PNP 002e.2 device, which happen to be close to each other inside >>>> the devicetree). I had to remove the power cord in order to be able to >>>> boot again (or to get the next random freeze...). Rarely, after such an >>>> recovery, I have got flooded by IOMMU warnings in Linux which would only >>>> disappear after another reboot. >>> >>> Ah, that resume reboot-loop issue. The bit that tells to do S3 resume >>> is a sticky register backed up by Vstb rail. With [2] you should not >>> need to do full power-cycling at least. We should extend this work to >>> other platforms. >>> >> >> I am not sure whether the term resume reboot-loop applies for my issue >> (side note: I used a serial connection to monitor the boot process): >> >> Rebooting (via holding the power button for some seconds) after >> encountering a freeze (aka stopping at the assign resource step) >> resulted into having no output from serial at all. I could repeat this >> with no effect at all, the computer seemed to be dead. Only removing the >> power cord could solve the issue. >> >> This issue could occur when rebooting but even when cold booting. >> > > One of these boards had LPC related lockups. I think the solution was to > disable serial console or to set console to low loglevel. > If that is the case I would suggest to alter the default board configuration to reflect this. Nevertheless, it seems strange to me that such a lockup disappeared after changing SPI chips. > > >> Answers are inside the text. >> I forgot to mention that I am currently on commit 793ae846e8. >> > > Let's take the parent of that, commit 4a027e6e -- the one you refer to only > appears on gerrit review branch. > > Kyösti > > > That is fine, sorry for the misleading commit hash. Cheers, Matthias

2 1

Re: [coreboot] Problem with W83627DHG in Baytrail I (Possible IRQ conflict or overlapped SOC legacy COM1)
by Rudolf Marek 15 Jun '18

15 Jun '18

Hi, In general I would check ELCR (I/O port register 0x4d0) to check if it is correctly programmed to EDGE/LEVEL (it should be edge) Also, how the Linux is supposed to detect the I/O port irq? I think you need some PNP device in ACPI to let linux infer the IRQ. I would also try to disable the IRQ from SoC, you just need to check how they are enabled (sorry not an expert here) and also I would use the legacy 0x3f8 instead. Thanks Rudolf

2 3

← Newer
1
...
4
5
6
7
8
9
10
11
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 June 2018