[U-Boot] [PATCH v9 12/18] sandbox: Enhance map_to_sysmem() to handle foreign pointers

Alexander Graf agraf at suse.de
Sat Sep 15 08:16:45 UTC 2018



On 14.09.18 17:46, Simon Glass wrote:
> Hi Alex,
> 
> On 26 August 2018 at 19:11, Alexander Graf <agraf at suse.de> wrote:
>>
>>
>> On 08.08.18 11:54, Simon Glass wrote:
>>> At present map_sysmem() maps an address into the sandbox RAM buffer,
>>> return a pointer, while map_to_sysmem() goes the other way.
>>>
>>> The mapping is currently just 1:1 since a case was not found where a more
>>> flexible mapping was needed. PCI does have a separate and more complex
>>> mapping, but uses its own mechanism.
>>>
>>> However this arrange cannot handle one important case, which is where a
>>> test declares a stack variable and passes a pointer to it into a U-Boot
>>> function which uses map_to_sysmem() to turn it into a address. Since the
>>> pointer is not inside emulated DRAM, this will fail.
>>>
>>> Add a mapping feature which can handle any such pointer, mapping it to a
>>> simple tag value which can be passed around in U-Boot as an address.
>>>
>>> Signed-off-by: Simon Glass <sjg at chromium.org>
>>
>> I think you are aware that this logic will fall apart spectacularly if
>> any arithmetic operation happens on the virtual (U-Boot) address, right?
>> So simple code like
>>
>>   readl(vaddr + 1);
>>
>> will just fail (hopefully) or (more likely) return a completely
>> incorrect value.
>>
>> I assume this is intentional, but shouldn't the tag increment be
>> something slightly larger then?
> 
> What do you expect readl() to do on sandbox? At present it is just a
> no-op. I suppose we could support memory-mapped I/O but it has not
> been attempted yet.

It was really just meant as an arbitrary example of something where you
assume "address + 1" == "pointer(address) + 1".


Alex


More information about the U-Boot mailing list