Thanks for the reply. It is now very clear. Sorry if some of above/below is clear to others - I did mention I was new to BlackICE. After review of schematics, layout, consideration of how the components are user and interact I am now very clear on how it all works. It is now so clear I am almost embarrassed I had to raise the queries!
I was considering things from the wrong perspective. I had been focused on digital1,2,3 and analog as the Arduino connectors and was trying to map from the pinout of the connector back to the mapping in the Arduino support in the STM32. This was looking at things the wrong way round. The Arduino mapping and support focused on mapping the STM32 pins to connectors and facilities on the BlackICE board.
The compatibility of the Arduino is simply a design of how the connectors were mapped to the STM32 to allow the original 28 pin Arduino shield to correspond allowing possible use of Arduino shields. The additional 8 pins on the connector have no correlation with Arduino or shields. All other IO from the STM connects to other devices, connectors etc. and is mapped into the Arduino digitalWrite mapping simply to allow use from the Arduino libraries when the STM32 is used as an Arduino target. A similar situation happens with the Mega and Due which also use pins beyond the digital pins capable on the Uno.
I have checked and see there is indeed no MUX connection to the PI. This is also clear now I fully understand the design behind the BlackICE - the STM32 is the board master, controls boot, loading of the FPGA, associated peripherals etc. I have been reviewing the code for iceBoot and can see if I wanted a situation where the PI assumed control it would need to interact with a minimal loader on the STM32 to ensure the MUX is configured and the STM32 does not attempt to do this.
Some quick consideration of the boot code suggests a modification I may attempt is much like the boot detect to look for a valid bitstream in the flash. In addition to a check to see if there is a valid bitstream it is also possible to have a system almost like a bus request where the PI presence can be detected and the PI can assert on boot that it wishes to have control over resources then the iceBoot can decide if it should load a bitstream, release the control to the PI or wait for a file over the USB.
All very clear now and I do appreciate your time and patience to resolve the issues. I will now push on and document all of my thoughts then move to create a modified boot and place the PI development system on board. I will certainly report back in due course and would not rule out further queries!
BTW I am really enjoying the BlackICE. Very powerful and a clever design. Much like computers of old it is complex enough to present challenge and potential yet simple enough to be able to understand every aspect of the hardware and software. Combined with iceStorm and a Linux development system it really is my ideal FPGA/hardware experimenter/learning/fun device. Thanks to everyone!