Why only 2GB of RAM is mapped by UBOOT in T2080 RDB when the other 2 GB is mapped

[manishraturi]

Hi Team,

in sdk 1.8 I can see that only 2GB of RAM is mapped by the UBOOT , what is the reason behind it ?

if I MAP 4 GB what problems I will face..?

Thanks & Regards

Manish Raturi

[evaneimer]

Manish,

 Did you ever get to the point where the OS/Kernel/Linux saw 4G?  If so, what are the steps/configuration that you needed to do to get this to work?

Thanks.

[Bulat]

I believe there were two main reasons for 2GB memory size. First is a historical one: this really comes from 32-bit address times. Second: 2GB memory is enough for uboot. I also believe that it will not create a problem for uboot if you map 4GB of memory.

Your follow-up questions are not so clear, you use a term "kernel". It looks like you already ask about an OS, not uboot? Uboot will pass correct memory size to the OS (even if 2GB were initially mapped), e.g. 4GB if such a DIMM is detected on the board.

Regards,

Bulat

[scottwood]

Yes, it will create a problem if you map 4 GiB -- you won't have any virtual address space left for I/O.  Yes, it is fully correct for T2080.  "Outside of lowest 4GB memory space" exists only for physical addresses, since U-Boot uses 32-bit virtual addresses.

[manishraturi]

Hi Bulat,

Thanks for the reply , and sorry for my terminology , I mean OS when I say kernel.

So you are saying if we map 2GB out of 4GB of DDR DIMM module in UBOOT and if we load the OS then OS will automatically know the 4 GB memory on board and we need not to change the memory map for the OS.

My understanding is this:

If we are only mapping 2GB of RAM to UBOOT and using the next 2 GB to map the other peripherals. Then when we transition from UBOOT to the OS then we need to establish different memory map in OS(different from what we have in UBOOT). Now here 4GB of the address will be taken by the DDR itself. Is it not TRUE..?

I am new to UBOOT and T2080 also I am  first time making the memory map for the system having 4GB of DDR and other peripherals.

Thanks & Regards

Manish Raturi

[Bulat]

Yes, in our case the OS will know actual memory size, e.g. 4GB, and will set up MMU/TLB in accordance with this size. Note that uboot sets correct memory size in the DDR controller and Local Access Windows, 2GB size is restricted in the MMU only.

I would add that statement "mapping 2GB of RAM to UBOOT and using the next 2 GB to map the other peripherals" is not fully correct in case of the T2080. As you noticed, uboot uses 36-bit addressing, and all "other peripheral" is mapped outside of lowest 4GB memory space.

Regards,

Bulat

[manishraturi]

Hi Bulat,

I am summarizing my understanding in the below mail, please let me know if it is correct.

We are making a new card using T2080 and  we have purchased the T2080 RDB board for doing some hands on. Our board will have some different interfaces with respect to reference board(T2080RDB).

So with your suggestions I have prepared a memory map for our system as shown below:

1) CS0  -> Boot Flash

-> F_E800_0000 - F_F7FF_FFFF -> 256 MB

2) CS1  -> Control FPGA 1 -> F_F800_0000 - F_F80F_FFFF -> 1 MB

3) CS2  -> Control Fpga 2 -> F_F810_0000 - F_F81F_FFFF -> 1 MB

4) CS3  -> Control Fpga 3 -> F_F820_0000 - F_F82F_FFFF -> 1 MB

5) CS4  -> Framer 1	-> F_F830_0000 - F_F83F_FFFF -> 1 MB
6) CS5  -> Framer 2	-> F_F840_0000 - F_F84F_FFFF -> 1 MB

7) CS6  -> spare to move boot flash when secure boot comes into picture

8) CS7  -> spare

9) n/a  -> DDR 3	-> 0_0000_0000  - 0_ffff_ffff -> 4 GiB  /*In boot loader (UBOOT) I will map 2 GiB only*/
10)n/a  -> CCSBAR	-> F_FE00_0000  - F_FEFF_FFFF -> 16 MB
11)n/a  -> PCIe1 MEM	-> C_0000_0000  - C_1FFF_FFFF -> 512 MB
12)n/a  -> PCIe2 MEM	-> C_2000_0000  - C_2FFF_FFFF -> 256 MB
13)n/a  -> PCIe 1 I/O	-> F_F850_0000  - F_F85F_FFFF -> 1 MB
14)n/a  -> PCIe 2 I/O	-> F_F860_0000  - F_F86F_FFFF -> 1 MB

So I can retain this memory map in OS. But as I need to access 4 GiB of space in kernel I will need to recreate a TLB entry for 4 GiB space.

Any other thing which I need to take care ?

Also let suppose If I want to address my control FPGA 1 register which is map at this location (F_F800_0000 - F_F80F_FFFF) from kernel I can use this address F800_0000(effective address) instead of F_F800_0000(physical address) for accessing the FPGA register. Please let me know if my understanding is correct.?

[Bulat]

1) I think thememory map is ok. Since the total memory size of all listed devices is less than 4GB (assuming DDR3 takes 2GB in uboot), you can map all devices to 32-bit virtual memory space in uboot.

2) Question about FPGA mapping is related to OS. Typically the user can NOT set correspondence between virtual and physical addresses on kernel level.

Regards,

Bulat

[scottwood]

U-Boot is 32-bit and thus can only address 2 GiB of RAM (with the other half of the address space reserved for I/O).  This does not affect your ability to address all of RAM once you've booted an OS.

[manishraturi]

Hi Scott,

Thanks for the reply. Is it true that UBOOT is 32 bit because I find some documentation which says that UBOOT can be build for 36-bit as well. Please correct me on this. Also my bdinfo gives me the following result:

=> bdinfo

memstart    = 0x00000000

memsize     = 0x100000000

flashstart  = 0xE8000000

flashsize   = 0x08000000

flashoffset = 0x00000000

sramstart   = 0x00000000

sramsize    = 0x00000000

immr_base   = 0xFE000000

bootflags   = 0x00000000

intfreq     = 1533.180 MHz

busfreq     = 599.940 MHz

addressing  = 36-bit

ethaddr     = 00:04:9F:03:47:D4

IP addr     = 192.168.0.3

baudrate    = 115200 bps

relocaddr   = 0x7FEF0000

Where I can see the addressing used is 36-bit. Why it is so when UBOOT is 32 bit..?

So mapping 4GB to kernel what all things I need to change..?

One thing which I am thinking is to recreate the TLB entry for DDR again in the kernel where EPN value will be 0x0000_0000 and the RPN will be 0x0_0000_0000 is my understanding correct..? What else is required we need to do inside the kernel?

Thanks & Regards

Manish Raturi

[scottwood]

When I said that U-Boot is 32-bit, I was referring to the size of an effective (virtual) address.  "36-bit addressing" refers to the size of a physical address.