[PATCH] board_r: Relocate OF_EMBED if NEEDS_MANUAL_RELOC only

Ajay Kaher akaher at vmware.com
Thu Mar 16 06:51:32 CET 2023



> On 16-Mar-2023, at 1:12 AM, Simon Glass <sjg at chromium.org> wrote:
> 
> !! External Email
> 
> Hi Ajay,
> 
> On Wed, 15 Mar 2023 at 13:24, Ajay Kaher <akaher at vmware.com> wrote:
>> 
>>> On Fri, Sep 09, 2022 at 09:16:18PM +0100,  Pierre-Clément Tosi  wrote:
>>> 
>>>> When the embedded device tree is pointed to by the __dtb_dt_*begin
>>>> symbols, it seems to be covered by the early relocation code and doesn't
>>>> need to be manually patched.
>>>> 
>>>> Cc: Simon Glass <sjg at chromium.org>
>>>> Signed-off-by: Pierre-Clément Tosi <ptosi at google.com>
>>> 
>>> Applied to u-boot/master, thanks!
>> 
>> Getting following error on Rpi3 board and fail to boot with u-boot upstream
>> commit 76f921eb95d5b814f973a263187db509d6f03903:
>> 
>> ERROR: invalid device tree
>> EFI LOAD FAILED: continuing...
>> 
>> As per bdinfo:
>> fdt_blob    = 0x00000000000f4b00
>> 
>> Would like to understand the reasoning of this upstream commit
>> 76f921eb95d5b814f973a263187db509d6f03903 and looking for proper fix for Rpi3.
>> 
>> -Ajay
> 
> Did you bisect to that patch?

Yes, between v2022.07 and v2022.10.

> 
> The proper fix would be to get away from OF_EMBED which is not allowed
> in production boards. Can you post the full console log so I can see
> what happens before the error?

Here are the logs:

U-Boot 2022.10 (Mar 15 2023 - 07:10:46 +0000)

DRAM:  948 MiB
RPI 3 Model B (0xa02082)
Core:  66 devices, 14 uclasses, devicetree: embed
MMC:   mmc at 7e202000: 0, mmc at 7e300000: 1
Loading Environment from FAT... OK
In:    serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
Bus usb at 7e980000: USB DWC2
scanning bus usb at 7e980000 for devices... 4 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
Saving Environment to FAT... OK
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Card did not respond to voltage select! : -110
No EFI system partition
BootOrder not defined
EFI boot manager: Cannot load any image
1146880 bytes read in 50 ms (21.9 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
ERROR: invalid device tree
EFI LOAD FAILED: continuing...
Card did not respond to voltage select! : -110

Device 0: unknown device
Waiting for Ethernet connection... unable to connect.
missing environment variable: pxeuuid
Retrieving file: pxelinux.cfg/01-b8-27-eb-4d-9e-e9
Waiting for Ethernet connection... unable to connect.
Retrieving file: pxelinux.cfg/00000000
Waiting for Ethernet connection... unable to connect.
Retrieving file: pxelinux.cfg/0000000
Waiting for Ethernet connection... unable to connect.
Retrieving file: pxelinux.cfg/000000
Waiting for Ethernet connection... unable to connect.
Retrieving file: pxelinux.cfg/00000
Waiting for Ethernet connection... unable to connect.
Retrieving file: pxelinux.cfg/0000
Waiting for Ethernet connection... unable to connect.
Retrieving file: pxelinux.cfg/000
Waiting for Ethernet connection... unable to connect.
Retrieving file: pxelinux.cfg/00
Waiting for Ethernet connection... unable to connect.
Retrieving file: pxelinux.cfg/0
Waiting for Ethernet connection... unable to connect.
Retrieving file: pxelinux.cfg/default-arm-bcm283x-rpi
Waiting for Ethernet connection... unable to connect.
Retrieving file: pxelinux.cfg/default-arm-bcm283x
Waiting for Ethernet connection... unable to connect.
Retrieving file: pxelinux.cfg/default-arm
Waiting for Ethernet connection... unable to connect.
Retrieving file: pxelinux.cfg/default
Waiting for Ethernet connection... unable to connect.
Config file not found
Waiting for Ethernet connection... unable to connect.
Waiting for Ethernet connection... unable to connect.
U-Boot>


> The commit does not look correct to me. This is nothing to do with the
> horrible NEEDS_MANUAL_RELOC which is only needed on m68k I think now.
> It is because we have moved the executable containing the DT. The DT
> in the old position may be overwritten by loading something.

Seems like your observations are correct and may be need to revert
76f921eb95d5b814f973a263187db509d6f03903. And handle m68k
case separately.

Thanks Simon for your response.

- Ajay



More information about the U-Boot mailing list