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

[Biju Das]

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