| Message ID | 1464817421-8519-10-git-send-email-kraxel@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wednesday, June 1, 2016 11:43:18 PM CEST Gerd Hoffmann wrote: > diff --git a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts > new file mode 100644 > index 0000000..36178a6 > --- /dev/null > +++ b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts > @@ -0,0 +1 @@ > +#include "../../../arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts" > -- > 1.8.3.1 > What does this gain you? Arnd
Arnd Bergmann <arnd@arndb.de> writes: > On Wednesday, June 1, 2016 11:43:18 PM CEST Gerd Hoffmann wrote: >> diff --git a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts >> new file mode 100644 >> index 0000000..36178a6 >> --- /dev/null >> +++ b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts >> @@ -0,0 +1 @@ >> +#include "../../../arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts" >> -- >> 1.8.3.1 >> > > What does this gain you? Many Raspberry Pi users use a small set of SD cards that they swap between various versions of the hardware. It would be good to have their 32-bit OS images work on the Pi3 as well.
On Wednesday, June 1, 2016 3:30:35 PM CEST Eric Anholt wrote: > Arnd Bergmann <arnd@arndb.de> writes: > > > On Wednesday, June 1, 2016 11:43:18 PM CEST Gerd Hoffmann wrote: > >> diff --git a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts > >> new file mode 100644 > >> index 0000000..36178a6 > >> --- /dev/null > >> +++ b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts > >> @@ -0,0 +1 @@ > >> +#include "../../../arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts" > >> -- > >> 1.8.3.1 > >> > > > > What does this gain you? > > Many Raspberry Pi users use a small set of SD cards that they swap > between various versions of the hardware. It would be good to have > their 32-bit OS images work on the Pi3 as well. Sure, but you already have the dts file in the other directory, and the dtb is the same. According to the comment in the other patch, the idea was to have the file in the arm64 directory because it's a 64-bit platform, but now you have it here as well. Arnd
On Do, 2016-06-02 at 00:39 +0200, Arnd Bergmann wrote: > On Wednesday, June 1, 2016 3:30:35 PM CEST Eric Anholt wrote: > > Arnd Bergmann <arnd@arndb.de> writes: > > > > > On Wednesday, June 1, 2016 11:43:18 PM CEST Gerd Hoffmann wrote: > > >> diff --git a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts > > >> new file mode 100644 > > >> index 0000000..36178a6 > > >> --- /dev/null > > >> +++ b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts > > >> @@ -0,0 +1 @@ > > >> +#include "../../../arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts" > > >> -- > > >> 1.8.3.1 > > >> > > > > > > What does this gain you? > > > > Many Raspberry Pi users use a small set of SD cards that they swap > > between various versions of the hardware. It would be good to have > > their 32-bit OS images work on the Pi3 as well. > > Sure, but you already have the dts file in the other directory, > and the dtb is the same. > > According to the comment in the other patch, the idea was to have > the file in the arm64 directory because it's a 64-bit platform, > but now you have it here as well. Well, it just includes the arm64 version as-is, so we don't have duplication. I'm open to suggestions to how handle this better. Symbolic link? Reference to ../../../arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts directly in the Makefile? I've seen arch/arm/boot/dts/Makefile uses globs on *.dts, so I suspect the later wouldn't be that straight forward. cheers, Gerd
On Thursday, June 2, 2016 8:56:05 AM CEST Gerd Hoffmann wrote: > On Do, 2016-06-02 at 00:39 +0200, Arnd Bergmann wrote: > > On Wednesday, June 1, 2016 3:30:35 PM CEST Eric Anholt wrote: > > > Arnd Bergmann <arnd@arndb.de> writes: > > > > > > > On Wednesday, June 1, 2016 11:43:18 PM CEST Gerd Hoffmann wrote: > > > >> diff --git a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts > > > >> new file mode 100644 > > > >> index 0000000..36178a6 > > > >> --- /dev/null > > > >> +++ b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts > > > >> @@ -0,0 +1 @@ > > > >> +#include "../../../arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts" > > > >> -- > > > >> 1.8.3.1 > > > >> > > > > > > > > What does this gain you? > > > > > > Many Raspberry Pi users use a small set of SD cards that they swap > > > between various versions of the hardware. It would be good to have > > > their 32-bit OS images work on the Pi3 as well. > > > > Sure, but you already have the dts file in the other directory, > > and the dtb is the same. > > > > According to the comment in the other patch, the idea was to have > > the file in the arm64 directory because it's a 64-bit platform, > > but now you have it here as well. > > Well, it just includes the arm64 version as-is, so we don't have > duplication. I'm open to suggestions to how handle this better. > > Symbolic link? > > Reference to ../../../arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts > directly in the Makefile? > > I've seen arch/arm/boot/dts/Makefile uses globs on *.dts, so I suspect > the later wouldn't be that straight forward. It's just weird that the arm64 file includes the .dtsi files from arch/arm/ and is then again included back from another file there. I can see two possible ways to handle this better: - leave the complete set of bcm2837 files in arch/arm and then have one reference from arch/arm64 per .dts that refers to just that file. - come up with a rule to also build the .dtb files in arch/arm64 when we run 'make dtbs' for arch/arm and leave this file there. The argument that one could use the same dtb with a 32-bit kernel should basically hold true for any arm64 system, it's not specific to rpi-3 really. We don't normally test 32-bit kernels on 64-bit SoCs because 64-bit kernels are more efficient in a number of ways, and I'm sure there are bugs that prevent some systems from working (aside from how some machines cannot work because they don't have RAM below 4GB), but if this is now something that users are interested in, making it just work seems nicer than having a couple of board specific hacks. Arnd
Hi, > > Well, it just includes the arm64 version as-is, so we don't have > > duplication. I'm open to suggestions to how handle this better. > > > > Symbolic link? > > > > Reference to ../../../arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts > > directly in the Makefile? > > > > I've seen arch/arm/boot/dts/Makefile uses globs on *.dts, so I suspect > > the later wouldn't be that straight forward. > > It's just weird that the arm64 file includes the .dtsi files from arch/arm/ > and is then again included back from another file there. > > I can see two possible ways to handle this better: > > - leave the complete set of bcm2837 files in arch/arm and then have one > reference from arch/arm64 per .dts that refers to just that file. So basically do it the other way around. Would be a bit less messy indeed. > - come up with a rule to also build the .dtb files in arch/arm64 when > we run 'make dtbs' for arch/arm and leave this file there. The argument > that one could use the same dtb with a 32-bit kernel should basically > hold true for any arm64 system, it's not specific to rpi-3 really. Yes, in theory. No, in practice. As far I know the rpi3 is the only 64bit soc where a almost identical 32bit version exists, so running 32bit kernels on a 64bit processor actually happens in practice and I expect this to continue. If you want create sdcard images which run on any rpi variant this is pretty much the only reasonable way to do it. > We don't normally test 32-bit kernels on 64-bit SoCs because 64-bit > kernels are more efficient in a number of ways, and I'm sure there > are bugs that prevent some systems from working (aside from how some > machines cannot work because they don't have RAM below 4GB), but if > this is now something that users are interested in, making it just > work seems nicer than having a couple of board specific hacks. See above, I have my doubts that the user interest in this expands to other boards. So I'd tend to pick the first option. cheers, Gerd
On Thursday, June 2, 2016 11:14:30 AM CEST Gerd Hoffmann wrote: > Hi, > > > > Well, it just includes the arm64 version as-is, so we don't have > > > duplication. I'm open to suggestions to how handle this better. > > > > > > Symbolic link? > > > > > > Reference to ../../../arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts > > > directly in the Makefile? > > > > > > I've seen arch/arm/boot/dts/Makefile uses globs on *.dts, so I suspect > > > the later wouldn't be that straight forward. > > > > It's just weird that the arm64 file includes the .dtsi files from arch/arm/ > > and is then again included back from another file there. > > > > I can see two possible ways to handle this better: > > > > - leave the complete set of bcm2837 files in arch/arm and then have one > > reference from arch/arm64 per .dts that refers to just that file. > > So basically do it the other way around. Would be a bit less messy > indeed. > > > - come up with a rule to also build the .dtb files in arch/arm64 when > > we run 'make dtbs' for arch/arm and leave this file there. The argument > > that one could use the same dtb with a 32-bit kernel should basically > > hold true for any arm64 system, it's not specific to rpi-3 really. > > Yes, in theory. No, in practice. As far I know the rpi3 is the only > 64bit soc where a almost identical 32bit version exists, so running > 32bit kernels on a 64bit processor actually happens in practice and I > expect this to continue. If you want create sdcard images which run on > any rpi variant this is pretty much the only reasonable way to do it. I think the Allwinner A64 and the Samsung s5p6818 are other examples for this, where the initial run of boards all run 32-bit kernels for much of the same reasons. If users want to run a 32-bit distro on rpi-3 and on e.g. orange-pi, I don't see why they wouldn't also run the same binary on A64. Arnd
Hi, > > > > Reference to ../../../arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts > > > > directly in the Makefile? Actually tried that, and to my surprise this worked fine for both "make dtbs" and "make dtbs_install". So we should just do that I guess ... > > Yes, in theory. No, in practice. As far I know the rpi3 is the only > > 64bit soc where a almost identical 32bit version exists, so running > > 32bit kernels on a 64bit processor actually happens in practice and I > > expect this to continue. If you want create sdcard images which run on > > any rpi variant this is pretty much the only reasonable way to do it. > > I think the Allwinner A64 and the Samsung s5p6818 are other examples > for this, where the initial run of boards all run 32-bit kernels > for much of the same reasons. If users want to run a 32-bit distro > on rpi-3 and on e.g. orange-pi, I don't see why they wouldn't also run > the same binary on A64. ... and others can join the party on a case-by-case basis. I still expect for the majority of arm64 boards it is not very useful, so I don't think we should build all of them unconditionally. cheers, Gerd
On Thursday, June 2, 2016 5:11:31 PM CEST Gerd Hoffmann wrote: > > > > > > Reference to ../../../arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts > > > > > directly in the Makefile? > > Actually tried that, and to my surprise this worked fine for both "make > dtbs" and "make dtbs_install". > > So we should just do that I guess ... Right. > > > Yes, in theory. No, in practice. As far I know the rpi3 is the only > > > 64bit soc where a almost identical 32bit version exists, so running > > > 32bit kernels on a 64bit processor actually happens in practice and I > > > expect this to continue. If you want create sdcard images which run on > > > any rpi variant this is pretty much the only reasonable way to do it. > > > > I think the Allwinner A64 and the Samsung s5p6818 are other examples > > for this, where the initial run of boards all run 32-bit kernels > > for much of the same reasons. If users want to run a 32-bit distro > > on rpi-3 and on e.g. orange-pi, I don't see why they wouldn't also run > > the same binary on A64. > > ... and others can join the party on a case-by-case basis. > > I still expect for the majority of arm64 boards it is not very useful, > so I don't think we should build all of them unconditionally. Well, they are still controlled by Kconfig symbols. Some of them are shared between arm and arm64 and you would just get all dtbs in that case, while other symbols are specific to one of the two. Just for fun, which machines do we actually get if we decide to just enter the arch/arm64/boot/dts/ directory in an allmodconfig build? Arnd
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 06b6c2d..16de98f 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -66,7 +66,8 @@ dtb-$(CONFIG_ARCH_BCM2835) += \ bcm2835-rpi-b-rev2.dtb \ bcm2835-rpi-b-plus.dtb \ bcm2835-rpi-a-plus.dtb \ - bcm2836-rpi-2-b.dtb + bcm2836-rpi-2-b.dtb \ + bcm2837-rpi-3-b.dtb dtb-$(CONFIG_ARCH_BCM_5301X) += \ bcm4708-asus-rt-ac56u.dtb \ bcm4708-asus-rt-ac68u.dtb \ diff --git a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts new file mode 100644 index 0000000..36178a6 --- /dev/null +++ b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts @@ -0,0 +1 @@ +#include "../../../arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts"