BCM2711 peripherals: please mention address bases for "low peripherals" mode

[MrMino]

The address sections in BCM2711 Peripherals manual don't explicitly mention low peripherals addresses. E.g. GPIO base is given as 0x7e20 0000, whereas when booting with the default config (I guess I'm running the default?) it is 0xfe20 0000

Stylistically, the "low peripherals" mode seems to be mentioned as a "secondary", and it's only explained in the first chapter. It is very easy to miss this if someone jumps to some later chapters just to get a reference.

It would be a lot easier to use the manual if both addresses were mentioned along each other.

I'm a bit new to bare metal, so I'm not sure if this is something that would be considered "adding bloat" to the documentation, but I think it could save newbs like me some head-desking.

On the upside, TIL what's data abort and how to attach gdb to qemu thanks to this :).

[lurch]

I suspect we probably won't be changing the BCM2711 PDF to accomodate this, as it's fairly low on our priority list.
If you read over Chapter 1 of https://datasheets.raspberrypi.com/bcm2711/bcm2711-peripherals.pdf a few times, you should be able to figure out how everything works? (And yes, I'm aware that it's very confusing at first! 🤣 )

You may also find https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#peripheral-addresses and the various addresses displayed in https://github.com/raspberrypi/linux/blob/rpi-5.10.y/arch/arm/boot/dts/bcm2711.dtsi useful?

And for questions about bare-metal stuff, asking questions in the appropriate subsection of https://forums.raspberrypi.com/ might be the quickest route to answers.

ping @pelwell in case he wants to add anything.

[MrMino]

Thanks! I already figured it out, I opened this issue to maybe pave the path for others.

Feel free to close it if you feel it isn't necessary to add this information :).

[pelwell]

@MrMino will probably already have found that the addresses in bcm2711.dtsi are misleading unless one knows enough to interpret the ranges property:

		ranges = <0x7e000000  0x0 0xfe000000  0x01800000>,
			 <0x7c000000  0x0 0xfc000000  0x02000000>,
			 <0x40000000  0x0 0xff800000  0x00800000>;

Taking the first column as hardware base addresses (bus addresses) and the last column as sizes, you can see that hardware addresses between 0x7e000000 and 0x7f7fffff are covered by the first line, and 0x40000000-0x407fffff by the last line.
For any given address, once you have found the corresponding line in the table, subtract the first column and add the third (and the second as the upper 32-bits, but there always 0 here) to get the addresses as seen from the ARMs.

Let's take two examples from that section of the .dtsi file: interrupt-controller@40041000 and avs-monitor@7d5d2000. N.B. Although the portion after the @ is an address, it is just a naming convention - the real address comes from the reg property, but you should complain loudly if you find nodes where the two don't match).

For the first example, 0x40041000 translates to an offset of 0x41000 from 0xff800000, i.e. 0xff841000.
Similarly, 0x7d5d2000 is 0x015d2000 from 0xfc000000, i.e. 0xfd5d2000.