Re: [linux-yocto] [PATCH 1/1] xilinx-zynqmp: add the basic support xilinx-zynqmp
Ha, yes, thanks Bruce, it's just right time. Have a good trip ~ And I did a quick check, it's OK as well :) zchen@pek-lpggp4:$ bitbake linux-yocto-dev WARNING: You have included the meta-openstack layer, but 'openstack' has not been enabled in your DISTRO_FEATURES. Some bbappend files and preferred version setting may not take effect. See the meta-openstack README for details on enabling openstack support. Parsing recipes: 100% |#| Time: 0:00:38 Parsing of 3648 .bb files complete (0 cached, 3648 parsed). 8552 targets, 5849 skipped, 0 masked, 0 errors. WARNING: No recipes available for: /buildarea1/zchen/build-19/wr19-06-14-arm64/layers/meta-cloud-services/meta-openstack/recipes-connectivity/openssh/openssh_7.%.bbappend /buildarea1/zchen/build-19/wr19-06-14-arm64/layers/meta-cgl/meta-cgl-common/recipes-extended/umip/umip_%.bbappend WARNING: No bb files matched BBFILE_PATTERN_overc '' WARNING: No bb files matched BBFILE_PATTERN_cube '' WARNING: No bb files matched BBFILE_PATTERN_wrlinux-overc '' NOTE: Resolving any missing task queue dependencies Build Configuration: WRLINUX_VERSION = "10.19.24.0" WRLINUX_BRANCH = "development" BB_VERSION = "1.43.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "ubuntu-16.04" DISTRO = "wrlinux-std-sato" DISTRO_VERSION = "10.19.24.0" MACHINE = "xilinx-zynqmp" DEFAULTTUNE = "cortexa53" TARGET_SYS = "aarch64-wrs-linux" TUNE_FEATURES = "aarch64 cortexa53 crc" TARGET_FPU = "" lib32: DEFAULTTUNE = "armv7athf-neon" lib32: TARGET_SYS = "arm-wrsmllib32-linux-gnueabi" lib32: TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard" lib32: TARGET_FPU = "hard" wrlinux wrlinux-distro = "master-wr:7fe21fafdfffcfb483bc5a4152fdfeb445b61e80" meta = "wr-10.19-20190610:50529a3a7b1d6867d9e4ec9d47b21f56578444b4" meta-initramfs meta-xfce meta-oe meta-filesystems meta-webserver meta-networking meta-python meta-perl meta-gnome meta-multimedia = "wr-10.19-20190528:9facfad2b487cdc1b335b1073b9182040de9676e" meta-security = "wr-10.19-20190529:b73416279b6b7f1735146911bb953e9bb13eb08f" meta-selinux = "wr-10.19-20190424:a8ed51181e5444c82f9702b6b5d12ca575472a58" intel-x86 = "master-wr:ad411c10245aeb78e8509e9e7b9e888e2fc8eb6c" xilinx-zynqmp = "master:fbb6d4f0affbaae78dbdf8cbdf43d1655b227843" meta-virtualization = "wr-10.19-20190603:e5d65550a5d532501ff245e7cd2a76cc415bf1bc" meta-realtime = "wr-10.19-20190408:9074810c117fdde9cec4058ac9c17c84f0f50420" meta-mingw = "wr-10.19-20190508:714437ac9ba52a4e022b3b199819dbb609d9952e" wr-template = "master-wr:4f4e06413262e09e9eadbad427860218485bb3c3" meta-yocto-bsp meta-poky = "wr-10.19-20190610:2826a58f6a0c103a3938ea5c797ea17923e10902" meta-gplv2 = "wr-10.19-20190610:168a5070bdf3bc45edb5bf2a1add9b7c081f5b64" meta-efi-secure-boot meta-encrypted-storage meta-integrity meta-signing-key = "wr-10.19-20190610:e3ee3d8c9bd7033ccde8d5ce1e23893f3b215ea0" meta-cloud-services = "wr-10.19-20190610:31dfe4207c05faead77514e36cd8af8dabd334e6" meta meta-ids meta-tpm meta-tpm2 = "wr-10.19-20190610:e3ee3d8c9bd7033ccde8d5ce1e23893f3b215ea0" meta-openstack meta-openstack-aio-deploy meta-openstack-compute-deploy meta-openstack-compute-test-config meta-openstack-controller-deploy meta-openstack-controller-test-config meta-openstack-qemu meta-openstack-swift-deploy = "wr-10.19-20190610:31dfe4207c05faead77514e36cd8af8dabd334e6" meta-intel = "wr-10.19-20190610:e51ad5e08182f164077ca6a56a9220857043ad8e" wrlinux-ovp = "master-wr:7fe21fafdfffcfb483bc5a4152fdfeb445b61e80" meta-cgl-common = "wr-10.19-20190508:bfd0554ad9734a210b636f9f5bdc307df19b1e79" wrlinux-cgl = "master-wr:7fe21fafdfffcfb483bc5a4152fdfeb445b61e80" meta-dpdk = "wr-10.19-20190528:95dea5817da2b59a8ce4fa20be4bdcaef03e4e8c" meta-intel-qat = "wr-10.19-20190408:7a49ca357fc1a130d5de2d6862168901f7229b14" meta-anaconda = "wr-10.19-20190610:f0b82870061f17176c5873515749251a2e4bd7b4" meta-overc meta-cube = "wr-10.19-20190520:4f7c0427acdf9ccab4e734840f1149840311a813" meta-iot-cloud = "wr-10.19-20190415:6e522eb46e35173eee5f9dd920bd32638aa00a11" wrlinux-overc = "master-wr:7fe21fafdfffcfb483bc5a4152fdfeb445b61e80" wrlinux-overc-cfg = "master-wr:639a999f5b83640b075c0306ea53b3da8913522d" meta-selinux-dl = "master-wr:0e044fd49b16872966bf1d3c8e99d12df4bc6831" meta-mingw-dl = "master-wr:8fc9becbb6f0d96b86b55969238e69fb9d8d3bb5" meta-security-dl = "master-wr:d43ef6844eee8734f943f23e3e1a983b3094ca9e" meta-efi-secure-boot-dl = "master-wr:b79180d67c83c0fdf317c0583fa9a8e5fdb21b86"
Re: [linux-yocto] [PATCH 1/1] xilinx-zynqmp: add the basic support xilinx-zynqmp
Sorry about that. I was traveling this week, and kept forgetting to create the branch. It should be in place now. Bruce On Thu, Jun 13, 2019 at 3:48 AM Zumeng Chen wrote: > > 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 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 >
Re: [linux-yocto] [PATCH 1/1] xilinx-zynqmp: add the basic support xilinx-zynqmp
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 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
Re: [linux-yocto] [PATCH 1/1] xilinx-zynqmp: add the basic support xilinx-zynqmp
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 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 +
Re: [linux-yocto] [PATCH 1/1] xilinx-zynqmp: add the basic support xilinx-zynqmp
On 6/10/19 9:37 PM, Bruce Ashfield wrote: On Sun, Jun 9, 2019 at 8:00 PM Zumeng Chen 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
Re: [linux-yocto] [PATCH 1/1] xilinx-zynqmp: add the basic support xilinx-zynqmp
On Sun, Jun 9, 2019 at 8:00 PM Zumeng Chen 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. 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 > >
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] [PATCH 1/1] xilinx-zynqmp: add the basic support xilinx-zynqmp
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
Re: [linux-yocto] [PATCH 1/1] xilinx-zynqmp: add the basic support xilinx-zynqmp
On Thu, 6 Jun 2019 at 10:16, Zumeng Chen wrote: > > > On 6/6/19 1:19 AM, Bruce Ashfield wrote: > > On Wed, Jun 5, 2019 at 4:02 AM Zumeng Chen > > 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 > >> --- > >> 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 000..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 000..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
Re: [linux-yocto] [PATCH 1/1] xilinx-zynqmp: add the basic support xilinx-zynqmp
On 6/6/19 1:19 AM, Bruce Ashfield wrote: On Wed, Jun 5, 2019 at 4:02 AM Zumeng Chen 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 --- 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 000..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 000..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
Re: [linux-yocto] [PATCH 1/1] xilinx-zynqmp: add the basic support xilinx-zynqmp
On 6/5/19 11:16 PM, Bruce Ashfield wrote: On Wed, Jun 5, 2019 at 4:08 AM Zumeng Chen wrote: Hi Bruce, Forget this party :) xilinx-zynqmp is arm64 BSP with cortexA53, and it seems stable in mainline to build and boot, so I add it into linux-yocto-dev and yocto-kernel-cache. This email is just about scc/cfg, no extra kernel patches is involved. So I leave it to you for linux-yocto-dev. Anyway, here is just a reminder: Hi Zumeng, This looks great! I'll have a closer look at the fragments later today, but wanted to follow up to let you know that I've received it. $ pwd layers/wrlinux/git/linux-yocto-dev $ git checkout -b standard/xilinx-zynqmp origin/standard/base $ git branch master * standard/xilinx-zynqmp This patch is safe for both master and yocto-5.0 branch in yocto-kernel-cache git repo. Excellent! Do you have some bootlogs to share for the 5.0 and -dev boot ? I'd like to include them with the fragments. Yes, absolutely, here it is: ZynqMP> setenv bootargs console=ttyPS0,115200 root=/dev/mmcblk0p2 rw rootwait earlycon=cdns,mmio,0xFF00 clk_ignore_unused ip=dhcp ZynqMP> setenv ipaddr ; setenv serverip x ZynqMP> tftpboot 0x1000 Image; tftpboot 0x1180 dtb; booti 0x1000 - 0x1180 Using ethernet@ff0e device TFTP from server 128.224.162.211; our IP address is 128.224.162.99 Filename 'Image'. Load address: 0x1000 Loading: # # # # # # # # # # # # # # # # # # 11.7 MiB/s done Bytes transferred = 16347648 (f97200 hex) Using ethernet@ff0e device TFTP from server 128.224.162.211; our IP address is 128.224.162.99 Filename 'dtb'. Load address: 0x1180 Loading: ## 4.7 MiB/s done Bytes transferred = 19746 (4d22 hex) ## Flattened Device Tree blob at 1180 Booting using the fdt blob at 0x1180 Loading Device Tree to 07ff8000, end 07fffd21 ... OK Starting kernel ... Booting Linux on physical CPU 0x00 [0x410fd034] Linux version 5.2.0-rc3-yoctodev-standard (oe-user@oe-host) (gcc version 9.1.0 (GCC)) #1 SMP PREEMPT Wed Jun 5 06:18:52 UTC 2019 Machine model: ZynqMP ZCU102 Rev1.0 earlycon: cdns0 at MMIO 0xff00 (options '') printk: bootconsole [cdns0] enabled efi: Getting EFI parameters from FDT: efi: UEFI not found. cma: Reserved 256 MiB at 0x6fc0 psci: probing for conduit method from DT. psci: PSCIv1.1 detected in firmware. psci: Using standard PSCI v0.2 function IDs psci: MIGRATE_INFO_TYPE not supported. psci: SMC Calling Convention v1.1 percpu: Embedded 30 pages/cpu s83224 r8192 d31464 u122880 Detected VIPT I-cache on CPU0 CPU features: detected: ARM erratum 845719 Speculative Store Bypass Disable mitigation not required Built 1 zonelists, mobility grouping on. Total pages: 1031940 Kernel command line: console=ttyPS0,115200 root=/dev/mmcblk0p2 rw rootwait earlycon=cdns,mmio,0xFF00 clk_ignore_unused ip=dhcp Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes) Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes) software IO TLB: mapped [mem 0x6bc0-0x6fc0] (64MB) Memory: 3768204K/4193280K available (10748K kernel code, 1180K rwdata, 2764K rodata, 1216K init, 394K bss, 162932K reserved, 262144K cma-reserved) SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 ftrace: allocating 36242 entries in 142 pages rcu: Preemptible hierarchical RCU implementation. rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4. Tasks RCU enabled. rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies. rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0 GIC: Adjusting CPU interface base to 0xf902f000 GIC: Using split EOI/Deactivate mode random: get_random_bytes called from start_kernel+0x324/0x4bc with crng_init=0 arch_timer: cp15 timer(s) running
Re: [linux-yocto] [PATCH 1/1] xilinx-zynqmp: add the basic support xilinx-zynqmp
On Wed, Jun 5, 2019 at 4:02 AM Zumeng Chen 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 > --- > 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 000..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 000..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. > +# > +#. > + > + > +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 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 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 ? > + > +# 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 >
Re: [linux-yocto] [PATCH 1/1] xilinx-zynqmp: add the basic support xilinx-zynqmp
On Wed, Jun 5, 2019 at 4:08 AM Zumeng Chen wrote: > > Hi Bruce, > > Forget this party :) > > > xilinx-zynqmp is arm64 BSP with cortexA53, and it seems stable in mainline > to build and boot, so I add it into linux-yocto-dev and yocto-kernel-cache. > This email is just about scc/cfg, no extra kernel patches is involved. So > I leave it to you for linux-yocto-dev. Anyway, here is just a reminder: Hi Zumeng, This looks great! I'll have a closer look at the fragments later today, but wanted to follow up to let you know that I've received it. > >$ pwd > layers/wrlinux/git/linux-yocto-dev >$ git checkout -b standard/xilinx-zynqmp origin/standard/base >$ git branch >master > * standard/xilinx-zynqmp > > This patch is safe for both master and yocto-5.0 branch in > yocto-kernel-cache git repo. Excellent! Do you have some bootlogs to share for the 5.0 and -dev boot ? I'd like to include them with the fragments. > > bitbake core-image-minimal core-image-base core-image-sato with > --template=feature/linux-yocto-dev > all passed. and boot as well. > > If you need me to add the bsp template into meta-yocto-bsp since there is no > real arm64 BSP there, just tell me, it's easy and really fast. This would be a good idea as well. Let me think on it a bit longer and I can follow up once I have the fragments merged and hopefully some boot tests completed. Bruce > > Cheers, > Zumeng > > On 6/5/19 3:57 PM, Zumeng Chen wrote: > > This patch is to add scc/cfg meta to build and boot zcu102 board with the > > bsp > > of xilinx-zynqmp. > > > > Signed-off-by: Zumeng.Chen > > --- > > 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 000..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 000..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. > > +# > > +#. > > + > > + > > +CONFIG_ARM64=y > > +CONFIG_ARCH_ZYNQMP=y > > +CONFIG_ARM64_4K_PAGES=y > > +CONFIG_SMP=y > > +CONFIG_NR_CPUS=8 > > +CONFIG_HOTPLUG_CPU=y > > + > > +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 > > + > > +# 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 > >
Re: [linux-yocto] [PATCH 1/1] xilinx-zynqmp: add the basic support xilinx-zynqmp
Hi Bruce, Forget this party :) xilinx-zynqmp is arm64 BSP with cortexA53, and it seems stable in mainline to build and boot, so I add it into linux-yocto-dev and yocto-kernel-cache. This email is just about scc/cfg, no extra kernel patches is involved. So I leave it to you for linux-yocto-dev. Anyway, here is just a reminder: $ pwd layers/wrlinux/git/linux-yocto-dev $ git checkout -b standard/xilinx-zynqmp origin/standard/base $ git branch master * standard/xilinx-zynqmp This patch is safe for both master and yocto-5.0 branch in yocto-kernel-cache git repo. bitbake core-image-minimal core-image-base core-image-sato with --template=feature/linux-yocto-dev all passed. and boot as well. If you need me to add the bsp template into meta-yocto-bsp since there is no real arm64 BSP there, just tell me, it's easy and really fast. Cheers, Zumeng On 6/5/19 3:57 PM, Zumeng Chen wrote: This patch is to add scc/cfg meta to build and boot zcu102 board with the bsp of xilinx-zynqmp. Signed-off-by: Zumeng.Chen --- 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 000..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 000..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. +# +#. + + +CONFIG_ARM64=y +CONFIG_ARCH_ZYNQMP=y +CONFIG_ARM64_4K_PAGES=y +CONFIG_SMP=y +CONFIG_NR_CPUS=8 +CONFIG_HOTPLUG_CPU=y + +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 + +# 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 + +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"
[linux-yocto] [PATCH 1/1] xilinx-zynqmp: add the basic support xilinx-zynqmp
This patch is to add scc/cfg meta to build and boot zcu102 board with the bsp of xilinx-zynqmp. Signed-off-by: Zumeng.Chen --- 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 000..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 000..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. +# +#. + + +CONFIG_ARM64=y +CONFIG_ARCH_ZYNQMP=y +CONFIG_ARM64_4K_PAGES=y +CONFIG_SMP=y +CONFIG_NR_CPUS=8 +CONFIG_HOTPLUG_CPU=y + +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 + +# 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 + +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 + +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 +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
