[U-Boot] [PATCH 1/3] arm64: versal: Add support for new Xilinx Versal ACAPs

[Michal Simek]

On 16. 10. 18 17:10, Alexander Graf wrote:
> 
> 
> On 16.10.18 16:57, Michal Simek wrote:
>> On 16.10.2018 16:55, Alexander Graf wrote:
>>>
>>>
>>> On 16.10.18 16:51, Michal Simek wrote:
>>>> On 16.10.2018 16:23, Alexander Graf wrote:
>>>>>
>>>>
>>>> ...
>>>>
>>>>>> +#define ENV_MEM_LAYOUT_SETTINGS \
>>>>>> +	"fdt_high=10000000\0" \
>>>>>> +	"initrd_high=10000000\0" \
>>>>>> +	"fdt_addr_r=0x40000000\0" \
>>>>>> +	"pxefile_addr_r=0x10000000\0" \
>>>>>> +	"kernel_addr_r=0x18000000\0" \
>>>>>> +	"scriptaddr=0x02000000\0" \
>>>>>> +	"ramdisk_addr_r=0x02100000\0"
>>>>>> +
>>>>>> +#define BOOT_TARGET_DEVICES(func) \
>>>>>> +	func(PXE, pxe, na) \
>>>>>> +	func(DHCP, dhcp, na)
>>>>>
>>>>> You seem to support SD as well, shouldn't that be in here too?
>>>>
>>>> Right now this is align with what devices are wired in qemu.
>>>> Some Kconfig are enabled for SD and QSPI, etc. We will all these devices
>>>> in future for sure.
>>>
>>> Ah, ok, I figured since I saw changes to those components that they're
>>> also wired up already. It was hard to tell without the DT :).
>>
>> It is really a question if we should continue with this enabling in this
>> way or simply enable it for all arch because they are based on DT anyway.
>> I am still lacking time to test all PS hard IP with microblaze which
>> will also require some Kconfig to be updated.
>>
>> If you look at virt platform that this is using OF_BOARD and DT passed
>> by qemu which should ensure that qemu is the key element in generating
>> these DTs for u-boot and Linux.
> 
> I agree that we probably want something smarter in the long run, maybe
> even w/o OF_BOARD because you could have most of the targets available
> via PCIe for example.

I am thinking about board self identification and image with more dtbs
but I am not quite sure how this should work with pcie based cards.

Thanks,
Michal