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