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

Requests
41

Oh, and I nearly forgot about the following (another small issue):

In my setup, I have no USB mass storage device connected (yet) to my NanoPC-T3 (only SD/mmc). The current default fstab is set up to have /mnt/usb_1 enabled as type autofs, and this causes all attempts to access this directory to completely hang (I noticed this when running “du -k /”) the shell/tty, because autofs seems to think it can mount “something” (even though there is no mass storage connected to my USB ports) while it indeed must not - and hangs on accessing the mount path… :frowning:

So for my image, I have patched /etc/fstab to comment out the line for /mnt/usb1 (as default).

Best
awl

42

Yes, this can happen.

We use the x-systemd.automount feature to allow the user to have 1 USB drive automatically mounted, without any need for configuration changes.
Its also used for automatic mounting when using the dietpi-drive_manager. All those usb_x entries are enabled when the script is run, then disables any unactive drive mounts at exit.

The downside is, if usb_1 is not attached, systemD will hang all commands that involve the target /mnt/usb_1. so ls -lha /mnt/usb_1 will hang in a endless loop.
I’ve been unable to find a timeout option or any workarounds, without disabling the mount entirely.

43

Hi Awl,

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…

Good find, great job :slight_smile:

Great work on adding that code in! I’ve sent to GitHub and your changes are available on the testing branch: v134 · Fourdee/DietPi@be35964 · GitHub

Notes:
Diff (left = current): https://www.diffchecker.com/LqBaadPQ

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?

Only remove it if it causes “brcm_patchram_plus.service” to fail, if “syslog.service” is not started/available.
DietPi-Ramlog has an option to have full logging which installs rsyslog. So our users can add/remove syslog to their system at any time.

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)?

Yep, I’ve made a note :wink:, will test when I can.





Notes:

root@DietPi:~# cat /lib/systemd/system/brcm_patchram_plus.service
[Unit]
Description=brcm_patchram_plus
Before=bluetooth.service hwservice.service hwservice_monitor.service

[Service]
Type=oneshot
ExecStart=/etc/init.d/brcm_patchram_plus start
ExecStop=/etc/init.d/brcm_patchram_plus stop
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
Alias=brcm_patchram_plus.service




root@DietPi:~# cat /etc/init.d/brcm_patchram_plus
#!/bin/bash

### BEGIN INIT INFO
# Provides:             brcm_patchram_plus
# Required-Start:       $remote_fs $syslog
# Required-Stop:        $remote_fs $syslog
# Default-Start:        2 3 4 5
# Default-Stop:
# Short-Description:    brcm_patchram_plus
### END INIT INFO


case "$1" in
    start|"")
      if [ -d /sys/class/rfkill/rfkill0 ]; then
        rfkill block 0
        rfkill unblock 0
        chmod 0660 /sys/class/rfkill/rfkill0/state
        chmod 0660 /sys/class/rfkill/rfkill0/type
        chgrp dialout /sys/class/rfkill/rfkill0/state
        chgrp dialout /sys/class/rfkill/rfkill0/type
        MACADDRESS=`md5sum /sys/devices/platform/cpu/uuid | cut -b 1-12 | sed -r ':1;s/(.*[^:])([^:]{2})/\1:\2/;t1'`
        echo $MACADDRESS > /tmp/brcm_mac.txt
        /bin/brcm_patchram_plus -d --patchram /lib/firmware/ap6212/bcm43438a0.hcd --enable_hci --bd_addr $MACADDRESS --no2bytes --tosleep 5000 /dev/ttyAMA1
      fi
        ;;

    stop)
        kill `ps --no-headers -C brcm_patchram_plus -o pid`
        ;;
    *)
        echo "Usage: brcm_patchram_plus start|stop" >&2
        exit 3
        ;;
esac
44

Hello again,

thank you, the patch is working fine for me.

But please be warned that on NanoPi-M2/NanoPC-T2 and NanoPi-M3/NanoPC-T3 (and probably also on the BananaPi using AP6212), you will also need to add the files from my Bluetooth patch tarball (i.e. /bin/bumpRTSCTS, /bin/brcm_patchram_plus, /etc/init.d/brcm_patchram_plus, /lib/systemd/system/brcm_patchram_plus.service) to the respective image.

I will do so for my NanoPi-M3/NanoPC-T3 image, but I will wait for the official release of v134 (including the above change) before I rebuild my image based on the final v134 release. Otherwise, my image would be “mostly” v133 with one file from v134 and not be based on an officially released DietPi version, which could create confusion about the exact versions of files included in the image and cause trouble on subsequent DietPi updates.

It is indeed necessary to remove the references (After, Requires) to the syslog service - changing “Requires” to “Wants” does not help, as even “Wants” causes brcm_patchram_plus service not to be started even though enabled, as no syslog service is running…

Please be warned that the code as listed above is outdated (IIRC, this is the original defunct code that FriendlyARM included with their image) and will not work. When looking into fixing the Bluetooth issue, please use the code from my updated tarball at the FriendlyARM forum:
http://www.friendlyarm.com/Forum/viewtopic.php?f=44&t=312#p958
and edit the systemd service description “brcm_patchram_plus.service” to remove all dependencies to the syslog service (After and Requires) - note that this change is only needed for DietPi, where no syslog service exists by default. The tarball is correct for Debian and Ubuntu.

Looking forward to the release of v134 (do you already have a target date?)…

Best,
awl

45

Looking forward to the release of v134 (do you already have a target date?)…

No date set at the moment. Been working alot on RPi Stretch support. You can track milestone progress here https://github.com/Fourdee/DietPi/milestone/35

I’ll probably release v134 as soon as your image is ready. Could be a few days delay, depends if any bug reports are sent in the mean time that need investigating. Either way, I can shuffle tickets around if needed to release v134.

Ran out of time today (apologies), so, I’ve made a note, will go through your post in detail tomorrow and get back to you with a full response.

46

No worries - there is no real need to hurry! :wink:

I have a working DietPi installation on my SD card (that I used for testing) for the meantime, and the new final NanoPC-T3 v134 image (which is “ready” except that I need the DietPi v134 files from the master branch) can perfectly wait until you’re finished with the release…

Best regards
awl

47

Ok uploaded your BT patch with syslog removed, to http://dietpi.com/downloads/binaries/all/ap6212_bt_patch.7z. It will be applied to T2 image (and M2, shared) during v134 update (under patch_file):
https://github.com/Fourdee/DietPi/commit/a30eca4485841020a5f2cd5649675881af2101d5

NanoPi M2 doesn’t have any wifi/bt chip, so i’ll test on BPi M2+ ap6212.

48

Thank you - that’s good news :smiley:

When testing on BPi M2+, please be warned that you most probably need to change the BT UART device port to something different from /dev/ttySAC1 (on the NanoPC-T series, the second UART port is used for Bluetooth).

Have a nice weekend!
awl

49

Legend, thanks :slight_smile:

Ok so, I’ll aim to get v134 wrapped up and released over the weekend. I’ll let you know when its done and ready for you to create the final image.

Have a nice weekend!

You too :slight_smile:

50

awl:

v134 is released. Good to go for creating your image on master branch :slight_smile:

EDIT: I’ve made various changes to the system prep file since we started this, so if your using your own script, you may need to update it: https://github.com/Fourdee/DietPi/blob/master/PREP_SYSTEM_FOR_DIETPI.sh

51

Great, thank you! :smiley:
Will probably try and get this done tomorrow, so stay tuned for an update here and in your Dropbox folder on Tuesday morning… :wink:

Will definitely double-check for any changes and update my specific script for NanoPi3.

One more time, many thanks for your great support in getting DietPi ported to my device!

Best,
awl

52

Phew - v134 image for NanoPi-M3/NanoPC-T3 successfully created and uploaded to your Dropbox. Wifi and Bluetooth working fine.

But still two small issues:
a) new timing issue with dietpi-banner on tty1 being called too early after each boot, i.e. before the eth0 link becomes ready (IP address not yet available) - have not seen this with the kernel from the FriendlyARM June image
b) I probably need to update the initramfs to include fsck.ext4 and force a fsck after resize, as resize2fs consistently results in corrupt size counts after expanding the root filesystem, which will cause bad corruption on the long run… :frowning:

So unfortunately this still is not the final image. Will try to resolve b) myself. But what shall we do with regards to a)?

Thanks & best regards,
awl

53

Hi,

Not much we can do with A. Unless we delay the boot (which i’am not keen on) to wait for DHCP ack to finish, before we launch the banner.
No IP wont occur all the time in banner, it really depends on the users network and how quickly DHCP offers are acknowledged by their router.
Personally, if the user is watching tty1, its most likely they are setting up the device locally, rather than over SSH. In which case, not knowing the IP at that time shouldn’t be an issue.

as resize2fs consistently results in corrupt size counts after expanding the root filesystem

Is this when DietPi does the resize on 1st run?

54

Fine. If you are ok with this, I clearly am. :wink:

Yes, exactly. I will try to create a script that does the job of patching /boot/root.img.gz (initramdisk - have already located where it executes resize2fs), such that you can also apply it to the NanoPi-M2/T2 image (for which I am almost 100% certain it will also be needed).

Will report back later tonight.

Best,
awl

55

Ouch,

this took much more time than anticipated… :cry:

Findings:

  • Debian Jessie comes with e2fsprogs 1.42.12-2 (Debian -- Error)
  • resize2fs in “offline” mode (i.e. doing the resize while the partition is not mounted) is clearly buggy in 1.42.12, but possibly even in the most recent 1.43.3 (http://e2fsprogs.sourceforge.net/)
  • fsck.ext4 as of 1.42.12 does NOT even uncover the “size count” inconsistency directly after resize2fs, but only after some write access to the SD card and a subsequent reboot.
  • I then tried to update the initramfs with most recent 1.43.3 e2fsprog binaries. Seemed to work fine, but the build/initramfs update was complex, and also I did not want to include more recent e2fsprogs binaries into the root filesystem image than the Debian release it builds on…
  • Only then, I found out about the “live”/“online” mode of resize2fs which was said to be much simpler (and less error-prone) in terms of resize algorithm (see the quote by Theodore Ts’o below: Re: resize2fs: Should never happen: resize inode corrupt! - lost key inodes (Linux Ext4)). Completely sufficient for our scenario, and much easier! :sunglasses:
  • I have now patched the initramdisk file to use online resizing and additionally force a file system check afterwards, while staying with Debian release version 1.42.12-2
  • From my testing, I could not reproduce any more “size count” corruptions with this setup (but I’ve only tested with two different SD cards (8GB and 64GB)


So I have now uploaded my final v134 build of DietPi (including the patched initramfs) to your Dropbox Shared Folder (md5sum included). Feel free to release it any time you like (maybe in beta at first until we have some reports from other users that it also works fine for them?)… :wink:

I have also uploaded the script that I used to patch the initramfs to the Dropbox, as I think you should also apply it to your NanoPi-M2/NanoPC-T2 image, which most probably uses the same initramdisk file (/boot/root.img.gz). Call the script as follows:

nanopi_fix_initramfs.sh <path-to-root-img.gz>

providing the compressed ramdisk image as the single parameter. The script will backup the original file (to end with “.orig”) and patch the initramdisk file in place in the same directory.

Finally, I have also uploaded a terminfo file that you may want to install using “tic” which resolves the issue of an invisible softcursor in any NanoPi/NanoPC framebuffer text console (“tput cnorm” to activate, can be nicely put into a script in /etc/rc.local.d).

Thanks again for your support in making DietPi run on my device! :smiley:

Best regards
awl

56

Sorry - bad news:

Please be warned that the NanoPC-T3 build still cannot be considered final:

Trying to move my DietPi install from SD card to the built-in emmc, one more time, I ran into resize2fs issues, this time with online resizing: :roll_eyes:

resize2fs 1.42.12 (29-Aug-2014)                                                 
Filesystem at /dev/mmcblk0p2 is mounted on /root; on-line resizing required     
old_desc_blocks = 1, new_desc_blocks = 1                                        
Performing an on-line resize of /dev/mmcblk0p2 to 1892096 (4k) blocks.          
resize2fs: Invalid argument While trying to add group #25      
resize2fs exited with status code 1




[  163.892000] EXT4-fs warning (device mmcblk0p2): reserve_backup_gdb:882: reserved block 128 not at offset 127
[  164.216000] EXT4-fs warning (device mmcblk0p2): reserve_backup_gdb:882: reserved block 128 not at offset 127
[  197.584000] EXT4-fs warning (device mmcblk0p2): reserve_backup_gdb:882: reserved block 128 not at offset 127
[  197.712000] EXT4-fs warning (device mmcblk0p2): reserve_backup_gdb:882: reserved block 128 not at offset 127

I will now try to update the initramfs with the most recent e2fsprogs - hoping that a current 1.43.3 dated Sept, 2016 fixes the issue (1.42.12 is dated Aug, 2014)… :face_with_raised_eyebrow:

Will report back shortly about my progress…
awl

57

this took much more time than anticipated… > :cry: >

Yep, it happens lol :slight_smile:
Looks like you got one of the worst to implement so far, Rhkean did our Pine A64 which was also a nightmare, lots of little issues kept cropping up.

Wish I could help (let me know how I can), but you seem to have it covered, hopefully not far till the end now :slight_smile:

58

OK, so I finally think I know what is going on here, and the root cause is FriendlyARM’s imaging process:

Have a look at this thread: https://lists.96boards.org/pipermail/dev/2016-January/000715.html

So the resize issue is caused by the fact that FriendlyARM, in the same way like people in the thread cited above, seem to use Android’s make_ext4fs tool to create ext4 sparse images, when they should rather use mkfs.ext4 plus ext2simg… :frowning:

My take on this so far is: Due to FriendlyARM having used the “wrong” (i.e., buggy) tool to create the root file system, the root file system of the FriendlyARM Debian image (which I have based my DietPi image on) was already non standard compliant (aka corrupt) from the very beginning, even though fsck.ext4 does not report any issues, but later attempts to resize2fs an image after lots of write accesses clearly uncovered them… Ouch! :roll_eyes:

I will now try to validate this theory (using fsarchiver to backup and restore FriendlyARM’s rootfs.img content into a new partition created by the “real” mkfs.ext4), and then make a sparse image from this, and see whether the resulting ext4 image can be used by resize2fs in both online and offline mode without issues.

Unfortunately, that would mean that most probably, the NanoPi-M2/NanoPC-T2 image is affected by the exact same issue. Have you seen any issues with it during file system resize (resize2fs) before? :thinking:

Stay tuned - I hope to have a truly valid image by the end of tomorrow… :wink:

Have a nice Sunday!
awl

59

Have you seen any issues with it during file system resize (resize2fs) before?

Not on the NanoPi M2, works every-time for me. For other boards, its only when PSU/SD card isn’t up to the job.

Just wondering if would be a “better” route to build the image from scratch, eg: http://wiki.friendlyarm.com/wiki/index.php/NanoPi_M3#Make_Your_Own_OS_Image?

60

Hard to believe, as I strongly doubt that they use mkfs.ext4/ext2img to create the S5P4418 image, and the buggy make_ext4fs to create the S5P6818 image…

And while I agree that read/write errors or kernel hangs/oops point to faulty SDs, any of the two types of errors that I have seen clearly points to software issues:

resize2fs: Invalid argument While trying to add group #25




[  197.712000] EXT4-fs warning (device mmcblk0p2): reserve_backup_gdb:882: reserved block 128 not at offset 127

Have you tried different size SD cards? The issue I uncovered gets more likely (1) the larger the target partition (SD/EMMC) is and (2) the more write accesses you made between image install and resize.

Unfortunately, fsck.ext4 even in the most recent release, is unable to detect the “non-conformance” (aka corruption) of the resulting file system - you will only notice on the attempt to resize (resize2fs) - or possibly fatal corruption only after quite some time when you happened to fill the filesystem close to its capacity… :cry:

The wiki headline is misleading: They talk about compiling u-boot and kernel on your own, but not the rootfs image (with device tree and Debian arm base image). In order to make this a full image, I would exactly have to copy an existing Debian root file system infrastructure from “somewhere”, so IMHO fsarchiver clearly is the way to go…

Best,
awl