[coreboot] ASUS M4A77TD-PRO slow progress
peter at stuge.se
Mon Aug 16 16:13:09 CEST 2010
Xavi Drudis Ferran wrote:
> 1.- In order to get sb700_lpc_init in sb700_early_setup.c to work
> I've got to modifiy pci_locate_device in order to refrain from
> scanning some functions in pci bus 0.
Hm. Which fn?
> And I don't know what's the purpose of scanning for devices for my
> mainboard that early, I guess it's because sb700_lpc_init it's
> used in other places where it makes sense,
I don't know if it makes sense. That's not neccessarily the case. It
depends on if the SB700 can have a different BDF on different boards.
> but then I wonder whether my change is acceptable for other
No, I don't think it is.
> or I should somehow configure some exclusion parameter so that it
> can still scan all devices if needed for some other card.
This is also not so nice IMO.
> Or maybe better I should hardcode de device addresses in
> sb700_lpc_init and don't call pci_locate_device. Is there a policy
> about hard coded bus, dev,fn, or pci_locate_device ?
In general nothing should be hard coded that is not hard coded in
documentation. Ie. if BDF *can* change, then it can not be hard
coded. However, the BDF should already be available from
devicetree.cb, and hopefully that can be used also for early setup.
> 2.- I'm using a Phenom II x4 910e which is revision RB_C3. I've got
> to add it to some constants like AMD_FAM10_ALL and the like for ht
> init and some cpu errata. I've also added some new errata and
> modified some existing one. (I've modified CPU name assignment too,
> I hope it works).
Please send patches for all these types of changes that you have
already done. Send many patches with one isolated change in every
patch. The smaller each patch is, the easier it is to commit it and
also review and comment on any things that should be improved.
> While looking at the latests revisions of AMD revision guide and
> BIOS and Kernel Developer Guide (BKDG), I realised there are more
> CPU models than the ones identified by the constants in amddefs.h.
> In fact I think a 32 bit flag value is used and there are more new
> CPU revisions to add than bits left unused (2). So I haven't added
> the new revisions from the current docs, like I did for processor
> names, since my RB_C3 already had a constant. But maybe something
> should be done to foresee the new revisions ?
Certainly. I for one think that the good fix is to make a single long
data structure which gathers that CPU revision information in one
> Has people already used RB_C3 processors with coreboot?
I doubt it.
> Should soem bits that are used in the same cases be folded into
> one, or should the value be extended to 64 bits or something ?
I like the idea of a data structure better. We're using C here so
there is no reason to spread one piece of logical information out
over multiple discrete variable types. A revision bitfield and an
array of names doesn't make sense when there could be a structure
with everything gathered in one place.
> 3.- It currently stops at fidvid setting, after starting other
> cores (stage2, I think, it's hard to read the log when they all
> write at once). Sometimes it continues until decompressing CBFS and
> stops when entering ram stage, but I'm trying to concentrate in the
> earliest point of failure.
This is very wise.
> By browsing fidvid.c and the BKDG it seems it is not up to date, in
> particular apparently has fixed values for rev B CPUs, and I can't
> find some of the procedures required by current BKDG. I suspect
> some use of configuration data before setting it up, after power
> up, to calculate ramp or slam values for voltage transitions, and
> apparently it won't work with all voltages (maybe some cases can't
> happen?). In fact I can't seem to understand how to code some of
> the missing(?) procedures (like setting vid and fid for dual power
> plane mainboards, which amd docs say it's mainboard-specific and I
> can't find either hooks to use in fibvid.c to make it dependend on
> the mainboard or hints on what do I have to tell the voltage
> regulators in ASUS M4a77td-pro to comply with AMD docs). So I
> wonder whether I'm looking to unused code, or whether not
> implementing the whole BKDG is on purpose, or I'm just not
> understanding what I read.
I think the code just has not been developed yet. The existing code
is in no way complete, and all your improvements are very much
> or I'm just lost in irrelevant details
Certainly not, you've identified very important points where coreboot
needs to be improved.
More information about the coreboot