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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot