coreboot November 2018

coreboot@coreboot.org

71 participants
149 discussions

FOSDEM Hardware Enablement Devroom
by Paul Kocialkowski 04 Dec '18

04 Dec '18

A Hardware Enablement devroom will be taking place at FOSDEM this year, on Sunday 10 December 2017. This newly-created devroom is the result of 3 proposals that were merged together. It is co-organized by several individuals. The devroom covers all aspects related to hardware enablement and support with free software, including aspects related to boot software, firmwares, drivers and userspace tools and adaptation. Proposals for talks related to these topics are welcome and can be submitted until Sunday 26 November 2017 via the pentabarf interface. Short talks are encouraged over longer ones in order to cover a wide range of topics. The announcement for the devroom, that contains all the useful information, was published at: https://lists.fosdem.org/pipermail/fosdem/2017-October/002649.html Cheers and see you at FOSDEM! -- Paul Kocialkowski, developer of free digital technology and hardware support Website: https://www.paulk.fr/ Coding blog: https://code.paulk.fr/ Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

3 3

Re: [coreboot] Asus KGPE-D16 with latest coreboot errors with Unsupported Hardware on Qubes 4 install missing IOMMU?
by Taiidan＠gmx.com 01 Dec '18

01 Dec '18

Oops sorry forgot I also need "sudo xl dmesg" from dom0!

2 1

riscv: how to running coreboot on HiFive Unleashed?
by 王翔 01 Dec '18

01 Dec '18

I try to running coreboot on HiFive Unleashed, but nothing come from uart. I tested by the following steps: 1. Write hifive-unleashed-a00-1.0-2018-03-20.gpt to TF card. 2. Change MSEL to 11 and boot linux 3. Copy coreboot.rom via scp 4. Write coreboot.rom to /dev/mtd0 by flashcp. 5. Change MSEL to 15 and boot coreboot. No response on uart. Do you have any suggestions?

2 5

Re: [coreboot] Asus KGPE-D16 with latest coreboot errors with Unsupported Hardware on Qubes 4 install missing IOMMU?
by Taiidan＠gmx.com 30 Nov '18

30 Nov '18

On 11/29/2018 12:33 PM, petecb wrote: > > I followed these instructions and found that "ucode=scan" was already present. But was it actually present in the grub.cfg you are using? > I also noticed that it had "iommu=no-igfx" That is an intel thing > so I changed this to "iommu=on" and rebooted. Unfortunately this did not appear to have an effect and when I ran the "qubes-hcl-report" it still indicated IOMMU was > not active :-( Can you provide me dmesg and # lspci -vvv from your system either in qubes or xen (does not matter what version) >>> Have you successfully got a 6386 on this board running with Qubes and all the microcode updates? >> >> Yeah I have with various 63xx CPU's. >> > > To clarify, have you been successful with Qubes 4? Yes I have and I know other people who have done it as well. > The rest of my systems are running this so I need to figure out a way to get version 4 running securely on this system. > > Do you have any other suggestions? > If this is a Xen issue do you expect it to be a while before it is fixed and merged in to Qubes? Note you can always use new versions of xen with qubes by installing yourself but I doubt that would do anything. > If a 62xx CPU definitely works and doesn't have these problems, it may be better for me to procure one of those so I can be up and running quicker. IMO Keep what you have and find out what is wrong the 63xx CPU's are much faster than 62xx. > >>> I have attached a copy of my serial output booting the system with 2 sticks of 16Gb ECC RAM (32Gb total) in case this is of any help. >> >> Put your RAM back in that would not effect anything :] >> > > I noticed it tended to take longer to boot with more RAM, so I took some out whilst I was troubleshooting :-) Yeah more RAM takes longer to train. > Do you know if this system is likely to be more stable with a single CPU and 128Gb RAM in all its slots or whether it would be better to have 2 CPUs and split the 128Gb RAM between them (ie. all Orange slots populated) Nah it doesn't matter you just can't have more than 192GB total without potentially running in to issues. Anyway don't worry I won't stop replying till all is well :D

2 1

Further coreboot releases, setting new standards
by Arthur Heymans 30 Nov '18

30 Nov '18

Dear coreboot community While the next coreboot release is due for november 2018, I think it is worthwhile to think about further releases and standards we want to set. In the past coreboot adapted numerous general improvements, which were not always ported to all coreboot targets. Keeping those platforms and their respective codepath then typically becomes a burden often accompanied with regressions. The reasonable decision to drop these targets was then made. A few examples of this were dropping targets that had a romcc compiled romstage (in favor of GCC compiled romstage running in Cache As Ram) and dropping targets without early_cbmem. Coreboot hasn't stood still and it might be time to set some new standards again which platforms have to conform. Since I mostly know x86 the following ideas will be quite x86 centric. I'd argue for requiring the following: - getting rid of NO_RELOCATABLE_RAMSTAGE on x86 This allows the ramstage to be relocated in a place out of the way of the OS such that copying the memory is unnecessary during S3 resume. - config NO_CAR_GLOBAL_MIGRATION on all x86 targets This is now achieved using postcar stage. This would mean that all x86 targets have a common way to set up and get rid of the CAR environment and car globals. - config C_ENVIRONMENT_BOOTBLOCK on all x86 targets This means that the bootblock is responsible to set up the CAR, which means that the rest of the bootblock can be compiled with GCC. This effectively makes ROMCC bootblocks obsolete. Having a bootblock with access to a working stack effectively increases the bootflow flexibility. This is reflected in for instance when using VBOOT, which can then verify all stages starting from the romstage, hence also allowing a fallback with regards to ram initialization (vs. having the romstage only in the RO_WP region). It would be a important step in making vboot useful and usable and maybe default on all targets. Any suggestions, reflections, ideas, remarks? Kind regards Arthur

12 25

Re: [coreboot] Coreboot and Kabylake FSP-M
by Jose Trujillo 30 Nov '18

30 Nov '18

Hello Roman, You need to provide the serial dump logs because I think very little amount of people here has access to the list of FSP post codes for every processor family (may be I am wrong but so far I don't know of someone who has them). Which coreboot platform are you using? Jose Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, November 29, 2018 6:09 PM, roman perepelitsin <perepelitsin.roman(a)gmail.com> wrote: > Hi! > I'm try to run Coreboot on Intel Xeon1505L with C236 and DDR4 memory down using kabylake FSP GOLD. I setup UART0 for coreboot console out and try to set UART0 for FSP-M debug out, but have only POST codes to port80/81 from FSP-M. In FSP integration guide I didn't find full POST-codes describe. > So - can some body help with this? My lasts post codes: DD46h DD30h DD32h DD35h DD45h DD36h DD37h DD41h DD4Dh DD3fh. I think it MRC codes, but that they mean - don't know. I see in oscilloscope, that DDR try to start in this stage, but after all I have error from FSP-M 80000007h. > > -- > regards, > Perepelitsin Roman

1 0

Re: [coreboot] GSOC submission
by Timothy Pearson 30 Nov '18

30 Nov '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On the POWER9 topic, it might even be possible to skip QEMU and go straight to hardware. My current understanding is that the FSI drivers in OpenBMC allow single stepping of the CPU and dumping of registers, without any other hardware being required to access those features. There's also a built-in firmware-from-RAM loader on the BMC side, so iterating changes should be fairly easy. Raptor would be also willing to donate a number of POWER9 development kits in support of a coreboot port, if there's interest. On 11/29/2018 08:13 AM, Patrick Georgi via coreboot wrote: > I was planning to apply this year, let's see what comes of it. > Thank you for the list of project ideas, very valuable! > > Patrick > > Am Do., 29. Nov. 2018 um 15:04 Uhr schrieb Arthur Heymans > <arthur(a)aheymans.xyz <mailto:arthur@aheymans.xyz>>: > > Hi > > It has been a few years since coreboot (or flashrom) applied for Google > Summer Of Code. In 2019 the applications for organizations open on > january 2019 and student applications on March 25. > > I think it would be great if the coreboot project could apply in 2019, > as doing so has been very valuable for the project in the past. > > I don't really know the full set of requirements and procedures, but I > think it could be worthwhile to start thinking about project ideas. > > A few ideas were already suggested on IRC on freenode #coreboot: > - 64bit x86 ramstage (hard) > - documented microcode update methods and write a tool that generates a > webpage which microcodes are included in coreboot (easy) > - nvidea optimus support (medium) > - QEMU power9 support / initial openpower support (hard I guess?) > - Rework device resource allocation to support 64bit BAR (relatively > hard) > > Any ideas or suggestions? > > Kind regards > > Arthur Heymans > > -- > coreboot mailing list: coreboot(a)coreboot.org > <mailto:coreboot@coreboot.org> > https://mail.coreboot.org/mailman/listinfo/coreboot > > > > -- > Google Germany GmbH, ABC-Str. 19, 20354 Hamburg > Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: > Hamburg > Geschäftsführer: Paul Manicle, Halimah DeLaine Prado > - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJcAGM2AAoJEK+E3vEXDOFbnHsIALfp6X1pdLwDNOoUXyIfWN0j icD+AvFJjZ0mrUwwGDyuo0e8uxYCdzDHsrLS0TMNDIhYEKJ6vkvwD1hl1DnV5VTZ Kmxpx7MUFmyGCYu5aGT66GqJraYM5o4qchc07D4tNZ+ZBLsk6CsGu4zUjPkGsv+x 0jCLkOrBzkx01ydPY3FYSUGs9bo+1G6CZ6sphBwotFkBury9y/lqr3GNcqGll/uK Lmdv2oZ36q5BmzRUvRWJLpw5VjNhsNnsMlRsbzbC6m7FF9Roh1pgAe/A0XlX4tNp flrJ1OdCWs/Mb7OI8DkEYzL+rILhlZDdg7RyWdYh8hkwOrGxGjMcwI9Oqs/+xZg= =bW2N -----END PGP SIGNATURE-----

2 1

Re: [coreboot] Skylake (XHCI): System self start just after suspend S3.
by Jose Trujillo 30 Nov '18

30 Nov '18

Hello Naresh: > Just to add thought in HW perspective, Is VBUS to USB ports are stable > during S3 transition. Do you see any OC# lines getting asserted ? I do not have an oscilloscope on hand until Monday BUT.... I just borrowed from my programmer's colleagues another model of COM express carrier board and works stable (as it should). So, it's certain that is a hardware flaw and probably cause a glitch on +5V_SBY (just looking and comparing the schematics of both). Not a coreboot's fault... Sorry about that, let's move on and thank you very much for your support and showing me the right way. BTW: This interesting debug information you provided me I will keep on hand for future issues. Jose Trujillo.

1 0

GSOC submission
by Arthur Heymans 30 Nov '18

30 Nov '18

Hi It has been a few years since coreboot (or flashrom) applied for Google Summer Of Code. In 2019 the applications for organizations open on january 2019 and student applications on March 25. I think it would be great if the coreboot project could apply in 2019, as doing so has been very valuable for the project in the past. I don't really know the full set of requirements and procedures, but I think it could be worthwhile to start thinking about project ideas. A few ideas were already suggested on IRC on freenode #coreboot: - 64bit x86 ramstage (hard) - documented microcode update methods and write a tool that generates a webpage which microcodes are included in coreboot (easy) - nvidea optimus support (medium) - QEMU power9 support / initial openpower support (hard I guess?) - Rework device resource allocation to support 64bit BAR (relatively hard) Any ideas or suggestions? Kind regards Arthur Heymans

4 4

Re: [coreboot] Coreboot and Kabylake FSP-M
by roman perepelitsin 29 Nov '18

29 Nov '18

Here coreboot log. Also I'm using next values for FSP-M config: *DqPinsInterleaved = FALSE;* * CaVrefConfig = 2; * * RefClk = 0;* * RcompResistor[3] = { 121, 121, 100 };* * RcompTarget[5] = { 120, 34, 39, 39, 39 };* */* Debug set - UART0 115200 - all the same -** didn't work** */* *PcdDebugInterfaceFlags = 1 << 1;PcdSerialIoUartNumber = 0;PcdIsaSerialUartBase = 0;PcdSerialDebugBaudRate = 7;PcdSerialDebugLevel = 5;* About RcompTarget - I didn't find fully describe of this values, only this - "RCOMP target values for DqOdt, DqDrv, CmdDrv, CtlDrv, ClkDrv". So, what means cmd/ctl/clk DRV? пт, 30 нояб. 2018 г. в 00:53, Naresh G. Solanki < naresh.solanki.2011(a)gmail.com>: > It mostly looks like fspm parameters are incorrect for memory init. > Can you please attach coreboot logs? > > > Regards, > Naresh G Solanki > > On Fri 30 Nov, 2018, 2:50 AM roman perepelitsin < > perepelitsin.roman(a)gmail.com wrote: > >> Hi! >> I'm try to run Coreboot on Intel Xeon1505L with C236 and DDR4 memory down >> using kabylake FSP GOLD. I setup UART0 for coreboot console out and try to >> set UART0 for FSP-M debug out, but have only POST codes to port80/81 from >> FSP-M. In FSP integration guide I didn't find full POST-codes describe. >> So - can some body help with this? My lasts post codes: DD46h DD30h DD32h >> DD35h DD45h DD36h DD37h DD41h DD4Dh DD3fh. I think it MRC codes, but that >> they mean - don't know. I see in oscilloscope, that DDR try to start in >> this stage, but after all I have error from FSP-M 80000007h. >> >> -- >> regards, >> Perepelitsin Roman >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot >> > -- regards, Perepelitsin Roman

1 0

Jump to page:

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 2018