[U-Boot] [PATCH 5/8] arm: Add boottime support for the ARM architecture

[Lee Jones]

Let's try to move this forward.

> And it has to be implemented using a completely new method, because
> all existing ones are crap or not the "correct way" to do it.  We've
> been there before.

> I accept this, but please also accept that I ask you not to add 
> code that duplicates existing functionality to U-Boot.

> But as much as you "don't want two different mechanisms for storing 
> bootloader and kernel entries" I don't want that either.  And that is
> the reason to reject these patches, asking for a change of the
> implementation to use the already existing methods.

Okay, to summarise so far:

1. Bootloader and kernel mechanisms should be the same

So putting bootloader tracepoints in the bootlog and the kernel's
in an internal data structure is not acceptable, as it would add
too much extra overhead to link them together and parse.

2. The kernel bootlog is not the correct place for tracepoints

If we were to adhere to point No1 and bootloader & kernel
entries would be placed into the bootlog; no self respecting
kernel engineer/maintainer will allow 100's of spurious
tracepoint entries in the kernel log, regardless of log level.
No other tracing mechanism does this and there's a good reason
for that.

3. Existing mechanisms to be used if they exist and are suitable

I am more than happy to use anything that already exists, but I
haven't seen anything yet. I can see how we could use the
show_boot_progress() call-back, but we'd have to use #defines
to store anything useful with regards to unique and readable 
identifiers. Also, we'd have to be careful to use it in such a
what that it wouldn't trash any architecture's implementation,
which would probably mean calling boottime_tag from within them.

As for passing the information to the kernel; munging it as
text and sticking it in __log_buf is out of the question, ATAGs
are architecture specific and are leaving us and DT is designed
to carry hardware information. So where does that leave us?

Actually, putting it in DT has lots of advantages. 1) DT works
cross-architecture and cross-platform, so your architecture
independent box is inherently ticked 2) DT already carries
non-hardware specific information such as the kernel cmdline.
I don't see how adding <10 (but would more likely to be 2-3)
tracepoint entries would completely break convention. We can
either get the kernel driver to scrub the entries if you'd be
that offended by keeping them in.

Let's be pragmatic about this. I'm happy to make changes to
the current implementation and code-up any sensible solutions
to this issue. It's a real problem that has gained a great
deal of interest amongst my kernel engineer peers. So much
so that people have stopped to ask me about it at kernel
conferences. Let's find a nice, long lasting way to solve it.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog