HI Ilias,
On Fri, 1 Nov 2024 at 05:32, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
On Thu, 31 Oct 2024 at 20:02, Simon Glass sjg@chromium.org wrote:
Hi Ilias,
On Tue, 29 Oct 2024 at 19:32, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Tue, 29 Oct 2024 at 17:45, Simon Glass sjg@chromium.org wrote:
Hi Ilias,
On Tue, 29 Oct 2024 at 10:58, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
On Mon, 28 Oct 2024 at 14:48, Simon Glass sjg@chromium.org wrote:
It is a bit of a pain to log EFI boot-services calls at present. The output goes to the console so cannot easily be inspected later. Also it would be useful to be able to store the log and review it later, perhaps after something has gone wrong.
This series makes a start on implementing a log-to-buffer feature. It provides a simple 'efidebug log' command to inspect the buffer. For now, only memory allocations are logged.
Why is this problem specific to EFI and no U-Boot in general? Do we have a similar machinery for malloc()?
Mostly because an app can make EFI calls and we want to know what they are, e.g. to debug them and figure out what might be wrong when something doesn't boot.
EFI_PRINT() has been proven pretty useful for this. I don't personally see the point of adding ~1300 lines of code to replace a print. What would make more sense is teach EFI_PRINT to log errors in a buffer.
Is that a NAK? Please be clear if you are reviewing the code or just rejecting the whole idea.
For the idea, no. But I don't think what's implemented here is what we want.
To track what EFI services are called, we already have EFI_ENTRY and EFI_EXIT. Why don't we instead, add a logging service (and we already have ftrace iirc) and plug it in the macros above? That would make more sense not to mention way less code.
I am wanting to programmatically log and manage what EFI_LOADER does, so that bootstd can present a high-level view of what is going on, e.g. which protocols are used, how much memory is allocated and where. So this is not just about logging text output.
I am hoping to expand this into a debugging tool for figuring out how to boot Windows and perhaps logging detailed information when things go wrong, for later analysis. It might seem like overkill, but we will see.
I've managed to run windows installers on QEMU & U-Boot. It's been more than a year but windows boots and calls EBS(). The something fails down the road. I think I have a branch somewhere with the changes needed, I'll send it over if I find it.
Did you find it?
Regards, Simon