Pfsense Install on Nokia IP390
-
I would abandon any attempt at decompiling the ipsctl driver. The best clues in the Watchguard OS were in the comments such as Charlie found.
We do now know for sure that the LEDs are software driven and not fed from some on board hardware monitor chip so we can go looking for them knowing they exist. :)Since the cable is so close to the ICH I would start by trying the GPIOs on that. If none of those work then look at the SuperIO chip. Can you see what the SuperIO is on that board? It would help tremedously if it's Winbond because that's what I know. The ICH GPIOs are much easier to test also.
Steve
-
In fact it appears that ipsctl is more like sysctl but using a proprietary set of OIDs. It's not a driver itself, more a way of accessing various data needed by scripts.
If you're still running IPSO and have a console try running 'ipsctl -a' and see what's listed. Is it specific LED states or system states that trigger the LED via some other script?Steve
-
Haha, you've lost me.
I would appreciate it if you explain that in idiot terms, and, I can't seem to identify a SuperIO chip on the board. I know the Intel nhe6300 is an IO controller chip, but, my googling of the matter appears to hint that it's a small chip with a logo printed on it relating to the manufacturer and model no.
All my best guesses for the SuperIO chip turned out to be Texas Instruments I/O controllers or an Altera Logic IC.
Here's a picture of the board, see if you can identify a SuperIO chip:
I did run the ipsctl -a command, here's the output (warning: seriously long.)
http://pastebin.com/RE2wBKDP -
From the position of the other components I would say it's the chip in between the empty BIOS ROM socket and the diagnostic LED readout. Is that the Altera device?
Nokia may not have needed a SuperI/O chip since many of the features they offer aren't needed in an embedded application. I'd be surprised though since everything else is pretty much standard X86 stuff and the SuperIO chip is ubiquitous.Thanks for the output from ipsctl. We can see that the ledtool program as well as the other referenced ways to change the LEDs simply set the values in the hw:sys_stat:state:X and that something else is interpreting those states and setting the LED appropriately as well as whatever other action is required.
Steve
-
Yeah, that's the Altera chip. It's the Altera EPM570F256C5N. Appears to be a programmable logic controller. My guess would be that it might drive the diagnostic LED
Yeah, it does seem that way. The PCMCIA card slot is driven by a Texas Instruments IO controller, which I think might be a child of the Intel chip.
It's possible that the SuperIO is buried under a heatsink, however i'd prefer not to take those off as that might cause further complications on the board, although the heatsinks that I've identified are the processor, north and south bridge chipsets, and 2 ethernet controllers. I don't know what the heatsink that is arranged in 2 rows of lines might be.
So my guess would be then that whatever either runs off of ipsctl, or whatever ipsctl works on, is what actually reads and sets the LEDs.
Would A BIOS dump help at all in identifying what the SuperIO chip might be, if the board has one?
-
I've never seen a superio chip that required a heatsink so I doubt it's hidden. It could be on the bottom of the board. I think it's likely they used the Altera chip for whatever reason. They clearly didn't need a floppy controller or a parallel port or many of the other functions provided. Much of what used to be handled by superio is on the ICH anyway.
I would guess they used ipsctl to allow them to hold values from several different hardware types in a common format. It removes the drivers from the higher level scripts.
Anyway it doesn't really matter because we don't have access to the source code for whatever drivers Nokia did use. I suggest we proceed on the basis that the LEDs are likely controlled by the ICH.
Steve
-
Agreed. I'll take a look at the bottom of the board a little later, but I would think the SuperIO would have been front-facing.
How would we proceed assuming that the LEDs are driven by the ICH?
-
Alright, I took a look at the bottom of the board - Here's a picture:
I don't think there's anything of interest here, so I agree the LEDs are probably controlled by the ICH.
-
The file 'VERSION' in the root directory of the IPSO image shows the other models that the image can be used on:```
os IPSO
number 1
time 225515
date 04.14.2010
user releng
host bsd61.nes.checkpoint.com
type tagged
release 6.2
subrelease GA039
products IP150 IP282 IP290 IP390 IP560 IP690 IP1280 IP2450I think you are right about the Alterra chip driving the diagnostic 2-digit LED chip during the boot process. You are also right about the cardbus controller; it seems to be the TI PCI-1520 chip. The two small chips, U22 and U21 near the 9-pin headers, are UARTs I believe. The chips on the daughter card are simply drivers for the LEDs (transistors Q1-Q7 and hex driver 7407). I'm not sure what are the two similar sized chips between PMC Slot 2 and the ribbon cable, U69 and U23. What is the chip under the ribbon cable, sitting between U23 and the PCI-1520 chip? In any case, I agree it's looking like the LEDs are driven by the ICH. -
Yep, nothing of note on the bottom of the board.
So toggling the the GPIO pins of the ICH is simply a matter of writing a 1 or 0 to the correct register. The registers are mapped to I/O space so it's really a matter of finding where to write 1. ;)
The ICH has a number of GPIO pins I forget exactly I have the data sheet but it's, say, 32. Most of those are dual purpose pins, they can be used as something else, and to use them as GPIO they need to be configured as such. That is done in another register so by reading that we can see which pins are configured as GPIO thus eliminating any that aren't. This assumes the bios has correctly configured the ICH registers initially. We can rule out further pins because they also need to configured as either IN or OUT via another register. We are only interested in pins configured as GPIO and as OUT. In the Watchguard boxes that left around 8 possibilities so easy enough to check.
The various registers addresses are known, given in the datasheet, but they are referenced to the GPIO base address. This is has a common address but can be changed and was in one Watchguard box.My home box here has the same ICH chip is yours so:
[2.1.5-RELEASE][root@pfsense.fire.box]/conf(12): pciconf -l | grep isa isab0@pci0:0:31:0: class=0x060100 card=0x00000000 chip=0x25a18086 rev=0x02 hdr=0x00If your result is the same then you can find the GPIO base address by reading the PCI device config for it:
[2.1.5-RELEASE][root@pfsense.fire.box]/conf(14): pciconf -r pci0:0:31:0: 0x58 00000481The data sheet dictates where in the PCI config data the GPIO address is found, 0x58, and that the final bit in the sequence is hardwired as 1 so the actual base address here is 0x0480.
Steve
-
Hmm
U23 is a Texas Instruments MAX211C RS232 tranceiver. U26 is a Texas Instruments TPS2226A, a PCMCIA Power protection, distribution and monitoring chip.The one under the ribbon cable, U24 is another MAX211C.
Alright, I ran those commands, here's the output:
Appears to be exactly identical to your chip Steve, which I can imagine is quite useful! So the GPIO address for this chip is 0x0480, and how do we proceed?
-
Yep, useful. :)
Ok so the 6300ESB has 32 GPIO pins but it also has some additional outputs which are specially for driving LEDs, they have higher current capability. In the Watchguard X6000 I have here it is these that drive the front LED. However since the IP390 has transistors to drive the LEDs separately it's probably using the standard GPIOs.
So we need to read the ICH registers to determine how the GPIO pins are configured. Download the readio program from here:
https://sites.google.com/site/pfsensefirebox/home/readio
I'm still pretty sure there's a built in utility that does this but I haven't found it. ::)
Change the permissions on the file to 755 so it can be run.The actual values we are looking for are single bits but they're read from the ICH registers as 8bits and given in hex. The first group of registers to look at show which pins are configured as GPIO. They are at addreses 0x480 to 0x483. So:
[2.1.5-RELEASE][root@pfsense.fire.box]/conf(15): ./readio 0x480 Reading 480 :0 [2.1.5-RELEASE][root@pfsense.fire.box]/conf(16): ./readio 0x481 Reading 481 :31 [2.1.5-RELEASE][root@pfsense.fire.box]/conf(17): ./readio 0x482 Reading 482 :a0 [2.1.5-RELEASE][root@pfsense.fire.box]/conf(18): ./readio 0x483 Reading 483 :1b0x480 is the least significant bit so the registers for my box read:
1ba03100
Now convert that to binary to see the individual bits/pins:
0001 1011 1010 0000 0011 0001 0000 0000Now do the same thing for addresses 0x484-0x487 to see which GPIOs are set to out (0).
Also get the datasheet so you can check what I'm telling you isn't completely wrong!
http://www.intel.co.uk/content/dam/doc/datasheet/6300esb-io-controller-hub-datasheet.pdf
Edit: Page 425. ;)Steve
-
Alright, thanks.
… However, I don't know how to get the program into the system! I've downloaded it here on my windows machine, but, alas, Windows doesn't even have a clue about the FFS filesystem.
How can I get the raw file I have here into pfSense?
-
Do it directly on the pfSense box:
[2.1.5-RELEASE][root@pfsense.fire.box]/conf(19): cd /tmp [2.1.5-RELEASE][root@pfsense.fire.box]/tmp(20): fetch https://sites.google.com/site/pfsensefirebox/home/readio readio 100% of 6207 B 4138 kBps [2.1.5-RELEASE][root@pfsense.fire.box]/tmp(21): chmod 0755 readio [2.1.5-RELEASE][root@pfsense.fire.box]/tmp(22): ./readio 0x480 Reading 480 :0/tmp is always read-write even in nano so that's easier but does get wiped at reboot.
Since it's such a small program I put it in /conf but that means mounting the filesystem RW first:
https://doc.pfsense.org/index.php/Remount_embedded_filesystem_as_read-write
There's also an option in Diagnostics: NanoBSD: to do it.You can also upload (or download) stuff to the pfSense box using WinSCP from Windows.
Steve
-
Alright, I ran readio from 0x480 to 0x487, here's the results:
As we can see, 0x486 is set to 0. What next?
-
Ok so we have selected GPIOs:
1bbc3180
0001 1011 1011 1100 0011 0001 1000 0000Selected as output:
1000ffff
0001 0000 0000 0000 1111 1111 1111 1111So things we are intersted in are:
–-- x-xx x-xx xx-- ---- ---- ---- ----Something to note though is that the default values for the GPIO select registers are 1b003100 thus there are 5 pins that have been set as GPIO when by default they are not. ;)
So lets read what the current values are at addresses 0x48e and 0x48f which correspond to the pins set as output.Steve
-
Alright, here's the results for 0x48e and 0x48f.
-
Ok, so:
1b3f
0001 1011 0011 1111
Comparing with bits that might be what we're looking for:
0000 1011 1011 1100That still leaves us with 7 possible bits/GPIOs. My money is on bit 21 since that is changes both select type and value from defaults.
So lets try changing it. Download and change the permissions on writeio from the same location.
We want to change 0x48e from 0011 1111 to 0001 1111 so:./writeio 0x48e 0x1fBare in mind that if this isn't the LED it may do something unexpected, like reboot the box if it happens to be connected to the reset button! On all 4 Watchguard boxes I played with nothing unexpected happened. Mostly just nothing happened! ;)
If nothing happens change 0x48e back to 0x3f and try one of the other bits.
Steve
-
Alright, so I tried writeio on 0x48e from 0x1f through 0x9f – Nothing happened, none of the LEDs turned on or off. All part of trial and error I guess!
Anyway, what next?
-
Try reading back the register you set to make sure it's actually setting correctly.
If you tried 1f-9f then that will have tried all 3 bits on that register. There are two bits on the lower half of the byte. You can try both at once by doing:
./writeio 0x48e 0x33If that does nothing then we can look at the bits in 0x48f.
Steve
