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 ? > [1] > https://elixir.bootlin.com/u-boot/v2020.10-rc4/source/board/samsung/common/exynos5-dt-types.c#L246 > [2] > https://elixir.bootlin.com/u-boot/v2020.10-rc4/source/arch/arm/mach-uniphier/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/tree/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@ee100000: 0, sd@ee140000: 1, sd@ee160000: 2 > Loading Environment from MMC... OK > In: serial@e6e88000 > Out: serial@e6e88000 > Err: serial@e6e88000 > Net: eth0: ethernet@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.