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

Suggestions for features and software you would like to see in DietPi, goes here.
awl29

Re: Request: Support for NanoPC-T3 (very similar to NanoPi-M

Post by awl29 »

Hello again,
k-plan wrote:if device boots up, it will be loaded into a file system in RAM => /DietPi
will be sync when device will shutdown or reboot
Hmm...

So am I correct in that this means all commands in the script PREP_SYSTEM_FOR_DIETPI.sh MUST NOT reference /DietPi (as this filesystem is not yet created)?

On the other hand, many commands at the bottom of PREP_SYSTEM_FOR_DIETPI.sh do indeed reference DietPi scripts from the tmpfs location /DietPi/dietpi...

After digging in a little further, am I correctly assuming that the workflow is as follows:
  • PREP_SYSTEM_FOR_DIETPI.sh copies DietPI's fstab to /etc/fstab (which includes a mount point for /DietPi as tmpfs)
  • The DietPi Service (dietpi-service) is started
  • The service startup calls dietpi-ramdisk, which takes care of copying /boot/dietpi/... to the ramdisk for the very first time
Correct? Pretty hard to figure out - there should at least be some additional hints on how this is supposed to work... ;)

Will have to stop now and call it a day for today, and report back late tomorrow night on my progress... :D

Thanks,
awl
User avatar
Fourdee
Site Admin
Posts: 2788
Joined: Tue Feb 06, 2007 1:36 pm

Re: Request: Support for NanoPC-T3 (very similar to NanoPi-M

Post by Fourdee »

awl29 wrote:
  • PREP_SYSTEM_FOR_DIETPI.sh copies DietPI's fstab to /etc/fstab (which includes a mount point for /DietPi as tmpfs)
  • The DietPi Service (dietpi-service) is started
  • The service startup calls dietpi-ramdisk, which takes care of copying /boot/dietpi/... to the ramdisk for the very first time
Correct? Pretty hard to figure out
Will have to stop now and call it a day for today, and report back late tomorrow night on my progress... :D

Thanks,
awl
This is correct. The RAMDISK isn't created until you run the dietpi-service section.

The script is designed as a start to finish script. Basically, you can follow the script, line by line. The order of the script has been designed as such.

The only things you should look out for are

Code: Select all

cat << _EOF_ /location
#Some kind of wacky commands and stuff
_EOF_
Make sure you copy and paste everything, in one paste, from the the starting cat << _EOF_ to the end _EOF_
If you find our project or support useful, then we’d really appreciate it if you’d consider contributing to the project however you can.
Donating is the easiest – you can use PayPal or become a DietPi patron.
awl29

Re: Request: Support for NanoPC-T3 (very similar to NanoPi-M

Post by awl29 »

Hello again, Fourdee (and/or k-plan),

so I've now indeed successfully arrived at the bottom of PREP_SYSTEM_FOR_DIETPI.sh, where it states

"A Unique HW_MODEL index will need to be assigned and coded into the DietPi sourcecode."

So here is my Unique HW_MODEL Index Request for NanoPi3:

I would assume that a HW_MODEL id of 62 would be appropriate, and HW_MODEL_DESCRIPTION should probably be 'NanoPi3' being kind of the "generic term" used by FriendlyARM themselves for NanoPC-T3 and NanoPi-M3. (Note that you might want to change 'NanoPi M2' for model 61 into 'NanoPi2' as well, as there also are NanoPC-T2 and NanoPi-M2 subsumed under this name.)

Am I correct in that I also need the following as well (in addition to the changes in dietpi-obtain_hw_model):

Code: Select all

echo 62 > /etc/.dietpi_hw_model_identifier
For IMAGE_ADDITIONAL_CREDITS, I'd propose 'FriendlyARM'.

Also, I have noticed that In finalise, you seem to disable serial console - which I think might not be such a good idea, as serial console might be needed in the very beginning to interact with the freshly installed system (e.g. in a no screen, no keyboard, no [or misconfigured] network scenario). When users want to save the last bits and bytes of memory, IMO it would be sufficient to be able to disable it via the config tool.

OK, once I have the HW_MODEL confirmed, I'll then run the finalise script and finally shut down the device in a clean way (shutdown -h now).

Next question is about the next step: "Read image". How do you want me to do this? The whole SD card (8GB in my case) at once, e.g. using Win32DiskImager? Or rather by partition, and from a Linux installation using other tools? And finally, how do you expect me to "Resize 2nd parition to mininum size +50MB"?

Please advise! ;)

So it looks like we might end up with an alpha build (SD card image(s)) once the above questions have been answered. Great!
I myself would finally need to determine in addition how to migrate DietPi from the SD card to the eMMC contained in my NanoPC-T3 (NanoPi-M3 has no such thing), but that's another story...

Thanks a lot for all your work and your kind help! :D

Best regards & have a nice weekend,
awl
awl29

Re: Request: Support for NanoPC-T3 (very similar to NanoPi-M

Post by awl29 »

Oh, and I nearly forgot:

finalise also needs to be patched to post-process fstab to make /boot an ext4 filesystem for model 62, too (in the same way as for $HW_MODEL == 61).

Best,
awl
User avatar
Fourdee
Site Admin
Posts: 2788
Joined: Tue Feb 06, 2007 1:36 pm

Re: Request: Support for NanoPC-T3 (very similar to NanoPi-M

Post by Fourdee »

awl29 wrote: So here is my Unique HW_MODEL Index Request for NanoPi3:
I've create a ticket for this. Hopefully get round to it in the next day or two: https://github.com/Fourdee/DietPi/issues/506
I would assume that a HW_MODEL id of 62 would be appropriate, and HW_MODEL_DESCRIPTION should probably be 'NanoPi3' being kind of the "generic term" used by FriendlyARM themselves for NanoPC-T3 and NanoPi-M3.
Pretty much spot on :)

HW_MODEL_DESCRIPTION will be NanoPC-T3 as per product webpage: http://www.friendlyarm.com/index.php?ro ... uct_id=123
Am I correct in that I also need the following as well (in addition to the changes in dietpi-obtain_hw_model):echo 62 > /etc/.dietpi_hw_model_identifier
Yep, spot on.
For IMAGE_ADDITIONAL_CREDITS, I'd propose 'FriendlyARM'.
We generally don't give credit for official images by manufacture (they should be always be available), but i'll have a think about it.
Next question is about the next step: "Read image". How do you want me to do this? The whole SD card (8GB in my case) at once, e.g. using Win32DiskImager? Or rather by partition, and from a Linux installation using other tools? And finally, how do you expect me to "Resize 2nd parition to mininum size +50MB"?
Read from win32diskimage and zip + upload will be fine.
Or your welcome to try my image resize script:

Code: Select all

#!/bin/bash
{

	#check packages are installed
	if (( ! $(dpkg -l | grep -ci -m1 'gparted') )); then
		apt-get install gparted zerofree -y
	fi

	#-------------------------------------------------------------------------------
	#MUST LEAVE 40MB+ space or automation autologin may fail due to 0 free space!!!
	#-------------------------------------------------------------------------------

	#XU4
	IMAGE_FP="/mnt/samba/#Backups/_Daniel/Projects/DietPi"

	IMAGE_NAME="DietPi-AmiBerry_v130_RPi-armv6-(Jessie)"
	IMAGE_NAME+=".img"

	modprobe loop
	losetup -f
	losetup /dev/loop2 "$IMAGE_FP/$IMAGE_NAME"
	partprobe /dev/loop2

	e2fsck -f /dev/loop2p1
	e2fsck -f /dev/loop2p2

	gparted /dev/loop2

	read -p "If failed press CTRL+C to exit and prevent further action, else, press any key to continue."

	zerofree -v /dev/loop2p1
	zerofree -v /dev/loop2p2

	losetup -d /dev/loop2

	END_PARTITION=$(( $(fdisk -l "$IMAGE_FP/$IMAGE_NAME" | grep ".img2" | awk '{print $3}') + 1 ))
	END_PARTITION=$(( $END_PARTITION * 512 ))

	truncate --size=$END_PARTITION "$IMAGE_FP/$IMAGE_NAME"

	read -p "Done, press any key to continue..."

	exit

}
Either way, i need to update the sourcecode to support this device before hand. I'll let you know when its ready.
finalise also needs to be patched to post-process fstab to make /boot an ext4 filesystem for model 62, too (in the same way as for $HW_MODEL == 61).
Noted, i'll code a FS type check into the script.
If you find our project or support useful, then we’d really appreciate it if you’d consider contributing to the project however you can.
Donating is the easiest – you can use PayPal or become a DietPi patron.
awl29

Re: Request: Support for NanoPC-T3 (very similar to NanoPi-M

Post by awl29 »

Hi again,

hey - you are faster than a speeding bullet indeed... 8-)
Fourdee wrote:
awl29 wrote: So here is my Unique HW_MODEL Index Request for NanoPi3:
I've create a ticket for this. Hopefully get round to it in the next day or two: https://github.com/Fourdee/DietPi/issues/506
No worries - take your time. I'm already about to proceed based on what I assume the change in dietpi-obtain_hw_model will look like... ;)
Fourdee wrote:
awl29 wrote:I would assume that a HW_MODEL id of 62 would be appropriate, and HW_MODEL_DESCRIPTION should probably be 'NanoPi3' being kind of the "generic term" used by FriendlyARM themselves for NanoPC-T3 and NanoPi-M3.
Pretty much spot on :)

HW_MODEL_DESCRIPTION will be NanoPC-T3 as per product webpage: http://www.friendlyarm.com/index.php?ro ... uct_id=123
I'm not sure whether you got the point I was trying to make about why I proposed "NanoPi3":

Basically, FriendlyARM has created two very similar types of devices (each type consists of two devices) that can share the exact same image: NanoPC-T2/NanoPi-M2 is the first (both quad-core 32-bits Samsung S5P4418), and NanoPC-T3/NanoPi-M3 (both octa-core 64-bits Samsung S5P6818, currently still with a 32-bits kernel) the second type.

In other words, HW_MODEL 61 already works fine for for both NanoPC-T2 and NanoPi-M2. As a "hypernym" (generic term), FriendlyARM themselves use the term "NanoPi2" when they mean both NanoPC-T2 and NanoPi-M2, and NanoPi2 is also the hostname in the stock Debian images for these two devices.

HW_MODEL 62 will work fine for for both NanoPC-T3 and NanoPi-M3. Hypernym/generic term here used by FriendlyARM is NanoPi3 when they mean both NanoPC-T2 and NanoPi-M3, and NanoPi3 is also the hostname in the stock Debian images for these devices.

So that's why I'd suggest to go with the generic names. As an alternative, you might of course create four HW_MODEL IDs with the exact product names (as found on their website) and handle two pairs of them in the exact same way.

I rather think it should be sufficient if some text on the DietPi download page states that NanoPi2 is fine for NanoPC-T2 and NanoPi-M2, and NanoPi3 is fine for NanoPC-T3 and NanoPi-M3...
Fourdee wrote:
awl29 wrote:For IMAGE_ADDITIONAL_CREDITS, I'd propose 'FriendlyARM'.
We generally don't give credit for official images by manufacture (they should be always be available), but i'll have a think about it.
Fine with me, they don't really deserve additional credit, as their image indeed is 99.5% nothing but plain Debian... ;)
Fourdee wrote:
awl29 wrote:Next question is about the next step: "Read image". How do you want me to do this? The whole SD card (8GB in my case) at once, e.g. using Win32DiskImager? Or rather by partition, and from a Linux installation using other tools? And finally, how do you expect me to "Resize 2nd parition to mininum size +50MB"?
Read from win32diskimage and zip + upload will be fine.
Or your welcome to try my image resize script
Will do so for the final image once device support is official :)
Fourdee wrote:
awl29 wrote:finalise also needs to be patched to post-process fstab to make /boot an ext4 filesystem for model 62, too (in the same way as for $HW_MODEL == 61).
Noted, i'll code a FS type check into the script.
Thanks, great!

Best,
awl
User avatar
k-plan
Posts: 416
Joined: Sun Feb 28, 2016 5:28 pm

Re: Request: Support for NanoPC-T3 (very similar to NanoPi-M

Post by k-plan »

Also, I have noticed that In finalise, you seem to disable serial console - which I think might not be such a good idea, as serial console might be needed in the very beginning to interact with the freshly installed system (e.g. in a no screen, no keyboard, no [or misconfigured] network scenario).
If you neeed it, you can switch it on by editing /boot/dietpi.txt after burning image on sd card: https://github.com/Fourdee/DietPi/blob/ ... i.txt#L152
(btw: - one reason, why first partition /boot better have to be FAT partition )
When users want to save the last bits and bytes of memory, IMO it would be sufficient to be able to disable it via the config tool.
If you will need it forever, you can switch it on via dietpi-config
160909-0002.gif
If you find our project or support useful, then we’d really appreciate it if you’d consider contributing to the project however you can.
Donating is the easiest – you can use PayPal and Bitcoin.
awl29

Re: Request: Support for NanoPC-T3 (very similar to NanoPi-M

Post by awl29 »

Hello Fourdee,

just wanted to let you know that I have just successfully completed an alpha build of DietPi v130 for NanoPi3 (NanoPC-T3/NanoPi-M3). :D

Note that I ran into a hidden pitfall when I stumbled over the fact that there is a MAX_HW_MODEL in dietpi-software that I also needed to increase to 62. :shock:

There were some error messages about trying to remove DietPi files that were not yet existing, but otherwise, things seemed pretty straightforward. :)

I have fully scripted the whole process (in a quick-and-dirty manner) based on PREP_SYSTEM_FOR_DIETPI.sh such that it can run unattended (takes several hours!), provided that the appropriate changes in finalise (fstab: ext4 boot partition!) as well as dietpi-obtain_hw_model and dietpi-software (HW_MODEL) are available from an official release (the git master branch):
  • Start by booting a from an SD card containing a fresh FriendlyARM Debian image
  • Change into a non-X11 virtual console (e.g. with Alt-F2), as X11 will be uninstalled during the process
  • log into the system as user root (password: fa)
  • download the script: PREP_NANOPI3_FOR_DIETPI.sh onto the NanoPi3 and start it from the root shell
Once the script has completed, it shuts down the NanoPi3 properly (e.g. shutdown -h now). Then take the SD card out, put it into a Windows or Linux PC and create an SD card image using e.g. Win32DiskImager (or Linux dd).

The current version of the script (quick and dirty - no warranties/liabilities for any damage!) is attached here:
PREP_NANOPI3_FOR_DIETPI.zip
Prepare NanoPi3 for DietPi script (alpha!)
(5.79 KiB) Downloaded 167 times
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.

That's it for now - note that I'll only be able to continue to work on this on Wednesday (Sept 14th) at the earliest.

Best regards & have a nice Sunday,
awl
User avatar
Fourdee
Site Admin
Posts: 2788
Joined: Tue Feb 06, 2007 1:36 pm

Re: Request: Support for NanoPC-T3 (very similar to NanoPi-M

Post by Fourdee »

awl29 wrote:That's it for now - note that I'll only be able to continue to work on this on Wednesday (Sept 14th) at the earliest.

Best regards & have a nice Sunday,
awl
Excellent work, looks good. Sept 14th is good, gives me some extra time :)
If you find our project or support useful, then we’d really appreciate it if you’d consider contributing to the project however you can.
Donating is the easiest – you can use PayPal or become a DietPi patron.
User avatar
Fourdee
Site Admin
Posts: 2788
Joined: Tue Feb 06, 2007 1:36 pm

Re: Request: Support for NanoPC-T3 (very similar to NanoPi-M

Post by Fourdee »

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

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.

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
Note that I ran into a hidden pitfall when I stumbled over the fact that there is a MAX_HW_MODEL in dietpi-software that I also needed to increase to 62.
Yep, good spot :)

DietPi-Software uses arrays to store its data. One of those arrays is what software is available for each HW_MODEL.
If you find our project or support useful, then we’d really appreciate it if you’d consider contributing to the project however you can.
Donating is the easiest – you can use PayPal or become a DietPi patron.
Post Reply