Quite a bit for you to read!

[ashcloud]

Everything has trade offs.

You either get full emmc speed, and don't get to boot from a microsd, or you get to boot from a microsd but have a slower emmc.

That's just it, I don't see a trade-off here. Either it's multiplexed with the interal EMMC, than it has a reason to exist, or it's multiplexed with the external SD card slot, in which case it has no purpose and could be left out as well. Well, except someone codes that mentioned hypothetically possible switching driver.

 

[elvissteinjr]

About linux not accessing the disk as much... I don't think you can generalize every application running under an OS like that. I remember having a system crawl around when copying from one partition to another on the same HDD with the system partition being on there too of course. That was like a worst case scenario and a spinning disk on top of that, but boy, the disk was accessed in order to actually do things on the machine.
Heck, if the eMMC ends up faster than the SD slots I'd consider moving games that take a bit longer to load on there while I actively play them. Just like I handle my small SSD space on the desktop.

I'm kinda torn on this one. I'm one of the first pre-orders. I'd like it asap, but I'd also not want a crippled version as a thanks for ordering early. I'm usually very tolerant to issues and quirks, but the microSD card slot is a feature I don't plan to use at all, so it's like "eh." for me.

 

[EvilDragon]

That's just it, I don't see a trade-off here. Either it's multiplexed with the interal EMMC, than it has a reason to exist, or it's multiplexed with the external SD card slot, in which case it has no purpose and could be left out as well. Well, except someone codes that mentioned hypothetically possible switching driver.

Just because you don't see a purpose doesn't mean there IS no purpose.
Having an OS in an internal slot has an advantage. You cannot accidentally remove it and the chances that someone snatches the SD Card out of your slot are also lower.
And you still have the normal (left) SD Card slot for normal usage.

Not everyone needs both slots.

 

[Haraldur]

To me, having 2 external SD card slots operational is more important than a faster eMMC, assuming it is not significantly slower than the SD cards. Would it not be rather sad to see an external slot that you cannot use?

 

[Eight Bit]

To me, having 2 external SD card slots operational is more important than a faster eMMC, assuming it is not significantly slower than the SD cards. Would it not be rather sad to see an external slot that you cannot use?

It's about he 3rd (mico)SD slot under the battery lid

 

[TrashyMG]

And so, just like the Keyboard threads of the past, the second Pyra Holy War began.

 

[Eight Bit]

Finally some more activity here again, it's actually worth it to F5 today

 

[zmatt]

Indeed, I meant that the eMMC speed is crippled, NOT the MicroSD card speed. The MicroSD card speed should work as fast as the OMAP can handle.

Sorry ED, but that's not true Both are limited due to the mux, the eMMC just moreso because it started out faster.

Most likely, there's no MUXer available that would be fast enough.

Well, there are muxes all the way into RF. The problem is mainly the bidirectional level shifting that's also being performed for μSD. The annoying bit is that it needs that only during initial communications, after which it drops down to 1.8V for high-speed communication. If the μSD could communicate at 1.8V right from the beginning then a pure mux (no level-shifting) would suffice.

Another would be a fast mux followed by level-shifting only for μSD. Then at least the eMMC would be full speed.

The next problem would probably be pcb area, or lack thereof...

 

[Bokkertoff]

So why cant we have a Pyra "model A" and "model B" ?

"Model A" has uSD + eMMC but capped at 480Mb/s. The cpu boards for model A are ready now (fingers crossed)

"Model B" has full speed eMMC and potentially no uSD. The cpu boards for model B will be ready in x months from now.

 

[Linux-SWAT]

A full speed miniSD would be the better choice IMHO.

 

[TrashyMG]

A full speed miniSD would be the better choice IMHO.

How so? it would still be half the speed of a fully working eMMC at best...

 

[Grench]

And so, just like the Keyboard threads of the past, the second Pyra Holy War began.

So, if we get a MUX that can control more pins, we could have the eMMC and use dimensional folding to add an microSDXC UHS-II slot on the SoC and then have the existing MUX switch between the microSDXC and right SDXC port... then we could have FOUR card slots and an eMMC... Yeah, that's the ticket.

With the keyboard there were for intents of human iterations nearly infinite combinations and configurations to consider. In this case there are a few options lining up with their own advantages and disadvantages.

The overall bandwidth of the v4.5 connection to the eMMC never would be able to match the overall bandwidth of the v5.1 eMMC. Where this would hurt is in sequential reads and maybe sequential writes. It may or may not make any difference at all to random reads and random writes. So, the actual impact to real world usage may be in single digit percentage decreases in data performance time. Quantifying this real world impact would require creating an SoC board without the MUX and the no longer MUX controlled pins connected to use for a baseline, right? It kind of sounds like they may be in the process of setting up that test?

- Does the current solution allow for and currently work with both the eMMC and microSD concurrently mounted or can this scenario only maybe work later after someone might be able to build a driver for it? (If working, it may make sense to accept it as is.)

- If the MUX is removed and the pins for the eMMC are wired directly (no idea how), that would sacrifice the microSD slot, but would it give the MUX full speed then? Is there something that can be loaded via a pick & place to make those connections? (Shed a tear for the internal microSD and move on option.)

Personally, I would like to know what the current solution MUXed up eMMC and microSD option really gets for performance on the eMMC before any rash decisions axing the microSDXC are considered.

 

[gpsqueeek]

How so? it would still be half the speed of a fully working eMMC at best...

I suppose it allows more testing of various OS versions. I must admit I am in a sort of "well whatever" way of thinking here ; I expected to have my /home on the internal µSD and the actual OS on the eMMC but I can do without this if need be. I'll keep neutral in the second Pyra war then (was not here in the first one, noob inside)

 

[TrashyMG]

@gpsqueeek, there are still two external SD cards and USB you can boot on if you want to try other OSs

 

[Silent-Hunter]

@TrashyMG Can the Pyra boot from all those? I thought it could only boot from microSD and eMMC?

 

[TrashyMG]

@TrashyMG Can the Pyra boot from all those? I thought it could only boot from microSD and eMMC?

The EVM at least can boot from eMMC, SD, USB or SATA... the Pyra I believe should still have this feature.

 

[Linux-SWAT]

How so? it would still be half the speed of a fully working eMMC at best...

miniSD owns even the best SSD.

 

[TrashyMG]

@Linux-SWAT if you say so...

 

[Linux-SWAT]

Can't you recognize an old joke ?

 

[TrashyMG]

Prob not, I can't remember yesterday.