Am 26.02.2014 um 13:30 schrieb Dr. H. Nikolaus Schaller:
some status about hw changes as discussed during/after embedded World:
- 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.
- 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.
- 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.
4. Barrel charger i have read through the forum and seen that people still want a barrel charger. And I tried to find out why people insist of having it.
Apparently they see the (real) problem that you can't charge the Pyra any more while using the USB3.0 port in Host Mode (which means connecting an external hard disk or whatever).
There is only one standard solution - some Y-Cable with Micro-USB3.0 to Micro-USB3.0 and a charger connection. There are some USB3 Y cables - but they are built for a completely different scenario (connect a micro-usb3 hard disk to a USB3 PC host port and add more power through a second USB2 plug). So we would have to find someone to build such a cable for us.
I have another idea: we can use the Micro-USB planned for the Console UART (FTDI RS232 built in) as a secondary charger input. So we just have to make sure that either Micro-USB socket can drive the charger. I.e. this needs some FETs as power switches (ideal diode). This appears as if it can easily be solved.
This solution may also justify the higher cost of the second Micro-USB socket plus FTDI chip on board - instead of just having the 1.8V levels on some expansion connector and requiring an external level shifter. Because it gets a dual purpose and saves us from providing a very special cable.
5. UMTS module activity sensor Some people would like to reliably disenable the UMTS module because they don't trust the power-off command or the power indicator LED provided by the module. So they want some external mechanical switch - or alternatively an activity indicator LED that uses external hardware to monitor the module's power drain. This can quite easily be done (there are current sensor chips with a threshold that can make an LED illuminate as soon as the module draws more than let's say 5 or 50mA). One minor problem is that such a circuit adds a voltage drop which must be kept very small since the module may draw 2-3 Amperes from the battery during transmission peaks. A mechanical switch must also have a very low resistance and should be very reliable.
BR, Nikolaus