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

[Marek Vasut]

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.