[U-Boot] Current u-boot memory mapping

[RgC]

Hi,

Thanks for the comments Tom.

On 2012.10/29, Tom Rini wrote:
> On Sat, Oct 27, 2012 at 08:17:00PM +0900, RgC wrote:
> 
> [snip]
> > My understanding is that after relocation no area between the bottom
> > and the top of RAM is reserved. We can use it freely. Is this correct?
> 
> Basically, yes.  You can use 'bdinfo' to see what / where things are
> being used at run-time.

Yep I've been using the bdinfo output as reference to support my understanding.

> 
> > If writing to the the "free area" in RAM results in crashing u-boot
> > then there is problem in the relocation procedure or a possible linker
> > script problem.
> 
> Well, it depends on how you trigger that crash.  If you're writing near
> where U-Boot is running you can overwrite yourself pretty easily.  If
> you aren't, then are you sure you've configured your memory controller
> correctly?

I think the memory controller has been configured correct if it wasn't a
HW based auto-mem check will fail. The mem check goes through all the
whole mem and performs a write/readback check.

I'm using the memory area very well above the interrupt vectors and very well
below the malloc arena/stack area of u-boot. Crash gets triggerred only when
doing large memory writes (i.e. 16Mb fatload to mem buffer), which ends up writting
over a magical area. 'mw' to the area results in the same crash.

Since the relocation code looks bogus and proprietary (not sure why the original
person who created the code made it that way) it is what I am suspecting. It
was supposed to be based on the Versatile relocation code but it doesn't look
anything like it.

I don't handle that part so I have very little say in the possible problem. I
can only suggest for them to fix it :-)

> 
> -- 
> Tom

All the best,
Rommel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20121101/56bdec30/attachment.pgp>