Document the MSM8939 and supported boards in upstream Sony "Tulip" M4 Aqua
and Square APQ8039 T2.
MSM8939 is one of the older SoCs so we need to expand the list of
qcom,board-ids to allow for the bootloader DTS board-id matching
dependency.
Reviewed-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Bryan O'Donoghue <[email protected]>
---
Documentation/devicetree/bindings/arm/qcom.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 47913a8e3eea3..0721d1a0b80e6 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -35,6 +35,7 @@ description: |
mdm9615
msm8226
msm8916
+ msm8939
msm8953
msm8956
msm8974
@@ -164,6 +165,12 @@ properties:
- samsung,s3ve3g
- const: qcom,msm8226
+ - items:
+ - enum:
+ - sony,kanuti-tulip
+ - square,apq8039-t2
+ - const: qcom,msm8939
+
- items:
- enum:
- sony,kugo-row
@@ -966,6 +973,7 @@ allOf:
- qcom,apq8026
- qcom,apq8094
- qcom,apq8096
+ - qcom,msm8939
- qcom,msm8953
- qcom,msm8956
- qcom,msm8992
--
2.38.1
On Tue, Jan 17, 2023 at 02:48:39AM +0000, Bryan O'Donoghue wrote:
> Document the MSM8939 and supported boards in upstream Sony "Tulip" M4 Aqua
> and Square APQ8039 T2.
>
> MSM8939 is one of the older SoCs so we need to expand the list of
> qcom,board-ids to allow for the bootloader DTS board-id matching
> dependency.
>
The original LK bootloaders cannot boot your msm8939.dtsi correctly,
because a spin-table implementation is required to get the other CPU
cores up. This means that a modified bootloader is always needed from
the upstream point of view, since I doubt anyone wants to use these
devices with a single core only. lk2nd (as the primary spin-table
implementation right now) has never required qcom,board-ids and any
custom LK would be easy to patch to ignore these.
Do you already have a bootloader with spin-table support deployed in the
field that can be no longer easily modified to ignore the qcom,board-id?
If not, and you're planning to keep using the downstream patches to
bring the CPU cores up without spin-table/PSCI then you might as well
add the qcom,board-id as downstream patch as well.
If we don't support the original bootloaders in a usable way upstream
then we should not add MSM8939 to the allow list of broken bootloaders
either, in my opinion.
Thanks,
Stephan
On 18/01/2023 08:47, Stephan Gerhold wrote:
> On Tue, Jan 17, 2023 at 02:48:39AM +0000, Bryan O'Donoghue wrote:
>> Document the MSM8939 and supported boards in upstream Sony "Tulip" M4 Aqua
>> and Square APQ8039 T2.
>>
>> MSM8939 is one of the older SoCs so we need to expand the list of
>> qcom,board-ids to allow for the bootloader DTS board-id matching
>> dependency.
>>
>
> The original LK bootloaders cannot boot your msm8939.dtsi correctly,
> because a spin-table implementation is required to get the other CPU
> cores up. This means that a modified bootloader is always needed from
> the upstream point of view, since I doubt anyone wants to use these
> devices with a single core only. lk2nd (as the primary spin-table
> implementation right now) has never required qcom,board-ids and any
> custom LK would be easy to patch to ignore these.
The system boots just fine with the shipped LK. We get display, USB, SD,
WiFi.
We just don't support booting the second cluster via any other means
than lk2nd right now.
You could also not use lk2nd, stick with your default LK and import LPM
patches.
Default LK:
root@linaro-alip:~# cat /proc/cpuinfo
processor : 0
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
root@linaro-alip:~# iw wlan0 info
Interface wlan0
ifindex 6
wdev 0x1
addr e2:b9:a0:ef:3a:ba
type managed
wiphy 0
channel 52 (5260 MHz), width: 80 MHz, center1: 5290 MHz
txpower 20.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol
tx-bytes tx-packets
0 0 0 0 0 0 0
0 0
root@linaro-alip:~# uname -a
Linux linaro-alip 6.2.0-rc4-next-20230116-00029-gf1a46ff9e812-dirty #392
SMP PREEMPT Tue Jan 17 23:46:42 GMT 2023 aarch64 GNU/Linux
LK2ND:
root@linaro-alip:~# cat /proc/cpuinfo
processor : 0
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 1
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 2
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 3
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 4
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 5
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 6
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 7
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
root@linaro-alip:~# iw wlan0 info
Interface wlan0
ifindex 6
wdev 0x1
addr 02:00:0e:66:5c:21
type managed
wiphy 0
channel 64 (5320 MHz), width: 80 MHz, center1: 5290 MHz
txpower 20.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol
tx-bytes tx-packets
0 0 0 0 0 0 0
0 0
root@linaro-alip:~# uname -a
Linux linaro-alip 6.2.0-rc4-next-20230116-00029-gf1a46ff9e812-dirty #392
SMP PREEMPT Tue Jan 17 23:46:42 GMT 2023 aarch64 GNU/Linux
---
bod
On Wed, Jan 18, 2023 at 12:05:50PM +0000, Bryan O'Donoghue wrote:
> On 18/01/2023 08:47, Stephan Gerhold wrote:
> > On Tue, Jan 17, 2023 at 02:48:39AM +0000, Bryan O'Donoghue wrote:
> > > Document the MSM8939 and supported boards in upstream Sony "Tulip" M4 Aqua
> > > and Square APQ8039 T2.
> > >
> > > MSM8939 is one of the older SoCs so we need to expand the list of
> > > qcom,board-ids to allow for the bootloader DTS board-id matching
> > > dependency.
> > >
> >
> > The original LK bootloaders cannot boot your msm8939.dtsi correctly,
> > because a spin-table implementation is required to get the other CPU
> > cores up. This means that a modified bootloader is always needed from
> > the upstream point of view, since I doubt anyone wants to use these
> > devices with a single core only. lk2nd (as the primary spin-table
> > implementation right now) has never required qcom,board-ids and any
> > custom LK would be easy to patch to ignore these.
>
> The system boots just fine with the shipped LK. We get display, USB, SD,
> WiFi.
>
> We just don't support booting the second cluster via any other means than
> lk2nd right now.
>
> You could also not use lk2nd, stick with your default LK and import LPM
> patches.
>
My point is: If you import out of tree LPM patches you can also just
import an extra patch that adds the qcom,board-id property where needed.
The qcom,board-id is only needed/used in configurations where you need
to add those extra LPM patches on top anyway. Those configurations are
(sadly) not supported from the upstream point of view, since only PSCI
or spin-table are supposed to be used for CPU bring-up/idle.
Anyway, for me personally there is no difference if the funky
qcom,board-id properties are there or not, so I'll leave it up to
Rob/Krzysztof to decide if the board-id exception is warranted here or
not. :)
Thanks,
Stephan
On 18/01/2023 08:47, Stephan Gerhold wrote:
> If we don't support the original bootloaders in a usable way upstream
> then we should not add MSM8939 to the allow list of broken bootloaders
> either, in my opinion.
Yes but, a vendor could just as easily cherry-pick the spin-table
enabling lk2nd patches back to their lk implementation and begin to drop
the ongoing burden of supporting the LPM stuff.
We certainly do and should support booting stock lk. There's no sense in
setting the bar to upstream even higher by imposing a chainloaded
bootloader on our hypothetical new user.
The right thing to do is to enable the vanilla path but, give the user
the extra option.
---
bod