• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 514 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.

AM623: Ethernet Boot

Chris Yorkey
Genius 16115 points
Part Number: AM623
Other Parts Discussed in Thread: AM3352,

Tool/software:

TI Friends & Family,.

Our customer is trying to get Ethernet boot working on a new AM6234 processor board and found the following comment on a TI Forum:

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1350579/sk-am62-u-boot---boot-via-ethernet

 There also is an errata i2329 that mentions possible MDIO interface corruption.

 The current AM3352 uses MII0 Ethernet boot during production and the intent is for the AM6234 processor board to use the same process.

Are there any issues with a primary RMII0 boot that we need to be aware of?

One other item to mention is about i2329 MDIO: MDIO interface corruption (CPSW and PRU-ICSS) from the Errata AM62x Processor Silicon Revision 1.0.  Please elaborate on what this actually means. Is the MDIO interface unreliable in the AM62X during boot or all the time and is this something we should be worried about?

 In addition ---

 "

They have been attempting to Ethernet boot teh AM623x HS-FS board with a build of tiboot3.bin, tispl.bin and u-boot.img from the Kirkstone version of Yocto Project.  It was discovered a MDIO bit-bang for the Cortex-A53 in the “k3-am625-beagleplay.dts” device tree for the Linux kernel.  The AM62 SK “k3-am625-sk.dts” device tree for the Linux kernel does not have a bit-banged MDIO for the Cortex-A53.  The “k3-am625-beagleplay.dts” device tree for the Linux kernel has the statement “Workaround for errata i2329 - Use mdio bitbang “. 

The “k3-am625-beagleplay.dts”  device tree for the Cortex-A53 boot loader does not have a bitbanged MDIO as in the following statement, “U-boot doesn't know about gpio bitbang for MDIO”. 

Why does the Beagleplay have a MDIO bitbang in the device tree and the SK EVM does not?

Do we need to use the MDIO bitbang version on our custom AM623x core board? 

Why is the MDIO bitbang in the Linux kernel, but not in the boot loader?

 "

TY,

CY

  • 0
    TI__Mastermind 18065 points

    Hello Chris,

    Chris Yorkey said:
    One other item to mention is about i2329 MDIO: MDIO interface corruption (CPSW and PRU-ICSS) from the Errata AM62x Processor Silicon Revision 1.0.  Please elaborate on what this actually means. Is the MDIO interface unreliable in the AM62X during boot or all the time and is this something we should be worried about?

    Please see the details of Errata i2329 in the AM62x Errata document linked below. This can be found at the AM623 TI Product page. 

    https://www.ti.com/lit/er/sprz487e/sprz487e.pdf 

    Chris Yorkey said:
    The current AM3352 uses MII0 Ethernet boot during production and the intent is for the AM6234 processor board to use the same process.

    As stated by the AM62x Errata, there is no workaround to guarantee primary ethernet boot is successful everything it is used. It could work successfully but it is not guaranteed to be the case every time; therefore, we do not recommend ethernet boot to be used during production and it should only really be used for development purposes.

    Is the customer limited to using Ethernet boot during production or can alternative methods, such as USB/DFU boot be an option? https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/latest/exports/docs/linux/Foundational_Components/U-Boot/UG-DFU.html#usb-device-firmware-upgrade-dfu 

    -Daolin

  • 0
    TI__Mastermind 18065 points

    Hi Chris,

    Chris Yorkey said:

    Why does the Beagleplay have a MDIO bitbang in the device tree and the SK EVM does not?

    Do we need to use the MDIO bitbang version on our custom AM623x core board? 

    Why is the MDIO bitbang in the Linux kernel, but not in the boot loader?

    Which Linux kernel version is the k3-am625-beagleplay.dts you are referring to from? We took a look at the 6.6 Linux Kernel k3-am625-beagleplay.dts and only saw this line that is referencing MDIO bit bang: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts?h=ti-linux-6.6.y#n649 . Is this the version that you are describing?

    The MDIO Errata workaround is to put the MDIO data and clock line into a manual mode, (means not using the MDIO IP). Keep in mind, this is not a workaround to the Ethernet boot description of the MDIO Errata. There is a kernel configuration that enables the bit-bang driver code to do the MDIO traffic. This is the same for U-Boot. DTS is not used to enable MDIO bit-bang.

    -Daolin

  • 0 in reply to Daolin Qiu
    TI__Genius 16115 points

    Hi Daolin,

    Very helpful, thx for jumping in on this.  Customer has replied with the following today:

    "

    The Kirkstone Yocto Project is Linux kernel version 6.1.33.  The Linux kernel-6-1, tispl.bin, and u-boot.img have the bitbang MDIO in the device tree for the Cortex-A53 on the Beagleplay.   The tiboot3.bin does not have the bitbang MDIO for the Cortex-R5 on the Beagleplay. 

     Why was this apparently removed in Linux kernel version 6.6? 

     Also was the revision silicon upgraded to version 2.0 which corrected the MDIO?

    "

    TY,

    CY

  • 0 in reply to Chris Yorkey
    TI__Mastermind 18065 points

    Hi Chris,

    Chris Yorkey said:
    Why was this apparently removed in Linux kernel version 6.6? 

    I need to double check internally, but I believe that the Linux Kernel version 6.1 enabling bitbang MDIO is using separate GPIO signals (instead of the original MDIO pinmuxed signals) to simulate the MDIO signals whereas Linux Kernel version 6.6 is enabling bitbang MDIO via the original MDIO pinmuxed signals.

    This is probably why there was configuration in the DTS for 6.1 for bitbang MDIO since the MDIO need to be generated on the GPIO signals. In 6.6, since the original MDIO pinmuxed signals are used for bitbang MDIO instead, there is naturally no need for the MDIO GPIO configuration. I need to check why this was changed between the two Kernel versions.

    Chris Yorkey said:
    Also was the revision silicon upgraded to version 2.0 which corrected the MDIO?

    I need to consult with a colleague on this as well. From what I know, I don't think we ever had a silicon revision upgrade that fixed this MDIO Errata. We did however fix this MDIO silicon issue on the newer processors (e.g. AM62Ax, AM62Px)

    Please ping this thread if I did not get back to you by Wednesday next week.

    -Daolin

  • 0 in reply to Daolin Qiu
    TI__Genius 16115 points

    Hi Daolin,

    Your previous post was quite helpful and informative.

    If you still have some final thoughts and confirmations to some of the other statements you made previously, please do let us know.

    Thank you,

    Chris

  • 0 in reply to Chris Yorkey
    TI__Mastermind 18065 points

    Hi Chris,

    Thanks for reminding me!

    Chris Yorkey said:
    Why was this apparently removed in Linux kernel version 6.6? 

    This commit message on version 6.6 might answer this question of yours https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts?h=ti-linux-6.6.y&id=d147b27debdf0e759d4bff808bf77dfed9fb170f 

    Chris Yorkey said:
    Also was the revision silicon upgraded to version 2.0 which corrected the MDIO?

    I've confirmed with a colleague that no silicon revision was made which corrected the MDIO errata.'

    -Daolin