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

[Biju Das]

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