Well, after many months I'm back to working on mapping IRQs for the MaxTerm 230 thin client system (Geode GX1/CS5530). First issue is flashrom. I've been swapping BIOS chips until now, but I want to start using flashrom to avoid wear on the PLCC sockets. However, flashrom identifies my SST29EE020 as an 020A, and seems unable to erase or program it. The erase option returns immediately, apparently doing nothing but not returning failure. The burn option also returns immediately, and indicates failure either because the chip isn't blank, or (I suspect) it's not actually able to write to it:
[root@fc5-test ~]# ./flashrom Calibrating delay loop... ok Found LinuxBIOS table at: 00000530 vendor id: eaglelion part id: 5bcm Enabling flash write on CS5530...OK SST29EE020A found at physical address: 0xfffc0000 Flash part is SST29EE020A (256 KB) OK, only ENABLING flash write, but NOT FLASHING. [root@fc5-test ~]# ./flashrom -E Calibrating delay loop... ok Found LinuxBIOS table at: 00000530 vendor id: eaglelion part id: 5bcm Enabling flash write on CS5530...OK SST29EE020A found at physical address: 0xfffc0000 Flash part is SST29EE020A (256 KB) Erasing flash chip [root@fc5-test ~]# ./flashrom -v linuxbios-irq-test2-20070301.rom Calibrating delay loop... ok Found LinuxBIOS table at: 00000530 vendor id: eaglelion part id: 5bcm Enabling flash write on CS5530...OK SST29EE020A found at physical address: 0xfffc0000 Flash part is SST29EE020A (256 KB) Verifying flash - FAILED [root@fc5-test ~]#
Any clues to flashrom's behavior appreciated.
I'm also trying to map out the IRQ routing for the onboard NIC and USB OHCI adapters, and I have a few questions: * Does the order the devices appear in LB's irq_tables.c matter? * Linux always finds the LB IRQ table, but doesn't seem able to map IRQs to my devices. Aren't the PCI IRQ lines mappable to pretty much any available ISA IRQ line, or are these hardwired? Here's an example of what I mean, from one of my tests (kernel 2.6.20.1, with PCI debugging enabled): natsemi dp8381x driver, version 2.1, Sept 11, 2006 originally by Donald Becker becker@scyld.com http://www.scyld.com/network/natsemi.html 2.4.x kernel port by Jeff Garzik, Tjeerd Mulder IRQ for 0000:00:15.0[A] -> PIRQ 02, mask 0400, excl 0800 -> newirq=10 ... failed PCI: Guessed IRQ 10 for device 0000:00:15.0 natsemi eth0: NatSemi DP8381[56] at 0xfebf2000 (0000:00:15.0), 00:50:f6:22:66:ba , IRQ 10, port TP.
Even though it "guesses" IRQ 10, which is what I set in the table, it doesn't work. Is that because I've got the NIC's INTA pointed at the wrong PCI IRQ in my irq_tables.c, or because of something else?
Oh and before I forget, this is harder than a normal PC, due to the fact that the original BIOS in this winterm was for WinCE only. Thanks for any help with the IRQ mapping, I've not done this before and I'm not having an easy time with it.
-Jonathan
* Jonathan Sturges jonathan@sprintmail.com [070302 01:04]:
apparently doing nothing but not returning failure. The burn option also returns immediately, and indicates failure either because the chip isn't blank, or (I suspect) it's not actually able to write to it:
-v only does verify. you have to use -w for writing.
[root@fc5-test ~]# ./flashrom -E Calibrating delay loop... ok Found LinuxBIOS table at: 00000530 vendor id: eaglelion part id: 5bcm Enabling flash write on CS5530...OK SST29EE020A found at physical address: 0xfffc0000 Flash part is SST29EE020A (256 KB) Erasing flash chip [root@fc5-test ~]# ./flashrom -v linuxbios-irq-test2-20070301.rom Calibrating delay loop... ok Found LinuxBIOS table at: 00000530 vendor id: eaglelion part id: 5bcm Enabling flash write on CS5530...OK SST29EE020A found at physical address: 0xfffc0000 Flash part is SST29EE020A (256 KB) Verifying flash - FAILED [root@fc5-test ~]#
Any clues to flashrom's behavior appreciated.
I'm also trying to map out the IRQ routing for the onboard NIC and USB OHCI adapters, and I have a few questions:
- Does the order the devices appear in LB's irq_tables.c matter?
- Linux always finds the LB IRQ table, but doesn't seem able to map
IRQs to my devices. Aren't the PCI IRQ lines mappable to pretty much any available ISA IRQ line, or are these hardwired? Here's an example of what I mean, from one of my tests (kernel 2.6.20.1, with PCI debugging enabled): natsemi dp8381x driver, version 2.1, Sept 11, 2006 originally by Donald Becker becker@scyld.com http://www.scyld.com/network/natsemi.html 2.4.x kernel port by Jeff Garzik, Tjeerd Mulder IRQ for 0000:00:15.0[A] -> PIRQ 02, mask 0400, excl 0800 -> newirq=10 ... failed PCI: Guessed IRQ 10 for device 0000:00:15.0 natsemi eth0: NatSemi DP8381[56] at 0xfebf2000 (0000:00:15.0), 00:50:f6:22:66:ba , IRQ 10, port TP.
Even though it "guesses" IRQ 10, which is what I set in the table, it doesn't work. Is that because I've got the NIC's INTA pointed at the wrong PCI IRQ in my irq_tables.c, or because of something else?
Oh and before I forget, this is harder than a normal PC, due to the fact that the original BIOS in this winterm was for WinCE only. Thanks for any help with the IRQ mapping, I've not done this before and I'm not having an easy time with it.
-Jonathan
-- linuxbios mailing list linuxbios@linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios
Hi,
just a side-note: please don't send HTML mails, they're horribly hard to read...
On Fri, Mar 02, 2007 at 10:59:45AM -0500, Jonathan Sturges wrote:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Thanks, Uwe.
On 3/1/07, Jonathan Sturges jonathan@sprintmail.com wrote:
- Does the order the devices appear in LB's irq_tables.c matter?
no, it keys by dev:fn.
- Linux always finds the LB IRQ table, but doesn't seem able to map
IRQs to my devices. Aren't the PCI IRQ lines mappable to pretty much any available ISA IRQ line, or are these hardwired? Here's an example of what I mean, from one of my tests (kernel 2.6.20.1, with PCI debugging enabled):
it's possible the pirq table is wrong, this is a frequent problem.
You can boot under the standard os, standard bios, and just look at the 3c register e.g. setpci -x 2:1.0 3cb. to see what the irq is for each device, then set your PIRQ table to work. Or, what we sometimes do, just ignore the PIRQ table and set the IRQs in linuxbios.
Even though it "guesses" IRQ 10, which is what I set in the table, it doesn't work. Is that because I've got the NIC's INTA pointed at the wrong PCI IRQ in my irq_tables.c, or because of something else?
could be some other stupid thing also needs setting up -- sometimes a problem on embedded system.
Oh and before I forget, this is harder than a normal PC, due to the fact that the original BIOS in this winterm was for WinCE only. Thanks for any help with the IRQ mapping, I've not done this before and I'm not having an easy time with it.
it's either hard or harder. You're doing fine. After DRAM, IRQs are the hardest thing to get right, thanks to the bad design of PCI interrupts.
ron
-
Jonathan Sturges -
Jonathan Sturges -
ron minnich -
Stefan Reinauer -
Uwe Hermann