On Mon, Jun 19, 2023 at 5:39 AM Adam Ford <aford173@xxxxxxxxx> wrote: > > On Mon, Jun 19, 2023 at 1:02 AM Wolfram Sang > <wsa+renesas@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > Hi Adam, > > > > > > U-Boot has a 1ms delay. Could you increase the delay to 1ms, please? > > > > > > Sorry for the delay, but I increased this to usleep_range(1000, 2500) > > > and it still hangs. > > > > Sigh, back to the drawing board... But still thanks for trying! I'll try > > to come up with something better after EOSS in Prague (will you be there > > by any chance?) Wolfram, I wanted to test the 6.7-rc1 on the microSD cards to see if there has been any improvement. In the process, I found yet another card which appears to have a similar issue where U-Boot can initialize a microSD card in SDR104 mode, but Linux fails. I think this brings the total to 3 cards. These same cards work on other platforms, so I don't think there is anything wrong with the cards, especially since they work on this platform in U-Boot. I added some debug code to indicate when when the priv->taps and priv->smpcmp bits are set when executing the timing command. FWICT, the priv-taps never get set, and smpcmp appears to always be successful. [ 3.741462] priv->smpcmp set bit 0 [ 3.747404] mmc_send_tuning opcode 19 [ 3.751173] priv->smpcmp set bit 1 [ 3.757129] mmc_send_tuning opcode 19 [ 3.760860] priv->smpcmp set bit 2 [ 3.766815] mmc_send_tuning opcode 19 [ 3.770564] priv->smpcmp set bit 3 [ 3.776514] mmc_send_tuning opcode 19 [ 3.780262] priv->smpcmp set bit 4 [ 3.786213] mmc_send_tuning opcode 19 [ 3.789966] priv->smpcmp set bit 5 [ 3.795915] mmc_send_tuning opcode 19 [ 3.799662] priv->smpcmp set bit 6 [ 3.805611] mmc_send_tuning opcode 19 [ 3.809364] priv->smpcmp set bit 7 [ 3.815294] mmc_send_tuning opcode 19 [ 3.819040] priv->smpcmp set bit 8 [ 3.824988] mmc_send_tuning opcode 19 [ 3.828735] priv->smpcmp set bit 9 [ 3.834685] mmc_send_tuning opcode 19 [ 3.838432] priv->smpcmp set bit 10 [ 3.844466] mmc_send_tuning opcode 19 [ 3.848214] priv->smpcmp set bit 11 [ 3.854251] mmc_send_tuning opcode 19 [ 3.857997] priv->smpcmp set bit 12 [ 3.864032] mmc_send_tuning opcode 19 [ 3.867778] priv->smpcmp set bit 13 [ 3.873820] mmc_send_tuning opcode 19 [ 3.877566] priv->smpcmp set bit 14 [ 3.883582] mmc_send_tuning opcode 19 [ 3.887328] priv->smpcmp set bit 15 [ 3.893361] priv->tap_num = 8 [ 3.896332] taps_size = 16 [ 3.899059] tap_cnt = 0 [ 3.901518] min_tap_row = 3 [ 3.904312] renesas_sdhi_select_tuning failed [ 3.908732] mmc1: tuning execution failed: -5 When I compare the values of taps and smpcmp in U-Boot vs linux, I get U-Boot Shows: taps = dfdf priv->smpcmp = dfdf Sometimes, priv->smpcmp = df9f Linux shows: priv->taps = 0 priv->smpcmp = ffff And the Linux values are consistent. Another thing that is interesting to me is that U-Boot explicitly forces PIO when tuning and it only happens when executing "ret = mmc_send_tuning(mmc, opcode, NULL);" Is there a proper way to temporarily switch to PIO in the Linux driver to see if I can accomplish the same thing? If I eject the card before it's mounted, it waits for the card to be inserted. If I insert the card, it enumerates: [ 3.701926] renesas_sdhi_start_signal_voltage_switch: 0 [ 3.869834] renesas_sdhi_start_signal_voltage_switch: 1 [ 3.898030] mmc_send_tuning opcode 19 [ 3.907006] priv->taps set bit 0 [ 3.910232] priv->smpcmp set bit 0 [ 3.916160] mmc_send_tuning opcode 19 [ 3.919901] priv->taps set bit 1 [ 3.923142] priv->smpcmp set bit 1 [ 3.929054] mmc_send_tuning opcode 19 [ 3.932793] priv->taps set bit 2 [ 3.936034] priv->smpcmp set bit 2 [ 3.941953] mmc_send_tuning opcode 19 [ 3.945697] priv->taps set bit 3 [ 3.948938] priv->smpcmp set bit 3 [ 3.954857] mmc_send_tuning opcode 19 [ 3.958596] priv->taps set bit 4 [ 3.961836] priv->smpcmp set bit 4 [ 3.967756] mmc_send_tuning opcode 19 [ 3.974009] mmc_send_tuning opcode 19 [ 3.977749] priv->taps set bit 6 [ 3.980987] priv->smpcmp set bit 6 [ 3.986910] mmc_send_tuning opcode 19 [ 3.990636] priv->taps set bit 7 [ 3.993876] priv->smpcmp set bit 7 [ 3.999797] mmc_send_tuning opcode 19 [ 4.003535] priv->taps set bit 8 [ 4.006760] priv->smpcmp set bit 8 [ 4.012688] mmc_send_tuning opcode 19 [ 4.016427] priv->taps set bit 9 [ 4.019668] priv->smpcmp set bit 9 [ 4.025587] mmc_send_tuning opcode 19 [ 4.029326] priv->taps set bit 10 [ 4.032654] priv->smpcmp set bit 10 [ 4.038689] mmc_send_tuning opcode 19 [ 4.042422] priv->taps set bit 11 [ 4.045745] priv->smpcmp set bit 11 [ 4.051748] mmc_send_tuning opcode 19 [ 4.055484] priv->taps set bit 12 [ 4.058795] priv->smpcmp set bit 12 [ 4.064803] mmc_send_tuning opcode 19 [ 4.071044] mmc_send_tuning opcode 19 [ 4.074752] priv->taps set bit 14 [ 4.078075] priv->smpcmp set bit 14 [ 4.084077] mmc_send_tuning opcode 19 [ 4.087832] priv->taps set bit 15 [ 4.091157] priv->smpcmp set bit 15 [ 4.097152] priv->tap_num = 8 [ 4.100127] taps_size = 16 [ 4.102828] priv->taps = dfdf [ 4.105800] priv->smpcmp = dfdf [ 4.108947] tap_cnt = 7 [ 4.111395] min_tap_row = 3 [ 4.116003] mmc1: new ultra high speed SDR104 SDHC card at address 59b4 [ 4.123361] mmcblk1: mmc1:59b4 USD00 29.5 GiB [ 4.129577] mmcblk1: p1 p2 Is there some sort of reset or power-cycle that needs to be better configured? thanks, adam > > I really tried to go, but my employer declined this time. I was going > to go on my own, butI didn't have enough personal time off available > to fly out there. > > adam > > > > Happy hacking, > > > > Wolfram > >
