Thank you for your response. Is there any way we can put code in u-boot to handle the abort? Thanks, Greg ________________________________________ From: Sascha Hauer [s.hauer@xxxxxxxxxxxxxx] Sent: Monday, April 18, 2011 3:29 AM To: Greg Topmiller Cc: barebox@xxxxxxxxxxxxxxxxxxx Subject: Re: Imx51 processor hangs when we do an md 0xf0000000 (memory display) in u-boot On Sat, Apr 16, 2011 at 11:14:13AM -0700, Greg Topmiller wrote: > We're are using the Freescale release L2.6.31_MX51_SDK_0912_Image and > it will do this on a Freescale Babbage board and our design. It also > does the same thing in Linux when we mmap the address 0xf0000000 and > try to read from it. It does not hang on the Redboot.bin image > supplied with the Freescale SDK. The Redboot dump command displays > some data. On the Freescale 3Stack board we get an illegal address > error in Redboot, but it will hang in u-boot. We realize this is a > reserved physical address but would hope that an error of some kind > would occur rather than locking up the CPU. Could it be some sort of > MMU initialization difference between Redboot and u-boot? I have no idea how redboot maps the memory in the mmu, but barebox and u-boot use a 1:1 mapping which results in the behaviour you see. Accessing reserved memory can result in a abort. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
