Hi Alex, On 22 October 2018 at 12:32, Alexander Graf <ag...@suse.de> wrote: > > > > > Am 22.10.2018 um 18:49 schrieb Simon Glass <s...@chromium.org>: > > > > Hi Alex, > > > >> On 19 October 2018 at 01:27, Alexander Graf <ag...@suse.de> wrote: > >> > >> > >>> On 19.10.18 05:25, Simon Glass wrote: > >>> Hi Alex, > >>> > >>>> On 16 October 2018 at 06:55, Alexander Graf <ag...@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 <s...@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. > >> > >> Why not? We can boot the UEFI Shell today - and that can use the "address". > > > > OK, so UEFI shell uses the SMBIOS tables? I didn't know that. > > There is a command to print the contents of smbios tables - and that one does > use them :).
OK, but it should work without any trouble due to my patch in dm/next. This seems like another reason to make sandbox use 32-bit pointers where possible. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot