[meta-xilinx] Pyro -> Rocko: "Nothing PROVIDES 'device-tree'" error?

[Nathan Rossi]

On 19 March 2018 at 23:00, Giordon Stark <kratsg at gmail.com> wrote:
> Comments inline.
>
> On Mon, Mar 19, 2018 at 4:18 AM Nathan Rossi <nathan at nathanrossi.com> wrote:
>>
>> On 19 March 2018 at 01:42, Giordon Stark <kratsg at gmail.com> wrote:
>> > Hi Nathan,
>> >
>> > On Sun, Mar 18, 2018 at 6:29 AM Nathan Rossi <nathan at nathanrossi.com>
>> > wrote:
>> >>
>> >> On 18 March 2018 at 04:57, Giordon Stark <kratsg at gmail.com> 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