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>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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. >>> >>> 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 [-- Attachment #2 --] -----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-----home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?024F43EF-E299-413E-AE42-2507AEDD0886>