That one got merged into the tree before 2015-10-11's 4.1.10-ti-r21
kernel. So we are good on that one..
It was first fixed on 4.1.6-ti-r17...
Regards,
Those are kernel parameters, right? Or are those sent to some other NVM. I’m going to flash again, this time I will power down and remove the sd card, and do a cold boot instead of a button reset.
The hdmi rail i2c edid rail was tied to the mmc0's card-detect...
So we had a situation where the we couldn't get the edid register when
booting from the eMMC. (lots of I2C errors)...
Regards,
Well, HDMI I2C still works. Not sure why it didn’t work the first boot…I had the board running for 29 days (actual uptime) with 4.1.6-ti-r14 and it wasn’t until this morning that I upgraded to 4.1.10-ti-r21 with the new eMMC image.
I’m pretty sure I didn’t do a cold boot before running the first eMMC flash session, but I am not 100% sure.
Maybe I can move on to compiling stuff now 
I have more on this: (thanks kishon for educating me on this).
Looks like we have a limitation on the current version of x15 (an issue
which was identified pretty late in the program):
- vdd pin of sd is connected also to the ldo1 which is the dual voltage
ldo in pmic - which basically makes uhs modes not possible to do on x15.
- kernel kind of assumes that uhs is always desired and these mux modes
are deemed as mandatory for functionality, hence prints warnings when
not found.
I guess we kind of missed the possibility of boards that may not be able
to do that.. at the very least we might have to control the spam of
messages by adequate dt description to better represent the board
limitation.
Anyways, that kind of explains what was going on.
Thanks Nishanth for the update.
I'll move these to pr_info for beagleboard.org's kernel as pr_err
spams the "quiet" parameter we use on bootup, and as we can't fix them
without a board change..
Regards,
I think the dev_errs are pretty much correct in the context here.
Given that we might have a newer board (at some unknown time - maybe
Gerald or who ever can comment better) *may* eventually have a fix (with
AM572x ES2.0 probably).. such a dev_err should indicate wrong dtb
attempt or so.
ideally, we should describe it correctly in dtb and driver should not
attempt to look for "mandatory dt parameters" on an "not possible to do
feature on this board" ... hopefully we will do capability for driver to
be educated that not everything in real world will be "rosy and true"
;)... give us a few days to fix up, but if it is very urgent feel free
to hack it up by lowering the warning severity, with the expectation
that the hack will be reverted once we push in the final fix.
I mean, what ever makes sense to you guys..
omap_hsmmc 4809c000.mmc: no pinctrl state for sdr104 mode
omap_hsmmc 4809c000.mmc: no pinctrl state for hs200_1_8v mode
omap_hsmmc 4809c000.mmc: no pinctrl state for ddr50 mode
omap_hsmmc 4809c000.mmc: no pinctrl state for sdr50 mode
omap_hsmmc 4809c000.mmc: no pinctrl state for sdr25 mode
omap_hsmmc 4809c000.mmc: no pinctrl state for sdr12 mode
omap_hsmmc 4809c000.mmc: no pinctrl state for ddr_1_8v mode
omap_hsmmc 480b4000.mmc: no pinctrl state for sdr104 mode
omap_hsmmc 480b4000.mmc: no pinctrl state for hs200_1_8v mode
omap_hsmmc 480b4000.mmc: no pinctrl state for ddr50 mode
omap_hsmmc 480b4000.mmc: no pinctrl state for sdr50 mode
omap_hsmmc 480b4000.mmc: no pinctrl state for sdr25 mode
omap_hsmmc 480b4000.mmc: no pinctrl state for sdr12 mode^^ This we know about on v4.1 kernel, and are working to fix.
basically iodelay configuration needed.I have more on this: (thanks kishon for educating me on this).
Looks like we have a limitation on the current version of x15 (an issue
which was identified pretty late in the program):
- vdd pin of sd is connected also to the ldo1 which is the dual voltage
ldo in pmic - which basically makes uhs modes not possible to do on x15.
- kernel kind of assumes that uhs is always desired and these mux modes
are deemed as mandatory for functionality, hence prints warnings when
not found.I guess we kind of missed the possibility of boards that may not be able
to do that.. at the very least we might have to control the spam of
messages by adequate dt description to better represent the board
limitation.Thanks Nishanth for the update.
I'll move these to pr_info for beagleboard.org's kernel as pr_err
spams the "quiet" parameter we use on bootup, and as we can't fix them
without a board change..I think the dev_errs are pretty much correct in the context here.
True, i was just thinking of hiding it from x15 users. 
Given that we might have a newer board (at some unknown time - maybe
Gerald or who ever can comment better) *may* eventually have a fix (with
AM572x ES2.0 probably).. such a dev_err should indicate wrong dtb
attempt or so.ideally, we should describe it correctly in dtb and driver should not
attempt to look for "mandatory dt parameters" on an "not possible to do
feature on this board" ... hopefully we will do capability for driver to
be educated that not everything in real world will be "rosy and true"
;)... give us a few days to fix up, but if it is very urgent feel free
to hack it up by lowering the warning severity, with the expectation
that the hack will be reverted once we push in the final fix.I mean, what ever makes sense to you guys..
Humm, it looks like the modes are defined in dra7.dtsi: mmcX:
I wonder, delprop?
(i'm use to adding random nods, not removing them.)
Regards,
Not sure what the plan is here. We have had a lot of direction changes over the last year from TI. Gotten hard to keep up with all of them.
Changes at ES2.0 make sense, but i have no schedule from TI on its availability. SO I cannot comment as to when we would have an update.
Gerald
Maybe Kishon can advice better here(I am on the boundary of my mmc mode
knowledge here).
Yes, /delete-property/ is already used on dra7-evm to remove
mmc-hs200-1_8v - something similar to be done here - but is that correct
way to do it? I am not sure.
Not sure what the plan is here. We have had a lot of direction changes
over the last year from TI. Gotten hard to keep up with all of them.
Unfortunately, yeah, the board changes have been reflecting that 
Changes at ES2.0 make sense, but i have no schedule from TI on its
availability. SO I cannot comment as to when we would have an update.
Beagleboard:BeagleBoard-X15 - eLinux.org mentions something
about "We are starting production build now of 2,000 boards based on
processor availability. "
Now, if it is decided to put ES2.0 silicon(due to what ever logistics
situation) on the existing boards, we are still stuck with the same
problem. we end up with a dts management mess as a result :(.
Ah we do that with mmc2 also with mmc-hs200-1_8v.. So unless we want
to define the available "modes" in the board *.dts, removal is the
best option.. (removal seems like less dts churn for mainline
kernel.org..)
Regards,
hum...
diff --git a/src/arm/am57xx-beagle-x15.dts b/src/arm/am57xx-beagle-x15.dts
index 333db77..b618071 100644
--- a/src/arm/am57xx-beagle-x15.dts
+++ b/src/arm/am57xx-beagle-x15.dts
@@ -639,6 +639,12 @@
bus-width = <4>;
cd-gpios = <&gpio6 27 0>; /* gpio 219 */
max-frequency = <96000000>;
+ /delete-property/ mmc-hs200-1_8v;
+ /delete-property/ sd-uhs-sdr104;
+ /delete-property/ sd-uhs-sdr50;
+ /delete-property/ sd-uhs-ddr50;
+ /delete-property/ sd-uhs-sdr25;
+ /delete-property/ sd-uhs-sdr12;
};
yet...
Starting kernel ...
[ 3.469224] pci 0000:00:00.0: IOMMU is currently not supported for PCI
[ 3.538881] omap_hsmmc 4809c000.mmc: no pinctrl state for sdr104 mode
[ 3.545386] omap_hsmmc 4809c000.mmc: no pinctrl state for hs200_1_8v mode
[ 3.552207] omap_hsmmc 4809c000.mmc: no pinctrl state for ddr50 mode
[ 3.558610] omap_hsmmc 4809c000.mmc: no pinctrl state for sdr50 mode
[ 3.565012] omap_hsmmc 4809c000.mmc: no pinctrl state for sdr25 mode
[ 3.571395] omap_hsmmc 4809c000.mmc: no pinctrl state for sdr12 mode
[ 3.577795] omap_hsmmc 4809c000.mmc: no pinctrl state for ddr_1_8v mode
[ 3.623736] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr104 mode
[ 3.631275] omap_hsmmc 480b4000.mmc: no pinctrl state for hs200_1_8v mode
[ 3.640157] omap_hsmmc 480b4000.mmc: no pinctrl state for ddr50 mode
[ 3.646615] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr50 mode
[ 3.653070] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr25 mode
[ 3.659507] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr12 mode
[ 3.723735] omap_voltage_late_init: Voltage driver support not added
okay so not that easy...
Regards,
Hi,
omap_hsmmc 4809c000.mmc: no pinctrl state for sdr104 mode
omap_hsmmc 4809c000.mmc: no pinctrl state for hs200_1_8v mode
omap_hsmmc 4809c000.mmc: no pinctrl state for ddr50 mode
omap_hsmmc 4809c000.mmc: no pinctrl state for sdr50 mode
omap_hsmmc 4809c000.mmc: no pinctrl state for sdr25 mode
omap_hsmmc 4809c000.mmc: no pinctrl state for sdr12 mode
omap_hsmmc 4809c000.mmc: no pinctrl state for ddr_1_8v mode
omap_hsmmc 480b4000.mmc: no pinctrl state for sdr104 mode
omap_hsmmc 480b4000.mmc: no pinctrl state for hs200_1_8v mode
omap_hsmmc 480b4000.mmc: no pinctrl state for ddr50 mode
omap_hsmmc 480b4000.mmc: no pinctrl state for sdr50 mode
omap_hsmmc 480b4000.mmc: no pinctrl state for sdr25 mode
omap_hsmmc 480b4000.mmc: no pinctrl state for sdr12 mode^^ This we know about on v4.1 kernel, and are working to fix.
basically iodelay configuration needed.I have more on this: (thanks kishon for educating me on this).
Looks like we have a limitation on the current version of x15 (an issue
which was identified pretty late in the program):
- vdd pin of sd is connected also to the ldo1 which is the dual voltage
ldo in pmic - which basically makes uhs modes not possible to do on x15.
- kernel kind of assumes that uhs is always desired and these mux modes
are deemed as mandatory for functionality, hence prints warnings when
not found.I guess we kind of missed the possibility of boards that may not be able
to do that.. at the very least we might have to control the spam of
messages by adequate dt description to better represent the board
limitation.Thanks Nishanth for the update.
I'll move these to pr_info for beagleboard.org's kernel as pr_err
spams the "quiet" parameter we use on bootup, and as we can't fix them
without a board change..I think the dev_errs are pretty much correct in the context here.
True, i was just thinking of hiding it from x15 users.
Given that we might have a newer board (at some unknown time - maybe
Gerald or who ever can comment better) *may* eventually have a fix (with
AM572x ES2.0 probably).. such a dev_err should indicate wrong dtb
attempt or so.ideally, we should describe it correctly in dtb and driver should not
attempt to look for "mandatory dt parameters" on an "not possible to do
feature on this board" ... hopefully we will do capability for driver to
be educated that not everything in real world will be "rosy and true"
;)... give us a few days to fix up, but if it is very urgent feel free
to hack it up by lowering the warning severity, with the expectation
that the hack will be reverted once we push in the final fix.I mean, what ever makes sense to you guys..
Humm, it looks like the modes are defined in dra7.dtsi: mmcX:
I wonder, delprop?
(i'm use to adding random nods, not removing them.)
Maybe Kishon can advice better here(I am on the boundary of my mmc mode
knowledge here).Yes, /delete-property/ is already used on dra7-evm to remove
mmc-hs200-1_8v - something similar to be done here - but is that correct
way to do it? I am not sure.Ah we do that with mmc2 also with mmc-hs200-1_8v.. So unless we want
to define the available "modes" in the board *.dts, removal is the
best option.. (removal seems like less dts churn for mainline
kernel.org..)hum...
diff --git a/src/arm/am57xx-beagle-x15.dts b/src/arm/am57xx-beagle-x15.dts
index 333db77..b618071 100644
--- a/src/arm/am57xx-beagle-x15.dts
+++ b/src/arm/am57xx-beagle-x15.dts
@@ -639,6 +639,12 @@
bus-width = <4>;
cd-gpios = <&gpio6 27 0>; /* gpio 219 */
max-frequency = <96000000>;
+ /delete-property/ mmc-hs200-1_8v;
+ /delete-property/ sd-uhs-sdr104;
+ /delete-property/ sd-uhs-sdr50;
+ /delete-property/ sd-uhs-ddr50;
+ /delete-property/ sd-uhs-sdr25;
+ /delete-property/ sd-uhs-sdr12;
};yet...
Starting kernel ...
[ 3.469224] pci 0000:00:00.0: IOMMU is currently not supported for PCI
[ 3.538881] omap_hsmmc 4809c000.mmc: no pinctrl state for sdr104 mode
[ 3.545386] omap_hsmmc 4809c000.mmc: no pinctrl state for hs200_1_8v mode
[ 3.552207] omap_hsmmc 4809c000.mmc: no pinctrl state for ddr50 mode
[ 3.558610] omap_hsmmc 4809c000.mmc: no pinctrl state for sdr50 mode
[ 3.565012] omap_hsmmc 4809c000.mmc: no pinctrl state for sdr25 mode
[ 3.571395] omap_hsmmc 4809c000.mmc: no pinctrl state for sdr12 mode
[ 3.577795] omap_hsmmc 4809c000.mmc: no pinctrl state for ddr_1_8v mode
[ 3.623736] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr104 mode
[ 3.631275] omap_hsmmc 480b4000.mmc: no pinctrl state for hs200_1_8v mode
[ 3.640157] omap_hsmmc 480b4000.mmc: no pinctrl state for ddr50 mode
[ 3.646615] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr50 mode
[ 3.653070] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr25 mode
[ 3.659507] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr12 mode
[ 3.723735] omap_voltage_late_init: Voltage driver support not addedokay so not that easy...
yeah.. these are not based on capability properties.
If the *compatible* indicates that this SoC requires pinctrl (for
iodelay), then during probe the driver tries to get the pinctrl of all
the modes. If pinctrl for a particular mode is not present, then it
disables that capability and prints a warning.
Thanks
Kishon
ES2.0 will not be put on these boards. We will make a layout change to fix the other issue…
Gerald
The flasher seemed to work for me. USB wireless keyboard and mouse are working as is HDMI and Ethernet 1.
apt-get update and apt-get upgrade downloaded and updated fine.
Looking through the dmesg, I don’t see anything horribly wrong yet.
And, I updated the bootloader this AM. The boot was snappy and the board was up quickly. Now, I’ve got to hook up an ESATA to it the test the new capability.
Digging up from an old discussion:
Well, HDMI I2C still works. Not sure why it didn't work the first boot....I
had the board running for 29 days (actual uptime) with 4.1.6-ti-r14 and it
wasn't until this morning that I upgraded to 4.1.10-ti-r21 with the new
eMMC image.I'm pretty sure I didn't do a cold boot before running the first eMMC flash
session, but I am not 100% sure.Maybe I can move on to compiling stuff now
> Those are kernel parameters, right? Or are those sent to some other NVM.
> I'm
> going to flash again, this time I will power down and remove the sd
> card,
> and do a cold boot instead of a button reset.The hdmi rail i2c edid rail was tied to the mmc0's card-detect...
So we had a situation where the we couldn't get the edid register when
booting from the eMMC. (lots of I2C errors)...
I am booting off the SD card :).
Here is something slightly different experience.
I bought Amazon.com and was trying to
get detection to work. but when I measured pin 15 on the connector (HP
DET), I can see 5v when plugged in 0v when removed (which I assume is
the expected Hot plug detect behavior). I then removed resistor R248
(10k) and at least I can see that x15 is able to detect the monitor -
however, EDID read has'nt progressed well for me.