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