coreboot November 2016

coreboot@coreboot.org

66 participants
187 discussions

Re: [coreboot] Rettungsboot
by Zoran Stojsavljevic 28 Nov '16

28 Nov '16

> The measurements are with me. Linux, properly configured, is a very fast bootloader. UEFI has always been nothing but slow. And > that's still true; I've seen recent systems with "stripped down" UEFI and they are still appallingly slow, slower than linuxbios was in > 2000 on slow CPUs. I still can't see the point of UEFI (well, I can: Intel has been telling me for 16 years that UEFI is a way to > ensure they can distribute binary blobs for firmware and not reveal "core IP" to their BIOS ecosystem). Linux on ARM for auto > computers hit the 800ms boot time goal 10 years ago. I have seen UEFI systems that get booted in seconds, but not much closer > and getting them there is a huge amount of work. What's the point? I am not talking about small/tiny systems. If you consider consumers electronics, my proposal is out of any picture. I am talking about laptops, notebooks, DT, WS, and also about servers. Yes, with systems with SSDs (SSD is set to win this futile fight between HDDs and SSDs). And SSDs are bloody fast (they'll be much faster). What's the point? Here are my points: [1] Much easier and much more layered control. I can, while in boot-loader (CMOS BIOS), to inspect TRUE fs: /boot/efi FAT32 system and see what I have exactly there, apart from BIOS booting page; [2] Even if eODMs and/or vendors disable EFI BIOS shell, it is possible to break into it (I am able to do this for every system) and see exact state of affairs (others will be as well); [3] Very soon HDDs and SSDs with capacities of > 2TB will be out (price wise), and MBR (as far as I know it) does NOT support such kind of capacities. And MBR is related with classical boot, as my best understanding goes; [4] Since all the SoCs are now, and will in The Future support 64b architecture, my take on this is that boot-loaders should go this route, and be soon 64b as well (all UEFI BIOSes are already 64b, pleonasm). Again, for IOT as it is defined, my proposal is No Go. I agree with you for IOT case. I am advertising Coreboot (and U-Boot also) to compete with BIOSes and BIOS Vendors. We see/read (in this Coreboot @ thread) that over 90% of versatile people port Coreboot to Lenovo 410, 420, 520W, Nehalem laptops... INTEL and AMD based Laptops/Notebooks... ;-) My two cent opinion, Zoran On Sun, Nov 27, 2016 at 11:37 PM, ron minnich <rminnich(a)gmail.com> wrote: > > > On Sun, Nov 27, 2016 at 1:03 AM Zoran Stojsavljevic < > zoran.stojsavljevic(a)gmail.com> wrote: > >> >> I'll again repeat what I always believe in, and always advertise(d) here, >> and anywhere else: Coreboot is one excellent absolute minimum required for >> booting HW platform to the next step: OS boot loader, and I like Coreboot >> as it is. But having U-boot, or Tiano core as payloads, or minimal Linux, >> to get to again to boot to the real Linux... Nope (too much overhead)! Not >> my understanding of how things should work. >> > >> I very much like UEFI concept, to have a fs (file system) formatted in >> the boot-loader (and get rid of legacy MBR), but with the absolute minimal >> overhead - good to go. And this is why I tried to advertise micro part of >> Tiano Core - ONLY fs FAT32 with /boot/efi (/dev/sda2) part. Since SEC and >> PEI part (BIOS equivalence) is Coreboot itself, and then DXE whole shaman >> of probably 2M lines of code... Forget it - Mont Everest burden! >> > > Every time I put linux in flash and used it as a bootloader, it was faster > than Tiano or UEFI. Every. Single.Time. > > Plus, I could for the most part read the code. Tiano code makes my eyes > hurt. > > Linux as payload was always far faster than etherboot/gpxe/ipxe for any > reasonable use of a network, since the linux network stack has very good > performance. I could boot linux from flash and boot linux over a network in > seconds. And, as we got to really fast networks, like 10G infiniband, the > advantage for linux only grew. And, of course, linux can use multiple nics > concurrently; no pxe ever could. I'm not even sure the spec allows for it. > > Fun measurement: back in 2001, we showed at Los Alamos that linuxbios > (i.e. linux payload) could boot a 1000 (one thousand) node cluster faster > than ipxe could figure out which NIC to use for DHCP on one single node. > This includes some heavy lifting: configure the myrinet network (non > trivial), load a new kernel, kexec a new kernel, and ... configure the > myrinet network AGAIN. It was always funny to have booted 1000 nodes on > Linux, twice, before iPXE got around to finding the one configured NIC on > an equivalent node. > > The measurements are with me. Linux, properly configured, is a very fast > bootloader. UEFI has always been nothing but slow. And that's still true; > I've seen recent systems with "stripped down" UEFI and they are still > appallingly slow, slower than linuxbios was in 2000 on slow CPUs. I still > can't see the point of UEFI (well, I can: Intel has been telling me for 16 > years that UEFI is a way to ensure they can distribute binary blobs for > firmware and not reveal "core IP" to their BIOS ecosystem). Linux on ARM > for auto computers hit the 800ms boot time goal 10 years ago. I have seen > UEFI systems that get booted in seconds, but not much closer and getting > them there is a huge amount of work. What's the point? > > Also, your proposal above, while interesting, assumes a local disk. Many > systems don't use a local disk *for booting* (they may have a local cache > of data files -- just not a local root file system). So your idea would not > work for many systems out there. > > thanks for the note! I always enjoy reading what you have to say even when > I disagree :-) > > ron >

1 0

Re: [coreboot] Rettungsboot
by ron minnich 28 Nov '16

28 Nov '16

On Sun, Nov 27, 2016 at 5:58 PM Charlotte Plusplus < pluspluscharlotte(a)gmail.com> wrote: > I don't know about you, but once I have a minimal working kernel or a > coreboot fallback, I never really update them. So having no way to recover > them without hardware intervention is fine. The kernel I may recompile, > patch, etc would be somewhere else. > > The job of this minimal kernel and initrd would just be to kexec the other > kernel, and let you recover coreboot if needed. > It really, really happens in many environments that you find you need to update that kernel. It's true that you, personally, might not want to do that. But any realistic design needs to accommodate a kernel update, which further means any realistic design needs to accommodate two kernels. Because, sooner or later, you'll flash a broken kernel (I did this once on 1000 nodes) and you have got to have a way out. Not saying you *have to use that*, mind you; but a design has to be able to do that. ron

1 0

Re: [coreboot] Rettungsboot
by ron minnich 28 Nov '16

28 Nov '16

yeah, david and nico both make very good points. I like the idea of JSON file, and further we're working on a Go program on the u-root project that would parse said file (trivial in Go to parse JSON, it's one statement and blam! your Go struct is all filled in) and then decide what to configure/what to download/how to validate (we have a gpgv command written in Go by Eric Grosse) and then how to kexec it. I think what we're doing might be useful? ron On Sun, Nov 27, 2016 at 6:04 PM David Hendricks <david.hendricks(a)gmail.com> wrote: > On Sat, Nov 26, 2016 at 2:46 PM, ron minnich <rminnich(a)gmail.com> wrote: > > coreboot today is linuxbios minus the linux. The original intent was > always that linux be our lifeboat. The current set of (as you point out) > not terrific options is a result of linux growing too big for flash, and > flash growing too big for linux, ca. 2002, when we adopted the payload > model. The original keyword in the config file was 'linux', not 'payload'. > The bootloaders we adopted (etherboot, filo, ...) were never (to me) a very > satisfactory replacement for linux. They always came with lots of > limitations. > > But why linux? Why a full OS? Simple observation, here in my 35th year of > working with firmware and bootloaders. > > Every bootloader starts simple, and becomes an OS. Every single one starts > with the intent of being small and compact and only supporting some needed > subset of file systems/devices/protocols and ends up implementing > everything. Because there was an attempt to start out simple, no matter how > good the intial design is, that design is overwhelmed by the continuous > addition of features, the result being a badly bloated, huge system with no > apparent design. > > > Totally agree with everything Ron said. But as I read Nico's proposal, he > is asking how we might specify the thing that is loaded by the bootloader > whether the bootloader is a Linux kernel or FILO or Depthcharger or > whatever. > > So for the purposes of this, let's presume we have coreboot+linux in ROM. > What do you do once your kernel is loaded and you're able to read all the > storage devices or get on the network? Do you read each storage device in > whatever seemingly random order they were enumerated in and boot the first > thing that looks like a kernel? Do you download a kernel using TFTP? And so > on. > > One positive aspect of Nico's proposal would be to mitigate the bloat one > can reasonably expect to need to support. Say that we have a vendor who > wants to support a relatively generic coreboot distro and use Linux as the > payload. How many filesystems and networking protocols should they really > need to worry about in order to consider their distribution > "well-supported?" > >

1 0

Re: [coreboot] Rettungsboot
by David Hendricks 28 Nov '16

28 Nov '16

On Sat, Nov 26, 2016 at 2:46 PM, ron minnich <rminnich(a)gmail.com> wrote: > coreboot today is linuxbios minus the linux. The original intent was > always that linux be our lifeboat. The current set of (as you point out) > not terrific options is a result of linux growing too big for flash, and > flash growing too big for linux, ca. 2002, when we adopted the payload > model. The original keyword in the config file was 'linux', not 'payload'. > The bootloaders we adopted (etherboot, filo, ...) were never (to me) a very > satisfactory replacement for linux. They always came with lots of > limitations. > > But why linux? Why a full OS? Simple observation, here in my 35th year of > working with firmware and bootloaders. > > Every bootloader starts simple, and becomes an OS. Every single one starts > with the intent of being small and compact and only supporting some needed > subset of file systems/devices/protocols and ends up implementing > everything. Because there was an attempt to start out simple, no matter how > good the intial design is, that design is overwhelmed by the continuous > addition of features, the result being a badly bloated, huge system with no > apparent design. > Totally agree with everything Ron said. But as I read Nico's proposal, he is asking how we might specify the thing that is loaded by the bootloader whether the bootloader is a Linux kernel or FILO or Depthcharger or whatever. So for the purposes of this, let's presume we have coreboot+linux in ROM. What do you do once your kernel is loaded and you're able to read all the storage devices or get on the network? Do you read each storage device in whatever seemingly random order they were enumerated in and boot the first thing that looks like a kernel? Do you download a kernel using TFTP? And so on. One positive aspect of Nico's proposal would be to mitigate the bloat one can reasonably expect to need to support. Say that we have a vendor who wants to support a relatively generic coreboot distro and use Linux as the payload. How many filesystems and networking protocols should they really need to worry about in order to consider their distribution "well-supported?"

1 0

Re: [coreboot] Rettungsboot
by Trammell Hudson 28 Nov '16

28 Nov '16

On Sun, Nov 27, 2016 at 07:30:07PM -0500, Charlotte Plusplus wrote: > [...] > With the amount of flash we have, sharing the kernel and initrd doesn't > seem like a bad idea. The problem is if a bad kernel or initrd is flashed then there is no way to recover without hardware intervention. Having a truly minimal recovery kernel with USB and a spiflash writer makes it possible to boot into some sort of mode to reocver from that failure. For both root of trust as well as reliability concerns, the recovery image at the top of the SPI flash should be read-only with the BP bits and the WP# pin enabled. That way hardware is required to really mess it up. -- Trammell

2 1

How to access temperature sensors on 'modern' thinkpads?
by Charlotte Plusplus 28 Nov '16

28 Nov '16

Hello I am still interested in lowering the power consumption. To try to find the culprit, I am thinking about monitoring temperature sensors. On the W520 specs, I see on p 70 ("Thermal sensor"): S0: PCH/BASE COVER S1: NVIDIA S2: GBE S3: WWAN S4: DIMM(TOP) S5: DIMM(BOTTOM) S6: WLAN S7: EXPRESS SLOT On the W530 specs, I see on p 69 ("Thermal sensor"): S0: PCH/BASE COVER S1: NVIDIA S2: DIMM(TOP) S3: WLAN S4: N/A S5: DIMM(BOTTOM) S6: GBE & WWAN So basically, on the specs, I see at least 7 temperature sensors, connected straight to a smbus chip (EMC1438-2-AP-TR-GP on a w520) or straight to the new EC (MEC1619L-GP on a w530). But I can't read any of them: even when using the default bios on a W530, I can't get any data. Apparently the userland tools do not support new thinkpads: /proc/acpi/ibm/thermal shows nothing. lm-sensors doesn't help - I only get the CPU sensors Using ec_access, the offsets used on older thinkpads (as seen on http://www.thinkwiki.org/wiki/Thermal_Sensors) remain at 0, In case the temperatures are shown on other offsets, I tried to acquire values for 3600 seconds while doing periods of activity. Plotting all the offset only shows temperature-like readings on 0x78 (the 121st entry). Other candidates with non-zero activity are the 48, 133, 134, 171, 205, and 206 entries, but the plot doesn't look like temperature readings (CSV data available upon request) So where is the data from these 7 temperature sensors?? I was told the Thinker1 can be accessed by writing to the EC, and exposes more values, but I don't have any example on how to do that. In the W530 specs, I read "To be monitor S4/5/6 line, EC should enable the function with register" - but I can only read one sensor. I suppose this is what was meant by accessing the Thinker 1. Anyone has any example?? After some googling, I found a reference to an advanced temperature management mode on https://sourceforge.net/p/ibm-acpi/mailman/ibm-acpi-devel/?viewmonth=201104 : but nothing about how to use it. In the W520 specs, I read: H8 I2C Bus 2 ADDRESS : 4DH Resistor value | SMBUS Address GND | 1001 100, 4Ch 270 | 1001 101, 4Dh 560 | 1001 110, 4Eh 1K | 1001 111, 4Fh 1.5K | 1001 001, 49h 2.7K | 1001 010, 4Ah 5.6K | 1001 011, 4Bh >=18K | 0011 000, 18h Based on my best guess, I suppose on the w520, reading some special address on the smbus will get me that data from that temperature sensors, as selected by a resistor. But I get nothing with i2cdump -y 6 0x4C bp Is there some code showing how to read the temperature sensors on either a xx20 serie thinkpad or a xx30 serie thinkpad? Thanks Charlotte

1 0

Re: [coreboot] Rettungsboot
by Charlotte Plusplus 28 Nov '16

28 Nov '16

If I had more flash, I would like that too, just for kicks. With the amount of flash we have, sharing the kernel and initrd doesn't seem like a bad idea. If the cmdline for the normal mode can be modified easily by updating the cbfs with flashrom, I don't see any drawback to using kexec from the shared kernel Charlotte On Sun, Nov 27, 2016 at 7:26 PM, ron minnich <rminnich(a)gmail.com> wrote: > > > On Sun, Nov 27, 2016 at 4:22 PM Charlotte Plusplus < > pluspluscharlotte(a)gmail.com> wrote: > >> >> >> In my ideal scenario, coreboot would have the 2 images (normal, fallback) >> both starting the same payload (a minimal linux kernel) to save space. >> > > at Los Alamos we found we wanted a fallback kernel and initramfs too. > > But YMMV. > > But your overall picture is much like what we had at Los Alamos and it > works really well. >

1 0

Re: [coreboot] Rettungsboot
by ron minnich 28 Nov '16

28 Nov '16

On Sun, Nov 27, 2016 at 4:22 PM Charlotte Plusplus < pluspluscharlotte(a)gmail.com> wrote: > > > In my ideal scenario, coreboot would have the 2 images (normal, fallback) > both starting the same payload (a minimal linux kernel) to save space. > at Los Alamos we found we wanted a fallback kernel and initramfs too. But YMMV. But your overall picture is much like what we had at Los Alamos and it works really well.

1 0

Re: [coreboot] Rettungsboot
by Trammell Hudson 28 Nov '16

28 Nov '16

On Sat, Nov 26, 2016 at 10:46:33PM +0000, ron minnich wrote: > [...] > Every bootloader starts simple, and becomes an OS. Every single one starts > with the intent of being small and compact and only supporting some needed > subset of file systems/devices/protocols and ends up implementing > everything. And these bootloader filesystem/device/protocol implementations won't receive the same battle-testing that the drivers in Linux receive, since the bootloader versions are only used for such a short period of time during the system bring up. So in addition to greatly increasing the TCB, they also potentially introduce security vulnerabilities. I'm in agreedment with Ron that the boot part of coreboot should have as few drivers as possible (basically only a TPM and maybe a 0x3f8 serial port). This reduces the TCB and makes more space available for the payload. > [...] Today's flash parts are more than large enough to do > a good environment -- tinycore linux could be used, for example, once it > was trimmed a bit. It's only about 12M today with a full X environment. The 4MB flash in the older thinkpads is a little tight, but still sufficient for a text-based modern Linux kernel -- the biggest issue is the cryptsetup tool brings in quite a few dependencies right now, which complicates using it with a fully encrypted drive. With 8-16 MB you can have a write-protected, interactive shell version that can mount a USB drive and run spiflash tools to recover from failures, and a second, read-write version that can be reflashed by the system's owner with all the fancy features. -- Trammell

2 1

Re: [coreboot] Rettungsboot
by ron minnich 27 Nov '16

27 Nov '16

On Sun, Nov 27, 2016 at 1:03 AM Zoran Stojsavljevic < zoran.stojsavljevic(a)gmail.com> wrote: > > I'll again repeat what I always believe in, and always advertise(d) here, > and anywhere else: Coreboot is one excellent absolute minimum required for > booting HW platform to the next step: OS boot loader, and I like Coreboot > as it is. But having U-boot, or Tiano core as payloads, or minimal Linux, > to get to again to boot to the real Linux... Nope (too much overhead)! Not > my understanding of how things should work. > > I very much like UEFI concept, to have a fs (file system) formatted in the > boot-loader (and get rid of legacy MBR), but with the absolute minimal > overhead - good to go. And this is why I tried to advertise micro part of > Tiano Core - ONLY fs FAT32 with /boot/efi (/dev/sda2) part. Since SEC and > PEI part (BIOS equivalence) is Coreboot itself, and then DXE whole shaman > of probably 2M lines of code... Forget it - Mont Everest burden! > Every time I put linux in flash and used it as a bootloader, it was faster than Tiano or UEFI. Every. Single.Time. Plus, I could for the most part read the code. Tiano code makes my eyes hurt. Linux as payload was always far faster than etherboot/gpxe/ipxe for any reasonable use of a network, since the linux network stack has very good performance. I could boot linux from flash and boot linux over a network in seconds. And, as we got to really fast networks, like 10G infiniband, the advantage for linux only grew. And, of course, linux can use multiple nics concurrently; no pxe ever could. I'm not even sure the spec allows for it. Fun measurement: back in 2001, we showed at Los Alamos that linuxbios (i.e. linux payload) could boot a 1000 (one thousand) node cluster faster than ipxe could figure out which NIC to use for DHCP on one single node. This includes some heavy lifting: configure the myrinet network (non trivial), load a new kernel, kexec a new kernel, and ... configure the myrinet network AGAIN. It was always funny to have booted 1000 nodes on Linux, twice, before iPXE got around to finding the one configured NIC on an equivalent node. The measurements are with me. Linux, properly configured, is a very fast bootloader. UEFI has always been nothing but slow. And that's still true; I've seen recent systems with "stripped down" UEFI and they are still appallingly slow, slower than linuxbios was in 2000 on slow CPUs. I still can't see the point of UEFI (well, I can: Intel has been telling me for 16 years that UEFI is a way to ensure they can distribute binary blobs for firmware and not reveal "core IP" to their BIOS ecosystem). Linux on ARM for auto computers hit the 800ms boot time goal 10 years ago. I have seen UEFI systems that get booted in seconds, but not much closer and getting them there is a huge amount of work. What's the point? Also, your proposal above, while interesting, assumes a local disk. Many systems don't use a local disk *for booting* (they may have a local cache of data files -- just not a local root file system). So your idea would not work for many systems out there. thanks for the note! I always enjoy reading what you have to say even when I disagree :-) ron

1 0

← Newer
1
2
3
4
5
6
7
...
19
Older →

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 2016