On Sun, Jun 9, 2019 at 8:00 PM Zumeng Chen <zc...@windriver.com> wrote: > > Sounds I like mean, no, I just talk the reality, Xilinx did like the > following: > > https://github.com/Xilinx/meta-xilinx/tree/master/meta-xilinx-bsp/recipes-kernel/linux/xilinx-kmeta/bsp > > I think they have a reason to share zynq-7000 series hardware, which > gears to the related hardware > > features, and the way to create dts(a relative complicated process) > corresponding to the hdl related > > features partly as well. And they just want to put zynqmp(arm64) into > recipes-kernel/linux/xilinx-kmeta/bsp/xilinx, > > As you can see, they have almost little in common in hardware features. > > > The reality here I said is about yocto project has not these related > ecosystem to create these whole thing for > > xilinx series(including zynq7000 32bit and zynqmp 64bit), like dts, hdl, > BOOT.BIN etc. there really are a bunch > > of Xilinx things. > > > So do we still want to following their SDK? If yes, fine, just help me > to merge zynqmp part from meta-xilinx, I'll take care the rest.
I'm actually fine with an approach like we are taking here. Come up with something that works purely with linux-yocto, and then we can start factoring and grouping the fragments with the help of people closer to the h/w. In particular as more Xilinx proprietary parts are open sourced, we'll have the opportunity to tweak the configuration fragments to support them properly/fully. We do want the fragments in the centralized kernel-cache, just as long as they are appropriated factored/grouped under a xilinx/ subdir where it makes sense, and have more generic feature groupings available to be shared in the more common directories. What we have is a good start to that goal, so I'll get it merged and we can start iterating on it in tree. Bruce > > > Cheers, > > Zumeng > > > On 6/6/19 2:55 PM, Zumeng Chen wrote: > > > >>> > >>> Yes, I checked it, it seems only for zynq 7000 and its special > >>> interfaces. I bet > >>> > >>> the original author didn't mean to share something for both arm64 > >>> and 32 :) > >> When I created the structure I had intended for it to include the > >> zynqmp related configs. I even had some yocto-kernel-cache patches for > >> it at the time, but zynqmp has changed quite a bit since those initial > >> patches. Most of those configs still live in meta-xilinx though (some > >> are specific to the linux-xlnx kernel). > >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/tree/meta-xilinx-bsp/recipes-kernel/linux/xilinx-kmeta > >> > >> > >> I would highly recommend keeping the xilinx bsp configs together under > >> the bsp/xilinx/ directory. And try to reuse the existing configs where > >> possible or splitting some parts of them out to make common configs > >> since zynq and zynqmp share a number of common drivers. > > > > > > Negative, try to see what had done in the past, a very little can > > re-used. And I suspect > > > > did you even how many features they are sharing. > > > > I don't think it's worth. To be honestly, they have totally the > > different app scenario. > > > > Cheers, > > > > Zumeng > > > >> > >> Regards, > >> Nathan > >> > >>> And for those common things, I guess some of them might be included > >>> by our > >>> > >>> rootfs build system. > >>> > >>> > >>>> sense to locate these fragments there, and to factor out some common > >>>> configs. I see some of the issues I'm pointing out here are in the > >>>> existing fragments as well, so there's an opportunity for some low > >>>> effort fixups. > >>> > >>>>> + > >>>>> +CONFIG_PCI=y > >>>>> +CONFIG_PCI_MSI=y > >>>>> +CONFIG_PCI_MSI_IRQ_DOMAIN=y > >>>>> +CONFIG_PCIE_XILINX_NWL=y > >>>>> +CONFIG_PCIEPORTBUS=y > >>>>> +CONFIG_PCIE_XDMA_PL=y > >>>>> + > >>>>> +#CPU ilde and freq > >>>>> +CONFIG_CPU_IDLE=y > >>>>> +CONFIG_ARM_CPUIDLE=y > >>>>> +CONFIG_CPU_FREQ=y > >>>>> +CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y > >>>>> +CONFIG_CPU_FREQ_GOV_USERSPACE=y > >>>>> +CONFIG_CPUFREQ_DT=y > >>>>> +CONFIG_CPUFREQ_DT_PLATDEV=y > >>>> These are also not tied to h/w. We already have a > >>>> features/power/intel.cfg fragment. Can you relocate these to a zynqmp > >>>> or xilinx fragment and put it along side of the existing ones ? > >>> > >>> I'll try it with a nice way. > >>> > >>>> > >>>>> + > >>>>> +# CAN Device Drivers > >>>>> +# > >>>>> +CONFIG_CAN=y > >>>>> +CONFIG_CAN_DEV=y > >>>>> +CONFIG_CAN_XILINXCAN=y > >>>>> + > >>>>> +CONFIG_MTD=y > >>>>> +CONFIG_MTD_OF_PARTS=y > >>>>> +CONFIG_MTD_BLKDEVS=y > >>>>> +CONFIG_MTD_BLOCK=y > >>>>> +CONFIG_MTD_M25P80=y > >>>>> +CONFIG_MTD_SPI_NOR=y > >>>>> +# CONFIG_JFFS2_FS_WRITEBUFFER is not set > >>>>> +# CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set > >>>>> + > >>>>> +CONFIG_BLK_DEV_SD=y > >>>>> +CONFIG_ATA=y > >>>>> +CONFIG_SATA_AHCI=y > >>>>> +CONFIG_AHCI_CEVA=y > >>>>> +CONFIG_NETDEVICES=y > >>>>> + > >>>>> +CONFIG_OF=y > >>>>> +CONFIG_OF_MDIO=y > >>>>> +CONFIG_ETHERNET=y > >>>>> +CONFIG_NET_CADENCE=y > >>>>> +CONFIG_MACB=y > >>>>> +CONFIG_MACB_EXT_BD=y > >>>>> + > >>>>> +CONFIG_PHYLIB=y > >>>>> +CONFIG_XILINX_PHY=y > >>>>> + > >>>>> +CONFIG_PHY_XILINX_ZYNQMP=y > >>>>> +CONFIG_FIXED_PHY=y > >>>>> +CONFIG_DEVMEM=y > >>>>> + > >>>>> +CONFIG_SERIAL_EARLYCON=y > >>>>> +CONFIG_SERIAL_CORE=y > >>>>> +CONFIG_SERIAL_CORE_CONSOLE=y > >>>>> +CONFIG_SERIAL_XILINX_PS_UART=y > >>>>> +CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y > >>>>> +# > >>>>> +CONFIG_I2C=y > >>>>> +CONFIG_I2C_MUX=y > >>>>> +CONFIG_I2C_MUX_PCA954x=y > >>>>> +CONFIG_I2C_MUX_REG > >>>>> +CONFIG_I2C_CADENCE=y > >>>>> +CONFIG_I2C_XILINX=y > >>>>> +CONFIG_EEPROM_AT24=y > >>>>> + > >>>>> + > >>>>> +CONFIG_SPI=y > >>>>> +CONFIG_SPI_MASTER=y > >>>>> +CONFIG_SPI_CADENCE=y > >>>>> +CONFIG_SPI_XILINX=y > >>>>> +CONFIG_SPI_ZYNQMP_GQSPI=y > >>>>> + > >>>>> +CONFIG_GPIOLIB=y > >>>>> +CONFIG_GPIO_DEVRES=y > >>>>> +CONFIG_OF_GPIO=y > >>>>> +CONFIG_GPIO_SYSFS=y > >>>>> +CONFIG_GPIO_XILINX=y > >>>>> +CONFIG_GPIO_PCA953X=y > >>>>> +CONFIG_GPIO_PCA953X_IRQ=y > >>>>> +CONFIG_GPIO_ZYNQ=y > >>>>> + > >>>>> +CONFIG_POWER_RESET=y > >>>>> +CONFIG_SENSORS_INA2XX=y > >>>>> +CONFIG_WATCHDOG=y > >>>>> +CONFIG_CADENCE_WATCHDOG=y > >>>>> +CONFIG_XILINX_WATCHDOG=y > >>>>> + > >>>>> +CONFIG_USB=y > >>>>> +CONFIG_USB_XHCI_HCD=y > >>>>> +CONFIG_USB_DWC3=y > >>>>> +CONFIG_USB_DWC3_OF_SIMPLE=y > >>>>> +CONFIG_USB_OTG=y > >>>>> +CONFIG_USB_OTG_FSM=m > >>>>> +CONFIG_USB_GADGET=y > >>>>> +CONFIG_USB_GADGET_XILINX=y > >>>>> +CONFIG_USB_ETH=m > >>>>> +CONFIG_USB_MASS_STORAGE=m > >>>> bsp/xilinx/soc/drivers-zynq.cfg has some of these already. Can we > >>>> update and then include that fragment ? > >>> > >>> This is a nasty cfg. I think you don't want to use it. But we can > >>> remove them since we have already include usb-mass-storage.scc > >>> > >>>>> + > >>>>> +CONFIG_MMC=y > >>>>> +CONFIG_MMC_BLOCK=y > >>>>> +CONFIG_MMC_SDHCI=y > >>>>> +CONFIG_MMC_SDHCI_PLTFM=y > >>>>> +CONFIG_MMC_SDHCI_OF_ARASAN=y > >>>>> + > >>>>> +CONFIG_EDAC=y > >>>>> +CONFIG_EDAC_MM_EDAC=y > >>>>> +CONFIG_EDAC_SYNOPSYS=y > >>>>> +CONFIG_EDAC_ZYNQMP_OCM=y > >>>>> + > >>>>> +CONFIG_RTC_CLASS=y > >>>>> +CONFIG_RTC_HCTOSYS=y > >>>>> +CONFIG_RTC_HCTOSYS_DEVICE="rtc0" > >>>>> +CONFIG_RTC_INTF_SYSFS=y > >>>>> +CONFIG_RTC_DRV_ZYNQMP=y > >>>>> + > >>>>> +CONFIG_DMADEVICES=y > >>>>> +CONFIG_DMA_ENGINE=y > >>>>> +CONFIG_DMA_OF=y > >>>>> +CONFIG_CMA=y > >>>>> +CONFIG_DMA_CMA=y > >>>>> +CONFIG_CMA_SIZE_MBYTES=256 > >>>> Similar to my USB comment, I'm seeing some of this in existing > >>>> fragments, can we update those fragments and then just include them ? > >>> > >>> En, I'll clean of them, some of them are redundant. But I'll keep > >>> CONFIG_DMA_CMA=y since: > >>> > >>> grep -rni 'CONFIG_DMA_CMA=y' ./ > >>> ./bsp/beaglebone/beaglebone.cfg:47:CONFIG_DMA_CMA=y > >>> ./bsp/xilinx-zynqmp/xilinx-zynqmp.cfg:140:CONFIG_DMA_CMA=y > >>> ./bsp/intel-x86/intel-x86.cfg:319:CONFIG_DMA_CMA=y > >>> > >>> > >>>>> + > >>>>> +CONFIG_XILINX_AXIDMA=y > >>>>> +CONFIG_XILINX_AXICDMA=y > >>>>> +CONFIG_XILINX_ZYNQMP_DMA=y > >>>>> +CONFIG_XILINX_DMA=y > >>>>> + > >>>>> +CONFIG_UIO=y > >>>>> +CONFIG_UIO_XILINX_APM=y > >>>>> +CONFIG_VIRTIO=y > >>>>> +CONFIG_COMMON_CLK=y > >>>>> +CONFIG_COMMON_CLK_SI570=y > >>>>> +CONFIG_COMMON_CLK_ZYNQMP=y > >>>>> +CONFIG_CLKSRC_OF=y > >>>>> +CONFIG_IOMMU_API=y > >>>>> +CONFIG_IOMMU_SUPPORT=y > >>>>> +CONFIG_OF_IOMMU=y > >>>>> +CONFIG_ARM_SMMU=y > >>>>> +CONFIG_ARM_SMMU_V3=y > >>>>> +# > >>>>> +CONFIG_REMOTEPROC=m > >>>> remotproc doesn't belong in a BSP fragment. > >>> > >>> remove it. > >>> > >>> > >>>>> +CONFIG_ZYNQMP_R5_REMOTEPROC=m > >>>>> + > >>>>> +CONFIG_STAGING=y > >>>>> +CONFIG_SOC_XILINX_ZYNQMP=y > >>>>> +CONFIG_ZYNQMP_PM_DOMAINS=y > >>>>> +CONFIG_PM_GENERIC_DOMAINS=y > >>>>> +CONFIG_ZYNQMP_PM_API=y > >>>>> +CONFIG_IRQCHIP=y > >>>>> +CONFIG_ARM_GIC=y > >>>>> +CONFIG_ARM_GIC_V3=y > >>>>> +CONFIG_ARM_GIC_V3_ITS=y > >>>>> + > >>>>> +CONFIG_IIO=y > >>>>> +CONFIG_XILINX_AMS=y > >>>>> +CONFIG_XILINX_FCLK=y > >>>>> + > >>>>> +CONFIG_FPGA=y > >>>>> +CONFIG_FPGA_MGR_ZYNQMP_FPGA=y > >>>>> +CONFIG_NVMEM_ZYNQMP=y > >>>>> +CONFIG_FPGA_REGION=y > >>>>> +CONFIG_FPGA_BRIDGE=y > >>>>> + > >>>>> +CONFIG_RESET_CONTROLLER=y > >>>>> +CONFIG_ZYNQMP_RESET_CONTROLLER=y > >>>>> + > >>>>> +CONFIG_REGULATOR=y > >>>>> +CONFIG_REGULATOR_FIXED_VOLTAGE=y > >>>>> +CONFIG_REGULATOR_GPIO=y > >>>>> + > >>>>> + > >>>>> +CONFIG_FB=y > >>>>> +CONFIG_FB_XILINX=y > >>>>> +CONFIG_MEDIA_SUPPORT=y > >>>>> +CONFIG_MEDIA_CONTROLLER=y > >>>>> +CONFIG_MEDIA_CAMERA_SUPPORT=y > >>>>> +CONFIG_VIDEO_DEV=y > >>>>> +CONFIG_VIDEO_V4L2_SUBDEV_API=y > >>>>> +CONFIG_VIDEO_V4L2=y > >>>>> +CONFIG_V4L_PLATFORM_DRIVERS=y > >>>>> +CONFIG_VIDEO_XILINX=y > >>>>> +CONFIG_VIDEO_XILINX_CFA=y > >>>>> +CONFIG_VIDEO_XILINX_CRESAMPLE=y > >>>>> +CONFIG_VIDEO_XILINX_HLS=y > >>>>> +CONFIG_VIDEO_XILINX_REMAPPER=y > >>>>> +CONFIG_VIDEO_XILINX_RGB2YUV=y > >>>>> +CONFIG_VIDEO_XILINX_SCALER=y > >>>>> +CONFIG_VIDEO_XILINX_SWITCH=y > >>>>> +CONFIG_VIDEO_XILINX_TPG=y > >>>>> +CONFIG_VIDEO_XILINX_VTC=y > >>>> The CONFIG_FB and related fragments can be separated out into a > >>>> feature fragment and then included. That's what we've done with other > >>>> FB features. > >>> > >>> En, yeah, these parts are BSP related other than this just one > >>> CONFIG_FB, can we live with these as other BSPs did? > >>> > >>> > >>>>> + > >>>>> +CONFIG_DRM=y > >>>>> +CONFIG_DRM_KMS_HELPER=y > >>>>> +CONFIG_DRM_KMS_FB_HELPER=y > >>>>> +CONFIG_DRM_FBDEV_EMULATION=y > >>>>> +CONFIG_DRM_BRIDGE=y > >>>>> +CONFIG_DRM_XILINX=y > >>>>> +CONFIG_HDMI=y > >>>>> +CONFIG_XILINX_FRMBUF=y > >>>>> +CONFIG_XILINX_DPDMA=y > >>>>> +CONFIG_XILINX_DMA_ENGINES=y > >>>>> + > >>>>> +CONFIG_FW_LOADER=y > >>>>> + > >>>>> +CONFIG_TIGON3=m > >>>>> +CONFIG_E1000E=m > >>>> Overall, this looks good to me. It just needs a bit of tweaking for > >>>> reuse. > >>> OK, I'll send v2 with sanity test, thanks Bruce. > >>> > >>> > >>> Cheers, > >>> > >>> Zumeng > >>> > >>>> Bruce > >>>> > >>>>> diff --git a/bsp/xilinx-zynqmp/xilinx-zynqmp.scc > >>>>> b/bsp/xilinx-zynqmp/xilinx-zynqmp.scc > >>>>> new file mode 100644 > >>>>> index 0000000..81696c2 > >>>>> --- /dev/null > >>>>> +++ b/bsp/xilinx-zynqmp/xilinx-zynqmp.scc > >>>>> @@ -0,0 +1,7 @@ > >>>>> +include cfg/usb-mass-storage.scc > >>>>> +include cfg/fs/flash_fs.cfg > >>>>> +include features/hugetlb/hugetlb.scc > >>>>> +# enable the ability to run 32 bit apps > >>>>> +include arch/arm/32bit-compat.scc > >>>>> + > >>>>> +kconf hardware xilinx-zynqmp.cfg > >>>>> -- > >>>>> 2.7.4 > >>>>> > >>>> -- > >>>> - Thou shalt not follow the NULL pointer, for chaos and madness await > >>>> thee at its end > >>>> - "Use the force Harry" - Gandalf, Star Trek II > >>> -- > >>> _______________________________________________ > >>> linux-yocto mailing list > >>> linux-yocto@yoctoproject.org > >>> https://lists.yoctoproject.org/listinfo/linux-yocto -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -- _______________________________________________ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
