Hi Jerome & Tom, On Mon, Jun 23, 2025 at 1:10 AM Jerome Forissier <[email protected]> wrote: > > Hi Tom, > > On 6/21/25 03:36, Tom Rini wrote: > > On Fri, Jun 20, 2025 at 02:21:59PM -0700, Tony Dinh wrote: > >> Hi Jerome, > >> > >> On Fri, Jun 20, 2025 at 4:03 AM Jerome Forissier > >> <[email protected]> wrote: > >>> > >>> On 6/20/25 12:53, Jerome Forissier wrote: > >>>> Hi Tony, > >>>> > >>>> On 6/19/25 22:37, Tony Dinh wrote: > >>>>> Hi Jerome, > >>>>> > >>>>> While fixing some ext4 file system problems on 2025.07-rc4, I ran into > >>>>> a problem booting a few Kirkwood boards. kwboot loaded the u-boot > >>>>> image, > >>>>> and then u-boot execution was frozen without anything going to the > >>>>> serial console. I did a bisect and found the commit that caused it. > >>>>> > >>>>> https://github.com/trini/u-boot/commit/6fe50e39508043f386fc1bd40bbc02b8a75c1940 > >>>>> > >>>>> When I tried to reverse this commit, I had a build error like this > >>>>> "{standard input}:24246: Error: selected processor does not support > >>>>> `mrc p15,1,r3,c15,c1,0' in Thumb mode" > >>>>> > >>>>> Currently, the only way to boot Kirkwood boards is to disable either > >>>>> CONFIG_LTO or CONFIG_SYS_THUMB_BUILD or both. > >>>>> > >>>>> I'm using the pogo_v4 and nsa325 boards as test beds. Please let me > >>>>> know if I can help with testing to troubleshoot this regression. > >>>>> > >>>>> All the best, > >>>>> Tony > >>>> > >>>> The problem seems to be that some arm32 instructions are inlined > >>>> inside thumb code and that's not allowed on this CPU without some > >>>> interworking instruction (bx, blx etc.). For example, consider > >>>> board_init_r(), is is mainly 16-bit instructions (Thumb): > >>>> > >>>> 006186a0 <board_init_r>: > >>>> board_init_r(): > >>>> /home/jerome/work/u-boot/common/board_r.c:799 > >>>> 6186a0: b5f0 push {r4, r5, r6, r7, lr} > >>>> 6186a2: b0ab sub sp, #172 @ 0xac > >>>> get_gd(): > >>>> /home/jerome/work/u-boot/./arch/arm/include/asm/global_data.h:127 > >>>> 6186a4: 464a mov r2, r9 > >>>> ... > >>>> > >>>> but then suddenly: > >>>> > >>>> /home/jerome/work/u-boot/arch/arm/mach-kirkwood/cpu.c:242 > >>>> 619aae: 9b15 ldr r3, [sp, #84] @ 0x54 > >>>> writefr_extra_feature_reg(): > >>>> /home/jerome/work/u-boot/./arch/arm/include/asm/arch/cpu.h:100 > >>>> 619ab0: ee2f3f11 mcr 15, 1, r3, cr15, cr1, {0} > >>>> ^^^^^^^^ > >>>> 32-bit arm instruction > >>>> > >>>> I would expect some call to a *_from_thumb() veneer, such as in: > >>>> > >>>> 006009dc <do_bootm_qnxelf>: > >>>> [...] > >>>> /home/jerome/work/u-boot/boot/bootm_os.c:379 > >>>> 600a02: 9501 str r5, [sp, #4] > >>>> /home/jerome/work/u-boot/boot/bootm_os.c:384 > >>>> 600a04: f04a fc7c bl 64b300 > >>>> <__dcache_status_from_thumb> > >>>> > >>>> > >>>> 0064b130 <__dcache_enable_from_thumb>: > >>>> __dcache_enable_from_thumb(): > >>>> 64b130: 4778 bx pc > >>>> 64b132: e7fd b.n 64b130 > >>>> <__dcache_enable_from_thumb> > >>>> 64b134: e59fc000 ldr ip, [pc] @ 64b13c > >>>> <__dcache_enable_from_thumb+0xc> > >>>> 64b138: e08cf00f add pc, ip, pc > >>>> 64b13c: fffffb28 .word 0xfffffb28 > >>>> > >>>> We may need to move the inline functions with mrc/mcr to a .S file, > >>>> making sure it's built with -marm on CPUs that do not support Thumb2. > >>>> Then hopefully the proper interworking sequence would be inserted by the > >>>> linker as is the case when Thumb is calling into object files resulting > >>>> from .c files built with -marm (for example: arch/arm/mach-kirkwood/cpu.c > >>>> which has CFLAGS_cpu.o := -marm). > >>>> > >>>> In the meantime, could you try the following patch? > >>>> > >>>> diff --git a/common/Makefile b/common/Makefile > >>>> index 35991562a12..a509675335a 100644 > >>>> --- a/common/Makefile > >>>> +++ b/common/Makefile > >>>> @@ -19,6 +19,8 @@ obj-y += version.o > >>>> # # boards > >>>> obj-y += board_f.o > >>>> obj-y += board_r.o > >>>> +CFLAGS_board_f.o += -marm > >>>> +CFLAGS_board_r.o += -marm > >>>> obj-$(CONFIG_DISPLAY_BOARDINFO) += board_info.o > >>>> obj-$(CONFIG_DISPLAY_BOARDINFO_LATE) += board_info.o > >>>> > >>>> I think it should resolve the issue, but is does also increase the > >>>> size of the binary (+4 KiB). So the .S solution would definitely be > >>>> better if it works IMO. I'll try to propose something ASAP, will > >>>> likely be on Monday, feel free to give it a try by yourself though :) > >>> > >>> Or maybe this which is a bit less radical: > >>> > >>> diff --git a/common/Makefile b/common/Makefile > >>> index 35991562a12..f0b7eadf7d2 100644 > >>> --- a/common/Makefile > >>> +++ b/common/Makefile > >>> @@ -19,6 +19,8 @@ obj-y += version.o > >>> # # boards > >>> obj-y += board_f.o > >>> obj-y += board_r.o > >>> +CFLAGS_REMOVE_board_f.o := $(LTO_CFLAGS) > >>> +CFLAGS_REMOVE_board_r.o := $(LTO_CFLAGS) > >>> obj-$(CONFIG_DISPLAY_BOARDINFO) += board_info.o > >>> obj-$(CONFIG_DISPLAY_BOARDINFO_LATE) += board_info.o > >>> > >>> Still results in +1 KiB. > >> > >> The above patch works great! I've tested it on 3 Kirkwood boards: the > >> Pogo V4 (88F6192), Zyxel NSA325 (88F6282), and GoFlex Home (88F6281, > >> same SoC as the Sheevaplug). > >> > >> The Sheevaplug is now 498K, which is well under limit. All these > >> boards see only 1K increase in binary size. > > > > Can we please get a patch of the latter option now for the release and > > look at doing the .S file for the future? Thanks! > > https://lists.denx.de/pipermail/u-boot/2025-June/592785.html > > Regards, > -- > Jerome
Just a heads up, in a few days I'll be away for a few weeks. And not sure I can access my development box to do the testing for the upcoming .S patch. If not, I will do that late next month. All the best, Tony
