AM5718: Problem booting from SD card on MMC1

Fredda

Part Number: AM5718

Hi,

I’ve got a custom AM5718 board, which is based on the AM571x Industrial Development Kit (IDK) Evaluation Module (EVM) Hardware (see SPRUI97A), that is having problem to boot from an SD card sitting on MMC1.

Schematics:

VSDMMC is generated by LDO1 on the TPS6590379 PMIC and it powers the MPU VDDSHV8. The MMC lines are also pulled up to this voltage.

I get the following errors during boot:

U-Boot SPL 2017.01-00319-gfe893f7-dirty (Jun 12 2018 - 10:50:13)
DRA722-GP ES2.0
Trying to boot from MMC1
omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
spl: mmc init failed with error: -110
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

Some boards from the same batch of boards boot fine, while others show the above error messages and don’t boot.

I suspect that we’re having some signal integrity problems and/or problems with the VSDMMC voltage, which sometimes stay at 1.8 V and sometimes at 3.0 V after the board has booted. The voltage also changes between these values during boot. I haven’t looked into the details on this, how it is supposed to work, but it looks weird. Why 3.0 V and not 3.3 V? And isn’t the voltage supposed to drop to 1.8 V after the speed has been negotiated and then stay there.

Some oscilloscope screenshots:

Yellow: MMC_CLK
Blue: MMC_CMD
Green: MMC_D0

Regards
Fredrik

over 5 years ago

0 Brad Griffis over 5 years ago

TI__Guru*** 125430 points

Only if your card supports 1.8V (e.g. UHS-1 card) should the voltage drop down. So if you swap cards between a board that is 3.3V and a board that is 1.8V, does the behavior follow the card? Or you are saying some boards boot directly to 1.8V (that would not be expected).

0 Fredda over 5 years ago in reply to Brad Griffis

Intellectual 595 points

Hi,

I'm using a UHS-1 SD card. The exact same card has been used with all boards I've tested so far. And as explained, some have booted properly and some haven't booted at all.

The boards that don't boot never change voltage to 1.8 V. The inconsistency in voltage was observed on one board that booted. The VSDMMC voltage was sometimes 3.0 V and sometimes 1.8 V after the board had booted. In addition, as can be seen on the first oscilloscope screenshot, it seems like the voltage changes from 1.8 V to 3.0 V when the bus is idle. I'm not very familiar with the MMC interface and can't tell if it is supposed to work like that or not.

0 Fredda over 5 years ago in reply to Fredda

Intellectual 595 points

Some more observations.

The PMIC is configured to automatically start the MPU when the PMIC is powered. When starting/booting the MPU by turning on the board power, the VSDMCC voltage will drop to 1.8 V. However, if rebooting the MPU (when the board is already powered) by asserting the PORZ input, the VSDMCC voltage will stay at 3.0 V.

To summarize. About 25% of the boards I've tested don't boot. I see two possible scenarios:

1. Something went wrong in the manufacturing process of the boards that don't boot. However, I haven't found anything obvious yet.
2. The design is somehow wrong, that is, problems with PinMUX, device tree, hardware etc. But the problems are of the subtle type and only show on some boards perhaps because of component variations.

In any case, I would like to understand/know if the MMC interface is supposed to work like described in the previous posts.

/F

0 peaves over 5 years ago in reply to Fredda

TI__Guru 58865 points

The faster transfer speeds supported by UHS-I cards require 1.8V signaling. SD card communications begins with 3.3 signaling to support backwards compatibility with legacy cards that only support 3.3V signaling.

A host that supports UHS-I cards will begin communicating with the card using 3.3V signaling to determine card capabilities. If the host determines the attached card supports 1.8V signaling, it will send a voltage change command to the card, wait a specified time for the voltage change to complete, then resume communicating with the card using 1.8V signaling.

Your host software will need to send a command to the PMIC and change the voltage applied to VDDSHV8 when appropriate.

I’m not sure what is causing your issue, but the scope captures clearly show there is an issue with voltage change relative to frequency change.

The first scope capture seems to indicate the external pull-up supply is 3.3V, but the signal swing is reduced. Are you sure VDDSHV8 is connected to the same source as the external pull-up resistors?

I see a similar voltage rise between data transfers in the second capture. This seems to indicate the external pull-up resistors are being sourced by a 3.3V supply which causes the voltage to rise when the signal is not driven. However, I can tell the signals are being driven by an output buffer operating at 1.8V based on the fast rise time and 1.8V signal swing. Also the clock frequency is 48MHz.

You should double check your PCB design to confirm the VDDSHV8 power pins and external pull-up resistors are both being powered from the PMIC output that is expected to change at the appropriate time. Also verify the PMIC voltage change occurs at the appropriate time. If not, you need to understand what is happening in your software.

Regards,
Paul

0 Fredda over 5 years ago in reply to peaves

Intellectual 595 points

Thanks for the answer.

Yes, VDDSHV8 is connected to the same voltage (VSDMMC) as the pull-up resistors and as described in the first post, VSDMMC is generated by LDO1 on the TPS6590379 PMIC and it powers the MPU VDDSHV8.

By the way, the scope I'm using has a 200 MHz analog bandwidth and thus the captures of the 48 MHz clock is somewhat limited in detail.

To me it seems like the PMIC changes (after being told so my the MPU?) the LDO1 output between 3.3 V and 1.8 V in some way that doesn't seem right.

I will check the AM571x Industrial Development Kit (IDK) Evaluation Module (EVM) Hardware (SPRUI97A) to see if that board behaves in the same way. The MMC1 design on our custom board is identical to that on the IDK board.

Regards
Fredrik

0 Brad Griffis over 5 years ago in reply to Fredda

TI__Guru*** 125430 points

Can you put a probe on VSDMMC? I would like to see in the case where the data lines are mysteriously floating up to 3.3V if that's because the entire VSDMMC rail is being pulled up somehow. On a related topic, can you please verify that the VSDMMC rail is not used to power anything else on the board.

What operating system are you using? Is this Linux? Do you even get to Linux, or are these screenshots taken during u-boot?

0 Fredda over 5 years ago in reply to Brad Griffis

Intellectual 595 points

I was just about to post an update on the VSDMMC voltage...

The VSDMMC voltage is NOT changing between 1.8 V and 3.0 V all the time as one may think by looking at the first oscilloscope capture, VSDMMC is at 3.0 V all the time. It seems like the MPU and the SD card negotiate the bus speed mode, which is then set at SDR25. When the SD card drives the data line, it drives it to 1.8 V. But when it "releases" the line, the line is pulled up to 3.0 V, which indicates that the MPU hasn't commanded the PMIC to change the LDO1 voltage to 1.8 V.

I can confirm that the VSDMMC rail is not used to power anything else on the board.

It's Linux. The screenshots are taken during u-boot and the board is actually booting properly and Linux i started. But as I described I have some boards that don't boot and I suspect that I'm just lucky that some of the boards are booting properly.

Also note that the VSDMMC is at 3.0 V and not at 3.3 V. When asserting the PORZ pin on the MPU and holding it asserted, the VSDMCC voltage is at 3.3 V, but as soon as PORZ is deasserted the voltage drops to 3.0 V

/F

0 Fredda over 5 years ago in reply to Fredda

Intellectual 595 points

Double post.

0 peaves over 5 years ago in reply to Fredda

TI__Guru 58865 points

If VDDSHV8 is 3.0V or 3.3V we should not be seeing a 1.8V signal rate when the host is driving the bus. I think the card is switching voltage and the scope capture represents a period of time where the card is driving and the pull-ups are at 3.0V or 3.3V.

Based on your measurements, it sounds like the PMIC is not changing voltage and this is your primary problem. Check the communication path to the PMIC and/or your software to confirm it is working as expected.

Regards,
Paul

0 Brad Griffis over 5 years ago in reply to peaves

TI__Guru*** 125430 points

I concur with Paul. You either have an issue with your I2C, or an issue with how your software was configured.

There are "PBIAS" registers inside the AM57xx that relate to the voltage on the MMC pins. It sounds like those are being configured for 1.8V operation but VSDMMC is still at 3.0V.

0 Fredda over 5 years ago in reply to Brad Griffis

Intellectual 595 points

To add to the confusion. As described in a previous post, the PMIC is configured to automatically start the MPU when the board is powered. When Linux is booted at power on, the VSDMMC voltage seems to behave as it should, it goes down to 1.8 V a short while after the boot process has started. This indicates that the I2C communication is working.

However, if rebooting the system by asserting PORZ, the VSDMMC voltage will stay at 3.0 V and the MMC signals will look as in the first oscilloscope capture.

If we return to the boards that don't start at all, do the error messages reveal any useful information?

U-Boot SPL 2017.01-00319-gfe893f7-dirty (Jun 12 2018 - 10:50:13)
DRA722-GP ES2.0
Trying to boot from MMC1
omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
spl: mmc init failed with error: -110
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

0 Fredda over 5 years ago in reply to Fredda

Intellectual 595 points

Some more scope captures.

Yellow: MMC_CLK
Blue: MMC_CMD
Green: MMC_D0
Purple: VSDMMC

The capture shows the MMC lines during power on for a board that is booting properly. VSDMMC drops down to 1.8 V after a while as it should.

For a board that doesn't boot, the activity on the bus just stops after a while:

Zooming in on the signals doesn't show anything suspicious:

0 peaves over 5 years ago in reply to Fredda

TI__Guru 58865 points

The first scope screen snapshot shows a voltage change with communications resuming at 1.8V, so this is what you would expect.

The waveforms shown in the other scope screen snapshots indicate the PMIC is not changing the supply voltage when it should. The second one shows as bust of activity followed by a voltage change (3.3V to 3.0V) and another short bust of activity. The third (zoom of the second) shows a 400kHz clock while the voltage was still at 3.3V, so this zoomed portion of the waveform still looks okay.

It looks like software tried to change the supply voltage and communications tried to resume, but the supply only changed to 3.0V rather than 1.8V. This indicates something is trying to communicate with the PMIC, but it is not clear why some of your systems would change to 1.8V while other only change to 3.0V. You may need to connect a scope to the PMIC I2C bus that is able to decode I2C commands to help understand what is happening relative to the other activity.

Regards,
Paul

0 Fredda over 5 years ago in reply to peaves

Intellectual 595 points

I've been looking at the AM572x IDK (SPRUI64A) and it seems to behave in almost the same way as our custom boards, which is not very surprising since we've copied the design to a large degree.

OS: am57xx-evm-linux-rt-05.02.00.10.img

Yellow: MMC_CLK
Blue: MMC_CMD
Green: MMC_D0
Purple: VSDMMC

Below capture shows that the VSDMMC is at 3.0 V, but the SD card operates at 1.8 V.

Below capture shows the MMC signals at power on. VSDMMC changes to 1.8 V after a while, but goes back to 3.0 V. The SD card, however, continues to operate at 1.8 V.

Something is obviously wrong with the configuration of the VSDMMC voltage, but the IDK board and most of our custom boards boot fine anyway. So if the VSDMMC voltage has something to do with our boards that don't boot is still unclear to me.

0 RonB over 5 years ago in reply to Fredda

TI__Mastermind 30396 points

Hi Fredrik,

I'm collaborating with Paul on this one from a SW standpoint. We did a test today to see if we could see what you are as far as the voltage goes. Unfortunately, we were not able to. We used an AM572x IDK with the Processor SDK for Linux with v5.02 on it and measured the voltage with Linux booted. We saw 1.8. I also used the below command in Linux to check the voltage and it also shows 1.8V. Here is the output from my setup:

root@am57xx-evm:/sys/class/mmc_host/mmc0/device# cat /sys/kernel/debug/mmc0/ios
clock: 192000000 Hz
vdd: 21 (3.3 ~ 3.4 V)
bus mode: 2 (push-pull)
chip select: 0 (don't care)
power mode: 2 (on)
bus width: 2 (4 bits)
timing spec: 6 (sd uhs SDR104)
signal voltage: 1 (1.80 V)
driver type: 0 (driver type B)

Can you try this on your end?

Also, you indicated you were using v5.02 as well. But, the U-Boot banner in your messages above corresponds to an older U-Boot than what is in v5.02. You may want to try the U-Boot version that comes with 5.02 to see if that makes a difference. This may be caused by something that was fixed in the later version.

I hope this is helpful to you. Thanks.

0 Fredda over 5 years ago in reply to RonB

Intellectual 595 points

Thanks for looking into this.

The U-Boot banner in my message was from our custom board. I was using m57xx-evm-linux-rt-05.02.00.10.img on the AM572x IDK.

Have you tried to measure the voltage when you reboot the board by pressing the PORZ button?

I will try the command you provided.

0 peaves over 5 years ago in reply to Fredda

TI__Guru 58865 points

Last week, we did not check the voltage after pressing reset. So we tried today and saw similar results.

I wanted to see what would happen if we removed the card and reinserted it while holding reset. When we do this, the system reinitializes as expected to SDR104 mode with 1.8V signaling.

Can you perform this test to confirm you get the same results?

Here is what I think is happening. The card is told to change to 1.8V signaling during the initial power-on initialization sequence and it remains in this mode when the host is reset and attempts to reinitialize using 3.3V signaling. The card doesn’t have a reset, so it doesn’t know the system was reset and is still using 1.8V signaling. Communications between the devices seems to be partially functional when the two devices are operating at different signal voltages.

We are in the process of discussing this observation with your Linux driver team.

Regards,
Paul

0 Fredda over 5 years ago in reply to peaves

Intellectual 595 points

I seem to have an issue with the IDK since the VSDMMC voltage just temporarily goes down to 1.8 V as can be seen in the scope capture. However, removing and reinserting the card while holding reset gives the same result as in the scope capture whereas just pushing the reset button never makes VSDMMC go down to 1.8. So, I guess this confirms that I get the same results as you and that your theory seems probable.

I have attached the boot messages:

AM572x IDK boot messages.txt

U-Boot SPL 2018.01-g313dcd69c2 (Dec 16 2018 - 10:03:08)
DRA752-GP ES2.0
Trying to boot from MMC1
no pinctrl state for default mode
no pinctrl state for default mode


U-Boot 2018.01-g313dcd69c2 (Dec 16 2018 - 10:03:08 +0000)

CPU  : DRA752-GP ES2.0
Model: TI AM5728 IDK
Board: AM572x IDK REV 1.3B
DRAM:  2 GiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
GUID Partition Table Header signature is wrong: 0x0 != 0x5452415020494645
part_get_info_efi: *** ERROR: Invalid GPT ***
GUID Partition Table Header signature is wrong: 0x0 != 0x5452415020494645
part_get_info_efi: *** ERROR: Invalid Backup GPT ***
SCSI:  SATA link 0 timeout.
AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: 64bit ncq stag pm led clo only pmp pio slum part ccc apst
scanning bus for devices...
Found 0 device(s).
Net:
Warning: ethernet@48484000 using MAC address from ROM
eth0: ethernet@48484000
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
** Unable to read file boot.scr **
1490 bytes read in 3 ms (484.4 KiB/s)
Loaded env from uEnv.txt
Importing environment from mmc0 ...
Running uenvcmd ...
1 bytes read in 1 ms (1000 Bytes/s)
Already setup.
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
3985920 bytes read in 218 ms (17.4 MiB/s)
101271 bytes read in 29 ms (3.3 MiB/s)
## Flattened Device Tree blob at 88000000
   Booting using the fdt blob at 0x88000000
   Loading Device Tree to 8ffe4000, end 8ffffb96 ... OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.14.79-rt47-g28d73230da (oe-user@oe-host) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #1 SMP PREEMPT RT Sun Dec 16 04:27:40 UTC 2018
[    0.000000] CPU: ARMv7 Processor [412fc0f2] revision 2 (ARMv7), cr=30c5387d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[    0.000000] OF: fdt: Machine model: TI AM5728 IDK
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] efi: Getting EFI parameters from FDT:
[    0.000000] efi: UEFI not found.
[    0.000000] Reserved memory: created CMA memory pool at 0x0000000095800000, size 56 MiB
[    0.000000] OF: reserved mem: initialized node ipu2-memory@95800000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created CMA memory pool at 0x0000000099000000, size 64 MiB
[    0.000000] OF: reserved mem: initialized node dsp1-memory@99000000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created CMA memory pool at 0x000000009d000000, size 32 MiB
[    0.000000] OF: reserved mem: initialized node ipu1-memory@9d000000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created CMA memory pool at 0x000000009f000000, size 8 MiB
[    0.000000] OF: reserved mem: initialized node dsp2-memory@9f000000, compatible id shared-dma-pool
[    0.000000] cma: Reserved 24 MiB at 0x00000000fe400000
[    0.000000] OMAP4: Map 0x00000000ffd00000 to fe600000 for dram barrier
[    0.000000] DRA752 ES2.0
[    0.000000] percpu: Embedded 15 pages/cpu @eed34000 s32032 r8192 d21216 u61440
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 472640
[    0.000000] Kernel command line: console=ttyO2,115200n8 root=PARTUUID=039f801c-02 rw rootfstype=ext4 rootwait
[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Memory: 1675132K/1897472K available (8192K kernel code, 358K rwdata, 2596K rodata, 2048K init, 289K bss, 33924K reserved, 188416K cma-reserved, 1283072K highmem)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
[    0.000000]     vmalloc : 0xf0800000 - 0xff800000   ( 240 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xf0000000   ( 768 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc0a00000   (10208 kB)
[    0.000000]       .init : 0xc0e00000 - 0xc1000000   (2048 kB)
[    0.000000]       .data : 0xc1000000 - 0xc1059860   ( 359 kB)
[    0.000000]        .bss : 0xc105b000 - 0xc10a3690   ( 290 kB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000]  RCU priority boosting: priority 1 delay 500 ms.
[    0.000000]  No expedited grace period (rcu_normal_after_boot).
[    0.000000]  Tasks RCU enabled.
[    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[    0.000000] GIC: Using split EOI/Deactivate mode
[    0.000000] OMAP clockevent source: timer1 at 32786 Hz
[    0.000000] arch_timer: cp15 timer(s) running at 6.14MHz (phys).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x16af5adb9, max_idle_ns: 440795202250 ns
[    0.000004] sched_clock: 56 bits at 6MHz, resolution 162ns, wraps every 4398046511023ns
[    0.000010] Switching to timer-based delay loop, resolution 162ns
[    0.000365] clocksource: 32k_counter: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 58327039986419 ns
[    0.000368] OMAP clocksource: 32k_counter at 32768 Hz
[    0.000831] Console: colour dummy device 80x30
[    0.000950] WARNING: Your 'console=ttyO2' has been replaced by 'ttyS2'
[    0.000952] This ensures that you still see kernel messages. Please
[    0.000953] update your kernel commandline.
[    0.000969] Calibrating delay loop (skipped), value calculated using timer frequency.. 12.29 BogoMIPS (lpj=61475)
[    0.000977] pid_max: default: 32768 minimum: 301
[    0.001091] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.001100] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.001738] CPU: Testing write buffer coherency: ok
[    0.001765] CPU0: Spectre v2: using ICIALLU workaround
[    0.001985] /cpus/cpu@0 missing clock-frequency property
[    0.002023] /cpus/cpu@1 missing clock-frequency property
[    0.002034] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.039932] Setting up static identity map for 0x80200000 - 0x80200060
[    0.079931] Hierarchical SRCU implementation.
[    0.140452] EFI services will not be available.
[    0.160078] smp: Bringing up secondary CPUs ...
[    0.260515] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.260519] CPU1: Spectre v2: using ICIALLU workaround
[    0.260628] smp: Brought up 1 node, 2 CPUs
[    0.260644] SMP: Total of 2 processors activated (24.59 BogoMIPS).
[    0.260652] CPU: All CPU(s) started in HYP mode.
[    0.260659] CPU: Virtualization extensions available.
[    0.261386] devtmpfs: initialized
[    0.291570] random: get_random_u32 called from bucket_table_alloc+0x14c/0x288 with crng_init=0
[    0.291848] VFP support v0.3: implementor 41 architecture 4 part 30 variant f rev 0
[    0.292099] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.292118] futex hash table entries: 512 (order: 3, 32768 bytes)
[    0.296034] pinctrl core: initialized pinctrl subsystem
[    0.296807] DMI not present or invalid.
[    0.297260] NET: Registered protocol family 16
[    0.299800] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.300857] omap_hwmod: l3_main_2 using broken dt data from ocp
[    0.518064] OMAP GPIO hardware version 0.1
[    0.554060] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
[    0.554072] hw-breakpoint: maximum watchpoint size is 8 bytes.
[    0.554488] omap4_sram_init:Unable to allocate sram needed to handle errata I688
[    0.554498] omap4_sram_init:Unable to get sram pool needed to handle errata I688
[    0.555810] OMAP DMA hardware revision 0.0
[    0.572126] edma 43300000.edma: memcpy is disabled
[    0.577980] edma 43300000.edma: TI EDMA DMA engine driver
[    0.590463] omap-dma-engine 4a056000.dma-controller: OMAP DMA engine driver (LinkedList1/2/3 supported)
[    0.596207] omap-iommu 40d01000.mmu: 40d01000.mmu registered
[    0.596670] omap-iommu 40d02000.mmu: 40d02000.mmu registered
[    0.597232] omap-iommu 58882000.mmu: 58882000.mmu registered
[    0.597772] omap-iommu 55082000.mmu: 55082000.mmu registered
[    0.598473] omap-iommu 41501000.mmu: 41501000.mmu registered
[    0.598941] omap-iommu 41502000.mmu: 41502000.mmu registered
[    0.599399] iommu: Adding device 58820000.ipu to group 1
[    0.599590] iommu: Adding device 55020000.ipu to group 2
[    0.599933] iommu: Adding device 40800000.dsp to group 0
[    0.600514] iommu: Adding device 41000000.dsp to group 3
[    0.603429] palmas 0-0058: Irq flag is 0x00000004
[    0.633402] palmas 0-0058: Muxing GPIO 2f, PWM 0, LED 0
[    0.635136] SMPS12: supplied by regulator-dummy
[    0.637031] SMPS3: supplied by VMAIN
[    0.638806] SMPS45: supplied by regulator-dummy
[    0.640847] SMPS6: supplied by VMAIN
[    0.642763] SMPS7: supplied by VMAIN
[    0.644817] SMPS8: supplied by VMAIN
[    0.646305] SMPS9: supplied by VMAIN
[    0.647490] LDO1: supplied by VMAIN
[    0.652582] LDO2: supplied by VMAIN
[    0.662421] LDO3: supplied by VMAIN
[    0.672469] LDO4: supplied by VMAIN
[    0.682467] LDO5: supplied by regulator-dummy
[    0.683406] LDO6: supplied by regulator-dummy
[    0.684337] LDO7: supplied by regulator-dummy
[    0.685279] LDO8: supplied by regulator-dummy
[    0.686220] LDO9: supplied by VMAIN
[    0.692813] LDOLN: supplied by VMAIN
[    0.702511] LDOUSB: supplied by VMAIN
[    0.716489] omap_i2c 48070000.i2c: bus 0 rev0.12 at 400 kHz
[    0.716772] media: Linux media interface: v0.10
[    0.716828] Linux video capture interface: v2.00
[    0.716947] pps_core: LinuxPPS API ver. 1 registered
[    0.716955] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.716977] PTP clock support registered
[    0.717019] EDAC MC: Ver: 3.0.0
[    0.717403] dmi: Firmware registration failed.
[    0.717964] omap-mailbox 48840000.mailbox: omap mailbox rev 0x400
[    0.718355] omap-mailbox 48842000.mailbox: omap mailbox rev 0x400
[    0.718921] Advanced Linux Sound Architecture Driver Initialized.
[    0.719998] clocksource: Switched to clocksource arch_sys_counter
[    0.733117] NET: Registered protocol family 2
[    0.733972] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[    0.734057] TCP bind hash table entries: 8192 (order: 5, 229376 bytes)
[    0.734325] TCP: Hash tables configured (established 8192 bind 8192)
[    0.734459] UDP hash table entries: 512 (order: 3, 32768 bytes)
[    0.734511] UDP-Lite hash table entries: 512 (order: 3, 32768 bytes)
[    0.734785] NET: Registered protocol family 1
[    0.735259] RPC: Registered named UNIX socket transport module.
[    0.735270] RPC: Registered udp transport module.
[    0.735279] RPC: Registered tcp transport module.
[    0.735288] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.736654] hw perfevents: no interrupt-affinity property for /pmu, guessing.
[    0.736991] hw perfevents: enabled with armv7_cortex_a15 PMU driver, 7 counters available
[    0.738847] workingset: timestamp_bits=14 max_order=19 bucket_order=5
[    0.746836] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.747723] NFS: Registering the id_resolver key type
[    0.747756] Key type id_resolver registered
[    0.747766] Key type id_legacy registered
[    0.747837] ntfs: driver 2.1.32 [Flags: R/O].
[    0.749836] bounce: pool size: 64 pages
[    0.749887] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 245)
[    0.749900] io scheduler noop registered
[    0.749910] io scheduler deadline registered
[    0.750134] io scheduler cfq registered (default)
[    0.750147] io scheduler mq-deadline registered
[    0.750156] io scheduler kyber registered
[    0.756492] pinctrl-single 4a003400.pinmux: 282 pins at pa fc003400 size 1128
[    0.761080] dra7-pcie 51000000.pcie: Linked as a consumer to phy-4a094000.pciephy.1
[    0.761626] OF: PCI: host bridge /ocp/axi@0/pcie@51000000 ranges:
[    0.761662] OF: PCI:    IO 0x20003000..0x20012fff -> 0x00000000
[    0.761689] OF: PCI:   MEM 0x20013000..0x2fffffff -> 0x20013000
[    1.760223] dra7-pcie 51000000.pcie: phy link never came up
[    1.760456] dra7-pcie 51000000.pcie: PCI host bridge to bus 0000:00
[    1.760475] pci_bus 0000:00: root bus resource [bus 00-ff]
[    1.760486] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
[    1.760497] pci_bus 0000:00: root bus resource [mem 0x20013000-0x2fffffff]
[    1.760895] PCI: bus0: Fast back to back transfers disabled
[    1.761030] PCI: bus1: Fast back to back transfers enabled
[    1.761074] pci 0000:00:00.0: BAR 0: assigned [mem 0x20100000-0x201fffff 64bit]
[    1.761092] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
[    1.761738] pcieport 0000:00:00.0: Signaling PME with IRQ 173
[    1.762026] pcieport 0000:00:00.0: AER enabled with IRQ 173
[    1.768058] V3_3D: supplied by smps9
[    1.768391] vtt_fixed: supplied by V3_3D
[    1.841750] Serial: 8250/16550 driver, 10 ports, IRQ sharing disabled
[    1.846376] 48020000.serial: ttyS2 at MMIO 0x48020000 (irq = 45, base_baud = 3000000) is a 8250
[    2.902959] console [ttyS2] enabled
[    2.909170] omap_rng 48090000.rng: Random Number Generator ver. 20
[    2.916663] DSS: OMAP DSS rev 6.1
[    2.922608] omapdss_dss 58000000.dss: bound 58001000.dispc (ops dispc_component_ops)
[    2.931350] omapdss_dss 58000000.dss: bound 58040000.encoder (ops hdmi5_component_ops)
[    2.959918] brd: module loaded
[    2.974813] loop: module loaded
[    2.984840] m25p80 spi0.0: s25fl256s1 (32768 Kbytes)
[    2.989892] 7 ofpart partitions found on MTD device spi0.0
[    2.995405] Creating 7 MTD partitions on "spi0.0":
[    3.000224] 0x000000000000-0x000000040000 : "QSPI.SPL"
[    3.006556] 0x000000040000-0x000000140000 : "QSPI.u-boot"
[    3.013098] 0x000000140000-0x0000001c0000 : "QSPI.u-boot-spl-os"
[    3.020317] 0x0000001c0000-0x0000001d0000 : "QSPI.u-boot-env"
[    3.027195] 0x0000001d0000-0x0000001e0000 : "QSPI.u-boot-env.backup1"
[    3.034789] 0x0000001e0000-0x0000009e0000 : "QSPI.kernel"
[    3.041334] 0x0000009e0000-0x000002000000 : "QSPI.file-system"
[    3.049270] libphy: Fixed MDIO Bus: probed
[    3.110057] davinci_mdio 48485000.mdio: davinci mdio revision 1.6, bus freq 1000000
[    3.117752] davinci_mdio 48485000.mdio: detected phy mask fffffffc
[    3.138933] libphy: 48485000.mdio: probed
[    3.142967] davinci_mdio 48485000.mdio: phy[0]: device 48485000.mdio:00, driver Micrel KSZ9031 Gigabit PHY
[    3.152668] davinci_mdio 48485000.mdio: phy[1]: device 48485000.mdio:01, driver Micrel KSZ9031 Gigabit PHY
[    3.163635] cpsw 48484000.ethernet: Detected MACID = 7c:38:66:7a:ca:50
[    3.170285] cpsw 48484000.ethernet: initialized cpsw ale version 1.4
[    3.176672] cpsw 48484000.ethernet: ALE Table size 1024
[    3.181933] cpsw 48484000.ethernet: device node lookup for pps timer failed
[    3.188966] cpsw 48484000.ethernet: cpts: overflow check period 500 (jiffies)
[    3.197280] cpsw 48484000.ethernet: cpsw: Detected MACID = 7c:38:66:7a:ca:51
[    3.206428] i2c /dev entries driver
[    3.211396] IR NEC protocol handler initialized
[    3.215951] IR RC5(x/sz) protocol handler initialized
[    3.221027] IR RC6 protocol handler initialized
[    3.225578] IR JVC protocol handler initialized
[    3.230127] IR Sony protocol handler initialized
[    3.234766] IR SANYO protocol handler initialized
[    3.239491] IR Sharp protocol handler initialized
[    3.244388] IR MCE Keyboard/mouse protocol handler initialized
[    3.250248] IR XMP protocol handler initialized
[    3.260637] sdhci: Secure Digital Host Controller Interface driver
[    3.266847] sdhci: Copyright(c) Pierre Ossman
[    3.272134] sdhci-pltfm: SDHCI platform and OF driver helper
[    3.279481] sdhci-omap 4809c000.mmc: Got CD GPIO
[    3.285568] sdhci-omap 4809c000.mmc: no pinctrl state for ddr_1_8v mode
[    3.292221] sdhci-omap 4809c000.mmc: no pinctrl state for hs200_1_8v mode
[    3.360386] mmc0: SDHCI controller on 4809c000.mmc [4809c000.mmc] using ADMA
[    3.408073] mmc0: host does not support reading read-only switch, assuming write-enable
[    3.418999] mmc0: new high speed SDHC card at address 0007
[    3.424970] mmcblk0: mmc0:0007 SD32G 29.0 GiB
[    3.430056] mmc1: SDHCI controller on 480b4000.mmc [480b4000.mmc] using ADMA
[    3.442175]  mmcblk0: p1 p2
[    3.451899] NET: Registered protocol family 10
[    3.457777] Segment Routing with IPv6
[    3.461548] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[    3.468206] NET: Registered protocol family 17
[    3.473118] Key type dns_resolver registered
[    3.477548] omap_voltage_late_init: Voltage driver support not added
[    3.483932] Power Management for TI OMAP4+ devices.
[    3.489164] Registering SWP/SWPB emulation handler
[    3.501548] mmc1: new DDR MMC card at address 0001
[    3.506915] mmcblk1: mmc1:0001 R1J56L 13.8 GiB
[    3.520091] mmcblk1boot0: mmc1:0001 R1J56L partition 1 4.00 MiB
[    3.526327] mmcblk1boot1: mmc1:0001 R1J56L partition 2 4.00 MiB
[    3.532540] mmcblk1rpmb: mmc1:0001 R1J56L partition 3 128 KiB
[    3.537952] dmm 4e000000.dmm: workaround for errata i878 in use
[    3.540734] dmm 4e000000.dmm: initialized all PAT entries
[    3.550214] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    3.556862] [drm] No driver support for vblank timestamp query.
[    3.563732] [drm] Cannot find any crtc or sizes
[    3.571489] [drm] Initialized omapdrm 1.0.0 20110917 for omapdrm.0 on minor 0
[    3.579376] hctosys: unable to open rtc device (rtc0)
[    3.585839] ALSA device list:
[    3.588822]   No soundcards found.
[    4.192170] EXT4-fs (mmcblk0p2): recovery complete
[    4.197884] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[    4.206075] VFS: Mounted root (ext4 filesystem) on device 179:2.
[    4.221572] devtmpfs: mounted
[    4.227459] Freeing unused kernel memory: 2048K
[    4.508302] systemd[1]: System time before build time, advancing clock.
[    4.553088] systemd[1]: systemd 234 running in system mode. (+PAM -AUDIT -SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP -LIBCRYPTSETUP -GCRYPT -GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID -ELFUTILS +KMOD -IDN2 -IDN default-hierarchy=hybrid)
[    4.574546] systemd[1]: Detected architecture arm.

Welcome to Arago 2018.10!

[    4.612277] systemd[1]: Set hostname to <am57xx-evm>.
[    4.640150] [drm] Cannot find any crtc or sizes
[    5.028679] random: systemd: uninitialized urandom read (16 bytes read)
[    5.035803] systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
[  OK  ] Started Dispatch Password Requests to Console Directory Watch.
[    5.080430] random: systemd: uninitialized urandom read (16 bytes read)
[    5.087215] systemd[1]: Listening on Network Service Netlink Socket.
[  OK  ] Listening on Network Service Netlink Socket.
[    5.130211] random: systemd: uninitialized urandom read (16 bytes read)
[    5.140495] systemd[1]: Created slice System Slice.
[  OK  ] Created slice System Slice.
[    5.170505] systemd[1]: Listening on Journal Socket (/dev/log).
[  OK  ] Listening on Journal Socket (/dev/log).
[    5.200401] systemd[1]: Listening on /dev/initctl Compatibility Named Pipe.
[  OK  ] Listening on /dev/initctl Compatibility Named Pipe.
[    5.240188] systemd[1]: Reached target Swap.
[  OK  ] Reached target Swap.
[    5.270336] systemd[1]: Listening on udev Kernel Socket.
[  OK  ] Listening on udev Kernel Socket.
[  OK  ] Listening on Process Core Dump Socket.
[  OK  ] Listening on Journal Socket.
         Starting Load Kernel Modules...
[  OK  ] Created slice User and Session Slice.
[    5.432279] cmemk: loading out-of-tree module taints kernel.
[    5.438880] CMEMK module: reference Linux version 4.14.79
[    5.445325] allocated heap buffer 0x40500000 of size 0x100000
[    5.451157] cmemk initialized
[  OK  ] Created slice system-serial\x2dgetty.slice.
[    5.462529] cryptodev: driver 1.9 loaded.
[  OK  ] Listening on udev Control Socket.
[    5.497295] usbcore: registered new interface driver usbfs
[    5.502915] usbcore: registered new interface driver hub
[    5.508384] usbcore: registered new device driver usb
[    5.521575] usbcore: registered new interface driver usbserial
[    5.545028] usbcore: registered new interface driver ftdi_sio
[    5.550906] usbserial: USB Serial support registered for FTDI USB Serial Device
[  OK  ] Listening on Syslog Socket.
         Mounting Kernel Debug File System...
         Starting Remount Root and Kernel File Systems...
[    5.675314] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
         Mounting Temporary Directory (/tmp)...
         Starting Create list of required stâ€¦ce nodes for the current kernel...
         Starting Journal Service...
[  OK  ] Reached target Slices.
[  OK  ] Created slice system-getty.slice.
[  OK  ] Started Forward Password Requests to Wall Directory Watch.
[  OK  ] Reached target Remote File Systems.
[  OK  ] Reached target Paths.
         Mounting POSIX Message Queue File System...
[  OK  ] Mounted Kernel Debug File System.
[  OK  ] Mounted POSIX Message Queue File System.
[  OK  ] Mounted Temporary Directory (/tmp).
[  OK  ] Started Journal Service.
[  OK  ] Started Load Kernel Modules.
[  OK  ] Started Remount Root and Kernel File Systems.
[  OK  ] Started Create list of required staâ€¦vice nodes for the current kernel.
         Starting Rebuild Hardware Database...
         Starting Create System Users...
         Mounting Kernel Configuration File System...
         Starting Apply Kernel Variables...
         Starting Flush Journal to Persistent Storage...
[  OK  ] Mounted Kernel Configuration File System.
[  OK  ] Started Create System Users.
[  OK  ] Started Apply Kernel Variables.
         Starting Create Static Device Nodes in /dev...
[    6.579118] systemd-journald[127]: Received request to flush runtime journal from PID 1
[  OK  ] Started Create Static Device Nodes in /dev.
[  OK  ] Started Flush Journal to Persistent Storage.
[  OK  ] Reached target Local File Systems (Pre).
         Mounting /var/volatile...
         Mounting /media/ram...
         Starting udev Kernel Device Manager...
[  OK  ] Mounted /var/volatile.
[  OK  ] Mounted /media/ram.
         Starting Load/Save Random Seed...
[  OK  ] Reached target Local File Systems.
         Starting Rebuild Journal Catalog...
         Starting Rebuild Dynamic Linker Cache...
         Starting Create Volatile Files and Directories...
[  OK  ] Started udev Kernel Device Manager.
[  OK  ] Started Load/Save Random Seed.
[  OK  ] Started Rebuild Journal Catalog.
[  OK  ] Started Create Volatile Files and Directories.
         Starting Network Time Synchronization...
         Starting Update UTMP about System Boot/Shutdown...
[  OK  ] Started Update UTMP about System Boot/Shutdown.
[  OK  ] Started Rebuild Dynamic Linker Cache.
[  OK  ] Started Network Time Synchronization.
[  OK  ] Reached target System Time Synchronized.
[  OK  ] Started Rebuild Hardware Database.
         Starting Update is Completed...
         Starting udev Coldplug all Devices...
[  OK  ] Started Update is Completed.
[    9.900777] omap-rproc 58820000.ipu: assigned reserved memory node ipu1-memory@9d000000
[    9.909016] remoteproc remoteproc0: 58820000.ipu is available
[    9.982642] omap-rproc 55020000.ipu: assigned reserved memory node ipu2-memory@95800000
[   10.020277] remoteproc remoteproc1: 55020000.ipu is available
[   10.061192] omap-rproc 40800000.dsp: assigned reserved memory node dsp1-memory@99000000
[   10.105623] remoteproc remoteproc2: 40800000.dsp is available
[   10.143942] omap-rproc 41000000.dsp: assigned reserved memory node dsp2-memory@9f000000
[   10.179672] remoteproc remoteproc3: 41000000.dsp is available
[  OK  ] Started udev Coldplug all Devices.
[  OK  ] Reached target System Initialization.
[  OK  ] Started Daily rotation of log files.
[   10.507721] remoteproc remoteproc1: powering up 55020000.ipu
[  OK  [   10.516080] remoteproc remoteproc1: Booting fw image dra7-ipu2-fw.xem4, size 3747220
] Started Daily Cleanup of Temporary Directories.
[   10.525411] omap-iommu 55082000.mmu: 55082000.mmu: version 2.1
[  OK  ] Reached target Timers.
[   10.572252] remoteproc remoteproc0: powering up 58820000.ipu
[   10.579075] remoteproc remoteproc0: Booting fw image dra7-ipu1-fw.xem4, size 6680920
[   10.600658] omap-iommu 58882000.mmu: 58882000.mmu: version 2.1
[   10.692560] virtio_rpmsg_bus virtio0: rpmsg host is online
[   10.698154] remoteproc remoteproc0: registered virtio0 (type 7)
[   10.714431] remoteproc remoteproc0: remote processor 58820000.ipu is now up
[   10.725266] virtio_rpmsg_bus virtio1: rpmsg host is online
[   10.725345] remoteproc remoteproc1: registered virtio1 (type 7)
[   10.725351] remoteproc remoteproc1: remote processor 55020000.ipu is now up
[   10.774281] virtio_rpmsg_bus virtio1: creating channel rpmsg-rpc addr 0x65
[   10.800407] virtio_rpmsg_bus virtio0: creating channel rpmsg-proto addr 0x3d
[   10.820169] virtio_rpmsg_bus virtio1: creating channel rpmsg-rpc addr 0x66
         Starting Network Service...
[  OK  ] Listening on dropbear.socket.
[  OK  ] Listening on RPCbind Server Activation Socket.
[  OK  ] Listening on Avahi mDNS/DNS-SD Stack Activation Socket.
[  OK  ] Listening on D-Bus System Message Bus Socket.
[  OK  ] Reached target Sockets.
[  OK  ] Reached target Basic System.
[   11.466718] omap_gpio 48057000.gpio: Could not set line 16 debounce to 20000 microseconds (-22)
[  OK  ] Started System Logging Service.
         Starting TI MultiCore Tools Daemon...
[   11.870132] ov2659 0-0030: Sensor detection failed (3030, 0)
         Starting Login Service...
[   11.908652] palmas-rtc 48070000.i2c:tps659038@58:tps659038_rtc: rtc core: registered 48070000.i2c:tps659038@58:tps659038_rtc as rtc0
         Starting TI IPC Daemon...
[  OK  ] Reached target Containers.
[  OK  ] Started Job spooling tools.
[   12.139678] omap_rtc 48838000.rtc: registered as rtc1
         Starting Print notice about GPLv3 packages...
[   12.174004] remoteproc remoteproc3: powering up 41000000.dsp
[   12.178124] omap-des 480a5000.des: OMAP DES hw accel rev: 2.2
[   12.203011] remoteproc remoteproc3: Booting fw image dra7-dsp2-fw.xe66, size 20392708
[   12.203014] omap-des 480a5000.des: will run requests pump with realtime priority
[   12.220189] omap_hwmod: mmu0_dsp2: _wait_target_disable failed
[   12.220243] omap-iommu 41501000.mmu: 41501000.mmu: version 3.0
[   12.220288] omap-iommu 41502000.mmu: 41502000.mmu: version 3.0
[   12.338544] virtio_rpmsg_bus virtio2: creating channel rpmsg-proto addr 0x3d
[   12.339415] virtio_rpmsg_bus virtio2: rpmsg host is online
[   12.339493] remoteproc remoteproc3: registered virtio2 (type 7)
[   12.339499] remoteproc remoteproc3: remote processor 41000000.dsp is now up
[   12.368174] SCSI subsystem initialized
         Starting Avahi mDNS/DNS-SD Stack...
[  OK  ] Started Hardware RNG Entropy Gatherer Daemon.
[  OK  ] Started D-Bus System Message Bus.
[   12.516044] remoteproc remoteproc2: powering up 40800000.dsp
[   12.548279] remoteproc remoteproc2: Booting fw image dra7-dsp1-fw.xe66, size 20392708
[   12.561015] vpe 489d0000.vpe: loading firmware vpdma-1b8.bin
[   12.600377] vpe 489d0000.vpe: Device registered as /dev/video0
[   12.631013] ahci 4a140000.sata: SSS flag set, parallel bus scan disabled
[   12.631041] ahci 4a140000.sata: AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl platform mode
[   12.631050] ahci 4a140000.sata: flags: 64bit ncq sntf stag pm led clo only pmp pio slum part ccc apst
[   12.670115] scsi host0: ahci
[   12.670574] ata1: SATA max UDMA/133 mmio [mem 0x4a140000-0x4a1410ff] port 0x100 irq 80
[   12.785544] omap_hwmod: mmu0_dsp1: _wait_target_disable failed
[   12.815595] omap-iommu 40d01000.mmu: 40d01000.mmu: version 3.0
[   12.828521] omap-iommu 40d02000.mmu: 40d02000.mmu: version 3.0
[   12.834289] vip 48990000.vip: loading firmware vpdma-1b8.bin
[  OK  ] Started Avahi mDNS/DNS-SD Stack.
         Starting RPC Bind Service...
[   12.938881] virtio_rpmsg_bus virtio3: rpmsg host is online
[   12.945211] remoteproc remoteproc2: registered virtio3 (type 7)
[   12.960112] vip 48990000.vip: VPDMA firmware loaded
[   12.974973] remoteproc remoteproc2: remote processor 40800000.dsp is now up
[   12.993920] virtio_rpmsg_bus virtio3: creating channel rpmsg-proto addr 0x3d
[   13.002634] ata1: SATA link down (SStatus 0 SControl 300)
[  OK  ] Started Kernel Logging Service.
         Starting uim-sysfs.service...
[   13.190492] net eth1: initializing cpsw version 1.15 (0)
[   13.295201] EXT4-fs (mmcblk1): recovery complete
[   13.299881] EXT4-fs (mmcblk1): mounted filesystem with ordered data mode. Opts: (null)
[   13.330691] Micrel KSZ9031 Gigabit PHY 48485000.mdio:01: attached PHY driver [Micrel KSZ9031 Gigabit PHY] (mii_bus:phy_addr=48485000.mdio:01, irq=POLL)
[  OK  ] Started Periodic Command Scheduler.
[   13.437329] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[   13.718188] net eth0: initializing cpsw version 1.15 (0)
[   13.819750] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
[  OK  ] Started Network Service.
[  OK  [   13.890486] omap-sham 4b101000.sham: hw accel on OMAP rev 4.3
] Started TI MultiCore Tools Daemon.
[   13.912515] Micrel KSZ9031 Gigabit PHY 48485000.mdio:00: attached PHY driver [Micrel KSZ [  135.261836] NET: Registered protocol family 15
[  135.392990] Initializing XFRM netlink socket

 _____                    _____           _         _
|  _  |___ ___ ___ ___   |  _  |___ ___  |_|___ ___| |_
|     |  _| .'| . | . |  |   __|  _| . | | | -_|  _|  _|
|__|__|_| |__,|_  |___|  |__|  |_| |___|_| |___|___|_|
              |___|                    |___|

Arago Project http://arago-project.org am57xx-evm ttyS2

Arago 2018.10 am57xx-evm ttyS2

am57xx-evm login: root
root@am57xx-evm:~#
root@am57xx-evm:~#

So, I'd like to return to the voltage switch between 3.0 V and 3.3 V. Have you any idea why it behaves like this?

Regards
F

0 peaves over 5 years ago in reply to Fredda

TI__Guru 58865 points

We discussed this issue with our Linux software team and were told the only way to return the SD card back to its initial operating condition is by cycling power to the card. Therefore, the system needs to implement a GPIO controlled power switch that allows software to cycle the SD card 3.3V supply to properly support UHS-1 cards. The control signal for this power switch needs to be turned on by default during power-up to support boot from SD card since the ROM boot code does not know which GPIO is used to control the power switch. The control signal also needs to be an AND logic function of the GPIO and power-on reset signal, so the power switch turns off when the system is reset without a power cycle.

With respect to your question about 3.0 volts, we observed the supply going to 3.3V after pressing the reset button on the TI IDK board with the latest software. Can you check the PMIC output on your board using the latest software to confirm this is still happening.

Regards,

Paul

0 Fredda over 5 years ago in reply to peaves

Intellectual 595 points

Hi,

Thanks for the answer. That makes perfect sense.

I can confirm that the VSDMMC voltage goes to 3.3 V when pressing the reset button. Also, the voltage is 3.3 V during the initial SD card communication, it then drops to 3.0 V after about 800 ms as shown below:

Yellow: MMC_CLK
Blue: MMC_CMD
Green: MMC_D0
Purple: MMC_D2

As for the initial problem, the reason for starting this thread, it turned out that the problem with the non booting boards was a bad solder joint at pin 8 (MMC_D1) in the SD card connector. Everything was looking fine in the microscope and even when I was measuring the resistance it looked fine, but I was probably putting pressure on the pin so it made contact with the pad.. Doh! Good thing, I guess, is that some other issues with the MMC interface was unveiled during the process.

Regards
Fredrik

0 Brad Griffis over 5 years ago in reply to Fredda

TI__Guru*** 125430 points

Fredrik,

Thanks for the updates. I'm glad to hear you've made major progress.

I'm still trying to understand why you're seeing activity at 3.0V. I was looking for possible places that could cause this issue. Clearly based on the timing this is happening in u-boot. So I was trying to find if there are any 3.0V configurations in u-boot.

[EDIT] Removed previous patch as it had no impact.

Best regards,
Brad

0 Brad Griffis over 5 years ago in reply to Brad Griffis

TI__Guru*** 125430 points

Fredrik,

I took a look on my AM572x IDK and saw the exact same issue, i.e. VSDMMC = 3.0V during u-boot. After a bit more digging I found the culprit. Here's a quick hack that resolves the issue:

diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index f12437c616..665bddceec 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -265,7 +265,7 @@ static unsigned char mmc_board_init(struct mmc *mmc)
!CONFIG_IS_ENABLED(DM_REGULATOR)
/* PBIAS config needed for MMC1 only */
if (mmc_get_blk_desc(mmc)->devnum == 0)
- vmmc_pbias_config(LDO_VOLT_3V0);
+ vmmc_pbias_config(LDO_VOLT_3V3);
#endif

return 0;

I call it a "hack" because it would cause issues for OMAP4 users that actually want 3.0V. For the purpose of getting 3.3V configured on AM57xx this should be ok.

Please give it a try and confirm that things are working as expected for you.

Best regards,
Brad

0 Fredda over 5 years ago in reply to Brad Griffis

Intellectual 595 points

It made a difference, but it still toggles between 3.0 V and 3.3 V.

Before change:

After change:

Regards
Fredrik

0 Brad Griffis over 5 years ago in reply to Fredda

TI__Guru*** 125430 points

Thanks for checking. I did a little more looking and I think I found the remaining place that needs to be fixed. Are you able to try this too:

diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 665bddceec..4d9c6a94a5 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -518,7 +518,7 @@ static int omap_hsmmc_set_signal_voltage(struct mmc *mmc)
/* Use 3.0V rather than 3.3V */
mv = 3000;
capa_mask = VS30_3V0SUP;
- palmas_ldo_volt = LDO_VOLT_3V0;
+ palmas_ldo_volt = LDO_VOLT_3V3;
} else if (mmc->signal_voltage == MMC_SIGNAL_VOLTAGE_180) {
capa_mask = VS18_1V8SUP;
palmas_ldo_volt = LDO_VOLT_1V8;

0 Fredda over 5 years ago in reply to Brad Griffis

Intellectual 595 points

Hi,

It seems like we're using an older SDK for our custom boards and we couldn't find those lines in omap_hsmmc.c. The two last scope captures were from our custom board and not from the IDK. Don't think I mentioned that. Sorry for the confusion.

0 peaves over 5 years ago in reply to Fredda

TI__Guru 58865 points

I previously mention how the SD Card power needs to be controlled with a power switch to re-initialize the card anytime the processor is reset without power cycling the entire system. I also mentioned how the power switch control needs to be gated with power-up reset. I have some additional information that you may find useful if you plan to implement the card power switch and gate it off with reset.

The SD card specification says it should not be accessed for 1ms after power has been applied. So the power-up reset signal used to gate the card power switch needs to ensure power is applied to the card at least 1ms before the processor is released from reset to make sure ROM boot code doesn't access the card before it is ready. Therefore, you may need to create two power-on reset signals where one is used to gate the card power switch and another releases reset to the processor 1ms after power is applied to the card.

The SD card specification also defines the minimum off period by requiring the card power source to be less than 0.5V for more than 1ms before power is applied. So it may be necessary to use a power switch that discharges its output when disabled to ensure the card power rail drops below 0.5V within the duration of the reset used to gate power to the card.

Regards,
Paul

Processors

Processors forum

AM5718: Problem booting from SD card on MMC1