Review Quick review of NanoPi Fire3

[datsuns]

On 6/1/2018 at 11:04 AM, shaun27 said:

@datsuns double check that the thermal pad they provided didn't move when you were installing the heatsink.

 

I know when I first got it I put the thermal pad on then placed the heatsink without putting the screws in the heatsink first. This caused the thermal pad to move off slightly. Also thought I killed it by pushing down to hard and all . 

 

Temp wise low usage you might get away with no active cooling but this thing does pack a bunch for its size. And I will add temp wise it does handle better then raspberry pi 3 due to the massive heatsink.

 

I've tested this for 4 days straight on xmrig and it sits @ 58c stock speed all 8 cores. 29.5hs btw for cryptonight. 

 

Just make sure when you shutdown under armbian you pull the power plug because it doesn't shutdown right and CPU heats up. Under friendlyarm it does the same btw only power off button works. So sudo halt or logout doesn't really shutdown right!.

 

 

I'd like to do some benchmarking with xmrig and explore overclocking now that we're approaching the end of the summer heat.

 

Can you share your xmrig build instructions? I am not finding anything concrete on the github for an armv8 aes support.

 

EDIT: I did get xmrig running using the standard build instructions for Ubuntu 16.04 (using gcc 6.3.0). I am getting a consistent 28.2 h/s with those build parameters and no overclock. Any suggestions for a more optimal build are highly appreciated.

Edited September 11, 2018 by datsuns
Additional information

[tkaiser]

On 6/1/2018 at 8:04 PM, shaun27 said:

double check that the thermal pad they provided didn't move when you were installing the heatsink

 

Well, the first thing I would try to improve is replacing the thermal pad with something with a lot better heat conductivity, see https://forum.armbian.com/topic/8125-quick-review-of-nanopi-k1-plus/?do=findComment&comment=61417

 

[tkaiser]

On 9/11/2018 at 7:03 AM, tkaiser said:

Well, the first thing I would try to improve is replacing the thermal pad with something with a lot better heat conductivity

 

I did just that:

 

 

The thick thermal pad has been removed and replaced with a 15x15mm copper shim (0.8mm height). The grey stuff around the SoC are leftovers from another thermal pad (came with RockPro64) just to prevent shorting things with the heatsink.

 

I tried to use sbc-bench in thermal testing mode. NanoPi Fire is in upright position (so convection might help a little bit) in a room with 24°C ambient temperature.

sbc-bench.sh -T 80 ; sbc-bench.sh -t 60

Problem N° 1: with stock thermal pad I would have to wait endlessly for the SoC to cool down below 60°C (that what 'sbc-bench.sh -t 60' is supposed to do). The board once hot remained at 62°C to 63°C. I had to temporarely switch cpufreq governor to let the CPU cores clock down from 1400 to 400 MHz to get an idle temperature below 60°C again.

 

Then numbers were as follows:

1400 MHz:  146.17 sec
1300 MHz:  148.42 sec
1200 MHz:       0 sec
1100 MHz:       0 sec
1000 MHz:       0 sec
 900 MHz:       0 sec
 800 MHz:       0 sec
 700 MHz:       0 sec
 600 MHz:       0 sec
 500 MHz:       0 sec
 400 MHz:    5.80 sec

(the 6 seconds on 400 MHz are not result of throttling but me manually switching back to performance cpufreq governor once the real benchmark run started). Full output where you can see how long it took to cool down from 80°C to 60°C: https://pastebin.com/raw/1DDt8yGk

 

Now with copper shim instead of thermal pad.

 

Problem N° 2: now it's impossible for the 'pre-heat' run to get above 80°C. I would have to wait endlessly for this so I stopped and ran 'sbc-bench.sh -T 78 ; sbc-bench.sh -t 60' instead to only wait until temperature exceeds 78°C. Full output: https://pastebin.com/raw/a0vmQJ0b

 

No throttling happened and temperature remained below 80°C. Again it's obvious that thermal pads simply suck when it's about efficient heat dissipation. But I've to admit that I've no idea whether the contact area now with my copper shim is sufficient or thermal pads are the recommended way since with my copper shim now only the very small die area and the copper shim have contact while the area around not.

 

@mindee can you please shed some light?

 

Edit: haha, today I realized that I ran with just 4 CPU cores active yesterday when I made my tests due to 'maxcpus=4' set in /boot/armbianEnv.txt (to test for swap efficiency of various approaches). Doesn't change anything wrt thermal conductivity but of course now with all 8 CPU cores active NanoPi Fire3 starts to throttle severely when running heavy stuff but at least with copper shim clockspeeds are much higher compared to thermal pad.

[cmoski]

Hello!

 

@wtarreau Would it be possible for you to upload your 05.dtb file or provide a few instructions on how you went about modifying the clock frequency to 1.6ghz? I have 10 of these boards and looking to give them a bit of a bump. 

 

Thanks!

[5kft]

33 minutes ago, cmoski said:

 

@wtarreau Would it be possible for you to upload your 05.dtb file or provide a few instructions on how you went about modifying the clock frequency to 1.6ghz? I have 10 of these boards and looking to give them a bit of a bump. 

 

 

Hi @cmoski, in case it is helpful to you:  If you are using the "nanopifire3" board configuration ("next" target), you can build the kernel, specifying the "CREATE_PATCHES=yes" option, and then modify the generated DT in "cache/sources/linux-4.14.y/arch/arm64/boot/dts/nexell/s5p6818-nanopi-fire3.dts".  Look for "dvfs-tables" in this DT file and edit/add the higher frequency:

		dvfs:dynamic-freq@bb000 {
			supply_name = "vdd_arm_spu";
			supply_optional = "vdd_arm_axp";
			vdd_arm_spu-supply = <&VCC1P1_ARM_SPU>;
			vdd_arm_axp-supply = <&VCC1P1_ARM_PMIC>;
			status = "okay";
			dvfs-tables = < 1400000 1200000
					1300000 1140000
					1200000 1100000
					1100000 1040000
					1000000 1040000
					 900000 1000000
					 800000 1000000
					 700000  980000
					 600000  980000
					 500000  940000
					 400000  940000>;
		};

In this table the first column is the frequency, and the second is the voltage provided by the SPU1705 regulator for that frequency.  Note that the maximum voltage that this regulator can output is 1.265v (please see ".../drivers/regulator/spu1705.c" for details).

 

My Fire3 could run fine at 1.5GHz using 1.265v, but 1.6GHz was too unstable (random crashes).  The original FriendlyELEC kernel tree sets the maximum to 1.4GHz at 1.2v, so this is what I brought over to Armbian.

 

I hope this helps...!

 

[wtarreau]

Confirmed, from memory I just added a line with "1600000 1250000". Mine is ultra-stable even with 8 cores at full speed. It happens to throttle a little bit from time to time because the heat cannot escape easily from the cardboard enclosure, but that's all. From what I remember from the datasheet, the chip is designed to run at 1.6 GHz, that's why I picked this frequency.

I also modified the thermal triple points because I don't want the machine to throttle quickly, I seeked the limits on mine and set the points slightly below. I can upload the file later if some want it. It's just that it's possible that my temp limits might cause issues to others so we need to be cautious and I don't want people to randomly download the file without reading the context, then complain about this board's stability when using armbian...

 

[cmoski]

@5kft -- Thanks for this, worked like a charm! For anyone looking for more -- all I had to do was grab the device tree tools and run the following on the existing dtb in the boot directory:

 

dtc -O dts s5p6818-nanopi-fire3.dtb > fire3-devicetreetxt.dts
#[Modify frequencies on dts file, too lazy to build a sed command]
dtc -O dtb fire3-devicetreetxt.dts > s5p6818-nanopi-fire3.dtb

I think on the FriendlyArm provided distro this would be the 05.dtb file as @wtarreau mentioned. No recompilation of the kernel required, just a reboot.

 

It seems that for any overclock a small voltage bump is required. I am still looking into if this will push my 10 port USB hub (60w anker) past its rated capacity when all 10 Fire3's are loaded to 100%.

 

@wtarreau -- If you have a chance I'd love to take a look at your thermal throttling point configuration. Standard disclaimer of course noted :-)

 

Thank you both!

 

[shaun27]

On 9/11/2018 at 12:42 AM, datsuns said:

I'd like to do some benchmarking with xmrig and explore overclocking now that we're approaching the end of the summer heat.

 

Can you share your xmrig build instructions? I am not finding anything concrete on the github for an armv8 aes support.

 

EDIT: I did get xmrig running using the standard build instructions for Ubuntu 16.04 (using gcc 6.3.0). I am getting a consistent 28.2 h/s with those build parameters and no overclock. Any suggestions for a more optimal build are highly appreciated.

 

I get exactly the same 28.2 using xmrig sometimes 28.1. IRC overclocking the CPU will do nothing to improve the hashrate but burn extra power.

 

The only way to increase hashrate is to overclock ram speed as crytonight algorithm uses 1mb per core or 2mb can't remember of top of my head. If I'm correct the CPU on the nanopi fire3 has like 1mb maybe, so it has to do these calculations from ram which is far slower then CPU memory.

 

Also don't forget to add some type of heatsink on those rams because they do get hot if you try overclocking!

 

Forgot to mention when you compile xmrig don't forget before you build under cmake to add following.

 

cmake .. -DCMAKE_C_COMPILER=gcc-7 -DCMAKE_CXX_COMPILER=g++-7

 

This supposedly gives hashrate increases using gcc7 etc but tbh xmrig isn't really optimized for arm cpus.

[wtarreau]

Hi,

 

On 9/27/2018 at 8:57 PM, cmoski said:

@wtarreau -- If you have a chance I'd love to take a look at your thermal throttling point configuration. Standard disclaimer of course noted :-)

 

So I finally found some time to pick the file form the board, sorry for the delay, was busy on other stuff. I verified the temperature thresholds. First alert is at 113, second at 115 and critical is at 120. The file includes one extra DVFS entry for 1600 MHz at 1.25V. I didn't find any other difference compared to the factory dtb. For those landing here from a search engine without preliminary context, this works for my board and is very likely to fry yours, so don't randomly try this file at all, or don't complain!

s5p6818-nanopi3-rev05.1g6-1v25-113deg.dtb

[shaun27]

Just wondering is anyone having issue with rebooting these fire3. Lastest stable image Bionic.

 

This issue doesn't happen on all of them when i reboot (i have 5) but you can bet at least one of them fails and i have rewrite a new image on them. It is not possible to ssh into them when this happens. As you can see from the image when i plugged in hdmi cable that screen shows then after 5 to 10 mins goes blank with a flashing _ . Brand new sd cards in these and all class 10 u1 and its not a particular fire3 which i having issues with its random. 

 

Today after a week running some loads i rebooted 4 came back up fine 1 with the bricked screen. Done some updates and and rebooted and another 2 bricked. Is their a way out this without doing a complete rewrite on sd card again?

 

 

 

 

[wtarreau]

2 hours ago, shaun27 said:

Is their a way out this without doing a complete rewrite on sd card again?

I never had such an issue, but I never plugged HDMI into it either, so it's hard to say if anything is related. If it fails to boot, I'd suggest it's not related to the software/distro so you'd better ask FriendlyElec directly in case they'd be aware of any stability issue or a workaround for what you're seeing. Note, be careful about the power supply, especially if it's shared between all boards. It could be possible that when they're all rebooting, the PSU doesn't cope nicely with the sudden current rush and provides too low a voltage to the boards.

[shaun27]

19 minutes ago, wtarreau said:

I never had such an issue, but I never plugged HDMI into it either, so it's hard to say if anything is related. If it fails to boot, I'd suggest it's not related to the software/distro so you'd better ask FriendlyElec directly in case they'd be aware of any stability issue or a workaround for what you're seeing. Note, be careful about the power supply, especially if it's shared between all boards. It could be possible that when they're all rebooting, the PSU doesn't cope nicely with the sudden current rush and provides too low a voltage to the boards.

I have only started seeing this the last few weeks normally i use them as headless servers and ssh into them. But when a few wasn't showing up on my router i connected the hdmi to see what it was displaying. As for power supply i doubt its that as i been using this setup for a few months now the only difference is i am using stable versions armbian (before was useing wip) and different sd cards which are brand new class 10 u1. I have to do a fresh install of armbian to get the boards working again but this evening i am trying 2 different sd cards just to make sure its not these new ones.  

 

 

 

 

[datsuns]

I've had my 14 boards going mostly continuously for about six months now with some occasional scheduled downtime.

I am finally having trouble with one board and I am trying to determine if it is dead. I just noticed that I wasn't able to find it on my network out of the blue a few days ago. The problem may be related to a power outage I had but I'm not certain about the timing of when it went offline.

 

The board power light still works and I am able to power external items with the GPIO pins (fan) with no issues. I cannot ssh onto the unit because it doesn't show up on my network. I am not getting any display output from the HDMI either. I have tried re-imaging the OS on two different Class 10 U1 micro sd cards and had the same results on both. I am leaning toward a dead board but is there anything else I should try before I throw in the towel on the board?

 

Also, I am now concerned about the health of my other boards and think I might be running them too hard/hot. I think my average temperature has been about 63 degrees Celsius. I have always been curious what an acceptable temperature is for these.

 

The temp usually shows up as red text instead of green on that flash screen on login. Does that red/green threshold have any basis on anything or is it just arbitrary. I run my boards pretty hard but I will throttle them back a bit if I am risking their longevity. I'm also probably going to do the copper spacer mod that tkaiser posted about now to see if I can get my temps down.

[wtarreau]

2 hours ago, datsuns said:

I am leaning toward a dead board but is there anything else I should try before I throw in the towel on the board?

 

You should try to connect a serial adapter to its console port to see if it emits anything at boot. If it doesn't, it's probably dead. If it emits random errors which differ upon every boot, it could be the RAM which became defective. This happened to me on a few boards in the past, and on one of the MIQIs on my build farm. It is also possible that a solder joint has gone bad under a BGA chip. That's the most common failure cause in modern hardware (especially smartphones). It's even worse with RoHS and lead-free because lead-free tin is less elastic and breaks more easily. I've repaired a few such dead boards using a hot air gun and an infrared thermometer, but each time you know that you're probably killing it even more, so you have to be prepared to this. Note that it can also work in an oven if you want to try. Most of the time it doesn't work and can even make things worse but if the board is dead, there's nothing to lose to try. Just pre-heat your oven at 180°C without the board, make sure the temperature is stable (otherwise pre-heat it at 200 and stop it). Then place the board inside for 3-5 minutes. Don't touch it to extract it, open the oven to let it cool down enough, and pick the board once the temperature has dropped enough for the solders to be solid. Some plastic may get slightly damaged if the oven is too hot (e.g. reset button).

 

2 hours ago, datsuns said:

Also, I am now concerned about the health of my other boards and think I might be running them too hard/hot. I think my average temperature has been about 63 degrees Celsius. I have always been curious what an acceptable temperature is for these.

 

The datasheet recommends -25 to 85°C operating temperature (both ambient and die), and -40 to 150 storage. In short it means that it must work flawlessly at 85, that beyond this it only will if you're lucky, and that at 150 you're definitely certain to fry it. Also running a chip past its maximum operating temperature risks to hang it and a hung chip may quickly get damaged. But below 85 you have zero risk for the device itself. If you're overclocking, the margin may be lower.

 

2 hours ago, datsuns said:

I run my boards pretty hard but I will throttle them back a bit if I am risking their longevity.

 

My personal appreciation of "running pretty hard" is when the chip's temperature never has the opportunity to fall back into the recommended range ;-)

 

2 hours ago, datsuns said:

I'm also probably going to do the copper spacer mod that tkaiser posted about now to see if I can get my temps down.

 

Yep I agree. I wanted to do it as well but my copper plates are too thick. However since my board is inside a very tight cardboard "enclosure", I've added an aluminum plate on the other side above two efficient thermal pads. It allows to collect some of the heat from the other side and spread it through the cardboard. It was enough to make the temperature drop by 5-10°C here. But in general since aluminum has a moderate thermal resistance, you indeed want to improve its contact surface with the hot source. A copper plate (which is a much better thermal conductor) does this by spreading the heat all over the base of the heat sink and avoiding hot spots below it. Ideally you need to have a soft thermal pad covering the whole surface of the copper plate, except the small silicon part, so that the heat is extracted from anything below. I've long been wondering if it would be possible to achieve this using a good chunk of silicon glue to stick the copper plate on top of everything. But that would definitely destroy the board.

[shaun27]

15 hours ago, datsuns said:

I've had my 14 boards going mostly continuously for about six months now with some occasional scheduled downtime.

I am finally having trouble with one board and I am trying to determine if it is dead. I just noticed that I wasn't able to find it on my network out of the blue a few days ago. The problem may be related to a power outage I had but I'm not certain about the timing of when it went offline.

 

The board power light still works and I am able to power external items with the GPIO pins (fan) with no issues. I cannot ssh onto the unit because it doesn't show up on my network. I am not getting any display output from the HDMI either. I have tried re-imaging the OS on two different Class 10 U1 micro sd cards and had the same results on both. I am leaning toward a dead board but is there anything else I should try before I throw in the towel on the board?

 

Also, I am now concerned about the health of my other boards and think I might be running them too hard/hot. I think my average temperature has been about 63 degrees Celsius. I have always been curious what an acceptable temperature is for these.

 

The temp usually shows up as red text instead of green on that flash screen on login. Does that red/green threshold have any basis on anything or is it just arbitrary. I run my boards pretty hard but I will throttle them back a bit if I am risking their longevity. I'm also probably going to do the copper spacer mod that tkaiser posted about now to see if I can get my temps down.

Think wtarreau summed up most bits but temp wise 63 is completely fine tbh (what temp mine were running at in the summer). Also have you tried completely disconnected the problematic board and completely discharging it and only starting it up with power in and no peripherals. In the past twice now i found static and a dodgy external usb hard-drives have caused problems with computers. Also if you got a multimeter its worth checking the gpio pins to see if they are  5volts at least that way you can eliminate its not the power supply chips on the board or weak connection on the micro usb.

[datsuns]

On 11/4/2018 at 12:26 AM, wtarreau said:

You should try to connect a serial adapter to its console port to see if it emits anything at boot. If it doesn't, it's probably dead.

Thanks for the thoughtful post. I am going to try the items you brought up, starting with giving the board a few days off to fully settle. If all fails I will try to reset the connections with the oven method but I will treat that as plan C. I will post a followup later with whatever ends up happening.

[wtarreau]

3 hours ago, datsuns said:

If all fails I will try to reset the connections with the oven method but I will treat that as plan C. I will post a followup later with whatever ends up happening.

OK, good luck! Note, you may want to contact FriendlyElec before putting the board into the oven to let them know that one of your boards seems to be dead and let them know what you've tried and that you're planning on trying the oven. Maybe they'll simply want to send you a replacement one and will ask for this one to be sent back there for inspection. They've already sent me some replacement hardware for early defects, they're really nice.

[datsuns]

On 11/6/2018 at 7:33 PM, wtarreau said:

OK, good luck! Note, you may want to contact FriendlyElec before putting the board into the oven to let them know that one of your boards seems to be dead and let them know what you've tried and that you're planning on trying the oven. Maybe they'll simply want to send you a replacement one and will ask for this one to be sent back there for inspection. They've already sent me some replacement hardware for early defects, they're really nice. 

 

That's a really good idea. I was considering placing another order for additional boards but I was getting cold feet - but if they replace it that will be a great sign.

 

So far not looking good for booting, although I seem to be getting proper voltages at all of the gpio pins I have tested.

[datsuns]

On 11/6/2018 at 7:33 PM, wtarreau said:

OK, good luck! Note, you may want to contact FriendlyElec before putting the board into the oven to let them know that one of your boards seems to be dead and let them know what you've tried and that you're planning on trying the oven. Maybe they'll simply want to send you a replacement one and will ask for this one to be sent back there for inspection. They've already sent me some replacement hardware for early defects, they're really nice. 

 

What avenue of contact did you use when you got in touch with them? I tried techsupport@friendlyarm.com but no response so far.

[wtarreau]

1 hour ago, datsuns said:

 

What avenue of contact did you use when you got in touch with them? I tried techsupport@friendlyarm.com but no response so far.

Use sales@, I've used it several times and it works. Oh and put a link to the discussion in this forum so that they know you're not just doing random stuff but are actually using their boards fine. I wouldn't be surprised if they're used to receive an occasional complaint from people who just accidently erase their micro-SD and cry for help.

[fnecboy]

Hi Datsuns

 

This is techsupport from FriendlyARM/FriendlyELEC. Could you help us collect some system log and send to yftan@friendlyarm.com ?

[shaun27]

Bit of an update regarding power button not working on nanopi fire3. Tech support got back to me and its missing a driver which is located friendlyarm kernel source code. I am not sure how to implement this yet but will look into it as and when i get some more time,  hopefully we can implement this into armbian.

[5kft]

On 11/17/2018 at 4:16 AM, shaun27 said:

Bit of an update regarding power button not working on nanopi fire3. Tech support got back to me and its missing a driver which is located friendlyarm kernel source code. I am not sure how to implement this yet but will look into it as and when i get some more time,  hopefully we can implement this into armbian.

 

Hi @shaun27, I just implemented support for this for the Fire3 and have pushed the changes into Armbian (see https://github.com/armbian/build/commit/1301f9f8c254d8408b9136948c786dffa5007acd).  The power button/PWRKEY now works for both powering up the board as well as powering it down 

 

[shaun27]

1 hour ago, 5kft said:

 

Hi @shaun27, I just implemented support for this for the Fire3 and have pushed the changes into Armbian (see https://github.com/armbian/build/commit/1301f9f8c254d8408b9136948c786dffa5007acd).  The power button/PWRKEY now works for both powering up the board as well as powering it down 

 

Your a star!! I assume i would have to update the kernel 10 boards to do :( cant do that through fabric :(

[A.Rahman.A]

Hi there

Does latest armbian build for s5p6818 on nanopi fire3 support opengl ES2 ?

Or include mali400 gpu driver in latest kernel?

 

[Igor]

21 hours ago, A.Rahman.A said:

Hi there

Does latest armbian build for s5p6818 on nanopi fire3 support opengl ES2 ?

Or include mali400 gpu driver in latest kernel?

AFAIK yes.

[A.Rahman.A]

19 hours ago, Igor said:

AFAIK yes.

Thanks for responding

is there any user space lib for openGLES ,

in friendlycore image there was libs and header file under  /usr/nexell  or /usr/nexell-lib

but i can't find similar lib in armbian

 

I also tried to build armbian through documents , using docker ( both kernel only and full OS )

# ./compile.sh docker

The only thing I checked/changed was support for arm mali400 in confige editor
But kernel fails  to compile when i check mali gpu
In normal situation , with default config no error happens

here is a pice of compile.sh output:

 

 CC      drivers/gpu/arm/mali400/linux/mali_osk_atomics.o
  CC      lib/raid6/int1.o
  CC      drivers/gpu/arm/mali400/linux/mali_osk_irq.o
  CC      fs/debugfs/file.o
  CC [M]  net/bridge/br_device.o
  CC [M]  net/bridge/br_fdb.o
  CC      fs/btrfs/delayed-ref.o
  CC      drivers/gpu/arm/mali400/linux/mali_osk_wq.o
  AR      lib/xz/xz_dec.o
scripts/Makefile.build:326: recipe for target 'drivers/gpu/arm/mali400/linux/mali_osk_atomics.o' failed
  CC      lib/raid6/int2.o
  AR      lib/xz/built-in.o
  CC [M]  fs/cifs/readdir.o
  CC [M]  fs/cifs/ioctl.o
scripts/Makefile.build:326: recipe for target 'drivers/gpu/arm/mali400/linux/mali_osk_irq.o' failed
  CC      fs/btrfs/relocation.o
  CC [M]  sound/soc/codecs/es7134.o
  CC      net/core/sock.o
  CC      net/core/request_sock.o
scripts/Makefile.build:326: recipe for target 'drivers/gpu/arm/mali400/linux/mali_osk_wq.o' failed
scripts/Makefile.build:585: recipe for target 'drivers/gpu/arm/mali400' failed
scripts/Makefile.build:585: recipe for target 'drivers/gpu/arm' failed
scripts/Makefile.build:585: recipe for target 'drivers/gpu' failed
Makefile:1054: recipe for target 'drivers' failed
.
.
.
.
.

[ error ] ERROR in function compile_kernel [ compilation.sh:378 ]
[ error ] Kernel was not built [ @host ]
[ o.k. ] Process terminated 

here is compile log in output/debug/compilation.log:

	== u-boot ==

arch/arm/dts/s5p6818-drone.dtb: Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name
arch/arm/dts/s5p6818-drone.dtb: Warning (unit_address_vs_reg): Node /usbhost@c0030000/phy has a reg or ranges property, but no unit name
arch/arm/dts/s5p6818-nanopim3.dtb: Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name
arch/arm/dts/s5p6818-nanopim3.dtb: Warning (unit_address_vs_reg): Node /usbhost@c0030000/phy has a reg or ranges property, but no unit name
arch/arm/dts/s5p6818-nanopi-fire3.dtb: Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name
arch/arm/dts/s5p6818-nanopi-fire3.dtb: Warning (unit_address_vs_reg): Node /usbhost@c0030000/phy has a reg or ranges property, but no unit name
arch/arm/dts/s5p6818-artik710-raptor.dtb: Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name
arch/arm/dts/s5p6818-artik710-raptor.dtb: Warning (unit_address_vs_reg): Node /usbhost@c0030000/phy has a reg or ranges property, but no unit name
arch/arm/dts/s5p6818-artik710-raptor.dtb: Warning (unit_address_vs_reg): Node /i2c_gpio@1 has a unit name, but no reg property
arch/arm/dts/s5p6818-artik710-raptor.dtb: Warning (unit_address_vs_reg): Node /i2c_gpio@2 has a unit name, but no reg property

	== kernel ==

In file included from drivers/gpu/arm/mali400/common/mali_osk.h:21,
                 from drivers/gpu/arm/mali400/linux/mali_osk_atomics.c:16:
drivers/gpu/arm/mali400/linux/mali_osk_specific.h: In function ‘_mali_osk_copy_from_user’:
drivers/gpu/arm/mali400/linux/mali_osk_specific.h:62:14: error: implicit declaration of function ‘copy_from_user’; did you mean ‘raw_copy_from_user’? [-Werror=implicit-function-declaration]
  return (u32)copy_from_user(to, from, (unsigned long)n);
              ^~~~~~~~~~~~~~
              raw_copy_from_user
cc1: some warnings being treated as errors
make[4]: *** [drivers/gpu/arm/mali400/linux/mali_osk_atomics.o] Error 1
make[4]: *** Waiting for unfinished jobs....
In file included from drivers/gpu/arm/mali400/common/mali_osk.h:21,
                 from drivers/gpu/arm/mali400/linux/mali_osk_irq.c:21:
drivers/gpu/arm/mali400/linux/mali_osk_specific.h: In function ‘_mali_osk_copy_from_user’:
drivers/gpu/arm/mali400/linux/mali_osk_specific.h:62:14: error: implicit declaration of function ‘copy_from_user’; did you mean ‘raw_copy_from_user’? [-Werror=implicit-function-declaration]
  return (u32)copy_from_user(to, from, (unsigned long)n);
              ^~~~~~~~~~~~~~
              raw_copy_from_user
cc1: some warnings being treated as errors
make[4]: *** [drivers/gpu/arm/mali400/linux/mali_osk_irq.o] Error 1
In file included from drivers/gpu/arm/mali400/common/mali_osk.h:21,
                 from drivers/gpu/arm/mali400/linux/mali_osk_wq.c:21:
drivers/gpu/arm/mali400/linux/mali_osk_specific.h: In function ‘_mali_osk_copy_from_user’:
drivers/gpu/arm/mali400/linux/mali_osk_specific.h:62:14: error: implicit declaration of function ‘copy_from_user’; did you mean ‘raw_copy_from_user’? [-Werror=implicit-function-declaration]
  return (u32)copy_from_user(to, from, (unsigned long)n);
              ^~~~~~~~~~~~~~
              raw_copy_from_user
cc1: some warnings being treated as errors
make[4]: *** [drivers/gpu/arm/mali400/linux/mali_osk_wq.o] Error 1
make[3]: *** [drivers/gpu/arm/mali400] Error 2
make[2]: *** [drivers/gpu/arm] Error 2
make[1]: *** [drivers/gpu] Error 2
make: *** [drivers] Error 2
make: *** Waiting for unfinished jobs....
sound/soc/codecs/es8316.c:439:12: warning: ‘es8316_pcm_startup’ defined but not used [-Wunused-function]
 static int es8316_pcm_startup(struct snd_pcm_substream *substream,
            ^~~~~~~~~~~~~~~~~~
fs/proc/task_mmu.c: In function ‘show_smap.isra.13’:
fs/proc/task_mmu.c:764:7: warning: ‘last_vma’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  bool last_vma;
       ^~~~~~~~

can you please help?

[Igor]

14 minutes ago, A.Rahman.A said:

can you please help?

 

You must be new around, so check this first https://github.com/armbian/build#support

[Igor]

We based our work on top of https://github.com/rafaello7/debian-installer-nanopi-m3 but its years from then. I don't recall any details.

[dolphs]

rgd NanoPi Fire3-LTS is it possible with kernel >=5.6 to (over)clock this board to 1.6GHz ( or even 1.8Ghz ) stable

Might be a lovely pick for my new server since the H5 boards are hard to get currently ( at friendlyarm at least )