Date: Mon, 19 May 2014 20:28:51 -0600 From: Warner Losh <imp@bsdimp.com> To: "Sulev-Madis Silber (ketas)" <madis555@hot.ee> Cc: freebsd-arm <freebsd-arm@FreeBSD.org> Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) Message-ID: <024F43EF-E299-413E-AE42-2507AEDD0886@bsdimp.com> In-Reply-To: <537AB675.1020006@hot.ee> References: <537A050E.3040804@hot.ee> <537AB550.2090401@hot.ee> <537AB675.1020006@hot.ee>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_38E5F53C-2EE7-4188-B2F9-E43B279E0A36 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 19, 2014, at 7:57 PM, Sulev-Madis Silber (ketas) = <madis555@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. >>>=20 >>> Although maybe I could write this as reply to some other message, I = feel >>> like it might deserve separate one. >>>=20 >>> 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). >>>=20 >>> 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. >>>=20 >>> Thanks. >>>=20 >>=20 >>=20 >> 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? >>=20 >=20 >=20 > Early "Send"... >=20 > patch: >=20 > http://ketas.si.pri.ee/mmc-detection-hacks2.diff Wow! That=92s a lot of added 10ms delays=85 Do we have a theory of the = crime for why they are needed? Usually they suggest to me that we=92re 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 --Apple-Mail=_38E5F53C-2EE7-4188-B2F9-E43B279E0A36 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTer3jAAoJEGwc0Sh9sBEAVFsP/A5retE8sUNyre8C1tNH27Sc 6reKp6LZAi5Vyzfd+s3dJy8Y8icziANWFeFc2Jb0Nh3967LaFo5MJ9Y8BrCYsLwY Zd2/tBaiv53L/dX9JTV/kn+QU0QUqXFSB6ZH+rloBYLN3A/pnKArhNH1edoS/x8u 1Sm3TF5LUZ0oJjp2Tz58em/bc4eQrp+traue0sTCHjx/qgCaeub6DMnRyRTebHUc 618R+xh1Wm0I8ZrhrQqVty72GT0aZN+KQAtvzl2OmU2qIjeOf4VoVTf5R2HYUwJm X66Sa+gWxFRfxemNrCeezAf8z9yObKfWO2Z0jPrMHq1pETw4hvtZjL4qTrBNrxND Rw0RHTARu07d7qUkDKO/HG7avec6M/PJQyuzZoZ44kIqZ4uIZdmlJ+EpLmmUy/kG op4IcWRa87e/SnpmkXt8Ls101Y1U3hjVJhjO8ql1a04XBzFqqgtzv4ob2oo9Exwj vxjUICjTF28RCEfeq/8ZEQWZGyvNt1+fd5INjWXxlaO2HO1xexg4KUHVmV3qFeiE REO/8+uRuB3Y6MX/eJ5tuAqg36ebBwpUseluz+vxYdenvz/p6vBO8Ph/LYqtvTrJ MoJDfuK0npiIizaqsi6i75+4TvRZYXEtXDojyy47I9Bneor5CVWR629ls1RM9mX1 36bDGY+Nni9wPJxCGu2N =EMQ1 -----END PGP SIGNATURE----- --Apple-Mail=_38E5F53C-2EE7-4188-B2F9-E43B279E0A36--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?024F43EF-E299-413E-AE42-2507AEDD0886>