This patch (which is NOT signed off) adds (or tries to) PIRQ support for the alix1c.
it crashes and burns badly, however, I don' t know why. Marc, is 0xf0000 set up as memory in the v3 port? I am not sure.
It dies at a strange point: PCI: devfn 0x9, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000(c) PCI: devfn 0xa pci_scan_get_dev: list is 0x00087eb8, *list is 0x0000b060 pci_scan_get_dev: check dev southbridge pci_scan_get_dev: check dev southbridge it has devfn 0x78 pci_scan_get_dev: check dev superio superio: Unknown device path type: 0 pci_scan_get_dev: child superio() not a pci device: it's type 0 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) new_device: devcnt 1
I can't see why it would die here. At the same time, I am not sure that we're not losing what's in the serial FIFO. Lots of FIFO action here. In fact, to help serial out run faster, I do this: cat /dev/ttyS0 instead of running minicom!
I have seen minicom buffering almost 30-40 seconds of serial output once I turn the alix off. Or, something is buffering it. Flow control is OFF in minicom.
Note that if I comment out this line: select PIRQ_TABLE in mainboard/pcengines/Kconfig, this bios builds and runs fine.
weird.
ron
On 08.02.2008 06:54, ron minnich wrote:
This patch (which is NOT signed off) adds (or tries to) PIRQ support for the alix1c.
it crashes and burns badly, however, I don' t know why.
You found the problem with LAR parsing of ELF. Any reason why this can't affect stage2 as well?
Regards, Carl-Daniel
On 08.02.2008 12:51, Carl-Daniel Hailfinger wrote:
On 08.02.2008 06:54, ron minnich wrote:
This patch (which is NOT signed off) adds (or tries to) PIRQ support for the alix1c.
it crashes and burns badly, however, I don' t know why.
You found the problem with LAR parsing of ELF. Any reason why this can't affect stage2 as well?
Sorry, some of your mails (including the one with the LAR patch) were caught by my provider's spam filter. I just found them a few minutes ago, so please discard the question above.
Regards, Carl-Daniel
On Feb 8, 2008 3:51 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 08.02.2008 06:54, ron minnich wrote:
This patch (which is NOT signed off) adds (or tries to) PIRQ support for the alix1c.
it crashes and burns badly, however, I don' t know why.
You found the problem with LAR parsing of ELF. Any reason why this can't affect stage2 as well?
I am pretty sure it is. I am thinking on stage 2, however, to add a manual step in main memset(bss, 0, end-bss);
not sure yet.
ron
On Feb 8, 2008 7:53 AM, ron minnich rminnich@gmail.com wrote:
On Feb 8, 2008 3:51 AM, Carl-Daniel Hailfinger
c-d.hailfinger.devel.2006@gmx.net wrote:
On 08.02.2008 06:54, ron minnich wrote:
This patch (which is NOT signed off) adds (or tries to) PIRQ support for the alix1c.
it crashes and burns badly, however, I don' t know why.
You found the problem with LAR parsing of ELF. Any reason why this can't affect stage2 as well?
I am pretty sure it is. I am thinking on stage 2, however, to add a manual step in main memset(bss, 0, end-bss);
ok, no need: the .bss thing is no longer an issue. Here is LAR: normal/stage2/segment0 (191796 bytes, lzma compressed to 110 bytes @0x9500);loadaddress 0x0xb8a0 entry 0x0x2000 normal/stage2/segment1 (32284 bytes, lzma compressed to 17073 bytes @0x95c0);loadaddress 0x0x2000 entry 0x0x2000 normal/stage2/segment2 (6300 bytes, lzma compressed to 431 bytes @0xd8d0);loadaddress 0x0xa000 entry 0x0x2000
Note that stage2 segment 0 is bss! The LAR fix is buying us quite a lot. (that said, decompressing zeros may be a very expensive way to zero-fill a region ...)
This leaves me more puzzled, will try more tonight.
ron
On 08.02.2008 06:54, ron minnich wrote:
This patch (which is NOT signed off) adds (or tries to) PIRQ support for the alix1c.
it crashes and burns badly, however, I don' t know why. Marc, is 0xf0000 set up as memory in the v3 port? I am not sure.
I still have the suspicion that the VSA doesn't like us.
Can you try latest svn (should have all your patches except the PIRQ one) and vendor BIOS and run lspci -nnvvvxxx for both under Linux? While interrupt stuff will surely not be identical, I hope we find something else to take a look at. Oh, and a possibly nice VSA stress test: run lspci -xxx in a tight loop for a few minutes.
Hm. Looking again at your patch, it seems there is some unmerged stuff besides PIRQ in it. We might want to merge that as well.
It dies at a strange point: PCI: devfn 0x9, bad id 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000(c) PCI: devfn 0xa pci_scan_get_dev: list is 0x00087eb8, *list is 0x0000b060 pci_scan_get_dev: check dev southbridge pci_scan_get_dev: check dev southbridge it has devfn 0x78 pci_scan_get_dev: check dev superio superio: Unknown device path type: 0 pci_scan_get_dev: child superio() not a pci device: it's type 0 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) new_device: devcnt 1
I can't see why it would die here. At the same time, I am not sure that we're not losing what's in the serial FIFO. Lots of FIFO action here. In fact, to help serial out run faster, I do this: cat /dev/ttyS0 instead of running minicom!
I have seen minicom buffering almost 30-40 seconds of serial output once I turn the alix off. Or, something is buffering it. Flow control is OFF in minicom.
Hm. Add banner printing to crucial points in pci_scan_dev? That should help if you are fighting with a FIFO issue.
Note that if I comment out this line: select PIRQ_TABLE in mainboard/pcengines/Kconfig, this bios builds and runs fine.
weird.
This is a crucial piece of information. It means we die here (unless we trigger bugs elsewhere due to alignment/memory layout/memory contents):
--- arch/x86/archtables.c (revision 578) +++ arch/x86/archtables.c (working copy) @@ -79,8 +79,13 @@ post_code(POST_STAGE2_ARCH_WRITE_TABLES_ENTER);
/* This table must be betweeen 0xf0000 & 0x100000 */ -// rom_table_end = write_pirq_routing_table(rom_table_end); -// rom_table_end = (rom_table_end + 1023) & ~1023;
- /* we need to make a decision: create empty functions
* in .h files if the cpp variable is undefined, or #ifdef?*/+#ifdef CONFIG_PIRQ_TABLES
Add a few banner prints here.
- rom_table_end = write_pirq_routing_table(rom_table_end);
Boom. A few more banner prints here.
- rom_table_end = (rom_table_end + 1023) & ~1023;
+#endif
/* Write ACPI tables */ /* write them in the rom area because DSDT can be large (8K on epia-m) which
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger -
ron minnich