[PATCH next v3] Kconfig: select SPL_USE_TINY_PRINTF_POINTER_SUPPORT for K3

[PATCH next v3] Kconfig: select SPL_USE_TINY_PRINTF_POINTER_SUPPORT for K3

[Anshul Dalal]

Since the commit 1e24e84db41a ("tiny-printf: Handle formatting of %p
with an extra Kconfig"), SPL_USE_TINY_PRINTF_POINTER_SUPPORT has been
made mandatory in order to use %p which would earlier have defaulted to
a 'long' print.

Without this config symbol, k3_sysfw_dfu_download fails to set the
correct value for the DFU string with:

 sprintf(dfu_str, "sysfw.itb ram 0x%p 0x%x", addr,
   CONFIG_K3_SYSFW_IMAGE_SIZE_MAX);

The value we get "sysfw.itb ram 0x? 0x41c29d40" causes a boot failure.

Therefore this patch sets SPL_USE_TINY_PRINTF_POINTER_SUPPORT for all K3
devices since the size impact is less than 100 bytes.

Signed-off-by: Anshul Dalal <anshuld@ti.com>
---
Changes in v3:
- Handle setting the config in Kconfig instead of the defconfig
- Link to v2: https://lore.kernel.org/r/20251105-am65_dfu_fix-v2-1-ccada89d966d@ti.com

Changes in v2:
- Remove unrelated changes
- Link to v1: https://lore.kernel.org/r/20251105-am65_dfu_fix-v1-1-acc29111dccf@ti.com
---
 arch/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 3db5474a05b..7756ed000b1 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -830,6 +830,7 @@ config ARCH_K3
 	bool "Texas Instruments' K3 Architecture"
 	select SPL
 	select SUPPORT_SPL
+	select SPL_USE_TINY_PRINTF_POINTER_SUPPORT
 	select FIT
 	select REGEX
 	select FIT_SIGNATURE if ARM64

---
base-commit: dca19206acf2af2d339087bb62aa0b8ee1b0e326
change-id: 20251105-am65_dfu_fix-1144eec06b19

Best regards,
-- 
Anshul Dalal <anshuld@ti.com>

Re: [PATCH next v3] Kconfig: select SPL_USE_TINY_PRINTF_POINTER_SUPPORT for K3

[Anshul Dalal]

Hi all,

Any updates on this patch? If possible could we pull this fix into
master as well for the 2026.01 release?

On Thu Dec 4, 2025 at 4:42 PM IST, Anshul Dalal wrote:
> Since the commit 1e24e84db41a ("tiny-printf: Handle formatting of %p
> with an extra Kconfig"), SPL_USE_TINY_PRINTF_POINTER_SUPPORT has been
> made mandatory in order to use %p which would earlier have defaulted to
> a 'long' print.
>
> Without this config symbol, k3_sysfw_dfu_download fails to set the
> correct value for the DFU string with:
>
>  sprintf(dfu_str, "sysfw.itb ram 0x%p 0x%x", addr,
>    CONFIG_K3_SYSFW_IMAGE_SIZE_MAX);
>
> The value we get "sysfw.itb ram 0x? 0x41c29d40" causes a boot failure.
>
> Therefore this patch sets SPL_USE_TINY_PRINTF_POINTER_SUPPORT for all K3
> devices since the size impact is less than 100 bytes.
>
> Signed-off-by: Anshul Dalal <anshuld@ti.com>
> ---
> Changes in v3:
> - Handle setting the config in Kconfig instead of the defconfig
> - Link to v2: https://lore.kernel.org/r/20251105-am65_dfu_fix-v2-1-ccada89d966d@ti.com
>
> Changes in v2:
> - Remove unrelated changes
> - Link to v1: https://lore.kernel.org/r/20251105-am65_dfu_fix-v1-1-acc29111dccf@ti.com
> ---
>  arch/arm/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 3db5474a05b..7756ed000b1 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -830,6 +830,7 @@ config ARCH_K3
>  	bool "Texas Instruments' K3 Architecture"
>  	select SPL
>  	select SUPPORT_SPL
> +	select SPL_USE_TINY_PRINTF_POINTER_SUPPORT
>  	select FIT
>  	select REGEX
>  	select FIT_SIGNATURE if ARM64
>
> ---
> base-commit: dca19206acf2af2d339087bb62aa0b8ee1b0e326
> change-id: 20251105-am65_dfu_fix-1144eec06b19
>
> Best regards,

Re: [PATCH next v3] Kconfig: select SPL_USE_TINY_PRINTF_POINTER_SUPPORT for K3

[Tom Rini]

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

On Tue, Dec 16, 2025 at 01:52:37PM +0530, Anshul Dalal wrote:
> Hi all,
> 
> Any updates on this patch? If possible could we pull this fix into
> master as well for the 2026.01 release?

I thought the feedback was that this was a generic problem and so the
Kconfig logic should be universal, or there was an incorrectly /
sub-optimally handled case in the tiny printf code, that needs fixing.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH next v3] Kconfig: select SPL_USE_TINY_PRINTF_POINTER_SUPPORT for K3

[Anshul Dalal]

On Tue Dec 16, 2025 at 7:31 PM IST, Tom Rini wrote:
> On Tue, Dec 16, 2025 at 01:52:37PM +0530, Anshul Dalal wrote:
>> Hi all,
>> 
>> Any updates on this patch? If possible could we pull this fix into
>> master as well for the 2026.01 release?
>
> I thought the feedback was that this was a generic problem and so the
> Kconfig logic should be universal, or there was an incorrectly /
> sub-optimally handled case in the tiny printf code, that needs fixing.

We have a few ways to go about fixing this:

1. Fix the commit 1e24e84db41a ("tiny-printf: Handle formatting of %p
   with an extra Kconfig"):

   Pointer formatting used to fall back to %x handling before the
   commit. Though going by the commit description, it looks like the
   change was intended. So, I'm unsure if we should re-introduce the
   confusing handling back where %p is handled but not %pa or %pap.

2. Add SPL_USE_TINY_PRINTF_POINTER_SUPPORT per defconfig:

   This was what v2 of the series were attempting to do but as Andrew
   pointed out, there might be other platforms with similar issues and
   it would be better to fix it for K3 overall.

3. Change usage of %p in k3_sysfw_dfu_download to %x:

   This is a suitable fix imo but we might still have to fix similar
   usages of %p in other places. We'd also have to be more careful when
   bringing proper U-Boot code to SPL since %p would not work the same
   way.

4. Unconditionally select SPL_USE_TINY_PRINTF_POINTER_SUPPORT for K3:

   This allows us to remedy the problems with above 3 solutions with
   very little overhead to the SPL size (<100 bytes).

If this problem is faced by non K3 platforms as well, perhaps it might
be better to take the hit and make SPL_USE_TINY_PRINTF_POINTER_SUPPORT
default y.

Regards,
Anshul

Re: [PATCH next v3] Kconfig: select SPL_USE_TINY_PRINTF_POINTER_SUPPORT for K3

[Tom Rini]

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

On Wed, Dec 17, 2025 at 11:03:43AM +0530, Anshul Dalal wrote:
> On Tue Dec 16, 2025 at 7:31 PM IST, Tom Rini wrote:
> > On Tue, Dec 16, 2025 at 01:52:37PM +0530, Anshul Dalal wrote:
> >> Hi all,
> >> 
> >> Any updates on this patch? If possible could we pull this fix into
> >> master as well for the 2026.01 release?
> >
> > I thought the feedback was that this was a generic problem and so the
> > Kconfig logic should be universal, or there was an incorrectly /
> > sub-optimally handled case in the tiny printf code, that needs fixing.
> 
> We have a few ways to go about fixing this:
> 
> 1. Fix the commit 1e24e84db41a ("tiny-printf: Handle formatting of %p
>    with an extra Kconfig"):
> 
>    Pointer formatting used to fall back to %x handling before the
>    commit. Though going by the commit description, it looks like the
>    change was intended. So, I'm unsure if we should re-introduce the
>    confusing handling back where %p is handled but not %pa or %pap.
> 
> 2. Add SPL_USE_TINY_PRINTF_POINTER_SUPPORT per defconfig:
> 
>    This was what v2 of the series were attempting to do but as Andrew
>    pointed out, there might be other platforms with similar issues and
>    it would be better to fix it for K3 overall.
> 
> 3. Change usage of %p in k3_sysfw_dfu_download to %x:
> 
>    This is a suitable fix imo but we might still have to fix similar
>    usages of %p in other places. We'd also have to be more careful when
>    bringing proper U-Boot code to SPL since %p would not work the same
>    way.
> 
> 4. Unconditionally select SPL_USE_TINY_PRINTF_POINTER_SUPPORT for K3:
> 
>    This allows us to remedy the problems with above 3 solutions with
>    very little overhead to the SPL size (<100 bytes).
> 
> If this problem is faced by non K3 platforms as well, perhaps it might
> be better to take the hit and make SPL_USE_TINY_PRINTF_POINTER_SUPPORT
> default y.

Ah, so now I understand the problem, with point 3. So yes, I think the
right fix is to add "select SPL_USE_TINY_PRINTF_POINTER_SUPPORT if
SPL_USE_TINY_PRINTF && DFU && CPU_V7R" under the ARCH_K3 symbol.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH next v3] Kconfig: select SPL_USE_TINY_PRINTF_POINTER_SUPPORT for K3

[Andrew Davis]

On 12/18/25 8:16 AM, Tom Rini wrote:
> On Wed, Dec 17, 2025 at 11:03:43AM +0530, Anshul Dalal wrote:
>> On Tue Dec 16, 2025 at 7:31 PM IST, Tom Rini wrote:
>>> On Tue, Dec 16, 2025 at 01:52:37PM +0530, Anshul Dalal wrote:
>>>> Hi all,
>>>>
>>>> Any updates on this patch? If possible could we pull this fix into
>>>> master as well for the 2026.01 release?
>>>
>>> I thought the feedback was that this was a generic problem and so the
>>> Kconfig logic should be universal, or there was an incorrectly /
>>> sub-optimally handled case in the tiny printf code, that needs fixing.
>>
>> We have a few ways to go about fixing this:
>>
>> 1. Fix the commit 1e24e84db41a ("tiny-printf: Handle formatting of %p
>>     with an extra Kconfig"):
>>
>>     Pointer formatting used to fall back to %x handling before the
>>     commit. Though going by the commit description, it looks like the
>>     change was intended. So, I'm unsure if we should re-introduce the
>>     confusing handling back where %p is handled but not %pa or %pap.
>>
>> 2. Add SPL_USE_TINY_PRINTF_POINTER_SUPPORT per defconfig:
>>
>>     This was what v2 of the series were attempting to do but as Andrew
>>     pointed out, there might be other platforms with similar issues and
>>     it would be better to fix it for K3 overall.
>>
>> 3. Change usage of %p in k3_sysfw_dfu_download to %x:
>>
>>     This is a suitable fix imo but we might still have to fix similar
>>     usages of %p in other places. We'd also have to be more careful when
>>     bringing proper U-Boot code to SPL since %p would not work the same
>>     way.
>>

For what it's worth my preference would be this one. We should just work
to avoid using %p in general outside of debug statements.

>> 4. Unconditionally select SPL_USE_TINY_PRINTF_POINTER_SUPPORT for K3:
>>
>>     This allows us to remedy the problems with above 3 solutions with
>>     very little overhead to the SPL size (<100 bytes).
>>

How about unconditionally select this for all platforms? If it is only
saving 100 bytes it shouldn't be an issue for most, then platforms that
have verified they do not need it (or need to save every last byte) can
then disable it. Seems odd to make a change like "1e24e84db41a" and not
have the default be the existing behavior.

>> If this problem is faced by non K3 platforms as well, perhaps it might
>> be better to take the hit and make SPL_USE_TINY_PRINTF_POINTER_SUPPORT
>> default y.
> 
> Ah, so now I understand the problem, with point 3. So yes, I think the
> right fix is to add "select SPL_USE_TINY_PRINTF_POINTER_SUPPORT if
> SPL_USE_TINY_PRINTF && DFU && CPU_V7R" under the ARCH_K3 symbol.
> 

Just the length and specificity of that conditional string is making
me think that is not the right solution. What happens when we find
the same issue for SPL DFU on ARM64, or in some other code not
related to DFU, etc..

Andrew

Re: [PATCH next v3] Kconfig: select SPL_USE_TINY_PRINTF_POINTER_SUPPORT for K3

[Tom Rini]

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

On Thu, Dec 18, 2025 at 08:41:57AM -0600, Andrew Davis wrote:
> On 12/18/25 8:16 AM, Tom Rini wrote:
> > On Wed, Dec 17, 2025 at 11:03:43AM +0530, Anshul Dalal wrote:
> > > On Tue Dec 16, 2025 at 7:31 PM IST, Tom Rini wrote:
> > > > On Tue, Dec 16, 2025 at 01:52:37PM +0530, Anshul Dalal wrote:
> > > > > Hi all,
> > > > > 
> > > > > Any updates on this patch? If possible could we pull this fix into
> > > > > master as well for the 2026.01 release?
> > > > 
> > > > I thought the feedback was that this was a generic problem and so the
> > > > Kconfig logic should be universal, or there was an incorrectly /
> > > > sub-optimally handled case in the tiny printf code, that needs fixing.
> > > 
> > > We have a few ways to go about fixing this:
> > > 
> > > 1. Fix the commit 1e24e84db41a ("tiny-printf: Handle formatting of %p
> > >     with an extra Kconfig"):
> > > 
> > >     Pointer formatting used to fall back to %x handling before the
> > >     commit. Though going by the commit description, it looks like the
> > >     change was intended. So, I'm unsure if we should re-introduce the
> > >     confusing handling back where %p is handled but not %pa or %pap.
> > > 
> > > 2. Add SPL_USE_TINY_PRINTF_POINTER_SUPPORT per defconfig:
> > > 
> > >     This was what v2 of the series were attempting to do but as Andrew
> > >     pointed out, there might be other platforms with similar issues and
> > >     it would be better to fix it for K3 overall.
> > > 
> > > 3. Change usage of %p in k3_sysfw_dfu_download to %x:
> > > 
> > >     This is a suitable fix imo but we might still have to fix similar
> > >     usages of %p in other places. We'd also have to be more careful when
> > >     bringing proper U-Boot code to SPL since %p would not work the same
> > >     way.
> > > 
> 
> For what it's worth my preference would be this one. We should just work
> to avoid using %p in general outside of debug statements.

I'm also fine with that.

> > > 4. Unconditionally select SPL_USE_TINY_PRINTF_POINTER_SUPPORT for K3:
> > > 
> > >     This allows us to remedy the problems with above 3 solutions with
> > >     very little overhead to the SPL size (<100 bytes).
> > > 
> 
> How about unconditionally select this for all platforms? If it is only
> saving 100 bytes it shouldn't be an issue for most, then platforms that
> have verified they do not need it (or need to save every last byte) can
> then disable it. Seems odd to make a change like "1e24e84db41a" and not
> have the default be the existing behavior.

There's just lots of platforms that can't afford much growth.

> > > If this problem is faced by non K3 platforms as well, perhaps it might
> > > be better to take the hit and make SPL_USE_TINY_PRINTF_POINTER_SUPPORT
> > > default y.
> > 
> > Ah, so now I understand the problem, with point 3. So yes, I think the
> > right fix is to add "select SPL_USE_TINY_PRINTF_POINTER_SUPPORT if
> > SPL_USE_TINY_PRINTF && DFU && CPU_V7R" under the ARCH_K3 symbol.
> > 
> 
> Just the length and specificity of that conditional string is making
> me think that is not the right solution. What happens when we find
> the same issue for SPL DFU on ARM64, or in some other code not
> related to DFU, etc..

Part of the answer is that since we should be printing "?" now instead
of the wrong value, it should be easier to spot the wrong code. Perhaps
we also need something in doc/develop/spl.rst to talk about it (we
default to a tiny subset printf, some things don't work without
additional options, avoid %p unless you must and then enable
SPL_USE...)?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH next v3] Kconfig: select SPL_USE_TINY_PRINTF_POINTER_SUPPORT for K3

[Andrew Davis]

On 12/18/25 8:58 AM, Tom Rini wrote:
> On Thu, Dec 18, 2025 at 08:41:57AM -0600, Andrew Davis wrote:
>> On 12/18/25 8:16 AM, Tom Rini wrote:
>>> On Wed, Dec 17, 2025 at 11:03:43AM +0530, Anshul Dalal wrote:
>>>> On Tue Dec 16, 2025 at 7:31 PM IST, Tom Rini wrote:
>>>>> On Tue, Dec 16, 2025 at 01:52:37PM +0530, Anshul Dalal wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Any updates on this patch? If possible could we pull this fix into
>>>>>> master as well for the 2026.01 release?
>>>>>
>>>>> I thought the feedback was that this was a generic problem and so the
>>>>> Kconfig logic should be universal, or there was an incorrectly /
>>>>> sub-optimally handled case in the tiny printf code, that needs fixing.
>>>>
>>>> We have a few ways to go about fixing this:
>>>>
>>>> 1. Fix the commit 1e24e84db41a ("tiny-printf: Handle formatting of %p
>>>>      with an extra Kconfig"):
>>>>
>>>>      Pointer formatting used to fall back to %x handling before the
>>>>      commit. Though going by the commit description, it looks like the
>>>>      change was intended. So, I'm unsure if we should re-introduce the
>>>>      confusing handling back where %p is handled but not %pa or %pap.
>>>>
>>>> 2. Add SPL_USE_TINY_PRINTF_POINTER_SUPPORT per defconfig:
>>>>
>>>>      This was what v2 of the series were attempting to do but as Andrew
>>>>      pointed out, there might be other platforms with similar issues and
>>>>      it would be better to fix it for K3 overall.
>>>>
>>>> 3. Change usage of %p in k3_sysfw_dfu_download to %x:
>>>>
>>>>      This is a suitable fix imo but we might still have to fix similar
>>>>      usages of %p in other places. We'd also have to be more careful when
>>>>      bringing proper U-Boot code to SPL since %p would not work the same
>>>>      way.
>>>>
>>
>> For what it's worth my preference would be this one. We should just work
>> to avoid using %p in general outside of debug statements.
> 
> I'm also fine with that.
> 
>>>> 4. Unconditionally select SPL_USE_TINY_PRINTF_POINTER_SUPPORT for K3:
>>>>
>>>>      This allows us to remedy the problems with above 3 solutions with
>>>>      very little overhead to the SPL size (<100 bytes).
>>>>
>>
>> How about unconditionally select this for all platforms? If it is only
>> saving 100 bytes it shouldn't be an issue for most, then platforms that
>> have verified they do not need it (or need to save every last byte) can
>> then disable it. Seems odd to make a change like "1e24e84db41a" and not
>> have the default be the existing behavior.
> 
> There's just lots of platforms that can't afford much growth.
> 
>>>> If this problem is faced by non K3 platforms as well, perhaps it might
>>>> be better to take the hit and make SPL_USE_TINY_PRINTF_POINTER_SUPPORT
>>>> default y.
>>>
>>> Ah, so now I understand the problem, with point 3. So yes, I think the
>>> right fix is to add "select SPL_USE_TINY_PRINTF_POINTER_SUPPORT if
>>> SPL_USE_TINY_PRINTF && DFU && CPU_V7R" under the ARCH_K3 symbol.
>>>
>>
>> Just the length and specificity of that conditional string is making
>> me think that is not the right solution. What happens when we find
>> the same issue for SPL DFU on ARM64, or in some other code not
>> related to DFU, etc..
> 
> Part of the answer is that since we should be printing "?" now instead
> of the wrong value, it should be easier to spot the wrong code. Perhaps
> we also need something in doc/develop/spl.rst to talk about it (we
> default to a tiny subset printf, some things don't work without
> additional options, avoid %p unless you must and then enable
> SPL_USE...)?
> 

That's fair, hopefully folks understand that to make "tiny" printf
so "tiny" some things needed to be removed, best we can do is thoroughly
document exactly what those removed features are. The issue here was this
was a feature that *did* work before in tiny printf, and was since
removed, more documentation wouldn't have helped.

The only way we would hit this issue again now that the feature is removed
by default is if we are taking code from U-Boot proper where the feature
does work, and running it in an SPL environment. Maybe we should work
towards using tiny printf in regular U-Boot also. Would keep function
behaviors more consistent.

Andrew