[BBB] Reboot/halt problem

This forum is for supported devices using an ARMv7 Texas Instruments (TI) SoC.

Re: [BBB] Reboot/halt problem

Postby kilian » Thu Aug 17, 2017 1:17 pm

The last line is the relevant one, the others are unrelated. The one of the musb-dsps driver is not included in your journal query because it is not flagged as an error. Should show up in dmesg, though (if you are interested).

Anyway, if you are not using the corresponding USB port, you should not be experiencing any issues, for now.
kilian
 
Posts: 8
Joined: Tue Aug 15, 2017 1:53 pm

Re: [BBB] Reboot/halt problem

Postby summers » Thu Aug 17, 2017 5:47 pm

Doah - I used the usb interface to bring up a ethernet gadget. So I had both power and Ethernet across the single connector.

Now that doesn't work, which is a hassle.

So one problem solved, but another problem made, so it isn't a solution ...
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: [BBB] Reboot/halt problem

Postby kilian » Thu Aug 17, 2017 6:47 pm

Do I read that right, you have tried it out? Meaning, it used to work before and now with the latest kernel package (4.12.7-2) it doesn't?

If so, you could just reverse the following commit and re-compile your device-tree:
https://github.com/torvalds/linux/commit/d680414d0f421563a9746c29d82e6794a604cf0c.

It should work with the latest kernel package version as well as with earlier ones (hopefully all of 4.11 and 4.12).
In my setup, the corresponding USB controller is available again, but as I am not using that port, I cannot say if it really works.
Nonetheless, I think you should give it a try. I have high hopes... :)
kilian
 
Posts: 8
Joined: Tue Aug 15, 2017 1:53 pm

Re: [BBB] Reboot/halt problem

Postby summers » Sat Aug 19, 2017 6:15 am

OOps sorry should have been clearer.

On 4.12.7 and 4.12.8 loading the g_ether kernel module gives the error:
$this->bbcode_second_pass_code('', 'udc-core: couldn't find an available UDC - added [g_ether] to list of pending drivers')

Whereas before it would bring up a usb ethernet device on the power/usb cable. So doing an "ip a" would show the usb0 device. Now I just have eth0.

I'll look at the device tree suggestion. Have to say I haven't looked at device trees for few years, well since they became mandatory for linux arm, so it will take a bit to remind myself of the commands.
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: [BBB] Reboot/halt problem

Postby summers » Sat Aug 19, 2017 9:36 am

OK here was what I did. To start with (e.g. linux-4.12.8-1, and the standard device tree)

$this->bbcode_second_pass_code('', 'ls /proc/device-tree/ocp/usb@47400000/usb@47401000
compatible interrupt-names mentor,multipoint name reg-names
dma-names interrupts mentor,num-eps phandle status
dmas interrupts-extended mentor,power phys
dr_mode linux,phandle mentor,ram-bits reg')

Now want to remove
$this->bbcode_second_pass_code('', '+ interrupts-extended = <&intc 18 &tps 0>;
+ interrupt-names = "mc", "vbus";')

So take the /boot/dtbs/am335x-boneblack.dtb

and change:
$this->bbcode_second_pass_code('', 'usb@47401000 {
...
interrupt-names = "mc", "vbus";
...
interrupts-extended = <0x1 0x12 0x3e 0x0>;
')

Remove those to lines, compile back to a dtb file, and replace /boot/dtbs/am335x-boneblack.dtb

Reboot and:
$this->bbcode_second_pass_code('', 'ls /proc/device-tree/ocp/usb@47400000/usb@47401000
compatible interrupts mentor,power phys
dma-names linux,phandle mentor,ram-bits reg
dmas mentor,multipoint name reg-names
dr_mode mentor,num-eps phandle status
')
So have remove the offending parts.

However still no usb0, e.g.

$this->bbcode_second_pass_code('', 'udc-core: couldn't find an available UDC - added [g_ether] to list of pending drivers
')

$this->bbcode_second_pass_code('', 'lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
')

So making that change in the device tree didn't help.

Think we are back to not knowing what is going wrong.

And looks like the error that is stopping usb0 coming up is:
$this->bbcode_second_pass_code('', '[ 2.807857] musb-dsps 47401400.usb: failed to get irq.
[ 2.813090] musb-dsps: probe of 47401400.usb failed with error -22
[ 2.833280] musb-hdrc musb-hdrc.1: Failed to request rx1.
')
Adding the interupt back into the device tree and error becomes:
$this->bbcode_second_pass_code('', '[ 3.597399] musb-dsps: probe of 47401400.usb failed with error -16')
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: [BBB] Reboot/halt problem

Postby kilian » Sat Aug 19, 2017 11:29 am

No, no, no, wrong file. :)

Please, look again: https://github.com/torvalds/linux/commit/d680414d0f421563a9746c29d82e6794a604cf0c
The file is arch/arm/boot/dts/am335x-bone-common.dtsi.
Your patch simply killed the whole usb0. That is a completely different part of the tree and different interrupts.

Furthermore, removing the $this->bbcode_second_pass_code('', '
+ interrupts-extended = <&intc 18 &tps 0>;
+ interrupt-names = "mc", "vbus";') lines doesn't kill all usb0 interrupts, just the tps 0 one. Interrupt intc 18 is still connected via inheritance.

I just tested the g_ether module in 4.12.7-2-ARCH. This is the dmesg result of a modprobe g_ether:
$this->bbcode_second_pass_code('', '
using random self ethernet address
using random host ethernet address
usb0: HOST MAC 5e:97:26:af:15:f3
usb0: MAC 4e:4e:4e:1f:83:b4
using random self ethernet address
using random host ethernet address
g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
g_ether gadget: g_ether ready')
Also:$this->bbcode_second_pass_code('', '
$ ip a
[...]
4: usb0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 4e:4e:4e:1f:83:b4 brd ff:ff:ff:ff:ff:ff')Looks fine to me.

BTW, when usb0 is used in this mode, it doesn't show up in lsusb, because it is not a host controller.
kilian
 
Posts: 8
Joined: Tue Aug 15, 2017 1:53 pm

Re: [BBB] Reboot/halt problem

Postby summers » Sat Aug 19, 2017 12:18 pm

To expand, I started from the dtb file for am335x-boneblack.dtb, I converted to a dts file.

Now the dts file had the $this->bbcode_second_pass_code('', 'interrupt-names = "mc", "vbus";') in the usb@47401000 section. The alias at the top of the dts file gives: $this->bbcode_second_pass_code('', 'usb0 = "/ocp/usb@47400000/usb@47401000";') so that is the correct section.

Now in the usb@47401000 section the interrupts-extended is written as $this->bbcode_second_pass_code('', 'interrupts-extended = <0x1 0x12 0x3e 0x0>;') as I expect the &intc and &tps have been expanded.

Those where the only two bits removed, the rest of usb@47401000 was left intact, as the listing of the device tree shows. Hence the device tree still describes usb0.

My reason for starting from the dtb file, is that is what is booted from, converting to a dts file and it *should* already have all includes in it. e.g. I still have interrupt = <0x12> defined in the usb section ...

I suspect the question is why I failed to get the irq, and what does error -22 mean; e.g. why do I get that error and not you. That I got the error shows that the kernel tried to bring up usb0, but that it failed.

So I think you are saying I would get a different dtb if I compiled from source, vs starting from the distributed dtb file, and editing that. I don't understand that ...
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: [BBB] Reboot/halt problem

Postby kilian » Sat Aug 19, 2017 1:16 pm

$this->bbcode_second_pass_quote('summers', 'T')o expand, I started from the dtb file for am335x-boneblack.dtb, I converted to a dts file.

Ah, OK, now I see. I just went to the kernel source, reverse-applied the commit, and recompiled all dtbs.

I just de-compiled the new and the old dtb and got the following diff in the usb@47401000 section (disregarding the changes in handle references):
$this->bbcode_second_pass_code('', '@@ -1814,18 +1615,15 @@
reg = <0x47401400 0x400 0x47401000 0x200>;
reg-names = "mc", "control";
interrupts = <0x12>;
- interrupt-names = "mc", "vbus";
+ interrupt-names = "mc";
dr_mode = "peripheral";
mentor,multipoint = <0x1>;
mentor,num-eps = <0x10>;
mentor,ram-bits = <0xc>;
mentor,power = <0x1f4>;
- interrupts-extended = <0x1 0x12 0x3e 0x0>;')So you could try again and retain the "mc" in the interrupt-names.

$this->bbcode_second_pass_quote('summers', 'M')y reason for starting from the dtb file, is that is what is booted from, converting to a dts file and it *should* already have all includes in it.
That is a fair approach. I used the kernel source because I really wanted to reverse-apply the commit.

$this->bbcode_second_pass_quote('summers', 'I') suspect the question is why I failed to get the irq, and what does error -22 mean; e.g. why do I get that error and not you. That I got the error shows that the kernel tried to bring up usb0, but that it failed.
According to the list of Linux error codes:
$this->bbcode_second_pass_code('', '16 EBUSY Device or resource busy
22 EINVAL Invalid argument')We got a -16 before on the second device probe, because the IRQ had already been claimed without interrupt sharing. I guess your removal of the interrupt name "mc" leads to the USB driver not being able to reference the IRQ number by name, so the registering function is called with an invalid IRQ number.

$this->bbcode_second_pass_quote('summers', '
')So I think you are saying I would get a different dtb if I compiled from source, vs starting from the distributed dtb file, and editing that. I don't understand that ...
Well, my diff shows lots of differences in other parts, even entire devices missing. I certainly didn't expect that. Seems some extensive patching has been done along the way.
Nonetheless, your approach should be working. I suspect that you simply removed too much from your .dts as a result of not factoring in the inheritance in the tree.
I will try to replicate your approach and see how that works out.

[edit]
Success! Tried with the dtb of the 4.12.8-1 package. De-compiled to dts, removed the "vbus" from interrupt-names and the entire interrupts-extended line, re-compiled to dtb, rebooted. Works.
kilian
 
Posts: 8
Joined: Tue Aug 15, 2017 1:53 pm
Top

Re: [BBB] Reboot/halt problem

Postby summers » Sat Aug 19, 2017 1:49 pm

Bingo!

Yes needed $this->bbcode_second_pass_code('', 'interrupt-names = "mc";')

What confused me was that the commit that made the change didn't remove the above - it just added the whole line with both "mc" and "vbus".

Anyway now works, and yes I also noted a whole lot of cape mgr problems in the dtb blob.

Are you happy asking to get the patch reversed in the kernel, copying in the relevant people - as you understand the problem with the shared interrupt.

Thanks for your work on this.
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: [BBB] Reboot/halt problem

Postby kilian » Sat Aug 19, 2017 2:48 pm

$this->bbcode_second_pass_quote('summers', 'W')hat confused me was that the commit that made the change didn't remove the above - it just added the whole line with both "mc" and "vbus".
That seems to be a result of inheritance in the tree combined with how specifying multiple interrupt parents works.
Binding of irq 18 (0x12) of the main interrupt controller "intc" is inherited from the generic usb0 specification (in the file am33xx.dtsi), but in order for "interrupts-extended" to work, the inherited parent has to be specified again. In other words, the "mc" binding had always been there (in the source).

$this->bbcode_second_pass_quote('summers', 'A')re you happy asking to get the patch reversed in the kernel, copying in the relevant people - as you understand the problem with the shared interrupt.
I might. Obviously, the proper way would be to fix the kernel to allow for real interrupt sharing of both drivers. Unfortunately, I do not yet know enough about cascaded interrupt handling and the interaction of tps65217-irq and tps65217-charger to be able to estimate how much of an effort that would be.
Seeing that the boards of the BeagleBoard family are the only ones using this mechanism for now, a complete reversal of the commit might be reasonable, but I don't know if the kernel people would go for that.
kilian
 
Posts: 8
Joined: Tue Aug 15, 2017 1:53 pm
Top

PreviousNext

Return to Texas Instruments (TI)

Who is online

Users browsing this forum: No registered users and 6 guests