[SOLVED] Support for NanoPC-T3 (very similar to NanoPi-M2)

[Fourdee]

lcd4linux.service
hwservice.service
hwservice_monitor.service

As far as I can tell, these are non-standard services. Probably something FriendlyARM manually added to their images.

I think for now, we should try disabling them with:

Code: Select all

systemctl disable name.service

We can do this with a patch/update. Are those services still enabled on the dropbox uploaded image?

I think you mixed up NanoPi2 (i.e. NanoPi-M2/NanoPC-T2 - for which no Armbian exists) with NanoPi NEO or NanoPi-M1 (for which indeed Armbian images are available).

As yes, correct. M2 image is based on the FriendlyARM image. So many images, hard to keep track lol

Great work on a image/zip, looks good

Ok, i've uploaded the image here: http://dietpi.com/downloads/images/Diet ... Jessie).7z

I'll release it under beta, once we can check a few things:

• Onboard WiFi and Bluetooth. Is this functional at the moment?
  I'll need to code this into dietpi-set_hardware. Can you run the following commands for me please:

  Code: Select all

  /DietPi/dietpi/func/dietpi-set_hardware wifi enable
  cat /etc/modules
  ls -lha /etc/modprobe.d/
  cat /etc/modprobe.d/*
  

• Serial console. if systemctl disable serial-getty@ttySAC0.service has no effect, I believe this may be hard coded as enabled in the /boot binary files. Cant see any config files we can edit. So not much we can do this about this for now.

[awl29]

Hello again,

lcd4linux.service
hwservice.service
hwservice_monitor.service

As far as I can tell, these are non-standard services. Probably something FriendlyARM manually added to their images.

I think for now, we should try disabling them with:

Code: Select all

systemctl disable name.service

We can do this with a patch/update. Are those services still enabled on the dropbox uploaded image?

Yes, unfortunately they are. If they have been created by FriendlyARM (and not Debian or even DietPi), I feel like we should even remove them fully instead of simply disabling them:

Code: Select all

systemctl stop [servicename]
systemctl disable [servicename]
rm /etc/systemd/system/[servicename]
rm /etc/systemd/system/[servicename] symlinks that might be related
systemctl daemon-reload
systemctl reset-failed

Great work on a image/zip, looks good

Thanks, but it's mostly due to your great instructions on how to do so (including shrinking the image).

I'll release it under beta, once we can check a few things:

• Onboard WiFi and Bluetooth. Is this functional at the moment?

WiFi: Yes, Bluetooth: No.

It looks like Bluetooth support (CONFIG_BT) is missing in the Debian/Linux kernel as opposed to the Android kernel. Also, there is a file /etc/modprobe.d/disable_bt.conf that blacklists the respective kernel modules. I will try to work around this, remove the blacklist file and compile a kernel with BT support on my own (based on FriendlyARM's source: https://github.com/friendlyarm/linux-3.4.y) during the next couple of days and report back here.

WLAN is fully functional:

Code: Select all

root@DietPi:~# iwconfig wlan0
wlan0     IEEE 802.11bg  ESSID:off/any
          Mode:Managed  Access Point: Not-Associated
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:on

I'll need to code this into dietpi-set_hardware. Can you run the following commands for me please:

/DietPi/dietpi/func/dietpi-set_hardware wifi enable

Code: Select all

root@DietPi:~# /DietPi/dietpi/func/dietpi-set_hardware wifi disable

 DietPi-Set_Hardware
âââââââââââââââââââââââââââââââââââââââââââââââââââââ
 Mode: wifi (disable)
 Please wait...

 [Ok] wifi disable | Completed

root@DietPi:~# /DietPi/dietpi/func/dietpi-set_hardware wifi enable

 DietPi-Set_Hardware
âââââââââââââââââââââââââââââââââââââââââââââââââââââ
 Mode: wifi (enable)
 Please wait...

 [Info] Please wait, enabling WiFi Modules...
 [Ok] wifi enable | Completed

cat /etc/modules

Code: Select all

root@DietPi:~# cat /etc/modules
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.

ls -lha /etc/modprobe.d/

Code: Select all

root@DietPi:~# ls -lha /etc/modprobe.d
total 28K
drwxr-xr-x  2 root root 4.0K Sep 29 21:02 .
drwxr-xr-x 80 root root 4.0K Sep 22 23:46 ..
-rw-r--r--  1 root root   68 Sep  1  2009 bcmdhd.conf
-rw-r--r--  1 root root   37 Sep 29 13:41 cfg80211.conf
-rw-r--r--  1 root root  102 Sep 22 10:57 disable_bt.conf
-rw-r--r--  1 root root  390 May 26  2015 fbdev-blacklist.conf
-rw-r--r--  1 root root  349 Apr  1 04:44 matrix-blacklist.conf

cat /etc/modprobe.d/bcmdhd.conf

Code: Select all

options bcmdhd firmware_path=/lib/firmware/ap6212/fw_bcm43438a0.bin

cat /etc/modprobe.d/cfg80211.conf

Code: Select all

options cfg80211 ieee80211_regdom=GB

cat /etc/modprobe.d/disable_bt.conf

Code: Select all

blacklist hci_uart
blacklist hidp
blacklist rfcomm
blacklist btbcm
blacklist bnep
blacklist bluetooth

cat /etc/modprobe.d/fbdev-blacklist.conf

Code: Select all

# This file blacklists most old-style PCI framebuffer drivers.

blacklist arkfb
blacklist aty128fb
blacklist atyfb
blacklist radeonfb
blacklist cirrusfb
blacklist cyber2000fb
blacklist kyrofb
blacklist matroxfb_base
blacklist mb862xxfb
blacklist neofb
blacklist pm2fb
blacklist pm3fb
blacklist s3fb
blacklist savagefb
blacklist sisfb
blacklist tdfxfb
blacklist tridentfb
blacklist vt8623fb

cat /etc/modprobe.d/matrix-blacklist.conf

Code: Select all

blacklist adxl34x
blacklist adxl34x_i2c
blacklist bmp085
blacklist dht11
blacklist fbtft_device
blacklist leds_pwm
blacklist matrix_ads7846
blacklist matrix_gpio_int
blacklist matrix_hcsr04
blacklist matrix_ir_recv
blacklist matrix_pwm
blacklist matrix_rotary_encoder
blacklist pcf8591
blacklist rtc_ds1307
blacklist w1-gpio
blacklist w1-gpio-board

• Serial console. if systemctl disable serial-getty@ttySAC0.service has no effect, I believe this may be hard coded as enabled in the /boot binary files. Cant see any config files we can edit. So not much we can do this about this for now.

I think that not all hope is lost: For testing purpose, I had already successfully changed and repackaged the initramfs in file /boot/root.img.gz in order to avoid the call to resize2fs, so I can also have a look whether I can find anything that is responsible for the serial console to be activated on every boot and comment it out...

Many thanks so far, I will report back shortly - as time permits - regarding Bluetooth and serial console in initramfs.

Best,
awl

[Fourdee]

I feel like we should even remove them fully instead of simply disabling them:

Yep agree. I also found these services on the NanoPi M2 image (based on FriendlyARM). I'll add a patch to remove them during dietpi-update on both M2 and M3 images.

Code: Select all

rm /lib/systemd/system/lcd4linux.service
rm /lib/systemd/system/hwservice.service
rm /lib/systemd/system/hwservice_monitor.service
systemctl daemon-reload

WiFi: Yes, Bluetooth: No.

WiFi, excellent.
I've added the module (bcmdhd) to the dietpi-set_hardware wifi script. So when wifi is disabled, the module wont be loaded into memory.

Many thanks so far, I will report back shortly - as time permits - regarding Bluetooth and serial console in initramfs.
Excellent, no rush, great work

[awl29]

Hi again,

I also found these services on the NanoPi M2 image (based on FriendlyARM). I'll add a patch to remove them during dietpi-update on both M2 and M3 images.

Code: Select all

rm /lib/systemd/system/lcd4linux.service
rm /lib/systemd/system/hwservice.service
rm /lib/systemd/system/hwservice_monitor.service
systemctl daemon-reload

There are even more systemd services that must be removed, as they address non-existing devices:

Code: Select all

rm /etc/systemd/system/getty.target.wants/serial-getty@ttyAMA0.service
rm /etc/systemd/system/getty.target.wants/serial-getty@ttySAC2.service
rm /etc/systemd/system/getty.target.wants/serial-getty@ttyS0.service

I will report back shortly - as time permits - regarding Bluetooth and serial console in initramfs.

OK, so after two days of digging really deep into the pitfalls of Broadcom Bluetooth device initialisation (the NanoPi-M2/NanoPC-T2 and NanoPi-M3/NanoPC-T3 both use a combination of AP6212/BCM43438), I have good news: I have finally managed to find out how to reliably initialize and attach Bluetooth on the NanoPi/NanoPC devices!

For the full nasty details , please see my thread over on the FriendlyARM forums: http://www.friendlyarm.com/Forum/viewto ... p=958#p958 and its file attachment "nanopi_bluetooth_fix.tar.bz2": http://www.friendlyarm.com/Forum/downlo ... .php?id=23.

With regards to DietPi for the NanoPi-M3/NanoPC-T3, this means that I will update "my" image soon to include the steps as described in my posting. Please note that you may want to do the same for your image for NanoPi-M2/NanoPC-T2 in order to get a working Bluetooth for this SoC as well.

And finally, regarding serial console: I have now found that it is not initramfs, but the u-boot default environment "bootargs" variable containing a kernel parameter "console=ttySAC0,115200,8n1" that causes a serial console to be created on every boot, and disabling serial console from DietPi to fail.

Unfortunately, I think that there is not much that we can do about this in a DietPi image, as the u-boot environment seems to be stored directly on the device in NVRAM and not on the DietPi SD card. So I think that every NanoPi2/NanoPi3 owner will have to remove this on his own to disable serial console.

Base line:
I would like to rebuild "my" image one more time to include all changes mentioned so far, and to incorporate the new September Debian image by FriendlyARM (my previous DirectPi image was still based on their June Debian image). What would be the best time to do so? Right now, again based on v131, or would you like me to wait for your next release?

Thanks & best regards,
awl

[Fourdee]

What would be the best time to do so? Right now, again based on v131, or would you like me to wait for your next release?

If you use the master branch (default stable), you can do the image at anytime. DietPi will always update to the latest version on 1st run. So if there are any additional "fixes" we need to add, that can be done easily and before the image is released to the public.

OK, so after two days of digging really deep into the pitfalls of Broadcom Bluetooth device initialisation (the NanoPi-M2/NanoPC-T2 and NanoPi-M3/NanoPC-T3 both use a combination of AP6212/BCM43438), I have good news: I have finally managed to find out how to reliably initialize and attach Bluetooth on the NanoPi/NanoPC devices!

Great work, although sounds like a nightmare few days lol.

I'll try your fix with the NanoPi M2, and, the BPi M2+ (has a AP6212 chip).

variable containing a kernel parameter "console=ttySAC0,115200,8n1" that causes a serial console to be created on every boot, and disabling serial console from DietPi to fail.

Yep no worries. If the option isn't available as a var we can change on the fly, not much we can do about it. If we start having to compile various kernels/uboot just to toggle 1 option, we would dig ourselves into a never ending loop.

Ok, great stuff. I'll take a look at the bluetooth/wifi fix you made.

[awl29]

Hi again,

unforeseen problems:

I would like to rebuild "my" image one more time to include all changes mentioned so far, and to incorporate the new September Debian image by FriendlyARM (my previous DirectPi image was still based on their June Debian image).

I have done so and used the exact same prepping script (especially with regards to the "apt-get purge" commands) on the FriendlyARM September Debian Jessie image that I had previously used on the June image, but at the end of the script, I have much more space still being occupied on the rootfs (nearly 600M) than I had on the June Debian Jessie image (immediately before calling finalise):

Code: Select all

root@NanoPi3:~# df -kv
Filesystem     1K-blocks   Used Available Use% Mounted on
/dev/mmcblk0p2   3683736 595496   3088240  17% /
udev              434004      0    434004   0% /dev
tmpfs              87236   5244     81992   7% /run
tmpfs             436164      0    436164   0% /dev/shm
tmpfs               5120      0      5120   0% /run/lock
tmpfs             436164      0    436164   0% /sys/fs/cgroup
/dev/mmcblk0p1     64496  21340     43156  34% /boot
tmpfs              87236      4     87232   1% /run/user/1000
tmpfs              87236      0     87236   0% /run/user/0

"apt-get clean", "apt-get update", "apt-get upgrade" and "apt-get -y --purge autoremove" report that they won't change anything...

Can you please look into the attached "dpkg -l" output one more time, and tell me what still needs to be uninstalled?

Thanks a million in advance & best regards
awl

[Fourdee]

600MB, ouch lol.

Overall looks fine. Maybe a few additions that we can remove.

Ok so these can be removed.
But double check deps and if additional items would be removed. If unsure, paste list here:

Code: Select all

apt-get purge dconf-gsettings-backend dconf-service libfm-* libsecret-* vim-common vim-tiny

You can check whats using the largest sizes with:

Code: Select all

cd /
treesize

Then follow the chain/folders until you find a culprit

example:

Code: Select all

root@DietPi:/# cd /
root@DietPi:/# treesize

du: cannot access ‘./proc/2848/task/2848/fd/3’: No such file or directory
du: cannot access ‘./proc/2848/task/2848/fdinfo/3’: No such file or directory
du: cannot access ‘./proc/2848/fd/4’: No such file or directory
du: cannot access ‘./proc/2848/fdinfo/4’: No such file or directory
1.1 GB .
595.2 MB ./mnt
201.5 MB ./usr
143.5 MB ./lib
106.9 MB ./var
22.3 MB ./boot
7.9 MB ./bin
6.8 MB ./sbin
6.4 MB ./run
4.8 MB ./opt
3.4 MB ./etc
1.2 MB ./DietPi
28.0 KB ./root
16.0 KB ./lost+found
4.0 KB ./srv
0.0 KB ./tmp
0.0 KB ./sys
0.0 KB ./proc
0.0 KB ./dev

root@DietPi:/# cd usr
root@DietPi:/usr# treesize

201.5 MB .
105.5 MB ./share
70.9 MB ./lib
21.7 MB ./bin
3.2 MB ./sbin
184.0 KB ./include
44.0 KB ./local
4.0 KB ./src
4.0 KB ./games

[awl29]

Hi,

600MB, ouch lol.

well, when we had ~440MB with the FriendlyARM June build, I think that 600MB with the September build would mean that DietPi did not follow its diet plan...

But double check deps and if additional items would be removed. If unsure, paste list here:

Code: Select all

apt-get purge dconf-gsettings-backend dconf-service libfm-* libsecret-* vim-common vim-tiny

Fine, but frees only an additional 5MB.

You can check whats using the largest sizes with:

Code: Select all

cd /
treesize

Then follow the chain/folders until you find a culprit

Thanks, sorry - I should clearly have suspected other files/locations than Debian packages at the first place...

Ran "du -k /" and indeed found out about a /usr/nexell tree, about additional unmatching kernel modules for s5p4418 and some other files which did not belong there. I also cleared /var/cache and got back to about the level of the FriendlyARM June image...

So stay tuned - there will be hopefully a new build by the end of tomorrow (Mon)...

Thanks & best regards
awl

[Fourdee]

So stay tuned - there will be hopefully a new build by the end of tomorrow (Mon)...

Thanks & best regards
awl

Excellent, great work!

[awl29]

Hi again,

So stay tuned - there will be hopefully a new build by the end of tomorrow (Mon)...

unfortunately, it looks as if we need an update to dietpi-set_hardware in order to properly support Bluetooth:

Currently, the brcm_patchram_plus service was set to be started on boot, but the way that you have set up things means that with modprobe file "disable_bt.conf" active, the firmware upload to the Broadcom device simply can not happen during boot.

Therefore, it looks to me like the most simple way out of this is to start with brcm_patchram_plus service disabled, and only start and enable the service when "dietpi-set_hardware bluetooth enable" is called, and stop and disable things again when "dietpi-set_hardware bluetooth disable" is called.

Please note that I think I have found a small bug: During disable, you'll also need to stop and disable the systemd bluetooth service first, and not only/simply force unload "modprobe -rf" the modules...

I have attached an updated version of dietpi-set_hardware that seems to do the job for me and would like to ask you to integrate this fix into v134. I will only then create a new build, as otherwise, I cannot make Bluetooth work out-of-the-box.

I have also found out that - specifically for DietPi (not needed for plain Debian or Ubuntu) - I need to remove the dependency of the systemd "brcm_patchram_plus.service" to "syslog.service", because a systemd service for logging does not seem to exist with DietPi - am I correct?

If you find some time, can you please also check whether (with an updated service file as stated above) my brcm_patchram_plus service does indeed also make Bluetooth work for NanoPi-M2/NanoPC-T2 (and possibly, BPi M2+ as you mentioned)?

Thanks & best regards
awl