gdm85

Members
  • Content Count

    17
  • Joined

  • Last visited

About gdm85

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. gdm85

    NanoPi NEO4

    @Jason Law for which board did you opt? M4 or Neo4? I have fairly similar requirements and not inclined for Odroid either.
  2. @@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.
  3. @@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.
  4. 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.
  5. 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.
  6. 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?
  7. 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..
  8. @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
  9. 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)
  10. @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
  11. 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?
  12. 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
  13. FYI, as I reported in this thread, the second USB works with their official Ubuntu Xenial core image (didn't test any other of theirs). So now I am trying to figure out if it's a kernel configuration issue or (more likely) DTB/kernel driver level.
  14. 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)
  15. 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