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

Thu Jun 13 00:47:46 PDT 2019

Ping ....

On 6/11/19 9:40 AM, Zumeng Chen wrote:
>
> Hi Bruce,
>
> I just finished insane check to build xilinx-zynqmp machine with 
> core-image-sato, all passed with boot process.
>
> Could you please help me to create a branch like that 
> standard/xilinx-zynqmp in the following git repo. in convenient your 
> time, just directly branch out from origin/standard/base, thanks~
>
> git://git.yoctoproject.org/linux-yocto-dev
>
>
> Cheers,
>
> Zumeng
>
> On 6/11/19 7:37 AM, Zumeng Chen wrote:
>>
>> On 6/10/19 9:37 PM, Bruce Ashfield wrote:
>>> On Sun, Jun 9, 2019 at 8:00 PM Zumeng Chen <zchen at 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.
>>
>>
>> Thanks Bruce, highly appreciated :)
>>
>>
>> Cheers,
>>
>> Zumeng
>>
>>>
>>> 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 at yoctoproject.org
>>>>>>> https://lists.yoctoproject.org/listinfo/linux-yocto
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/linux-yocto/attachments/20190613/b15858f0/attachment-0001.html>