On 19 March 2018 at 23:00, Giordon Stark <[email protected]> wrote: > Comments inline. > > On Mon, Mar 19, 2018 at 4:18 AM Nathan Rossi <[email protected]> wrote: >> >> On 19 March 2018 at 01:42, Giordon Stark <[email protected]> wrote: >> > Hi Nathan, >> > >> > On Sun, Mar 18, 2018 at 6:29 AM Nathan Rossi <[email protected]> >> > wrote: >> >> >> >> On 18 March 2018 at 04:57, Giordon Stark <[email protected]> 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 [email protected] https://lists.yoctoproject.org/listinfo/meta-xilinx
