coreboot February 2018

coreboot@coreboot.org

49 participants
79 discussions

Re: [coreboot] Asus AM1I-A
by Taiidan＠gmx.com 13 Feb '18

13 Feb '18

Has anyone figured out if the AM1 platform has IOMMU? the OEM bios on the AM1ML has an option for it but it doesn't work. The lack of that is really disappointing. I am also unable to locate the spec sheets for the AM1 platform that would confirm this.

2 1

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 13 Feb '18

13 Feb '18

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 2 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 1385944: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1385944: Null pointer dereferences (NULL_RETURNS) /src/drivers/generic/adau7002/adau7002.c: 36 in adau7002_fill_ssdt() 30 static void adau7002_fill_ssdt(struct device *dev) 31 { 32 if (!dev->enabled) 33 return; 34 35 /* Device */ >>> CID 1385944: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be null "acpi_device_scope(dev)" when calling "acpigen_write_scope". 36 acpigen_write_scope(acpi_device_scope(dev)); 37 acpigen_write_device(acpi_device_name(dev)); 38 acpigen_write_name_string("_HID", ADAU7002_ACPI_HID); 39 acpigen_write_name_integer("_UID", 0); 40 acpigen_write_name_string("_DDN", dev->chip_ops->name); 41 acpigen_write_STA(ACPI_STATUS_DEVICE_ALL_ON); ** CID 1385943: Error handling issues (CHECKED_RETURN) /src/soc/amd/common/block/s3/s3_resume.c: 30 in get_s3nv_info() ________________________________________________________________________________________________________ *** CID 1385943: Error handling issues (CHECKED_RETURN) /src/soc/amd/common/block/s3/s3_resume.c: 30 in get_s3nv_info() 24 #define DEFAULT_MRC_VERSION 0 25 26 void get_s3nv_info(void **base, size_t *size) 27 { 28 struct region_device rdev; 29 >>> CID 1385943: Error handling issues (CHECKED_RETURN) >>> Calling "mrc_cache_get_current" without checking return value (as is done elsewhere 6 out of 7 times). 30 mrc_cache_get_current(MRC_TRAINING_DATA, DEFAULT_MRC_VERSION, &rdev); 31 *base = rdev_mmap_full(&rdev); 32 *size = region_device_sz(&rdev); 33 if (!*base || !*size) 34 printk(BIOS_ERR, "Error: S3 NV data not found\n"); 35 else ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Re: [coreboot] Asus AM1I-A
by Elisenda Cuadros 12 Feb '18

12 Feb '18

Hi Gergely, Sorry, I didn´t know the PCI IDs are APU depending. I´m using an Athlon 5350. Yes, the differences are minor. Only UART used and TTYS0_BASE address. Thank you for clarifying the memory requirement. I didn´t see it in the manual :-( . Maybe you can change the defaults for CONFIG_UART_FOR_CONSOLE=1 and CONFIG_TTYS0_BASE=0x2f8. Actually, I only bought this board to have this port tested and working :-) . But, like you said, it´s the ideal system for a HTPC. I have a AM1M-A too. I think this board is (almost) identical. "Only" it has more PCIEs slots (it´s micro-atx) Thank you for your work and your valuable help. Best regards, Eli On 13/02/2018 6:57, Gergely Kiss wrote: > Hi, > > taking a look at the diffs, I can't see any major difference. > CONFIG_USE_BLOBS is y by default so setting it to y is not really > useful. The only notable difference is that you used COM1 for console > output instead of COM2 (which is the port soldered on-board). However, > this does not seem to explain why you got "slow" output on your > console. If the COM port number and the base address is specified > incorrectly then you'd see no output, at all, so I'm unsure what the > real issue was in your case and how you managed to fix it. > > As for the PCI IDs of the VGA adapter, it can be different depending > on what APU is installed. My installation uses the one that is set in > Kconfig by default. > > The requirement to place the DIMM to slot DIMM_A2 (the slot closest to > the edge of the board) when only one module is present is noted in the > vendor manual on page 1-7. > > About changing the defaults in the board's Kconfig, I'm not sure what > you mean, could you please clarify? I think changing the default VGA > PCI ID does not make sense as the VGA controller is integrated to the > APU so each APU model and revision might use different PIDs and I > believe there's no point preferring one ID over the others. The one > that I have included is for reference only which might need to be > changed to match the APU installed (my installation uses a Sempron > 3850 APU). > > Anyway, I'm happy to see that you could finally make coreboot work on > your board, it's good to known I'm not the only user of my port! :) > > Regards, > Gergely > > On 11 February 2018 at 12:26, Elisenda Cuadros <lists(a)e4l.es > <mailto:lists@e4l.es>> wrote: > > 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 >> <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 >>> >>> >>> >> >> >> >> > >

1 0

QEMU x86_64 Q35 Automated Test Failure [master]
by Raptor Engineering Automated Coreboot Test Stand 12 Feb '18

12 Feb '18

The QEMU x86_64 Q35 fails verification for branch master as of commit 1b64ae1119fc7891b043d5d29bf93859ef9dbfa1 The following tests failed: BOOT_FAILURE Commits since last successful test: 1b64ae1 soc/intel/cannonlake: Add Pch iSCLK programming 106a9fe mb/google/fizz: Set SATA GPIOs in bootblock f0b3a5f mb/google/poppy/variants/nautilus: set oem_id, oem_table_id fields of acpi_header_t 3dd7d84 mainboard/google/meowth: Enable ECT again b924f40 mb/google/poppy/variants/nami: set oem_id, oem_table_id fields of acpi_header_t <45 commits skipped> 75f5d99 mb/asus/m2v-mx_se: Add `cmos.default` 25874b8 mb/google/eve: Enable HotPlug on PCIe root port for WiFi 74ea48e soc/intel/skylake: Add devicetree variable for PCIe HotPlug f5e3775 google/kahlee: Initialize non-early i2c buses in mainboard_init e0ea982 soc/amd/stoneyridge: Add API to initialize non-early_init i2c buses See attached log for details This message was automatically generated from Raptor Engineering's QEMU x86_64 Q35 test stand Want to test on your own equipment? Check out https://www.raptorengineering.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineering.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineering.com> regarding any issues stemming from this notification

3 2

Re: [coreboot] Custom Layer or Overlay
by Naveed Ghori 11 Feb '18

11 Feb '18

Thanks David. Not sure if it exactly what I recall as being mentioned. .. but could be wrong. Basically I wanted to place my proprietary board files in a location that would not pollute the main Coreboot repo with boards that no one else has access to. I will look further into thridparty but according to the text file you pointed to it is probably not exactly what I am after. On Sat, Feb 10, 2018 at 4:56 AM, David Hendricks <david.hendricks(a)gmail.com> wrote: > Hi Naveed, > 3rdparty/ is probably what you want. That directory is managed using git > submodules: https://review.coreboot.org/cgit/coreboot.git/tree/Documenta > tion/submodules.txt > >

1 0

QEMU x86_64 Q35 Automated Test Failure [master]
by Raptor Engineering Automated Coreboot Test Stand 11 Feb '18

11 Feb '18

The QEMU x86_64 Q35 fails verification for branch master as of commit 3be35976d6a640d0bc4fd40e232b6499b170431f The following tests failed: BOOT_FAILURE Commits since last successful test: 3be3597 google/snappy: enhance BigDaddy USB#2 2.0 strength 1b64ae1 soc/intel/cannonlake: Add Pch iSCLK programming 106a9fe mb/google/fizz: Set SATA GPIOs in bootblock f0b3a5f mb/google/poppy/variants/nautilus: set oem_id, oem_table_id fields of acpi_header_t 3dd7d84 mainboard/google/meowth: Enable ECT again <46 commits skipped> 75f5d99 mb/asus/m2v-mx_se: Add `cmos.default` 25874b8 mb/google/eve: Enable HotPlug on PCIe root port for WiFi 74ea48e soc/intel/skylake: Add devicetree variable for PCIe HotPlug f5e3775 google/kahlee: Initialize non-early i2c buses in mainboard_init e0ea982 soc/amd/stoneyridge: Add API to initialize non-early_init i2c buses See attached log for details This message was automatically generated from Raptor Engineering's QEMU x86_64 Q35 test stand Want to test on your own equipment? Check out https://www.raptorengineering.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineering.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineering.com> regarding any issues stemming from this notification

1 0

Re: [coreboot] Are multiple GPUs with lots of memory (ex: 8GB+8GB) supported in coreboot?
by echelon＠free.fr 11 Feb '18

11 Feb '18

So .. what's the solution?.. Why this statement: ".. It's not a straight-forward solution to simply push all prefetchable BARs above 4GiB (that would be NICs and GFX too)..." ? >From what I'm seeing this feature is not only usefull, it is essential.. (if we were to pretend always supporting real high-performance HW like powerfull GPUs..). As Taiidan said, it's really a shame that nobody continued working on this.. What can be done?.. Maybe some of us would be able/willing to pick-up this task, but as this implies modifying the resource allocator which seems like a critical element of coreboot.. (if I'm not mistaken..), someone with experience should (at least) give the entry points.. My 2 satoshis, Florentin ----- Mail d'origine ----- De: Kyösti Mälkki <kyosti.malkki(a)gmail.com> À: Taiidan(a)gmx.com Cc: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net>, Arthur Heymans <arthur(a)aheymans.xyz>, coreboot <coreboot(a)coreboot.org> Envoyé: Sun, 11 Feb 2018 22:47:05 +0100 (CET) Objet: Re: [coreboot] Are multiple GPUs with lots of memory (ex: 8GB+8GB) supported in coreboot? On Sun, Feb 11, 2018 at 11:04 PM, Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote: > On 02/11/2018 03:32 PM, Carl-Daniel Hailfinger wrote: > >> On 10.02.2018 19:57, Arthur Heymans wrote: >>> >>> "Taiidan(a)gmx.com" <Taiidan(a)gmx.com> writes: >>>> >>>> I would like to add this information to the wiki so I am wondering if >>>> anyone has successfully used for instance dual 8GB graphics cards with >>>> coreboot. >>>> >>> I don't think that this gpu memory is mapped into the linear memory >>> space. Such a GPU will typically have a PCI memory resource BAR that is >>> (only) 256M large (could be 512M or more these days). >>> >>>> I am not sure if this would be an issue due to coreboot only having >>>> 32bit MMIO space. >>>> >>> It depends a bit on how things are configured but with a fairly common >>> 2G mmio space below 4G I think it is unlikely for 2 external GPU's to be >>> an issue. >>> >>> It would of course be nice to have 64bit BAR support but that would >>> require substantial changes in the allocator and more importantly a lot >>> of time spend in a sane and thoughtful design... >> >> I think Myles Watson (not 100% sure) worked on an improved resource >> allocator with 64 bit resource support for v3. I do not know if it ever >> was merged in v4, or if that was instead a port of the v2 allocator to >> v3, in which case this would be mostly what we have now. The mails about >> this are mostly from 2009. > > Thanks for the info everyone :] > > That is a damn shame it didn't get merged, it would be quite useful to make > coreboot a better server platform - it is needed for many nics, sr-iov, etc. > Hi Some of that work did get merged, bust mostly hacked in for certain AMD parts only. After some years, that code did not even build anymore as it was behind some #ifdef and Kconfig options, and no board had it enabled by default. 64 bit PCI BARs (as configuration registers) are supported, but no MMIO resources are pushed over 4GiB boundary as stated above. You need some classification of what resources must reside in 32bit space. That is, all the resources payload may need to use. It's not a straight-forward solution to simply push all prefetchable BARs above 4GiB (that would be NICs and GFX too). Any off-board, prefetchable 64bit BARs that are large (say over 64MiB) in size might a viable starting point, where 32bit space would not run out of room. I have had a look at this before, but without funding did not pursue for submitting or completing it. There was also work maybe two years ago, reusing some of the design choices from UEFI. I think the developer never returned with answers or change requests for the changeset. AFAIR it relied on identinfying whether a device has an oprom associated with it, so I did not find that work mergeable. Kyösti -- coreboot mailing list: coreboot(a)coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot

2 1

Are multiple GPUs with lots of memory (ex: 8GB+8GB) supported in coreboot?
by Taiidan＠gmx.com 11 Feb '18

11 Feb '18

I would like to add this information to the wiki so I am wondering if anyone has successfully used for instance dual 8GB graphics cards with coreboot. I am not sure if this would be an issue due to coreboot only having 32bit MMIO space. Thanks!

4 4

Re: [coreboot] Asus AM1I-A
by Elisenda Cuadros 10 Feb '18

10 Feb '18

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 > > 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 > > >

2 1

Re: [coreboot] kasten.core backdoor? new weird message after each coreboot build
by Mike Banon 10 Feb '18

10 Feb '18

Looks like there was the old hidden window of okteta hex editor that I forgot to close, and for each rebuild of coreboot.rom okteta's core printed these spooky messages :P Sorry for the false alarm... (although its never wrong to be on high alert) On Sat, Feb 10, 2018 at 10:52 PM, Mike Banon <mikebdp2(a)gmail.com> wrote: > While building a coreboot now I'm getting this "kasten.core" message > (see below), it wasn't like that earlier! Tried to search through all > the coreboot sources with ' find . -type f -print0 | xargs -0 grep > "kasten" ' but no results! So thats not a new coreboot build script. > It almost looks like instantly after I complete a coreboot build, > something malicious modifies my coreboot.rom file. Haven't analyzed > the .rom yet, I wanted to submit these findings as soon as possible. > What do you think? Meanwhile I will take my system offline and remove > a hard drive from it, so that someone couldn't remotely delete this > backdoor before I find it > > CBFS payload_config > CBFS payload_revision > CBFS coreboot.rom > kasten.core: "/home/mikeb/coreboot/build/coreboot.rom" > CBFSPRINT coreboot.rom > > Name Offset Type Size Comp > cbfs master header 0x0 cbfs header 32 none > fallback/romstage 0x80 stage 320396 none > fallback/ramstage 0x4e480 stage 131631 none > config 0x6e700 raw 84 none > revision 0x6e7c0 raw 575 none > cmos_layout.bin 0x6ea40 cmos_layout 1164 none > fallback/postcar 0x6ef40 stage 13268 none > fallback/dsdt.aml 0x72380 raw 9016 none > fallback/payload 0x74700 payload 67370 none > payload_config 0x84e80 raw 1611 none > payload_revision 0x85540 raw 239 none > (empty) 0x85680 null 3581720 none > s3nv 0x3efdc0 raw 32768 none > (empty) 0x3f7e00 null 31704 none > bootblock 0x3ffa00 bootblock 928 none > > Built lenovo/g505s (LENOVO G505S) > mikeb@testing:~/coreboot$ kasten.core: "/home/mikeb/coreboot/build/coreboot.rom"

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 February 2018