On Wednesday 02 November 2011 14:35:55 Matthias Weisser wrote:
> So, as you can see, dumping to far is not faulting. It just dumps (in
> this case) the first bytes of my local libc.
yes, and i think this is acceptable behavior. take any SoC out there, and if
you do `md` on addresses that aren't
Am 01.11.2011 21:10, schrieb Mike Frysinger:
> On Tuesday 01 November 2011 15:01:55 Matthias Weisser wrote:
>> Am 01.11.2011 19:52, schrieb Mike Frysinger:
>>> On Tuesday 01 November 2011 14:37:24 Matthias Weisser wrote:
I don't know the memory layout strategies for all the Linux/Unix variant
On Tuesday 01 November 2011 15:01:55 Matthias Weisser wrote:
> Am 01.11.2011 19:52, schrieb Mike Frysinger:
> > On Tuesday 01 November 2011 14:37:24 Matthias Weisser wrote:
> >> I don't know the memory layout strategies for all the Linux/Unix variant
> >> out there. But typically text/bss/data is i
Am 01.11.2011 19:52, schrieb Mike Frysinger:
> On Tuesday 01 November 2011 14:37:24 Matthias Weisser wrote:
>> I don't know the memory layout strategies for all the Linux/Unix variant
>> out there. But typically text/bss/data is in the lower address range
>> (some megs above 0) and in the upper ran
On Tuesday 01 November 2011 14:37:24 Matthias Weisser wrote:
> I don't know the memory layout strategies for all the Linux/Unix variant
> out there. But typically text/bss/data is in the lower address range
> (some megs above 0) and in the upper range (right under kernel space)
> there is space use
Am 01.11.2011 17:45, schrieb Simon Glass:
+#define CONFIG_SYS_SDRAM_BASE 0x2000
...
-mem = malloc(size);
+mem = os_mmap((void *)CONFIG_SYS_SDRAM_BASE, CONFIG_SYS_SDRAM_SIZE,
+0, 0, -1, 0);
>>>
>>> mmap() makes no guarantee that
On Tuesday 01 November 2011 12:05:05 Matthias Weisser wrote:
> Am 01.11.2011 16:28, schrieb Mike Frysinger:
> > On Tuesday 01 November 2011 10:07:31 Matthias Weisser wrote:
> >> --- a/arch/sandbox/lib/board.c
> >> +++ b/arch/sandbox/lib/board.c
> >>
> >> +static gd_t gd_mem;
> >
> > i don't think
Hi Matthias,
On Tue, Nov 1, 2011 at 9:05 AM, Matthias Weisser wrote:
> Am 01.11.2011 16:28, schrieb Mike Frysinger:
>> On Tuesday 01 November 2011 10:07:31 Matthias Weisser wrote:
>>> --- a/arch/sandbox/cpu/os.c
>>> +++ b/arch/sandbox/cpu/os.c
>>>
>>> +void *os_mmap(void *addr, size_t length, int
Hi Matthias,
On Tue, Nov 1, 2011 at 7:07 AM, Matthias Weisser wrote:
> Using mmap we can simulate RAM at a specific address. This also
> eliminated the use of system malloc function.
>
> Signed-off-by: Matthias Weisser
Thanks for the patch!
> ---
> arch/sandbox/cpu/os.c | 9 +
>
Am 01.11.2011 16:28, schrieb Mike Frysinger:
> On Tuesday 01 November 2011 10:07:31 Matthias Weisser wrote:
>> --- a/arch/sandbox/cpu/os.c
>> +++ b/arch/sandbox/cpu/os.c
>>
>> +void *os_mmap(void *addr, size_t length, int prot, int flags, int fd,
>> +off_t offset)
>> +{
>> +return m
On Tuesday 01 November 2011 10:07:31 Matthias Weisser wrote:
> --- a/arch/sandbox/cpu/os.c
> +++ b/arch/sandbox/cpu/os.c
>
> +void *os_mmap(void *addr, size_t length, int prot, int flags, int fd,
> + off_t offset)
> +{
> + return mmap((void *)addr, length, PROT_READ | PROT_WRITE,
v
Using mmap we can simulate RAM at a specific address. This also
eliminated the use of system malloc function.
Signed-off-by: Matthias Weisser
---
arch/sandbox/cpu/os.c |9 +
arch/sandbox/lib/board.c | 19 +++
include/configs/sandbox.h |1 +
include/os.h
12 matches
Mail list logo
