Creating a bug report/issue
I don’t know if this is a bug. Probably not. Probably just a quirk of the way FriendlyElec does things that I have not been able to figure out.
Required Information
- DietPi version |
cat /boot/dietpi/.version
G_DIETPI_VERSION_CORE=8
G_DIETPI_VERSION_SUB=15
G_DIETPI_VERSION_RC=2
G_GITBRANCH=‘master’
G_GITOWNER=‘MichaIng’
- Distro version |
echo $G_DISTRO_NAME $G_RASPBIAN
- Kernel version |
uname -a
- SBC model |
echo $G_HW_MODEL_NAME or (EG: RPi3)
NanoPi M4v2
- Power supply used | (EG: 5V 1A RAVpower)
85w wall wart
- SD card used | (EG: SanDisk ultra)
Real Sandisk Ultra
Steps to reproduce
- Download and unzip image
- Etcher > SD card
- Insert card
- Power on
Expected behaviour
Lots of text scrolling. Desktop load. IP comes up on nmap. Normal stuff.
Actual behaviour
Friendly Elec screen flashing periodically. No text. No IP. That’s it.
Extra details
I have burned several hundred SD cards of images for SBCs over the last 8 years and am trying to write a book on building a home media server for beginners. I am not like an actual smart guy and don’t know any of the details about the kernel or really most of anything until I dig into it when I need it. But I have successfully used SBCs for everything from daily computers to a fleet of in-store kiosks.
Years ago I got the first NanoPi M4, and I vaguely remember that I had to go through a burning process that Rockchip created back then. But these days the Friendly Elec site seems to have regular win32diskimager instructions like everyone else. (and yes I tried switching to windows and doing that as well) But no matter what image I use, I get the same thing.
I even tried some of their vague instructions on their “eflasher” images where you edit the eflasher.conf file and supposedly it will dump it on the EMMC. But to no avail. The board itself is fine. I had a preburned EMMC with android on it and that eventually did boot into android.
Have tried with the EMMC in, out. Different SD cards. I’m not someone who usually posts questions on forums. I dig because I don’t have the patience to wait for an answer. But I am giving up and asking.
Since the beginning have been an Armbian guy and have helped support Igors efforts for many years. But I just gave DietPi a roll and it is really something else. The application list itself is an education in what is out there without having to go look for it. And I have successfully used DietPi on a few other boards already (C2, Opi PC, Rpi2). Just can’t figure this guy out.
Thanks.
Not sure if @StephanStS has such board available to assist. As well our developer @MichaIng could have a look.
Thanks. 
I feel like it is something basic that I’m just missing.
FWIW I tried DietPi on a NanoPi K2 and worked perfectly. So it is something specific to these boards. Same result on the regular first version M4 as well. If they don’t have one I’ll just have to wait for a response from Friendly Elec and see if it can be figured out.
I did some tests with my M4v2 and two different .7z files (the actual one and one older from november 2022).
I used Balena Etcher as well as Rufus.
Every combination worked well, booted up with all text messages running through until the first boot login.
So, I assume your power supply is too weak for your board.
Could you do some tests with
- different power supplies
- different power cables (USB-C cables might also limit the current flow)
In case of cheap cables or weak power supplies, the M4v2 starts to boot a couple of seconds (green LED begins to flash), then it reboots. This loop does not end.
I tested this with different cables and power supplies at my M4v2 and could reproduce this boot/reboot loop.
/StephanStS
1 Like
Just to be sure I do not misunderstand: The attached HDMI monitor is flashing black/white/grey or such? Or is it an LCD from FriendlyELEC, or a FriendlyELEC logo or so?
I was first thinking that also the HDMI signal may be too weak if e.g. a long cable is used. The Raspberry Pi has some HDMI signal strength setting, but such does not exist on mainline Linux.
But if the device does not come online either, indeed it looks like boot fails at an early stage. I agree with @StephanStS that PSU or power cable are the first typical reasons for this. Note that if it previously worked with same PSU/cable is not guarantee that it works now. It may have been close already and a recent kernel update may have lead to a slightly higher peak power usage at boot which makes it fail now.
And if you have a UART adapter: That is a great tool to debug such early boot issues if no network and not even HDMI came up.
Yep, that’s it. Fat cable with thin insides. I had a little voice in my head and ignored it, but sure enough, that was it. Took me a couple tries because Comcast was up and down today, but it’s working fine now. Thankyou for taking the time to answer. I have an open ticket at Emby because it appears that even x86 Linux has something introduced upstream that is fubar’ing your ability to log new clients into the system, and it was completely unanswered for a week or so. It really matters that you guys are attentive and don’t answer snarky. I have been dealing with internet questions and comments since 1996 myself so I know how old and tired it gets. I really understand how nice it is that you guys really show up. Got me to the next step in my research.
I have looked into the UART thing, but I don’t know what to even look for, or what it even is, except the pins lol. I don’t actually know anything. I just figure out how to do stuff. Thankyou again. -ph
2 Likes
“Fat cable with thin insides.” lol, rofl.
Generally, I had only a few " power sensitive" SBCs in my Raspberry-and-derivatives-zoo like the NanoPi M3 (was the worst up to now), the NanoPi M4v2 and - of course - also the Pi 4.
My systems all are running stable, but no one knows the headroom in detail. 
Nice to hear that your problem is solved. Thanks for the praise to the team.
I grabbed one of the cables I had bought for the Pi 4 lol. I knew they were really butch and if I remember there was some kind of thing with the early ones where you had to get cables with (or possibly without) the lightning bolt on them because they forgot to connect a trace or something on the c connector to get enough power. So yea, it’s working, but who knows if the bridge is just holding or was way overbuilt. Better to get off it. I’m going to focus on the Opi 5 I think. I have not plugged mine in yet, but it has good reviews from what I have seen and I’m hoping it isn’t as rip snorting hot as the 3399.
Something like this:
with 3-6 pins. In short: You attach 3 ends (RX, TX, GND) to the right pins on the NanoPi’s GPIO header and the USB end to another computer. On that other computer you start a serial console client, like PuTTY (which is a famous SSH client but supports serial access as well) and connect via COM port. Our images are configured to send boot messages to the default UART device, which includes the earliest boot stages, starting with the ROM firmware of the NanoPi checking for storage devices, looking for U-Boot on them, loading that U-Boot, loading the
/boot/boot.scr, from there the kernel, device tree, initramfs and finally boot. Hence much more than what is possible on a HDMI screen. And you also get a login console there, so can login “commonly” without any monitor, keyboard attached and without network (for SSH). That is what you see in movies when people hack other systems with their Laptop by attaching a cable somewhere
.
Very valuable for debugging boot issues.
1 Like
I think I have the cable somewhere but never dedicated the brain hurt to figuring it out. Com ports have always been a bain of my exhistence, but plug and play has come a long way since I last had to deal with them. I will try it when I am not having problems so I see what it looks like normally. It is strange that the boards don’t throw something voltage related to the screens when this is the problem. I haven’t even been using a screen for this project because I had originally intended to only suggest Armbian, and root 1234. But actually plugging a monitor in and trying DietPi really has opened my eyes to a simpler way that will apply to most people. I think most people will put their media server box on the main TV, but with the emby aps on the TVs you really don’t have to. So I’ll do both.
I would really include ntfs-3g, because without simple instruction that will make some folks pull hair out of their heads, but that’s just me. I guess these things make us all pull the hair out of our heads periodically regardless.
What do you mean by this? Do you mean to be able to connect NTFS drives? Usually using our drive manager should detect the NTFS drive and install ntfs-3g automatically.
The serial interface is quite easy to use, especially with MobaXterm, which helps you to setup your virtual COM-Port in the terminal session:
Just click on “Session”, in the next dialog choose “Serial” and select the COM-Port.
The screenshot example above shows the boot messages of my RISC-V board.
