Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Le ven. 3 déc. 2021 à 21:14, Simon Glass a écrit : > Hi François, > > On Fri, 3 Dec 2021 at 10:03, François Ozog > wrote: > > > > > > > > On Fri, 3 Dec 2021 at 17:04, Simon Glass wrote: > >> > >> Hi Tom, > >> > >> On Fri, 3 Dec 2021 at 05:14, Tom Rini wrote: > >> > > >> > On Thu, Dec 02, 2021 at 12:23:10PM -0700, Simon Glass wrote: > >> > > Hi François, > >> > > > >> > > On Thu, 2 Dec 2021 at 11:44, François Ozog < > francois.o...@linaro.org> wrote: > >> > > > > >> > > > Hi Simon > >> > > > > >> > > > On Thu, 2 Dec 2021 at 19:29, Simon Glass > wrote: > >> > > >> > >> > > >> Hi François, > >> > > >> > >> > > >> On Thu, 2 Dec 2021 at 11:17, François Ozog < > francois.o...@linaro.org> wrote: > >> > > >> > > >> > > >> > Hi Simon > >> > > >> > > >> > > >> > On Thu, 2 Dec 2021 at 19:05, Simon Glass > wrote: > >> > > >> >> > >> > > >> >> Hi Tom, > >> > > >> >> > >> > > >> >> On Thu, 2 Dec 2021 at 10:56, Tom Rini > wrote: > >> > > >> >> > > >> > > >> >> > On Thu, Dec 02, 2021 at 05:40:46PM +, Oleksandr > Andrushchenko wrote: > >> > > >> >> > > Hi, Simon! > >> > > >> >> > > > >> > > >> >> > > Sorry for being late to the party > >> > > >> >> > > > >> > > >> >> > > On 02.12.21 17:59, Simon Glass wrote: > >> > > >> >> > > > Add an empty file to prevent build errors when building > with > >> > > >> >> > > > CONFIG_OF_SEPARATE enabled. > >> > > >> >> > > > > >> > > >> >> > > > The build instructions in U-Boot do not provide enough > detail to build a > >> > > >> >> > > > useful devicetree, unfortunately. > >> > > >> >> > > Xen guest doesn't use any built-in device trees as the > guest's device tree is provided > >> > > >> >> > > by the Xen hypervisor itself and is generated at the > virtual machine creation time: it is > >> > > >> >> > > populated with memory size, number of CPUs etc. based on > [1]. > >> > > >> >> > > So, even if we provide some device tree here it must not > be used by U-boot at > >> > > >> >> > > the end of the day. Thus, it might be a reasonable > solution to provide an empty device > >> > > >> >> > > tree as you do, but put a comment that it is not used. > >> > > >> >> > > >> > > >> >> > So another example of why this series is taking things in > the wrong > >> > > >> >> > direction. > >> > > >> >> > >> > > >> >> Why? > >> > > >> > > >> > > >> > I only had that comment in mind: "there is none so deaf as he > who will not hear." > >> > > >> > >> > > >> Hey, stop the pile-on. It's not useful. > >> > > >> > >> > > >> I've guided U-Boot's use of devicetree for 10 years > successfully. The > >> > > >> current state is a mess and I just to straighten it out. > >> > > >> > >> > > > I admire your talent and knowledge. > >> > > > I know you are 99,99% of the time correct and spot on for your > comments in many meetings we were attending. > >> > > > When you questioned a number of points I made, I first tried to > understand what I got wrong because you said it. > >> > > > And you were right ;-) > >> > > > For this topic, I made every effort to come to your position, but > definitively can't. > >> > > > >> > > Thank you. I think this will come together in a few years when > >> > > devicetree is sorted out in U-Boot and Binman is more widely used. > >> > > > >> > > For this series, if and when it is applied, I predict: > >> > > - it will not cause any confusion > >> > > - it will aid development > >> > > - it will help with discoverability, pressuring people to explain > how > >> > > to build for their systems > >> > > - it will be a good basis for future work (we have a long list) > >> > > - everyone will wonder what the fuss was about > >> > > > >> > > Here is the commit that introduced OF_PRIOR_STAGE. It attracted no > >> > > such push-back. > >> > > > >> > > commit 894c3ad27fa940beb7fdc07d01dcfe81c03d0481 > >> > > Author: Thomas Fitzsimmons > >> > > Date: Fri Jun 8 17:59:45 2018 -0400 > >> > > > >> > > board: arm: Add support for Broadcom BCM7445 > >> > > > >> > > Add support for loading U-Boot on the Broadcom 7445 SoC. This > port > >> > > assumes Broadcom's BOLT bootloader is acting as the second stage > >> > > bootloader, and U-Boot is acting as the third stage bootloader, > loaded > >> > > as an ELF program by BOLT. > >> > > > >> > > Signed-off-by: Thomas Fitzsimmons > >> > > Cc: Stefan Roese > >> > > Cc: Tom Rini > >> > > Cc: Florian Fainelli > >> > > >> > I want to cycle back over here. Yes, historically a number of things > >> > came in that perhaps shouldn't have. I went with "well, this is what > we > >> > need to handle this case I suppose" and applied it. > >> > >> Yes and we need to move things forward. We can't just object to things > >> without an alternative. > > > > As far as I can follow the threads, I proposed the dts to be empty to > pass compilation and move forward, but I think you haven't replied. The > empty dts can contain a comment pointing to documentation, which could > describe the DT lifecycle of the platform, and a
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
On Fri, Dec 03, 2021 at 01:14:04PM -0700, Simon Glass wrote: > Hi François, > > On Fri, 3 Dec 2021 at 10:03, François Ozog wrote: > > > > > > > > On Fri, 3 Dec 2021 at 17:04, Simon Glass wrote: > >> > >> Hi Tom, > >> > >> On Fri, 3 Dec 2021 at 05:14, Tom Rini wrote: > >> > > >> > On Thu, Dec 02, 2021 at 12:23:10PM -0700, Simon Glass wrote: > >> > > Hi François, > >> > > > >> > > On Thu, 2 Dec 2021 at 11:44, François Ozog > >> > > wrote: > >> > > > > >> > > > Hi Simon > >> > > > > >> > > > On Thu, 2 Dec 2021 at 19:29, Simon Glass wrote: > >> > > >> > >> > > >> Hi François, > >> > > >> > >> > > >> On Thu, 2 Dec 2021 at 11:17, François Ozog > >> > > >> wrote: > >> > > >> > > >> > > >> > Hi Simon > >> > > >> > > >> > > >> > On Thu, 2 Dec 2021 at 19:05, Simon Glass > >> > > >> > wrote: > >> > > >> >> > >> > > >> >> Hi Tom, > >> > > >> >> > >> > > >> >> On Thu, 2 Dec 2021 at 10:56, Tom Rini wrote: > >> > > >> >> > > >> > > >> >> > On Thu, Dec 02, 2021 at 05:40:46PM +, Oleksandr > >> > > >> >> > Andrushchenko wrote: > >> > > >> >> > > Hi, Simon! > >> > > >> >> > > > >> > > >> >> > > Sorry for being late to the party > >> > > >> >> > > > >> > > >> >> > > On 02.12.21 17:59, Simon Glass wrote: > >> > > >> >> > > > Add an empty file to prevent build errors when building > >> > > >> >> > > > with > >> > > >> >> > > > CONFIG_OF_SEPARATE enabled. > >> > > >> >> > > > > >> > > >> >> > > > The build instructions in U-Boot do not provide enough > >> > > >> >> > > > detail to build a > >> > > >> >> > > > useful devicetree, unfortunately. > >> > > >> >> > > Xen guest doesn't use any built-in device trees as the > >> > > >> >> > > guest's device tree is provided > >> > > >> >> > > by the Xen hypervisor itself and is generated at the virtual > >> > > >> >> > > machine creation time: it is > >> > > >> >> > > populated with memory size, number of CPUs etc. based on [1]. > >> > > >> >> > > So, even if we provide some device tree here it must not be > >> > > >> >> > > used by U-boot at > >> > > >> >> > > the end of the day. Thus, it might be a reasonable solution > >> > > >> >> > > to provide an empty device > >> > > >> >> > > tree as you do, but put a comment that it is not used. > >> > > >> >> > > >> > > >> >> > So another example of why this series is taking things in the > >> > > >> >> > wrong > >> > > >> >> > direction. > >> > > >> >> > >> > > >> >> Why? > >> > > >> > > >> > > >> > I only had that comment in mind: "there is none so deaf as he who > >> > > >> > will not hear." > >> > > >> > >> > > >> Hey, stop the pile-on. It's not useful. > >> > > >> > >> > > >> I've guided U-Boot's use of devicetree for 10 years successfully. > >> > > >> The > >> > > >> current state is a mess and I just to straighten it out. > >> > > >> > >> > > > I admire your talent and knowledge. > >> > > > I know you are 99,99% of the time correct and spot on for your > >> > > > comments in many meetings we were attending. > >> > > > When you questioned a number of points I made, I first tried to > >> > > > understand what I got wrong because you said it. > >> > > > And you were right ;-) > >> > > > For this topic, I made every effort to come to your position, but > >> > > > definitively can't. > >> > > > >> > > Thank you. I think this will come together in a few years when > >> > > devicetree is sorted out in U-Boot and Binman is more widely used. > >> > > > >> > > For this series, if and when it is applied, I predict: > >> > > - it will not cause any confusion > >> > > - it will aid development > >> > > - it will help with discoverability, pressuring people to explain how > >> > > to build for their systems > >> > > - it will be a good basis for future work (we have a long list) > >> > > - everyone will wonder what the fuss was about > >> > > > >> > > Here is the commit that introduced OF_PRIOR_STAGE. It attracted no > >> > > such push-back. > >> > > > >> > > commit 894c3ad27fa940beb7fdc07d01dcfe81c03d0481 > >> > > Author: Thomas Fitzsimmons > >> > > Date: Fri Jun 8 17:59:45 2018 -0400 > >> > > > >> > > board: arm: Add support for Broadcom BCM7445 > >> > > > >> > > Add support for loading U-Boot on the Broadcom 7445 SoC. This port > >> > > assumes Broadcom's BOLT bootloader is acting as the second stage > >> > > bootloader, and U-Boot is acting as the third stage bootloader, > >> > > loaded > >> > > as an ELF program by BOLT. > >> > > > >> > > Signed-off-by: Thomas Fitzsimmons > >> > > Cc: Stefan Roese > >> > > Cc: Tom Rini > >> > > Cc: Florian Fainelli > >> > > >> > I want to cycle back over here. Yes, historically a number of things > >> > came in that perhaps shouldn't have. I went with "well, this is what we > >> > need to handle this case I suppose" and applied it. > >> > >> Yes and we need to move things forward. We can't just object to things > >> without an alternative. > > > > As far as I can follow the threads, I proposed the dts to be empty to pass > > compilation
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi François, On Fri, 3 Dec 2021 at 10:03, François Ozog wrote: > > > > On Fri, 3 Dec 2021 at 17:04, Simon Glass wrote: >> >> Hi Tom, >> >> On Fri, 3 Dec 2021 at 05:14, Tom Rini wrote: >> > >> > On Thu, Dec 02, 2021 at 12:23:10PM -0700, Simon Glass wrote: >> > > Hi François, >> > > >> > > On Thu, 2 Dec 2021 at 11:44, François Ozog >> > > wrote: >> > > > >> > > > Hi Simon >> > > > >> > > > On Thu, 2 Dec 2021 at 19:29, Simon Glass wrote: >> > > >> >> > > >> Hi François, >> > > >> >> > > >> On Thu, 2 Dec 2021 at 11:17, François Ozog >> > > >> wrote: >> > > >> > >> > > >> > Hi Simon >> > > >> > >> > > >> > On Thu, 2 Dec 2021 at 19:05, Simon Glass wrote: >> > > >> >> >> > > >> >> Hi Tom, >> > > >> >> >> > > >> >> On Thu, 2 Dec 2021 at 10:56, Tom Rini wrote: >> > > >> >> > >> > > >> >> > On Thu, Dec 02, 2021 at 05:40:46PM +, Oleksandr >> > > >> >> > Andrushchenko wrote: >> > > >> >> > > Hi, Simon! >> > > >> >> > > >> > > >> >> > > Sorry for being late to the party >> > > >> >> > > >> > > >> >> > > On 02.12.21 17:59, Simon Glass wrote: >> > > >> >> > > > Add an empty file to prevent build errors when building with >> > > >> >> > > > CONFIG_OF_SEPARATE enabled. >> > > >> >> > > > >> > > >> >> > > > The build instructions in U-Boot do not provide enough >> > > >> >> > > > detail to build a >> > > >> >> > > > useful devicetree, unfortunately. >> > > >> >> > > Xen guest doesn't use any built-in device trees as the guest's >> > > >> >> > > device tree is provided >> > > >> >> > > by the Xen hypervisor itself and is generated at the virtual >> > > >> >> > > machine creation time: it is >> > > >> >> > > populated with memory size, number of CPUs etc. based on [1]. >> > > >> >> > > So, even if we provide some device tree here it must not be >> > > >> >> > > used by U-boot at >> > > >> >> > > the end of the day. Thus, it might be a reasonable solution to >> > > >> >> > > provide an empty device >> > > >> >> > > tree as you do, but put a comment that it is not used. >> > > >> >> > >> > > >> >> > So another example of why this series is taking things in the >> > > >> >> > wrong >> > > >> >> > direction. >> > > >> >> >> > > >> >> Why? >> > > >> > >> > > >> > I only had that comment in mind: "there is none so deaf as he who >> > > >> > will not hear." >> > > >> >> > > >> Hey, stop the pile-on. It's not useful. >> > > >> >> > > >> I've guided U-Boot's use of devicetree for 10 years successfully. The >> > > >> current state is a mess and I just to straighten it out. >> > > >> >> > > > I admire your talent and knowledge. >> > > > I know you are 99,99% of the time correct and spot on for your >> > > > comments in many meetings we were attending. >> > > > When you questioned a number of points I made, I first tried to >> > > > understand what I got wrong because you said it. >> > > > And you were right ;-) >> > > > For this topic, I made every effort to come to your position, but >> > > > definitively can't. >> > > >> > > Thank you. I think this will come together in a few years when >> > > devicetree is sorted out in U-Boot and Binman is more widely used. >> > > >> > > For this series, if and when it is applied, I predict: >> > > - it will not cause any confusion >> > > - it will aid development >> > > - it will help with discoverability, pressuring people to explain how >> > > to build for their systems >> > > - it will be a good basis for future work (we have a long list) >> > > - everyone will wonder what the fuss was about >> > > >> > > Here is the commit that introduced OF_PRIOR_STAGE. It attracted no >> > > such push-back. >> > > >> > > commit 894c3ad27fa940beb7fdc07d01dcfe81c03d0481 >> > > Author: Thomas Fitzsimmons >> > > Date: Fri Jun 8 17:59:45 2018 -0400 >> > > >> > > board: arm: Add support for Broadcom BCM7445 >> > > >> > > Add support for loading U-Boot on the Broadcom 7445 SoC. This port >> > > assumes Broadcom's BOLT bootloader is acting as the second stage >> > > bootloader, and U-Boot is acting as the third stage bootloader, >> > > loaded >> > > as an ELF program by BOLT. >> > > >> > > Signed-off-by: Thomas Fitzsimmons >> > > Cc: Stefan Roese >> > > Cc: Tom Rini >> > > Cc: Florian Fainelli >> > >> > I want to cycle back over here. Yes, historically a number of things >> > came in that perhaps shouldn't have. I went with "well, this is what we >> > need to handle this case I suppose" and applied it. >> >> Yes and we need to move things forward. We can't just object to things >> without an alternative. > > As far as I can follow the threads, I proposed the dts to be empty to pass > compilation and move forward, but I think you haven't replied. The empty dts > can contain a comment pointing to documentation, which could describe the DT > lifecycle of the platform, and a template dts that could be used for > adventurous developers. That does not go far enough for me. We actually do want to be able to build U-Boot and run it on the board,
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
On Fri, 3 Dec 2021 at 17:04, Simon Glass wrote: > Hi Tom, > > On Fri, 3 Dec 2021 at 05:14, Tom Rini wrote: > > > > On Thu, Dec 02, 2021 at 12:23:10PM -0700, Simon Glass wrote: > > > Hi François, > > > > > > On Thu, 2 Dec 2021 at 11:44, François Ozog > wrote: > > > > > > > > Hi Simon > > > > > > > > On Thu, 2 Dec 2021 at 19:29, Simon Glass wrote: > > > >> > > > >> Hi François, > > > >> > > > >> On Thu, 2 Dec 2021 at 11:17, François Ozog < > francois.o...@linaro.org> wrote: > > > >> > > > > >> > Hi Simon > > > >> > > > > >> > On Thu, 2 Dec 2021 at 19:05, Simon Glass > wrote: > > > >> >> > > > >> >> Hi Tom, > > > >> >> > > > >> >> On Thu, 2 Dec 2021 at 10:56, Tom Rini > wrote: > > > >> >> > > > > >> >> > On Thu, Dec 02, 2021 at 05:40:46PM +, Oleksandr > Andrushchenko wrote: > > > >> >> > > Hi, Simon! > > > >> >> > > > > > >> >> > > Sorry for being late to the party > > > >> >> > > > > > >> >> > > On 02.12.21 17:59, Simon Glass wrote: > > > >> >> > > > Add an empty file to prevent build errors when building > with > > > >> >> > > > CONFIG_OF_SEPARATE enabled. > > > >> >> > > > > > > >> >> > > > The build instructions in U-Boot do not provide enough > detail to build a > > > >> >> > > > useful devicetree, unfortunately. > > > >> >> > > Xen guest doesn't use any built-in device trees as the > guest's device tree is provided > > > >> >> > > by the Xen hypervisor itself and is generated at the virtual > machine creation time: it is > > > >> >> > > populated with memory size, number of CPUs etc. based on [1]. > > > >> >> > > So, even if we provide some device tree here it must not be > used by U-boot at > > > >> >> > > the end of the day. Thus, it might be a reasonable solution > to provide an empty device > > > >> >> > > tree as you do, but put a comment that it is not used. > > > >> >> > > > > >> >> > So another example of why this series is taking things in the > wrong > > > >> >> > direction. > > > >> >> > > > >> >> Why? > > > >> > > > > >> > I only had that comment in mind: "there is none so deaf as he who > will not hear." > > > >> > > > >> Hey, stop the pile-on. It's not useful. > > > >> > > > >> I've guided U-Boot's use of devicetree for 10 years successfully. > The > > > >> current state is a mess and I just to straighten it out. > > > >> > > > > I admire your talent and knowledge. > > > > I know you are 99,99% of the time correct and spot on for your > comments in many meetings we were attending. > > > > When you questioned a number of points I made, I first tried to > understand what I got wrong because you said it. > > > > And you were right ;-) > > > > For this topic, I made every effort to come to your position, but > definitively can't. > > > > > > Thank you. I think this will come together in a few years when > > > devicetree is sorted out in U-Boot and Binman is more widely used. > > > > > > For this series, if and when it is applied, I predict: > > > - it will not cause any confusion > > > - it will aid development > > > - it will help with discoverability, pressuring people to explain how > > > to build for their systems > > > - it will be a good basis for future work (we have a long list) > > > - everyone will wonder what the fuss was about > > > > > > Here is the commit that introduced OF_PRIOR_STAGE. It attracted no > > > such push-back. > > > > > > commit 894c3ad27fa940beb7fdc07d01dcfe81c03d0481 > > > Author: Thomas Fitzsimmons > > > Date: Fri Jun 8 17:59:45 2018 -0400 > > > > > > board: arm: Add support for Broadcom BCM7445 > > > > > > Add support for loading U-Boot on the Broadcom 7445 SoC. This port > > > assumes Broadcom's BOLT bootloader is acting as the second stage > > > bootloader, and U-Boot is acting as the third stage bootloader, > loaded > > > as an ELF program by BOLT. > > > > > > Signed-off-by: Thomas Fitzsimmons > > > Cc: Stefan Roese > > > Cc: Tom Rini > > > Cc: Florian Fainelli > > > > I want to cycle back over here. Yes, historically a number of things > > came in that perhaps shouldn't have. I went with "well, this is what we > > need to handle this case I suppose" and applied it. > > Yes and we need to move things forward. We can't just object to things > without an alternative. As far as I can follow the threads, I proposed the dts to be empty to pass compilation and move forward, but I think you haven't replied. The empty dts can contain a comment pointing to documentation, which could describe the DT lifecycle of the platform, and a template dts that could be used for adventurous developers. > As I have mentioned before, I think, I did > actually review this (there was a question about sequence numbers or > something) and didn't even notice the devicetree thing! It should have > been a separate patch, I suppose. But even with the other patch > (OF_BOARD), I did not at the time understand the implications. I feel > very bad about the situation we are in and I wish I had thought it > through properly at the
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi, Simon! On 03.12.21 18:23, Simon Glass wrote: > Hi Oleksandr, > > On Thu, 2 Dec 2021 at 22:41, Oleksandr Andrushchenko > wrote: >> Hi, Simon! >> >> On 02.12.21 19:57, Simon Glass wrote: >>> Hi Oleksandr, >>> >>> On Thu, 2 Dec 2021 at 10:40, Oleksandr Andrushchenko >>> wrote: Hi, Simon! Sorry for being late to the party On 02.12.21 17:59, Simon Glass wrote: > Add an empty file to prevent build errors when building with > CONFIG_OF_SEPARATE enabled. > > The build instructions in U-Boot do not provide enough detail to build a > useful devicetree, unfortunately. Xen guest doesn't use any built-in device trees as the guest's device tree is provided by the Xen hypervisor itself and is generated at the virtual machine creation time: it is populated with memory size, number of CPUs etc. based on [1]. So, even if we provide some device tree here it must not be used by U-boot at the end of the day. Thus, it might be a reasonable solution to provide an empty device tree as you do, but put a comment that it is not used. >>> OK we can go with an empty one if we have to, but where are the >>> instructions to create the DT that is used? >> You don't need to create the device tree yourself, but instead it is >> provided by Xen and generated at run-time while creating a >> virtual machine. So, it is up to Xen to provide one. >> There are cases [1] when you may want providing a so called >> partial device tree to better tune what a virtual machine gets. >> But again, it is used by Xen toolstack outside of the virtual machine >> and serves as a sort of overlay to the generated device tree. >> So, we can provide some device tree to be embedded in U-boot, >> but it will have no practical meaning and will make more harm than good >>> I'm not even sure how to run U-Boot with Xen? The in-tree instructions >>> don't help... >> This is just a virtual machine from Xen POV, so U-boot is nothing >> different here from Linux kernel or anything else. >> Thus no specific instructions are needed nor provided > I'd like to try it out. How?? Well, it can be tricky a bit. There are number of ARM64 platforms which have Xen running: Arm, Renesas, Xilinx, iMX8, Rpi4... You can probably start from QEMU, for example OP-TEE has a way to build Xen + QEMU, please see [1]. The build has Xen in it and a virtual machine [2]. You will need to tweak [3] and put U-boot instead of the Linux kernel. I never tried that build myself, but I know it is used for OP-TEE tests for Xen. Hope this helps, Oleksandr > > Regards, > Simon [1] https://github.com/OP-TEE/manifest/blob/master/qemu_v8.xml [2] https://github.com/OP-TEE/build/tree/master/qemu_v8/xen [3] https://github.com/OP-TEE/build/blob/master/qemu_v8/xen/guest.cfg#L1
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi Oleksandr, On Thu, 2 Dec 2021 at 22:41, Oleksandr Andrushchenko wrote: > > Hi, Simon! > > On 02.12.21 19:57, Simon Glass wrote: > > Hi Oleksandr, > > > > On Thu, 2 Dec 2021 at 10:40, Oleksandr Andrushchenko > > wrote: > >> Hi, Simon! > >> > >> Sorry for being late to the party > >> > >> On 02.12.21 17:59, Simon Glass wrote: > >>> Add an empty file to prevent build errors when building with > >>> CONFIG_OF_SEPARATE enabled. > >>> > >>> The build instructions in U-Boot do not provide enough detail to build a > >>> useful devicetree, unfortunately. > >> Xen guest doesn't use any built-in device trees as the guest's device tree > >> is provided > >> by the Xen hypervisor itself and is generated at the virtual machine > >> creation time: it is > >> populated with memory size, number of CPUs etc. based on [1]. > >> So, even if we provide some device tree here it must not be used by U-boot > >> at > >> the end of the day. Thus, it might be a reasonable solution to provide an > >> empty device > >> tree as you do, but put a comment that it is not used. > > OK we can go with an empty one if we have to, but where are the > > instructions to create the DT that is used? > You don't need to create the device tree yourself, but instead it is > provided by Xen and generated at run-time while creating a > virtual machine. So, it is up to Xen to provide one. > There are cases [1] when you may want providing a so called > partial device tree to better tune what a virtual machine gets. > But again, it is used by Xen toolstack outside of the virtual machine > and serves as a sort of overlay to the generated device tree. > So, we can provide some device tree to be embedded in U-boot, > but it will have no practical meaning and will make more harm than good > > > > I'm not even sure how to run U-Boot with Xen? The in-tree instructions > > don't help... > This is just a virtual machine from Xen POV, so U-boot is nothing > different here from Linux kernel or anything else. > Thus no specific instructions are needed nor provided I'd like to try it out. How?? Regards, Simon
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi Tom, On Fri, 3 Dec 2021 at 05:14, Tom Rini wrote: > > On Thu, Dec 02, 2021 at 12:23:10PM -0700, Simon Glass wrote: > > Hi François, > > > > On Thu, 2 Dec 2021 at 11:44, François Ozog wrote: > > > > > > Hi Simon > > > > > > On Thu, 2 Dec 2021 at 19:29, Simon Glass wrote: > > >> > > >> Hi François, > > >> > > >> On Thu, 2 Dec 2021 at 11:17, François Ozog > > >> wrote: > > >> > > > >> > Hi Simon > > >> > > > >> > On Thu, 2 Dec 2021 at 19:05, Simon Glass wrote: > > >> >> > > >> >> Hi Tom, > > >> >> > > >> >> On Thu, 2 Dec 2021 at 10:56, Tom Rini wrote: > > >> >> > > > >> >> > On Thu, Dec 02, 2021 at 05:40:46PM +, Oleksandr Andrushchenko > > >> >> > wrote: > > >> >> > > Hi, Simon! > > >> >> > > > > >> >> > > Sorry for being late to the party > > >> >> > > > > >> >> > > On 02.12.21 17:59, Simon Glass wrote: > > >> >> > > > Add an empty file to prevent build errors when building with > > >> >> > > > CONFIG_OF_SEPARATE enabled. > > >> >> > > > > > >> >> > > > The build instructions in U-Boot do not provide enough detail > > >> >> > > > to build a > > >> >> > > > useful devicetree, unfortunately. > > >> >> > > Xen guest doesn't use any built-in device trees as the guest's > > >> >> > > device tree is provided > > >> >> > > by the Xen hypervisor itself and is generated at the virtual > > >> >> > > machine creation time: it is > > >> >> > > populated with memory size, number of CPUs etc. based on [1]. > > >> >> > > So, even if we provide some device tree here it must not be used > > >> >> > > by U-boot at > > >> >> > > the end of the day. Thus, it might be a reasonable solution to > > >> >> > > provide an empty device > > >> >> > > tree as you do, but put a comment that it is not used. > > >> >> > > > >> >> > So another example of why this series is taking things in the wrong > > >> >> > direction. > > >> >> > > >> >> Why? > > >> > > > >> > I only had that comment in mind: "there is none so deaf as he who will > > >> > not hear." > > >> > > >> Hey, stop the pile-on. It's not useful. > > >> > > >> I've guided U-Boot's use of devicetree for 10 years successfully. The > > >> current state is a mess and I just to straighten it out. > > >> > > > I admire your talent and knowledge. > > > I know you are 99,99% of the time correct and spot on for your comments > > > in many meetings we were attending. > > > When you questioned a number of points I made, I first tried to > > > understand what I got wrong because you said it. > > > And you were right ;-) > > > For this topic, I made every effort to come to your position, but > > > definitively can't. > > > > Thank you. I think this will come together in a few years when > > devicetree is sorted out in U-Boot and Binman is more widely used. > > > > For this series, if and when it is applied, I predict: > > - it will not cause any confusion > > - it will aid development > > - it will help with discoverability, pressuring people to explain how > > to build for their systems > > - it will be a good basis for future work (we have a long list) > > - everyone will wonder what the fuss was about > > > > Here is the commit that introduced OF_PRIOR_STAGE. It attracted no > > such push-back. > > > > commit 894c3ad27fa940beb7fdc07d01dcfe81c03d0481 > > Author: Thomas Fitzsimmons > > Date: Fri Jun 8 17:59:45 2018 -0400 > > > > board: arm: Add support for Broadcom BCM7445 > > > > Add support for loading U-Boot on the Broadcom 7445 SoC. This port > > assumes Broadcom's BOLT bootloader is acting as the second stage > > bootloader, and U-Boot is acting as the third stage bootloader, loaded > > as an ELF program by BOLT. > > > > Signed-off-by: Thomas Fitzsimmons > > Cc: Stefan Roese > > Cc: Tom Rini > > Cc: Florian Fainelli > > I want to cycle back over here. Yes, historically a number of things > came in that perhaps shouldn't have. I went with "well, this is what we > need to handle this case I suppose" and applied it. Yes and we need to move things forward. We can't just object to things without an alternative. As I have mentioned before, I think, I did actually review this (there was a question about sequence numbers or something) and didn't even notice the devicetree thing! It should have been a separate patch, I suppose. But even with the other patch (OF_BOARD), I did not at the time understand the implications. I feel very bad about the situation we are in and I wish I had thought it through properly at the time. Mea culpa. Regards, Simon
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
On Thu, Dec 02, 2021 at 12:23:10PM -0700, Simon Glass wrote: > Hi François, > > On Thu, 2 Dec 2021 at 11:44, François Ozog wrote: > > > > Hi Simon > > > > On Thu, 2 Dec 2021 at 19:29, Simon Glass wrote: > >> > >> Hi François, > >> > >> On Thu, 2 Dec 2021 at 11:17, François Ozog > >> wrote: > >> > > >> > Hi Simon > >> > > >> > On Thu, 2 Dec 2021 at 19:05, Simon Glass wrote: > >> >> > >> >> Hi Tom, > >> >> > >> >> On Thu, 2 Dec 2021 at 10:56, Tom Rini wrote: > >> >> > > >> >> > On Thu, Dec 02, 2021 at 05:40:46PM +, Oleksandr Andrushchenko > >> >> > wrote: > >> >> > > Hi, Simon! > >> >> > > > >> >> > > Sorry for being late to the party > >> >> > > > >> >> > > On 02.12.21 17:59, Simon Glass wrote: > >> >> > > > Add an empty file to prevent build errors when building with > >> >> > > > CONFIG_OF_SEPARATE enabled. > >> >> > > > > >> >> > > > The build instructions in U-Boot do not provide enough detail to > >> >> > > > build a > >> >> > > > useful devicetree, unfortunately. > >> >> > > Xen guest doesn't use any built-in device trees as the guest's > >> >> > > device tree is provided > >> >> > > by the Xen hypervisor itself and is generated at the virtual > >> >> > > machine creation time: it is > >> >> > > populated with memory size, number of CPUs etc. based on [1]. > >> >> > > So, even if we provide some device tree here it must not be used by > >> >> > > U-boot at > >> >> > > the end of the day. Thus, it might be a reasonable solution to > >> >> > > provide an empty device > >> >> > > tree as you do, but put a comment that it is not used. > >> >> > > >> >> > So another example of why this series is taking things in the wrong > >> >> > direction. > >> >> > >> >> Why? > >> > > >> > I only had that comment in mind: "there is none so deaf as he who will > >> > not hear." > >> > >> Hey, stop the pile-on. It's not useful. > >> > >> I've guided U-Boot's use of devicetree for 10 years successfully. The > >> current state is a mess and I just to straighten it out. > >> > > I admire your talent and knowledge. > > I know you are 99,99% of the time correct and spot on for your comments in > > many meetings we were attending. > > When you questioned a number of points I made, I first tried to understand > > what I got wrong because you said it. > > And you were right ;-) > > For this topic, I made every effort to come to your position, but > > definitively can't. > > Thank you. I think this will come together in a few years when > devicetree is sorted out in U-Boot and Binman is more widely used. > > For this series, if and when it is applied, I predict: > - it will not cause any confusion > - it will aid development > - it will help with discoverability, pressuring people to explain how > to build for their systems > - it will be a good basis for future work (we have a long list) > - everyone will wonder what the fuss was about > > Here is the commit that introduced OF_PRIOR_STAGE. It attracted no > such push-back. > > commit 894c3ad27fa940beb7fdc07d01dcfe81c03d0481 > Author: Thomas Fitzsimmons > Date: Fri Jun 8 17:59:45 2018 -0400 > > board: arm: Add support for Broadcom BCM7445 > > Add support for loading U-Boot on the Broadcom 7445 SoC. This port > assumes Broadcom's BOLT bootloader is acting as the second stage > bootloader, and U-Boot is acting as the third stage bootloader, loaded > as an ELF program by BOLT. > > Signed-off-by: Thomas Fitzsimmons > Cc: Stefan Roese > Cc: Tom Rini > Cc: Florian Fainelli I want to cycle back over here. Yes, historically a number of things came in that perhaps shouldn't have. I went with "well, this is what we need to handle this case I suppose" and applied it. -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi, Simon! On 02.12.21 19:57, Simon Glass wrote: > Hi Oleksandr, > > On Thu, 2 Dec 2021 at 10:40, Oleksandr Andrushchenko > wrote: >> Hi, Simon! >> >> Sorry for being late to the party >> >> On 02.12.21 17:59, Simon Glass wrote: >>> Add an empty file to prevent build errors when building with >>> CONFIG_OF_SEPARATE enabled. >>> >>> The build instructions in U-Boot do not provide enough detail to build a >>> useful devicetree, unfortunately. >> Xen guest doesn't use any built-in device trees as the guest's device tree >> is provided >> by the Xen hypervisor itself and is generated at the virtual machine >> creation time: it is >> populated with memory size, number of CPUs etc. based on [1]. >> So, even if we provide some device tree here it must not be used by U-boot at >> the end of the day. Thus, it might be a reasonable solution to provide an >> empty device >> tree as you do, but put a comment that it is not used. > OK we can go with an empty one if we have to, but where are the > instructions to create the DT that is used? You don't need to create the device tree yourself, but instead it is provided by Xen and generated at run-time while creating a virtual machine. So, it is up to Xen to provide one. There are cases [1] when you may want providing a so called partial device tree to better tune what a virtual machine gets. But again, it is used by Xen toolstack outside of the virtual machine and serves as a sort of overlay to the generated device tree. So, we can provide some device tree to be embedded in U-boot, but it will have no practical meaning and will make more harm than good > > I'm not even sure how to run U-Boot with Xen? The in-tree instructions > don't help... This is just a virtual machine from Xen POV, so U-boot is nothing different here from Linux kernel or anything else. Thus no specific instructions are needed nor provided Thank you, Oleksandr > > Regards, > Simon [1] https://xenbits.xen.org/docs/unstable/misc/arm/passthrough.txt
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi François, On Thu, 2 Dec 2021 at 11:44, François Ozog wrote: > > Hi Simon > > On Thu, 2 Dec 2021 at 19:29, Simon Glass wrote: >> >> Hi François, >> >> On Thu, 2 Dec 2021 at 11:17, François Ozog wrote: >> > >> > Hi Simon >> > >> > On Thu, 2 Dec 2021 at 19:05, Simon Glass wrote: >> >> >> >> Hi Tom, >> >> >> >> On Thu, 2 Dec 2021 at 10:56, Tom Rini wrote: >> >> > >> >> > On Thu, Dec 02, 2021 at 05:40:46PM +, Oleksandr Andrushchenko wrote: >> >> > > Hi, Simon! >> >> > > >> >> > > Sorry for being late to the party >> >> > > >> >> > > On 02.12.21 17:59, Simon Glass wrote: >> >> > > > Add an empty file to prevent build errors when building with >> >> > > > CONFIG_OF_SEPARATE enabled. >> >> > > > >> >> > > > The build instructions in U-Boot do not provide enough detail to >> >> > > > build a >> >> > > > useful devicetree, unfortunately. >> >> > > Xen guest doesn't use any built-in device trees as the guest's device >> >> > > tree is provided >> >> > > by the Xen hypervisor itself and is generated at the virtual machine >> >> > > creation time: it is >> >> > > populated with memory size, number of CPUs etc. based on [1]. >> >> > > So, even if we provide some device tree here it must not be used by >> >> > > U-boot at >> >> > > the end of the day. Thus, it might be a reasonable solution to >> >> > > provide an empty device >> >> > > tree as you do, but put a comment that it is not used. >> >> > >> >> > So another example of why this series is taking things in the wrong >> >> > direction. >> >> >> >> Why? >> > >> > I only had that comment in mind: "there is none so deaf as he who will not >> > hear." >> >> Hey, stop the pile-on. It's not useful. >> >> I've guided U-Boot's use of devicetree for 10 years successfully. The >> current state is a mess and I just to straighten it out. >> > I admire your talent and knowledge. > I know you are 99,99% of the time correct and spot on for your comments in > many meetings we were attending. > When you questioned a number of points I made, I first tried to understand > what I got wrong because you said it. > And you were right ;-) > For this topic, I made every effort to come to your position, but > definitively can't. Thank you. I think this will come together in a few years when devicetree is sorted out in U-Boot and Binman is more widely used. For this series, if and when it is applied, I predict: - it will not cause any confusion - it will aid development - it will help with discoverability, pressuring people to explain how to build for their systems - it will be a good basis for future work (we have a long list) - everyone will wonder what the fuss was about Here is the commit that introduced OF_PRIOR_STAGE. It attracted no such push-back. commit 894c3ad27fa940beb7fdc07d01dcfe81c03d0481 Author: Thomas Fitzsimmons Date: Fri Jun 8 17:59:45 2018 -0400 board: arm: Add support for Broadcom BCM7445 Add support for loading U-Boot on the Broadcom 7445 SoC. This port assumes Broadcom's BOLT bootloader is acting as the second stage bootloader, and U-Boot is acting as the third stage bootloader, loaded as an ELF program by BOLT. Signed-off-by: Thomas Fitzsimmons Cc: Stefan Roese Cc: Tom Rini Cc: Florian Fainelli Regards, Simon
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi Simon On Thu, 2 Dec 2021 at 19:29, Simon Glass wrote: > Hi François, > > On Thu, 2 Dec 2021 at 11:17, François Ozog > wrote: > > > > Hi Simon > > > > On Thu, 2 Dec 2021 at 19:05, Simon Glass wrote: > >> > >> Hi Tom, > >> > >> On Thu, 2 Dec 2021 at 10:56, Tom Rini wrote: > >> > > >> > On Thu, Dec 02, 2021 at 05:40:46PM +, Oleksandr Andrushchenko > wrote: > >> > > Hi, Simon! > >> > > > >> > > Sorry for being late to the party > >> > > > >> > > On 02.12.21 17:59, Simon Glass wrote: > >> > > > Add an empty file to prevent build errors when building with > >> > > > CONFIG_OF_SEPARATE enabled. > >> > > > > >> > > > The build instructions in U-Boot do not provide enough detail to > build a > >> > > > useful devicetree, unfortunately. > >> > > Xen guest doesn't use any built-in device trees as the guest's > device tree is provided > >> > > by the Xen hypervisor itself and is generated at the virtual > machine creation time: it is > >> > > populated with memory size, number of CPUs etc. based on [1]. > >> > > So, even if we provide some device tree here it must not be used by > U-boot at > >> > > the end of the day. Thus, it might be a reasonable solution to > provide an empty device > >> > > tree as you do, but put a comment that it is not used. > >> > > >> > So another example of why this series is taking things in the wrong > >> > direction. > >> > >> Why? > > > > I only had that comment in mind: "there is none so deaf as he who will > not hear." > > Hey, stop the pile-on. It's not useful. > > I've guided U-Boot's use of devicetree for 10 years successfully. The > current state is a mess and I just to straighten it out. > > I admire your talent and knowledge. I know you are 99,99% of the time correct and spot on for your comments in many meetings we were attending. When you questioned a number of points I made, I first tried to understand what I got wrong because you said it. And you were right ;-) For this topic, I made every effort to come to your position, but definitively can't. >> > >> At least we might figure out where to get the DT and how to run > >> Xen with U-Boot. I don't see any down-side to having a basic DT in the > >> tree along with instructions on how to run Xen. > > > > If an EMPTY device is what is required to pass current build > constraints, so be it, and let's correct that in a later patch. And EMPTY > is not basic. > > The problem here is a difference in philosophy around device tree. > > Indeed! > Regards, > Simon > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi François, On Thu, 2 Dec 2021 at 11:17, François Ozog wrote: > > Hi Simon > > On Thu, 2 Dec 2021 at 19:05, Simon Glass wrote: >> >> Hi Tom, >> >> On Thu, 2 Dec 2021 at 10:56, Tom Rini wrote: >> > >> > On Thu, Dec 02, 2021 at 05:40:46PM +, Oleksandr Andrushchenko wrote: >> > > Hi, Simon! >> > > >> > > Sorry for being late to the party >> > > >> > > On 02.12.21 17:59, Simon Glass wrote: >> > > > Add an empty file to prevent build errors when building with >> > > > CONFIG_OF_SEPARATE enabled. >> > > > >> > > > The build instructions in U-Boot do not provide enough detail to build >> > > > a >> > > > useful devicetree, unfortunately. >> > > Xen guest doesn't use any built-in device trees as the guest's device >> > > tree is provided >> > > by the Xen hypervisor itself and is generated at the virtual machine >> > > creation time: it is >> > > populated with memory size, number of CPUs etc. based on [1]. >> > > So, even if we provide some device tree here it must not be used by >> > > U-boot at >> > > the end of the day. Thus, it might be a reasonable solution to provide >> > > an empty device >> > > tree as you do, but put a comment that it is not used. >> > >> > So another example of why this series is taking things in the wrong >> > direction. >> >> Why? > > I only had that comment in mind: "there is none so deaf as he who will not > hear." Hey, stop the pile-on. It's not useful. I've guided U-Boot's use of devicetree for 10 years successfully. The current state is a mess and I just to straighten it out. >> >> At least we might figure out where to get the DT and how to run >> Xen with U-Boot. I don't see any down-side to having a basic DT in the >> tree along with instructions on how to run Xen. > > If an EMPTY device is what is required to pass current build constraints, so > be it, and let's correct that in a later patch. And EMPTY is not basic. The problem here is a difference in philosophy around device tree. Regards, Simon
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi Simon On Thu, 2 Dec 2021 at 19:05, Simon Glass wrote: > Hi Tom, > > On Thu, 2 Dec 2021 at 10:56, Tom Rini wrote: > > > > On Thu, Dec 02, 2021 at 05:40:46PM +, Oleksandr Andrushchenko wrote: > > > Hi, Simon! > > > > > > Sorry for being late to the party > > > > > > On 02.12.21 17:59, Simon Glass wrote: > > > > Add an empty file to prevent build errors when building with > > > > CONFIG_OF_SEPARATE enabled. > > > > > > > > The build instructions in U-Boot do not provide enough detail to > build a > > > > useful devicetree, unfortunately. > > > Xen guest doesn't use any built-in device trees as the guest's device > tree is provided > > > by the Xen hypervisor itself and is generated at the virtual machine > creation time: it is > > > populated with memory size, number of CPUs etc. based on [1]. > > > So, even if we provide some device tree here it must not be used by > U-boot at > > > the end of the day. Thus, it might be a reasonable solution to provide > an empty device > > > tree as you do, but put a comment that it is not used. > > > > So another example of why this series is taking things in the wrong > > direction. > > Why? I only had that comment in mind: "there is none so deaf as he who will not hear." > At least we might figure out where to get the DT and how to run > Xen with U-Boot. I don't see any down-side to having a basic DT in the > tree along with instructions on how to run Xen. > If an EMPTY device is what is required to pass current build constraints, so be it, and let's correct that in a later patch. And EMPTY is not basic. > Regards, > Simon > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
On Thu, Dec 02, 2021 at 11:05:16AM -0700, Simon Glass wrote: > Hi Tom, > > On Thu, 2 Dec 2021 at 10:56, Tom Rini wrote: > > > > On Thu, Dec 02, 2021 at 05:40:46PM +, Oleksandr Andrushchenko wrote: > > > Hi, Simon! > > > > > > Sorry for being late to the party > > > > > > On 02.12.21 17:59, Simon Glass wrote: > > > > Add an empty file to prevent build errors when building with > > > > CONFIG_OF_SEPARATE enabled. > > > > > > > > The build instructions in U-Boot do not provide enough detail to build a > > > > useful devicetree, unfortunately. > > > Xen guest doesn't use any built-in device trees as the guest's device > > > tree is provided > > > by the Xen hypervisor itself and is generated at the virtual machine > > > creation time: it is > > > populated with memory size, number of CPUs etc. based on [1]. > > > So, even if we provide some device tree here it must not be used by > > > U-boot at > > > the end of the day. Thus, it might be a reasonable solution to provide an > > > empty device > > > tree as you do, but put a comment that it is not used. > > > > So another example of why this series is taking things in the wrong > > direction. > > Why? At least we might figure out where to get the DT and how to run > Xen with U-Boot. I don't see any down-side to having a basic DT in the > tree along with instructions on how to run Xen. I agree with everything except "a basic DT in the tree". It's not used. If you're going to do something with it, the instructions on where the DT comes from will get you there. If the instructions are something like "Well, it's actually horribly complex and depends on what you're doing Xen on and ...", then that's even more of an argument for not having "a basic DT" that will be misleading as well. -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi Tom, On Thu, 2 Dec 2021 at 10:56, Tom Rini wrote: > > On Thu, Dec 02, 2021 at 05:40:46PM +, Oleksandr Andrushchenko wrote: > > Hi, Simon! > > > > Sorry for being late to the party > > > > On 02.12.21 17:59, Simon Glass wrote: > > > Add an empty file to prevent build errors when building with > > > CONFIG_OF_SEPARATE enabled. > > > > > > The build instructions in U-Boot do not provide enough detail to build a > > > useful devicetree, unfortunately. > > Xen guest doesn't use any built-in device trees as the guest's device tree > > is provided > > by the Xen hypervisor itself and is generated at the virtual machine > > creation time: it is > > populated with memory size, number of CPUs etc. based on [1]. > > So, even if we provide some device tree here it must not be used by U-boot > > at > > the end of the day. Thus, it might be a reasonable solution to provide an > > empty device > > tree as you do, but put a comment that it is not used. > > So another example of why this series is taking things in the wrong > direction. Why? At least we might figure out where to get the DT and how to run Xen with U-Boot. I don't see any down-side to having a basic DT in the tree along with instructions on how to run Xen. Regards, Simon
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi Oleksandr, On Thu, 2 Dec 2021 at 10:40, Oleksandr Andrushchenko wrote: > > Hi, Simon! > > Sorry for being late to the party > > On 02.12.21 17:59, Simon Glass wrote: > > Add an empty file to prevent build errors when building with > > CONFIG_OF_SEPARATE enabled. > > > > The build instructions in U-Boot do not provide enough detail to build a > > useful devicetree, unfortunately. > Xen guest doesn't use any built-in device trees as the guest's device tree is > provided > by the Xen hypervisor itself and is generated at the virtual machine creation > time: it is > populated with memory size, number of CPUs etc. based on [1]. > So, even if we provide some device tree here it must not be used by U-boot at > the end of the day. Thus, it might be a reasonable solution to provide an > empty device > tree as you do, but put a comment that it is not used. OK we can go with an empty one if we have to, but where are the instructions to create the DT that is used? I'm not even sure how to run U-Boot with Xen? The in-tree instructions don't help... Regards, Simon
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
On Thu, Dec 02, 2021 at 05:40:46PM +, Oleksandr Andrushchenko wrote: > Hi, Simon! > > Sorry for being late to the party > > On 02.12.21 17:59, Simon Glass wrote: > > Add an empty file to prevent build errors when building with > > CONFIG_OF_SEPARATE enabled. > > > > The build instructions in U-Boot do not provide enough detail to build a > > useful devicetree, unfortunately. > Xen guest doesn't use any built-in device trees as the guest's device tree is > provided > by the Xen hypervisor itself and is generated at the virtual machine creation > time: it is > populated with memory size, number of CPUs etc. based on [1]. > So, even if we provide some device tree here it must not be used by U-boot at > the end of the day. Thus, it might be a reasonable solution to provide an > empty device > tree as you do, but put a comment that it is not used. So another example of why this series is taking things in the wrong direction. -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi, Simon!
Sorry for being late to the party
On 02.12.21 17:59, Simon Glass wrote:
> Add an empty file to prevent build errors when building with
> CONFIG_OF_SEPARATE enabled.
>
> The build instructions in U-Boot do not provide enough detail to build a
> useful devicetree, unfortunately.
Xen guest doesn't use any built-in device trees as the guest's device tree is
provided
by the Xen hypervisor itself and is generated at the virtual machine creation
time: it is
populated with memory size, number of CPUs etc. based on [1].
So, even if we provide some device tree here it must not be used by U-boot at
the end of the day. Thus, it might be a reasonable solution to provide an empty
device
tree as you do, but put a comment that it is not used.
Thank you,
Oleksandr
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v1)
>
> arch/arm/dts/Makefile| 2 ++
> arch/arm/dts/xenguest-arm64.dts | 15 +++
> configs/xenguest_arm64_defconfig | 2 +-
> 3 files changed, 18 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/dts/xenguest-arm64.dts
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index d53bae2c350..f6345988c8c 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1140,6 +1140,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
> mt8516-pumpkin.dtb \
> mt8518-ap1-emmc.dtb
>
> +dtb-$(CONFIG_XEN) += xenguest-arm64.dtb
> +
> dtb-$(CONFIG_TARGET_GE_BX50V3) += \
> imx6q-bx50v3.dtb \
> imx6q-b850v3.dtb \
> diff --git a/arch/arm/dts/xenguest-arm64.dts b/arch/arm/dts/xenguest-arm64.dts
> new file mode 100644
> index 000..52d3b062248
> --- /dev/null
> +++ b/arch/arm/dts/xenguest-arm64.dts
> @@ -0,0 +1,15 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Dummy devicetre file for xenguest_arm64
> + *
> + * This is required to make the board build with CONFIG OF_SEPARATE
> + * Build instructions at xenguest_arm64.rst are inadequate for obtaining a
> real
> + * devicetree.
> + *
> + * Copyright 2021 Google LLC
> + */
> +
> +/dts-v1/;
> +
> +/ {
> +};
> diff --git a/configs/xenguest_arm64_defconfig
> b/configs/xenguest_arm64_defconfig
> index 8d9d9133a2e..edce34346d3 100644
> --- a/configs/xenguest_arm64_defconfig
> +++ b/configs/xenguest_arm64_defconfig
> @@ -3,7 +3,7 @@ CONFIG_POSITION_INDEPENDENT=y
> CONFIG_TARGET_XENGUEST_ARM64=y
> CONFIG_SYS_TEXT_BASE=0x4008
> CONFIG_SYS_MALLOC_LEN=0x200
> -CONFIG_SYS_MALLOC_F_LEN=0x2000
> +CONFIG_DEFAULT_DEVICE_TREE="xenguest-arm64"
> CONFIG_IDENT_STRING=" xenguest"
> CONFIG_SYS_LOAD_ADDR=0x4000
> CONFIG_BOOTDELAY=10
[1] https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html
[PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Add an empty file to prevent build errors when building with
CONFIG_OF_SEPARATE enabled.
The build instructions in U-Boot do not provide enough detail to build a
useful devicetree, unfortunately.
Signed-off-by: Simon Glass
---
(no changes since v1)
arch/arm/dts/Makefile| 2 ++
arch/arm/dts/xenguest-arm64.dts | 15 +++
configs/xenguest_arm64_defconfig | 2 +-
3 files changed, 18 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/xenguest-arm64.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index d53bae2c350..f6345988c8c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1140,6 +1140,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
mt8516-pumpkin.dtb \
mt8518-ap1-emmc.dtb
+dtb-$(CONFIG_XEN) += xenguest-arm64.dtb
+
dtb-$(CONFIG_TARGET_GE_BX50V3) += \
imx6q-bx50v3.dtb \
imx6q-b850v3.dtb \
diff --git a/arch/arm/dts/xenguest-arm64.dts b/arch/arm/dts/xenguest-arm64.dts
new file mode 100644
index 000..52d3b062248
--- /dev/null
+++ b/arch/arm/dts/xenguest-arm64.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Dummy devicetre file for xenguest_arm64
+ *
+ * This is required to make the board build with CONFIG OF_SEPARATE
+ * Build instructions at xenguest_arm64.rst are inadequate for obtaining a real
+ * devicetree.
+ *
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/ {
+};
diff --git a/configs/xenguest_arm64_defconfig b/configs/xenguest_arm64_defconfig
index 8d9d9133a2e..edce34346d3 100644
--- a/configs/xenguest_arm64_defconfig
+++ b/configs/xenguest_arm64_defconfig
@@ -3,7 +3,7 @@ CONFIG_POSITION_INDEPENDENT=y
CONFIG_TARGET_XENGUEST_ARM64=y
CONFIG_SYS_TEXT_BASE=0x4008
CONFIG_SYS_MALLOC_LEN=0x200
-CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_DEFAULT_DEVICE_TREE="xenguest-arm64"
CONFIG_IDENT_STRING=" xenguest"
CONFIG_SYS_LOAD_ADDR=0x4000
CONFIG_BOOTDELAY=10
--
2.34.0.rc2.393.gf8c9666880-goog
