coreboot December 2017

coreboot@coreboot.org

68 participants
177 discussions

Re: [coreboot] SeaBIOS boot order / can't boot from USB
by awokd＠elude.in 02 Dec '17

02 Dec '17

> If I have USB bootable media plugged in, SeaBIOS seems to immediately boot > from the hdd. I'm not able to boot from USB unless I physically unplug the > SATA connection. I've noticed on my system at least the USB device doesn't show up in the boot menu on a cold boot. If I hit ESC, then ctrl-alt-del, then ESC again on the warm boot I can select it. Also, try a USB 2.0 port instead of 3.0 if you have one.

1 0

SeaBIOS boot order / can't boot from USB
by Hal Martin 02 Dec '17

02 Dec '17

Hi all, I'd like to learn more about SeaBIOS boot order, but unfortunately I wasn't able to find the answer to my question on the wiki page: https://www.coreboot.org/SeaBIOS#Configuring_boot_order I would like to add a bootscript for SeaBIOS to search for USB boot devices before falling back to the hdd or PXE. If I have USB bootable media plugged in, SeaBIOS seems to immediately boot from the hdd. I'm not able to boot from USB unless I physically unplug the SATA connection. When I look at the console log in cbmem, I don't see SeaBIOS searching the USB controller at all. It's an Ivy Bridge platform. SeaBIOS log from cbmem: Searching bootorder for: /pci@i0cf8/*@1f,2/drive@0/disk@0 Searching bootorder for: /pci@i0cf8/pci-bridge@1c,3/*@0 Press ESC for boot menu. lspci: 00:00.0 Host bridge [0600]: Intel Corporation 3rd Gen Core processor DRAM Controller [8086:0154] (rev 09) 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port [8086:0151] (rev 09) (prog-if 00 [Normal decode]) 00:01.1 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port [8086:0155] (rev 09) (prog-if 00 [Normal decode]) 00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller]) 00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04) (prog-if 30 [XHCI]) 00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network Connection (Lewisville) [8086:1502] (rev 04) 00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04) (prog-if 20 [EHCI]) 00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C216 Chipset Family High Definition Audio Controller [8086:1e20] (rev 04) 00:1c.0 PCI bridge [0604]: Intel Corporation 7 Series/C216 Chipset Family PCI Express Root Port 1 [8086:1e10] (rev c4) (prog-if 00 [Normal decode]) 00:1c.4 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 5 [8086:1e18] (rev c4) (prog-if 00 [Normal decode]) 00:1d.0 USB controller [0c03]: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #1 [8086:1e26] (rev 04) (prog-if 20 [EHCI]) 00:1f.0 ISA bridge [0601]: Intel Corporation HM76 Express Chipset LPC Controller [8086:1e59] (rev 04) 00:1f.2 SATA controller [0106]: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] [8086:1e03] (rev 04) (prog-if 01 [AHCI 1.0]) 00:1f.3 SMBus [0c05]: Intel Corporation 7 Series/C216 Chipset Family SMBus Controller [8086:1e22] (rev 04) 00:1f.6 Signal processing controller [1180]: Intel Corporation 7 Series/C210 Series Chipset Family Thermal Management Controller [8086:1e24] (rev 04) Any suggestions? Thanks, Hal

1 0

Re: [coreboot] ASUS P2-99 with P2B config
by Branden Waldner 02 Dec '17

02 Dec '17

Alright, I've finally got a follow up with the raminit logs and bx configuration dumps. Hopefully you'll find something interesting or useful in there. As expected, I had to use serial capture for the raminit logs, since the default cbmem size isn't large enough. I didn't get any logs from it completely failing though, kept forgetting to have the serial capture running when rebooting from memtest with the ram unstable. Sometimes it reboots from memtest fine (by pressing escape), but others it hangs or boots with the ram even more unstable then the first time. This unstablility is still only initially triggered after rebooting from the gentoo uclibc hardened install. As for the pentium ii, it seems that coreboot does fail to init the L2 cache. I hadn't even looked at the cbmem previously to see what was going on. It's a 400MHz Deschutes SL3D5. I have no idea what was all involved in figuring out the values for the latency table (intel documented or not?) - assuming that's what the problem is. It's not likely I'm going to actually use this processor normally anyway. For the multiplier jumpers, I had thought that the processors where multiplier locked/auto, but didn't understand why the board had jumpers for it then. Figured it was either for early pii's or special unlocked processors. They don't do anything, I must have just been having issues with the processor, ram, agp/pci cards, or bios chip not being seated right. I've had it fail to do anything a few times after messing with stuff. As for the bus frequency, I did end up playing around for a bit with that a bit. For being a lower end nb, the 440zx didn't seem to have any problems. I ran a piii 866MHz no problem, ram was stable even with 140 bus speed. Neither of the pair of agp video cards liked the agp bus being overclocked though. Probably not a good idea to be overclocking an almost 20 year old system, especially with it being the only p2b/p2-99 still being tested with coreboot and being the only board with coreboot running on it that I have. As for the floppy and devicetree.cb, it seems to be enabled. I'll have to try it again and see if anything shows up in the cbmem or for seabios. Maybe check the bios vs coreboot /proc/ioports a bit closer yet too. The seabios ps/2 keyboard init still seems to fail sometimes as well. It usually works fine after a reset though. I think when I tried to set a ps/2 init timeout for seabios I was using the master version and it didn't seem to do anything. I'll have to try it again with the serial console output and possibly some level of debug output from seabios, maybe even just use coreboot's ps/2 keyboard init. Thanks for the work you've done with these older systems, without support for them, I probably wouldn't have been willing to try coreboot. Most of the newer systems I have it wouldn't be practical to have them sitting on the workbench trying get coreboot to work on them, they're already in use.

1 0

SeaBIOS boot order / can't boot from USB
by Hal Martin 01 Dec '17

01 Dec '17

1 0

Re: [coreboot] Lenovo G505s AMD Hardware Virtualization
by awokd 01 Dec '17

01 Dec '17

On Fri, December 1, 2017 15:33, Ivan Ivanov wrote: > I have thought that if Qubes sees HVM available it is always using it. > (so if Qubes reports to you that HVM is enabled, that means its using > HVM and without any problems). Am I wrong here? That's true of 4.0 but not 3.2. Look for virt_mode under "qvm-prefs vmname" in 4.0 or type under "sudo xl list -l vmname" in 3.2. You'll see hvm and pv respectively by default (but we should probably take this off list). >> Last resort is to flash back the OEM image but I'm hoping to avoid that. > It is rare that a default proprietary UEFI/BIOS has a good virtualization > support, especially for AMD-based consumer level hardware. > E.g. I am almost sure that no IOMMU supported by that InsydeH2O, > but still it would be curious to hear your results... At first glance, IOMMU doesn't appear to be enabled after flashing back the OEM image but I'm going to play with Xen iommu options. There are some workarounds for AMD IOMMU quirks. It did answer my question on CPU microcode though, in dmesg I'm seeing patch_level=0x06001119 now vs. 0x00000000 before. My test HVM started right up on Qubes 4.0 too which makes me wonder if it would have worked on Coreboot with a disabled IOMMU. Anyways, I won't bore you all with a play by play but I might have to ask for help locating the microcode in the image. There's no modules called "CPU MICROCODE HERE!" showing in UEFI_Tool, unfortunately. I'll keep digging. > Next time you disassemble, you could carefully cut a small window > (e.g. using a heated knife or soldering iron) inside the bottom's half of > a > laptop. Please check out the attached image to see how to do it safely. > After you cut this window - you could attach SOIC8 clip to a flash chip > without completely disassembling your laptop. But, because of the > same reason, someone may use your "quick access window" to quickly > flash a "coreboot with added backdoors" image - since now he doesn't > need to completely disassemble your laptop, can do it very quickly. > So you will have to never leave your laptop unattended after this mod, > or at least invent some additional security measures (vboot?) ... Thanks, hopefully I won't need to go back to the OEM image much more often! Once it's corebooted again the internal flasher works fine.

1 0

Re: [coreboot] Is Goryachy's JTAG hack a chance for free firmware ?
by Enrico Weigelt, metux IT consult 01 Dec '17

01 Dec '17

On 30.11.2017 07:40, Zoran Stojsavljevic wrote: > You can fully use UEFI BIOS without any signatures. With so-called slim > TXE engine. Can we completely replace UEFI w/o any signatures ? And what about ME ? I've read that the cpu itself verifies the signature of ME firmware, so we cant completely replace it. If it would be possible to read out the privkey or burn in another one, that blockade would be fallen. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info(a)metux.net -- +49-151-27565287

4 4

Re: [coreboot] Embedded Controller (EC)
by Randall Spangler 01 Dec '17

01 Dec '17

On Fri, Dec 1, 2017 at 6:32 AM, Vadim Bendebury <vbendeb(a)chromium.org> wrote: > [+cc a couple of guys who might have some advice in this respect] > > On Fri, Dec 1, 2017 at 5:07 AM, Аладышев Константин <aladyshev(a)nicevt.ru> > wrote: > >> Hello! I'm trying to understand, what is the easiest way today to >> integrate >> EC to custom motherboard? What controller should I choose for new custom >> motherboard? >> >> 1) First of all, are there any ECs on market that ship with embedded >> firmware, where all you need to do is just a little bit of register >> configuration (like SuperIO)? Or is it always like you need to write all >> firmware by yourself? > > Most EC vendors that sell dedicated ECs also sell their SDK and source code, but it's not cheap. So usually roll your own, hopefully based on an open design. > In that case what is the main difference between >> ordinary microcontroller (for example STM32) and some controller marked by >> vendor as EC? >> > Interfaces. EC will have: - Keyboard scanner - eSPI / LPC for connecting to x86 SoC - More I2C ports (and in the old days, PECI and PS/2 ports). > >> 2) How stable and flexible are projects about open EC firmware? Is it >> possible to adapt these projects for my custom motherboard? >> >> I'm talking about: >> - Chromium Embedded Controller: >> http://www.chromium.org/chromium-os/ec-development > > This is used on all current Chromebooks, so it's full-featured and stable. We do tend to branch old boards, so if your motherboard has an old chipset on it you may need to look back in time to find support for it. > >> - Origami-EC: https://git.code.paulk.fr/gitw >> eb/?p=origami-ec.git;a=summary >> >> 3) What is the current status of EC support from coreboot point of view? >> https://review.coreboot.org/cgit/coreboot.git/tree/src/ec >> >> Best regards, >> Aladyshev Konstantin >> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot >> > >

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