Jump to content

jock

Members
  • Posts

    2066
  • Joined

  • Last visited

Everything posted by jock

  1. @remlei ok this is better, but you still miss the important information: * what packages apt upgraded when you got the system broken? * what is the kernel version that broke the ethernet? I compiled a fresh image with latest kernel version at that time (5.15.74) and nothing happened on a MXQPRO_V73 board
  2. @Max Sterg It's happening that the partition will be enlarged the first time you run the system. You should read a bit of the armbian documentation to grasp the basics, it has been written for a purpose: https://docs.armbian.com/
  3. @remlei As expected, I download the latest 5.15.74 community image and there are no problems with ethernet at all 😑
  4. 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!
  5. 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?
  6. @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.
  7. @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.
  8. 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?
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. @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.
  14. 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
  15. 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
  16. Finally! On my personal testing on 5.19.x never had any issue with both armhf and arm64 architectures
  17. @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
  18. @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
  19. 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.
  20. Modify the img.xz to do what? It will be overwritten as well with apt upgrade anyway
  21. @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
  22. 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.
  23. 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.
  24. 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.
  25. 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.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines