[coreboot] hudson BAR troubles

[Martin Roth]

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.
>
> 1) 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).

>
> 2) 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.

>
> 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 ;)
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
>