* [U-Boot] Issue with memcpy when booting a fitImage on SPEAr600
@ 2018-12-05 10:38 Quentin Schulz
2018-12-05 11:30 ` Stefan Roese
0 siblings, 1 reply; 7+ messages in thread
From: Quentin Schulz @ 2018-12-05 10:38 UTC (permalink / raw)
To: u-boot
Hello everyone,
I'm working on porting a mainline U-Boot on a custom board based on a
SPEAr600. Right now, I'm facing an issue related with fitImage booting.
Before starting on the fitImage issue, let me state that the zImage and the
custom DTB concatenated in a uImage have the load address and entry point
be respectively 0x0200.0000 and 0x0200.0040. The fitImage load and entry
are both 0x0200.0000. The uImage loaded at the address 0x0080.0000 is
booted fine by U-Boot, the fitImage at the same address, not.
The datasheet of the SoC states that the external SDRAM is located between
0x0000.0000 and 0x3fff.ffff. The size of the fitImage is currently
0x0038.9484 bytes, the uImage 0x0038.9007.
The fitImage booting abruptly stops right after "Loading Device Tree to
0778a000, end 0778e7d6 ... OK" with the following trace:
"prefetch abort
pc : [<f188af44>] lr : [<07fca8c7>]
reloc pc : [<ed7f8f44>] lr : [<03f388c7>]
sp : 0778fb78 ip : fffc4c98 fp : 03f00020
r10: deadbeef r9 : 0778ff00 r8 : 07f922a0
r7 : 00ff0000 r6 : 000047d7 r5 : 00004700 r4 : 0778a1b8
r3 : 00000008 r2 : 000016c4 r1 : 0778a1b8 r0 : 0778a1b8
Flags: nZCv IRQs off FIQs off Mode SVC_32
Code: data abort
pc : [<07f931c6>] lr : [<07fb2dd1>]
reloc pc : [<03f011c6>] lr : [<03f20dd1>]
sp : 0778fa80 ip : 00000114 fp : 03f00020
r10: deadbeef r9 : 0778ff00 r8 : 07f922a0
r7 : 60000000 r6 : 00000698 r5 : f188af44 r4 : fffffffc
r3 : fffffff0 r2 : 0778ff00 r1 : 00000020 r0 : 00000006
Flags: NzCv IRQs on FIQs on Mode SVC_32
Code: 23036be5 439d4818 f885f038 42642404 (595a00a3)
Resetting CPU ...
resetting ...
System is going to reboot ..."
I've narrowed down the issue to a memmove being called with destination
pointer being the source pointer. If I print a debug message before and
after this memcpy[1], the first debug message is printed but not the
second one.
If I add a condition for (dest == src) return dest in the very beginning of
memmove, the fitImage boots just fine. This test seemed to have been
removed by commit cb0eae8cf8aaca76910dee4c7eb536d0814d1bd2[12], and by
reverting this commit, I was able to successfuly boot Linux with a
fitImage.
Here is the log without debug messages WITHOUT the dest == src check in
memmove:
U-Boot 2018.11-00007-g0b16f8424a-dirty (Dec 05 2018 - 09:23:31 +0100)-SPEAr
CPU: SPEAr600
DRAM: 128 MiB
Flash: 512 KiB
NAND: 128 MiB
Loading Environment from Flash... OK
Net: dwmac.e0800000
Hit SPACE in 3 seconds to stop autoboot.
=> dhcp; tftp fitImage; bootm
Speed: 100, full duplex
BOOTP broadcast 1
DHCP client bound to address 192.168.0.169 (3 ms)
Speed: 100, full duplex
Using dwmac.e0800000 device
TFTP from server 192.168.0.13; our IP address is 192.168.0.169
Filename 'fitImage'.
Load address: 0x800000
Loading: #################################################################
#################################################################
#################################################################
##########################################################
5.5 MiB/s
done
Bytes transferred = 3708036 (389484 hex)
## Loading kernel from FIT Image at 00800000 ...
Using 'conf at default' configuration
Trying 'kernel at 0' kernel subimage
Description: Linux
Type: Kernel Image
Compression: uncompressed
Data Start: 0x008000b0
Data Size: 3700720 Bytes = 3.5 MiB
Architecture: ARM
OS: Linux
Load Address: 0x02000000
Entry Point: 0x02000000
Hash algo: sha1
Hash value: efe249f573647bad3ce87c9c4b244986a90234db
## Loading fdt from FIT Image at 00800000 ...
Using 'conf at default' configuration
Trying 'fdt at 0' fdt subimage
Description: Device Tree
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x00b87984
Data Size: 6103 Bytes = 6 KiB
Architecture: ARM
Hash algo: sha1
Hash value: 53089fa031e727f094e6bf9ad4e93f4e95b7fba3
Booting using the fdt blob at 0xb87984
Loading Kernel Image ... OK
Loading Device Tree to 0778a000, end 0778e7d6 ... OK
prefetch abort
pc : [<f188af44>] lr : [<07fca8c7>]
reloc pc : [<ed7f8f44>] lr : [<03f388c7>]
sp : 0778fb78 ip : fffc4c98 fp : 03f00020
r10: deadbeef r9 : 0778ff00 r8 : 07f922a0
r7 : 00ff0000 r6 : 000047d7 r5 : 00004700 r4 : 0778a1b8
r3 : 00000008 r2 : 000016c4 r1 : 0778a1b8 r0 : 0778a1b8
Flags: nZCv IRQs off FIQs off Mode SVC_32
Code: data abort
pc : [<07f931c6>] lr : [<07fb2dd1>]
reloc pc : [<03f011c6>] lr : [<03f20dd1>]
sp : 0778fa80 ip : 00000114 fp : 03f00020
r10: deadbeef r9 : 0778ff00 r8 : 07f922a0
r7 : 60000000 r6 : 00000698 r5 : f188af44 r4 : fffffffc
r3 : fffffff0 r2 : 0778ff00 r1 : 00000020 r0 : 00000006
Flags: NzCv IRQs on FIQs on Mode SVC_32
Code: 23036be5 439d4818 f885f038 42642404 (595a00a3)
Resetting CPU ...
resetting ...
System is going to reboot ...
With debug messages (_DEBUG = 1 and a few printf("%s: %d\n", __func__,
__LINE__);):
=> dhcp; tftp fitImage; bootm
Trying dwmac.e0800000
Speed: 100, full duplex
BOOTP broadcast 1
DHCPHandler: got packet: (src=67, dst=68, len=300) state: 3
Filtering pkt = 0
DHCPHandler: got DHCP packet: (src=67, dst=68, len=300) state: 3
DHCP: state=SELECTING bp_file: ""
TRANSITIONING TO REQUESTING STATE
dhcp_send_request_packet: Sending DHCPREQUEST
Transmitting DHCPREQUEST packet: len = 342
DHCPHandler: got packet: (src=67, dst=68, len=300) state: 4
Filtering pkt = 0
DHCPHandler: got DHCP packet: (src=67, dst=68, len=300) state: 4
DHCP State: REQUESTING
net_boot_file_name:
DHCP client bound to address 192.168.0.169 (21 ms)
Initial value for argc=3
Final value for argc=3
Initial value for argc=3
Final value for argc=3
Initial value for argc=3
Final value for argc=3
Initial value for argc=3
Final value for argc=3
Initial value for argc=3
Final value for argc=3
Initial value for argc=3
Final value for argc=3
Trying dwmac.e0800000
Speed: 100, full duplex
TFTP blocksize = 1468, timeout = 5000 ms
Using dwmac.e0800000 device
TFTP from server 192.168.0.13; our IP address is 192.168.0.169
Filename 'fitImage'.
Load address: 0x800000
Loading: send option "timeout 5"
Got OACK: timeout 5
Blocksize ack: 1468, 1468
#################################################################
#################################################################
#################################################################
##########################################################
5.3 MiB/s
done
Bytes transferred = 3708036 (389484 hex)
Initial value for argc=3
Final value for argc=3
Initial value for argc=3
Final value for argc=3
Initial value for argc=3
Final value for argc=3
Initial value for argc=3
Final value for argc=3
Initial value for argc=3
Final value for argc=3
Initial value for argc=3
Final value for argc=3
Initial value for argc=3
Final value for argc=3
## Current stack ends at 0x0778dd04 * kernel: default image load address = 0x00800000
## Loading kernel from FIT Image at 00800000 ...
No configuration specified, trying default...
Found default configuration: 'conf at default'
Using 'conf at default' configuration
Trying 'kernel at 0' kernel subimage
Description: Linux
Type: Kernel Image
Compression: uncompressed
Data Start: 0x008000b0
Data Size: 3700720 Bytes = 3.5 MiB
Architecture: ARM
OS: Linux
Load Address: 0x02000000
Entry Point: 0x02000000
Hash node: 'hash at 0'
Hash algo: sha1
Hash value: efe249f573647bad3ce87c9c4b244986a90234db
Hash len: 20
kernel data at 0x008000b0, len = 0x003877f0 (3700720)
* ramdisk: using config 'conf at default' from image at 0x00800000
* ramdisk: no 'ramdisk' in config
* fdt: using config 'conf at default' from image at 0x00800000
## Checking for 'FDT'/'FDT Image' at 00800000
## Loading fdt from FIT Image at 00800000 ...
Using 'conf at default' configuration
Trying 'fdt at 0' fdt subimage
Description: Device Tree
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x00b87984
Data Size: 6103 Bytes = 6 KiB
Architecture: ARM
Can't get 'load' property from FIT 0x00800000, node: offset 3701020, name fdt at 0 (FDT_ERR_NOTFOUND)
Hash node: 'hash at 0'
Hash algo: sha1
Hash value: 53089fa031e727f094e6bf9ad4e93f4e95b7fba3
Hash len: 20
Can't get 'load' property from FIT 0x00800000, node: offset 3701020, name fdt at 0 (FDT_ERR_NOTFOUND)
fit_uname=fdt at 0, fit_uname_config=conf at default
Booting using the fdt blob at 0xb87984
of_flat_tree at 0x00b87984 size 0x000017d7
Initial value for argc=3
Final value for argc=3
Loading Kernel Image ... OK
kernel loaded at 0x02000000, end = 0x023877f0
## initrd_high = 0x08000000, copy_to_ram = 1
ramdisk load start = 0x00000000, ramdisk load end = 0x00000000
Initial value for argc=3
Final value for argc=3
Initial value for argc=3
Final value for argc=3
using: FDT
## device tree at 00b87984 ... 00b8915a (len=18391 [0x47D7])
Loading Device Tree to 07788000, end 0778c7d6 ... OK
Initial value for argc=3
Final value for argc=3
image_setup_linux: 1511
fdt_setprop: 300
fdt_setprop_placeholder: 283
fdt_splice_: 108
fdt_splice_struct_: 132
fdt_splice_: 108
image_setup_libfdt: 480
arch_fixup_fdt: 54
fdt_fixup_memory_banks: 440
fdt_setprop: 300
fdt_setprop_placeholder: 283
fdt_resize_property_: 215
fdt_splice_struct_: 132
fdt_splice_: 108
memmove: 547 dest=0x77881b8 src=0x77881b8 size=0x16c4
undefined instruction
pc : [<07fc9534>] lr : [<07fc9537>]
reloc pc : [<03f39534>] lr : [<03f39537>]
sp : 0778db58 ip : fffc3f40 fp : 03f00020
r10: deadbeef r9 : 0778df00 r8 : 07f902a0
r7 : 00ff0000 r6 : 077881b8 r5 : 077881b8 r4 : 000016c4
r3 : 07fc952d r2 : 000016c4 r1 : 077881b8 r0 : 077881b8
Flags: nZCv IRQs off FIQs off Mode SVC_32
Code: 48094908 fd17f000 00310022 f0030028 (0028faf1)
Resetting CPU ...
resetting ...
System is going to reboot ...
Basically, the error path is:
image_setup_linux[2]->image_setup_libfdt[3]->arch_fixup_fdt[4]->
fdt_fixup_memory_banks[5]->fdt_setprop[6]->fdt_setprop_placeholder[7]->
fdt_resize_property_[8]->fdt_splice_struct_[9]->fdt_splice_[10]->
memmove[11]->memcpy
The bootloader build is marked as dirty but I'm only adding files (board
C and header files, board defconfig, etc...) for board support, no
modifications otherwise, it's based on 2018.11.
It's weird to me that it's happening with this SoC because it's based on
ARM926ejs which is widely used I assume. Shouldn't have anyone already
encountered the bug? Or is nobody actually booting a fitImage and had the
luck to never call memcpy with src == dest anywhere else in the code?
Let me know if I can be of any help for debugging.
Thanks,
Quentin
[1] https://elixir.bootlin.com/u-boot/latest/source/lib/string.c#L547
[2] https://elixir.bootlin.com/u-boot/latest/source/common/image.c#L1511
[3] https://elixir.bootlin.com/u-boot/latest/source/common/image-fdt.c#L480
[4] https://elixir.bootlin.com/u-boot/latest/source/arch/arm/lib/bootm-fdt.c#L54
[5] https://elixir.bootlin.com/u-boot/latest/source/common/fdt_support.c#L440
[6] https://elixir.bootlin.com/u-boot/latest/source/scripts/dtc/libfdt/fdt_rw.c#L296
[7] https://elixir.bootlin.com/u-boot/latest/source/scripts/dtc/libfdt/fdt_rw.c#L280
[8] https://elixir.bootlin.com/u-boot/latest/source/scripts/dtc/libfdt/fdt_rw.c#L213
[9] https://elixir.bootlin.com/u-boot/latest/source/scripts/dtc/libfdt/fdt_rw.c#L131
[10] https://elixir.bootlin.com/u-boot/latest/source/scripts/dtc/libfdt/fdt_rw.c#L108
[11] https://elixir.bootlin.com/u-boot/latest/source/lib/string.c#L547
[12] http://git.denx.de/?p=u-boot.git;a=commit;h=cb0eae8cf8aaca76910dee4c7eb536d0814d1bd2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181205/22e9d1af/attachment.sig>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] Issue with memcpy when booting a fitImage on SPEAr600
2018-12-05 10:38 [U-Boot] Issue with memcpy when booting a fitImage on SPEAr600 Quentin Schulz
@ 2018-12-05 11:30 ` Stefan Roese
2018-12-06 10:37 ` Thomas Petazzoni
0 siblings, 1 reply; 7+ messages in thread
From: Stefan Roese @ 2018-12-05 11:30 UTC (permalink / raw)
To: u-boot
Hi Quentin,
On 05.12.18 11:38, Quentin Schulz wrote:
> I'm working on porting a mainline U-Boot on a custom board based on a
> SPEAr600. Right now, I'm facing an issue related with fitImage booting.
>
> Before starting on the fitImage issue, let me state that the zImage and the
> custom DTB concatenated in a uImage have the load address and entry point
> be respectively 0x0200.0000 and 0x0200.0040. The fitImage load and entry
> are both 0x0200.0000. The uImage loaded at the address 0x0080.0000 is
> booted fine by U-Boot, the fitImage at the same address, not.
>
> The datasheet of the SoC states that the external SDRAM is located between
> 0x0000.0000 and 0x3fff.ffff. The size of the fitImage is currently
> 0x0038.9484 bytes, the uImage 0x0038.9007.
>
> The fitImage booting abruptly stops right after "Loading Device Tree to
> 0778a000, end 0778e7d6 ... OK" with the following trace:
> "prefetch abort
> pc : [<f188af44>] lr : [<07fca8c7>]
> reloc pc : [<ed7f8f44>] lr : [<03f388c7>]
> sp : 0778fb78 ip : fffc4c98 fp : 03f00020
> r10: deadbeef r9 : 0778ff00 r8 : 07f922a0
> r7 : 00ff0000 r6 : 000047d7 r5 : 00004700 r4 : 0778a1b8
> r3 : 00000008 r2 : 000016c4 r1 : 0778a1b8 r0 : 0778a1b8
> Flags: nZCv IRQs off FIQs off Mode SVC_32
> Code: data abort
> pc : [<07f931c6>] lr : [<07fb2dd1>]
> reloc pc : [<03f011c6>] lr : [<03f20dd1>]
> sp : 0778fa80 ip : 00000114 fp : 03f00020
> r10: deadbeef r9 : 0778ff00 r8 : 07f922a0
> r7 : 60000000 r6 : 00000698 r5 : f188af44 r4 : fffffffc
> r3 : fffffff0 r2 : 0778ff00 r1 : 00000020 r0 : 00000006
> Flags: NzCv IRQs on FIQs on Mode SVC_32
> Code: 23036be5 439d4818 f885f038 42642404 (595a00a3)
> Resetting CPU ...
>
> resetting ...
> System is going to reboot ..."
>
> I've narrowed down the issue to a memmove being called with destination
> pointer being the source pointer. If I print a debug message before and
> after this memcpy[1], the first debug message is printed but not the
> second one.
> If I add a condition for (dest == src) return dest in the very beginning of
> memmove, the fitImage boots just fine. This test seemed to have been
> removed by commit cb0eae8cf8aaca76910dee4c7eb536d0814d1bd2[12], and by
> reverting this commit, I was able to successfuly boot Linux with a
> fitImage.
>
> Here is the log without debug messages WITHOUT the dest == src check in
> memmove:
>
> U-Boot 2018.11-00007-g0b16f8424a-dirty (Dec 05 2018 - 09:23:31 +0100)-SPEAr
>
> CPU: SPEAr600
> DRAM: 128 MiB
> Flash: 512 KiB
> NAND: 128 MiB
> Loading Environment from Flash... OK
> Net: dwmac.e0800000
> Hit SPACE in 3 seconds to stop autoboot.
> => dhcp; tftp fitImage; bootm
> Speed: 100, full duplex
> BOOTP broadcast 1
> DHCP client bound to address 192.168.0.169 (3 ms)
> Speed: 100, full duplex
> Using dwmac.e0800000 device
> TFTP from server 192.168.0.13; our IP address is 192.168.0.169
> Filename 'fitImage'.
> Load address: 0x800000
> Loading: #################################################################
> #################################################################
> #################################################################
> ##########################################################
> 5.5 MiB/s
> done
> Bytes transferred = 3708036 (389484 hex)
> ## Loading kernel from FIT Image at 00800000 ...
> Using 'conf at default' configuration
> Trying 'kernel at 0' kernel subimage
> Description: Linux
> Type: Kernel Image
> Compression: uncompressed
> Data Start: 0x008000b0
> Data Size: 3700720 Bytes = 3.5 MiB
> Architecture: ARM
> OS: Linux
> Load Address: 0x02000000
> Entry Point: 0x02000000
> Hash algo: sha1
> Hash value: efe249f573647bad3ce87c9c4b244986a90234db
> ## Loading fdt from FIT Image at 00800000 ...
> Using 'conf at default' configuration
> Trying 'fdt at 0' fdt subimage
> Description: Device Tree
> Type: Flat Device Tree
> Compression: uncompressed
> Data Start: 0x00b87984
> Data Size: 6103 Bytes = 6 KiB
> Architecture: ARM
> Hash algo: sha1
> Hash value: 53089fa031e727f094e6bf9ad4e93f4e95b7fba3
> Booting using the fdt blob at 0xb87984
> Loading Kernel Image ... OK
> Loading Device Tree to 0778a000, end 0778e7d6 ... OK
> prefetch abort
> pc : [<f188af44>] lr : [<07fca8c7>]
> reloc pc : [<ed7f8f44>] lr : [<03f388c7>]
> sp : 0778fb78 ip : fffc4c98 fp : 03f00020
> r10: deadbeef r9 : 0778ff00 r8 : 07f922a0
> r7 : 00ff0000 r6 : 000047d7 r5 : 00004700 r4 : 0778a1b8
> r3 : 00000008 r2 : 000016c4 r1 : 0778a1b8 r0 : 0778a1b8
> Flags: nZCv IRQs off FIQs off Mode SVC_32
> Code: data abort
> pc : [<07f931c6>] lr : [<07fb2dd1>]
> reloc pc : [<03f011c6>] lr : [<03f20dd1>]
> sp : 0778fa80 ip : 00000114 fp : 03f00020
> r10: deadbeef r9 : 0778ff00 r8 : 07f922a0
> r7 : 60000000 r6 : 00000698 r5 : f188af44 r4 : fffffffc
> r3 : fffffff0 r2 : 0778ff00 r1 : 00000020 r0 : 00000006
> Flags: NzCv IRQs on FIQs on Mode SVC_32
> Code: 23036be5 439d4818 f885f038 42642404 (595a00a3)
> Resetting CPU ...
>
> resetting ...
> System is going to reboot ...
>
> With debug messages (_DEBUG = 1 and a few printf("%s: %d\n", __func__,
> __LINE__);):
>
> => dhcp; tftp fitImage; bootm
> Trying dwmac.e0800000
> Speed: 100, full duplex
> BOOTP broadcast 1
> DHCPHandler: got packet: (src=67, dst=68, len=300) state: 3
> Filtering pkt = 0
> DHCPHandler: got DHCP packet: (src=67, dst=68, len=300) state: 3
> DHCP: state=SELECTING bp_file: ""
> TRANSITIONING TO REQUESTING STATE
> dhcp_send_request_packet: Sending DHCPREQUEST
> Transmitting DHCPREQUEST packet: len = 342
> DHCPHandler: got packet: (src=67, dst=68, len=300) state: 4
> Filtering pkt = 0
> DHCPHandler: got DHCP packet: (src=67, dst=68, len=300) state: 4
> DHCP State: REQUESTING
> net_boot_file_name:
> DHCP client bound to address 192.168.0.169 (21 ms)
> Initial value for argc=3
> Final value for argc=3
> Initial value for argc=3
> Final value for argc=3
> Initial value for argc=3
> Final value for argc=3
> Initial value for argc=3
> Final value for argc=3
> Initial value for argc=3
> Final value for argc=3
> Initial value for argc=3
> Final value for argc=3
> Trying dwmac.e0800000
> Speed: 100, full duplex
> TFTP blocksize = 1468, timeout = 5000 ms
> Using dwmac.e0800000 device
> TFTP from server 192.168.0.13; our IP address is 192.168.0.169
> Filename 'fitImage'.
> Load address: 0x800000
> Loading: send option "timeout 5"
> Got OACK: timeout 5
> Blocksize ack: 1468, 1468
> #################################################################
> #################################################################
> #################################################################
> ##########################################################
> 5.3 MiB/s
> done
> Bytes transferred = 3708036 (389484 hex)
> Initial value for argc=3
> Final value for argc=3
> Initial value for argc=3
> Final value for argc=3
> Initial value for argc=3
> Final value for argc=3
> Initial value for argc=3
> Final value for argc=3
> Initial value for argc=3
> Final value for argc=3
> Initial value for argc=3
> Final value for argc=3
> Initial value for argc=3
> Final value for argc=3
> ## Current stack ends at 0x0778dd04 * kernel: default image load address = 0x00800000
> ## Loading kernel from FIT Image at 00800000 ...
> No configuration specified, trying default...
> Found default configuration: 'conf at default'
> Using 'conf at default' configuration
> Trying 'kernel at 0' kernel subimage
> Description: Linux
> Type: Kernel Image
> Compression: uncompressed
> Data Start: 0x008000b0
> Data Size: 3700720 Bytes = 3.5 MiB
> Architecture: ARM
> OS: Linux
> Load Address: 0x02000000
> Entry Point: 0x02000000
> Hash node: 'hash at 0'
> Hash algo: sha1
> Hash value: efe249f573647bad3ce87c9c4b244986a90234db
> Hash len: 20
> kernel data at 0x008000b0, len = 0x003877f0 (3700720)
> * ramdisk: using config 'conf at default' from image at 0x00800000
> * ramdisk: no 'ramdisk' in config
> * fdt: using config 'conf at default' from image at 0x00800000
> ## Checking for 'FDT'/'FDT Image' at 00800000
> ## Loading fdt from FIT Image at 00800000 ...
> Using 'conf at default' configuration
> Trying 'fdt at 0' fdt subimage
> Description: Device Tree
> Type: Flat Device Tree
> Compression: uncompressed
> Data Start: 0x00b87984
> Data Size: 6103 Bytes = 6 KiB
> Architecture: ARM
> Can't get 'load' property from FIT 0x00800000, node: offset 3701020, name fdt at 0 (FDT_ERR_NOTFOUND)
> Hash node: 'hash at 0'
> Hash algo: sha1
> Hash value: 53089fa031e727f094e6bf9ad4e93f4e95b7fba3
> Hash len: 20
> Can't get 'load' property from FIT 0x00800000, node: offset 3701020, name fdt at 0 (FDT_ERR_NOTFOUND)
> fit_uname=fdt at 0, fit_uname_config=conf at default
> Booting using the fdt blob at 0xb87984
> of_flat_tree at 0x00b87984 size 0x000017d7
> Initial value for argc=3
> Final value for argc=3
> Loading Kernel Image ... OK
> kernel loaded at 0x02000000, end = 0x023877f0
> ## initrd_high = 0x08000000, copy_to_ram = 1
> ramdisk load start = 0x00000000, ramdisk load end = 0x00000000
> Initial value for argc=3
> Final value for argc=3
> Initial value for argc=3
> Final value for argc=3
> using: FDT
> ## device tree at 00b87984 ... 00b8915a (len=18391 [0x47D7])
> Loading Device Tree to 07788000, end 0778c7d6 ... OK
> Initial value for argc=3
> Final value for argc=3
> image_setup_linux: 1511
> fdt_setprop: 300
> fdt_setprop_placeholder: 283
> fdt_splice_: 108
> fdt_splice_struct_: 132
> fdt_splice_: 108
> image_setup_libfdt: 480
> arch_fixup_fdt: 54
> fdt_fixup_memory_banks: 440
> fdt_setprop: 300
> fdt_setprop_placeholder: 283
> fdt_resize_property_: 215
> fdt_splice_struct_: 132
> fdt_splice_: 108
> memmove: 547 dest=0x77881b8 src=0x77881b8 size=0x16c4
> undefined instruction
> pc : [<07fc9534>] lr : [<07fc9537>]
> reloc pc : [<03f39534>] lr : [<03f39537>]
> sp : 0778db58 ip : fffc3f40 fp : 03f00020
> r10: deadbeef r9 : 0778df00 r8 : 07f902a0
> r7 : 00ff0000 r6 : 077881b8 r5 : 077881b8 r4 : 000016c4
> r3 : 07fc952d r2 : 000016c4 r1 : 077881b8 r0 : 077881b8
> Flags: nZCv IRQs off FIQs off Mode SVC_32
> Code: 48094908 fd17f000 00310022 f0030028 (0028faf1)
> Resetting CPU ...
>
> resetting ...
> System is going to reboot ...
>
> Basically, the error path is:
> image_setup_linux[2]->image_setup_libfdt[3]->arch_fixup_fdt[4]->
> fdt_fixup_memory_banks[5]->fdt_setprop[6]->fdt_setprop_placeholder[7]->
> fdt_resize_property_[8]->fdt_splice_struct_[9]->fdt_splice_[10]->
> memmove[11]->memcpy
>
> The bootloader build is marked as dirty but I'm only adding files (board
> C and header files, board defconfig, etc...) for board support, no
> modifications otherwise, it's based on 2018.11.
>
> It's weird to me that it's happening with this SoC because it's based on
> ARM926ejs which is widely used I assume. Shouldn't have anyone already
> encountered the bug? Or is nobody actually booting a fitImage and had the
> luck to never call memcpy with src == dest anywhere else in the code?
I did some work on the SPEAr600 some years ago and I'm pretty sure that
I never used FIT image at that time. Sorry, but I can't remember any
similar issues like these.
FWIW, I would not oppose to having at least this "src == dest" check
in the code again, since it doesn't really make sense to overwrite
an area with the same value - other than for testing purposes.
Thanks,
Stefan
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] Issue with memcpy when booting a fitImage on SPEAr600
2018-12-05 11:30 ` Stefan Roese
@ 2018-12-06 10:37 ` Thomas Petazzoni
2019-01-07 10:00 ` Quentin Schulz
2019-01-08 0:38 ` Simon Glass
0 siblings, 2 replies; 7+ messages in thread
From: Thomas Petazzoni @ 2018-12-06 10:37 UTC (permalink / raw)
To: u-boot
Hello Stefan,
On Wed, 5 Dec 2018 12:30:57 +0100, Stefan Roese wrote:
> > It's weird to me that it's happening with this SoC because it's based on
> > ARM926ejs which is widely used I assume. Shouldn't have anyone already
> > encountered the bug? Or is nobody actually booting a fitImage and had the
> > luck to never call memcpy with src == dest anywhere else in the code?
>
> I did some work on the SPEAr600 some years ago and I'm pretty sure that
> I never used FIT image at that time. Sorry, but I can't remember any
> similar issues like these.
Well, the issue is in generic ARM code, so whether it's SPEAr600 or any
other ARM SoC should not really matter here.
> FWIW, I would not oppose to having at least this "src == dest" check
> in the code again, since it doesn't really make sense to overwrite
> an area with the same value - other than for testing purposes.
The thing is that the memcpy() that gets called does have this src ==
dest check, as its code starts with:
ENTRY(memcpy)
cmp r0, r1
bxeq lr
which, if my assembly-fu is not bad, means: if first argument == second
argument, then return. But even with this src == dest check within
memcpy() itself, Quentin is seeing memmove() hang when src == dest.
Another thing is that the memmove() code looks like this:
{
char *tmp, *s;
if (dest <= src) {
memcpy(dest, src, count);
However, having dest <= src does not guarantee that the destination and
source areas are non-overlapping. And the normal semantic for memcpy()
is that it doesn't work for overlapping areas. From memcpy(3):
The memcpy() function copies n bytes from memory area src to memory
area dest. The memory areas must not overlap. Use memmove(3) if the
memory areas do overlap.
Of course, this man page documents the memcpy() implementation from the
C library, and perhaps the semantic of U-Boot memcpy is different.
So is it correct to use memcpy() to implement memmove() when the areas
are overlapping ?
Perhaps Simon Glass, who did the change to use memcpy() in
cb0eae8cf8aaca76910dee4c7eb536d0814d1bd2 could comment on that ?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] Issue with memcpy when booting a fitImage on SPEAr600
2018-12-06 10:37 ` Thomas Petazzoni
@ 2019-01-07 10:00 ` Quentin Schulz
2019-01-08 0:38 ` Simon Glass
1 sibling, 0 replies; 7+ messages in thread
From: Quentin Schulz @ 2019-01-07 10:00 UTC (permalink / raw)
To: u-boot
Hi all,
On Thu, Dec 06, 2018 at 11:37:14AM +0100, Thomas Petazzoni wrote:
> Hello Stefan,
>
> On Wed, 5 Dec 2018 12:30:57 +0100, Stefan Roese wrote:
>
> > > It's weird to me that it's happening with this SoC because it's based on
> > > ARM926ejs which is widely used I assume. Shouldn't have anyone already
> > > encountered the bug? Or is nobody actually booting a fitImage and had the
> > > luck to never call memcpy with src == dest anywhere else in the code?
> >
> > I did some work on the SPEAr600 some years ago and I'm pretty sure that
> > I never used FIT image at that time. Sorry, but I can't remember any
> > similar issues like these.
>
> Well, the issue is in generic ARM code, so whether it's SPEAr600 or any
> other ARM SoC should not really matter here.
>
> > FWIW, I would not oppose to having at least this "src == dest" check
> > in the code again, since it doesn't really make sense to overwrite
> > an area with the same value - other than for testing purposes.
>
> The thing is that the memcpy() that gets called does have this src ==
> dest check, as its code starts with:
>
> ENTRY(memcpy)
> cmp r0, r1
> bxeq lr
>
> which, if my assembly-fu is not bad, means: if first argument == second
> argument, then return. But even with this src == dest check within
> memcpy() itself, Quentin is seeing memmove() hang when src == dest.
>
> Another thing is that the memmove() code looks like this:
>
> {
> char *tmp, *s;
>
> if (dest <= src) {
> memcpy(dest, src, count);
>
> However, having dest <= src does not guarantee that the destination and
> source areas are non-overlapping. And the normal semantic for memcpy()
> is that it doesn't work for overlapping areas. From memcpy(3):
>
> The memcpy() function copies n bytes from memory area src to memory
> area dest. The memory areas must not overlap. Use memmove(3) if the
> memory areas do overlap.
>
> Of course, this man page documents the memcpy() implementation from the
> C library, and perhaps the semantic of U-Boot memcpy is different.
>
> So is it correct to use memcpy() to implement memmove() when the areas
> are overlapping ?
>
> Perhaps Simon Glass, who did the change to use memcpy() in
> cb0eae8cf8aaca76910dee4c7eb536d0814d1bd2 could comment on that ?
>
Kindly pinging on the question here.
Best regards,
Quentin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190107/49a3b7a0/attachment.sig>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] Issue with memcpy when booting a fitImage on SPEAr600
2018-12-06 10:37 ` Thomas Petazzoni
2019-01-07 10:00 ` Quentin Schulz
@ 2019-01-08 0:38 ` Simon Glass
2019-01-08 11:03 ` Quentin Schulz
1 sibling, 1 reply; 7+ messages in thread
From: Simon Glass @ 2019-01-08 0:38 UTC (permalink / raw)
To: u-boot
Hi,
On Thu, 6 Dec 2018 at 03:37, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello Stefan,
>
> On Wed, 5 Dec 2018 12:30:57 +0100, Stefan Roese wrote:
>
> > > It's weird to me that it's happening with this SoC because it's based on
> > > ARM926ejs which is widely used I assume. Shouldn't have anyone already
> > > encountered the bug? Or is nobody actually booting a fitImage and had the
> > > luck to never call memcpy with src == dest anywhere else in the code?
> >
> > I did some work on the SPEAr600 some years ago and I'm pretty sure that
> > I never used FIT image at that time. Sorry, but I can't remember any
> > similar issues like these.
>
> Well, the issue is in generic ARM code, so whether it's SPEAr600 or any
> other ARM SoC should not really matter here.
>
> > FWIW, I would not oppose to having at least this "src == dest" check
> > in the code again, since it doesn't really make sense to overwrite
> > an area with the same value - other than for testing purposes.
>
> The thing is that the memcpy() that gets called does have this src ==
> dest check, as its code starts with:
>
> ENTRY(memcpy)
> cmp r0, r1
> bxeq lr
>
> which, if my assembly-fu is not bad, means: if first argument == second
> argument, then return. But even with this src == dest check within
> memcpy() itself, Quentin is seeing memmove() hang when src == dest.
>
> Another thing is that the memmove() code looks like this:
>
> {
> char *tmp, *s;
>
> if (dest <= src) {
> memcpy(dest, src, count);
>
> However, having dest <= src does not guarantee that the destination and
> source areas are non-overlapping. And the normal semantic for memcpy()
> is that it doesn't work for overlapping areas. From memcpy(3):
>
> The memcpy() function copies n bytes from memory area src to memory
> area dest. The memory areas must not overlap. Use memmove(3) if the
> memory areas do overlap.
>
> Of course, this man page documents the memcpy() implementation from the
> C library, and perhaps the semantic of U-Boot memcpy is different.
Yes I suppose it is different.
>
> So is it correct to use memcpy() to implement memmove() when the areas
> are overlapping ?
Strictly speaking, no. I think perhaps my patch should have been more careful.
>
> Perhaps Simon Glass, who did the change to use memcpy() in
> cb0eae8cf8aaca76910dee4c7eb536d0814d1bd2 could comment on that ?
>
That said, I cannot see why the memcpy() fails. How do you explain
that? If you revert my change, does it work?
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
Regards,
Simon
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] Issue with memcpy when booting a fitImage on SPEAr600
2019-01-08 0:38 ` Simon Glass
@ 2019-01-08 11:03 ` Quentin Schulz
2019-01-10 12:56 ` Simon Glass
0 siblings, 1 reply; 7+ messages in thread
From: Quentin Schulz @ 2019-01-08 11:03 UTC (permalink / raw)
To: u-boot
Hi Simon,
On Mon, Jan 07, 2019 at 05:38:19PM -0700, Simon Glass wrote:
> Hi,
>
> On Thu, 6 Dec 2018 at 03:37, Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> wrote:
> >
> > Hello Stefan,
> >
> > On Wed, 5 Dec 2018 12:30:57 +0100, Stefan Roese wrote:
> >
> > > > It's weird to me that it's happening with this SoC because it's based on
> > > > ARM926ejs which is widely used I assume. Shouldn't have anyone already
> > > > encountered the bug? Or is nobody actually booting a fitImage and had the
> > > > luck to never call memcpy with src == dest anywhere else in the code?
> > >
> > > I did some work on the SPEAr600 some years ago and I'm pretty sure that
> > > I never used FIT image at that time. Sorry, but I can't remember any
> > > similar issues like these.
> >
> > Well, the issue is in generic ARM code, so whether it's SPEAr600 or any
> > other ARM SoC should not really matter here.
> >
> > > FWIW, I would not oppose to having at least this "src == dest" check
> > > in the code again, since it doesn't really make sense to overwrite
> > > an area with the same value - other than for testing purposes.
> >
> > The thing is that the memcpy() that gets called does have this src ==
> > dest check, as its code starts with:
> >
> > ENTRY(memcpy)
> > cmp r0, r1
> > bxeq lr
> >
> > which, if my assembly-fu is not bad, means: if first argument == second
> > argument, then return. But even with this src == dest check within
> > memcpy() itself, Quentin is seeing memmove() hang when src == dest.
> >
> > Another thing is that the memmove() code looks like this:
> >
> > {
> > char *tmp, *s;
> >
> > if (dest <= src) {
> > memcpy(dest, src, count);
> >
> > However, having dest <= src does not guarantee that the destination and
> > source areas are non-overlapping. And the normal semantic for memcpy()
> > is that it doesn't work for overlapping areas. From memcpy(3):
> >
> > The memcpy() function copies n bytes from memory area src to memory
> > area dest. The memory areas must not overlap. Use memmove(3) if the
> > memory areas do overlap.
> >
> > Of course, this man page documents the memcpy() implementation from the
> > C library, and perhaps the semantic of U-Boot memcpy is different.
>
> Yes I suppose it is different.
>
> >
> > So is it correct to use memcpy() to implement memmove() when the areas
> > are overlapping ?
>
> Strictly speaking, no. I think perhaps my patch should have been more careful.
>
> >
> > Perhaps Simon Glass, who did the change to use memcpy() in
> > cb0eae8cf8aaca76910dee4c7eb536d0814d1bd2 could comment on that ?
> >
>
> That said, I cannot see why the memcpy() fails. How do you explain
> that? If you revert my change, does it work?
>
Yes.
2018.11 does not work.
2018.11 with your patch reverted works.
That being said, I was working on updating to 2019.01-rc3 and noticed it
was working fine now.
We found out that:
commit ba08afe8377ac72f834f8baad38e9631957b2ea8
Author: Klaus Goger <klaus.goger@theobroma-systems.com>
Date: Thu Apr 26 20:18:10 2018 +0200
arm: Make arch specific memcpy thumb-safe.
The current arch implementation of memcpy cannot be called
from thumb code, because it does not use bx instructions on return.
This patch addresses that. Note, that this patch does not touch
the hot loop of memcpy, so performance is not affected.
Tested on MXS (arm926ejs) with and without thumb-mode enabled.
Signed-off-by: Klaus Goger <klaus.goger@theobroma-systems.com>
Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com>
makes it work on 2018.11 (it was merged for 2019.01-rc1).
Can't understand why all memcpy would work but not some, though.
Best regards,
Quentin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190108/5b9c50cd/attachment.sig>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] Issue with memcpy when booting a fitImage on SPEAr600
2019-01-08 11:03 ` Quentin Schulz
@ 2019-01-10 12:56 ` Simon Glass
0 siblings, 0 replies; 7+ messages in thread
From: Simon Glass @ 2019-01-10 12:56 UTC (permalink / raw)
To: u-boot
Hi Quentin,
On Tue, 8 Jan 2019 at 04:03, Quentin Schulz <quentin.schulz@bootlin.com> wrote:
>
> Hi Simon,
>
> On Mon, Jan 07, 2019 at 05:38:19PM -0700, Simon Glass wrote:
> > Hi,
> >
> > On Thu, 6 Dec 2018 at 03:37, Thomas Petazzoni
> > <thomas.petazzoni@bootlin.com> wrote:
> > >
> > > Hello Stefan,
> > >
> > > On Wed, 5 Dec 2018 12:30:57 +0100, Stefan Roese wrote:
> > >
> > > > > It's weird to me that it's happening with this SoC because it's based on
> > > > > ARM926ejs which is widely used I assume. Shouldn't have anyone already
> > > > > encountered the bug? Or is nobody actually booting a fitImage and had the
> > > > > luck to never call memcpy with src == dest anywhere else in the code?
> > > >
> > > > I did some work on the SPEAr600 some years ago and I'm pretty sure that
> > > > I never used FIT image at that time. Sorry, but I can't remember any
> > > > similar issues like these.
> > >
> > > Well, the issue is in generic ARM code, so whether it's SPEAr600 or any
> > > other ARM SoC should not really matter here.
> > >
> > > > FWIW, I would not oppose to having at least this "src == dest" check
> > > > in the code again, since it doesn't really make sense to overwrite
> > > > an area with the same value - other than for testing purposes.
> > >
> > > The thing is that the memcpy() that gets called does have this src ==
> > > dest check, as its code starts with:
> > >
> > > ENTRY(memcpy)
> > > cmp r0, r1
> > > bxeq lr
> > >
> > > which, if my assembly-fu is not bad, means: if first argument == second
> > > argument, then return. But even with this src == dest check within
> > > memcpy() itself, Quentin is seeing memmove() hang when src == dest.
> > >
> > > Another thing is that the memmove() code looks like this:
> > >
> > > {
> > > char *tmp, *s;
> > >
> > > if (dest <= src) {
> > > memcpy(dest, src, count);
> > >
> > > However, having dest <= src does not guarantee that the destination and
> > > source areas are non-overlapping. And the normal semantic for memcpy()
> > > is that it doesn't work for overlapping areas. From memcpy(3):
> > >
> > > The memcpy() function copies n bytes from memory area src to memory
> > > area dest. The memory areas must not overlap. Use memmove(3) if the
> > > memory areas do overlap.
> > >
> > > Of course, this man page documents the memcpy() implementation from the
> > > C library, and perhaps the semantic of U-Boot memcpy is different.
> >
> > Yes I suppose it is different.
> >
> > >
> > > So is it correct to use memcpy() to implement memmove() when the areas
> > > are overlapping ?
> >
> > Strictly speaking, no. I think perhaps my patch should have been more careful.
> >
> > >
> > > Perhaps Simon Glass, who did the change to use memcpy() in
> > > cb0eae8cf8aaca76910dee4c7eb536d0814d1bd2 could comment on that ?
> > >
> >
> > That said, I cannot see why the memcpy() fails. How do you explain
> > that? If you revert my change, does it work?
> >
>
> Yes.
> 2018.11 does not work.
> 2018.11 with your patch reverted works.
>
> That being said, I was working on updating to 2019.01-rc3 and noticed it
> was working fine now.
>
> We found out that:
> commit ba08afe8377ac72f834f8baad38e9631957b2ea8
> Author: Klaus Goger <klaus.goger@theobroma-systems.com>
> Date: Thu Apr 26 20:18:10 2018 +0200
>
> arm: Make arch specific memcpy thumb-safe.
>
> The current arch implementation of memcpy cannot be called
> from thumb code, because it does not use bx instructions on return.
> This patch addresses that. Note, that this patch does not touch
> the hot loop of memcpy, so performance is not affected.
>
> Tested on MXS (arm926ejs) with and without thumb-mode enabled.
>
> Signed-off-by: Klaus Goger <klaus.goger@theobroma-systems.com>
> Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com>
>
> makes it work on 2018.11 (it was merged for 2019.01-rc1).
OK good that it is fixed.
>
> Can't understand why all memcpy would work but not some, though.
The particular case introduced by my patch shows up this problem more
often, I suppose.
- Simon
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-01-10 12:56 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-12-05 10:38 [U-Boot] Issue with memcpy when booting a fitImage on SPEAr600 Quentin Schulz
2018-12-05 11:30 ` Stefan Roese
2018-12-06 10:37 ` Thomas Petazzoni
2019-01-07 10:00 ` Quentin Schulz
2019-01-08 0:38 ` Simon Glass
2019-01-08 11:03 ` Quentin Schulz
2019-01-10 12:56 ` Simon Glass
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.