[Skiboot] Support for DIMM without ECC

[Alexandre Ghiti]

Le jeu. 18 avr. 2019 à 21:51, Dean Sanner <dsanner at us.ibm.com> a écrit :

> Hi Alexandre,
>
> I'm suspecting not so much of a reset... but that the skiboot code is
> targeting the wrong unit within the chip.  Hostboot has a feature
> on scom addresses that do translation based on which target you are
> attempting to access.  The raw skiboot access will only return the
> zero'th unit (skiboot expects the user to do the scom translation).
>
> > > [   51.504955724,5] CHIP: Chip ID 0000 type: P9N
> > > DD2.2^M
> > > [   51.504992069,3] UPMEM: __xscom_read: gcid, read address gcid:0x0
> > > 0x0x603fc38085050
>
> This is socket 0 (base Xscom address of 0x603fc00000000) and the scom
> address
> is 0x7010A0A  (0x38085050>>3)
>
> > >  51.72614|FAPI|call_host_start_payload.C: UPMEM: 0x7010a0a value is :
> > > *0x8890a23810800000*^M
> > >  51.72616|FAPI|call_host_start_payload.C: UPMEM:* PIR: 0x80d*^M
>
> I'm guessing this is not on the zero'th instance of the memory controller
> in the chip (there are 8 per socket).  Can you also print out the HUID
> to be sure (TARGETING::get_huid(i_target))?
>
> The addresses of the 8 memory controllers in the chip are:
> 07010A0A
> 07010A4A
> 07010A8A
> 07010ACA
> 08010A0A
> 08010A4A
> 08010A8A
> 08010ACA
>
>
HUID gave me:  0x240005 and this is the output of ALL the memory controllers
from skiboot:

[   51.131975420,3] XXXXX: chip: 0 addr: 0000000007010a0a = 0a10603810800000
[   51.132051318,3] XXXXX: chip: 0 addr: 0000000007010a4a = 0a10603810800000
[   51.132107445,3] XXXXX: chip: 0 addr: 0000000007010a8a = 0a10603810800000
[   51.132164424,3] XXXXX: chip: 0 addr: 0000000007010aca = 0a10603810800000
[   51.132219694,3] XXXXX: chip: 0 addr: 0000000008010a0a = 0a10603810800000
*[   51.132270030,3] XXXXX: chip: 0 addr: 0000000008010a4a =
8890a23810800000*
[   51.132314136,3] XXXXX: chip: 0 addr: 0000000008010a8a = 0a10603810800000
[   51.132359437,3] XXXXX: chip: 0 addr: 0000000008010aca = 0a10603810800000
[   51.132408643,3] XXXXX: chip: 8 addr: 0000000007010a0a = 0a10603810800000
[   51.132472784,3] XXXXX: chip: 8 addr: 0000000007010a4a = 0a10603810800000
[   51.132529917,3] XXXXX: chip: 8 addr: 0000000007010a8a = 0a10603810800000
[   51.132595065,3] XXXXX: chip: 8 addr: 0000000007010aca = 0a10603810800000
[   51.132648960,3] XXXXX: chip: 8 addr: 0000000008010a0a = 0a10603810800000
[   51.132698377,3] XXXXX: chip: 8 addr: 0000000008010a4a = 0a10603810800000
[   51.132746432,3] XXXXX: chip: 8 addr: 0000000008010a8a = 0a10603810800000
[   51.132798168,3] XXXXX: chip: 8 addr: 0000000008010aca = 0a10603810800000


So I now understand what you mean: hostboot turned 0x7010a0a into 0x8010a4a
when it
saw that p was the fifth MC.

 FAPI_TRY(fapi2::getScom(p, 0x7010a0a, o_buffer), "UPMEM: Failed to read
recr");
 FAPI_INF("UPMEM: @0x7010a0a HUID = %u, value is : 0x%llx",
TARGETING::get_huid(p), o_buffer);


Ok that's good to know, I'll take care of this address translation in the
future !

Thank you everyone for your answers, very helpful.

Alex


> Please let me know if this doesn't help, and I'll dig into the code
> further.
>
>
> Dean Sanner
> Dept. DIH, IBM Rochester, MN
> (507) 253-7523 t/l 553-7523
> dsanner at us.ibm.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/skiboot/attachments/20190419/0c69801f/attachment.htm>