TDA4VM: High address access in uboot

Hi Johnson,

We do NOT access high address from U-Boot. Can you please give more details on which exact part of U-Boot are you adding this?

There are three parts to it it. MCU Domain R5 SPL --> A72 SPL --> A72 U-Boot. 

Can you share the patch that you have added to U-Boot code? That will help us analyze better.

Best Regards,
Keerthy

Hi Johnson,

 The 0x44_0000_0000 is like a virtual address, I tried  we can't access it directly.  could you please provide the context,  we can provide more feedback to you. 

Best regards,

LINJUN

pcie_atu_r5.c
pcie_atu_uboot.c

Hi keerthy,

The specific code refers to the two files I uploaded;

The specific instructions are as follows:

1): pcie_atu_r5.c is the code running in r5, pcie_atu_uboot.c is the code running in a72 uboot.

2): pcie2 function is the initialization code of TDA4 PCIE2 controller. Before configuring PCIE2_CONTROL related registers, rc and ep are in the linkup state.

3): After configuring PCIE2_CONTROL related registers, we read back the registers to ensure that the value set by the register is successful, and the values set and read back in r5 and uboot are the same. 4): The high address is accessed through rat in r5, see the rat setting in the r5 code for details

5): The code PCIE_logPrintf ("ep vid:0x%x\n",*route_base); is the vid requesting to read the ep configuration space. It runs normally in r5 and can read the ep vid correctly. But it will crash when running in uboot, so we suspect that there are certain restrictions when directly accessing high addresses in uboot.

The above information hopes to help you understand and analyze the issues we raised.    

Hi jun:

for more information please refer the msg reply to keerthy. thanks.

Hi Billy,

Suggestion from our PCIe expert is to use the PCIe 128MB which has < 32 bit address. Are you able to use that in your U-Boot code?
Is the issue only with the higher address i.e 0x44_0000_0000?

Keerthy J said:

We do NOT access high address from U-Boot. Can you please give more details on which exact part of U-Boot are you adding this?

This was w.r.t R5 my bad. From A72 we are able to access 0x880000000. Thanks for pointing out.

Best Regards,
Keerthy

U-Boot file:

arch/arm/mach-k3/arm64-mmu.c

Has all the mmu mappings.

struct mm_region j721e_mem_map[NR_MMU_REGIONS] = {

Can you try adding the region you want to access to the above map?

- Keerthy

hi keerthy:

   We set up the MMU with the following patch, there is no coredump msg print, but uboot will get stuck without any information 。Please help confirm whether the patch settings are correct 。thanks

diff --git a/arch/arm/mach-k3/arm64-mmu.c b/arch/arm/mach-k3/arm64-mmu.c
index 94242e1e5c..c5bd1b2406 100644
--- a/arch/arm/mach-k3/arm64-mmu.c
+++ b/arch/arm/mach-k3/arm64-mmu.c
@@ -112,6 +112,12 @@ struct mm_region j721e_mem_map[NR_MMU_REGIONS] = {
                .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
                         PTE_BLOCK_NON_SHARE |
                         PTE_BLOCK_PXN | PTE_BLOCK_UXN
+       }, {
+               .virt = 0x4400000000UL,
+               .phys = 0x4400000000UL,
+               .size = 0x0008000000UL,
+               .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL_NC) |
+                        PTE_BLOCK_INNER_SHARE
        }, {
                .virt = 0x4d80000000UL,
                .phys = 0x4d80000000UL,

regards

johnson

 the #define NR_MMU_REGIONS (CONFIG_NR_DRAM_BANKS+6) should change to #define NR_MMU_REGIONS (CONFIG_NR_DRAM_BANKS+7).