T113-S3: Secure Boot

T113-S3: Secure Boot

[Lukas Schmid]

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

Hi all,

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. The SoC correctly boots a TOC0-signed image from SD card, and U-
Boot starts up and behaves as expected.

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’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 --]

Re: T113-S3: Secure Boot

[Andre Przywara]

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.
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.
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.

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

Re: T113-S3: Secure Boot

[Lukas Schmid]

[-- 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 --]

Re: T113-S3: Secure Boot

[Parthiban]

Hi Lukas,

On 8/1/25 10:33 PM, Lukas Schmid wrote:
> 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. The SoC correctly boots a TOC0-signed image from SD card, and U-
> Boot starts up and behaves as expected.

Could you please share how this is done or may be with a document patch to
u-boot? To add, am also in the initial analysis of adding secure boot for A133.

Thanks,
Parthiban

Re: T113-S3: Secure Boot

[Lukas Schmid]

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

On Freitag, 7. November 2025 18:13:13 Mitteleuropäische Normalzeit Parthiban 
wrote:
> Hi Lukas,
Hi Parthiban
> 
> On 8/1/25 10:33 PM, Lukas Schmid wrote:
> > 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. The SoC correctly boots a TOC0-signed image from SD card, and
> > U- Boot starts up and behaves as expected.
> 
> Could you please share how this is done or may be with a document patch to
> u-boot? To add, am also in the initial analysis of adding secure boot for
> A133.
I actually do have a document on how I fused and flashed my prototype board 
here: https://nagami.readthedocs.io/en/latest/software/enable-secureboot-on-soc/

The required changes to U-Boot are already in a Patch, but I haven't heard 
anything back yet.
> 
> Thanks,
> Parthiban
Best regards,
Lukas


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

Re: T113-S3: Secure Boot

[Parthiban]

Dear Lukas,

On 11/8/25 5:56 PM, Lukas Schmid wrote:
> On Freitag, 7. November 2025 18:13:13 Mitteleuropäische Normalzeit Parthiban 
> wrote:
>> Hi Lukas,
> Hi Parthiban
>>
>> On 8/1/25 10:33 PM, Lukas Schmid wrote:
>>> 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. The SoC correctly boots a TOC0-signed image from SD card, and
>>> U- Boot starts up and behaves as expected.
>>
>> Could you please share how this is done or may be with a document patch to
>> u-boot? To add, am also in the initial analysis of adding secure boot for
>> A133.
> I actually do have a document on how I fused and flashed my prototype board 
> here: https://nagami.readthedocs.io/en/latest/software/enable-secureboot-on-soc/

Thanks for your response and link to the document. I will check that.

> 
> The required changes to U-Boot are already in a Patch, but I haven't heard 
> anything back yet.

I couldn't find that patch in upstream u-boot mainline list. Could you please
point to the series / patch?

Thanks,
Parthiban

>>
>> Thanks,
>> Parthiban
> Best regards,
> Lukas
> 

Re: T113-S3: Secure Boot

[Lukas Schmid]

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

On Samstag, 8. November 2025 18:01:02 Mitteleuropäische Normalzeit Parthiban 
wrote:
Hi Parthiban,
> Dear Lukas,
> 
> On 11/8/25 5:56 PM, Lukas Schmid wrote:
> > On Freitag, 7. November 2025 18:13:13 Mitteleuropäische Normalzeit
> > Parthiban> 
> > wrote:
> >> Hi Lukas,
> > 
> > Hi Parthiban
> > 
> >> On 8/1/25 10:33 PM, Lukas Schmid wrote:
> >>> 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. The SoC correctly boots a TOC0-signed image from SD card,
> >>> and
> >>> U- Boot starts up and behaves as expected.
> >> 
> >> Could you please share how this is done or may be with a document patch
> >> to
> >> u-boot? To add, am also in the initial analysis of adding secure boot for
> >> A133.
> > 
> > I actually do have a document on how I fused and flashed my prototype
> > board
> > here:
> > https://nagami.readthedocs.io/en/latest/software/enable-secureboot-on-soc
> > /
> Thanks for your response and link to the document. I will check that.
> 
> > The required changes to U-Boot are already in a Patch, but I haven't heard
> > anything back yet.
> 
> I couldn't find that patch in upstream u-boot mainline list. Could you
> please point to the series / patch?

Actually it seems I did not send them yet as I was waiting on another patch to 
be sent.

My changes are available here however: https://gitlab.com/netcube-systems-austria/u-boot/-/commits/next?ref_type=HEADS

Best regards,
Lukas
> 
> Thanks,
> Parthiban
> 
> >> Thanks,
> >> Parthiban
> > 
> > Best regards,
> > Lukas


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

Re: T113-S3: Secure Boot

[Parthiban]

Dear Lukas,

On 11/8/25 6:55 PM, Lukas Schmid wrote:
> I actually do have a document on how I fused and flashed my prototype
> board
> here:
> https://nagami.readthedocs.io/en/latest/software/enable-secureboot-on-soc
> /
> My changes are available here however: https://gitlab.com/netcube-systems-austria/u-boot/-/commits/next?ref_type=HEADS

Many thanks for sharing the details in the document and also the code changes.
I had to do minor changes to get the SPL -> (BL31 + U-Boot) to work with FIT
signature verification. In short, u-boot had to "loadbles" instead for firmware

@@ -164,7 +162,8 @@
                                @config-SEQ {
                                        description = "NAME";
 #if CONFIG_SUNXI_BL31_BASE
-                                       firmware = "atf", "uboot";
+                                       firmware = "atf";
+                                       loadables = "uboot";
 #else
                                        firmware = "uboot";
 #endif

and otherwise the verification worked great.

For secure boot,

```
commit 33cab879691bce96bddaf6558d53a987157e3a4f
Author: Parthiban Nallathambi <parthiban@linumiz.com>
Date:   Wed Jan 7 14:45:43 2026 +0530

    dts: sunxi: fix for ARM64 with A133 secure booting
    
    Fix the global dtsi to boot with secure boot enabled for A133
    
    Signed-off-by: Parthiban Nallathambi <parthiban@linumiz.com>

diff --git a/arch/arm/dts/sunxi-u-boot.dtsi b/arch/arm/dts/sunxi-u-boot.dtsi
index 93e58bc9ba6..b3fffd39838 100644
--- a/arch/arm/dts/sunxi-u-boot.dtsi
+++ b/arch/arm/dts/sunxi-u-boot.dtsi
@@ -30,11 +30,7 @@
 &binman {
 #ifdef CONFIG_SPL_FIT_SIGNATURE
        spl {
-#ifdef CONFIG_SPL_IMAGE_TYPE_SUNXI_TOC0
                filename = "spl/u-boot-spl.bin";
-#else
-               filename = "spl/sunxi-spl.bin";
-#endif
 
                u-boot-spl-nodtb {
                };
@@ -46,19 +42,21 @@
                };
        };
 
-#ifdef CONFIG_SPL_IMAGE_TYPE_SUNXI_TOC0
         image {
             filename = "spl/sunxi-spl.bin";
 
             mkimage {
-                args = "-a 0x20060 -T sunxi_toc0";
+#ifdef CONFIG_SPL_IMAGE_TYPE_SUNXI_TOC0
+               args = "-v -n allwinner/sun50i-a133-helper-board -a 0x20060 -T sunxi_toc0";
+#elif CONFIG_SPL_IMAGE_TYPE_SUNXI_EGON
+               args = "-v -n allwinner/sun50i-a133-helper-board -a 0x20060 -T sunxi_egon";
+#endif
                 data-to-imagename;
 
                 u-boot-spl {
                };
             };
         };
-#endif
 #endif
```

that's the diff which I tried to use it. Without explicit CONFIG_SPL_IMAGE_TYPE_SUNXI_EGON,
the image generated by the previous stage using mkimage is again replaced with binman. So
the eGON wasn't working and I added the additional sunxi_egon one. And also I had to disable
"CONFIG_SPL_BINMAN_UBOOT_SYMBOLS".

For the TOC0 to work, I tried the below commands. As far as I understand from your blog and
also documents, ROTPK can be optionally flashed. If flashed, S_BROM will check for the
integrity of the public key. If not flashed / fused, it will continue to the next steps of
verification i.e verifying the signature of the SPL using the public key.

So I have tried using the below commands to enable the secure boot bit, (RTC base in A133
is 0x07000000) after flashing the TOC0 contained image in the eMMC.

mw 0x07000204 0x1
mw 0x03006050 0x00000800        # bit 11 = 1
mw 0x03006040 0x0048AC01        # write to offset 0x48
mw 0x07000204 0x0

when I reset after these commands, the device enters FEL. So it didn't boot. Also with FEL,
am not able to load using sunxi-fel. So I guess I bricked this device.

- Is there a way I can load SPL / U-boot using sunxi-fel with this state? [1] checks for
eGON and exits if I use TOC0. So it's not possible or is it only the limitation of sunxi-fel?
- SID Specification and Address map is not shared in public by Allwinner for A133. So assumed
"eFUSE Region Overview" [2] is after H6. Is there a way to verify or dump register contents
and cross check it?
- Only way to verify the written eFUSE is by reading it after writing i.e
md 0x03006040? But the SID_PRCTL states 0x02 is for reading. So I shall write
"mw 0x03006040 0x0048AC02" and read "md 0x03006050"?

[1]: https://github.com/linux-sunxi/sunxi-tools/blob/master/fel.c#L776
[2]: https://linux-sunxi.org/SID_Register_Guide

--
Thanks,
Parthiban
https://linumiz.com
https://www.linkedin.com/company/linumiz
> 
> Best regards,
> Lukas