some status about hw changes as discussed during/after embedded World:
1. eMMC/uSD/nanoSSD for internal memory
since nanoSDD draws too much current and is bigger and more difficult to get (so we expect it to be more pricy) we have ruled it out.
So we have decided to use the SIM/uSD combo socket and an electronic switch between eMMC and the uSD on the eMMC port 1 of the OMAP5.
It is not exactly clear how we operate the electronic switch.
People (_wb_) expect that there is some fully automatic search sequence...
Ideas so far:
a) DIP switch (i.e. a permanent switch)
b) reuse some shoulder/other button to be pressed during boot
c) GPIO (but the BootROM is not able to operate the GPIO and we can't modify the BootROM!)
Unfortunately we have no card-detect on such uSD readers. So we can't detect that a uSD is inserted to activate the switch.
Even if we had, I would not recommend to use it - because we then never have access to the eMMC and can't even reprogram it.
But what we can do is to mix the GPIO + button solution by using some series resistor on the GPIO and work with pull-up/pull down.
The means we can control the switch by software (and hook it up as "eMMC by default" and "press button" to force uSD).
As long as the Xloader/MLO in eMMC is ok, it could even be a patched version that really use the GPIO control and tries both options until it finds a U-Boot.
Linux could even suspend one memory and switch to the other one if user space tries to access the other one.
So the "force-uSD" button is just a "force MLO from uSD" (like on the OpenPandora, Beagleboard, GTA04).
Well, it is not that simple - because we must disable this function as soon as the system has booted - or people may activate the switch in the middle of some writing process. But this is also solvable by using a second GPIO to disable the override option. I think all this can be placed on the CPU board.
2. eSATA
since we have ruled out to use nanoSDD with eSATA interface (), the eSATA interface of the OMAP5 is sitting there without use.
So the idea of the USB2+eSATA combo is back.
By chance I did see an Atom eval board using exactly this socket, I did no recognise that the problematic wires are for USB2 and not for eSATA. So I think now that the layout will not as critical as I thought.
But still we have two potential issues:
a) we have no SMD socket - so it is THT making production more expensive or slower (but making the socket more robust)
b) space for the bigger socket (maybe it is less problematic as we think)
I will check the space aspect again today.
3. MIPI
Yesterday evening Christoph Mair did have his Nexus 5 with him and told that he did scan the /sys or /proc/config or something similar and also did like us not find a Renesas chip in the kernel config.
So we have developed a new speculation: the leaked LG Nexus 5 D821 service manual which is one source of assuming a MIPI interface is not the latest one and does not match the device we could buy. It might be possible that LG had planned to use this panel, but was not able to really use it in the final product. Maybe because it was not finished in time or whatever. And therefore they did use another one (on pressure from Google) with different interface and different drivers. And the updated service manual has not yet been leaked.
Today I want to look again in the OMAP5 MIPI Clock lane issue. Maybe the errata pointed by Notaz are the missing clue.
BR,
Nikolaus