All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Glass <sjg@chromium.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v11 3/6] sandbox: smbios: Update to support sandbox
Date: Thu, 18 Oct 2018 21:25:47 -0600	[thread overview]
Message-ID: <CAPnjgZ3pBUT4GTU10VWxnWMO1vzpB9hcAC4RxTUbN45OwKXcqw@mail.gmail.com> (raw)
In-Reply-To: <d592d968-f815-1e5b-f651-049d5c35ece3@suse.de>

Hi Alex,

On 16 October 2018 at 06:55, Alexander Graf <agraf@suse.de> wrote:
>
>
> On 15.10.18 16:17, Simon Glass wrote:
>> At present this code casts addresses to pointers so cannot be used with
>> sandbox. Update it to use mapmem instead.
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>
> Unfortunately this won't work. The SMBIOS2 structure itself contains a
> physical pointer to the target address (which in EFI lands really has to
> be linear physical pointer). This pointer gets set based on "addr" in
> write_smbios_table():
>
>         tables = addr;
>         [...]
>         se->struct_table_address = tables;

Does that actually matter? We will never actually boot anything on
sandbox that will use that address.

Also sandbox addresses are always <4GB (they start@0).

>
> So I think the only thing we can do for now is to just graciously fail
> SMBIOS generation (maybe only on sandbox?) when we can not find a
> pointer that is < U32_MAX.
>
> The shortcoming above was fixed with SMBIOS3, so the "good" path forward
> would be to add SMBIOS3 support and just not rely on 32bit pointers at
> all. I don't remember OTOH if SMBIOS3 stores offsets or 64bit pointers
> to the tables. Depending on that we can either use your maps or we can't.

Maybe I prefer device tree as it avoid this sort of thing :-)

Regards,
Simon

  reply	other threads:[~2018-10-19  3:25 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-15 14:17 [U-Boot] [PATCH v11 0/6] efi_loader: Code refactoring and improvement Simon Glass
2018-10-15 14:17 ` [U-Boot] [PATCH v11 1/6] sandbox: Put CPUs under a cpu-bus node Simon Glass
2018-10-15 17:05   ` Heinrich Schuchardt
2018-10-15 14:17 ` [U-Boot] [PATCH v11 2/6] efi_loader: Drop setup_ok Simon Glass
2018-10-15 17:16   ` Heinrich Schuchardt
2018-10-19  3:25     ` Simon Glass
2018-10-19  5:53       ` Heinrich Schuchardt
2018-10-15 14:17 ` [U-Boot] [PATCH v11 3/6] sandbox: smbios: Update to support sandbox Simon Glass
2018-10-16 12:55   ` Alexander Graf
2018-10-19  3:25     ` Simon Glass [this message]
2018-10-19  7:27       ` Alexander Graf
2018-10-22 17:49         ` Simon Glass
2018-10-22 18:32           ` Alexander Graf
2018-11-04 18:39             ` Simon Glass
2018-10-15 14:17 ` [U-Boot] [PATCH v11 4/6] efi: Split out test init/uninit into functions Simon Glass
2018-10-15 17:34   ` Heinrich Schuchardt
2018-11-04 18:46     ` Simon Glass
2018-10-15 14:17 ` [U-Boot] [PATCH v11 5/6] efi: Create a function to set up for running EFI code Simon Glass
2018-10-15 14:17 ` [U-Boot] [PATCH v11 6/6] efi: Rename bootefi_test_finish() to bootefi_run_finish() Simon Glass

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPnjgZ3pBUT4GTU10VWxnWMO1vzpB9hcAC4RxTUbN45OwKXcqw@mail.gmail.com \
    --to=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.