Pfsense Install on Nokia IP390
-
The proximity to the ICH chip (6300esb) would have me guessing it's controlled by one of the GPIO pins on that. That was where I found the control on the earlier firebox models. The only issue is that I don't think the 6300 had a flashing mode. :-\ There are lot of components on that daughter board considering it's only got 3 leds on it. Flashing could be done there.
Steve
-
Hmm. The daughter board actually governs 4 LEDs, as, from left to right, you have: System activity indicator (green), System warning (Yellow !), System On/Off (Nokia logo, illumunated blue) and the system fault indicator (Red X ). I've worked out that 5 of the LEDs on the daughter board govern the system On/Off light alone.
Here's a picture of the daughter board taken off:
There's a few chips on here, any ideas? My initial thoughts were that they were voltage regulators, but I'm pretty sure the System fault indicator is ran from the BIOS, which might explain the chip on the top right of the board. That would also explain why the fault indicator is working properly.
-
I agree there's probably some voltage or current regulation. The outputs from the ICH are probably not capable of sinking enough current to drive the LEDs directly so instead there are transistors for each LED (Q1, Q2 etc) and a line driver/buffer (the 7407 IC). The other large device, labelled 10-16L, is a capacitor perhaps to filter switching spikes. I like that there's a mystery space for an LED, CR9, that Nokia decided not to use for whatever reason. :)
Do the 4 LEDs come on as soon as you power on the box? Do they vary at all during boot?
The BIOS setup in embedded hardware like these boxes is often available on the serial console via 'console redirection'. It's usually at a baud rate of 115200bps. To access it you often have to press TAB because you can't send DEL over serial. Interestingly it looks like that box has two BIOS ROM chips.
Edit: Maybe on the other serial port, AUX, perhaps.
Steve
-
You're correct. The board has support for 2 BIOS chips, but only the right one is populated with a BIOS chip. According to the stickers on the MB, the BIOS is an American Megatrends AMI BIOS 786Q.
As for accessing the BIOS, I'll give that baud rate a try tomorrow. How will I know when I'm in the BIOS? Will it print text like the normal 9600 baud rate does?
I believe that the LED for CR9 Might be for and LED for the IP560. I don't exactly know what that LED would be, but I would imagine that Nokia use the same status LED boards across most of their IP series products to save money.
-
Searching for info on the IP390 there are a number of people who have posted IPSO boot logs and it includes the memory count. That is before the bootloader so it's coming from the BIOS. It's in the same log at the same baud rate so I would suggest whatever baud rate IPSO uses should be good for accessing the BIOS setup. If you're seeing the memory count you're probably good, try pressing TAB. Of course Nokia could have it all shut down deliberately to stop access but they haven't forced only signed boot images for instance.
Steve
-
Just for reference the IP530 uses the SuperIO chip to control those LEDs:
http://www.coreboot.org/Board:nokia/ip530#Front_LEDs
Does not mean the IP390 does though. ;)Steve
-
Alright, I just managed to get into the BIOS by pressing tab after the memory test had completed.
It came up with a message:American Megatrends AMBIOS (version #) Press ~~ to enter setup.~~It wouldn't allow me to enter text on that screen.
Here's pictures of the BIOS:
http://s26.postimg.org/j5bb13bi1/bios1.png
http://s26.postimg.org/mq76kbg1l/bios2.png
Here's inside the SuperIO menu:
http://s26.postimg.org/j7v6nxf5l/bios2_5.png
http://s26.postimg.org/fpj6rje9l/bios3.png
http://s26.postimg.org/41p4wzp4p/bios4.png
http://s26.postimg.org/cl8iuqxh5/bios5.png
http://s26.postimg.org/f3u7vfj7d/bios6.pngThat's all of it. There doesn't appear to be any options for the status LEDs on the front panel.. Any ideas?
Sidenote: I should have said the IP690, not IP530. The IP690 is the model up from the 390.
-
It was worth looking, only one of the Watchguard boxes had a custom bios menu for the led. If it is connected to the ICH it's worth looking in the southbridge setup menu.
I assume that the yellow warning led comes on as soon as you power up the box and then just stays on?Steve
-
Here's a picture of the southbridge menu:
Yeah. On boot the only LED which does not switch on is the System fault. All the other LEDs, System activity (Is meant to be on), System warning (Should not be on) And System Power (Should be on) Are all on.
-
Any chance something shows up as /dev/led* or /dev/gpio*? If one or both show up under IPSO, but not pfSense, that could be a big clue.
-
Hmm. I see what you're getting at, but how can I check if /dev/led* or /dev/gpio* show up under IPSO? What command should I enter?
-
Hmm. I see what you're getting at, but how can I check if /dev/led* or /dev/gpio* show up under IPSO? What command should I enter?
Do you get a shell prompt on the serial console with IPSO? If not, try the AUX port, which is set up for remote management via modem. Or try to ssh into the unit.
For pfSense, you can use the shell on the serial console, or ssh in to the unit. Choose '8' from the menu, then use 'ls' command:
*** Welcome to pfSense 2.2-ALPHA-pfSense (amd64) on pfsense *** WAN (wan) -> bge1 -> v4/DHCP4: xx.yyy.zzz.12/20 LAN (lan) -> bge0 -> v4: 192.168.2.128/24 OPT1 (opt1) -> bge1_vlan2 -> v4: 192.168.100.5/32 0) Logout (SSH only) 8) Shell 1) Assign Interfaces 9) pfTop 2) Set interface(s) IP address 10) Filter Logs 3) Reset webConfigurator password 11) Restart webConfigurator 4) Reset to factory defaults 12) pfSense Developer Shell 5) Reboot system 13) Upgrade from console 6) Halt system 14) Disable Secure Shell (sshd) 7) Ping host 15) Restore recent configuration Enter an option: [2.2-ALPHA][root@pfsense.localdomain]/var/log(1): ls -l /dev/gpio* /dev/led* ls: No match.The ls command would be the same in either IPSO or pf Sense.
-
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.
