[PATCH 00/15] efi_loader: Add support for logging to a buffer
Ilias Apalodimas
ilias.apalodimas at linaro.org
Fri Nov 1 12:31:43 CET 2024
Hi Simon,
On Thu, 31 Oct 2024 at 20:02, Simon Glass <sjg at chromium.org> wrote:
>
> Hi Ilias,
>
> On Tue, 29 Oct 2024 at 19:32, Ilias Apalodimas
> <ilias.apalodimas at linaro.org> wrote:
> >
> > On Tue, 29 Oct 2024 at 17:45, Simon Glass <sjg at chromium.org> wrote:
> > >
> > > Hi Ilias,
> > >
> > > On Tue, 29 Oct 2024 at 10:58, Ilias Apalodimas
> > > <ilias.apalodimas at linaro.org> wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Mon, 28 Oct 2024 at 14:48, Simon Glass <sjg at 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 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.
/Ilias
>
> Regards,
> Simon
More information about the U-Boot
mailing list