Tom, thanks, I appreciate all of your hard work, the code base looks good.. David
On Thu, 26 Jul 2018 at 16:11 Tom Rini trini@konsulko.com wrote:
On Thu, Jul 26, 2018 at 01:55:51PM +0100, Peter Robinson wrote:
On Thu, Jul 26, 2018 at 1:46 PM, David Rusling david.rusling@linaro.org
wrote:
Peter, thanks, that was one explanation that I hadn't thought of (32b = 32 bits). Really helpful, onwards and upwards...
FYI they work fine 32 and 64 bits on both the 3B and 3B+ for me, only currently tested 64 bit with uefi but they work fine for me, plus a bunch of other 96boards.
A Pi 3B is also in my CI loop (32bit then 64bit) so our (U-Boot's) test.py bits run on it reliably or I start yelling at people :)
-- Tom
Success. I now have a u-boot built on Arm64 that works. Along the way I learnt various things:
[1] Raspberry Pi's first stage loader generates the device tree. Overlays are used to turn various things on (for example sound) at boot time.
[2] There's a big difference between fdt_addr and fdt_addr_r, depending on whether you're running mainstream u-boot or rpi u-boot.
[3] RPI3 is not really fully upstream, various bits always need to be added. In other words, RPi, like a lot of Arm boards has its own mediated kernel tree, u-boot tree etc
[4] There's not yet a standard 64 bit aarch64 release of Debian buster (9). That's terrible progress. I managed to build my own but not without a lot of faffing about.
[5] Yocto / OE does not build natively arm on arm (as well as taking a very long time on a RPi 3)
I should take my notes and write this 'folklore' up, but it is a mess compared to pretty much any Intel board. The shame is that the Raspberry Pi is probably the best supported aarch64 device that there is...
David
On Thu, 26 Jul 2018 at 17:56 David Rusling david.rusling@linaro.org wrote:
Tom, thanks, I appreciate all of your hard work, the code base looks good.. David
On Thu, 26 Jul 2018 at 16:11 Tom Rini trini@konsulko.com wrote:
On Thu, Jul 26, 2018 at 01:55:51PM +0100, Peter Robinson wrote:
On Thu, Jul 26, 2018 at 1:46 PM, David Rusling <
david.rusling@linaro.org> wrote:
Peter, thanks, that was one explanation that I hadn't thought of (32b = 32 bits). Really helpful, onwards and upwards...
FYI they work fine 32 and 64 bits on both the 3B and 3B+ for me, only currently tested 64 bit with uefi but they work fine for me, plus a bunch of other 96boards.
A Pi 3B is also in my CI loop (32bit then 64bit) so our (U-Boot's) test.py bits run on it reliably or I start yelling at people :)
-- Tom
-- David A Rusling CTO, Linaro https://linaro.org
On 07/30/2018 02:16 PM, David Rusling wrote:
Success. I now have a u-boot built on Arm64 that works. Along the way I learnt various things:
[1] Raspberry Pi's first stage loader generates the device tree. Overlays are used to turn various things on (for example sound) at boot time.
Yes. In order for those to propagate into U-Boot you will want to enable CONFIG_OF_BOARD. That way the first stage generated DT gets consumed by U-Boot as well. This allows you to run on CM3 or have the same U-Boot binary for B and B+ for example.
[2] There's a big difference between fdt_addr and fdt_addr_r, depending on whether you're running mainstream u-boot or rpi u-boot.
What should "mainstream" U-Boot refer to here? "fdt_addr" is the U-Boot internal variable that it stores the location of the device tree to that was passed into it from a previous stage. "fdt_addr_r" is what the distro boot framework passes into whatever you load from within U-Boot.
There's also another one: "fdtcontroladdr". That's the one that U-Boot consumes itself.
[3] RPI3 is not really fully upstream, various bits always need to be added. In other words, RPi, like a lot of Arm boards has its own mediated kernel tree, u-boot tree etc
That's not really true. We have a lot of happy customers running SLES (and openSUSE) off a fully upstream U-Boot + Linux kernel stack. It only gets hairy when you want to use things like the camera interface. Also from my experience the vc4 driver is very unstable.
Alex
On 07/30/2018 02:39 PM, Alexander Graf wrote:
On 07/30/2018 02:16 PM, David Rusling wrote:
Success. I now have a u-boot built on Arm64 that works. Along the way I learnt various things:
[1] Raspberry Pi's first stage loader generates the device tree. Overlays are used to turn various things on (for example sound) at boot time.
Yes. In order for those to propagate into U-Boot you will want to enable CONFIG_OF_BOARD. That way the first stage generated DT gets consumed by U-Boot as well. This allows you to run on CM3 or have the same U-Boot binary for B and B+ for example.
I forgot to mention that for this to work fully with propagation of that same device tree to an upstream kernel, you will also want to add the "upstream" overlay. Just add a line saying "dtoverlay=upstream" to config.txt. Then plug in any installer or image that is UEFI enabled (and works with DT) and it should boot.
Alex
Tom
On Mon, 30 Jul 2018 at 15:10 Alexander Graf agraf@suse.de wrote:
On 07/30/2018 02:39 PM, Alexander Graf wrote:
On 07/30/2018 02:16 PM, David Rusling wrote:
Success. I now have a u-boot built on Arm64 that works. Along the way I learnt various things:
[1] Raspberry Pi's first stage loader generates the device tree. Overlays are used to turn various things on (for example sound) at boot time.
Yes. In order for those to propagate into U-Boot you will want to enable CONFIG_OF_BOARD. That way the first stage generated DT gets consumed by U-Boot as well. This allows you to run on CM3 or have the same U-Boot binary for B and B+ for example.
Thanks for the tip, I'll play
I forgot to mention that for this to work fully with propagation of that same device tree to an upstream kernel, you will also want to add the "upstream" overlay. Just add a line saying "dtoverlay=upstream" to config.txt. Then plug in any installer or image that is UEFI enabled (and works with DT) and it should boot.
Alex
OK, that was going to be my next step, thanks
David
On Mon, Jul 30, 2018 at 8:11 AM Alexander Graf agraf@suse.de wrote:
On 07/30/2018 02:39 PM, Alexander Graf wrote:
On 07/30/2018 02:16 PM, David Rusling wrote:
Success. I now have a u-boot built on Arm64 that works. Along the way I learnt various things:
[1] Raspberry Pi's first stage loader generates the device tree. Overlays are used to turn various things on (for example sound) at boot time.
Yes. In order for those to propagate into U-Boot you will want to enable CONFIG_OF_BOARD. That way the first stage generated DT gets consumed by U-Boot as well. This allows you to run on CM3 or have the same U-Boot binary for B and B+ for example.
I forgot to mention that for this to work fully with propagation of that same device tree to an upstream kernel, you will also want to add the "upstream" overlay. Just add a line saying "dtoverlay=upstream" to config.txt. Then plug in any installer or image that is UEFI enabled (and works with DT) and it should boot.
Yuck. That's a fix-up applied to the RPi downstream dtb, right? I always just load my own (upstream) dtb. Who is providing the upstream overlay, and how do you do dtb updates in this case as what is upstream evolves? I'm just concerned this is very much RPi specific and how can EBBR define managing dtb updates/storage in a consistent way.
Rob
On 07/30/2018 06:02 PM, Rob Herring wrote:
On Mon, Jul 30, 2018 at 8:11 AM Alexander Graf agraf@suse.de wrote:
On 07/30/2018 02:39 PM, Alexander Graf wrote:
On 07/30/2018 02:16 PM, David Rusling wrote:
Success. I now have a u-boot built on Arm64 that works. Along the way I learnt various things:
[1] Raspberry Pi's first stage loader generates the device tree. Overlays are used to turn various things on (for example sound) at boot time.
Yes. In order for those to propagate into U-Boot you will want to enable CONFIG_OF_BOARD. That way the first stage generated DT gets consumed by U-Boot as well. This allows you to run on CM3 or have the same U-Boot binary for B and B+ for example.
I forgot to mention that for this to work fully with propagation of that same device tree to an upstream kernel, you will also want to add the "upstream" overlay. Just add a line saying "dtoverlay=upstream" to config.txt. Then plug in any installer or image that is UEFI enabled (and works with DT) and it should boot.
Yuck. That's a fix-up applied to the RPi downstream dtb, right? I always just load my own (upstream) dtb. Who is providing the upstream overlay, and how do you do dtb updates in this case as what is upstream evolves? I'm just concerned this is very much RPi specific and how can EBBR define managing dtb updates/storage in a consistent way.
The downstream DT is actually derived from the upstream one. The upstream overlay is officially maintained in the downstream repo to bring compatibility back into upstream shape, without losing additional references that the downstream DT adds (that don't hurt upstream compatibility).
The main reason why I pushed for that model is that this way we can reuse the raspberry pi specific overlay mechanism and propagate a *single* device tree all the way from early boot to Linux.
EBBR itself isn't concerned with how the device tree gets into Linux, as long as firmware provides it one way or another and allows for updates. Whether firmware consumes it from yet another layer or not IMHO is out of scope of EBBR.
Alex
On Mon, 30 Jul 2018 at 17:24 Alexander Graf agraf@suse.de wrote:
EBBR itself isn't concerned with how the device tree gets into Linux, as long as firmware provides it one way or another and allows for updates. Whether firmware consumes it from yet another layer or not IMHO is out of scope of EBBR.
...and into u-boot on it's way to the Linux kernel. u-boot is there to supply EFI callbacks and environment variables.
David
Alex
--
David A Rusling CTO, Linaro https://linaro.org
On Mon, Jul 30, 2018 at 01:16:08PM +0100, David Rusling wrote:
[4] There's not yet a standard 64 bit aarch64 release of Debian buster (9). That's terrible progress. I managed to build my own but not without a lot of faffing about.
Is the real problem:
a) That there is no AArch64 Debian buster rootfs image.
b) That the existing AArch64 Debian buster *installer* images doesn't boot out of the box.
Personally my own answer has always been b) and, to be honest, that's what got me interested in EBBR in the first place. EBBR (admitedly coupled with upstreamed hardware enablement for both bootloader and kernel) gets us much closer to that.
[5] Yocto / OE does not build natively arm on arm (as well as taking a very long time on a RPi 3)
Is this the "how to bootstrap go without using the host go compiler" problem or something else?
I should take my notes and write this 'folklore' up, but it is a mess compared to pretty much any Intel board. The shame is that the Raspberry Pi is probably the best supported aarch64 device that there is...
Must... resist... commenting...
Daniel.
Daniel
On Mon, 30 Jul 2018 at 14:06 Daniel Thompson daniel.thompson@linaro.org wrote:
On Mon, Jul 30, 2018 at 01:16:08PM +0100, David Rusling wrote:
[4] There's not yet a standard 64 bit aarch64 release of Debian buster (9). That's terrible progress. I managed to build my own but not without a lot of faffing about.
Is the real problem:
a) That there is no AArch64 Debian buster rootfs image.
b) That the existing AArch64 Debian buster *installer* images doesn't boot out of the box.
Personally my own answer has always been b) and, to be honest, that's what got me interested in EBBR in the first place. EBBR (admitedly coupled with upstreamed hardware enablement for both bootloader and kernel) gets us much closer to that.
I could only find a buster image via h https://wiki.debian.org/RaspberryPi3ttps://wiki.debian.org/RaspberryPi3 and that didn't work out of the box for RPi 3b+. I'll chat with Steve et al and see what's missing / happening.
[5] Yocto / OE does not build natively arm on arm (as well as taking a
very
long time on a RPi 3)
Is this the "how to bootstrap go without using the host go compiler" problem or something else?
The problem appears to be not cross building as I see 'internal' issues. I'll build on x86 and see where the differences are, but I suspect that this is an arm-on-arm problem.
I should take my notes and write this 'folklore' up, but it is a mess compared to pretty much any Intel board. The shame is that the Raspberry Pi is probably the best supported aarch64 device that there is...
Must... resist... commenting...
Well done
David
Daniel.
--
David A Rusling CTO, Linaro https://linaro.org
Steve (hi), I'm following https://wiki.debian.org/RaspberryPi3, but support for RPi 3b+ (the + is important) is not working. Let's chat offline... David
On Mon, 30 Jul 2018 at 15:39 David Rusling david.rusling@linaro.org wrote:
Daniel
On Mon, 30 Jul 2018 at 14:06 Daniel Thompson daniel.thompson@linaro.org wrote:
On Mon, Jul 30, 2018 at 01:16:08PM +0100, David Rusling wrote:
[4] There's not yet a standard 64 bit aarch64 release of Debian buster (9). That's terrible progress. I managed to build my own but not without a lot of faffing about.
Is the real problem:
a) That there is no AArch64 Debian buster rootfs image.
b) That the existing AArch64 Debian buster *installer* images doesn't boot out of the box.
Personally my own answer has always been b) and, to be honest, that's what got me interested in EBBR in the first place. EBBR (admitedly coupled with upstreamed hardware enablement for both bootloader and kernel) gets us much closer to that.
I could only find a buster image via h https://wiki.debian.org/RaspberryPi3ttps://wiki.debian.org/RaspberryPi3 and that didn't work out of the box for RPi 3b+. I'll chat with Steve et al and see what's missing / happening.
[5] Yocto / OE does not build natively arm on arm (as well as taking a
very
long time on a RPi 3)
Is this the "how to bootstrap go without using the host go compiler" problem or something else?
The problem appears to be not cross building as I see 'internal' issues. I'll build on x86 and see where the differences are, but I suspect that this is an arm-on-arm problem.
I should take my notes and write this 'folklore' up, but it is a mess compared to pretty much any Intel board. The shame is that the
Raspberry
Pi is probably the best supported aarch64 device that there is...
Must... resist... commenting...
Well done
David
Daniel.
--
David A Rusling CTO, Linaro https://linaro.org
[Looping in Steve McIntyre]
Steve, are you to comment on the 64-bit Arm support in Debian that David was running into?
g.
On 30/07/2018 13:16, David Rusling wrote:
Success. I now have a u-boot built on Arm64 that works. Along the way I learnt various things:
[1] Raspberry Pi's first stage loader generates the device tree. Overlays are used to turn various things on (for example sound) at boot time.
[2] There's a big difference between fdt_addr and fdt_addr_r, depending on whether you're running mainstream u-boot or rpi u-boot.
[3] RPI3 is not really fully upstream, various bits always need to be added. In other words, RPi, like a lot of Arm boards has its own mediated kernel tree, u-boot tree etc
[4] There's not yet a standard 64 bit aarch64 release of Debian buster (9). That's terrible progress. I managed to build my own but not without a lot of faffing about.
[5] Yocto / OE does not build natively arm on arm (as well as taking a very long time on a RPi 3)
I should take my notes and write this 'folklore' up, but it is a mess compared to pretty much any Intel board. The shame is that the Raspberry Pi is probably the best supported aarch64 device that there is...
David
On Thu, 26 Jul 2018 at 17:56 David Rusling <david.rusling@linaro.org mailto:david.rusling@linaro.org> wrote:
Tom, thanks, I appreciate all of your hard work, the code base looks good.. David On Thu, 26 Jul 2018 at 16:11 Tom Rini <trini@konsulko.com <mailto:trini@konsulko.com>> wrote: On Thu, Jul 26, 2018 at 01:55:51PM +0100, Peter Robinson wrote: > On Thu, Jul 26, 2018 at 1:46 PM, David Rusling <david.rusling@linaro.org <mailto:david.rusling@linaro.org>> wrote: > > Peter, > > thanks, that was one explanation that I hadn't thought of (32b = 32 > > bits). Really helpful, onwards and upwards... > > FYI they work fine 32 and 64 bits on both the 3B and 3B+ for me, only > currently tested 64 bit with uefi but they work fine for me, plus a > bunch of other 96boards. A Pi 3B is also in my CI loop (32bit then 64bit) so our (U-Boot's) test.py bits run on it reliably or I start yelling at people :) -- Tom -- David A Rusling CTO, Linaro https://linaro.org-- David A Rusling CTO, Linaro https://linaro.org
Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi Grant,
Just seen this - out at DebConf in Taiwan this week.
David - can you expand on your point [4] below please? Not sure what you're referring to with limited context...
On Mon, Jul 30, 2018 at 03:06:26PM +0100, Grant Likely wrote:
[Looping in Steve McIntyre]
Steve, are you to comment on the 64-bit Arm support in Debian that David was running into?
g.
On 30/07/2018 13:16, David Rusling wrote:
Success. I now have a u-boot built on Arm64 that works. Along the way I learnt various things:
[1] Raspberry Pi's first stage loader generates the device tree. Overlays are used to turn various things on (for example sound) at boot time.
[2] There's a big difference between fdt_addr and fdt_addr_r, depending on whether you're running mainstream u-boot or rpi u-boot.
[3] RPI3 is not really fully upstream, various bits always need to be added. In other words, RPi, like a lot of Arm boards has its own mediated kernel tree, u-boot tree etc
[4] There's not yet a standard 64 bit aarch64 release of Debian buster (9). That's terrible progress. I managed to build my own but not without a lot of faffing about.
[5] Yocto / OE does not build natively arm on arm (as well as taking a very long time on a RPi 3)
I should take my notes and write this 'folklore' up, but it is a mess compared to pretty much any Intel board. The shame is that the Raspberry Pi is probably the best supported aarch64 device that there is...
David
On Thu, 26 Jul 2018 at 17:56 David Rusling <david.rusling@linaro.org mailto:david.rusling@linaro.org> wrote:
Tom, thanks, I appreciate all of your hard work, the code base looks good.. David On Thu, 26 Jul 2018 at 16:11 Tom Rini <trini@konsulko.com <mailto:trini@konsulko.com>> wrote: On Thu, Jul 26, 2018 at 01:55:51PM +0100, Peter Robinson wrote: > On Thu, Jul 26, 2018 at 1:46 PM, David Rusling <david.rusling@linaro.org <mailto:david.rusling@linaro.org>> wrote: > > Peter, > > thanks, that was one explanation that I hadn't thought of (32b = 32 > > bits). Really helpful, onwards and upwards... > > FYI they work fine 32 and 64 bits on both the 3B and 3B+ for me, only > currently tested 64 bit with uefi but they work fine for me, plus a > bunch of other 96boards. A Pi 3B is also in my CI loop (32bit then 64bit) so our (U-Boot's) test.py bits run on it reliably or I start yelling at people :) -- Tom -- David A Rusling CTO, Linaro https://linaro.org-- David A Rusling CTO, Linaro https://linaro.org
Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Cheers,
boot-architecture@lists.linaro.org
-
Alexander Graf -
Daniel Thompson -
David Rusling -
Grant Likely -
Rob Herring -
Steve McIntyre