• Content Count

  • Joined

  • Last visited

About jock

  • Rank
    Elite member

Recent Profile Visitors

1223 profile views
  1. Modifying the memory node in the device tree should suffice to match your hardware configuration
  2. 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 and have more modern hardware on board
  3. @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)
  4. Just made a fresh Ubuntu Bionic image with kernel 5.3.4. It's untested, but should work flawlessy:
  5. 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
  6. 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.
  7. 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?
  8. 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
  9. 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...
  10. 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.
  11. 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:
  12. 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.
  13. 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.
  14. @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.
  15. 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.