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
On Tue, Feb 14, 2017 at 1:06 PM, Nico Huber nico.h@gmx.de wrote:
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???
You need a stack and vector for the SIPI to be somewhere.
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.
This largely works with static allocation, but the question is if you want to handle different SKUs of devices that have different hardware behind root bridges. You need to recalculate the IO windows. You could produce a signature of devices and leverage that for picking the right static allocation. Doable, but gets kinda funky needing to run the allocation pass for each configuration and ensuring its updated properly.
o Those small PCI device "drivers" => I doubt they need RAM
That's how their initialization code is currently scheduled. May not need RAM, but I'm not sure that's what makes them distinctive nor why you bring this up? Just a regular pci device doesn't need anything in practice. It's the workarounds and things that need to be done for power optimization, etc is where the complexity arises. Using pci device "drivers" as a proxy for all pci devices isn't representative.
o Table generation => Not that dynamic after all I suppose much is done with static (compile time) information.
Sure, if you go and analyze devicetree.cb to know all the options. Tables have quite a few things that change based on runtime attributes aside from that. For example, a single firmware build can support a different number SoC models that have largely different numbers of CPUs, etc or support different feature sets that require different table generation.
o Sometimes gfx modesetting => do it in the payload
Nico
Hi All,
We started looking at doing things in parallel speed the boot process and meet the ChromeOS boot time requirements. One of the larger portions of boot time is memory initialization which is why we are considering doing parallelism early.
On Chromebooks, the Intel boot path is using bootstage/verstage to determine which version of romstage should run. Memory initialization is being done during romstage which is now replaceable in the field. One approach to parallelism is to use additional processors. This approach requires that the cores start in the bootblock and transition to romstage to perform work in parallel with memory initialization. While this approach has a number of issues, it is a path that might work with the existing FSP architecture. Other single-thread approaches are also possible but most likely require changes to the FSP architecture to do work in parallel with memory initialization.
This thread has discussed multiple alternatives to achieve parallelism. At this time we are not considering any type of preemptive mechanism. Currently we are investigating alternatives and what benefits they bring. If our investigation indicates that the parallelism significantly reduces the boot time and that the code is easy to develop and understand then we will share the patches with the coreboot community for further review and comment.
Until then we welcome constructive ways to enable coreboot to do things in parallel to reduce the boot time.
Thanks for your help, Lee Leahy (425) 881-4919 Intel Corporation Suite 125 2700 - 156th Ave NE Bellevue, WA 98007-6554
-----Original Message----- From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Nico Huber Sent: Tuesday, February 14, 2017 11:07 AM To: ron minnich rminnich@gmail.com; Aaron Durbin adurbin@google.com Cc: Petrov, Andrey andrey.petrov@intel.com; Coreboot coreboot@coreboot.org Subject: Re: [coreboot] Add coreboot storage driver
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
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
-
Aaron Durbin -
Leahy, Leroy P -
Nico Huber