sandbox: Add improved RAM simulation

PATCH New Matthias Weisser 3 participants 23 messages Nov 1, 2011 – Dec 2, 2011

lore

Share & tools

lore

Matthias Weisser

author

2011-11-01 14:07 UTC #0 lore raw

PATCH 1/1 sandbox: Add improved RAM simulation

Using mmap we can simulate RAM at a specific address. This also eliminated the use of system malloc function.

Signed-off-by Matthias Weisser <[email protected]>

---
 arch/sandbox/cpu/os.c     |    9 +++++++++
 arch/sandbox/lib/board.c  |   19 +++++++++++--------
 include/configs/sandbox.h |    1 +
 include/os.h              |   13 +++++++++++++
 4 files changed, 34 insertions(+), 8 deletions(-)

arch/sandbox/cpu/os.c +9 -0

index 6c175d4..cd2fb05 100644
@@ -24,6 +24,7 @@
 #include <unistd.h>
 #include <sys/types.h>
 #include <sys/stat.h>
+#include <sys/mman.h>
 
 #include <os.h>

@@ -53,3 +54,11 @@ void os_exit(int exit_code)
 {
 	exit(exit_code);
 }
+
+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,
+			MAP_PRIVATE | MAP_ANONYMOUS,
+			-1, 0);
+}

arch/sandbox/lib/board.c +11 -8

index ae5a517..0912a8b 100644
@@ -45,8 +45,12 @@
 #include <version.h>
 #include <serial.h>
 
+#include <os.h>
+
 DECLARE_GLOBAL_DATA_PTR;
 
+static gd_t gd_mem;
+
 /************************************************************************
  * Init Utilities							*
  ************************************************************************

@@ -112,7 +116,7 @@ typedef int (init_fnc_t) (void);
 
 void __dram_init_banksize(void)
 {
-	gd->bd->bi_dram[0].start = 0;
+	gd->bd->bi_dram[0].start = (ulong) gd->ram_buf;
 	gd->bd->bi_dram[0].size =  gd->ram_size;
 }

@@ -147,7 +151,7 @@ void board_init_f(ulong bootflag)
 	uchar *mem;
 	unsigned long addr_sp, addr, size;
 
-	gd = malloc(sizeof(gd_t));
+	gd = &gd_mem;
 	assert(gd);
 
 	memset((void *)gd, 0, sizeof(gd_t));

@@ -158,7 +162,8 @@ void board_init_f(ulong bootflag)
 	}
 
 	size = CONFIG_SYS_SDRAM_SIZE;
-	mem = malloc(size);
+	mem = os_mmap((void *)CONFIG_SYS_SDRAM_BASE, CONFIG_SYS_SDRAM_SIZE,
+			0, 0, -1, 0);
 	assert(mem);
 	gd->ram_buf = mem;
 	addr = (ulong)(mem + size);

@@ -214,11 +219,9 @@ void board_init_r(gd_t *id, ulong dest_addr)
 	post_output_backlog();
 #endif
 
-#if 0 /* Sandbox uses system malloc for now */
-	/* The Malloc area is immediately below the monitor copy in DRAM */
-	malloc_start = dest_addr - TOTAL_MALLOC_LEN;
-	mem_malloc_init(malloc_start, TOTAL_MALLOC_LEN);
-#endif
+	/* The Malloc area is at the top of simulated DRAM */
+	mem_malloc_init(gd->ram_buf + gd->ram_size - TOTAL_MALLOC_LEN,
+			TOTAL_MALLOC_LEN);
 
 	/* initialize environment */
 	env_relocate();

include/configs/sandbox.h +1 -0

index 0230256..ce4675d 100644
@@ -60,6 +60,7 @@
 #define CONFIG_PHYS_64BIT
 
 /* Size of our emulated memory */
+#define CONFIG_SYS_SDRAM_BASE		0x20000000
 #define CONFIG_SYS_SDRAM_SIZE		(128 << 20)
 
 #define CONFIG_BAUDRATE			115200

include/os.h +13 -0

index 3ea6d2d..ed4cd4f 100644
@@ -71,3 +71,16 @@ int os_close(int fd);
  * @param exit_code	exit code for U-Boot
  */
 void os_exit(int exit_code);
+
+/**
+ * Access to the OS mmap() system call. Currently all
+ *
+ * \param addr		Prefered address of the mapping
+ * \param length	Length in bytes
+ * \param prot		Ignored. Always PROT_READ | PROT_WRITE
+ * \param flags		Ignored. Always MAP_PRIVATE | MAP_ANONYMOUS
+ * \param fd		Ignored. Always -1
+ * \param offset	Ignored. Always 0
+ */
+void *os_mmap(void *addr, size_t length, int prot, int flags, int fd,
+		off_t offset);

Signature · 1 line

1.7.4.1

Mike Frysinger

2011-11-01 15:28 UTC #1 lore raw

PATCH 1/1 sandbox: Add improved RAM simulation

arch/sandbox/cpu/os.c void os_exit(int exit_code) · line 61

Quoted 7 lines · On Tuesday 01 November 2011 10:07:31 Matthias Weisser wrote:

arch/sandbox/cpu/os.c +4 -0

 
+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

arch/sandbox/lib/board.c line 52

Quoted 4 lines

arch/sandbox/lib/board.c +1 -0
 
+static gd_t gd_mem;

i don't think this indirection is necessary. probably can replace the static gd_mem with:

	gd_t gd;

arch/sandbox/lib/board.c void board_init_f(ulong bootflag) · line 166

Quoted 5 lines

arch/sandbox/lib/board.c +3 -1

+#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.

also, with Simon's other patch to md to use the remap func, the address of our memory backing store doesn't matter.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111101/4c9c0588/attachment.pgp

Matthias Weisser

author

2011-11-01 16:05 UTC #2 lore raw

PATCH 1/1 sandbox: Add improved RAM simulation

Am 01.11.2011 16:28, schrieb Mike Frysinger:

Quoted 10 lines · On Tuesday 01 November 2011 10:07:31 Matthias Weisser wrote:

arch/sandbox/cpu/os.c void os_exit(int exit_code) · line 61
Quoted 7 lines
arch/sandbox/cpu/os.c +4 -0
 
+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.

Quoted 8 lines

arch/sandbox/lib/board.c line 52
Quoted 4 lines
arch/sandbox/lib/board.c +1 -0
 
+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.

Quoted 9 lines

arch/sandbox/lib/board.c void board_init_f(ulong bootflag) · line 166
Quoted 5 lines
arch/sandbox/lib/board.c +3 -1
+#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.

Quoted 2 lines

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

Simon Glass

2011-11-01 16:45 UTC #3 lore raw

PATCH 1/1 sandbox: Add improved RAM simulation

Hi Matthias,

Quoted 17 lines · Matthias Weisser

Am 01.11.2011 16:28, schrieb Mike Frysinger:
Quoted 10 lines · On Tuesday 01 November 2011 10:07:31 Matthias Weisser wrote:
arch/sandbox/cpu/os.c
Quoted 7 lines
arch/sandbox/cpu/os.c +4 -0
 
+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.
Quoted 3 lines
Quoted 3 lines
arch/sandbox/lib/board.c +0 -0

Quoted 8 lines

Quoted 5 lines
Quoted 1 line
+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.

Yes I think that's right.

Quoted 7 lines

Quoted 7 lines
Quoted 6 lines
+#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);

Quoted 8 lines

Quoted 3 lines
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.

Most?

Quoted 6 lines

Quoted 3 lines
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.

This is interesting. What is the test purpose of specifying a particular virtual address for your memory?

If this is useful then we should make the mmap function fail if it cannot honour the address, since otherwise presumably some tests will fail.

Regards,
Simon

Quoted 8 lines

Regards
Matthias
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Matthias Weisser

author

2011-11-01 18:37 UTC #4 lore raw

PATCH 1/1 sandbox: Add improved RAM simulation

Am 01.11.2011 17:45, schrieb Simon Glass:

Quoted 10 lines

Quoted 10 lines
Quoted 9 lines
arch/sandbox/lib/board.c void board_init_f(ulong bootflag) · line 166
Quoted 5 lines
arch/sandbox/lib/board.c +3 -1
+#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.

Quoted 6 lines

Quoted 4 lines
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.
Most?

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 used for stack and shared objects. Even with ASLR the address I used in the patch should be mappable.

Quoted 8 lines

Quoted 5 lines
Quoted 2 lines
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.
This is interesting. What is the test purpose of specifying a particular virtual address for your memory?

Emulating the behavior of a u-boot on real hardware as close as possible. We have some chunk of memory at a given location. Thats it. With a minimum of additional work we can also simulate additional banks of RAM using multiple mmaps.

Quoted 3 lines

If this is useful then we should make the mmap function fail if it cannot honour the address, since otherwise presumably some tests will fail.

Maybe. But on the other hand tests can always extract the actual address of RAM from gd->bd->bi_dram[0].start. If test use these address we can abandon the use of of fixed address. But I still thinks its nice to have an aligned address of RAM start as this is what we have on (all?) real hardware.

Regards
Matthias

Mike Frysinger

2011-11-01 18:52 UTC #5 lore raw

PATCH 1/1 sandbox: Add improved RAM simulation

Quoted 5 lines · 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 used for stack and shared objects. Even with ASLR the address I used in the patch should be mappable.

relying on any address layout behavior is doomed to fail. and in this case, it's unnecessary. so let's not bother.

Quoted 6 lines

Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
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.

Quoted 7 lines

Quoted 2 lines
This is interesting. What is the test purpose of specifying a particular virtual address for your memory?
Emulating the behavior of a u-boot on real hardware as close as possible. We have some chunk of memory at a given location. Thats it. With a minimum of additional work we can also simulate additional banks of RAM using multiple mmaps.

adding a CONFIG knob to control the virtual address of the memory is fine

Quoted 9 lines

Quoted 3 lines
If this is useful then we should make the mmap function fail if it cannot honour the address, since otherwise presumably some tests will fail.
Maybe. But on the other hand tests can always extract the actual address of RAM from gd->bd->bi_dram[0].start. If test use these address we can abandon the use of of fixed address. But I still thinks its nice to have an aligned address of RAM start as this is what we have on (all?) real hardware.

i'd rather see bi_dram die than extend it. if you want to utilize the virtual memory, let's use the already existing map helper.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111101/51e15d18/attachment.pgp

Matthias Weisser

author

2011-11-01 19:01 UTC #6 lore raw

PATCH 1/1 sandbox: Add improved RAM simulation

Am 01.11.2011 19:52, schrieb Mike Frysinger:

Quoted 9 lines · On Tuesday 01 November 2011 14:37:24 Matthias Weisser wrote:

Quoted 5 lines
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 used for stack and shared objects. Even with ASLR the address I used in the patch should be mappable.
relying on any address layout behavior is doomed to fail. and in this case, it's unnecessary. so let's not bother.

Accepted but not convinced :-) As the address passed to mmap is only a hint it will not fail. But I will remove the hint in V2 of the patch.

Regards
Matthias

Mike Frysinger

2011-11-01 20:10 UTC #7 lore raw

PATCH 1/1 sandbox: Add improved RAM simulation

Quoted 8 lines · On Tuesday 01 November 2011 15:01:55 Matthias Weisser wrote:

Am 01.11.2011 19:52, schrieb Mike Frysinger:
Quoted 7 lines · On Tuesday 01 November 2011 14:37:24 Matthias Weisser wrote:
Quoted 5 lines
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 used for stack and shared objects. Even with ASLR the address I used in the patch should be mappable.

Quoted 5 lines

Quoted 2 lines
relying on any address layout behavior is doomed to fail. and in this case, it's unnecessary. so let's not bother.
Accepted but not convinced :-) As the address passed to mmap is only a hint it will not fail. But I will remove the hint in V2 of the patch.

by "fail" i meant "relying on the address being the same all the time". not "mmap returned MAP_FAILED".
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111101/eebc5192/attachment.pgp

Matthias Weisser

author

2011-11-02 18:35 UTC #8 lore raw

PATCH 1/1 sandbox: Add improved RAM simulation

Am 01.11.2011 21:10, schrieb Mike Frysinger:

Quoted 12 lines · On Tuesday 01 November 2011 15:01:55 Matthias Weisser wrote:

Quoted 11 lines
Am 01.11.2011 19:52, schrieb Mike Frysinger:
Quoted 9 lines · On Tuesday 01 November 2011 14:37:24 Matthias Weisser wrote:
Quoted 5 lines
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 used for stack and shared objects. Even with ASLR the address I used in the patch should be mappable.
relying on any address layout behavior is doomed to fail. and in this case, it's unnecessary. so let's not bother.

Quoted 6 lines

Quoted 2 lines
Accepted but not convinced :-) As the address passed to mmap is only a hint it will not fail. But I will remove the hint in V2 of the patch.
by "fail" i meant "relying on the address being the same all the time". not "mmap returned MAP_FAILED".
-mike

I just implemented it as suggested. One thing I observed now is that an unhinted mmap now returns an address > 4GB (on my x86_64 machine) which is directly mapped under the shared object address range.

$ cat /proc/9150/maps
...
7f0e6f09b000-7f0e7709b000 rw-p 00000000 00:00 0        # <u-boot RAM
7f0e7709b000-7f0e77225000 r-xp 00000000 08:02 1198174  # libc
...

After applying Simons md patch I can now successfully md the 128MBytes of simulated RAM. If I use an "virtual" address close to the end of this area:

=>md 7ffff80
md 7ffff80

07ffff80: 00000000 00000000 00000000 00000000    ................
07ffff90: 00000000 00000000 00000000 00000000    ................
07ffffa0: 00000000 00000000 00000000 00000000    ................
07ffffb0: 00000000 00000000 00000000 00000000    ................
07ffffc0: 00000000 00000000 00000000 00000000    ................
07ffffd0: 00000000 00000000 00000000 00000000    ................
07ffffe0: 00000000 00000000 00000000 00000000    ................
07fffff0: 00000000 00000000 00000000 00000000    ................
08000000: 464c457f 00010102 00000000 00000000    .ELF............
08000010: 003e0003 00000001 0001f010 00000000    ..>.............
08000020: 00000040 00000000 0018ed28 00000000    @.......(.......
08000030: 00000000 00380040 0040000a 00460047    .... at [email protected].
08000040: 00000006 00000005 00000040 00000000    ........ at .......
08000050: 00000040 00000000 00000040 00000000    @....... at .......
08000060: 00000230 00000000 00000230 00000000    0.......0.......
08000070: 00000008 00000000 00000003 00000004    ................

So, as you can see, dumping to far is not faulting. It just dumps (in this case) the first bytes of my local libc.

Regards
Matthias

Mike Frysinger

2011-11-02 19:20 UTC #9 lore raw

PATCH 1/1 sandbox: Add improved RAM simulation

Quoted 2 lines · 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 actually backed by memory, you get chip- specific behavior. it could be an exception, a hardware error signal, random garbage, or something else.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111102/5819f22a/attachment.pgp

Mike Frysinger

2011-11-01 17:12 UTC #10 lore raw

PATCH 1/1 sandbox: Add improved RAM simulation

In reply to Matthias Weisser

Quoted 10 lines · On Tuesday 01 November 2011 12:05:05 Matthias Weisser wrote:

Am 01.11.2011 16:28, schrieb Mike Frysinger:
Quoted 9 lines · On Tuesday 01 November 2011 10:07:31 Matthias Weisser wrote:
arch/sandbox/lib/board.c line 52
Quoted 4 lines
arch/sandbox/lib/board.c +1 -0
 
+static gd_t gd_mem;
i don't think this indirection is necessary. probably can replace the static

Quoted 5 lines

Quoted 2 lines
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.

only if you use the DECLARE macro. but it's fine either way.

Quoted 15 lines

Quoted 9 lines
arch/sandbox/lib/board.c void board_init_f(ulong bootflag) · line 166
Quoted 5 lines
arch/sandbox/lib/board.c +3 -1
+#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.

Quoted 5 lines

Quoted 2 lines
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.

except for when that base address happens to already be used, then any assumptions about memory addresses are now invalid.

the internal memory layout should be disconnected from the user-api facing layout. so while internally sandbox does an anon mmap of some chunk of memory, where that is based should not matter. the memory as seen by commands run from the console should always be the same. which is what Simon's patch gets us.

as for sandbox working the same as random SoCs, that's going to be highly SoC and architecture specific. i'd keep it simple and have sandbox expose its chunk of memory starting at address 0 and work its way up.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111101/b031d604/attachment.pgp

Simon Glass

2011-11-01 16:42 UTC #11 lore raw

PATCH 1/1 sandbox: Add improved RAM simulation

In reply to Matthias Weisser

Hi Matthias,

Quoted 4 lines · Matthias Weisser

Using mmap we can simulate RAM at a specific address. This also eliminated the use of system malloc function.
Signed-off-by Matthias Weisser <[email protected]>

Thanks for the patch!

Quoted 20 lines

---
?arch/sandbox/cpu/os.c ? ? | ? ?9 +++++++++
?arch/sandbox/lib/board.c ?| ? 19 +++++++++++--------
?include/configs/sandbox.h | ? ?1 +
?include/os.h ? ? ? ? ? ? ?| ? 13 +++++++++++++
?4 files changed, 34 insertions(+), 8 deletions(-)
arch/sandbox/cpu/os.c +0 -0
index 6c175d4..cd2fb05 100644
@@ -24,6 +24,7 @@
?#include <unistd.h>
?#include <sys/types.h>
?#include <sys/stat.h>
+#include <sys/mman.h>
?#include <os.h>

arch/sandbox/cpu/os.c void os_exit(int exit_code) · line 59

Quoted 6 lines

arch/sandbox/cpu/os.c +3 -0

@@ -53,3 +54,11 @@ void os_exit(int exit_code)
 ?{
 ? ? ? ?exit(exit_code);
 ?}
+
+void *os_mmap(void *addr, size_t length, int prot, int flags, int fd,
+ ? ? ? ? ? ? ? off_t offset)

I would prefer that you define something like os_malloc() instead, and your implementation use mmap(). After all your flags cannot sensibly be used elsewhere in U-Boot, and we might as well define only the feature that we actually want to use. I don't see a general use for mmap().

Quoted 41 lines

arch/sandbox/cpu/os.c +5 -0
+{
+ ? ? ? return mmap((void *)addr, length, PROT_READ | PROT_WRITE,
+ ? ? ? ? ? ? ? ? ? ? ? MAP_PRIVATE | MAP_ANONYMOUS,
+ ? ? ? ? ? ? ? ? ? ? ? -1, 0);
+}
arch/sandbox/lib/board.c +0 -0
index ae5a517..0912a8b 100644
@@ -45,8 +45,12 @@
?#include <version.h>
?#include <serial.h>
arch/sandbox/lib/board.c +2 -0
+#include <os.h>
+
?DECLARE_GLOBAL_DATA_PTR;
arch/sandbox/lib/board.c +2 -0
+static gd_t gd_mem;
+
?/************************************************************************ ?* Init Utilities ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?* ?************************************************************************
arch/sandbox/lib/board.c +2 -2
@@ -112,7 +116,7 @@ typedef int (init_fnc_t) (void);
 
 ?void __dram_init_banksize(void)
 ?{
- ? ? ? gd->bd->bi_dram[0].start = 0;
+ ? ? ? gd->bd->bi_dram[0].start = (ulong) gd->ram_buf;
 ? ? ? ?gd->bd->bi_dram[0].size = ?gd->ram_size;
 ?}
 
@@ -147,7 +151,7 @@ void board_init_f(ulong bootflag)
 ? ? ? ?uchar *mem;
 ? ? ? ?unsigned long addr_sp, addr, size;
 
- ? ? ? gd = malloc(sizeof(gd_t));
+ ? ? ? gd = &gd_mem;
 ? ? ? ?assert(gd);
 
 ? ? ? ?memset((void *)gd, 0, sizeof(gd_t));

arch/sandbox/lib/board.c void board_init_f(ulong bootflag) · line 165

Quoted 5 lines

arch/sandbox/lib/board.c +1 -1

@@ -158,7 +162,8 @@ void board_init_f(ulong bootflag)
 ? ? ? ?}
 
 ? ? ? ?size = CONFIG_SYS_SDRAM_SIZE;
- ? ? ? mem = malloc(size);
+ ? ? ? mem = os_mmap((void *)CONFIG_SYS_SDRAM_BASE, CONFIG_SYS_SDRAM_SIZE,

What is the base used for here?

Quoted 39 lines

arch/sandbox/lib/board.c +1 -0
+ ? ? ? ? ? ? ? ? ? ? ? 0, 0, -1, 0);
 ? ? ? ?assert(mem);
 ? ? ? ?gd->ram_buf = mem;
 ? ? ? ?addr = (ulong)(mem + size);
@@ -214,11 +219,9 @@ void board_init_r(gd_t *id, ulong dest_addr)
 ? ? ? ?post_output_backlog();
?#endif
arch/sandbox/lib/board.c +3 -5
-#if 0 /* Sandbox uses system malloc for now */
- ? ? ? /* The Malloc area is immediately below the monitor copy in DRAM */
- ? ? ? malloc_start = dest_addr - TOTAL_MALLOC_LEN;
- ? ? ? mem_malloc_init(malloc_start, TOTAL_MALLOC_LEN);
-#endif
+ ? ? ? /* The Malloc area is at the top of simulated DRAM */
+ ? ? ? mem_malloc_init(gd->ram_buf + gd->ram_size - TOTAL_MALLOC_LEN,
+ ? ? ? ? ? ? ? ? ? ? ? TOTAL_MALLOC_LEN);
? ? ? ?/* initialize environment */
? ? ? ?env_relocate();
include/configs/sandbox.h +0 -0
index 0230256..ce4675d 100644
@@ -60,6 +60,7 @@
?#define CONFIG_PHYS_64BIT
?/* Size of our emulated memory */
+#define CONFIG_SYS_SDRAM_BASE ? ? ? ? ?0x20000000 ?#define CONFIG_SYS_SDRAM_SIZE ? ? ? ? ?(128 << 20)
?#define CONFIG_BAUDRATE ? ? ? ? ? ? ? ? ? ? ? ?115200
include/os.h +0 -0
index 3ea6d2d..ed4cd4f 100644
@@ -71,3 +71,16 @@ int os_close(int fd);
?* @param exit_code ? ?exit code for U-Boot
?*/
?void os_exit(int exit_code);

include/os.h

Quoted 10 lines

include/os.h +10 -0

+
+/**
+ * Access to the OS mmap() system call. Currently all
+ *
+ * \param addr ? ? ? ? Prefered address of the mapping
+ * \param length ? ? ? Length in bytes
+ * \param prot ? ? ? ? Ignored. Always PROT_READ | PROT_WRITE
+ * \param flags ? ? ? ? ? ? ? ?Ignored. Always MAP_PRIVATE | MAP_ANONYMOUS
+ * \param fd ? ? ? ? ? Ignored. Always -1
+ * \param offset ? ? ? Ignored. Always 0

Hmm please see above - we don't have to mimic the POSIX API exactly. The preferred address doesn't really matter since in sandbox it will be accessed as an offset from the start. Apart from length the other parameters should probably not be included.

Regards,
Simon

Quoted 7 lines

+ */
+void *os_mmap(void *addr, size_t length, int prot, int flags, int fd,
+ ? ? ? ? ? ? ? off_t offset);
--
1.7.4.1

Matthias Weisser

author

2011-11-02 20:12 UTC #12 lore raw

PATCH v2 1/1 ] sandbox: Add improved RAM simulation

In reply to Matthias Weisser

Using mmap to allocate memory from the OS for RAM simulation we can use u-boots own malloc implementation.

Signed-off-by Matthias Weisser <[email protected]>

---
Changes in V2:
Removed the address hint for mmap
Removed the special handling of dlmalloc in common Set gd->bd->bi_dram[0].start to 0 again

 arch/sandbox/cpu/os.c    |    7 +++++++
 arch/sandbox/lib/board.c |   17 ++++++++++-------
 common/Makefile          |    2 --
 include/os.h             |    8 ++++++++
 4 files changed, 25 insertions(+), 9 deletions(-)

arch/sandbox/cpu/os.c +7 -0

index 6c175d4..05f91f2 100644
@@ -24,6 +24,7 @@
 #include <unistd.h>
 #include <sys/types.h>
 #include <sys/stat.h>
+#include <sys/mman.h>
 
 #include <os.h>

@@ -53,3 +54,9 @@ void os_exit(int exit_code)
 {
 	exit(exit_code);
 }
+
+void *os_malloc(size_t length)
+{
+	return mmap(NULL, length, PROT_READ | PROT_WRITE,
+			MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+}

arch/sandbox/lib/board.c +10 -7

index ae5a517..d71cd6f 100644
@@ -45,8 +45,12 @@
 #include <version.h>
 #include <serial.h>
 
+#include <os.h>
+
 DECLARE_GLOBAL_DATA_PTR;
 
+static gd_t gd_mem;
+
 /************************************************************************
  * Init Utilities							*
  ************************************************************************

@@ -147,7 +151,7 @@ void board_init_f(ulong bootflag)
 	uchar *mem;
 	unsigned long addr_sp, addr, size;
 
-	gd = malloc(sizeof(gd_t));
+	gd = &gd_mem;
 	assert(gd);
 
 	memset((void *)gd, 0, sizeof(gd_t));

@@ -158,7 +162,8 @@ void board_init_f(ulong bootflag)
 	}
 
 	size = CONFIG_SYS_SDRAM_SIZE;
-	mem = malloc(size);
+	mem = os_malloc(CONFIG_SYS_SDRAM_SIZE);
+
 	assert(mem);
 	gd->ram_buf = mem;
 	addr = (ulong)(mem + size);

@@ -214,11 +219,9 @@ void board_init_r(gd_t *id, ulong dest_addr)
 	post_output_backlog();
 #endif
 
-#if 0 /* Sandbox uses system malloc for now */
-	/* The Malloc area is immediately below the monitor copy in DRAM */
-	malloc_start = dest_addr - TOTAL_MALLOC_LEN;
-	mem_malloc_init(malloc_start, TOTAL_MALLOC_LEN);
-#endif
+	/* The Malloc area is at the top of simulated DRAM */
+	mem_malloc_init(gd->ram_buf + gd->ram_size - TOTAL_MALLOC_LEN,
+			TOTAL_MALLOC_LEN);
 
 	/* initialize environment */
 	env_relocate();

common/Makefile +0 -2

index 1b672ad..919be42 100644
@@ -29,9 +29,7 @@ LIB	= $(obj)libcommon.o
 ifndef CONFIG_SPL_BUILD
 COBJS-y += main.o
 COBJS-y += command.o
-ifndef CONFIG_SANDBOX
 COBJS-y += dlmalloc.o
-endif
 COBJS-y += exports.o
 COBJS-$(CONFIG_SYS_HUSH_PARSER) += hush.o
 COBJS-y += image.o

include/os.h +8 -0

index 3ea6d2d..2bb2fb7 100644
@@ -71,3 +71,11 @@ int os_close(int fd);
  * @param exit_code	exit code for U-Boot
  */
 void os_exit(int exit_code);
+
+/**
+ * Acquires some memory from the underlying os.
+ *
+ * \param length	Number of bytes to be allocated
+ * \return Pointer to length bytes or NULL on error
+ */
+void *os_malloc(size_t length);

Signature · 1 line

1.7.4.1

Mike Frysinger

2011-11-02 20:39 UTC #13 lore raw

PATCH v2 1/1 ] sandbox: Add improved RAM simulation

Acked-by Mike Frysinger <[email protected]>

-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111102/8f926283/attachment.pgp

Simon Glass

2011-11-02 20:56 UTC #14 lore raw

PATCH v2 1/1 ] sandbox: Add improved RAM simulation

In reply to Matthias Weisser

Quoted 65 lines · Matthias Weisser

Using mmap to allocate memory from the OS for RAM simulation we can use u-boots own malloc implementation.
Signed-off-by Matthias Weisser <[email protected]>
---
Changes in V2:
?Removed the address hint for mmap
?Removed the special handling of dlmalloc in common ?Set gd->bd->bi_dram[0].start to 0 again
?arch/sandbox/cpu/os.c ? ?| ? ?7 +++++++
?arch/sandbox/lib/board.c | ? 17 ++++++++++-------
?common/Makefile ? ? ? ? ?| ? ?2 --
?include/os.h ? ? ? ? ? ? | ? ?8 ++++++++
?4 files changed, 25 insertions(+), 9 deletions(-)
arch/sandbox/cpu/os.c +0 -0
index 6c175d4..05f91f2 100644
@@ -24,6 +24,7 @@
?#include <unistd.h>
?#include <sys/types.h>
?#include <sys/stat.h>
+#include <sys/mman.h>
?#include <os.h>
arch/sandbox/cpu/os.c +6 -0
@@ -53,3 +54,9 @@ void os_exit(int exit_code)
 ?{
 ? ? ? ?exit(exit_code);
 ?}
+
+void *os_malloc(size_t length)
+{
+ ? ? ? return mmap(NULL, length, PROT_READ | PROT_WRITE,
+ ? ? ? ? ? ? ? ? ? ? ? MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+}
arch/sandbox/lib/board.c +0 -0
index ae5a517..d71cd6f 100644
@@ -45,8 +45,12 @@
?#include <version.h>
?#include <serial.h>
arch/sandbox/lib/board.c +2 -0
+#include <os.h>
+
?DECLARE_GLOBAL_DATA_PTR;
arch/sandbox/lib/board.c +2 -0
+static gd_t gd_mem;
+
?/************************************************************************ ?* Init Utilities ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?* ?************************************************************************
arch/sandbox/lib/board.c +1 -1
@@ -147,7 +151,7 @@ void board_init_f(ulong bootflag)
 ? ? ? ?uchar *mem;
 ? ? ? ?unsigned long addr_sp, addr, size;
 
- ? ? ? gd = malloc(sizeof(gd_t));
+ ? ? ? gd = &gd_mem;
 ? ? ? ?assert(gd);
 
 ? ? ? ?memset((void *)gd, 0, sizeof(gd_t));

arch/sandbox/lib/board.c void board_init_f(ulong bootflag) · line 166

Quoted 6 lines

arch/sandbox/lib/board.c +2 -1

@@ -158,7 +162,8 @@ void board_init_f(ulong bootflag)
 ? ? ? ?}
 
 ? ? ? ?size = CONFIG_SYS_SDRAM_SIZE;
- ? ? ? mem = malloc(size);
+ ? ? ? mem = os_malloc(CONFIG_SYS_SDRAM_SIZE);
+

Just a suggestion if you like: perhaps also assert that CONFIG_SYS_SDRAM_SIZE is greater than TOTAL_MALLOC_LEN. Or assert lower down at the end of board_init_f() that addr_sp is still greatrer than mem?

Quoted 7 lines

arch/sandbox/lib/board.c +0 -0

 ? ? ? ?assert(mem);
 ? ? ? ?gd->ram_buf = mem;
 ? ? ? ?addr = (ulong)(mem + size);

@@ -214,11 +219,9 @@ void board_init_r(gd_t *id, ulong dest_addr)
 ? ? ? ?post_output_backlog();

?#endif

arch/sandbox/lib/board.c

Quoted 8 lines

arch/sandbox/lib/board.c +3 -5

-#if 0 /* Sandbox uses system malloc for now */
- ? ? ? /* The Malloc area is immediately below the monitor copy in DRAM */
- ? ? ? malloc_start = dest_addr - TOTAL_MALLOC_LEN;
- ? ? ? mem_malloc_init(malloc_start, TOTAL_MALLOC_LEN);
-#endif
+ ? ? ? /* The Malloc area is at the top of simulated DRAM */
+ ? ? ? mem_malloc_init(gd->ram_buf + gd->ram_size - TOTAL_MALLOC_LEN,
+ ? ? ? ? ? ? ? ? ? ? ? TOTAL_MALLOC_LEN);

I get:

board.c:224:4: warning: passing argument 1 of ?mem_malloc_init? makes integer from pointer without a cast [enabled by default]

Quoted 8 lines

? ? ? ?/* initialize environment */
? ? ? ?env_relocate();
common/Makefile +0 -0
index 1b672ad..919be42 100644
@@ -29,9 +29,7 @@ LIB ? = $(obj)libcommon.o

Quoted 6 lines

?ifndef CONFIG_SPL_BUILD
?COBJS-y += main.o
?COBJS-y += command.o
-ifndef CONFIG_SANDBOX
?COBJS-y += dlmalloc.o
-endif

I think this can be removed. It was added unconditionally lower down in the Makefile by this commit:

2d01dd9 omap: spl: fix build break due to changes in FAT

(incidentally this is what has broken sandbox).

Quoted 23 lines

?COBJS-y += exports.o
?COBJS-$(CONFIG_SYS_HUSH_PARSER) += hush.o
?COBJS-y += image.o
include/os.h +0 -0
index 3ea6d2d..2bb2fb7 100644
@@ -71,3 +71,11 @@ int os_close(int fd);
?* @param exit_code ? ?exit code for U-Boot
?*/
?void os_exit(int exit_code);
include/os.h +8 -1
+
+/**
+ * Acquires some memory from the underlying os.
+ *
+ * \param length ? ? ? Number of bytes to be allocated
+ * \return Pointer to length bytes or NULL on error
+ */
+void *os_malloc(size_t length);
--
1.7.4.1

Matthias Weisser

author

2011-11-03 17:55 UTC #15 lore raw

PATCH v2 1/1 ] sandbox: Add improved RAM simulation

Am 02.11.2011 21:56, schrieb Simon Glass:

Quoted 68 lines · Matthias Weisser

Quoted 67 lines

Using mmap to allocate memory from the OS for RAM simulation we can use u-boots own malloc implementation.

Signed-off-by Matthias Weisser <[email protected]>

---
Changes in V2:
Removed the address hint for mmap
Removed the special handling of dlmalloc in common Set gd->bd->bi_dram[0].start to 0 again

 arch/sandbox/cpu/os.c    |    7 +++++++
 arch/sandbox/lib/board.c |   17 ++++++++++-------
 common/Makefile          |    2 --
 include/os.h             |    8 ++++++++
 4 files changed, 25 insertions(+), 9 deletions(-)

arch/sandbox/cpu/os.c +7 -0

index 6c175d4..05f91f2 100644
@@ -24,6 +24,7 @@
 #include <unistd.h>
 #include <sys/types.h>
 #include <sys/stat.h>
+#include <sys/mman.h>
 
 #include <os.h>

@@ -53,3 +54,9 @@ void os_exit(int exit_code)
 {
       exit(exit_code);
 }
+
+void *os_malloc(size_t length)
+{
+       return mmap(NULL, length, PROT_READ | PROT_WRITE,
+                       MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+}

arch/sandbox/lib/board.c +5 -1

index ae5a517..d71cd6f 100644
@@ -45,8 +45,12 @@
 #include <version.h>
 #include <serial.h>
 
+#include <os.h>
+
 DECLARE_GLOBAL_DATA_PTR;
 
+static gd_t gd_mem;
+
 /************************************************************************
 * Init Utilities                                                      *
 ************************************************************************

@@ -147,7 +151,7 @@ void board_init_f(ulong bootflag)
       uchar *mem;
       unsigned long addr_sp, addr, size;
 
-       gd = malloc(sizeof(gd_t));
+       gd = &gd_mem;
       assert(gd);
 
       memset((void *)gd, 0, sizeof(gd_t));

@@ -158,7 +162,8 @@ void board_init_f(ulong bootflag)
       }

Quoted 9 lines

arch/sandbox/lib/board.c void board_init_f(ulong bootflag) · line 166
Quoted 4 lines
arch/sandbox/lib/board.c +2 -1
       size = CONFIG_SYS_SDRAM_SIZE;
-       mem = malloc(size);
+       mem = os_malloc(CONFIG_SYS_SDRAM_SIZE);
+
Just a suggestion if you like: perhaps also assert that CONFIG_SYS_SDRAM_SIZE is greater than TOTAL_MALLOC_LEN. Or assert lower down at the end of board_init_f() that addr_sp is still greatrer than mem?

I will leave out this point for a separate patch.

Quoted 18 lines

Quoted 5 lines

arch/sandbox/lib/board.c +0 -0

       assert(mem);
       gd->ram_buf = mem;
       addr = (ulong)(mem + size);

@@ -214,11 +219,9 @@ void board_init_r(gd_t *id, ulong dest_addr)
       post_output_backlog();

arch/sandbox/lib/board.c void board_init_r(gd_t *id, ulong dest_addr) · line 224

Quoted 10 lines

arch/sandbox/lib/board.c +3 -5

 #endif
 
-#if 0 /* Sandbox uses system malloc for now */
-       /* The Malloc area is immediately below the monitor copy in DRAM */
-       malloc_start = dest_addr - TOTAL_MALLOC_LEN;
-       mem_malloc_init(malloc_start, TOTAL_MALLOC_LEN);
-#endif
+       /* The Malloc area is at the top of simulated DRAM */
+       mem_malloc_init(gd->ram_buf + gd->ram_size - TOTAL_MALLOC_LEN,
+                       TOTAL_MALLOC_LEN);

I get:

Quoted 2 lines

board.c:224:4: warning: passing argument 1 of ?mem_malloc_init? makes integer from pointer without a cast [enabled by default]

Fixed. Will send an updated version.

Quoted 18 lines

Quoted 8 lines
arch/sandbox/lib/board.c +0 -0
       /* initialize environment */
       env_relocate();
common/Makefile +0 -0
index 1b672ad..919be42 100644
common/Makefile LIB = $(obj)libcommon.o · line 34
Quoted 6 lines
common/Makefile +0 -2
@@ -29,9 +29,7 @@ LIB   = $(obj)libcommon.o
 ifndef CONFIG_SPL_BUILD
 COBJS-y += main.o
 COBJS-y += command.o
-ifndef CONFIG_SANDBOX
 COBJS-y += dlmalloc.o
-endif
I think this can be removed. It was added unconditionally lower down in the Makefile by this commit:

Quoted 3 lines

2d01dd9 omap: spl: fix build break due to changes in FAT
(incidentally this is what has broken sandbox).

Will do.

Matthias

Matthias Weisser

author

2011-11-03 18:02 UTC #16 lore raw

PATCH v3 1/1 sandbox: Add improved RAM simulation

In reply to Matthias Weisser

Using mmap to allocate memory from the OS for RAM simulation we can use u-boot own malloc implementation.

Signed-off-by Matthias Weisser <[email protected]>

---
Changes in V3:
Fixed a build warning

Changes in V2:
Removed the address hint for mmap
Removed the special handling of dlmalloc in common Set gd->bd->bi_dram[0].start to 0 again

This patch also fixes the runtime error of sandbox introduced in 2d01dd9 omap: spl: fix build break due to changes in FAT

 arch/sandbox/cpu/os.c    |    7 +++++++
 arch/sandbox/lib/board.c |   17 ++++++++++-------
 common/Makefile          |    3 ---
 include/os.h             |    8 ++++++++
 4 files changed, 25 insertions(+), 10 deletions(-)

arch/sandbox/cpu/os.c +7 -0

index 6c175d4..05f91f2 100644
@@ -24,6 +24,7 @@
 #include <unistd.h>
 #include <sys/types.h>
 #include <sys/stat.h>
+#include <sys/mman.h>
 
 #include <os.h>

@@ -53,3 +54,9 @@ void os_exit(int exit_code)
 {
 	exit(exit_code);
 }
+
+void *os_malloc(size_t length)
+{
+	return mmap(NULL, length, PROT_READ | PROT_WRITE,
+			MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+}

arch/sandbox/lib/board.c +10 -7

index ae5a517..b7997e9 100644
@@ -45,8 +45,12 @@
 #include <version.h>
 #include <serial.h>
 
+#include <os.h>
+
 DECLARE_GLOBAL_DATA_PTR;
 
+static gd_t gd_mem;
+
 /************************************************************************
  * Init Utilities							*
  ************************************************************************

@@ -147,7 +151,7 @@ void board_init_f(ulong bootflag)
 	uchar *mem;
 	unsigned long addr_sp, addr, size;
 
-	gd = malloc(sizeof(gd_t));
+	gd = &gd_mem;
 	assert(gd);
 
 	memset((void *)gd, 0, sizeof(gd_t));

@@ -158,7 +162,8 @@ void board_init_f(ulong bootflag)
 	}
 
 	size = CONFIG_SYS_SDRAM_SIZE;
-	mem = malloc(size);
+	mem = os_malloc(CONFIG_SYS_SDRAM_SIZE);
+
 	assert(mem);
 	gd->ram_buf = mem;
 	addr = (ulong)(mem + size);

@@ -214,11 +219,9 @@ void board_init_r(gd_t *id, ulong dest_addr)
 	post_output_backlog();
 #endif
 
-#if 0 /* Sandbox uses system malloc for now */
-	/* The Malloc area is immediately below the monitor copy in DRAM */
-	malloc_start = dest_addr - TOTAL_MALLOC_LEN;
-	mem_malloc_init(malloc_start, TOTAL_MALLOC_LEN);
-#endif
+	/* The Malloc area is at the top of simulated DRAM */
+	mem_malloc_init((ulong)gd->ram_buf + gd->ram_size - TOTAL_MALLOC_LEN,
+			TOTAL_MALLOC_LEN);
 
 	/* initialize environment */
 	env_relocate();

common/Makefile +0 -3

index 1b672ad..015c17e 100644
@@ -29,9 +29,6 @@ LIB	= $(obj)libcommon.o
 ifndef CONFIG_SPL_BUILD
 COBJS-y += main.o
 COBJS-y += command.o
-ifndef CONFIG_SANDBOX
-COBJS-y += dlmalloc.o
-endif
 COBJS-y += exports.o
 COBJS-$(CONFIG_SYS_HUSH_PARSER) += hush.o
 COBJS-y += image.o

include/os.h +8 -0

index 3ea6d2d..2bb2fb7 100644
@@ -71,3 +71,11 @@ int os_close(int fd);
  * @param exit_code	exit code for U-Boot
  */
 void os_exit(int exit_code);
+
+/**
+ * Acquires some memory from the underlying os.
+ *
+ * \param length	Number of bytes to be allocated
+ * \return Pointer to length bytes or NULL on error
+ */
+void *os_malloc(size_t length);

Signature · 1 line

1.7.4.1

Mike Frysinger

2011-11-03 18:05 UTC #17 lore raw

PATCH v3 1/1 sandbox: Add improved RAM simulation

Acked-by Mike Frysinger <[email protected]>

Simon Glass

2011-11-03 22:55 UTC #18 lore raw

PATCH v3 1/1 sandbox: Add improved RAM simulation

In reply to Matthias Weisser

Hi Matthias,

Quoted 13 lines · Matthias Weisser

Using mmap to allocate memory from the OS for RAM simulation we can use u-boot own malloc implementation.
Signed-off-by Matthias Weisser <[email protected]>
---
Changes in V3:
?Fixed a build warning
Changes in V2:
?Removed the address hint for mmap
?Removed the special handling of dlmalloc in common ?Set gd->bd->bi_dram[0].start to 0 again

Quoted 8 lines

This patch also fixes the runtime error of sandbox introduced in 2d01dd9 omap: spl: fix build break due to changes in FAT
?arch/sandbox/cpu/os.c ? ?| ? ?7 +++++++
?arch/sandbox/lib/board.c | ? 17 ++++++++++-------
?common/Makefile ? ? ? ? ?| ? ?3 ---
?include/os.h ? ? ? ? ? ? | ? ?8 ++++++++
?4 files changed, 25 insertions(+), 10 deletions(-)

Unfortunately the terminal changes got in before you - can you please rebase and resubmit?

Otherwise I have tested this again and it work well, thank you.

Regards,
Simon

Quoted 108 lines

arch/sandbox/cpu/os.c +0 -0
index 6c175d4..05f91f2 100644
@@ -24,6 +24,7 @@
?#include <unistd.h>
?#include <sys/types.h>
?#include <sys/stat.h>
+#include <sys/mman.h>
?#include <os.h>
arch/sandbox/cpu/os.c +6 -0
@@ -53,3 +54,9 @@ void os_exit(int exit_code)
 ?{
 ? ? ? ?exit(exit_code);
 ?}
+
+void *os_malloc(size_t length)
+{
+ ? ? ? return mmap(NULL, length, PROT_READ | PROT_WRITE,
+ ? ? ? ? ? ? ? ? ? ? ? MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+}
arch/sandbox/lib/board.c +0 -0
index ae5a517..b7997e9 100644
@@ -45,8 +45,12 @@
?#include <version.h>
?#include <serial.h>
arch/sandbox/lib/board.c +2 -0
+#include <os.h>
+
?DECLARE_GLOBAL_DATA_PTR;
arch/sandbox/lib/board.c +2 -0
+static gd_t gd_mem;
+
?/************************************************************************ ?* Init Utilities ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?* ?************************************************************************
arch/sandbox/lib/board.c +3 -2
@@ -147,7 +151,7 @@ void board_init_f(ulong bootflag)
 ? ? ? ?uchar *mem;
 ? ? ? ?unsigned long addr_sp, addr, size;
 
- ? ? ? gd = malloc(sizeof(gd_t));
+ ? ? ? gd = &gd_mem;
 ? ? ? ?assert(gd);
 
 ? ? ? ?memset((void *)gd, 0, sizeof(gd_t));
@@ -158,7 +162,8 @@ void board_init_f(ulong bootflag)
 ? ? ? ?}
 
 ? ? ? ?size = CONFIG_SYS_SDRAM_SIZE;
- ? ? ? mem = malloc(size);
+ ? ? ? mem = os_malloc(CONFIG_SYS_SDRAM_SIZE);
+
 ? ? ? ?assert(mem);
 ? ? ? ?gd->ram_buf = mem;
 ? ? ? ?addr = (ulong)(mem + size);
@@ -214,11 +219,9 @@ void board_init_r(gd_t *id, ulong dest_addr)
 ? ? ? ?post_output_backlog();
?#endif
arch/sandbox/lib/board.c +3 -5
-#if 0 /* Sandbox uses system malloc for now */
- ? ? ? /* The Malloc area is immediately below the monitor copy in DRAM */
- ? ? ? malloc_start = dest_addr - TOTAL_MALLOC_LEN;
- ? ? ? mem_malloc_init(malloc_start, TOTAL_MALLOC_LEN);
-#endif
+ ? ? ? /* The Malloc area is at the top of simulated DRAM */
+ ? ? ? mem_malloc_init((ulong)gd->ram_buf + gd->ram_size - TOTAL_MALLOC_LEN,
+ ? ? ? ? ? ? ? ? ? ? ? TOTAL_MALLOC_LEN);
? ? ? ?/* initialize environment */
? ? ? ?env_relocate();
common/Makefile +0 -0
index 1b672ad..015c17e 100644
@@ -29,9 +29,6 @@ LIB ? = $(obj)libcommon.o
?ifndef CONFIG_SPL_BUILD
?COBJS-y += main.o
?COBJS-y += command.o
common/Makefile +0 -3
-ifndef CONFIG_SANDBOX
-COBJS-y += dlmalloc.o
-endif
?COBJS-y += exports.o
?COBJS-$(CONFIG_SYS_HUSH_PARSER) += hush.o
?COBJS-y += image.o
include/os.h +0 -0
index 3ea6d2d..2bb2fb7 100644
@@ -71,3 +71,11 @@ int os_close(int fd);
?* @param exit_code ? ?exit code for U-Boot
?*/
?void os_exit(int exit_code);
include/os.h +8 -1
+
+/**
+ * Acquires some memory from the underlying os.
+ *
+ * \param length ? ? ? Number of bytes to be allocated
+ * \return Pointer to length bytes or NULL on error
+ */
+void *os_malloc(size_t length);
--
1.7.4.1

Matthias Weisser

author

2011-11-05 10:40 UTC #19 lore raw

PATCH v4 1/1 sandbox: Add improved RAM simulation

In reply to Matthias Weisser

Using mmap to allocate memory from the OS for RAM simulation we can use u-boot own malloc implementation.

Signed-off-by Matthias Weisser <[email protected]>

---
Changes in V4:
Rebased to current HEAD

Changes in V3:
Fixed a build warning

Changes in V2:
Removed the address hint for mmap
Removed the special handling of dlmalloc in common Set gd->bd->bi_dram[0].start to 0 again

 arch/sandbox/cpu/os.c    |    7 +++++++
 arch/sandbox/lib/board.c |   17 ++++++++++-------
 common/Makefile          |    3 ---
 include/os.h             |    8 ++++++++
 4 files changed, 25 insertions(+), 10 deletions(-)

arch/sandbox/cpu/os.c +7 -0

index f80faac..b7c3bf5 100644
@@ -25,6 +25,7 @@
 #include <unistd.h>
 #include <sys/types.h>
 #include <sys/stat.h>
+#include <sys/mman.h>
 
 #include <os.h>

@@ -87,3 +88,9 @@ void os_tty_raw(int fd)
 
 	atexit(os_fd_restore);
 }
+
+void *os_malloc(size_t length)
+{
+	return mmap(NULL, length, PROT_READ | PROT_WRITE,
+			MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+}

arch/sandbox/lib/board.c +10 -7

index ae5a517..b7997e9 100644
@@ -45,8 +45,12 @@
 #include <version.h>
 #include <serial.h>
 
+#include <os.h>
+
 DECLARE_GLOBAL_DATA_PTR;
 
+static gd_t gd_mem;
+
 /************************************************************************
  * Init Utilities							*
  ************************************************************************

@@ -147,7 +151,7 @@ void board_init_f(ulong bootflag)
 	uchar *mem;
 	unsigned long addr_sp, addr, size;
 
-	gd = malloc(sizeof(gd_t));
+	gd = &gd_mem;
 	assert(gd);
 
 	memset((void *)gd, 0, sizeof(gd_t));

@@ -158,7 +162,8 @@ void board_init_f(ulong bootflag)
 	}
 
 	size = CONFIG_SYS_SDRAM_SIZE;
-	mem = malloc(size);
+	mem = os_malloc(CONFIG_SYS_SDRAM_SIZE);
+
 	assert(mem);
 	gd->ram_buf = mem;
 	addr = (ulong)(mem + size);

@@ -214,11 +219,9 @@ void board_init_r(gd_t *id, ulong dest_addr)
 	post_output_backlog();
 #endif
 
-#if 0 /* Sandbox uses system malloc for now */
-	/* The Malloc area is immediately below the monitor copy in DRAM */
-	malloc_start = dest_addr - TOTAL_MALLOC_LEN;
-	mem_malloc_init(malloc_start, TOTAL_MALLOC_LEN);
-#endif
+	/* The Malloc area is at the top of simulated DRAM */
+	mem_malloc_init((ulong)gd->ram_buf + gd->ram_size - TOTAL_MALLOC_LEN,
+			TOTAL_MALLOC_LEN);
 
 	/* initialize environment */
 	env_relocate();

common/Makefile +0 -3

index 1b672ad..015c17e 100644
@@ -29,9 +29,6 @@ LIB	= $(obj)libcommon.o
 ifndef CONFIG_SPL_BUILD
 COBJS-y += main.o
 COBJS-y += command.o
-ifndef CONFIG_SANDBOX
-COBJS-y += dlmalloc.o
-endif
 COBJS-y += exports.o
 COBJS-$(CONFIG_SYS_HUSH_PARSER) += hush.o
 COBJS-y += image.o

include/os.h +8 -0

index d5df22f..fd4120c 100644
@@ -76,3 +76,11 @@ void os_exit(int exit_code);
  * Put tty into raw mode to mimic serial console better
  */
 void os_tty_raw(int fd);
+
+/**
+ * Acquires some memory from the underlying os.
+ *
+ * \param length	Number of bytes to be allocated
+ * \return Pointer to length bytes or NULL on error
+ */
+void *os_malloc(size_t length);

Signature · 1 line

1.7.4.1

Simon Glass

2011-11-05 15:05 UTC #20 lore raw

PATCH v4 1/1 sandbox: Add improved RAM simulation

Quoted 4 lines · Matthias Weisser

Using mmap to allocate memory from the OS for RAM simulation we can use u-boot own malloc implementation.
Signed-off-by Matthias Weisser <[email protected]>

Thanks for the rebase

Tested-by Simon Glass <[email protected]>

Quoted 18 lines

---
Changes in V4:
?Rebased to current HEAD
Changes in V3:
?Fixed a build warning
Changes in V2:
?Removed the address hint for mmap
?Removed the special handling of dlmalloc in common ?Set gd->bd->bi_dram[0].start to 0 again
?arch/sandbox/cpu/os.c ? ?| ? ?7 +++++++
?arch/sandbox/lib/board.c | ? 17 ++++++++++-------
?common/Makefile ? ? ? ? ?| ? ?3 ---
?include/os.h ? ? ? ? ? ? | ? ?8 ++++++++
?4 files changed, 25 insertions(+), 10 deletions(-)

Mike Frysinger

2011-11-05 16:47 UTC #21 lore raw

PATCH v4 1/1 sandbox: Add improved RAM simulation

In reply to Matthias Weisser

Acked-by Mike Frysinger <[email protected]>

Mike Frysinger

2011-12-02 17:08 UTC #22 lore raw

PATCH v4 1/1 sandbox: Add improved RAM simulation

In reply to Matthias Weisser

Quoted 2 lines · On Saturday 05 November 2011 06:40:34 Matthias Weisser wrote:

Using mmap to allocate memory from the OS for RAM simulation we can use u-boot own malloc implementation.

i've merged this into my sandbox branch
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20111202/4e37fdd2/attachment.pgp>