[PATCH 1/2] arm: rmobile: Add RZ/G2M SoC
Marek Vasut
marek.vasut at gmail.com
Sat Sep 19 15:00:15 CEST 2020
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 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.
More information about the U-Boot
mailing list