| Message ID | 20241007163414.32458-1-exxxxkc@getgoogleoff.me (mailing list archive) |
|---|---|
| Headers | show |
| Series | Initial Support for Linksys EA9350 V3 (linksys-jamaica) | expand |
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
On 7.10.2024 10:23 PM, Linus Walleij wrote: > 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? Not sure about this one, but older (10+yo) qcom socs had a secure call to switch to 64bit.. Konrad
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
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.
On Tue, Oct 8, 2024 at 10:49 AM Karl Chan <exxxxkc@getgoogleoff.me> wrote: > 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. It's maybe scary to reflash U-Boot. But you can boot a "new" U-Boot from U-Boot, so if you can compile a U-Boot with the proper hardware support and the RMR quirk, you should be able to boot that, and then use that to boot Linux into 64bit mode. Yours, Linus Walleij
I found a uboot for ipq5018 qcom reference boards https://git.codelinaro.org/clo/qsdk/oss/boot/u-boot-2016 .Considering my router is quite similar to one of those boards so the uboot should workon EA9350 i think?
Let me compile and try to chainload it from the stock uboot.(Btw I have never tried chainloading on qcom platform but i did try that on amlogic platform.)
U-Boot 2016.01 (Dec 06 2021 - 10:08:47 +0800)
CBT U-Boot ver: 3.2.08 ([IPQ5018].[SPF11.3].[CSU2])
DRAM: smem ram ptable found: ver: 1 len: 4
512 MiB
NAND: QPIC controller support serial NAND
ID = 22c822c8
Vendor = c8
Device = 22
Serial Nand Device Found With ID : 0xc8 0x22
Serial NAND device Manufacturer:GD5F2GQ5REYIH
Device Size:256 MiB, Page size:2048, Spare Size:64, ECC:4-bit
SF: Unsupported flash IDs: manuf 00, jedec 0000, ext_jedec 0000
ipq_spi: SPI Flash not found (bus/cs/speed/mode) = (0/0/48000000/0)
256 MiB
MMC: sdhci: Node Not found, skipping initialization
PCI Link Intialized
PCI1 is not defined in the device tree
In: serial@78AF000
Out: serial@78AF000
Err: serial@78AF000
machid: 8040001
eth0 MAC Address from ART is not valid
eth1 MAC Address from ART is not valid
Updating boot_count ... done
Hit any key to stop autoboot: 3 0
Net: cmbblk is stable 5
MAC1 addr:0:11:22:33:44:55
athrs17_reg_init: complete
S17c init done
eth0
Warning: eth0 MAC addresses don't match:
Address in SROM is 00:11:22:33:44:55
Address in environment is 00:03:7f:ba:db:ad
IPQ5018#
IPQ5018#
IPQ5018# usb start
starting USB...
USB0: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus 0 for devices... 2 USB Device(s) found
IPQ5018# fatload usb 0 ${loadaddr} u-boot.bin
reading u-boot.bin
419816 bytes read in 261 ms (1.5 MiB/s)
IPQ5018# go ${loadaddr}
## Starting application at 0x44000000 ...
prefetch abort
pc : [<44000004>] lr : [<4a92891b>]
reloc pc : [<44000004>] lr : [<4a92891b>]
sp : 4a822840 ip : 0000001c fp : 00000002
r10: 00000000 r9 : 4a822ea0 r8 : 4a97d300
r7 : 4a9288f1 r6 : 00000002 r5 : 44000000 r4 : 4a828b74
r3 : 44000000 r2 : 4a828b74 r1 : 4a828b74 r0 : 00000001
Flags: nzCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
resetting ...
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