sameh4
Posts: 25
Joined: Wed Nov 29, 2017 6:58 pm

Physical Address Mapping on the Pi3

Thu Dec 07, 2017 1:41 am

In past two days I am researching Memory Mapped IO to fully understand the basic ACT LED examples for RPi A+ and Zero.

I have been reading the Peripherals manual and I have one question plus I would like to ensure I've understood correctly. So far it's going better than I expected :D

https://www.raspberrypi.org/app/uploads ... herals.pdf

Now, GPFSEL4 is a 32 bit address starting @ 0x20200010 with the bits between 23-21 representing the 47th GPIO pin. The 21'st bit should be set to 1 and the others to zero to make the pin behave as an outputs pin (vs input or alternate function like SA1 from the Alternate Functions table in the manual).

GPSET 0 and 1 together are 64 bits that represent setting the actual pin to either 0 or 1. So left shifting the number 15 by one produces a 32 bit number where the 16th bit is 1 and all others are 0. Setting the address of GPSET1 to this makes the 47th pin 1 because it's the second set of pins, meaning 31 + 16 = 47.

Have I understood all that correctly?

Where does it say that the 47'th pin is for the ACT LED?

Finally in the below paragraph:
Physical addresses range from 0x20000000 to 0x20FFFFFF for peripherals. The bus
addresses for peripherals are set up to map onto the peripheral bus address range starting at
0x7E000000. Thus a peripheral advertised here at bus address 0x7Ennnnnn is available at
physical address 0x20nnnnnn.
I understand the difference between the address bus vs the data bus. But I can't find a good reference on the difference between a physical address and a bus address. The only one I've found is here https://unix.stackexchange.com/a/71422

Nevertheless, the address translation is simple enough. So when I see 0x7E200000 for GPFSEL0 it really means 0x20000000 for bare metal purposes. Fair enough...

LdB
Posts: 583
Joined: Wed Dec 07, 2016 2:29 pm

Re: Physical Address Mapping on the Pi3

Thu Dec 07, 2017 3:23 am

sameh4 wrote:
Thu Dec 07, 2017 1:41 am
GPSET 0 and 1 together are 64 bits that represent setting the actual pin to either 0 or 1. So left shifting the number 15 by one produces a 32 bit number where the 16th bit is 1 and all others are 0. Setting the address of GPSET1 to this makes the 47th pin 1 because it's the second set of pins, meaning 31 + 16 = 47.
That is all very confused

You actually mean 32 + 15 = 47

There are 54 IO ports controls mapped
GPSET0 Bits 0 .. 31 (32 bits) control IO ports 0 .. 31
GPSET1 Bits 0 .. 21 (22bits) control IO ports 32 .. 53

For the control mask in GPSELx control you left shift 7 (not 15) as each entry is 3 bits

if gpio is you port number you can write the mask bit as
mask = (7 << ((gpio % 10) * 3));

Which of the GFSEL is gpio / 10
Nevertheless, the address translation is simple enough. So when I see 0x7E200000 for GPFSEL0 it really means 0x20000000 for bare metal purposes. Fair enough...
There are two processors on the same BUS, the ARM is actually a coprocessor to the GPU. The GPU actually does all the bootloading.
The other address given is the GPU address this get back to what I was trying to explain with the mailbox address offset.

2 processors = 2 different addresses to the same location in memory depending which processor you are referring from.

dwelch67
Posts: 848
Joined: Sat May 26, 2012 5:32 pm

Re: Physical Address Mapping on the Pi3

Thu Dec 07, 2017 9:41 am

you almost exactly have it right it is 47-32=15th bit

Where does it say the 47th bit is the led? in some broadcom schematic we dont have access to. or in the linux port from broadcom that someone dug through to figure this out. There may be some documentation at this point that we have visibility to, but as expected broadcom keeps everything secret and we have to do extra work to get information, either ask on this forum and someone works there with access and tells us or someone reverse engineers something or stumbles on the right line in a document that might not be a document you expect, or in rare cases they actually give us a schematic with enough information on it.

Code: Select all

    ra=GET32(GPFSEL4);
    ra&=~(7<<21);
    ra|=1<<21;
    PUT32(GPFSEL4,ra);

    while(1)
    {
        PUT32(GPSET1,1<<(47-32));
        for(ra=0;ra<0x100000;ra++) dummy(ra);
        PUT32(GPCLR1,1<<(47-32));
        for(ra=0;ra<0x100000;ra++) dummy(ra);
    }
the document is really written for the gpu it appears as that is the address space for the gpu, we have a window into that space which moved so yes for the pizero and older/est pi chips, we replace the 0x7E with 0x20. generic system/chip decoding has nothing to do with arm or x86 or whatever, someone does the system design they determine there are x registers or a y sized address space for this perpiheral and we are going to place it here, as you move from the peripheral to the processor you build/layer address spaces, the layers to get to the gpu where they wanted the peripherals in a high address space ended up at the last layer at 0x7E, for the arm we are behind an L2 cache to us if you will, and the arm space is quartered and in that quarter they wanted the perihperals high-ish in the address space (all of this is obvious from their addressing choices, I dont have an internal knowledge, its also fairly generic from a system design perspective) although not forward thinking enough to put high enough. when moving to a 64 bit arm processor they could have used the extra address bits and changed how they quartered the space, but then the 32 bit mode wouldnt work and early on if not still they use a 32 bit linux port not 64 bit. so if they were to continue making pi designs, and adding more ram, they would either need to abandon the quarter of a 32 bit address space (for the four caching modes they hardcoded us into) or use more than 32 bits of address space and quarter that. for example if they used 33 then things we see at 0x40000000 would now be at 0x080000000 (mailboxes, etc). allowing for 0x80000000 per quarter and perhaps then move the peripherals to 0x7E000000 to get them out of the way allowing for twice the ram as a prior generation.

in short yes when you see 0x7Exxxxxx on the oldest pi processor replace that with 0x20xxxxxx on the others we know of to date replace with 0x3Fxxxxxx (older pi2 and current pi2 and current pi3).

sameh4
Posts: 25
Joined: Wed Nov 29, 2017 6:58 pm

Re: Physical Address Mapping on the Pi3

Thu Dec 07, 2017 3:44 pm

@LdB: I think I get what you mean now. In my previous post I had the Mailbox address as 0x3f00b880

@Dave: I was looking at that bit of code on Github yesterday while looking at the manual and that's how I understood what I was reading.

To clarify one thing I wrote: it is the 15th bit (47-32), so if we left shift 1 by 15 we end up with:

Code: Select all

$ python
bin((1<<(47-32))).lstrip('-0b').zfill(32).find('1')
16
Which makes sense because the indices of the first address (in bits as a string) are 0 to 31. Then it's the 16th index of the second string of bits, so it's 31 + 16 = 47. It's just how I worked it out yesterday having a python background.

I hope more and more of what you said about the GPU addressing and chip design makes more sense I read more and more manuals. Next up I am looking at your uart02 example and the chapter 2 of the manual.

Thanks again to both of you guys!

sameh4
Posts: 25
Joined: Wed Nov 29, 2017 6:58 pm

Re: Physical Address Mapping on the Pi3

Fri Dec 08, 2017 1:25 am

I've since learned that is wrong since I am looking at the index from the wrong direction. It's right to left and not left to right as I counted.

Return to “Bare metal”

Who is online

Users browsing this forum: No registered users and 5 guests