On Mon, May 27, 2013 at 9:45 PM, David Hubbard david.c.hubbard+coreboot@gmail.com wrote:
- How hard would it be to import the kernel code into coreboot directly?
don't. You should do a lot of extraction using coccinelle. And even then, there's lots of work to do. I hope to start commits next week and hopefully this will provide some ideas.
The ACPI init at the end could be skipped for a first attempt.
yeah.
It would be some work to find the kernel APIs used in the radeon code and produce suitable glue for coreboot.
yes, do don't do that. The kernel APIs are not right for firmware.
- Do coreboot developers have contact with the radeon driver developers? A
little nudge from time to time could keep a project like this on track.
anyone?
- It feels wrong to add so much code to coreboot.
So, don't add it. The i915 support is slowly boiling down to a few hundred lines and that should be your goal. Also, the kernel uses generic code to switch to device specific functions. That makes sense for a kernel, because it boots on many chipsets and many vga devices. It makes no sense for firmware, because we have so much we already know -- what chipset, what vga, etc.. Remove generice code and create device specific functions with a reasonable API.
With 20/20 hindsight, this could be one of UEFI's downfalls, namely making the pre-boot environment into an entire kernel.
I've been saying this for 14 years ... :-)
But they are not listening of course. EFI is basically a not very good OS that is wanting to be a boot loader. It never made much sense technically but it seems to have done well politically.
Is a modular approach better? A payload to modeset or some sort of driver model would be nice.
No, what's best is a simple set of functions with a simple API. See superio for example. Or give it 2 more weeks and see what is coming :-)
ron
-
ron minnich