From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Thu, 18 Oct 2018 21:25:47 -0600 Subject: [U-Boot] [PATCH v11 3/6] sandbox: smbios: Update to support sandbox In-Reply-To: References: <20181015141750.56480-1-sjg@chromium.org> <20181015141750.56480-4-sjg@chromium.org> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Alex, On 16 October 2018 at 06:55, Alexander Graf 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 > > 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