Joulinar
commented
3 years ago @BillyCorgan1 Can you share the download link if the image used. Thx
Closed BillyCorgan1 closed 3 years ago
Joulinar
commented
3 years ago @BillyCorgan1 Can you share the download link if the image used. Thx
MichaIng
commented
3 years ago When no explicit frequencies are set, the bootloader should apply the defaults for the N2 or N2+ respectively, which matches exactly the two values you now applied manually. So it would be interesting which CPU frequencies were applied before you set them explicitly. If those did not match, it would be a bug in the bootloader or kernel.
If you have a chance, can you revert the boot.ini change, reboot and run cpu to show CPU frequencies?
@Joulinar Everything matches our current N2 image, or is there a reason you suspect that it's not ours?
BillyCorgan1
commented
3 years ago Ok this is the link:
https://dietpi.com/downloads/images/DietPi_OdroidN2-ARMv8-Buster.7z
The SHA256 sum is ead9a9ea0772550679d2fe80ef6baa352635ca3f0461c41584192517f8521258
This matches with my file i.e. the ISO is not corrupted. I checked with HashCheck on Windows 10. I flashed the image with BalenaEtcher and there were no errors so I am happy that the resulting image is not corrupted.
Joulinar
commented
3 years ago @MichaIng Just thinking. sometimes we had images from different sources. So just to have that checked. No special reason 🙂
MichaIng
commented
3 years ago If you find time, please try to revert the boot.ini change (comment the frequency settings again) and see what frequency is applied as fallback/default.
BillyCorgan1
commented
3 years ago Yes I will. I am just trying to get it to boot at the moment and work through what changes I have made. Sorry, I am not very quick at this.
BillyCorgan1
commented
3 years ago OK, here is the output of CPU:
─────────────────────────────────────────────────────
DietPi v7.2.0 (beta) : 17:01 - Tue 25/05/21
─────────────────────────────────────────────────────
- Device model : Odroid N2 (aarch64)
- CPU temp : 34'C : 93'F (Cool runnings)
- LAN IP : 192.168.1.5 (eth0)
- MOTD : Open Beta v7.2 | Please help testing the upcoming release:
https://github.com/MichaIng/DietPi/issues/4409
─────────────────────────────────────────────────────
DietPi Team : MichaIng (lead), Daniel Knight (founder), Joulinar (support)
Image by : DietPi Core Team (pre-image: Meveric)
Web : https://dietpi.com | https://twitter.com/DietPi_
Patreon Legends : Camry2731
Contribute : https://dietpi.com/contribute.html
DietPi Hosting : Powered by https://myvirtualserver.com
dietpi-launcher : All the DietPi programs in one place.
dietpi-config : Feature rich configuration tool for your device.
dietpi-software : Select optimized software for installation.
htop : Resource monitor.
cpu : Shows CPU information and stats.
root@OdroidN2:~# cpu
─────────────────────────────────────────────────────
DietPi CPU Info
Use dietpi-config to change CPU / performance options
─────────────────────────────────────────────────────
Architecture | aarch64
Temperature | 34'C : 93'F (Cool runnings)
Governor | schedutil
Current Freq Min Freq Max Freq
CPU0 | 100 MHz 100 MHz 1896 MHz
CPU1 | 100 MHz 100 MHz 1896 MHz
CPU2 | 1800 MHz 100 MHz 1800 MHz
CPU3 | 1800 MHz 100 MHz 1800 MHz
CPU4 | 1800 MHz 100 MHz 1800 MHz
CPU5 | 1800 MHz 100 MHz 1800 MHz
[ INFO ] DietPi-CPU_info | CPU current frequency, may be affected by this script, due to the processing required to run it.
root@OdroidN2:~#I took the eMMC Chip out after a clean shutdown and edited the boot.ini file to comment (#) out the processor frequencies. It booted normally.
Joulinar
commented
3 years ago Means it is working without the workaround now?
MichaIng
commented
3 years ago The frequencies for the two CPU types are exactly as expected and as you manually set them. So then it looks like the crash was not related to CPU frequencies, respectively your workaround was not a workaround but it was a coincidence that it crashed without frequencies set and did not crash after setting frequencies. The typical mismatch between correlation and causality 🙂.
The question remains why it crashed in the first place. But let's not waste time with guessing, as we have no logs. If that happens again, keep an eye on CPU temperature (perfectly low currently), dmesg (for kernel errors), memory usage, via htop and/or free. Enabling persistent system logs would then help, i.e. setting logging mode to 0 none/custom + mkdir -p /var/log/journal to make all system, service and kernel logs persistent, and after crash journalctl can then be used to review what happened before.
BillyCorgan1
commented
3 years ago Means it is working without the workaround now?
As far as I can tell. I have rebooted it again and it comes up normally.
The frequencies for the two CPU types are exactly as expected and as you manually set them. So then it looks like the crash was not related to CPU frequencies, respectively your workaround was not a workaround but it was a coincidence that it crashed without frequencies set and did not crash after setting frequencies. The typical mismatch between correlation and causality 🙂.
The question remains why it crashed in the first place. But let's not waste time with guessing, as we have no logs. If that happens again, keep an eye on CPU temperature (perfectly low currently),
dmesg(for kernel errors), memory usage, viahtopand/orfree. Enabling persistent system logs would then help, i.e. setting logging mode to 0 none/custom +mkdir -p /var/log/journalto make all system, service and kernel logs persistent, and after crashjournalctlcan then be used to review what happened before.
Is there any way to do this before it crashes? Something I can put into the boot.ini or a setting in the dietpi.ini?
MichaIng
commented
3 years ago Is there any way to do this before it crashes?
You mean enabling persistent log before doing the first boot? The logging mode can be set via dietpi.txt and generally manual commands can run by adding one of two possible scripts to the boot (FAT) partition: https://github.com/MichaIng/DietPi/blob/master/dietpi.txt#L58-L68
Automation_Custom_PreScript.sh runs in early setup step, before network is configured.Automation_Custom_Script.sh as one of the last setup steps, after update and in case chosen software installs.BillyCorgan1
commented
3 years ago Just a quick update. I am having problems with crashes happening when using the system. I will try and get the logs out of the system and I will have to hook it up to my monitor to see what is happening. I have been SSHing in at the moment. It might take a little time but I will feedback with my findings and if I need some help. Thanks.
BillyCorgan1
commented
3 years ago I have been unable to get v7.02 working, It always seems to hang at random moments. I have been able to get it up and running with v6.28. I now have Plex installed and will leave it on to see if it hangs or has any problems.
MichaIng
commented
3 years ago Did you try to update from your working v6.28 image?
I have an idea what might be the problem, as you say it hangs at random moments:
haveged installed, right? dpkg-query -s havegedapt install rng-tools5
sleep 2
systemctl status rngdProbably it's similar to XU4, that the hardware random generator is not usable, and hence haveged is required.
BillyCorgan1
commented
3 years ago Did you try to update from your working v6.28 image?
I have an idea what might be the problem, as you say it hangs at random moments:
* You current image (v6.28) has `haveged` installed, right? `dpkg-query -s haveged` * If so, could you try to install a hardware random generator daemon and see if that functions? ``` apt install rng-tools5 sleep 2 systemctl status rng-tools5 ```Probably it's similar to XU4, that the hardware random generator is not usable, and hence
havegedis required.
I installed using the v6.28 image dated Mon 9 Mar 14:43:47 CET 2020 with a sha256 hash of 8752e5f3d99175fdc43ac831ec571df1072fa9b7dcf2864b93f97b5822e7e47a The v6.28 updated itself, with no problems seen, to v7.2.3. It is on v7.2.3 that I have run the commands below.
These are the command responses as entered:
root@OdroidN2:~# dpkg-query -s haveged
Package: haveged
Status: install ok installed
Priority: optional
Section: misc
Installed-Size: 90
Maintainer: Jérémy Bobbio <lunar@debian.org>
Architecture: arm64
Version: 1.9.13-1
Depends: lsb-base (>= 3.2-14), libc6 (>= 2.17), libhavege2 (>= 1.9.13)
Pre-Depends: init-system-helpers (>= 1.54~)
Suggests: apparmor
Conffiles:
/etc/apparmor.d/usr.sbin.haveged 7d8400e675e94a0dbe65b0f5e6b8fab8
/etc/default/haveged 697e664338da071d73cf17d594b5753c
/etc/init.d/haveged 31ced0bebd90450344174b95765d55f7
Description: Linux entropy source using the HAVEGE algorithm
haveged is a userspace entropy daemon which is not dependent upon the
standard mechanisms for harvesting randomness for the system entropy
pool. This is important in systems with high entropy needs or limited
user interaction (e.g. headless servers).
.
haveged uses HAVEGE (HArdware Volatile Entropy Gathering and Expansion)
to maintain a 1M pool of random bytes used to fill /dev/random
whenever the supply of random bits in dev/random falls below the low
water mark of the device.
.
More information about HAVEGE is available at
http://www.irisa.fr/caps/projects/hipsor/
Homepage: https://issihosts.com/haveged/`
root@OdroidN2:~# apt install rng-tools5
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following package was automatically installed and is no longer required:
linux-image-4.9.213+
Use 'apt autoremove' to remove it.
The following NEW packages will be installed:
rng-tools5
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 19.8 kB of archives.
After this operation, 74.8 kB of additional disk space will be used.
Get:1 https://deb.debian.org/debian buster/main arm64 rng-tools5 arm64 5-4 [19.8 kB]
Fetched 19.8 kB in 0s (79.4 kB/s)
Selecting previously unselected package rng-tools5.
(Reading database ... 21034 files and directories currently installed.)
Preparing to unpack .../rng-tools5_5-4_arm64.deb ...
Unpacking rng-tools5 (5-4) ...
Setting up rng-tools5 (5-4) ...
Created symlink /etc/systemd/system/multi-user.target.wants/rngd.service → /lib/systemd/system/rngd.service.
Processing triggers for systemd (241-7~deb10u7) ...root@OdroidN2:~# sleep 2
root@OdroidN2:~# systemctl status rng-tools5 Unit rng-tools5.service could not be found.
I hope this is useful information for you. Please let me know if you want me to try anything else or need more information. Thanks for your time.
MichaIng
commented
3 years ago Many thanks. Sorry the last command was wrong (my fault), but the first ones point into the direction of my guess already. Please run and print again:
systemctl status rngdMany thanks. Sorry the last command was wrong (my fault), but the first ones point into the direction of my guess already. Please run and print again:
systemctl status rngd
OK, Here are the commands as required. I ran them all so you can see everything.
root@OdroidN2:~# dpkg-query -s haveged
Package: haveged
Status: install ok installed
Priority: optional
Section: misc
Installed-Size: 90
Maintainer: Jérémy Bobbio <lunar@debian.org>
Architecture: arm64
Version: 1.9.13-1
Depends: lsb-base (>= 3.2-14), libc6 (>= 2.17), libhavege2 (>= 1.9.13)
Pre-Depends: init-system-helpers (>= 1.54~)
Suggests: apparmor
Conffiles:
/etc/apparmor.d/usr.sbin.haveged 7d8400e675e94a0dbe65b0f5e6b8fab8
/etc/default/haveged 697e664338da071d73cf17d594b5753c
/etc/init.d/haveged 31ced0bebd90450344174b95765d55f7
Description: Linux entropy source using the HAVEGE algorithm
haveged is a userspace entropy daemon which is not dependent upon the
standard mechanisms for harvesting randomness for the system entropy
pool. This is important in systems with high entropy needs or limited
user interaction (e.g. headless servers).
.
haveged uses HAVEGE (HArdware Volatile Entropy Gathering and Expansion)
to maintain a 1M pool of random bytes used to fill /dev/random
whenever the supply of random bits in dev/random falls below the low
water mark of the device.
.
More information about HAVEGE is available at
http://www.irisa.fr/caps/projects/hipsor/
Homepage: https://issihosts.com/haveged/root@OdroidN2:~# apt install rng-tools5
Reading package lists... Done
Building dependency tree
Reading state information... Done
rng-tools5 is already the newest version (5-4).
The following package was automatically installed and is no longer required:
linux-image-4.9.213+
Use 'apt autoremove' to remove it.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.root@OdroidN2:~# sleep 2`
root@OdroidN2:~# systemctl status rngd
● rngd.service - Start entropy gathering daemon (rngd)
Loaded: loaded (/lib/systemd/system/rngd.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2021-06-08 19:02:24 BST; 1h 47min ago
Docs: man:rngd(8)
Main PID: 4387 (rngd)
Tasks: 1 (limit: 3846)
Memory: 164.0K
CGroup: /system.slice/rngd.service
└─4387 /usr/sbin/rngd -f
Jun 08 19:02:24 OdroidN2 systemd[1]: Started Start entropy gathering daemon (rngd).Sorry, I can't get Github to put the last part in code. I have just left it as it is in case I remove something important.
I hope this helps you. Let me know if you need me to test anything else. Thanks again.
MichaIng
commented
3 years ago Okay, the hardware random generator seems to work fine. Then you should be able to remove haveged. But disable it first only, and when the system starts to hang at random points, re-enable it, and we know that the hardware random generator does not work properly, even that the rngd daemon does not report any issue:
systemctl disable --now havegedto re-enable:
systemctl enable --now havegedBtw, as there was a kernel upgrade (linux-image-4.9.213+ is not longer required), did you reboot since then?
BillyCorgan1
commented
3 years ago Okay, the hardware random generator seems to work fine. Then you should be able to remove haveged. But disable it first only, and when the system starts to hang at random points, re-enable it, and we know that the hardware random generator does not work properly, even that the rngd daemon does not report any issue:
systemctl disable --now havegedto re-enable:
systemctl enable --now havegedBtw, as there was a kernel upgrade (
linux-image-4.9.213+is not longer required), did you reboot since then?
This will be quite long so I will try to be brief.
dd if=/dev/random of=/dev/null bs=1024 count=1 iflag=fullblock and rngtest -c 1000 </dev/random
the tests came back as expected with no known errors shown. I will of course retest if required or you want me to run different tests.
Now the most interesting (or stupid) thing is that I installed the latest version of DietPi with the latest downloadable version from the website. This is now working as expected and I can install it with one problem. This problem I have observed when first reporting this bug but I have now been able to copy the message.
─────────────────────────────────────────────────────
DietPi v7.0.2 : 12:31 - Mon 09/03/20
─────────────────────────────────────────────────────
- LAN IP : 192.168.1.4 (eth0)
[ OK ] DietPi-Login | Checking network connectivity
[ OK ] DietPi-Login | Checking DNS resolver
[ OK ] DietPi-Run_NTPD | systemctl restart systemd-timesyncd
Warning: The unit file, source configuration file or drop-ins of systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
[ INFO ] DietPi-Run_NTPD | Waiting for completion of systemd-timesyncd (1/60)
Warning: The unit file, source configuration file or drop-ins of systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
[ OK ] DietPi-Run_NTPD | systemd-timesyncd synced
Warning: The unit file, source configuration file or drop-ins of systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
[ OK ] Network time sync | CompletedAs you can see there is a problem with the NTPD System service. I have tried to set my time server to time.cloudflare.com in the DietPi config menu and when I try the system reboots itself. I can now not install software due to the time sync hanging:
[ OK ] DietPi-Run_NTPD | systemctl restart systemd-timesyncd
Warning: The unit file, source configuration file or drop-ins of systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
[ INFO ] DietPi-Run_NTPD | Waiting for completion of systemd-timesyncd (1/60)I am wondering if this error is the one that is causing all the problems I have had with the hangs and reboots. I have only noticed this error on my Odroid N2, It did not appear when I installed DietPi on my Raspberry Pi 4. Let me know If you want any more information. Thanks for your time.
Joulinar
commented
3 years ago this should not be an issue as at the end time sync succeeded.
[ OK ] Network time sync | Completed
BillyCorgan1
commented
3 years ago this should not be an issue as at the end time sync succeeded.
[ OK ] Network time sync | Completed
Yes, that is true. Even if I change time server the hang/freeze still happens.
I am at a loss as what to do next with this problem. I am going to stay using the 6.28 version that works and call it a day. I think this bug should be closed if no one else has this problem. I will of course test anything that you want me too if you have any other ideas. Thanks for your time.
MichaIng
commented
3 years ago The "Warning: The unit file, source configuration file or drop-ins of systemd-timesyncd.service changed on disk." can be ignored and does not cause any issue. I see this by times, systemctl daemon-reload solves it, but it should not show up in the first place. I think it can happen when the system time is changed from before to after an mtime timestamp of a systemd unit or so, i.e. it's a visual-only bug or limitation in systemd.
In your second last post I understood that the latest N2 image does work now, or did I misunderstood? Or is it that you need to preserve your data/config with the production image, and once you upgrade it, it starts to cause the issue?
I bet that the kernel upgrade triggers the issue, in case. We meanwhile also updated the boot config, mostly to support the N2+, but probably other changes in it are somehow required/helpful with the latest kernel upgrade. As the new boot.ini is included in our latest N2 image, this one relevant difference I can think of, compared to updating an older image.
BillyCorgan1
commented
3 years ago I apologise for not replying sooner. I cannot get the latest image that I download from the website to work. it just crashes and reboots on the following command:
DietPi-Update
─────────────────────────────────────────────────────
Phase: Checking for available DietPi update
[ INFO ] DietPi-Update | Getting repository version: https://raw.githubusercontent.com/MichaIng/DietPi/beta/.update/versionThere is no log file that I can get. There is no issue if I use the 6.28 version from early 2020. It works as expected.
MichaIng
commented
3 years ago ~Does the v6.28 image still work if you upgrade the kernel via apt full-upgrade?~
Ah sorry, you verified this working already above, I think. So it is the image, not the kernel or DietPi version which causes the issue, right?
It must be the boot.ini then. Can you paste it:
cat /boot/boot.iniThis is the boot.ini of v6.28 to v7.23:
root@OdroidN2:~# cat /boot/boot.ini
ODROIDN2-UBOOT-CONFIG
# Default Console Device Setting
setenv condev "console=ttyS0,115200n8" # on both
# Auto Detection of Monitor settings based on your Screen information
setenv display_autodetect "true"
# HDMI Mode
# Resolution Configuration
# Symbol | Resolution
# ----------------------+-------------
# "480x272p60hz" | 480x272 Progressive 60Hz
# "480x320p60hz" | 480x320 Progressive 60Hz
# "480p60hz" | 720x480 Progressive 60Hz
# "576p50hz" | 720x576 Progressive 50Hz
# "720p60hz" | 1280x720 Progressive 60Hz
# "720p50hz" | 1280x720 Progressive 50Hz
# "1080p60hz" | 1920x1080 Progressive 60Hz
# "1080p50hz" | 1920x1080 Progressive 50Hz
# "1080p30hz" | 1920x1080 Progressive 30Hz
# "1080p24hz" | 1920x1080 Progressive 24Hz
# "1080i60hz" | 1920x1080 Interlaced 60Hz
# "1080i50hz" | 1920x1080 Interlaced 50Hz
# "2160p60hz" | 3840x2160 Progressive 60Hz
# "2160p50hz" | 3840x2160 Progressive 50Hz
# "2160p30hz" | 3840x2160 Progressive 30Hz
# "2160p25hz" | 3840x2160 Progressive 25Hz
# "2160p24hz" | 3840x2160 Progressive 24Hz
# "smpte24hz" | 3840x2160 Progressive 24Hz SMPTE
# "2160p60hz420" | 3840x2160 Progressive 60Hz YCbCr 4:2:0
# "2160p50hz420" | 3840x2160 Progressive 50Hz YCbCr 4:2:0
# "640x480p60hz" | 640x480 Progressive 60Hz
# "800x480p60hz" | 800x480 Progressive 60Hz
# "800x600p60hz" | 800x600 Progressive 60Hz
# "1024x600p60hz" | 1024x600 Progressive 60Hz
# "1024x768p60hz" | 1024x768 Progressive 60Hz
# "1280x800p60hz" | 1280x800 Progressive 60Hz
# "1280x1024p60hz" | 1280x1024 Progressive 60Hz
# "1360x768p60hz" | 1360x768 Progressive 60Hz
# "1440x900p60hz" | 1440x900 Progressive 60Hz
# "1600x900p60hz" | 1600x900 Progressive 60Hz
# "1600x1200p60hz" | 1600x1200 Progressive 60Hz
# "1680x1050p60hz" | 1680x1050 Progressive 60Hz
# "1920x1200p60hz" | 1920x1200 Progressive 60Hz
# "2560x1080p60hz" | 2560x1080 Progressive 60Hz
# "2560x1440p60hz" | 2560x1440 Progressive 60Hz
# "2560x1600p60hz" | 2560x1600 Progressive 60Hz
# "3440x1440p60hz" | 3440x1440 Progressive 60Hz
setenv hdmimode "1080p60hz"
# Overscan percentage
# This value scales down the actual screen size by the percentage below
# valid range is 80 to 100
setenv overscan "100"
### voutmode : hdmi or dvi
setenv voutmode "hdmi"
# setenv voutmode "dvi"
# HPD enable/disable option
setenv disablehpd "false"
# Hardkernel ODROID-VU7 support
# By default VU7 support is disabled
setenv disable_vu7 "true"
# setenv disable_vu7 "false"
# max cpu frequency for big core, A73 in MHz unit
# setenv max_freq_a73 "2004" # 2.004 GHz
# setenv max_freq_a73 "1992" # 1.992 GHz
# setenv max_freq_a73 "1908" # 1.908 GHz
setenv max_freq_a73 "1800" # 1.8 GHz, default value
# setenv max_freq_a73 "1704" # 1.704 GHz
# max cpu frequency for little core, A53 in MHz unit
# setenv max_freq_a53 "1992" # 1.992 GHz
setenv max_freq_a53 "1896" # 1.896 GHz, default value
# setenv max_freq_a53 "1704" # 1.704 GHz
# max cpu-cores
# Note:
# CPU's 0 and 1 are the A53 (small cores)
# CPU's 2 to 5 are the A73 (big cores)
# Lowering this value disables only the bigger cores (the last cores).
# setenv maxcpus "4"
# setenv maxcpus "5"
setenv maxcpus "6"
### Normal HDMI Monitors
if test "${display_autodetect}" = "true"; then hdmitx edid; fi
if test "${hdmimode}" = "custombuilt"; then setenv cmode "modeline=${modeline}"; fi
# VU7 Settings
if test "${disable_vu7}" = "false"; then setenv hid_quirks "usbhid.quirks=0x0eef:0x0005:0x0004"; fi
# Boot Args
setenv bootargs "root=UUID=e139ce78-9841-40fe-8823-96a304a09859 rootwait rw ${condev} ${amlogic} no_console_suspend fsck.repair=yes net.ifnames=0 elevator=noop hdmimode=${hdmimode} cvbsmode=576cvbs max_freq_a53=${max_freq_a53} max_freq_a73=${max_freq_a73} maxcpus=${maxcpus} voutmode=${voutmode} disablehpd=${disablehpd} ${hid_quirks} ${cmode} overscan=${overscan} cvbscable=${cvbscable}"
# Set load addresses
setenv dtb_loadaddr "0x1000000"
setenv k_addr "0x1100000"
setenv loadaddr "0x1B00000"
setenv initrd_loadaddr "0x3700000"
# Load kernel, dtb and initrd
fatload mmc ${devno}:1 ${k_addr} Image.gz
fatload mmc ${devno}:1 ${dtb_loadaddr} meson64_odroidn2.dtb
fatload mmc ${devno}:1 ${initrd_loadaddr} uInitrd
fdt addr ${dtb_loadaddr}
# unzip the kernel
unzip ${k_addr} ${loadaddr}
# boot
booti ${loadaddr} ${initrd_loadaddr} ${dtb_loadaddr}
root@OdroidN2:~#
`
This is the boot.ini that I have pulled from the iso 0f v7.02:
`ODROIDN2-UBOOT-CONFIG
setenv board "odroidn2"
# Serial console device: /dev/tty1 is appended automatically
setenv condev "console=ttyS0,115200n8"
# Auto-detection of monitor settings based on your screen information: "false" or "true"
setenv display_autodetect "true"
# Toggle HDMI output: "false" or "true"
setenv monitor_onoff "false"
# Force SDR or HDR mode: "sdr", "hdr" or "auto"
setenv sdrmode "auto"
# Toggle CEC support: "false" or "true"
setenv cec "true"
# Toggle Wake-On-Lan support: 0=disable, 1=enable
setenv enable_wol "0"
# Device tree overlays
# See /boot/overlays/odroidn2/ for available overlays, e.g.:
# - hktft32: 3.2" TFT from HardKernel
# - hktft35: 3.5" TFT from HardKernel
#setenv overlays "spi0 i2c0 i2c1 uart0"
# HDMI mode resolution configuration
# Symbol | Resolution
# ----------------------+-------------
# "480x272p60hz" | 480x272 Progressive 60Hz
# "480x320p60hz" | 480x320 Progressive 60Hz
# "480p60hz" | 720x480 Progressive 60Hz
# "576p50hz" | 720x576 Progressive 50Hz
# "720p60hz" | 1280x720 Progressive 60Hz
# "720p50hz" | 1280x720 Progressive 50Hz
# "1080p60hz" | 1920x1080 Progressive 60Hz
# "1080p50hz" | 1920x1080 Progressive 50Hz
# "1080p30hz" | 1920x1080 Progressive 30Hz
# "1080p24hz" | 1920x1080 Progressive 24Hz
# "1080i60hz" | 1920x1080 Interlaced 60Hz
# "1080i50hz" | 1920x1080 Interlaced 50Hz
# "2160p60hz" | 3840x2160 Progressive 60Hz
# "2160p50hz" | 3840x2160 Progressive 50Hz
# "2160p30hz" | 3840x2160 Progressive 30Hz
# "2160p25hz" | 3840x2160 Progressive 25Hz
# "2160p24hz" | 3840x2160 Progressive 24Hz
# "smpte24hz" | 3840x2160 Progressive 24Hz SMPTE
# "2160p60hz420" | 3840x2160 Progressive 60Hz YCbCr 4:2:0
# "2160p50hz420" | 3840x2160 Progressive 50Hz YCbCr 4:2:0
# "640x480p60hz" | 640x480 Progressive 60Hz
# "800x480p60hz" | 800x480 Progressive 60Hz
# "800x600p60hz" | 800x600 Progressive 60Hz
# "1024x600p60hz" | 1024x600 Progressive 60Hz
# "1024x768p60hz" | 1024x768 Progressive 60Hz
# "1280x800p60hz" | 1280x800 Progressive 60Hz
# "1280x1024p60hz" | 1280x1024 Progressive 60Hz
# "1360x768p60hz" | 1360x768 Progressive 60Hz
# "1440x900p60hz" | 1440x900 Progressive 60Hz
# "1600x900p60hz" | 1600x900 Progressive 60Hz
# "1600x1200p60hz" | 1600x1200 Progressive 60Hz
# "1680x1050p60hz" | 1680x1050 Progressive 60Hz
# "1920x1200p60hz" | 1920x1200 Progressive 60Hz
# "2560x1080p60hz" | 2560x1080 Progressive 60Hz
# "2560x1440p60hz" | 2560x1440 Progressive 60Hz
# "2560x1600p60hz" | 2560x1600 Progressive 60Hz
# "3440x1440p60hz" | 3440x1440 Progressive 60Hz
setenv hdmimode "1080p60hz"
# Custom modeline
# To use a custom modeline you need to comment "setenv hdmimode" above,
# uncomment the two settings below and adjust "setenv modeline" to your needs:
# http://odroid.com/dokuwiki/doku.php?id=en:c2_hdmi_autosetting
#setenv hdmimode "custombuilt"
#setenv modeline "2560,1440,241500,88800,60,2560,2608,2640,2720,1440,1442,1447,1481,1,1,1"
# Toggle composite video (CVBS) output: "0" or "1"
setenv cvbscable "0"
# Composite video (CVBS) mode: "480cvbs" (NTSC) or "576cvbs" (PAL)
setenv cvbsmode "576cvbs"
# Overscan percentage
# This value scales down the actual screen size by the percentage below.
# Valid range is 80 to 100.
setenv overscan "100"
# Output mode: "hdmi" or "dvi"
# "dvi" disables HDMI audio.
setenv voutmode "hdmi"
# Disable HDMI hot-plug detection and force HDMI output: "false" or "true"
setenv disablehpd "false"
# Disable Hardkernel ODROID-VU7 LCD support: "false" or "true" (default)
setenv disable_vu7 "true"
# Max CPU frequency for big A73 cores in MHz
# - Valid values on Odroid N2: 500, 667, 1000, 1200, 1398, 1512, 1608, 1704, 1800 (default), 1908, 2004
# - Valid values on Odroid N2+: 500, 667, 1000, 1200, 1398, 1512, 1608, 1704, 1800, 1908, 2016, 2100, 2208 (default), 2304, 2400
#setenv max_freq_a73 "2004"
# Max CPU frequency for small A53 cores in MHz
# - Valid values on Odroid N2: 100, 250, 500, 667, 1000, 1200, 1398, 1512, 1608, 1704, 1896 (default), 1992
# - Valid values on Odroid N2+: 500, 667, 1000, 1200, 1398, 1512, 1608, 1704, 1800, 1908 (default), 2016
#setenv max_freq_a53 "1992"
# Max CPU cores
# CPU's 0 and 1 are the A53 (small cores)
# CPU's 2 to 5 are the A73 (big cores)
# Lowering this value disables only the bigger cores (the last cores).
# Valid range is 1 to 6.
setenv maxcpus "6"
### DO NOT EDIT ANYTHING BELOW THIS LINE ###
# Apply HDMI settings
if test "${display_autodetect}" = "true"; then hdmitx edid; fi
if test "${hdmimode}" = "custombuilt"; then setenv cmode "modeline=${modeline}"; fi
# Apply CEC setting
if test "${cec}" = "true"; then setenv cec_enable "hdmitx=cec3f"; fi
# Apply VU7 settings
if test "${disable_vu7}" = "false"; then setenv hid_quirks "usbhid.quirks=0x0eef:0x0005:0x0004"; fi
# Apply CPU frequencies if assigned
if test "x${max_freq_a73}" != "x"; then setenv a73_freq "max_freq_a73=${max_freq_a73}"; fi
if test "x${max_freq_a53}" != "x"; then setenv a53_freq "max_freq_a53=${max_freq_a53}"; fi
# Label for petitboot
setenv bootlabel "DietPi (64-bit)"
# Boot args
setenv bootargs "root=UUID=e139ce78-9841-40fe-8823-96a304a09859 rootwait ro ${condev} ${amlogic} no_console_suspend fsck.repair=yes net.ifnames=0 elevator=noop hdmimode=${hdmimode} cvbsmode=${cvbsmode} maxcpus=${maxcpus} voutmode=${voutmode} disablehpd=${disablehpd} enable_wol=${enable_wol} ${cec_enable} sdrmode=${sdrmode} consoleblank=0 logo=osd0,loaded monitor_onoff=${monitor_onoff} ${hid_quirks} ${cmode} overscan=${overscan} cvbscable=${cvbscable} ${a73_freq} ${a53_freq}"
# Set load addresses
setenv dtb_loadaddr "0x1000000"
setenv k_addr "0x1100000"
setenv loadaddr "0x1B00000"
setenv initrd_loadaddr "0x3700000"
# Load kernel, dtb and initrd
fatload mmc ${devno}:1 ${k_addr} Image.gz
fatload mmc ${devno}:1 ${dtb_loadaddr} meson64_odroid${variant}.dtb
fatload mmc ${devno}:1 ${initrd_loadaddr} uInitrd
fdt addr ${dtb_loadaddr}
# Load device tree overlays
if test "x${overlays}" != "x"; then
setenv dtbo_addr_r "0x11000000"
fdt resize "16384"
for overlay in ${overlays}; do
fatload mmc ${devno}:1 ${dtbo_addr_r} overlays/${board}/${overlay}.dtbo && fdt apply ${dtbo_addr_r}
done
fi
# Unzip the kernel
unzip ${k_addr} ${loadaddr}
# Boot
booti ${loadaddr} ${initrd_loadaddr} ${dtb_loadaddr}I think there is a problem with this part of the boot.ini:
# Load kernel, dtb and initrd fatload mmc ${devno}:1 ${k_addr} Image.gz fatload mmc ${devno}:1 ${dtb_loadaddr} meson64_odroid${variant}.dtb fatload mmc ${devno}:1 ${initrd_loadaddr} uInitrd fdt addr ${dtb_loadaddr}
I ignored the warning and edited meson64_odroid${variant}.dtb to meson64_odroidn2.dtb and the system booted up as expected and I was able to install DietPi. It rebooted once during dietpi-config but I was able to finish and install Plex and Samba. I am wondering if there is a problem with which variant is being called.
MichaIng
commented
3 years ago That is mysterious. If the variant variable wouldn't be set, or set to anything different than n2 or n2_plus it would fail to boot in the first place as no device tree would be found. If it boots, it is set to one of these two, so if some part firmware/bootloader side would be outdated to not set the variable "correctly", then it is nearly assured to be n2 on N2+ instead of n2_plus on N2 non-plus. As before also setting the CPU frequencies explicitly seemed to have solved the issue, while without doing that in fact the exact same frequencies were used, I still bet that it is not related to a wrong variable or board detection, and that actual issues do appear a bit random, so that it succeeds sometimes and fails sometimes, which makes it difficult to reliably reproduce it and derive whether a change fixed it or not.
Can you please paste the whole output of dmesg, probably we see some hint there.
BillyCorgan1
commented
3 years ago OK, here is the output of dmesg after booting:
Joulinar
commented
3 years ago question, in your first post you stated on the questionnaire you are running Debian Buster, however on your kernel log it looks like Debian Stretch
[ 0.000000] Linux version 4.9.241-arm64 (root@odroid-stretch64) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP PREEMPT Thu Feb 25 18:56:07 CET 2021
BillyCorgan1
commented
3 years ago question, in your first post you stated on the questionnaire you are running Debian Buster, however on your kernel log it looks like Debian Stretch
[ 0.000000] Linux version 4.9.241-arm64 (root@odroid-stretch64) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP PREEMPT Thu Feb 25 18:56:07 CET 2021
That is strange! I thought I was using buster as that is what is written on the description of the ISO image from the DietPi website DietPi_OdroidN2-ARMv8-Buster.img. I don't know why it would be stating that.
Joulinar
commented
3 years ago @MichaIng do you know if this is a correct information or just misleading?
@BillyCorgan1
just to be sure, what is the output of echo $G_DISTRO_NAME and cat /etc/debian_version
BillyCorgan1
commented
3 years ago @Joulinar
Here are the two outputs you requested:
root@OdroidN2:~# echo $G_DISTRO_NAME buster root@OdroidN2:~# cat /etc/debian_version 10.10 root@OdroidN2:~#
I hope this helps, Thanks.
MichaIng
commented
3 years ago The uname -a line does not show the Debian/OS versions of the system it is installed on, but it was built on. So we know that kernel was build on a Debian Stretch system, with hostname odroid-stretch64 as root user and Debian glibc compiler version 6.3.0-18+deb9u1 😉. Also in case of Odroids, the same kernel packages are used on all distro versions, so unlike on RPi or x86_64 systems also the Linux version does not say something about the Debian version of the system.
The kernel command line was set as wanted, sadly we cannot see which device tree was used, but all drivers load nicely, aside of the audio codec, which throws some errors, which may be expected when no speakers are attached.
But I have an idea now: With v7.2 we changed the default CPU scheduling governor from ondemand to schedutil, which is generally more efficient, but probably the N2 has issues with it:
G_CONFIG_INJECT 'CONFIG_CPU_GOVERNOR=' 'CONFIG_CPU_GOVERNOR=ondemand' /boot/dietpi.txtrespectively doing that before first boot.
BillyCorgan1
commented
3 years ago The
uname -aline does not show the Debian/OS versions of the system it is installed on, but it was built on. So we know that kernel was build on a Debian Stretch system, with hostnameodroid-stretch64as root user and Debian glibc compiler version6.3.0-18+deb9u1😉. Also in case of Odroids, the same kernel packages are used on all distro versions, so unlike on RPi or x86_64 systems also the Linux version does not say something about the Debian version of the system.The kernel command line was set as wanted, sadly we cannot see which device tree was used, but all drivers load nicely, aside of the audio codec, which throws some errors, which may be expected when no speakers are attached.
But I have an idea now: With v7.2 we changed the default CPU scheduling governor from
ondemandtoschedutil, which is generally more efficient, but probably the N2 has issues with it:G_CONFIG_INJECT 'CONFIG_CPU_GOVERNOR=' 'CONFIG_CPU_GOVERNOR=ondemand' /boot/dietpi.txtrespectively doing that before first boot.
I have just pulled the dietpi.txt file from the ISO I have been using and the CONFIG_CPU_GOVERNOR is already set to on demand.
MichaIng
commented
3 years ago Ah indeed, the image was created after v7.2 release, hence after the default was changed. You could try to change it to powersave, performance or conservative to have a static or slowly adapting governor, just to rule that out. I'll also create a new image tomorrow, after v7.3 release and review everything again.
BillyCorgan1
commented
3 years ago Ah indeed, the image was created after v7.2 release, hence after the default was changed. You could try to change it to powersave, performance or conservative to have a static or slowly adapting governor, just to rule that out. I'll also create a new image tomorrow, after v7.3 release and review everything again.
Well, I changed the CPU governor to "performance" and it now boots as it should and it didn't reboot in the dietpi-config launcher. I did not make any other changes to boot.ini or dietpi.txt and it was a clean reinstall. I will try the other governor settings to see if they work and boot.
BillyCorgan1
commented
3 years ago OK, powersave failed, conservative worked.
MichaIng
commented
3 years ago Hmm, I do not really trust this as a definite result yet, as actually powersave should be the most stable governor, statically using the lower-end frequency. But the conservative governor is quite some alternative, if ondemand and schedutil cause issues, as it also clocks up to max frequencies, only in smaller steps. ondemand jumps the frequency right to max, as fast as the configured threshold is reached (50% by default) and schedutil usually includes a lot more and quicker frequency adjustments, which makes it very effective, but possibly some older CPUs have issues with that, or older Linux versions do have it implemented as good.
We didn't enable boot-persistent system logs to try catching what happened right before the crash, did we? That would be another way to possibly debug the case. But that probably makes more sense based on a fresh reviewed image, which I'll create tomorrow.
MichaIng
commented
3 years ago New image ready: https://dietpi.com/downloads/images/DietPi_OdroidN2-ARMv8-Buster.7z
BillyCorgan1
commented
3 years ago New image ready: https://dietpi.com/downloads/images/DietPi_OdroidN2-ARMv8-Buster.7z
Sadly the new image has not fixed the issue. I am still having problems with it crashing and rebooting. Thanks for your hard work though. Can you supply me with a command so that I can enable logging to see if I can give you some more information on the crashes? Thanks for your time.
MichaIng
commented
3 years ago Do the following, I hope they go through:
dietpi-software uninstall 103
mkdir /var/log/journal
rebootNow /var/log is no tmpfs anymore and the journalctl system logs are done to /var/log/journal automatically, when the directory is present.
BillyCorgan1
commented
3 years ago OK, the bad news first. I am unable to get to a point where I am able to put the commands into a prompt. The slightly good news is that I connected my Odroid via HDMI and keyboard to my monitor. It has (so far) in my testing started up and installs as expected. I will continue testing and reinstalling for the the next few days to see if anything changes. If the problem is something to do with SSH then I don't know what causes it to restart itself. I am using MobaXterm to SSH into the Odroid N2. I will update you with the results of my testing. Thanks for your time and help.
BillyCorgan1
commented
3 years ago After doing some more testing it seems that, sadly, SSH is not the issue. I am still having problems with the Odroid N2 rebooting itself while connected to the monitor with an HDMI cable and keyboard. I will try and see if I can get some logs off of the Odroid.
MichaIng
commented
3 years ago Did you get some system logs from the minutes before the unexpected reboot?
MichaIng
commented
3 years ago Marking as closed. Feel free to reopen if issue persists. We'll also upload a new Debian Bullseye based image the next days.
Required Information
Additional Information (if applicable)
echo $G_HW_UUIDNot ApplicableSteps to reproduce
Expected behaviour
Actual behaviour
Extra details
I have edited the file so that setenv max_freq_a73 and setenv max_freq_a73 are uncommeneted and put to their default values.
With this fix I am able to get the installation to work and install to the latest 7.2 beta version. I am unable to test this fix on an Odroid N2+ (Plus)as I don't own one. I am aware of a person with an Odroid N2+ (Plus) who had trouble getting the install to work. I can try and find the thread if required. This to me is a severe bug as a new user of DietPi using an Odroid N2 would not be able to use DietPi at all without this fix. I, of course, don't know how complicated it will be to fix. I of course remain available to test any fix and provide information to you. Thanks for your time.