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

[awl29]

I'm happy to repeat these actions to create an official image once the HW_MODEL changes have been published in git, and then provide the resulting image file.

Would be great if you could. Who am I giving credit to in changelog (eg: name you want me to use)?

I don't think that I've really done that much to receive explicit credit. In case you really feel like you need to mention me, please simply use "awl" or "awl29" (without a full real name).

Looks like your right, T2 vs M2 main differences I can see are:
- T2 + EMMC
- T2 + Bluetooth

Aside from that same boards. I've updated M2 references to include M2/T2.

And another difference in naming: While the "M" models are called NanoPi, the "T" models are called NanoPC, so you may want to change the models' long description texts one more time...!?

HW_MODEL code is done: https://github.com/Fourdee/DietPi/commi ... aab3aeec21
You'll need to download: https://raw.githubusercontent.com/Fourd ... n_hw_model and overwrite it on your image /boot/dietpi/dietpi-obtain_hw_model

Yup, I know. I had already done so in my image with which I was able to successfully boot DietPi.

Regarding the full model patch for NanoPi3, would it be possible for you to please also modify the finalise script until Wednesday: It must be changed in a way that it also post-processes /etc/fstab in order not to end up with an unbootable system (an unpatched finalise script for HW_MODEL=62 currently ends up with a boot partition of type vfat and resulting boot failure).

Also, I've already noted some issue with serial console, which I seem to be unable to switch between disabled and enabled state.

Finally, the tty1 console does not seem to have a getty spawned (no login prompt after the last kernel boot log message), while virtual consoles tty2 up to tty6 do exist and show a login prompt, even though only tty1 and tty2 should really exist. Will look into this on Wednesday or later when I have more time...

Thanks again for your help in putting me on track quite fast

Best,
awl

[Fourdee]

While the "M" models are called NanoPi, the "T" models are called NanoPC, so you may want to change the models' long description texts one more time...!?

Its mainly a visual thing.
We need to use short descriptions, so the dietpi-banner lines fit on single lines with 320x240 > displays. The purple lines are the max width in 320xXXX

Untitled.png (8.84 KiB) Viewed 5956 times

Regarding the full model patch for NanoPi3, would it be possible for you to please also modify the finalise script until Wednesday: It must be changed in a way that it also post-processes /etc/fstab in order not to end up with an unbootable system (an unpatched finalise script for HW_MODEL=62 currently ends up with a boot partition of type vfat and resulting boot failure).

Done. But with a twist.
We now use the auto filesystem type in /etc/fstab. So we never have to define it
Heres the updated fstab file https://github.com/Fourdee/DietPi/blob/ ... stab#L3-L4

Also, I've already noted some issue with serial console, which I seem to be unable to switch between disabled and enabled state.

Are there any "other" config files in /boot/* that are not dietpi.txt or config.txt?

Finally, the tty1 console does not seem to have a getty spawned (no login prompt after the last kernel boot log message), while virtual consoles tty2 up to tty6 do exist and show a login prompt, even though only tty1 and tty2 should really exist. Will look into this on Wednesday or later when I have more time...

Strange, never experienced this myself, try:

Code: Select all

systemctl enable getty@tty[1-2].service
systemctl disable getty@tty[3-6].service
reboot

[awl29]

Hello again,

We need to use short descriptions, so the dietpi-banner lines fit on single lines with 320x240 > displays.

Ah, I see... Ouch...

We now use the auto filesystem type in /etc/fstab. So we never have to define it
Heres the updated fstab file https://github.com/Fourdee/DietPi/blob/ ... stab#L3-L4

Great - thanks!

Are there any "other" config files in /boot/* that are not dietpi.txt or config.txt?

No, none.

Strange, never experienced this myself, try:

Code: Select all

systemctl enable getty@tty[1-2].service
systemctl disable getty@tty[3-6].service
reboot

Bingo - that resolved this one!

Good news: I have now created the following alpha build based on the current state of the v131/git "testing" branch:

Code: Select all

-rw-r--r--   1 root  root   84378941 Sep 16 00:00 DietPi_NanoPiM3T3-armv7-(Jessie).7z

Code: Select all

Listing archive: DietPi_NanoPiM3T3-armv7-(Jessie).7z

--
Path = DietPi_NanoPiM3T3-armv7-(Jessie).7z
Type = 7z
Method = LZMA
Solid = +
Blocks = 1
Physical Size = 84378941
Headers Size = 234

   Date      Time    Attr         Size   Compressed  Name
------------------- ----- ------------ ------------  ------------------------
2016-09-15 23:55:05 ....A         6372     84378707  README.md
2016-09-15 23:57:15 ....A    540016640               DietPi_v131_NanoPiM3T3-armv7-(Jessie).img
------------------- ----- ------------ ------------  ------------------------
                             540023012     84378707  2 files, 0 folders

From cursorily testing, it looks ok!

Although with one small known issue:
I still can neither disable the serial console nor switch it from disabled to enabled nor vice-versa.
How can I debug the menu scripts/files? There seems to be some error messages when I select Enable/Disable, but I am unable to read them as they are displayed only for a few milliseconds before the screen gets blue again and the menu window displayed.

Where do you want me to upload the 7z file? Please advise!
Or should I rather wait until you officially released v131, and then rebuild from the real "master" branch as soon as v131 has been integrated?

Thanks & best regards,
awl

[Fourdee]

Hi awl,

Great work, looks good

Or should I rather wait until you officially released v131, and then rebuild from the real "master" branch as soon as v131 has been integrated?

Although your 1st image is probably fine, it wouldn't be a bad idea, just to make sure there are no "kinks". Hoping to release v131 Sunday, so that would be the perfect time to recreate the image if you are able to?
If you do this, make sure you use the current system prep script,https://github.com/Fourdee/DietPi/blob/ ... _DIETPI.sh

As I made some changes (mainly the auto filesystem mounts for /boot): https://github.com/Fourdee/DietPi/commi ... _DIETPI.sh

I still can neither disable the serial console nor switch it from disabled to enabled nor vice-versa.
How can I debug the menu scripts/files? There seems to be some error messages when I select Enable/Disable, but I am unable to read them as they are displayed only for a few milliseconds before the screen gets blue again and the menu window displayed.

Try running the function script itself:

Code: Select all

/DietPi/dietpi/func/dietpi-set_hardware serialconsole enable
/DietPi/dietpi/func/dietpi-set_hardware serialconsole disable

It should result in:

Where do you want me to upload the 7z file? Please advise!

I'll setup a dropbox share for the upload, if you could email me daniel.knight@dietpi.com with a simple "hello, give dropbox", i'll set one up

[awl29]

Hello Fourdee,

Although your 1st image is probably fine, it wouldn't be a bad idea, just to make sure there are no "kinks". Hoping to release v131 Sunday, so that would be the perfect time to recreate the image if you are able to?
If you do this, make sure you use the current system prep script,https://github.com/Fourdee/DietPi/blob/ ... _DIETPI.sh

I will definitely do so in order to ensure that the image becomes official and contains a released state, although I'd still consider it beta state due to potential other issues like with the serial console (see below) that you maybe want to address before releasing v131.

I still can neither disable the serial console nor switch it from disabled to enabled nor vice-versa.
How can I debug the menu scripts/files? There seems to be some error messages when I select Enable/Disable, but I am unable to read them as they are displayed only for a few milliseconds before the screen gets blue again and the menu window displayed.

Try running the function script itself

Done, my output is:

Code: Select all

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

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

Failed to execute operation: Invalid argument
 [Ok] serialconsole enable | Completed

root@DietPi:~# sh -x /DietPi/dietpi/func/dietpi-set_hardware serialconsole enable
/DietPi/dietpi/func/dietpi-set_hardware: 407: /DietPi/dietpi/func/dietpi-set_hardware: Syntax error: "(" unexpected (expecting "}")
root@DietPi:~#

This means that you need to check the brackets in this file in v131 - it may be corrupt!?

I now moved the "-x" to the first line of the script: "#!/bin/bash -x" in order to see more:

Code: Select all

root@DietPi:~# /DietPi/dietpi/func/dietpi-set_hardware serialconsole enable     + LANG=en_GB.UTF-8
++ echo -e serialconsole
++ tr '[:upper:]' '[:lower:]'
+ INPUT_DEVICE_NAME=serialconsole
++ echo -e enable
++ tr '[:upper:]' '[:lower:]'
+ INPUT_DEVICE_VALUE=enable
+ '[' enable = 1 ']'
+ '[' enable = 0 ']'
+ EXIT_CODE=0
++ sed -n 1p /DietPi/dietpi/.hw_model
+ HW_MODEL=62
++ sed -n 3p /DietPi/dietpi/.hw_model
+ DISTRO=3
+ PANEL_UPDATE_DIETPITXT=0
+ /DietPi/dietpi/func/dietpi-notify 3 DietPi-Set_Hardware 'serialconsole (enable)'

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

+ '[' serialconsole = soundcard ']'
+ '[' serialconsole = serialconsole ']'
+ Serial_Main
+ '[' enable = enable ']'
+ systemctl enable serial-getty@.service
[b][color=#FF0000]+ systemctl enable serial-getty@ttyAMA0.service
Failed to execute operation: Invalid argument[/color][/b]
+ systemctl enable serial-getty@ttySAC2.service
+ systemctl enable serial-getty@ttyS0.service
+ ((  62 < 10  ))
+ ((  62 == 10  ))
+ ((  62 == 11  ))
+ ((  62 == 12  ))
+ ((  62 >= 40 && 62 < 50  ))
+ sed -i '/^serial_console_enabled=/c\serial_console_enabled=1' /DietPi/dietpi.txt
+ /DietPi/dietpi/func/dietpi-notify -1 0 'serialconsole enable |'
 [Ok] serialconsole enable | Completed

+ exit 0

OK, so even more issues with this on NanoPi3:

• The serial console device is called /dev/ttySAC0 on this device, not ttySAC2
• systemctl returns "Invalid argument" for ttyAMA0 (even though the device /dev/ttyAMA0 as such exists)
• There are the following systemd services in failed/degraded state

Code: Select all

root@DietPi:~# systemctl --state=failed
  UNIT                      LOAD   ACTIVE SUB    DESCRIPTION
â hwservice.service         loaded failed failed hwservice
â hwservice_monitor.service loaded failed failed hwservice_monitor
â lcd4linux.service         loaded failed failed daemon for driving LCD based displays

As I am a complete newbie to systemd, please advise! As you seem to have access to a NanoPi2, can you please check whether the same issues also exist there (which, IMO, is quite likely)?

Where do you want me to upload the 7z file? Please advise!

I'll setup a dropbox share for the upload, if you could email me daniel.knight@dietpi.com with a simple "hello, give dropbox", i'll set one up

Done!

Thanks again & best regards
awl

[Fourdee]

Code: Select all

root@DietPi:~# sh -x /DietPi/dietpi/func/dietpi-set_hardware serialconsole enable
/DietPi/dietpi/func/dietpi-set_hardware: 407: /DietPi/dietpi/func/dietpi-set_hardware: Syntax error: "(" unexpected (expecting "}")

Bash and Shell scripts are two different programs. So expected result: http://stackoverflow.com/questions/5725 ... h-and-bash
DietPi is all /bin/bash
Although the array init could be =0, then generate the array, i'll take a look.

Code: Select all

root@DietPi:~# systemctl --state=failed
  UNIT                      LOAD   ACTIVE SUB    DESCRIPTION
â hwservice.service         loaded failed failed hwservice
â hwservice_monitor.service loaded failed failed hwservice_monitor
â lcd4linux.service         loaded failed failed daemon for driving LCD based displays

Not sure what these are, try running the following to get more information:

Code: Select all

systemctl status hwservice.service -l
systemctl status hwservice_monitor.service -l
systemctl status cd4linux.service -l

The serial console device is called /dev/ttySAC0 on this device, not ttySAC2

Aha! Lets see if this has any effect on the serial console. Please try running:

Code: Select all

systemctl enable serial-getty@ttySAC0.service
reboot
ps aux > /root/attach_enabled.txt

Then same again with disable:

Code: Select all

systemctl disable serial-getty@ttySAC0.service
reboot
ps aux > /root/attach_disabled.txt

You should have two files in /root (attach_*.txt), please copy/paste or attach them.

As you seem to have access to a NanoPi2, can you please check whether the same issues also exist there (which, IMO, is quite likely)?

Doubtful, we use ARMbian to build that image. But i'll make a note to check it either way.

[awl29]

Sorry, I had planned to respond tonight, but I have just found that the SD card in my NanoPC-M3 seems to have crashed, and the image I created last week seems corrupt (partition table has a filesystem size that is much smaller than the correct size in the superblock), so I need to rebuild the image...

Will report back hopefully tomorrow night...

Best,
awl

[Fourdee]

Sorry, I had planned to respond tonight, but I have just found that the SD card in my NanoPC-M3 seems to have crashed, and the image I created last week seems corrupt (partition table has a filesystem size that is much smaller than the correct size in the superblock), so I need to rebuild the image...

Will report back hopefully tomorrow night...

Best,
awl

No worries and no rush, it happens

[awl29]

Hello again,

I have finally found some time to use a proper SD card to rebuild the image - this time based on the official released v131 codebase - and try again:

Bash and Shell scripts are two different programs. So expected result: http://stackoverflow.com/questions/5725 ... h-and-bash
DietPi is all /bin/bash

Oh, I see. Sorry, I should have done "bash -x /DietPi/dietpi/func/dietpi-set_hardware serialconsole enable" (which indeed works fine).

Not sure what these are, try running the following to get more information:

Code: Select all

root@DietPi:~# systemctl status hwservice.service -l
● hwservice.service - hwservice
   Loaded: loaded (/lib/systemd/system/hwservice.service; enabled)
   Active: failed (Result: exit-code) since Thu 2016-09-22 15:25:44 BST; 5h 15min ago
  Process: 591 ExecStart=/etc/init.d/hwservice start (code=exited, status=127)
 Main PID: 591 (code=exited, status=127)

Sep 22 15:25:44 DietPi systemd[1]: Starting hwservice...
Sep 22 15:25:44 DietPi hwservice[591]: /etc/init.d/hwservice: line 16: /usr/sbin/hwservice: No such file or directory
Sep 22 15:25:44 DietPi systemd[1]: hwservice.service: main process exited, code=exited, status=127/n/a
Sep 22 15:25:44 DietPi systemd[1]: Failed to start hwservice.
Sep 22 15:25:44 DietPi systemd[1]: Unit hwservice.service entered failed state.

Code: Select all

root@DietPi:~# systemctl status hwservice_monitor.service -l
● hwservice_monitor.service - hwservice_monitor
   Loaded: loaded (/lib/systemd/system/hwservice_monitor.service; enabled)
   Active: failed (Result: exit-code) since Thu 2016-09-22 15:25:44 BST; 5h 17min ago
  Process: 584 ExecStart=/etc/init.d/hwservice_monitor start (code=exited, status=127)
 Main PID: 584 (code=exited, status=127)

Sep 22 15:25:44 DietPi hwservice_monitor[584]: /etc/init.d/hwservice_monitor: line 16: /usr/sbin/hwservice_monitor: No such file or directory
Sep 22 15:25:44 DietPi systemd[1]: hwservice_monitor.service: main process exited, code=exited, status=127/n/a
Sep 22 15:25:44 DietPi systemd[1]: Failed to start hwservice_monitor.
Sep 22 15:25:44 DietPi systemd[1]: Unit hwservice_monitor.service entered failed state.

Code: Select all

root@DietPi:~# systemctl status lcd4linux.service -l
● lcd4linux.service - daemon for driving LCD based displays
   Loaded: loaded (/lib/systemd/system/lcd4linux.service; enabled)
   Active: failed (Result: exit-code) since Thu 2016-09-22 15:25:44 BST; 5h 17min ago
  Process: 524 ExecStart=/usr/sbin/lcd4linux $ARGS (code=exited, status=127)

Sep 22 15:25:44 DietPi lcd4linux[524]: /usr/sbin/lcd4linux: error while loading shared libraries: libX11.so.6: cannot open shared object file: No such file or directory
Sep 22 15:25:44 DietPi systemd[1]: lcd4linux.service: control process exited, code=exited status=127
Sep 22 15:25:44 DietPi systemd[1]: Failed to start daemon for driving LCD based displays.
Sep 22 15:25:44 DietPi systemd[1]: Unit lcd4linux.service entered failed state.

For the first two, it is very interesting that /usr/sbin/hwservice does indeed exist, but on the NanoPi3 is a dangling relative link:

Code: Select all

root@DietPi:~# ls -l /usr/sbin/hwservice
lrwxrwxrwx 1 root root 6 Jun 29 12:53 /usr/sbin/hwservice -> bin/ls

and of course, /usr/sbin/bin/ls does not exist. But I have no clue why "hwservice" should even link to "/bin/ls"...!?

Regarding the second one, it first looked like at least Debian packages libx11-6, libgd-3, libmysqlclient18 and libpython2.7.so.1.0 (including their dependencies) are missing, as the lcd4linux binary on my NanoPi3 was dynamically linked against those libraries. But even installing all library dependencies did not help - now lcd4linux failed differently:

Code: Select all

root@DietPi:~# systemctl status -l lcd4linux.service
● lcd4linux.service - daemon for driving LCD based displays
   Loaded: loaded (/lib/systemd/system/lcd4linux.service; enabled)
   Active: failed (Result: resources) since Thu 2016-09-22 21:14:16 BST; 3s ago
  Process: 2149 ExecStart=/usr/sbin/lcd4linux $ARGS (code=exited, status=0/SUCCESS)

Sep 22 21:14:16 DietPi LCD4Linux[2151]: LCD2USB: could not find a LCD2USB USB LCD
Sep 22 21:14:16 DietPi LCD4Linux[2151]: Error initializing driver LCD2USB: Exit!
Sep 22 21:14:16 DietPi systemd[1]: PID file /var/run/lcd4linux.pid not readable (yet?) after start.
Sep 22 21:14:16 DietPi systemd[1]: lcd4linux.service never wrote its PID file. Failing.
Sep 22 21:14:16 DietPi systemd[1]: Failed to start daemon for driving LCD based displays.
Sep 22 21:14:16 DietPi systemd[1]: Unit lcd4linux.service entered failed state.

I then noticed that "my" lcd4linux binary was not from Debian, but seemingly from FriendlyARM, as the Debian package "lcd4linux" was not even installed. I then did an "apt-get install lcd4linux", which indeed finally made the errors go away, and the lcd4linux service is now running, but still has suspicious output:

Code: Select all

root@DietPi:~# systemctl status -l lcd4linux.service
● lcd4linux.service - daemon for driving LCD based displays
   Loaded: loaded (/lib/systemd/system/lcd4linux.service; enabled)
   Active: active (running) since Thu 2016-09-22 21:24:59 BST; 54s ago
  Process: 2620 ExecStart=/usr/sbin/lcd4linux $ARGS (code=exited, status=0/SUCCESS)
 Main PID: 2622 (lcd4linux)
   CGroup: /system.slice/lcd4linux.service
           └─2622 /usr/sbin/lcd4linux

Sep 22 21:24:59 DietPi systemd[1]: lcd4linux.service: Supervising process 2622 which is not our child. We'll most likely not notice when it exits.
Sep 22 21:24:59 DietPi systemd[1]: Started daemon for driving LCD based displays.
Sep 22 21:24:59 DietPi LCD4Linux[2622]: widget 'Rain': class 'icon' not supported

Any ideas?

The serial console device is called /dev/ttySAC0 on this device, not ttySAC2

Aha! Lets see if this has any effect on the serial console. Please try running:

Code: Select all

systemctl enable serial-getty@ttySAC0.service
reboot
ps aux > /root/attach_enabled.txt

Then same again with disable:

Code: Select all

systemctl disable serial-getty@ttySAC0.service
reboot
ps aux > /root/attach_disabled.txt

Results attached - the ZIP contains both the enabled and the disabled case.

As you seem to have access to a NanoPi2, can you please check whether the same issues also exist there (which, IMO, is quite likely)?

Doubtful, we use ARMbian to build that image. But i'll make a note to check it either way.

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). But in case you have indeed created the NanoPi2 image from an Armbian build for the Samsung/Nexell S5P4418 SoC, it would also be possible to use this exact build for NanoPi3 - except both the initramfs and the kernels on the /boot partition, which must be specific to S5P6818.

Additional news:
Even though I think the above issues should probably be fixed before the NanoPi3 image becomes official, I have nevertheless uploaded my new v131 master branch image for NanoPi3 to your dropbox. What do you think?

Thanks again, sorry for all those new (but truly minor!) issues & best regards,
awl

[Fourdee]

Hi Awl,

Thanks for the update.
I've not had a chance to go through your full post yet, so i've created a git ticket to remind me. Hopefully get back to you within a few days: https://github.com/Fourdee/DietPi/issues/530