coreboot April 2018

coreboot@coreboot.org

68 participants
128 discussions

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

[RFH] Asus KGPE-D16: Tester for commit
by Paul Menzel 16 Apr '18

16 Apr '18

Dear coreboot folks, Could somebody please test if on the Asus KGPE-D16 the PS/2 keyboard still works after resume from ACPI S3 with the change-set *winbond/w83667hg-a: Disable mouse controller also during resume* [1] applied? Kind regards, Paul [1] https://review.coreboot.org/#/c/coreboot/+/22286/

1 0

Re: [coreboot] Asus AM1I-A
by Elisenda Cuadros 16 Apr '18

16 Apr '18

Hi Gergely, Thank you for your config. Now I have coreboot + SeaBIOS perfectly working. Console speed is now "normal" :-) These are the changes between the two configs: ------------- diff config_original.txt config_Gergely.txt 23c23 < # CONFIG_USE_BLOBS is not set --- > CONFIG_USE_BLOBS=y 101c101 < CONFIG_UART_FOR_CONSOLE=0 --- > CONFIG_UART_FOR_CONSOLE=1 150c150 < CONFIG_POST_DEVICE=y --- > # CONFIG_POST_DEVICE is not set 210c210 < CONFIG_TTYS0_BASE=0x3f8 --- > CONFIG_TTYS0_BASE=0x2f8 428,429d427 < # CONFIG_PCI_OPTION_ROM_RUN_REALMODE is not set < # CONFIG_PCI_OPTION_ROM_RUN_YABEL is not set 431d428 < # CONFIG_VGA_TEXT_FRAMEBUFFER is not set 556c553 < # Serial port base address = 0x3f8 --- > # Serial port base address = 0x2f8 581,583d577 < CONFIG_POST_DEVICE_NONE=y < # CONFIG_POST_DEVICE_LPC is not set < # CONFIG_POST_DEVICE_PCI_PCIE is not set -------------- I made some tweaks to the configuration, added VGA output before payload, a nice bootsplash, etc.. Other considerations: VGA Device PCI IDs are 1002,9830 (The default 1002,9836 does not get output). Memory has to be located firstly on second slot (yellow DIMM_A2). If not you get AGESA_FATAL_ERROR. I only have one module. Please, find attached a working config.txt and console.log. Coreboot revision is 4.7-294-g2db6fbc47b. If you verify these changes are working for you is it possible to change the defaults in Kconfig? Thank you very much. Best regards, -- Eli On 11/02/18 00:07, Gergely Kiss wrote: > Strange, the log you shared looked less verbose to me than expected > but seems like I was wrong. Anyway, you might find an example on a > full debug log here [1]. > > I have a small build script I use to build coreboot for my board, > please find it attached. > > The version currently running on my box is 4.6-2554-ga1b4c94. > > [1] https://www.coreboot.org/Board:asus/am1i-a#Bootlog > > On 10 February 2018 at 23:18, Elisenda Cuadros <lists(a)e4l.es > <mailto:lists@e4l.es>> wrote: > > Thank you for your kind reply Gergely. > > I think the cable is not the problem, I have been using it for > years and it's intact. > > I am using a usb dongle but not a cheap one. Tomorrow I will try > with another cable and a real COM port. Just to be 100% sure. > > Console is fast at the very first time (just the "normal") but > after two seconds it becomes extremely slow. > > Please, can you say me which is the git revision you are using? > > The console log I attached is from a SPEW debug level, not > corresponding with the config.. I tried several configs today :-) . > > Is it possible to share your config with me? > > Best regards, > > Eli > > > On 10/02/18 21:44, Gergely Kiss wrote: >> Hi Eli, >> >> I've been using Coreboot on my board for several weeks, it is >> serving as an HTPC running 24/7 and it's working perfectly stable >> which suggests the firmware should be free of bugs. It is likely >> that you are facing some configuration or hardware issue here. >> >> I didn't see any issues with the serial output while working with >> the board once the SuperIO chip started to work. Make sure the >> cable you use is intact and try to attach it to another machine. >> At the time I was working with my board, I used a Dell Port >> Replicator with a native COM port so I could use a standard >> null-modem cable and it was working flawlessly. In case you use a >> USB serial adapter, try replacing it or attach the serial cable >> directly to a COM port if you have one available. >> >> Also, please enable debug_level=Spew as it seems the console log >> you attached comes from a less verbose setting and therefore it's >> not as useful as it should be. >> >> Note that the VBIOS image is executed by SeaBIOS which means you >> won't see anything on your display until the payload is executed. >> >> If all else fails, you can still attach a POST debug module to >> the LPC header of the board [1] which can help a lot to find out >> where the boot process hangs. >> >> Feel free to contact me if you need some more help or >> information, I'm happy to assist! >> >> Regards, >> Gergely >> >> [1] https://www.youtube.com/watch?v=aGGqsWx3-1c >> <https://www.youtube.com/watch?v=aGGqsWx3-1c> >> >> On 10 February 2018 at 18:17, Elisenda Cuadros <lists(a)e4l.es >> <mailto:lists@e4l.es>> wrote: >> >> Hello, >> >> I'm trying to use Coreboot in an Asus AM1I-A board recently >> ported by Gergely Kiss (thank you!). >> >> I am using the default config settings and added vga rom >> extracted with UEFITool from the vendor bios. >> >> After flashing and booting I get no output from vga. >> >> Serial console is extremely slow too (30 minutes to write the >> log) >> >> I attach the coreboot console log, config and cbfs.txt. >> >> Any hints? >> >> Thanks in advance. >> >> Best regards, >> >> -- Eli >> >> >> > > > >

3 5

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

15 Apr '18

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 ? 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. The benefit of having it in blobs repo is that it increases compability and user friendliness. Just tick the Kconfig option, done. It is independed from a free tool to generate a VBT (which would be nice to have). > Nico > > PS. Please fix your mail client. It shouldn't break quoted lines. > > PPS. If VBT ends up in 3rdparty/blobs, please also make a distinction > in Kconfig between binary programs and configuration data (or get > rid of USE_BLOBS).

2 1

How to handle vbt.bin
by Arthur Heymans 15 Apr '18

15 Apr '18

Hi Recently there has been some development towards better handling of the VBT (Video BIOS Table) on Intel targets within coreboot. [1],[2](and a whole lot of patches that hook up this code). VBT is usually a part of the option rom for the Intel integrated graphic device. It is pure configuration data that is in binary format, has a variable length and is fully documented. The OS typically needs to know a few things about the hardware like on which I2C address to talk to SDVO devices, which I2C pins to use for the VGA port (standalone or shared with DVI-I port). Linux can typically work to some extend without it by it assumes some defaults but the Windows drivers fails to work without it. I heard it is also a hard requirement for the GOP (pre-os driver). Usually this VBT data is passed on via the option rom address for video devices (0xc0000) but this can also be passed on via ACPI via a pointer, which coreboot can do (either by extracting it from an option rom in cbfs or via a cbfsfile named vbt.bin) Now the real question. Since this is purely configuration data that is also fully documented it holds no copyright and can be included into the coreboot project without legal troubles. Now one would be able to generate this binary file but due to its modularity and variable length such generator would be tedious to create. So currently the option are to either include the binary in the blob repo or in the main repo. An argument was made that it belongs in the main repo in the src/mainboard/*/*/ dir as we already have binary configuration data in there, namely SPD (serial presence detect) for soldered dram. Also having the policy of allowing (and encouraging) such binaries in the main repo could make it easier for users to run their self-build coreboot roms on devices from big coreboot vendors (like Google). So what are your thoughts on this? Kind regards Arthur Heymans -------------- [1] https://review.coreboot.org/#/c/coreboot/+/18902/ [2] https://review.coreboot.org/#/c/coreboot/+/19905/

4 4

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

15 Apr '18

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. > > > > > > For the example case you sited of users building coreboot images > > for > > > Chromebooks (eg), they still need numerous other platform/device > > specific > > > blobs (ie, FSP), so having the vbt alone in the main repo is > > really not of > > > any consequence. > > > > That's very wrong. For instance I would have added Skylake+ > > backlight > > support to coreboot over a year ago if the information wasn't > > hidden in > > a secret lair. Not having information published early and > > conveniently > > accessible is always of consequence. You might just not know in > > what > > ways yet. ;) > > I meant having the vbt in the main repo vs blobs repo wasn't of any > consequence > for building upstream coreboot images, given that other blobs are > still needed. > But agree that either location is better than none :) > > > > I'd also like to see those other required blobs in the > > > 3rd party blobs repo, but that's an entirely separate issue :) > > > > True. > > > > Nico > > Patrick

3 2

asrock-B75-pro3-m
by CarlosGonzalez 14 Apr '18

14 Apr '18

Hello: coreboot team I am look for help on coreboot install, I have issues to get work coreboot on my side, so I have many questions to understand this field. 1) I have asrockB75Pro3m with !7 k serie. this will wok with coreboot? 2) will coreboot work without ME intel? 3) When i use -E from flashrom this erase regions including ME intel? If yes can I put ME intel back using flashrom? 4) what command to use on flash coreboot in asrockB75Pro3m? 5) Is nesesary do layout to get coreboot work? if yes how I do a correct layout? Thanks.

1 0

ifdtool change layout and density simultaneously
by Trammell Hudson 14 Apr '18

14 Apr '18

I just noticed that ifdtool doesn't work correctly if the layout and density are changed simultaneously: % ./coreboot-4.6/util/ifdtool/ifdtool -n /tmp/layout.txt -D 16 /tmp/test.rom File /tmp/test.rom is 8388608 bytes The image has changed in size. The old image is 8388608 bytes. The new image is 16777216 bytes. Copy Descriptor 0 (Flash Descriptor) (65536 bytes) from 00000000+00000000:0000ffff ( 65536) to 00000000+00000000:0000ffff ( 65536) Copy Descriptor 1 (BIOS) (4128768 bytes) from 00400000+00000000:007effff ( 4128768) to 00410000+00800000:00ffffff ( 12517376) Copy Descriptor 2 (Intel ME) (4128768 bytes) from 00010000+00000000:003fffff ( 4128768) to 00010000+00000000:003fffff ( 4128768) Copy Descriptor 4 (Platform Data) (65536 bytes) from 007f0000+00000000:007fffff ( 65536) to 00400000+00000000:0040ffff ( 65536) Writing new image to /tmp/test.rom.new Setting chip density to 16MB Writing new image to /tmp/test.rom.new The resulting file has only the density change; the layout changes have been discarded. Instead it is necessary to run two commands: % ./coreboot-4.6/util/ifdtool/ifdtool -n /tmp/layout.txt /tmp/test.rom File /tmp/test.rom is 8388608 bytes The image has changed in size. The old image is 8388608 bytes. The new image is 16777216 bytes. Copy Descriptor 0 (Flash Descriptor) (65536 bytes) from 00000000+00000000:0000ffff ( 65536) to 00000000+00000000:0000ffff ( 65536) Copy Descriptor 1 (BIOS) (4128768 bytes) from 00400000+00000000:007effff ( 4128768) to 00410000+00800000:00ffffff ( 12517376) Copy Descriptor 2 (Intel ME) (4128768 bytes) from 00010000+00000000:003fffff ( 4128768) to 00010000+00000000:003fffff ( 4128768) Copy Descriptor 4 (Platform Data) (65536 bytes) from 007f0000+00000000:007fffff ( 65536) to 00400000+00000000:0040ffff ( 65536) Writing new image to /tmp/test.rom.new % ./coreboot-4.6/util/ifdtool/ifdtool -D 16 /tmp/test.rom.new File /tmp/test.rom.new is 16777216 bytes Setting chip density to 16MB Writing new image to /tmp/test.rom.new.new -- Trammell

1 0

Re: [coreboot] BIOS/CoreBoot/UBOOT
by Taiidan＠gmx.com 13 Apr '18

13 Apr '18

On 04/11/2018 06:39 PM, Raymond Yeung wrote: > I currently have a board that uses Intel Xeon D (previously codenamed Broadwell DE). It boots up with BIOS/UEFI. I 'm exploring other oot-up options here. Let us know what you are attempting to accomplish. > I'm not familiar with this early stage of system initialization. It seems BIOS/UEFI to Linux needs to use PXE Hm? do you want to boot over the network? why would you need PXE just to boot linux on your local machine? I believe there is a neat petietboot coreboot payload with some network booting features that is better than PXE....there is also iSCSI as an option of course either a coreboot payload or part of a networking card. > with the need to configure DHCP (and possibly Proxy DHCP), TFTP server PXELINUX, Linux initial RAM disk (initrd) configuration file, and then Linux. Previously, I'd been using Coreboot/UBOOT environment (as a user, not developer). Prerequisite seemed much simpler. I am sorry I do not understand what you wish to do? > A few questions - > > > 1. Is there even a coreboot support for this CPU already available and stable that I could download and reflash? Or are we talking about some serious re-development? The issue isn't support for the CPU it is support for your board, there are a few broadwell boards in coreboot but they are only development boards with no board status so I have no idea if the platform port even works. FYI the hardware initiation for the newer intel stuff is done entirely by intels FSP binary blob in case you are wondering so there isn't really much to change or poke around with. > 2. Is it possible to go from BIOS/UEFI to UBOOT (on-board)? How? Without coreboot no it isn't. > 3. Support for Secure Boot - would one approach be simpler than another? SB was invented by MS for DRM, it serves no real security purpose IMO and such a thing is better served by for example a grub payload with kernel code signing enabled where you sign your own kernels. "pointless? why?" Any hypothetical rootkit could simply infect some other key system component that is always loaded and used every time the computer is running. "DRM?" SB 2.0 has removed the owner control mandate from MS leaving OEM's free to not offer it, eventually only "developer" computers that cost much more will let you install linux leaving the next generation of computer programmer kids out in the cold and only able to create programs for windows in a walled garden....even wealthy families probably wouldn't know to get their kid a special computer and most would just give up when faced with a "you cant do that" error. > 4. Am I even on the right track thinking this way? Ports for coreboot cost a lot of money (think 50K+) or if you have the necessary firmware development skills 6months+ of time and effort honestly I would just buy a board that already has what you want if you want to play around with firmware programming - the entirely open source being the very fast TALOS 2 (factory libre firmware but not coreboot) and the not as fast KGPE-D16 (libre coreboot and OpenBMC ports are available) unfortunately "coreboot" in general no longer means open source firmware for most boards so be aware if you want to buy something else. Anyways welcome to the community :]

4 5

Re: [coreboot] When does AMD release the fam15 spectre microcode updates?
by Taiidan＠gmx.com 13 Apr '18

13 Apr '18

On 04/12/2018 09:06 AM, Mike Banon wrote: >> AMD kept their promise. > Are you sure? I cannot find any download links except for the Windows 10. > Yes, theoretically it should be possible to unpack those monstrous .cab files > aimed for Win10 and extract a microcode hidden somewhere, but this is stupid. > Do you have the download links for the standalone microcode updates? Yeah its absolutely retarded but this is par for the course these days, I unfortunately have no idea where to obtain them but they apparently do exist. The so called experts in charge these days think letting us peons own and control our computer, and run and have access to whatever code we please is simply too dangerous. In this absurdly risk adverse society they don't want to have any tech support requests because they released it to everyone and "help it doesn't work".

1 0

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