jock

@remlei As expected, I download the latest 5.15.74 community image and there are no problems with ethernet at all 😑

Do you know if it is sufficient to install packaged falkon, qt and gstream packages on Ubuntu Jammy/Debian bullseye to get thing working or there is the need to compile something by hand? I ask because it would be nice to have some out-of-the-box solution to say that the path is traced and things are getting squared. Thanks!

Mmmh, that's rather strange, probably is not something related to the board itself but to the monitor, because I have exactly that board and it works fine on my full-hd monitor even on 5.19 without LE patches. However the LE patches introduce several fixes to timings and HDMI subsystem that it is very expected that compatibility is better all-around. What kind of monitor do you have?

@Max Sterg Yes the github repository is the best place to grab community images. Feel free to write questions here on the forum, even though this specific thread is specialized for rk322x support in armbian, so it is related mostly to hardware support and peripherals. edit: ah, don't expect great performance for the rk322x within graphical environment, it is a very limited device that is more suitable for server-like and command line tasks.

@Max Sterg Ok, no problems! From the previous post you let us think you were a total newbie, but yet you have some experience. However, if you want a desktop image, you have to go with an xfce image. Read carefully the first post for the instructions, also don't take the images from that directory you did the screenshot above, but follow the link to the community images built by armbian server. I suggest to use a mainline kernel (either "current" 5.15 or "edge" 5.19) with xfce if you want to experience a desktop environment. The difference is that "current" kernel is more stable, "edge" kernels are development ones and may potentially break, even though I don't usually push anything that deliberately breaks things even for edge kernels.

You should at least describe the issue before alarming people this way, and moreover you should post logs to let people understand if there is an issue with the image. I don't see logs and I don't see the filename of the image object of the problem, just a dubious procedure based upon a dubious hypothesis. And I say it is a dubious hypothesis because what you are stating can be only an issue related to the kernel (or possibly device trees), just because u-boot and related code has been frozen months ago. Everything is possible, and I will check soon, to me it looks very difficult that a newer minor release of the kernel could corrupt some ROM data about the ethernet that, even after reverting to a previous working image, you don't solve the problem. Maybe you have a broken cable or a broken router?

GPU is only doing 3D graphics. Media applications are accelerated by VPU, which is a totally different part of the chip. I think gstreamer is already quite capable of using the v4l2 interface to profit of media acceleration drivers already in mainline kernel (namely hantro and rkvdec for rk3318, both accelerating h.264, vp8, vp9 and hevc, but some codecs still have partial support on rockchip64 armbian branch). Ffmpeg needs to be built with patches and in a custom way because kernel interface for codecs has been made "stable" very recently (I guess in kernel 5.19). Also mpv has the capability to use hardware video decoding via v4l2, but still need a custom build because it uses in turn ffmpeg. There is this old thread where I provided a custom build binary of mpv, but it was for ubuntu hirsute and debian bullseye; surely it would require some adaptations and tinker if you want to run on newer distros. Accelarerating youtube in a browser is a whole different story. I don't know what is the current status (maybe @usual user has some clues?), but surely it is much more challenging than standalone video playing.

Out of the box: it means that is already installed and working and you have nothing to do except run you OpenGL/OpenGL ES application to profit.

Hardware GPU acceleration is working out of the box on mainline kernel images at least from two years via Lima driver. Nothing particular is required to set it to work, it just works out of the box.

This is not very helpful message. How much time you did wait to say it was blocked? Did you change the power adapter with something more suitable? Assuming you were trying to install armbian in the internal eMMC flash, it is very possible that the eMMC is broken. Also, what is your board? Do you have logs? Please read the instructions on first post, there is a paragraph with all the informations on how to contribute, they are very helpful to debug.

@Seth Thanks a lot for testing, it is very useful! That's not a bug, that's just a message that u-boot is trying to change the voltage for a device that is not there. It happens, for example, when you have installed it on eMMC and there is nothing in the sdcard slot: u-boot tries to change the voltage of the sdcard but since there is no sdcard it reports an error. The other error messages about audio things appeared in kernel 5.15 onwards and honestly I don't know what is wrong. All rockchip SOCs (from rk322x up to rk3399) show them, but functionality is not broken in any way.

Okay I made kernel deb packages 5.19 with libreelec patches to test an upgrade on a live system, as usual can be installed with dpkg -i Kernel 5.19.15 image kernel 5.19.15 dtb And also a ready-made debian bullseye testing image

This HDMI problem is a shame 😒, it works fine on a rk3318 and a rk3328 tv boxes I have here and can't replicate the problem, as it is even more frustrating because it is a regression from 5.15 Normally it is the HDMI driver that communicates with the HDMI monitor/TV via I2C, when there is no dedicated i2c bus on the board, the HDMI driver spawns a limited but function i2c bus to retrieve the data from the monitor (namely, the EDID info about resolutions and timing). It could be interesting tu use i2cdetect -l to see if the HDMI I2C bus is present or not, but I guess the issue is more related to HDMI timings or so. If you wish, I can provide a special 5.19 kernel package with the some patches from LibreELEC to see if the HDMI works again

Finally! On my personal testing on 5.19.x never had any issue with both armhf and arm64 architectures

@Seth Very much thank you for the photos! I looked at them side by side trying to spot differences, and the board layout and printings seems exactly the same to me. The squared has a 2146 printed below the heatsink, the rounded has 2147; I may guess it is a something like lot number; the date "2020/06/29" maybe is the date when the board was designed. @FRIKIdelTO has the 2151 lot number but the same 2020/06/29 date on his board. The differences are, as you already noticed, in some pads being populated with components or just unpopulated. I may guess the fx8934 comes with an on-board crystal which is below the metal shield, instead the sp2734c requires an external crystal and the inductor too. I checked the nvram files, and both the default shipped with armbian and the alternative version for the 2734c have the crystal set to 37.4MHz. My HK1 board comes with an HK6334Q, has the external 37.4MHz crystal but works with the default firmware like the fx8934 that has no external crystal. Very messy 😄 About the HDMI, on kernel 5.19 it does not work on both of them or just on the "squared" one? I cleaned, sorted and finally made a diff of the two nvram fiels I attach here for curiosity and study purposes. You can see there are several calibration parameters that differs a bit, but there are also some obscure parameters like swctlmap that probably control some chip registers to behave in a way or another. Use zless -R to see it correctly with colors. diff-def-alt-nvram.txt.gz

@Max Sterg No disturb, but please read the first post that will answer all your questions. PS: the specs of your box are totally fake, you don't have 8GB + 128GB eMMC, you probably have 1GB of RAM and 8GB of eMMC

I understand; the problem is that those boards have some minor changes that makes them different than established boards. Maybe it is just a matter of tuning some little bits to get things perfectly working... I never stress enough that if you need something more serious, proper SBCs are the way, tv boxes are just for toying around and for those people that know perfectly how to work around in case they suddenly break because of the faulty components often they mount.

Modify the img.xz to do what? It will be overwritten as well with apt upgrade anyway

@SethI was inspecting an old dtb I have in my archive of a h96 max that someone posted time ago. Actually I don't know if it comes from the "rounded one" or the "squared one". I see that the one posted by @FRIKIdelTO has the RK3318_V1.4 marking and, searching through this thread, I see that also @kruzer had a h96max but on his photos the board marking is behind the heatsink. Anyway my guess is that SP6334, HY2734C, etc... are all clones of the AmPAK AP6334 which is, in turn, a combo of wifi and bluetooth chipsets from broadcom (BCM4334 for the wifi part, don't remember the name of the bluetooth chip). The driver is the very same broadcom driver that works fine for all the chips and the firmware is the very same. The only that changes is the "nvram" file, which is nothing more than the configuration settings of the firmware. Often, when you see the wireless network but can't associate with them, the problem is the crystal frequency that gives the clock to the wifi chip: the board mounts a crystal and the nvram says there is another one. @Seth do you have any photos of the boards? Or at least could you tell if both boards have RK3318_V1.x marking on them or are they quite different? It could just be that they are two different board from different manufacturers that have different internal designs. Also HDMI does work for you? As far as I understand, HDMI works for @FRIKIdelTO on this RK3318_V1.4

AFAIK you don't need a specific driver for sata to usb bridges; they will just work as a generic USB mass storage device. You may need some special applications (like smartmontools) to know the bridge chip to send sata commands directly to the drive, but that's not something related to OS.

Well, apart from making it read-only, honestly I don't know. It is part of the armbian firmware package and will get overwritten every time the package is updated. The reason I did not ship the alternative nvram for bcm4334 (your wifi chip is a broadcom bcm4334, 2734c is just a random name no one knows where it comes from) is that there is no easy way to switch from the "default" nvram to the "alternative" nvram.

Yes: follow instructions on first post, in particular always test image on sdcard first! You did a bad mix: with this command you installed part of the proprietary bootloader/u-boot (which is in use on multitool but not on armbian) over the armbian installation, which does not use anything from the proprietary code. multitool should still boot fine, if it booted before it should boot as well after the mistake, I don't know why you get a black screen, but you may try to access it via ssh if you don't see anything on screen.

Hello @rafaeldavid, thanks a lot, you're very kind! About the r29 board, yes as you noticed there are issues with that board. The HDMI problem is very well known and it is quite obscure, maybe some gpio has to be set to the right state but I wasn't able to find useful hints inspecting the device tree. The stability issues are very new to me, but looking at the board photos I see a bit of different design for the power section than usual boards. These differences may have some stability implications, but I'm just guessing. Another potential problem can be related with the Trust OS binary: during early development we noticed that the wront Trust binary could freeze the device after a predefined amount of time because it was triggering a sort of "sleep" mode, but the Trust (proprietary) binary now is working pretty fine for the vast majority of boards, so it would be quite strange that this is the offender. As you read in the other posts, this R29 board seems to be one of the bad ones and unfortunately I have no sample to study, so I'm very open to receive one sample. Recently I received a couple of rk322x boards from @Jason Duhamell and those were terribly useful to fix eMCP issues and support esp8089 wifi; having such R29 board on my desk to work with obviosuly increases a lot the chances to understand and fix those issues. edit: in the past we have encountered R29_MXQ boards, those may be a bit different than yours but the HDMI problem looks like is the same. You may try to apply led-conf7 from rk322x-config to see if stability problems goes away, but I'm afraid it won't really chance anything.

This is the download page for Tinkerboard / Tinkerboars-S: https://www.armbian.com/tinkerboard/ Well, there is still confusion in your steps: If you want to write a full image (step 7) to the eMMC, you don't need step 5 and step 6. If you want to erase the flash and let the device always boot from sdcard, you step 5 is not needed Also when you do step 6, the device is not automatically in maskrom mode... it will enter maskrom mode when you turn it off and turn it on again! Remember that you are in real maskrom mode when you first need to run rkdeveloptool db command. This is not exactly "activation" of the bootloader. ul means upgrade loader: it will write the bootloader on the eMMC in the famous first 0x2000 sectors. Although it is very harmless to run the command after db command, you don't really need ul if you're going to erase the internal flash right after with ef command. You also don't need to do ul if you're going to burn a full image, either taken from multitool backup or a pristine armbian image. I'm sorry about the confusion, but it is so because the instructions on the linked page assumed that you are going to do a manual backup in rockusb mode (that will skip the first 0x2000 sectors), and then restore in maskrom mode. Multitool came much later than those instructions, I left them there for reference. Multitool is the preferred way to do backup and restore because has no limitations and indeed is much easier to use.

Extensions have no meaning in the Unix world, you can even rename that file with a ".exe" extension but it does not change anything. What counts is the data in the file. The procedure requires that you first erase the eMMC with rkdeveloptool ef command; when done turn the box off, then turn the box on and you will be in MaskROM mode . Once there, follow the steps from "Restore backup" paragraph in the link above: you have to first use rkdeveloptool db command to upload a program to the SoC to program (no pun intended) the eMMC you can skip the rkdeveloptool ul command (it was necessary for manual backups, not for multitool backups) run the rkdeveloptool wl command Maybe the serial is switched to 1.5Mbps; some firmwares use 115200, some others use 1.5Mbps and may show you garbled data. On multitool and armbian by default I use 115200bps for compatibility. Yes, both of these behaviours are expected. The OTG port works as a power supply since it is supposed to be bidirectional. In fact when you do maintenance in maskrom mode you have not to connect the regular power supply but just the USB cable. Not all boards work this way though, but it looks like that both mine and yours behave this way. rkdeveloptool does not let you do anything with the box in MaskROM mode because you first have to upload the famous program with rkdeveloptool db I talked above. Once you do that, then you can use the other rkdeveloptool commands (including ef, wl, etc...) A lot of confusion comes from a fact: rockchip u-boot bootloader that is shipped with original firmwares, when stuck or when the reset button is pressed, provides the RockUSB mode, which is similar to MaskROM, but it is not the same! Unfortunately lsusb has no chances to recognize the difference and will tell you the board is in MaskROM mode, but it is not true. When you are in RockUSB mode, rkdeveloptool works without the bootstrap program because on the other side there is u-boot that is already answering. Another very very important difference between MaskROM and RockUSB modes is that the latter does not allow you to write the whole firmware: it will skip the first 0x2000 sectors, not allowing to overwrite the bootloader part, plus it will shift by the same amount the image you're going to write on the internal flash. Clearly this breaks everything, because partitions will not be in the expected positions anymore. To make the long story short: always operate on the internal flash when you're in real MaskROM mode. To get into real MaskROM mode you have to: erase the internal flash, or gate the clock pin with the screwdriver/whatever trick This is because the SoC on first instance tries to boot from eMMC. If it does not find a valid bootloader, then tries to boot from sdcard. If a valid bootloader is not there too, then stays there waiting in MaskROM mode waiting for an input from USB OTG port. No firmware/software has been loaded at this point, and that's the reason why you must upload the bootstrap program with rkdeveloptool db command before you can do anything else. Yes, this is the problem I talked you about the differences on the boards: the kernel is stuck somewhere because the device tree tells about a hardware configuration but your board has a different hardware configuration. If you burn the image on a sdcard, you can edit the file /boot/armbianEnv.txt and change verbosity=1 to verbosity=7 to let the kernel to show the whole log on the serial. This is of great help when you're debugging. You may also try armbian images for the Asus Tinkerboard-S, which has the rk3288 SoC as well and share many similarities. edit: you didn't say if you tried to just restore the backup with the multitool. Did you try? That's the easiest way to restore the backup...