Quite a bit for you to read!

[mclien]

Just a quick thought to the CPU boards. There is one Option missing: Since the CPU Boards were designed anyway to be usable in other projects, you might even sell them as functional boards for other projects, like a PalmPyra, PsionPyra, etc where tat issue might even not come up because those projects might use non of those options anyway.
keychains would be a waist (and I hate waist).
Oh and I personally would be OK with a bit less speed anyway...

 

[ghostpatch]

I'm placed in the fist 100 pre-orders. The mmc cap is no big deal to me. I'm fine with either solution, using the old cpu pcb or buying one or two additional unpopulated pcb's!

 

[zmatt]

(Note: in this post I'm using power-of-ten definitions of MB/s. I don't intend to make this a habit.)

I was honestly already a bit annoyed about the fact that the OMAP5432 can't support the most recent eMMC modules (just 4.5 or 4.51, if I remember correctly).

Note that the eMMC standard version is mostly about features of the eMMC module that software can take advantage of, the only part relevant to the OMAP5 itself is the signalling. You can still make full use of the 5.1 feature set (which is what the eMMC supports), just not of the "HS400" transfer speed.

Here are some concrete numbers in MB/s (in this case meaning 1000000 bytes/s since it's more convenient), to the best of my understanding, based on datasheets etc (no actual tests):
270 MB/s - sequential read speed claimed by eMMC manufacturer
192 MB/s - max transfer speed for eMMC (ignoring mux)
140 MB/s - sequential write speed claimed by eMMC manufacturer
96 MB/s - max transfer speed for primary SD slot
96 MB/s - max transfer speed for μSD slot (ignoring mux)
48 MB/s - max transfer speed for μSD slot (due to mux)
30 MB/s - UHS speed class "U3"
24 MB/s - max transfer speed for secondary SD slot
10 MB/s - UHS speed class "U1" / SD speed class 10

I'm not yet certain about the max eMMC speed with mux.

 

[codifies]

yeah this emmc thing could get out of proportion, Linux is very efficient, once loaded, usually the only disk access other than swap (which you can live without!) will be loading applications and then applications loading/saving data, as saving is probably best not done on emmc this leaves application load time, which if it takes 0.2 of a second or 0.4 of a second, well it ain't going to have any practical effect on your experience ...

Basically its the same straw man argument that was used to force systemd on people, boot speed is largely irrelevant

You could even argue that emmc should be read only with a writeable overlay elsewhere....

I have booted from sloooooow SD media on a number of different arm boards, and the boot media (once actually booted) really isn't an issue...

honest its all too easy to get this kind of thing out of proportion...

 

[kabaiakh]

I'm OK with a maybe-slower eMMC immediately since it will be possible to upgrade it later for a 15-something euros.
Another proof – if needed – the mezzanine CPU board was wonderful idea.
I also like the key-chain idea; it looks soooooo geeky.
Especially for someone who had a broken 486DX4 pinned onto the wall of his room for several year. ;-)

(Note: in this post I'm using power-of-ten definitions of MB/s. I don't intend to make this a habit.)

Since not everyone knows about binary prefixes, it's always good to clarify.
My apologies for my showing proselytism here.

 

[Haraldur]

For those, like me, not familiar with IRC, and not particularly keen to say anything or keep a window open for long periods, is there an easy way to get logs so we can see the development conversations?

 

[ssokolow]

since it will be possible to upgrade it later for a 15-something euros.

$15 sounds far too low to include all the components on a populated CPU board.

 

[WizardStan]

I seriously do not think the eMMC thing is going to be a problem at all.

It kind of is. We were promised eMMC speeds, that was literally a key debate point early on in development: pros and cons of internal SD vs eMMC were presented and we were eventually told we could have both. Now we find out we can't have both, that the microSD camp has won by default: we have expandability at the expense of speed.
It doesn't matter whether it will be "fast enough" or not, this is a crippling design flaw and it needs to be spun properly. This isn't like on the Pandora with people complaining about "slow" SD writes because they don't understand the technology: this time around, people complaining about slow eMMC will be correct; it is transferring slower than it should, history shows that it was intended to be faster but due to this unforeseen flaw it can't.

What I don't get is why the MUXer would cause this. My experience with such chips is that it's basically just a switch: two sets of X pins in, one set of X pins out, set the mux pin high and it selects one, set it low and it selects the other, and the signals pass from one input to the output unmodified. What is this one doing that's different and causes it to go at half speed? It almost sounds like it's a factor of the OMAP itself locking the speed, and if that's the case maybe it can be selectable at boot time and just have one or the other as originally desired instead of being able to flip flop between them at run time.

it will be possible to upgrade it later for a 15-something euros

It's only 15eur now because the board hasn't been fully populated. Once it's got all the parts on it it'll cost significantly more. There's no cheap path to upgrading.

 

[zmatt]

We were promised eMMC speeds

That term really means nothing, I have devices whose eMMC whose advertised speeds are 30 MB/s read and 6.6 MB/s write.
[doublepost=1490268990,1490268139][/doublepost]

It doesn't matter whether it will be "fast enough" or not, this is a crippling design flaw and it needs to be spun properly.

You are correct that it is a design flaw. This should have been checked, but apparently it slipped between the cracks. Unfortunately it's very easy to overlook something like this, even if all the pieces are supposed to be somewhere in your head. I've personally seen "completely obvious" mistakes being overlooked by half a dozen people (myself included) carefully reviewing a schematic.

What matters now is how to deal with it: accept it as-is, or revise the cpu board and flush 570 pcbs down the drain (minus some keychains). Note that I don't even know if a suitable mux that doesn't have the same problem exists at all, so it's possible that fixing the speed for eMMC means sacrificing μSD.

What I don't get is why the MUXer would cause this.

Because it has a maximum speed (60 MHz). Its propagation delay is also potentially an issue since only 6 signals (clk, cmd, dat0-dat3) are muxed while 4 go only to eMMC (dat4-dat7).

signals pass from one input to the output unmodified

If you zoom in enough, signals never pass through unmodified.

 

[TrashyMG]

Note that I don't even know if a suitable mux that doesn't have the same problem exists at all, so it's possible that fixing the speed for eMMC means sacrificing μSD.

Well the original plan was just having a switch to select between one or the other. The the cool surprise Nikolaus came up with is the muxer that was suppose to give everyone what they wanted.

 

[Kippykip]

As long as it's faster than an SD card I don't care

 

[vcoleiro1]

@zmatt or @ED

There are 1032 pre-orders, so if the issue is with 570 boards that have been made, does that mean the next batch of boards will be fixed and not have the issue?

My suggestion is to provide those 570 boards to the pre-orderers who don't care about the issue. The carrot being they get them first. Of course the rest of the story is to fix the issue and provide the other pre-orders and future orders with the fixed board.

 

[Eight Bit]

I just hope the speed of the eMMC won't suffer too much because of the muxer. These are the important numbers?

192 MB/s - max transfer speed for eMMC (ignoring mux)
I'm not yet certain about the max eMMC speed with mux.

96 MB/s - max transfer speed for μSD slot (ignoring mux)
48 MB/s - max transfer speed for μSD slot (due to mux)

Does the mux bottleneck the speed by 50% of the original speed or by a maximum bandwidth the muxer allows? Because that would mean the eMMC would go down to 48 MB/s too... right?

Sorry if my question seems silly, just trying to understand the problem...
If it's switch vs muxer, speed vs ease of use, I think I'd rather wait for a board without the muxer.. it all depends..

Need moar data

 

[ible]

that's essentially what ED is saying

 

[PowerGod]

I'm a little lost in this flow of informations...

So, is still not possible to use the eMMC while booting from micro-SD ?

I thought the choice of that particular switch was to make it possible, but instead it's purpose is just to choose one of them ?

 

[NetBLOKS]

If an upgrade will be cheap enough for the people who take the slower variant, I don´t care. Like a coupon, that enables everyone with the flawed CPU-Board to upgrade for the manufacturing price of an flawless board, if they so desire.

 

[Letalis Sonus]

Does the mux bottleneck the speed by 50% of the original speed or by a maximum bandwidth the muxer allows? Because that would mean the eMMC would go down to 48 MB/s too... right?

Frequency is the limiting factor of the muxer.

The eMMC's data interface is twice as wide, so it still ought to be about twice as fast as the µSD card - if the propagation delay of the chip doesn't cause any issues that would require using an even lower frequency, 4 out of 8 data signals arriving later than the others is not a trivial thing.

 

[TrashyMG]

I'm a little lost in this flow of informations...

So, is still not possible to use the eMMC while booting from micro-SD ?

I thought the choice of that particular switch was to make it possible, but instead it's purpose is just to choose one of them ?

The original plan was only to switch from one or the other, Nikolaus came up with the idea of using a muxer to allow access to both at the same time, however it looks like how it's currently implemented it is degrading the uSD speed a bit more than expected.

 

[Letalis Sonus]

The original plan was only to switch from one or the other, Nikolaus came up with the idea of using a muxer to allow access to both at the same time

I'm pretty you'd need a mux IC either way, being able to access both is just a matter of software.

 

[TrashyMG]

I'm pretty you'd need a mux IC either way, being able to access both is just a matter of software.

Not necessarily, originally it was going to be just a small switch in the battery compartment, Which could have been just been toggling the power to one or the other. Also there is a bit of difference between a mux designed specifically for multiplexing the eMMC bus and a more generic one for slower speed switching of a few data lines.

That said a mux is a much better choice, as it can reside on the CPU module board and won't hinder upgradability of the main CPU board.