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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
