[PATCH 14/15] board: ti: Add j721e_beagleboneai64_* config fragments and env file

[Andrew Davis]

On 11/17/23 8:27 AM, Romain Naour wrote:
> Hello Andrew, All,
> 
> Le 03/11/2023 à 20:20, Andrew Davis a écrit :
>> On 11/3/23 2:06 PM, Nishanth Menon wrote:
>>> On 13:51-20231103, Andrew Davis wrote:
>>>> On 11/2/23 7:38 PM, Nishanth Menon wrote:
>>>>> Add defconfig fragments for J721E based BeagleBone AI-64 and
>>>>> corresponding customized environment.
>>>>>
>>>>> Signed-off-by: Nishanth Menon <nm at ti.com>
>>>>> ---
>>>>>     board/ti/j721e/beagleboneai64.env        | 19 ++++++++
>>>>>     board/ti/j721e/beagleboneai64_a72.config | 55 ++++++++++++++++++++++++
>>>>>     board/ti/j721e/beagleboneai64_r5.config  | 19 ++++++++
>>>>
>>>> Beagle boards are not TI boards, add the board support to board/beagle/
>>>
>>> Huh, why bring in commercials and organization changes here? am335x
>>> and am62 are under the TI umbrella.
>>>
>>
>> The SoCs used are yes, the boards are not, we only make our EVM/SK
>> line of boards in house.
>>
>> We did AM335x wrong, in board/ti/am335x/board.c we tried to support
>> like 11 different boards in one file. And while it might have made adding
>> our own extra EVMs easier, it only made things less clear for folks trying
>> to add their own AM335x based boards[0].
>>
>> We don't integrate support for any other board partner like this. Our
>> friends over at Toradex or Phytec are currently upstreaming boards based
>> on K3 SoCs and in doing so have shown us some areas we can improve.
>>
>> We focus on these little short-cuts to make adding our EVMs (or boards
>> that look like our EVMs) easy. But that only leads to extra work and
>> code duplication for external boards.
>>
>> If something is actually common to the SoC then lets move it to
>> arch/arm/mach-k3/j721e. Tricks like board-variants.c only hide the
>> issue and doesn't help folks wanting to add their boards based on our
>> SoCs to their board/<vendor>/ directory.
> 
> I'm starting a new custom board bring-up based on a j721e SoC (without any SOM)
> and adding a now board variant from the u-boot provided in the TI SDK (based on
> 2023.04) is far from easy for the reasons mentioned above (extra work and code
> duplication for external boards).
> 
> Also the build break for j7200/j721e SoC as soon as CONFIG_TARGET_J721E_A72_EVM
> and CONFIG_TARGET_J7200_A72_EVM are undefined:
> 

The issue is we didn't properly split J7200 support from J721e and now that
there are differences between the two, the only way we have to check which
is which is to check the TARGET board, not the SOC (as there is no SOC_K3_J7200,
but we are working on that [0]). So currently adding new J721E/J7200 TARGET
boards breaks things :(

> https://source.denx.de/u-boot/u-boot/-/blob/v2023.10/arch/arm/mach-k3/arm64-mmu.c?ref_type=tags#L71
> 
> I always wonder if I should work on top of EVMs board or create a new
> board/<vendor>/ directory for customer boards.
> 

New board/<vendor>/ would be preferred, we do things in our EVM board/ti/
dir that are specific to our EVMs, and there will be more churn, etc..

If adding a new board/<vendor>/ for our SoCs is difficult just let us know,
we are working several issues to make it more easy going forward and guiding
feedback always helps.

Andrew

[0] https://lore.kernel.org/all/20231106165044.xrmlxoyfbnkmpb5v@revolt/

> Best regards,
> Romain
> 
>>
>> Andrew
>>
>> [0] See "Software Design" https://jaycarlson.net/embedded-linux/#am335x
>>
>>> $ git grep beagle board/|cut -d ':' -f1|sort -u
>>> board/ti/am335x/board.c
>>> board/ti/am335x/board.h
>>> board/ti/am57xx/board.c
>>> board/ti/am62x/beagleplay_a53.config
>>> board/ti/am62x/beagleplay_r5.config
>>> board/ti/am62x/MAINTAINERS
>>> board/ti/beagle/beagle.c
>>> board/ti/beagle/Kconfig
>>> board/ti/beagle/led.c
>>> board/ti/beagle/MAINTAINERS
>>> board/ti/beagle/Makefile
>>> board/ti/j721e/beagleboneai64_a72.config
>>> board/ti/j721e/beagleboneai64_r5.config
>>> board/ti/j721e/MAINTAINERS
>>> board/timll/devkit8000/README
>>>
>