On Mon, May 27, 2013 at 9:45 PM, David Hubbard <[email protected]> wrote:
> 1. 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. > 2. 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? > > 3. 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 -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
