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

[Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx>]

On 7.10.2024 10:23 PM, Linus Walleij wrote:
> On Mon, Oct 7, 2024 at 6:35 PM Karl Chan <exxxxkc@xxxxxxxxxxxxxxx> 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