Current u-boot memory mapping

U-Boot RgC 2 participants 3 messages Oct 27, 2012 – Oct 31, 2012

Share & tools

RgC

author

2012-10-27 11:17 UTC #0 lore raw

Hi All,

Last week I got a weird problem on an ARM platfrom.
It is using an old version of u-boot because of our design/implementation cycle, but let's not talk about upgrading the u-boot version that I use please.

My understanding of the u-boot memory mapping is in question :-)
I've dealt with the early versions (v1.x.x) on PowerPC and ARM. I'm now dealing with newer u-boot versions but mostly on the PowerPC arch. So I'm not sure if everything I know applies to the ARM arch.

In the PowerPC arch, after relocation the actual memory mapping follows the "Memory Management" section in the u-boot README. Bottom of RAM for exception handlers, then free space until we reach near the top of RAM. This is populated by the stack, global data, malloc-area, and the u-boot code. My understanding is that this design was never altered and was implemented across all platforms.

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?

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.

All the best,
RgC

-------------- 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/20121027/e6c514cf/attachment.pgp>

Tom Rini

2012-10-29 18:13 UTC #1 lore raw

On Sat, Oct 27, 2012 at 08:17:00PM +0900, RgC wrote:

[snip]

Quoted 2 lines

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.

Quoted 3 lines

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?

Signature · 8 lines

Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20121029/d16a5600/attachment.pgp>

RgC

author

2012-10-31 21:49 UTC #2 lore raw

Hi,

Thanks for the comments Tom.

Quoted 8 lines · Tom Rini

On Sat, Oct 27, 2012 at 08:17:00PM +0900, RgC wrote:
[snip]
Quoted 2 lines
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.

Quoted 9 lines

Quoted 4 lines
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 :-)

Quoted 3 lines

Signature · 2 lines
-- 
Tom

All the best,
Rommel