Hi,
I'm missing something obvious and need someone to point me in the right direction.
I'm finishing up mapping IRQs on a CS5530 winterminal board I've got. I know the IRQ mappings of each on-board device and slot, and I put together my irq_tables.c accordingly. However, only the first 2 entries get written to the IRQ table, even though the file designates 3. Then, when I boot the LB image, I get this warning:
Inconsistent IRQ routing table size (0x40/0x50)
The 0x50 makes sense; that's the …
[View More]"32+16*3" from my irq_tables.c. But where is the size being set to 0x40? It seems there's a configuration I missed somewhere.
My irq_tables.c is below.
thanks,
Jonathan
/* This file was generated by getpir.c, do not modify!
(but if you do, please run checkpir on it to verify)
* Contains the IRQ Routing Table dumped directly from your memory, which BIOS sets up
*
* Documentation at : http://www.microsoft.com/hwdev/busbios/PCIIRQ.HTM
*/
#include <arch/pirq_routing.h>
const struct irq_routing_table intel_irq_routing_table = {
PIRQ_SIGNATURE, /* u32 signature */
PIRQ_VERSION, /* u16 version */
32+16*3, /* there can be total 3 devices on the bus */
0x00, /* Where the interrupt router lies (bus) */
(0x12<<3)|0x0, /* Where the interrupt router lies (dev) */
0x0e00, /* IRQs devoted exclusively to PCI usage */
0x1078, /* Vendor */
0x0100, /* Device */
0, /* Crap (miniport) */
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */
0x21, /* u8 checksum , this hase to set to some value that would give 0 after the sum of all bytes for this structure (including checksum) */
/* 0x13 = on-board USB OHCI; 0x15 = on-board NatSemi ethernet; 0x14 = miniPCI */
{
/* bus, dev|fn, {link, bitmap}, {link, bitmap}, {link, bitmap}, {link, bitmap}, slot, rfu */
{0x00,(0x13<<3)|0x0, {{0x01, 0x0400}, {0x02, 0x0800}, {0x03, 0x0200}, {0x04, 0x0000}}, 0x0, 0x0},
{0x00,(0x15<<3)|0x0, {{0x02, 0x0800}, {0x03, 0x0200}, {0x04, 0x0000}, {0x01, 0x0400}}, 0x0, 0x0},
{0x00,(0x14<<3)|0x0, {{0x03, 0x0200}, {0x04, 0x0000}, {0x01, 0x0400}, {0x02, 0x0800}}, 0x0, 0x0},
}
};
unsigned long write_pirq_routing_table(unsigned long addr)
{
return copy_pirq_routing_table(addr);
}
____________________________________________________________________________________
Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.
http://farechase.yahoo.com/
[View Less]
Hi,
when outputting ELF segments in LAR, the utility will use the segment
number from ELF as segment number in the file. This works nicely when
there are no skips (e.g. not PT_LOAD segments, which are discarded).
If one segment is skipped, we get a bump:
normal/payload0/segment0 (27288 bytes, lzma compressed to 14506 bytes
@0x64c0)
normal/payload0/segment2 (211136 bytes, lzma compressed to 70905 bytes
@0x9dc0)
The LAR loader wont load segment2, and in this particular case, grub2-lb
will …
[View More]only boot into rescue mode (segment0 contains it).
Attached patch adds a counter for segment number in the LAR utility to
solve this bug:
normal/payload0/segment0 (27288 bytes, lzma compressed to 14506 bytes
@0x64c0)
normal/payload0/segment1 (211136 bytes, lzma compressed to 70905 bytes
@0x9dc0)
Also the eagle eyed can see that I merged in Uwe's multiple-payload
patch into current stage1, which includes the segment support. And this
means that grub2-lb without any hacks works when loaded from LAR
segments.
--
Alex
[View Less]
Author: uwe
Date: 2007-09-16 16:37:59 +0200 (Sun, 16 Sep 2007)
New Revision: 498
Modified:
LinuxBIOSv3/util/lar/stream.c
Log:
When outputting ELF segments in LAR, the utility will use the segment
number from ELF as segment number in the file. This works nicely when
there are no skips (e.g. not PT_LOAD segments, which are discarded).
If one segment is skipped, we get a bump:
normal/payload0/segment0 (27288 bytes, lzma compressed to 14506 bytes @0x64c0)
normal/payload0/segment2 (211136 …
[View More]bytes, lzma compressed to 70905 bytes @0x9dc0)
The LAR loader wont load segment2, and in this particular case, grub2-lb
will only boot into rescue mode (segment0 contains it).
Attached patch adds a counter for segment number in the LAR utility to
solve this bug:
normal/payload0/segment0 (27288 bytes, lzma compressed to 14506 bytes @0x64c0)
normal/payload0/segment1 (211136 bytes, lzma compressed to 70905 bytes @0x9dc0)
Also the eagle eyed can see that I merged in Uwe's multiple-payload
patch into current stage1, which includes the segment support. And this
means that grub2-lb without any hacks works when loaded from LAR segments.
Signed-off-by: Alex Beregszaszi <alex(a)rtfs.hu>
Acked-by: Ronald G. Minnich <rminnich(a)gmail.com>
Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de>
Modified: LinuxBIOSv3/util/lar/stream.c
===================================================================
--- LinuxBIOSv3/util/lar/stream.c 2007-09-16 14:32:26 UTC (rev 497)
+++ LinuxBIOSv3/util/lar/stream.c 2007-09-16 14:37:59 UTC (rev 498)
@@ -79,6 +79,7 @@
u32 entry;
int i;
int size;
+ int segment = 0;
char *header;
char ename[64];
int headers;
@@ -153,7 +154,7 @@
entry, phdr[i].p_paddr);
}
/* ok, copy it out */
- sprintf(ename, "%s/segment%d", name, i);
+ sprintf(ename, "%s/segment%d", name, segment++);
complen = lar_compress(&header[phdr[i].p_offset], size, temp, &thisalgo);
ret = lar_add_entry(lar, ename, temp, complen, size,
phdr[i].p_paddr, entry, thisalgo);
[View Less]