Hi Tom and Heinrich,
On Thu, 19 Sept 2024 at 13:48, Tom Rini trini@konsulko.com wrote:
On Thu, Sep 19, 2024 at 04:13:02PM +0200, Simon Glass wrote:
Hi,
On Sun, 15 Sept 2024 at 20:28, Tom Rini trini@konsulko.com wrote:
On Sun, Sep 15, 2024 at 07:57:19PM +0200, Heinrich Schuchardt wrote:
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 trini@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.connolly@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.
Many commands fall into that category.
Yes, there is a trade-off to be made.
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.
Sounds like a good idea to me.
I would like to see this series land in U-Boot as I believe it is very helpful for seeing what the table looks like. Dumping to a file which then needs to be decoded is not as convenient. We may also find it easier to add tests for SMBIOS.
And I don't look forward to the seemingly inevitable parsing bug means CVE assigned. If the command is broadly enabled then "everyone" gets to worry about it, and if it's narrowly enabled have we really gotten better than the options of dump to file, parse elsewhere or load a parser and run it?
Currently the code for parsing the SMBIOS tables really helps debugging
before an external parser is ready for use. I think we can keep it until a dump tool is in the project, at that time we can just simply disable the CMD_SMBIOS config for the concern of code size.
Regards, Raymond