[U-Boot] testing u-boot on virtual environment
Hello,
Does anyone know if exists somekind of simulator to run u-boot in test mode?
I also have a spare qoriva platform (MPC5604B-TRK), which can't run linux, but maybe could run uboot just to test some autoboot commands.
Thanks
Hi Érico
On 23/12/11 23:46, Érico Porto wrote:
Hello,
Does anyone know if exists somekind of simulator to run u-boot in test mode?
Have a look at the sandbox 'board' - It allows U-Boot to be run as an executable in Linux to test non hardware specific code
do:
make sandbox_config make all
Regards,
Graeme
Thanks!
Tried to do some memory display commands but got instant segmentation fault, and tried to run it as root - but then some bad things happened, so now I know no one should run it as root.
I wanted to tryout a memory test algorithm I developed, but it seem u-boot runs with no ram access. If I could findout the ram address where it is located, I think then the 8MB it says it has wouldn't give me segmentation fault...
=>version
U-Boot 2011.12-rc3 (Dec 23 2011 - 11:07:12) gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1 GNU ld (GNU Binutils for Ubuntu) 2.21.53.20110810 =>printenv baudrate=115200 stderr=serial stdin=serial stdout=serial
Environment size: 66/8188 bytes =>bdinfo boot_params = 0x00000000 DRAM bank = 0x00000000 -> start = 0x00000000 -> size = 0x08000000 FB base = 0x00000000
On 12/23/11, Graeme Russ graeme.russ@gmail.com wrote:
Hi Érico
On 23/12/11 23:46, Érico Porto wrote:
Hello,
Does anyone know if exists somekind of simulator to run u-boot in test mode?
Have a look at the sandbox 'board' - It allows U-Boot to be run as an executable in Linux to test non hardware specific code
do:
make sandbox_config make all
Regards,
Graeme
md 0 gives me in dmesg:
[11753.433067] u-boot[4277]: segfault at 0 ip 0805283e sp bfb809f0 error 4 in u-boot[8048000+1a000]
On 12/23/11, Érico Porto ericoporto2008@gmail.com wrote:
Thanks!
Tried to do some memory display commands but got instant segmentation fault, and tried to run it as root - but then some bad things happened, so now I know no one should run it as root.
I wanted to tryout a memory test algorithm I developed, but it seem u-boot runs with no ram access. If I could findout the ram address where it is located, I think then the 8MB it says it has wouldn't give me segmentation fault...
=>version
U-Boot 2011.12-rc3 (Dec 23 2011 - 11:07:12) gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1 GNU ld (GNU Binutils for Ubuntu) 2.21.53.20110810 =>printenv baudrate=115200 stderr=serial stdin=serial stdout=serial
Environment size: 66/8188 bytes =>bdinfo boot_params = 0x00000000 DRAM bank = 0x00000000 -> start = 0x00000000 -> size = 0x08000000 FB base = 0x00000000
On 12/23/11, Graeme Russ graeme.russ@gmail.com wrote:
Hi Érico
On 23/12/11 23:46, Érico Porto wrote:
Hello,
Does anyone know if exists somekind of simulator to run u-boot in test mode?
Have a look at the sandbox 'board' - It allows U-Boot to be run as an executable in Linux to test non hardware specific code
do:
make sandbox_config make all
Regards,
Graeme
-- Érico V. Porto
doing md 0805283e works
if I can change the base address now, every memory command should work
On 12/23/11, Érico Porto ericoporto2008@gmail.com wrote:
md 0 gives me in dmesg:
[11753.433067] u-boot[4277]: segfault at 0 ip 0805283e sp bfb809f0 error 4 in u-boot[8048000+1a000]
On 12/23/11, Érico Porto ericoporto2008@gmail.com wrote:
Thanks!
Tried to do some memory display commands but got instant segmentation fault, and tried to run it as root - but then some bad things happened, so now I know no one should run it as root.
I wanted to tryout a memory test algorithm I developed, but it seem u-boot runs with no ram access. If I could findout the ram address where it is located, I think then the 8MB it says it has wouldn't give me segmentation fault...
=>version
U-Boot 2011.12-rc3 (Dec 23 2011 - 11:07:12) gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1 GNU ld (GNU Binutils for Ubuntu) 2.21.53.20110810 =>printenv baudrate=115200 stderr=serial stdin=serial stdout=serial
Environment size: 66/8188 bytes =>bdinfo boot_params = 0x00000000 DRAM bank = 0x00000000 -> start = 0x00000000 -> size = 0x08000000 FB base = 0x00000000
On 12/23/11, Graeme Russ graeme.russ@gmail.com wrote:
Hi Érico
On 23/12/11 23:46, Érico Porto wrote:
Hello,
Does anyone know if exists somekind of simulator to run u-boot in test mode?
Have a look at the sandbox 'board' - It allows U-Boot to be run as an executable in Linux to test non hardware specific code
do:
make sandbox_config make all
Regards,
Graeme
-- Érico V. Porto
-- Érico V. Porto
md 0805283e 0805283e: 4489028b 1beba4bd 7502fb83 028b660d ...D.......u.f.. 0805284e: 7d448966 c0b70fa4 028a09eb a43d4488 f.D}.........D=. 0805285e: 51c0b60f 75ff5047 90558994 059e2568 ...QGP.u..U.h%.. 0805286e: aaefe808 558bffff 10c48390 f739da01 .......U......9. 0805287e: f089b975 af0fff31 0c4501c3 548a1deb u...1.....E....T 0805288e: b60fa43d 89b60fca 08059cdc 7497e180 =..............t 0805289e: 79d28404 3d44c605 39472ea4 50df75c7 ...y..D=..G9.u.P 080528ae: a4458d50 9e2b6850 44c60805 e800a43d P.E.Ph+....D=... 080528be: ffffaaa1 29087d01 25e81475 83ffffab .....}.)u..%.... 080528ce: c08510c4 14eb0874 891b048d 7d839445 ....t.......E..} 080528de: 850f0014 ffffff33 03ebc031 8dffc883 ....3...1....... 080528ee: 5e5bf465 90c35d5f 89559090 0c458be5 e.[^_]....U...E. 080528fe: 5d084589 ffae50e9 e58955ff 0f10458b .E.].P...U...E.. 0805290e: 830c45af e0830fc0 084589f0 b00de95d .E........E.]... 0805291e: 8955ffff 535657e5 8b4cec83 3c6a0c7d ..U..WVS..L.}.j< 0805292e: 68145d8b 08059e33 758df16a 45c756ac .].h3...j..u.V.E =>mtest 0805283e 080528fe Pattern 00000000 Writing... Segmentation Fault
So close..
On 12/23/11, Érico Porto ericoporto2008@gmail.com wrote:
doing md 0805283e works
if I can change the base address now, every memory command should work
On 12/23/11, Érico Porto ericoporto2008@gmail.com wrote:
md 0 gives me in dmesg:
[11753.433067] u-boot[4277]: segfault at 0 ip 0805283e sp bfb809f0 error 4 in u-boot[8048000+1a000]
On 12/23/11, Érico Porto ericoporto2008@gmail.com wrote:
Thanks!
Tried to do some memory display commands but got instant segmentation fault, and tried to run it as root - but then some bad things happened, so now I know no one should run it as root.
I wanted to tryout a memory test algorithm I developed, but it seem u-boot runs with no ram access. If I could findout the ram address where it is located, I think then the 8MB it says it has wouldn't give me segmentation fault...
=>version
U-Boot 2011.12-rc3 (Dec 23 2011 - 11:07:12) gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1 GNU ld (GNU Binutils for Ubuntu) 2.21.53.20110810 =>printenv baudrate=115200 stderr=serial stdin=serial stdout=serial
Environment size: 66/8188 bytes =>bdinfo boot_params = 0x00000000 DRAM bank = 0x00000000 -> start = 0x00000000 -> size = 0x08000000 FB base = 0x00000000
On 12/23/11, Graeme Russ graeme.russ@gmail.com wrote:
Hi Érico
On 23/12/11 23:46, Érico Porto wrote:
Hello,
Does anyone know if exists somekind of simulator to run u-boot in test mode?
Have a look at the sandbox 'board' - It allows U-Boot to be run as an executable in Linux to test non hardware specific code
do:
make sandbox_config make all
Regards,
Graeme
-- Érico V. Porto
-- Érico V. Porto
-- Érico V. Porto
Hi Erico,
Le 23/12/2011 15:03, Érico Porto a écrit :
md 0805283e 0805283e: 4489028b 1beba4bd 7502fb83 028b660d ...D.......u.f.. 0805284e: 7d448966 c0b70fa4 028a09eb a43d4488 f.D}.........D=. 0805285e: 51c0b60f 75ff5047 90558994 059e2568 ...QGP.u..U.h%.. 0805286e: aaefe808 558bffff 10c48390 f739da01 .......U......9. 0805287e: f089b975 af0fff31 0c4501c3 548a1deb u...1.....E....T 0805288e: b60fa43d 89b60fca 08059cdc 7497e180 =..............t 0805289e: 79d28404 3d44c605 39472ea4 50df75c7 ...y..D=..G9.u.P 080528ae: a4458d50 9e2b6850 44c60805 e800a43d P.E.Ph+....D=... 080528be: ffffaaa1 29087d01 25e81475 83ffffab .....}.)u..%.... 080528ce: c08510c4 14eb0874 891b048d 7d839445 ....t.......E..} 080528de: 850f0014 ffffff33 03ebc031 8dffc883 ....3...1....... 080528ee: 5e5bf465 90c35d5f 89559090 0c458be5 e.[^_]....U...E. 080528fe: 5d084589 ffae50e9 e58955ff 0f10458b .E.].P...U...E.. 0805290e: 830c45af e0830fc0 084589f0 b00de95d .E........E.]... 0805291e: 8955ffff 535657e5 8b4cec83 3c6a0c7d ..U..WVS..L.}.j< 0805292e: 68145d8b 08059e33 758df16a 45c756ac .].h3...j..u.V.E =>mtest 0805283e 080528fe Pattern 00000000 Writing... Segmentation Fault
So close..
Please do not top-post.
I don't know what exactly the sandbox 'board' covers, but displaying memory in it has rather little meaning, does it not? Memory mapping and usage is quite board-dependent.
It could help if you indicated what you're trying to achieve by simulation exactly. You might possibly be better off using qemu, for instance.
Amicalement,
Hi,
On Fri, Dec 23, 2011 at 5:53 AM, Érico Porto ericoporto2008@gmail.com wrote:
md 0 gives me in dmesg:
[11753.433067] u-boot[4277]: segfault at 0 ip 0805283e sp bfb809f0 error 4 in u-boot[8048000+1a000]
On 12/23/11, Érico Porto ericoporto2008@gmail.com wrote:
Thanks!
Tried to do some memory display commands but got instant segmentation fault, and tried to run it as root - but then some bad things happened, so now I know no one should run it as root.
Good lesson to learn :-)
There was a revert of the memory map code in cmd_mem.c about a month ago - if you track that down and un-revert it then md will work for you.
The real fix is to devise some third meaning of a memory address (physical address, effective address, ...?) - I did post a suggestion to the list but no response and I haven't got back to it.
Regards, Simon
I wanted to tryout a memory test algorithm I developed, but it seem u-boot runs with no ram access. If I could findout the ram address where it is located, I think then the 8MB it says it has wouldn't give me segmentation fault...
=>version
U-Boot 2011.12-rc3 (Dec 23 2011 - 11:07:12) gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1 GNU ld (GNU Binutils for Ubuntu) 2.21.53.20110810 =>printenv baudrate=115200 stderr=serial stdin=serial stdout=serial
Environment size: 66/8188 bytes =>bdinfo boot_params = 0x00000000 DRAM bank = 0x00000000 -> start = 0x00000000 -> size = 0x08000000 FB base = 0x00000000
On 12/23/11, Graeme Russ graeme.russ@gmail.com wrote:
Hi Érico
On 23/12/11 23:46, Érico Porto wrote:
Hello,
Does anyone know if exists somekind of simulator to run u-boot in test mode?
Have a look at the sandbox 'board' - It allows U-Boot to be run as an executable in Linux to test non hardware specific code
do:
make sandbox_config make all
Regards,
Graeme
-- Érico V. Porto
-- Érico V. Porto _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Hi Simon,
Le 24/12/2011 07:03, Simon Glass a écrit :
Hi,
On Fri, Dec 23, 2011 at 5:53 AM, Érico Portoericoporto2008@gmail.com wrote:
md 0 gives me in dmesg:
[11753.433067] u-boot[4277]: segfault at 0 ip 0805283e sp bfb809f0 error 4 in u-boot[8048000+1a000]
On 12/23/11, Érico Portoericoporto2008@gmail.com wrote:
Thanks!
Tried to do some memory display commands but got instant segmentation fault, and tried to run it as root - but then some bad things happened, so now I know no one should run it as root.
Good lesson to learn :-)
There was a revert of the memory map code in cmd_mem.c about a month ago - if you track that down and un-revert it then md will work for you.
The real fix is to devise some third meaning of a memory address (physical address, effective address, ...?) - I did post a suggestion to the list but no response and I haven't got back to it.
I don't understand why we'd need a third way to map. It's still an issue of physical vs virtual mapping, only in the sandbox case the phys-vs-virt mapping should be done through the mmap()/munmap() OS services (which at the moment it does not). Or am I missing something else?
OTOH, while reading the sandbox board config header, I see this:
/* Memory things - we don't really want a memory test */
Seems to me like it comforts my comment that having 'effective' (in the sense of 'having an actual effect') memory access commands does not make much sense for sandbox -- it's an application in Linux and as such could barely use physical memory unless it is reserved for it, which on a pure development host is improbable: either the reserved memory is mundane RAM and it would best be allocated to the sandbox app as BSS or data, or it is actually mapped to some HW module and you had better make sure the underlying Linux kernel never ever uses this module.
But since the goal of sandbox is only to test U-Boot commands, not perform actual bootloader tasks, it can test md/mw etc. with some big array of RAM correctly 'mapped' to the working area defined through CONFIG_SYS_MEMTEST_START and CONFIG_SYS_MEMTEST_END.
I think mmap() allows the callerto suggest a value for the returned pointer, but it is only a suggestion, so you can never be sure what actual address the test RAM area will have in sandbox. But you can always set a pair env vars with the actual values and write the md/mw etc. tests so that they uses these values.
Regards, Simon
Amicalement,
Am 24.12.2011 11:00, schrieb Albert ARIBAUD:
I don't understand why we'd need a third way to map. It's still an issue of physical vs virtual mapping, only in the sandbox case the phys-vs-virt mapping should be done through the mmap()/munmap() OS services (which at the moment it does not). Or am I missing something else?
OTOH, while reading the sandbox board config header, I see this:
/* Memory things - we don't really want a memory test */
Seems to me like it comforts my comment that having 'effective' (in the sense of 'having an actual effect') memory access commands does not make much sense for sandbox -- it's an application in Linux and as such could barely use physical memory unless it is reserved for it, which on a pure development host is improbable: either the reserved memory is mundane RAM and it would best be allocated to the sandbox app as BSS or data, or it is actually mapped to some HW module and you had better make sure the underlying Linux kernel never ever uses this module.
Don't forget that we have commands like tftpboot or fatload which both get an address where to load the data. At least tftpboot is working with my tap patch and USB should also be possible. So we may need to touch more then just the memory commands to get the current situation fixed.
But since the goal of sandbox is only to test U-Boot commands, not perform actual bootloader tasks, it can test md/mw etc. with some big array of RAM correctly 'mapped' to the working area defined through CONFIG_SYS_MEMTEST_START and CONFIG_SYS_MEMTEST_END.
I think mmap() allows the callerto suggest a value for the returned pointer, but it is only a suggestion, so you can never be sure what actual address the test RAM area will have in sandbox. But you can always set a pair env vars with the actual values and write the md/mw etc. tests so that they uses these values.
This was the way my original patch worked. It passed an address to mmap which was unlikely to not match the returned address as far as I know the typical linux process address space layout. The actual address was then readable with the bdinfo command. Another possible solution would be to assert when the address passed to mmap is not the same as the returned address.
I think we should still think of sandbox as a tool which eases debugging and shouldn't let it influence "real" systems by adding code to these systems which is not needed.
Matthias
Indeed, qemu seems to be the best option. I've also downloaded aqemu to help to build a system configuration fast. Not sure how to load mine ltib generated BSP... Will try a simple env with u-boot only just for now..
Érico V. Porto
2011/12/24 Matthias Weißer m.weisser.m@googlemail.com
Am 24.12.2011 11:00, schrieb Albert ARIBAUD:
I don't understand why we'd need a third way to map. It's still an issue of physical vs virtual mapping, only in the sandbox case the phys-vs-virt mapping should be done through the mmap()/munmap() OS services (which at the moment it does not). Or am I missing something
else?
OTOH, while reading the sandbox board config header, I see this:
/* Memory things - we don't really want a memory test */Seems to me like it comforts my comment that having 'effective' (in the sense of 'having an actual effect') memory access commands does not make much sense for sandbox -- it's an application in Linux and as such could barely use physical memory unless it is reserved for it, which on a pure development host is improbable: either the reserved memory is mundane RAM and it would best be allocated to the sandbox app as BSS or data, or it is actually mapped to some HW module and you had better make sure the underlying Linux kernel never ever uses this module.
Don't forget that we have commands like tftpboot or fatload which both get an address where to load the data. At least tftpboot is working with my tap patch and USB should also be possible. So we may need to touch more then just the memory commands to get the current situation fixed.
But since the goal of sandbox is only to test U-Boot commands, not perform actual bootloader tasks, it can test md/mw etc. with some big array of RAM correctly 'mapped' to the working area defined through CONFIG_SYS_MEMTEST_START and CONFIG_SYS_MEMTEST_END.
I think mmap() allows the callerto suggest a value for the returned pointer, but it is only a suggestion, so you can never be sure what actual address the test RAM area will have in sandbox. But you can always set a pair env vars with the actual values and write the md/mw etc. tests so that they uses these values.
This was the way my original patch worked. It passed an address to mmap which was unlikely to not match the returned address as far as I know the typical linux process address space layout. The actual address was then readable with the bdinfo command. Another possible solution would be to assert when the address passed to mmap is not the same as the returned address.
I think we should still think of sandbox as a tool which eases debugging and shouldn't let it influence "real" systems by adding code to these systems which is not needed.
Matthias _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Hi Érico
Am 23.12.2011 14:19, schrieb Érico Porto:
Thanks!
Tried to do some memory display commands but got instant segmentation fault, and tried to run it as root - but then some bad things happened, so now I know no one should run it as root.
I wanted to tryout a memory test algorithm I developed, but it seem u-boot runs with no ram access. If I could findout the ram address where it is located, I think then the 8MB it says it has wouldn't give me segmentation fault...
You could try to change the address passed to the mmap in os.c: 92 void *os_malloc(size_t length) from NULL to something known. 0x20000000 worked well for me when I added the RAM simulation. The approach of a fixed RAM address was nacked for mainline but for tests I still use this approach.
Matthias
participants (5)
-
Albert ARIBAUD -
Graeme Russ -
Matthias Weißer -
Simon Glass -
Érico Porto