After /opt/scripts update usb network is not working

[Grzegorz G]

BBBlack, image: debian-7.11-lxde

how:

cd /opt/scripts

git pull

After reboot there are two usb network interfaces (new is usb1). Both ip addresses are not reachable from windows (no route entry in route print), usb mass storage is still working.

Some logs:

[   11.737870] usb0: HOST MAC 04:a3:16:af:a1:6d

[   11.737981] usb0: MAC 04:a3:16:af:a1:6e

[   11.738706] usb1: HOST MAC 1c:ba:8c:a2:ed:72

[   11.738750] usb1: MAC 1c:ba:8c:a2:ed:73

[   11.775559] cpsw 4a100000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx

[   11.775631] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

[   12.038548] IPv6: ADDRCONF(NETDEV_UP): usb0: link is not ready

[   12.117325] IPv6: ADDRCONF(NETDEV_UP): usb1: link is not ready

[   12.117431] configfs-gadget gadget: high-speed config #1: c

[   12.117881] IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready

When I revert scripts to old version:

root@beaglebone:/opt/scripts# git reflog

a5d5f43 HEAD@{0}: pull: Fast-forward

ce39028 HEAD@{1}: pull: Fast-forward

b71b6d7 HEAD@{2}: clone: from https://github.com/RobertCNelson/boot-scripts

root@beaglebone:/opt/scripts# git reset --hard ce39028

then reboot abd usb0 192.168.7.2 is working again.

Best regards

Grzegorz

[Robert Nelson]

What kernel version? (uname -r) The dual usb's should only occur
after 4.4.x, since that's when we patched the rndis driver to support
Microsoft's built-in rndis driver (without a signed driver
installer)... The 2nd interface (usb-cdc) is for mac users..

https://github.com/RobertCNelson/boot-scripts/blob/master/boot/am335x_evm.sh#L652-L668

Regards,

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

[Grzegorz G]

Linux beaglebone 4.4.39-bone15 #1 Sat Dec 17 16:14:57 UTC 2016 armv7l GNU/Linux

Driver on Windows:

Linux Developer Community

2012-04-27

6.0.6000.16384

signed by BeagleBoard.org Foundation

should I install other BONE_D64.exe file?

[Robert Nelson]

On Mon, Nov 6, 2017 at 10:18 AM, Grzegorz G <grzeg...@gmail.com> wrote:
> Linux beaglebone 4.4.39-bone15 #1 Sat Dec 17 16:14:57 UTC 2016 armv7l
> GNU/Linux

Crap, looks like i completely forgot to back port this patch from our
v4.4.x-ti tree to v4.4.x-bone

https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/ti-linux-4.4.y/patches/drivers/gadget/0001-Change-USB-class-for-RNDIS.patch

(starting re-build now)

> Driver on Windows:
> Linux Developer Community
> 2012-04-27
> 6.0.6000.16384
> signed by BeagleBoard.org Foundation
>
> should I install other BONE_D64.exe file?

You can try, but it's probably expired, Micro$oft loves milking money
from developers..

[Robert Nelson]

On Mon, Nov 6, 2017 at 10:41 AM, Robert Nelson <robert...@gmail.com> wrote:
> On Mon, Nov 6, 2017 at 10:18 AM, Grzegorz G <grzeg...@gmail.com> wrote:
>> Linux beaglebone 4.4.39-bone15 #1 Sat Dec 17 16:14:57 UTC 2016 armv7l
>> GNU/Linux
>
> Crap, looks like i completely forgot to back port this patch from our
> v4.4.x-ti tree to v4.4.x-bone
>
> https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/ti-linux-4.4.y/patches/drivers/gadget/0001-Change-USB-class-for-RNDIS.patch
>
> (starting re-build now)

and pushed as: "4.4.96-bone20"

[Grzegorz G]

Thank you very much :)

Now latest is 4.4.71-bone17 (via ./update_kernel.sh --bone-kernel --lts-4_4)

Will 4.4.96-bone20 be available tomorrow or I need to change update parameters?

[Robert Nelson]

On Mon, Nov 6, 2017 at 11:34 AM, Grzegorz G <grzeg...@gmail.com> wrote:
> Thank you very much :)
> Now latest is 4.4.71-bone17 (via ./update_kernel.sh --bone-kernel --lts-4_4)

Ouch, yeah i stopped doing wheezy (7.x) builds when stretch (9.x) hit stable..

> Will 4.4.96-bone20 be available tomorrow or I need to change update
> parameters?

voodoo@hades:~$ git clone -b am33x-v4.4
https://github.com/RobertCNelson/bb-kernel/ --depth=1
voodoo@hades:~$ cd bb-kernel/
voodoo@hades:~/bb-kernel$ ./build_deb.sh

Then copy the ./deploy/linux-image*.deb to your beagle and run:

sudo dpkg -i linux-image*.deb
sudo reboot

[Grzegorz G]

I did it. It took 1.5h on my debian virtual machine.

Results:

- usb network i not available (still no route in route print),

+ serial over usb is working (it was not available before),

- in device management there is working com port "USB serial  device COM8" (mentioned above) and there is visible "Gadget serial COM7" defined not exsisted device,

- big problems with RTC over I2C - almost not readable (before kernel upgrade, there was not as many problems with RTC over i2c),

- old problem with ethernet is back

[  158.682964] rtc-ds1307 1-0068: read error -121

[  160.284608] rtc-ds1307 1-0068: read error -121

[  201.901327] cpsw 4a100000.ethernet eth0: Link is Down

[  402.656641] rtc-ds1307 1-0068: read error -110

[  404.291265] rtc-ds1307 1-0068: read error -121

[  407.762364] rtc-ds1307 1-0068: read error -121

[  408.601046] rtc-ds1307 1-0068: read error -121

[  411.371277] omap_i2c 4802a000.i2c: controller timed out

[  411.376635] rtc-ds1307 1-0068: read error -110

[  413.062533] rtc-ds1307 1-0068: read error -121

[  413.983043] rtc-ds1307 1-0068: read error -121

I didn't make any changes to kernel configuration (I did save, then exit).

PS. My OS is Windows 10 Fall Creators Update.

Did I miss something while compiling kernel?

[Grzegorz G]

Ethernet is working now... I don't know why before link goes down. I can't repeat this behaviour.

I have udev rule:

SUBSYSTEM=="rtc", KERNEL=="rtc1", SYMLINK+="rtc", OPTIONS+="link_priority=10", TAG+="systemd"

when it is commented rtc problem remain.

[Robert Nelson]

On Wed, Nov 8, 2017 at 12:18 PM, Grzegorz G <grzeg...@gmail.com> wrote:
> Ethernet is working now... I don't know why before link goes down. I can't
> repeat this behaviour.
>
> I have udev rule:
> SUBSYSTEM=="rtc", KERNEL=="rtc1", SYMLINK+="rtc",
> OPTIONS+="link_priority=10", TAG+="systemd"
>
> when it is commented rtc problem remain.

this udev rule in un-reiable.. i fixed this in v4.4.x via, u-boot
overlays and a rtc cape overlay with the "alisas":

https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-RTC-01-00A0.dts#L32-L40

[Grzegorz G]

Ok, I've updated and installed overlays again. No more errors in dmesg while read/write to RTC1, only init messages:

[    4.293079] rtc-ds1307 1-0068: SET TIME!

[    4.295910] rtc-ds1307 1-0068: rtc core: registered mcp7940x as rtc1

[    4.295938] rtc-ds1307 1-0068: 64 bytes nvram

but RTC1 is not accessible:

root@beaglebone:/lib/firmware# date

Thu Nov  9 10:34:42 CET 2017

root@beaglebone:/lib/firmware# hwclock --rtc=/dev/rtc1

hwclock: Timed out waiting for time change.

hwclock: The Hardware Clock registers contain values that are either invalid (e.g. 50th day of month) or beyond the range we can handle (e.g. Year 2095).

root@beaglebone:/lib/firmware# hwclock --rtc=/dev/rtc1 --systohc

hwclock: Timed out waiting for time change.

Can't read or set valid time.

my boot/uEnv.txt file contains:

uname_r=4.4.96-bone20

cmdline=coherent_pool=1M quiet init=/lib/systemd/systemd

dtb=am335x-boneblack-emmc-overlay.dtb

cape_enable=bone_capemgr.enable_partno=BB-RTC-01,BB-UART1,BB-UART2,BB-UART4,BB-UART5

When old kernel 4.4.39-bone15 is used rtc is registered as below and is working fine:

[    1.186751] rtc-ds1307 1-0068: SET TIME!

[    1.189263] rtc-ds1307 1-0068: rtc core: registered ds1338 as rtc1

[    1.189293] rtc-ds1307 1-0068: 56 bytes nvram

but after update and install overlays I got same error:

hwclock: The Hardware Clock registers contain values that are either invalid (e.g. 50th day of month) or beyond the range we can handle (e.g. Year 2095).

So, I've change file src/arm/BB-RTC-01-00A0.dts section:

mcp7940x@68 {
	compatible = "microchip,mcp7940x";
	reg = <0x68>;
	};

to compatible value from old version:

compatible = "maxim,ds1338";

After this and update/install/reboot, rtc1 is working again! :)

Next step is to check if it will be working with newest kernel aswell. It works!

The question is, why compatible "maxim,ds1338" was changed to "microchip,mcp7940x"?

Why aliases (rtc1 = "/ocp/rtc@44e3e000") are not equal to kernel values: omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc as rtc0? But this maybe doesn't matter.