mbox series

[v6,0/5] Initial Support for Linksys EA9350 V3 (linksys-jamaica)

Message ID 20241007163414.32458-1-exxxxkc@getgoogleoff.me
Headers show
Series Initial Support for Linksys EA9350 V3 (linksys-jamaica) | expand

Message

Karl Chan Oct. 7, 2024, 4:34 p.m. UTC
Add device tree source for Linksys EA9350 V3 which is a WiFi router based on the IPQ5018 SoC.

As of now , only the UART,USB,USB LED,buttons is working.The front PWM LED require the IPQ PWM driver.Therefore the PWM LED isn't configed in the tree.

Also The original firmware from Linksys can only boot ARM32 kernels.

As of now There seems to be no way to boot ARM64 kernels on those device.

However, it is possible to use this device tree by compiling an ARM32 kernel instead.

Signed-off-by: Karl Chan <exxxxkc@getgoogleoff.me>
---
Changes in v6:
  - Fix the subject in the cover letter (I messed that up in v5)
  - Fix line wrap issue as Dmitry Baryshkov pointed out
  - Mention the 64-bit variant in the commit message and the comment
Changes in v5:
  - drop all fake tags as Krzysztof Kozlowski pointed out
  - (It was my bad i thought i dropped all the tag but i missed one that
    in the cover letter)
  - Link to v4:
    https://lore.kernel.org/linux-arm-msm/20241002162812.31606-2-exxxxkc@getgoogleoff.me/T/#t
Changes in v4:
  - drop all fake tags as Krzysztof Kozlowski pointed out
  - Link to v3: https://lore.kernel.org/linux-arm-msm/20241002152419.30364-1-exxxxkc@getgoogleoff.me/T/#t
Changes in v3:
  - Add 2 commit that I forgot to send in v1/2.
  - Link to v2: https://lore.kernel.org/linux-arm-msm/20241002132302.31608-1-exxxxkc@getgoogleoff.me/T/#t
Changes in v2:
  - reorder the properties in the tree to follow the
    usual order pointed out by Krzysztof Kozlowski
  - Add the missing word to the cover letter
  - Link to v1: https://lore.kernel.org/linux-arm-msm/20241002120804.25068-1-exxxxkc@getgoogleoff.me/T/#t
---
Karl Chan (5):
  dt-bindings: arm: qcom: add Linksys EA9350 V3
  arm64: dts: qcom: add Linksys EA9350 V3
  clk: qcom: ipq5018: allow it to be bulid on arm32
  pinctrl: qcom: ipq5018: allow it to be bulid on arm32
  arm: dts: qcom-ipq5018-linksys-jamaica: Include dts from arm64

 .../devicetree/bindings/arm/qcom.yaml         |   1 +
 arch/arm/boot/dts/qcom/Makefile               |   1 +
 .../dts/qcom/qcom-ipq5018-linksys-jamaica.dts |   2 +
 arch/arm64/boot/dts/qcom/Makefile             |   1 +
 .../boot/dts/qcom/ipq5018-linksys-jamaica.dts | 109 ++++++++++++++++++
 drivers/clk/qcom/Kconfig                      |   2 +-
 drivers/pinctrl/qcom/Kconfig.msm              |   2 +-
 7 files changed, 116 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/boot/dts/qcom/qcom-ipq5018-linksys-jamaica.dts
 create mode 100644 arch/arm64/boot/dts/qcom/ipq5018-linksys-jamaica.dts

Comments

Krzysztof Kozlowski Oct. 7, 2024, 6:11 p.m. UTC | #1
On 07/10/2024 18:34, Karl Chan wrote:
> Document linksys,jamaica for Linksys EA9350 V3.
> 
> Signed-off-by: Karl Chan <exxxxkc@getgoogleoff.me>

I repeat myself and no results, so I don't know how to say it
differently. But I am not going to repeat the same over and over and
expect different results.

Best regards,
Krzysztof
Linus Walleij Oct. 7, 2024, 8:23 p.m. UTC | #2
On Mon, Oct 7, 2024 at 6:35 PM Karl Chan <exxxxkc@getgoogleoff.me> wrote:

> Also The original firmware from Linksys can only boot ARM32 kernels.
>
> As of now There seems to be no way to boot ARM64 kernels on those device.

So this is a Cortex-A53 Aarch64 system running in ARM32 mode.

So I got this interactive U-boot log from Karl showing how the attempt
to boot an Aarch64 kernel manifests:

CBT U-Boot ver: 3.2.08  ([IPQ5018].[SPF11.3].[CSU2])

## Loading kernel from FIT Image at 44000000 ...
   Using 'standard' configuration
   Trying 'kernel' kernel subimage
     Description:  Kernel
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x440000a8
     Data Size:    8249289 Bytes = 7.9 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x41208000
     Entry Point:  0x41208000
   Verifying Hash Integrity ... OK
(...)
## Loading ramdisk from FIT Image at 44000000 ...
(...)
## Loading fdt from FIT Image at 44000000 ...
(...)
fdt_fixup_qpic: QPIC: unable to find node '/soc/qpic-nand@79b0000'
Could not find PCI in device tree
Using machid 0x8040001 from environment

Starting kernel ...

undefined instruction
pc : [<41208004>]          lr : [<4a921f8f>]
reloc pc : [<41208004>]    lr : [<4a921f8f>]
sp : 4a822838  ip : 00000001     fp : 00000000
r10: 4a83b914  r9 : 4a822ea0     r8 : 00000000
r7 : 00000000  r6 : 41208000     r5 : 4a97d848  r4 : 00000000
r3 : 644d5241  r2 : 4a0ae000     r1 : 08040001  r0 : 00000000
Flags: nzCV  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

resetting ...

So perhaps someone knows how we can get around this.

It seems to me the U-Boot is in 32bit mode and tries to just
execute an Aarch64 binary and that doesn't work.

What we need is a 32bit mode preamble that can switch
the machine to Aarch64 and continue.

I don't know *how* to do that, but I would *guess* a botched
return from exception where you provide your own stack
with the Aarch64 state hardcoded on it should do the job?

The Aarch64 maintainers will know what to do.

Surely it should be possible to add a little code snippet
to do this somewhere in memory, and that in turn jumps
to execute the actual Aarch64 kernel in Aarch64 mode?

Yours,
Linus Walleij
Arnd Bergmann Oct. 7, 2024, 10 p.m. UTC | #3
On Mon, Oct 7, 2024, at 20:23, Linus Walleij wrote:
> On Mon, Oct 7, 2024 at 6:35 PM Karl Chan <exxxxkc@getgoogleoff.me> wrote:
>
> Starting kernel ...
>
> undefined instruction
> pc : [<41208004>]          lr : [<4a921f8f>]
> reloc pc : [<41208004>]    lr : [<4a921f8f>]
> sp : 4a822838  ip : 00000001     fp : 00000000
> r10: 4a83b914  r9 : 4a822ea0     r8 : 00000000
> r7 : 00000000  r6 : 41208000     r5 : 4a97d848  r4 : 00000000
> r3 : 644d5241  r2 : 4a0ae000     r1 : 08040001  r0 : 00000000
> Flags: nzCV  IRQs off  FIQs off  Mode SVC_32
> Resetting CPU ...
>
> resetting ...
>
> So perhaps someone knows how we can get around this.
>
> It seems to me the U-Boot is in 32bit mode and tries to just
> execute an Aarch64 binary and that doesn't work.
>
> What we need is a 32bit mode preamble that can switch
> the machine to Aarch64 and continue.

I found this older patch for u-boot about a similar problem
on sunxi machines:

https://patchwork.ozlabs.org/project/uboot/patch/1480902750-839-12-git-send-email-andre.przywara@arm.com/#1528602

Karl, do you have the u-boot sources for this board? I found
a source tarball for kernel (both in 32-bit and 64-bit
mode) and userland on this machines at

https://support.linksys.com/kb/article/316-en/

but the u-boot sources in there don't seem to match the binary
(they are only used to build the u-boot tools, but not the
actual loader). Is this the same base you are working from,
or do you have something else beyond that?

      Arnd
Karl Chan Oct. 8, 2024, 8:47 a.m. UTC | #4
I dont have the uboot sauce.Also i did ask for the gpl code via their form and they putted that in the site that u sanded.I tried ask for the uboot sauce via the live support chat but i got nothing back.Maybe i should use the form again?(linksys dont have the uboot sauce in the gpl tarball of other rotuer as well. i guess it is the time for fsf to suit linksys twice? (See https://en.wikipedia.org/wiki/Free_Software_Foundation%2C_Inc._v._Cisco_Systems%2C_Inc.) )

Also Other linksys ipq5018 based rotuer is capable of booting arm64.maybe i could rip the uboot from those rotuer and flash it to ea9350 v3 but i dont have another linksys ipq5018 based rotuer.