The 0x1_0000_0000 is really not an address (kind of... it is an address offset with an index into the bridge number, but I've tried to explain below). There are ranges defined in the device tree for each soft IP core connected to the H2F and LW_H2F bridges. Here is an example device tree source snippet:
ranges = <0x00000000 0x00400000 0xc0400000 0x00040000>,
<0x00000000 0x10000000 0xd0000000 0x10000000>,
<0x00000001 0x00004000 0xff204000 0x00004000>,
<0x00000001 0x00000000 0xff200000 0x00000100>,
<0x00000001 0x00000130 0xff200130 0x00000008>,
<0x00000001 0x00000120 0xff200120 0x00000010>,
<0x00000001 0x00000110 0xff200110 0x00000010>,
<0x00000001 0x00000100 0xff200100 0x00000010>;
The first 32bit value (on each line) is the bridge the IP is connected to: 0x00000000 is the H2F bridge and 0x00000001 is the LW_H2F.
The second 32bit value is the address offset from that bridge base address.
The third 32bit value is the address of that IP as seen by the Cortex-A9.
The fourth 32bit value is the size of the address space in bytes.
For example, the led_pio in your address map above would most likely show with the following ranges:
<0x00000001 0x00010040 0xff210040 0x00000010>,
The onchip ram in your example would show with these ranges settings:
<0x00000000 0x00000000 0xc0000000 0x00010000>,
The first two 32bit values concatenated together yields the numbers you've mentioned.
I hope this helps!