The Solid-Run CuBox-i lower board used in the first generation of
CuBox-i devices feature a hinged micro SD card slot, that does not have
card-detect capability. Since the card-detect GPIO was specified in the
common cubox-i dtsi, it is moved to each device using the 1.5 SOM and is
thus removed from the imx6q-cubox-i dts.
Enabling the card-detect GPIO on the first generation CuBox-i devices
results in waiting for a card-detect event (that never occurs) and thus
not detecting the mmc card.
Since the CD pin is still dedicated to the purpose on the SOM board even
on the first generation CuBox-i devices, the pin control properties are
kept untouched regardless of the slot capability.
Signed-off-by: Paul Kocialkowski <[email protected]>
---
arch/arm/boot/dts/imx6dl-cubox-i-emmc-som-v15.dts | 4 ++++
arch/arm/boot/dts/imx6dl-cubox-i-som-v15.dts | 4 ++++
arch/arm/boot/dts/imx6q-cubox-i-emmc-som-v15.dts | 4 ++++
arch/arm/boot/dts/imx6q-cubox-i-som-v15.dts | 4 ++++
arch/arm/boot/dts/imx6qdl-cubox-i.dtsi | 1 -
5 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6dl-cubox-i-emmc-som-v15.dts b/arch/arm/boot/dts/imx6dl-cubox-i-emmc-som-v15.dts
index 2b2fc360b865..90a15f3b4fc0 100644
--- a/arch/arm/boot/dts/imx6dl-cubox-i-emmc-som-v15.dts
+++ b/arch/arm/boot/dts/imx6dl-cubox-i-emmc-som-v15.dts
@@ -50,3 +50,7 @@
model = "SolidRun Cubox-i Solo/DualLite (1.5som+emmc)";
compatible = "solidrun,cubox-i/dl", "fsl,imx6dl";
};
+
+&usdhc2 {
+ cd-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
+};
diff --git a/arch/arm/boot/dts/imx6dl-cubox-i-som-v15.dts b/arch/arm/boot/dts/imx6dl-cubox-i-som-v15.dts
index e09c565d1d1f..9bdec07fefe3 100644
--- a/arch/arm/boot/dts/imx6dl-cubox-i-som-v15.dts
+++ b/arch/arm/boot/dts/imx6dl-cubox-i-som-v15.dts
@@ -49,3 +49,7 @@
model = "SolidRun Cubox-i Solo/DualLite (1.5som)";
compatible = "solidrun,cubox-i/dl", "fsl,imx6dl";
};
+
+&usdhc2 {
+ cd-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
+};
diff --git a/arch/arm/boot/dts/imx6q-cubox-i-emmc-som-v15.dts b/arch/arm/boot/dts/imx6q-cubox-i-emmc-som-v15.dts
index 3e59ebbb3608..679a5431cbdb 100644
--- a/arch/arm/boot/dts/imx6q-cubox-i-emmc-som-v15.dts
+++ b/arch/arm/boot/dts/imx6q-cubox-i-emmc-som-v15.dts
@@ -58,3 +58,7 @@
fsl,transmit-atten-16ths = <9>;
fsl,no-spread-spectrum;
};
+
+&usdhc2 {
+ cd-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
+};
diff --git a/arch/arm/boot/dts/imx6q-cubox-i-som-v15.dts b/arch/arm/boot/dts/imx6q-cubox-i-som-v15.dts
index dab70d1230a2..b9b8733f13c3 100644
--- a/arch/arm/boot/dts/imx6q-cubox-i-som-v15.dts
+++ b/arch/arm/boot/dts/imx6q-cubox-i-som-v15.dts
@@ -57,3 +57,7 @@
fsl,transmit-atten-16ths = <9>;
fsl,no-spread-spectrum;
};
+
+&usdhc2 {
+ cd-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
+};
diff --git a/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi b/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
index d1cfdc264126..170b3d27f875 100644
--- a/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
@@ -254,7 +254,6 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_cubox_i_usdhc2_aux &pinctrl_cubox_i_usdhc2>;
vmmc-supply = <&vcc_3v3>;
- cd-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
status = "okay";
};
--
2.17.0
On Sun, Apr 22, 2018 at 04:21:51PM +0200, Paul Kocialkowski wrote:
> The Solid-Run CuBox-i lower board used in the first generation of
> CuBox-i devices feature a hinged micro SD card slot, that does not have
> card-detect capability. Since the card-detect GPIO was specified in the
> common cubox-i dtsi, it is moved to each device using the 1.5 SOM and is
> thus removed from the imx6q-cubox-i dts.
This seems incorrect.
The 1.5 SOM is a relatively recent thing, and I have one of the first
Cubox-i's that were produced which is not hinged, and does not have a
1.5 SOM. There is _no_ correlation between the 1.5 SOM and the SD
card slot.
Talking to folk at SolidRun, we're all confused about your assertions.
We're also confused about "hinged micro SD card slot" - Cubox-i's
come with either a push-push slot or a static (push-in, pull-out) slot.
(Prototypes were the latter.)
Maybe someone's modified yours?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
Hi,
Le dimanche 22 avril 2018 à 15:39 +0100, Russell King - ARM Linux a
écrit :
> On Sun, Apr 22, 2018 at 04:21:51PM +0200, Paul Kocialkowski wrote:
> > The Solid-Run CuBox-i lower board used in the first generation of
> > CuBox-i devices feature a hinged micro SD card slot, that does not
> > have
> > card-detect capability. Since the card-detect GPIO was specified in
> > the
> > common cubox-i dtsi, it is moved to each device using the 1.5 SOM
> > and is
> > thus removed from the imx6q-cubox-i dts.
>
> This seems incorrect.
>
> The 1.5 SOM is a relatively recent thing, and I have one of the first
> Cubox-i's that were produced which is not hinged, and does not have a
> 1.5 SOM. There is _no_ correlation between the 1.5 SOM and the SD
> card slot.
>
> Talking to folk at SolidRun, we're all confused about your assertions.
It appears that I was also confused about the different models in the
CuBox-i line. I had assumed that the models had been updated to a new
revision (carrying that 1.5 SOM) since the time I bought mine (which was
thus some sort of first generation). With this scenario in mind, it made
sense to me that a CD GPIO required only for the second generation would
have been applied by mistake to all the cubox-i devices by having it in
the common dtsi.
I checked on the leaflet inside the box and models did not change, only
the 4x4 model was added in the meantime.
> We're also confused about "hinged micro SD card slot" - Cubox-i's
> come with either a push-push slot or a static (push-in, pull-out)
> slot.
> (Prototypes were the latter.)
The one I have definitely does not have a spring-loaded mechanism, so I
would call it a push/pull static slot. I mentioned a hinged slot because
that's the term used to describe the layout in the CuBox-i-Lower
schematics, SD/MMC Connector part: "U3 is an internal hinged micro SD".
Looking at pictures of what hinged slots look like, that's definitely
not what I have here.
Are all CuBox-i units that have ever been sold supposed to have a
connector with a CD line? I find it hard to believe that it's broken
specifically on mine.
If that's really needed, I could open up the device, check whether the
R8 pull is in place and check the voltage there.
Cheers,
--
Paul Kocialkowski,
developer of free digital technology and hardware support.
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
Hi,
Le dimanche 22 avril 2018 à 15:02 +0000, Jon Nettleton a écrit :
> On Sun, Apr 22, 2018 at 4:39 PM Russell King - ARM Linux <linux@armlin
> ux.org.uk> wrote:
> > On Sun, Apr 22, 2018 at 04:21:51PM +0200, Paul Kocialkowski wrote:
> > > The Solid-Run CuBox-i lower board used in the first generation of
> > > CuBox-i devices feature a hinged micro SD card slot, that does not
> > have
> > > card-detect capability. Since the card-detect GPIO was specified
> > in the
> > > common cubox-i dtsi, it is moved to each device using the 1.5 SOM
> > and is
> > > thus removed from the imx6q-cubox-i dts.
> >
> > This seems incorrect.
> >
> > The 1.5 SOM is a relatively recent thing, and I have one of the
> > first
> > Cubox-i's that were produced which is not hinged, and does not have
> > a
> > 1.5 SOM. There is _no_ correlation between the 1.5 SOM and the SD
> > card slot.
> >
> > Talking to folk at SolidRun, we're all confused about your
> > assertions.
> >
> > We're also confused about "hinged micro SD card slot" - Cubox-i's
> > come with either a push-push slot or a static (push-in, pull-out)
> > slot.
> > (Prototypes were the latter.)
> >
> > Maybe someone's modified yours?
> >
> Regardless of the physical mechanics of the device, the CD-GPIO is a
> mechanism of the carrier and not the SOM. I have one of the few Cubox-
> i's that have been physically modified to work with the rev 1.5 som
> and have no issues (the heat spreader needs additional cutouts).
There was some confusion about the relationship with the 1.5 SOM. It is
now clear that the issue is not linked to it at all.
> Now if you are still using the old 2013 u-boot then there is possibly
> confusion between the eMMC and SDHC slots which can cause
> strangeness. Please use the 2018.01 branch on our github and that
> will handle this properly.
I'm using U-Boot 2018.03, so I think I'm safe on that side.
Cheers,
--
Paul Kocialkowski,
developer of free digital technology and hardware support.
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
Hi,
Le dimanche 22 avril 2018 à 19:22 +0200, Paul Kocialkowski a écrit :
> Are all CuBox-i units that have ever been sold supposed to have a
> connector with a CD line? I find it hard to believe that it's broken
> specifically on mine.
Do you have a clue whether there should, in fact, be a CD line on all
CuBox-i models out there? Although you seemed to imply that my device
might be broken, I am still confused about whether this issue concerns
my device only or a specific revision of the CuBox-i.
> If that's really needed, I could open up the device, check whether the
> R8 pull is in place and check the voltage there.
In case there is a doubt, I will proceed with opening the device so we
can have a clear idea, but I'd rather avoid it as much as possible.
Cheers,
--
Paul Kocialkowski,
developer of free digital technology and hardware support.
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
On Sun, Apr 29, 2018 at 3:47 PM, Paul Kocialkowski <[email protected]> wrote:
> Hi,
>
> Le dimanche 22 avril 2018 à 19:22 +0200, Paul Kocialkowski a écrit :
>> Are all CuBox-i units that have ever been sold supposed to have a
>> connector with a CD line? I find it hard to believe that it's broken
>> specifically on mine.
>
> Do you have a clue whether there should, in fact, be a CD line on all
> CuBox-i models out there? Although you seemed to imply that my device
> might be broken, I am still confused about whether this issue concerns
> my device only or a specific revision of the CuBox-i.
>
>> If that's really needed, I could open up the device, check whether the
>> R8 pull is in place and check the voltage there.
>
> In case there is a doubt, I will proceed with opening the device so we
> can have a clear idea, but I'd rather avoid it as much as possible.
>
> Cheers,
>
> --
> Paul Kocialkowski,
>
> developer of free digital technology and hardware support.
>
> Website: https://www.paulk.fr/
> Coding blog: https://code.paulk.fr/
> Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
Paul,
You can see on our schematics that the hinged sdhc card slot is an
assembly option and not the default.
https://wiki.solid-run.com/lib/exe/fetch.php?media=imx6:cubox-i:schematics-rev-1.1:cubox-i-lower.pdf
You have either an initial early developer unit (pre-production) that
was assembled like this for testing, or a unit that someone
specifically ordered assembled this way. You can see from the
schematic that this option does not have a CD-pin because it is meant
to be a more permanent storage option.
That being said, this is not a default option and therefore should not
be merged into the mainline device-tree. Our soms and carriers are
designed to be very flexible regarding the assembly options and we try
to mainline device-tree files that represent the most common assembly
options. Once there is a common accepted mainlining for device-tree
fragments for overlays, that would be the proper place to make this
change. Although in this case you would also need a custom u-boot so
it is probably best to just handle the change there. If you would
like touch base with me off list and I can point you at the required
u-boot changes.
Thanks,
Jon
Hi,
Le dimanche 29 avril 2018 à 16:09 +0200, Jon Nettleton a écrit :
> You have either an initial early developer unit (pre-production) that
> was assembled like this for testing, or a unit that someone
> specifically ordered assembled this way. You can see from the
> schematic that this option does not have a CD-pin because it is meant
> to be a more permanent storage option.
It turns out that the card-detection mechanism was somewhat broken on my
device (which does have a regular push slot). It would report card-
detect only when the card was not fully inserted, and stop asserting
card-detect when it was pushed fully.
I used a fitting tweezer to move the mechanical parts around and got it
to also detect the card when it is pushed all the way.
So no change is necessary after all, it was just my device that needed
fixing.
Thanks for the helpful answers!
--
Paul Kocialkowski,
developer of free digital technology and hardware support.
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/