Re: [meta-xilinx] Pyro -> Rocko: "Nothing PROVIDES 'device-tree'" error?
On 19 March 2018 at 23:00, Giordon Stark wrote: > Comments inline. > > On Mon, Mar 19, 2018 at 4:18 AM Nathan Rossi wrote: >> >> On 19 March 2018 at 01:42, Giordon Stark wrote: >> > Hi Nathan, >> > >> > On Sun, Mar 18, 2018 at 6:29 AM Nathan Rossi >> > wrote: >> >> >> >> On 18 March 2018 at 04:57, Giordon Stark wrote: >> >> > Hi, >> >> > >> >> > Based on Jorge's suggestion (cc'd), I uncommented my lines in >> >> > device-tree.bbappend to set compatible machine = ".*" for my >> >> > particular >> >> > boards as it is being done upstream... and bitbake seems to be >> >> > happier >> >> > with >> >> > that, but then I run into this error >> >> >> >> Yes that change was done for rocko. It was done to prevent >> >> expectations around device-tree supporting machines where the user has >> >> not provided the device tree files to build, in order to make it clear >> >> what pieces are needed to build for custom machines. >> > >> > >> > Can you point to the specific change made? It's not clear to me that >> > adding >> > >> > COMPATIBLE_MACHINE_my-machine = ".*" >> > >> > actually makes this situation clearer, rather than say >> > >> > COMPATIBLE_MACHINE_my-machine = "my_machine" >> >> The change that made requirement of COMPATIBLE_MACHINE to be set is: >> >> >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/commit/?id=eb0abe0230 >> > > I see. How is this change affecting the zynqmp boards? I don't see a > bbappends adding COMPATIBLE_MACHINE for them? It only affects machines that depend on device-tree. The zcu102-zynqmp machine doesn't depend or use the device-tree recipe (as such no files or COMPATIBLE_MACHINE), its device trees are sourced from the kernel. Regards, Nathan > >> >> There is not a lot of difference between the two ways of setting >> COMPATIBLE_MACHINE as you have described above. >> >> Just be careful not to use "_" in machine names, or you will hit issues. >> >> > >> > So I went ahead and set SPL_BINARY = "" to clear it out, and updated >> > platform-init but then I got a boot-bin recipe related error as well as >> > the >> > fact that platform-init can't find the ps*init files. I guess a lot of >> > this >> > is now requiring tighter integration with the SDK which is slightly >> > breaking >> > my use case.. >> >> I don't think there is any integration between the SDK tooling and the >> platform-init recipe or for that matter the >> virtual/xilinx-platform-init provider. But u-boot-xlnx will _not_ >> provide virtual/boot-bin if it does not have the platform-init files, >> though that is intended in your case. You might need to select a >> different provider for virtual/boot-bin if you are using the SDK >> tooling layer and depending on that virtual target. >> >> > >> > I'm currently using the FSBL method at the moment, so I'm doing this via >> > CROPS (virtual machine + automating the build in continuous integration) >> > and >> > then taking the bitbake outputs and loading them up into my SDK on a >> > different machine to make the BOOT.bin. Is this not possible anymore >> > with >> > all of these changes and requiring the zcu102-zynqmp.conf? Should I just >> > go >> > one step higher and set all of these things myself manually and drop >> > platform-init/boot-bin/spl? >> >> If you are not building your machine exactly like the >> zcu102-zynqmp.conf then you are likely better off copying it and >> modifying it the way you want instead of including it. But looking at >> your layers master branch it appears you have already made that >> change. So I am not sure of the exact question you are asking here? > > > Yes, very observant :) I've been switching things over because I'm now > realizing my (lazy!) days of copying the zcu102-zynqmp.conf is probably > coming to an end... I suspect my problem is that I had to add the > "zcu102-zynqmp" to the machine overrides for when I initially copied things > over, and that caused issues down the line with things like platform-init > and so on -- with all the changes to COMPATIBLE_MACHINE. > > G > >> >> >> Regards, >> Nathan > > -- > Giordon Stark -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] Pyro -> Rocko: "Nothing PROVIDES 'device-tree'" error?
Comments inline. On Mon, Mar 19, 2018 at 4:18 AM Nathan Rossi wrote: > On 19 March 2018 at 01:42, Giordon Stark wrote: > > Hi Nathan, > > > > On Sun, Mar 18, 2018 at 6:29 AM Nathan Rossi > wrote: > >> > >> On 18 March 2018 at 04:57, Giordon Stark wrote: > >> > Hi, > >> > > >> > Based on Jorge's suggestion (cc'd), I uncommented my lines in > >> > device-tree.bbappend to set compatible machine = ".*" for my > particular > >> > boards as it is being done upstream... and bitbake seems to be happier > >> > with > >> > that, but then I run into this error > >> > >> Yes that change was done for rocko. It was done to prevent > >> expectations around device-tree supporting machines where the user has > >> not provided the device tree files to build, in order to make it clear > >> what pieces are needed to build for custom machines. > > > > > > Can you point to the specific change made? It's not clear to me that > adding > > > > COMPATIBLE_MACHINE_my-machine = ".*" > > > > actually makes this situation clearer, rather than say > > > > COMPATIBLE_MACHINE_my-machine = "my_machine" > > The change that made requirement of COMPATIBLE_MACHINE to be set is: > > http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/commit/?id=eb0abe0230 > > I see. How is this change affecting the zynqmp boards? I don't see a bbappends adding COMPATIBLE_MACHINE for them? > There is not a lot of difference between the two ways of setting > COMPATIBLE_MACHINE as you have described above. > > Just be careful not to use "_" in machine names, or you will hit issues. > > > > > So I went ahead and set SPL_BINARY = "" to clear it out, and updated > > platform-init but then I got a boot-bin recipe related error as well as > the > > fact that platform-init can't find the ps*init files. I guess a lot of > this > > is now requiring tighter integration with the SDK which is slightly > breaking > > my use case.. > > I don't think there is any integration between the SDK tooling and the > platform-init recipe or for that matter the > virtual/xilinx-platform-init provider. But u-boot-xlnx will _not_ > provide virtual/boot-bin if it does not have the platform-init files, > though that is intended in your case. You might need to select a > different provider for virtual/boot-bin if you are using the SDK > tooling layer and depending on that virtual target. > > > > > I'm currently using the FSBL method at the moment, so I'm doing this via > > CROPS (virtual machine + automating the build in continuous integration) > and > > then taking the bitbake outputs and loading them up into my SDK on a > > different machine to make the BOOT.bin. Is this not possible anymore with > > all of these changes and requiring the zcu102-zynqmp.conf? Should I just > go > > one step higher and set all of these things myself manually and drop > > platform-init/boot-bin/spl? > > If you are not building your machine exactly like the > zcu102-zynqmp.conf then you are likely better off copying it and > modifying it the way you want instead of including it. But looking at > your layers master branch it appears you have already made that > change. So I am not sure of the exact question you are asking here? > Yes, very observant :) I've been switching things over because I'm now realizing my (lazy!) days of copying the zcu102-zynqmp.conf is probably coming to an end... I suspect my problem is that I had to add the "zcu102-zynqmp" to the machine overrides for when I initially copied things over, and that caused issues down the line with things like platform-init and so on -- with all the changes to COMPATIBLE_MACHINE. G > > Regards, > Nathan > -- Giordon Stark -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] Pyro -> Rocko: "Nothing PROVIDES 'device-tree'" error?
On 19 March 2018 at 01:42, Giordon Stark wrote: > Hi Nathan, > > On Sun, Mar 18, 2018 at 6:29 AM Nathan Rossi wrote: >> >> On 18 March 2018 at 04:57, Giordon Stark wrote: >> > Hi, >> > >> > Based on Jorge's suggestion (cc'd), I uncommented my lines in >> > device-tree.bbappend to set compatible machine = ".*" for my particular >> > boards as it is being done upstream... and bitbake seems to be happier >> > with >> > that, but then I run into this error >> >> Yes that change was done for rocko. It was done to prevent >> expectations around device-tree supporting machines where the user has >> not provided the device tree files to build, in order to make it clear >> what pieces are needed to build for custom machines. > > > Can you point to the specific change made? It's not clear to me that adding > > COMPATIBLE_MACHINE_my-machine = ".*" > > actually makes this situation clearer, rather than say > > COMPATIBLE_MACHINE_my-machine = "my_machine" The change that made requirement of COMPATIBLE_MACHINE to be set is: http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/commit/?id=eb0abe0230 There is not a lot of difference between the two ways of setting COMPATIBLE_MACHINE as you have described above. Just be careful not to use "_" in machine names, or you will hit issues. > > So I went ahead and set SPL_BINARY = "" to clear it out, and updated > platform-init but then I got a boot-bin recipe related error as well as the > fact that platform-init can't find the ps*init files. I guess a lot of this > is now requiring tighter integration with the SDK which is slightly breaking > my use case.. I don't think there is any integration between the SDK tooling and the platform-init recipe or for that matter the virtual/xilinx-platform-init provider. But u-boot-xlnx will _not_ provide virtual/boot-bin if it does not have the platform-init files, though that is intended in your case. You might need to select a different provider for virtual/boot-bin if you are using the SDK tooling layer and depending on that virtual target. > > I'm currently using the FSBL method at the moment, so I'm doing this via > CROPS (virtual machine + automating the build in continuous integration) and > then taking the bitbake outputs and loading them up into my SDK on a > different machine to make the BOOT.bin. Is this not possible anymore with > all of these changes and requiring the zcu102-zynqmp.conf? Should I just go > one step higher and set all of these things myself manually and drop > platform-init/boot-bin/spl? If you are not building your machine exactly like the zcu102-zynqmp.conf then you are likely better off copying it and modifying it the way you want instead of including it. But looking at your layers master branch it appears you have already made that change. So I am not sure of the exact question you are asking here? Regards, Nathan -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] Pyro -> Rocko: "Nothing PROVIDES 'device-tree'" error?
Hi Nathan, On Sun, Mar 18, 2018 at 6:29 AM Nathan Rossi wrote: > On 18 March 2018 at 04:57, Giordon Stark wrote: > > Hi, > > > > Based on Jorge's suggestion (cc'd), I uncommented my lines in > > device-tree.bbappend to set compatible machine = ".*" for my particular > > boards as it is being done upstream... and bitbake seems to be happier > with > > that, but then I run into this error > > Yes that change was done for rocko. It was done to prevent > expectations around device-tree supporting machines where the user has > not provided the device tree files to build, in order to make it clear > what pieces are needed to build for custom machines. > Can you point to the specific change made? It's not clear to me that adding COMPATIBLE_MACHINE_my-machine = ".*" actually makes this situation clearer, rather than say COMPATIBLE_MACHINE_my-machine = "my_machine" So I went ahead and set SPL_BINARY = "" to clear it out, and updated platform-init but then I got a boot-bin recipe related error as well as the fact that platform-init can't find the ps*init files. I guess a lot of this is now requiring tighter integration with the SDK which is slightly breaking my use case.. I'm currently using the FSBL method at the moment, so I'm doing this via CROPS (virtual machine + automating the build in continuous integration) and then taking the bitbake outputs and loading them up into my SDK on a different machine to make the BOOT.bin. Is this not possible anymore with all of these changes and requiring the zcu102-zynqmp.conf? Should I just go one step higher and set all of these things myself manually and drop platform-init/boot-bin/spl? G > > > > > ERROR: Nothing PROVIDES 'virtual/xilinx-platform-init' (but > > /local/d4/gstark/meta-xilinx/meta-xilinx-bsp/recipes-bsp/u-boot/ > u-boot-xlnx_2017.3.bb > > DEPENDS on or otherwise requires it) > > platform-init PROVIDES virtual/xilinx-platform-init but was skipped: > > incompatible with machine gfex-prototype3a (not in COMPATIBLE_MACHINE) > > ERROR: Required build target 'zynq-base' has no buildable providers. > > Missing or unbuildable dependency chain was: ['zynq-base', > > 'virtual/bootloader', 'virtual/xilinx-platform-init'] > > > > So I suppose I need to add a platform-init/platform-init.bbappend file > that > > overrides the compatible machine again as well... > > > > This seems slightly hacky, and maybe indicative that I've done something > > wrong in defining a machine on top of zcu102-zynqmp somehow... but this > > worked in pyro, so there must be a change between pyro and rocko... any > > ideas? > > There were some changes to the u-boot spl platform detection logic, > this may have changed your use case. But if you don't want u-boot SPL > for zynqmp, don't set SPL_BINARY to boot.bin. > > If you do want SPL make sure you are doing one of the following: > > * using a defconfig that provides platform init files (e.g. > xilinx_zynqmp_zcu102_rev1_0_defconfig), u-boot-xlnx had some churn to > which configs provided platform-init files, check you are using the > desired one > * appending to platform-init to include the files in your layer, and > that platform-init has COMPATIBLE_MACHINE set to match your machine > * patching u-boot to include the platform init files, and that you are > adding the defconfig that provides them to the HAS_PLATFORM_INIT > variable. > > Regards, > Nathan > > > > > Giordon > > > > > > > > On Sat, Mar 17, 2018 at 1:10 PM Giordon Stark wrote: > >> > >> Hi, > >> > >> I've been trying to understand/figure out what changed to break > something > >> that was definitely working on pyro -- but it's been hard to trace > changes > >> because of the move/restructuring... > >> > >> When I re-run bitbake for an image that I've built in pyro just fine > using > >> all the same code, I see this error about "Nothing PROVIDES > 'device-tree' as > >> seen below. > >> > >> This seems to stem from how I tell u-boot about the dtb files that have > >> been made: > >> > https://github.com/kratsg/meta-l1calo/blob/master/recipes-bsp/u-boot/u-boot-xlnx.inc > >> (DEPENDS_append_... = " device-tree"). Is there a new way of doing it? > >> > >> ERROR: Nothing PROVIDES 'device-tree' (but > >> /local/d4/gstark/meta-xilinx/meta-xilinx-bsp/recipes-bsp/u-boot/ > u-boot-xlnx_2017.3.bb > >> DEPENDS on or otherwise requires it) > >> device-tree was skipped: incompatible with machine gfex-prototype3a (not > >> in COMPATIBLE_MACHINE) > >> ERROR: Required build target 'zynq-base' has no buildable providers. > >> Missing or unbuildable dependency chain was: ['zynq-base', > >> 'virtual/bootloader', 'device-tree'] > >> > >> Summary: There were 2 ERROR messages shown, returning a non-zero exit > >> code. > >> > >> Giordon > >> -- > >> Giordon Stark > > > > -- > > Giordon Stark > > > > -- > > ___ > > meta-xilinx mailing list > > meta-xilinx@yoctoproject.org > > https://lists.yoctoproject.org/listinfo/meta-xilinx > > > -- Giordon Stark
Re: [meta-xilinx] Pyro -> Rocko: "Nothing PROVIDES 'device-tree'" error?
On 18 March 2018 at 04:57, Giordon Stark wrote: > Hi, > > Based on Jorge's suggestion (cc'd), I uncommented my lines in > device-tree.bbappend to set compatible machine = ".*" for my particular > boards as it is being done upstream... and bitbake seems to be happier with > that, but then I run into this error Yes that change was done for rocko. It was done to prevent expectations around device-tree supporting machines where the user has not provided the device tree files to build, in order to make it clear what pieces are needed to build for custom machines. > > ERROR: Nothing PROVIDES 'virtual/xilinx-platform-init' (but > /local/d4/gstark/meta-xilinx/meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-xlnx_2017.3.bb > DEPENDS on or otherwise requires it) > platform-init PROVIDES virtual/xilinx-platform-init but was skipped: > incompatible with machine gfex-prototype3a (not in COMPATIBLE_MACHINE) > ERROR: Required build target 'zynq-base' has no buildable providers. > Missing or unbuildable dependency chain was: ['zynq-base', > 'virtual/bootloader', 'virtual/xilinx-platform-init'] > > So I suppose I need to add a platform-init/platform-init.bbappend file that > overrides the compatible machine again as well... > > This seems slightly hacky, and maybe indicative that I've done something > wrong in defining a machine on top of zcu102-zynqmp somehow... but this > worked in pyro, so there must be a change between pyro and rocko... any > ideas? There were some changes to the u-boot spl platform detection logic, this may have changed your use case. But if you don't want u-boot SPL for zynqmp, don't set SPL_BINARY to boot.bin. If you do want SPL make sure you are doing one of the following: * using a defconfig that provides platform init files (e.g. xilinx_zynqmp_zcu102_rev1_0_defconfig), u-boot-xlnx had some churn to which configs provided platform-init files, check you are using the desired one * appending to platform-init to include the files in your layer, and that platform-init has COMPATIBLE_MACHINE set to match your machine * patching u-boot to include the platform init files, and that you are adding the defconfig that provides them to the HAS_PLATFORM_INIT variable. Regards, Nathan > > Giordon > > > > On Sat, Mar 17, 2018 at 1:10 PM Giordon Stark wrote: >> >> Hi, >> >> I've been trying to understand/figure out what changed to break something >> that was definitely working on pyro -- but it's been hard to trace changes >> because of the move/restructuring... >> >> When I re-run bitbake for an image that I've built in pyro just fine using >> all the same code, I see this error about "Nothing PROVIDES 'device-tree' as >> seen below. >> >> This seems to stem from how I tell u-boot about the dtb files that have >> been made: >> https://github.com/kratsg/meta-l1calo/blob/master/recipes-bsp/u-boot/u-boot-xlnx.inc >> (DEPENDS_append_... = " device-tree"). Is there a new way of doing it? >> >> ERROR: Nothing PROVIDES 'device-tree' (but >> /local/d4/gstark/meta-xilinx/meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-xlnx_2017.3.bb >> DEPENDS on or otherwise requires it) >> device-tree was skipped: incompatible with machine gfex-prototype3a (not >> in COMPATIBLE_MACHINE) >> ERROR: Required build target 'zynq-base' has no buildable providers. >> Missing or unbuildable dependency chain was: ['zynq-base', >> 'virtual/bootloader', 'device-tree'] >> >> Summary: There were 2 ERROR messages shown, returning a non-zero exit >> code. >> >> Giordon >> -- >> Giordon Stark > > -- > Giordon Stark > > -- > ___ > meta-xilinx mailing list > meta-xilinx@yoctoproject.org > https://lists.yoctoproject.org/listinfo/meta-xilinx > -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] Pyro -> Rocko: "Nothing PROVIDES 'device-tree'" error?
Hi, Based on Jorge's suggestion (cc'd), I uncommented my lines in device-tree.bbappend to set compatible machine = ".*" for my particular boards as it is being done upstream... and bitbake seems to be happier with that, but then I run into this error ERROR: Nothing PROVIDES 'virtual/xilinx-platform-init' (but /local/d4/gstark/meta-xilinx/meta-xilinx-bsp/recipes-bsp/u-boot/ u-boot-xlnx_2017.3.bb DEPENDS on or otherwise requires it) platform-init PROVIDES virtual/xilinx-platform-init but was skipped: incompatible with machine gfex-prototype3a (not in COMPATIBLE_MACHINE) ERROR: Required build target 'zynq-base' has no buildable providers. Missing or unbuildable dependency chain was: ['zynq-base', 'virtual/bootloader', 'virtual/xilinx-platform-init'] So I suppose I need to add a platform-init/platform-init.bbappend file that overrides the compatible machine again as well... This seems slightly hacky, and maybe indicative that I've done something wrong in defining a machine on top of zcu102-zynqmp somehow... but this worked in pyro, so there must be a change between pyro and rocko... any ideas? Giordon On Sat, Mar 17, 2018 at 1:10 PM Giordon Stark wrote: > Hi, > > I've been trying to understand/figure out what changed to break something > that was definitely working on pyro -- but it's been hard to trace changes > because of the move/restructuring... > > When I re-run bitbake for an image that I've built in pyro just fine using > all the same code, I see this error about "Nothing PROVIDES 'device-tree' > as seen below. > > This seems to stem from how I tell u-boot about the dtb files that have > been made: > https://github.com/kratsg/meta-l1calo/blob/master/recipes-bsp/u-boot/u-boot-xlnx.inc > (DEPENDS_append_... > = " device-tree"). Is there a new way of doing it? > > ERROR: Nothing PROVIDES 'device-tree' (but > /local/d4/gstark/meta-xilinx/meta-xilinx-bsp/recipes-bsp/u-boot/ > u-boot-xlnx_2017.3.bb DEPENDS on or otherwise requires it) > device-tree was skipped: incompatible with machine gfex-prototype3a (not > in COMPATIBLE_MACHINE) > ERROR: Required build target 'zynq-base' has no buildable providers. > Missing or unbuildable dependency chain was: ['zynq-base', > 'virtual/bootloader', 'device-tree'] > > Summary: There were 2 ERROR messages shown, returning a non-zero exit code. > > Giordon > -- > Giordon Stark > -- Giordon Stark -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
