Re: T113-S3: Secure Boot

[Lukas Schmid <lukas.schmid@netcube.li>]

[-- Attachment #1: Type: text/plain, Size: 4150 bytes --]

On Samstag, 2. August 2025 02:09:39 CEST Andre Przywara wrote:
> On Fri, 01 Aug 2025 22:33:19 +0200
> Lukas Schmid <lukas.schmid@netcube.li> wrote:
> 
> Hi Lukas,
> 
> > I’m working on enabling secure boot on the Allwinner T113-S3 (as part of
> > preparing my SoM design for EU CRA compliance).
> > 
> > I’ve successfully fused the SoC with secure boot enabled and burned the
> > ROTPK_HASH.
> 
> Brave! I think so far we rarely have seen people actually written the
> ROTPK hash, but apparently that worked for you!
> 
> > The SoC correctly boots a TOC0-signed image from SD card, and U-
> > Boot starts up and behaves as expected.
> 
> Ah, nice!
> 
> > However, when I try to load and boot the kernel from U-Boot, the board
> > hangs right after U-Boot hands over control, no further progress. The
> > same kernel image worked fine before enabling secure boot, so I suspect
> > it might be related to the secure boot configuration or runtime
> > expectations.
> 
> I think so. The common problem is that without the secure boot fuse
> burnt, some devices that are documented as being accessible from secure
> world only are actually usable even from non-secure world, at least
> that's the case on the A64. The SID is one example, hence U-Boot
> (already running in non-secure EL2 on that chip) cannot read the serial
> number and thus fails to calculate a MAC address, when using secure
> boot.

So I actually know when I am in U-Boot and try to memory-dump the SID's memory 
range (the shadow register? at offset 0x200) I can actually read it fully, that 
is as long U-Boot was loaded over the signed image. If I load U-Boot over FEL 
and try to dump it I only get the first 16-ish words.

> Another thing that is different is access to secure SRAM. That's
> supposed to only work from secure, but works from non-secure as well
> (on the A64), when the secure fuse is not burnt.
> 
> So I would check those two things (SRAM + SID). Can you enable
> earlyprintk in the kernel config, to get really early output from the
> kernel? You would need to set the UART address and such in the config.

I'm building a kernel right now with earlyprintk, but I am unsure as what I 
should set for the config. Since the T113-s3 has it's "Console" on UART3 I'd 
need to specify the 8250 on a custom address. The base address is probably 
then 0x02500C00 but do i also need a Virtual address and if so what does it 
need to be set to?

> The first code to run on an arch/arm kernel is the decompressor, that's
> a rabbit hole of its own, but I doubt that it's triggering any of those
> devices.
> You could try to add "pings" in the early code to output a life sign on
> the UART, to see how far into the code you come.
> In assembly:
> 	mov	r1, #0x2500000
> 	orr	r1, r1, #0xc000
> 	mov	r0, #"1"
> 	str	r0, [r1]
> In C:
> 	volatile u32 *uart = (void *)(0x250c000UL);
> 	*uart = '2';
> 
> I also have some simple bare-metal C runtime, that allows to compile
> into something that looks like a kernel, and would allow you to verify
> that the kernel image is loaded correctly and executed at all. Let me
> know if you'd need that, I can then make you a simple version that says
> "Hello".
> 
> Hope that helps!
> 
> Oh, and please join us on IRC: #linux-sunxi on OFTC, that makes this
> kind of debugging much easier.

Sure thing. However I had tried it on there once and somehow the IRC Chat 
didn't actually send my message. I did see it in the Browser but not on the 
archive or any other IRC Chat...

> 
> Cheers,
> Andre
> 
> > I’ve already tried debugging U-Boot and confirmed that the kernel is
> > loaded and `bootm` is called; the system hangs at that point.
> > 
> > Here are the versions I’m using:
> > - **Kernel:** Linux 6.15.4 (mainline)
> > - **U-Boot:** 2025.07-rc5 (with custom devicetree and I2C3 modifications)
> > 
> > Is there anything specific I might be missing when running the kernel
> > under
> > secure boot on the T113-S3? Any guidance, common pitfalls, or pointers
> > would be appreciated.
> > 
> > Best regards,
> > Lukas


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]