Hi Simon,
Le 24/12/2011 07:03, Simon Glass a écrit :
Hi,
On Fri, Dec 23, 2011 at 5:53 AM, Érico Portoericoporto2008@gmail.com 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 Portoericoporto2008@gmail.com 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,