On 8/26/24 21:59, Tom Rini wrote:
On Mon, Aug 26, 2024 at 01:12:16PM -0600, Simon Glass wrote:
Hi Tom,
On Mon, 26 Aug 2024 at 12:23, Tom Rini <tr...@konsulko.com> wrote:
On Mon, Aug 26, 2024 at 11:58:54AM -0600, Simon Glass wrote:
Hi Caleb,
On Mon, 19 Aug 2024 at 17:03, Caleb Connolly <caleb.conno...@linaro.org> wrote:
Hi Simon,
As a general comment, this is adding a load of code which is used by a
lot of platforms. As more and more aarch64 platforms are created, this
data grows. Why not use the devicetree for this hardware information?
That is what it is for.
This data does not belong in devicetree, the various system registers
exist to describe this information... Putting it in DT would be
duplicating it.
I am not wanting to duplicate info which can be read from system registers.
Using DT for this would additionally require having bindings accepted
upstream and for all SoCs to add them. To what end?
To get the correct information in there. How are boards supposed to
add SMBIOS info? Do we end up creating a whole infra in U-Boot just
for the driver to read it out? It just doesn't make any sense to me...
Let's put hardware info in the DT where it belongs.
I'm a little confused here because of some older threads on this overall
topic. Part of the issue here is that in user space, "everyone" has
SMBIOS-based tooling today, and wants to have that work, rather than
inventing new tooling or modify existing tooling. And you were concerned
I thought that we had tied SMBIOS too much to EFI being present when
indeed it should be possible to pass the location along to the OS
without EFI, but at the time Linux at least only supported that notion
on MIPS I think?
That is a whole other concern I have, that we are perpetuating this
legacy format which is a real pain to work with, when we already have
devicetree. Let's leave that issue aside as I have not detected any
interest in solving that problem, or even any agreement that it is a
problem.
OK, yes, lets set that aside.
But for this particular series, I am just wanting to get the correct
info in there. Having the CPU-detection code provide an opinion about
what type of chassis is in use (just to take an example, the patch
pieces I highlighted have been dropped from the email I am replying
to) just seems a bit daft to me. Only the board vendor would know that
info.
Yes, I agree the detection should be reworked a good bit as some
information will be board design specific while others SoC specific. And
we should avoid adding many unused at run time strings to all platforms
that enable this too (looking at all the CPU vendor related stuff).
I doubt on productive machines there will be much use of U-Boot's smbios
command use. It is more a developer tool.
For reading all the details we currently have
lib/efi_loader/smbiosdump.efi which can dump the SMBIOS table to a file
that dmidecode can read.
Maybe instead of adding more and more decoding logic into the U-Boot
smbios command we should add an smbios sub-command to dump to a file.
This would be less of a hassle than running an EFI program for the same
purpose.
Best regards
Heinrich
