[v4,1/2] arm: rmobile: Add PRR CPU ID macros for RZ/G2[HMNE]

RZ/G2 SoC's are identical to R-Car Gen3 SoC's apart from some
automotive peripherals and they also share the same PRR CPU ID's.

RZ/G2H (a.k.a R8A774E1) is identical to R-Car H3 SoC.
RZ/G2M (a.k.a R8A774A1) is identical to R-Car M3W SoC.
RZ/G2N (a.k.a R8A774B1) is identical to R-Car M3N SoC.
RZ/G2E (a.k.a R8A774C0) is identical to R-Car E3 SoC.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
 v3->v4
   * Dropped CPU info reporting logic for RZ/G2. Will address this later.
   * Added PRRID's for RZG2[HMNE]

 v2->v3  
   * Reworked as per Marek's suggestion
   * Added rzg2_get_cpu_type function to get cpu_type by matching TFA compatible string
   * Removed SoC family type Enum
   (Ref: https://patchwork.ozlabs.org/project/uboot/patch/20200922160317.16296-2-biju.das.jz@bp.renesas.com/)

 v1->v2:
  * Add comment's related to loop logic
   (ref: https://patchwork.ozlabs.org/project/uboot/patch/20200918160307.14323-1-biju.das.jz@bp.renesas.com/)

 v1:
  * New patch
  (ref:https://patchwork.ozlabs.org/project/uboot/patch/20200915143630.7678-4-biju.das.jz@bp.renesas.com/)
	
---
 arch/arm/mach-rmobile/include/mach/rmobile.h | 4 ++++
 1 file changed, 4 insertions(+)

On 10/1/20 12:36 PM, Biju Das wrote:
[...]

> diff --git a/arch/arm/mach-rmobile/include/mach/rmobile.h b/arch/arm/mach-rmobile/include/mach/rmobile.h
> index a50249dc96..bd4bd01b75 100644
> --- a/arch/arm/mach-rmobile/include/mach/rmobile.h
> +++ b/arch/arm/mach-rmobile/include/mach/rmobile.h
> @@ -27,6 +27,10 @@
>  /* PRR CPU IDs */
>  #define RMOBILE_CPU_TYPE_SH73A0		0x37
>  #define RMOBILE_CPU_TYPE_R8A7740	0x40
> +#define RMOBILE_CPU_TYPE_R8A774A1	0x52

The problem here is that this is the same as
#define RMOBILE_CPU_TYPE_R8A7796   0x52

So if you use that ^ in the code, you cannot discern it from
RMOBILE_CPU_TYPE_R8A774A1 .

We really need to find a way to tell these two apart first, e.g. by
checking the bootrom, and then use it in U-Boot all over the place.

Hi Marek,

Thanks for the feedback.

> Subject: Re: [PATCH v4 1/2] arm: rmobile: Add PRR CPU ID macros for
> RZ/G2[HMNE]
>
> On 10/1/20 12:36 PM, Biju Das wrote:
> [...]
>
> > diff --git a/arch/arm/mach-rmobile/include/mach/rmobile.h
> > b/arch/arm/mach-rmobile/include/mach/rmobile.h
> > index a50249dc96..bd4bd01b75 100644
> > --- a/arch/arm/mach-rmobile/include/mach/rmobile.h
> > +++ b/arch/arm/mach-rmobile/include/mach/rmobile.h
> > @@ -27,6 +27,10 @@
> >  /* PRR CPU IDs */
> >  #define RMOBILE_CPU_TYPE_SH73A00x37
> >  #define RMOBILE_CPU_TYPE_R8A77400x40
> > +#define RMOBILE_CPU_TYPE_R8A774A10x52
>
> The problem here is that this is the same as
> #define RMOBILE_CPU_TYPE_R8A7796   0x52
>
> So if you use that ^ in the code, you cannot discern it from
> RMOBILE_CPU_TYPE_R8A774A1 .

But this value is same as per the hardware manual, see the definitions in linux[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/soc/renesas/renesas-soc.c?h=v5.9-rc7#n114
Please correct me, if this macros are not as per hardware manual.

> We really need to find a way to tell these two apart first, e.g. by checking the
> bootrom, and then use it in U-Boot all over the place.

Yes, I agree we need to differentiate them. Different ways I can think of is

1) Bootrom level
2) Checking some IP register which is present in RCar and not in RZ/G2
3) Compatible SoC string from TFA
4) TFA there will be separation for RZ/G2 SoC and RCar Gen3 SoC, So populate some dtfragment for RCar/RZG2 SoC similar to dram and u-boot handling it for SoC separation.
5) Use compile time macros in U-boot.

Please let me you know, which is the best way to go forward and also let me know, if you have any other ideas in your mind.

Regards,
Biju





Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647

On 10/3/20 9:31 PM, Biju Das wrote:

Hi,

[...]

>>>  /* PRR CPU IDs */
>>>  #define RMOBILE_CPU_TYPE_SH73A00x37
>>>  #define RMOBILE_CPU_TYPE_R8A77400x40
>>> +#define RMOBILE_CPU_TYPE_R8A774A10x52
>>
>> The problem here is that this is the same as
>> #define RMOBILE_CPU_TYPE_R8A7796   0x52
>>
>> So if you use that ^ in the code, you cannot discern it from
>> RMOBILE_CPU_TYPE_R8A774A1 .
> 
> But this value is same as per the hardware manual, see the definitions in linux[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/soc/renesas/renesas-soc.c?h=v5.9-rc7#n114
> Please correct me, if this macros are not as per hardware manual.

This is not what I am complaining about. See for example the output of
$ git grep RMOBILE_CPU_TYPE_
...
drivers/mmc/renesas-sdhi.c:     if (((rmobile_get_cpu_type() ==
RMOBILE_CPU_TYPE_R8A7795) &&
drivers/mmc/renesas-sdhi.c:         ((rmobile_get_cpu_type() ==
RMOBILE_CPU_TYPE_R8A7796) &&
drivers/net/ravb.c:     if ((rmobile_get_cpu_type() ==
RMOBILE_CPU_TYPE_R8A77990) ||
drivers/net/ravb.c:         (rmobile_get_cpu_type() ==
RMOBILE_CPU_TYPE_R8A77995))

These tests will no longer work on RZG as they should (the test to match
on RMOBILE_CPU_TYPE_R8A7796 will also match on RMOBILE_CPU_TYPE_R8A774A1
and that might not be what is expected). So there needs to be some way
to implement match on RZG-only.

So we will need some rmobile_cpu_match(RMOBILE_CPU_TYPE_R8A7796)
function, which will match on 7796 only and if it is called with
RMOBILE_CPU_TYPE_R8A774A1 it will not match (assuming the SoC on which
it is running is 7796).

>> We really need to find a way to tell these two apart first, e.g. by checking the
>> bootrom, and then use it in U-Boot all over the place.
> 
> Yes, I agree we need to differentiate them. Different ways I can think of is
> 
> 1) Bootrom level
> 2) Checking some IP register which is present in RCar and not in RZ/G2

Did you make any progress on these two ?

> 3) Compatible SoC string from TFA

This only shifts the problem into TFA, so now TFA has to figure out a
way to discern RZG and RCar. Surely one can argue that TFA is built for
a specific SoC, so this could be a no-problem.

> 4) TFA there will be separation for RZ/G2 SoC and RCar Gen3 SoC, So populate some dtfragment for RCar/RZG2 SoC similar to dram and u-boot handling it for SoC separation.
> 5) Use compile time macros in U-boot.

No, we worked too hard to make things based purely on DT and get rid of
compile-time macros, so lets not put those back.

> Please let me you know, which is the best way to go forward and also let me know, if you have any other ideas in your mind.

I would highly prefer 1) or 2) if possible.

Hi Marek,

Thanks for the feedback.

> Subject: Re: [PATCH v4 1/2] arm: rmobile: Add PRR CPU ID macros for
> RZ/G2[HMNE]
>
> On 10/3/20 9:31 PM, Biju Das wrote:
>
> Hi,
>
> [...]
>
> >>>  /* PRR CPU IDs */
> >>>  #define RMOBILE_CPU_TYPE_SH73A00x37  #define
> >>> RMOBILE_CPU_TYPE_R8A77400x40
> >>> +#define RMOBILE_CPU_TYPE_R8A774A10x52
> >>
> >> The problem here is that this is the same as
> >> #define RMOBILE_CPU_TYPE_R8A7796   0x52
> >>
> >> So if you use that ^ in the code, you cannot discern it from
> >> RMOBILE_CPU_TYPE_R8A774A1 .
> >
> > But this value is same as per the hardware manual, see the definitions
> > in linux[1]
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tre
> > e/drivers/soc/renesas/renesas-soc.c?h=v5.9-rc7#n114
> > Please correct me, if this macros are not as per hardware manual.
>
> This is not what I am complaining about. See for example the output of $ git
> grep RMOBILE_CPU_TYPE_ ...
> drivers/mmc/renesas-sdhi.c:     if (((rmobile_get_cpu_type() ==
> RMOBILE_CPU_TYPE_R8A7795) &&
> drivers/mmc/renesas-sdhi.c:         ((rmobile_get_cpu_type() ==
> RMOBILE_CPU_TYPE_R8A7796) &&
> drivers/net/ravb.c:     if ((rmobile_get_cpu_type() ==
> RMOBILE_CPU_TYPE_R8A77990) ||
> drivers/net/ravb.c:         (rmobile_get_cpu_type() ==
> RMOBILE_CPU_TYPE_R8A77995))
>
> These tests will no longer work on RZG as they should (the test to match on
> RMOBILE_CPU_TYPE_R8A7796 will also match on
> RMOBILE_CPU_TYPE_R8A774A1 and that might not be what is expected). So
> there needs to be some way to implement match on RZG-only.

I have tested all the interfaces on RZ/H2[HMN] and they work as they expected
Moreover SOC's  with same PRR ID's use identical IP's.

For eg:-
R8A7796 SDHI IP is identical to RZ/G2M SDHI IP

SDHI case, it has generic compatible string "renesas,rcar-gen3-sdhi " [1] .
Generic compatible string tells that the driver is compatible with RCar Gen3 and RZ/G2 family.
SoC PRR ID's used to adapt the changes related to SoC family. So it will work as expected.
https://elixir.bootlin.com/u-boot/v2020.10-rc5/source/drivers/mmc/renesas-sdhi.c#L845

> So we will need some rmobile_cpu_match(RMOBILE_CPU_TYPE_R8A7796)
> function, which will match on 7796 only and if it is called with
> RMOBILE_CPU_TYPE_R8A774A1 it will not match (assuming the SoC on which
> it is running is 7796).

OK, If we really needed to separate this, then

We can define CPU_MASK for  both RCar and RZG2.  We can define SoC PRRID's as per hardware Manual and We can redefine the above CPU macro's like this.

#define SOC_R8A7796_PRR_ID 0x52
#define SOC_R8A774A1_PRR_ID 0x52

#define RCAR_GEN3_CPU_MASK  0x0
#define RZG2_CPU_MASK 0x1000

#define RMOBILE_CPU_TYPE_R8A7796   (SOC_R8A7796_PRR_ID + RCAR_GEN3_CPU_MASK)
#define RMOBILE_CPU_TYPE_R8A774A1 (SOC_R8A774A1_PRR_ID + RZG2_CPU_MASK)

So rmobile_cpu_match will return RMOBILE_CPU_TYPE_R8A7796 or RMOBILE_CPU_TYPE_R8A774A1
instead of PRRID's.

What do you think?

> >> We really need to find a way to tell these two apart first, e.g. by
> >> checking the bootrom, and then use it in U-Boot all over the place.
> >
> > Yes, I agree we need to differentiate them. Different ways I can think
> > of is
> >
> > 1) Bootrom level
> > 2) Checking some IP register which is present in RCar and not in RZ/G2
>
> Did you make any progress on these two ?

Still investigating [1] and [2],

For 1) this to done at TFA  right, not at u-boot level?
TFA runs at EL3, So all secure stuffs to be handled at TFA and TFA needs to identify the SoC/Family type pass this info to u-boot.
Basically identify the SoC using BootRom code at TFA  and pass that info to u-boot   (for eg:-  in the form of  "SoC Compatible string"  , which has the info  "r8a7796" for RCar and "r8a774a1" for RZ/G2 )
which is same as the Solution 3 ("Compatible SoC string from TFA")

For 2, May be IP's like DRIF is not present in RZ/G2, so currently based on some register access, we may be able to differentiate it at u-boot level.

> > 3) Compatible SoC string from TFA
>
> This only shifts the problem into TFA, so now TFA has to figure out a way to
> discern RZG and RCar. Surely one can argue that TFA is built for a specific SoC,
> so this could be a no-problem.

Yes, Exactly I see this is a no-problem at u-boot, TFA will handle separation stuff( Either Bootrom Code or  by checking some Security related IP's or
Compile time macros) and adds the appropriate SoC compatible string and pass it to U-boot.

May be 3 is the right way to go.

What do you think?

>
> > 4) TFA there will be separation for RZ/G2 SoC and RCar Gen3 SoC, So
> populate some dtfragment for RCar/RZG2 SoC similar to dram and u-boot
> handling it for SoC separation.
> > 5) Use compile time macros in U-boot.
>
> No, we worked too hard to make things based purely on DT and get rid of
> compile-time macros, so lets not put those back.
OK.

> > Please let me you know, which is the best way to go forward and also let
> me know, if you have any other ideas in your mind.
>
> I would highly prefer 1) or 2) if possible.

But  for 1, we should not access any boot rom stuff's from u-boot.  Security related stuffs needs to be handled  at EL3 level.
U-boot runs at EL1 level, and so it can't access the BootRoM code.

For 2, May be IP's like DRIF is not present in RZ/G2, so currently based on some register access, we may be able to differentiate it at u-boot level.
Tomorrow, if any RZ/G2 SoC enables DRIF IP, then our logic will fail on that SoC. But the chances are very remote.

I may be wrong, Please correct me if I am wrong.

Cheers,
Biju



Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647

On 10/4/20 6:57 PM, Biju Das wrote:

Hi,

[...]

>>>>>  /* PRR CPU IDs */
>>>>>  #define RMOBILE_CPU_TYPE_SH73A00x37  #define
>>>>> RMOBILE_CPU_TYPE_R8A77400x40
>>>>> +#define RMOBILE_CPU_TYPE_R8A774A10x52
>>>>
>>>> The problem here is that this is the same as
>>>> #define RMOBILE_CPU_TYPE_R8A7796   0x52
>>>>
>>>> So if you use that ^ in the code, you cannot discern it from
>>>> RMOBILE_CPU_TYPE_R8A774A1 .
>>>
>>> But this value is same as per the hardware manual, see the definitions
>>> in linux[1]
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tre
>>> e/drivers/soc/renesas/renesas-soc.c?h=v5.9-rc7#n114
>>> Please correct me, if this macros are not as per hardware manual.
>>
>> This is not what I am complaining about. See for example the output of $ git
>> grep RMOBILE_CPU_TYPE_ ...
>> drivers/mmc/renesas-sdhi.c:     if (((rmobile_get_cpu_type() ==
>> RMOBILE_CPU_TYPE_R8A7795) &&
>> drivers/mmc/renesas-sdhi.c:         ((rmobile_get_cpu_type() ==
>> RMOBILE_CPU_TYPE_R8A7796) &&
>> drivers/net/ravb.c:     if ((rmobile_get_cpu_type() ==
>> RMOBILE_CPU_TYPE_R8A77990) ||
>> drivers/net/ravb.c:         (rmobile_get_cpu_type() ==
>> RMOBILE_CPU_TYPE_R8A77995))
>>
>> These tests will no longer work on RZG as they should (the test to match on
>> RMOBILE_CPU_TYPE_R8A7796 will also match on
>> RMOBILE_CPU_TYPE_R8A774A1 and that might not be what is expected). So
>> there needs to be some way to implement match on RZG-only.
> 
> I have tested all the interfaces on RZ/H2[HMN] and they work as they expected
> Moreover SOC's  with same PRR ID's use identical IP's.

If (rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7796) is true on RZG2,
then it does not work as expected, I think we can agree on that ?

> For eg:-
> R8A7796 SDHI IP is identical to RZ/G2M SDHI IP

If there ever is some RZG2 specific quirk further down the line, which
does not apply to R-Car, then how do you propose that quirk is applied
without having a way to tell RZG and RCar apart ?

> SDHI case, it has generic compatible string "renesas,rcar-gen3-sdhi " [1] .
> Generic compatible string tells that the driver is compatible with RCar Gen3 and RZ/G2 family.
> SoC PRR ID's used to adapt the changes related to SoC family. So it will work as expected.
> https://elixir.bootlin.com/u-boot/v2020.10-rc5/source/drivers/mmc/renesas-sdhi.c#L845
> 
>> So we will need some rmobile_cpu_match(RMOBILE_CPU_TYPE_R8A7796)
>> function, which will match on 7796 only and if it is called with
>> RMOBILE_CPU_TYPE_R8A774A1 it will not match (assuming the SoC on which
>> it is running is 7796).
> 
> OK, If we really needed to separate this, then
> 
> We can define CPU_MASK for  both RCar and RZG2.  We can define SoC PRRID's as per hardware Manual and We can redefine the above CPU macro's like this.
> 
> #define SOC_R8A7796_PRR_ID 0x52
> #define SOC_R8A774A1_PRR_ID 0x52
> 
> #define RCAR_GEN3_CPU_MASK  0x0
> #define RZG2_CPU_MASK 0x1000
> 
> #define RMOBILE_CPU_TYPE_R8A7796   (SOC_R8A7796_PRR_ID + RCAR_GEN3_CPU_MASK)
> #define RMOBILE_CPU_TYPE_R8A774A1 (SOC_R8A774A1_PRR_ID + RZG2_CPU_MASK)
> 
> So rmobile_cpu_match will return RMOBILE_CPU_TYPE_R8A7796 or RMOBILE_CPU_TYPE_R8A774A1
> instead of PRRID's.
> 
> What do you think?

I think this is just an implementation detail. What needs to be figured
out first is how to tell RCar3 and RZG2 apart. Lets continue this
discussion in the bootrom thread, that really needs to be figured out
first and only then can U-Boot and TFA patches be implemented on top of
that solution.

>>>> We really need to find a way to tell these two apart first, e.g. by
>>>> checking the bootrom, and then use it in U-Boot all over the place.
>>>
>>> Yes, I agree we need to differentiate them. Different ways I can think
>>> of is
>>>
>>> 1) Bootrom level
>>> 2) Checking some IP register which is present in RCar and not in RZ/G2
>>
>> Did you make any progress on these two ?
> 
> Still investigating [1] and [2],
> 
> For 1) this to done at TFA  right, not at u-boot level?

Yes

> TFA runs at EL3, So all secure stuffs to be handled at TFA and TFA needs to identify the SoC/Family type pass this info to u-boot.
> Basically identify the SoC using BootRom code at TFA  and pass that info to u-boot   (for eg:-  in the form of  "SoC Compatible string"  , which has the info  "r8a7796" for RCar and "r8a774a1" for RZ/G2 )
> which is same as the Solution 3 ("Compatible SoC string from TFA")
> 
> For 2, May be IP's like DRIF is not present in RZ/G2, so currently based on some register access, we may be able to differentiate it at u-boot level.

Note that it doesn't really matter whether you do the identification in
TFA and just pass that information to U-Boot (via DT fragment) or
whether you do the identification in U-Boot.

If the identification can be implemented, that is the important first
step, the rest are implementation details.

>>> 3) Compatible SoC string from TFA
>>
>> This only shifts the problem into TFA, so now TFA has to figure out a way to
>> discern RZG and RCar. Surely one can argue that TFA is built for a specific SoC,
>> so this could be a no-problem.
> 
> Yes, Exactly I see this is a no-problem at u-boot, TFA will handle separation stuff( Either Bootrom Code or  by checking some Security related IP's or
> Compile time macros) and adds the appropriate SoC compatible string and pass it to U-boot.
> 
> May be 3 is the right way to go.
> 
> What do you think?

Then you still have the problem of discerning the R-Car and RZG2, except
you moved it from U-Boot to TFA, but the problem remains.

>>> 4) TFA there will be separation for RZ/G2 SoC and RCar Gen3 SoC, So
>> populate some dtfragment for RCar/RZG2 SoC similar to dram and u-boot
>> handling it for SoC separation.
>>> 5) Use compile time macros in U-boot.
>>
>> No, we worked too hard to make things based purely on DT and get rid of
>> compile-time macros, so lets not put those back.
> OK.
> 
>>> Please let me you know, which is the best way to go forward and also let
>> me know, if you have any other ideas in your mind.
>>
>> I would highly prefer 1) or 2) if possible.
> 
> But  for 1, we should not access any boot rom stuff's from u-boot.  Security related stuffs needs to be handled  at EL3 level.
> U-boot runs at EL1 level, and so it can't access the BootRoM code.
> 
> For 2, May be IP's like DRIF is not present in RZ/G2, so currently based on some register access, we may be able to differentiate it at u-boot level.
> Tomorrow, if any RZ/G2 SoC enables DRIF IP, then our logic will fail on that SoC. But the chances are very remote.
> 
> I may be wrong, Please correct me if I am wrong.

See above, it doesn't matter where you discern the SoCs. The first step
is to figure out how to discern them.

Hi Marek,

> [...]
>
> >>>>>  /* PRR CPU IDs */
> >>>>>  #define RMOBILE_CPU_TYPE_SH73A00x37  #define
> >>>>> RMOBILE_CPU_TYPE_R8A77400x40
> >>>>> +#define RMOBILE_CPU_TYPE_R8A774A10x52
> >>>>
> >>>> The problem here is that this is the same as
> >>>> #define RMOBILE_CPU_TYPE_R8A7796   0x52
> >>>>
> >>>> So if you use that ^ in the code, you cannot discern it from
> >>>> RMOBILE_CPU_TYPE_R8A774A1 .
> >>>
> >>> But this value is same as per the hardware manual, see the
> >>> definitions in linux[1]
> >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/t
> >>> re
> >>> e/drivers/soc/renesas/renesas-soc.c?h=v5.9-rc7#n114
> >>> Please correct me, if this macros are not as per hardware manual.
> >>
> >> This is not what I am complaining about. See for example the output
> >> of $ git grep RMOBILE_CPU_TYPE_ ...
> >> drivers/mmc/renesas-sdhi.c:     if (((rmobile_get_cpu_type() ==
> >> RMOBILE_CPU_TYPE_R8A7795) &&
> >> drivers/mmc/renesas-sdhi.c:         ((rmobile_get_cpu_type() ==
> >> RMOBILE_CPU_TYPE_R8A7796) &&
> >> drivers/net/ravb.c:     if ((rmobile_get_cpu_type() ==
> >> RMOBILE_CPU_TYPE_R8A77990) ||
> >> drivers/net/ravb.c:         (rmobile_get_cpu_type() ==
> >> RMOBILE_CPU_TYPE_R8A77995))
> >>
> >> These tests will no longer work on RZG as they should (the test to
> >> match on
> >> RMOBILE_CPU_TYPE_R8A7796 will also match on
> >> RMOBILE_CPU_TYPE_R8A774A1 and that might not be what is expected).
> So
> >> there needs to be some way to implement match on RZG-only.
> >
> > I have tested all the interfaces on RZ/H2[HMN] and they work as they
> > expected Moreover SOC's  with same PRR ID's use identical IP's.
>
> If (rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7796) is true on
> RZG2, then it does not work as expected, I think we can agree on that ?
>
> > For eg:-
> > R8A7796 SDHI IP is identical to RZ/G2M SDHI IP
>
> If there ever is some RZG2 specific quirk further down the line, which does
> not apply to R-Car, then how do you propose that quirk is applied without
> having a way to tell RZG and RCar apart ?

OK, Will Make RMOBILE_CPU_TYPE_R8A774A1 as unique.

> > SDHI case, it has generic compatible string "renesas,rcar-gen3-sdhi " [1] .
> > Generic compatible string tells that the driver is compatible with RCar Gen3
> and RZ/G2 family.
> > SoC PRR ID's used to adapt the changes related to SoC family. So it will work
> as expected.
> > https://elixir.bootlin.com/u-boot/v2020.10-rc5/source/drivers/mmc/rene
> > sas-sdhi.c#L845
> >
> >> So we will need some
> rmobile_cpu_match(RMOBILE_CPU_TYPE_R8A7796)
> >> function, which will match on 7796 only and if it is called with
> >> RMOBILE_CPU_TYPE_R8A774A1 it will not match (assuming the SoC on
> >> which it is running is 7796).
> >
> > OK, If we really needed to separate this, then
> >
> > We can define CPU_MASK for  both RCar and RZG2.  We can define SoC
> PRRID's as per hardware Manual and We can redefine the above CPU
> macro's like this.
> >
> > #define SOC_R8A7796_PRR_ID 0x52
> > #define SOC_R8A774A1_PRR_ID 0x52
> >
> > #define RCAR_GEN3_CPU_MASK  0x0
> > #define RZG2_CPU_MASK 0x1000
> >
> > #define RMOBILE_CPU_TYPE_R8A7796   (SOC_R8A7796_PRR_ID +
> RCAR_GEN3_CPU_MASK)
> > #define RMOBILE_CPU_TYPE_R8A774A1 (SOC_R8A774A1_PRR_ID +
> > RZG2_CPU_MASK)
> >
> > So rmobile_cpu_match will return RMOBILE_CPU_TYPE_R8A7796 or
> > RMOBILE_CPU_TYPE_R8A774A1 instead of PRRID's.
> >
> > What do you think?
>
> I think this is just an implementation detail. What needs to be figured out
> first is how to tell RCar3 and RZG2 apart. Lets continue this discussion in the
> bootrom thread, that really needs to be figured out first and only then can U-
> Boot and TFA patches be implemented on top of that solution.

OK.

> >>>> We really need to find a way to tell these two apart first, e.g. by
> >>>> checking the bootrom, and then use it in U-Boot all over the place.
> >>>
> >>> Yes, I agree we need to differentiate them. Different ways I can
> >>> think of is
> >>>
> >>> 1) Bootrom level
> >>> 2) Checking some IP register which is present in RCar and not in
> >>> RZ/G2
> >>
> >> Did you make any progress on these two ?
> >
> > Still investigating [1] and [2],
> >
> > For 1) this to done at TFA  right, not at u-boot level?
>
> Yes
>
> > TFA runs at EL3, So all secure stuffs to be handled at TFA and TFA needs to
> identify the SoC/Family type pass this info to u-boot.
> > Basically identify the SoC using BootRom code at TFA  and pass that info to
> u-boot   (for eg:-  in the form of  "SoC Compatible string"  , which has the info
> "r8a7796" for RCar and "r8a774a1" for RZ/G2 )
> > which is same as the Solution 3 ("Compatible SoC string from TFA")
> >
> > For 2, May be IP's like DRIF is not present in RZ/G2, so currently based on
> some register access, we may be able to differentiate it at u-boot level.
>
> Note that it doesn't really matter whether you do the identification in TFA
> and just pass that information to U-Boot (via DT fragment) or whether you
> do the identification in U-Boot.
>
> If the identification can be implemented, that is the important first step, the
> rest are implementation details.

OK.

> >>> 3) Compatible SoC string from TFA
> >>
> >> This only shifts the problem into TFA, so now TFA has to figure out a
> >> way to discern RZG and RCar. Surely one can argue that TFA is built
> >> for a specific SoC, so this could be a no-problem.
> >
> > Yes, Exactly I see this is a no-problem at u-boot, TFA will handle
> > separation stuff( Either Bootrom Code or  by checking some Security
> related IP's or Compile time macros) and adds the appropriate SoC
> compatible string and pass it to U-boot.
> >
> > May be 3 is the right way to go.
> >
> > What do you think?
>
> Then you still have the problem of discerning the R-Car and RZG2, except you
> moved it from U-Boot to TFA, but the problem remains.
>
> >>> 4) TFA there will be separation for RZ/G2 SoC and RCar Gen3 SoC, So
> >> populate some dtfragment for RCar/RZG2 SoC similar to dram and u-boot
> >> handling it for SoC separation.
> >>> 5) Use compile time macros in U-boot.
> >>
> >> No, we worked too hard to make things based purely on DT and get rid
> >> of compile-time macros, so lets not put those back.
> > OK.
> >
> >>> Please let me you know, which is the best way to go forward and also
> >>> let
> >> me know, if you have any other ideas in your mind.
> >>
> >> I would highly prefer 1) or 2) if possible.
> >
> > But  for 1, we should not access any boot rom stuff's from u-boot.  Security
> related stuffs needs to be handled  at EL3 level.
> > U-boot runs at EL1 level, and so it can't access the BootRoM code.
> >
> > For 2, May be IP's like DRIF is not present in RZ/G2, so currently based on
> some register access, we may be able to differentiate it at u-boot level.
> > Tomorrow, if any RZ/G2 SoC enables DRIF IP, then our logic will fail on that
> SoC. But the chances are very remote.
> >
> > I may be wrong, Please correct me if I am wrong.
>
> See above, it doesn't matter where you discern the SoCs. The first step is to
> figure out how to discern them.

OK, As we agreed on passing the DT compatible from TFA to U-Boot and use that info for differentiating RCar from RZ/G2.
 I will send a patch based on this solution.

Thanks and regards,
Biju



Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647