On 13.11.18 22:45, Heinrich Schuchardt wrote: > On 11/13/18 10:35 PM, Simon Glass wrote: >> Hi, >> >> On 13 November 2018 at 12:39, Alexander Graf <ag...@suse.de> wrote: >>> >>> >>> On 12.11.18 18:55, Heinrich Schuchardt wrote: >>>> On the sandbox the memory addresses in the device tree refer to the virtual >>>> address space of the sandbox. This implies that the memory reservations for >>>> the fdt also have to be converted to this address space. >>>> >>>> Signed-off-by: Heinrich Schuchardt <xypron.g...@gmx.de> >>>> --- >>>> v2: >>>> no change >>>> --- >>>> common/fdt_support.c | 7 +++++-- >>>> 1 file changed, 5 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/common/fdt_support.c b/common/fdt_support.c >>>> index e6daa67990d..ec6af92dbba 100644 >>>> --- a/common/fdt_support.c >>>> +++ b/common/fdt_support.c >>>> @@ -7,6 +7,7 @@ >>>> */ >>>> >>>> #include <common.h> >>>> +#include <mapmem.h> >>>> #include <stdio_dev.h> >>>> #include <linux/ctype.h> >>>> #include <linux/types.h> >>>> @@ -240,7 +241,8 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong >>>> initrd_end) >>>> } >>>> } >>>> >>>> - err = fdt_add_mem_rsv(fdt, initrd_start, initrd_end - initrd_start); >>>> + err = fdt_add_mem_rsv((void *)(uintptr_t)map_to_sysmem(fdt), >>> >>> This sounds like an API bug to me. Either fdt_add_mem_rsv() takes an >>> address (ulong) or a pointer (void*). But taking void * while expecting >>> an address to get passed in sounds pretty broken to me. >> >> Yes that can't be right. If it, we need to change the first param of >> fdt_initrd() to a ulong and adjust. > > Why? The first parameter is where address where the fdt lives. For any > board but sandbox the current API is fine. And the sandbox is not the > world but the playground. > >> >> We should use addresses in U-Boot code, not pointers. >> We should use addresses in U-Boot code, not pointers. >> We should use addresses in U-Boot code, not pointers. > > Your repetitive poetry does not catch. A pointer holds an address in > memory. Usage of different C types for the same content is just a way to > confuse ones mind.
The way I managed to wrap my head around Simon's "address" and "pointer" logic is: U-Boot address is what you would usually consider "physical address" Pointer is what you would usually consider "virtual address" So a pointer is what you use to access memory from code. An address is the location that an arbitrary virt/phys conversion mechanism points to. I think the best analogy is Linux's PAE code. When you run on a 32bit system, Linux can not fit more than 2 (or 3) GB of RAM into its linear map. But hardware supports page table entries that point to addresses >4GB. So Linux has something called HIGHMEM which allows you to dynamically add/remove page table entries for regions that are in "high" memory. This is similar in concept. You have a physical address (U-Boot address in Simon's speak), but you can't access it, because it may not be mapped yet. To actually have a mapping, you have to go through the mapping function. The framework he borrowed from (map_sysmem and friends) was actually created for exactly the PAE use case. So it is not a complete waste of time to support it :). Alex _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
