coreboot February 2017

coreboot@coreboot.org

66 participants
212 discussions

Understand vboot logic to select FW_B
by tturne＠codeaurora.org 15 Feb '17

15 Feb '17

Folks, I'm working on coreboot on ARMv8 architecture and recently attempted to verify FW_B can be selected if FW_A is corrupted. In reviewing the code-path through coreboot vboot wrapper and vboot_reference library I'm not understanding the logic. The logic appears to be that vboot_reference library determines FW_A is corrupt and forces a reboot. After reboot, early in verstage_main(), both the NVRAM (flash) and vb2_context structures are initialized, wiping out any history of failure condition. I know I must be missing something in my analysis but don't see it. Can anybody on this list share their experiences in confirming the FW_B boot path if FW_A is corrupt? Cheers, T.mike

2 1

Re: [coreboot] Add coreboot storage driver
by Nico Huber 14 Feb '17

14 Feb '17

On 14.02.2017 18:56, ron minnich wrote: > At what point is ramstage a kernel? I think at the point we add file > systems or preemptive scheduling. We're getting dangerously close. If we > really start to cross that boundary, it's time to rethink the ramstage in > my view. It's not a good foundation for a kernel. Agreed. I wouldn't call it a kernel, but it really seems to grow very ugly. Every time I think about this, I scarcely find anything that needs to be done in ramstage. I believe even most payloads could live without it with some more initialization done in romstage. Some things that I recall, what ramstage does: o MP init => maybe can be done earlier, does it need RAM generally??? o PCI resource allocation => can be done offline Just add the resources to the devicetree. If you want to boot from a plugged card, that isn't in the devicetree, the payload would have to handle it though. o Those small PCI device "drivers" => I doubt they need RAM o Table generation => Not that dynamic after all I suppose much is done with static (compile time) information. o Sometimes gfx modesetting => do it in the payload Nico

3 2

Re: [coreboot] Add coreboot storage driver
by Aaron Durbin 14 Feb '17

14 Feb '17

On Tue, Feb 14, 2017 at 1:07 PM, Patrick Georgi <pgeorgi(a)google.com> wrote: > 2017-02-14 17:12 GMT+01:00 Aaron Durbin via coreboot <coreboot(a)coreboot.org>: >> For an optimized bootflow >> all pieces of work that need to be done pretty much need to be closely >> coupled. One needs to globally optimize the full sequence. > Like initializing slow hardware even before RAM init (as long as it's > just an initial command)? > How about using PIT/IRQ0 plus some tiny register-only interrupt > routine to do trivial register wrangling (we do have register > scripts)? I don't think I properly understand your suggestion. For this particular eMMC case are you suggesting taking the PIT interrupt and doing the next piece of work in it? > >> that we seem to be absolutely needing to >> maintain boot speeds. Is Chrome OS going against tide of coreboot >> wanting to solve those sorts of issues? > The problem is that two basic qualities collide here: speed and > simplicity. The effect is that people ask to stop a second to > reconsider the options. > MPinit and parallelism are the "go to" solution for all performance > related issues of the last 10 years, but they're not without cost. > Questioning this approach doesn't mean that that we shouldn't go there > at all, just that the obvious answers might not lead to simple > solutions. > > As Andrey stated elsewhere, we're far from CPU bound. Agreed. But our chunking of work is very coarsely sectioned up. I think the other CPU path is an attempt to work around the coarseness of the work steps in the dependency chain. > > For his concrete example: does eMMC init fail if you ping it more > often than every 10ms? It better not, you already stated that it's > hard to guarantee those 10ms, so there needs to be some spare room. We > could look at the largest chunk of init process that could be > restructured to implement cooperative multithreading on a single core > for as many tasks as possible, to cut down on all those udelays (or > even mdelays). Maybe we could even build a compiler plugin to ensure > at compile time that the resulting code is proper (loops either have > low bounds or are yielding, yield()/sched()/... aren't called within > critical sections)... That's a possibility, but you have to solve the case for each combination of hardware present and/or per platform. Building up the dependency chain is the most important piece. And from there to ensure execution context is not lost for longer than a set amount of time. We're miles away from that since we're run to completion serially right now. > > Once we leave that scheduling to physics (ie enabling multicore > operation), all bets are off (or we have to synchronize the execution > to a degree that we could just as well do it manually). A lot of > complexity just to have 8 times the CPU power for the same amount of > IO bound tasks. > > > Patrick

1 0

There are G34 Opteron 6287SE's on ebay (best g34 cpu and very rare)
by Taiidan＠gmx.com 14 Feb '17

14 Feb '17

I thought people might want to know: There's three opteron 6287SE's on ebay for $300 each and the seller also has best offer, they are a foreign seller but the ebay money back guarantee applies. It is the fastest g34 cpu made and apparently it was only ever sold to a small amount of OEM's so it is very rare. Btw I heard most enterprise hardware usually goes for half of list if you want to try to get it for $150 or w/e.

2 1

Re: [coreboot] Add coreboot storage driver
by Timothy Pearson 14 Feb '17

14 Feb '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/14/2017 01:36 PM, Zoran Stojsavljevic wrote: >> Where do we go from here? > > As I said (and I'll repeat, many times, if required - I do NOT care what > all INTEL [all their 13000+ managers] think): > > /I have another idea for INTEL SoCs/CPUs, as HW architecture > improvement. Why your top-notch HW guys do NOT implement MRC as part of > MCU. Some HW thread inside CPU/SoC should execute MCU, shouldn't it? > MRCs should be few K in size, and they can perfectly fit in there, thus > MRC should be (my take on this) part of internal CPU architecture./ I highly doubt this would ever happen, unless it's yet another signed blob with highly privileged access. The main problem is that memory initialisation is very complex, and there is a definite need to be able to issue updates when / if a CPU / MB / DIMM combination fails to function correctly. Personally, having worked on RAM initialisation for many different systems (embedded to server), I find it ludicrous that this can be considered top secret IP worthy of a closed blob. It takes time to get right, but the end result is inextricably tied to the hardware in question and is really not much more than a hardware-specific implementation of the bog-standard and widely known DDR init algorithms. Intel, why the blob? What's hiding in there? Asian companies I know tend to keep things closed to avoid patent lawsuits over stolen IP, but I highly doubt you have this problem? Just my *personal* $0.02 here. :-) - -- 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/ iQEcBAEBAgAGBQJYo15LAAoJEK+E3vEXDOFbCCMH/RazQCmj3rW8a+4hWG0Wt2zR eGrSnsoEgfnZOCiPO6lLQX3w799kr3lZUu02HtS0CvsHbIpzUPQ7cdNzcd6kgtMN /AzYNonmU6PM2dPjAMyrtk7oVInN7VsakfE3RaAvkqh9SdBH7z35AWbsgjXk1iQA +6n7EXFy1cfJKqk2OdNVcWCCf4b8tEZ5n9WcWufhLie0z/r7Fll4Jsk2UF39G+P4 lsSp757bO2Y2juoEPmPT+lm6akSrV8h37FirnmIFvzbPhpGfJ2IrwJkjRpgK4Ypn 9hrvDMctmvq6X+FtW6y7Eer94i1jzXvWSjXJlOSnHPGJKAh946EhztmRijceMf4= =4Oil -----END PGP SIGNATURE-----

2 1

Re: [coreboot] Add coreboot storage driver
by Zoran Stojsavljevic 14 Feb '17

14 Feb '17

> Where do we go from here? As I said (and I'll repeat, many times, if required - I do NOT care what all INTEL [all their 13000+ managers] think): *I have another idea for INTEL SoCs/CPUs, as HW architecture improvement. Why your top-notch HW guys do NOT implement MRC as part of MCU. Some HW thread inside CPU/SoC should execute MCU, shouldn't it? MRCs should be few K in size, and they can perfectly fit in there, thus MRC should be (my take on this) part of internal CPU architecture.* *Today's INTEL COREs and ATOMs have at least/minimum 100M gates, why not to add couple of dozen K more? Lot of problems solved, don't they? ;-)* *[1] BOOT stage to be much shorter (no anything such as CAR phase);* *[2] ROM stage does not exist;* *[3] IP preserved in HW, so the whole INTEL FSP is actually (imagine the Beauty) Open Source...* With INTEL. Here we go! Where no one has gone before! ;-) Zoran On Tue, Feb 14, 2017 at 6:56 PM, ron minnich <rminnich(a)gmail.com> wrote: > Just a reminder about times past. This discussion has been ongoing since > 2000. In my view the questions come down to how much the ramstage does, how > that impacts code complexity and performance, and when the ramstage gets so > much capability that it ought to be a kernel. > > In the earliest iteration, there was no ramstage per se. What we now call > the ramstage was a Linux kernel. > > We had lots of discussions in the early days with LNXI and others about > what would boot fastest, a dedicated boot loader like etherboot or a > general purpose kernel like Linux. In all the cases we measured at Los > Alamos, Linux always won, easily: yes, slower to load than etherboot, more > startup overhead, but once started Linux support for concurrency and > parallelism always won the day. Loaders like etherboot (and its descendant, > iPXE) spend most of their time doing nothing (as measured at the time). It > was fun to boot 1000 nodes in the time it took PXE on one node to find a > connected NIC. > > The arguments over payload ended when the FLASH sockets changed to QFP and > maxed at 256K and Linux could no longer fit. > > But if your goal is fast boot, in fact if your goal is 800 miliseconds, we > know this can work on slow ARMs with Linux, as was shown in 2006. > > The very first ramstage was created because Linux could not correctly > configure a PCI bus in 2000. The core of the ramstage as we know it was the > PCI config. > > We wanted to have ramstage only do PCI setup. We initially put SMP startup > in Linux, which worked on all but K7, at which point ramstage took on SMP > startup too. And ramstage started to grow. The growth has never stopped. > > At what point is ramstage a kernel? I think at the point we add file > systems or preemptive scheduling. We're getting dangerously close. If we > really start to cross that boundary, it's time to rethink the ramstage in > my view. It's not a good foundation for a kernel. > > I've experimented with kernel-as-ramstage with harvey on the riscv and it > worked. In this case, I manually removed the ramstage from coreboot.rom and > replaced it with a kernel. It would be interesting, to me at least, to have > a Kconfig option whereby we can replace the ramstage with some other ELF > file, to aid such exploration. > > I also wonder if we're not at a fork in the road in some ways. There are > open systems, like RISCV, in which we have full control and can really get > flexibility in how we boot. We can influence the RISCV vendors not to > implement hardware designs that have negative impact on firmware and boot > time performance. And then there are closed systems, like x86, in which > many opportunities for optimization are lost, and we have little > opportunity to impact hardware design. We also can't get very smart on x86 > because the FSP boulder blocks the road. > > Where do we go from here? > > ron > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Add coreboot storage driver
by Patrick Georgi 14 Feb '17

14 Feb '17

2017-02-14 17:12 GMT+01:00 Aaron Durbin via coreboot <coreboot(a)coreboot.org>: > For an optimized bootflow > all pieces of work that need to be done pretty much need to be closely > coupled. One needs to globally optimize the full sequence. Like initializing slow hardware even before RAM init (as long as it's just an initial command)? How about using PIT/IRQ0 plus some tiny register-only interrupt routine to do trivial register wrangling (we do have register scripts)? > that we seem to be absolutely needing to > maintain boot speeds. Is Chrome OS going against tide of coreboot > wanting to solve those sorts of issues? The problem is that two basic qualities collide here: speed and simplicity. The effect is that people ask to stop a second to reconsider the options. MPinit and parallelism are the "go to" solution for all performance related issues of the last 10 years, but they're not without cost. Questioning this approach doesn't mean that that we shouldn't go there at all, just that the obvious answers might not lead to simple solutions. As Andrey stated elsewhere, we're far from CPU bound. For his concrete example: does eMMC init fail if you ping it more often than every 10ms? It better not, you already stated that it's hard to guarantee those 10ms, so there needs to be some spare room. We could look at the largest chunk of init process that could be restructured to implement cooperative multithreading on a single core for as many tasks as possible, to cut down on all those udelays (or even mdelays). Maybe we could even build a compiler plugin to ensure at compile time that the resulting code is proper (loops either have low bounds or are yielding, yield()/sched()/... aren't called within critical sections)... Once we leave that scheduling to physics (ie enabling multicore operation), all bets are off (or we have to synchronize the execution to a degree that we could just as well do it manually). A lot of complexity just to have 8 times the CPU power for the same amount of IO bound tasks. Patrick

1 0

Re: [coreboot] Add coreboot storage driver
by Aaron Durbin 14 Feb '17

14 Feb '17

On Tue, Feb 14, 2017 at 11:56 AM, ron minnich <rminnich(a)gmail.com> wrote: > Just a reminder about times past. This discussion has been ongoing since > 2000. In my view the questions come down to how much the ramstage does, how > that impacts code complexity and performance, and when the ramstage gets so > much capability that it ought to be a kernel. > > In the earliest iteration, there was no ramstage per se. What we now call > the ramstage was a Linux kernel. > > We had lots of discussions in the early days with LNXI and others about what > would boot fastest, a dedicated boot loader like etherboot or a general > purpose kernel like Linux. In all the cases we measured at Los Alamos, Linux > always won, easily: yes, slower to load than etherboot, more startup > overhead, but once started Linux support for concurrency and parallelism > always won the day. Loaders like etherboot (and its descendant, iPXE) spend > most of their time doing nothing (as measured at the time). It was fun to > boot 1000 nodes in the time it took PXE on one node to find a connected NIC. > > The arguments over payload ended when the FLASH sockets changed to QFP and > maxed at 256K and Linux could no longer fit. > > But if your goal is fast boot, in fact if your goal is 800 miliseconds, we > know this can work on slow ARMs with Linux, as was shown in 2006. > > The very first ramstage was created because Linux could not correctly > configure a PCI bus in 2000. The core of the ramstage as we know it was the > PCI config. > > We wanted to have ramstage only do PCI setup. We initially put SMP startup > in Linux, which worked on all but K7, at which point ramstage took on SMP > startup too. And ramstage started to grow. The growth has never stopped. > > At what point is ramstage a kernel? I think at the point we add file systems > or preemptive scheduling. We're getting dangerously close. If we really > start to cross that boundary, it's time to rethink the ramstage in my view. > It's not a good foundation for a kernel. > > I've experimented with kernel-as-ramstage with harvey on the riscv and it > worked. In this case, I manually removed the ramstage from coreboot.rom and > replaced it with a kernel. It would be interesting, to me at least, to have > a Kconfig option whereby we can replace the ramstage with some other ELF > file, to aid such exploration. > > I also wonder if we're not at a fork in the road in some ways. There are > open systems, like RISCV, in which we have full control and can really get > flexibility in how we boot. We can influence the RISCV vendors not to > implement hardware designs that have negative impact on firmware and boot > time performance. And then there are closed systems, like x86, in which many > opportunities for optimization are lost, and we have little opportunity to > impact hardware design. We also can't get very smart on x86 because the FSP > boulder blocks the road. > > Where do we go from here? That I'm not sure. And it does very much depend on the goals of the project. I will say this, though. Not all architectures are the same so comparing them both as apples is impossible. With ARM punting almost all of its initialization to ATF or the kernel it's not surprising that coreboot's current architecture is simple and easy for it. The work has just been pushed into other places. For some reason Intel continually decides to place a large amount of things into the firmware to do, but I think that decision is usually taken because it keeps the kernel simpler. The complexity just got moved to a different place in the stack. Coupled with the decision to hide the SoC support into a closed off blob just makes things worse. When comparing an Intel solution to an ARM vendor the SoC bits for bring up are much more open and thus easier to optimize, if needed. As noted before you can't punt things out on x86 where device visibility needs be configured prior to resource allocation so there's definitely intertwining involved in bringing up the intel SoCs. Firmware is inherently exposed to the micro-architecture of the underlying device. There's not a good way around that. Acting like it's not doesn't solve that problem. > > ron

1 0

Re: [coreboot] Add coreboot storage driver
by ron minnich 14 Feb '17

14 Feb '17

Just a reminder about times past. This discussion has been ongoing since 2000. In my view the questions come down to how much the ramstage does, how that impacts code complexity and performance, and when the ramstage gets so much capability that it ought to be a kernel. In the earliest iteration, there was no ramstage per se. What we now call the ramstage was a Linux kernel. We had lots of discussions in the early days with LNXI and others about what would boot fastest, a dedicated boot loader like etherboot or a general purpose kernel like Linux. In all the cases we measured at Los Alamos, Linux always won, easily: yes, slower to load than etherboot, more startup overhead, but once started Linux support for concurrency and parallelism always won the day. Loaders like etherboot (and its descendant, iPXE) spend most of their time doing nothing (as measured at the time). It was fun to boot 1000 nodes in the time it took PXE on one node to find a connected NIC. The arguments over payload ended when the FLASH sockets changed to QFP and maxed at 256K and Linux could no longer fit. But if your goal is fast boot, in fact if your goal is 800 miliseconds, we know this can work on slow ARMs with Linux, as was shown in 2006. The very first ramstage was created because Linux could not correctly configure a PCI bus in 2000. The core of the ramstage as we know it was the PCI config. We wanted to have ramstage only do PCI setup. We initially put SMP startup in Linux, which worked on all but K7, at which point ramstage took on SMP startup too. And ramstage started to grow. The growth has never stopped. At what point is ramstage a kernel? I think at the point we add file systems or preemptive scheduling. We're getting dangerously close. If we really start to cross that boundary, it's time to rethink the ramstage in my view. It's not a good foundation for a kernel. I've experimented with kernel-as-ramstage with harvey on the riscv and it worked. In this case, I manually removed the ramstage from coreboot.rom and replaced it with a kernel. It would be interesting, to me at least, to have a Kconfig option whereby we can replace the ramstage with some other ELF file, to aid such exploration. I also wonder if we're not at a fork in the road in some ways. There are open systems, like RISCV, in which we have full control and can really get flexibility in how we boot. We can influence the RISCV vendors not to implement hardware designs that have negative impact on firmware and boot time performance. And then there are closed systems, like x86, in which many opportunities for optimization are lost, and we have little opportunity to impact hardware design. We also can't get very smart on x86 because the FSP boulder blocks the road. Where do we go from here? ron

1 0

Re: [coreboot] Add coreboot storage driver
by Aaron Durbin 14 Feb '17

14 Feb '17

On Mon, Feb 13, 2017 at 9:32 PM, ron minnich <rminnich(a)gmail.com> wrote: > andrey, great questions. If you're really concerned about those issues, then > yes, maybe a space sharing solution is the right one. > > I really would rather not see people implementing schedulers at this point. > If we're going to go that route, let's get a reasonable > operating system and use it instead. If we continue on coreboot's current > trajectory we're going to end up like every other > firmware project that became an OS, and that to me is the wrong direction. It's quite the predicament if we don't want to give up on boot speed. Being heavily invested in coreboot is where we currently are -- for better or worse (I think for the better). For an optimized bootflow all pieces of work that need to be done pretty much need to be closely coupled. One needs to globally optimize the full sequence. Carving that work into granular pieces across different code bases just leaves the perf on the floor that we seem to be absolutely needing to maintain boot speeds. Is Chrome OS going against tide of coreboot wanting to solve those sorts of issues? > > ron > > On Mon, Feb 13, 2017 at 6:43 PM Andrey Petrov <andrey.petrov(a)intel.com> > wrote: >> >> Hi, >> >> On 02/13/2017 12:31 PM, ron minnich wrote: >> > Another idea just popped up: Performing "background" tasks in >> > udelay() >> > / mdelay() implementations ;) >> > >> > >> > that is adurbin's threading model. I really like it. >> > >> > A lot of times, concurrency will get you just as far as ||ism without >> > the nastiness. >> >> But how do you guarantee code will get a slice of execution time when it >> needs it? For example for eMMC link training you need to issue certain >> commands with certain time interval. Lets say every 10ms. How do you >> make sure that happens? You can keep track of time and see when next >> piece of work needs to be scheduled, but how do you guarantee you enter >> this udelay code often enough? >> >> Andrey > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot

1 0

← Newer
1
...
10
11
12
13
14
15
16
...
22
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 February 2017