coreboot October 2017

coreboot@coreboot.org

66 participants
140 discussions

Re: [coreboot] Problems changing payload on Intel Leaf Hill
by Tahnia Lichtenstein 26 Oct '17

26 Oct '17

Hi Craig, coreboot folks, Short answer is no, I have not had any luck, I am still stuck! As per suggestions from the coreboot community, I tried the following, which results in no change (i.e. no serial debug console output and no graphics output once coreboot transitions to payload): *Tianocore* · Ensure UDK2017 CorebootPayloadPkg sets up serial console port with 115200 bps baud, 8 data bits, no parity, 1 stop bit to match coreboot config – However I am unsure if the com port matches coreboot’s config (COM2) · Compile UDK2017 with the same toolchain as coreboot (previously compiled using VS2015 toolchain)… After this didn’t work I’m now just using plain GCC5 · Compile UDK2017 32-bit version (as my previous attempts focused on 64-bit). After this didn’t work I reverted back to 64-bit version, since I would like to run 64-bit Windows 10 IoT (amongst others) · Try using VGA BIOS Option ROM, to no avail o The only relevant files I could find were vbt.bin and vbt.dat variants. I believe this is the type of video “drivers” required by a UEFI payload (as opposed to vbios)? o I could not find any vbios file compatible with Leaf Hill o Intel provides a tool to create your own vbios file from a template, but this seemed error-prone to me, so I have not yet tried this o I managed to find a “gop_10.0_1035_64bit.zip” which contains an IntelGopDriver.efi, but I have not tried to integrate this into the Tianocore build because I don’t know how (yet) *SeaBIOS* · The SeaBIOS config previously used the wrong COM port for serial console output – I changed it to COM 2 to match coreboot’s config. The rest of the serial console settings looked fine to me · The SeaBIOS serial debug level was previously set to 1, which I changed to 8 · As per above Tianocore efforts, I was not able to obtain a compatible VGA BIOS Option ROM, so could not try this · Even without graphics, I would have expected the COM port config update to show me output on the serial console, which is not the case · Qemu does work using SeaBIOS Following discussion on another coreboot thread (“Intel Leaf Hill Coreboot Trouble”), I tried the following: *U-Boot* · Following discussion with Craig, I realised U-Boot requires some updates to incorporate coreboot’s device tree. · I followed U-Boot’s readme instructions and am fairly certain it is now set up correctly. (see https://github.com/qemu/u-boot/blob/master/doc/README.x86) o I tried including uboot payload directly in coreboot's make menuconfig as well as loading it through running the cbfs command to add it - does not seem to make a difference) · I also applied Intel’s provided patch to support Leaf Hill · The U-Boot payload gets further than Tianocore and SeaBIOS – there is serial console output, and U-Boot loads its command line interface · When running the “pci” command, the output seems to match the coreboot device tree · When running “usb start” I get “no controllers found” · When running “sf probe 0” I get “Invalid bus 0 (err=-19) Failed to initialize SPI flash at 0:0 (error -19)” · I tried to poke around in the U-Boot .config. o Manually enabling USB and SPI flash support in this config file results in “redeclaration” of variables warnings o Following up on these warnings, it really does seem that USB and SPI flash is already enabled by other deeper level config files · No idea why USB does not work, and have not yet tested to see what else also does not work · Verified that SSD SATA device works, but unable to load Yocto from SDD (due to some strange System D initialization errors) · My Yocto build was verified to work using the precompiled payload obtained from Intel · When you say U-Boot would require a lot of work, have you identified in detail what needs to be done? Is most of it not already done in the Intel U-Boot patch? o Does the GPL license extend to code patches for GPL projects? Am I allowed for instance to share a U-Boot code patch if it was obtained from an Intel website that requires CNDA access? Various payload config files attached with accompanying coreboot configs and serial output logs. Also attached coreboot device tree (to compare to uboot's "pci" command output). Any ideas what I'm doing wrong? Regards, Tahnia On Tue, Oct 24, 2017 at 4:51 PM, Cameron Craig <Cameron.Craig(a)exterity.com> wrote: > Hi Tahnia et al, > > Have you had any luck with Tianocore or SeaBIOS on Leaf Hill? > > I would be interested to know if you (or anyone!) have managed to get any > of these working on Leaf Hill. > We are now also considering these, as U-Boot on Leaf Hill looks like a > fair bit of work. > > Cheers, > Cameron > > > > > Cameron Craig | Graduate Software Engineer | Exterity Limited > tel: +44 1383 828 250 | fax: | mobile: > e: Cameron.Craig(a)exterity.com | w: www.exterity.com > > > -----Original Message----- > >From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Nico > >Huber > >Sent: 10 October 2017 15:12 > >To: Tahnia Lichtenstein; coreboot(a)coreboot.org > >Subject: Re: [coreboot] Problems changing payload on Intel Leaf Hill > > > >Hi Tahnia, > > > >On 10.10.2017 10:29, Tahnia Lichtenstein wrote: > >> ... > >> > >> Then I built this version of coreboot with a self-compiled payload, > >> such as Tianocore UDK2017 CorebootPayloadPkg or SeaBIOS, using the > >> .confg files provided by Intel for UEFI payloads or legacy payloads > >> respectively (just modified for specific payload type and path, and > >> disabling verified and measured boot). I stitched the coreboot output > >> with the Intel-provided blobs using the exact same method as before. > >> Then, in run-time, coreboot transitions to the payload and nothing > >> happens from then on (i.e. no further serial debug messages, no change > to > >display monitor). > > > >you've only attached config files for your coreboot but not for the > payloads. > >It's hard to tell what output to expect without that (e.g. > >do you have serial output enabled in your SeaBIOS build? if you let the > >coreboot build environment configure SeaBIOS it is enabled expli- citly). > So > >with the current information you've provided, it could just be that the > >payloads don't try to output anything on serial. > > > >Output on a monitor is a little more complicated and depends on each > >payload. SeaBIOS expects a Video BIOS to be present. This can either be an > >option ROM from a gfx adapter card (looking at your logs, you don't seem > to > >have one), a Video BIOS file in CBFS matching the inte- grated gfx > adapter, or, > >in case coreboot already configured a frame- buffer, a Video BIOS shim > called > >SeaVGABIOS (aka. cbvga in this case, it's a separate component in the > SeaBIOS > >source). > > > >Current CorebootPayloadPkg *should* be able to use a preconfigured > >framebuffer. I never tried it, though, and there are reports that it > doesn't > >always work... It's generally possible that Intel's precom- piled UEFI > payload > >has it's own gfx driver (GOP) built in. > > > >> ... > >> Am I not specifying the correct configuration options for Tianocore > >> and SeaBIOS? I.e. is there more to it than just selecting the payload > >> type and specifying the payload path? Do I need to configure or update > >> memory addresses or ranges to match payload sizes, or some such? Do I > >> need to make specific changes to the payloads' source code to support > >> the platform? Any advice on how/where to start debugging? > > > >Usually there is nothing more to specify. The best option, IMO, is to get > one of > >the simpler payloads (SeaBIOS should do) to output on serial. > >You can also test your SeaBIOS binary in QEMU to make sure it does out- > put > >something. > > > >Hope that helps, > >Nico > > > >-- > >coreboot mailing list: coreboot(a)coreboot.org > >https://mail.coreboot.org/mailman/listinfo/coreboot > > > >___________________________________________________________ > >___________ > >This email has been scanned by the Symantec Email Security.cloud service. > >For more information please visit http://www.symanteccloud.com > >___________________________________________________________ > >___________ > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ >

1 0

Thinkpad T430s, grub2 40sec lags, disable SATA ports 2~5?
by Kyle K 25 Oct '17

25 Oct '17

Hello, I had a great success of compiling and flashing latest git of Coreboot onto T430s laptop that I have https://i.redd.it/n3mldxw43xtz.jpg I have learned a lot and would like to thank all the developers and contributors for all the hard work they did. I have been experiencing issue with grub2 (grub2 is my payload) where it lags/hangs for 40 seconds each time I do a 'ls' in '>grub ' shell. I believe this is due to Coreboot exposing 6 SATA ports to grub2 and OS. My grub.cfg is composed of functions such as 'for ahci0 ahci1 ahciX' that go through some disks and partitions to find an OS to boot from (I dumped grub.cfg from libreboot and used it in my coreboot.rom), with 40sec access lags this leads to unbootable OS and I boot by issuing commands manually from grub rescue shell. When I 'rmmod ahci' all the lags go away, typing 'ls' lists "(memdisk) (cbfsdisk)" instantly. However I need ahci for obvious reasons. How can I tweak the sata_port_map value to only enable first 2 SATA ports? Port 0 for my SSD and Port 1 for the CD-ROM? I believe in src/mainboard/lenovo/t430s/devicetree.cb I could change the value [ register "sata_port_map" = "0x17" ]. However I'm not sure what the value should be. Please help and advise. Thanks

1 0

Re: [coreboot] Let’s solve the Asus KCMA-D8 mess
by Timothy Pearson 24 Oct '17

24 Oct '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/29/2017 02:54 PM, Pierre P wrote: > > > Hi, > > > Thanks Paul for this peaceful and hopeful message. I'll follow you and > would like to help with another 1000 €. > > > Thanks Timothy for your work ! > > > Pierre Just wanted to follow up with some closure on this thread. Leah contacted us earlier this year and offered to pay; all debts have been settled at this point and we have no further qualms or concerns regarding Libreboot or Minifree. Thank you all for your understanding! - -- 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 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJZ720dAAoJEK+E3vEXDOFbhgEIAI6qzR2et5C0zH937YL+sVcK g2PN1jydESDTLYa6hVKHR3uUvb6s+pic9rtdm4ZBpO/Y1P9CVp3ORY12BD2ueMcU Jt7XS+XuMLPDbdmYwFZSkT6/wxWxlQzVBpUbhfRZOHyhjA2VVIm+IeN02x2RiWWW GXaDHS05YSLQzQBnrc+9f8qqUektvenlV22b0GEJu07mnoAJc7O69xHdXoB6tAJ/ rhkT80qZePYEugiJVBGhErLN7GDtKIsb1+Lt01syT9t6GY5euXQFqp+PRvtp1Z1o l9+ZRk8JLYZeXcnsp60qM7E9J9vWOMCIyM6spvyaOBwDnIXb3seYRsIKk47t0pc= =pqPX -----END PGP SIGNATURE-----

1 0

Re: [coreboot] Problems changing payload on Intel Leaf Hill
by Nico Huber 24 Oct '17

24 Oct '17

Hi Tahnia, On 10.10.2017 10:29, Tahnia Lichtenstein wrote: > ... > > Then I built this version of coreboot with a self-compiled payload, such as > Tianocore UDK2017 CorebootPayloadPkg or SeaBIOS, using the .confg files > provided by Intel for UEFI payloads or legacy payloads respectively (just > modified for specific payload type and path, and disabling verified and > measured boot). I stitched the coreboot output with the Intel-provided > blobs using the exact same method as before. Then, in run-time, coreboot > transitions to the payload and nothing happens from then on (i.e. no > further serial debug messages, no change to display monitor). you've only attached config files for your coreboot but not for the payloads. It's hard to tell what output to expect without that (e.g. do you have serial output enabled in your SeaBIOS build? if you let the coreboot build environment configure SeaBIOS it is enabled expli- citly). So with the current information you've provided, it could just be that the payloads don't try to output anything on serial. Output on a monitor is a little more complicated and depends on each payload. SeaBIOS expects a Video BIOS to be present. This can either be an option ROM from a gfx adapter card (looking at your logs, you don't seem to have one), a Video BIOS file in CBFS matching the inte- grated gfx adapter, or, in case coreboot already configured a frame- buffer, a Video BIOS shim called SeaVGABIOS (aka. cbvga in this case, it's a separate component in the SeaBIOS source). Current CorebootPayloadPkg *should* be able to use a preconfigured framebuffer. I never tried it, though, and there are reports that it doesn't always work... It's generally possible that Intel's precom- piled UEFI payload has it's own gfx driver (GOP) built in. > ... > Am I not specifying the correct configuration options for Tianocore and > SeaBIOS? I.e. is there more to it than just selecting the payload type and > specifying the payload path? Do I need to configure or update memory > addresses or ranges to match payload sizes, or some such? Do I need to make > specific changes to the payloads' source code to support the platform? Any > advice on how/where to start debugging? Usually there is nothing more to specify. The best option, IMO, is to get one of the simpler payloads (SeaBIOS should do) to output on serial. You can also test your SeaBIOS binary in QEMU to make sure it does out- put something. Hope that helps, Nico

2 1

ASUS P2-99 with P2B config
by Branden Waldner 24 Oct '17

24 Oct '17

Hi all, I wasn't planning on posting unless I could actually contribute something, but since Keith Hui posted last month about his work on CBMEM for 440BX and ACPI, I figured I should do some proper testing and at least post if it worked out. I'm running coreboot on a ASUS P2-99 board with the config copied straight from P2B. It's not perfect, but it is stable and I haven't found anything that doesn't work that did with the original firmware. Testing I did over the past week: 1. Actually made a seperate P2-99 config, I'd been using vanilla P2B with no renaming for a few months on it. 2. Built it properly with coreboot crossgcc. Previously I couldn't build it on amd64 Debian Sid but worked fine with the Debian toolchain. Now it builds fine on amd64 sid and stretch, but fails patching gcc-6.3.0_nds32_ite.patch on i686 Debian stretch and jessiie. 3. Setup a serial console - seems to work fine. I was using I different board for flashing anyway, since flashrom doesn't know the board enable and the asus flasher only works on with original firmware to find the board enable - it can flash coreboot though if you use the right flag to tell it to flash the whole rom. 4. Tried Keith Hui's ACPI patches (https://review.coreboot.org/c/22067/). It has no problem booting or restarting, but linux complains about the acpi. Didn't really expect it to work properly on a different board anyway. As it stands now, all I've done is run it with a P2B config and not verified if everything is working as it should, I barely have beginner knowledge of C and nothing on low level x86 or acpi, so I can't actually do anything but testing. I can't upload board status for it since it's a P2-99 not P2B. I'm also still stuck with with using another board and hot swapping chips to flash roms. I should probably post on the flashrom list that the board I'm flashing with works as well as see if anyone knows anything about the asus board enable (it's getting pretty old). The main reason I'm posting is to say I can test patches the patches Keith Hui has been working on and post logs. I'd also be glad for any other recommendations on what I can do to help with this system.

1 0

[RFH] Still looking for a review of 440BX+Asus P2B family ACPI work
by Keith Hui 22 Oct '17

22 Oct '17

Hi all, Almost a month ago I submitted this patch that adds ACPI to my p2b-ls mainboard, They haven't been looked at since. https://mail.coreboot.org/pipermail/coreboot/2017-September/085189.html In the meantime the patch set has progressed to the point where the power button and soft-off works, and the P2B breakage was fixed (by applying the patch there as well.) They are now in these three patches. https://review.coreboot.org/c/21670/ https://review.coreboot.org/c/22066/ (a fix for the shared ACPI infrastructure) https://review.coreboot.org/c/22067/ (includes p2b-ls, p2b, i82371eb, have to be in one patch to pass build) I need a review for them so they can enter the tree, in particular an idea on how to separate 22067 into their parts without breaking build. Once this settles down I'll port this to p3b-f as well. It shares almost all the ACPI stuff with p2b-ls except IRQ routing.

1 0

Re: [coreboot] ast2400 / ast2500
by Alberto Bursi 21 Oct '17

21 Oct '17

On 10/21/2017 07:22 PM, Tirumalesh wrote: > Using complete open source firmware is just one of the important > advantages. > > In my understanding coreboot provides lot more than that for a small team. > > 1. No drivers in firmware(leaving some basic things like spi etc) > 2. A single image (firmware + Linux + rootfs) > 3. The above means it’s very convenient for updates (major source of > security bugs) > 4. Using same firmware on x86 and bmc means, what ever infra we > develop for board bring up and ops (as coreboot payload) works on both. > 5. Same thing for secure booting. > > > Most of the time the above things are also very important. > > Thanks, > Tirumalesh. Coreboot is hardware-specific, so the Coreboot that runs in the x86 system will be very different from the one running in the BMC. They will have the same interfaces to boot a payload of course. I'm not sure what kind of firmware you plan to deploy on both the x86 system and the BMC. The BMC has a very weak ARM processor and not much onboard flash for firmware. It is much better if you do 2 different payloads already. Besides, on ARM systems the board bringup part (what Coreboot was born for) is done by a bootROM (read-only memory inside the ARM SoC, you can't do anything to this). Then it loads a bootloader from the device's flash memory. This bootloader then does some more initalization, and then that loads a linux kernel written on raw flash or something like that and executes it. From there the Linux kernel takes over. For the AST2400 the bootloader is uboot, and the openbmc project has the source to compile this part too so you can have a fully open system https://github.com/openbmc/u-boot/commit/f03ebaa6c2aefc49c0fdd6bdca51c666ba… -Alberto

1 0

Re: [coreboot] ast2400 / ast2500
by Andrey Korolyov 21 Oct '17

21 Oct '17

> 4. Using same firmware on x86 and bmc means, what ever infra we develop for > board bring up and ops (as coreboot payload) works on both. > 5. Same thing for secure booting. > While I borrow not much expertise there, these points are applicable at this moment only if you are planning to run UEFI on both ARM and x86 devices at once, all other things are pretty less generic and not replaceable. UEFI is mentioned, but it could be u-boot or something else which works as cross-platform bootloader and could be inserted within a boot sequence stack on both IMC and host - on certain hardware you would manage to get identical software stack on different architectures for a small effort but for most times this is not true and significant work needs to be done. The second major point is a lack of host board signaling unification, you would not even have a guarantee that same BMC-side GPIO pins are responsible for same action types across boards of a single vendor (true for generations of Supermicro removable BMCs), so each board or board family would probably need additional work to create signaling descriptions. I`m not sure if coreboot is an appropriate replacement for OpenBMC efforts right there, as it was said before in this thread because real positive outcome is barely imaginable from this description.

1 0

Re: [coreboot] ast2400 / ast2500
by Tirumalesh 21 Oct '17

21 Oct '17

Using complete open source firmware is just one of the important advantages. In my understanding coreboot provides lot more than that for a small team. 1. No drivers in firmware(leaving some basic things like spi etc) 2. A single image (firmware + Linux + rootfs) 3. The above means it’s very convenient for updates (major source of security bugs) 4. Using same firmware on x86 and bmc means, what ever infra we develop for board bring up and ops (as coreboot payload) works on both. 5. Same thing for secure booting. Most of the time the above things are also very important. Thanks, Tirumalesh. On Sat, Oct 21, 2017 at 2:41 AM, Alberto Bursi <alberto.bursi(a)outlook.it> wrote: > What's the point? Coreboot is not supposed to be used as BMC firmware. If you want open BMC firmware you need to look for OpenBMC project, that supports Aspeed BMC chips and provides all features a BMC firmware should provide. https://github.com/openbmc/openbmc On 10/21/2017 04:00 AM, Tirumalesh wrote: > Thanks for the information. > > As I understand correctly, the main support is for x86 only. So if we > want to run coreboot as the only firmware, we have to do it our self. > > Thanks, > Tirumalesh > > On Fri, Oct 20, 2017 at 6:42 PM, Taiidan(a)gmx.com > wrote: >> On 10/20/2017 03:04 PM, Tirumalesh wrote: > Thanks for the reply, it >> is somewhat strange though. > > It means no server board runs fully >> with coreboot as firmware for both c86 and BMC. > > If this is not >> the case, what kind of bmc is used by all the supported boards, all >> of them are using different firmware for bmc and x86? As tim said the >> KGPE-D16 and KCMA-D8 have a fully open source libre init process on >> coreboot and support the libre OpenBMC for the AST BMC chip There >> aren't any other coreboot boards that support a BMC, and the only >> other device that has both fully open source firmware/init and an >> open source BMC off the shelf is the TALOS 2. Coreboot itself >> couldn't be ran on a BMC chip, well I suppose one could port it but >> there really wouldn't be a point to that as that isn't what it was >> designed for. PS welcome to the list :D > > -- coreboot mailing list: coreboot(a)coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot @gmx.com> @gmx.com>

1 0

Re: [coreboot] ast2400 / ast2500
by Alberto Bursi 21 Oct '17

21 Oct '17

What's the point? Coreboot is not supposed to be used as BMC firmware. If you want open BMC firmware you need to look for OpenBMC project, that supports Aspeed BMC chips and provides all features a BMC firmware should provide. https://github.com/openbmc/openbmc On 10/21/2017 04:00 AM, Tirumalesh wrote: > Thanks for the information. > > As I understand correctly, the main support is for x86 only. So if we > want to run coreboot as the only firmware, we have to do it our self. > > Thanks, > Tirumalesh > > On Fri, Oct 20, 2017 at 6:42 PM, Taiidan(a)gmx.com <Taiidan(a)gmx.com > <mailto:Taiidan@gmx.com>> wrote: >> On 10/20/2017 03:04 PM, Tirumalesh wrote: > Thanks for the reply, it >> is somewhat strange though. > > It means no server board runs fully >> with coreboot as firmware for both c86 and BMC. > > If this is not >> the case, what kind of bmc is used by all the supported boards, all >> of them are using different firmware for bmc and x86? As tim said the >> KGPE-D16 and KCMA-D8 have a fully open source libre init process on >> coreboot and support the libre OpenBMC for the AST BMC chip There >> aren't any other coreboot boards that support a BMC, and the only >> other device that has both fully open source firmware/init and an >> open source BMC off the shelf is the TALOS 2. Coreboot itself >> couldn't be ran on a BMC chip, well I suppose one could port it but >> there really wouldn't be a point to that as that isn't what it was >> designed for. PS welcome to the list :D > >

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