[coreboot] ASUS M4A77TD-PRO slow progress

Xavi Drudis Ferran xdrudis at tinet.cat
Mon Aug 16 15:07:31 CEST 2010


Thanks to help from this list I could get my serial port to work with coreboot, and have been slowly progressing
getting a little more log messages each time. I was keeping some questions to ask about what I'm doing that
I pretended to send once I got coreboot to boot, in case I resolve them alone in the way,
but It's getting longer than I thought and I thought I may ask
now just in case I go too astray. Specially since skimming Qi's patch I don't see he needed all these changes
for a similar board.
I'm sending just the summary of the questions, I may send more details
if you want or start different threads if that's best.

Details on the mainboard in my previous message:

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. For most of the adresses without a device, the system hanged
when trying to get the pci id (I thought it should have returned FFF... but it
stopped cold there, apparently). Serialice does no id scan, it simply uses
hardcoded device addresses. 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, but then I wonder whether my change is
acceptable for other mainboards, or I should somehow configure some exclusion
parameter so that it can still scan all devices if needed for some other card.
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 ?

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). 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 ? Has people already used RB_C3 processors
with coreboot? 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 ?

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

So, in general, is all this normal, because I'm using hardware that hasn't been used before with
coreboot, or I'm just lost in irrelevant details and everything should just work, so I should look
elsewhere ?


More information about the coreboot mailing list