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

Sun Jun 9 17:00:32 PDT 2019

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.

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 at yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/linux-yocto