<kallisti5[m]>
then telling gdb to position the efi binary at 0xfe6b0000
<kallisti5[m]>
it would be awesome if u-boot said "positioning EFI image at 0xfe6b0000" or something
<kallisti5[m]>
unless y'all know an easier way 😆
jybz has quit [Ping timeout: 256 seconds]
<apritzel>
kallisti5[m]: which address do you mean, exactly? The one that you (or some script) needs to give as a parameter to bootefi? Or the address of one of the internal EFI payloads?
adeepv has joined #u-boot
<xypron>
kallisti5[m]: efi_load_image() is called in multiple places: cmd/bootefi.c:510, lib/efi_loader/efi_bootmgr.c and possibly by client applications.
<xypron>
kallisti5[m]: So the best place for a debug statement would be in efi_load_image().
<xypron>
kallisti5[m]: The UEFI implementation does not yet support the logging infrastruture to be able to select debug output for a single function. See the log command.
<xypron>
kallisti5[m]: telling gdb anything is outside the scope of U-Boot
<xypron>
apritzel: gdb needs the load offset to show the code
jybz has joined #u-boot
<cambrian_invader>
xypron: maybe you could document how to determine the address like how doc/README.arm-relocation describes how to load the symbol file for where U-Boot relocates itself
<kallisti5[m]>
xypron: exactly :-) My first tries were kernel_addr_r, but that didn't do it
<kallisti5[m]>
i've actually run into this issue a few times in the past on various architecture ports. I kinda have a process above to make it work, but it's a lot of work to find the address.
<kallisti5[m]>
xypron: what about a verbosity level along the lines of "show efi image loads"
<kallisti5[m]>
That would indeed be too much for normal operation, but a clear trace statement would at least help there
<xypron>
kallisti5[m]: There is not way to get the address currently unless a crash occurs. In a crash dump you will find all loaded images and the relative address to the image if the EFI binary crashed.
<xypron>
kallisti5[m]: $kernel_addr_r is where you loaded the EFI binary. But U-Boot has to copy the sections according to the section table into fresh memory.
<xypron>
kallisti5[m]: Do we really always need this output? The UEFI SCT for instance is loading dozens of binaries. Writing test message during the runtime of a menu driven program can be very disturbing.
<kallisti5[m]>
Good point. Unsure. Maybe should be only enabled for qemu builds?
<kallisti5[m]>
The value there definitely works, so *really* useful
monstr has quit [Remote host closed the connection]
<apritzel>
kallisti5[m]: for *you*, during the once-in-a-lifetime bringup of a niche OS to a new architecture? :-D
<apritzel>
kallisti5[m]: what about log_debug() instead?
mckoan is now known as mckoan|away
<kallisti5[m]>
log_debug is probably fine too 😅
<kallisti5[m]>
Haiku isn't niche either *flex*
<kallisti5[m]>
Number 4 most poput os behind windows, os x, and Linux 😁
<kallisti5[m]>
s/poput/popular/
<kallisti5[m]>
.. ok maybe #5. Missed BSD
torez has quit [Quit: torez]
sobkas has joined #u-boot
matthias_bgg has quit [Ping timeout: 260 seconds]
<qyx>
marex: it works now, there were multiple issues, I tried also the TF-A approach, but didn't get far.. SPL initializes, uart output works, it can be booted over UART using the STM32 cube programmer
<qyx>
also I moved to official ARM toolchain
<qyx>
one of the problems was if trustzone is enabled, backup domain cannot be unprotected using "normal writes", LSE couldn't be started, so the SPL hung right at the start
<qyx>
so loading u-boot SPL over JTAG will not work until trustzone is disabled with option bytes
<qyx>
which, surprise surprise, I wasn't able to achieve using vendor tools
<qyx>
and I wasn't adventurous enough to manually poke registers using openocd to program them
sobkas has quit [Read error: Connection reset by peer]
<qyx>
so now it works like 0. boot in UART recovery 1. run openocd, 2. run gdb, attach, load symbols, setup breakpoint somewhere near board_init_f, continue the recovery bootrom 3. load SPL over UART using the bootrom (so not using JTAG), 4. run in secure mode using STM32 cube programmer and when it finishes 5. attach serial terminal to the same UART, 6. resume after breakpoint in gdb
sobkas has joined #u-boot
___nick___ has joined #u-boot
<kallisti5[m]>
apritzel: ok. I think I have a better solution
<kallisti5[m]>
how do you get EFI_PRINT (defined' to debug(xxx)) to show up in u-boot?
behanw has joined #u-boot
<xypron>
kabel: EFI_PRINT has debug() inside. So you could put #define DEBUG before #include <common.h>. Or compile with CONFIG_LOG=y, CONFIG_LOG_MAX_LEVEL >= 7 and enable whatever your want to debug with the log command.
<marex>
qyx: if you have USB OTG available, you can start U-Boot SPL and U-Boot via DFU btw
<qyx>
zes that's the plan when TUSB320 becomes available
<marex>
qyx: can't you just connect DN/DP/ID/GND to some USB-A connector in the meantime ?
<kallisti5[m]>
eh. I just did a log_info. Submitted. I think there's a case to EFI_PRINT, i just don't know how that works and it isn't obvious after tracing through the defines
<qyx>
I could but meh
___nick___ has joined #u-boot
<marex>
qyx: it is surprising to see you need to deal with TZ btw
<marex>
iirc it is off by default
<qyx>
it is on by default, BL1 starts in secure mode
<qyx>
at least that's how i understand it
<qyx>
from ST docs
<marex>
BL1 is bootrom ?
<qyx>
yes
<marex>
mrnuke: you still around ?
<marex>
qyx: I really should try booting the Avenger96 via JTAG again