Hi, As a learning experience, I've been trying to port coreboot to the supermicro h8dme-2 w/ AMD K10. I've had not much luck either in the learning or the porting. In any case I've got coreboot up to where it is out of car and has started to clear memory, at which point it hangs. I presume this is because I failed to properly set up each socket's memory controller.
Copying data from cache to RAM -- switching to use RAM as stack... Done testx = 5a5a5a5a Disabling cache as ram now Clearing initial memory region:
I started with the h8dmr_fam10 port since the h8dmr is identical, spec-wise, to the h8dme except that it has half the number of dimm slots. Also there is both K8 and K10 versions of coreboot for the h8dmr which in principle makes the study of the differences a good way to learn coreboot internals.
In any case I have not been able to find where the info in spd_addr.h comes from, so I have not been able to make it correct for my board. How does one construct this table? In general, how does one construct devicetree.cb and the other tables from scratch?
Is there an apprenticeship program somewhere, perhaps at some conference? How do people in general get their coreboot skill-set jump-started?
Regards, Joe
On Thu, Jun 10, 2010 at 7:38 AM, Joe Korty joe.korty@ccur.com wrote:
Hi, As a learning experience, I've been trying to port coreboot to the supermicro h8dme-2 w/ AMD K10.
Ward and others have tried this board in the past. There seems to be something wrong with multi-core setup for K10.
If you search the mailing list for "h8dme fam10", it might give you some help. I would disable all the other processors until you get the board working.
CONFIG_LOGICAL_CPUS 0 CONFIG_SMP 0 CONFIG_MAX_PHYSICAL_CPUS 1
I started with the h8dmr_fam10 port since the h8dmr is identical, spec-wise, to the h8dme except that it has half the number of dimm slots. Also there is both K8 and K10 versions of coreboot for the h8dmr which in principle makes the study of the differences a good way to learn coreboot internals.
I agree that's a good approach. K8 and fam10 code are pretty similar, though they could be made even more similar.
In any case I have not been able to find where the info in spd_addr.h comes from, so I have not been able to make it correct for my board. How does one construct this table? In general, how does one construct devicetree.cb and the other tables from scratch?
I don't know that anyone does it from scratch. The idea is to make the devicetree as minimal as possible. That usually means including the processor and configuring the southbridge buses. The rest can usually be found.
Is there an apprenticeship program somewhere, perhaps at some conference?
I don't know. There have been some talks and short tutorials, but I haven't heard of an official training program.
How do people in general get their coreboot skill-set jump-started?
IRC and the mailing list is what I've heard most. I've used the mailing list.
Qemu and SimNOW are both helpful, too. SimNOW exhibits the same problems for fam10 as hardware (super slow initialization and problems with logical CPUs), so fixing it there would probably help.
Thanks, Myles
Myles Watson escribió:
On Thu, Jun 10, 2010 at 7:38 AM, Joe Korty joe.korty@ccur.com wrote:
Hi, As a learning experience, I've been trying to port coreboot to the supermicro h8dme-2 w/ AMD K10.
Ward and others have tried this board in the past. There seems to be something wrong with multi-core setup for K10.
I think that why Ward had problems with this CPU family is for the same reason why I had problems with it on different boards, the resource map! I started using the one from the h8dme fam 10 board. So maybe you should try another resource map from another fam 10 board. bye!
If you search the mailing list for "h8dme fam10", it might give you some help. I would disable all the other processors until you get the board working.
CONFIG_LOGICAL_CPUS 0 CONFIG_SMP 0 CONFIG_MAX_PHYSICAL_CPUS 1
I started with the h8dmr_fam10 port since the h8dmr is identical, spec-wise, to the h8dme except that it has half the number of dimm slots. Also there is both K8 and K10 versions of coreboot for the h8dmr which in principle makes the study of the differences a good way to learn coreboot internals.
I agree that's a good approach. K8 and fam10 code are pretty similar, though they could be made even more similar.
In any case I have not been able to find where the info in spd_addr.h comes from, so I have not been able to make it correct for my board. How does one construct this table? In general, how does one construct devicetree.cb and the other tables from scratch?
I don't know that anyone does it from scratch. The idea is to make the devicetree as minimal as possible. That usually means including the processor and configuring the southbridge buses. The rest can usually be found.
Is there an apprenticeship program somewhere, perhaps at some conference?
I don't know. There have been some talks and short tutorials, but I haven't heard of an official training program.
How do people in general get their coreboot skill-set jump-started?
IRC and the mailing list is what I've heard most. I've used the mailing list.
Qemu and SimNOW are both helpful, too. SimNOW exhibits the same problems for fam10 as hardware (super slow initialization and problems with logical CPUs), so fixing it there would probably help.
Thanks, Myles
Hi, As a learning experience, I've been trying to port coreboot to the supermicro h8dme-2 w/ AMD K10.
Ward and others have tried this board in the past. There seems to be something wrong with multi-core setup for K10.
I think that why Ward had problems with this CPU family is for the same reason why I had problems with it on different boards, the resource map! I started using the one from the h8dme fam 10 board. So maybe you should try another resource map from another fam 10 board. bye!
I'd forgotten about that problem. I think it's separate from the SimNOW problems, but it could be causing you grief, too.
Thanks, Myles
On Thu, Jun 10, 2010 at 10:52:30AM -0400, Knut Kujat wrote:
Myles Watson escribi?:
On Thu, Jun 10, 2010 at 7:38 AM, Joe Korty joe.korty@ccur.com wrote:
As a learning experience, I've been trying to port coreboot to the supermicro h8dme-2 w/ AMD K10.
Ward and others have tried this board in the past. There seems to be something wrong with multi-core setup for K10.
I think that why Ward had problems with this CPU family is for the same reason why I had problems with it on different boards, the resource map! I started using the one from the h8dme fam 10 board. So maybe you should try another resource map from another fam 10 board.
If you search the mailing list for "h8dme fam10", it might give you some help. I would disable all the other processors until you get the board working.
Qemu and SimNOW are both helpful, too. SimNOW exhibits the same problems for fam10 as hardware (super slow initialization and problems with logical CPUs), so fixing it there would probably help.
Myles and Knut, Thanks! I'll probe these ideas and see what happens.
Another data point: It _does_ continue after the hang, but it takes about an hour. I image each memory write is timing out so a bunch of writes via memset drags the total timeout to an hour. At that point we try to load the payload so it seems that I am really really close to the end here....
Regards, Joe
... the extra trace data ... Clearing initial memory region: Done Loading stage image. Check CBFS header at fffff8da magic is 4f524243 Found CBFS header at fffff8da Check fallback/romstage CBFS: follow chain: fff00000 + 38 + 12438 + align -> fff12480 Check fallback/coreboot_ram Stage: loading fallback/coreboot_ram @ 0x200000 (1146880 bytes), entry @ 0x200000 lzma: Decoding error = 1 CBFS: LZMA decompression failed! Loading stage failed!
On Thu, Jun 10, 2010 at 11:10:28AM -0400, Joe Korty wrote:
Ward and others have tried this board in the past.
Yeah - I still have a test setup and need to get back to this soon. I'm just tied up with too much other stuff. Bleh.
There seems to be
something wrong with multi-core setup for K10.
I think that why Ward had problems with this CPU family is for the same reason why I had problems with it on different boards, the resource map! I started using the one from the h8dme fam 10 board. So maybe you should try another resource map from another fam 10 board.
If you search the mailing list for "h8dme fam10", it might give you some help. I would disable all the other processors until you get the board working.
Qemu and SimNOW are both helpful, too. SimNOW exhibits the same problems for fam10 as hardware (super slow initialization and problems with logical CPUs), so fixing it there would probably help.
Myles and Knut, Thanks! I'll probe these ideas and see what happens.
Another data point: It _does_ continue after the hang, but it takes about an hour.
Oh! That's interesting. I never tried to leave the board alone for that long.
I image each memory write is timing out so a bunch of writes via memset drags the total timeout to an hour. At that point we try to load the payload so it seems that I am really really close to the end here....
It does sound like it.
Thanks, Ward.
Joe Korty joe.korty@ccur.com writes:
Myles and Knut, Thanks! I'll probe these ideas and see what happens.
Another data point: It _does_ continue after the hang, but it takes about an hour. I image each memory write is timing out so a bunch of writes via memset drags the total timeout to an hour. At that point we try to load the payload so it seems that I am really really close to the end here....
This sounds kinda familiar. Can you check if it is related to http://article.gmane.org/gmane.linux.bios/57707 -- do the patches there help any?
On Thu, Jun 10, 2010 at 03:00:41PM -0400, Arne Georg Gleditsch wrote:
Joe Korty joe.korty@ccur.com writes:
Myles and Knut, Thanks! I'll probe these ideas and see what happens.
Another data point: It _does_ continue after the hang, but it takes about an hour. I image each memory write is timing out so a bunch of writes via memset drags the total timeout to an hour. At that point we try to load the payload so it seems that I am really really close to the end here....
This sounds kinda familiar. Can you check if it is related to http://article.gmane.org/gmane.linux.bios/57707 -- do the patches there help any?
Doesn't look like it. We are getting hosed (consuming an hour's worth of time) between the printk of 'Clearing memory...' and the printk of 'Done.' The only thing between those two printk's is a memset.
Joe
Joe Korty joe.korty@ccur.com writes:
This sounds kinda familiar. Can you check if it is related to http://article.gmane.org/gmane.linux.bios/57707 -- do the patches there help any?
Doesn't look like it. We are getting hosed (consuming an hour's worth of time) between the printk of 'Clearing memory...' and the printk of 'Done.' The only thing between those two printk's is a memset.
I believe there's a patch to memset there too, unless I've pasted the wrong URL? I saw what appeared to be dramatic performance issues, presumably related to instruction cache misses/refetches in the memset code. (The impact is likely related to how the alignment turns out as well as the latency over the SB towards ROM.)
I'm not sure a northbridge timeout on write to coherent memory would be benign enough to let you continue going gracefully... Either way, it'd be interesting to know if modifying the code itself helps any.
On Thu, Jun 10, 2010 at 03:30:09PM -0400, Arne Georg Gleditsch wrote:
Joe Korty joe.korty@ccur.com writes:
This sounds kinda familiar. Can you check if it is related to http://article.gmane.org/gmane.linux.bios/57707 -- do the patches there help any?
Doesn't look like it. We are getting hosed (consuming an hour's worth of time) between the printk of 'Clearing memory...' and the printk of 'Done.' The only thing between those two printk's is a memset.
I believe there's a patch to memset there too, unless I've pasted the wrong URL? I saw what appeared to be dramatic performance issues, presumably related to instruction cache misses/refetches in the memset code. (The impact is likely related to how the alignment turns out as well as the latency over the SB towards ROM.)
I'm not sure a northbridge timeout on write to coherent memory would be benign enough to let you continue going gracefully... Either way, it'd be interesting to know if modifying the code itself helps any.
Hi Arne, First first applied only the memset change then I applied the whole patch.
The memset-only change did indeed speed up the memset. It is now instantaeous. The speedup seems too great to me, it implies that I've no-oped memset somehow.
Then I applied the whole patch. I had to change the "#if CONFIG_ARCH_X86" to "#if 1" as CONFIG_ARCH_X86 doesn't seem to be set. With that single change to your patch I see a speed-up to 'no delays, anywhere'; but now the execution patch is quite a bit different, we are in a warm reset infinite loop.
Anyways your patch made a difference ....... Thanks, Joe
Joe Korty joe.korty@ccur.com writes:
Hi Arne, First first applied only the memset change then I applied the whole patch.
The memset-only change did indeed speed up the memset. It is now instantaeous. The speedup seems too great to me, it implies that I've no-oped memset somehow.
Well, RAMTOP is what, 16MB? DDR2 (peak) transfer rates are 100-500 times that per second. There's reason that memset operation should be taking any noticeable amount of time.
Then I applied the whole patch. I had to change the "#if CONFIG_ARCH_X86" to "#if 1" as CONFIG_ARCH_X86 doesn't seem to be set. With that single change to your patch I see a speed-up to 'no delays, anywhere'; but now the execution patch is quite a bit different, we are in a warm reset infinite loop.
That's interesting. What's happening at the end there, before the warm reset?
On Thu, Jun 10, 2010 at 04:48:17PM -0400, Arne Georg Gleditsch wrote:
Joe Korty joe.korty@ccur.com writes:
Hi Arne, First first applied only the memset change then I applied the whole patch.
The memset-only change did indeed speed up the memset. It is now instantaeous. The speedup seems too great to me, it implies that I've no-oped memset somehow.
Well, RAMTOP is what, 16MB? DDR2 (peak) transfer rates are 100-500 times that per second. There's reason that memset operation should be taking any noticeable amount of time.
Then I applied the whole patch. I had to change the "#if CONFIG_ARCH_X86" to "#if 1" as CONFIG_ARCH_X86 doesn't seem to be set. With that single change to your patch I see a speed-up to 'no delays, anywhere'; but now the execution patch is quite a bit different, we are in a warm reset infinite loop.
That's interesting. What's happening at the end there, before the warm reset?
Hi Arnie, I've looked more closely; I first see a warm reset (which is normal) followed by an infinite series of soft resets (which are new). Here is the first part of the log, containing the warm reset and two of thesoft resets.
Still digesting this new development, myself.....
Regards, Joe
coreboot-4.0-r5628M Thu Jun 10 16:21:49 EDT 2010 starting...
Coreboot configured for H8DME-2 with K10 AMD processors BSP Family_Model: 00100f42 *sysinfo range: [000cc000,000cdfa0] bsp_apicid = 00 cpu_init_detectedx = 00000000 microcode: equivalent rev id = 0x1041, current patch id = 0x00000000 microcode: rev id (1062) does not match this patch. microcode: Not updated! Fix microcode_updates[] cpuSetAMDMSR done Enter amd_ht_init() AMD_CB_EventNotify() event class: 05 event: 1004 data: 04 00 00 01 AMD_CB_ManualBUIDSwapList() AMD_CB_EventNotify() event class: 05 event: 2006 data: 04 00 02 ff Exit amd_ht_init() cpuSetAMDPCI 00 done cpuSetAMDPCI 01 done Prep FID/VID Node:00 F3x80: e600a681 F3x84: a0e641e6 F3xD4: c3310f24 F3xD8: 03001615 F3xDC: 00005322 Prep FID/VID Node:01 F3x80: e600a681 F3x84: a0e641e6 F3xD4: c3310f24 F3xD8: 03001615 F3xDC: 00005322 setup_remote_node: 01 done Start node 01 done. core0 started: core0: --- { APICID = 04 NODEID = 01 COREID = 00} --- crm1i v ostcaordet:_ oteqhueri_vcaloernest( r)e c iniidt =n od0ex1:0 4001 , ccuorrersen:t 03p at hSt aird t= o t0hx0e0r0 c0o00r0e0 - 2nmiodceriocdo: d0e:0 r ceovr ieds : (01036 .)i ndoiets nnoodte :m 0a1t ch ctohriess :p a0t3c h S ptamirctr ooctohdeer: cNoorte u-p dnaotdeeid!d :F i0x1 m iccorroecso:d e0_3u a attccceaooorsrrr[etee]xexx :d:: -p--c-p- -a--u-S p i{{e{tc AiAAAMdPPPD:IIIM CCCSIIIDDDR === 000OOO32n eNNN DDDEEEiIIInDDDit _===f i000d000v iCCCdOOO_RRRaEEEpIII(DDDs t===a 0gc0e3211}}}) ------ap---
cs i*ccc ooodAmmm:iPiirrre c cceex0rrxx0r:o1oo::4 cc AuuA uA -dd-F-ad-re-ee-I-:::-D-t V e {d{{Ieeeqq Dq eeae0007vrvP*PiiIv IvvInCaaC CaAIAIlPIllDePDe De n0 n n: =t2=t=t s 0rtr4r DE E E v65 tNiNNieidddOdOOD D I*=I=I=D D D 0 0A0=Pxx==x 1 11 00000001341414 1 s1 1C,C,Ct, aO O ORe=crRcEuEuEuterIrIrIDrdrDrD e e ddnn==n t tt 00 01ppp32aaa}}} tt t-cc--c-h-hh-- -- d
*=== mmmi0A0ii0cxcxPxcr0r0r0 o00o0o0c0c05c0o0o0o0st0d0d0de0ea0e0:0:0:r0eeeq 0 q
uummmiii iiivcvcc*var ararloloAloecececPno nonotdtd0td 6eeer:sr::re e te vrvrvrd d= = =ivivtivd d d edi i i d (* ( ( 011 010x0xx00A16P61160202 204)4)4)01 71 1 ,d,ds,d o o otaecececut rsusr r rt nernrnreoodeoentnntt m papapa m tct atatta cctchchcBh eh h h t tg tihihihinididid s s s = = F = Ip p p0a0Da0axtxtxVtcI0c0000h0hD0h0.0.0. M S 0 xr 00m00mRm0 ii00i0c00cc0 c oo oc0ccmmmooiio0ic1ddccdrer0eero::o:o0c7c c oNo1oNNoodod d0ttetee: :: x 3uu u rpr0ppreddedebv0vaava t 0 tteeiei0idaddddd !3 !!( ( (101FF1F0i0x0iixx6x6462o2 2 )m)0)mmii i 3 d5ccdcdoroo0rreoooee4s0scccs o oonddndn oeeoet_tt__FuIuu mmpDppmadaadVdIaatattccDttcthehh ee sss ottnt[[[h]]h h]i i iBsSs
P _AA ppp,ccca apppatutAtuuSScScPchIeeheh.t..Ctt i MMM ccooomDmdmDDMMiMi:ic cSScSrRr0rRRoo0o c P dddeee :::dd d NoNoNoononontetteeB
u uupp piiidnndfdnaiaiiaitdttttt__e e_efffd=dd!! !iii dd 1 dFvFvvF0i6iiiiixddx0xmamaappim ipicc(((cWrrrasssotttooictcaaacogo oggeededfdeoe11e1_)_r_)) u u upAaapa13pddPppaiiiaa tstcccteieteiisddsdsa[g[::[:] ]e] 00 0
:
cccpaFFFppuuupIIISDDSS_DeaVeVVetItpItIADADAiD cM M MDoDoiDoMnMnMnd S S SRA=ARA P PP ::1: n000 d1dd32oo
n neee
riiinenniiaitdtt___bfaffiicidkddvvv i=iiddd _1__aaa0p1pp(((0s6sstt0ta1aaegg aee111 )))c o aaampmppiioicncciii_dfdd::i: d 000(5p76 c
: FFFkIeIIDDDdV)VVIII D=DD o1oonn0n 6 AAA0P0PP:: i 0W006a57 t
for AP stage 1: ap_apicid = 2 readback = 2010601 common_fid(packed) = 10600 Wait for AP stage 1: ap_apicid = 3 readback = 3010601 common_fid(packed) = 10600 Wait for AP stage 1: ap_apicid = 4 readback = 4010601 common_fid(packed) = 10600 Wait for AP stage 1: ap_apicid = 5 readback = 5010601 common_fid(packed) = 10600 Wait for AP stage 1: ap_apicid = 6 readback = 6010601 common_fid(packed) = 10600 Wait for AP stage 1: ap_apicid = 7 readback = 7010601 common_fid(packed) = 10600 common_fid = 10600 FID Change Node:00, F3xD4: c3310f26 FID Change Node:01, F3xD4: c3310f26 End FIDVIDMSR 0xc0010071 0x30b000a3 0x38035040 mcp55_num:01 ...WARM RESET...
coreboot-4.0-r5628M Thu Jun 10 16:21:49 EDT 2010 starting...
Coreboot configured for H8DME-2 with K10 AMD processors BSP Family_Model: 00100f42 *sysinfo range: [000cc000,000cdfa0] bsp_apicid = 00 cpu_init_detectedx = 00000000 microcode: equivalent rev id = 0x1041, current patch id = 0x00000000 microcode: rev id (1062) does not match this patch. microcode: Not updated! Fix microcode_updates[] cpuSetAMDMSR done Enter amd_ht_init() AMD_CB_EventNotify() event class: 05 event: 1004 data: 04 00 00 01 AMD_CB_ManualBUIDSwapList() AMD_CB_EventNotify() event class: 05 event: 2006 data: 04 00 02 ff Exit amd_ht_init() cpuSetAMDPCI 00 done cpuSetAMDPCI 01 done Prep FID/VID Node:00 F3x80: e600a681 F3x84: a0e641e6 F3xD4: c3310f26 F3xD8: 03001615 F3xDC: 00005322 Prep FID/VID Node:01 F3x80: e600a681 F3x84: a0e641e6 F3xD4: c3310f26 F3xD8: 03001615 F3xDC: 00005322 setup_remote_node: 01 done Start node 01 done. core0 started: 01 start_other_cores() init node: c0o0r ec0:o re s-:- -0 3{ A 3SICtIaDrt =o th0e4r N OcoDrEeI D -= n o0d1 eCiOd:R E0ID0 = c0o0re}s -:- -0
imnicirto cnooddee:: e0q1 ui cvaolreenst: r0e3v dS t a=r t0 xo1t0h4e1r, ccourrer e-n tn opdaeticdh: i0d1 = c0oxr0e0s0:0 00000 sccc tooomiarrreecrexxrtxo::e:c d o da---ep :--- a---rp ei{{{vc iAAAidPPPd:III CCC(III1DDD0 6===2 ) d000132o eNNNsO OOnDDDoEEEItIIDDD m a===t c000h000 tCCChOOOiRRRsEEE IIIpDDDa t===c h000.312}}} o m---i---c---r
c* occcd mmmeAoiiioorccr:Prce rerre ooxNx0ox:1c:cc:o ot so otdd d --aee-ue- ueu uAiiAd- -t e a eeetq{q{d{q Aid!PvvP*PvI Ia IaaCllCAClFIPeiIeeIDnnDD nxt0 tt == 2m=is rr receDevvrva00056 7o rcit ii NddNodeNd dOO OD De =EE==E_ Iu* IID0D00Dp xdA x x=1=1=1aPt0 0 0 0440e4003111111s,, [s, C C C]trR aOcOcRuuRu rtEErrEIrrIIrecDedDeeDpnn u n dd =S= e 0ppt0p023aaA1a}t}ttM} c ccD--h-hMh- - - SR-i--ii
0o0 ===* 00Am0mmdxxPixiic0co00 c000rr0rno0oe005oc0sc0c t0o0toa0dd0d0ier0e0ne0i0:0:t0:
d mmmuieqfqq iuiuiidicic*c rrvvvrviaoaAooacPcldlcleoeo oe_n0dsndndttt6teeeas: :: rgt di erreeeev2ervv t vv vi a iei dddidipi d d dd1 c=(i=(*=( 1 1 1d 00:0A000x66x6 xP021 12210))04)004 74 4 ettnn 1,ot,oo,ee ea csrcsscu tu urnernnrrodrooreet tm a an tmtm a atptptp cacactBhththc e c chhtgtht hih hiiiiniidsds sd F =p=p=pI a a aD0Vt0t0txIcx0000hDh0h00. .0.00 S 0 oc 0m0mRm000i0i i00c0c0c0r0r0rx 0c c co0oommmid1iiddcee0ccer::0rr:o 7oocNNN1ccooooo odddttt0 eeexuuu:3:: ppp 0 rdddrbreeaaae0vvtttv0 0 eee iiaiddddd3d!!! (F(0(FF1i1x1ii0xx030x6 686 dddnen)iii)3) ccc 5 ddrrrd0o4oooooe0ecccess sooo neeo_oo__tuuuttEpppn mddddmmaaaaa attttttFccceeeIhDhhsss V [[[t]Itt]]hsiih i
Sss MM R cccppppp paauuua0txtSSStccceeechh0httt.A.0.AA DD 0 DmMMm0mMiSSSi7iccRRRc1r rr o0oocccxo3ooddd0 dddeebe:ooo::0 nnn 0N0eeeNoott3
t iiiuuu0nnnpppxiiidtdd3tta_aa8__tfftt0feiiee0idddd2ddv8vv!!!0iii F8ddsssx __iixx ttt mmmaaamggiiigccpeeccer522rr2o 5 oocca_aacoopnppoddduiiiececcme_i_ii:_d d a00a:p::1d es a0t21tt3e s
s[[[]]]
cccpppuuuSSSeeetttAAAMMMDDDMMMSSSRRR dddooonnneee
iiinnniiittt___fffiiidddvvviiiddd___ssstttaaagggeee222 aaapppiiiccciiiddd::: 000567
fill_mem_ctrl() raminit_amdmct() raminit_amdmct begin: Node: 01 base: 00 limit: 7fffff BottomIO: e00000 Copy dram map from Node 0 to Node 01 raminit_amdmct end: v_esp=000cbee8 testx = 5a5a5a5a Copying data from cache to RAM -- switching to use RAM as stack... Done testx = 5a5a5a5a Disabling cache as ram now Clearing initial memory region: Done Loading stage image. Check CBFS header at fffff8da magic is 4f524243 Found CBFS header at fffff8da Check fallback/romstage CBFS: follow chain: fff00000 + 38 + 124d4 + align -> fff12540 Check fallback/coreboot_ram Stage: loading fallback/coreboot_ram @ 0x200000 (1179648 bytes), entry @ 0x200000
INIT detected from --- { APICID = 00 NODEID = 00 COREID = 00} ---
Issuing SOFT_RESET...
coreboot-4.0-r5628M Thu Jun 10 16:21:49 EDT 2010 starting...
Coreboot configured for H8DME-2 with K10 AMD processors BSP Family_Model: 00100f42 *sysinfo range: [000cc000,000cdfa0] bsp_apicid = 00 cpu_init_detectedx = 00000000 microcode: equivalent rev id = 0x1041, current patch id = 0x00000000 microcode: rev id (1062) does not match this patch. microcode: Not updated! Fix microcode_updates[] cpuSetAMDMSR done Enter amd_ht_init() AMD_CB_EventNotify() event class: 05 event: 1004 data: 04 00 00 01 AMD_CB_ManualBUIDSwapList() AMD_CB_EventNotify() event class: 05 event: 2006 data: 04 00 02 ff Exit amd_ht_init() cpuSetAMDPCI 00 done cpuSetAMDPCI 01 done Prep FID/VID Node:00 F3x80: e600a681 F3x84: a0e641e6 F3xD4: c3310f26 F3xD8: 03001615 F3xDC: 00005322 Prep FID/VID Node:01 F3x80: e600a681 F3x84: a0e641e6 F3xD4: c3310f26 F3xD8: 03001615 F3xDC: 00005322 setup_remote_node: 01 done Start node 01 done. core0 started: 01 start_other_cores() nit node: 0 0 c orceor0e: s: -0--3 { -SAtPIaCrtI Do =t her 0c4 oNreO D-EI Dno d= e0i1d: CO0R0 EI cDo =r es0:0} 0-3 i- nit mnicordoec:o 0d1e : ceqoureisv:a l0e3n t rSetva ritd o t=h e0rx 1c0o4r1e, -c unrordeenitd :p a0t1c h ciodr e=s :0 x0000 rre0 sc0tcoc00aoror etexexx:mid:: c ra op---c ---oa---dp {i{{e: c AiAArPdPPeI:IIvC CC IIIiDDDd ===( 1060001232) NNNdOOOoDDDeEEEsIII DDDn o===t 000m000a tC---OOOhRRR EEEtIIIhDDDi s=== p000a321}}}tc h----.-- m
i*ccc coooAmmrrrrmiieieeoPxccxxc crr::o0r: o d1o ocescc -o-o-o:t-d a-d-dNeuuPPupt: : : o{ { {te d eeeAqqAAqu PiiIIid*ICCva CvvIatAIaaIDlePDllD ee ed=n=n!=0n tt 2t F s trirr000xeeeD DDr v5v tm ieiiNiNNdddOdOOc E EEo I==IIc=* DDo D 0 d0A 0=xexP=x=_11 1 0000000u341411p4 11 d1s,,Cnn==CO Ot aO RcecrRcRsuutEuEErreIrII[drDrDD]r ee e = t ii t t0 0 0c3pp2p1p}u}a}aa tt S t-e-c-cc-hh-t-h-A- - D d dd M *=S== R mmm iA000ii cPxcxxcr00rr 0 00do00ooo5c00cc0os00oo0n0t0dd0ed0aee0:r:0 eneeeq:00 t0 00 i q diq uummmi_i ut iiiifc*vvccv raarrailolooldAecccevPeoooni nnddtd0ttd _6 eees:srr::rete d dd rrvar ree ge vtvievii ed2 dd d i iia == =p * (( (i 10110c0x000xixA6661d1P1220:0 024) 404))0 171 1,ds,dd,4to ceeec tttnn tttsuururtr rrernnnrooeedeon mmm papp ccttct aaatatta chBhhcc hhh e tgtt hhiiihidiniidd s s s= F = = p pIp0aDa0a0xtxxtVt0cIc0000h00hDh0. .0.00 S 0 rxr00m00mRm0i i0i00c00c0c o
ococ0ccmmmooiiio0cd1ddccrerre0eo:0:o:oc cc 7 oN1NoNododdo o0ttteee:: : x uu3u rprrpp0eddbedevavvaa0 tt0 t ieiiee0ddadddd 3! !!( ( (10F11FF0ii0xi063x66xx2 dne 2)0m))mm ii 0i d2cddccorro8roe0oeeoosccs8cs o oonddn ooeeot__t_t uu u Emmnppmpddadaadtt aatattctccFhhIeehe ss DsttV[t[[h]]hhI]iiD S s
MMM pppRcccpppaa at0tuuutSSSccxchcheeehttt..0.
1 m0mDDDmMMMii0ic7cSSScRRrr1rRo oo cc0cooxodd3d ee0e :bddd:: o 0ooN0nnNnNott 0ee
3 uuuiiipnpnn0piixddidatatt3a__8tt_tefeff0eii0iddd!!d!dd2vv8 v FFiFii0dd8i s mmtmttss aaiiaimcccgcggreerpreo5o2o22c c5c o_oaoaadppdndpeueeiiiccc_m__u:uiiiua00tt0pd1d:::d aa [s t0e312ees [
[]]]
cccpppuuuSSSeeetttAAAMMMDDDMMMSSSRRR dddooonnneee
iiinnniiittt___fffiiidddvvviiiddd___ssstttaaagggeee222 aaapppiiiccciiiddd::: 000576
fill_mem_ctrl() raminit_amdmct() raminit_amdmct begin: Node: 01 base: 00 limit: 7fffff BottomIO: e00000 Copy dram map from Node 0 to Node 01 raminit_amdmct end: v_esp=000cbee8 testx = 5a5a5a5a Copying data from cache to RAM -- switching to use RAM as stack... Done testx = 5a5a5a5a Disabling cache as ram now Clearing initial memory region:
INIT detected from --- { APICID = 00 NODEID = 00 COREID = 00} ---
Issuing SOFT_RESET...
coreboot-4.0-r5628M Thu Jun 10 16:21:49 EDT 2010 starting...
Coreboot configured for H8DME-2 with K10 AMD processors BSP Family_Model: 00100f42 *sysinfo range: [000cc000,000cdfa0] bsp_apicid = 00 cpu_init_detectedx = 00000000 microcode: equivalent rev id = 0x1041, current patch id = 0x00000000 microcode: rev id (1062) does not match this patch. microcode: Not updated! Fix microcode_updates[] cpuSetAMDMSR done Enter amd_ht_init() AMD_CB_EventNotify() event class: 05 event: 1004 data: 04 00 00 01 AMD_CB_ManualBUIDSwapList() AMD_CB_EventNotify() event class: 05 event: 2006 data: 04 00 02 ff Exit amd_ht_init() cpuSetAMDPCI 00 done cpuSetAMDPCI 01 done Prep FID/VID Node:00 F3x80: e600a681 F3x84: a0e641e6 F3xD4: c3310f26 F3xD8: 03001615 F3xDC: 00005322 Prep FID/VID Node:01 F3x80: e600a681 F3x84: a0e641e6 F3xD4: c3310f26 F3xD8: 03001615 F3xDC: 00005322 setup_remote_node: 01 done Start node 01 done. core0 started: 01 start_other_cores() nit node: 0 0c ocreo0re:s : - 0-3- { SAtPaICrIt Do =t her 0c4 oNreO DE-I nDo d= e0id1: C O00R EI Dco r=e 0s0: }0 -3- i rnit mnicordoec:o 0d1e : ceqourievsa:l e0n3t eSvt airdt o=t h0exr1 0c4o1r,e c-u rnroedneti dp:a t0c1h icdo r=e s0:x 00000 teee sc0tcc0aooo0rrrr exxx:d::mi ca rp-o-- ac---po--- di ec{{{: i AAdArPP:PeII IvCCC IIIiDDDd ===( 1060002132) NNNdOOOoDDDeEEEsIII DDDn o===t 000m000a tCCCcOOOhRRR EEEtIIIhDDDi s=== p000a213t}}} ch------.---
mi * cccArcoommmoorriiiPreeccc cxxrrr0oe:ooo1dx:cccse: oot: o --ddda -eeerNuuup A-:::-e t{d{ eee qqqu{ AiidAP*PiavPI IvvIaCACaatIlPIlleCD eeIDed!D n 0nn=t=2tt s F= irtrr xeaDDDr E vrvv7 m t iieiiNNNdddOOOcd EEo I*Ic===ID o DDdA000 xPxx===e11 _1 0000u000141p4341 1d1s1 a,,e nn a OOOtrccRRRecEuEEsutuIrI[rerIDr]rdrDD ee tt n=== iiiddd000 c21p3ppp}aaa}}u S ttt-ccc--e--t-hhh --A-
D 0e00ere:00:t: ===RmmAm iiPic000c crxxxr0r 00o5odo0c0scoc00t0ono00od0ed00da iq 000 e 0in000edeeq
uu tuii*_immmvv fviiiaAiacccadPlrrrlleoooeev cccnni0noottd6to d _s ddrstrreeetae a iii trrr g eeeeieiivdvd2ddv p==ddd*= i0Ac00(((iPxx111x1 10001d006660:027224 44)s)1011), 4d dda cocoorc ee ueeetuurrssserrr drennn ttt nnoottt a pmmmpp aaaaattttBttceccccchhhhghh i ttiiintd hhhddii Fi=Isss== D 0Vpp0p0xaxx00atDt0t000c00c cMhh0h000.0S..0 0
c 0m000m0m0i0iix0cc r r0r o0oommmiccc1iic0ccooordddr0ro7ooeee:::c1cco oo NNNd0ddoooexee:3:ttt: 0 rbuuurrppeee0pv0dddvv a 0aaiattitidedd3ee ddd(!(!0(!x 1 1 10F03F0F6ii6i682no02xx) ) )0 m 2 mmdiidid8oc0occoerreer8so soos cc c noonddoodoeettetEn__ _ mumduump paapatdtdFdtaIccacahthttDhVe e etstsIst[Dhh[ p]]]MiiS sss pp
tt1AA0a0aacccxpttptpcuucucchShhSS0.ee0.e. A
mMmmMM0DD7iDiicMccMM1SS rSrroRoRR0ocxcc ooo3d0ddeebe:0:: ddd 0 No0NN onnonao3etteet 0uu
dx_ uppxpiii3ndnnddiiaa8iat0ttttte_e_0e_f2ffddd!!i!i8i0dd d FvF8vvFi iiiiixdxd _ _msmssmmtticiticpacaacggrr5gro5eoeeo22cc_2c no ooaaddaudmpeppee__:_iiiuc::a:apip1piidddddd ] att t e00ee0ss3s21[[ ]
]
cccpppuuuSSSeeetttAAAMMMDDDMMMSSSRRR dddooonnneee
iiinnniiittt___fffiiidddvvviiiddd___ssstttaaagggeee222 aaapppiiiccciiiddd::: 000765
fill_mem_ctrl() raminit_amdmct() raminit_amdmct begin: Node: 01 base: 00 limit: 7fffff BottomIO: e00000 Copy dram map from Node 0 to Node 01 raminit_amdmct end: v_esp=000cbee8 testx = 5a5a5a5a Copying data from cache to RAM -- switching to use RAM as stack... Done testx = 5a5a5a5a Disabling cache as ram now Clearing initial memory region:
INIT detected from --- { APICID = 00 NODEID = 00 COREID = 00} ---
Issuing SOFT_RESET...
coreboot-4.0-r5628M Thu Jun 10 16:21:49 EDT 2010 starting...
Coreboot configured for H8DME-2 with K10 AMD processors
Joe Korty joe.korty@ccur.com writes:
I've looked more closely; I first see a warm reset (which is normal) followed by an infinite series of soft resets (which are new). Here is the first part of the log, containing the warm reset and two of thesoft resets.
Still digesting this new development, myself.....
[..]
raminit_amdmct() raminit_amdmct begin: Node: 01 base: 00 limit: 7fffff BottomIO: e00000
Looks like coreboot only finds memory on node 01. Not sure if that's supposed to work or not, but I'd be surprised if it did. I assume you have memory installed on node 00 as well? You mentioned spd earlier, and this seems like a likely symptom of coreboot failing to detect the spd roms on socket 0. You might want to enable CONFIG_DEBUG_RAM_SETUP to get some more data.
On Thu, Jun 10, 2010 at 05:21:44PM -0400, Arne Georg Gleditsch wrote:
Joe Korty joe.korty@ccur.com writes:
I've looked more closely; I first see a warm reset (which is normal) followed by an infinite series of soft resets (which are new). Here is the first part of the log, containing the warm reset and two of thesoft resets.
Still digesting this new development, myself.....
[..]
raminit_amdmct() raminit_amdmct begin: Node: 01 base: 00 limit: 7fffff BottomIO: e00000
Looks like coreboot only finds memory on node 01. Not sure if that's supposed to work or not, but I'd be surprised if it did. I assume you have memory installed on node 00 as well?
Yes I do. When I stick K8's in and compile coreboot accordingly, it all works.
You mentioned spd earlier, and this seems like a likely symptom of coreboot failing to detect the spd roms on socket 0. You might want to enable CONFIG_DEBUG_RAM_SETUP to get some more data.
I will! Thanks, Joe
On Thu, Jun 10, 2010 at 05:21:44PM -0400, Arne Georg Gleditsch wrote:
Joe Korty joe.korty@ccur.com writes:
I've looked more closely; I first see a warm reset (which is normal) followed by an infinite series of soft resets (which are new). Here is the first part of the log, containing the warm reset and two of thesoft resets.
Still digesting this new development, myself.....
[..]
raminit_amdmct() raminit_amdmct begin: Node: 01 base: 00 limit: 7fffff BottomIO: e00000
Looks like coreboot only finds memory on node 01. Not sure if that's supposed to work or not, but I'd be surprised if it did. I assume you have memory installed on node 00 as well? You mentioned spd earlier,
FYI, the K8 version of the h8dme-2 (which works) has this comment in it. This comment isn't in the h8dmr version (K8 or K10) nor in the h8qme K10 version. I wonder how the K8 version initializes the node 00 bank? Whatever that is, I think I need it here also.
Regards, Joe
... from src/mainboard/supermicro/h8dme/romstage.c:
/* We have no idea where the SMBUS switch is. This doesn't do anything ATM. */ #define RC0 (2<<8) #define RC1 (1<<8)
void cache_as_ram_main(unsigned long bist, unsigned long cpu_init_detectedx) { /* The SPD is being read from the CPU1 (marked CPU2 on the board) and we don't know how to switch the SMBus to decode the CPU0 SPDs. So, The memory on each CPU must be an exact match. */ static const uint16_t spd_addr[] = {
Joe Korty joe.korty@ccur.com writes:
FYI, the K8 version of the h8dme-2 (which works) has this comment in it. This comment isn't in the h8dmr version (K8 or K10) nor in the h8qme K10 version. I wonder how the K8 version initializes the node 00 bank? Whatever that is, I think I need it here also.
Haha, I just had a look and noticed this too. This appears to be a massive hack which simply pretends that the SPD addresses of the node 0 banks are the same as the ones for node 1 -- so instead of probing the banks on both node, the code is in effect probing the banks on node 1 twice. This is harmless as long as both sockets are identically populated, but fairly brittle...
To recreate for the fam10 infrastructure, you'll need a somewhat non-standard spd_addr.h. Since the addresses you have for the second node seems to work, you could start with just copying them to the line representing the first node as well.
But long-term we really should find out how to switch the SMBus between the different SPD groups. SerialICE is handy tool for this, for someone who has the time.
On Thu, Jun 10, 2010 at 05:46:24PM -0400, Arne Georg Gleditsch wrote:
Joe Korty joe.korty@ccur.com writes:
FYI, the K8 version of the h8dme-2 (which works) has this comment in it. This comment isn't in the h8dmr version (K8 or K10) nor in the h8qme K10 version. I wonder how the K8 version initializes the node 00 bank? Whatever that is, I think I need it here also.
Haha, I just had a look and noticed this too. This appears to be a massive hack which simply pretends that the SPD addresses of the node 0 banks are the same as the ones for node 1 -- so instead of probing the banks on both node, the code is in effect probing the banks on node 1 twice. This is harmless as long as both sockets are identically populated, but fairly brittle...
To recreate for the fam10 infrastructure, you'll need a somewhat non-standard spd_addr.h. Since the addresses you have for the second node seems to work, you could start with just copying them to the line representing the first node as well.
Thanks, I'll play with this tomorrow and see what happens.... Joe
-
Arne Georg Gleditsch -
Joe Korty -
Knut Kujat -
Myles Watson -
Ward Vandewege