jock

Members
  • Content Count

    240
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Raffles

Applications

Everything posted by jock

  1. Oops, I removed the link by mistake... I fixed it, so you can following the link in the previous post. You can compile the driver and install it, it may work or may not work, as I said I don't know the DRM state for rk3229. Then you need to compile and install the kernel driver for mali 400/450 (rk3328 has the mali 450, you should be able to use that one), then install the userspace egl/opengles libraries. It's a bit long journey, I know. Thanks for the new thread, I will read it into, even if I don't own an rk3229 box (I got a rk3288). edit: You can take a look to this post, you can find there a precompiled armsoc (which may or may not work for your xorg server version) and some instructions on how to install it. Armsoc driver replaces the default Modesetting xorg driver, which in general is not a great idea, but only Armsoc is capable to let EGL and OpenGL ES proprietary userspace libraries work for 3D acceleration. edit 2: hardware acceleration should also work on legacy 4.4 kernel. There you should also get some video decoding acceleration which will probably never be supported on mainline for that chipset. But you will need a different armsoc driver than mine if you want to run it on legacy 4.4 kernel because the DRM interface is different (no generic dumb buffers on 4.4, instead there are per-vender IOCTLs :/ ) and the armsoc driver has to deal with that.
  2. My armsoc variant (you can find it here) has decent support for video acceleration. To be honest I just fixed some minor issues to get page flipping when in full-screen and copy-pasted some code to allow rockchip, amlogic and allwinner chipset to use the DRM dumb buffers in mainline kernels; nonetheless using it you can then use the proprietary Mali drivers to get windowed and full-screen 3d acceleration. I don't what is the state of DRM bits for rk3229, maybe it worth a try (but you need mainline kernel).
  3. Modifying the memory node in the device tree should suffice to match your hardware configuration
  4. I want to underline that AFAIK rk3318 is still missing support from opensource communtiy, it does not even boot (ie: no documentation, no source code, ...) If you don't want to run armbian or any other Linux distro soon and possibly never, it could be. Personally I would not choose rk3318 for anything at the moment. S905X2 and S905X3 are in a better shape according to http://www.linux-meson.com and have more modern hardware on board
  5. @fabiobassa Open a new thread focusing just on rk3229. It's a very old SoC, and probably you won't get much support from the community because of the newly-released SoCs, but nonetheless it's easier by far to find and share experiences in a dedicated thread. About acceleration, I guess you mean hardware graphics acceleration? If so, it's up to rockchip to release the right ARM Mali drivers tailored for the rk3229 chip, nonetheless the opensource lima driver landed in mainline kernel and mainline mesa and it is already working at least for some clients (ie: Kodi)
  6. Just made a fresh Ubuntu Bionic image with kernel 5.3.4. It's untested, but should work flawlessy: https://drive.google.com/open?id=1YTw2gD21G7nyXZZmJac-u4qsWkuoeK9X
  7. Theoretically rk3318 is a cheap version of rk3328. We don't know yet perfectly what rockchip means with "cheap version", what is stripped down and what has been removed from rk3328 that makes it less expensive because there is no datasheet, no official launch and no technical documents about. It's just my guessing that maybe they reduced the video encoding/decoding media features, but some other people said that the rk3318 has a bit more powerful GPU than rk3328, and on par with s905x (which is a bit strange, because rk3318 should be the cheaper version...) edit: ah, rk3328 has support from armbian and mainline kernel, 3318 in theory is exactly the same but still does not appear officially anywhere
  8. Hello, I managed to bump the rockchip-dev kernel to 5.3.y on my fork. After removing a couple of redundant patches and updating two or three of them I'm able to compile with no problems. The new kernel also boots fine on my rk3288. Don't know if anyone is already working on this (maybe @Igor or @TonyMac32), if my work can ease someone's else fatigue I can make a merge request from my repo to main armbian repo for code review (the single commit is here) documenting the steps I did.
  9. a tv box (xt-q8l-v10) Mostly the same as yours, but I tried different OTG adapters and all worked fine. BTW, mine was just a suggestion to play with, as long as I don't have a tinkerboard to test by myself it's not the real solution. Do the OTG port can be used as a HOST port with official OS?
  10. It should, but I don't know if there are all the bits in the drivers and if there's something needed to do in userspace (like udev rules, usb mode switching, ...). I don't own a Tinkerboard but a device based on rk3288. The OTG port comes out directly from the SoC and dr_mode="host" works flawlessy on my device
  11. I had the chance to try (had to bring out the serial adapter, cables, etc...) and I confirm it works! Finally I decided to not hardwire it in u-boot but set the environment variable, which is fine for my setup. Definitely a video console could be really helpful to tinker with u-boot environmental variables instead of the need for the serial adapter and a separate PC each time...
  12. Looking at the device tree, the OTG port is explicitly enabled and configured in "otg" mode, so there is a hint that could possibly work but it is not an evidence. You may try to decompile the device tree, find this section: usb@ff580000 { compatible = "rockchip,rk3288-usb", "rockchip,rk3066-usb", "snps,dwc2"; reg = <0x0 0xff580000 0x0 0x40000>; interrupts = <0x0 0x17 0x4>; clocks = <0x7 0x1c1>; clock-names = "otg"; dr_mode = "otg"; // Change this to "host" g-np-tx-fifo-size = <0x10>; g-rx-fifo-size = <0x113>; g-tx-fifo-size = <0x100 0x80 0x80 0x40 0x40 0x20>; phys = <0x40>; phy-names = "usb2-phy"; status = "okay"; }; and change dr_mode into "host". Then recompile the device tree and try again. Maybe the mode can be changed at runtime, but I'm not aware of any way to do it.
  13. Yes it should work that way. At least, it worked on my S905 machine. Didn't you forget to recompile the dts back to dtb, did you? I'm not sure, but the reusable flag there should allow the kernel to use the same CMA region for its own needs, so it should act totally as a shared dynamic memory. You can anyway take a look to the official documentation becuase I may miss something: https://www.kernel.org/doc/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
  14. The reg property is used to declare where the device have their memory-mapped region to interact with the operating system. You can imagine that devices (like the ethernet, the gpu, etc...) have one or more "windows" in the virtual address space of the CPU. Normally these windows are fixed in the address space, and the device tree declares where those windows are, letting the operating system drivers know where to access the devices. In case of reserved-memory section, I see no real drivers involved there, so I guess that the memory is already reserved by bootloaders (the amlogic proprietary bootloader, mainly) and the declarations there inform the kernel not to use those locations because they are reserved. You could remove the reserved sections, probably the kernel will show that more memory is available, but you may also expect malfunctions because some application may write in those reserved locations causing unpredictable behaviour! Also check the size of the reserved CMA block (dmesg | grep cma). It should be possible to resize it via extraargs in armbianEnv.txt or recompiling the kernel. 8 megabytes there should suffice. edit: I checked on a S905 device, the CMA can be changed only editing the device tree and should not be less than 32M, otherwise X fails to start on my configuration.
  15. Thanks for the finding, I will try to test as soon as I can; unfortunately u-boot on rockchip has no video console, so it requires a serial port access :/ Also armbianEnv.txt is of no use here because the USB detection happens before its parsing.
  16. @Sergei Steshenko yes, add extraargs=... to /boot/armbianEnv.txt to append options to the kernel command line. @DRAGO4k I prepared a debian buster image (kernel is the very latest 5.2.6, u-boot is v2019.04) with the changes to the device tree I mentioned some posts ago. I'm currently using the modified device tree and I see no regressions. You can download the image from here to see if the power down/power up event still happens. In the meantime I had a session with the serial attached to see why I had issues with my USB-to-SATA adapter. In practice it looks like there is no issue at all: my adapter takes some seconds to initialize. The box just does not enumerate the USB device because it is not ready yet. More of that, I found no evidence of any configurable timeout in u-boot not in the code nor in the environment variables. Eventually it looks like there isn't any issue from the box side, it's just the adapters that expose themselves after a timeout, probably to wait for the SATA disk to fully spin-up.
  17. hmm that's interesting. I guess I should take some care about that. For example the kernel device tree contains these lines Maybe adding regulator-boot-on and removing the pinctrl-* properties from the vcc_host_5v and vcc_otg_5v sections will prevent the USB ports to be powered off 1) I guess that there is a mosfet or whatever that controls the power to the USB ports, controlled by GPIO lines. You can see from the piece of the device tree I highlighted previously that GPIO 14 of bank 0 controls the power of the two non-OTG ports and GPIO 12 of bank 0 controls the OTG port. In theory it could be interesting to find the part on the board, read the signature on it and try to understand how much current it can sink. 2) True, under heavy load the chip and the board can draw quite an amount of current. Definitely an ATX power supply is a good way to benchmark this. 3) and 4) Very interesting! Where did you sample the voltage, I guess near the USB port? Clearly so much voltage drop even with modest load could not sustain any external hard drive.
  18. @Sergei Steshenko You can add kernel command line parameters using the extraargs argument. They will be appended to the command line as is: extraargs=rootdelay=30 If you are booting the kernel from the sdcard/emmc and the root filesystem is on the external HDD this may work. Of course if the HDD is suffering power outages (like you're describing), it won't work anyway.
  19. @DRAGO4k I also thought it could a software issue, I mean some kind of power limit to prevent issues from too demanding devices. So I tried the very same HDD with the original firmware and the motor failed to spin up, exactly the same way it happens on armbian. I guess that's a limit of the hardware. A thing I noticed is that, while taking the photo above, the box is able to be backpowered from USB: while moving the things to arrange the photo, by the barrel connector slipped outside from the box but the box didn't turn off: the other barrel connector feeding the hdd was backpowering the box via USB
  20. Hello @Sergei Steshenko, I'm in your very same situation: I have a external 2.5" HDD connected to a non-OTG USB port that contains the whole armbian rootfs. U-boot is installed in internal eMMC, so I don't required the sdcard to boot from the USB. My HDD enclosure has a convenient barrel power connector for auxiliary 5V power. The non-OTG USB port itself is not able to spin-up the hard disk (neither the OTG port is), so auxiliary power is required. I use a 12V 2.0A PSU which feeds a very small DC-DC switching power converter outputting 2A at 5V, which in turn feeds the box and the HDD. I thought that 2A are way too low for both the devices, in fact the DC-DC power converter gets quite hot, but after a couple of months of work it has not yet failed. I have the same problem as you: if I turn on the box too soon, the hard disk is not detected. I have to wait a couple of seconds letting it initialize and then I can turn on the box. It's clearly a timeout issue. After a quick look into u-boot compilation config file I could not find the USB timeout we are looking for, I guess I need to check better. If the USB timeout is stored into an u-boot variable, it can be changed very easily setting it into /boot/armbianEnv.txt, otherwise it is necessary to recompile u-boot. Stay tuned, I'll look into it.
  21. If you mean hardware accelerated 2D desktop, the out-of-the-box xorg modesetting driver is sufficient for light desktop usage. If you want 3D acceleration you need to compile and install the Mali kernel driver, compile and install the xorg armsoc driver and install the ARM Mali OpenGL ES proprietary binary drivers. It's not a titanic job, but requires some experience
  22. jock

    Wayland on ARM SBCs

    I queue for the details about panfrost + updated mesa + wayland (or X11) session. Some basic steps to get an usable setup would be wonderful
  23. FYI, just upgraded to dev kernel 5.2 and thermal trip points are back! root@xt:/home/paolo# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 16:08:41: 600MHz 1.58 20% 3% 12% 0% 4% 0% 62.9°C 0/11 16:08:46: 1608MHz 1.46 12% 2% 8% 0% 1% 0% 62.1°C 0/11
  24. About point #3, your Orange PI PC is not stuck at kernel 3.0. H3 chip is not the fastest nor the newest, but currently is one of the best supported in mainline kernel. There is an enduring work-in-progress for hardware decoding on mainline kernel which is progressing nicely. It looks like LibreElec will soon include some official H3 support. All the main peripherals are working well and 3D acceleration is available. As for desktop replacement, the problem with the H3 is the lacking of the thermal driver, so frequencies of the SoC are set in a conservative fashion in armbian. The experience may suffer from this. You may think to use a small heatsink and drive the SoC to its rated 1.4Ghz and see if it satisfactory for you. IMHO it is not powerful enough for a decent desktop replacement, but you may try and see if it suits your needs.
  25. I'm aware of the bootloader tinkering, but in the armbian download page there are the instructions to wipe the internal eMMC to enable the straight usage of armbian image (and mainline u-boot). If you don't mind to lose the embedded Android, you may try to follow those instructions. BTW: it's better to discuss about this other tv box on the other thread