From owner-freebsd-arm@FreeBSD.ORG Tue May 20 02:29:02 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7086F38D for ; Tue, 20 May 2014 02:29:02 +0000 (UTC) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E9D32026 for ; Tue, 20 May 2014 02:29:01 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bj1so6586587pad.41 for ; Mon, 19 May 2014 19:28:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=/cSFxILNOg9cK6B417ttS0GVx2GOol4jWnvJWhxc3sU=; b=BiYJEYxSuDpM/9jAwkhJD/+eblABPP5hLAGcK2O6TB2kyfhddR88scnNuQ2UN6JnKf 8ieOAj7wWZpqpT0hYcXSEIsEpjiv+jE+PVUgOaSYPSo0Fq/4nxxp2DSSSso7hyFF3iJM 88ZKSGoFh3EKD3ib8Er8InG4bBp3fbM85QL3rELP3qOC+2XNaWBIMfvbYFPSyQVIy0sj VZvgvEzZmfzWf6VdDJ+mOjtin4V7d2HEI5K3+CZImmaHvFIUhCBccS/3mExmDyi+Wtrk qw72QJD+sEAwlm/PPv5zcDC15NmHyPoPOhb46iiCSCHxioP/+OBJ6EQYdVQPG6WDhUPy DsHg== X-Gm-Message-State: ALoCoQkfYHOlp+fGGT00Bt0dLI4Erp7Gi9m319V0E7625h7KuRX53Wbg2cAGigtc3BMxtafhDUlc X-Received: by 10.66.65.225 with SMTP id a1mr35839436pat.139.1400552934870; Mon, 19 May 2014 19:28:54 -0700 (PDT) Received: from [10.64.26.239] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id pr4sm149307pbb.53.2014.05.19.19.28.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 May 2014 19:28:53 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_38E5F53C-2EE7-4188-B2F9-E43B279E0A36"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: Warner Losh In-Reply-To: <537AB675.1020006@hot.ee> Date: Mon, 19 May 2014 20:28:51 -0600 Message-Id: <024F43EF-E299-413E-AE42-2507AEDD0886@bsdimp.com> References: <537A050E.3040804@hot.ee> <537AB550.2090401@hot.ee> <537AB675.1020006@hot.ee> To: "Sulev-Madis Silber (ketas)" X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 02:29:02 -0000 --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) = 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--