[PATCH 1/2] arm: rmobile: Add RZ/G2M SoC

[Biju Das]

Hi Marek,

Thanks for the feedback.

> Subject: Re: [PATCH 1/2] arm: rmobile: Add RZ/G2M SoC
>
> On 9/19/20 1:37 PM, Biju Das wrote:
> [...]
> >>> +static const struct udevice_id *of_soc_match_compatible(void) {
> >>> +const struct udevice_id *of_match = soc_ids; int i;
> >>> +
> >>> +for (i = 0; i < ARRAY_SIZE(soc_ids); i++) { if
> >>> +(!fdt_node_check_compatible(gd->fdt_blob, 0,
> >>> +       of_match->compatible))
> >>> +return of_match;
> >>> +of_match++;
> >>> +}
> >>> +
> >>> +return NULL;
> >>> +}
> >>
> >> This should rather be a generic function, I think this is something
> >> that already exists in Linux common code too, right ?
> >
> > No.  I have seen some other SoC's uses similar logic [1]& [2] .
>
> I mean, this looks like Linux's soc_device_match() , so such a function is likely
> generic code, there is nothing platform specific to it, is there ?

I agree, we need to have a new generic api for such purpose. The Linux/U-boot soc_device_match  is for adding quirks with in different ES version of same SoC.

What we here need is similar to of_match_compatible for  array of different SoC's.
Can you please confirm  [1] drivers/soc/soc-uclass.c is the right place for such generic api?

[1] https://elixir.bootlin.com/u-boot/v2020.10-rc4/source/drivers/soc/soc-uclass.c

> > [1]
> > https://elixir.bootlin.com/u-boot/v2020.10-rc4/source/board/samsung/co
> > mmon/exynos5-dt-types.c#L246 [2]
> > https://elixir.bootlin.com/u-boot/v2020.10-rc4/source/arch/arm/mach-un
> > iphier/boards.c#L156
> >
> >
> >>>  static int rmobile_cpuinfo_idx(void)  {  int i = 0;
> >>>  u32 cpu_type = rmobile_get_cpu_type();
> >>> +const struct udevice_id *match = of_soc_match_compatible();
> >>>
> >>> +/*
> >>> + * This loop identifies CPU based on PRR register, it
> >>> +differentiates
> >>> + * RZ/G SoC's from R-Car SoC's by matching RZ/G SoC compatible
> >> string
> >>> + * from DT against the family_type.
> >>> + */
> >>>  for (; i < ARRAY_SIZE(rmobile_cpuinfo); i++) -if
> >>> (rmobile_cpuinfo[i].cpu_type == cpu_type) -break;
> >>> +if (rmobile_cpuinfo[i].cpu_type == cpu_type) { if (match &&
> >>> +    rmobile_cpuinfo[i].family_type == match->data) break; else if
> >>> +(!match &&  rmobile_cpuinfo[i].family_type !=
> >> SOC_RZG2)
> >>> +break;
> >>> +}
> >>
> >> I still don't understand this, so if cpu_type ==
> >> RMOBILE_CPU_TYPE_R8A7796 , then it can be either RZG2 or R8A7796,
> right?
> >
> > Yep you are right.
> >
> >> And there is no PRR bit or any other bit to tell those two chips apart ?
> > No. Currently only way you can distinguish is by SoC compatible string and
> family type.
> > See [3] for SoC identification logic used to differentiate  RCar and
> > RZ/G2
> > [3]:-
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tre
> > e/drivers/soc/renesas/renesas-soc.c?h=v5.9-rc5#n311
>
> So Linux is matching on the compatible string of DT passed from U-Boot ,
> right ? Linux has it easier then.
>
> But where does U-Boot get that compatible string from, in case there are
> multiple DTs passed to U-Boot and U-Boot needs to find out on which SoC it
> is running on ?
>
> Maybe you can pass the compatible from TFA, which is already happening.
>
> >> I would like to avoid using the OF match here, because that fails if
> >> you use MULTI_DTB_FIT , does it not ?
> >
> > No. It works OK on both RZ/G2SoC's[4] and RCar[5]
> >
> > [4]  MULTI_DTB_FIT logs for RZG2[HMN] boards
> >
> > CPU: Renesas Electronics R8A774E1 rev 3.0
> > Model: HopeRun HiHope RZ/G2H with sub board
> > DRAM:  3.9 GiB
> >
> > CPU: Renesas Electronics R8A774A1 rev 1.3
> > Model: HopeRun HiHope RZ/G2M with sub board
> > DRAM:  3.9 GiB
> >
> > CPU: Renesas Electronics R8A774B1 rev 1.1
> > Model: HopeRun HiHope RZ/G2N with sub board
> > DRAM:  3.9 GiB
> >
> > [5] u-boot based on R-Car M3N using rcar3_salvator-x_defconfig,  it reports
> proper SoC.
> >
> > CPU: Renesas Electronics R8A77965 rev 1.1
> > Model: Renesas Salvator-XS board based on r8a77965
> > DRAM: 1.9 GiB
> > Bank #0: 0x048000000 - 0x0bfffffff, 1.9 GiB
> >
> > MMC: sd at ee100000: 0, sd at ee140000: 1, sd at ee160000: 2 Loading
> > Environment from MMC... OK
> > In: serial at e6e88000
> > Out: serial at e6e88000
> > Err: serial at e6e88000
> > Net: eth0: ethernet at e6800000
> > Hit any key to stop autoboot: 0
> > =>
> >
> >  So can you please check whether there might
> >> be some way to tell the two SoCs apart ?
> >
> > At present there is no way other than matching the SoC compatible string.
>
> Thinking about it a bit more, if you were to use the compatible string psssed
> from TFA in the / node, you could iterate over soc_ids[] array and return
> RMOBILE_CPU_TYPE_x , which could be stored there as .data .
> Then you won't even need the SOC_RZG2 and it would all be faster, as all you
> would need is a single pass over a smaller array.

Good point. Ok will get rid of SOC_RZG2,  will use smaller array forRZG2.

Are you suggesting to modify "arch_misc_init" directly set "platform" environment variable using match logic, which use a smaller array
Compared to rmobile_cpuinfo.

Basically we match the compatible string from TFA, .data from " RMOBILE_CPU_TYPE_x" matched against PRR values and set the platform type .

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