I ran into strange problem that flashrom was looping forever in the chip probe.
I have the Hudson D3 here:
00:14.0 SMBus: Advanced Micro Devices [AMD] Hudson SMBus Controller (rev 14) 00:14.2 Audio device: Advanced Micro Devices [AMD] Hudson Azalia Controller (rev 01) 00:14.3 ISA bridge: Advanced Micro Devices [AMD] Hudson LPC Bridge (rev 11) 00:14.4 PCI bridge: Advanced Micro Devices [AMD] Hudson PCI Bridge (rev 40) 00:14.5 USB controller: Advanced Micro Devices [AMD] Hudson USB OHCI Controller (rev 11) 00:14.7 SD Host controller: Advanced Micro Devices [AMD] Hudson SD Flash Controller
The problem I was seeing is that 14.3 SPI BAR has the SAME address as 14.7 SD controller.
Also, there is some special code in hudson.c to protect the SPI BAR from changing otherwise IMC firmware dies.
1) workaround for IMC does not work for me, it gets new address from coreboot resource management.
Martin, please can you check?
2) even if SD controller 14.7 is "off" in devicetree, the PCI device exists
I noticed that hudson enable() is empty...
3) because 1) does not work, the newly allocated BAR by coreboot 0xf014fa00 is used for SPI, and because linux is super smart, it figures out first free PCI resource and this is also 0xf014fa00!!!
[ 0.215751] pci 0000:00:14.7: >BAR 0: assigned [mem 0xf014fa00-0xf014faff 64bit]
And last pitty point is that SD wins over SPI controller ;)
My questions are mostly 1) and 2) any clue about that? The 3) was just FYI if you ran ever into same problem. I will do a patch to the f2a85x to "on" 14.7 in devicetree. This allocates the BAR in coreboot and everything is fine again.