* does beaglebone black device tree need to specify amount of eMMC flash?
@ 2014-07-05 10:47 Robert P. J. Day
2014-07-07 6:53 ` Sascha Hauer
0 siblings, 1 reply; 6+ messages in thread
From: Robert P. J. Day @ 2014-07-05 10:47 UTC (permalink / raw)
To: U-Boot Version 2 (barebox)
(aside: i'm digging into device trees in barebox and will certainly
have a number of questions shortly so i can write some tutorials for
an upcoming class, but i'll start simple.)
i'm particularly interested in configuring and building barebox for
my beaglebone black (henceforth "BBB"), and i can see all of the .dts*
support files under arch/arm/dts/, but a simple question -- the *new*
BBB has upgraded from 2G of eMMC to 4G eMMC, but i don't see that
mentioned anywhere in those .dts files. does that property need to be
mentioned, or is that simply autodetected by the kernel at boot time?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: does beaglebone black device tree need to specify amount of eMMC flash?
2014-07-05 10:47 does beaglebone black device tree need to specify amount of eMMC flash? Robert P. J. Day
@ 2014-07-07 6:53 ` Sascha Hauer
2014-07-07 7:06 ` Alexander Aring
0 siblings, 1 reply; 6+ messages in thread
From: Sascha Hauer @ 2014-07-07 6:53 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: U-Boot Version 2 (barebox)
On Sat, Jul 05, 2014 at 06:47:36AM -0400, Robert P. J. Day wrote:
>
> (aside: i'm digging into device trees in barebox and will certainly
> have a number of questions shortly so i can write some tutorials for
> an upcoming class, but i'll start simple.)
>
> i'm particularly interested in configuring and building barebox for
> my beaglebone black (henceforth "BBB"), and i can see all of the .dts*
> support files under arch/arm/dts/, but a simple question -- the *new*
> BBB has upgraded from 2G of eMMC to 4G eMMC, but i don't see that
> mentioned anywhere in those .dts files. does that property need to be
> mentioned, or is that simply autodetected by the kernel at boot time?
eMMC size is autodetected by barebox and the kernel. In the end it's
just a MMC/SD card.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: does beaglebone black device tree need to specify amount of eMMC flash?
2014-07-07 6:53 ` Sascha Hauer
@ 2014-07-07 7:06 ` Alexander Aring
2014-07-07 8:53 ` Lucas Stach
2014-07-07 21:05 ` Holger Schurig
0 siblings, 2 replies; 6+ messages in thread
From: Alexander Aring @ 2014-07-07 7:06 UTC (permalink / raw)
To: Sascha Hauer; +Cc: U-Boot Version 2 (barebox)
On Mon, Jul 07, 2014 at 08:53:45AM +0200, Sascha Hauer wrote:
> On Sat, Jul 05, 2014 at 06:47:36AM -0400, Robert P. J. Day wrote:
> >
> > (aside: i'm digging into device trees in barebox and will certainly
> > have a number of questions shortly so i can write some tutorials for
> > an upcoming class, but i'll start simple.)
> >
> > i'm particularly interested in configuring and building barebox for
> > my beaglebone black (henceforth "BBB"), and i can see all of the .dts*
> > support files under arch/arm/dts/, but a simple question -- the *new*
> > BBB has upgraded from 2G of eMMC to 4G eMMC, but i don't see that
> > mentioned anywhere in those .dts files. does that property need to be
> > mentioned, or is that simply autodetected by the kernel at boot time?
>
> eMMC size is autodetected by barebox and the kernel. In the end it's
> just a MMC/SD card.
>
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.
- MMC/SD:
Disadvantage:
- mcu in the middle, abstract block device. OS doesn't know about this.
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)
For the marketing you can say if your eMMC is broken, then buy a new
complete board. This kind of marketing is very bad. :-(
- Alex
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: does beaglebone black device tree need to specify amount of eMMC flash?
2014-07-07 7:06 ` Alexander Aring
@ 2014-07-07 8:53 ` Lucas Stach
2014-07-07 9:37 ` Alexander Aring
2014-07-07 21:05 ` Holger Schurig
1 sibling, 1 reply; 6+ messages in thread
From: Lucas Stach @ 2014-07-07 8:53 UTC (permalink / raw)
To: Alexander Aring; +Cc: U-Boot Version 2 (barebox)
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: does beaglebone black device tree need to specify amount of eMMC flash?
2014-07-07 8:53 ` Lucas Stach
@ 2014-07-07 9:37 ` Alexander Aring
0 siblings, 0 replies; 6+ messages in thread
From: Alexander Aring @ 2014-07-07 9:37 UTC (permalink / raw)
To: Lucas Stach; +Cc: U-Boot Version 2 (barebox)
Hi Lucas,
On Mon, Jul 07, 2014 at 10:53:20AM +0200, Lucas Stach wrote:
> This has nothing to do with barebox, but I feel this needs an answer as
> a lot of misinformation is spread here.
>
Thanks for your answer.
Yes, it's off-topic but I always feel bad when I heard "eMMC".
> 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.
>
yes, but I think that a mtd filesystem can do a better scheduling of
erase/write/read cycles than the integrated mcu with an abstracted block
device.
I need to test it myself, to see what the mcu exactly do and this
depends on manufacturer.
> >
> >
> > - 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.
>
okay, I didn't know that. Does barebox use the 8 bit interface at the
moment?
> 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.
>
So now I have the question about "Why they don't make a new sd/mmc card
holder standard and sells replaceable cards". I could say that to every
electronic device, but maybe it's better that there is no new standard.
:-)
- Alex
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: does beaglebone black device tree need to specify amount of eMMC flash?
2014-07-07 7:06 ` Alexander Aring
2014-07-07 8:53 ` Lucas Stach
@ 2014-07-07 21:05 ` Holger Schurig
1 sibling, 0 replies; 6+ messages in thread
From: Holger Schurig @ 2014-07-07 21:05 UTC (permalink / raw)
To: Alexander Aring; +Cc: U-Boot Version 2 (barebox)
> Advantage
> - maybe avoid some bad connections (never expired by using sd cards)
This is the k.o. criteria in the company I work for SDCARDs. The
devices run in high vibration / shock targets (e.g. mining), and you
really wouldn't want to have an SDCARD there. You, you could probably
glue the SDCARD with a tape, but this is only a kludge. And eventually
the glue will corrode, or stop being glue ...
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-07-07 21:05 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-05 10:47 does beaglebone black device tree need to specify amount of eMMC flash? 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
2014-07-07 9:37 ` Alexander Aring
2014-07-07 21:05 ` Holger Schurig
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox