Peter Stuge wrote:
Jens Rottmann wrote:
Maybe make that one option per port instead,
I had considered this but decided against it.
Oh well.
It is simply not feasible to make _everything_ configurable,
I'm not sure I agree about feasible. I agree it's not worthwhile though. You know your customers best, but from my experience with embedded customers, more configurability is better. :)
It also changes the code from "do the minimal effort for hardware init" to "parse a lot of different options and make sure all possible combinations make sense and work".
I'm not saying we shouldn't. I'm just saying it'll be a shift in principles. (And a lot of effort if done right)
you'd have to start with devicetree.cb,
I know. This is one part of coreboot "infrastructure" that I think needs some improvement. A first step would be interrupt routing.
It might also be nice to make it a little easier to use devicetree.cb from the coreboot code.
Now that we have a good grip on the device tree and sconfig is increasingly stable, we should discuss how to get the routing into our device tree. Suggestions?
Some brainstorming: - every device that has an APIC needs to have IRQ routing information. Every bridge, even? - what about 8259? Virtual Wire? - We need to represent the IO apics in the device tree so we can walk the system for dynamic boot time table creation. - any of the i945 ports would be an easy initial target, as they have i945_pci_irqs.asl, ich7_pci_irqs.asl, irq_tables.c and mptable.c in separate files, so they could be replaced easily by something auto generated. *.asl could (at least for now) be created from the device tree at compile time. - A good first start (and relatively easy, since its only refactoring) would also be to factor out interrupt routing from the K8/Fam10 boards into separate files, and move their acpi code to the north/southbridge like it's done on i945/ich7. Any takers?
Stefan