• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 99 subscribers
  • Views 135 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

AM6442: GPMC 16 bit read issue

AM6442: How to suppress prefetch-reads from a 16 bit GPMC interface under Linux?

Mario Trams
Prodigy 170 points
Part Number: AM6442
Other Parts Discussed in Thread: TMDS64EVM, SK-AM64B

Tool/software:

Hello,

when working with the 16 bit GPMC interface I'm seeing two back-to-back reads from the interface, despite there is read of just a 16 bit word (aka short aka int16_t) by the process. I.e. when reading from address 0, there is also read from address 1, but the result from address 1 becomes discarded, obviously. Writing a 16 bit word is resulting in a single write as expected. So that's fine.

The access to the GPMC window is simply done through an mmapped area from /dev/mem.

I found the problem described here as well:  AM6442: GPMC 16 bit read issue 

There is also linked a more in-depth explanation here: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/316742/am335x-gpmc-phantom-chip-select-generation/1106520#1106520

In fact, the theory behind is clear to me. However, I do not know how to implement the according settings with this pgprot-stuff. I'm afraid that this can only be done through a device driver...

Are there any advises how to accomplish that?

Thanks,

Mario

  • +1
    TI__Guru**** 168291 points

    Hi Mario,

    Which revision of the AM6442 do you use? The U-Boot log prints the silicon revision.

    Please note that SR1.0 has errata i2313 that GPMC read access has to be 32-bit.

  • 0 in reply to Bin Liu
    Prodigy 170 points

    Hi Bin!

    Thanks for that hint! The output of U-Boot is:

    SoC:   AM64X SR1.0 GP

    So this seems to be the issue here.

    Btw., this is errate i2313.

    So assuming that later silicon revisions do not have this errata, there are no additional precautions required with this pgprot-stuff? I'm asking because the problem description I cited above ( AM6442: GPMC 16 bit read issue ) was also dedicated to the AM6442. Though, there was not really a solution in this short discussion but just that link to a rather older thread dealing about the AM335x.

    At the moment I can deal with that situation - it just hurts performance a little bit.

    Greetings,

    Mario 

  • 0 in reply to Mario Trams
    TI__Guru**** 168291 points

    Hi Mario,

    Mario Trams said:
    Btw., this is errate i2313.

    Thanks!. I will correct my typo above to avoid confusion for any future reading.

    Mario Trams said:
    So assuming that later silicon revisions do not have this errata, there are no additional precautions required with this pgprot-stuff? I'm asking because the problem description I cited above ( AM6442: GPMC 16 bit read issue ) was also dedicated to the AM6442.

    I wasn't involved in the i2313 issue debugging and don't know the exact timeline, but I believe the conversation in this referred e2e thread was happened before the issue i2313 was understood, so the pgprot was something trying to understand the issue.

    Mario Trams said:

    Thanks for that hint! The output of U-Boot is:

    SoC:   AM64X SR1.0 GP

    So this seems to be the issue here.

    Issue i2313 doesn't affect SR2.0. Do you have SR2.0 processor to check if the second 16-bit read does no longer happen so that we are certain the issue you see is indeed due to i2313?

    SR1.0 is no longer supported in the current SDK, I believe every customer should go production with SR2.0 by now.

  • 0 in reply to Bin Liu
    Prodigy 170 points

    Hi Bin,

    Bin Liu said:
    I wasn't involved in the i2313 issue debugging and don't know the exact timeline, but I believe the conversation in this referred e2e thread was happened before the issue i2313 was understood, so the pgprot was something trying to understand the issue.

    Ok, I see. 

    Bin Liu said:
    Issue i2313 doesn't affect SR2.0. Do you have SR2.0 processor to check if the second 16-bit read does no longer happen so that we are certain the issue you see is indeed due to i2313?

    Momentarily, as for the AM6442 I've only one TMDS64GPEVM here in order to sort out basic things prior to going into our own hardware design. There's also an AM64SK and right now I don't know what revision is soldered there. But that eval kit is not suitable for the tasks to be done anyway.

    Bin Liu said:
    SR1.0 is no longer supported in the current SDK, I believe every customer should go production with SR2.0 by now.

    What does "no longer supported" mean here? Currently I'm working with 11.00.09.04, which is already outdated again, as I see. I didn't try the recent one yet. But if this is is not working with SR1.0 at all, I don't even need to try it.

    Anyawy, right now I can deal with that minor issue. But probably we should order another eval kit soon... 

  • 0 in reply to Mario Trams
    TI__Guru**** 168291 points

    Hi Mario,

    Mario Trams said:
    Momentarily, as for the AM6442 I've only one TMDS64GPEVM here in order to sort out basic things prior to going into our own hardware design

    TMDS64GPEVM has SR1.0. The new version is called TMDS64EVM which has SR2.0.

    Mario Trams said:
    There's also an AM64SK and right now I don't know what revision is soldered there.

    It depends the name printed on the PCB. If it is SK-AM64, it has SR1.0; but if it is SK-AM64B, it has SR2.0.

    Bot TMDS64EVM and SK-AM64B, with SR2.0 on it, are available on ti.com.

    Mario Trams said:
    What does "no longer supported" mean here?

    It basically means the recent versions of Processor SDK out of the box won't be able to run on SR1.0. The SYSFW binaries are difference for SR1.0 and SR2.0, and the SDK does no longer provide the SYSFW binaries for SR1.0.

    Mario Trams said:
    Currently I'm working with 11.00.09.04,

    Do you really use the U-Boot provided in 11.00.09.04? I don't have this version of the SDK installed on my PC, but I see the previous version - 10.01.10.04 does not provide the SYSFW binaries for SR1.0.

  • 0 in reply to Bin Liu
    Prodigy 170 points

    Hi Bin,

    thanks for the clarifications. The SK-AM64 (I did name it wrongly it before) is really an SK-AM64, no SK-AM64B. So it has got SR1.0 as well then. But as I see, I should urge an upgrade to the TMDS64EVM here....

    And, indeed, I'm using 11.00.09.04 and the U-Boot coming along with it with the SR1.0 then. Don't ask me why this is working although it should not... But I can't say that it is working out-of-the-box. For instance, I have to rename tiboot3-am64x-gp-evm.bin into tiboot3.bin first. But I have to do this since the beginning.

    Just for your reference, I'm quoting below the first output of the console messages during boot.

    Greetings,

    Mario

    U-Boot SPL 2025.01-00406-gcd91d7360181 (Mar 25 2025 - 16:14:37 +0000)
    Resetting on cold boot to workaround ErrataID:i2331
    Please resend tiboot3.bin in case of UART/DFU boot
    resetting ...

    U-Boot SPL 2025.01-00406-gcd91d7360181 (Mar 25 2025 - 16:14:37 +0000)
    SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.7--v11.00.07 (Fancy Rat)')
    SPL initial stack usage: 13392 bytes
    Trying to boot from MMC2
    Skipping authentication on GP device
    Skipping authentication on GP device
    Skipping authentication on GP device
    Skipping authentication on GP device
    Loading Environment from nowhere... OK
    Starting ATF on ARM64 core...

    NOTICE:  BL31: v2.12.0(release):11.00.08-1-gb11beb2b6-dirty
    NOTICE:  BL31: Built : 12:35:58, Mar 24 2025
    I/TC:
    I/TC: OP-TEE version: 4.5.0-73-gef1ebdc23-dev (gcc version 13.3.0 (GCC)) #1 Tue Feb  4 11:33:18 UTC 2025 aarch64
    I/TC: WARNING: This OP-TEE configuration might be insecure!
    I/TC: WARNING: Please check optee.readthedocs.io/.../porting_guidelines.html
    I/TC: Primary CPU initializing
    I/TC: GIC redistributor base address not provided
    I/TC: Assuming default GIC group status and modifier
    I/TC: SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.7--v11.00.07 (Fancy Rat)')
    I/TC: Activated SA2UL device
    I/TC: Fixing SA2UL firewall owner for GP device
    I/TC: Enabled firewalls for SA2UL TRNG device
    I/TC: SA2UL TRNG initialized
    I/TC: SA2UL Drivers initialized
    I/TC: HUK Initialized
    I/TC: Primary CPU switching to normal world boot

    U-Boot SPL 2025.01-00406-gcd91d7360181 (Mar 25 2025 - 16:14:37 +0000)
    SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.7--v11.00.07 (Fancy Rat)')
    Trying to boot from MMC2
    Skipping authentication on GP device
    Skipping authentication on GP device


    U-Boot 2025.01-00406-gcd91d7360181 (Mar 25 2025 - 16:14:37 +0000)

    SoC:   AM64X SR1.0 GP
    Model: Texas Instruments AM642 EVM
    Board: AM64-GPEVM rev A
    DRAM:  2 GiB
    Core:  105 devices, 33 uclasses, devicetree: separate
    MMC:   mmc@fa10000: 0, mmc@fa00000: 1
    Loading Environment from nowhere... OK
    In:    serial@2800000
    Out:   serial@2800000
    Err:   serial@2800000
    Net:   eth0: ethernet@8000000port@1, eth2: icssg1-eth-port@0
    Hit any key to stop autobo 0
    =>env default -f -a
    ## Resetting to default environment
    =>reset
    resetting ...

    U-Boot SPL 2025.01-00406-gcd91d7360181 (Mar 25 2025 - 16:14:37 +0000)
    SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.7--v11.00.07 (Fancy Rat)')
    SPL initial stack usage: 13392 bytes
    Trying to boot from MMC2
    Skipping authentication on GP device
    Skipping authentication on GP device
    Skipping authentication on GP device
    Skipping authentication on GP device
    Loading Environment from nowhere... OK
    Starting ATF on ARM64 core...

    NOTICE:  BL31: v2.12.0(release):11.00.08-1-gb11beb2b6-dirty
    NOTICE:  BL31: Built : 12:35:58, Mar 24 2025
    I/TC:
    I/TC: OP-TEE version: 4.5.0-73-gef1ebdc23-dev (gcc version 13.3.0 (GCC)) #1 Tue Feb  4 11:33:18 UTC 2025 aarch64
    I/TC: WARNING: This OP-TEE configuration might be insecure!
    I/TC: WARNING: Please check optee.readthedocs.io/.../porting_guidelines.html
    I/TC: Primary CPU initializing
    I/TC: GIC redistributor base address not provided
    I/TC: Assuming default GIC group status and modifier
    I/TC: SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.7--v11.00.07 (Fancy Rat)')
    I/TC: Activated SA2UL device
    I/TC: Fixing SA2UL firewall owner for GP device
    I/TC: Enabled firewalls for SA2UL TRNG device
    I/TC: SA2UL TRNG initialized
    I/TC: SA2UL Drivers initialized
    I/TC: HUK Initialized
    I/TC: Primary CPU switching to normal world boot

    U-Boot SPL 2025.01-00406-gcd91d7360181 (Mar 25 2025 - 16:14:37 +0000)
    SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.7--v11.00.07 (Fancy Rat)')
    Trying to boot from MMC2
    Skipping authentication on GP device
    Skipping authentication on GP device


    U-Boot 2025.01-00406-gcd91d7360181 (Mar 25 2025 - 16:14:37 +0000)

    SoC:   AM64X SR1.0 GP
    Model: Texas Instruments AM642 EVM
    Board: AM64-GPEVM rev A
    DRAM:  2 GiB
    Core:  105 devices, 33 uclasses, devicetree: separate
    MMC:   mmc@fa10000: 0, mmc@fa00000: 1
    Loading Environment from nowhere... OK
    In:    serial@2800000
    Out:   serial@2800000
    Err:   serial@2800000
    Net:   eth0: ethernet@8000000port@1, eth2: icssg1-eth-port@0
    Hit any key to stop autobo 0
    =>setenv serverip 195.100.100.76
    =>setenv nfs_root /home/mtr/ti-processor-sdk-linux-am64xx-evm-11.00.09.04/targetNFS
    =>setenv name_kern Image-am64xx-evm.bin
    =>setenv bootcmd 'run envboot; run setup_${kern_boot}; run init_${rootfs_boot}; run get_kern_${kern_boot}; run get_fdt_${kern_boot}; run get_overlay_${kern_b'
    =>setenv init_net 'run args_all args_net; setenv autoload no; dhcp'
    =>setenv args_net 'setenv bootargs console=${console} ${optargs} rootfstype=nfs root=/dev/nfs rw nfsroot=${serverip}:${nfs_root},${nfs_options} ip=dhcp'
    =>setenv get_kern_net 'tftp ${loadaddr} ${name_kern}'
    =>setenv get_fdt_net 'tftp ${fdtaddr} ${fdtfile}'
    =>setenv get_overlay_net 'fdt address ${fdtaddr};fdt resize 0x100000;for overlay in ${name_overlays};do;tftp ${overlayaddr} ${overlay};fdt apply ${overlayadd'
    =>setenv nfs_options 'nolock,v3,tcp,rsize=4096,wsize=4096'
    =>setenv setup_mmc ''
    =>setenv setup_net 'setenv autoload no; dhcp'
    =>setenv kern_boot net
    =>setenv rootfs_boot net
    =>boot
    switch to partitions #0, OK
    mmc1 is current device
    SD/MMC found on device 1
    574 bytes read in 2 ms (280.3 KiB/s)
    Loaded env from uEnv.txt
    Importing environment from mmc1 ...
    link up on port 1, speed 100, full duplex
    BOOTP broadcast 1
    DHCP client bound to address 195.100.100.52 (26 ms)
    link up on port 1, speed 100, full duplex
    BOOTP broadcast 1
    DHCP client bound to address 195.100.100.52 (25 ms)
    link up on port 1, speed 100, full duplex
    Using ethernet@8000000port@1 device
    TFTP from server 195.100.100.76; our IP address is 195.100.100.52
    Filename 'Image-am64xx-evm.bin'.
    Load address: 0x82000000
    Loading: #################################################################

     

  • 0 in reply to Mario Trams
    TI__Guru**** 168291 points

    Hi Mario,

    Mario Trams said:
    And, indeed, I'm using 11.00.09.04 and the U-Boot coming along with it with the SR1.0 then. Don't ask me why this is working although it should not... But I can't say that it is working out-of-the-box. For instance, I have to rename tiboot3-am64x-gp-evm.bin into tiboot3.bin first. But I have to do this since the beginning.

    You are right, the recent SDK still provides tiboot3-am64x-gp-evm.bin (which should be renamed to tiboot3.bin) to boot on the EVM with SR1.0. I haven't touched the SR1.0 EVM for a long time and over looked such details.

    However, the SDK doesn't provide the SYSFW binary for SR1.0, so when you recompile U-Boot, I believe it won't generate correct tiboot3-am64x-am64-gp-evm.bin. This is what I meant by "SR1.0 is no longer support in recent SDKs".