From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Sat, 24 Dec 2011 11:00:32 +0100 Subject: [U-Boot] testing u-boot on virtual environment In-Reply-To: References: <4EF47AA9.4020802@gmail.com> Message-ID: <4EF5A2C0.2050104@aribaud.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Simon, Le 24/12/2011 07:03, Simon Glass a ?crit : > Hi, > > On Fri, Dec 23, 2011 at 5:53 AM, ?rico Porto 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 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.