Hi, > I'm not sure I understand the P4 register readout - but here's what it is: > `P4 register = 0x4261699584x` That should have been in hex - 0xfe046000. However, I'm puzzled by this. We already identified the CG4 and resolution of 1152x900. So, I would expect that the value starts 0x41 (the top 8 bits are model and resolution if I'm reading pfourreg.h correctly). Video is currently on (obviously!) so I would also expect the that bit to be set. With my guess of interrupts enabled, I was expecting to see something like 0x41000022. So, I must be missing something or we're not actually referencing the correct location in cgfourattach(). > We still panic on the same line (bt->bt_addr[0]): > `cpu0: data fault: pc=0xf00122cc addr=0xfe048000 ser=0x8020<WRITE,TIMEOUT>` I wonder if this is related to the above and we need to check the addresses that we're actually reading/writing. Unfortunately, I'll not have access to my 4/330 for a few weeks, so I'll not be able to run some comparisons on the BW2 that I have there. > No such luck commenting out the cmap lines unfortunately; still just > stray interrupts. Presumably because we weren't able to disable them earlier. It might be possible to get some information from the PROM prompt. Instead of booting, can you try something like the following - guessing because I don't know how the 4/110 PROM behaves - it might be too old for these to work. cd / cd obio cd bwtwo .attributes # this might be .properties cd .. cd cgfour .attributes # this might be .properties You should also be able to use `ls` in case I have the names of some of the device tree wrong. For example, on my SS2, I have a BW2 framebuffer and it appears as "/sbus@1,f8000000/bwtwo@3,0" but I can type "cd /sbus/bwtwo". Regards, Julian --