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

[Sulev-Madis Silber (ketas)]

On 2014-05-20 05:39, Winston Smith wrote:
> On Mon, May 19, 2014 at 10:28 PM, Warner Losh <imp at bsdimp.com> wrote:
>> 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).
> 
> It's a good start (since the BBB is really flakey at 1Ghz), but yes,
> more delays aren't good!
> 
> For what it's worth, I'm working in parallel with both FreeBSD and
> Debian Wheezy images on the BBB, and it is quite apparent that the BBB
> running FreeBSD is *much* slower to boot than the BBB running Debian;
> which currently boots to the login prompt in about 15 seconds from
> power up.  FreeBSD has a 15-20 second delay just to detect the eMMC,
> let alone everything else.
> 
> Comparatively, my x64 FreeBSD VM boots much more quickly than my Ubuntu x64 VM.
> 
> -W.
> 


"really flakey" sounds like "unstable, panics 1000 times a day". I don't
see any of that here (as of 11.0-CURRENT r266442).

Boot, hmm... yea, 1min (just measured) to fully boot up and connect to
server (I'm using ethernet, DHCP, loader boot delay = 3, huge Perl
program) might be too slow if you have some embedded system which
constantly loses power or something... I haven't tried to do any boot
time optimizations yet. Compress kernel? Compress userland? Execute
something in parallel on init (NOTE: *DON'T* even think about porting
Linux init replacements here)? Use rescue-like static binary? Heavily
customize / patch kernel? Use own init? Use rootfs inside kernel?
Actually I guess many people might think like me... "HELL, optimizing
boot time of 1min?! I have more important tasks to do than this".