Re: [coreboot] how to delete symbol link created at compile time

[She, Kerry]

> -----Original Message-----
> From: Marc Jones [mailto:[e-mail]]
> Sent: Tuesday, October 18, 2011 10:39 AM
> To: Stefan Reinauer
> Cc: She, Kerry; coreboot
> Subject: Re: [coreboot] how to delete symbol link created at compile time
>
> On Mon, Oct 17, 2011 at 4:44 PM, Stefan Reinauer
>  wrote:
> > Marc Jones  [111016 10:10]:
> > > > > > I have created 2 devicetree file :
> > > > > >
> > > > > > devicetree_f15.cb for platform with family 15 CPU
> > > > > >
> > > > > > devicetree_f10.cb  for platform with family 10 CPU
> > > > > >
> > > > > > I changed the makefile to create a symbol link "devicetree.cb"
>
> link to
> > > > > > devicetree_f10.cb or devicetree_f15.cb at compile time.
> > > > > >
> > > > > > The problem is that I can't delete the symbol link when make
> > > > > > clean/distclean.
> > > >
> > > > Please fix the problem by using one device tree for both platforms.
> > > Stefan,
> > >
> > > Can you explain your thoughts on how that would work? Can we put a #if
> > > in the devicetree.cb? It uses the c precompiler? It requires different
> > > CPU files/device locations.  We can try it next week.
> >
> > Usually the way this is handled in coreboot is that there is one socket
> > that binds together all CPU types. Then in the device tree only the
> > socket type is specified, and code for both CPUs is pulled in.
> > Maybe we need something like a socket for northbridge code, since the
> > northbridge now lives in the CPU?
> >
> > It seems like a bad idea to have to recompile your BIOS because you
> > change the CPU. We did a lot of nastyness with K8 and Fam10, but we
> > should find a better way to do this for future chipsets/CPUs.
>
> Yes, we are discussing how the AGESA code would work. The socket
> decision is rather complicated as we need a way to handle multiple
> calls with the same names (function point tables etc). I think that
> there may be a solution within AGESA, but the device tree may still be
> a problem as the CPUs have different HT link numbering. This makes it
> hard to have the same device tree layout for the same socket.

Because of the function name conflict, put cpu code of 2 families together would not compile.
We need to dig into AGESA more to figure out a solution.
As for the devicetree problem, following text is the devicetree difference in detail:

--- devicetree_fam10.cb	2011-08-15 15:00:14.426692437 +0800
+++ devicetree_fam15.cb	2011-08-15 15:00:14.426692437 +0800
@@ -16,19 +16,17 @@
 # along with this program; if not, write to the Free Software
 # Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
 #
-chip northbridge/amd/agesa/family10/root_complex
+chip northbridge/amd/agesa/family15/root_complex
    device lapic_cluster 0 on
-		chip cpu/amd/agesa/family10
-			device lapic 0x10 on end
+		chip cpu/amd/agesa/family15
+			device lapic 0x20 on end
    	end
    end
    device pci_domain 0 on
    	subsystemid 0x15d9 0xab11 inherit #SuperMicro
-		chip northbridge/amd/agesa/family10 # CPU side of HT root complex
-			device pci 18.0 on end # link 0
-			device pci 18.0 on end # link 1
-			device pci 18.0 on end # link 2
-			device pci 18.0 on     # link 3, SB on socket0 link 2, on internal Node0 Link 3
+		chip northbridge/amd/agesa/family15 # CPU side of HT root complex
+			device pci 18.0 on end # Link 0
+			device pci 18.0 on     # Link 1, IO-HUB on socket0 link 2(internal Node0 Link 1)
    			chip northbridge/amd/cimx/rd890 # Southbridge PCI side of HT Root complex
    				device pci 0.0 on  end # HT Root Complex 0x9600

Issues with Supermicro H8SCM

[Samir Ibradžić]

Hello Kerry, Thomas, Marc,

I got this board for a personal server project, as well as test platform 
to dive into coreboot. Board is H8SCM-F rev 1.02, one with BMC. Had 
build nice external FT2232 programmer for bailing out of broken flash 
situation, works great. I've experimented with recent coreboot revision, 
ea5c2b6 + Kerry's AGESA patches (thanks a bunch!), and had experienced 
same problem as Thomas, plus some more;

1. Two DIMMs in dual-channel setup wont work, same issue as Thomas, 
2x4GB ECC DIMMs here.

2. After booting via coreboot with same Linux distro, SR5850 NorthBridge 
heatsink instantly gets much more hot than booting via SuperMicro BIOS. 
The temperature is MUCH higher, on idle system, though i can not measure 
this by other method than putting my finger there, and i got instantly 
BURNED when coreboot is being used. I am afraid to fry my board if it 
runs longer this way, it is really that hot.

3. HPET is not being reported at all by coreboot ACPI, OS timer 
precision suffers big deal. Dont know if this is a feature or bug? Dmesg 
clearly shows the difference, all these lines are missing when booting 
via coreboot:

# dmesg | grep -i hpet
[    0.000000] ACPI: HPET 00000000cfeaa5e0 00038 (v01 062911 OEMHPET 
20110629 MSFT 00000097)
[    0.000000] ACPI: HPET id: 0x8300 base: 0xfed00000
[    0.000000] hpet clockevent registered
[    1.132106] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0
[    1.140072] hpet0: 4 comparators, 32-bit 14.318180 MHz counter
[    1.146104] Switching to clocksource hpet
[    3.499557] rtc0: alarms up to one month, y3k, 114 bytes nvram, hpet irqs

4. CPU (got 4170 HE) frequency scaling only goes as low as 1800MHz in 
coreboot when idle. SuperMicro BIOS easily goes all the way down to 
800MHz. Spotted this in /proc/cpuinfo

5. USB/EHCI - i haven't really tested this, but it seems minor compared 
to 1 & 2.

Now, i know this board is not exactly supported, most probably being an 
AGESA problem, but i would really like to do my best to help to make it 
work better if possible.

@ Kerry,

I was trying to analyze some AGESA code to get to the DIMM problem, but 
most of it is a mystery to me. Could you please point me to the right 
place for "DRAM training" in the code, i am willing to invest some time 
and nerves to test & investigate this, as well as NB overheating 
problem. Any plans to update those AGESA patches for this board?

One strange thing about RAM init is that the coreboot somehow thinks the 
board has 8 slots, but it has only four (there should be no channels 2 & 3);

Socket 0 Channel 0 Dimm 0 found dimm: 00400745
Socket 0 Channel 0 Dimm 1 not found dimm
Socket 0 Channel 1 Dimm 0 found dimm: 00400947
Socket 0 Channel 1 Dimm 1 not found dimm
Socket 0 Channel 2 Dimm 0 not found dimm
Socket 0 Channel 2 Dimm 1 not found dimm
Socket 0 Channel 3 Dimm 0 not found dimm
Socket 0 Channel 3 Dimm 1 not found dimm
  Dct 0 Channel 0
   RegDimmPresent:    1
   SODimmPresent:     0
   ChDimmValid:       1
   DimmPlPresent:     0
   DimmQrPresent:     0
   DimmDrPresent:     0
   DimmSRPresent:     1
   Dimmx4Present:     1
   DimmX8Present:     0
   DimmX16Present:    0
   DimmMirrorPresent: 0
  Dct 1 Channel 0
   RegDimmPresent:    1
   SODimmPresent:     0
   ChDimmValid:       1
   DimmPlPresent:     0
   DimmQrPresent:     0
   DimmDrPresent:     0
   DimmSRPresent:     1
   Dimmx4Present:     1
   DimmX8Present:     0
   DimmX16Present:    0
   DimmMirrorPresent: 0
ASSERTION FAILED: file 
'src/vendorcode/amd/agesa/f10/Proc/Mem/Main/C32/mmflowC32.c',  line 163

Thanks,
Samir

Issues with Supermicro H8SCM

[She, Kerry]

Hello, Samir
> -----Original Message-----
> From: Samir Ibradžić [mailto:[e-mail]]
> Sent: Monday, November 21, 2011 1:35 AM
> To: She, Kerry
> Cc: Thomas Gstädtner; Marc Jones; coreboot
> Subject: Re: [coreboot] Issues with Supermicro H8SCM
>
> Hello Kerry, Thomas, Marc,
>
> I got this board for a personal server project, as well as test platform
> to dive into coreboot. Board is H8SCM-F rev 1.02, one with BMC. Had
> build nice external FT2232 programmer for bailing out of broken flash
> situation, works great. I've experimented with recent coreboot revision,
> ea5c2b6 + Kerry's AGESA patches (thanks a bunch!), and had experienced
> same problem as Thomas, plus some more;
> Two DIMMs in dual-channel setup wont work, same issue as Thomas,
>
> 2x4GB ECC DIMMs here.
> After booting via coreboot with same Linux distro, SR5850 NorthBridge
>
> heatsink instantly gets much more hot than booting via SuperMicro BIOS.
> The temperature is MUCH higher, on idle system, though i can not measure
> this by other method than putting my finger there, and i got instantly
> BURNED when coreboot is being used. I am afraid to fry my board if it
> runs longer this way, it is really that hot.

The hardware monitor is not enable in coreboot.
> HPET is not being reported at all by coreboot ACPI, OS timer
>
> precision suffers big deal. Dont know if this is a feature or bug? Dmesg
> clearly shows the difference, all these lines are missing when booting
> via coreboot:
>
> # dmesg | grep -i hpet
> [    0.000000] ACPI: HPET 00000000cfeaa5e0 00038 (v01 062911 OEMHPET
> 20110629 MSFT 00000097)
> [    0.000000] ACPI: HPET id: 0x8300 base: 0xfed00000
> [    0.000000] hpet clockevent registered
> [    1.132106] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0
> [    1.140072] hpet0: 4 comparators, 32-bit 14.318180 MHz counter
> [    1.146104] Switching to clocksource hpet
> [    3.499557] rtc0: alarms up to one month, y3k, 114 bytes nvram, hpet
> irqs
> CPU (got 4170 HE) frequency scaling only goes as low as 1800MHz in
>
> coreboot when idle. SuperMicro BIOS easily goes all the way down to
> 800MHz. Spotted this in /proc/cpuinfo
> USB/EHCI - i haven't really tested this, but it seems minor compared
>
> to 1 & 2.

Kevin have fixed some usb-msc bugs in seabios recently,
you may need to check the seabios maillist.
> Now, i know this board is not exactly supported, most probably being an
> AGESA problem, but i would really like to do my best to help to make it
> work better if possible.
>
> @ Kerry,
>
> I was trying to analyze some AGESA code to get to the DIMM problem, but
> most of it is a mystery to me. Could you please point me to the right
> place for "DRAM training" in the code, i am willing to invest some time
> and nerves to test & investigate this, as well as NB overheating
> problem. Any plans to update those AGESA patches for this board?

We have made some update for h8scm mainboard.
In order to support new Orochi platform,
Except the mainboard code, agesa wrapper, sr56x0 cimx wrapper and
sb700/sp5100 cimx wrapper are also included in the change set.
But the patch set still pending to release to the community for review.
We need some time to get the release process done.
Hope the code would be available soon.
> One strange thing about RAM init is that the coreboot somehow thinks the
> board has 8 slots, but it has only four (there should be no channels 2 &
> 3);

AGESA support 4 channels.
But family10 processor for h8scm only have 2 channels.
> Socket 0 Channel 0 Dimm 0 found dimm: 00400745
> Socket 0 Channel 0 Dimm 1 not found dimm
> Socket 0 Channel 1 Dimm 0 found dimm: 00400947
> Socket 0 Channel 1 Dimm 1 not found dimm
> Socket 0 Channel 2 Dimm 0 not found dimm
> Socket 0 Channel 2 Dimm 1 not found dimm
> Socket 0 Channel 3 Dimm 0 not found dimm
> Socket 0 Channel 3 Dimm 1 not found dimm
>   Dct 0 Channel 0
>    RegDimmPresent:    1
>    SODimmPresent:     0
>    ChDimmValid:       1
>    DimmPlPresent:     0
>    DimmQrPresent:     0
>    DimmDrPresent:     0
>    DimmSRPresent:     1
>    Dimmx4Present:     1
>    DimmX8Present:     0
>    DimmX16Present:    0
>    DimmMirrorPresent: 0
>   Dct 1 Channel 0
>    RegDimmPresent:    1
>    SODimmPresent:     0
>    ChDimmValid:       1
>    DimmPlPresent:     0
>    DimmQrPresent:     0
>    DimmDrPresent:     0
>    DimmSRPresent:     1
>    Dimmx4Present:     1
>    DimmX8Present:     0
>    DimmX16Present:    0
>    DimmMirrorPresent: 0
> ASSERTION FAILED: file
> 'src/vendorcode/amd/agesa/f10/Proc/Mem/Main/C32/mmflowC32.c',  line 163

Maybe a dimm spd address problem, you can try following patch:
--- a/src/mainboard/supermicro/h8scm_fam10/dimmSpd.c
+++ b/src/mainboard/supermicro/h8scm_fam10/dimmSpd.c
@@ -55,8 +55,11 @@ static void sp5100_set_gpio(u8 reg, u8 out, u8 enable)
 static const UINT8 spdAddressLookup [1] [2] [2] = { // socket, channel, dimm
        /* socket 0 */
        {
-               {0xA6, 0xA4},
-               {0xA2, 0xA0},
+               /* silkprint: DIMM1A DIMM2A DIMM1B DIMM2B
+                * i2c addr:    A6     A2     A4     A0
+                */
+               {0xA4, 0xA6},
+               {0xA0, 0xA2},
        },
 };

Thanks
Kerry

Issues with Supermicro H8SCM

[Samir Ibradžić]

Kairui,

I honestly appreciate your help.

On 2011年11月21日 12:00, She, Kerry wrote:
> Hello, Samir
> > -----Original Message-----
> > From: Samir Ibradžić [mailto:[e-mail]]
> > Sent: Monday, November 21, 2011 1:35 AM
> > To: She, Kerry
> > Cc: Thomas Gstädtner; Marc Jones; coreboot
> > Subject: Re: [coreboot] Issues with Supermicro H8SCM
> >
> > Hello Kerry, Thomas, Marc,
> >
> > I got this board for a personal server project, as well as test platform
> > to dive into coreboot. Board is H8SCM-F rev 1.02, one with BMC. Had
> > build nice external FT2232 programmer for bailing out of broken flash
> > situation, works great. I've experimented with recent coreboot revision,
> > ea5c2b6 + Kerry's AGESA patches (thanks a bunch!), and had experienced
> > same problem as Thomas, plus some more;
> > Two DIMMs in dual-channel setup wont work, same issue as Thomas,
> >
> > 2x4GB ECC DIMMs here.
> > After booting via coreboot with same Linux distro, SR5850 NorthBridge
> >
> > heatsink instantly gets much more hot than booting via SuperMicro BIOS.
> > The temperature is MUCH higher, on idle system, though i can not measure
> > this by other method than putting my finger there, and i got instantly
> > BURNED when coreboot is being used. I am afraid to fry my board if it
> > runs longer this way, it is really that hot.
>
> The hardware monitor is not enable in coreboot.

Not sure what do you mean by that. SR56x0 power management is not 
working in coreboot? It really gets dangerously hot. If only there was 
some workaround for this, i would switch 100% to corebot.
> > HPET is not being reported at all by coreboot ACPI, OS timer
> >
> > precision suffers big deal. Dont know if this is a feature or bug? Dmesg
> > clearly shows the difference, all these lines are missing when booting
> > via coreboot:
> >
> > # dmesg | grep -i hpet
> > [    0.000000] ACPI: HPET 00000000cfeaa5e0 00038 (v01 062911 OEMHPET
> > 20110629 MSFT 00000097)
> > [    0.000000] ACPI: HPET id: 0x8300 base: 0xfed00000
> > [    0.000000] hpet clockevent registered
> > [    1.132106] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0
> > [    1.140072] hpet0: 4 comparators, 32-bit 14.318180 MHz counter
> > [    1.146104] Switching to clocksource hpet
> > [    3.499557] rtc0: alarms up to one month, y3k, 114 bytes nvram, hpet
> > irqs

Nothing about this?
> > CPU (got 4170 HE) frequency scaling only goes as low as 1800MHz in
> >
> > coreboot when idle. SuperMicro BIOS easily goes all the way down to
> > 800MHz. Spotted this in /proc/cpuinfo
> > USB/EHCI - i haven't really tested this, but it seems minor compared
> >
> > to 1&  2.
>
> Kevin have fixed some usb-msc bugs in seabios recently,
> you may need to check the seabios maillist.
> > Now, i know this board is not exactly supported, most probably being an
> > AGESA problem, but i would really like to do my best to help to make it
> > work better if possible.
> >
> > @ Kerry,
> >
> > I was trying to analyze some AGESA code to get to the DIMM problem, but
> > most of it is a mystery to me. Could you please point me to the right
> > place for "DRAM training" in the code, i am willing to invest some time
> > and nerves to test&  investigate this, as well as NB overheating
> > problem. Any plans to update those AGESA patches for this board?
>
> We have made some update for h8scm mainboard.
> In order to support new Orochi platform,
> Except the mainboard code, agesa wrapper, sr56x0 cimx wrapper and
> sb700/sp5100 cimx wrapper are also included in the change set.
> But the patch set still pending to release to the community for review.
> We need some time to get the release process done.
> Hope the code would be available soon.

I am really looking forward for this update. Latest coreboot git head 
will not compile with your previous patches, something got broken again.
> > One strange thing about RAM init is that the coreboot somehow thinks the
> > board has 8 slots, but it has only four (there should be no channels 2&
> > 3);
>
> AGESA support 4 channels.
> But family10 processor for h8scm only have 2 channels.
> > Socket 0 Channel 0 Dimm 0 found dimm: 00400745
> > Socket 0 Channel 0 Dimm 1 not found dimm
> > Socket 0 Channel 1 Dimm 0 found dimm: 00400947
> > Socket 0 Channel 1 Dimm 1 not found dimm
> > Socket 0 Channel 2 Dimm 0 not found dimm
> > Socket 0 Channel 2 Dimm 1 not found dimm
> > Socket 0 Channel 3 Dimm 0 not found dimm
> > Socket 0 Channel 3 Dimm 1 not found dimm
> >    Dct 0 Channel 0
> >     RegDimmPresent:    1
> >     SODimmPresent:     0
> >     ChDimmValid:       1
> >     DimmPlPresent:     0
> >     DimmQrPresent:     0
> >     DimmDrPresent:     0
> >     DimmSRPresent:     1
> >     Dimmx4Present:     1
> >     DimmX8Present:     0
> >     DimmX16Present:    0
> >     DimmMirrorPresent: 0
> >    Dct 1 Channel 0
> >     RegDimmPresent:    1
> >     SODimmPresent:     0
> >     ChDimmValid:       1
> >     DimmPlPresent:     0
> >     DimmQrPresent:     0
> >     DimmDrPresent:     0
> >     DimmSRPresent:     1
> >     Dimmx4Present:     1
> >     DimmX8Present:     0
> >     DimmX16Present:    0
> >     DimmMirrorPresent: 0
> > ASSERTION FAILED: file
> > 'src/vendorcode/amd/agesa/f10/Proc/Mem/Main/C32/mmflowC32.c',  line 163
>
> Maybe a dimm spd address problem, you can try following patch:
> --- a/src/mainboard/supermicro/h8scm_fam10/dimmSpd.c
> +++ b/src/mainboard/supermicro/h8scm_fam10/dimmSpd.c
> @@ -55,8 +55,11 @@ static void sp5100_set_gpio(u8 reg, u8 out, u8 enable)
>   static const UINT8 spdAddressLookup [1] [2] [2] = { // socket, channel, dimm
>          /* socket 0 */
>          {
>           {0xA6, 0xA4},
>           {0xA2, 0xA0},
>           /* silkprint: DIMM1A DIMM2A DIMM1B DIMM2B
>            * i2c addr:    A6     A2     A4     A0
>            */
>           {0xA4, 0xA6},
>           {0xA0, 0xA2},
>    },
> };

Tested-by: Samir Ibradžić

Thanks, looks like this had fixed the issue!

Socket 0 Channel 0 Dimm 0 not found dimm
Socket 0 Channel 0 Dimm 1 found dimm: 00400846
Socket 0 Channel 1 Dimm 0 not found dimm
Socket 0 Channel 1 Dimm 1 found dimm: 00400a48
Socket 0 Channel 2 Dimm 0 not found dimm
Socket 0 Channel 2 Dimm 1 not found dimm
Socket 0 Channel 3 Dimm 0 not found dimm
Socket 0 Channel 3 Dimm 1 not found dimm
  Dct 0 Channel 0
   RegDimmPresent:    2
   SODimmPresent:     0
   ChDimmValid:       2
   DimmPlPresent:     0
   DimmQrPresent:     0
   DimmDrPresent:     0
   DimmSRPresent:     2
   Dimmx4Present:     2
   DimmX8Present:     0
   DimmX16Present:    0
   DimmMirrorPresent: 0
  Dct 1 Channel 0
   RegDimmPresent:    2
   SODimmPresent:     0
   ChDimmValid:       2
   DimmPlPresent:     0
   DimmQrPresent:     0
   DimmDrPresent:     0
   DimmSRPresent:     2
   Dimmx4Present:     2
   DimmX8Present:     0
   DimmX16Present:    0
   DimmMirrorPresent: 0
BSP Frequency: 2100MHz
agesawrapper_amdinitpost passed
agesawrapper_amdinitenv passed
> Thanks
> Kerry

Thanks,
Samir

Issues with Supermicro H8SCM

[Samir Ibradžić]

Hello Kerry, Zheng Bao,

I was doing some tests with Coreboot on Supermicro H8SCM(-F) couple of 
months back. Now i have much more time to spare to experiment with 
Coreboot, so just wondering, are there any updates regarding this board?

It looks like Trinity & Parmer boards received many updates, just 
wondering if these apply to H8SCM, mainly interested in F15 support & IOMMU.

Thanks,
Samir