I'm attempting to port Coreboot to an Asus M4A78XTD board, which has an RS780/SB700 chipset with a socket AM3 (Fam10h+DDR3) CPU.
Starting with the tilapia_10h mainboard code, the first problem I'm hitting occurs very early on: any attempt to call pci_locate_device(), for example in sb700_lpc_init(), hangs forever (or at least longer than I'm willing to wait), unless I disable all the PCIe bridges on the 780 by inserting the following into enable_rs780_dev8():
set_nbmisc_enable_bits(PCI_DEV(0, 0, 0), 0x0c, 0, 0x000300fc);
If I leave even one of the bridges enabled, I get the hang. See section 2.5.6 in http://support.amd.com/us/Embedded_TechDocs/43291_rs780_rpr_pub_1.01.pdf for a description of this register.
With the PCIe bridges out of the picture, I get through memory initialization (woo hoo!), but for some reason ram_fill() and ram_verify() take many minutes to complete, and it hangs shortly thereafter. Boot log attached.
Any clues would be appreciated!
--Ed
I'm attempting to port Coreboot to an Asus M4A78XTD board, which has an RS780/SB700 chipset with a socket AM3 (Fam10h+DDR3) CPU.
Starting with the tilapia_10h mainboard code, the first problem I'm hitting occurs very early on: any attempt to call pci_locate_device(),
Have you tried changing it to pci_locate_device_on_bus()? That will constrain the search to a single bus.
With the PCIe bridges out of the picture, I get through memory initialization (woo hoo!), but for some reason ram_fill() and ram_verify() take many minutes to complete, and it hangs shortly thereafter. Boot log attached.
I think there must be some MTRR setup problem. Maybe you could print out the MTRRs just before the slow parts?
Thanks, Myles
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I found that in k8 CAR set_var_mtrr is set as it the arguments would be an adresses, but in fact they HAVE TO be in kilobytes.
Try this:
/* So we can access RAM from [1M, CONFIG_RAMTOP) */ set_var_mtrr(0, 0x00000000, (CONFIG_RAMTOP >> 10), MTRR_TYPE_WRBACK);
Instead of: set_var_mtrr(0, 0x00000000, CONFIG_RAMTOP, MTRR_TYPE_WRBACK);
Rudolf
Hi Ed,
On Wed, Apr 28, 2010 at 1:01 PM, Rudolf Marek r.marek@assembler.cz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I found that in k8 CAR set_var_mtrr is set as it the arguments would be an adresses, but in fact they HAVE TO be in kilobytes.
Try this:
/* So we can access RAM from [1M, CONFIG_RAMTOP) */ set_var_mtrr(0, 0x00000000, (CONFIG_RAMTOP >> 10), MTRR_TYPE_WRBACK);
Instead of: set_var_mtrr(0, 0x00000000, CONFIG_RAMTOP, MTRR_TYPE_WRBACK);
This is a problem. There is an early init version and a normal version of this function that take different input. Very confusing. I am still not sure why we are doing a bunch of memory clearing and what CONFIG_RAMTOP is supposed to be.
I also started porting a board today and hit the memset clearing problem you mentioned. This seems to have come up since the introduction of the memset, but that is probably a symptom.
Marc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Rudolf Marek wrote:
I found that in k8 CAR set_var_mtrr is set as it the arguments would be an adresses, but in fact they HAVE TO be in kilobytes.
Hi again,
I re-checked and it was OK, we do have an early function with same name which takes bytes parameters (mtrr-early.c). So this is not the case. I investigated MTRRs bit more.
The RAM init on AMD does not use the varmtrr0 and varmtrr1 the reason is that it thinks the first is used for 0-RAMBASE second for ROM caching.
I also changed the XIP MTRR setup to cache whole ROM with the MTRR. I think it is OK to do it this way...
After the code goes to the post_cache_as_ram.c it sets up an mtrr for the coreboot_ram as 0-RAMTOP. Maybe we can go with a big mtrr 0-TOM and create UCs for VGA....
Thanks, Rudolf
On Sun, May 2, 2010 at 3:45 PM, Rudolf Marek r.marek@assembler.cz wrote:
I re-checked and it was OK, we do have an early function with same name which takes bytes parameters (mtrr-early.c). So this is not the case. I investigated MTRRs bit more.
I noticed that too. Perhaps we should rename the early version to something like early_set_var_mtrr() to avoid confusion?
The RAM init on AMD does not use the varmtrr0 and varmtrr1 the reason is that it thinks the first is used for 0-RAMBASE second for ROM caching.
I also changed the XIP MTRR setup to cache whole ROM with the MTRR. I think it is OK to do it this way...
After the code goes to the post_cache_as_ram.c it sets up an mtrr for the coreboot_ram as 0-RAMTOP. Maybe we can go with a big mtrr 0-TOM and create UCs for VGA....
Would we also need to carve out an uncached space for any MMIO BARs that are used during early setup?
--Ed
On Sun, May 2, 2010 at 9:24 PM, Ed Swierk eswierk@aristanetworks.com wrote:
On Sun, May 2, 2010 at 3:45 PM, Rudolf Marek r.marek@assembler.cz wrote:
I re-checked and it was OK, we do have an early function with same name which takes bytes parameters (mtrr-early.c). So this is not the case. I investigated MTRRs bit more.
I noticed that too. Perhaps we should rename the early version to something like early_set_var_mtrr() to avoid confusion?
That would be good.
The RAM init on AMD does not use the varmtrr0 and varmtrr1 the reason is that it thinks the first is used for 0-RAMBASE second for ROM caching.
I also changed the XIP MTRR setup to cache whole ROM with the MTRR. I think it is OK to do it this way...
After the code goes to the post_cache_as_ram.c it sets up an mtrr for the coreboot_ram as 0-RAMTOP. Maybe we can go with a big mtrr 0-TOM and create UCs for VGA....
Would we also need to carve out an uncached space for any MMIO BARs that are used during early setup?
TOM will have the hole already handled and additional memory would be hoisted.
Marc
On Sun, May 2, 2010 at 4:45 PM, Rudolf Marek r.marek@assembler.cz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Rudolf Marek wrote:
I found that in k8 CAR set_var_mtrr is set as it the arguments would be an adresses, but in fact they HAVE TO be in kilobytes.
Hi again,
I re-checked and it was OK, we do have an early function with same name which takes bytes parameters (mtrr-early.c). So this is not the case. I investigated MTRRs bit more.
The RAM init on AMD does not use the varmtrr0 and varmtrr1 the reason is that it thinks the first is used for 0-RAMBASE second for ROM caching.
I also changed the XIP MTRR setup to cache whole ROM with the MTRR. I think it is OK to do it this way...
After the code goes to the post_cache_as_ram.c it sets up an mtrr for the coreboot_ram as 0-RAMTOP. Maybe we can go with a big mtrr 0-TOM and create UCs for VGA....
Thanks, Rudolf
Hi Rudolf,
I was just looking at the same thing. I don't like the MTRR manipulation that is happening in post_cache_as_ram.c. Doing 0-TOM is a little tricky if the dimms are different sizes. It is easier to let that get setup in the RAM stage. Getting the XIP setup correctly for the lzma decompress seems to be an issue. I am not certain what is happening and if we are crossing some boundaries that are causing flushes. In addition to fixing the cache, Arne's patch to put the lzma into memory may be the way to go.
Marc
Am Sonntag, den 02.05.2010, 21:47 -0600 schrieb Marc Jones:
I was just looking at the same thing. I don't like the MTRR manipulation that is happening in post_cache_as_ram.c. Doing 0-TOM is a little tricky if the dimms are different sizes. It is easier to let
It's one MTRR per DIMM, where identically sized DIMMs can be merged (in pairs of two, until merging is done). Actually, as long as there are only power-of-two DIMMs around, it's a matter of knowing the total memory size (in addition to usable memory due to UMA and the like), and counting bits.
Then another MTRR for shared video memory (if configured, and if it's power-of-two sized) and another for 0xa0000-0xc0000.
For 512 + 512 + 128 + 128MB DIMMs and 8MB UMA this gives: 0-1024MB: cached 1024-(1024+256): cached (1024+256-8) - (1024+256): uncached 0xa0000-0xc0000: uncached 0xfff00000-0x10000000: ROM: cached
Contrast this to the current setup: 0x00000-0x80000 cached 0x80000-0xa0000 cached 0xa0000-0xc0000 uncached 0xe0000-0x100000 cached 0x100000-whereever cached (hopefully covering all of RAMBASE..RAMTOP) subset of 0xfff00000-0x10000000 (XIP_ROM): ROM: cached
The latter takes more MTRRs, and we still have to hope that the >1MB MTRR actually covers the whole RAMBASE..RAMTOP area. And we can't simply use RAMBASE and RAMTOP to determine the MTRR, as MTRRs have these nice requirements about power-of-two sizes and being aligned to their size.
that get setup in the RAM stage. Getting the XIP setup correctly for the lzma decompress seems to be an issue. I am not certain what is happening and if we are crossing some boundaries that are causing flushes.
That would most likely mean that the XIP_ROM_SIZE is too small (so XIP_ROM + CAR isn't larger than the available cache). Curiously, the romstage doesn't run slow, only the memcpy/ulzma part.
But it's not that bad: When we decompress, RAM is around, so CAR should already be disabled, and we can cache the entire ROM area and all of RAM.
In addition to fixing the cache, Arne's patch to put the lzma into memory may be the way to go.
I'm not sure we can trust the compiler to always build the code in a way that we can copy it, so I'd prefer that solution to be a work-around until the real issue is solved and then to never reappear.
Patrick
On Wed, Apr 28, 2010 at 6:26 AM, Myles Watson mylesgw@gmail.com wrote:
Have you tried changing it to pci_locate_device_on_bus()? That will constrain the search to a single bus.
That doesn't help; config space accesses to the PCIe bridge devices themselves are hanging.
I worked around the problem by replacing pci_locate_device() with hardcoded PCI_DEV values, which should be okay for this chipset as long as the northbridge and southbridge are always at the normal addresses.
I managed to set up SerialICE on my board and get a few thousand lines of tracing from the factory BIOS. I notice that it doesn't touch those PCIe bridge devices at all early on. Is it possible that some HyperTransport magic needs to happen to get them to behave?
I think there must be some MTRR setup problem. Maybe you could print out the MTRRs just before the slow parts?
Here's a dump of various MSRs right after the call to raminit_amdmct() in romstage.c:
/* variable MTRRs */ msr 00000200=0000000000000000 msr 00000201=0000000000000000 msr 00000202=00000000fff00006 msr 00000203=0000fffffff80800 msr 00000204=0000000000000006 msr 00000205=0000ffff80000800 msr 00000206=0000000080000006 msr 00000207=0000ffffc0000800 msr 00000208=00000000c0000006 msr 00000209=0000ffffe0000800 msr 0000020a=0000000000000000 msr 0000020b=0000000000000000 msr 0000020c=0000000000000000 msr 0000020d=0000000000000000 msr 0000020e=0000000000000000 msr 0000020f=0000000000000000
/* fixed MTRRs */ msr 00000250=1e1e1e1e1e1e1e1e msr 00000258=1e1e1e1e1e1e1e1e msr 00000259=0000000000000000 msr 00000268=1e1e1e1e00000000 msr 00000269=1e1e1e1e1e1e1e1e msr 0000026a=0000000000000000 msr 0000026b=0000000000000000 msr 0000026c=0404040404040404 msr 0000026d=0404040404040404 msr 0000026e=0404040404040404 msr 0000026f=0404040404040404
/* variable & fixed MTRRs enabled */ msr 000002ff=0000000000000c00
/* IORRs */ msr c0010016=0000000080210000 msr c0010017=0000000000000000 msr c0010018=0000000000000000 msr c0010019=0000000000000000
/* top of memory registers */ msr c001001a=00000000e0000000 msr c001001d=0000000120000000
Another experiment I tried was to replace memset() with the original assembler version of clear_memory(). With this change, the "Clearing initial memory region:" step takes a fraction of a second vs. minutes with memset(). Then things grind to a halt after "Stage: loading fallback/coreboot_ram @ ...".
--Ed
On Wed, Apr 28, 2010 at 6:26 AM, Myles Watson mylesgw@gmail.com wrote:
Have you tried changing it to pci_locate_device_on_bus()? That will constrain the search to a single bus.
That doesn't help; config space accesses to the PCIe bridge devices themselves are hanging.
I worked around the problem by replacing pci_locate_device() with hardcoded PCI_DEV values, which should be okay for this chipset as long as the northbridge and southbridge are always at the normal addresses.
I managed to set up SerialICE on my board and get a few thousand lines of tracing from the factory BIOS. I notice that it doesn't touch those PCIe bridge devices at all early on. Is it possible that some HyperTransport magic needs to happen to get them to behave?
I don't know. It's surprising to hang.
I think there must be some MTRR setup problem. Maybe you could print
out
the MTRRs just before the slow parts?
Here's a dump of various MSRs right after the call to raminit_amdmct() in romstage.c:
/* variable MTRRs */ msr 00000200=0000000000000000 msr 00000201=0000000000000000 msr 00000202=00000000fff00006 msr 00000203=0000fffffff80800
This looks wrong to me. I'm not an expert, but Since 202 is the base, and 203 is the mask, It looks like the area from 0xfff00000 - 0xfff7ffff is cached. I would think the correct setting would be:
msr 00000202=00000000fff00006 msr 00000203=0000fffffff00800
To cache the last MB of mem.
msr 00000204=0000000000000006 msr 00000205=0000ffff80000800
Then this one caches 0 - 2GB
msr 00000206=0000000080000006 msr 00000207=0000ffffc0000800
This one caches 2GB-3GB
msr 00000208=00000000c0000006 msr 00000209=0000ffffe0000800
This one caches 3GB-3.5GB
Something to keep in mind is that caching should be disabled then enabled when setting the var MTRRs. Since you don't want to disable caches when you're using cache-as-RAM, I think it's best to make sure that the MTRRs are set correctly from the beginning and not touch them again until you've copied the RAM stage to the RAM and moved your stack.
msr 0000020a=0000000000000000 msr 0000020b=0000000000000000 msr 0000020c=0000000000000000 msr 0000020d=0000000000000000 msr 0000020e=0000000000000000 msr 0000020f=0000000000000000
/* fixed MTRRs */ msr 00000250=1e1e1e1e1e1e1e1e msr 00000258=1e1e1e1e1e1e1e1e msr 00000259=0000000000000000 msr 00000268=1e1e1e1e00000000 msr 00000269=1e1e1e1e1e1e1e1e msr 0000026a=0000000000000000 msr 0000026b=0000000000000000 msr 0000026c=0404040404040404 msr 0000026d=0404040404040404 msr 0000026e=0404040404040404 msr 0000026f=0404040404040404
/* variable & fixed MTRRs enabled */ msr 000002ff=0000000000000c00
/* IORRs */ msr c0010016=0000000080210000 msr c0010017=0000000000000000 msr c0010018=0000000000000000 msr c0010019=0000000000000000
/* top of memory registers */ msr c001001a=00000000e0000000 msr c001001d=0000000120000000
Another experiment I tried was to replace memset() with the original assembler version of clear_memory(). With this change, the "Clearing initial memory region:" step takes a fraction of a second vs. minutes with memset(). Then things grind to a halt after "Stage: loading fallback/coreboot_ram @ ...".
My theory is that since clear_memory was a single rep instruction, the fact that it wasn't being cached wasn't a big deal. With the caches set correctly, memset was faster on my board.
Good luck, Myles
On Fri, Apr 30, 2010 at 9:49 PM, Myles Watson mylesgw@gmail.com wrote:
/* variable MTRRs */ msr 00000200=0000000000000000 msr 00000201=0000000000000000 msr 00000202=00000000fff00006 msr 00000203=0000fffffff80800
This looks wrong to me. I'm not an expert, but Since 202 is the base, and 203 is the mask, It looks like the area from 0xfff00000 - 0xfff7ffff is cached. I would think the correct setting would be:
msr 00000202=00000000fff00006 msr 00000203=0000fffffff00800
I agree, this is only 512KB not 1MB as I would expect. Check $REAL_XIP_ROM_BASE and CONFIG_XIP_ROM_SIZE which get used in cpu/amd/car/cache_as_ram.inc.
Marc
I think there must be some MTRR setup problem. Maybe you could print out the MTRRs just before the slow parts?
Here's a dump of various MSRs right after the call to raminit_amdmct() in romstage.c:
/* fixed MTRRs */ msr 00000250=1e1e1e1e1e1e1e1e msr 00000258=1e1e1e1e1e1e1e1e msr 00000259=0000000000000000 msr 00000268=1e1e1e1e00000000 msr 00000269=1e1e1e1e1e1e1e1e msr 0000026a=0000000000000000 msr 0000026b=0000000000000000 msr 0000026c=0404040404040404 msr 0000026d=0404040404040404 msr 0000026e=0404040404040404 msr 0000026f=0404040404040404
I don't understand these values. I would have expected msr 00000268=1e1e1e1e1e1e1e1e (0xc0000-c7fff) (only if CAR size = 64K) msr 00000269=1e1e1e1e1e1e1e1e (0xc8000-cffff)
Why are we setting anything in the 0-0x80000 range ( msr 0x250) or the 0x80000-0x9ffff range (msr 0x258)? Same question for 0xe0000-0xfffff (0x26d-26f).
Thanks, Myles
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Why are we setting anything in the 0-0x80000 range ( msr 0x250) or the 0x80000-0x9ffff range (msr 0x258)?
addr = 0x250; <------>lo = 0x1E1E1E1E; <------>hi = lo; <------>_WRMSR(addr, lo, hi);<-><------>/* 0 - 512K = WB Mem */ <------>addr = 0x258; <------>_WRMSR(addr, lo, hi);<-><------>/* 512K - 640K = WB Mem */
In mctmtr_d.c
Thanks, Rudolf
Why are we setting anything in the 0-0x80000 range ( msr 0x250) or the 0x80000-0x9ffff range (msr 0x258)?
addr = 0x250; <------>lo = 0x1E1E1E1E; <------>hi = lo; <------>_WRMSR(addr, lo, hi);<-><------>/* 0 - 512K = WB Mem */ <------>addr = 0x258; <------>_WRMSR(addr, lo, hi);<-><------>/* 512K - 640K = WB Mem */
In mctmtr_d.c
Thanks for pointing out where it's done. I'm surprised that fam10 sets this up so early. K8 doesn't set any of that up until much later.
Thanks, Myles
Attached is my output of a new board. The chipset are quite close. Just for reference. For the problem of early stage, I met that before. I don't know why, but we can change pci_located_device to PCI_DEV(b, d, f) in sb700_early_setup.
The DIMM you are using is ECC capable. The code is there but I haven't tried that. I am wondering if there is problem.
------------------ coreboot-4.0-r717:718M Wed Apr 28 19:02:56 CST 2010 starting...
BSP Family_Model: 00100f43 *sysinfo range: [000cc000,000cf360] bsp_apicid = 00 cpu_init_detectedx = 00000000 microcode: equivalent rev id = 0x1043, current patch id = 0x00000000 microcode: patch id to apply = 0x010000b6 microcode: updated to patch id = 0x010000b6 success
cpuSetAMDMSR done Enter amd_ht_init() AMD_CB_EventNotify() event class: 05 event: 2006 data: 04 00 00 00 Exit amd_ht_init() cpuSetAMDPCI 00 done Prep FID/VID Node:00 F3x80: e600a681 F3x84: a0e641e6 F3xD4: c8810025 F3xD8: 00002e15 F3xDC: 00005334 core0 started: start_other_cores() init node: 00 cores: 03 Start other core - nodeid: 00 cores: 03 started ap apicid: cccooorrreeexx:x: : - ------- - {{{ AAAPPPIIICCCIIIDDD === 0001 -3 NNNOOODDDEEEIIID DD= == 0 0000 0 C CCOOORRREEEIDII DD === 000132} }} - -------
eqiqiPmcmri icoc01rcrosooctcdeoaod:drte e:e:eq d ue *uvui ialvAvaeaPlnl 0eten2n rtst e trvrare evtvid e idid d rret* 0= = x A00P10xx 0411033044,st33 ca,, ur crtcuuredrren ttp enn 0 aspratpa5tcht6ch c5 ih0_id ied =da = r 0=ly0x _x00xs0000e0000t000up0000(0000)00 0 g e dtd mpiucm_mirirecocvrcro oodcEcoeoAXd:d=e e:0:pa x ptp10acat0thcfc ih4h d 3i i. o ttCPaooUp a pappRlyppe llv =yy i ==s0 x000K1xx8_0001101000000.0b00 bf66a mi m
ee0cmmi_irococcprrootodccieoomi:ddez e::aup tiduuoappdntdaa(edtt) 0xx1dd o st rtoop56 at5ppac0atth_cc pohhidr i _idd=i ni==0xt 00 000110000000b00006 bb6 6 s u cscpssue5uccs1ccs00ee ess a
lpu
DMM _SccpespuutetSSAueeMpttDM(AAMS)MDR _onnSSsR pR5 do1n0 e0ddo deeeivn ii ((sgiine_niifs_ttidp__fvofiiir_dddivv_aniidpid__(t(aas)ppta _ 00sttespaa1)5gg 1ee1a01))p0_ icdaaieppidvicc:icii 0edd1s:: D_ po23FIr
D00iFIIInDDDitVV o(IIDn)D :ooA nnPSM : BAAP0uP::1s i e23v
ce, BDF:0-20-0 SMBus controller enabled, sb revision is A15 sp5100_devices_por_init(): IDE Device, BDF:0-20-1 sp5100_devices_por_init(): LPC Device, BDF:0-20-3 sp5100_devices_por_init(): P2P Bridge, BDF:0-20-4 sp5100_devices_por_init(): SATA Device, BDF:0-18-0 sp5100_pmio_por_init()
Begin FIDVID MSR 0xc0010071 0x28ac0133 0x4c036840 FIDVID on BSP, APIC_id: 00 BSP fid = 10500 Wait for AP stage 1: ap_apicid = 1 readback = 1010501 common_fid(packed) = 10500 Wait for AP stage 1: ap_apicid = 2 readback = 2010501 common_fid(packed) = 10500 Wait for AP stage 1: ap_apicid = 3 readback = 3010501 common_fid(packed) = 10500 common_fid = 10500 FID Change Node:00, F3xD4: c8810025 End FIDVIDMSR 0xc0010071 0x28ac0133 0x4c036840 sr5650_htinit cpu_ht_freq=a. sr5650_htinit: HT3 mode ...WARM RESET...
coreboot-4.0-r717:718M Wed Apr 28 19:02:56 CST 2010 starting...
BSP Family_Model: 00100f43 *sysinfo range: [000cc000,000cf360] bsp_apicid = 00 cpu_init_detectedx = 00000000 microcode: equivalent rev id = 0x1043, current patch id = 0x00000000 microcode: patch id to apply = 0x010000b6 microcode: updated to patch id = 0x010000b6 success
cpuSetAMDMSR done Enter amd_ht_init() AMD_CB_EventNotify() event class: 05 event: 2006 data: 04 00 00 00 Exit amd_ht_init() cpuSetAMDPCI 00 done Prep FID/VID Node:00 F3x80: e600a681 F3x84: a0e641e6 F3xD4: c8810025 F3xD8: 00002e15 F3xDC: 00005334 core0 started: start_other_cores() init node: 00 cores: 03 Start other core - nodeid: 00 cores: 03 started ap apicid: cccooorrreeexxx::: --------- {{{ AAAPPPIIICCCIIIDDD === 0002 13 NNNOOODDDEEEIIIDDD === 000000 CCCOOORRREEEIIIDDD === 000132}}} ---------
quuummiiPiccc rrr01oooscccotooddadeeer:::te edeeqq iii* vvvaAaallPleee nnn02ttt s rrtreeearvvvt ieiidddd eee*=== 00A0xxxP 1110000434433s3,,,t arcccutuurrerrrrd tt nnt 000 pppsaraatt5tccc6hhh50 i_iidded ar===l 0y00xx_x000se000t0000u0000p0000(000)
g _cpmummi_iiccrcrrrevoooc ccoEooddAdeeeX=::: 0 pxppaa1attt00cccfhhh 4 ii3iddd. tttoooC PUaaap ppppRpllleyyyv =i== s 000 xxxK0008_1110100000000.0000 abb666f
m1mmmi0iicc_corrropooctccooiodddmieeez::: a uutupppiodddanaat(ttee)eddd xxx0ttsooro 56ppp5aaa0tttc_cchhph oiiir_ddd i ==n= it000 _ss 00111000000000000bbb666 sssuscpuucc5ccce1ees00sss e
ar l
MSSpccup_puSuseSeStetetutAMApAMDM()DMDM SR RRsp 5 d1 odd00noon_eneed ev
gge2iiinnciiiet_ttsf___ipffidoiddvr_vvidiii_ndd_si_sstttta()aage e e22 sp ap5aapi1piic00cci_iid:ddd: e: v0i2001c
s_por_init(): SMBus Device, BDF:0-20-0 SMBus controller enabled, sb revision is A15 sp5100_devices_por_init(): IDE Device, BDF:0-20-1 sp5100_devices_por_init(): LPC Device, BDF:0-20-3 sp5100_devices_por_init(): P2P Bridge, BDF:0-20-4 sp5100_devices_por_init(): SATA Device, BDF:0-18-0 sp5100_pmio_por_init()
Begin FIDVID MSR 0xc0010071 0x28ac0133 0x4c034c40 End FIDVIDMSR 0xc0010071 0x28ac0133 0x4c004c06 sr5650_htinit cpu_ht_freq=a. sr5650_htinit: HT3 mode fill_mem_ctrl() raminit_amdmct() raminit_amdmct begin: DIMMPresence: DIMMValid=1 DIMMPresence: DIMMPresent=1 DIMMPresence: RegDIMMPresent=0 DIMMPresence: DimmECCPresent=0 DIMMPresence: DimmPARPresent=0 DIMMPresence: Dimmx4Present=0 DIMMPresence: Dimmx8Present=1 DIMMPresence: Dimmx16Present=0 DIMMPresence: DimmPlPresent=0 DIMMPresence: DimmDRPresent=1 DIMMPresence: DimmQRPresent=0 DIMMPresence: DATAload[0]=2 DIMMPresence: MAload[0]=10 DIMMPresence: MAdimms[0]=1 DIMMPresence: DATAload[1]=0 DIMMPresence: MAload[1]=0 DIMMPresence: MAdimms[1]=0 DIMMPresence: Status 1000 DIMMPresence: ErrStatus 0 DIMMPresence: ErrCode 0 DIMMPresence: Done
DCTInit_D: mct_DIMMPresence Done SPDCalcWidth: Status 1000 SPDCalcWidth: ErrStatus 0 SPDCalcWidth: ErrCode 0 SPDCalcWidth: Done DCTInit_D: mct_SPDCalcWidth Done SPDGetTCL_D: DIMMCASL 4 SPDGetTCL_D: DIMMAutoSpeed 4 SPDGetTCL_D: Status 1000 SPDGetTCL_D: ErrStatus 0 SPDGetTCL_D: ErrCode 0 SPDGetTCL_D: Done
AutoCycTiming: Status 1000 AutoCycTiming: ErrStatus 0 AutoCycTiming: ErrCode 0 AutoCycTiming: Done
DCTInit_D: AutoCycTiming_D Done SPDSetBanks: CSPresent 3 SPDSetBanks: Status 1000 SPDSetBanks: ErrStatus 0 SPDSetBanks: ErrCode 0 SPDSetBanks: Done
AfterStitch pDCTstat->NodeSysBase = 0 mct_AfterStitchMemory: pDCTstat->NodeSysLimit = 7fffff StitchMemory: Status 1000 StitchMemory: ErrStatus 0 StitchMemory: ErrCode 0 StitchMemory: Done
InterleaveBanks_D: Status 1000 InterleaveBanks_D: ErrStatus 0 InterleaveBanks_D: ErrCode 0 InterleaveBanks_D: Done
AutoConfig_D: DramControl: 2a06 AutoConfig_D: DramTimingLo: 90092 AutoConfig_D: DramConfigMisc: 0 AutoConfig_D: DramConfigMisc2: 0 AutoConfig_D: DramConfigLo: 8010000 AutoConfig_D: DramConfigHi: f48000b AutoConfig: Status 1000 AutoConfig: ErrStatus 0 AutoConfig: ErrCode 0 AutoConfig: Done
DCTInit_D: AutoConfig_D Done DCTInit_D: PlatformSpec_D Done DCTInit_D: StartupDCT_D mctAutoInitMCT_D: SyncDCTsReady_D mctAutoInitMCT_D: HTMemMapInit_D Node: 00 base: 00 limit: 7fffff BottomIO: e00000 Node: 00 base: 03 limit: 7fffff Node: 01 base: 00 limit: 00 Node: 02 base: 00 limit: 00 Node: 03 base: 00 limit: 00 Node: 04 base: 00 limit: 00 Node: 05 base: 00 limit: 00 Node: 06 base: 00 limit: 00 Node: 07 base: 00 limit: 00 mctAutoInitMCT_D: CPUMemTyping_D CPUMemTyping: Cache32bTOP:800000 CPUMemTyping: Bottom32bIO:800000 CPUMemTyping: Bottom40bIO:0 mctAutoInitMCT_D: DQSTiming_D TrainRcvrEn: Status 1000 TrainRcvrEn: ErrStatus 0 TrainRcvrEn: ErrCode 0 TrainRcvrEn: Done
TrainDQSRdWrPos: Status 1000 TrainDQSRdWrPos: TrainErrors 0 TrainDQSRdWrPos: ErrStatus 0 TrainDQSRdWrPos: ErrCode 0 TrainDQSRdWrPos: Done
TrainDQSRdWrPos: Status 1000 TrainDQSRdWrPos: TrainErrors 0 TrainDQSRdWrPos: ErrStatus 0 TrainDQSRdWrPos: ErrCode 0 TrainDQSRdWrPos: Done
TrainDQSRdWrPos: Status 1000 TrainDQSRdWrPos: TrainErrors 0 TrainDQSRdWrPos: ErrStatus 0 TrainDQSRdWrPos: ErrCode 0 TrainDQSRdWrPos: Done
TrainDQSRdWrPos: Status 1000 TrainDQSRdWrPos: TrainErrors 0 TrainDQSRdWrPos: ErrStatus 0 TrainDQSRdWrPos: ErrCode 0 TrainDQSRdWrPos: Done
mctAutoInitMCT_D: UMAMemTyping_D mctAutoInitMCT_D: :OtherTiming InterleaveNodes_D: Status 1000 InterleaveNodes_D: ErrStatus 0 InterleaveNodes_D: ErrCode 0 InterleaveNodes_D: Done
InterleaveChannels_D: Node 0 InterleaveChannels_D: Status 1000 InterleaveChannels_D: ErrStatus 0 InterleaveChannels_D: ErrCode 0 InterleaveChannels_D: Node 1 InterleaveChannels_D: Status 1000 InterleaveChannels_D: ErrStatus 0 InterleaveChannels_D: ErrCode 0 InterleaveChannels_D: Node 2 InterleaveChannels_D: Status 1000 InterleaveChannels_D: ErrStatus 0 InterleaveChannels_D: ErrCode 0 InterleaveChannels_D: Node 3 InterleaveChannels_D: Status 1000 InterleaveChannels_D: ErrStatus 0 InterleaveChannels_D: ErrCode 0 InterleaveChannels_D: Node 4 InterleaveChannels_D: Status 1000 InterleaveChannels_D: ErrStatus 0 InterleaveChannels_D: ErrCode 0 InterleaveChannels_D: Node 5 InterleaveChannels_D: Status 1000 InterleaveChannels_D: ErrStatus 0 InterleaveChannels_D: ErrCode 0 InterleaveChannels_D: Node 6 InterleaveChannels_D: Status 1000 InterleaveChannels_D: ErrStatus 0 InterleaveChannels_D: ErrCode 0 InterleaveChannels_D: Node 7 InterleaveChannels_D: Status 1000 InterleaveChannels_D: ErrStatus 0 InterleaveChannels_D: ErrCode 0 InterleaveChannels_D: Done
mctAutoInitMCT_D: ECCInit_D All Done raminit_amdmct end:
*** Yes, the copy/decompress is taking a while, FIXME! 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 fffffd2e magic is 4f524243 Found CBFS header at fffffd2e Check fallback/romstage CBFS: follow chain: fff00000 + 38 + 17e39 + align -> fff17e80 Check fallback/coreboot_ram Stage: loading fallback/coreboot_ram @ 0x200000 (1245184 bytes), entry @ 0x200000 Stage: done loading. Jumping to image. coreboot-4.0-r717:718M Wed Apr 28 19:02:56 CST 2010 booting... Enumerating buses... Show all devs...Before Device Enumeration. Root Device: enabled 1, 0 resources APIC_CLUSTER: 0: enabled 1, 0 resources APIC: 00: enabled 1, 0 resources PCI_DOMAIN: 0000: enabled 1, 0 resources PCI: 00:18.0: enabled 1, 0 resources PCI: 00:00.0: enabled 1, 0 resources PCI: 00:02.0: enabled 1, 0 resources PCI: 00:03.0: enabled 1, 0 resources PCI: 00:04.0: enabled 0, 0 resources PCI: 00:05.0: enabled 0, 0 resources PCI: 00:06.0: enabled 0, 0 resources PCI: 00:07.0: enabled 0, 0 resources PCI: 00:08.0: enabled 0, 0 resources PCI: 00:09.0: enabled 0, 0 resources PCI: 00:0a.0: enabled 0, 0 resources PCI: 00:0b.0: enabled 0, 0 resources
-----Original Message----- From: coreboot-bounces@coreboot.org
[mailto:coreboot-bounces@coreboot.org]
On Behalf Of Ed Swierk Sent: Wednesday, April 28, 2010 3:14 PM To: Coreboot Cc: Marc Jones Subject: [coreboot] Porting to RS780/SB700 board
I'm attempting to port Coreboot to an Asus M4A78XTD board, which has an RS780/SB700 chipset with a socket AM3 (Fam10h+DDR3) CPU.
Starting with the tilapia_10h mainboard code, the first problem I'm hitting occurs very early on: any attempt to call pci_locate_device(), for example in sb700_lpc_init(), hangs forever (or at least longer than I'm willing to wait), unless I disable all the PCIe bridges on the 780 by inserting the following into enable_rs780_dev8():
set_nbmisc_enable_bits(PCI_DEV(0, 0, 0), 0x0c, 0, 0x000300fc);
If I leave even one of the bridges enabled, I get the hang. See section 2.5.6 in
http://support.amd.com/us/Embedded_TechDocs/43291_rs780_rpr_pub_1.01.pdf
for a description of this register.
With the PCIe bridges out of the picture, I get through memory initialization (woo hoo!), but for some reason ram_fill() and ram_verify() take many minutes to complete, and it hangs shortly thereafter. Boot log attached.
Any clues would be appreciated!
--Ed
-
Bao, Zheng -
Ed Swierk -
Marc Jones -
Myles Watson -
Patrick Georgi -
Rudolf Marek