Hi All,
I build an image for SAMA5D27 for debian as described here
I noticed the following message every few seconds on the shell prompt
mmc0: Tuning timeout, falling back to fixed sampling clock
does someone have experience the same issue? I am using an industrial SD card of 8Gb p/n sdsdqaf3-008g-i.
So far the linux image seems to work fine but I got that message on the terminal and not sure how this might affect.
u-boot mmc info is
=> mmc info
Device: sdio-host@a0000000
Manufacturer ID: 3
OEM: 5344
Name: SA08G
Bus Speed: 50000000
Mode : SD High Speed (50MHz)
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 7.4 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes
Will appreciate any comments,
Manuel
Hi @mhanuel, sorry i didn’t have this board at home, just got it from work… I can confirm the same issue:
at91bootstrap: v3.8.10
u-boot: v2019.01
kernel: 4.14.144-sama5-armv7-r6
[ 144.060000] mmc0: Tuning timeout, falling back to fixed sampling clock
[ 145.180000] mmc0: Tuning timeout, falling back to fixed sampling clock
[ 146.300000] mmc0: Tuning timeout, falling back to fixed sampling clock
Hum, bumping at91bootstrap to v3.8.11 looks to fix it…
AT91Bootstrap 3.8.11 (Wed 17 Jun 2020 09:52:02 AM CDT)
SD/MMC: Image: Read file u-boot.bin to 0x23f00000
MMC: ADMA supported
SD: Card Capacity: High or Extended
SD: Specification Version 3.0X
SD/MMC: Done to load image
<debug_uart>
U-Boot 2019.01-dirty (Jun 17 2020 - 09:39:51 -0500)
CPU: SAMA5D27 1G bits DDR2 SDRAM
Crystal frequency: 24 MHz
CPU clock : 492 MHz
Master clock : 164 MHz
DRAM: 128 MiB
MMC: sdio-host@a0000000: 0, sdio-host@b0000000: 1
debian@arm:~$ dmesg | grep mmc
[ 1.620000] mmc0: SDHCI controller on a0000000.sdio-host [a0000000.sdio-host] using ADMA
[ 1.690000] mmc0: new high speed SDHC card at address 0007
[ 1.700000] mmc1: SDHCI controller on b0000000.sdio-host [b0000000.sdio-host] using ADMA
[ 1.720000] mmcblk0: mmc0:0007 SD8GB 7.42 GiB
[ 1.730000] mmcblk0: p1 p2
[ 1.950000] EXT4-fs (mmcblk0p2): INFO: recovery required on readonly filesystem
[ 1.960000] EXT4-fs (mmcblk0p2): write access will be enabled during recovery
[ 6.190000] EXT4-fs (mmcblk0p2): recovery complete
[ 6.610000] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[ 11.950000] EXT4-fs (mmcblk0p2): re-mounted. Opts: errors=remount-ro
debian@arm:~$ uname -r
4.14.144-sama5-armv7-r6
And following a reboot, it’s back…
Regards,
Hi @mhanuel, after more testing, I updated AT91Bootstrap, U-Boot and the kernel in the directions. I’ve been having much better luck running 5.4.x:
debian@arm:~$ uname -r
5.4.46-sama5-armv7-r2
debian@arm:~$ dmesg | grep mmc
[ 1.340317] mmc0: SDHCI controller on a0000000.sdio-host [a0000000.sdio-host] using ADMA
[ 1.393695] mmc1: SDHCI controller on b0000000.sdio-host [b0000000.sdio-host] using ADMA
[ 1.470622] mmc0: new ultra high speed DDR50 SDHC card at address 0007
[ 1.479880] mmcblk0: mmc0:0007 SD8GB 7.42 GiB
[ 1.489906] mmcblk0: p1 p2
[ 1.758937] EXT4-fs (mmcblk0p2): INFO: recovery required on readonly filesystem
[ 1.769464] EXT4-fs (mmcblk0p2): write access will be enabled during recovery
[ 3.686396] EXT4-fs (mmcblk0p2): recovery complete
[ 3.698023] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[ 9.144272] EXT4-fs (mmcblk0p2): re-mounted. Opts: errors=remount-ro
Regards,
Hi Robert,
Thank you for your quick response,
I have a problem that for some reason the board seems to be dead, at the beginning I thought it was my terminal that I cannot see it booting but then I confirm my setup is correct with another board which boot correctly.
I tried to load a bare metal example on the board using external Segger J-Link Plus debugger and the device cannot communicate (same stuff works on the “good one”), in short something really goes wrong that I cannot even program it, i basically just left it overnight on my desk.
Can you point me to some work around to try if possible? I know there are some caveats or different ways this arm processor boot and maybe something got corrupted?
Will appreciate your response,
Manuel
As long as there is no jumper on J14, the large SD connector should be accessed out of reset. Are you using a virtual machine to build AT91Bootstrap? In the past we’ve had issues where the virtualization environment is unable to correctly copy the “boot.bin” file to the SD card over the USB filter driver.
Regards,
Hi Robert,
Actually I cannot find any jumper number J14. J14 is actually the micro SD card connector. I was booting from SD card J12 before it stop working.
Do you think of anything else that might brick up the board ?
Many thanks,
Manuel
Hi Robert,
After inspecting a little bit more, I found the Segger led was orange which means the target is held in reset, I then measure the reset signal on the JTAG header pin 10 ans is always low level of few mV.
The board was just sitting running debian, what could be the cause of becoming always in reset ?
I just want to discard any problem with the linux image, but it is possible for a software image to produce such effect? or this might be more a hardware problem?
Looking forward for any comments,
Many thanks,
I’m really not sure, do you have “anything” connected to the headers of the SAMA5D27? All power-management options are just the mainline defaults, so the board is usable for everyone. Thus we assume end users would configure what they need for low–power, suspend, etc…
Regards,
