Packaging PCI FCode

The following is an example of testing a new version of an FCode program when the developer creates a new package:

ok 4000 dload /stand/mydev.fcode ok 0 0 " 4,0" " /pci@1f,2000" begin-package ok 4020 1 byte-load ok end-package

However, when performing an ls, it is obvious that there are now two packages corresponding to the card:

ok l ffd70c00 pci108e,1001@4,0 ffd6e860 pci108e,1001@4,0 ok

To override the original package so that the downloaded code is executed, remove the PCI card PROM. The CPU PROM will create a device node for the card, but the name property will have a value of pci<DDDD>,<VVVV>.

Create a name property for your device in your downloaded code with a different value than the one created by the CPU PROM. Then refer to your device by its full device path.

System Flags and FCode Debugging

The following is an example of how to use Sun systems debugging flags to aid in debugging FCode.

Set the NVRAM variable fcode-debug? to true to keep the headers for words that are preceded with headers in your code.

Some CPU PROMS have a fcode-verbose variable to display each FCode as it is being read at probe time by the CPU PROM token interpreter.

To turn it on, before you probe your FCode, type:

ok true to fcode-verbose? <probe-your-card>

To set it from NVRAMRC, type:

ok nvedit 0: true to fcode-verbose? ^C ok nvstore ok setenv use-nvramrc? tru ok reset-all

Some CPU PROMs have pcimsg? and probemsg? variables to give additional PCI-related information. You can turn them on in the way as described in what to do before you probe your FCode. pcimsg? controls the display of all accesses to PCI configuration space. probemsg? controls the display of probing status information, including physical allocation.

Note that not all CPU PROMs have pcimsg? and probemsg?. In future PROMs, this command may not work in the same way or may be eliminated.