jshc1

So... .161 works ok. I checked again 5.4 and still no boot. I checked the clean Buster 5.4 installation and the same, 30 seconds heartbeat, and darkness. There is no ssh, hc dead ... I checked clean 4.14 stretch installations and change to 5.4 again darkness. My HC1 just has 5.x allergies I don't know how your HC1 works with 5.x

I saw this behavior on one of 5.4.x I changed to nightly and I probably used current and I had the same symptom as TK, the blue diode is lit all the time and no boot, on DEV, however, as I wrote above, the diode stops lighting and there is no boot. Of course, I'm talking about an update, maybe with a clean installation something is better and works just like yours

Strange, since your hc is booting hmmm ... If I find the time, I'll try a clean installation. Whether it's warm or cold I can't see the difference. I have a maximum clock frequency of 2Ghz and 1.5Ghz, boot problems or stability I didn't have until 5.x The same thing happened at 5.0 but then I thought it was the initial problem of underdevelopment and I hoped that it would be solved over time but remained with me to this day. But if you say that there are problems with stability, then probably I will stay for now at 4.14. Any plans for 4.14.161 in the near future? Because .157 is a bit old ... Currently, arm-conf only shows me DEV when it comes to 5.x PS in the attachment both boot partitions ... Working correctly 4.14.157 and problematic with 5.4.6 Kernels.4_14.157-5.4.6.tar

I can send you the whole boot partition if it helps...

Everything looks similar between 5.4 and 4.14 ... Everything is on SD. Nothing modified. 4.14 works normally without problems I do uptime 20-30 days. Only there is always this problem with boot at 5.x As if something was wrong with armbian-config and the installation procedure or with the 5.x kernel for HC1. I log in. I run armbian-config and System / Other / I change the kernel ... the typical 5.4 installation procedure begins and the old kernel is removed, after which the ssh connection is broken and after a while it gets reboot and HC1 does not get up anymore. Only the blue LED is lit for a while as if it was looking for a boot and goes off, nothing happens. Red and green behave normally. dtb exists and points to the right place. I did the test, restored working 4.14.157 boot partition from backup and manually copied 5.4.6 and changed the links ... the effect is the same no boot and just change the links back to 4.14.157 and it is boot. It seems that specifically with 5.x for hc there is something wrong ... UUID is also ok. Unfortunately, I do not have a cable that would fit the odroid, I only have a regular uart.

This situation has been around for quite a long time with 5.x and HC1. Using armbian-config theoretically the installation is the same as in the case of 4.14.x At the end of the installation, automatic reboot is made and the HC1 does not get up again. Hard power on / off also does nothing. The blue idode will light up for a moment and afterwards go off and nothing happens as if something was wrong with the boot. I have performed the installation 5.x a dozen times always the same so a random error during installation I rather rule out. What's worse, this behavior has always been with 5.x, earlier I just treated it as an error with the early version 5.x but now with 5.4.6 it's a bit too far to ignore it. Any ideas?

My HC1 after changing from 4.14.157 to 5.4.6 using armbian-config is not able to get up ... zero response, no boot Does HC1 work with kernel 5 and boot, can anyone confirm?

https://forum.armbian.com/topic/9277-proccpuinfo-show-only-litlle-cores-on-odroid-hc1-hints-appreciated

HC2 doesn't have AES-NI so I don't know what HA you mean. First, just start using. What transfers do you currently have?

Thank you for showing this. So I installed chromium from sid 72.0.3626.109-1 and it works. But the amount of dependence probably will give me a lot of trouble and probably it will not be worth sacrificing. Now only I will have to go and look what has stopped working through these dependencies ....

jshc1@ODROID-HC1:~$ chromium Received signal 11 SEGV_MAPERR 000000000000 #0 0x0000022d9030 <unknown> #1 0x000002267920 <unknown> #2 0x0000022d937e <unknown> #3 0x0000022d95ac <unknown> #4 0x0000b2cf5fe0 <unknown> #5 0x000000b0214c <unknown> #6 0x0000025be95c <unknown> #7 0x000002a8f91e <unknown> #8 0x0000036afee0 <unknown> #9 0x0000036b0512 <unknown> #10 0x0000036b059c <unknown> #11 0x0000036b05d2 <unknown> #12 0x000002139a56 <unknown> #13 0x000002139a92 <unknown> #14 0x000001fba092 <unknown> #15 0x000001fc5c2e <unknown> #16 0x000001fc6130 <unknown> #17 0x000001098de8 <unknown> #18 0x000001356e64 <unknown> #19 0x00000109a7f6 <unknown> #20 0x00000109b422 <unknown> #21 0x00000108f790 <unknown> #22 0x000001f914bc <unknown> #23 0x000001f91626 <unknown> #24 0x000001f918a8 <unknown> #25 0x000001f9880e <unknown> #26 0x000001f90228 <unknown> #27 0x00000097e510 ChromeMain #28 0x0000b2ce74aa __libc_start_main [end of stack trace] Calling _exit(1). Core file will not be generated. ATTENTION: default value of option force_s3tc_enable overridden by environment. jshc1@ODROID-HC1:~$ [28554:28554:0221/212433.772966:ERROR:sandbox_linux.cc(364)] InitializeSandbox() called with multiple threads in process gpu-process. jshc1@ODROID-HC1:~$ firefox ExceptionHandler::GenerateDump cloned child 28758 ExceptionHandler::SendContinueSignalToChild sent continue signal to child ExceptionHandler::WaitForContinueSignal waiting for continue signal...

The last chromium update has broken chromium, can anyone confirm? 71.0.3639.110-1 It works without a problem 72.0.3626.96-1 It does not start Firefox is still broken from what I see on the armv7 ... now chromium gets hiccups. 4.14.94 / 5.73

Huawei is everywhere ....

HC1 / 5.73 / 4.14.94-odroidxu4

4.19 for xu4 at the moment is a mess. Stay at 4.14 if you are able. I currently have 4.14.87 https://forum.armbian.com/topic/9319-problem-with-underclocking-odroid-hc1hc2xu4-with-kernel41914armbian570/

It's good that the problem is solved. If you have any stubborn program, you can always let it run on specific cores. I'm doing it with Kodi 17.1. This mofo is so greedy on the cores that eats all 8 in 90% regardless of whatever. It just so happens that I use kodi as a poor audio player and I only need to give it three litlle cores to perform its task. it does not occupy big cores, which at the same time allows them to sit on 600Mhz and in theory less heat and electricity.

I'm not sure where the problem is. Your Exynos5422 is detected almost as it should. Only 1800/1300 is bad but it's the fault of 4.19. Are you sure that htop simply does not give you the same cores twice? In my case, htop 2.1.1 on both 4.14 and 4.19 gave the correct reading(2000/1500 - 1800/1300). Make sure that you have the cores properly set in htop. And if you stay on 4.19 remember that you lose 200Mhz on the core.

Ok. I did it right away. ;) I hope that the kernel will be polished in the near future. ;)

Try using 4.14.69. Personally, I have not noticed any problems with HC1 and 4.14.69 lately. However, on 4.19.14 I have problems with clocking ... I am not sure how the situation is up to 4.19.5. But according to Igor 4.19.y is not polished for XU4 (HC1 / 2). And Igor recommends returning to 4.14.y. Personally, I am currently using 4.14.69 for HC1 without problems, so maybe you can try and let us know how the situation looks like. Exynos5422 should be clocked up to 2000Mhz for big and 1500Mhz for LITTLE. 1800/1300 is a reduced bar on 4.19.y

Hey Can anyone confirm the problem with under-clocking in Odroid HC1/HC2/XU4 with Kernel 4.19.14 / Armbian 5.70? I could always reach 2000/1500Mhz without a problem. Currently, after the last Armbian update from 5.60 to 5.70, I noticed a strange behavior that Odroid does not want to reach full clocks. With cpufrequtils min 600 max 2000 and "performance" and clocks do not want to go higher than 1800/1300Mhz temperature cpu 45.0 ° C. No changes just last updates nothing more was touched. After returning to 5.60 and 4.14.69 the CPU runs normally at 2000/1500 .... I also have the impression that HDD sometimes behaves strangely at 5.70 / 4.19.14 According to the @tkaiser suggestion.... -- John Stiles