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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160601/d63d9ec8/attachment.sig>
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
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
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
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.
quoted hunk
- 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,
quoted
quoted
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.
quoted
- 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
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 ...
quoted
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:
quoted
quoted
quoted
quoted
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.
quoted
quoted
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