FAQs
English (US) 日本語 | Japanese 中文 | Chinese (Simplified)

S32G2 EMMC data line swapping

cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Show  only  | Search instead for 
Did you mean: 

S32G2 EMMC data line swapping

‎10-29-2023 12:02 PM
3,865 Views
Delishtm
Contributor II

I made a custom board with S32G2 (S32G274AABK0VUCx) in that we have added an EMMC but drawing schematics i accidently swap the data lines. it should be d0-d0,d1-d1,d2-d2 etc but connected wrongly.(please see the image). While i tried to boot i found that i am not able to boot the linux. but am getting still uboot.

My doubt is will it work by wrongly connecting the emmc data lines?

Delishtm_0-1698606130078.png

 

0 Kudos
Reply
5 Replies

‎10-30-2023 01:01 PM
3,844 Views
Daniel-Aguirre
NXP TechSupport
NXP TechSupport

Hi,

Under the eMMC scheme, the general idea is to connect, as you are saying, each corresponding bit from the processor to the memory, and not swap them. 

As if it should work, we cannot confirm nor deny it. You could try and swap the endianness of the data by SW, since at the end this is being swapped on HW. But we cannot confirm if this is enough. We do apologize.

Please, let us know.

Reply

‎11-08-2023 02:22 PM
3,806 Views
Delishtm
Contributor II

Hi @Daniel-Aguirre 

Let me clarify something Our entire aim is to boot the an image from this EMMC.

in the schematics the correctly connected data lines are D0 & d4,

so as per my understanding (please correct me if i am wrong)

in 1 bit speed mode the emmc and processor use only 1 data line to communicate.

and in 4 bit it use 4 data lines to communicate each other and so on..

at that time if a configure the processor to work in 1 bit mode normal speed (by making the  RCON20,RCON19,RCON21 pins 0)

it should be able to boot from EMMC right?

 

And Some of our observations/doubts are as follows kindly comment on the same,

  • While writing the image to EMMC through Flash tool i can see data transitions in d0,d3,d7 lines Is that expected?
  • In the Flash tool while we uploading the algorithm to hardware are we defining the bus width or some thing?
  •  While we upload the image through flash tool and put the RCON switches to 8 bit normal speed we are able to boot till u boot and its getting stopped over there the logs are as follows, my question was after u boot will the processor/emmc will try any other speed modes is at a reason its getting stoppped there ?

NOTICE: Reset status: Power-On Reset
NOTICE: BL2: v2.5(release):bsp36.0-2.5
NOTICE: BL2: Built : 17:42:10, Mar 23 2023
NOTICE: BL2: Booting BL31


U-Boot 2020.04+gec57ab5ab8 (Mar 24 2023 - 13:55:02 +0000)

CPU: NXP S32G274A rev. 2.0
Model: NXP S32G2XXX-EVB3
DRAM: 3.5 GiB
MMC: FSL_SDHC: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment

Failed to lock PCIe phy
Failed to power on 'serdes_lane0' PHY
In: serial@401c8000
Out: serial@401c8000
Err: serial@401c8000
Loading SJA1105 firmware over SPI 5:0
No matching device ID found for devid 0, cs 0.
Error SJA1105 configuration not completed
Net: EQOS phy: rgmii @ 4

Warning: eth_eqos (eth0) using random MAC address - 9a:6a:ee:6c:5b:8c
eth0: eth_eqosFailed to get speed of XPCS for emac1_xpcsFailed to set the frequency of mac2_rx_rgmii
Failed to enable mac2_rx_rgmii clock
PFE: emac0: sgmii emac1: sgmii emac2: rgmii
** No partition table - mmc 0 **
PFEng firmware file 'mmc@0:1:s32g_pfe_class.fw' loading failed: -1

Hit any key to stop autoboot: 0
Failed to get speed of XPCS for emac1_xpcs** No partition table - mmc 0 **
PFEng firmware file 'mmc@0:1:s32g_pfe_class.fw' loading failed: -1
PFE: emac0: sgmii emac1: sgmii emac2: rgmii
pfeng_cfg_mode_enable: Invalid PFE device
switch to partitions #0, OK
mmc0(part 0) is current device
** No partition table - mmc 0 **
Booting from net ...
Failed to get speed of XPCS for emac1_xpcsFailed to set the frequency of mac2_rx_rgmii
Failed to enable mac2_rx_rgmii clock
PFE: emac0: sgmii emac1: sgmii emac2: rgmii
** No partition table - mmc 0 **
PFEng firmware file 'mmc@0:1:s32g_pfe_class.fw' loading failed: -1
Failed to enable rx_rgmii clock
Could not get PHY for eth_eqos: addr 4
phy_connect() failedFAILED: 0BOOTP broadcast 1
eqos_send: TX timeout

Abort
Failed to enable rx_rgmii clock
Could not get PHY for eth_eqos: addr 4
phy_connect() failedFAILED: 0BOOTP broadcast 1
eqos_send: TX timeout
BOOTP broadcast 2
eqos_send: TX timeout
BOOTP broadcast 3
eqos_send: TX timeout
BOOTP broadcast 4
eqos_send: TX timeout
BOOTP broadcast 5
eqos_send: TX timeout
BOOTP broadcast 6
eqos_send: TX timeout
BOOTP broadcast 7
eqos_send: TX timeout
BOOTP broadcast 8
eqos_send: TX timeout
BOOTP broadcast 9
eqos_send: TX timeout
BOOTP broadcast 10
eqos_send: TX timeout
BOOTP broadcast 11
eqos_send: TX timeout
BOOTP broadcast 12
eqos_send: TX timeout
BOOTP broadcast 13
eqos_send: TX timeout

Retry time exceeded; starting again
Bad Linux ARM64 Image magic!

=>
=>
=>
=>

-----------------------------------------------------------------

If you need any additional information regarding this issue please let me know.

 

0 Kudos
Reply

‎11-09-2023 02:34 PM
3,796 Views
Daniel-Aguirre
NXP TechSupport
NXP TechSupport

Hi,

Below will be some comments on your asked questions:

  • While writing the image to EMMC through Flash tool i can see data transitions in d0,d3,d7 lines Is that expected?

Since we assume you are using the "EMMC.bin" file, we don't have information on how the algorithm was built, but we assume it was not under a 1-bit communication, hence we assume that this is expected.

  • In the Flash tool while we uploading the algorithm to hardware are we defining the bus width or some thing?

This should be determined by the binary of the algorithm selected, so we assume this is correct. The algorithm provides the configuration for the external device.

  •  While we upload the image through flash tool and put the RCON switches to 8 bit normal speed we are able to boot till u boot and its getting stopped over there the logs are as follows, my question was after u boot will the processor/emmc will try any other speed modes is at a reason its getting stoppped there ?

The eMMC should not reconfigure itself if it is not asked to do it (or it is not power cycled). Since we understand that after uboot, while trying to load linux you are failling, this could be related to linux/uboot reconfiguring the eMMC. Since, as you have said, the lines are not connected as required, there could a transaction which the order matters and in the end it causes the "Bad Linux ARM64 Image magic!" message.

As for:

"at that time if a configure the processor to work in 1 bit mode normal speed (by making the  RCON20,RCON19,RCON21 pins 0)

it should be able to boot from EMMC right?"

We may be misunderstanding your questions, but the RCON configuration is related to the BootROM itself. Once the BootROM finishes, the application can reconfigure the interfaces as required. As said under the S32G2 RM [Page 1319, S32G2 Reference Manual, Rev. 7, February 2023]:

"RCON uses up to 32 general-purpose I/O pins—RCON[0] to RCON[31]—that are latched on functional reset deassertion."

Which, after the functional reset has been deasserted, the RCON configuration should not matter, since the values have been latched for BootROM usage/configuration.

Please, let us know.

Reply

‎11-09-2023 03:50 PM
3,788 Views
Delishtm
Contributor II

Hi @Daniel-Aguirre  

I appreciate your quick response, and the provided information suits me perfectly.

I will work with my software team and check more deep into the code, to check about the bus width.

and some responses for your reply is as follows

Since we assume you are using the "EMMC.bin" file, we don't have information on how the algorithm was built, but we assume it was not under a 1-bit communication, hence we assume that this is expected.

  • yes we use the default "EMMC.bin" file. is there any other bin file available which only configure as 1 bit.?
  • Is there any possible way to edit the "EMMC.bin" file and change the bus width?

We may be misunderstanding your questions, but the RCON configuration is related to the BootROM itself. Once the BootROM finishes, the application can reconfigure the interfaces as required. As said under the S32G2 RM [Page 1319, S32G2 Reference Manual, Rev. 7, February 2023]:

"RCON uses up to 32 general-purpose I/O pins—RCON[0] to RCON[31]—that are latched on functional reset deassertion."

Which, after the functional reset has been deasserted, the RCON configuration should not matter, since the values have been latched for BootROM usage/configuration.

  • you had not misunderstood i mean the same. in that RCON switches there are switches (RCON20,RCON19,RCON21) which determine the MMC Boot Modes.
  • Can you just imagine a situations where i am using a EMMC memory which have only 1 data bus (d0) and how will be the processor communicating with the memory? Will it use the RCON switch to understand in which boot mode it should work?
    • In a practical senario in which all cases we use multiple MMC Boot Modes?                      MMC Boot Modes
      00- 1-bit Normal Speed
      10- 4-bit Normal Speed
      01 - 8-bit Normal Speed
      11- 1-bit HIGH Speed
      00 - 4-bit HIGH Speed
      10 - 8-bit HIGH Speed
      01 - 4-bit DDR HIGH Speed
      11 - 8-bit DDR HIGHl Speed 
    • In which practical condition we use 1 bit normal speed / 8 bit DDR HIGH Speed.?

In the mean time I would like to share some more observations

i was having 2 flashing images

  1. which support 1 bit mode 
  2. Which support 8 bit mode,

I tried writing both images the booting logs are as follows 

 

  • With image which support 1 bit mode (Note: RCON switch is in 8 bit normal speed. Not getting till CLI if we put RCON switch to 1-bit normal speed)

Delishtm_1-1699569659116.png

Observation: Uboot is not getting displayed.

  • With image which support 8 bit mode (Note: RCON switch is in 8 bit normal speed.)

     

    NOTICE: Reset status: Power-On Reset
    NOTICE: BL2: v2.5(release):bsp36.0-2.5
    NOTICE: BL2: Built : 17:42:10, Mar 23 2023
    NOTICE: BL2: Booting BL31


    U-Boot 2020.04+gec57ab5ab8 (Mar 24 2023 - 13:55:02 +0000)

    CPU: NXP S32G274A rev. 2.0
    Model: NXP S32G2XXX-EVB3
    DRAM: 3.5 GiB
    MMC: FSL_SDHC: 0
    Loading Environment from MMC... *** Warning - bad CRC, using default environment

    Failed to lock PCIe phy
    Failed to power on 'serdes_lane0' PHY
    In: serial@401c8000
    Out: serial@401c8000
    Err: serial@401c8000
    Loading SJA1105 firmware over SPI 5:0
    No matching device ID found for devid 0, cs 0.
    Error SJA1105 configuration not completed
    Net: EQOS phy: rgmii @ 4

    Warning: eth_eqos (eth0) using random MAC address - 9a:6a:ee:6c:5b:8c
    eth0: eth_eqosFailed to get speed of XPCS for emac1_xpcsFailed to set the frequency of mac2_rx_rgmii
    Failed to enable mac2_rx_rgmii clock
    PFE: emac0: sgmii emac1: sgmii emac2: rgmii
    ** No partition table - mmc 0 **
    PFEng firmware file 'mmc@0:1:s32g_pfe_class.fw' loading failed: -1

    Hit any key to stop autoboot: 0
    Failed to get speed of XPCS for emac1_xpcs** No partition table - mmc 0 **
    PFEng firmware file 'mmc@0:1:s32g_pfe_class.fw' loading failed: -1
    PFE: emac0: sgmii emac1: sgmii emac2: rgmii
    pfeng_cfg_mode_enable: Invalid PFE device
    switch to partitions #0, OK
    mmc0(part 0) is current device
    ** No partition table - mmc 0 **
    Booting from net ...
    Failed to get speed of XPCS for emac1_xpcsFailed to set the frequency of mac2_rx_rgmii
    Failed to enable mac2_rx_rgmii clock
    PFE: emac0: sgmii emac1: sgmii emac2: rgmii
    ** No partition table - mmc 0 **
    PFEng firmware file 'mmc@0:1:s32g_pfe_class.fw' loading failed: -1
    Failed to enable rx_rgmii clock
    Could not get PHY for eth_eqos: addr 4
    phy_connect() failedFAILED: 0BOOTP broadcast 1
    eqos_send: TX timeout

    Abort
    Failed to enable rx_rgmii clock
    Could not get PHY for eth_eqos: addr 4
    phy_connect() failedFAILED: 0BOOTP broadcast 1
    eqos_send: TX timeout
    BOOTP broadcast 2
    eqos_send: TX timeout
    BOOTP broadcast 3
    eqos_send: TX timeout
    BOOTP broadcast 4
    eqos_send: TX timeout
    BOOTP broadcast 5
    eqos_send: TX timeout
    BOOTP broadcast 6
    eqos_send: TX timeout
    BOOTP broadcast 7
    eqos_send: TX timeout
    BOOTP broadcast 8
    eqos_send: TX timeout
    BOOTP broadcast 9
    eqos_send: TX timeout
    BOOTP broadcast 10
    eqos_send: TX timeout
    BOOTP broadcast 11
    eqos_send: TX timeout
    BOOTP broadcast 12
    eqos_send: TX timeout
    BOOTP broadcast 13
    eqos_send: TX timeout

    Retry time exceeded; starting again
    Bad Linux ARM64 Image magic!

    =>
    =>
    =>
    =>

    -----------------------------------------------------------------

 

Looking forward to your swift reply....................!!

 

Regards,

Delish

 

0 Kudos
Reply

‎11-13-2023 12:49 PM
3,744 Views
Daniel-Aguirre
NXP TechSupport
NXP TechSupport

Hi,

Thans for your feedback. We will provide some comments on your asked questions:

  • yes we use the default "EMMC.bin" file. is there any other bin file available which only configure as 1 bit.?
  • Is there any possible way to edit the "EMMC.bin" file and change the bus width?

There is a FlashSDK project under the following path:

"C:\nxp\S32DS.3.5\S32DS\tools\S32FlashTool\FlashSDK_Ext"

Under the User Guide of this project, the following is provided [Page 20, S32 Flash Tool, User Guide, Rev. 1.3, 06/2023]:

DanielAguirre_0-1699904476004.png

Which implies that you should also be able to create your algorithm with the eMMC configurations you require, or so we understand.

  • Can you just imagine a situations where i am using a EMMC memory which have only 1 data bus (d0) and how will be the processor communicating with the memory? Will it use the RCON switch to understand in which boot mode it should work?

We may not understand this question, but the RCON switches are used for BootROM only. The following information is provided under the S32G2 RM [Page 1356, S32G2 Reference Manual, Rev. 7, February 2023]:

"BootROM provides an option of overriding some of the default μSDHC IOMUX configuration settings in BootROM firmware, shown in the attached BootROM settings spreadsheet, via a pad override scheme."

For the scenarios you are showing, it seems that for the first one ATF cannot find the uboot image to be able to boot-it up. The second one seems to imply that the image is detected as corrupted or not built correctly, which might be related to the data pins being swapped.

Still, could be that we misunderstood the questions. Let us know if this has happened.

Please, let us know.

0 Kudos
Reply