Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

NanoPi M3/Fire3 | NanoPC T3 | ZeroPi | Debian Buster images #3221

Closed
MichaIng opened this issue Nov 7, 2019 · 28 comments
Closed

NanoPi M3/Fire3 | NanoPC T3 | ZeroPi | Debian Buster images #3221

MichaIng opened this issue Nov 7, 2019 · 28 comments
Labels
Buster FriendlyELEC All NanoPi related Image request 💾 NanoPi Fire3 NanoPi M3/T3 Solution available 🥂 Definite solution has been done
Milestone
v6.29

Comments

@MichaIng
Copy link
Owner

MichaIng commented Nov 7, 2019 •
edited
Loading

Thanks to @StephanStS we can offer a new set of community-created Debian Buster images. Those are based on @Armbian, so credits for the kernel, bootloader and firmware work, to have Debian running on those boards, go to them.

Besides finally running Debian Buster and Linux 4.14, a great benefit for M3/T3/Fire3 is that they run a ARMv8/aarch64 kernel + OS.

The images have been tested and are actively used by @Stephan and have gone through some review by us. However we offer them as "beta" for now until some more users have tested them their way. This means for you, if you face any issue or have any suggestions to enhance the initial boot or setup experience, please report this here, so we can do some fine tuning before shipping them as stable replacement for the current Stretch-based images.

NanoPi M3 + NanoPC T3: https://dietpi.com/downloads/images/DietPi_NanoPiM3-ARMv8-Buster.7z

NanoPi Fire3: https://dietpi.com/downloads/images/DietPi_NanoPiFire3-ARMv8-Buster.7z

ZeroPi: https://dietpi.com/downloads/images/DietPi_ZeroPi-ARMv7-Buster.7z

The old stable image for M3/T3/Fire3 (Stretch + Linux 4.4 + ARMv7) is available here: REMOVED INVALID LINK
Although it has been proven to work fine, I highly recommend to go with the above updated images. Report any issue here and we'll assist quickly.
This was referenced Nov 7, 2019
Closed
Closed
MichaIng added a commit that referenced this issue Nov 12, 2019
@MichaIng
v6.27
bd0aa9b 
+ DietPi-Obtain_HW_model | Add FriendlyARM ZeroPi support with new hardware ID 59: #3221
@MichaIng
Copy link
Owner Author

MichaIng commented Nov 12, 2019 •
edited
Loading

ZeroPi hardware identifier added for v6.27: bd0aa9b

dietpi.com download page for M3/T3/Fire3 links to this issue now: https://dietpi.com/#download
The benefit if the new images is too large to have any user downloading the old (though proven stable) ones. We'll assist here quickly if any issue arises.

@MichaIng MichaIng added this to the v6.27 milestone Nov 12, 2019
@MichaIng
Copy link
Owner Author

MichaIng commented Nov 12, 2019 •
edited
Loading

Could one of you guys with ZeroPi paste cat /proc/cpuinfo, please? So we can apply the new DietPi internal hardware ID 59 to all of them during next update. Otherwise I would scan /etc/armbian-release to apply it at least for Armbian-based images, but it would be better to do that based on generic /proc/cpuinfo identifier 😉.

Added hardware ID to DietPi-PREP: 3a6a060
Changelog: 72b7dff

MichaIng added a commit that referenced this issue Nov 12, 2019
@MichaIng
v6.27
72b7dff 
+ CHANGELOG | FriendlyARM ZeroPi: Initial hardware identifier (ID: 59) and support for this device has been added to DietPi: #3221
@MichaIng MichaIng added the Solution available 🥂 Definite solution has been done label Nov 12, 2019
@StephanStS
Copy link
Collaborator

root@DietPiZeroPi:~# cat /proc/cpuinfo

processor : 0
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 64.80
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5

processor : 1
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 64.80
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5

processor : 2
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 64.80
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5

processor : 3
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 64.80
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5

Hardware : Allwinner sun8i Family
Revision : 0000
Serial : 02c00181ef5b3435

@MichaIng
Copy link
Owner Author

@StephanStS
Many thanks! Sadly the revision code is not unique, hence I guess we must rely on /etc/armbian-release to apply hardware ID to existing systems. However, for all systems based on your image, this works, so no big issue.

@StephanStS
Copy link
Collaborator

StephanStS commented Nov 12, 2019 via email •
edited
Loading

@MichaIng
Copy link
Owner Author

MichaIng commented Nov 12, 2019 •
edited
Loading

@StephanStS
I have no idea what OMV installer does, just remember that it is quite intrusive and OMV in general doubles many DietPi features and config setup, hence conflicts e.g. with dietpi-config network options for sure and probably with the initial network setup as well, not sure. This was the reason we removed the OMV install option from DietPi-Software once.

However what you need to check is:
/etc/network/interfaces
and if existent, files in
/etc/network/interfaces.d
e.g.
cat /etc/network/interfaces{,.d/*}

The main network adapter needs to have an interface assigned there, in case of DHCP on Ethernet this should then look like this:

allow-hotplug eth0
iface eth0 inet dhcp

With this, there is an ifup@eth0 service that configures this interface, once the adapter is available on boot. ifup then invokes the dhclient to retrieve an IP and as well a DNS nameserver.

You can check the service status and that the dhclient is up:

systemctl status ifup@eth0
ps ax | grep [d]hclient

Common issues due to 3rd party installers are:

  • Install of additional network related packages, e.g. dhcpcd5, an additional DHCP client which conflicts with isc-dhcp-client (dhclient) and requires different /etc/network/interface entries: iface eth0 inet manual (instead of "dhcp" in the end)
  • /etc/network/interface changes, e.g. like above which leads to dhclient not being invoked on interface start.

@MichaIng MichaIng mentioned this issue Nov 13, 2019
Merged
@MichaIng MichaIng modified the milestones: v6.27, v6.28 Nov 18, 2019
@MichaIng
Copy link
Owner Author

Adjusted milestone to keep track of those images through next development cycle as well and, if no urgent errors are reported, move them into stable place.

@mrbluecoat
Copy link

ZeroPi image worked great - thanks!

Benchmark:

 CPU Performance : Duration = 20.64 seconds (lower is faster)
   │  - CPU Temp        : Idle = 37'c | Full load = 51'c
   │  - RootFS          : Write = 13 MiB/s | Read = 21 MiB/s
   │  - RAM             : Write = 328 MiB/s | Read = 476 MiB/s

cat /proc/cpuinfo

processor       : 0
model name      : ARMv7 Processor rev 5 (v7l)
BogoMIPS        : 136.80
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc07
CPU revision    : 5

processor       : 1
model name      : ARMv7 Processor rev 5 (v7l)
BogoMIPS        : 136.80
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc07
CPU revision    : 5

processor       : 2
model name      : ARMv7 Processor rev 5 (v7l)
BogoMIPS        : 136.80
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc07
CPU revision    : 5

processor       : 3
model name      : ARMv7 Processor rev 5 (v7l)
BogoMIPS        : 136.80
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc07
CPU revision    : 5

Hardware        : Allwinner sun8i Family
Revision        : 0000
Serial          : 02c00181744f6c08

@StephanStS
Copy link
Collaborator

Regarding the resolv.conf issue mentioned above (from 12th of november) I found out:

In the good case the resolv.conf symbolic link was:

root@Fire3:~# ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 31 Nov  4 05:46 /etc/resolv.conf -> /etc/resolvconf/run/resolv.conf

In the bad case (after the OMV5 installation) the resolv.conf symbolic link was:

root@Fire3:~# ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 32 Nov 26 18:32 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf

Also in the bad case the output of "systemctl status ifup@eth0" gave amongst others:

Nov 15 17:51:10 Fire3 sh[595]: /etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to /etc/resolvconf/run/resolv.conf

After changing the symbolic link back to /etc/resolvconf/run/resolv.conf the system ran o.k., but further installation problems occured.

Yesterday (a couple of days later) I tested the OMV5 installation again on a fresh dietpi image and it ran without errors, the nameserver resolution showed the correct entries. The symbolic link was changed to /run/systemd/resolve/resolv.conf, but the resolv.conf contents was now correct:

root@Fire3:~# cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 1.0.0.1
nameserver 192.168.178.2
search fritz.box

I actually do not know whether this changed behaviour has its cause in a changed OMV 5 installation process, I am not aware that I did any changed to the steps of the OMV 5 installation.

The system is now running fine, this issue I 'define' as closed for now.

@MichaIng
Copy link
Owner Author

MichaIng commented Nov 27, 2019 •
edited
Loading

This was and is the reason why we dropped OMV from software options. It really changes the very basic system setup which breaks our scripts and existing setup. One really has to take it as an own OS and use either OMV or DietPi. Merging both requires the mentioned tinkering, and using OMV UI and dietpi-config/dietpi-software will go on conflicting each other.

To explain what it does:
/run/systemd/resolve/resolv.conf is the systemd-resolved location, which is a systemd-internal alternative to resolvconf, which DietPi uses/expects by default. It makes sense to use this, if one uses systemd-networkd as well, the alternative to ifupdown. Using both in parallel conflicts of course. I was playing around with it as well and thinking about switching DietPi: #1581
However there is none or only marginal benefit. Less APT packages are required, hence some disk space freed, but the systemd services are not passive (like ifupdown + resolvconf) but actively running all the time, taking ~5M RAM constantly each, hence 10M additional RAM usage on idle systems. For 256M SBCs this is too much IMO.

@it-esco
Copy link

it-esco commented Dec 2, 2019

ZeroPi image works great, may thanks

This is cat /proc/cpuinfo

processor : 0
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 64.80
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5

processor : 1
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 64.80
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5

processor : 2
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 64.80
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5

processor : 3
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 64.80
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5

Hardware : Allwinner sun8i Family
Revision : 0000
Serial : 02c0008112b32ca6

@MichaIng
Copy link
Owner Author

MichaIng commented Dec 2, 2019 •
edited
Loading

@it-esco
Many thanks for testing. I'll move that image to stable with v6.27 release and the update will apply the new hardware ID based on /etc/armbian-release content.

@epicfrequency
Copy link

zeropi images hangs on MPD usb audio card playback, not sure why

@MichaIng
Copy link
Owner Author

@epicfrequency
Many thanks for testing. Does the USB sound card otherwise work fine? You selected it via dietpi-config > Audio Options? If so, please open a separate issue, since this should then be some soundcard and/or MPD specific issue, not related to the underlying image 😉.

@epicfrequency
Copy link

epicfrequency commented Dec 16, 2019 •
edited
Loading

Hi Michalng
I have the same usb card(gustard u16) working perfectly fine with Dietpi on Odroid C2/Tinkerboard S using same MPD version .21.16, so that rules out soud card.

In addtion, I tried buildroot Zeropi image built accoring to this one https://github.com/bz31/Buildroot, works fine as well, that rules out the Zeropi itself.

That's why I am guessing something wrong with the Dietpi ZeroPi image:) ~

@MichaIng
Copy link
Owner Author

MichaIng commented Dec 16, 2019 •
edited
Loading

@epicfrequency
Finally to rule out its MPD-related it would be good to test raw audio playback first, e.g. using aplay /path/to/test.raw. Also MPD logs, or probably related dmesg/journalctl entries could help.

The (quite interesting) Buildroot image contains some kernel/dt patch for ZeroPi: https://github.com/bz31/Buildroot/blob/master/board/zeropi/patches/uboot/add-zeropi.patch
It includes some usb_otg driver settings, although I have not much experience with that. Possibly that fixes some issue(s) with other kernel configs, used by ARMbian/kernel that our image is based on. At least could be worth to compare those.

As well Buildroot kernel config: https://github.com/bz31/Buildroot/blob/master/linux-configs/zeropi_linux-4.19.x_usb-audio.config

ARMbian kernel config: https://github.com/armbian/build/blob/master/config/kernel/linux-sunxi-current.config (not it's Linux 5.3 vs 4.19 on Buildroot)
ARMbian kernel patch: https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-sunxi/add-zeropi.patch

@MichaIng MichaIng modified the milestones: v6.28, v6.27 Dec 18, 2019
@MichaIng MichaIng mentioned this issue Dec 18, 2019
Closed
@MichaIng
Copy link
Owner Author

ZeroPi's are detected during DietPi v6.27 pre-patches to have new hardware ID applied, based on which correct further patches, reinstalls etc can be done, and banner will show the device correctly then as well of course: 43387b5

@epicfrequency
Copy link

Looking at dmseg, here shows the error . now sure what is the cause.
[ 4532.063527] usb 5-1.1: uac_clock_source_is_valid(): cannot get clock validity for id 1
[ 4532.063545] usb 5-1.1: clock source 1 is not valid, cannot use
[ 4532.067692] usb 5-1.1: 1:2: cannot get freq (v2/v3): err -71
[ 4532.072600] usb 5-1.1: 1:2: cannot set freq 705600 (v2/v3): err -71
[ 4535.464982] usb 5-1.1: uac_clock_source_is_valid(): cannot get clock validity for id 1
[ 4535.465004] usb 5-1.1: clock source 1 is not valid, cannot use
[ 4535.469303] usb 5-1.1: 1:2: cannot get freq (v2/v3): err -71
[ 4535.474741] usb 5-1.1: 1:2: cannot set freq 705600 (v2/v3): err -71
[ 4661.351676] usb 5-1.1: uac_clock_source_is_valid(): cannot get clock validity for id 1
[ 4661.351690] usb 5-1.1: clock source 1 is not valid, cannot use
[ 4661.355925] usb 5-1.1: 1:2: cannot get freq (v2/v3): err -71
[ 4661.360144] usb 5-1.1: 1:2: cannot set freq 705600 (v2/v3): err -71
[ 4667.134616] usb 5-1.1: 1:1: usb_set_interface failed (-71)

@MichaIng
Copy link
Owner Author

@epicfrequency
Okay a kernel/driver issue. See this patch, which seams to deal with this issue: https://lkml.org/lkml/2019/10/29/201

Could you try to upgrade the firmware packages: apt update && apt full-upgrade

@epicfrequency
Copy link

Tired, no package is updated, even tried on 5.4.6 kernel. same as before.

@MichaIng
Copy link
Owner Author

@epicfrequency
I just recognised that we set ARMbian packages on hold. Doesn't make sense since G_AGDUG and similar override hold states anyway. Just to assure:

apt-mark unhold $(apt-mark showhold)
apt full-upgrade

@epicfrequency
Copy link

epicfrequency commented Dec 28, 2019 •
edited
Loading

root@DietPi:~# apt-mark unhold $(apt-mark showhold)

Canceled hold on linux-buster-root-next-zeropi.
Canceled hold on linux-dtb-next-sunxi.
Canceled hold on linux-image-next-sunxi.
Canceled hold on linux-u-boot-zeropi-next.
Canceled hold on sunxi-tools.

root@DietPi:~# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

And I have narrowed down the failure only happens when I play the maximum DSD512 setup(equivalent of 32bit PCM768Khz .
Everything else works. Same behavior shows in Buildroot.

On dietpi with Odroid C2/Tinkerboard/64bit X86 all works fine. I am guessing more of a Zeropi limitation?

@MichaIng
Copy link
Owner Author

@epicfrequency
Okay, so if the above linked patch indeed solves this ZeroPi audio issue, then it is not yet merged into ARMbian kernel packages. Great that you found a workaround meanwhile.

Could be ZeroPi limitation but I guess kernel/driver patches could solve it. But this exceeds my knowledge. If the issue is the same with buildroot, probably it should be reported there. It could be tested with fresh ARMbian image (https://dl.armbian.com/zeropi/Buster_current_minimal) as well and if its the same then with DietPi (pretty expected), then it could be reported to ARMbian forum as well, if not already a related issue exists: https://forum.armbian.com/forum/13-allwinner-h2-h3/
These guys should be able much better to track down the issue or even find a solution.

@MichaIng MichaIng mentioned this issue Dec 30, 2019
Merged
@MichaIng MichaIng modified the milestones: v6.27, v6.28, v6.29 Jan 1, 2020
@MichaIng
Copy link
Owner Author

I moved the images to stable, updated download links: https://dietpi.com/#download
I'll update them by times for new testing images.

@MichaIng
Copy link
Owner Author

@StephanStS
Little question: We have a workaround on NanoPi Fire3 in place since HDMI output on TTY1 did not work on previous image. Does it still work fine when you remove it?

rm /var/lib/dietpi/postboot.d/fire3_tty2
chvt 1 # When accessing via HDMI
# And to check whether boot output and and login prompt appears still fine
reboot
  • This does not affect SSH or such, only local console output and login.
  • Actually the workaround could even lead to missing login prompt, since getty@tty1 is enabled but not getty@tty2 on the new image.

Btw sorry for missing mail reply. I am currently using any free time for image updates/creation + related DietPi-PREP fine tuning and review, mostly. M4v2 is up already: #2979
When all are done and uploaded for testing, we have a good basis to start with, regarding the topics you listed in your mail.

@StephanStS
Copy link
Collaborator

StephanStS commented Feb 21, 2020 via email

@MichaIng
Copy link
Owner Author

MichaIng commented Feb 21, 2020 via email •
edited
Loading

@StephanStS
Copy link
Collaborator

StephanStS commented Feb 21, 2020 via email

MichaIng added a commit that referenced this issue Feb 22, 2020
@MichaIng
v6.29
75d0a90 
+ DietPi-FirstBoot | Remove obsolete workaround for NanoPi Fire3: #3221 (comment)
+ DietPi-FirstBoot | Be case-sensitive with dietpi.txt, since "sed -n" value scraping is as well. No need and not consistent to ignore cases for dietpi.txt settings.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Buster FriendlyELEC All NanoPi related Image request 💾 NanoPi Fire3 NanoPi M3/T3 Solution available 🥂 Definite solution has been done
Projects
None yet
Milestone
v6.29
Development

No branches or pull requests
5 participants
@mrbluecoat @epicfrequency @MichaIng @it-esco @StephanStS