Re: [linux-yocto] [PATCH 1/1] xilinx-zynqmp: add the basic support xilinx-zynqmp
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
Re: [linux-yocto] [kernel-cache][PATCH 1/2] features: add qemu-guest
On Sun, Jun 9, 2019 at 8:49 AM Adrian Freihofer wrote: > > Purpose: Provide an easy way to add ARCH_VIRT=y to the kernel configuration. > This allows to boot ARM images compiled for real hardware in Qemu as well. > Including this feature e.g. into the Beaglebone BSP allows to: We already have the qemuarma15 BSP, and calling it that for the purposes of qemu booting was entirely on purpose. History has shown us many times that maintaining a BSP for both h/w and virtual boots eventually leads to conflicting requirements and compromise on both the h/w and virtual variant. i.e. there's not a lot of benefit outside of asking for the qemu* machines to be used when someone wants to do a virtual boot . .and yes, I understand the request and justification for it, I've been asked many times for something similar to this. That being said, if we do take something like this, the CONFIG_ARCH_VIRT, etc of this fragment should be used by qemuarma15 as well, since that is the variant that gets regular boot testing. So the summary is, with some refactoring, I don't see why this can't merge. > > export MACHINE="beaglebone-yocto" > bitbake core-image-minimale > runqemu > > This also works with the eSDK. Whithout this feature usually two different > SDKs need to be compiled and maintained. One SDK is used for development > in Qemu, another one is used to develop for the real target hardware. > > Note: For newer aarch64 devices a pci variant of this config snipped > might be beneficial. > > [Yocto #13384] > > Signed-off-by: Adrian Freihofer > --- > features/qemu-guest/qemu-arm-virt.cfg | 10 ++ > features/qemu-guest/qemu-arm-virt.scc | 4 > 2 files changed, 14 insertions(+) > create mode 100644 features/qemu-guest/qemu-arm-virt.cfg > create mode 100644 features/qemu-guest/qemu-arm-virt.scc > > diff --git a/features/qemu-guest/qemu-arm-virt.cfg > b/features/qemu-guest/qemu-arm-virt.cfg > new file mode 100644 > index ..7aec61de > --- /dev/null > +++ b/features/qemu-guest/qemu-arm-virt.cfg > @@ -0,0 +1,10 @@ > +CONFIG_ARCH_VIRT=y > +CONFIG_VIRTIO_BLK=y > +CONFIG_VIRTIO_BLK_SCSI=y > +CONFIG_VIRTIO_NET=y > +CONFIG_SERIAL_AMBA_PL011=y > +CONFIG_SERIAL_AMBA_PL011_CONSOLE=y > +CONFIG_HW_RANDOM=y > +CONFIG_HW_RANDOM_VIRTIO=y > +CONFIG_VIRTIO_MMIO=y > +CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES=y We already have configuration blocks for virtio, and they should be reused here. If there are issues with those config fragments, we should refactor them so they can be reused. Cheers, Bruce > diff --git a/features/qemu-guest/qemu-arm-virt.scc > b/features/qemu-guest/qemu-arm-virt.scc > new file mode 100644 > index ..54682dcf > --- /dev/null > +++ b/features/qemu-guest/qemu-arm-virt.scc > @@ -0,0 +1,4 @@ > +define KFEATURE_DESCRIPTION "Enable options for ARM images in Qemu" > +define KFEATURE_COMPATIBILITY board > + > +kconf hardware qemu-arm-virt.cfg > -- > 2.11.0 > > -- > ___ > 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
Re: [linux-yocto] [kernel-cache][PATCH 0/2] qemu support for ARM devices
On Sun, Jun 9, 2019 at 8:49 AM Adrian Freihofer wrote: > > The purpose/idea is documented here: > https://bugzilla.yoctoproject.org/show_bug.cgi?id=13384 Just cut and paste the reasons into the cover letter + patches. Not all reviews are done online and having the info quickly available for git queries is handy. Bruce > > Adrian Freihofer (2): > features: add qemu-guest > bsp/beaglebone: include qemu-guest feature > > bsp/beaglebone/beaglebone.scc | 1 + > features/qemu-guest/qemu-arm-virt.cfg | 10 ++ > features/qemu-guest/qemu-arm-virt.scc | 4 > 3 files changed, 15 insertions(+) > create mode 100644 features/qemu-guest/qemu-arm-virt.cfg > create mode 100644 features/qemu-guest/qemu-arm-virt.scc > > -- > 2.11.0 > > -- > ___ > 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
[linux-yocto] [kernel-cache][PATCH 0/2] qemu support for ARM devices
The purpose/idea is documented here: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13384 Adrian Freihofer (2): features: add qemu-guest bsp/beaglebone: include qemu-guest feature bsp/beaglebone/beaglebone.scc | 1 + features/qemu-guest/qemu-arm-virt.cfg | 10 ++ features/qemu-guest/qemu-arm-virt.scc | 4 3 files changed, 15 insertions(+) create mode 100644 features/qemu-guest/qemu-arm-virt.cfg create mode 100644 features/qemu-guest/qemu-arm-virt.scc -- 2.11.0 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [kernel-cache][PATCH 1/2] features: add qemu-guest
Purpose: Provide an easy way to add ARCH_VIRT=y to the kernel configuration. This allows to boot ARM images compiled for real hardware in Qemu as well. Including this feature e.g. into the Beaglebone BSP allows to: export MACHINE="beaglebone-yocto" bitbake core-image-minimale runqemu This also works with the eSDK. Whithout this feature usually two different SDKs need to be compiled and maintained. One SDK is used for development in Qemu, another one is used to develop for the real target hardware. Note: For newer aarch64 devices a pci variant of this config snipped might be beneficial. [Yocto #13384] Signed-off-by: Adrian Freihofer --- features/qemu-guest/qemu-arm-virt.cfg | 10 ++ features/qemu-guest/qemu-arm-virt.scc | 4 2 files changed, 14 insertions(+) create mode 100644 features/qemu-guest/qemu-arm-virt.cfg create mode 100644 features/qemu-guest/qemu-arm-virt.scc diff --git a/features/qemu-guest/qemu-arm-virt.cfg b/features/qemu-guest/qemu-arm-virt.cfg new file mode 100644 index ..7aec61de --- /dev/null +++ b/features/qemu-guest/qemu-arm-virt.cfg @@ -0,0 +1,10 @@ +CONFIG_ARCH_VIRT=y +CONFIG_VIRTIO_BLK=y +CONFIG_VIRTIO_BLK_SCSI=y +CONFIG_VIRTIO_NET=y +CONFIG_SERIAL_AMBA_PL011=y +CONFIG_SERIAL_AMBA_PL011_CONSOLE=y +CONFIG_HW_RANDOM=y +CONFIG_HW_RANDOM_VIRTIO=y +CONFIG_VIRTIO_MMIO=y +CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES=y diff --git a/features/qemu-guest/qemu-arm-virt.scc b/features/qemu-guest/qemu-arm-virt.scc new file mode 100644 index ..54682dcf --- /dev/null +++ b/features/qemu-guest/qemu-arm-virt.scc @@ -0,0 +1,4 @@ +define KFEATURE_DESCRIPTION "Enable options for ARM images in Qemu" +define KFEATURE_COMPATIBILITY board + +kconf hardware qemu-arm-virt.cfg -- 2.11.0 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
