URGENT Initial Default x15 Image

[Robert Nelson]

Hey Everyone,

It's getting close to that time.. Anyone with a Beta X15, please test
this flasher asap:

wget https://rcn-ee.com/rootfs/bb.org/testing/2015-10-11/lxqt-4gb/bbx15-eMMC-flasher-debian-8.2-lxqt-4gb-armhf-2015-10-11-4gb.img.xz
sha256sum: 431d933678c03c86c7d33a3e6508f3d68045cf3cc13a7a325d775db4cb30cde0

Either we will go with that image as-is or we get one shot at changes
for the "NEXT" weekly build on sunday Oct 18th. ;)

Reminder, this is just the 'initial' image flashed to the eMMC.. I'm
planning weekly builds..

and we can always update packages via apt..

PS... if you don't currently have an x15, you can also use the
omap5_uevm: (just note it's using a mainline u-boot)

wget https://rcn-ee.com/rootfs/bb.org/testing/2015-10-11/lxqt-4gb/omap5-uevm-debian-8.2-lxqt-4gb-armhf-2015-10-11-4gb.img.xz
sha256sum: 45a288e7d703dbb6a93b6a8e57a6fcc86a84dd23ceb8470a750921af3b7080ed

but the setup is similar..

Regards,

--
Robert Nelson
https://rcn-ee.com/

[Louis McCarthy]

For some reason the post has screwed up the download hyperlink. Not hard to find/fix. 

Used Ubuntu 14.04 "Disks" tool to write image to SD card. Inserted SD card into board and powered it up. It took ~930 seconds to flash eMMC (last dmesg entry:  [  928.221073] reboot: System halted) 

Good feedback through system console and on a locally connected monitor. 

There were a few system messages during the flash which were related to a USB device. Something about a disconnect reconnect of keyboard or mouse. My terminal buffer history was too short to keep the actual messages. Flashed system seems to be fine, with no USB messages so far. 

The system log has a few errors (no glaring problems, but FYI):

/cpus/cpu@0 missing clock-frequency property

/cpus/cpu@1 missing clock-frequency property

pci 0000:00:00.0: IOMMU is currently not supported for PCI

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

omap_voltage_late_init: Voltage driver support not added

omapdss error: HDMI I2C timeout reading EDID

systemd[1]: Job console-setup.service/start deleted to break ordering cycle starting with basic.target/start

vgaarb: this pci device is not a vga device

And lots of remoteproc messages, which I won't post here. 

I will continue to test other applications and peripherals.

Louis

[Nishanth Menon]

On 10/16/2015 11:39 AM, Louis McCarthy wrote:

>
> The system log has a few errors (no glaring problems, but FYI):
> /cpus/cpu@0 missing clock-frequency property
> /cpus/cpu@1 missing clock-frequency property

there is a bit of discussion on this topic
http://comments.gmane.org/gmane.linux.ports.arm.kernel/246932

> pci 0000:00:00.0: IOMMU is currently not supported for PCI
> 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.

> omap_voltage_late_init: Voltage driver support not added

This appears from legacy code in arch/arm/mach-omap2/voltage.c and is
harmless - I can squash this if folks want to.. mostly because the
am57/dra7 logic is reusing omap2_common_pm_late_init

> omapdss error: HDMI I2C timeout reading EDID
> systemd[1]: Job console-setup.service/start deleted to break ordering
> cycle starting with basic.target/start
> vgaarb: this pci device is not a vga device
>
> And lots of remoteproc messages, which I won't post here.
>
> I will continue to test other applications and peripherals.
>

Thanks..


--
Regards,
Nishanth Menon

[Robert Nelson]

On Fri, Oct 16, 2015 at 11:39 AM, Louis McCarthy <comp...@gmail.com> wrote:
> For some reason the post has screwed up the download hyperlink. Not hard to
> find/fix.
>
> Used Ubuntu 14.04 "Disks" tool to write image to SD card. Inserted SD card
> into board and powered it up. It took ~930 seconds to flash eMMC (last dmesg
> entry: [ 928.221073] reboot: System halted)
>
> Good feedback through system console and on a locally connected monitor.
>
> There were a few system messages during the flash which were related to a
> USB device. Something about a disconnect reconnect of keyboard or mouse. My
> terminal buffer history was too short to keep the actual messages. Flashed
> system seems to be fine, with no USB messages so far.
>
> The system log has a few errors (no glaring problems, but FYI):
> /cpus/cpu@0 missing clock-frequency property
> /cpus/cpu@1 missing clock-frequency property

I'm going to steal the pr_warn patch Nishanth pointed too. I already
do that for the ttyO0 -> ttyS0 migration.. ;)

> pci 0000:00:00.0: IOMMU is currently not supported for PCI
> 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
> omap_voltage_late_init: Voltage driver support not added

> omapdss error: HDMI I2C timeout reading EDID

odd.. i see that all the time on my omap5_uevm... did you have the
hdmi cable plugged in?

> systemd[1]: Job console-setup.service/start deleted to break ordering cycle
> starting with basic.target/start


> vgaarb: this pci device is not a vga device

This is from the drm stack, now that pci-e is enabled, a whole lot of
options... ;)

>
> And lots of remoteproc messages, which I won't post here.

all those remoteproc messages are about devices looking for firmware..
It's firmware you can compile. ;)

[Louis McCarthy]

It's been 2 years and we still don't know where to put the clock-frequency :) 

Yes I get a lot of HDMI timeouts (I only listed one for brevity), but they stop after about 60 seconds. I have an HDMI cable connected to a HDMI to DVI adapter, which is then connected to an old Dell monitor.

I'm getting to the compile part...hold your horses :) Gotta connect my fan again....that sucker gets hot after a while (compiling Qt). I didn't want to assume that it would start throttling after >70C temps, at least not until more units are available :)

[Robert Nelson]

On Fri, Oct 16, 2015 at 12:14 PM, Louis McCarthy <comp...@gmail.com> wrote:
> It's been 2 years and we still don't know where to put the clock-frequency
> :)

It looks to be a "what color do we paint the barn door?" problem. ;)

> Yes I get a lot of HDMI timeouts (I only listed one for brevity), but they
> stop after about 60 seconds. I have an HDMI cable connected to a HDMI to DVI
> adapter, which is then connected to an old Dell monitor.

I"m doing the same thing: DELL 1707FP

> I'm getting to the compile part...hold your horses :) Gotta connect my fan
> again....that sucker gets hot after a while (compiling Qt). I didn't want to
> assume that it would start throttling after >70C temps, at least not until
> more units are available :)

Oh it'll throttle.. ;) i think it'll even reboot if it gets too hot..

[Louis McCarthy]

If I open up the "Monitor Settings" tool, I get jerky mouse movement for a few seconds and then 3 more "omapdss error: HDMI I2C timeout reading EDID" in the system log.

[Robert Nelson]

On Fri, Oct 16, 2015 at 12:38 PM, Louis McCarthy <comp...@gmail.com> wrote:
> If I open up the "Monitor Settings" tool, I get jerky mouse movement for a
> few seconds and then 3 more "omapdss error: HDMI I2C timeout reading EDID"
> in the system log.

I get that too.. when opening "monitor settings"...

but not when firing up chrome.. It must be the i2c bus?

[Louis McCarthy]

I changed a couple things (brightness and resolution) and hit apply. I get a whole string of I2C errors, system becomes very sluggish, mouse movement is severely diminished. But, everything comes back to normal, after the "Keep Settings?" message is shown and times out.

After one or more of these changes, the system menu app crashed. But, interestingly, after that, the monitor settings application is much faster to change settings and the mouse is jerky but usable.

[Louis McCarthy]

Correction, the app is not crashed, but simply not visible anymore. The menu can still be shown with Alt-F1.

[Louis McCarthy]

Ok, so I performed a reboot using the command 'reboot'. No HDMI I2C errors and the display is properly detected now "HDMI-1 (HDMI-1) DELL 2007WF" at 1680x1050 & 59.88 Hz

[Louis McCarthy]

On another note, on that same 'reboot' there is a boot message that does not show up in the system log, but is printed to the console:

Starting kernel ...

[    0.051587] /cpus/cpu@0 missing clock-frequency property
[    0.051644] /cpus/cpu@1 missing clock-frequency property
[    3.458828] pci 0000:00:00.0: IOMMU is currently not supported for PCI
[    3.539322] omap_hsmmc 4809c000.mmc: no pinctrl state for sdr104 mode
[    3.545820] omap_hsmmc 4809c000.mmc: no pinctrl state for hs200_1_8v mode
[    3.552640] omap_hsmmc 4809c000.mmc: no pinctrl state for ddr50 mode
[    3.559040] omap_hsmmc 4809c000.mmc: no pinctrl state for sdr50 mode
[    3.565440] omap_hsmmc 4809c000.mmc: no pinctrl state for sdr25 mode
[    3.571824] omap_hsmmc 4809c000.mmc: no pinctrl state for sdr12 mode
[    3.578226] omap_hsmmc 4809c000.mmc: no pinctrl state for ddr_1_8v mode
[    3.623888] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr104 mode
[    3.631426] omap_hsmmc 480b4000.mmc: no pinctrl state for hs200_1_8v mode
[    3.640307] omap_hsmmc 480b4000.mmc: no pinctrl state for ddr50 mode
[    3.646766] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr50 mode
[    3.653220] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr25 mode
[    3.659657] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr12 mode
[    3.723787] omap_voltage_late_init: Voltage driver support not added
Loading, please wait...
fsck from util-linux 2.25.2
fsck: error 2 (No such file or directory) while executing fsck.ext4 for /dev/mmcblk0p1
fsck exited with status code 8
[   10.487702] systemd[1]: Job console-setup.service/start deleted to break ordering cycle starting with basic.target/start
[   10.794018] systemd-fsck[194]: BOOT: clean, 118616/233856 files, 719153/933632 blocks

[Robert Nelson]

On Fri, Oct 16, 2015 at 1:28 PM, Louis McCarthy <comp...@gmail.com> wrote:
> On another note, on that same 'reboot' there is a boot message that does not
> show up in the system log, but is printed to the console:
>
> Starting kernel ...
>
> [ 0.051587] /cpus/cpu@0 missing clock-frequency property
> [ 0.051644] /cpus/cpu@1 missing clock-frequency property

This ^^ is now patched hidden: (r23)
https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/ti-linux-4.1.y/patches/quieter/0002-quiet-topology.c-use-pr_info-over-pr_err-missing-clo.patch

> [ 3.458828] pci 0000:00:00.0: IOMMU is currently not supported for PCI
> [ 3.539322] omap_hsmmc 4809c000.mmc: no pinctrl state for sdr104 mode
> [ 3.545820] omap_hsmmc 4809c000.mmc: no pinctrl state for hs200_1_8v mode
> [ 3.552640] omap_hsmmc 4809c000.mmc: no pinctrl state for ddr50 mode
> [ 3.559040] omap_hsmmc 4809c000.mmc: no pinctrl state for sdr50 mode
> [ 3.565440] omap_hsmmc 4809c000.mmc: no pinctrl state for sdr25 mode
> [ 3.571824] omap_hsmmc 4809c000.mmc: no pinctrl state for sdr12 mode
> [ 3.578226] omap_hsmmc 4809c000.mmc: no pinctrl state for ddr_1_8v mode
> [ 3.623888] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr104 mode
> [ 3.631426] omap_hsmmc 480b4000.mmc: no pinctrl state for hs200_1_8v mode
> [ 3.640307] omap_hsmmc 480b4000.mmc: no pinctrl state for ddr50 mode
> [ 3.646766] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr50 mode
> [ 3.653220] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr25 mode
> [ 3.659657] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr12 mode

> [ 3.723787] omap_voltage_late_init: Voltage driver support not added
> Loading, please wait...
> fsck from util-linux 2.25.2
> fsck: error 2 (No such file or directory) while executing fsck.ext4 for

I need to fix this "error 2" too.. haven't found the systemd patch
with the fix to backport yet..

> /dev/mmcblk0p1
> fsck exited with status code 8

and then a 2nd error..

> [ 10.487702] systemd[1]: Job console-setup.service/start deleted to break
> ordering cycle starting with basic.target/start
> [ 10.794018] systemd-fsck[194]: BOOT: clean, 118616/233856 files,
> 719153/933632 blocks

[Robert Nelson]

Louis:

does:

sudo apt-get install initramfs-tools --reinstall

sudo reboot

fix that?

[Louis McCarthy]

debian@BeagleBoard-X15:~$ sudo apt-get install initramfs-tools --reinstall
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reinstallation of initramfs-tools is not possible, it cannot be downloaded.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Am I missing a config option or repo?

[Robert Nelson]

On Fri, Oct 16, 2015 at 1:42 PM, Louis McCarthy <comp...@gmail.com> wrote:
> debian@BeagleBoard-X15:~$ sudo apt-get install initramfs-tools --reinstall
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Reinstallation of initramfs-tools is not possible, it cannot be downloaded.
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>
> Am I missing a config option or repo?

eh.. forgot, out of the box the apt cache is empty to save space..

sudo apt-get update

sudo apt-get install initramfs-tools --reinstall

[Louis McCarthy]

The USB errors during flash were mouse disconnects and reconnects. They happened very consistently about every 60 seconds.

-----------------------------
Formatting: /dev/mmcblk1 complete
-----------------------------
Copying: /dev/mmcblk0p1 -> /dev/mmcblk1p1
[   36.246521] EXT4-fs (mmcblk1p1): mounted filesystem with ordered data mode. Opts: (null)
rsync: / -> /tmp/rootfs/
rsync: note the % column is useless...
        129.84M  98%    4.02MB/s    0:00:30 (xfr#3695, ir-chk=1004/6539)
[   67.627173] usb 1-1.1.1: USB disconnect, device number 4
[   68.882945] usb 1-1.1.1: new low-speed USB device number 6 using xhci-hcd
[   69.006542] usb 1-1.1.1: New USB device found, idVendor=046d, idProduct=c077
[   69.014447] usb 1-1.1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   69.027541] usb 1-1.1.1: Product: USB Optical Mouse
[   69.038023] usb 1-1.1.1: Manufacturer: Logitech
[   69.048473] usb 1-1.1.1: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes
[   69.069123] input: Logitech USB Optical Mouse as /devices/platform/44000000.ocp/48880000.omap_dwc3_1/48890000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.1/1-1.1.1/1-1.1.1:1.0/0003:046D:C077.0004/input/input3
[   69.092042] hid-generic 0003:046D:C077.0004: input,hidraw0: USB HID v1.11 Mouse [Logitech USB Optical Mouse] on usb-xhci-hcd.1.auto-1.1.1/input0
        226.62M  62%    2.33MB/s    0:01:32 (xfr#11043, ir-chk=1048/15516)
[  129.323171] usb 1-1.1.1: USB disconnect, device number 6
[  130.582966] usb 1-1.1.1: new low-speed USB device number 7 using xhci-hcd
[  130.706546] usb 1-1.1.1: New USB device found, idVendor=046d, idProduct=c077
[  130.716107] usb 1-1.1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  130.726528] usb 1-1.1.1: Product: USB Optical Mouse
[  130.731433] usb 1-1.1.1: Manufacturer: Logitech
[  130.736351] usb 1-1.1.1: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes
[  130.765531] input: Logitech USB Optical Mouse as /devices/platform/44000000.ocp/48880000.omap_dwc3_1/48890000.usb/xhci-hcd.1.auto/usb1/1-1/1-1.1/1-1.1.1/1-1.1.1:1.0/0003:046D:C077.0005/input/input4
[  130.788976] hid-generic 0003:046D:C077.0005: input,hidraw0: USB HID v1.11 Mouse [Logitech USB Optical Mouse] on usb-xhci-hcd.1.auto-1.1.1/input0

It keeps going on...

I swapped USB ports between keyboard and mouse, and the mouse is still the only device to disconnect and reconnect.

I would guess a hid-generic watchdog or something similar is at work here, especially due to the high fs load.

[Louis McCarthy]

I reflashed eMMC with the original image from this morning and no HDMI I2C errors. So something has been changed in the hardware to fix the I2C errors? Could it be a PMIC thing?

[Robert Nelson]

On Fri, Oct 16, 2015 at 3:25 PM, Louis McCarthy <comp...@gmail.com> wrote:
> I reflashed eMMC with the original image from this morning and no HDMI I2C
> errors. So something has been changed in the hardware to fix the I2C errors?
> Could it be a PMIC thing?

Haven't pushed any changes, same image from last sunday. might have
just been a loose connection... hdmi cable hadn't warmed up enough??
;)

[Nishanth Menon]

On 10/16/2015 03:26 PM, Robert Nelson wrote:
> On Fri, Oct 16, 2015 at 3:25 PM, Louis McCarthy <comp...@gmail.com> wrote:
>> I reflashed eMMC with the original image from this morning and no HDMI I2C
>> errors. So something has been changed in the hardware to fix the I2C errors?
>> Could it be a PMIC thing?
>
> Haven't pushed any changes, same image from last sunday. might have
> just been a loose connection... hdmi cable hadn't warmed up enough??
> ;)
>

Hmm... do we have this merged in?
https://patchwork.kernel.org/patch/7264501/

--
Regards,
Nishanth Menon

[Robert Nelson]

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...

[Louis McCarthy]

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. 

[Robert Nelson]

On Fri, Oct 16, 2015 at 3:36 PM, Louis McCarthy <comp...@gmail.com> wrote:
> 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)...

[Louis McCarthy]

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 :)

[Nishanth Menon]

On 10/16/2015 11:47 AM, Nishanth Menon wrote:
> On 10/16/2015 11:39 AM, Louis McCarthy wrote:

>> 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.

Anyways, that kind of explains what was going on.

--
Regards,
Nishanth Menon

[Robert Nelson]

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..

[Nishanth Menon]

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..


--
Regards,
Nishanth Menon

[Gerald Coley]

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

--
You received this message because you are subscribed to the Google Groups "beagleboard-x15" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard-x...@googlegroups.com.
To post to this group, send email to beagleb...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard-x15/56266397.2020107%40ti.com.

For more options, visit https://groups.google.com/d/optout.

--

Gerald

 

ger...@beagleboard.org

http://beagleboard.org/

[Robert Nelson]

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:

http://git.ti.com/gitweb/?p=ti-linux-kernel/ti-linux-kernel.git;a=blob;f=arch/arm/boot/dts/dra7.dtsi;h=79a2c7940a7bd84c2f38f1259d35c68f5c6cc6a0;hb=refs/heads/ti-linux-4.1.y#l953

I wonder, delprop?

(i'm use to adding random nods, not removing them.)

[Nishanth Menon]

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.

--
Regards,
Nishanth Menon

[Nishanth Menon]

On 10/20/2015 11:01 AM, Gerald Coley wrote:
> 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.

http://www.elinux.org/Beagleboard:BeagleBoard-X15 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 :(.

--
Regards,
Nishanth Menon

[Robert Nelson]

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..)

[Robert Nelson]

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...

[Kishon Vijay Abraham I]

Hi,

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

>
> Regards,
>

[Gerald Coley]

ES2.0 will not be put on these boards. We will make a layout change to fix the other issue.. 

Gerald

>

--
You received this message because you are subscribed to the Google Groups "beagleboard-x15" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard-x...@googlegroups.com.
To post to this group, send email to beagleb...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard-x15/56266A23.3070905%40ti.com.

For more options, visit https://groups.google.com/d/optout.

[mike anderson]

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.

On Thursday, October 15, 2015 at 12:56:47 PM UTC-4, robert nelson wrote:

Hey Everyone,

It's getting close to that time..  Anyone with a Beta X15, please test
this flasher asap:

wget https://rcn-ee.com/rootfs/bb.org/testing/2015-10-11/lxqt-4gb/bbx15-eMMC-flasher-debian-8.2-lxqt-4gb-armhf-2015-10-11-4gb.img.xz
sha256sum: 431d933678c03c86c7d33a3e6508f3d68045cf3cc13a7a325d775db4cb30cde0

Either we will go with that image as-is or we get one shot at changes
for the "NEXT" weekly build on sunday Oct 18th. ;)

Reminder, this is just the 'initial' image flashed to the eMMC..  I'm
planning weekly builds..

and we can always update packages via apt..

PS... if you don't currently have an x15, you can also use the
omap5_uevm: (just note it's using a mainline u-boot)

wget https://rcn-ee.com/rootfs/bb.org/testing/2015-10-11/lxqt-4gb/omap5-uevm-debian-8.2-lxqt-4gb-armhf-2015-10-11-4gb.img.xz
sha256sum: 45a288e7d703dbb6a93b6a8e57a6fcc86a84dd23ceb8470a750921af3b7080ed

but the setup is similar..

[Nishanth Menon]

Digging up from an old discussion:

I am booting off the SD card :).

Here is something slightly different experience.
I bought http://www.amazon.com/gp/product/B00PFLZV2G 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.


--
Regards,
Nishanth Menon