[linux-yocto] [PATCH 1/1] xilinx-zynqmp: add the basic support xilinx-zynqmp

Wed Jun 5 17:15:25 PDT 2019

On 6/6/19 1:19 AM, Bruce Ashfield wrote:
> On Wed, Jun 5, 2019 at 4:02 AM Zumeng Chen <zumeng.chen at 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.chen at 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 :)

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