[coreboot] Fam10 FIDVID in SVI : disabling microcode update

Xavi Drudis Ferran xdrudis at tinet.cat
Wed Feb 16 14:45:02 CET 2011


Hello. 

I finally splitted my changes into some 25 small patches (some 8-10 quite trivial refactorings, but I hesitate to use "trivial"  in signing off) .
 I compiled each for my board and tested it , and I hoped to find which of them fixed my fidvid issues. I have to add some commit comments
and I hope to send them tonight or tomorrow evening.

But after applying all of them it still didn't work. So I looked again and discovered in my previous tests I had commented the 
calls to update_microcode(...) . In the test of the smaller patches I had mistakenly commented only the call for the BSP 
but not for the APs. I tried with both calls commented and it works, then I thought, "ok, it must work with both uncommented, 
having diferent microcode versions in different cores is just weird". But with the calls uncommented it won't work (it hangs in 
ram initialization, like without most of the patches, or with microcode updated only in some cores, and then it depends, sometines
it works).

So in order for my board to pass fidvid and ram init I have to disable microcode updating. I haven't tried any new microcode in 
Agesa code submitted this last sunday, because, after all, it does not have source, so for all I care I'll be happier  
if it works without it. 

I guess the reason could be either of: 
- coreboot is applying the wrong microcode version, and some logic selecting the microcode can be fixed
- the version of the microcode itself is faulty, and may be fixed in a later version (maybe already under /vendorcode/...)
- the way to update the microcode does not work in my CPU 

But I don't feel like fixing any.

Yet I don't think I should send a patch just commenting those calls to update_microcode, should I ? 
  
Should I send a patch making a Kconfig option to not upgrade microcode for fam10? Is there any interest in that ? 

Should I just send the patches for fidvid and keep the update_microcode commented for myself only, 
even if this still does not fix the issues for my setup, so that someone else may investigate what's wrong 
with the microcode ? 

Are my patches moot because fam10 fidvid is going to be replaced with something from Agesa ? 

Finally, I've never used abuild, but taking into account I'm touching 

src/cpu/amd/model_10xxx/fidvid.c
src/cpu/amd/model_10xxx/defaults.h
src/cpu/amd/model_10xxx/init_cpus.c
src/northbridge/amd/amdmct/wrappers/mcti_d.c
src/northbridge/amd/amdmct/amddefs.h
src/northbridge/amd/amdfam10/Kconfig
src/northbridge/amd/amdfam10/raminit_amdmct.c
src/northbridge/amd/amdht/AsPsDefs.h

should I try to abuild before sending my patches ? 

thanks.






More information about the coreboot mailing list