Image | NanoPi NEO2 Black #3333
Comments
|
@mrbluecoat Since SoC/CPU and RAM-type did not change, I think the regular NEO2 images should work just fine? |
|
My only unknown is the new eMMC flash module but if that's handled already by the OS we should be good. I have mine on order and I'll test with the existing NEO2 image when it arrives. |
|
@mrbluecoat |
|
Here's a quick update: My NanoPi NEO2 Black unit managed to ship out of China before the virus lockdown. (My heart goes out to our FriendlyArm friends in Shenzen!) The unit works fine with a micro-SD card:
Using the https://www.friendlyarm.com/index.php?route=product/product&product_id=209 8 GB eMMC module and FriendlyArm eMMC-to-microSD adapter, I was able to load the DietPi image no problem with Balena Etcher. However, I never got an SSH prompt (waited 10 minutes). I'll dig out my UART adapter later this week to probe further... |
|
P.S. It works fine when I boot from the eMMC module when connected to the micro-SD adapter in the micro-SD slot so I know the eMMC module is operational. |
|
@mrbluecoat |
|
New image ready, you might want to test it on NEO2 Black: https://dietpi.com/downloads/images/DietPi_NanoPiNEO2-ARMv8-Buster.7z |
|
Hmm.. no luck. Same behavior. I'll look into it over the weekend. |
|
@mrbluecoat You could try it with the Armbian NEO2 Black image (Buster server): https://www.armbian.com/nanopi-neo-2-black/#kernels-archive-all |
|
Okay, here's the latest results: The official FriendlyArm Xenial image based on UbuntuCore and Linux Kernel-4.14 works out of the box (booting directly from the eMMC drive). In preparation to test the Armbian and DietPi images, their UART was a pain to figure out because after a lot of trial and error I discovered their UART1 pins are useless. The only working UART option is UART0 ("Debug UART" on their schematic) which has no 2pin-pads to connect to (lame!) and the ground/5v pins are on the other side of the board. I had some parts lying around to get it to work but people should be aware that UART is not an option out-of-the-box for the Black version (unlike its Blue sibling). With all that said, I tried the Armbian NEO2 Black buster image you recommended and it briefly starts but then hangs: I'll try your nand-sata-install method next. |
|
I was able to load the Armbian NEO2 Black image onto the SD card, use the nand-sata-install method to move it to the eMMC chip, remove the SD card and boot exclusively from the eMMC chip, then upgrade to DietPi using your PREP_SYSTEM_FOR_DIETPI.sh script, then image it using your dietpi-imager. I then loaded it onto the eMMC chip and it doesn't boot. Argh! UART doesn't even connect. The image works fine booting from the SD card, though. Too tired at this point...I'll try again next weekend. |
|
@mrbluecoat After using Could you paste the following after running From what I found, the partitioning and filesystem should actually not change at all, but maybe I've overseen something:
which points to the SDcard. which points to whichever partition has this UUID, I am not sure whether this is correctly read from u-boot or not, even that it would not have any reason if not 🤔. However Last step of the script is installing u-boot to the eMMC, via I am now adjusting the entries in the image and verify its partition layout... |
|
Uploaded new image to test with eMMC: https://dietpi.com/downloads/images/DietPi_NanoPiNEO2-ARMv8-Buster_eMMC.7z |
|
No luck with that image, but here's the UART output in case it helps: I'll get the other data you requested soon. |
|
Not sure why but the Armbian image never worked with the UART or eMMC connected. I would always hang on either After using the df -T fdisk -l cat /etc/fstab /boot/{armbianEnv.txt,boot.cmd} I was able to |
|
I was also able to boot and reboot from the eMMC after running |
|
Here's the eMMC benchmark for comparison: |
|
@mrbluecoat I am dumb.. NEO2 has no video output, hence kernel/boot messages on tty1 have no reason 😄. So partition setup is as expected, matching the case when you directly flash the image to eMMC. fstab entry is a bid different, but nothing related. What I find interesting is that
On the other hand, the Armbian image fails the same when flashing to eMMC directly, right? So it might be true that for some reason the bootloader must be written to eMMC manually. Just for reference:
It seems it tries to perform a network boot which fails.
Not sure if this means it cannot find a "valid" card in both, external SD slot and internal eMMC. EDITI compared the related bits from our image file with the uboot files and they match 100%:
EDIT: Related bits still match 100%. when using EDITI recognised that our image for some reason contains the PARTUUID in fstab instead of the UUID. This should only be the case on RPi and redoing the fstab cleaning resulted in UUID as expected. I'll have a look into this, if other images are affected as well. |
I think with all my variations in testing I somehow missed testing the Armbian image with the wall adapter directly because I loaded the Armbian black image using Balena Etcher onto the eMMC and then plugged the unit into the wall and it booted just fine. My guess is the UART wasn't providing enough power because when I connected the UART RX/TX/Ground but used the wall adapter for power it booted fine: Using the same UART method, still no luck with your latest image: I'll use my method from yesterday to get a working DietPi instance on the eMMC and then use |
|
I swear this eMMC chip is going to give me brain damage.. After trying your image I loaded Armbian back on, removed the UART, and plugged in the wall adapter just like I did less than an hour ago. It didn't boot. I unplugged and replugged in and it didn't boot. I unplugged, waited about 10 minutes, and then plugged in and it booted. Not sure if the chip is flaky or some residual electrons in the circuitry are causing the issue. I'll keep testing... |
|
Hmm strange, probably the PSU does not provide stable voltage when eMMC and UART are both attached? |
|
I used the process above to install DietPi on to the eMMC chip and then shut down. I waited a while and then plugged it into my computer using the micro-SD adapter. Using |
|
Here's the result of my manual resizing: https://drive.google.com/file/d/1jTeHccp83_uaKSG8RoHV-P2GjeLdV85w/view?usp=sharing It only works on the eMMC chip (not micro-SD) but I was able to consistently boot, shutdown, and reboot. I hope it helps with your troubleshooting. |
|
No luck with |
|
@mrbluecoat I think the NEO2 non-black bootloader simply does not support eMMC, since non-black NEO2 does not have one. I totally forgot that as possible simple reason on the way. Looks quite clear: Armbian NEO2 Black image
DietPi NEO2 non-Black image
I'll redo a NEO2 Black image later. Regarding your issue with DietPi-Imager, this is very strange indeed, since it works perfectly fine for all the new images I created. You used the most current dev version? https://raw.githubusercontent.com/MichaIng/DietPi/dev/.meta/dietpi-imager
|
I should clarify that those errors were on separate runs Removing Here's the result of that run: https://drive.google.com/open?id=1VQ5Dl8YJpYln49IhNpPKVrTPuNVPtN3t Running Here's the result of that run: https://drive.google.com/open?id=1aWUJjWZVhXeUHNpqXLzejmFbGytqHm1_ Interesting that the second method (local drive *.img file) produces a file that's is so much smaller than the first method (eMMC drive) even though they're both based on the same image. |
|
Redid the NEO2 Black image with newest DietPi version and some minor image-wise fixes, e.g. forced 1.0.0.1 DNS nameserver: https://dietpi.com/downloads/images/DietPi_NanoPiNEO2Black-ARMv8-Buster.7z Would be great if anyone could verify that it first boot setup works as fine as with the last one, then I'll move it to stable. |
|
No luck with the eMMC chip but microSD was fine (both boot and reboot): I wouldn't spend more time on it, though, since FriendlyElec discontinued it :( I have an Orange Pi One Plus on the way and we'll see if it gets comparable results... |
The steps you did above did not work this time?
It seams it gets a higher clock rate with the NEO2 Black image compared to the results you got with the regular NEO2 image: #3333 (comment) Probably the higher clock rate + power consumption also makes it a bid unstable with current PSU. |
|
Re: eMMC, nope. Unplugged, waited 10 seconds. Unplugged, waited an hour. Reflashed using Etcher. Tried a number of ways. |
|
If you find time for testing, does the current Armbian image work on eMMC? https://dl.armbian.com/nanopineo2black/archive/Armbian_20.02.1_Nanopineo2black_buster_current_5.4.20.7z Would be good to have some other NEO2 Black user to check whether it is hardware-specific or not. Would be just great to have one reliably booting Buster image, as well from eMMC since that is the significant difference between Black and non-Black version. |
|
Armbian loaded fine on eMMC: That said, I had to flash twice with Etcher because it failed the first time so my guess is the eMMC chip is flaky. I'll let others verify the image for more reliable results. Great work, by the way - I love DietPi! |
|
P.S. Your earlier |
|
Many thanks in any case for all your testing effort 👍. |
|
After reading armbian/build#1838 - And having FriendlyWRT blow away my setup notes - I tried the Neo2 Black beta image on the NanoPi R1S-H5 Basic setup worked. I've run into three caveats for the setup (a tunneling router) I'm trying to replace so far;
Both of these probably merit separate issues.
|
|
Jep, multiple/flexible network adapter setup is planned for next release (probably one more, as its a huge task), until then the second adapter should be setup manually via e.g. A wireless access point can be setup by installing WiFi Hotspot via dietpi-software, and can then be configure via dietpi-config. Making this available as config option right from the start is as well planned.
I know that Armbian kernels have highest possible clocks enabled. Does CPU scheduling not working to clock it down in idle? I.e. what does the following show in your case (here example on RPi2):
I would expect that CPUfreq-based scheduling works on Armbian kernel as well in general, so that temperatures are a question of related settings. Since even the upper clock can be limited via |
While booting, it is apparently still quite messed up. |
|
Does this exist or give an output? In case not: |
|
I does not. And, |
|
Okay, no cpufreq scaling driver is active. Probably it is since the NanoPi NEO2 Black image does not fit 100% for R1S, not sure. Just to be sure, but I guess this does not exist on (most) SBCs: However to assure that I did not oversee something, try: And see if any of the above files appeared now. But I don't think so and you should then purge the package again which otherwise does a lot of obsolete loading, checking, scraping at boot: |
cpufrequtils got me nothing new, after service and system restart. And just to confirm, |
|
Okay there we have two CPUFreq drivers, one more specific and one more generic from what I read, both for certain ARM chips. If you're prepared to get a system crash, you can try them: If it does not throw an error, recheck if the sysfs files are available now, check temperatures and clock: Same procedure. I totally forgot to check dmesg for any related driver load attempts: |
|
From a clean boot: So cpufreq-dt is already loaded, with no obvious dmesg entries scpi-cpufreq does load, no crashes, but only effects lsmod output, not dmesg, or anything in /sys/ that's been previously noted. |
|
Okay, I think we have to accept that currently the Armbian H5 kernel (with the available device trees) does not fully support this device. Probably they publish a separate image in the future, we can keep an eye on it. From our end it also has not highest priority until our network setup scripts do not support router/multi-Ethernet systems in a reasonable way. However keep up investigation and research for this. Probably it makes sense to track this in a separate image request? |
ADMIN EDIT
Latest beta image: https://dietpi.com/downloads/images/DietPi_NanoPiNEO2Black-ARMv8-Buster.7z
Creating an image request
Formal device information
Is the SBC officially supported by the Debian installer?
If not, is a reliable 3rd party Debian image available for this SBC?
https://www.armbian.com/nanopi-neo-2-black/
If not, are there install instructions for Debian available?
http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO2_Black
Vote for this image on FeatHub: https://feathub.com/MichaIng/DietPi/
The text was updated successfully, but these errors were encountered: