Pfsense, Watchguard Firebox II and the LED Panel on the Front
-
/*
This code was mainly created to operate parallel port bits with keyboard in
OpenBSD 4.0 to control whatever experimental electronics projects
attached there. Software was created between February and March 2007.After getting a PC-based router called Watchguard Firebox II,
and seeing a website (where FreeBSD-based M0n0wall router software
was installed on the Firebox) mentioned that the front panel LEDs are
connected to the parallel port, and as there were no support for the LEDs
at the time being, I started to think maybe I should do something about it.( The website : http://www.ls-net.com/m0n0wall-watchguard/ )
First problem was that I had already installed OpenBSD on Firebox,
and since there was no display adapter attached the easiest way to
write software was to connect to the box through ethernet, so the port
fiddling had to be done on OpenBSD. I had no idea how to operate
the ports in OpenBSD. I could have used Linux or DOS for that too,
but as installing the operating system to Firebox is not exactly
something you want to do several times a week after getting it running,
the ports needed to be used in OpenBSD.I found a Sourceforge project called lcdproc (I think) , which supported
many LCD and VFD displays connected to the parallel port in multiple
operating systems. I used copy and paste on the OpenBSD port opening
and accessing routines, so the lcdproc shall get full credit for these.( lcdproc website : http://lcdproc.org/ )
First the parallel port was first fed with purely random values to get
any signs of life. And what do you know, the LEDs became alive!Then the parallel port bits were operated manually to figure out some of
the details. The results presented here are purely based on the LED output
only, so there might be some important bits that do something, but I doubt it.I take no responsibility if something goes wrong, but I did not get
any smoke out.I am also not aware that using the LEDs violate any patents or something.
I hope someone will write a decent LED driver for *BSD and Linux systems,
so that someone could actually gather the network anc CPU usage data with
a daemon and present it with the LEDs. Personally I'd like to see the arrows
flowing from interface to another when a packet goes through the ethernet
ports. The LEDs should not need to be updated more than 10 times per
second for a nice blinking effect.Because of the lcdproc code, I think this code should be under the GPL licence.
If the GPL licence should be here, then please insert it.- Jani Laaksonen, 2008
*/
#include <sys types.h="">#include <machine pio.h="">#include <machine sysarch.h="">//#include <iostream>//using namespace std;
/*
lcdproc code starts here
*/
/* Read a byte from port */
static inline int port_in (unsigned short port) {
return inb(port);
}/* Write a byte 'val' to port */
static inline void port_out (unsigned short port, unsigned char val) {
outb(port, val);
}static inline void setaccess(u_long * map, u_int bit, int allow) {
u_int word;
u_int shift;
u_long mask;word = bit / 32;
shift = bit - (word * 32);mask = 0x000000001 << shift;
if (allow)
map[word] &= ~mask;
else
map[word] |= mask;
}/* Get access to a specific port */
static inline int port_access (unsigned short port) {
u_long iomap[32];if (i386_get_ioperm(iomap) == -1) return -1;
setaccess(iomap, port , 1);
if (i386_set_ioperm(iomap) == -1) return -1;
return 0;
}/* Close access to a specific port */
static inline int port_deny (unsigned short port) {
u_long iomap[32];if (i386_get_ioperm(iomap) == -1) return -1;
setaccess(iomap, port, 0);
if (i386_set_ioperm(iomap) == -1) return -1;
return 0;
}/* Get access to multiple ports at once */
static inline int port_access_multiple (unsigned short port, unsigned short count) {
u_long iomap[32];
unsigned short i;if (i386_get_ioperm(iomap) == -1) return -1;
for (i=0; i <count; i++)="" {<br="">setaccess(iomap, port + i, 1);
}if (i386_set_ioperm(iomap) == -1) return -1;
return 0;
}/* Close access to multiple ports at once */
static inline int port_deny_multiple (unsigned short port, unsigned short count) {
u_long iomap[32];
unsigned short i;if (i386_get_ioperm(iomap) == -1) return -1;
for (i=0; i <count; i++)="" {<br="">setaccess(iomap, port + i, 0);
}if (i386_set_ioperm(iomap) == -1) return -1;
return 0;
}/*
lcdproc code stops here
*/
/*
the following function was the first main loop.
it can be used to write random values to data and control ports,
and read the current port values.
*/void prosessoi1(void)
{
int jatkuu=1;
char merkki=' ';
int arvo=0;
printf("open ok\n");while (jatkuu)
{// scanf( "%c",&merkki);
merkki=getchar();if (merkki=='1')
{
arvo=port_in(0x378);
printf("%d\n",arvo);
}
else
if (merkki=='2')
{
arvo=port_in(0x379);
printf("%d\n",arvo);}else if (merkki=='3')
{
arvo=port_in(0x37a);
printf("%d\n",arvo);}
else if (merkki=='4')
{
port_out(0x378, rand() );
}
else if (merkki=='5')
{
port_out(0x379, rand() );
}
else if (merkki=='6')
{
port_out(0x37a, rand() );
}else
if (merkki=='q')
{
jatkuu=0;
}
else
printf(".\n");
}
}/*
global variables used to keep a shadow copy of what is written to ports.
this way if we need to modify something, we don't have to read the port.*/
int d=0;
int c=0;/*
following function updates the port values from variables.
some control port bits are inverted in hardware, hence the xor.
*/void updateports(void)
{
port_out(0x378, d);
port_out(0x37a, c^0x0b);}
/*
function to toggle (xor) a single bit in the data port.
the port is updated and the value is also printed on screen.
*/void toggledbit( int bit)
{
d ^= (1<<bit);<br> updateports();
printf ("data %d\n", d);
}/*
function to toggle (xor) a single bit in the control port.
the port is updated and the value is also printed on screen.
*/void togglecbit( int bit)
{
c ^= (1<<bit);<br> updateports();
printf ("ctrl %d\n", c);
}/*
this function generates random data and control values,
updates them to the port and writes the values.
*/void randcdbit( void )
{
d = rand();
c = rand();
updateports();
printf ("data %d\n", d);
printf ("ctrl %d\n", c);
}/*
this function resets all data and control values to zero.
all data and control pins should be logic 0 (0v)
as hardware inversion is taken into account.
*/void zerobit( void )
{
d = 0;
c = 0;
updateports();
printf ("data %d\n", d);
printf ("ctrl %d\n", c);
}/*
this function reads back the current data, status and control port values
and prtints them.
*/void status( void)
{
int rd = 0;
int rs = 0;
int rc = 0;
updateports();
rd=port_in(0x378);
rs=port_in(0x379);
rc=port_in(0x37a);
printf ("data out %d\n", d);
printf ("ctrl out %d\n", c);
printf ("data in %d\n", rd);
printf ("stat in %d\n", rs);
printf ("ctrl in %d\n", rc);
}/*
mainloop for second experiment.
function to toggle single bit at a time from keyboard. output is updated immediately.*/
void prosessoi2(void)
{
char merkki=' ';
int jatkuu=1;while (jatkuu)
{merkki=getchar();
switch (merkki)
{
case '1' : toggledbit(0);
break;
case '2' : toggledbit(1);
break;
case '3' : toggledbit(2);
break;
case '4' : toggledbit(3);
break;
case '5' : toggledbit(4);
break;
case '6' : toggledbit(5);
break;
case '7' : toggledbit(6);
break;
case '8' : toggledbit(7);
break;case 'q' : togglecbit(0);
break;
case 'w' : togglecbit(1);
break;
case 'e' : togglecbit(2);
break;
case 'r' : togglecbit(3);
break;
case 't' : togglecbit(4);
break;
case 'y' : togglecbit(5);
break;case 'a' : randcdbit();
break;case 'z' : zerobit();
break;case 's' : status();
break;case 'x' :
jatkuu=0;
break;}
}}
/*
LED names are mapped to a number in this enum.
note that there are at least two more LEDs behind the front panel.
they might be the reserved_1 and _2.*/
enum lednumber {
LED_DISARM = 0,
LED_ARMED,
LED_SYS_A,
LED_SYS_B,
LED_RESERVED_1,
LED_RESERVED_2,
LED_GLOBAL_ENABLE = 6,
LED_RESERVED_3,LED_LOAD_0,
LED_LOAD_1,
LED_LOAD_2,
LED_LOAD_3,
LED_LOAD_4,
LED_LOAD_5,
LED_LOAD_6,
LED_LOAD_7,LED_TRAFFIC_0,
LED_TRAFFIC_1,
LED_TRAFFIC_2,
LED_TRAFFIC_3,
LED_TRAFFIC_4,
LED_TRAFFIC_5,
LED_TRAFFIC_6,
LED_TRAFFIC_7,LED_FROM_TRUSTED_TO_EXTERNAL_1,
LED_FROM_TRUSTED_TO_EXTERNAL_2,
LED_FROM_OPTIONAL_TO_EXTERNAL_1,
LED_FROM_OPTIONAL_TO_EXTERNAL_2,
LED_EXTERNAL,
LED_TRUSTED,
LED_OPTIONAL,
LED_RESERVED_4,LED_FROM_EXTERNAL_TO_TRUSTED_1,
LED_FROM_EXTERNAL_TO_TRUSTED_2,
LED_FROM_OPTIONAL_TO_TRUSTED_1,
LED_FROM_OPTIONAL_TO_TRUSTED_2,
LED_FROM_TRUSTED_TO_OPTIONAL_1,
LED_FROM_TRUSTED_TO_OPTIONAL_2,
LED_FROM_EXTERNAL_TO_OPTIONAL_1,
LED_FROM_EXTERNAL_TO_OPTIONAL_2,};
/*
array to keep LED states for 40 leds.
*/uint8_t ledarray[5] = {0,0,0,0,0};
/*
function to set a value to control port, hardware inversion taken into account
*/void set_logical_control(int ctrl)
{
port_out(0x37a, ctrl^0x0b);
}/*
function to set a value to data port.
*/
void set_logical_data(int ctrl)
{
port_out(0x378, ctrl);
}/*
function to set LED values to data port. logic 0 lights leds and logic 1 turns off.
*/
void set_led_data(int ctrl)
{
port_out(0x378, ctrl^0xff);
}/*
the following function updates all the 40 leds from the LED array.
*/void update_all(void)
{
set_logical_control(0x00);set_led_data(ledarray[0]);
set_logical_control(0x02);
set_logical_control(0x03);
set_logical_control(0x02);set_led_data(ledarray[1]);
set_logical_control(0x00);
set_logical_control(0x01);
set_logical_control(0x00);set_led_data(ledarray[2]);
set_logical_control(0x08);
set_logical_control(0x09);
set_logical_control(0x08);set_led_data(ledarray[3]);
set_logical_control(0x0c);
set_logical_control(0x0d);
set_logical_control(0x0c);set_led_data(ledarray[4]);
set_logical_control(0x04);
set_logical_control(0x05);
set_logical_control(0x04);set_logical_control(0x00);
set_logical_data(0x00);}
/*
function to set an individual LED on. input is the enum number.
*/void led_on(int number)
{
if (number<40)
{
ledarray[(number>>3)] |= (1<<(number&0x07));
update_all();
}
}/*
function to set an individual LED off. input is the enum number.
*/void led_off(int number)
{
if (number<40)
{
ledarray[(number>>3)] &=~ (1<<(number&0x07));
update_all();
}
}/*
following two function set global LED enable.
it is inverted so that logic 0 turns the display on and logic 1 turns the display off.
*/void led_global_on(void)
{
led_off(LED_GLOBAL_ENABLE);
}void led_global_off(void)
{
led_on(LED_GLOBAL_ENABLE);
}/*
function to initialize LED array and front panel.
all LEDs are turned off.
*/
void init(void)
{
ledarray[0]=0;
ledarray[1]=0;
ledarray[2]=0;
ledarray[3]=0;
ledarray[4]=0;update_all();
}/*
main loop experiment 3
code walks throuhg one led at a time, turning it on and off.
*/void prosessoi3(void)
{init();
led_global_on();uint16_t led = 0;
while(1)
{
led_on(led);
led_global_on();
usleep(200000);
led_off(led);
led_global_on();
usleep(200000);
led++;if (led==40) led=0;
}
}/*
function to light the "ARMED" LED.
I used this in the startup script to indicate the OpenBSD box booted.
*/void light_armed(void)
{
init();
led_global_on();
led_on(LED_ARMED);
}/*
function to light the "DISARM" LED.
I used this in the shutdown script to indicate
the OpenBSD box can be powered off
*/void light_disarm(void)
{
init();
led_global_on();
led_on(LED_DISARM);
}/*
main function to call the disarm lighting function.
*/int main(void)
{
int retval = 0;retval = port_access_multiple(0x378,3);
if (retval==0)
{
//printf("open ok\n");//prosessoi3();
//light_armed();
light_disarm();retval = port_deny_multiple(0x378,3);
if (retval==0)
{
//printf("close ok\n");
}
else
{
//printf("close fail\n");
}
}
else
{
//printf("open fail\n");
}return 0;
}/*
Documentation written during experimentation.
Ugly and might contain some errors.*/
/*
bit 7 unused
bit 6 unused
bit 5 data port direction, 1=input, 0=output
bit 4 ack irq enable, 1=enable, 0=disable
bit 3 SelectIn, 1=low, 0=high, pin 17 r
bit 2 Init, 0=low, 1=high, pin 16 e
bit 1 LineFeed, 1=low, 0=high, pin 14 w
bit 0 Strobe, 1=low, 0=high, pin 1 q0123 -> 0123
0 0000 -> 1101
2 0100 -> 1001 traffic
0 0000 -> 11010123 -> 0123
2 0100 -> 1001
3 1100 -> 0001 traffic
2 0100 -> 10010123 -> 0123
4 0010 -> 1111 upper triangle
6 0110 -> 1011
4 0010 -> 11110123 -> 0123
8 0001 -> 1100
a 0101 -> 1000 lower triangle and load
8 0001 -> 11000123 -> 0123
c 0011 -> 1110
e 0111 -> 1010 lower triangle
c 0011 -> 11100123 -> 0123
0 0000 -> 1101
8 0001 -> 1100 status & enable
0 0000 -> 11010123 -> 0123
b 1101 -> 0000
a 0101 -> 1000 load
b 1101 -> 00000123 -> 0123
4 0010 -> 1111data 0, ctrl 0->2, traffic kaikki syttyy
data 255, ctrl 0->2, traffic kaikki sammuuTRAFFIC, CTRL 0->2 (w)
BIT 7, reddest, 0=ON, 1=off
BIT 6, 0=ON, 1=off
BIT 5, 0=ON, 1=off
BIT 4, 0=ON, 1=off
BIT 3, 0=ON, 1=off
BIT 2, 0=ON, 1=off
BIT 1, greenest, 0=ON, 1=offTRAFFIC 0->2->0
o d7
o d6
o d5
o d4
o d3
o d2
o d1
o d0o d4 (4->6->4) (d7 unknown???)
d1 o o d3
d0 o o d2
o o
o o
d5 o o o o o o d6o (c->e->c)
o o
o o
0 o o 6
1 o o 7
o o o o o o
3 2 4 5control 0->8->0
bit 7
bit 6 display enable, 1=on, 0=off
bit 5
bit 4
bit 3 SYS B LED, AMBER, 0=on, 1=off
bit 2 SYS A LED, AMBER, 0=on, 1=off
bit 1 ARMED LED, GREEN, 0=on, 1=off
bit 0 DISARM LED, RED, 0=on, 1=offCTRL 0->1 LOAD
CTRL 2->3 STATUS & ENABLE
CTRL 4->5 LOWER TRIANGLE
CTRL 6->7 unused
CTRL 8->9 TRAFFIC
CTRL a->b unused
CTRL c->d UPPER TRIANGLE
CTRL e->f unusedctrl d0 = strobe (lo->hi = 1->0 )
ctrl d1 = sel0
ctrl d2 = sel1
ctrl d3 = sel2*/
/*
The end!
*/</bit);<br></bit);<br></count;></count;></iostream></machine></machine></sys> -
After a lot of strugling with my two Fireboxes (FBIII-500 and FBIII-1000) I have complete control over the LED panels!
I now have a piece of code from which I can do nearly everything with the LEDs.
It seems to be working under both FreeBSD and OpenBSD.
(OpenBSD with some security restrictions)All I need (to make) now is some code to get the information from the OS and translate it to the LEDs.
Are there any people interested in this?
(and can somebody help me with the last pieces) -
rsw686 wrote some nice code to use the /dev/led devices on WRAP boards here: http://forum.pfsense.org/index.php/topic,3454.0.html
Even a simple program to turn the LEDs on and off would be useful to many. I'm using this program on Alix boxes to basically have an led light when the box is 'armed'. http://forum.m0n0.ch/index.php/topic,2210.0.html
I'm interested in what you've got running on them. I've got a FB III-700 and I've tried 6.3, 7.1, and an 8.0 snapshot unsuccessfully. After reading your post on the m0n0 board, I guess I'll have to try 6.4 and 7.2 now. -
Sorry, but controlling the LEDs on the firebox looks totally different.
Afaik, there's no way of sending anything to the firebox leds without using a programming language.
Perhaps if anyone is smart enough to re-code my source to a device driver that acts as /dev/led or something like that, but I don't think thats a good way of controlling the firebox LEDs. What I have is code written in C, that opens control to specific hardware ports and then writes codes to the ports to control the LEDs. Although part of these ports are like the parallelport, it's not possible to handle it as a parallelport (like /dev/lp..) because it involves more that just that port and because the bitpatterns that define which LED to light is not very easy (and certainly not like an ASCII table or so).The Firebox LEDs are much more than the LEDs on the WRAP board.
But what do you mean by having tried 6.3 and 7.1?
I believe every version of FreeBSD (and OpenBSD) can run on the Firebox III, as long as you know what to change to th files that control the diskcontroller and the network interfaces. What I mean is that you have to build your own modified kernel from the *BSD sources with some modifications to the .c files before compiling it. -
Just referenced that as a code example. But even something that could run via a shell script could be used for simple things.
I've been trying stock FreeBSD on my firebox. I managed a 4.11 custom kernel to get m0n0 running, but the 4.x ata patch I found did not look easily transferable to 6.x or 7.x. I've just been periodically re-testing with new versions to see if some other ata related changes would fix the lockup when initializing the onboard flash. -
Agree, any way to get something from the system "my" the LED panel program will do.
It now compiles to a program that accepts a few parameters through which the LEDs can be controlled.
So I you just want to set something like the ARMED LED during/after booting, it can be done now from a shell script.About the disk controller…
I've been working with two other guys to make the freebsd 4.11 patch work under openbsd 4.4. After a lot of work I discovered that the original 4.11 patch is a bit too much.
In fact, all that was needed (at least for OpenBSD 4.4) was a disable_intr() and enable_intr() around the wdc_output_bytes() call. The ad_vlb_sync() function in the original patch was not needed. We think (but have not tested) that this is also true for freebsd4.11.
A few days ago, I booted a selfmade m0n0wall with FreeBSD 6.4 on my Firebox III without having to modify anything for the diskcontroller.About the network interfaces...
The patch for freebsd 4.11 also works for OpenBSD 4.4 and FreeBSD 6.4.
Since no big changes were made to the if_dc.c file between 4.11 and 6.4, I imagine the patch will also work for other 6.x (and 7.x?) FreeBSD versions.
Under OpenBSD if_dc.c needs the same change as in the freebsd patch.
My Firebox had correct MAC addresses after the patch with FreeBSD 6.4. -
Interesting. A stock 6.4 still hangs at:
ad1: FAILURE - SETFEATURES SET TRANSFER MODE status=51 <ready,dsc,error>error=4 <aborted>ad1: 7 MB < VER4.64> at ata0-slave BIOSPIO</aborted></ready,dsc,error> -
I've seen messages from other people with boxes failing at the 8Mb onboard flash chip.
The FBIII has an 8Mb onboard flash and a 32Mb flashdisk connected to a laptop-ide connector along the side of the motherboard. I haven't has managed to get the 8Mb chip working, you may need to focus on the 32Mb flashdisk (or another CF card with a CF-converter).There are two things you can try:
1. Set both disks to MASTER: there's a jumper with "slave/mstr", set it to mstr (this makes the onboard chip master). Then set your 32Mb flashdisk (or CF card) also to Master. That way, the onboard flashdisk is overruled by the flashdisk/CF and will not be visible anymore.
2. Format the onboard flashdisk: Close the FMT JMPR, turn on the box, wait a while.
Now the onboard flashdisk is empty so BSD won't try to mount it anymore.It this moment I am in the process of rebuilding, so it's going to take a few moments before I can continue testing FreeBSD 6.4 again on my box(es).
-
In addition to my previous message, my freebsd 6.4 bootlog says:
atapci0: <acerlabs m5229="" udma33="" controller="">port 0x1f0-0x1f7,0x3f6,0x170-0x177,0
x376,0xf400-0xf40f irq 15 at device 15.0 on pci0
ata0: <ata 0="" channel="">on atapci0
ata1: <ata 1="" channel="">on atapci0
…
ad0: 61MB <sandisk sdcfb-64="" vdi="" 1.24="">at ata0-master PIO4
Trying to mount root from ufs:/dev/md0
Found configuration on ad0.I use a 64Mb CF card with a CF converter, set to Master.
I have the SLAVE/MSTR jumper set to MSTR and used the FMT once (a while ago).The box seems to boot just fine.
The NICs say:
dc0: <macronix 10="" 98715aec-c="" 100basetx="">port 0xf000-0xf0ff mem 0xc0001000-0xc000
10ff irq 11 at device 16.0 on pci0
miibus0: <mii bus="">on dc0
dcphy0: <intel 21143="" nway="" media="" interface="">on miibus0
dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
dc0: Ethernet address: ff:ff:ff:ff:ff:ffThe ff:ff:ff:ff:ff:ff can be fixed with one small change to the /sys/pci/if_dc.c file (and rebuild the kernel).
With just the old patch, commenting out one line, it now says:
dc0: Ethernet address: 00:90:7f:20:5a:c2So now I'm very curious if your box can boot with only setting the jumpers.
And, ofcourse, I'm still looking for somebody to help me getting the missing parts for the LEDs!</intel></mii></macronix></sandisk></ata></ata></acerlabs>
-
I'm testing with an old laptop HDD. The box hangs on boot if the jumper is set to master and the HDD is set to master or cable select. I have m0n0 1.235 (with a custom kernel) on the flash chip. I just realized that 6.4 will boot in safe mode- it gets the error, but continues instead of hanging.
Back on topic RE: the LEDs- My 700 looks to have the full set of LEDs but the traffic and load bars have an opaque label instead of having clear holes for the LEDs. -
If you look behind the plastic part that 'transfers' the light, you will see that there are no leds on the pcb for the Network- and CPU load. ::)
I think you will have to format the onboard flash so bsd won't hang on scanning it…
Currently I have a brand-new m0n0wall image with freebsd 6.4 and it still boots fine.
As said, I have the jumper set to MSTR and the CF card converter as Master too.Oh, another though just came up:
Before formatting, you could reset the bios to default. It's now configured with fixed parameters for drive0, so if some other disk becomes Master it might not boot properly. After a bios-reset it will be set to some auto-detect.
Bios reset jumper is close to the battery. Box off, jumper to CLR, box on, wait a while, box off, jumper back...To be sure, you might try my fresh freebsd 6.4 mono-image? (almost 7Mb file)
-
If you look behind the plastic part that 'transfers' the light, you will see that there are no leds on the pcb for the Network- and CPU load. ::)
Yeah, you're right. I unscrewed the board and there are no LEDs soldered on. Looks to be missing a couple of chips too.
I did some more testing- while I can get 6.4 to boot in safe mode, 7.2 locks up even in safe mode. Disappointing, as I'd like to get pfSense running on the thing. I may try to isolate what it is about safe mode that is allowing it to boot. I'd guess it's the conservative ATA settings in safe mode. -
I just thought of something else that could cause boot problems.
The BIOS is really old. I've seen it by plugging in a PCI VGA card and connecting a keyboard (yes, the board has a keyboard connector hidden as 4 pins). The BIOS cannot handle "Large" disks. I guess the limit is somewhere around 4Gb or so. You said you use a laptop harddisk, that might be to large for the BIOS.
Don't you have the original flashdisk?About the missing LEDs and chips. Yes, both pcb's (the motherboard and the LED panel) are generic. They saved some money by leaving out some parts. E.g. on the motherboard, the cheaper models (500 and 700) are missing the VPN accelerator and some memory for that chip.
Some boards, either model, have a USB connector (but most don't). But I haven't been able to use that.I'm currently focussing on m0n0wall, since that will fit on the original 32Mb flashdisk.
And also because I've managed to build it with the patches in the kernel. I don't know if I can build my own pfsense.Do you have some webspace or a (large enough) mailaccount where I can send you a working m0n0wall image? The image is roughly 7Mb.
BTW, can you give me a bootlog from the lockup?
-
I've got a ps/2 keyboard connector hacked on to my firebox and use a pci riser card to stick a VGA card in while tinkering. The bios boots fine off an old 12GB laptop drive. I have a drive with 4.11 on it I used while working on getting m0n0wall 1.2 on it. Mine came with the OS loaded on the onboard 8MB flash. I now have m0n0wall there and it works fine. I'd like to get pfSense running on a HDD or flash drive plugged into the IDE connector. I found 6.4 boots (umm, most of the time) with the generic kernel if acpi is disabled. Mine has USB (but I'll have to cut a hole in the case to use it…) I remember it panic'd under 4.11, but I can get an old USB1 network dongle (rue) to be recognized under 6.4. (MB out of the case...)
The log doesn't show anything interesting when it locks. It just stops responding after ad1. I tried fiddling with the bios ide settings without much luck. You should be able to send the file to the email in my profile. -
The image is sent.
You may not see anything in your bootlog about the lockup, but I might see a difference with mine…
Can you send the bootlog to me?
And perhaps also the freebsd image you use (if not to big), so we can see if my box also hangs on it...
