Message ID | 20201001103658.4835-1-biju.das.jz@bp.renesas.com |
---|---|
State | Superseded |
Delegated to: | Marek Vasut |
Headers | show |
Series | [v4,1/2] arm: rmobile: Add PRR CPU ID macros for RZ/G2[HMNE] | expand |
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
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 +#define RMOBILE_CPU_TYPE_R8A774B1 0x55 +#define RMOBILE_CPU_TYPE_R8A774C0 0x57 +#define RMOBILE_CPU_TYPE_R8A774E1 0x4F #define RMOBILE_CPU_TYPE_R8A7790 0x45 #define RMOBILE_CPU_TYPE_R8A7791 0x47 #define RMOBILE_CPU_TYPE_R8A7792 0x4A