jock

Members
  • Posts

    1158
  • Joined

  • Last visited

Recent Profile Visitors

5522 profile views
  1. ASUS Tinkerboard-S, briefly tested and perfectly working: Kernel 5.15 - CLI - Debian Bullseye Kernel 5.15 - XFCE Desktop - Ubuntu Focal
  2. @hexdump Thanks a lot! I later checked out the patch series and in the description armhf architecture is effectively omitted, so probably is untested and not expected to work. Anyway I don't know how it could enter into mainline if it is allowed to compile on armhf but cause heavy issues: the kconfig file should at least be patched to allow compilation only on amd64 and arm64 architectures. I hope they will provide fix and tests for armhf too - hopefully x86 32 bit too. Those 32 bit architectures are going to benefit a lot from this patch since most memory-constrained devices are 32 bit only.
  3. @Jack853 @MR01 Multitool will expand the FAT partition automatically to the size of the medium once it has been run for the first time on the box. Also you can put compressed images on sdcard and multitool will expand them on the fly during restore/burn process. Note also that, due to FAT partition limitations, a file cannot be larger than 4GB
  4. @cmuki Assuming the boot you provided is from the original image, I think there is no extra questions to ask: if the ddrbin says that you have 2048 megabytes, that is so. The ddrbin, which is the first piece of code that is executed at all and initializes the board DDR memory, is the most reliable source from this point of view. Going on with the bootstrap phase, u-boot says the same: U-Boot 2017.09-gaa00306-201224-dirty #foxluo (Jan 19 2021 - 14:31:53 +0800) PreSerial: 2, raw, 0xff130000 DRAM: 2 GiB And obviously even the linux android kernel also detects 2 gigabytes of total RAM: [ 0.000000] Memory: 1955884K/2064384K available (14910K kernel code, 2056K rwdata, 8884K rodata, 3968K init, 2806K bss, 75732K reserved, 32768K cma-reserved) That's it, fake hardware specs; the manufacturer altered the Android image somehow to show fake specs and maybe something is wrong with the DDR chips too (are they have been reprinted? are they just fake chips or not really connected to the board? who knows...)
  5. Lima driver for 3D is active and working pretty fine since a long time, the only reason it was disabled for X.org was the slower performances in desktop usage due to missing "optimizations" in modesetting X.org driver. This causes buffers being moved back and forth and thus degraded performance but, as you confirm, 3D is enabled for X.org too. For any other usage unrelated to X.org (including Wayland/Weston, Kodi, OpenGL games, ...) Lima driver and 3D acceleration have always been available.
  6. @cmuki Well, the ways of the chinese cheap tv boxes are infinite... we have seen fake Androids that show more hardware or different hardware; in a case we have also seen a fake amlogic s905x chip which in reality was a rockchip rk322x chip: they altered both the serigraphy printed on the chip itself and the Android software to make it appear as an amlogic. The guy was not able to let armbian run until he finally tried rk322x image and voilà... it worked! So it could be quite possible that your box is advertised with a fake specs (and indeed the eMMC is detected as a 32Gb part and not 64 as advertised), and even the chips are somehow fake, disconnected or broken. There could obviously be a bug in the code, that even won't surprise me. To be really sure of the amount of RAM you have available you need the serial UART: at the very beginning, the boot process will show the amount of memory banks you have and their size. That's the source of truth, because it is a binary provided by rockchip itself. If you still have Android installed (or did a backup), you can read that info during boot and that will provide a reliable info.
  7. I may remember not so well because rk3318 received little attention lately, but it should be enable and provided via opensource Lima driver. You can check if AccelMethod is set to "glamor" (enabled) or "none" (disabled) in /etc/X11/xorg.conf.d/40-serverflags.conf As usual, it is wise to disable compositing for a bit better performance in a typical desktop usage.
  8. @MattWestB @fedex Hello, I enabled BPF filters and various other related options. I built an experimental kernel you can install with dpkg taking packages from here I didn't enable other cgroups options except for the one related to BPF, let me know if docker works for you or still there is the need for something else.
  9. @fedex not really too much time lately, but I will try to enable config options and compile it today if possible!
  10. I guess lightdm+lxde are not under wayland but rather regular X.org. About hw acceleration, what do you mean? Both 3D acceleration via GPU and hw video decoding through VPU works on all recent mainline kernels, Chrome is just not able to deal with them: that's a long way to get there.
  11. @RaptorSDS Well, I guess the patch should not really harm anything and can fit in with no particular problems.
  12. Never heard about sv6030P and never saw any driver for it. It looks very similar so ssv6051p, but can't say what kind of support it has.
  13. It is perfectly ok and safe to do: you may want to change and test other parameters, it will not cause any conflict of any kind, at least if you don't modify manually the overlays line in /etc/armbianEnv.txt
  14. Hello @Buqan Kaleng Kaleng 1. you should try and see which one works for your board. You can enable both of them: and a valid board, the kernel will choose the best option and it will just work. On a so-so board it may happen that the kernel choice does not really work and the board may have issues to detect the internal eMMC; then you need to use to use multitool to manually tinker with /etc/armbianEnv.txt and do trial and error to find which one works for you. If you are not skilled enough or are afraid to lose the installed system, keep both of them disabled so the safest (but slowest) capability will be used 2. H96Max is the tv box market name; we don't use the market name because the same tvbox can contain many different boards: you have to open the case and see the signature printed on the board PCB
  15. Understand, but AP6330 should work both for wireless and bluetooth parts right now on rk3318/3328 - everything is already in place and implementation is right since, as you see, it works. The issue you had must be investigated with more tests to get into the real cause (rfkill? wrong dtb? ...) I have AP6330 in a rk3288 box and both wifi and bluetooth works well. There are issue though when you do a lot of traffic at the same time with both devices, because co-existance is difficult on 2.4ghz channel and I never really digged into the issue.