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