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.weisse...@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 >
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot