All Activity

This stream auto-updates     

  1. Past hour
  2. I just built the lastest armbian sources for BananaPi minimal, which is version Armbian_20.08.0-trunk_Bananapi_buster_current_5.4.44_minimal and startet ist on my BananaPro. After that I got mesa running doing this: ... and kodi on X11 started properly. Got into Kodi->Systeminformation. There it says lima driver is used. This failed on various BananaPro images before. The question is how to integrate that into a build script. Furthermore there seem to be some differences between the image configuration of BananaPi and BananaPro although the only differences are integrated WIFI-Device (Pro) and 40-Pin GPIO (Pro). Therefore there should be no differences between processorelated functionality. Differences known so far (each image tested on bananapro): AHCI does work properly on Pro but fails on Pi, sun4i-drm works on Pi but not on Pro I`m going to try some reverse engineering to find the differences in configuration.
  3. Today
  4. DTBO loaded by U-Boot is always difficult to debug. Maybe you leave it out from U-Boot and try to load it dynamically using /sys/kernel/config/device-tree/overlays/ ? mkdir /sys/kernel/config/device-tree/overlays/myoverlay cat myoverlay.dtbo > /sys/kernel/config/device-tree/overlays/myoverlay/dtbo Then check any errors in "dmesg" ... "verbosity=7" would help, but only for kernel errors, not U-Boot errors ...
  6. You could start by telling what you did to achieve make it work?
  7. I have the base model, so it's only a 100Mbps link. Have you tried enabling speed 1000 in ethtool?
  8. Finally got it to work building mesa on my own on a recent BananaPi image But it would be very cool if the sun4i-drm driver was fixed in BananaPro images. Can you please take care of that, Igor? I'll help you as far as I can and will provide further information from my test machine.
  9. Also you can (as always) download the current versions directly from armbian.
  10. ..but I always mentioned that wifi only works on 4.x versions of HW and on other just eth(or usb wifi). If you would find sources for this chip, you might be able to build the needed modules for this kernel, but I simply prefer using ethernet or usb-wifi (with better connection since antenna is outside the box on other standard x96 mini )which is -if you use the usb ports already- with a 3-Port mini hub plus the usb-wifi under 7-10$/€ shipped from CN.
  11. Nobody claimed that. Such service is too expensive which is why we don't provide it yet. If you need this module faster than its our release update cycle, you are on your own. You can also ask someone to provide this update for you ... there are more ways. Certain condition has to met: - network connection - 3rd party paste/bin service availability ... bugs are always possible and it takes time before they are addressed. We will help you only under our terms and when possible. There are around 1000x too much - users are generating a lot of stress expecting even far better than paid support - of you asking (some dare to demand) for help (100% paid from our own pocket). Limit has its purpose and ofc some colateral damage ... since most of people seek for a free support its better that you wait, then us. Anyway, lots of cases are not resolved since its simply not possible. You are not restricted anymore after 7 days or if you get one like. Which you got.
  12. That's fair enough. Thank you for replying. It's understandable that the wiki hasn't been updated yet given the release was so recent. Thank you
  13. I'm working on a project using the nanopim4v2-current image. I noticed an issue with the available HDMI output resolutions. Only a select few resolutions are available, despite the connected screen advertising support for additional ones. I was also unable to output a custom resolution (for example 1920x538) by adding the proper modeline in manually through xrandr. I've been looking into this for a bit and managed to find a partial solution in Miouyouyou's recent pull request "[RFC] RK3288 : Add HDMI resolutions". Adding the patches to my build enabled support for my monitor's native resolution (1920x1200) and allowed me the ability to output custom resolutions as well. However, some custom resolutions, which work with the legacy 4.4.x kernel, still don't output properly. The restriction on the available resolutions stems from the dw_hdmi_rockchip_mode_valid function. It currently rejects any modes with a clock rate that isn't in the rockchip_mpll_cfg table (as mentioned by Kwiboo). I'm able to fix my issue by just removing the registration of the helper function with the following patch: diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c index 906891b03..8a9ccf508 100644 --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c @@ -459,7 +459,6 @@ static struct rockchip_hdmi_chip_data rk3399_chip_data = { }; static const struct dw_hdmi_plat_data rk3399_hdmi_drv_data = { - .mode_valid = dw_hdmi_rockchip_mode_valid, .mpll_cfg = rockchip_mpll_cfg, .cur_ctr = rockchip_cur_ctr, .phy_config = rockchip_phy_config, I'd like to see this functionality (setting custom resolutions) added to Armbian. Is this a patch worth submitting as a pull request? I understand that this is more of a hack than a proper solution. I saw that Kwiboo mentioned he was working on something more comprehensive. What can I do to help with this?
  14. You received a 'like', restriction should be gone now. Try armbianmonitor -U (take note the U is large), This will output the stuff directly to console/file.
  15. As regards bbr, it is not fixed after the upgrade. I would like to provide any help if I can, but ironically, when i ran the following command right after upgrade sudo armbianmonitor -u System diagnosis information will now be uploaded to Please post the URL in the forum where you've been asked for. "the URL" is disappearing and I don't even know what is going wrong... And would you like to help me with the reply restriction? 1 reply a day is so harsh that I cannot give immediate information
  16. In general it seems that the RK3399 runs best on the legacy but still maintained 4.4.x kernel. Newers are known to be either unstable or not properly supporting certain features.
  17. Hello gprovost, I´m very excited about the upcoming Helios64 and I´m following it since it was announced. I would like to know about the customs status for shipments going to EU, as well as estimated shipping time. Another very vital point is software support, for what i can tell the RK3399 doesnt seem to run all too stable on other devices so far? I´m running armbian for quite some years on different devices and I´m feeling with the developers who are more than patient with enduser critics and still doing that job more or less for free on a daily basis, on that matter is there some business agreement involved that pays the devs here for their work on that specific product? Best Regards, Vin
  18. Oh, no wonder. I saw your previous posts that said wifi was working and that caused the confusion. Is there no way to get wifi working on this model then?
  19. Thank you very much mate, it did the trick!
  20. Armbian_20.05.2_Orangepizero_focal_current_5.4.43.img.xz works without any problem. Thank you ___ ____ _ _____ / _ \| _ \(_) |__ /___ _ __ ___ | | | | |_) | | / // _ \ '__/ _ \ | |_| | __/| | / /| __/ | | (_) | \___/|_| |_| /____\___|_| \___/ Welcome to Armbian Focal with Linux 5.4.43-sunxi System load: 1.03 1.49 0.70 Up time: 4 min Memory usage: 30 % of 239MB Zram usage: 19 % of 119Mb IP: CPU temp: 56°C Usage of /: 13% of 7.3G [ General system configuration (beta): armbian-config ] Last login: Fri Jun 5 07:17:01 2020 from
  21. mboehmer

    Odroid C4

    Hi Igor, eMMC reboot was 20x so far with no lockup. It seems a uSD card problem - I have not managed to get a "reboot" with uSD card done properly. I use a SanDisk Extreme 16GB Class 3 HC I card. The power supply should be sufficient (12V 2A). With uSD card, the following errors occur when I log in after booting and do a "reboot" as root: root@odroidc4:~# reboot [ 59.522866] reboot: Restarting system bl31 reboot reason: 0xd bl31 reboot reason: 0x0 system cmd 1. SM1:BL:511f6b:81ca2f;FEAT:A0F83180:20282000;POC:F;RCY:0;EMMC:800;NAND:81;SD?:0;SD:0;READ:0;0.0;CHK:0; bl2_stage_init 0x01 bl2_stage_init 0x81 hw id:øSM1:BL:511f6b:81ca2f;FEAT:A0F83180:20282000;POC:F;RCY:0;EMMC:800;NAND:81;SD?:0;SD:400;USB:8;LOOP:1;EMMC:800;NAND:81;SD?:0;SD:400;USB:8; After that, the system is stuck and needs a power cycle (didn't find a reset yet). The same image on an eMMC card does the following on a "reboot": root@odroidc4:~# reboot [ 50.423833] reboot: Restarting system bl31 reboot reason: 0xd bl31 reboot reason: 0x0 system cmd 1. SM1:BL:511f6b:81ca2f;FEAT:A0F83180:20282000;POC:F;RCY:0;EMMC:0;READ:0;0.0;CHK:0; bl2_stage_init 0x01 bl2_stage_init 0x81 hw id: 0x0000 - pwm id 0x01 bl2_stage_init 0xc1 bl2_stage_init 0x02 L0:00000000 L1:00000703 L2:00008067 L3:15000020 S1:00000000 B2:20282000 B1:a0f83180 TE: 67922 BL2 Built : 20:29:41, Jun 18 2019. g12a ga659aac - luan.yuan@droid15-sz Board ID = 1 Set cpu clk to 24M Set clk81 to 24M Use GP1_pll as DSU clk. DSU clk: 1200 Mhz CPU clk: 1200 MHz Set clk81 to 166.6M eMMC boot @ 0 sw8 s So there are differences in the output, I have no clue yet where this output comes from. Hope this helps.
  22. Igor

    Odroid C4

    Can you perhaps repeat this like 10 times? I hope to get some input from others.
  23. Hello I tried this working for uart2. Works perfectly(I worked on Orange Pi zero and Olinuxino-A64 board). When I tried same working for uart4 for Olinuxino-A64 board but I did't achieve. I opened uart4 from dts file: diff -ruN uboot-2020.04_original/arch/arm/dts/sun50i-a64-olinuxino.dts uboot-2020.04_uart4/arch/arm/dts/sun50i-a64-olinuxino.dts --- uboot-2020.04_original/arch/arm/dts/sun50i-a64-olinuxino.dts 2020-06-05 08:59:24.341767776 +0300 +++ uboot-2020.04_uart4/arch/arm/dts/sun50i-a64-olinuxino.dts 2020-06-05 09:07:52.377518517 +0300 @@ -53,10 +53,11 @@ aliases { ethernet0 = &emac; serial0 = &uart0; + serial4 = &uart4; }; chosen { - stdout-path = "serial0:115200n8"; + stdout-path = "serial4:115200n8"; }; hdmi-connector { @@ -305,6 +306,12 @@ status = "okay"; }; +&uart4 { + pinctrl-names = "default"; + pinctrl-0 = <&uart4_pins>; + status = "okay"; +}; + &usb_otg { dr_mode = "otg"; status = "okay"; I added uart4 pins(PD2->Tx and PD3-> Rx) and set pinmux(Function 3 is uart mode for this pins in A64-datasheet). I set CONS_INDEX. diff -ruN uboot-2020.04_original/arch/arm/include/asm/arch-sunxi/gpio.h uboot-2020.04_uart4/arch/arm/include/asm/arch-sunxi/gpio.h --- uboot-2020.04_original/arch/arm/include/asm/arch-sunxi/gpio.h 2020-06-05 08:59:24.365768023 +0300 +++ uboot-2020.04_uart4/arch/arm/include/asm/arch-sunxi/gpio.h 2020-06-05 09:07:52.545511506 +0300 @@ -165,6 +165,7 @@ #define SUN8I_A83T_GPB_UART0 2 #define SUN8I_V3S_GPB_UART0 3 #define SUN50I_GPB_UART0 4 +#define SUN50I_GPD_UART4 3 #define SUNXI_GPC_NAND 2 #define SUNXI_GPC_SPI0 3 diff -ruN uboot-2020.04_original/arch/arm/mach-sunxi/board.c uboot-2020.04_uart4/arch/arm/mach-sunxi/board.c --- uboot-2020.04_original/arch/arm/mach-sunxi/board.c 2020-06-05 08:59:24.389768269 +0300 +++ uboot-2020.04_uart4/arch/arm/mach-sunxi/board.c 2020-06-05 09:07:52.733503660 +0300 @@ -133,10 +133,10 @@ sunxi_gpio_set_cfgpin(SUNXI_GPB(0), SUN8I_GPB_UART2); sunxi_gpio_set_cfgpin(SUNXI_GPB(1), SUN8I_GPB_UART2); sunxi_gpio_set_pull(SUNXI_GPB(1), SUNXI_GPIO_PULL_UP); -#elif CONFIG_CONS_INDEX == 5 && defined(CONFIG_MACH_SUN8I) - sunxi_gpio_set_cfgpin(SUNXI_GPL(2), SUN8I_GPL_R_UART); - sunxi_gpio_set_cfgpin(SUNXI_GPL(3), SUN8I_GPL_R_UART); - sunxi_gpio_set_pull(SUNXI_GPL(3), SUNXI_GPIO_PULL_UP); +#elif CONFIG_CONS_INDEX == 5 && defined(CONFIG_MACH_SUN50I) + sunxi_gpio_set_cfgpin(SUNXI_GPD(2), SUN50I_GPD_UART4); + sunxi_gpio_set_cfgpin(SUNXI_GPD(3), SUN50I_GPD_UART4); + sunxi_gpio_set_pull(SUNXI_GPD(3), SUNXI_GPIO_PULL_UP); #else #error Unsupported console port number. Please fix pin mux settings in board.c #endif diff -ruN uboot-2020.04_original/configs/a64-olinuxino_defconfig uboot-2020.04_uart4/configs/a64-olinuxino_defconfig --- uboot-2020.04_original/configs/a64-olinuxino_defconfig 2020-06-05 08:59:24.545769870 +0300 +++ uboot-2020.04_uart4/configs/a64-olinuxino_defconfig 2020-06-05 09:07:53.789459652 +0300 @@ -9,3 +9,4 @@ CONFIG_SUN8I_EMAC=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_OHCI_HCD=y +CONFIG_CONS_INDEX=5 \ No newline at end of file Finally configure uart4 base address for CONS_INDEX diff -ruN uboot-2020.04_original/include/configs/sunxi-common.h uboot-2020.04_uart4/include/configs/sunxi-common.h --- uboot-2020.04_original/include/configs/sunxi-common.h 2020-06-05 08:59:24.661771061 +0300 +++ uboot-2020.04_uart4/include/configs/sunxi-common.h 2020-06-05 09:07:55.001409242 +0300 @@ -246,8 +246,8 @@ #define OF_STDOUT_PATH "/soc@01c00000/serial@01c28400:115200" #elif CONFIG_CONS_INDEX == 3 && defined(CONFIG_MACH_SUN8I) #define OF_STDOUT_PATH "/soc@01c00000/serial@01c28800:115200" -#elif CONFIG_CONS_INDEX == 5 && defined(CONFIG_MACH_SUN8I) -#define OF_STDOUT_PATH "/soc@01c00000/serial@01f02800:115200" +#elif CONFIG_CONS_INDEX == 5 && defined(CONFIG_MACH_SUN50I) +#define OF_STDOUT_PATH "/soc@01c00000/serial@01c29000:115200" #else #error Unsupported console port nr. Please fix stdout-path in sunxi-common.h. #endif And I set console ttys4 but I could not take any data from uart4. Is there a way to do this for uart4? What points might I be missing? Thanks for helping.
  24. AFAIK its purposely disabled on dev builds.
  25. I have a X96Air P3 4/64MB with 1GB ethernet. I can confirm Wifi, Bluetooth and HDMI audio are not working with Armbian and the Ethernet speed is only 100Mb. For me, it is not a question of uptime but question of ALL things working with Armbian.
  26. Werner

    remove desktop

    You are also slightly outdated. The release model has been changed last year.
  27. Spam encounter measure. The limit should be gone now for you.
  1. Load more activity