Re: [PATCH v1 08/10] arm64: dts: exynos: Add initial support for exynos8895 SoC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2024-08-07 at 14:20 +0300, Ivaylo Ivanov wrote:
> 
> On 8/7/24 12:20, Krzysztof Kozlowski wrote:
> > On 07/08/2024 10:28, ivo.ivanov.ivanov1@xxxxxxxxx wrote:
> > > From: Ivaylo Ivanov <ivo.ivanov.ivanov1@xxxxxxxxx>
[snip]
> > > 
> > > +
> > > +	timer {
> > > +		compatible = "arm,armv8-timer";
> > > +		/* Hypervisor Virtual Timer interrupt is not
> > > wired to GIC */
> > > +		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8)
> > > | IRQ_TYPE_LEVEL_LOW)>,
> > > +			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8)
> > > | IRQ_TYPE_LEVEL_LOW)>,
> > > +			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8)
> > > | IRQ_TYPE_LEVEL_LOW)>,
> > > +			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8)
> > > | IRQ_TYPE_LEVEL_LOW)>;
> > > +		clock-frequency = <26000000>;
> > Hm? I think this was explicitly disallowed.
> 
> It's weird. Without the clock-frequency property it fails early
> during the
> 
> boot process and I can't get any logs from pstore or simple-
> framebuffer.
> 
> Yet it's not set on similar platforms (exynos7885, autov9). Perhaps I
> 
> could alias the node and set it in the board device tree..? That
> doesn't
> 
> sound right.

This sounds like CNTFRQ_EL0 is not set properly by the firmware.
Now, if I read the documentation properly, this can be only set from
EL3, which in your case is... not easy.

On my Galaxy A8 2018 (Exynos7885) I remember the old Android 8
bootloader not being able to boot mainline, but Android 9 bootloaders
did. I did not take the time to check if it was related to this, but it
is my guess.

Your best bet is that maybe Samsung decided to fix this on the latest
bootloader, and upgrading will fix it. (Though if it's already on an
Android 9 based bootloader and it's still broken, my guess is a newer
version won't fix it, but who knows)

Or... Exynos8895 has a known bootrom vulnerability, you could force the
SoC into USB Download mode, and use the exploit to boot into a patched
bootloader. This is of course pretty tedious.

Your only actually relistic choice is submitting without this line and
manually adding it while actually using the phone (or making the
chainloaded bootloader/boot wrapper add it).

Not optimal, but it is what it is...

Best Regards,
David






[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux