IgorS

  • Content Count

    67
  • Joined

  • Last visited

About IgorS

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yes, I am building current images. 2021-03-27 14:17:03 Executing: ./compile.sh BOARD=orangepione USEALLCORES=yes BRANCH=current KERNEL_ONLY=yes KERNEL_CONFIGURE=no Result: version 5.10.21
  2. Hello Armbian, Since long time ago, build system is stuck at mainline kernel version 5.10.21 (for OrangePi H2+ H3 and H5 boards). Am I doing something wrong or what? Best regards.
  3. Tried, problem is really solved. Btw, I am building kernels for 6 boards, mainline and legacy, everytime when new versions of kernel appear. Changes in building system that have been made since kernel version 5.8.16 speeds up building about 20%, according my observations. Good work!
  4. Of course, I know that debugging takes time. I'm just trying to provide developers with as many clues as I can to make their job easier.
  5. I need to build kernels for several sbcs, six to be exact and do this in a loop using a small script to save myself from waiting build to finish and start another.The reason why I don't want to clear entire cache directory is because in that case it downloads toolchain's and sources again and this is slow. It looks like that deleting 'ghost' debs in build/cache/sources/linux-mainline before building do the magic.
  6. I think, found what is wrong. @Werner was right, first build from 'fresh' build directory is always ok. In next builds without 'radical' cleaning cache things go messy. In directory build/cache/sources/Linux-mainline I found: linux-5.4.72-sunxi_20.11.0-trunk_armhf.buildinfo linux-5.4.72-sunxi_20.11.0-trunk_armhf.changes linux-5.8.17-sunxi64_20.11.0-trunk_arm64.buildinfo linux-5.8.17-sunxi64_20.11.0-trunk_arm64.changes linux-5.8.17-sunxi_20.11.0-trunk_armhf.buildinfo linux-5.8.17-sunxi_20.11.0-trunk_armhf.changes linux-dtb-current-sunxi64_20.11.0-trunk_arm64.deb linux-dtb-current-sunxi_
  7. @Werner thanks for advice, but I got a whole bunch of debs at first build, after I deleted build directory and created it fresh from git. It can't be a problem with any 'leftovers' because everything was fresh.
  8. Definitely is an issue. For very long time i use build script to build kernel for several orange pi boards, and allways the result was 8 debs for each board: source, dtb, headers, image, u-boot, armbian-firmware, armbian-firmware-full, armbian-config. Now something went terribly wrong, I become whole bunch of debs which are unrelated to my target.
  9. I can confirm, there is new bug in build system. I tried with clean build system just cloned from git, and here is the result in build/output/debs which was empty (not existing) before build run: 2020-10-31 07:51:45 Executing: ./compile.sh BOARD=orangepione USEALLCORES=yes BRANCH=current KERNEL_ONLY=yes KERNEL_CONFIGURE=no 2020-10-31 08:18:36 Created: file: -rw-r--r-- 1 root root 43716 2020-10-31 08:17:33.152639730 +0100 armbian-config_20.11.0-trunk_all.deb file: -rw-r--r-- 1 root root 139643152 2020-10-31 08:18:35.516980290 +0100 armbian-firmware-full_20.11.0-trunk_all.de
  10. Finally good news! Today (2020-07-14) for ubuntu bionic becomes available mesa update, following packages: libegl-mesa0 libegl1-mesa libgbm1 libgl1-mesa-dri libgl1-mesa-glx libglapi-mesa libglx-mesa0 mesa-va-drivers mesa-vdpau-drivers After that, xfce desktop on orangepi2e starts to work flawlessly with kernel 5.4.xx (in my case 5.4.51) again. Exact versions of packages: igor@orangepiplus2e:~/trash/mesa$ dpkg -l | grep 'mesa\|libgbm1' ii libegl-mesa0:armhf 20.0.8-0ubuntu1~18.04.1 armhf free implementation of t
  11. Ubuntu issued mesa 19.2.8, still not working with kernel 5 on H3 an H5
  12. I narrowed a bit the problem. Just mesa packages causing rendering problem, drm packages are ok. So, bad guys are: libegl-mesa0 libegl1-mesa libgbm1 libgl1-mesa-dri libgl1-mesa-glx libglapi-mesa libglx-mesa0
  13. In description of this ppa: "Supported architectures: amd64, arm64, i386" and there is problem on 32 bit armhf (H3 i.e.) However, I tryed on H5 (OrangePi PC2, OrangePI Prime) without success. After updating drivers and configuring Xorg, problem remains exactly the same as before.