Newer U-Boot version throwing "Bootstage space exhasuted" with FIT image
Simon Glass
sjg at chromium.org
Sun Apr 2 20:45:03 CEST 2023
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
More information about the U-Boot
mailing list