SAMA5D44 revB Boot From MMC0

[SoarHuang]

Hello,

As we know, the MMC0 interface of SAMA5D44 revA cannot be used for booting.
Does SAMA5D44 revB MMC0 interface can be used for booting? Would you recommend use MMC0 as boot-interface?

Our board HW configuration:
SOC: SAMA5D44
MMC0: eMMC5 (8 Bit width)
MMC1: WiFi Module

We had modified belows in AT91-Bootstrap and rebuilt it.
1. Set mmc0 in sama5d4_xplainedsd_uboot_secure_defconfig
2. Refer sama5d4ek.c and set PC4~PC13, PIOC, HSMCI0 in sama5d4_xplained.c

Do we miss anything?
We have no luck with booting from MMC0 even we rework eMMC5 to SDcard (4 Bit width).
Always stuck in Bootstrap ...
Please help us out ... Any help would be appreciated.

AT91Bootstrap 3.8.13 (Wed Nov 20 16:09:44 CST 2019)
All interrupts redirected to AIC
EEPROM: Loading AT24xx information ...
EEPROM: BoardName | [Revid] | VendorName
twi read: timeout to wait RXRDY bit on bus 0
EEPROM: Failed to read
EEPROM: Using default information
EEPROM: Board sn: 0x1012420 revision: 0x680820
ACT8865: Set REG1/REG2/REG3 Power-saving mode
twi read: timeout to wait RXRDY bit on bus 3
ACT8865: Disable ACT8865's I2C interface
[DBG] at91_mci0_hw_init
SD/MMC: Image: Read file u-boot.bin to 0x26f00000
[DBG] sdcard_identification()
[DBG] sd_cmd_go_idle_state() ret=0
[DBG] mmc_verify_operating_condition()
[DBG]: mmc_cmd_send_op_cond() ocr=0
[DBG] mmc_cmd_send_op_cond() ret=0
[DBG]: mmc_cmd_send_op_cond() ocr=1073741824
[DBG] mmc_cmd_send_op_cond()-try 0, ret=0
[DBG]: mmc_cmd_send_op_cond() ocr=1073741824
[DBG] mmc_cmd_send_op_cond()-try 1, ret=0
[DBG]: mmc_cmd_send_op_cond() ocr=1073741824
[DBG] mmc_cmd_send_op_cond()-try 2, ret=0
[DBG]: mmc_cmd_send_op_cond() ocr=1073741824
(...............Trying 1000 times)
Unusable Card
*** FATFS: f_open, filename: [u-boot.bin]: error
SD/MMC: Failed to load image

[blue_z]

As we know, the MMC0 interface of SAMA5D44 revA cannot be used for booting.
Does SAMA5D44 revB MMC0 interface can be used for booting?

As documented in the SoC datasheet, the errata you refer to only applies to MRL A parts and not MRL B parts.

That errata only implicates the ROM code of the SoC.
Since your board apparently loads a version of AT91Bootstrap from MMC0 into the internal SRAM, clearly your SoC is not affected by that errata.
Any complications in booting after the boot ROM has finished executing would be unrelated to that errata.
The problem(s) would be with your version (or build) of AT91Bootstrap.

We had modified belows in AT91-Bootstrap and rebuilt it.
1. Set mmc0 in sama5d4_xplainedsd_uboot_secure_defconfig
2. Refer sama5d4ek.c and set PC4~PC13, PIOC, HSMCI0 in sama5d4_xplained.c

Why are you mentioning the third PIO instance, "PIOC"?
Or maybe you are referring to the third peripheral function specifier?

You summation of what you allegedly modified is inadequate compared to actual code.

Regards

[SoarHuang]

Thanks for your input.

We refer "Build AT91Bootstrap from sources" on Linux4SAM website
https://www.linux4sam.org/bin/view/Linu ... edMainPage
And git clone git://github.com/linux4sam/at91bootstrap.git
We had tested AT91Bootstrap version 'tag v3.8.13' and 'branch master' but without luck.
Do you know which branch of at91bootstrap may support SAMA5D44 MRL B parts?

Apologies for not being clear, the "PIOC" should be AT91C_ID_PIOC.
Since sama5d4_xplained.c (line 701~718) only configures MCI1(mmc1),
we refers sama5d4ek.c (line 738~781) and add MCI0(mmc0) and MCI1(mmc1) sama5d4_xplained.c.
https://github.com/linux4sam/at91bootst ... xplained.c
https://github.com/linux4sam/at91bootst ... ama5d4ek.c
The diffs - at91bootstrap-mmc0.patch as below.
Thank U.

[SoarHuang]

at91bootstrap-mmc0.patch

Code: Select all

diff --git a/board/sama5d4_xplained/sama5d4_xplained.c b/board/sama5d4_xplained/sama5d4_xplained.c
index 12cb4f6..dbfd56d 100644
--- a/board/sama5d4_xplained/sama5d4_xplained.c
+++ b/board/sama5d4_xplained/sama5d4_xplained.c
@@ -698,9 +698,36 @@ void at91_board_set_dtb_name(char *of_name)
 }
 #endif
 
+#if defined(CONFIG_AT91_MCI0)
 void at91_mci0_hw_init(void)
 {
-	const struct pio_desc mci_pins[] = {
+dbg_very_loud("[DBG] at91_mci0_hw_init\n");
+
+	const struct pio_desc mci0_pins[] = {
+		{"MCI0_CK", AT91C_PIN_PC(4), 0, PIO_DEFAULT, PIO_PERIPH_B},
+		{"MCI0_CDA", AT91C_PIN_PC(5), 0, PIO_DEFAULT, PIO_PERIPH_B},
+
+		{"MCI0_DA0", AT91C_PIN_PC(6), 0, PIO_DEFAULT, PIO_PERIPH_B},
+		{"MCI0_DA1", AT91C_PIN_PC(7), 0, PIO_DEFAULT, PIO_PERIPH_B},
+		{"MCI0_DA2", AT91C_PIN_PC(8), 0, PIO_DEFAULT, PIO_PERIPH_B},
+		{"MCI0_DA3", AT91C_PIN_PC(9), 0, PIO_DEFAULT, PIO_PERIPH_B},
+		{"MCI0_DA4", AT91C_PIN_PC(10), 0, PIO_DEFAULT, PIO_PERIPH_B},
+		{"MCI0_DA5", AT91C_PIN_PC(11), 0, PIO_DEFAULT, PIO_PERIPH_B},
+		{"MCI0_DA6", AT91C_PIN_PC(12), 0, PIO_DEFAULT, PIO_PERIPH_B},
+		{"MCI0_DA7", AT91C_PIN_PC(13), 0, PIO_DEFAULT, PIO_PERIPH_B},
+		{(char *)0, 0, 0, PIO_DEFAULT, PIO_PERIPH_A},
+	};
+
+	pio_configure(mci0_pins);
+	pmc_enable_periph_clock(AT91C_ID_PIOC);
+	pmc_enable_periph_clock(AT91C_ID_HSMCI0);
+}
+
+#elif defined(CONFIG_AT91_MCI1)
+void at91_mci1_hw_init(void)
+{
+dbg_very_loud("[DBG] at91_mci1_hw_init\n");
+	const struct pio_desc mci1_pins[] = {
 		{"MCI1_CK", AT91C_PIN_PE(18), 0, PIO_DEFAULT, PIO_PERIPH_C},
 		{"MCI1_CDA", AT91C_PIN_PE(19), 0, PIO_DEFAULT, PIO_PERIPH_C},
 
@@ -712,10 +739,12 @@ void at91_mci0_hw_init(void)
 	};
 
 	/* Configure the PIO controller */
-	pio_configure(mci_pins);
+	pio_configure(mci1_pins);
 	pmc_enable_periph_clock(AT91C_ID_PIOE);
 	pmc_enable_periph_clock(AT91C_ID_HSMCI1);
 }
+#endif 
+
 #endif /* #ifdef CONFIG_SDCARD */
 
 #ifdef CONFIG_NANDFLASH

[blue_z]

Do you know which branch of at91bootstrap may support SAMA5D44 MRL B parts?

Until there's a new board that utilizes a feature that requires new software, there's probably no reason to explicitly support SAMA5D44 MRL B parts.
For instance the SAMA5D4-XULT does not have the MMC0 socket installed, so even if the SoC was updated, the off-the-shelf board would not need updated boot programs.
(The SAMA5D4-EK does have a MMC0 socket, but it's out of production.)
(Note that when the SAMA5D2_XULT was updated with the MRL C part, the board got a new name/partnumber, but boot programs don't make a distinction.)


Your patch to at91_mci0_hw_init() looks okay.

From your boot log, it looks like you've added some debug output.
Without the actual modified source code, it's difficult to determine exactly what information is being presented.
If

[DBG]: mmc_cmd_send_op_cond() ocr=1073741824

is reporting the value of local variable and/or parameter ocr (in decimal instead of readable hexadecimal), then that is not helpful.
In mmc_verify_operating_condition() the salient datum is in command->resp[0] after the return from each mmc_cmd_send_op_cond() call.

If command->resp[0] is always zero, then the interface is probably now inactive (i.e. the eMMC is no longer responding).
Can you verify that power and clock signals to the eMMC chip are consistent during both ROMboot and AT91Bootstrap stages?

What toolchain are you using?

Regards

[SoarHuang]

Until there's a new board that utilizes a feature that requires new software,
there's probably no reason to explicitly support SAMA5D44 MRL B parts.

Okay, I see.

About value of ocr, we change it to readable hexadecimal.
Please refer log on gdrive: https://drive.google.com/file/d/1ZOMZ_V ... sp=sharing
(We couldn't upload logs since the board attachment quota has been reached.)

Can you verify that power and clock signals to the eMMC chip are consistent during both ROMboot and AT91Bootstrap stages?

We've asked EE for help and we will update results to you lately

What toolchain are you using?

ARCH=arm
CROSS_COMPILE=arm-linux-gnueabi-
Thank U.

[SoarHuang]

Hello,
Electrical Engineer reworks two boards: one sdcard slot on MMC0 and the other one on MMC1.
Booting from MMC0 failed and booting from MMC1 successful and works good.

MMC0 & MMC1 Clock/CMD/Data0 signals are uploaded in gdrive:
https://drive.google.com/drive/folders/ ... sp=sharing

Some information from Electrical Engineer:
1. MMC0 & MMC1 initial voltage are different: Since external circuit of MMC0 & MMC1 are the same, it would be effected by chip ROM code.
2. MMC0 & MMC1 are different.
3. MMC0 Clock/CMD/Data0 stop output.

Thanks your great help.

[blue_z]

About value of ocr, we change it to readable hexadecimal.

That is still useless information.
What is this "ocr"? Isn't it a constant in the loop?

ARCH=arm
CROSS_COMPILE=arm-linux-gnueabi-

That is not an appropriate response.
Where did you get the toolchain?
What version number is it?

Booting from MMC0 failed and booting from MMC1 successful and works good.

This report makes the toolchain information irrelevant; whatever toolchain that you're using does produce working code.

MMC0 & MMC1 Clock/CMD/Data0 signals are uploaded in gdrive:

I'm unable to read your rar archives.
The failure notice is "unknown archive type, only plain RAR 2.0 supported(normal and solid archives), SFX and Volumes are NOT supported!".

Some information from Electrical Engineer:
1. MMC0 & MMC1 initial voltage are different: Since external circuit of MMC0 & MMC1 are the same, it would be effected by chip ROM code.
2. MMC0 & MMC1 are different.

If you're going to claim that two things "are different", then describe those differences.
What exactly is this "information" about "MMC0" and "MMC1"?
Are you using the same/similar SD card(s) in each socket?

3. MMC0 Clock/CMD/Data0 stop output.

That is poorly worded.
Only the clock is an output.
The CMD line is bidirectional, and used as both an output and an input.
Boot operations only perform read operations, so DATA0 would only be used as an input.

Is this #3 supposed to be the phase when AT91Bootstrap is executing?
If so, then why is clock and command activity on this interface completely absent?
Isn't there a loop that repeatedly sends the SD_SEND_OP_COND command one thousand times?
This looks like this build of AT91Bootstrap is not directing any of its HSMCI activity to MMC0.
What activity is happening over at the MMC1 socket?

Regards

[SoarHuang]

What is this "ocr"? Isn't it a constant in the loop?

We added logs in line 525 of mci_media.c.
https://drive.google.com/drive/folders/ ... sp=sharing

Where did you get the toolchain?
What version number is it?

we installed it by "sudo apt install gcc-arm-linux-gnueabi".

Code: Select all

$ arm-linux-gnueabi-gcc --version
arm-linux-gnueabi-gcc (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1) 7.4.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

We also used buildroot toolchain "arm-buildroot-linux-uclibcgnueabihf", which is generated by buildroot. https://github.com/linux4sam/buildroot-at91.git

Code: Select all

$ ./buildroot-at91/output/host/bin/arm-buildroot-linux-uclibcgnueabihf-gcc --version
arm-buildroot-linux-uclibcgnueabihf-gcc.br_real (Buildroot 2019.05-dirty) 7.4.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I'm unable to read your rar archives.

We compress it as zip file, please try again.
https://drive.google.com/drive/folders/ ... sp=sharing

What exactly is this "information" about "MMC0" and "MMC1"?
Are you using the same/similar SD card(s) in each socket?

EE reworks two boards - board A & B, booting with similar SD cards. (Both are Class 4 and we also had tested with Class 10 but get same results)

Board A HW configuration:
SOC: SAMA5D44
MMC0: SD card slot
MMC1: WiFi Module

Board B HW configuration:
SOC: SAMA5D44
MMC0: eMMC5 (8 Bit width)
MMC1: SD card slot

Is this #3 supposed to be the phase when AT91Bootstrap is executing?
If so, then why is clock and command activity on this interface completely absent?
Isn't there a loop that repeatedly sends the SD_SEND_OP_COND command one thousand times?

We are not sure where is Chip ROM code/Bootstrap/uboot executing.
Maybe put Bootstrap image only into SD card would make it more clear. But it still couldn't separate Chip ROM code and Bootstrap.
Need to find some ways to locate it .....
Do you have any idea how to separate each other?

What activity is happening over at the MMC1 socket?

We add logs in mci_media.c under the AT91Bootstrap/driver folder. Please refer code files and MMC0 & MMC1 logs in gdrive:
https://drive.google.com/drive/folders/ ... sp=sharing
Viewing logs, you would see return values are different.
Hmm.... we don't know how to fix it.
MMCO: [DBG] Query Card & Voltage - mmc_cmd_send_op_cond() ret=0
MMC1: [DBG] Query Card & Voltage - mmc_cmd_send_op_cond() ret=-10
These two logs were reported by line 554 of mci_media.c.

Thank you.

[blue_z]

What is this "ocr"? Isn't it a constant in the loop?

We added logs in line 525 of mci_media.c.

For the third time, why do you persist in reporting a variable that is actually a constant (instead of the salient variable) (and waste everyone's time with redundant information)?

What activity is happening over at the MMC1 socket?

We add logs in mci_media.c under the AT91Bootstrap/driver folder. Please refer code files and MMC0 & MMC1 logs ...

By "activity" I do not mean posting more log files, but rather adding another channel(s) on your 'scope for (simultaneously) capturing signal(s) from the other socket.
Then you might see that your AT91Bootstrap is accessing the wrong HSMCI device.
On second thought, that interfce would be uninitialized, so there would be no activity either.

Turns out your patch is incomplete.
In board/sama5d4_xplained/sama5d4_xplained.h you need something like:

Code: Select all

  /*
   * MCI Settings
   */
+ #if defined(CONFIG_AT91_MCI0)
+ #define CONFIG_SYS_BASE_MCI	AT91C_BASE_HSMCI0
+ #elif defined(CONFIG_AT91_MCI1)
  #define CONFIG_SYS_BASE_MCI	AT91C_BASE_HSMCI1
+ #endif
  
  /*
   * Others

Regards

[SoarHuang]

adding another channel(s) on your 'scope for (simultaneously) capturing signal(s) from the other socket.
Then you would see that your AT91Bootstrap is accessing the wrong HSMCI device.

Good idea, thanks.

The patch of bootstrap works and here is the update.

Code: Select all

AT91Bootstrap 3.8.13 (Thu Nov 28 11:59:51 CST 2019)

All interrupts redirected to AIC
EEPROM: Loading AT24xx information ...
EEPROM: BoardName | [Revid] | VendorName
twi read: timeout to wait RXRDY bit on bus 0
EEPROM: Failed to read

EEPROM: Using default information

EEPROM: Board sn: 0x1012420 revision: 0x680820

ACT8865: Set REG1/REG2/REG3 Power-saving mode
twi read: timeout to wait RXRDY bit on bus 3
ACT8865: Disable ACT8865's I2C interface
[DBG] Try... init_load_image()
[DBG] init_load_image()
[DBG] load_sdcard()
[DBG] at91_mci0_hw_init
SD/MMC: Image: Read file u-boot.bin to 0x26f00000
[DBG] sdcard_loadimage()
[DBG] sdcard_initialize()
[DBG] CONFIG_AT91_MCI
[DBG] sdcard_identification()
[DBG] sd_cmd_go_idle_state()
[DBG] SEND CMD - ask idle_state...
[DBG] sd_cmd_go_idle_state() ret=0
[DBG] mmc_verify_operating_condition()
[DBG] mmc_cmd_send_op_cond() ocr=0x0
Cmd: 1 Response Time-out
[DBG] Query Card & Voltage - mmc_cmd_send_op_cond() ret=-10
[DBG] mmc_verify_operating_condition() ret=-10
[DBG] sd_cmd_send_if_cond() ret=0
[DBG] V2.0-sd_check_operational_condition() ret=0
SD: Card Capacity: High or Extended
[DBG] sd_cmd_all_send_cid() ret=0
[DBG] sd_cmd_send_relative_addr() ret=0
[DBG] sd_cmd_send_csd() ret=0
[DBG] sd_initialization()
SD: Specification Version 3.0X
Cmd: 12 Response Time-out
*** FATFS: f_read: error
[DBG] Try... load_image_done()
[DBG] load_image_done() retval=
SD/MMC: Failed to load image

Although it still stuck in bootstrap but it looks better than before.
We would check more and report back.
Thank you and guys behind you.