Pfsense Install on Nokia IP390
-
I'm getting no output on the AUX port under pfSense, and the console port gets to "bootup complete" and won't accept further input. I'll try to ssh to pfSense in a minute.
-
Alright, I managed to get the pfSense shell working through the serial port - There was an option under System > Advanced to enable the serial console.
So I booted into the shell, and ran that ls command:
And the same command under IPSO:
As you can see, IPSO didn't find anything under /dev/led* or /dev/gpio* … Any more ideas? Thanks for helping by the way.
-
That would have been nice but was a pretty long shot, FreeBSD has very few specialist drivers like that.
-
You have two options here (three if you decide it's just not worth the trouble!):
Modify the BIOS to turn off the LED at boot. It's probably one of the settings in the BIOS tables that are fairly easy to spot.
Switch it off after boot using a custom utility.Both of those require knowing where the LED is driven from. Modifying and then flashing the BIOS is inherently risky.
I would certainly be willing to work with you to find the LED if you wish. You can read the posts in the arm/disarm led thread where ifloris and I found the location on the X-core box without me having access to it: https://forum.pfsense.org/index.php?topic=32013.msg171469#msg171469Steve
-
Yeah, I think option 2 would be the best option, given that if I was to flash the BIOS i'd have to go buy a few bits of hardware to get the new bios on the chip, and a couple of BIOS chips so I don't need to overwrite the original.
Should I upload the original IPSO kernel so you can take a look through it?
Also, would the readio and writeio programs work on the IP390 do you think? -
You wouldn't need any additional hardware to flash the bios. You can do it from within pfSense the flashrom utility (available as a FreeBSD package) or boot a DOS image somehow and use AMI's flash utility. Though if you want to keep the original chip you would. The two bios sockets might introduce to extra unknowns. You can extract the existing BIOS to see if it gives us any clues using flashrom relatively risk free.
I'm not sure you've understood quite what the kernel is (I apologise if I'm wrong!). Looking through the IPSO file system for clues would help though. There is probably some script that calls the custom driver to change the LED for example.
The readio and writeio programs will certainly work. They have almost no saftey features that might stop them working!
Steve
-
Hmm. I'd need to find out how that works before I'd do that.
Probably, I believe it to be the base-level system which interacts with the hardware?
Haha, I think then that it's only a question of trying to extract any clues from IPSO and the fun matter of trying to get them into pfSense.
Anyway, I think the next logical step is to give you a copy of IPSO to look through:
https://drive.google.com/folderview?id=0B4fVBOx_qVyRaktqMk9yaHF6UW8&usp=sharingI don't really know where to start looking in the system files, but I did take a look at a few which appear to be FreeBSD config files.
-
I don't really know where to start looking in the system files, but I did take a look at a few which appear to be FreeBSD config files.
Read through the /etc/ledtool and /etc/install_from_rstg scripts; unfortunately /etc/ledtool contains this:```
This doesn't manipulate the LEDs directly. Instead, it uses 'ipsctl' to
tell the IPSO kernel about a condition, and the IPSO kernel will blink
the LEDs appropriately for that condition.
-
Hmm. That does complicate things, however, that DOES give us the script which controls the LEDs. According to Stephenw10's method of getting the LEDs working, as long as we know where the I/O for the LEDs are we should be able to modify the ledtool script to print directly to the LED panel. But, as I feared, the script currently sends the LED commands to the kernel, so we need to find the IDs of the front panel LEDs before any progress can be made.
Also, the file appears to reference /bin/ipsctl often, I'm thinking that's where we might find our I/O controller. However, I tried to open ipsctl, and it needs decrypting / unpacking, as it's not in any kind of readable format.
-
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?
