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

[Érico Porto]

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