On Thu, 6 Jun 2019 at 10:16, Zumeng Chen <zc...@windriver.com> wrote: > > > On 6/6/19 1:19 AM, Bruce Ashfield wrote: > > On Wed, Jun 5, 2019 at 4:02 AM Zumeng Chen <zumeng.c...@windriver.com> > > wrote: > >> This patch is to add scc/cfg meta to build and boot zcu102 board with the > >> bsp > >> of xilinx-zynqmp. > >> > > See some questions below. > > > >> Signed-off-by: Zumeng.Chen <zumeng.c...@windriver.com> > >> --- > >> bsp/xilinx-zynqmp/xilinx-zynqmp-standard.scc | 8 + > >> bsp/xilinx-zynqmp/xilinx-zynqmp.cfg | 227 > >> +++++++++++++++++++++++++++ > >> bsp/xilinx-zynqmp/xilinx-zynqmp.scc | 7 + > >> 3 files changed, 242 insertions(+) > >> create mode 100644 bsp/xilinx-zynqmp/xilinx-zynqmp-standard.scc > >> create mode 100644 bsp/xilinx-zynqmp/xilinx-zynqmp.cfg > >> create mode 100644 bsp/xilinx-zynqmp/xilinx-zynqmp.scc > >> > >> diff --git a/bsp/xilinx-zynqmp/xilinx-zynqmp-standard.scc > >> b/bsp/xilinx-zynqmp/xilinx-zynqmp-standard.scc > >> new file mode 100644 > >> index 0000000..23dd874 > >> --- /dev/null > >> +++ b/bsp/xilinx-zynqmp/xilinx-zynqmp-standard.scc > >> @@ -0,0 +1,8 @@ > >> +define KMACHINE xilinx-zynqmp > >> +define KTYPE standard > >> +define KARCH arm64 > >> + > >> +include ktypes/standard/standard.scc > >> +branch xilinx-zynqmp > >> + > >> +include xilinx-zynqmp.scc > >> diff --git a/bsp/xilinx-zynqmp/xilinx-zynqmp.cfg > >> b/bsp/xilinx-zynqmp/xilinx-zynqmp.cfg > >> new file mode 100644 > >> index 0000000..e292366 > >> --- /dev/null > >> +++ b/bsp/xilinx-zynqmp/xilinx-zynqmp.cfg > >> @@ -0,0 +1,227 @@ > >> +#......................................................................... > >> +# WARNING > >> +# > >> +# This file is a kernel configuration fragment, and not a full kernel > >> +# configuration file. The final kernel configuration is made up of > >> +# an assembly of processed fragments, each of which is designed to > >> +# capture a specific part of the final configuration (e.g. platform > >> +# configuration, feature configuration, and board specific hardware > >> +# configuration). For more information on kernel configuration, please > >> +# consult the product documentation. > >> +# > >> +#......................................................................... > > > Forget to remove this part, I'll delete them above. > > >> + > >> + > >> +CONFIG_ARM64=y > >> +CONFIG_ARCH_ZYNQMP=y > >> +CONFIG_ARM64_4K_PAGES=y > >> +CONFIG_SMP=y > >> +CONFIG_NR_CPUS=8 > >> +CONFIG_HOTPLUG_CPU=y > > Since cpu hotplug isn't related to the hardware capabilities of the > > board, we should really separate this out into another fragment. > > > > Both hotplug and smp are defined in: debug-cpu-hotplug-state-control.cfg > > > Sure, and I guess we can include it since it might be useful in some app > scenario. > > > > > While that is in the debug subdirectory, it really could just be a > > kernel feature outside of that structure. For now, I'd say just > > include that fragment, and we can move it around later. > > > > We also do have a bsp/xilinx/soc/ subdirectory, and it would make > > > 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. 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 -- _______________________________________________ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
