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

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

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.