[U-Boot] testing u-boot on virtual environment

[U-Boot] testing u-boot on virtual environment

[Érico Porto]

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

[U-Boot] testing u-boot on virtual environment

[Graeme Russ]

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

[U-Boot] testing u-boot on virtual environment

[É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...

=>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

[U-Boot] testing u-boot on virtual environment

[Érico Porto]

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

[U-Boot] testing u-boot on virtual environment

[Érico 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
>


-- 
?rico V. Porto

[U-Boot] testing u-boot on virtual environment

[Érico 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
>


-- 
?rico V. Porto

[U-Boot] testing u-boot on virtual environment

[Matthias Weißer]

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

[U-Boot] testing u-boot on virtual environment

[Albert ARIBAUD]

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.

[U-Boot] testing u-boot on virtual environment

[Simon Glass]

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

[U-Boot] testing u-boot on virtual environment

[Albert ARIBAUD]

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.

[U-Boot] testing u-boot on virtual environment

[Matthias Weißer]

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] testing u-boot on virtual environment

[Érico Porto]

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
>