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
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
On Wed, Feb 26, 2014 at 6:53 PM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
- 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.
At least on OMAP3+twl4030 combo this wouldn't work, unless you disconnect VBUS from twl4030 and control it externally.. As soon as you put musb into host mode it automatically drives the bus (musb hw sends commands to twl through ULPI (or whatever it was) bus automatically), and if somebody else is driving the bus the controller crashes and needs a powercycle.
Maybe things have improved now but I wouldn't be surprised if this scenario still wouldn't work at all.
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.
I'd prefer this one too, perhaps even only allow charging though that port to avoid potential issues like I described above.
Some time ago ED told me he wanted a dedicated charging solution that the unit could be charged while it's off. Do we still have such goal?
Gražvydas
Am 26.02.2014 um 18:36 schrieb Grazvydas Ignotas:
On Wed, Feb 26, 2014 at 6:53 PM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
- 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.
At least on OMAP3+twl4030 combo this wouldn't work, unless you disconnect VBUS from twl4030 and control it externally.. As soon as you put musb into host mode it automatically drives the bus (musb hw sends commands to twl through ULPI (or whatever it was) bus automatically), and if somebody else is driving the bus the controller crashes and needs a powercycle.
Maybe things have improved now but I wouldn't be surprised if this scenario still wouldn't work at all.
The USB host mode on OMAP5 is completely different from OMAP3+TWL.
They just do the protocols. VBUS logic has to be done externally.
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.
I'd prefer this one too, perhaps even only allow charging though that port to avoid potential issues like I described above.
Some time ago ED told me he wanted a dedicated charging solution that the unit could be charged while it's off. Do we still have such goal?
Yes. We even must use it since there is no TWL4030 on the OMAP5 which tries to do everything and does not everything right.
Even the TWL6037 has no charger integrated.
So things will be easier (but we may see different problems).
BR, Nikolaus
Am Wed, 26 Feb 2014 17:53:24 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
- 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.
Be careful about a switch! We do NOT want to add a physical switch somewhere at the case! Not all units will have UMTS, and a switch adds costs (more complicated case mold, needs to manually be assembled, etc.)
So in case an LED does not work, we will not include anything else - I still think the chance of the module being compromised is very very slim.
Am 26.02.2014 um 19:07 schrieb Michael Mrozek:
Am Wed, 26 Feb 2014 17:53:24 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
- 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.
Be careful about a switch! We do NOT want to add a physical switch somewhere at the case! Not all units will have UMTS, and a switch adds costs (more complicated case mold, needs to manually be assembled, etc.)
Exactly - if we even get a switch that does not harm normal operation (2-3A switching current and less than 30 mOhms or so...). A simple DIP switch is definitively not reliable enough.
So in case an LED does not work, we will not include anything else - I still think the chance of the module being compromised is very very slim.
Me too... Those manufacturers have no interest in adding what some of our customers suspect. Because they can't risk ruining their reputation.
And would NSA be interested in tracking if a coke vending machine becomes empty? I don't think so...
But sometimes by thinking a little more we can find a good solution that makes everybody happy.
BR, Nikolaus
Okay, so I took a look at all that MIPI stuff tonight and hope I can be a bit of help.
As we know, MIPI only gives out specifications if you become a member (which is horribly expensive).
OculusVR is a member, so I could get more needed details from Palmer if we need them. Additionally, TI is a founder of the MIPI alliance, so they might be able to help us out with further documentation as well.
However, I was able to find PDF copies of the MIPI Specifications, that might be of help. The most important one is probably the DCS command set documentation. It tells us a lot about how to speak to the display, and even request diagnostic information back!
Maybe in there there's the hidden clue to get it working - maybe after you initialize it, you need to send a DCS to tell it to become active... who knows.
Well, I attached all these documents, together with a copy of "DSI Demystified" by TI - which seems to give more information about MIPI and the OMAP as well.
I hope that helps. Let me know if there's anything else I can look for.
I'll phone up Renesas about the IC driver datasheet as well (though as far as I understood, MIPI DCS is standard, so I'm not sure we learn more about that here).
Oookay, page 19 of the DCS guide is interesting.
According to a flowchart, a MIPI display is in sleep mode after the initialization sequence.
And according to MIPI, sleep mode is: "In Sleep mode, the display module does not show any image data. In addition, the display interface shall remain powered and along with those functional blocks necessary to maintain the data in the frame memory and registers. The remaining functional blocks are placed in their low power modes. See section 6.5 for a description of Sleep mode."
So yeah, if we just initialized the display without leaving sleep mode, the display shouldn't show any picture at all.
Did we ever exit the sleep mode? (according to DCS, exiting sleep mode is hex code 11h)
get_power_mode (0Ah) is probably interesting as well - as it tells us whether the display is idle, in sleep mode, powered off, etc. (refer to page 58 of the DCS specs)
The result are bits that are encoded to Hex - impossible to read that without the DCS Specs guide, so that really should be helpful!
Am 27.02.2014 um 03:34 schrieb Michael Mrozek:
Oookay, page 19 of the DCS guide is interesting.
According to a flowchart, a MIPI display is in sleep mode after the initialization sequence.
And according to MIPI, sleep mode is: "In Sleep mode, the display module does not show any image data. In addition, the display interface shall remain powered and along with those functional blocks necessary to maintain the data in the frame memory and registers. The remaining functional blocks are placed in their low power modes. See section 6.5 for a description of Sleep mode."
So yeah, if we just initialized the display without leaving sleep mode, the display shouldn't show any picture at all.
Did we ever exit the sleep mode?
Yes, of course:
[ 1866.119171] dsi: r63311_write(00) [ 1866.133605] dsi: r63311_write(b0 04) [ 1866.149230] dsi: r63311_write(00) [ 1866.164855] dsi: r63311_write(00) [ 1866.180480] dsi: r63311_write(b3 14 00 00 00 00 00) [ 1866.196105] dsi: r63311_write(b6 3a d3) [ 1866.211730] dsi: r63311_write(c1 84 60 50 00 00 00 00 00 00 0c 01 58 73 ae 31 20 06 00 00 00 00 00 00 10 10 10 10 00 00 00 22 02 02 00) [ 1866.235168] dsi: r63311_write(c2 31 f7 80 0a 08 00 00) [ 1866.250793] dsi: r63311_write(c3 01 00 00) [ 1866.266418] dsi: r63311_write(c4 70 00 00 00 07 05 05 09 09 0c 06 00 00 00 00 07 05 05 09 09 0c 06) [ 1866.289855] dsi: r63311_write(c6 00 69 00 69 00 69 00 00 00 00 00 69 00 69 00 69 10 19 07 00 01 00 69 00 69 00 69 00 00 00 00 00 69 00 69 00 69 10 19 07) [ 1866.313293] dsi: r63311_write(c7 00 09 14 26 31 48 3b 52 5f 67 6b 70 00 09 14 26 31 48 3b 52 5f 67 6b 70) [ 1866.336944] dsi: r63311_write(c8 00 09 14 26 31 48 3b 52 5f 67 6b 70 00 09 14 26 31 48 3b 52 5f 67 6b 70) [ 1866.360168] dsi: r63311_write(c9 00 09 14 26 31 48 3b 52 5f 67 6b 70 00 09 14 26 31 48 3b 52 5f 67 6b 70) [ 1866.383605] dsi: r63311_write(cc 09) [ 1866.399291] dsi: r63311_write(d0 00 00 19 18 99 99 19 01 89 00 55 19 99 01) [ 1866.414855] dsi: r63311_write(d3 1b 33 bb cc c4 33 33 33 00 01 00 a0 d8 a0 0d 37 33 44 22 70 02 37 03 3d bf 00) [ 1866.438293] dsi: r63311_write(d5 06 00 00 01 39 01 39) [ 1866.453918] dsi: r63311_write(d5 06 00 00 01 39 01 39) [ 1866.500793] dsi: r63311_write(51 ff) [ 1866.504577] dsi: r63311_write(29) [ 1866.516418] dsi: r63311_write(11)
BTW: [ 1866.667999] DISPC: channel 0 xres 1080 yres 1920 [ 1866.668029] DISPC: pck 144000 [ 1866.668029] DISPC: hsw 10 hfp 10 hbp 100 vsw 10 vfp 10 vbp 60 [ 1866.668060] DISPC: vsync_level 0 hsync_level 0 data_pclk_edge 1 de_level 0 sync_pclk_edge 0 [ 1866.668090] DISPC: hsync 120000Hz, vsync 60Hz
(according to DCS, exiting sleep mode is hex code 11h)
Yes. This is BTW the only command that has a visual influence. 10h and 11h make the washed out image invert. But nothing else (besides changing the register 0Ah).
get_power_mode (0Ah) is probably interesting as well - as it tells us whether the display is idle, in sleep mode, powered off, etc. (refer to page 58 of the DCS specs)
Yes, I had checked that a while ago. It works as documented.
The result are bits that are encoded to Hex - impossible to read that without the DCS Specs guide, so that really should be helpful!
That was not that difficult w/o the DCS command set because the DCS command set is available in all panels and driver chips. And I have checked with 4 or 5 of them and some have a pretty good description of the 10h and 11h and 0Ah commands.
That is why I think our panel is working correct in the standard commands and the problem must be in the non-standardized area and why we need the R63311 data sheet.
Ah, if Oculus is member of MIPI they should be able to contact the secretary to get the name of the MIPI representative of Renesas. And through that channel they might be able to get the datasheet.
BR, Nikolaus
Hi,
Am 27.02.2014 um 01:39 schrieb Michael Mrozek:
Okay, so I took a look at all that MIPI stuff tonight and hope I can be a bit of help.
As we know, MIPI only gives out specifications if you become a member (which is horribly expensive).
Unfortunatley...
OculusVR is a member, so I could get more needed details from Palmer if we need them.
Ah, that may be really helpful!
Additionally, TI is a founder of the MIPI alliance, so they might be able to help us out with further documentation as well.
However, I was able to find PDF copies of the MIPI Specifications, that might be of help. The most important one is probably the DCS command set documentation. It tells us a lot about how to speak to the display, and even request diagnostic information back!
I already have studied those documents except that one. I had tried to find it a while ago (it is referenced in other documents) but without success.
Great thanks!
Unfortunately it turns out that it is not the newest release. E.g. the backlight commands are not described. And of course the manufacturer specific commands of the R63311 aren't as well.
Maybe in there there's the hidden clue to get it working - maybe after you initialize it, you need to send a DCS to tell it to become active... who knows.
Yes. We are doing everything as described in the DCS command and the responses we can read (power mode etc.) are as expected (I have tested that a while ago).
Well, I attached all these documents, together with a copy of "DSI Demystified" by TI - which seems to give more information about MIPI and the OMAP as well.
Yes (it is part of the package we did FTP download from TI). Our signals look exactly as described there - at least as much as we can see (the problem may also be hidden in some invisible detail).
I hope that helps. Let me know if there's anything else I can look for.
I'll phone up Renesas about the IC driver datasheet as well (though as far as I understood, MIPI DCS is standard, so I'm not sure we learn more about that here).
I think I described it several times: there are Renesas defined commands that go beyond any spec by MIPI. MIPI-DCS only defines that they can exist but not what they do. E.g. the commands to control voltage converters on the panel.
BR, Nikolaus
Hi,
and some more information following soon. I've just had a chat with Palmer from Oculus and they're trying to send us as many documentation as might be helpful for us to get MIPI working.
They got an LG 5,5" display working (using the same RS driver IC, so probably similar), and he'll also ask his display hacker team whether someone would like to help us out in his spare time.
Am 27.02.2014 um 02:26 schrieb Michael Mrozek:
Hi,
and some more information following soon. I've just had a chat with Palmer from Oculus and they're trying to send us as many documentation as might be helpful for us to get MIPI working.
They got an LG 5,5" display working (using the same RS driver IC, so probably similar), and he'll also ask his display hacker team whether someone would like to help us out in his spare time.
Yes, that would be great! At least if they can share schematics and source code of their driver.
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
ICQ: 15691903 MSN: EvilDragon1717@hotmail.com eMail: info@openpandora.de _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
On Wed, Feb 26, 2014 at 2:30 PM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
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.
I don't really understand how you are going to make it work at all, ignoring the software switch issues. The data lines would be shared between eMMC and uSD, wouldn't they be? Even if you don't power the one you don't need, wouldn't they both interfere? I don't think SD cards are designed for the case of somebody else driving data lines while they are powered off. Wouldn't the voltages differ too, like the SD card uses ~3V and I'd expect eMMC 1.8V, although I haven't checked.
I think some old Nokia tablet (N800?) used multiple cards on the same controller somehow, at least I remember seeing some kernel code for that..
Gražvydas
Am 26.02.2014 um 18:27 schrieb Grazvydas Ignotas:
On Wed, Feb 26, 2014 at 2:30 PM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
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.
I don't really understand how you are going to make it work at all, ignoring the software switch issues. The data lines would be shared between eMMC and uSD, wouldn't they be? Even if you don't power the one you don't need, wouldn't they both interfere?
They are not wired in parallel but there is an electronic switch chip for the data and clock:
http://www.ti.com/product/txs02612
I don't think SD cards are designed for the case of somebody else driving data lines while they are powered off. Wouldn't the voltages differ too, like the SD card uses ~3V and I'd expect eMMC 1.8V, although I haven't checked.
It also handles the voltage level translation.
I think some old Nokia tablet (N800?) used multiple cards on the same controller somehow, at least I remember seeing some kernel code for that..
Gražvydas _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel