# \[SOLVED\] Support for NanoPC-T3 (very similar to NanoPi-M2) **URL:** \ **Category:** Requests\ **Created:** [26 August 2016 22:51 UTC](https://dietpi.com/forum/t/solved-support-for-nanopc-t3-very-similar-to-nanopi-m2/527 "2016-08-26T22:51:01Z")\ **Posts on this page:** 7\ **Page:** 4
**Author:** ![Fourdee](https://dietpi.com/forum/user_avatar/dietpi.com/fourdee/32/11_2.png) [@Fourdee](https://dietpi.com/forum/u/Fourdee)\ **Post date:** [22 October 2016 19:16 UTC](https://dietpi.com/forum/t/solved-support-for-nanopc-t3-very-similar-to-nanopi-m2/527/61 "2016-10-22T19:16:23Z")
> 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. Sandisk Ultra, Sandisk Extreme (uhs-3), Samsung EVO. I actually have a M2 in use daily for ARMv7 testing (faster than the H3’s). Its yet to give me any issues (touching wood with a grin lol). But i’ll check dmesg tomorrow, maybe its been occurring already and i’ve been blindly unaware. > 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… Yep. Ok, so, current issues are (please correct me if i’am wrong, just trying to break this down into a list so we can work on it): - Friendly ARM image is possible already corrupt due to a possible bug in Android make\_ext4fs. - Resize of partition on 1st run results in filesystem corruption, and/or, could accelerate a failure occurring. > Have a nice Sunday! Sunday roast! gonna be a good one 😉, you too 🙂 ---
**Author:** ![awl29](https://dietpi.com/forum/letter_avatar_proxy/v4/letter/a/7c8e57/32.png) [@awl29](https://dietpi.com/forum/u/awl29)\ **Post date:** [23 October 2016 17:23 UTC](https://dietpi.com/forum/t/solved-support-for-nanopc-t3-very-similar-to-nanopi-m2/527/62 "2016-10-23T17:23:14Z")
Hello again, > [@Fourdee](#): > > Ok, so, current issues are (please correct me if i’am wrong, just trying to break this down into a list so we can work on it): > > - Friendly ARM image is possible already corrupt due to a possible bug in Android make\_ext4fs. > - Resize of partition on 1st run results in filesystem corruption, and/or, could accelerate a failure occurring. so, finally, I have now indeed resolved both issues. I have also successfully installed and resized this new image onto the built-in emmc of my NanoPC-T3. 😃 Another good news is that, while I was at it and used to running fsarchiver, I decided to try and fix the same ext 4 file system/resize issue for your existing v129 M2 image. As I don’t have access to this device, it’s of course untested, but as I repeated the exact same steps/commands based on your image that I did before on mine (fsarchiver savefs, clean partition, fsarchiver restfs, zerofree, patch initramfs, fsck, read and repackage image) I’m 99,9% certain that it will just work. Please verify nevertheless… 😉 Upload of the following new files to your dropbox has just completed (in two subfolders): - DietPi\_NanoPiM3T3-armv7-(Jessie).7z (with md5sum): **my final v134 image for M3/T3** - DietPi\_NanoPiM2-armv7-(Jessie).7z (with md5sum): **your original v129 image for M2/T2** , but migrated to newly created ext4 filesystems created by mkfs.ext4 through fsarchiver, and with my updated initramfs (root.img.gz) as described above to do online (instead of offline) resize2fs and a forced file system check afterwards on first boot So I am pretty confident that this time, this finally indeed concludes my work on the final v134 image for NanoPi-M3/NanoPC-T3. 😃 Thanks again for your great job in creating DietPi and your help with this porting effort! Much appreciated! Best regards awl ---
**Author:** ![Fourdee](https://dietpi.com/forum/user_avatar/dietpi.com/fourdee/32/11_2.png) [@Fourdee](https://dietpi.com/forum/u/Fourdee)\ **Post date:** [23 October 2016 18:51 UTC](https://dietpi.com/forum/t/solved-support-for-nanopc-t3-very-similar-to-nanopi-m2/527/63 "2016-10-23T18:51:42Z")
> so, finally, I have now indeed resolved both issues. I have also successfully installed and resized this new image onto the built-in emmc of my NanoPC-T3. \> 😃 \> Whooohooo, legend 😃 Great stuff. I’ll test the updated M2 image tomorrow. Once completed, i’ll put the images live and let you know when they are online. > Thanks again for your great job in creating DietPi and your help with this porting effort! Much appreciated! All credit to you for adding the M3/T3 to DietPi! ---
**Author:** ![Fourdee](https://dietpi.com/forum/user_avatar/dietpi.com/fourdee/32/11_2.png) [@Fourdee](https://dietpi.com/forum/u/Fourdee)\ **Post date:** [24 October 2016 12:52 UTC](https://dietpi.com/forum/t/solved-support-for-nanopc-t3-very-similar-to-nanopi-m2/527/64 "2016-10-24T12:52:10Z")
Great work on this AWL29, cracking job 🙂 **Your M3/T3 image is now live:** Doc = [DietPi Community Forum - Welcome to the DietPi OS Community Forum](https://dietpi.com/phpbb/viewtopic.php?p=3482#p3482) DL = [DietPi - Lightweight justice for your SBC!](https://dietpi.com/#download) > M2 image. As I don’t have access to this device, it’s of course untested, but as I repeated the exact same steps/commands based on your image that I did before on mine (fsarchiver savefs, clean partition, fsarchiver restfs, zerofree, patch initramfs, fsck, read and repackage image) I’m 99,9% certain that it will just work. Please verify nevertheless… Works a treat, great work! I’ve updated it to v135 and will update download once v135 is released. ---
**Author:** ![Fourdee](https://dietpi.com/forum/user_avatar/dietpi.com/fourdee/32/11_2.png) [@Fourdee](https://dietpi.com/forum/u/Fourdee)\ **Post date:** [24 October 2016 13:03 UTC](https://dietpi.com/forum/t/solved-support-for-nanopc-t3-very-similar-to-nanopi-m2/527/65 "2016-10-24T13:03:48Z")
Whats the physical mount locations for the onboard EMMC on T3 (eg: blkid)? I would like to create a doc similar to [https://github.com/Fourdee/DietPi/issues/345#issuecomment-220782308](https://github.com/Fourdee/DietPi/issues/345#issuecomment-220782308) allow user to install DietPi on EMMC. ---
**Author:** ![awl29](https://dietpi.com/forum/letter_avatar_proxy/v4/letter/a/7c8e57/32.png) [@awl29](https://dietpi.com/forum/u/awl29)\ **Post date:** [24 October 2016 22:19 UTC](https://dietpi.com/forum/t/solved-support-for-nanopc-t3-very-similar-to-nanopi-m2/527/66 "2016-10-24T22:19:49Z")
Hi again, and many thanks for officially releasing “my” M3/T3 image… 🙂 > [@Fourdee](#): > > Whats the physical mount locations for the onboard EMMC on T3 (eg: blkid)? I would like to create a doc similar to [https://github.com/Fourdee/DietPi/issues/345#issuecomment-220782308](https://github.com/Fourdee/DietPi/issues/345#issuecomment-220782308) allow user to install DietPi on EMMC. if only it were so simple… ☹ I can definitely tell you that on my T3 (and I assume, things are the same for the T2), the particular devices for emmc and SD depend on the boot mode: - boot mode emmc (boot button not pressed during power on): emmc is /dev/mmcblk0, SD is /dev/mmcblk1 - boot mode SD (boot button pressed during power on): SD is /dev/mmcblk0, emmc is /dev/mmcblk1 While all content on emmc and SD is exactly the same from block 2048 onwards, unfortunately, there are a number of binary differences in the blocks before (0-2047) between SD and emmc (e.g. bootparams), although u-boot bootloader and partition table are equal. I have used the following multi-step, but relatively straightforward approach to install DietPi on my emmc: Write FriendlyARM’s eflasher utility: [http://www.mediafire.com/file/9d220h5uts5yrd3/s5p6818-eflasher-sd8g-20160913-full.img.7z](http://www.mediafire.com/file/9d220h5uts5yrd3/s5p6818-eflasher-sd8g-20160913-full.img.7z) onto an SD card (of at least 8GB in size), then boot from this SD card (using the boot button), and install Debian onto emmc from the graphical installer. This prepares emmc blocks 0-2048 to properly boot into Linux (as opposed to Android) from emmc, and writes FriendlyARM’s Debian images into emmc partitions p1 (boot) and p2 (rootfs). Now switch to a login prompt using Alt+F2 and login as root (password is “fa”). Note that, as this still is from the command prompt of the eflasher (i.e. running off the SD card), the emmc device is currently still called mmcblk1 (and not mmcblk0 like as it would once we’ve booted from emmc): ```plaintext Disk /dev/mmcblk1: 7.3 GiB, 7818182656 bytes, 15269888 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x4dc52160 Device Boot Start End Sectors Size Id Type /dev/mmcblk1p1 2048 133119 131072 64M 83 Linux /dev/mmcblk1p2 133120 15269887 15136768 7.2G 83 Linux ``` Then, using fdisk, delete the maxed out rootfs partition /dev/mmcblk1p2: enter “d” and “2”, and recreate it to be the exact size of the DietPi raw rootfs partition as contained in the DietPi image (which happens to be exactly 1024000 blocks of 512 bytes each, i.e. 500MB): enter “n”(ew) “p”(rimary) “2” “133120” “+1023999”. This results in: ```plaintext Disk /dev/mmcblk1: 7.3 GiB, 7818182656 bytes, 15269888 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x4dc52160 Device Boot Start End Sectors Size Id Type /dev/mmcblk1p1 2048 133119 131072 64M 83 Linux /dev/mmcblk1p2 133120 1157119 1024000 500M 83 Linux ``` Write this modified partition map to emmc by entering “w”, and then quit fdisk with “q”. Finally copy blocks 2048 and following of the DietPi image to block 2048 and following of the emmc using dd: ```plaintext dd if=DietPi_v134_NanoPiM3T3-armv7-(Jessie).img of=/dev/mmcblk1 ibs=512 skip=2048 obs=512 seek=2048 ``` Now shutdown the eflasher command propmpt, switch off the device and switch it back on again, this time without pressing the boot button. You will now be booting into DietPi from emmc, and it will resize the emmc rootfs partition on first run from 1024000 blocks (500MB) to the full 15136768 blocks (7.2GB). That’s how I did it, unfortunately, the process is quite complex. It might be possible to tweak the code available from here: [GitHub - friendlyarm/sd-fuse\_s5p6818: Create bootable SD card for S5P6818 boards](https://github.com/friendlyarm/sd-fuse_s5p6818) to do all of this in only one step, but - at least for me - it wasn’t worth the effort, as the above method worked for me… Hope this helps & best regards awl ---
**Author:** ![thieums](https://dietpi.com/forum/letter_avatar_proxy/v4/letter/t/41988e/32.png) [@thieums](https://dietpi.com/forum/u/thieums)\ **Post date:** [30 January 2018 12:18 UTC](https://dietpi.com/forum/t/solved-support-for-nanopc-t3-very-similar-to-nanopi-m2/527/67 "2018-01-30T12:18:28Z")
Hello! sorry to up a thread this old, but it seem the most appropriate for what i’ve found. I own a nanopi M3 and while looking for a lightweight OS i found dietpi (i have rpi too i think i’ll try it on them)… Works fine, but if i understood it right, only in 32b… so, back on google! and found [https://github.com/rafaello7/debian-installer-nanopi-m3](https://github.com/rafaello7/debian-installer-nanopi-m3) it a net install for jessie, stretch or buster wich support wifi/bluetooth/arm64 on the M3 🙂 tried it (the stretch one), and beside some install pb due to the sd card i think, looks like it work fine (didn’t yet test the bluetooth tho) maybe if someone from the team get in touch with the maker it could be used as a start to make another image of dietpi for the M3 [Previous page](https://dietpi.com/forum/t/solved-support-for-nanopc-t3-very-similar-to-nanopi-m2/527.md?page=3)