• Content Count

  • Joined

  • Last visited

About jock

  • Rank
    Elite member

Recent Profile Visitors

1126 profile views
  1. 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?
  2. 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
  3. 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...
  4. 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.
  5. 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:
  6. 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.
  7. 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.
  8. @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.
  9. 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.
  10. @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.
  11. @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
  12. 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.
  13. 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
  14. 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
  15. 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