• Content Count

  • Joined

  • Last visited

About pask

  • Rank

Profile Information

  • Gender
  • Location

Recent Profile Visitors

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

  1. Hello @piter75 Thank you! Now I understand why I'm not able to reach the nanopim4-v2 with a buster/4.4x sd image through the wired network. BTW I've not anymore connected my serial dongle to the m4v2, as I've moved the board from my desktop to an "intended production" position, and I'm using it headless and wired connected. The 5.4.2 buster image works quite well in server mode (wired network, usb, and so on). Still troubles when in desktop mode as I have experienced frequent freezes that make it unusable. Even when connected via a tigervnc client to a tigervnc se
  2. I you scroll down the page you'll find the fat desktop images too.
  3. @pkfox It's time to use WIP images for this board No need anymore for patchs or other magics. Anyway, my experience is that the 4.4.y images still don't work for me. While the ones with buster 5.4 kernel work, but I'm still struggling to get anything really useful done as I'm still experiencing some unreliable behavior, like sudden freezes when connecting be means of tigervnc. Perhaps my board is an unlucky sample. Let us know if you experience goes better.
  4. Great job, @piter75! "current" buster desktop works well for me. The debug ttl console too. Performance are much better than default friendlyelec 4.4.y kernel's ones, although not overall better than those of the ddr3 version 1 nanopi m4 (see Memory performance (big.LITTLE cores measured individually): memcpy: 1880.5 MB/s (0.6%) memset: 8430.7 MB/s (0.6%) memcpy: 3729.4 MB/s memset: 8492.3 MB/s (1.0%) Complete sbc-bech results here: Bot
  5. My usb ttl dongle is a "DSD TECH SH-U09C5" with a FTDI FT232RL chip. Here is today dmesg from the default kernel image and it doesn't look like totally "healthy" to me Yes I use TX,RX and GND wires. As soon as I plug in the dongle (or connect the gnd to the board), the nanopi m4v2 freezes. The problem is that I do not see anything recorded in the logs of the freezing event.
  6. @Enrico You can use the minimal "test" image shared by @piter75 some posts above: it works already quite well, altough more testing is needed. You can also compile it yourself using nanopim4v2 ddr branch from armbian/build git repository.
  7. Thank you @piter75 While booting your minimal default image (as well a default desktop one compiled by me using your last commits), if the ttl serial dongle is plugged in, my board gets stuck somewhere at kernel time. Here is a log For many tries I had not understood that the problem was, actually, the ttl dongle itself. But, as a last try (given that I was suspicions because of the lack of hdmi activity during kernel boot, at least until it went stuck), I have disconnected the serial debug dongle, and finally I have seen hdmi activity and, at the end,
  8. Indeed, the dev kernel image worked for me too. Could you also check a default kernel image, please? (using the nanopi-m4v2-u-boot-v2019.10-ddr-miniloader branch) Only this one failed on my M4v2, instead. ./ BOARD=nanopim4v2 BRANCH=default RELEASE=buster BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no Thank you @piter75 . Comparing the two default image boot logs, mine and yours, they have some "small" differences. Yours: ChipType = 0x10, 316 Mine: ChipType = 0x10, 250 I do not know to what this attri
  9. @piter75 the dev kernel boots correctly: I have also tried the desktop version which works quite well if panfrost is disabled. Audio doesn't work: strangely it seems that this kernel version doesn't support the Realtek ACL 5651: I tried to manually edit the .config, but with no success Instead, images with the default kernel fail (tested with various sd cards): I guess that the friendlyelec 4.4.y kernel dts isn't compatible with the 2019 uboot branch
  10. Hello @piter75 fails because of some absolute paths left into the code. pack uboot.img success! /home/pask/armbian-master-build/config/sources/rk3399.conf: line 70: /home/vagrant/armbian/patch/atf/atf-rk3399/add-trust-ini.patch: No such file or directory config(trust.ini) not found! merge failed! [ error ] ERROR in function compile_uboot [ ] [ error ] U-boot file not found [ trust.bin ] [ o.k. ] Process terminated which was easy to fix by myself. But, some steps later: pack input ./u-boot-dtb.bin pack file size: 829663 crc = 0xdf3
  11. @piter75 At the moment I'm running Manjaro with 5.3.11 kernel on the M4v2: I'm experiencing lots of freezes that I'm not been able to diagnose and troubleshoot so far. I was suspecting power issues (which could also explain the USB issues that @NicoDdescribes). But, this morning I tried to use the Raspberry Pi4 official power adapter and cable, which I know to be dependable. But while I was doing a dd of a 4GB file on the SD card, the board got stuck for the umpteenth time: so, now I believe my issues might be related to the SD card / controller. Anyway, in the evening I
  12. Hello Nico, your reviews go so deep and are so well made that I learn something from you everytime I watch one of them. Thanks
  13. @sfx2000 It's not a question of performance, but of convenience. At least to me. Small fanless ARM personal computer devices are getting faster and faster on one hand. On the other, they can be easy installed at home or other places where space, energy costs, and even cooling, are an issue. And left there running 24h. So, you can launch heavy duty compiling tasks and forget them, till the next morning or the evening when you return back home. BTW, I understand that building a working arm64 toolchain could be not easy. Actually, I can't imagine the effort required. I
  14. This is an excellent idea: I have an odroid n2 always on the Internet using a public IP, I'd like to use to compile Armbian for other boards (at the moment a NanoPiM4-v2). Sadly, it seems that the author abandoned, or could not continue this interesting project. On the other side, for what I have understood reading some of the Armbian code, It's not easy to archive the goal of compiling directly on arm64 hardware.
  15. pask

    M4 V2

    @pkfox The long part of my emmc card has an hole for a screw: this part has to be aligned to the screw holder, in the opposite side with respect to the hdmi. Il you buyed the emmc for the first version of the m4, I suspect yours does not have the hole. Try to place as if it had.