[IPCop-devel] BCM5823 Crypto Accelerator.

I am in possession of two Symantec 5420 Firewall appliances that contain an 
Iwill G478 motherboard and in Symantec's case, one of the optional Crypto 
Accelerators, a Broadcom BCM5823 is standard. Iwill themselves made a 
barebones appliance from this board only the Crypto Accelerator was an 
option and you had more choices than just the BCM5823. I believe HiFn was an 
option as well as one other. 

I started a special build tree for this appliance aside from the Cobalt 
stuff and managed to make an LFS that downloads the bcm58xx driver from 
Sourceforge and builds it. It builds two utilities that can read 
/dev/cryptonet, a separate libubsec.so that resides in /usr/lib NOT 
/usr/lib/engines. The driver package comes with a start script that loads 
the driver and makes the device node /dev/cryptonet. This script is copied 
to /etc/rc.d/bcm58xx. I had to do a minor patch to the driver source to make 
it look for the correct kernel otherwise it looks for the build host 
version. 

Beside the typical end user using rc.event.local to start it, what would be 
the logical place to start this script? It IS a service that can be started 
and stopped as most services can be. The other question is, does having this 
operating gain anything?  

Now that I have it building, loading and working, will the system use it? 
SHOULD the system use it if it even can? I thought since it is there I might 
as well build and load something to the bcm5823. It is an out of kernel 
driver as you might have concluded. Nobody pushed very hard for inclusion 
into the newer kernels as it needed updating to cover more than just the 
5820 which was slower. This driver started as an outgrowth of the 2.4 
kernel's bcm5820 driver to not only work with 2.6 and up but to cover newer 
faster chips. 

Here is the output of the two utilities which will only work if the driver 
is loaded and /dev/cryptonet is created as well as it's own 
/usr/lib/libubsec existing. It does not care about the same named library in 
the engines directory. Here we go, sorry about the email truncation:

root@5420:~ # b58stats
bcm58xx stats - (Public Key Ops):
Dv|       IKE|   IKEfail|     DHP|     DHS|    RPub|    RPrv|      DS|      
DV
 1|         1|         0|       1|       0|       0|       0|       0|       
0
  |      0.00|      0.00|    0.00|    0.00|    0.00|    0.00|    0.00|    
0.00
root@5420:~ # b58diag
Card number 0 requested.
1 cards present in the system.
Device type BCM5823 Revision 1. Driver version 2.10
succeeded.

Side Facts: This appliance is a socket 478 and comes with a 2ghz Celeron and 
uses PC2100 ram, has six 82551 Intel Nics built in, has two usb ports which 
support USB2 and one com port. Com2 is used for the 16x2 lcd. It does have 
headers for VGA (standard adapter needs rewiring to work) Parallel and a 
header for led signals for all six nics, only eth0 is wired on this. A PCI 
slot exists on all of them but some appliances would need a slot cut into 
the back to use it. I have one with the cutout and mount already there as a 
facory option. 

I set my build to use the serial port at 115200 out of the box via extlinux 
and inittab. It can easily be installed via Virtual and a slaved USB drive 
and then set up via serial at first. It's a 1U appliance. I would never have 
a monitor attached unless there was something I could do in the bios which 
is doubtful. ACPI works perfectly on this. My motivation is that I need 
something that can use my Solos PCI Quad. The Cobalts work with the Pulsar 
but not with the Solos. There is reportedly an endian swap on the Cobalt PCI 
bus that causes some hardware not to work, eg PCI Wireless nics and the 
Solos. This swap was carried to the 5000 series before Sun Killed Cobalt.    

-- 
Dave Studeman
http://www.raqcop.com