From: Matthias Weisser <weisserm@arcor.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] sandbox: Add improved RAM simulation
Date: Tue, 01 Nov 2011 17:05:05 +0100 [thread overview]
Message-ID: <4EB018B1.6080301@arcor.de> (raw)
In-Reply-To: <201111011128.56191.vapier@gentoo.org>
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 mmap((void *)addr, length, PROT_READ | PROT_WRITE,
>
> void cast here is unnecessary
Right.
>> --- a/arch/sandbox/lib/board.c
>> +++ b/arch/sandbox/lib/board.c
>>
>> +static gd_t gd_mem;
>
> i don't think this indirection is necessary. probably can replace the static
> gd_mem with:
> gd_t gd;
AFAIK gd is a pointer. So I think we always need some sort of memory
where the actual structure is stored.
>> +#define CONFIG_SYS_SDRAM_BASE 0x20000000
>> ...
>> - mem = malloc(size);
>> + mem = os_mmap((void *)CONFIG_SYS_SDRAM_BASE, CONFIG_SYS_SDRAM_SIZE,
>> + 0, 0, -1, 0);
>
> mmap() makes no guarantee that the requested address is what you'll get back.
> so there's no point in having this SDRAM_BASE define. punt it and pass in NULL
> instead.
But it works in most cases :-) The point of adding it was that I really
like to have memory aligned on a 256MB boundary or so like it is in most
SOCs. But thats a personal preference. And if it doesn't work you can
still get the address of physical memory from bdinfo.
> also, with Simon's other patch to md to use the remap func, the address of our
> memory backing store doesn't matter.
Well, you are right. But with the posted patch you don't need any remap
function and md/mm/mtest/mw works out of the box.
Regards
Matthias
next prev parent reply other threads:[~2011-11-01 16:05 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-01 14:07 [U-Boot] [PATCH] sandbox: Add improved RAM simulation Matthias Weisser
2011-11-01 15:28 ` Mike Frysinger
2011-11-01 16:05 ` Matthias Weisser [this message]
2011-11-01 16:45 ` Simon Glass
2011-11-01 18:37 ` Matthias Weisser
2011-11-01 18:52 ` Mike Frysinger
2011-11-01 19:01 ` Matthias Weisser
2011-11-01 20:10 ` Mike Frysinger
2011-11-02 18:35 ` Matthias Weisser
2011-11-02 19:20 ` Mike Frysinger
2011-11-01 17:12 ` Mike Frysinger
2011-11-01 16:42 ` Simon Glass
2011-11-02 20:12 ` [U-Boot] [[PATCH V2]] " Matthias Weisser
2011-11-02 20:39 ` Mike Frysinger
2011-11-02 20:56 ` Simon Glass
2011-11-03 17:55 ` Matthias Weisser
2011-11-03 18:02 ` [U-Boot] [PATCH V3] " Matthias Weisser
2011-11-03 18:05 ` Mike Frysinger
2011-11-03 22:55 ` Simon Glass
2011-11-05 10:40 ` [U-Boot] [PATCH V4] " Matthias Weisser
2011-11-05 15:05 ` Simon Glass
2011-11-05 16:47 ` Mike Frysinger
2011-12-02 17:08 ` Mike Frysinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EB018B1.6080301@arcor.de \
--to=weisserm@arcor.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.