On 05/01/2013 02:25 PM, Rudolf Marek wrote:
Hi all,
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.
- workaround for IMC does not work for me, it gets new address from
coreboot resource management.
Martin, please can you check?
Hi Rudolph, I do not think the IMC workaround does what you think it does.... It isn't meant to prevent the address from changing. The main reason this workaround is needed is that this bar (naturally) doesn't actually follow the PCI spec. Bit 1 isn't to enable memory - it's to enable the spy controller itself. The reason for the workaround was that when the device memory was getting changed, it was also getting disabled. When it got disabled at this point, for whatever reason the IMC rom would crash and stop running (I actually later tried this method of killing off the IMC, but it seems to be timing dependent - I couldn't kill it with this method after booting).
- even if SD controller 14.7 is "off" in devicetree, the PCI device
exists. I noticed that hudson enable() is empty...
yeah, there's no code in the hudson directory to do ANYTHING with the SD device right now. I did some work on that this past weekend - I'll try to wrap it up and push it this weekend. Each component gets its own enable() function. I liked the way that SB800 was done, but when the southbridge wrapper was re-architected from cimx to agesa, this structure was changed... whatever, either way works.
- 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 ;)
I think I see the bug in my change that's causing this. I think the problem is that I adjusted the base address before setting the resources and didn't adjust it back. Because of this there's nothing in the tables at 0xf014fa00 - The code doing the tables thinks the base address is at 0xf014fa02, and this messed SOMETHING up. I'll submit a patch.
I'll pester you on IRC about testing this.
Martin
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.
Thanks Rudolf