Patrick Peters

  • Content Count

  • Joined

  • Last visited

  1. UPDATE: unloading the module also in some cases did not work. I found out that using the default ondemand governor but changing the lower frequency to the max frequency does 'fix' this problem. So to test it you can use the following command: cpufreq-set -d 1.15G Keep in mind the 1.15G is an example. You can find the max. supported frequency with the command: cpufreq-info To make the changes permanent at each reboot create or edit the file at: /etc/default/cpufrequtils
  2. Hi Gogoer, I did recompiled u-boot myself also the kernel for the Gentoo distribution, but i did not yet do anything with the emmc unit (on my Pine64-LTS) so i do not know exactly how u-boot knows which device to read and wirte environment data from/to. I expect this to be hardcoded in the u-boot bootloader when first time creating it with the make config command (during recompile of u-boot). I expect some config settings indicating the environment device. But u-boot has made some major changes during the last year, so it could also be possible that there is some sort of autodetect possible. I don't have any experience with the Orange Pi, but i would expect Armbian to work in the same way. Can't you just boot up your system first, then edit the arnbianenv.txt in the /boot directory, use armbian-config to update emmc u-boot and after that follow the recompile steps i post earlier?
  3. You can use plymouth to create a splash boot. I have done this on a Pine64-LTS board so maybe you need to alter some steps. First step is to create a custom boot logo image for u-boot to show. I am not really sure which file you need exactly but to be sure just use the same image as boot logo and save the images in /boot 1 file named boot-desktop.png in /boot/boot-desktop.png 1 file named boot.bmp in /boot/boot.bmp If you don't want to lose the original ones, back-up them first: cp /boot/boot-desktop.png /boot/boot-desktop.png-orig cp /boot/boot.bmp /boot/boot.bmp-orig Next reboot you will notice you are having a nice new boot image, but you will probably also notice that the kernel boot messages are written over this screen and/or maybe also the init boot messages. Sadly this is due to the fact that u-boot isn't compled with silent boot support. It would have been nice, because you could then set a parameter to use it in silent or not. Now we first have to recompile the u-boot with a patch to silence the boot messages. Use the default Armbian build guide and before you start compiling you need to enable a u-boot patch. You can try to enable the patch, but i tried it and it failed applying due to some inconsistencies. I changed the patch so it now works. I don't know how i should give this patch change to the correct maintainer, so i will place it here: patch file located in -><armbian git clone dir>/20.02.2/build/patch/u-boot/u-boot-sunxi File name -> remove-boot-messages-from-hdmi.patch.disabled You should normally only have to remove the '.disabled' part to make use of this patch. But since this version did not work i created a new file called: remove-boot-messages-from-hdmi.patch containing: diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -438,12 +438,12 @@ #ifdef CONFIG_VIDEO #define CONSOLE_STDOUT_SETTINGS \ - "stdout=serial,vga\0" \ - "stderr=serial,vga\0" + "stdout=serial\0" \ + "stderr=serial\0" #elif CONFIG_DM_VIDEO #define CONSOLE_STDOUT_SETTINGS \ - "stdout=serial,vidconsole\0" \ - "stderr=serial,vidconsole\0" + "stdout=serial\0" \ + "stderr=serial\0" #else #define CONSOLE_STDOUT_SETTINGS \ "stdout=serial\0" \ After creating this file you can use the Armbian build guide to create a new 'release'. Use the deb files in the output path located at: <armbian git clone dir>/20.02.2/build/output/debs The most important file is -> linux-u-boot-current-pine64so_20.05.0-trunk_arm64.deb Keep in mind i am describing these steps for a Pine64-LTS, the idea stays the same... Put the deb file on your unit and install the package with: dpkg -i linux-u-boot-current-pine64so_20.05.0-trunk_arm64.deb Once this is finished you also have to save this u-boot img to mmc/sdcard or whatever you are using. You can do this with armbian-config. Start armbian-config and select menu item 'system' then 'install' and then '5 Install/Update the bootloader on sD/eMMC' . Once finished you will have the new u-boot on your system. To really make sure you are not getting any messages to your console make the following changes to your armbianEnv.txt verbosity=0 console=custom consoleargs="console=ttyS0,115200 console=tty7" #extraargs=vt.global_cursor_default=0 quiet splash fbcon=rotate:3 plymouth.ignore-serial-consoles extraargs=vt.global_cursor_default=0 quiet splash plymouth.ignore-serial-consoles stdout=serial vt.global_cursor_default=0 makes sure you dont see any blinking cursor in the upper left corner quiet makes sure you don't get extra kernel messages. splash enables kernel splash logo. fbcon=rotate:3 you don't need to and is only needed on LCD's or HDMI units that are rotated. plymouth.ignore-serial-consoles makes sure plymouth ignores the /dev/ttyS0 console because else plymouth wont continue and you wont get any video driver attached to plymouth. stdout=serial makes sure the boot.scr does not do his own thing. Once you made all these changes you can do a reboot and notice that you will see a splash screen followed by a long silence black screen and then the login prompt (or desktop if you are using desktop image). You can now install plymouth to also show splash screen (takeover) from the point where u-boot left. apt-get install plymouth apt-get install plymouth-themes Now you can try a default theme, for example spinner: plymouth-set-default-theme spinner To make really sure the initrd also starts plymouth i ran an extra initrd update: update-initramfs -u Ok, now you should be done. Reboot the system and enjoy the splash boot and loader.
  4. Hi Martinayotte, Thank you for your fast reaction. Nice to know the next release is again a bit better
  5. I am currently using the Armbian 20.02 release and doing some tests with the serial ports of a Pine64-LTS board. I noticed that i could not get all the serial ports to work. I needed to make a couple of changes in order to get them all working. Maybe i did something wrong and my changes were not needed, but i still would like to list them here in order to help other users who are having problems with the serial ports. When first starting up the armbian release i used the armbian-config tool to enable the uart 1, uart 2, uart 3 and uart4. I rebooted but noticed not all ports where present. I noticed a message in the dmesg log showing ttyS4 error -28. After some research (zcat /proc/config.gz) i noticed the kernel was compiled with only max 4 serial ports -> CONFIG_SERIAL_8250_NR_UARTS=4 Sadly this meant i had to recompile the kernel since this item can't be increased with a kernel parameter setting. After recompiling the kernel with CONFIG_SERIAL_8250_NR_UARTS=16 and CONFIG_SERIAL_8250_RUNTIME_UARTS=5 i rebooted the system with the new kernel and this time got the last uart 4 (addressed by 1c29000.serial) initialized (no more error -28). I did noticed a new problem. The uart 1 (addressed by 1c28400.serial) was initialized by the kernel as /dev/ttyS1 but after looking in the /dev directory there was no /dev/ttyS1 I did some more research and thought this was due to the bluetooh hci_uart or other bluetooth items. So i blacklisted the modules by creating files in /dev/modprobe.d/<module name>.conf containing the line 'blacklist <module name>'. This stopped the bluetooth modules from loading but still the /dev/ttyS1 got lost. I thought this was probably due to some issue in the dtb file so i converted the /boot/dtb/allwinner/sun50i-a64-pine64-lts.dtb file to a dts file so i could read what was going on (using the dtc command): dtc -I dtb -O dts -o sun50i-a64-pine64-lts.dts sun50i-a64-pine64-lts.dtb In the dts file i noticed the uart 1 (addressed by 1c28400.serial) also contained a bluetooth part: serial@1c28400 { compatible = "snps,dw-apb-uart"; reg = < 0x1c28400 0x400 >; interrupts = < 0x00 0x01 0x04 >; reg-shift = < 0x02 >; reg-io-width = < 0x04 >; clocks = < 0x02 0x44 >; resets = < 0x02 0x2f >; status = "okay"; pinctrl-names = "default"; pinctrl-0 = < 0x32 0x33 >; phandle = < 0x76 >; bluetooth { compatible = "realtek,rtl8723bs-bt"; reset-gpios = < 0x34 0x00 0x04 0x01 >; device-wake-gpios = < 0x34 0x00 0x05 0x00 >; host-wake-gpios = < 0x34 0x00 0x06 0x00 >; firmware-postfix = "pine64"; }; }; I removed the complete bluetooth part, so this part looked like: serial@1c28400 { compatible = "snps,dw-apb-uart"; reg = < 0x1c28400 0x400 >; interrupts = < 0x00 0x01 0x04 >; reg-shift = < 0x02 >; reg-io-width = < 0x04 >; clocks = < 0x02 0x44 >; resets = < 0x02 0x2f >; status = "okay"; pinctrl-names = "default"; pinctrl-0 = < 0x32 0x33 >; phandle = < 0x76 >; }; I first made a backup of the original dtb file: cp /boot/dtb/allwinner/sun50i-a64-pine64-lts.dtb /boot/dtb/allwinner/sun50i-a64-pine64-lts.dtb-orig I then converted the altered dts file back into a dtb format with the help of the following command: dtc -I dts -O dtb -o sun50i-a64-pine64-lts.dtb sun50i-a64-pine64-lts.dts I rebooted the system and this time i did got all 5 serial ports working and also available via /dev/ttyS* device nodes. dmesg log (serial lines) [ 2.877614] 1c28000.serial: ttyS0 at MMIO 0x1c28000 (irq = 30, base_baud = 1500000) is a U6_16550A [ 2.929097] 1c28400.serial: ttyS1 at MMIO 0x1c28400 (irq = 31, base_baud = 1500000) is a U6_16550A [ 2.952307] 1c28800.serial: ttyS2 at MMIO 0x1c28800 (irq = 32, base_baud = 1500000) is a U6_16550A [ 2.975520] 1c28c00.serial: ttyS3 at MMIO 0x1c28c00 (irq = 33, base_baud = 1500000) is a U6_16550A [ 2.998728] 1c29000.serial: ttyS4 at MMIO 0x1c29000 (irq = 34, base_baud = 1500000) is a U6_16550A ls -al /dev/ttyS* crw-rw---- 1 root dialout 4, 64 Feb 25 12:54 /dev/ttyS0 crw-rw---- 1 root dialout 4, 65 Feb 25 11:42 /dev/ttyS1 crw-rw---- 1 root dialout 4, 66 Feb 25 11:42 /dev/ttyS2 crw-rw---- 1 root dialout 4, 67 Feb 25 11:42 /dev/ttyS3 crw-rw---- 1 root dialout 4, 68 Feb 25 11:42 /dev/ttyS4 I do not know who is maintaining these parts of Armbian but would like to propose to remove the bluetooth item from the default DTB file and create an overlay for enabling bluetooth. Possibly with the help of armbian-config to enable and disable it. Also the kernel should have at least the amount of uarts enabled to make use of it without recompiling it.
  6. I am using Armbian Buster on Pine64-LTS units. I recently upgraded version 19.11.3 to 20.02.1 and since having problems with high kworker load and strange warning in dmesg output: [ 7.734729] ------------[ cut here ]------------ [ 7.737084] WARNING: CPU: 1 PID: 30 at drivers/clocksource/arm_arch_timer.c:360 sun50i_a64_read_cntpct_el0+0x24/0x30 [ 7.738928] Modules linked in: cpufreq_dt realtek axp20x_usb_power industrialio pinctrl_axp209 dw_hdmi_cec lima dw_hdmi_i2s_audio gpu_sched dwmac_sun8i mdio_mux [ 7.741485] CPU: 1 PID: 30 Comm: kworker/1:1 Not tainted 5.4.20-sunxi64 #20.02.1 [ 7.743435] Hardware name: Pine64 LTS (DT) [ 7.745514] Workqueue: events dbs_work_handler [ 7.747504] pstate: 80000005 (Nzcv daif -PAN -UAO) [ 7.749508] pc : sun50i_a64_read_cntpct_el0+0x24/0x30 [ 7.751489] lr : arch_counter_get_cntpct_stable+0x38/0x78 [ 7.753420] sp : ffff8000110739c0 [ 7.755295] x29: ffff8000110739c0 x28: ffff0000721e6200 [ 7.757379] x27: ffff00007246a200 x26: ffff000077b77098 [ 7.759351] x25: 0000000000000000 x24: 00000000ffffffff [ 7.761348] x23: 0000000000000001 x22: ffff800011073b10 [ 7.763352] hrtimer: interrupt took 26239875 ns [ 7.765224] x21: 0000000000000000 x20: 0000000000000018 [ 7.767278] x19: ffff800010f4f000 x18: 0000000000000001 [ 7.769323] x17: 0000000000000018 x16: 0000000000000002 [ 7.771285] x15: 0000000000000001 x14: 0000000000000001 [ 7.773271] x13: 0000000000000005 x12: 0000000000000021 [ 7.775229] x11: 0000000000000005 x10: 00000000bcd3d800 [ 7.777217] x9 : 0000000000000004 x8 : 0000000000000004 [ 7.779167] x7 : ffff800010f1b5a0 x6 : 00000000112a8800 [ 7.781121] x5 : 0000000000000010 x4 : 000000000000ffff [ 7.783220] x3 : 0000000000000050 x2 : 000000001ad70336 [ 7.785255] x1 : 0000000000000000 x0 : 000000001ad7033c [ 7.787272] Call trace: [ 7.789327] sun50i_a64_read_cntpct_el0+0x24/0x30 [ 7.791318] __delay+0x20/0xa0 [ 7.793261] __udelay+0x28/0x30 [ 7.795273] ccu_mux_notifier_cb+0x5c/0x90 [ 7.797319] notifier_call_chain+0x54/0x90 [ 7.799359] __srcu_notifier_call_chain+0x54/0x90 [ 7.801372] srcu_notifier_call_chain+0x14/0x20 [ 7.803396] __clk_notify+0x88/0xc8 [ 7.805373] clk_propagate_rate_change+0xb8/0xd0 [ 7.807431] clk_core_set_rate_nolock+0x114/0x1b8 [ 7.809441] clk_set_rate+0x34/0xa0 [ 7.811426] dev_pm_opp_set_rate+0x260/0x498 [ 7.813493] set_target+0x3c/0x80 [cpufreq_dt] [ 7.815441] __cpufreq_driver_target+0x18c/0x580 [ 7.817405] od_dbs_update+0x138/0x190 [ 7.819404] dbs_work_handler+0x3c/0x70 [ 7.821455] process_one_work+0x1ec/0x370 [ 7.823545] worker_thread+0x4c/0x4f8 [ 7.825518] kthread+0x120/0x128 [ 7.827490] ret_from_fork+0x10/0x18 [ 7.829444] ---[ end trace 869ed0a5cc6097b4 ]--- I have traced the high kworker load back to the cpufreq-dt module. When unloading this module the high kworker load stops and system is usable again. As a workaround turning off ondemand governor and selecting performance governor looked like it did the job. But on other units with an X graphics desktop i get a much higher kworker load and the system becomes unusable (slow). The only thing that works all the time is unloading the cpufreq-dt module.