Not able to boot from SCSI disk on SYM21002 but all other works

hello,
I'm a newcomer here from germany so please excuse if something is miss-formulated or bad english.

I have an older 21002 with 53C896 on. It is a two channel SCSI hba with 16 bit SCSI (up to 80 Mb/s) and PCI interface. The system it was in was damaged some time ago so the mb is no longer usable. As I got a new mb from some friend I tried out the other parts and the supply was not correctly functioning but the other parts seems to be o.k. With one restriction: as I tried to boot the new system from the SCSI disk (as I done with old system too) it presents only "PRESS ANY KEY TO REBOOT' (all in capitals as here -I want to make it easier to recognize it- and the only seeable on the whole screen) and stops. Pressing any key reboots up to this point ... and all comes again.

I tried with some linux DVD useable as live systems (in germany -I don't know if this is the some in other countries- a lot of illustrated papers concerning computer themes puts into their product a CD or DVD with a lot of software on it. Some of these contains one -or more- complete linux installation packages -with live system included- belonging to different distributions). I can boot them all if I do it from the DVD writer which is IDE. The DVD-ROM (SCSI) isn't bootable as the disks. Most of the tries it is not not-bootable from beginning but it stops and hangs later on. I found out that the hangs came up if the boot image is a floppy emulation. Possibly there is a link. All SCSI devices can be reached from linux; all partitions -linux or windows- can be read. I tried a dd on the whole disks to see if there is any fault on them but it works all fine.

As I looked into the SCSI-HBA-BIOS setup (which I can open normally) I found in the per-device-settings section at the most end in front of the verivy and format commands a column named boot choice which is for selecting the boot drive from the list of disks. Of course this entries have to be changeable to work. If more than one are set to yes the first device in the list would be booted (it is not needed to be zero on Symbios Logic adaptors). If the lower id's are set to no the system can boot even from id 5 if desired. This column on the not-booting 21002 is set to no on the whole list and ... is not changeable.

Since it worked before (but at this time I never looked at this column I must confess) it seems to be a wrong entry in the nv-ram included at all higher (not 810-based; that's a typical not-disk-addon adaptor) adaptors from Symbios Logic.

So the question is how I can delete this entry from nv-ram. As I use linux and there is a lot more possible to do as in windows there is possibly a chance to reach the nv-ram from system. If so how I can do it? And what I would be doing there (deleting, writing, reading all of this possible)? Are there any information out there on the layout of the entries in nv-ram? I'm sure since differnet adaptors have different settings to be changeable that in nv-ram is a list concerning the columns and make them changeable or not. And a list of entries shows the state all of them have. If I could change the state of all devices to yes it would be fine since this feature I never used and I'm sure I would never use in future. If I could change the state of the column to changeable it would be fine too since I then can change the state of the devices to yes by hand.

Don't say 'take another hba' or something like this because of course I now that this is an option (and possibly of course the only one). Please I'm searching for another option so do you have any idea?

LSI (former SymbiosLogic) is no help since there they didn't know the chip number of the chip on this adaptor -it seems like there are a lot of knowings lost at the change to lsi. Of course I have a question concerning this problem sent there but I've got no good advice yet. So I tries here in parallel since I don't want to wait for any solution forever.

For any good idea I will be happy. As I know how to handle the compiler and how to write a C-program it will be helpful too if anyone knows the addresses and so on to read the nv-ram from cpu. I'm sure it will then be possible to write a program to read and write the nv-ram. than the rest will be tests (a lot of them possibly of course) to see which byte (or bit?) controls this feature.

greetings and thanks for all you can answer

manfred
.