NanoPi Neo 2 plus: second USB dead?

[gdm85]

Hi there!

 

I have been playing around with my NanoPi Neo 2 plus, I managed to get initramfs working thanks to the kernel config of armbian.

 

I have just noticed a problem: only the first of the two USBs works. The second is completely dead.

 

Big disclaimer: I am using an HTC PSU that provides only 1A, not the 2A that should be fed, although I do not know if this could be the cause of the issue.

 

Aside from this problem, I cannot see other issues. Wifi is working and I disabled bluetooth.

 

lsusb without anything plugged in to USB:

Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

 

[Superkoning]

In 

 someone says "the USB socket closer to the edge (USBN1) is not visible, even with overlays" ... so ... same same?

 

[Igor]

Most likely it's not enabled/powered on. Nothing unusual for a new board. Somebody needs to waste time to study documentation, create a patch, recompile and test. From one hour to few days ... when the issue comes to executing priority.

 

Those boards just started to appear.  We have some preproduction sample which looks completely different ...  so its fairly pointless to deal with this problem right now.

[gdm85]

1 hour ago, Superkoning said:

In 

 someone says "the USB socket closer to the edge (USBN1) is not visible, even with overlays" ... so ... same same?

 

Oh, I had read that thread but I didn't understand what "visible" meant in that context. So yeah, same issue.

I am going to test with their provided image as it's not clear to me whether he's saying that the USB is working with their Ubuntu image or not.

 

40 minutes ago, Igor said:

Most likely it's not enabled/powered on. Nothing unusual for a new board. Somebody needs to waste time to study documentation, create a patch, recompile and test. From one hour to few days ... when the issue comes to executing priority.

 

Those boards just started to appear.  We have some preproduction sample which looks completely different ...  so its fairly pointless to deal with this problem right now.

I am familiar with the process, I understand what you mean. If it's a software issue then I will not return it, going to verify with their provided image. I posted here to see if I was the only one with the issue, I understand now it's not the case and anyway you have a different sample.

 

I have contacted FriendlyARM ("friendly", lol) via email last week about this, no reply yet.

 

By the way, I am using their kernel (https://github.com/friendlyarm/linux.git at friendlyarm/sunxi-4.11.y) with armbian's config, I was expecting this to work out of the box. I didn't test bluetooth but wifi is working correctly (they never shipped the antenna though, I used one of mine).

[Igor]

1 minute ago, gdm85 said:

If it's a software issue then I will not return it, going to verify with their provided image.

The kernel which they use is a combination between mainline and some private development branch. It's better than stock Allwinner (buggy 3.10.) which is another alternative. Their image is still more or less a static product and it doesn't look they will provide an update. It's not necessarily that everything already works. I doubt. 

 

6 minutes ago, gdm85 said:

I have contacted FriendlyARM ("friendly", lol) via email last week about this, no reply yet.

 

Even boards are dirt cheap, support remains expensive. It requires a highend techy person to answer mostly repeated emails whole day long. What a waste

[gdm85]

20 minutes ago, Igor said:

The kernel which they use is a combination between mainline and some private development branch. It's better than stock Allwinner (buggy 3.10.) which is another alternative. Their image is still more or less a static product and it doesn't look they will provide an update. It's not necessarily that everything already works. I doubt. 

 

 

Even boards are dirt cheap, support remains expensive. It requires a highend techy person to answer mostly repeated emails whole day long. What a waste

eheh..but success is making a good product (so you need less support) and then covering up with some decent support  I understand it's very cheap so you get what you pay.. I will check out later that ubuntu image (I do not have the device at hand), but yeah I also expect it to not be working since they probably used the same kernel tree I used

[gdm85]

An update: the official provided Ubuntu Xenial ROM (for reference, in this directory) has all working USB. So now I will try to figure out if it's a kernel config issue or rather dtb/more low-level (that probably would block me, for example if some patches to the *HCI that enable that USB are unavailable).

 

Regarding their support: I have to say they were very nice via PayPal (although never replied to normal emails). They offered me a refund if I ship it back, but since hardware is fine I will not proceed (without mentioning that shipping cost alone would make it doubtfully convenient)

Edited September 20, 2017 by gdm85
added link to official ROMs

[gdm85]

I have tested their kernel with their config and the USB works fine, so it is definitely a kernel .config issue that could be fixed in the armbian .config; I do not know (yet) precisely what, but I guess it just takes a comparison with their official .config and some tests to find out.

 

I am attaching theirs here for reference (this is the one with working USB, vanilla/untouched from their Xenial core image).

config-4.11.2-h5

[tkaiser]

5 minutes ago, gdm85 said:

could be fixed in the armbian

 

On 19.9.2017 at 8:00 AM, Igor said:

Somebody needs to waste time to study documentation, create a patch, recompile and test. From one hour to few days ... when the issue comes to executing priority.

 

@gdm85 what about doing this? Checking device tree contents (nodes below /proc/device-tree/), checking how this stuff works (for NanoPi NEO Plus 2 we use upstream settings and none of us has the right hardware since the dev samples sent out months ago have nothing to do with production hardware now), checking out how the build system works and where patches have to be applied and then submitting the necessary patches. Only alternative: waiting.

 

All H5 boards share the same kernel config so it's pointless looking into since the differences are DT.

[gdm85]

2 hours ago, tkaiser said:

 

 

@gdm85 what about doing this? Checking device tree contents (nodes below /proc/device-tree/), checking how this stuff works (for NanoPi NEO Plus 2 we use upstream settings and none of us has the right hardware since the dev samples sent out months ago have nothing to do with production hardware now), checking out how the build system works and where patches have to be applied and then submitting the necessary patches. Only alternative: waiting.

 

All H5 boards share the same kernel config so it's pointless looking into since the differences are DT.

You mean that differences are in the device tree but we can compile the dtb from the kernel repo sources right? Or you're saying that the .dtb file that's shipped in their image is different than the one built with the kernel? (I didn't overwrite that, on purpose, might do a test later).

 

If the .dts file is there and corresponds to the .dtb, then we can just copy that?

[tkaiser]

On 16.9.2017 at 9:34 PM, gdm85 said:

I have just noticed a problem: only the first of the two USBs works. The second is completely dead.

 

Ah, I remember. What you refer to as the 2nd USB port is usb0/OTG exposed as a type A receptacle on the Plus 2. So most probably not only a matter of device tree but also patches to turn OTG port into real host mode (Allwinner H3 and H5 can attach usb0 to either an own OTG controller or to a 4th OHCI/EHCI controller pair)

[gdm85]

@tkaiser this is the DTS of the exact branch I used (albeit I didn't replace the .dtb yet): https://github.com/friendlyarm/linux/blob/sunxi-4.11.y/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo-plus2.dts

[tkaiser]

7 minutes ago, gdm85 said:

If the .dts file is there and corresponds to the .dtb, then we can just copy that?

 

No, DT and kernel version have to match. FriendlyELEC obviously chose to remain on 4.11.2 (at least for now -- maybe they just started with 4.11 since Icenowy's kernel branch was at this version back then and will switch over to 4.14 once released... 4.14 is said to be the next LTS -- long term support -- kernel release). Armbian currently switched to 4.13. All this stuff is a moving target and you'll (we'll) waste huge amounts of efforts and time switching between versions (updating).

 

As already said: No one from us has the production board revision and such minor problems are low priority anyway. I fear if you can't fix it yourself (without extensive guidance) then all you can do is to wait. In the meantime there are 2 more USB ports on the GPIO header to be used.

 

[gdm85]

2 minutes ago, tkaiser said:

 

No, DT and kernel version have to match. FriendlyELEC obviously chose to remain on 4.11.2 (at least for now -- maybe they just started with 4.11 since Icenowy's kernel branch was at this version back then and will switch over to 4.14 once released... 4.14 is said to be the next LTS -- long term support -- kernel release). Armbian currently switched to 4.13. All this stuff is a moving target and you'll (we'll) waste huge amounts of efforts and time switching between versions (updating).

 

As already said: No one from us has the production board revision and such minor problems are low priority anyway. I fear if you can't fix it yourself (without extensive guidance) then all you can do is to wait. In the meantime there are 2 more USB ports on the GPIO header to be used.

 

Okay, I was not aware of the different kernel version (and that it takes in such a breaking change already), thanks for the explanation. I was assuming most of FriendlyELEC's patches were already in the tree (and/or upstream) you're using.

 

So eventually someone has to fix the DTS/kernel for it so that it stays mainline on latest (at least LTS) tree. The way I see this process: cherry-picking the FriendlyELEC patches on top of 4.11, right? That's something I can do easily. But changing voltages/reading datasheets for them, not really my cup of tea, and also afraid of damaging components (I know I could be running wrong voltage for long without side effects, but I don't know enough to feel safe on that type of tweaking)

[tkaiser]

16 minutes ago, gdm85 said:

The way I see this process: cherry-picking the FriendlyELEC patches on top of 4.11, right?

 

No, since they 'do their own thing'. It would be different if FriendlyELEC would try to send their work upstream but they just chose a mainline kernel version suitable for their needs, a branch from Icenowy with most patches they needed included, and then considered this being their private thing. They even patch stuff broken to be compatible to Allwinner's smelly legacy kernel (see this as an example -- I gave up immediately after).

 

This 'we do our own thing' attitude has other downsides too (eg. their own board detection uses a different way to configure DRAM clockspeeds and the values in u-boot config are unused/wrong. Now these wrong values are submitted by open source community members upstream and in the end we as Armbians strangely being the only ones around caring about such details have to add patches for this to our build system later).

 

In other words: trying to keep up with this is a huge waste of time and it will be done when it's done

[gdm85]

@tkaiser I have used their github kernel fork and armbian's config and the 2nd USB does not work. With their config (exact same source code) instead the USB works.

 

That's why I said, let's look at the kernel .config..but now I am a bit confused, I admit

[gdm85]

It can probably be explained by the different kernel; I understand one shouldn't try to fix their kernel (it's a dead end) and rather work upstream for the benefit of community..

[Igor]

The diff is in device tree (hardware configuration) not a kernel config. As already said by Thomas.

 

+ some changes in kernel code of course. 4.11.+ minor changes vs 4.13 which we use.

[tkaiser]

1 hour ago, gdm85 said:

It can probably be explained by the different kernel; I understand one shouldn't try to fix their kernel (it's a dead end) and rather work upstream for the benefit of community..

 

These are the DT bits they use: https://github.com/friendlyarm/linux/blob/sunxi-4.11.y/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo-plus2.dts#L412-L420

 

And then it needs the relevant code to let the magic work (Jared from FreeBSD/NetBSD discovered this and shared his wisdom with linux-sunxi kernel folks -- of course this needs some code also and as already said: DT bits have to match kernel version and the necessary patches must also be present -- no idea whether that happened already upstream for H5 or not)

[gdm85]

To summarize the previous posts/status of 2nd USB support for FriendlyElec NanoPi-NEO-Plus2: the driver was not properly upstreamed into mainline kernel although all the pieces to do that were available (in particular they had it fixed in FreeBSD). A combination of DTS + driver changes was needed.

 

Fast forward to today: I am fetching Linus' upstream and will try to build this again. Do you guys know if anything changed regarding this specific board and the USB support?

[@lex]

6 hours ago, gdm85 said:

Do you guys know if anything changed regarding this specific board and the USB support?

 Do you want the OTG ( i think you are referring to microUSB ) to act as a Host? Can you describe your use case? I have read @Igor explaining somewhere on how to use the OTG as peripheral. 

Would not this suffice? https://github.com/friendlyarm/linux/blob/sunxi-4.11.y/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo-plus2.dts#L413

I usually disable OTG, OTG enabled eats a lot of CPU and increases CPU temp.

 

Sorry if I misunderstood, I am now very curious about this 2nd USB support.

[gdm85]

1 hour ago, @lex said:

 Do you want the OTG ( i think you are referring to microUSB ) to act as a Host? Can you describe your use case? I have read @Igor explaining somewhere on how to use the OTG as peripheral. 

Would not this suffice? https://github.com/friendlyarm/linux/blob/sunxi-4.11.y/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo-plus2.dts#L413

I usually disable OTG, OTG enabled eats a lot of CPU and increases CPU temp.

 

Sorry if I misunderstood, I am now very curious about this 2nd USB support.

 

it's very simple. The board has two normal USB ports. Only one works when using mainline kernel (Linus' tree for example). Look at the image below of the actual product:

 

Only the USB port closest to the ethernet works. The other one does not. I do not know if it is in OTG mode, any easy way to check?

 

Although not interesting/useful for armbian, I was asking here how it is possible that depending on the .config used this port works or not when using FriendlyElec's kernel fork. (That was my last "progress" back then).

 

I would like to use that 2nd port as a regular one.

[Igor]

19 minutes ago, gdm85 said:

I would like to use that 2nd port as a regular one.

If FA uses reference design and I believe they do, then you download latest armbian, go to armbian-config -> hardware and enable all USB ports. If this doesn't work, then there is could be something wrong with the board ... which I actually don't have and can't check. (I do have some engineering sample of this board but it is completely different)

 

[gdm85]

5 minutes ago, Igor said:

If FA uses reference design and I believe they do, then you download latest armbian, go to armbian-config -> hardware and enable all USB ports. If this doesn't work, then there is could be something wrong with the board ... which I actually don't have and can't check. (I do have some engineering sample of this board but it is completely different)

 

Wouldn't hardware malfunction be excluded by the fact that I can get it working with a certain combination of kernel + .config? I can give a try to the armbian-config approach, but I would still have to walk my way back to a working kernel + .config combination as that's what I need usually.

[@lex]

Just now, Igor said:

If this doesn't work, then there is something wrong with the board

 

@gdm85

 

Chances are you have a faulty USB socket.

 

 

Both USB work with low-speed devices (that is why I asked your use case), if you attach a high-speed device, kernel (depends on which version) may or not detect your device.

Works with 4.11.y, 4.14.y, 4.15.y with high-speed on some devices.

 

See below:

 

[  370.698551] usb 2-1: new low-speed USB device number 2 using ohci-platform
[  370.945496] input: USB USB Keykoard as /devices/platform/soc/1c1a400.usb/usb2/2-1/2-1:1.0/0003:1C4F:0002.0001/input/input2
[  371.006119] hid-generic 0003:1C4F:0002.0001: input,hidraw0: USB HID v1.10 Keyboard [USB USB Keykoard] on usb-1c1a400.usb-1/input0
[  371.020708] input: USB USB Keykoard as /devices/platform/soc/1c1a400.usb/usb2/2-1/2-1:1.1/0003:1C4F:0002.0002/input/input3
[  371.080155] hid-generic 0003:1C4F:0002.0002: input,hidraw1: USB HID v1.10 Device [USB USB Keykoard] on usb-1c1a400.usb-1/input1
[  431.591036] usb 2-1: USB disconnect, device number 2
[  435.232021] usb 8-1: new low-speed USB device number 2 using ohci-platform
[  435.477981] input: USB USB Keykoard as /devices/platform/soc/1c1d400.usb/usb8/8-1/8-1:1.0/0003:1C4F:0002.0003/input/input4
[  435.539589] hid-generic 0003:1C4F:0002.0003: input,hidraw0: USB HID v1.10 Keyboard [USB USB Keykoard] on usb-1c1d400.usb-1/input0
[  435.554152] input: USB USB Keykoard as /devices/platform/soc/1c1d400.usb/usb8/8-1/8-1:1.1/0003:1C4F:0002.0004/input/input5
[  435.613613] hid-generic 0003:1C4F:0002.0004: input,hidraw1: USB HID v1.10 Device [USB USB Keykoard] on usb-1c1d400.usb-1/input1

 

[gdm85]

On 9/20/2017 at 9:46 AM, gdm85 said:

I have tested their kernel with their config and the USB works fine, so it is definitely a kernel .config issue that could be fixed in the armbian .config; I do not know (yet) precisely what, but I guess it just takes a comparison with their official .config and some tests to find out.

 

I am attaching theirs here for reference (this is the one with working USB, vanilla/untouched from their Xenial core image).

config-4.11.2-h5

@@lex ^

 

This would exclude for me any hardware problem.

 

In your latest post you mentioned both hardware problems and kernel problems.....

I have been testing with same devices and different kernels/config combinations. The devices get power but nothing is on the log.

[@lex]

3 minutes ago, gdm85 said:

The devices get power but nothing is on the log

if you attach a high-speed device, kernel (depends on which version) may or not detect your device

4 minutes ago, gdm85 said:

I have been testing with same devices and different kernels/config combinations

That's exactly what you are doing wrong! Justa attach a USB keyboard and you will see a log, if NOT you have a faulty USB connector.

 

Why not you tell which device you want to use? 

[gdm85]

@@lex I refuse to answer your posts if you do not read what I write. Thanks for your help, I will take the issue with other users/developers.

[@lex]

Just now, gdm85 said:

Thanks for your help, I will take the issue with other users/developers

Sorry, i wanted to help did not want to sound rude. Good luck.

[martinayotte]

There 2 other USB available on pins of CON2, you can attached a breakout there ...