[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