[PATCH 4/5] xilinx: zynqmp: add Beckhoff CX8200

[Steffen Dirkwinkel]

Am 01.09.23 um 09:36 schrieb Michal Simek:
> 
> 
> On 8/30/23 16:03, Steffen Dirkwinkel wrote:
>> From: Steffen Dirkwinkel <s.dirkwinkel at beckhoff.com>
>>
>> This adds support for the Beckhoff CX8200 series of industrial 
>> embedded PCs.
>> There is some information about the device and features here:
>> https://www.beckhoff.com/en-en/products/ipc/embedded-pcs/cx8200-arm-cortex-a53/
>>
>> Currently supported/tested:
>> - Boot from microSD
>> - Ethernet
>> - USB
>> - rtc / rtc eeprom
>> - tpm access
>> - uart
>>
>> Open points:
>> - adding the psgtr usb phy doesn't work in linux (failed to get pll
>>    lock)
>> - fpga loading currently only as u-boot script or pre launch cmd (type
>>    may be stored in eeprom of rtc so this could be made generic)
>>
>> Signed-off-by: Steffen Dirkwinkel <s.dirkwinkel at beckhoff.com>
>> ---
>>
>>   arch/arm/dts/Makefile                         |    1 +
>>   arch/arm/dts/zynqmp-beckhoff-cx8200.dts       |  247 +++
>>   .../zynqmp-beckhoff-cx8200/psu_init_gpl.c     | 1960 +++++++++++++++++
>>   configs/xilinx_zynqmp_virt_defconfig          |    2 +-
>>   4 files changed, 2209 insertions(+), 1 deletion(-)
>>   create mode 100644 arch/arm/dts/zynqmp-beckhoff-cx8200.dts
>>   create mode 100644 
>> board/xilinx/zynqmp/zynqmp-beckhoff-cx8200/psu_init_gpl.c
> 
> First of all xilinx folder is not the right location because Xilinx/AMD 
> is not manufacturer of this board.

Yeah, sorry. I saw the avnet board and copied that.

> 
> Second I am normally pushing back on adding these custom boards because 
> it just increase time for maintaining.
> Your last commit was in 2019 but at least you have some commits that I 
> can trust that you would maintain your board for some time.

Our last board [1] only had linux/u-boot support as an afterthought. 
Customers had to buy a special option to set the right boot fuses, so 
most devices don’t boot u-boot.
With this board and a second similar zynqmp board (CX9240 [2]) we’ll 
have u-boot as default (and probably only) bootloader, so we’ll be
more active. We can also set two of us as maintainers and it would be 
fine to drop the boards if nobody responds.
We generally support these industrial boards for long time frames and 
would like to stay close to mainline instead of maintaining forks.

The alternative would be to have a downstream u-boot repository on 
github or somewhere. We’ll still likely have something there for build 
scripts / firmware builds / integration, but don’t plan to really 
diverge from upstream u-boot.

The main advantage of being in upstream u-boot would be that we can 
trigger internal CI on upstream changes. We can still do that and apply 
patches, but even simple patches like adding files to a makefile may 
fail to apply and will need fixing.


> 
> My biggest question is in what category is your board unique that it 
> should be added it to the tree?

Currently the board isn’t really unique. I guess we’d be the only users 
of the rtc with eeprom and there might be something needed for loading 
the correct fpga file based on eeprom (this might be done in linux / 
userspace or even u-boot script though)

[1] 
https://www.beckhoff.com/en-en/products/ipc/embedded-pcs/cx9020-arm-cortex-a8/cx9020.html#tab_productdetails_1
[2] 
https://www.beckhoff.com/en-en/products/ipc/embedded-pcs/cx9240-arm-cortex-a53/cx9240.html

> 
> Thanks,
> Michal