Hi Alex, On 12 June 2018 at 08:05, Alexander Graf <ag...@suse.de> wrote: > > > On 12.06.18 15:48, Simon Glass wrote: >> Hi Alex, >> >> On 12 June 2018 at 02:12, Alexander Graf <ag...@suse.de> wrote: >>> >>> >>> On 12.06.18 07:26, 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> >>>> --- >>>> >>>> Changes in v5: None >>>> Changes in v4: None >>>> Changes in v3: >>>> - Drop incorrect map_sysmem() in write_smbios_table() >>>> >>>> Changes in v2: None >>>> >>>> lib/smbios.c | 32 ++++++++++++++++++++++++-------- >>>> 1 file changed, 24 insertions(+), 8 deletions(-) >>>> >>>> diff --git a/lib/smbios.c b/lib/smbios.c >>>> index df3d26b071..fc3dabcbc1 100644 >>>> --- a/lib/smbios.c >>>> +++ b/lib/smbios.c >>>> @@ -6,6 +6,7 @@ >>>> */ >>>> >>>> #include <common.h> >>>> +#include <mapmem.h> >>>> #include <smbios.h> >>>> #include <tables_csum.h> >>>> #include <version.h> >>>> @@ -72,9 +73,10 @@ static int smbios_string_table_len(char *start) >>>> >>>> static int smbios_write_type0(ulong *current, int handle) >>> >>> Please change the function argument to indicate that we're no longer >>> dealing with pointers, but instead with "u-boot physical addresses". >>> >>> Same for the other functions obviously :). >> >> That actually hasn't changed. We are currently passing a U-Boot >> address around and it is a ulong, as it normally is in U-Boot. What >> has changed is that sandbox does not have a direct mapping between >> U-Boot address and memory address, so we have to do the mapping. >> >> While it is try that the ulong can be converted to a pointer with a >> cast normally, this is not possible with sandbox, so things that need >> to convert the ulong to a pointer need to do a conversion. > > Oh, I missed the * in *current. So it already does get passed as a > number which then is cast back into a pointer. > > That however means that the smbios tables are now u-boot address space > relative. So anything that tries to read them from within EFI context > will explode.
Aren't these tables for the Linux kernel? If so, then this doesn't matter. But if EFI reads them, we are in trouble. We cannot always put a 64-bit address into a 32-bit word. I suppose we could support it on 32-bit sandbox, but not a lot of people use that. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot