• Content Count

  • Joined

  • Last visited

About jock

  • Rank
    Elite member

Recent Profile Visitors

986 profile views
  1. They are still "kinda open": the BLOB firmware is still there, and the GPU is still in control of everything
  2. With the log you provided it's not easy to understand why your u-boot instance is not booting your kernel. Maybe you can compile u-boot turning on the debug flag, so it will be much more verbose and could be much more helpful.
  3. Technically speaking, the only important part (for you particular setup) of the sd-card is u-boot, which is located starting at sector 64 up to 2048: it is the first megabyte of the sdcard or so. In theory you can just copy the content of those sectors on another sdcard at the same place and it will just boot fine from the USB drive. Such a command would be enough (of course use the proper source and destination devices): # dd if=/dev/mmcblk0 of=/dev/mmcblk1 bs=512 skip=64 seek=64 count=1984 You could do exactly the same using the eMMC device as destination and you would not need the sdcard at all Yes, no problem compiling the kernel directly on the box. I did some time ago, of course the box compiled fine. About multiboot, nothing is stopping to put some kind of boot manager after u-boot. I don't know ant boot manager of sort suitable for ARM machines, but I guess there should be some out there, and indeed there are no technical issues preventing doing such piece of software. U-boot indeed should stay there because it does the initialization of some devices since these boxes lacks a real BIOS/embedded firmware. Just plug the drive using the adapter and it should work. The OTG port is even faster than the non-OTG ports because it is directly connected to the SoC. Well I don't think it is a real issue... gcc -v shows you the compilation flags of gcc. Probably all the packages are compiled with the same architecture and tuning options, which is sub-optimal, but I don't think the gain in performance would be great using arm-cortex-a17... The microarchitecture is the same (ARMv7) so the instructions set is the same, you may think that the difference between arm-cortex-a7 and arm-cortex-a17 is around arranging the code in a different way to let the cache, branch predictors, pipelines and so on work a bit better. I don't think you should worry so much about, but if you have spare time you may try compile and do some benchmark to see if it worth it. PS: to show the gcc default compilation flags: gcc -Q --help=target
  4. Got it. I'm trying the box with an HDD attached to the OTG USB port. too It works wonderfully and it is a perfect desktop replacement to me :) Are you using the sdcard too? In my setup I have an image installed on the eMMC and, by default, it boots from the USB HDD when it is attached, so no need for the sdcard at all.
  5. I'll remove the eMMC friendly link. You can use a stable image form the Armbian download page (or, if you feel adventourous, the latest nightly development image above)
  6. It looks like video acceleration is almost there in mainline. I think that in a matter of at most a couple of months rockchip will have some functioning hardware accelerated video decoding for at least h.264. Audio playback is fine at the moment, solving the purple line issue apparently solved the last audio issue I'm aware of. I suggested a patch that is going to be mainlined to armbian to finally have the proper labels to pulseaudio devices HDMI and SPDIF devices (it's just a matter of exchanging /etc/asound.conf with the one proposed in this issue, if you don't want to wait) and maybe it allows also some kind of AC3/DTS passthrough (not sure, have no chance to test it)
  7. Is it my fault or the thermal trip points and cooling steps disappeared in Linux 5.1 on (at least) RK3288 devices? The "C/St." field from armbianmonitor -m disappeared: root@xt:/home/paolo# uname -a Linux xt 5.1.7-rockchip #5.88 SMP PREEMPT Sat Jun 8 13:06:26 UTC 2019 armv7l armv7l armv7l GNU/Linux root@xt:/home/paolo# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU 12:03:51: 1608MHz 0.58 7% 1% 5% 0% 0% 0% 58.6°C 12:03:56: 696MHz 0.54 4% 1% 3% 0% 0% 0% 58.6°C 12:04:01: 696MHz 0.49 4% 1% 3% 0% 0% 0% 56.8°C and if I launch a stress test the SoC happily goes beyond 80°C
  8. @Sergei Steshenko Apparently the purple line and audio issues with HDMI are gone in kernel 5.1! Here is an experimental image (Armbian 5.88 + Kernel 5.1.7) if you want to give it a chance.
  9. Yeah, that's an issue I partially addressed and it is related to the peculiar PMU integrated circuit controlling the power of the SoC. Without a reference implementation, it is hard to get the job done.
  10. I'll take a look to the script. Never dig into, just tried a couple of times to check if it was working on our tv box. By the way, there are more options for your setup: use the nand-sata-install script to install armbian on the internal eMMC and then burn a pristine armbian image directly on the hard drive. This way u-boot gets installed in the embedded flash: it is programmed to first check for bootable SD card, then for bootable USB device and, if nothing can be found, tries to boot from embedded flash. (Remember to remove the bootable SD card from the tv box slot) The get a swap partition, you can easily use a tool like gparted and edit the partitions table of the hard drive later. ext4 partitions can easily shrink with no data loss.
  11. Yeah I remember the workaround (it was about editing pulseaudio conf files). This other solution is not a workaround: it's about of making ALSA aware of HDMI and SPDIF devices. This information is then used by Pulseaudio to properly label the devices. It's much better and it is the proper way to do it. The previous workaround is not needed anymore. BTW, ALSA and Pulseaudio do different things. ALSA is an abstraction layer over the hardware, but also has some "software" capabilities, like support for plugins, mixing, etc... Pulseaudio is an audio server which has the same software capabilities of ALSA, but also does something more. It looks to me that ALSA is quite messy, it just does too many things without a clear separation of concepts. I studied it a bit to grasp the bits to understand how to solve the label problem, still I don't understand how it is possible the solution I found works
  12. Mmmh, truly I don't know exactly. I guess the script does everything to setup the whole thing, but I never tried.
  13. That's an HDMI problem, so optical output is always fine (maybe you're interested in giving the sound devices the right names, check this) The bug, as far as I know, is not being actively worked on. @Myy imported some patches that tweaked the HDMI clocks which got into newer kernels, but the problem was not solved.
  14. @Sergei Steshenko Yeah, the bug of the purple line appears in text mode too, because (I guess) it's somewhere in the HDMI kernel driver, so it is not happening in X only. I don't really remember, but it was there (sort-of) in the legacy 4.4 rockchip kernel too, but I'm not totally sure. It's curious your monitor supports only one mode. Usually monitors expose via EDID a list of modes and one mode is "preferred", which is usually the native resolution. Did you try your monitor on a regular PC to check if it really supports just one mode? @pro777 had issues with resolution modes because his box was not reporting any EDID at all, maybe yours has the same issue. Both your issues with the refresh rate and sound are quite strange: changing the refresh rate should not make X crash at boot. Sometimes, expecially with older (<4.20) kernels, it may happen that sound disappears even without the purple line: my guess is that it is the very same problem in the HDMI driver of the purple line, something like bad clocks or bad parameters.
  15. @Sergei SteshenkoThe purple line is a bug in the kernel HDMI driver. It appears in all rk3288 devices. Plugging and unplugging is a solution, but you can also turn the monitor off and on or use xrandr to switch resolution, for example: xrandr --output HDMI-1 --mode 1920x1080 The purple line appars every other time HDMI change status, so a software solution with xrandr you have to switch to another resolution, then to a third resolution and finally back to your native resolution. You can easily make a script to automatize the workaround.