Jump to content

Recommended Posts

Posted

I received a NanoPi Duo today. Since I did not order the shield I set up for Wifi.

A preliminary network performance test using speedtest-cli shows about 18 MBit/s with the on-board antenna, and 20 MBit/s with an OPiZ-Antenna (ca. 1,5 m from AP).

Though not impressive, this is significantly better the OPiZ WLAN performance - despite the identical driver(and close to the numbers reported by @TarableCode).

Nice little board, though ...

NanoPiDuo.JPG

Posted

Some iperf results

A.: 1.5m from AP

internal Antenna - server 20.8 Mbit/s - client 21.7 MBit/s

external Antenne - server 21.5 MBit/s - client 21.8 MBit/s

B.: 5m from AP

internal Antenna - server 20.7 Mbit/s - client 20.3 MBit/s

external Antenne - server 21.2 MBit/s - client 21.9 MBit/s

 

The xradio_wlan driver seems to be loaded as an out-of-tree module:

[    6.402364] xradio_wlan: loading out-of-tree module taints kernel.

I cannot find the out-of-tree driver code at friendlyarms github ... any ideas where to look?

Posted

Fiddling with it more today and it doesn't take long to hit the throttle point of ~65c when compiling with -j5 and loading all cores.

It might benefit from a tiny fan, I have a smallish desk fan pointed at it and it's hovering around 43c still loaded.

 

I have been using an orangepi-zero build so that may be affecting things.

Posted
16 hours ago, TarableCode said:

Fiddling with it more today and it doesn't take long to hit the throttle point of ~65c when compiling with -j5 and loading all cores.

The H2+/H3 SoCs have tendency to reach such temperatures at prologed max loads. As simple test with sysbench at an ambient temp of 20c sees my duo reach 65c after about 8 minutes. Throttling occurs lowering cpu freq to 816k and quite effectivly reducing temp below throttling point quickly. I am currently using the nanpi provided image btw.

Posted
18 minutes ago, raschid said:

As simple test with sysbench at an ambient temp of 20c sees my duo reach 65c after about 8 minutes

 

Just for the record: These 65°C are just a number set here: https://github.com/friendlyarm/linux/blob/sunxi-4.11.y/arch/arm/boot/dts/sun8i-h3-nanopi.dtsi#L158

 

Ondrej used this and the other numbers when he started to code DVFS/THS stuff last year, AFAIK no one so far has looked into H3 thermal/throttling stuff from a user perspective ('Are these settings sufficient') and the only time I looked into it it was pretty obvious that the way throttling currently works with mainline kernel on those boards with primitive voltage regulation (switching only between 1.1V and 1.3V) is worse compared to BSP/legacy kernel.

Posted

Thx @tkaiser, I am quite aware of DVFS/THS entries in device trees - good analysis in that separate post.

BTW, any progress on DVFS for H3-boards (OPi-One/-Lite) in mainline?

Posted

8 Minutes before thermal throttling is still pretty impressive and I wouldn't think it unreasonable to need active cooling if you're going to peg all 4 cores for a long time on such a tiny board with a tiny heatsink.

I'm always open for more testing though :)

Posted

Has anyone with access to the Shield and a SSD connected to the mSATA slot looked into how the JMS567 is powered on the board? I had a short look into Shield schematic and to me (noob!) it seems that PG11 is used to provide power the chip? If that's the case we would need the following set in u-boot to allow moving the rootfs to the mSATA slot, true?

CONFIG_SATAPWR="PG11"

Just asking since @Peter Scargill was asking over at CNX how to transfer the rootfs to an mSATA SSD. A possible way to test would be (with a SATA device connected):

sunxi-pio -m PG11'<default><default<default><0>'
lsusb
sunxi-pio -m PG11'<default><default<default><1>'
sleep 3
lsusb

 

Posted

@tkaiser
This pin "PG11" is connected to 0R/NC (R14) probably is not soldered in the shield board
btw the pin 38 from JMS567 is only for reset (Active-low) to reset the entire chip. so, is not needed to provide power to the chip.

Posted

I just set up my NanoPi Duo and I was hoping to get SPI performance similar to the Orange Pi Zero. I don't have an oscilloscope, but it looks like I'm getting a max frequency of around 3Mhz (based on ili9341 LCD refresh rate). Anyone else seeing sluggish SPI performance? I mapped the GPIO numbers for the pins too. I'll update my SPI_LCD project shortly with the new pin->gpio table.

Posted

Howdy folks, I bought 3 NanoPi Duos without the mini shield. I was able to power it off the bus, but I expected the OTG port to work in host mode when it's not the power source (as it says on the Friendly Arm wiki). I used the official Ubuntu image and lsusb shows no devices plugged in directly or through a powered hub. I contacted Friendly Arm and they still haven't replied. Any help is much appreciated.

 

7e7b8df3e2a9899d416c64701cc7e8619576b713

Posted
6 hours ago, sgjava said:

I expected the OTG port to work in host mode when it's not the power source (as it says on the Friendly Arm wiki)

 

Where do they claim this?

Posted

"VDD_5V: 5V power input/output. When the external device’s voltage is greater than the MicroUSB's voltage the external device is powering the board" Maybe I read this the wrong way, but since it claims to be an OTG port this is how it works with all the other SBCs I've used. If you power from the bus it frees up the OTG port for USB peripherals. If this isn't the case then it looks like you have to have the mini shield which shouldn't be required for running a simple setup like I have (maybe a USB drive or camera).

Posted

I don't think the FriendlyELEC powering conventions (to allow powering external devices on the Micro USB port also) is related to the USB port switching role between OTG and host.

 

It would be great if you could do the following quick test and provide results:

  • remove SD card (I hope you did not flashed anything to the SPI NOR right now)
  • use a Micro USB cable to connect your Duo to the USB port of any other Linux host (eg the NEO2 in the background)
  • Run there 'lsusb', 'sunxi-fel ver' and 'sunxi-fel sid' please (see here)

My hope is the Duo then being in 'FEL mode' (connecting the SoC's OTG controller to the Micro USB port). To switch between host and OTG role different steps are needed with legacy and mainline kernel and I've not the slightest idea which patches and DT settings FriendlyELEC uses on their mainline kernel OS images currently.

Posted

I tried it on a new Duo (I have 2 unopened). Here's what I get plugging it into my Linux x86 desktop without SD:

 

lsusb

Bus 006 Device 002: ID 1f3a:efe8 Onda (unverified) V972 tablet in flashing mode

 

sunxi-fel ver

AWUSBFEX soc=00001680(H3) 00000001 ver=0001 44 08 scratchpad=00007e00 00000000 00000000

 

sunxi-fel sid

This sid command was missing from sunxi-fel on Ubuntu 16.04 x86_64 repo. I'll try that later on my NEO Plus2. Is there a better ROM than the official distro?

 

Usage: sunxi-fel [options] command arguments... [command...]
    -v, --verbose            Verbose logging

    spl file            Load and execute U-Boot SPL
        If file additionally contains a main U-Boot binary
        (u-boot-sunxi-with-spl.bin), this command also transfers that
        to memory (default address from image), but won't execute it.

    uboot file-with-spl        like "spl", but actually starts U-Boot
        U-Boot execution will take place when the fel utility exits.
        This allows combining "uboot" with further "write" commands
        (to transfer other files needed for the boot).

    hex[dump] address length    Dumps memory region in hex
    dump address length        Binary memory dump
    exe[cute] address        Call function address
    read address length file    Write memory contents into file
    write address file        Store file contents into memory
    ver[sion]            Show BROM version
    clear address length        Clear memory
    fill address length value    Fill memory

 

Posted
15 minutes ago, sgjava said:

Bus 006 Device 002: ID 1f3a:efe8 Onda (unverified) V972 tablet in flashing mode

 

Ok, that's the expected output so there's OTG on the NanoPi Duo Micro USB port. On the more recent Allwinner SoCs this port can be routed to both OTG and an own EHCI/OHCI controller pair which is done in software later (for legacy kernel -- in case you want to ever try this -- you'd search for 'g_ether h3' in this forum, for mainline kernel search for 'missing usb nano pi plus 2' or something like that, there was a discussion recently since on the NEO Plus 2 FriendlyELEC chose to expose usb0 as USB-A receptacle).

 

In other words: It will work to turn the Micro USB port into a full USB host port but please don't ask how with FriendlyELEC's image :)

 

The sunxi-tools package can be built from github easily and if you choose an Armbian image for the NEO2 most recent version is included on all images (possibly containing a bug). But SID isn't that important to know, I was just curious.

Posted

Yea, FriendlyElec is on vacation until Oct 8th (I received an auto-reply from their sales email). It would be nice if their image supported host mode out of the box like most other SBCs. Once nice thing I was able to do is configure Duo's wifi on the SD card instead of having a serial cable and just ssh in. This worked on the NEO Plus2 as well.

Posted

I put up a blog about "breadboarding for cheap misers" showing some simple ways to make certain components breadboardable (like USB A Host connectors), leading up to "Breadboarding with the NanoPi Duo".  This thing is a lot of fun, to be honest.

 

IMG_20171116_004522.jpg

Posted

Excellent stuff :)

 

On 17.11.2017 at 12:13 AM, TonyMac32 said:

Also, there is a test image specifically for the Duo, so far so good.  https://www.armbian.com/nanopi-duo/

When using this image on a breadboard, keep in mind that here SPI is activated by default - so you should not use GPIOs  A13-A16 for non-SPI stuff.

There's an updated set of patches addressing this issues that hat not been merged yet: https://github.com/armbian/build/pull/816

Works.

 

Posted
4 hours ago, raschid said:

so you should not use GPIOs  A13-A16 for non-SPI stuff

 

I tested this out, I can control those pins.  Is the issue that the SPI driver can show up and smash everything?  And if so, is this possible accidentally, or would it have to be triggered by an unsuspecting user?

 

Side note for @tkaiser I was getting about 160-190 mA consumption (varied widely) on the vendor image, with the nightly Armbian I get about 150.

 

 

Posted
6 hours ago, raschid said:

keep in mind that here SPI is activated by default - so you should not use GPIOs  A13-A16 for non-SPI stuff.


Not on mainline kernel. This used to be the case with legacy.

I see.

Posted

maybe "enabled" would have been a better term than "activated" ... "enabled" as in containing the following in the "sun8i-nanopi-duo" kernel-patch:

+
+&spi1 {
+	status = "okay";
+	spidev1: spi@1 {
+		compatible = "nanopi,spidev";
+		reg = <0>;
+		spi-max-frequency = <10000000>;
+	};
+};

 

Posted
On 16.11.2017 at 6:37 AM, TonyMac32 said:

I put up a blog about "breadboarding for cheap misers" showing some simple ways to make certain components breadboardable (like USB A Host connectors), leading up to "Breadboarding with the NanoPi Duo"

 

Maybe I need a bigger bread board ... testing I2C with a small OLED display with the current device tree patches ...

IMG_5898.JPG

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines