fraz0815

@fraz0815 - thanks, i read this news on https://linuxgizmos.com/   

this helped me:
 
sudo add-apt-repository ppa:pipewire-debian/pipewire-upstream
sudo apt install pipewire pipewire-audio-client-libraries gstreamer1.0-pipewire libpipewire-0.3-{0,dev,modules} libspa-0.2-{bluetooth,dev,jack,modules} pipewire{,-{audio-client-libraries,pulse,media-session,bin,locales,tests}} -y
systemctl --user daemon-reload
systemctl --user --now disable pulseaudio.service pulseaudio.socket
systemctl --user --now enable pipewire pipewire-pulse
pactl info
reboot

Ver 20230609-edge (use u-boot) kernel 6.4-rc5 (no HDMI)
20230609-EDK2-EFI-edge kernel 6.4-rc5 - HDMI work only EDK2 (grub), HDMI in system not work
 
 
root@192.168.1.15's password: ____ _ ____ ____ | _ \ ___ ___| | __ | ___|| __ ) | |_) / _ \ / __| |/ / |___ \| _ \ | _ < (_) | (__| < ___) | |_) | |_| \_\___/ \___|_|\_\ |____/|____/ Welcome to Armbian 23.04 Lunar with bleeding edge Linux 6.4.0-rc5-media No end-user support: built from trunk System load: 7% Up time: 4 min Memory usage: 1% of 15.21G IP: 192.168.1.15 Usage of /: 26% of 7.0G RX today: 5.4 KiB [ 29 security updates available, 34 updates total: apt upgrade ] Last check: 2023-06-09 06:57 Last login: Fri Jun 9 11:08:36 2023 root@rock-5b:~# neofetch root@rock-5b ------------ █ █ █ █ █ █ █ █ █ █ █ OS: Armbian (23.04) aarch64 ███████████████████████ Host: ROCK 5 Model B 0 ▄▄██ ██▄▄ Kernel: 6.4.0-rc5-media ▄▄██ ███████████ ██▄▄ Uptime: 5 mins ▄▄██ ██ ██ ██▄▄ Packages: 559 (dpkg) ▄▄██ ██ ██ ██▄▄ Shell: bash 5.2.15 ▄▄██ ██ ██ ██▄▄ Terminal: /dev/pts/0 ▄▄██ █████████████ ██▄▄ CPU: (8) ▄▄██ ██ ██ ██▄▄ Memory: 222MiB / 15572MiB ▄▄██ ██ ██ ██▄▄ ▄▄██ ██ ██ ██▄▄ ▄▄██ ██▄▄ ███████████████████████ █ █ █ █ █ █ █ █ █ █ █ root@rock-5b:~# root@rock-5b:~# free -m total used free shared buff/cache available Mem: 15572 357 15113 9 251 15214 Swap: 7786 0 7786 root@rock-5b:~# lspci 0004:40:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3588 (rev 01) 0004:41:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 04) root@rock-5b:~#  

Rock Pi-4B - Armbian_23.05.1_Rockpi-4b_jammy_current_6.1.30_gnome_desktop.img
installed to emmc: logs 
wlan, hdmi, nvme working
 
Rock-5B - Armbian_23.05.1_Rock-5b_jammy_legacy_5.10.160_gnome_desktop.img
Took me a while to boot from SD, was using an older 23.05-trunk version.
Even 'sudo dd if=zero.img of=/dev/mtdblock0' with radxa zero.img would continue to boot happily from nvme instead of sd, changed armbianEnv.txt to sd root, updated bootloaderon mtd -> worked.
besides mtd being a mystical thing for me, almost anything worked:
installed to mtd+nvme: logs
using btrfs on nvme + mtd did not work (don't know if supported, but installer lets you pick it).
performance with panfrost ppa's enabled is absolutely stunning. 

Btw, this time for testing I used my 45W PD PSU (+ PD C<->C Cable 60W) instead of fixed 5V@4A w/o errors and activated the max 12V PD option in armbian-config just for fun.
Sensors report ed
in0: 12.00 V (min = +12.00 V, max = +12.00 V) curr1: 1.50 A (max = +1.50 A) and had no reboots or whatsoever.

ver 20230420 mesa 23.2.0-devel for pancsf fot kernel 6.2
 
https://disk.yandex.ru/d/FUqgx3Zz9ZSckw

There is a mirror, where images are updated to the latest version (In a few hours there will be a new version).
https://users.armbian.com/balbes150/
 
I don't use archlinux. As far as I know (I may be mistaken) - this version is assembled from parts of Armbian with the addition of ready-made binary files and settings from other systems, i.e. it is essentially an analogue of twisteros (a prefabricated binary hodgepodge) based on archlinux.
 
u-boot radxa is useless junk with a bunch of errors and hidden problems for users (with any failure to start with NVMe, you will get a problem, you cannot start any system with SD\USB until you physically disable NVMe and other problems).
 
armbian-config is an order of magnitude better and more convenient, it also allows you to easily install\update u-boot in MTD\SPI and simultaneously install the system on NVMe or other media (eMMC\USB).
 
For a long time there have been versions of Armbian with support for different EFI\grub variants (EDK2-EFI and u-boot-efi), see details and links to such images in this topic. So far, OS selection management is available only via UART.
 
Using ARM-blob and additional system performance settings, I get almost 3800 on Rock 5b, on other rk3588s models I get more than 4400 and I have a suspicion that slower memory is used on models with 16GB of RAM, but no one wanted to share the results from rock5b with 8 GB of RAM, with with this system, to determine exactly how reliable it is.
 
Using extlinux.conf or efi\grub (with the correct parameters).

I explained to you what the problem is and I absolutely don't care what you will use.
 
 

No, initially there was an attempt to use the normal version (extlinux.conf) for rock 5b, but under the pressure of retrogrades, there was a rollback to this old stuff.
 
Odroid is the stupidest choice and obsession with all sorts of old shit (boot.ini, piteboot).
 
rk35xx (rk356x rk3588) - should initially focus on normal, new versions of startup systems (EFI\Grub). For rk356x - EDK2 has been available for a long time with a choice of system\kernel on the screen (for the headless option, this also works fine). For rk3588 - test versions are already available and in the coming weeks \ month there will be a working version with monitor support.
 
With whom and what to discuss if retrogrades don't even understand how extlinux or efi\grub works and squeal at every corner that these are "very bad decisions"? 
At the same time, they do not understand elementary things - that switching at least to extlinux gives a huge step forward and allows you to atomize the installation of several cores at the same time (it is not necessary to make a choice of the core on the screen, it is important to keep the ability to easily roll back to the primary core if the new one has problems). Try using boot.scr to implement two\three\N cores installed in the system at the same time. When using boot.scr - updating the system\kernel, this is a lottery, with a high probability of getting a serious problem (strictly there is no kernel anymore. and the new one is not working).

Current only working software for this HW is very old stuff anyway 
 
 
Vendors objectives are different than ours. They want to sell hardware and they want to have control over software. By doing on their own, they control it and they don't help their competitors. It this aspect it makes sense. 

But yes, I totally agree. 
 
 
Research has been done on the topic, we know many pros and cons and I think we do agree to some point.
https://forum.armbian.com/topic/20847-the-boot-process-and-various-devices/
A good topic to discuss it next week - how to proceed from current stage? @ManoftheSea Too early?
 
 
If preparation and transition is not done well, we also have a lottery. It is nice that you experiment with all this, I know others also did some. We found some issues and we need to make some decisions ... 

Of course it's far from perfect, but can be used. I remember the start of rk3399 boards, that was pretty bad in comparison to today.
ARM64 and panfrost really made some serious progress.
 
JFYI, wayland progress on gnome was always more advanced than KDE's (and only choice if you wanted working wayland DE besides sway etc)

Installed with armbian-install to SPI+NVME and works perfectly. Thanks!

See the first message of the topic, I changed it and there is a link to the shared directory with all the images.

New version 20221210.
I checked the installation of the new version of u-boot on SPI. Everything works correctly. The new version works correctly with the system startup order.
If you install the system on NVMe and connect the SD card with another system, the SD card will start. For example, you can install an Ubuntu system on NVMe and run Debian from an SD card. Also, the new u-boot supports the system startup mode with EFI\grub.

Those are developers preview builds, where you can check what works and at some point it will be good enough for some uses cases. In a couple of years, it will be functional on the level of kernel 5.10.y. 
 
Download is possible from CI pipeline: https://github.com/armbian/build/releases
 

 
Boot log:
 
This board is looking for maintainer(s) and (this) forum moderator (contact @Werner).

Try version 20220926, it has patch fixes added, but I haven't checked their work (I don't have a working T4 anymore)

@fraz0815 
Could you try to revert those kernel commits :
06653ebc0ad2e0b7d799cd71a5c2933ed2fb7a66
and probably also aea6cb99703e17019e025aa71643b4d3e0a24413 (both commits are related).
 
  see
 
 
Those commits are proper fixes but trigger the emmc hs400 breakage on helios64 rockchip 3399 .

This has been possible for a long time (available in all versions of Armbian that switched to using extlinux.conf), but requires manual editing of extlinux.conf (changing the parameter that is responsible for loading by default it is enough to change one line).
Please note, extlinux.conf is a standard settings file that is well documented in u-boot. In fact, it is very close to the logic of using grub.cfg

I checked this information, yes there is a problem on T4. A PR with the proposed correction will be sent in the near future.
 
As a temporary solution for already downloaded 5.16 kernel images, you can replace DTB with a new one.
 
 
rk3399-nanopc-t4.dtb

The test version of ArmbianTV 20220324 with a new version of u-boot-2022. Allows you to select different systems when starting on the TV screen from the keyboard. This will allow you to have several different systems on eMMC at once and choose which system to run. Please note, this is a test version and there may be errors in it. I recommend checking its operation by launching it from an SD card.

Fixed in sources
https://github.com/armbian/build/pull/2190

hey,
after updating my nanopct4 and rockpi-4b to from 20.05 to 20.08 RDP stopped working for me, only black screen.
After reading all the messy logs, fresh install etc, I found a simple working solution online:
 
In /etc/xrdp/startwm.sh change 
#!/bin/sh  to 
#!/bin/bash  
Sources:
https://github.com/neutrinolabs/xrdp/issues/1630
https://askubuntu.com/questions/1166568/remote-desktop-blue-screen-after-login
 
Maybe others are affected too, don't know about Ubuntu.

hey,
after updating my nanopct4 and rockpi-4b to from 20.05 to 20.08 RDP stopped working for me, only black screen.
After reading all the messy logs, fresh install etc, I found a simple working solution online:
 
In /etc/xrdp/startwm.sh change 
#!/bin/sh  to 
#!/bin/bash  
Sources:
https://github.com/neutrinolabs/xrdp/issues/1630
https://askubuntu.com/questions/1166568/remote-desktop-blue-screen-after-login
 
Maybe others are affected too, don't know about Ubuntu.

hey,
after updating my nanopct4 and rockpi-4b to from 20.05 to 20.08 RDP stopped working for me, only black screen.
After reading all the messy logs, fresh install etc, I found a simple working solution online:
 
In /etc/xrdp/startwm.sh change 
#!/bin/sh  to 
#!/bin/bash  
Sources:
https://github.com/neutrinolabs/xrdp/issues/1630
https://askubuntu.com/questions/1166568/remote-desktop-blue-screen-after-login
 
Maybe others are affected too, don't know about Ubuntu.