coreboot November 2016

coreboot@coreboot.org

66 participants
187 discussions

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

27 Nov '16

Rettungs (German) - Ubersetzung/translate ist/is rescue. As much as I know... Desperately trying to learn more Deutsche Sprache these days (bloody tough - too old for it). 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! UEFI BIOSes (64b - pleonasm) these days rule (Client and Server INTEL CORE/ATOM platforms)... And Coreboot should (my subjective opinion - pleonasm) add slim payload from described above: making just /boot/efi file system... with CSM OFF, true UEFI environment. Have no idea if GRUB2 as payload already does this (UEFI lookalike /boot/efi)? This is the question I am asking Coreboot Community (if this is the case, even better)! :-) For Consumer Electronics, I completely agree with Ron and others in this thread. Thank you, Zoran On Sun, Nov 27, 2016 at 1:23 AM, ron minnich <rminnich(a)gmail.com> wrote: > And let's not forget John Lewis' excellent work on JELTKA for chromebooks, > which is also Linux and kexec. I've used it and it's great. > > I have a replacement for petitboot which is an all-Go userland: u-root. > Programs in the root file system are Go source and are compiled on first > use -- there's a full Go toolchain embedded in flash. There are only 5 > userland binaries on the root file system, four of which are Go toolchain, > one is /init, and the rest is all Go source. I've got this working today on > a KGPE-D16. I first tested it in Prague in 2014, and we've also had it > working on the Gizmo II and a Chromebox. If you have 16 MiB flash, it just > works -- really. > > So there's five efforts, working today, all based on linux and kexec, and > at least one in commercial use. > > I think the lifeboat should come with a penguin painted on its side. It's > known to work -- since 1999 :-) -- and it avoids recreating the full > universe of drivers, protocols, file systems, and so on. > > ron > > On Sat, Nov 26, 2016 at 4:20 PM Zaolin <zaolin(a)das-labor.org> wrote: > >> In my opinion there are currently two payloads which are really >> interesting and promising for end users: >> >> * HEADS - https://github.com/osresearch/heads >> >> * Petitboot - https://secure.raptorengineering.com/content/kb/1.html >> >> I am currently working on the UI of Heads. So feel free to contribute ;) >> >> >> Best Regards >> >> Zaolin >> >> On 11/26/2016 11:47 PM, ron minnich wrote: >> >> Oh, my fingers type too much for me now. >> >> 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 SMALL for linux, ca. >> 2002, when we adopted the payload model. >> >> On Sat, Nov 26, 2016 at 3: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. >> >> The exception, it has been argued, is EFI, which had some sort of design >> in 1999. From my point of view, it skipped right past all the initial >> stages and entered the world bloated and with no apparent design, or at >> least not a very good one. >> >> So you need to think, not in terms of lean and clean, but in terms of >> what it looks like after a few years when everyone has attached their >> favorite features to your lifeboat. I think it's a mistake to ever think >> you are going to implement some limited-function, limited-footprint >> bootloader, because people will jump on it and just add code. Just look at >> what's happened with systemd. >> >> Also worth considering is that the tinykernel configs have got linux down >> to 400K. You can trim it down to that, and carefully add features back. >> This comes with huge benefits I think. You get drivers that work, protocols >> that work, all the file systems you want, and you can put nice interactive >> boot UIs in user mode. 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. >> >> Power8 and Power9 systems use linux in flash as their bootloader. This >> example has not been lost on other systems being developed today. >> >> I think it's worth considering a tinykernel linux as bootloader before >> you start with a new thing. >> >> ron >> >> > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Nehalem not booting with two ram sticks
by Federico Amedeo Izzo 27 Nov '16

27 Nov '16

On 11/23/2016 10:14 AM, Zoran Stojsavljevic wrote: > > Federico, I have here also suggestion for you. You should try to run > only one DDR memory stick, and then record the memory values (since I > see from your logs that they are identical for both memories/DDRs), > and then to try to hard-code them for both sticks, altogether avoiding > raminit.c setup, and see if this improves your situation?! Hi Zoran and others, I finally flashed again coreboot after trying the Lenovo BIOS. I used the decode-dimms util to dump RAM info while on the Lenovo BIOS with both RAM sticks, and run the same program on the coreboot BIOS with just one stick. Sadly the output on coreboot is the same of the output on Lenovo BIOS so no info gained by this. I will attach the output from the Lenovo BIOS in case it turns out useful. The next step I will try will be to modify raminit.c of Nehalem to accept hardcoded frequency as SandyBridge does, hoping that this will be a temporary fix to get the two DIMMs working.

2 1

Re: [coreboot] Rettungsboot
by Zaolin 27 Nov '16

27 Nov '16

In my opinion there are currently two payloads which are really interesting and promising for end users: * HEADS - https://github.com/osresearch/heads * Petitboot - https://secure.raptorengineering.com/content/kb/1.html I am currently working on the UI of Heads. So feel free to contribute ;) Best Regards Zaolin On 11/26/2016 11:47 PM, ron minnich wrote: > Oh, my fingers type too much for me now. > > 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 SMALL for > linux, ca. 2002, when we adopted the payload model. > > On Sat, Nov 26, 2016 at 3:46 PM ron minnich <rminnich(a)gmail.com > <mailto:rminnich@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. > > The exception, it has been argued, is EFI, which had some sort of > design in 1999. From my point of view, it skipped right past all > the initial stages and entered the world bloated and with no > apparent design, or at least not a very good one. > > So you need to think, not in terms of lean and clean, but in terms > of what it looks like after a few years when everyone has attached > their favorite features to your lifeboat. I think it's a mistake > to ever think you are going to implement some limited-function, > limited-footprint bootloader, because people will jump on it and > just add code. Just look at what's happened with systemd. > > Also worth considering is that the tinykernel configs have got > linux down to 400K. You can trim it down to that, and carefully > add features back. This comes with huge benefits I think. You get > drivers that work, protocols that work, all the file systems you > want, and you can put nice interactive boot UIs in user mode. > 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. > > Power8 and Power9 systems use linux in flash as their bootloader. > This example has not been lost on other systems being developed today. > > I think it's worth considering a tinykernel linux as bootloader > before you start with a new thing. > > ron > > >

2 1

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

26 Nov '16

Oh, my fingers type too much for me now. 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 SMALL for linux, ca. 2002, when we adopted the payload model. On Sat, Nov 26, 2016 at 3: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. > > The exception, it has been argued, is EFI, which had some sort of design > in 1999. From my point of view, it skipped right past all the initial > stages and entered the world bloated and with no apparent design, or at > least not a very good one. > > So you need to think, not in terms of lean and clean, but in terms of what > it looks like after a few years when everyone has attached their favorite > features to your lifeboat. I think it's a mistake to ever think you are > going to implement some limited-function, limited-footprint bootloader, > because people will jump on it and just add code. Just look at what's > happened with systemd. > > Also worth considering is that the tinykernel configs have got linux down > to 400K. You can trim it down to that, and carefully add features back. > This comes with huge benefits I think. You get drivers that work, protocols > that work, all the file systems you want, and you can put nice interactive > boot UIs in user mode. 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. > > Power8 and Power9 systems use linux in flash as their bootloader. This > example has not been lost on other systems being developed today. > > I think it's worth considering a tinykernel linux as bootloader before you > start with a new thing. > > ron >

1 0

Rettungsboot
by Nico Huber 26 Nov '16

26 Nov '16

Hey coreboot folks, here's something that's bugging me for a long time: Our lack of an out- of-the-box booting experience. All our payloads that don't implement legacy boot facilities (i.e. BIOS, UEFI), only work in the usual case, to boot an installed OS that's con- figured to work with that payload. But they stink at booting in the un- usual case, e.g. from installation, rescue or live boot media. One could now point a finger at the developers of those media and say, they only have an MBR / UEFI boot partition, no GRUB / FILO / whatever configuration file. So it's their fault? Well, I say, it's our fault! We never specified how a civilized, general booting process shall look like. My proposal: Let's specify a fallback boot mechanism for bootloaders for the case they feel lost. This would include o a configuration file format (to specify a binary to load along with its parameters), o a search scheme for the configuration file (e.g. search the first partition of each disk for `/boot/rettungsboot`), o a set of supported partition table formats, o a set of supported file systems, o a set of binary formats that one can expect the payload to support (e.g. multiboot2, multiboot, bzImage). The configuration file format should be most lean and simple. We might want support for multiple options (i.e. a simple menu) though. Some- thing like the legacy GRUB format maybe? What do you think? Best regards, Nico PS. Yes, it's too late to change the name (see subject). For the curi- ous, who didn't look it up yet: "Rettungsboot" is the German phrase for "life boat".

3 3

PCI passthrough on ASUS KGPE-D16
by opteron＠keemail.me 26 Nov '16

26 Nov '16

Hi, would it be possible to passthrough a graphics card to a virtual machine while using Coreboot/Libreboot? The libreboot website says that the motherboard offers full IOMMU-support when using a CPU from the Opteron 6200/6300 series. https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF https://libreboot.org/docs/hcl/kgpe-d16.html

3 3

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 25 Nov '16

25 Nov '16

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 1 new defect(s) introduced to coreboot found with Coverity Scan. 9 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1366397: Control flow issues (DEADCODE) /src/drivers/spi/spi_flash.c: 326 in __spi_flash_probe() ________________________________________________________________________________________________________ *** CID 1366397: Control flow issues (DEADCODE) /src/drivers/spi/spi_flash.c: 326 in __spi_flash_probe() 320 for (i = 0; i < sizeof(idcode); i++) 321 printk(BIOS_SPEW, "%02x ", idcode[i]); 322 printk(BIOS_SPEW, "\n"); 323 } 324 325 /* count the number of continuation bytes */ >>> CID 1366397: Control flow issues (DEADCODE) >>> Execution cannot reach the expression "*idp == 127" inside this statement: "for ((shift = 0) , (idp = i...". 326 for (shift = 0, idp = idcode; shift < IDCODE_CONT_LEN && *idp == 0x7f; 327 ++shift, ++idp) 328 continue; 329 330 printk(BIOS_INFO, "Manufacturer: %02x\n", *idp); 331 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "coreboot(a)coreboot.org", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Re: [coreboot] native video init question
by Nico Huber 24 Nov '16

24 Nov '16

Hi, On 20.11.2016 21:29, ron minnich wrote: > I also wonder if you could use the code Nico put in for the graphics init. > I have no idea if it's possible, Nico could tell us. But that code looks > really thorough and might work better. I suppose, it (libgfxinit) would just work (if you get it to compile). It's well tested on Ivy Bridge with the MRC blob (kontron/ktqm77, roda/ rv11, roda/rw11) and Sandy Bridge with native raminit (lenovo/t420). To compile it, you need an Ada toolchain (this is where most people run off). And to get it running you need several patches in coreboot that are still under review. Tip of the minimum for kontron/ktqm77 is [1]. If anyone wants to try, the most reliable way to get the Ada toolchain is to install a `gnat` or `gcc-ada` package matching gcc from your dis- tribution. Then rebuild the coreboot toolchain with `-l c,ada -b`, e.g. mv util/crossgcc/xgcc{,.bak} && make BUILDGCC_OPTIONS="-l c,ada -b" CPUS=8 crossgcc-i386 and wait for an unexpected long period (the `-b` makes it slow, but it's more likely to succeed). Nico [1] https://review.coreboot.org/#/c/17074/

2 1

Re: [coreboot] Nehalem not booting with two ram sticks
by Zoran Stojsavljevic 23 Nov '16

23 Nov '16

Hello Charlotte++, On Wed, Nov 23, 2016 at 2:40 AM, Charlotte Plusplus < pluspluscharlotte(a)gmail.com> wrote: > Edit devicetree.cb and set: register "max_mem_clock_mhz" = "666" > Good to know! Thank you for the tip, so Federico can try quick check and see if this does work as workaround for now. :-) Federico, I have here also suggestion for you. You should try to run only one DDR memory stick, and then record the memory values (since I see from your logs that they are identical for both memories/DDRs), and then to try to hard-code them for both sticks, altogether avoiding raminit.c setup, and see if this improves your situation?! > I suppose there is one. I don't know. I want to investigate. I will > certainly try again by adding the patches suggested by Kyosti. As soon as I > can get the MRC blob to work, I can make some better guesses about what is > going wrong (I tried so many various things already) by having some > reference points. > Please, keep us in the loop. I really enjoy reading your posts. They are very technical, and very instructive. They force me to think, and recall various things I did once upon a time (referring to Y2012/Y2013). At the moment, I want to make a first public commit for the W520, but with > the RAM issues (only stable with the MCU at 666), and no native video init, > and the power consumption issues, I'm not sure how helpful it will be. > YES, of course, it will be/is VERY/extremely helpful. You did excellent job, paving path to other platform yet, and leaving to the community to fix these bugs. Yeah, the blob. I don't like blob, but I like to have the option of > something that works if I need to investigate why something else is not > working. Or just for an initial release. > You are talking about SNB/IVB MRC blob, I have noticed. About this blob (beneath), correct? _______ *This change was committed on Apr. 5th, 2012 into the main coreboot git repository. In fact, if you going to look into directory:* *…/src/northbridge/intel/sandybridge/raminit.c you'll see the following:* *http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/northbridge/intel/sandybridge/raminit.c;h=696417f1615621bc9118c92b4717ce4afdcb4e5a;hb=HEAD <http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/northbridge/i…> * *Please, find the line 213: void sdram_initialize(struct pei_data *pei_data)* *And then, the line 245: entry = (unsigned long)cbfs_find_file("mrc.bin", 0xab);* _______ Yup, this was the MRC blob and the commit you are referring to, back then in April 5th, 2012. This was the MRC SNB BIOS blob developed (my best guess) by some BIOS CCG group for Coreboot/Google. And I also guess, this one was reverse engineered by two of Google people (Vladimir Serbinenko somehow comes to my mind). ;-) Kyosti, my best guess is that you can find this patch/original SNB MRC blob API code, and blob itself, can you (since Charlotte++ would like to experiment with it)? Thank you all for refreshing my old, patchy, full of black holes brain, giving me the hope that I can (much) better organize huge DATA info scattered all over my mind! :-) Zoran

1 0

Re: [coreboot] Nehalem not booting with two ram sticks
by Federico Amedeo Izzo 23 Nov '16

23 Nov '16

Thank you all for your support, My x201 is a Nehalem architecture, not IVB (Ivy Bidge I suppose) On 11/23/2016 02:40 AM, Charlotte Plusplus wrote: > > On Tue, Nov 22, 2016 at 4:28 PM, Zoran Stojsavljevic > <zoran.stojsavljevic(a)gmail.com <mailto:zoran.stojsavljevic@gmail.com>> > wrote: > > If MCU is later, could you, please, explain how you did this in > IVB Coreboot code (since this might be beneficial to Federico's > attempts)? > > > Edit devicetree.cb and set: > > register "max_mem_clock_mhz" = "666" I've looked inside `src/mainboard/lenovo/x201/devicetree.cb` but the option "max_mem_clock_mhz" is missing, while it is present in other sandy bridge mainboards. So I think the actual `raminit.c` of nehalem does not allow choosing a fixed frequency for RAM. > Here I understood that you tried to compare IVB raminit.c source > code with MRC algorithm, embedded in BIOS itself. And I have here > one ignorant question: what is the difference between IVB (I > assumed in this case SNB (tock), since I could not find IVB (tick) > in rc/northbridge/intel/) raminit.c source code and MRC from IVB > BIOS (there MUST be some difference, it is obvious, doesn't it)? > > > I suppose there is one. I don't know. I want to investigate. I will > certainly try again by adding the patches suggested by Kyosti. As soon > as I can get the MRC blob to work, I can make some better guesses > about what is going wrong (I tried so many various things already) by > having some reference points. About trying with MRC blob RAM init, sadly the source file `raminit_mrc.c` present for SNB is absent from `src/northbridge/intel/nehalem` So I think MRC blob init has not been coded/is not supported in nehalem :( This is confirmed by this wiki page: https://www.coreboot.org/Intel_Native_Raminit So the options of fixing frequency or using MRC are not feasible on nehalem at the moment. I will try to check the RAM settings running the Lenovo bios and see if i can add the code for "max_mem_clock_mhz" Unfortunately I won't be able to flash coreboot until friday because my laptop needs an external power supply for the flash chip and I will borrow it on friday. Thanks again, Federico

1 0

← Newer
1
2
3
4
5
6
7
8
...
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