Newer U-Boot version throwing "Bootstage space exhasuted" with FIT image

[deffo at gmx.de]

Hi Simon,

even with CONFIG_BOOTSTAGE disabled I still get this data abort:

Starting kernel ...

data abort
pc : [<fdf3b91a>]	   lr : [<00000000>]
reloc pc : [<c010191a>]	   lr : [<c21c6000>]
sp : fbbefafc  ip : 00000000	 fp : 00000001
r10: c20000d8  r9 : fbbffec0	 r8 : 00000000
r7 : 00000000  r6 : 00000000	 r5 : e28ff010  r4 : 00000000
r3 : 00000000  r2 : 00000a10	 r1 : fdfab018  r0 : 2ffc0020
Flags: nzCv  IRQs off  FIQs off  Mode SVC_32 (T)
Code: f891 f03c f891 f05c (f891) f07c
Resetting CPU ...

resetting ...

How can I debug this any further?

Best regards

============================================================================================

Hi,

On Mon, 3 Apr 2023 at 00:43, <deffo at gmx.de> wrote:
>
> Hi Simon,
>
> it's an STM32MP1, here's a bdinfo and the full boot log. Btw, OPTEE OS is active:
>
> STM32MP> bdinfo
> boot_params = 0x00000000
> DRAM bank   = 0x00000000
> -> start    = 0xc0000000
> -> size     = 0x40000000
> flashstart  = 0x00000000
> flashsize   = 0x00000000
> flashoffset = 0x00000000
> baudrate    = 115200 bps
> relocaddr   = 0xfdf3a000
> reloc off   = 0x3de3a000
> Build       = 32-bit
> current eth = ethernet at 5800a000
> ethaddr     = 00:00:00:00:00:00
> IP addr     = <NULL>
> fdt_blob    = 0xfbf27e10
> new_fdt     = 0xfbf27e10
> fdt_size    = 0x000100a0
> lmb_dump_all:
>  memory.cnt  = 0x1
>  memory[0]      [0xc0000000-0xffffffff], 0x40000000 bytes flags: 0
>  reserved.cnt  = 0x5
>  reserved[0]    [0x10000000-0x10047fff], 0x00048000 bytes flags: 4
>  reserved[1]    [0x30000000-0x3003ffff], 0x00040000 bytes flags: 4
>  reserved[2]    [0x38000000-0x3800ffff], 0x00010000 bytes flags: 4
>  reserved[3]    [0xfbf23940-0xfdffffff], 0x020dc6c0 bytes flags: 0
>  reserved[4]    [0xfe000000-0xffffffff], 0x02000000 bytes flags: 4
> devicetree  = board
> arch_number = 0x00000000
> TLB addr    = 0xfdff0000
> irq_sp      = 0xfbf27b80
> sp start    = 0xfbf27b70
> Early malloc usage: 11f8 / 3000
> STM32MP> ext4load mmc ${boot_instance}:${boot_part} ${kernel_addr_r} ${linux}; bootm ${kernel_addr_r}
> 10590706 bytes read in 542 ms (18.6 MiB/s)
> ## Loading kernel from FIT Image at c2000000 ...
>    Using 'config' configuration
>    Trying 'kernel' kernel subimage
>      Description:  Linux kernel - base
>      Created:      2023-03-31  12:45:20 UTC
>      Type:         Kernel Image
>      Compression:  uncompressed
>      Data Start:   0xc20000d8
>      Data Size:    7527552 Bytes = 7.2 MiB
>      Architecture: ARM
>      OS:           Linux
>      Load Address: 0xc0008000
>      Entry Point:  0xc0008000
>      Hash algo:    sha256
>      Hash value:   b0ca7e8de523721697b6990e67f142159845f1b5e2a52a4fef4da8f6754d49a7
>      Sign algo:    sha256,rsa2048:board
>      Sign value:   unavailable
>      Timestamp:    unavailable
>    Verifying Hash Integrity ... sha256+ OK
>    kernel data at 0xc20000d8, len = 0x0072dc80 (7527552)
> ## Loading ramdisk from FIT Image at c2000000 ...
>    Using 'config' configuration
>    Trying 'ramdisk' ramdisk subimage
>      Description:  ramdisk
>      Created:      2023-03-31  12:45:20 UTC
>      Type:         RAMDisk Image
>      Compression:  uncompressed
>      Data Start:   0xc273d318
>      Data Size:    2998533 Bytes = 2.9 MiB
>      Architecture: ARM
>      OS:           Linux
>      Load Address: unavailable
>      Entry Point:  unavailable
>      Hash algo:    sha256
>      Hash value:   3d9201eee8e91a161719ea35b630d9d09dc6be204fcda3390ecd7a540e322048
>      Sign algo:    sha256,rsa2048:board
>      Sign value:   unavailable
>      Timestamp:    unavailable
>    Verifying Hash Integrity ... sha256+ OK
> ## Loading fdt from FIT Image at c2000000 ...
> Bootstage space exhasuted
>    Using 'config' configuration
>    Trying 'dtb' fdt subimage
>      Description:  DeviceTree blob - base
>      Created:      2023-03-31  12:45:20 UTC
>      Type:         Flat Device Tree
>      Compression:  uncompressed
>      Data Start:   0xc272de94
>      Data Size:    62326 Bytes = 60.9 KiB
>      Architecture: ARM
>      Load Address: 0xc4000000
>      Hash algo:    sha256
>      Hash value:   2b1df931402fd642c8a1618aa140630e22fed4c095deed4df201637f008630ea
>      Sign algo:    sha256,rsa2048:board
>      Sign value:   unavailable
>      Timestamp:    unavailable
>    Verifying Hash Integrity ... sha256+ OK
> Bootstage space exhasuted
> Bootstage space exhasuted
> Bootstage space exhasuted
> Bootstage space exhasuted
>    Loading fdt from 0xc272de94 to 0xc4000000
> Bootstage space exhasuted
>    Booting using the fdt blob at 0xc4000000
>    Loading Kernel Image
>    kernel loaded at 0xc0008000, end = 0xc0735c80
> Bootstage space exhasuted
> Bootstage space exhasuted
>    Loading Ramdisk to cfd23000, end cffff105 ... OK
>    Loading Device Tree to cfd10000, end cfd22375 ... OK
> Bootstage space exhasuted
> Bootstage space exhasuted
>
> Starting kernel ...
>
> data abort
> pc : [<fdf3b8ba>]          lr : [<00000000>]
> reloc pc : [<c01018ba>]    lr : [<c21c6000>]
> sp : fbf2786c  ip : 00000000     fp : 00000001
> r10: c20000d8  r9 : fbf37eb0     r8 : 00000000
> r7 : 00000000  r6 : 00000000     r5 : e28ff010  r4 : 00000000
> r3 : 00000000  r2 : 00000a10     r1 : fdfabb14  r0 : 2ffc0020
> Flags: nzCv  IRQs off  FIQs off  Mode SVC_32 (T)
> Code: f891 f03c f891 f05c (f891) f07c
> Resetting CPU ...
>
> resetting ...
>
> Thanks and best regards
>
> ======================================
>
> Hi,
>
> On Sat, 1 Apr 2023 at 02:57, <deffo at gmx.de> wrote:
> >
> > Hi,
> >
> > I changed from v2020.10 to v2022.10 and suddenly I get a bunch of "Bootstage space exhasuted" messages during bootm.
> >
> > reloc pc : [<c01018ba>] is memcpy()
> >
> > It evens triggers a reset. Older version works just fine:
> >
> >      Sign value:   unavailable
> >      Timestamp:    unavailable
> >    Verifying Hash Integrity ... sha256+ OK
> > Bootstage space exhasuted
> > Bootstage space exhasuted
> > Bootstage space exhasuted
> > Bootstage space exhasuted
> >    Loading fdt from 0xc272de94 to 0xc4000000
> > Bootstage space exhasuted
> >    Booting using the fdt blob at 0xc4000000
> >    Loading Kernel Image
> >    kernel loaded at 0xc0008000, end = 0xc0735c80
> > Bootstage space exhasuted
> > Bootstage space exhasuted
> >    Loading Ramdisk to cfd23000, end cffff105 ... OK
> >    Loading Device Tree to cfd10000, end cfd22375 ... OK
> > Bootstage space exhasuted
> > Bootstage space exhasuted
> >
> > Starting kernel ...
> >
> > data abort
> > pc : [<fdf3b8ba>]          lr : [<00000000>]
> > reloc pc : [<c01018ba>]    lr : [<c21c6000>]
> > sp : fbf2786c  ip : 00000000     fp : 00000001
> > r10: c20000d8  r9 : fbf37eb0     r8 : 00000000
> > r7 : 00000000  r6 : 00000000     r5 : e28ff010  r4 : 00000000
> > r3 : 00000000  r2 : 00000a10     r1 : fdfabb14  r0 : 2ffc0020
> > Flags: nzCv  IRQs off  FIQs off  Mode SVC_32 (T)
> > Code: f891 f03c f891 f05c (f891) f07c
> > Resetting CPU ...
> >
> > resetting ...
>
> Do you know which board it is? It would help to produce a full console trace.

If you disabled CONFIG_BOOTSTAGE does the problem go away? Running out
of space should not cause any problems. Also, try disabling
CONFIG_BOOTSTAGE and see if that makes a difference.

You can enable CONFIG_BOOTSTAGE_REPORT to see a report before the kernel boots.

Regards,
Simon