NanoPi R6S

[jalsco]

Hi all - probably a very basic question....
I am thinking to buy NanoPi r6s - and install Dietpi on it.
It has 3 ethernet ports.
I wish to configure like this : some services ( like caddy and lighttpd ) using one IP address (one ethernet port)
and PiHole using different IP address ( a different ethernet port).

Each port cabled to different router, on different subnet

Is any obvious problem with this idea ? And how to do it ? ... I mean .. the multiple IP addresses ( one for each ethernet) on the same Linux system ? Can find my way around a Linux system - though am still relatively new to it

Any advice or suggestions warmly received.... Thanks in advance

[Joulinar]

That might be possible but would require some manual work to restrict apps to a specific IP address sub net. As well network interface need to be configured manually as our tools don't support multiple interface as of now.

[jalsco]

Hi @Joulinar happy new year ! and thanks for your fast reply .

I think is easy enough to restrict the apps ( because bind them individually to a ip and port ) .
" network interface need to be configured manually" -- that is ok ... as long as it will work on DietPi after that is done. I do not need "specific dietpi tools".... just want to know that nothing in Deitpi would prevent it from working.

[MichaIng]

You can configure the eth0 (LAN2) interface with dietpi-config and configure the other two interfaces eth1 (LAN1) and eth2 (WAN) with own configs in /etc/network/interfaces.d. That way everything will be preserved in any case.

[jalsco]

Awesome !! Thanks @MichaIng and happy new year .

I will go ahead and confirm my order for the NanoPi R6S

postscript: Seems I spoke too soon. There's a worldwide shortage. Expecting stock availability again in 3-4 weeks.

[MichaIng]

Ayy, chip/supply chain crisis is not over yet 😞. Hopefully they get it sorted soon.

[jalsco]

Hi @MichaIng and @Joulinar - I got my shiny new (actually is not shiny, is mat-black) nanopi r6s.

I have run into some problems installing DietPi at at very early step. I am certain it is caused by me not quite (but almost) understanding what I am doing and is not any problem with the DietPi image. But - I am hoping that you can help me anyway.

I want to install the IMG by the usb cable approach. See here

These are the steps :

1. I download the right DietPi img file from here and extract it ✅
2. I successfully get the nanopi into the right mode to load the file, and the RKDevTool is detecting as "Found One MASKROM Device" ✅
3. Then I go to - Upgrade Firmware - and click "Firmware" - and point to the DietPi img file... And I get this :

I think the problem is about the Partitions that already exist (pre-installed) on the device. So my guess is they need to be wiped so DietPi will install into - one partition - taking up the whole space. This is the screen that I believe shows what is there now:

I am just nervous to do anything without advice - as I fear bricking the device ...

Any advice you can provide is ALWAYS welcome 😁🙏🏻

[jalsco]

The Rockpi that use the same usb tool as Nanopi (RKDevTool) ....

the Rockpi site gives clear instructions on using that tool, and on my Rockpi I had no problems installing Dietpi with that tool . : https://wiki.radxa.com/Rockpi4/dev/usb-install

But for Nanopi, which to keep ? which to clear ? I am assume I must keep "Loader" ? (pls confirm) - but what of all those other ones ? Paramter, Uboot, Misc, Dtbo, vbmeta, Boot, Recovery, baseparamter, Super ? Which to keep and which to clear ?

I can not find instructions that explains CLEARLY what are the steps

[Joulinar]

Personally, I booted the system first time from SD card. Once install finished, I used dd command to flash DietPi image to eMMC.

[jalsco]

Hi @Joulinar , thanks for your reply. That's not really an option for me here.

And I suspect, even if went on that path, I would STILL run up against the same problem I am facing now. That is, the eMMC seems to be partitioned now and contain all those things that I showed . Which partition (on eMMC) did you dd the image across to ? Did you leave all the other partitions as they were (see above image) ? That is the main knowledge gap at this point . If I know those things - I should be able to proceed with the RKDevTool

[jalsco]

Here is the manual for RKDevTool -

I "believe" (but not know for sure) that I should be leaving the LOADER in place and then just have an IMG for Dietpi. The manual seems like translated to english by google translate or other robot - so is not so easy to follow.

RKDevTool_manual_v1.2_en.pdf

[Joulinar]

I use dd to copy the image to the whole eMMC storage and not a single partition. Means the whole eMMC will be overwritten. Our image contains all the partition information needed to recreate the 8 partition again.

[jalsco]

how can i take that knowledge and then use RKDevTool to load the Dietpi image via the usb cable ?

[jalsco]

To load the Android image ( this from friendlyelec forum ), their advice is this:

Start RKDevTool_Release_v2.84

Change all .bin files to point to extracted Android image folder equivalents
Then Click Highlighted first button (next to words Loader Ver 1.ob) to write image to eMMC

So, seems like, I just need the corresponding info for DietPi.

[Joulinar]

why not simply loading a DietPi image on SD card, boot, finish install, use dd to copy image to eMMC, done.

[jalsco]

I do not have any SD card at this location - and not easy to source

[jalsco]

When I used the RKDevTool ( in different location) for the RockPi4 - I had to KEEP - the Raxda supplied "loader". Is that likely to be the same for this one ? It would be easy enough to wipe out everything showing in their table - but the actual Message when trying to laod the DietPi image was "Loading Firmware failed" -- I suspect it was loading to the wrong address, or something else is already there that needs to first be deleted. Rather than guessing - I am trying to find out that information .

[jalsco]

The is link : https://wiki.friendlyelec.com/wiki/index.php/NanoPi_R6S#Install_OS_to_eMMC
Explains the process for "Option 1: Install whole image (ie, update.img)" which is says most 3rd party developers use.
But, it goes on to list Debian Buster as one of the options under Option 2. DietPi is not listed.

---------------- cut/paste-----------
4.5.2.3.3 Step 3: Install image to eMMC

A firmware in general is packaged in either of the two options: the first is an whole image (ie, update.img) which is often offered by third party developers, the second is that an image is packaged and placed in multiple partition images. FriendlyElec offers an image in the latter option.

Option 1: Install whole image (ie, update.img)

On a PC which has the extracted RKDevTool_Release_v2.84 utility, go to the RKDevTool_Release_v2.84 directory, run the RKDevTool.exe file. If everything works, you will see a “Found a new Maskrom device” message on the utility;
Go to “Upgrade Firmware(升级固件)”, click on “Firmware(固件)”, select your wanted image file, and click on “Upgrade(升级)” to install. After installation is done, your board will reboot automatically and load the system from eMMC;

Option 2: Install OS that is packaged & placed in multiple partition images

---------------- cut/paste-----------

[MichaIng]

I never got this working with the RKDevTool either. On ROCK Pi S, you need to additionally select a firmware binary to successfully connect to the MASKROM device, not sure why (and really if) this is not required for NanoPi R5S/R6S, or if even this is why it fails and they simply missed to mention this step and provide the required firmware binary. That it says "Loading Firmware failed" is actually pointing into this direction. There is a Linux variant of this tool as well, called rkdeveltool where it is simply impossible to flash an image without first connecting (called "downloading" for some reason) with such firmware binary.

You btw need to select the whole single DietPi image (if it shall every work). On the first tab, it includes partitioning, and you do not want our image to be flashed into a partition, but as it contains partitions itself, you want it to be flashed onto the whole drive, which can be only done on the other tab, but there you must select a firmware binary. For dd this means to select e.g. /dev/mmcblk0 instead of /dev/mmcblk0pX (with X being whatever partition).

Why Rockchip offers this crap instead of just exposing the eMMC as regular block device when connecting via USB, and let everyone choose well known flashing tools, remains a mystery...

[jalsco]

Hi @MichaIng - oh that's bad "you never got it working".

For me, it is a 4.5 hour drive to Darwin, probably another hour to find a suitable SD, and then another 4.5 hour drive time back to here. I wasn't planning to go there again until late Feb. Really hoping to get this working by USB. I have downloaded the Debian Bullseye USB image to see if I can make sense of it. But to go the SD card option, I got to drive 500km in each direction or wait till late Feb..... So I am not inclined to give up on the USB cable just yet - but have a headache now that I know u didn't get it to work either.

[jalsco]

For Debian Bullseye - to load by USB (using RKDevTool )

The set of img files etc are :

I was hoping it was going to be one file - a loader.img - hahahaha ...

So I am guessing that it absolutely ZERO chance, that just swapping in the DietPi image (into that Debian filelist) will work. Maybe you could look at those files ?

"Why Rockchip offers this crap instead of just exposing the eMMC as regular block device when connecting via USB, and let everyone choose well known flashing tools, remains a mystery..." I totally agree ! Unnecessarily difficult, very poorly documented, and high chance of bricking if do something wrong. Just crazy.

MAYBE - In RKDevTool - the third Tab "Advanced Function" -- where you select 2 images. First a BOOT image , and second the firmware... As in "boot.img" from the buster download and then the dietpi.img for the firmware. I seem to remember , that the "boot" image is expecting a type BIN not type IMG ...

[MichaIng]

high chance of bricking if do something wrong. Just crazy.

To be fair, you cannot brick anything with this, you can always flash a new image with dd, regardless what you flashed or erased form it before.

I was hoping it was going to be one file - a loader.img - hahahaha ...

Actually, the MiniLoaderAll.bin looks promising. Try with the "Advanced Function" in RKDevTool, select this MiniLoaderAll.bin in the "Boot:" field, and our DietPi image in the "Firmware:" field. Hit "Download" (at the right of the "Boot:" field) first, which hopefully shows a success. Then hit "Unpack" below the "Download" button, to flash our image.

[jalsco]

What about using the LOADER from Raxda - https://dl.radxa.com/rock5/sw/images/loader/rock-5b/rk3588_spl_loader_v1.08.111.bin
And the third tab (advanced functions) ?

Am trying your suggestion now

[MichaIng]

I'm sure the loader needs to match the hardware so that the Radxa loader won't work on any NanoPi.

[jalsco]

It was suspiciously promising - even it didn't work - and I am going to bed now.

Tomorrow - I am partly emboldened to try a few more things since you say I cannot brick it.

The first thing - is to try it from a Mac or Linux device. I remember a a couple months ago in Manila doing it with the RockPi4, it didn't work from Windows , but then from an old Mac using the sudo rkdeveloptool it did work.

Also - https://wiki.radxa.com/Rock5/install/spi here they are always saying to ERASE first with a zero.img (which they supply) before loading. And the MiniLoaderAll.bin and rk3588_spl_loader_v1.08.111 are same number of bytes.. so I will try with both of those using rkdeveloptool, while erasing with zero.img first.....

Anyway - it is worth a try. I fear the only Mac here is a new one with only usb-c ports, but hopefully that will still work. Thanks for your help. And if any other ideas - just let me know

UPDATE - I just saw your comment, so I will avoid the raxda loader bin file in my attempts tomorrow.

[MichaIng]

Erasing with zero.img shouldn't make a difference, as our images overwrites everything from the first bit anyway. But who knows, try it out.

Good idea to test from Linux. In case of my ROCK Pi S it also only worked from Linux, although I later recognised that my model does not have any onboard eMMC and hence the image was written to nowhere. I then was not sure whether the Linux tool is just dumb to not detect whether an eMMC is actually present, while the Windows variant does, or whether the Windows tool really is broken, or we are too dumb to use it 😄.

UPDATE - I just saw your comment, so I will avoid the raxda loader bin file in my attempts tomorrow.

You can just try it. I'd expect the "Download" step, respectively the rkdeveltool db radxas_whatever.bin from macOS/Linux to fail, which makes the next step of flashing the image impossible.

[jalsco]

Hi @Joulinar - yeah... I failed on all possibilities to get the USB cable working. So now onto plan B ( SD card, then using DD )

I already bit the bullet and did the long drive (1000km round trip) . Besides the time, fuel and accom costs, unfortunately one kangaroo gave up his life (road kill) so I could get that SD card to make DietPi run on the NanoPi R6S 😢🙏🏻

Anyway - have now installed Dietpi onto SD card and have it running on the NanoPi R6S. Please advise about the best dd command to use. Should any Services etc be shutdown first, before doing the dd ? What's the proper procedure ?

System looks like this (64gb sd card) and (32 GB eMMC) :

root@DietPi:~# root@DietPi:~# lsblk
NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
mmcblk2      179:0    0 28.9G  0 disk
├─mmcblk2p1  179:1    0    4M  0 part
├─mmcblk2p2  179:2    0    4M  0 part
├─mmcblk2p3  179:3    0    4M  0 part
├─mmcblk2p4  179:4    0   16M  0 part
├─mmcblk2p5  179:5    0   40M  0 part
├─mmcblk2p6  179:6    0   32M  0 part
├─mmcblk2p7  179:7    0   32M  0 part
├─mmcblk2p8  179:8    0  424M  0 part
└─mmcblk2p9  179:9    0 28.4G  0 part
mmcblk2boot0 179:32   0    4M  1 disk
mmcblk2boot1 179:64   0    4M  1 disk
mmcblk0      179:96   0 59.5G  0 disk
├─mmcblk0p1  179:97   0    4M  0 part
├─mmcblk0p2  179:98   0    4M  0 part
├─mmcblk0p3  179:99   0    4M  0 part
├─mmcblk0p4  179:100  0   16M  0 part
├─mmcblk0p5  179:101  0   40M  0 part
├─mmcblk0p6  179:102  0   32M  0 part
├─mmcblk0p7  179:103  0   32M  0 part
└─mmcblk0p8  179:104  0 59.3G  0 part /

SD Card:

eMMC:

[Joulinar]

Basically you have 2 options.

1. Copy the existing system from SD card to eMMC
2. flash a new img directly to eMMC

What would be your preferred way?

[jalsco]

Hi @Joulinar , thanks for your reply.
Preference is #1 , but please gives steps for both options

[Joulinar]

1. guide for this option https://dietpi.com/blog/?p=1236
2. flash new image dd if=/path/to/dietpi.file.img of=/dev/mmcblk2 bs=1M status=progress

[jalsco]

Option 1 , as described in that link, does not work for the case where SD is larger than eMMc. The instructions on that page for that case are not correct, or are inadequate. Just because gparted is used to make 58gb (of 64gb) unallocated , does not prevent dd from (trying to) copy the whole 64gb .

The dd command still tries to copy all of the if (in my case 64gb) - even 59gb is unallocated space, as result of the gparted step on that page. I even tried using count= in the dd command, which did prevent the dd ending in an error, but did not work to produce a bootable eMMC.

So I ended up doing option 2 - I am thinking I could have done option 2 even without Dietpi running .... so probably did not even need the SD card. Or the usb cable, I mean, the nanopi boots up to another linux ( ie think openwrt ? ) . For that option, only needs to wget the image file, and then dd it to the eMMC. So could I have done it from the openwrt terminal ? <answer is "no" , see below >

Another very annoying problem is the TTY screen size dimensions ( I mean before SSH is setup, direct by hdmi cable). And, although usually use SSH there are sometimes (rare) when still need to attach the hdmi cable and use a real tty session. The problem is that it goes off the bottom of the screen, so cannot see if cursor is on "ok" or "cancel" or "back" , becasue that is at the bottom (ie off the screen). So do not know what "enter" or "tab" will do.. How to change the dimensions of the tty screen ? At first I tried dietpi-config and 1. display options only to get the message (about resolution), This option is not available for NanoPi R6S (aarch64) .... So how can the default tty screen dimensions be changed, if not in there ?

[Joulinar]

@MichaIng @StephanStS maybe we would need to extend our blog post with the information how to dd such multipartition systems correctly?

[MichaIng]

The instructions are complete (with GPerted and dd on full drive) already, but we could add a hint that the dd failure can be ignored when the target drive is smaller but the partition has been resized.

[Joulinar]

@MichaIng maybe I'm doing it wrong, but I tried to move my already shrined SD card without success.

Before copy, you see mmcblk0p8 is 900MB only. The whole SD card (29.7G) is a but larger than the internal eMMC (28.9G)

root@DietPiR6S:~# lsblk -o name,fstype,label,size,ro,type,mountpoint,partuuid,uuid
NAME         FSTYPE LABEL  SIZE RO TYPE MOUNTPOINT PARTUUID                             UUID
mmcblk2                   28.9G  0 disk
mmcblk2boot0                 4M  1 disk
mmcblk2boot1                 4M  1 disk
mmcblk0                   29.7G  0 disk
├─mmcblk0p1                  4M  0 part            b750e44e-833f-4a30-c38c-b117241d84d4
├─mmcblk0p2                  4M  0 part            a1c81622-7741-47ad-b846-c6972488d396
├─mmcblk0p3                  4M  0 part            43784a32-a03d-4ade-92c6-ede64ff9b794
├─mmcblk0p4                 16M  0 part            000b305f-484a-4582-9090-4ad0099d47bd
├─mmcblk0p5                 40M  0 part            24eeb649-277f-4c11-ffeb-d9f20027a83b
├─mmcblk0p6                 32M  0 part            1cac805f-726a-495a-fd35-821355a6e7e8
├─mmcblk0p7                 32M  0 part            2bfee623-d83c-426a-ab80-21732c9bb7d3
└─mmcblk0p8  ext4          909M  0 part /          83fa15d9-b435-4472-965e-a3406624497c 41900e80-aabd-4cda-b30d-85577329589d

As expected, dd is complaining about insufficient space.

root@DietPiR6S:~# dd if=/dev/mmcblk0 of=/dev/mmcblk2 bs=1M status=progress
31028412416 bytes (31 GB, 29 GiB) copied, 976 s, 31.8 MB/s
dd: error writing '/dev/mmcblk2': No space left on device
29601+0 records in
29600+0 records out
31037849600 bytes (31 GB, 29 GiB) copied, 1036.69 s, 29.9 MB/s
root@DietPiR6S:~#

Afterwards the R6S is not booting up.

[jalsco]

Yeah @Joulinar , that is same outcome that I observed 🤷🏻‍♂️

[MichaIng]

What is the output of:

gdisk -l /dev/mmcblk2

And does it help to fix the backup partition table:

sgdisk -e /dev/mmcblk2

[jalsco]

hi @MichaIng -

(1) about the dd ok - as it did not work (meaning "boot' after the copy) for me, trying it multple times, both with the error message and also by using count= -- I accept your wisdom and conclude that it was some problem specific to my system. Anyway, as stated, I moved on from that and did the other option... of downloading the image to the eMMC.. from a running Dietpi system that had been booted from the SD card. That worked first run through - and already customised the system after that...

(2) about the annoying console screen sizing - I fix it each time, manually, by using stty rows 65 cols 132 I probably should use 180 or more for the cols, but the main issue is the rows. That command solves that immediate problem for me. But obviously is not elegant and not automatic.

(3) I have bigger problems right now.... It WAS all running perfectly, until about 1am last night. The nanopi was giving screamingly fast performance with a few of my own tests. I had used the dietpi-config to setup LAN2 network (as u advised)... All was good. And then I tried to configure a second ethernet - which failed - there was some (coincidental) hardware failures on the router's Ethernet ports.. More to details to follow

[jalsco]

This is what happened

• I noted ETH0 was correctly in etc/network/interfaces . Using a static address of 192.168.9.113 , gateway of 192.168.9.1 .... the dns was commented out (I assume probably by pihole), but that not causing any problems, all was working perfectly. So I added a new file in etc/network.interfaces.d with the ETH1 config... Just to get it working (i thought) first I added the ETH0 just as diff subnet 192.168.33.11 with gateway at 192.168.33.1. I didn't expect that line to work immediately without a few changes to the router.. But I rebooted - expecting the nanopi would come back online on ETH0 (as before 192.168.9.113) and expecting that the second interface would be offline becasue not able to find the gateway as I had made no changes to the router. Shutdown, powered off, then added the 2nd ethernet cable to a spare port in a 5-port hardware switch attached to same router... then rebooted the nanopi....

• First thing I noticed was upon rebooting the nanopi - is that the internet (upstream by ethernet to the wan port on the router ) - for all devices here - had coincidentally just dropped out at that exact moment in time..... "very odd" I thought, but can look at that problem later.... Then I realised I could not ssh or even ping the nanopi (on any address). Then realised I could not ping any ethernet connected device, but wifi connected devices were fine. The upstream link (ethernet) was also out ... and power off (few minutes), power on - of the router changed nothing. The router was not getting a dhcp address from the upstream WAN ethernet link . I quickly tested that upstream was ok - by direct attaching a laptop to that line - which got a dhcp address and was able to go online to internet... very strange... internet offline when the line connected to the router.. And also all the other ethernet devices connected to that router all offline. I was able to access the nanopi (by hdmi and direct keyboard) i reversed out the changes.... a few times... even reset the network completely by going back to dietpi-config and letting it do it..... reboot etc.... powered off and disconnected EVERYTHING..... waiting an hour(+10mins) for any dhcp leases to expire.... plan to one by one add each device ... PROBLEM UNCHANGED - no connection upstream and no ethernet devices (including the nanopi) connect to he LAN. Wifi devices all still connect to the lan , can ping each other and ssh each other, but without an upstream wan link obviously none can access internet.

• I do not even understand how it could be possible ?? It seems having 2 ethernet cables into the same router ( one via the switch) shorted-out the ethernet capability of Router (all ports, including upstream wan ethernet). Router is a linksys wrt1900acs v2, running ddwrt. Surely I am wrong ? Surely that could not have happened ? Please someone tell me I am wrong and explain this ... omg... At this point - I have abandoned plans for the 2nd line from the nanopi until this immediate problem is fixed ... For now, I just want the router's ethernet ports (which inlcudes wan internet upstream ) running again, and then hopefully that will mean dietpi ETH0 (on lan2) is running again...

Can u add any suggestions or input to this problem ? I cannot believe it... total disaster here at this time.

[Joulinar]

Are you able to login locally still? What does ip a return?

[jalsco]

Am back on line - replacement router - nanopi - operational and fully online again ( ETH0 only) .... I am starting to think that those router problems were pure coincidence, I will tackle the inital problem again tomorrow, that is: getting ETH1 to work on different subnet, ie both ETH0 and ETH1 running....

[MichaIng]

Okay good. I also cannot imagine how any network configuration and Ethernet cable attachment can permanently break the whole network/router, unless you manage to set the cable under high voltage somehow 😄.

• Generally take care to not cause any DNS or routing loops.
• Generally attaching the same device with two cables to the same router sounds like something that has no reason and may cause mentioned loops. The router always has a single subnet only, so both R6S Ethernet adapters cannot work on different subnets then, or do I misunderstand something or does your router support different subnets on its multiple Ethernet ports?
• In any case, I'd expect the problem to be solved then by simply unplugging the R6S, or reboot the router, if some overload has happened.

Can you explain the setup you want to achieve with both Ethernet adapters/interfaces?

the dns was commented out (I assume probably by pihole)

Note, that is expected. The DNS setting in there is only relevant if you use resolvconf, otherwise DNS servers are set directly in /etc/resolv.conf. Note that you cannot set individual DNS servers per network interface. That those settings appear two times below Ethernet and WiFi somewhat misleading, same with the gateway/default route. Basically those should only be set at the main internet facing interface and not on any internal interface.

[jalsco]

My router does support different subnets on its multiple Ethernet ports. I have configured other routers to do that many times. Easy to configure - vlans using ddwrt.

The plan is NOT to have the nanopi to do any routing between its 2 different IP addresses.
Rather, it will service its 2nd IP address as I define it in Caddy. That's it.

[MichaIng]

Ah right with ddwrt/OpenWRT/FriendlyWRT multiple subnets will be possible.

The plan is NOT to have the nanopi to do any routing between its 2 different IP addresses.

Makes sense. Should be the case OOTB if that subnet has no Internet access but is for LAN communication only. So assure to not assign a gateway/default route. Can you show how you set it up? I want to write a blog post about those FriendlyELEC mini routers and add an example about how to setup one internet facing interface (connected to router/modem) and bridge the other two for a LAN facing side with Internet access forwarded for clients. A bridge is the best method to have both adapters merged into one LAN subnet, isn't it?

[jalsco]

I will - but, may take a week - 😁🙏🏻

[jalsco]

Hi @MichaIng - I am sorry late to provide an update. All running from my side for a few days now, both ETH0 and ETH1 on different subnets. One or two minor things still to update, most of that is outside of dietpi on other devices.

In order to more fully test my setup - there are few tests I want to do from HDMI/direct keyboard. Those hw items are not usually connected to the nanopi. They were connected at a few stages during my initial install. But not been connected for a week or so.

Today I plugged hdmi screen directly into dietpi and reboot now from a ssh session. Even attempt by power off then power on ... But the hdmi screen does not show anything , I am expecting the blinking cursor to log in in tty console mode. Everything else on deitpi is running nicely . I can ssh and use the LXDE desktop. I have been through a pile of troubleshooting steps - clearly I am forgetting something or missing something about the HDMI screen.

On raspi I could always add these two lines to /boot/config.txt thus :

hdmi_force_hotplug=1
hdmi_drive=2

Then if at some point in future I want to plug in hdmi , it is there even without a reboot. Is there something similar on dietpi ? Maybe my problem is even deeper, because I see nothing on the hdmi screen even after a power-on .

Any advice please ?

[MichaIng]

Probably you face the same issue than us here? #6095 (comment)

I've still no solution for this, respectively better workaround than adjusting the framebuffer size to the screen resolution (while the other way round would be preferred).

[jalsco]

Hi @MichaIng and thanks for your reply.

Ok - i will try that package.... But my "hdmi not working" seems a bit different,.

I had no problems about, and never had problems about , "will not boot". At the beginning ( a few weeks ago), before I setup everything - like my keys in ssh , my nanopi always did boot up to HDMI screen and attached keyboard. Since then, I have only been using ssh and occasionally LXDE. So, I do not know when "HDMI stopped giving output".

Now - it just seems like the HDMI is "set to off". I mean the screen displays "no signal". This problem is not about the resolution size of the screen. When I encountered that problem, weeks ago, I simply solved it by manually setting stty rows 65 cols 132. This seems different. This seems like "HDMI is not active at all".

UPDATE: aahh - I think I see what you mean - that maybe the nanopi is not getting enough power to activate the HDMI.. I suppose that could be the problem, because in the early days of set up it was only driving eth0... but now it is driving eth0 and eth1... It should be getting 12watts.