[PATCH v5 04/17] arm: mach-k3: Add basic support for J784S4 SoC definition

Neha Malcom Francis n-francis at ti.com
Fri Dec 1 18:32:20 CET 2023


Hi Apurva

On 01-Dec-23 10:38 PM, Francesco Dolcini wrote:
> On Fri, Dec 01, 2023 at 10:37:55AM -0600, Bryan Brattlof wrote:
>> On November 30, 2023 thus sayeth Apurva Nandan:
>>> Add J784S4 initialization files for initial SPL boot.
>>>
>>> Signed-off-by: Hari Nagalla <hnagalla at ti.com>
>>> [ add firewall configurations and change the R5 MCU scratchpad ]
>>> Signed-off-by: Manorit Chawdhry <m-chawdhry at ti.com>
>>> Signed-off-by: Dasnavis Sabiya <sabiya.d at ti.com>
>>> Signed-off-by: Apurva Nandan <a-nandan at ti.com>
>>> ---
>>>   arch/arm/mach-k3/Kconfig                      |  16 +-
>>>   arch/arm/mach-k3/Makefile                     |   2 +
>>>   arch/arm/mach-k3/arm64-mmu.c                  |  52 +++
>>>   arch/arm/mach-k3/include/mach/hardware.h      |   4 +
>>>   .../mach-k3/include/mach/j784s4_hardware.h    |  60 ++++
>>>   arch/arm/mach-k3/include/mach/j784s4_spl.h    |  47 +++
>>>   arch/arm/mach-k3/include/mach/spl.h           |   4 +
>>>   arch/arm/mach-k3/j784s4_fdt.c                 |  15 +
>>>   arch/arm/mach-k3/j784s4_init.c                | 338 ++++++++++++++++++
>>>   arch/arm/mach-k3/r5/Makefile                  |   1 +
>>>   10 files changed, 532 insertions(+), 7 deletions(-)
>>>   create mode 100644 arch/arm/mach-k3/include/mach/j784s4_hardware.h
>>>   create mode 100644 arch/arm/mach-k3/include/mach/j784s4_spl.h
>>>   create mode 100644 arch/arm/mach-k3/j784s4_fdt.c
>>>   create mode 100644 arch/arm/mach-k3/j784s4_init.c
>>>
>>
>> ...
>>
>>> +	if (IS_ENABLED(CONFIG_TARGET_J784S4_R5_EVM)) {
>>> +		ret = uclass_get_device_by_name(UCLASS_MISC, "msmc", &dev);
>>> +		if (ret)
>>> +			panic("Probe of msmc failed: %d\n", ret);
>>> +
>>> +		ret = uclass_get_device(UCLASS_RAM, 0, &dev);
>>> +		if (ret)
>>> +			panic("DRAM 0 init failed: %d\n", ret);
>>> +
>>> +		ret = uclass_next_device_err(&dev);
>>> +		if (ret)
>>> +			panic("DRAM 1 init failed: %d\n", ret);
>>> +
>>> +		ret = uclass_next_device_err(&dev);
>>> +		if (ret)
>>> +			panic("DRAM 2 init failed: %d\n", ret);
>>> +
>>> +		ret = uclass_next_device_err(&dev);
>>> +		if (ret)
>>> +			panic("DRAM 3 init failed: %d\n", ret);
>>> +	}
>>
>> I don't know if this is is the right approach. I can see situations
>> where people will not have all these controllers utilized or would want
>> to artificially remove them for some reason.
> 
> Not sure on the exact implication, but yes, you should expect customers
> (like myself/my company) integrating the SoC into some board to not
> necessarily use all the functionalities, memory controller included.
> 
> Francesco
> 

I think you can make use of uclass_next_device_err() and a while loop to 
handle this according to the device tree.

-- 
Thanking You
Neha Malcom Francis


More information about the U-Boot mailing list