* [U-Boot] testing u-boot on virtual environment @ 2011-12-23 12:46 Érico Porto 2011-12-23 12:57 ` Graeme Russ 0 siblings, 1 reply; 12+ messages in thread From: Érico Porto @ 2011-12-23 12:46 UTC (permalink / raw) To: u-boot 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 -- ?rico V. Porto ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] testing u-boot on virtual environment 2011-12-23 12:46 [U-Boot] testing u-boot on virtual environment Érico Porto @ 2011-12-23 12:57 ` Graeme Russ 2011-12-23 13:19 ` Érico Porto 0 siblings, 1 reply; 12+ messages in thread From: Graeme Russ @ 2011-12-23 12:57 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] testing u-boot on virtual environment 2011-12-23 12:57 ` Graeme Russ @ 2011-12-23 13:19 ` Érico Porto 2011-12-23 13:53 ` Érico Porto 2011-12-23 15:03 ` Matthias Weißer 0 siblings, 2 replies; 12+ messages in thread From: Érico Porto @ 2011-12-23 13:19 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] testing u-boot on virtual environment 2011-12-23 13:19 ` Érico Porto @ 2011-12-23 13:53 ` Érico Porto 2011-12-23 14:00 ` Érico Porto 2011-12-24 6:03 ` Simon Glass 2011-12-23 15:03 ` Matthias Weißer 1 sibling, 2 replies; 12+ messages in thread From: Érico Porto @ 2011-12-23 13:53 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] testing u-boot on virtual environment 2011-12-23 13:53 ` Érico Porto @ 2011-12-23 14:00 ` Érico Porto 2011-12-23 14:03 ` Érico Porto 2011-12-24 6:03 ` Simon Glass 1 sibling, 1 reply; 12+ messages in thread From: Érico Porto @ 2011-12-23 14:00 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] testing u-boot on virtual environment 2011-12-23 14:00 ` Érico Porto @ 2011-12-23 14:03 ` Érico Porto 2011-12-23 15:03 ` Albert ARIBAUD 0 siblings, 1 reply; 12+ messages in thread From: Érico Porto @ 2011-12-23 14:03 UTC (permalink / raw) To: u-boot 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 > -- ?rico V. Porto ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] testing u-boot on virtual environment 2011-12-23 14:03 ` Érico Porto @ 2011-12-23 15:03 ` Albert ARIBAUD 0 siblings, 0 replies; 12+ messages in thread From: Albert ARIBAUD @ 2011-12-23 15:03 UTC (permalink / raw) To: u-boot 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, -- Albert. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] testing u-boot on virtual environment 2011-12-23 13:53 ` Érico Porto 2011-12-23 14:00 ` Érico Porto @ 2011-12-24 6:03 ` Simon Glass 2011-12-24 10:00 ` Albert ARIBAUD 1 sibling, 1 reply; 12+ messages in thread From: Simon Glass @ 2011-12-24 6:03 UTC (permalink / raw) To: u-boot 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 at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] testing u-boot on virtual environment 2011-12-24 6:03 ` Simon Glass @ 2011-12-24 10:00 ` Albert ARIBAUD 2011-12-24 10:58 ` Matthias Weißer 0 siblings, 1 reply; 12+ messages in thread From: Albert ARIBAUD @ 2011-12-24 10:00 UTC (permalink / raw) To: 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 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. 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, -- Albert. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] testing u-boot on virtual environment 2011-12-24 10:00 ` Albert ARIBAUD @ 2011-12-24 10:58 ` Matthias Weißer 2011-12-24 20:06 ` Érico Porto 0 siblings, 1 reply; 12+ messages in thread From: Matthias Weißer @ 2011-12-24 10:58 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] testing u-boot on virtual environment 2011-12-24 10:58 ` Matthias Weißer @ 2011-12-24 20:06 ` Érico Porto 0 siblings, 0 replies; 12+ messages in thread From: Érico Porto @ 2011-12-24 20:06 UTC (permalink / raw) To: u-boot 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 at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] testing u-boot on virtual environment 2011-12-23 13:19 ` Érico Porto 2011-12-23 13:53 ` Érico Porto @ 2011-12-23 15:03 ` Matthias Weißer 1 sibling, 0 replies; 12+ messages in thread From: Matthias Weißer @ 2011-12-23 15:03 UTC (permalink / raw) To: 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2011-12-24 20:06 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-12-23 12:46 [U-Boot] testing u-boot on virtual environment Érico Porto 2011-12-23 12:57 ` Graeme Russ 2011-12-23 13:19 ` Érico Porto 2011-12-23 13:53 ` Érico Porto 2011-12-23 14:00 ` Érico Porto 2011-12-23 14:03 ` Érico Porto 2011-12-23 15:03 ` Albert ARIBAUD 2011-12-24 6:03 ` Simon Glass 2011-12-24 10:00 ` Albert ARIBAUD 2011-12-24 10:58 ` Matthias Weißer 2011-12-24 20:06 ` Érico Porto 2011-12-23 15:03 ` Matthias Weißer
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.