AM5728: Jailhouse Hypervisor error

Hi Nir,

The kernel dump basically tells ARM still access the GPMC module which is not accessible. I will check the Linux kernel to see if there is anything other change needed other than the DTS to disable GPMC. I will keep you posted.

Hi,

Just wanted to add that I made sure that when running the RTOS application native, and when running it as a jailhouse inmate, the pinctrl is identical in both cases.

Not sure if this is of any help.

Waiting for your post.

Thanks,

Nir.

Nir,

Please try to apply the following kernel patch to see if the kernel dump still happens.

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 24fcc874b2c9..ea3237f1397d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -4567,7 +4567,6 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = {
        &dra7xx_l4_per1__gpio6,
        &dra7xx_l4_per1__gpio7,
        &dra7xx_l4_per1__gpio8,
-       &dra7xx_l3_main_1__gpmc,
        &dra7xx_l3_main_1__gpu,
        &dra7xx_l4_per1__hdq1w,
        &dra7xx_l4_per1__i2c1,

Hi,

The kernel dump still comes up.

Thanks,

Nir.

Hi Nir,

please undo the previous hwmod patch but try to add "ti,no-idle;" in the gpmc DT node which you disabled. If it doesn't solve the issue, what is the gpmc interrupt number used in RTOS inmate application? Did you skip it in the DTS file?

Hi,

I reverted the previous patch and added "ti,no-idle" to the GPMC node.

The dump still occurs.

My RTOS app doesn't use GPMC interrupt. We use polling method, but still I skipped the GPMC interrupt number 20, and passed it to the 

RTOS inmate cell.

The dump still occurs.

Thanks,

Nir.

Hi Bin,

According to AM572x Technical Reference Manual, page 3558, GPMC Error Handling, the registers GPMC_ERR_TYPE and GPMC_ERR_ADDRESS hold some precious data in case of an error.

After the system is powered up these two registers hold the value zero, and after the dump occurs for the first time I read these values:

root@am57xx-evm:~#
root@am57xx-evm:~# devmem2 0x50000044
/dev/mem opened.
Memory mapped at address 0xb6f80000.
Read at address 0x50000044 (0xb6f80044): 0x40413430
root@am57xx-evm:~#
root@am57xx-evm:~#
root@am57xx-evm:~# devmem2 0x50000048
/dev/mem opened.
Memory mapped at address 0xb6f55000.
Read at address 0x50000048 (0xb6f55048): 0x00000211
root@am57xx-evm:~#

Meaning that a read was attempted of the unsupported address 0x50413430 in the GPMC registers address space.

I'm going along with case 3 and some problems come up, maybe you can help me sort them out...

I'm using CCS to debug the A15 core1 on which the RTOS jailhouse inmate is running, and I set a HW watchpoint on 0x50413430.

When I attempt to intentionally read this address from the RTOS side, the watchpoint is caught, and when I allow the core to continue running I get the familiar dump from the kernel. The mentioned GPMC registers hold exactly the same values as if  the real error happened.

When the error comes up spontaneously though, the watchpoint doesn't get caught, which brings me to the conclusion that the source is NOT the RTOS inmate running on A15 core1.

Now I'm using CCS to debug the A15 core0 on which Linux is running as the root cell, and I set a HW watchpoint on 0x50413430.

When I attempt to intentionally read this address with devmem2, I get the familiar dump from the kernel, but the watchpoint doesn't get caught.

When the error comes up spontaneously, the watchpoint doesn't get caught either.

In order to find out if the source of the dump is indeed the Linux, I first have to make sure that watchpoints work.

Only after that I'll be able to determine if the origin of the real error is indeed the Linux side.

Can you please advise?

Thanks a lot,

Nir.

Just wanted to add that when debugging A15 core0, and setting HW watchpoint in the RAM address space (0xB0000000), and reading it with devmem2

the read was successful and the watchpoint didn't caught either.

Thanks,

Nir.

Hi,

Thanks for your answer on 

In this case, I really have no idea how to translate physical address to a virtual address. I have no idea which process is causing the dump..

But anyway, I took a different approach and decided to use the hypervisor root cell config to completely block Linux from accessing the GPMC registers address space.

After doing so, I can't read or write the registers GPMC_ERR_TYPE and GPMC_ERR_ADDRESS because the hypervisor immediately parks cpu 0, obviously.

However, the dump still happens.

No other core or DSP is activated besides A15 core0 and 1.. 

Any idea what else I can test?

Thanks,

Nir.

Hi,

The dump happens when I run RTOS on core1.

The thing is, that I ran the RTOS inmate while debugging core 1 with CCS, and placing a HW watchpoint on the address 0x50413430.

When the dump came out the watchpoint didn't get caught, which leads to the conclusion that core1 doesn't perform the read attempt.

What else might be causing this? 

Hi Nir,

I am a Linux guy and not familiar with RTOS. But I believe when you attach CCS/JTAG and set the HW watchpoint, it only monitors the activities between A15 core1 and L3, it won't catch any access from other cores, for example DSP or DMA...

That's my understanding as well.

Therefore, when I'm running RTOS inmate on A15 core1, and debugging core1 with CCS, and setting HW watchpoint on some address, and the watchpoint doesn't get caught, it leads me to conclude that RTOS is not responsible for the dump from the linux kernel.

DSP is not activated.

Can you tell me more about DMA? can I trap accesses done by DMA to GPMC registers address space?

Thanks.

Hi Nir,

Here is the response I got from internal about DMA access to GPMC address space - based on the ARM documentation, the Hardware breakpoint is a comparator between a CPU bus access and a memory address. So it is almost certain that a DMA access will not trigger the breakpoint (watchpoint).