BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz)

[Warner Losh]

On May 19, 2014, at 7:57 PM, Sulev-Madis Silber (ketas) <madis555 at hot.ee> wrote:

> On 2014-05-20 04:52, Sulev-Madis Silber (ketas) wrote:
>> On 2014-05-19 16:20, Sulev-Madis Silber (ketas) wrote:
>>> Hello.
>>> 
>>> Although maybe I could write this as reply to some other message, I feel
>>> like it might deserve separate one.
>>> 
>>> I use U-Boot 2014.04 which sets CPU frequency to 1GHz, which seems nice.
>>> Apart from inability to find eMMC in ubldr (SD card is always fine), now
>>> I get whole different issues here. With 2013.04, I get occasional eMMC
>>> failure I mentioned earlier. With 2014.04, it's very hard to get SD
>>> devices detected at all. And I get all sorts of weird errors (megabytes
>>> of boot logs from serial if anyone wishes to see). I'm aware how HW
>>> clock changes can affect things like this, but I'm not exactly sure
>>> where and what happens when this is done. If I boot with 2013.04, it's
>>> ok again, if I switch to 2014.04 again, it's ok again for a while. It
>>> really feels like it's overheating. After a while, it gets extremely
>>> hard to get thing booted up. Both devices sometimes detect and sometimes
>>> not. I get things like "no compatible cards found on bus" (mmc 0/1), or
>>> things like "card at relative address x lost". Tried adding delays like
>>> suggested earlier, but that doesn't help and now the issue seems
>>> different. I get no other issues. System is very stable once it's booted
>>> up. There are no hangs, panics... Everything works. I must mention that
>>> I always use latest CURRENT. I didn't find a way to make kernel reboot
>>> system when root mount fails, so I manually patched that option in. Last
>>> time I got 11 failures before it booted up with both SD and eMMC found
>>> (they don't fail same way every time, sometimes SD is missing, often
>>> eMMC is missing).
>>> 
>>> What would somebody else think about such issues? I don't have
>>> experience in HW dev, I can only guess what goes wrong. And again, if it
>>> boots, it works. And no component on BBB gets too warm to hold finger
>>> there for long time, too (if that matters). I have 5V 2.5A PSU powering
>>> it (but the PMIC should fail if voltage drops too much, etc, I read the
>>> datasheet for that), I have few LEDs with resistors connected to GPIO
>>> pins, two ~30cm wires that sit on table for input testing (resistors
>>> there too, of course) and Nokia DKU-5 data cable for USB-TTL serial
>>> console. If the board gets any ground, it's via this cable. But I don't
>>> see how my HW config is related to this issue. And I don't change this
>>> when I try different U-Boot's?! I don't have USB devices connected to
>>> host port and nothing to other USB port too. I use old 64MB SD card to
>>> help with booting (because of ubldr issues), not sure that matters, though.
>>> 
>>> Thanks.
>>> 
>> 
>> 
>> Now I have patch too. I feel much better now. It seems to fix
>> everything. I'm sure that not all of those "delay"'s are needed. I got
>> tired of failures and just put one into each place that seemed to need
>> some waiting before continue. The side effect is that mmc detection
>> doesn't take several seconds now, it's near instant. It also feels like
>> device read speed is faster but I'm not entirely sure about that. So,
>> what happened here? Slower CPU acted as some kind of limiter by itself?
>> What's correct solution here? I'm only guessing but it at least works
>> now. I don't think I've lost devices after this change, both SD card and
>> eMMC device are always there. I should disable reboot on rootfs mount
>> fail to fully confirm it. However that BUSTEST_W still gives error. Now,
>> only ubldr-no-eMMC fix is needed. And / or U-Boot fix?
>> 
> 
> 
> Early "Send"...
> 
> patch:
> 
> http://ketas.si.pri.ee/mmc-detection-hacks2.diff

Wow! That’s a lot of added 10ms delays…  Do we have a theory of the crime
for why they are needed? Usually they suggest to me that we’re doing something
wrong (either not checking the right bits in the bridge, having a fixed retry count
rather than a timed limit and having some bridges fail more slowly than others
so the delays are effecting the same thing).

Warner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20140519/6385a1b1/attachment.sig>