BCM2835 Memory Map

[stuporhero]

One of the things I've been thinking about with OS development on the RasPi is how the memory is layed out (start address, GPU memory block, any memory regions generally not a good idea to write to) and wondered if there was a memory map of how the BCM2835 presents itself after initial GPU initialization? That way I'm not clearing any memory areas I shouldn't be!

[Gert van Loo]

Don't worry: You can't.
The GPU memory your not allowed to touch you can't touch.

[Burngate]

According to my understanding (which probably has no relation to reality) on startup, the GPU sets itself up, then starts the ARM, and provides it with memory-management such that the ARM sees a continuous memory-space from 0 to x, and can also see the same memory as pages. (It also wouldn't surprise me to find out that the ARM doesn't really exist until the GPU has booted, only being a set of registers and such like until the GPU joins it all together!)
My question would be: out of the 128MB the PoP has, how much is the ARM left with?

[jamesh]

How much memory is allocated to each device can be specified - not sure how - might be a compile time option on the GPU code.

The GPU sees a contiguous memory space. It tells the Arm when it boots which bit it can use, and the Arm memory manager takes over in that area only. Any references outside that area are a page fault. Note a contiguous memory space to the Arm may not be a physical contiguous memory space as the Arm memory manager will be shuffling things around. The GPU always sees a contiguous space, it has no HW memory manager.

[stuporhero]

Thanks for the info guys!

@Burngate I imagine that the memory space left would be 128MB/256MB minus the GPU blob size. Can anyone divulge if this is true and also what the size of the blob is?

[Burngate]

(Quick adjustment to picture held in brain) The Arm starts from cold from vector at 0x00000000? So it must be able to see that. Whether that's actually at that location or somewhere else in the GPU's memory map is neither here nor there - and unknowable because it's Broadcom-land. Also the Arm must think it's got some contiguous memory, even if the GPU actually hands it effectively random chunks from its own space - since we can't see what the GPU sees, it's of no interest.
Dredging stuff up from my own memory (Narrowcom?) the Arm expects vectors at
0 (reset),
4 (undefined instruction),
8 (SWI),
C (Prefetch abort),
10 (Data abort),
14 (Address exception),
18 (IRQ) &
1C (FIQ)
So they must exist as far as the Arm is concerned, as must where they point to when the kernel has loaded.
Sorry - thinking out loud here - and my vague idea of memory-management comes from how the original Archimedes chip-set worked ~1990

[Burngate]

I believe (from another place) the blob is c. 10MB on the SD card, but I would also assume it needs its own workspace, so its bite of the cherry would be larger. We Need to Know (arrogance surfaces) the figures. Actually it would be interesting, though Need is relative.

another place is a dark and forbidding land. Travellers rarely return from there

[ukscone]

I thought it was something like 18MB for the blob (forget where i read it but 18 does stick in my mind somehow) and the video ram is shared with the arm too so you need to take that out of the mix as well. One of jamesh's early posts of the alphaboard booting showed 80MB free for the arm but that was yonks ago and nothing was optimised

[jamesh]

The amount the GPU needs is dependant on the use case. If you are using a high megapixel camera, it needs more memory to store temporary buffers etc.

The split can be changed as required at boot I believe.

The GPU binary is less than 2MB, but does need some further DLL type libraries which are only loaded as required e.g. camera drivers.

[ukscone]

@jamesh ah great. don't know where i got the 18Mb from then

[Burngate]

Quote from jamesh on November 21, 2011, 16:19
The split can be changed as required at boot I believe.
Changed by us (as in a linux script or similar) or Broadcom?
The GPU binary is less than 2MB, but does need some further DLL type libraries which are only loaded as required e.g. camera drivers.
And those libraries are in the linux bit?

80MB free sounds good to me; more would be a bonus but 80's good

[mard0]

Quote from ukscone on November 21, 2011, 16:05
I thought it was something like 18MB for the blob (forget where i read it but 18 does stick in my mind somehow) and the video ram is shared with the arm too so you need to take that out of the mix as well. One of jamesh's early posts of the alphaboard booting showed 80MB free for the arm but that was yonks ago and nothing was optimised

Which model was this 128mb or 256mb? and im guessing this is only CLI?

[hippy]

Quote from ukscone on November 21, 2011, 16:05
I thought it was something like 18MB for the blob (forget where i read it but 18 does stick in my mind somehow)


That's what it says on the Wiki - "The GPU blob is an 18MB as an elf file, plus libraries. It does an awful lot" - http://elinux.org/RaspberryPiBoard

[ukscone]

Quote from hippy on November 21, 2011, 18:07
Quote from ukscone on November 21, 2011, 16:05
I thought it was something like 18MB for the blob (forget where i read it but 18 does stick in my mind somehow)


That's what it says on the Wiki - "The GPU blob is an 18MB as an elf file, plus libraries. It does an awful lot" - http://elinux.org/RaspberryPiBoard

Ah thanks. i'm not going nuts then after all

[tufty]

Quote from jamesh on November 21, 2011, 15:10
The GPU sees a contiguous memory space. It tells the Arm when it boots which bit it can use, and the Arm memory manager takes over in that area only. Any references outside that area are a page fault.
Ah. Interesting.

I'm currently in a situation where I need to find out how much memory I have available, which means I need to deal with this. From what you're saying, can I assume that the ARM MMU is preconfigured by the GPU before my kernel is loaded?

[jamesh]

Quote from ukscone on November 21, 2011, 18:45
Quote from hippy on November 21, 2011, 18:07
Quote from ukscone on November 21, 2011, 16:05
I thought it was something like 18MB for the blob (forget where i read it but 18 does stick in my mind somehow)


That's what it says on the Wiki - "The GPU blob is an 18MB as an elf file, plus libraries. It does an awful lot" - http://elinux.org/RaspberryPiBoard

Ah thanks. i'm not going nuts then after all

That's an ELF file with debugging info. Stripped out release builds are less than 2MB.

[jamesh]

Quote from tufty on November 22, 2011, 09:40
Quote from jamesh on November 21, 2011, 15:10
The GPU sees a contiguous memory space. It tells the Arm when it boots which bit it can use, and the Arm memory manager takes over in that area only. Any references outside that area are a page fault.
Ah. Interesting.

I'm currently in a situation where I need to find out how much memory I have available, which means I need to deal with this. From what you're saying, can I assume that the ARM MMU is preconfigured by the GPU before my kernel is loaded?

Well, it's told the memory it will have available, if that's what you mean by preconfigured.

I think if you assume the GPU will use 32MB that wouldn't be far off. That's all the original VC3 had. The VC4 usually has 128 but only needs all of that in extreme use cases.