This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TDA4VM: Unable to handle kernel paging request

Part Number: TDA4VM

Hi, 

On our custom board we are experiencing some issue while booting Linux. Linux boot fails with a kernel panic and the error message: "Unable to handle kernel paging request at virtual address ". 

See below for an example of the error: 

It is not always the same virtual address the paging fails on and it changes on different boot iterations. 

So far, as we use 8Gb RAM, we have adapted U-Boot and RTOS PDK memory configuration as documented in the Jacinto 7 DDRSS Register Configuration Tool: https://www.ti.com/lit/an/spracu8/spracu8.pdf?ts=1635504871631&ref_url=https%253A%252F%252Fe2e.ti.com%252F

Are there additional steps to take into account order to configure the memory properly?

I have seen the following e2e post: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/950628/tda4vm-tda4vm-how-to-config-mt53e768m32d4dt-3gb-ddr-on-tda4vm/3516412?tisearch=e2e-sitesearch&keymatch=ram_size#3516412 which highlights a couple more steps to take if the RAM has a reduced size compared to the EVM. Are there similar steps to take in case RAM size is increased?

For now, we have not modified any Linux or SDK memory map related configuration. What would be the required steps to do so in order to adapt to 8Gb? 

Are there additional configurations to take into account which might cause this issue?

Thank you and Best Regards,

Max

  • Hi Max,

    Can you please share the complete boot log on the failing board starting from SPL prints? Also please share the patches that you have done
    on top tp support 8GB memory?

    Do the default images work on your board without doing any modifications(I mean 4GB)?

    - Keerthy

  • Hi Keerthy,

    Please find the boot log for 8GB here: 

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    U-Boot SPL 2021.01 (Nov 12 2021 - 16:35:58 +0100)
    Model: Texas Instruments K3 J721E SoC
    Board: J721EX-PM2-SOM rev E8
    SYSFW ABI: 3.1 (firmware rev 0x0015 '21.5.0--v2021.05 (Terrific Llam')
    Trying to boot from MMC2
    Starting ATF on ARM64 core...
    NOTICE: BL31: v2.5(release):08.00.00.004-dirty
    NOTICE: BL31: Built : 22:30:09, Aug 4 2021
    U-Boot SPL 2021.01 (Nov 12 2021 - 16:41:05 +0100)
    Model: Texas Instruments K3 J721E SoC
    Board: J721EX-PM2-SOM rev E8
    SYSFW ABI: 3.1 (firmware rev 0x0015 '21.5.0--v2021.05 (Terrific Llam')
    Trying to boot from MMC2
    U-Boot 2021.01 (Nov 12 2021 - 16:41:05 +0100)
    SoC: J721E SR2.0
    Model: Texas Instruments K3 J721E SoC
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    We updated the RTOS PDK registers settings as follows:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    --- board_ddrRegInit_EVM.h 2021-10-01 14:29:48.248504904 +0200
    +++ board_ddrRegInit.h 2021-11-11 09:24:24.192371058 +0100
    @@ -1,4424 +1,4424 @@
    -/* Copyright (c) 2019, Texas Instruments Incorporated
    - *
    - * Redistribution and use in source and binary forms, with or without
    - * modification, are permitted provided that the following conditions
    - * are met:
    - *
    - * * Redistributions of source code must retain the above copyright
    - * notice, this list of conditions and the following disclaimer.
    - *
    - * * Redistributions in binary form must reproduce the above copyright
    - * notice, this list of conditions and the following disclaimer in the
    - * documentation and/or other materials provided with the distribution.
    - *
    - * * Neither the name of Texas Instruments Incorporated nor the names of
    - * its contributors may be used to endorse or promote products derived
    - * from this software without specific prior written permission.
    - *
    - * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    For u-boot we used this patch initially to update to 8GB

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    --- bk_evm.c 2021-11-15 14:08:31.503777868 +0100
    +++ evm.c 2021-11-15 14:09:52.307775021 +0100
    @@ -50,9 +50,9 @@
    int dram_init(void)
    {
    #ifdef CONFIG_PHYS_64BIT
    - gd->ram_size = 0x100000000;
    + gd->ram_size = 0x200000000;
    #else
    - gd->ram_size = 0x80000000;
    + gd->ram_size = 0x100000000;
    #endif
    return 0;
    @@ -73,14 +73,14 @@
    {
    /* Bank 0 declares the memory available in the DDR low region */
    gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
    - gd->bd->bi_dram[0].size = 0x80000000;
    - gd->ram_size = 0x80000000;
    + gd->bd->bi_dram[0].size = 0x100000000;
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    However with 8GB configuration, we are unsure on the proper u-boot update of the device tree memory node in k3-j721e-som-p0.dtsi  and the mmu in arch/arm/mach-k3/arm64-mmu.c

    As an experiment we reduced the capacity to 2Gb and followed the steps outlined in: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/950628/tda4vm-tda4vm-how-to-config-mt53e768m32d4dt-3gb-ddr-on-tda4vm/3516412?tisearch=e2e-sitesearch&keymatch=ram_size#3516412

    Please find the patch for 2 GB here: 

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    diff --git a/ti-processor-sdk-linux-j7-evm-08_00_00_08/board-support/u-boot-2021.01+gitAUTOINC+53e79d0e89-g53e79d0e89/arch/arm/dts/k3-j721e-som-p0.dtsi b/ti-processor-sdk-linux-j7-evm-08_00_00_08/board-support/u-boot-2021.01+gitAUTOINC+53e79d0e89-g53e79d0e89/arch/arm/dts/k3-j721e-som-p0.dtsi
    index c12353a92..29452533a 100644
    --- a/ti-processor-sdk-linux-j7-evm-08_00_00_08/board-support/u-boot-2021.01+gitAUTOINC+53e79d0e89-g53e79d0e89/arch/arm/dts/k3-j721e-som-p0.dtsi
    +++ b/ti-processor-sdk-linux-j7-evm-08_00_00_08/board-support/u-boot-2021.01+gitAUTOINC+53e79d0e89-g53e79d0e89/arch/arm/dts/k3-j721e-som-p0.dtsi
    @@ -10,9 +10,8 @@
    / {
    memory@80000000 {
    device_type = "memory";
    - /* 4G RAM */
    - reg = <0x00000000 0x80000000 0x00000000 0x80000000>,
    - <0x00000008 0x80000000 0x00000000 0x80000000>;
    + /* 2G RAM */
    + reg = <0x00000000 0x80000000 0x00000000 0x80000000>;
    };
    reserved_memory: reserved-memory {
    diff --git a/ti-processor-sdk-linux-j7-evm-08_00_00_08/board-support/u-boot-2021.01+gitAUTOINC+53e79d0e89-g53e79d0e89/arch/arm/mach-k3/arm64-mmu.c b/ti-processor-sdk-linux-j7-evm-08_00_00_08/board-support/u-boot-2021.01+gitAUTOINC+53e79d0e89-g53e79d0e89/arch/arm/mach-k3/arm64-mmu.c
    index 94242e1e5..cbf26e54c 100644
    --- a/ti-processor-sdk-linux-j7-evm-08_00_00_08/board-support/u-boot-2021.01+gitAUTOINC+53e79d0e89-g53e79d0e89/arch/arm/mach-k3/arm64-mmu.c
    +++ b/ti-processor-sdk-linux-j7-evm-08_00_00_08/board-support/u-boot-2021.01+gitAUTOINC+53e79d0e89-g53e79d0e89/arch/arm/mach-k3/arm64-mmu.c
    @@ -70,7 +70,8 @@ struct mm_region *mem_map = am654_mem_map;
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    We dont have an EEPROM on our board, so we mocked the response.

    Patching to 2GB results in a similar error, see below for 2GB boot log:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    U-Boot SPL 2021.01 (Nov 11 2021 - 14:41:08 +0100)
    Model: Texas Instruments K3 J721E SoC
    Board: J721EX-PM2-SOM rev E8
    SYSFW ABI: 3.1 (firmware rev 0x0015 '21.5.0--v2021.05 (Terrific Llam')
    Trying to boot from MMC2
    Starting ATF on ARM64 core...
    NOTICE: BL31: v2.5(release):08.00.00.004-dirty
    NOTICE: BL31: Built : 22:30:09, Aug 4 2021
    U-Boot SPL 2021.01 (Nov 11 2021 - 14:42:44 +0100)
    Model: Texas Instruments K3 J721E SoC
    Board: J721EX-PM2-SOM rev E8
    SYSFW ABI: 3.1 (firmware rev 0x0015 '21.5.0--v2021.05 (Terrific Llam')
    Trying to boot from MMC2
    U-Boot 2021.01 (Nov 11 2021 - 14:42:44 +0100)
    SoC: J721E SR2.0
    Model: Texas Instruments K3 J721E SoC
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    If we do not change the capacity at all and use the default 4GB  configuration, we get stuck here:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    U-Boot 2021.01-g53e79d0e89 (Aug 04 2021 - 22:33:28 +0000)
    SoC: J721E SR2.0
    Model: Texas Instruments K3 J721E SoC
    Board: J721EX-PM2-SOM rev E8
    DRAM:
    U-Boot SPL 2021.01 (Nov 12 2021 - 16:35:58 +0100)
    Model: Texas Instruments K3 J721E SoC
    Board: J721EX-PM2-SOM rev E8
    SYSFW ABI: 3.1 (firmware rev 0x0015 '21.5.0--v2021.05 (Terrific Llam')
    Trying to boot from MMC2
    Starting ATF on ARM64 core...
    NOTICE: BL31: v2.5(release):08.00.00.004-dirty
    NOTICE: BL31: Built : 22:30:09, Aug 4 2021
    U-Boot SPL 2021.01 (Nov 12 2021 - 16:41:05 +0100)
    Model: Texas Instruments K3 J721E SoC
    Board: J721EX-PM2-SOM rev E8
    SYSFW ABI: 3.1 (firmware rev 0x0015 '21.5.0--v2021.05 (Terrific Llam')
    Trying to boot from MMC2
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    The default images for 4GB  do not work on our board. Trying it out results in a timeout during frequency handshake:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    U-Boot SPL 2021.01-g53e79d0e89 (Aug 04 2021 - 23:32:00 +0000)
    Model: Texas Instruments K3 J721E SoC
    EEPROM not available at 0x50, trying to read at 0x51
    Reading on-board EEPROM at 0x51 failed 1
    Board: J721EX-PM1-SOM rev E2
    SYSFW ABI: 3.1 (firmware rev 0x0015 '21.5.0--v2021.05 (Terrific Llam')
    EEPROM not available at 0x50, trying to read at 0x51
    Reading on-board EEPROM at 0x51 failed 1
    Timeout during frequency handshake
    ### ERROR ### Please RESET the board ###
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Thank you and Best Regards,

    Max

  • Hi Max,

    A few initial thoughts:

    1. I see you are already using a reduced frequency configuration (-3200 data rate instead of -4266 data rate), and this appears to get you further in the boot process than the default TDA4VM EVM configuration. Can you also try a slower frequency (maybe -2133 data rate)? If it passes, this might help point to an SI issue instead of a functional / code issue.
    2. Larger density memories generally have larger refresh cycle times. Can you double check the tRFC timing value entered in the DRAMTiming tab of the register configuration tool and ensure it is set correctly for the memory on your custom board?
    3. Can you try the changes below to see if any impact? Unfortunately these changes are not configurable via the register configuration tool. Since you are using the RTOS header file output, you will need to find the lines in the header file that correspond to the registers listed below. All of these registers are a part of the DDRSS_phyReg array, and the register number corresponds to the array element. In other words, DDRSS_PHY_33_DATA corresponds to DDRSS_phyReg[33]. 
    • For below registers, change the '7' to a '6' as shown below

    #define DDRSS_PHY_33_DATA 0x0C002006
    #define DDRSS_PHY_289_DATA 0x0C002006
    #define DDRSS_PHY_545_DATA 0x0C002006
    #define DDRSS_PHY_801_DATA 0x0C002006

    • For below registers, change the '20' to a '40' as shown below

    #define DDRSS_PHY_32_DATA 0x10400000
    #define DDRSS_PHY_288_DATA 0x10400000
    #define DDRSS_PHY_544_DATA 0x10400000
    #define DDRSS_PHY_800_DATA 0x10400000

    Regards,
    Kevin

  • HI Kevin,

    Thank you for your feedback. We double checked the memory configuration and identified the DDR Density per channel to be misconfigured. We updated both Density and Refresh Timings and tried booting our board with the updated boot binaries. The frequency for this attempt is still configured to -3200 data rate and we will check lower frequencies next.

    Unfortunately the boot up fails even earlier with the new settings. Please find the boot log below:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    U-Boot SPL 2021.01 (Nov 18 2021 - 11:03:21 +0100)
    Model: Texas Instruments K3 J721E SoC
    Board: J721EX-PM2-SOM rev E8
    SYSFW ABI: 3.1 (firmware rev 0x0015 '21.5.0--v2021.05 (Terrific Llam')
    Trying to boot from MMC2
    Starting ATF on ARM64 core...
    ti_sci dmsc@44083000: ti_sci_get_response: Message receive failed. ret = -110
    ti_sci dmsc@44083000: Mbox send fail -110
    Failed to put device 262 (-110)
    resetting ...
    ti_sci dmsc@44083000: ti_sci_get_response: Message receive failed. ret = -110
    ti_sci dmsc@44083000: Mbox send fail -110
    ti-sci-sysreset sysreset-controller: ti_sci_sysreset_request: reboot_device failed (-110)
    ti_sci dmsc@44083000: ti_sci_get_response: Message receive failed. ret = -110
    ti_sci dmsc@44083000: Mbox send fail -110
    ti-sci-sysreset sysreset-controller: ti_sci_sysreset_request: reboot_device failed (-110)
    ti_sci dmsc@44083000: ti_sci_get_response: Message receive failed. ret = -110
    ti_sci dmsc@44083000: Mbox send fail -110
    ti-sci-sysreset sysreset-controller: ti_sci_sysreset_request: reboot_device failed (-110)
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
     

    Do you have an idea what could cause this issue? 

    For your information we use Micron DDR MT53D512M32D2DS-053 AAT:D

    Thank you and Best Regards,

    Max

  • Hi Kevin, 

    please ignore the previous post. The error above was caused by a corrupt path to bl31.bin so it wasn't properly included in the build. This has been fixed.

    Furthermore we managed to get past the initial error reported in this post by reducing the frequency down to -2133 data rate. The error message  "Unable to handle kernel paging request" does not appear anymore. 

    You mentioned this might help point to an SI issue. Do you have an idea or hint what the issue might be in this case?

    For now, we can boot up until the point where the rootfs is supposed to be mounted. However we are getting stuck at " Waiting for root device PARTUUID=06b81fb2-02..."

    Please find the boot log below: 

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    U-Boot 2021.01 (Nov 18 2021 - 15:58:54 +0100)
    SoC: J721E SR2.0
    Model: Texas Instruments K3 J721E SoC
    Board: J721EX-PM2-SOM rev E8
    DRAM: ^@
    U-Boot SPL 2021.01 (Nov 18 2021 - 16:14:50 +0100)
    Model: Texas Instruments K3 J721E SoC
    Board: J721EX-PM2-SOM rev E8
    SYSFW ABI: 3.1 (firmware rev 0x0015 '21.5.0--v2021.05 (Terrific Llam')
    Trying to boot from MMC2
    Starting ATF on ARM64 core...
    NOTICE: BL31: v2.5(release):08.00.00.004-dirty
    NOTICE: BL31: Built : 22:30:09, Aug 4 2021
    U-Boot SPL 2021.01 (Nov 18 2021 - 16:16:27 +0100)
    Model: Texas Instruments K3 J721E SoC
    Board: J721EX-PM2-SOM rev E8
    SYSFW ABI: 3.1 (firmware rev 0x0015 '21.5.0--v2021.05 (Terrific Llam')
    Trying to boot from MMC2
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Any idea what might be the issue or should we post this issue in another thread?

    Thank you and Best Regards,

    Max

  • Hello Max,

    As already mentioned to your team, our Jacinto 7 LPDDR4 design application note (link)  covers the signal integrity issues among others.

    Since you have opened another thread about your system being stuck in "Waiting for root device...", I will close this thread and we will pursue the debugging on your new thread.


    Best regards,
    François.