Quite a bit for you to read!

[Grench]

@Grench as someone number 4 in the normal pre-order and someone that wants the speed of the eMMC I'd rather have the uSD disabled. But there is always someone that wants something different. I'd rather see the issue fixed from the start.

If you really want to play line position...
As someone number 8 in the prototype preorder and someone who wants a fully functioning unit but has a realistic approach to life, I'd also like to see some functioning units ship very soon.

The eMMC has a set of traces. Half of those traces are going through the MUX and getting slowed to being out of sync with the half that are not going through the MUX. Simply removing the MUX leaves a gap in the traces that the MUX would otherwise connect. Making those borderline microscopic pinpoints on the SoC board connect to each other without the MUX part itself would be very difficult and possibly manual using micro soldering and very teeny tiny wires. Theoretically possible for 1-2 boards, nobody wants the job of doing that to 570.

So, IMHO, the eMMC is unlikely to be running 'full speed' on the current SoC board revision. If you want the eMMC to be -fast-, then you might have to wait another 3 months for the next board revision. That revision may or may not have a working microSD and may or may not MUX the microSD with one of the SDXC slots.

However, the current boards might work just fine for no-eMMC systems with full functioning microSDXC as they are WITH the MUX still existing on the board and connecting those micro pin point can't really make them out solder points.

Selling point to the microSDXC only boards: You can pull your microSDXC data card, SIM (if equipped), and SDXC cards out and know that you have physically wiped the machine. It could actually be a selling point to the security conscious crowd. Physically no non-removable storage.

I'm not saying that the eMMC should not be fixed. It SHOULD be fixed and it SHOULD be fixed right. Fixing it right will most likely require an SoC board revision and push the project 3 months. If these 570 boards are seen as serviceable or possibly even preferential to a subset of the Pyra's admittedly niche audience, shouldn't they fulfill that? Even if it means skipping over people for whom it is not an acceptable outcome?

 

[sm0kew0n]

I'm under the impression that this issue may not even be resolved......? Shouldn't we find out if there are at least 570 pre-orderers that are willing to take it as is?

 

[Grench]

I'm under the impression that this issue may not even be resolved......? Shouldn't we find out if there are at least 570 pre-orderers that are willing to take it as is?

As detailed above, using half of these SoC boards as unpopulated keychain rewards for people willing to do so, including a 5% board population fail rate (not uncommon in initial board production)...
.05*Xfail + Xpopulated + Xkeychain = 570
2.05X = 570
X = 278

So, roughly 275 people taking this theoretical option would wipe out the supply of this SoC board revision.

 

[sm0kew0n]

theoretical option

I asked if we should find out. It feels like lots of theoretical options here, no solid ones.

 

[Grench]

I asked if we should find out. It feels like lots of theoretical options here, no solid ones.

Very true. I don't even know if the MUXer can be set to default to the microSD.

For the Pyra to boot from anything, the system has to find the bootloader first - then that can point to other media.
To my understanding, the bootloader must exist either on the controller for the eMMC or the controller for the left SDXC slot.
The controller for the eMMC is MUXed to the microSDXC. I'm betting that it defaults to the eMMC to grab the bootloader.
I.e. the 0/1 switch on the MUX is likely set to default to the eMMC.
For a unit without the eMMC to be able to seamlessly boot from the microSDXC, it may need to have that one bit flipped by default somehow. I don't know if that is possible or if any of my assumptions are correct though.

 

[Yogurt]

I'd like the fastest storage available. I won't lose sleep over some slower flash, but I would prefer full speed.

 

[Swordfish II]

As detailed above, using half of these SoC boards as unpopulated keychain rewards for people willing to do so, including a 5% board population fail rate (not uncommon in initial board production)...
.05*Xfail + Xpopulated + Xkeychain = 570
2.05X = 570
X = 278

So, roughly 275 people taking this theoretical option would wipe out the supply of this SoC board revision.

Or maybe there are 570 people like me that want both emmc and microsd, but are OK with slightly slower speed.

 

[Calculus]

I was not assuming replacing the eMMC would fix the problem, which is minor to me. I was a bit unclear about that. I simply don't want a brick when the eMMC fails, and don't plan on relying on it at all, since it can't be replaced. Is it possible to use the eMMC as read-only just for the boot-loader and then boot off the faster full size SD? So long as it doesn't get bricked by booting up to the faster SD too many times, I'm definitely okay with that regardless of what happens to the microSD.

 

[GizmoTheGreen]

wasn't the idea with the internal µSD clost that if the eMMC fails you could switch to that and still have a functioning boot drive that's "permanent", not something that might be removed during use by accident of some sort? (you drop the device the sdcard flies out...)
if the muxer is a problem we can just return to the original plan which was a switch of sorts? like an actual switch you need to toggle with your finger.

 

[Calculus]

How easy would it be to pop the SD card out accidentally? I didn't consider that when writing my last post.

 

[TrashyMG]

How easy would it be to pop the SD card out accidentally? I didn't consider that when writing my last post.

Well Micro SD is in the battery compartment, and has a hinged lid so pretty hard.

 

[gpsqueeek]

Well Micro SD is in the battery compartment, and has a hinged lid so pretty hard.

@Calculus asked for SD, not micro-SD ;-)

 

[TrashyMG]

@Calculus asked for SD, not micro-SD ;-)

But his prior post mentioned the Micro-SD...

But it's pretty hard to pop those out too, outside of dropping it by accident.

 

[gpsqueeek]

But his prior post mentioned the Micro-SD...

But it's pretty hard to pop those out too, outside of dropping it by accident.

I guess it depends on the mechanical part, I did it with my laptop once or twice (luckily it only ejected a dummy SD), you know, just handling the PC in one hand and moving around to show whatever happened on the screen and... Press... Click! Not good if the OS or even /home is there I suppose...
But then maybe it's just me.
I an not concerned with the micro-sd though, you detailed that pretty well

 

[PowerGod]

All the drops of my Pandoras never popped out the SD cards

 

[Calculus]

I was asking about the full size SD card popping out because, while I'd prefer the OS to be on an internal, physically very well secured replaceable medium like the microSD, so long as I can boot off the (full size) faster SD without eventually bricking the device due to the eMMC, It's acceptable, unless the SD can easily pop out.

 

[Swordfish II]

I was not assuming replacing the eMMC would fix the problem, which is minor to me. I was a bit unclear about that. I simply don't want a brick when the eMMC fails, and don't plan on relying on it at all, since it can't be replaced. Is it possible to use the eMMC as read-only just for the boot-loader and then boot off the faster full size SD? So long as it doesn't get bricked by booting up to the faster SD too many times, I'm definitely okay with that regardless of what happens to the microSD.

Could it fail? Sure... But I don't think it will. For perspective I use the NAND on a Pandora. No issues. I also use the SSD on an original eeepc. No issues.

People will bring that up, but IMO the concern is misplaced.
[doublepost=1490388596,1490388471][/doublepost]

wasn't the idea with the internal µSD clost that if the eMMC fails you could switch to that and still have a functioning boot drive that's "permanent", not something that might be removed during use by accident of some sort? (you drop the device the sdcard flies out...)
if the muxer is a problem we can just return to the original plan which was a switch of sorts? like an actual switch you need to toggle with your finger.

Sigh this has been said numerous times, but a "switch" is a MUX and we are right back where we are now.

 

[Letalis Sonus]

Sigh this has been said numerous times, but a "switch" is a MUX and we are right back where we are now.

A mux is not just a switch.

However, mechanical switches are not designed to handle high frequency signals, they'll just distort the signals beyond recognition. Only switching the power supply is not an option, either - you can't just leave the signal lines attached to unpowered ICs and expect the signals to be unaffected by this.

 

[Neelix]

On a "next board revision" basis, could the mux chip be changed for one that can handle all the data lines on the eMMC? And would routing the extra data lines through the mux help the situation?

-Neelix

 

[slaeshjag]

On a "next board revision" basis, could the mux chip be changed for one that can handle all the data lines on the eMMC? And would routing the extra data lines through the mux help the situation?

-Neelix

Routing all data lines through the same type mux as used now would potentially improve (maybe double the max peak bandwidth), but it would still be half of what the OMAP could talk to the eMMC. For µSD, there would be no change.