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.

AM623: Difference between AM6234 and AM6254

Part Number: AM623

What is the difference between AM6234 and AM6254?

I have a network driver which is working on AM6254, but not on AM6234. There is no error detected, RGMII link and PHY link is fixed. Is there any difference in the device IDs and other IDs including allocated IDs (https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am62x/devices.html)?

Do the chips have the same ethernet port numbers (tag) regarding PDMA?

Loading u-boot for AM6234 via USB also does not work on AM6254, because tispl.bin seems not to be compatible.

There are some registers which are not described in the manual spruiv7a.pdf (NOVEMBER 2022), but the Lauterbach debugger decodes them. Where do I get the full register descriptions?

For example I cannot find the description of FAULT_DETECT_ENABLE in CPSW_NUSS_VBUSP_CONTROL_REG at 0x8000F04.

When I click on the register it jumps to the wrong definition:

Which happens for CPSW_MDIO_CONTROL_REG on page 9113.
 

  • Hi,

    There is not any difference between the peripherals on the two different devices. The only difference is that the AM6254 has the GPU and the AM6234 does not everything else is the same such as the PDMA that you mentioned.

    Concerning the registers the register seems to be missing currently from the AM62x TRM (this is a documentation bug).   Looking at the TRM for AM64x a similar part I am not able to find that register.

    Could you please post a picture of the AM6254 that is on your board? Also please post a picture of the AM6234.

    Also, which SDK version are you using?

    Thanks and Best Regards,

    Schuyler

  • TQMa6254-PROTO1

    TQMa6234-PROTO1

    I am not using the SDK for the network driver.

    I think u-boot and SPL is based on (I only have the binary):

    https://support.tq-group.com/en/arm/tqma62xx/linux/yocto/quickstart_yocto

    github.com/.../linux-tqmaxx.git commit 35d4f25049eb1779c79221011717cc9a195a614b

    github.com/.../ci-meta-tq.git commit 313950e841879b635394cac9508b3a6e7a1b8557

  • Hi,

    Thanks for the pictures. I was hoping to read the part numbers off of the devices, unfortunately I am not able to read the respective part numbers. I am looking to see if there a difference in secure or GP between the two SOMs. The figure below is from the datasheet.

    Best Regards,

    Schuyler

  • It seems that the following is written on the chips:

    AM6254A TCGAALW

    AM6234A TCGAALW

  • Hi,

    Thank you for the numbers off of the processor. I wanted to check if there was a difference between the two boards with GP or HS (general purpose or secure). Both parts are GP. If they had been different one would not have booted. Back to the original post though I want to confirm that the AM6234 boots? It's just the network is not working?

    Best Regards,

    Schuyler

  • The AM6234 is booting, only network is affected.

    Actually it seems that network is now working on one port, the problem was caused by RGMII Rx/Tx delays. The boards do not have the same PHY chip. In the error case the CPSW0 reported that the RGMII link is good while there were problems there.

  • Hi,

    these part numbers are missing a letter - it should be TCGGAALW (with 2 "G") or TCGHAALW. To my knowledge, all existing TQMa6234 are TCGHAALW (HS-FS SoC), and all TQMa6254 are TCGGAALW (GP SoC), so they require different tiboot3.bin variants (but my information on existing prototypes may be incomplete). The same tispl.bin should work on all variants as long as the correct tiboot3.bin is used.

    I do not have an explanation for the different behavior of the Ethernet on the TQMa6254 and 6234 either. In linux-tqmaxx, we are using the same DTB for all TQMa62xx variants, with only the following fixups happening in U-Boot to account for the differences: https://github.com/tq-systems/u-boot-tqmaxx/blob/TQMaxx-ti-u-boot-2023.04/arch/arm/mach-k3/am625_fdt.c

    If only one port is working, you may be missing some initialization of the Ethernet controller. As the CPSW driver in U-Boot supports only one port, presumably the controller is left in a state with one port having more complete configuration than the other when the OS is started.

    Best regards,
    Matthias

  • Hi,

    Could you please attach the results of ethtool -S and ethtool for both eth0 and eth1?

    ex: ethtool -S eth0

    Are both ethernet ports using a fixed link?

    Best Regards,

    Schuyler

  • The board vendor was in the mean time able to send me a linux where both ethernet ports are working, the cables were also swapped, both ethernet ports are using fixed link, but with different speed. I was able to get the second ethernet port also working in my driver. I needed to initialize the PHY registers in the same order as in Linux.

    I wasn't able to run on the exact same hardware because of the problems with tispl.bin/tiboot3.bin. A higher compatibility on that level would have helped to detect whether a problem is related to the SoC or the peripherals. It is not easy read the text written on the chip. Regarding my original problem I consider this to be resolved.