u-boot sandbox crash

Hello,

I think this segfault below is not wanted?

$ ./MAKEALL sandbox
Configuring for sandbox board...
   text    data     bss     dec     hex filename
 131497    6048   28488  166033   28891 ./u-boot

--------------------- SUMMARY ---------------------------- Boards compiled: 1
----------------------------------------------------------
marex at mashiro:~/U-Boot/u-boot-marex$ ./u-boot

U-Boot 2011.12-00509-ge7dc4f9 (Mar 18 2012 - 03:10:34)

DRAM: 128 MiB
Using default environment

In:    serial
Out:   serial
Err:   serial

=>base
Base Address: 0x00000000
=>md 0
00000000:Segmentation fault

Best regards,
Marek Vasut

this is because the change to make this work was reverted. i think ppc is broken, but haven't gone through the details to figure things out.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120318/91c29d74/attachment.pgp>

Dear Mike Frysinger,

I see.

Hrm ... I wish I'd be able to figure out how to run PPC/Taihu or PPC/Bamboo U- Boot in QEMU.

Best regards,
Marek Vasut

Hi,

It's because sandbox has a 128MB memory region, which is just created using malloc(). We want address 0 to refer to the first byte of this region.

I did create a patch to fix this, which used the map_physmem() to get the address in the md command. However, ppc expects that the md command just blindly uses the address it is given (i.e. assume it is already a virtual address if the MMU is on, and a physical address if not). I suspect other archs would have the same requirement if they ever mapped virtual memory differently to physical memory.

I did post about it at the time. My proposed fix was to introduce the idea of mapping an 'apparent' address. This would be a 1-1 mapping for all architectures except sandbox, which would map it into its malloc'd memory.

It's a little unfortunate that sandbox has to be the only thing with a mapping, though. Partly that's why I haven't sent a patch. Taken to its logical conclusion then any memory access that the user requests would end up going through this veneer. But I don't have any better ideas yet.

If you're interested, the original patch was here:

http://patchwork.ozlabs.org/patch/121815/

Regards,
Simon