From: Lucas Stach <l.stach@pengutronix.de>
To: Alexander Aring <alex.aring@gmail.com>
Cc: "U-Boot Version 2 (barebox)" <barebox@lists.infradead.org>
Subject: Re: does beaglebone black device tree need to specify amount of eMMC flash?
Date: Mon, 07 Jul 2014 10:53:20 +0200 [thread overview]
Message-ID: <1404723200.4587.14.camel@weser.hi.pengutronix.de> (raw)
In-Reply-To: <20140707070610.GA11833@omega>
This has nothing to do with barebox, but I feel this needs an answer as
a lot of misinformation is spread here.
Am Montag, den 07.07.2014, 09:06 +0200 schrieb Alexander Aring:
[...]
>
> btw.: that's why eMMC is evil.
>
> Raw-Flash:
>
> Disadvantage:
> - you can't replace it.
>
> Advantage:
> - no mcu in the middle, access the raw Flash.
This isn't an advantage. If your not working for the NAND flash
manufacturer you will have an extremely hard time getting the wear
leveling parameters right. Having this abstracted behind an MCU that
actually know about the flash chip behind it is a good thing.
>
>
> - MMC/SD:
>
> Disadvantage:
> - mcu in the middle, abstract block device. OS doesn't know about this.
No disadvantage, see above.
>
> Advantage:
> - you can replace it.
>
>
> Combines these Disadvantage and Advantage you will get:
>
> Disadvantage:
> - mcu in the middle, abstract block device. OS doesn't know about this.
> - you can't replace it.
>
> Advantage:
> - maybe a little bit cheaper...
> - maybe avoid some bad connections (never expired by using sd cards)
>
You are neglecting the fact that the eMMC interface can be driven with a
lot higher clock speeds compared to an SD card. Also most eMMCs have an
interface width of 8 bits, which is double the SDs 4 bit.
This amounts to a lot more raw speed on the interface side and most
eMMCs are actually capable of supplying data at those rates.
Also eMMC provides some really useful additional features like the boot
partitions and health checks.
While SD cards may be convenient for the casual hobbyist user when it
comes to real embedded devices, where speed and reliability matters,
eMMC has a huge lead.
Raw NAND is only an option if your device manufacturing runs are big
enough that the lower price for NAND stacks up enough to make up the
additional development time (cost) you need to get things right. Note
there is a big difference here between getting it working and getting it
right.
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2014-07-07 8:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-05 10:47 Robert P. J. Day
2014-07-07 6:53 ` Sascha Hauer
2014-07-07 7:06 ` Alexander Aring
2014-07-07 8:53 ` Lucas Stach [this message]
2014-07-07 9:37 ` Alexander Aring
2014-07-07 21:05 ` Holger Schurig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1404723200.4587.14.camel@weser.hi.pengutronix.de \
--to=l.stach@pengutronix.de \
--cc=alex.aring@gmail.com \
--cc=barebox@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox