Ron,
one question though:
how does the information in the DTS relate to the information in the file irq_tables.c below?
Do we have to specify polarity and interrupt enables twice now?
We need to add all information from irq_tables.c to the mainboard DTS and read it from there. The mainboard DTS is our central data structure.
something like
eth0 { routing = "C, D, A, B"; polarity="level" }; pci_slot1 { routing = "B, C, D, A"; polarity="edge" }; pci_slot2 { ... }; agp_slot { .... };
I know the only truth is sending patches, but I see we're falling back into an old, overhauled scheme here and we should rethink careful. Two places for defining things is a 100% guarantee for failures to happen.
Stefan
* svn@coreboot.org svn@coreboot.org [080209 17:33]:
Modified: coreboot-v3/mainboard/pcengines/alix1c/dts
--- coreboot-v3/mainboard/pcengines/alix1c/dts 2008-02-08 15:57:02 UTC (rev 581) +++ coreboot-v3/mainboard/pcengines/alix1c/dts 2008-02-09 16:32:59 UTC (rev 582) @@ -43,6 +43,16 @@ pcipath = "0xf,0"; enabled; enable_ide = "1";
/* Interrupt enables for LPC bus.
* Each bit is an IRQ 0-15. */
lpc_serirq_enable = "0x000010da";
/* LPC IRQ polarity. Each bit is an IRQ 0-15. */
lpc_serirq_polarity = "0x0000EF25";
/* 0:continuous 1:quiet */
lpc_serirq_mode = "1";
/* GPIO(0-0x20) for INT D:C:B:A, 0xFF=none.
* See virtual PIC spec. */
}; superio { /config/("superio/winbond/w83627hf/dts");enable_gpio_int_route = "0x0D0C0700";
Added: coreboot-v3/mainboard/pcengines/alix1c/irq_tables.c
--- coreboot-v3/mainboard/pcengines/alix1c/irq_tables.c (rev 0) +++ coreboot-v3/mainboard/pcengines/alix1c/irq_tables.c 2008-02-09 16:32:59 UTC (rev 582)
+/* Platform IRQs */ +#define PIRQA 11 +#define PIRQB 10 +#define PIRQC 11 +#define PIRQD 9
- What Device IRQ PIN PIN WIRED TO
- AES 00:01.2 0a 01 A A
- 3VPCI 00:0c.0 0a 01 A A
- eth0 00:0d.0 0b 01 A B
- mpci 00:0e.0 0a 01 A A
- usb 00:0f.3 0b 02 B B
- usb 00:0f.4 0b 04 D D
- usb 00:0f.5 0b 04 D D
/* CPU */
{0x00, (0x01 << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},
/* PCI (slot 1) */
{0x00, (0x0C << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}}, 0x4, 0x0},
/* On-board ethernet */
{0x00, (0x0D << 3) | 0x0, {{L_PIRQB, M_PIRQB}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},
/* Mini PCI (slot 2) */
{0x00, (0x0E << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x1, 0x0},
/* Chipset slots -- f.3 wires to B, and f.4 and f.5 wires to D. */
{0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0},
- }
+};
On Feb 9, 2008 9:27 AM, Stefan Reinauer stepan@coresystems.de wrote:
Ron,
one question though:
how does the information in the DTS relate to the information in the file irq_tables.c below?
Do we have to specify polarity and interrupt enables twice now?
We need to add all information from irq_tables.c to the mainboard DTS and read it from there. The mainboard DTS is our central data structure.
you are right and I was not thinking. I will work on this today.
BTW, boot time is "really fast". So fast I can't easily time it. And there are some warning prints in there that need to be debug, so there is room to make it just a tad faster. From power on to FILO prompt just feels instantaneous, though.
OK, I will look at this dts issue. I wonder if we need a pirq node in the dts?
ron
On Feb 9, 2008 9:40 AM, ron minnich rminnich@gmail.com wrote:
OK, I will look at this dts issue. I wonder if we need a pirq node in the dts?
Well, let's toss some ideas around here. I don't quite know how we should specify pirq in the dts. Before you join this discussion, be sure you have read the $PIR spec :-)
There are several pieces. First are the values of the "links", then the values of the "masks".
So we could have a dts node like this: pirq { lirqa = "value"; lirqb = "value"; lirqc = "value"; lirqd = "value"; mirqa = "value"; etc. };
Then we could specify a device ether0 {pcipath="dev,fn"; /* bus is inherited from parent */ pirq { routing="B,C,D,A"; level="edge"}; };
This all has to be parsed in flattree.c
I welcome other ideas. I assume this info would go in the struct device, although it is a tad PCI specific, not compatible with PCI-E. Comments?
I won't port any other LX targets until we work this out.
On another note, how do we do VGA?
BTW I have a hunch that v3 on this thing is a tad faster than v2. It's only a hunch. It just feels a bit faster.
ron
On Sat, Feb 09, 2008 at 09:40:54AM -0800, ron minnich wrote:
On Feb 9, 2008 9:27 AM, Stefan Reinauer stepan@coresystems.de wrote:
We need to add all information from irq_tables.c to the mainboard DTS and read it from there. The mainboard DTS is our central data structure.
Was just about to write same.
you are right and I was not thinking. I will work on this today.
BTW, boot time is "really fast". So fast I can't easily time it. And there are some warning prints in there that need to be debug, so there is room to make it just a tad faster. From power on to FILO prompt just feels instantaneous, though.
Just as if modern firmware was running on modern hardware! ;)
OK, I will look at this dts issue. I wonder if we need a pirq node in the dts?
I think interrupt routing in dts will need a bit of thought.
Perhaps we can combine all previous ways of describing interrupt routing in a new, better, simpler way?
Then have generators for ACPI, PIRQ, device tree, whatever..
//Peter
On Feb 9, 2008 9:53 AM, Peter Stuge peter@stuge.se wrote:
Perhaps we can combine all previous ways of describing interrupt routing in a new, better, simpler way?
Then have generators for ACPI, PIRQ, device tree, whatever..
This just started sounding really hard.
I don't know if we need total generality, thinking about it. I am guessing that, in any general scheme, we should drop $PIR from a list of things we care about.
$PIR is really deprecated. And it doesn't work all that well anyway -- the kernel(s) keep getting it wrong. The kernel only really looks at $PIR when the 3c.b register is zero. We're better off just setting this stuff in the kernel.
So, maybe what I should have done, for older systems like LX, is have a simple hardwire map in the mainboard for specifying how to set interrupt registers, and just drop $PIR entirely? I think we should ignore $PIR in any future scheme, and do something simple for now.
FWIW, the interrupt map for these systems is just a 2d array, and on the LX map, many of the entries in the array are zero.
It's also a sparse array, with just two indices: the busdevfn (16 bits) and the interrupt # (2 bits).
Will removing PIR hurt hot plug? I doubt it -- hot plug is for newer stuff and that's all PCI-E anyway.
Just some random thoughts. Who understands ACPI interrupt specification? I still don't.
ron
Who understands ACPI interrupt specification? I still don't.
It depends what you need. If you care only about APIC interrupt based routing then it is quite easy.
Just create a _PRT method for all PCI bridges:
Package (0x04) { 0x000BFFFF, 0x00, 0x00, 0x10 }, //slot 0xB Package (0x04) { 0x000BFFFF, 0x01, 0x00, 0x11 }, Package (0x04) { 0x000BFFFF, 0x02, 0x00, 0x12 }, Package (0x04) { 0x000BFFFF, 0x03, 0x00, 0x13 },
0x0B is slot 0x00 0xffff means all functions 0x00-0x03 is INTA-INTD and
0x10-0x13 are so called GSI (global system interrupt). All your interrupts routed through first APIC will start with 0x00, second APIC will perhaps start at IRQ24 etc etc.
If you want to support also PIC based routing and let OS choose, then you need to put there instead 0f 0x00 on third position PIRQA-PIRQD special devices and create some method which will either return APIC based table like abobe or PIC based table if IOAPIC is "disabled". I dont care about DOS and very legacy systems so I have implemented just APIC based _PRTs.
In other words you dont need PIR if you implement the _PRT with legacy PIRQ entries.
http://www.microsoft.com/whdc/system/CEC/ACPI-MP.mspx
Maybe we can add this link to wiki?
Rudolf
what amazes me is that we can do this in ACPI but it cost 270K. It doesn't seem worth it.
thanks
ron
On Mon, Feb 11, 2008 at 04:59:26AM -0800, ron minnich wrote:
what amazes me is that we can do this in ACPI but it cost 270K. It doesn't seem worth it.
We should test the size difference after the tiny patches are applied. I'll see if I have some time today.
Thanks, Ward.
On 11.02.2008 13:59, ron minnich wrote:
what amazes me is that we can do this in ACPI but it cost 270K. It doesn't seem worth it.
270k in the Linux kernel, not necessarily in the ROM. In case we boot from hard disk, this is no problem, and the space requirements on the coreboot side are almost zero. So I see this as one very good route to tell the OS about interrupts.
Regards, Carl-Daniel