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
