jock

Members
  • Content Count

    420
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Applications

Calendar

Everything posted by jock

  1. @pro777 The DRM is already there in my fork for u-boot mainline and I confirm it works! I didn't merged it yet into mainline armbian because it required u-boot 2020.01 and u-boot 2020.01 requires python development packages. I wanted to wait for general support for 2020.01 in Armbian before moving further. But thanks for notifying it , I guess I need to update the images with recent kernels and packages too! BTW: I would like to try the hantro patches from libreelec, maybe there's the real chance that Kodi works out of the box with accelerated video decoding
  2. I tried Lima on a rockchip based device with mesa coming with Ubuntu Focal but in X11. Indeed it was running, not plenty fast and yet with some graphical issues, but it works. I guess compiling latest mesa from sources may just make things better. Also Lima is currently used in development Libreelec (so no X11) with awesome results.
  3. Unfortunately that's not so easy. GPU and VPU are separate things placed in the same silicon. The former does the rendering on screen, but the latter has to do the video decoding. Hardware video acceleration come with some challenges by itself, plus just rendering what comes out from the video decoder to the screen has also more challenges and can't be done in a "unified" fashion, but each vendor has its own way to do that. Consider also that a decoded stream 1080p25 produces ~150Mb/s of data moving around; those 150Mb/s of data should pass from the VPU to the GPU directly, but that's not easy because of undocumented or unknown specifications. Even if you get that thing done (consider Kodi on libreelec, for example), putting all of this in a browser is another great challenge, because it's not just a video that can be rendered by the hardware in a portion of the screen, but it is a video which has to live inside the HTML elements of the browser, so the whole amount of data must be also processed by the main CPU. This required tons of optimization specific to vendor which works in very particular setups, uneasy to replicate in other ways. Of course having opensource GPU and VPU drivers make the thing much much more easier, but still challenging.
  4. I did some tests yesterday using audacious and had no issues with lagging or stuttering, although pulseaudio is taking an insane amount of cpu processing power (around 20% of one cpu); using ALSA directly, decoding and playing a vorbis file just requires 4% of one core. Youtube instead is out of reach, no way to watch a video even in low quality (480p) without having audio and video issues. I'd like to try armsoc driver sooner or later to see if there is any difference from current modesetting driver, but the SoC is too limited to do video decoding without using the hardware acceleration to ease the work of the ARM cores.
  5. Yes, the missing reboot is an hardware issue, but it is related to NANDs. The board does not shut down, it rebootes correctly but the NAND are not correctly detected anymore after a reboot, so the rockchip miniloader is stuck in an endless loop. This is clearly logged on the serial, if you got any attached. I'm looking into it, but at the moment I can't say if it this could be solved.
  6. The chip is not really powerful enough for a satisfactory desktop experience. I think some optimizations here and there can still squeeze a bit of performance to make it decent enough.
  7. Ok, at least it is a step forward. Most probably your board still does not like mmc-ddr-1_8v, so you can try removing them from the dtb I gave you. That's odd, your eMMC should be quite capable of running in DDR mode at least, but without the board I can't tell.
  8. @Zim_256 very glad you shared the serial ports on this board! Chiptrip board designers always hide serials somewhere on these boards. After showing the GPL the Multitool just unmounts the FAT partition and scans for the flash devices, which should be quite easy task and the screen should definitely not go blank. Could you scroll the GPL with up and down keys? Are you sure the SD Card is fine? Since you got the serial, you could also see what happens in dmesg edit: would you mind to share the commercial name of the tv box?
  9. I understand. Can you please try this other device tree? It's basically the same, but without the mmc-pwrseq property for emmc rk3288-xt-q8l-v10.dtb
  10. Cannot find any traces on the internet of public discussion, but my source says that this is an issue that people from glibc are trying to resolve, and it seems to affect all 32 bit arm systems. The culprit seems to be searched in the architected system timer initialization: if done by kernel causes the problem, done by ATF works ok.
  11. Hello, images have been updated in first page, coming with a more detailed rk322x-config script that will prevent future NAND/eMMC mistakes and provides some more info about the board. Also mainline kernel has been pushed to 5.6 and now an Ubuntu Focal image is also proposed, albeit having a very slow desktop experience and requires the user to uninstall chrony package which is broken and prevents date and time synchronization from network.
  12. @Alex83 I try to explain what happened. The wifi device is attached to the SDIO bus, which is disabled in the generic device tree that is loaded at first boot, that's why the command does not work. In the next release of the images I will fix this. When you called rk322x-config, you choose boards which have no support for nand, so at next reboot it has been disabled and the system was not able to boot anymore. Objectively, at the current stage the user is unaware of this important information making the selection. I'm already addressing this issue providing more info to the rk322x-config script that prevents this kind of mistakes. You could restore the system boot using the Multitool, getting a shell, mounting the armbian partition on rknand0 and then removing the fdtfile= line from /boot/armbianEnv.txt Anyway you could try the mxq-pro-4k box which has NAND and SSV6051 support, you should have no more surprises. Unfortunately, on legacy kernel, wifi requires some kernel module juggling (ie: blacklisting and whitelisting). I would really like to fix this at root, but I only have boards with ssv6051/ssv6256 chips and the worst offenders are the realtek modules, so heading into kernel modules which I can't test is a jump in the dark. About hardware acceleration, all the kernel modules are there, just the software is not compiled to use it. Video players that come with debian/ubuntu are not aware about rockchip acceleration. At this stage you need to compile things by yourself unfortunately. I will take a look to the Mediascript for RK3288 that maybe can be used for a proof of concept, but I don't know how much can be used for RK322x
  13. @Maker39 Very glad you find it useful! Could you please tell me the output of this command: cat "/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1/modalias" Since you got a 8723cs I can make the script autodetect the wifi chip and automatically enable the right module.
  14. That's an issue with the u-boot shipped along the Multitool, missing some patches. I updated the Multitool, so on next installations the MAC address will be stable. In the meantime, to fix the current NAND installations you can download legacy-uboot.img and install it: sudo dd if=legacy-uboot.img of=/dev/rknand0 bs=4M seek=1 conv=sync,fsync
  15. @Armin if you need just something such small, you may find nanopi or orange pi boards. Some small models are pretty cheap (<10$) and well supported by armbian. Tv boxes have no exposed GPIOs, which can instead be very useful for domotic applications. For example, I have an old Orange PI One (Allwinner H3) which has ethernet, 1 USB port, 512mb of ram and some exposed GPIO. I paid less than 10$ some year ago. I guess now you can get something similar with wifi too at the same price.
  16. Yes, I have an idea: rkdeveloptool ef wiped out the internal bootloader, so it must be restored. I attached a couple of binary files in this post. Do the procedure with the first one (V2.51), then if not successful try the second one. Detach all the cables from the board, remove the sdcard also. Connect the Male-to-male cable to the OTG port and then connect to an USB2 port of the computer. Calling lsusb you should see a device with ID 2207:320b. If so good, we're in maskrom mode. Call rkdeveloptool db loader.bin - change loader.bin with the filename of the loader you want to use. It should take a couple of seconds Wait for 10 seconds, then call rkdeveloptool rfi - this command should reply immediately and should tell you sensible informations about the flash memory you have: its total size in megabytes, its page size, access timing and vendor. You should not get senseless informations, like a total size of 0 megabytes or zero access timing. If so, restart the procedure and try the other loader. Call rkdeveloptool ul loader.bin - again change loader.bin accordingly. Should terminate immediately. Wait 5 seconds and then call rkdeveloptool rd Now wait for a minute. If you're lucky, armbian will boot automatically, otherwise detach all the cables and do again the steP-nand installation If still does not work, repeat the procedure using the other loader Try this and let me know if it worked. If it didn't we will try another procedure. RK322XMiniLoaderAll_V2.51_spectek_en_ddr2_rd_odt_180703.bin MiniLoaderAll_unknown.bin
  17. Hello guys, finally, after a huge and time consuming effort, me and @fabiobassa have a working method for installing Armbian on NAND devices! The method is called steP-nand (Ste Puttane di NAND) and is available as an option in the multitool only for boxes equipped with NANDs. What you need: a fresh copy of the multitool a fresh copy of the armbian images installation instructions Everything can be found in the first page of the thread. Enjoy!
  18. I think the mmc-hs200 option blocked the kernel from recognizing the internal flash, so probably yes. It depends. On legacy kernel there are all the modules and options active in the kernel, but the compilation and installation of the video drivers (armsoc) and software (kodi, mpv, etc...) is demanded to the users at the moment. On mainline kernel the driver for hardware video decoding is there, but lima driver is not yet working with X11 and still the user require to compile kodi, mpv or whatever. Yes, it partially supports the internal NAND at the moment. You can write images on NAND, but they won't work because the NAND has a different layout organization. We are working on a solution we will make public soon.
  19. You can change status="disabled" into status="okay" from your HK1 device tree to activate the emmc node. Then recompile dtb, reboot and it should work. Or, as you said, remove the hs200 from all the 3229 dtbs and try them all. edit: I'm going to upload refreshed Armbian images without the hs200 line later, also because Focal now has been released and contains official packages.
  20. @Maker39 Well, I don't see any eMMC controller in your dmesg (30020000.dwmmc) Try with another board with rk322x-config. Still you need to remove hs200 mode from the device tree you select. I think the eMMC node of the board you selected is just disabled in the device tree.
  21. Just to be sure, since that happened a ton of times to me: did you remember to compile the dts back to dtb? A dmesg log would be interesting to see.
  22. @Maker39 The multitool did its work, but I think that the problem you're having is the same as before: the mmc-hs200-1_8v; line in the device tree prevents the correct detection of the eMMC by the kernel, so it hangs. Normally the driver automatically resorts to a slower but safer mode, but it is not happening for your board. Need to fix this in the Armbian images
  23. Hmm, never experienced such problem, also because the message is from kernel and is totally normal. Do you mean it stopped because the progress bar was not increasing or did it give you an error? Do you get the message on the screen of just on the serial? Also was the serial still responding? Did you try to load up all the three images in the same session or in separate sessions? Note that the blue led is normally blinking fast when you read or write into emmc, did you notice if it was blinking or it was steady on or off when it stopped? It happened to me that the screen freezed after 10 minutes, it is normal because the kernel blanks the screen after some minutes of inactivity. Rockchip HDMI kernel driver has an issue that makes freeze the screen, but is sufficient to press a key to restore the screen updates. I disabled this in the kernel command line, so it should have not happened... but don't know Anyway thanks for testing! Hint: the multitool works also for libreelec images
  24. Yep, Armbian image is not "plug&play", requires some preparation of the board because the purpose (server machine/all purpose desktop) is different than LibreElec. NAND is available as a storage device only if you use legacy kernel 4.4 images. Mainline kernels do not have the necessary driver to access it. As a boot device it is not usable at all at the moment. Option a (JumpStart) is almost full Armbian, so it allows all the updates of the kernels when they will be programmed and software, also allows to boot from external SD Card and USB Stick, but prevents the internal image to boot (due to missing NAND driver above) Option b (Maker39 images), are plug and play, don't require tinkering with internal NAND, but may miss some low-level updates in the future Usually they fix LED behaviour, WiFi detection and NAND/eMMC selection. You can do by trial and error, you should not get stuck but in case, just remove the line "fdtfile=" from /boot/armbianEnv.txt on the sdcard to restore the default board.
  25. I have seen the photos you posted. The eMMC is a sandisk and should be well supported in HS-200 mode. If you feel brave, you can decompile the device tree (rk322x-box.dtb in the FAT partition), find and remove mmc-hs200-1_8v; then recompile it back and try again. That's the only thing it may interfere with hardware detection