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

Albert ARIBAUD
2011-12-24T10:00:32Z

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.