Jump to content

pask

Members
  • Posts

    29
  • Joined

  • Last visited

Everything posted by pask

  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 server there are frequent freezes of the xfce desktop environment. But the board itself doesn't freeze: indeed, if I close the tigervnc client window once frozen, when I reconnect to the tigervnc server, I can continue using the desktop, at least until the next freeze. I suspect It's not a tigervnc specific issue, as I've also tried x2go and experienced a similar behavior. Thank you too @pkfox. Actually who deserves our kudos are the great armbian developers, and among them I can cite @piter75, who has made possible to us the use of the great armbian OS on this board.
  2. I you scroll down the page https://www.armbian.com/nanopi-m4-v2/ you'll find the fat desktop images too.
  3. @pkfox It's time to use WIP images for this board https://www.armbian.com/nanopi-m4-v2/ 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 https://www.cnx-software.com/2019/10/28/nanopi-m4v2-kit-review-part-2-friendlycore-desktop/): 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: http://ix.io/23eC Both sd card read and write speeds are good: 70MB/s with a sandisk 32GB extreme pro card Stability also looks good, but requires more time to be tested. As soon I'll be able to run some panfrost benchmarks, I'll update. By the way, desktop experience is smooth and stable and sound works too, but lack of acceleration is limiting when watching videos, although the 5.4 kernel improved speed over the 4.4.y is evident. The only "small" issue I have found so far, is that boot is a bit slow. And for about 30 seconds I do not see any activity, neither on the serial console, nor on hdmi. Perhaps because of "printk: bootconsole [uart8250] disabled" ? I'm going to do some usb storage tests, before considering this board ready for replacing the raspberry pi4 I use at the moment as my home nextcloud server.
  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 http://ix.io/22SV 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 http://ix.io/22L4 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, the login prompt. In other words, the problem with the default kernel image seems to be the serial dongle plugged in. On the other hand, once booted the board (default kernel) without the ttl dongle plugged, and once normally running the Armbian OS, if I try to plug the ttl usb dongle into my laptop usb port, the board freezes.
  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. ./compile.sh 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 attribute references . Perhaps to the sd card vendor/model? Yours: ## Executing script at 00500000 Boot script loaded from mmc 1 244 bytes read in 9 ms (26.4 KiB/s) 6514583 bytes read in 421 ms (14.8 MiB/s) 18395144 bytes read in 1172 ms (15 MiB/s) 103833 bytes read in 19 ms (5.2 MiB/s) ## Loading init Ramdisk from Legacy Image at 04000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 6514519 Bytes = 6.2 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 Loading Ramdisk to f58c6000, end f5efc757 ... OK ERROR: reserving fdt memory region failed (addr=0 size=0) Loading Device Tree to 00000000f5844000, end 00000000f58c5fff ... OK Mine: ## Executing script at 00500000 Boot script loaded from mmc 1 142 bytes read in 5 ms (27.3 KiB/s) 7556947 bytes read in 480 ms (15 MiB/s) 18395144 bytes read in 1161 ms (15.1 MiB/s) 103833 bytes read in 14 ms (7.1 MiB/s) ## Loading init Ramdisk from Legacy Image at 04000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 7556883 Bytes = 7.2 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 Loading Ramdisk to f57c8000, end f5efcf13 ... OK ERROR: reserving fdt memory region failed (addr=0 size=0) Loading Device Tree to 00000000f5746000, end 00000000f57c7fff ... OK On the same hardware, the same running software shouldn't lead to the same amount of bytes read? Anyway, I'll try the debug enabled image and I'll further check. In the meantime, could you also share the default minimal image it's working to you? Just to be sure I'm not doing some dumb error while compiling the image I'm not aware of.
  9. @piter75 the dev kernel boots correctly: https://pastebin.com/jrghsmPi 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): https://pastebin.com/FSfEs9Kq I guess that the friendlyelec 4.4.y kernel dts isn't compatible with the 2019 uboot branch
  10. Hello @piter75 compile.sh 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 [ compilation.sh:216 ] [ 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 = 0xdf37889f pack uboot.img success! /home/pask/armbian-master-build #pask info patching file trust.ini out:trust.bin E: [mergetrust] filter_elf /home/vagrant/armbian/cache/sources/rkbin-tools/rk33/rk3399_bl31_v1.30.elf file failed merge failed! [ error ] ERROR in function compile_uboot [ compilation.sh:216 ] [ error ] U-boot file not found [ trust.bin ] [ o.k. ] Process terminated which I don't have time to catch at the moment as I'm already (very) late for going to work
  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'll burn a M4 image with the default kernel to see if it's stable under high CPU and I/O load. @piter75 Do you have any link to share explaining all the components needed and where to get them, to build from scratch and burn the bootloader for arm rk3399 boards? I found so much information around but nothing clear and simple enough I could use
  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 would have to deepen armbian code or be given some hint where to start by somebody more experienced than me.
  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.
  16. pask

    M4 V2

    @pkfox Are you sure you inserted the emmc in the right way? The emmc socket is mechanically symmetrical, not electrically
  17. pask

    M4 V2

    @pkfox 1- be sure to connect the usb2ttl dongle to the NanoPi-M4v2 correctly: only rx tx and gnd have to be connected 2 - use "picocom --baud 1500000 /dev/ttyUSB0" to start the serial console (thanks to @martinayotte for recommending a good tool to use) 3 - boot from sd card while keeping the emmc card disconnected. During the boot process, keep a key pressed: the u-boot loader will stop just before launching the kernel 4 - carefully insert the emmc card (pay attention to connect it in the right way!) (thanks to @martinayotte for this smart&fast method) 5 - write command "boot" in the console. The kernel will boot, hopefully recognizing the emmc card and creating the proper device (in my case mmcblk2) 6 - sudo nand-sata-install to launch the armbian tool for transferring the sd content to the emmc card in the proper way. At the end of the transfer, DO NOT reboot, but exit to the console 7 - patch the new emmc install to replace the not-yet-working bootloader: sudo dd if=8M_after64ibs_uboot_working_rockpi4image_on_nanopim4v2.dd of=/dev/mmcblk2 seek=64 Enjoy your armbian running from the emmc card (tested on buster and the dev kernel)
  18. Perhaps the only serial terminal program I had not tried yet, It's the working one: I can confirm my dongle with the FTDI chip, works in linux too, at a rate of 1500000 baud using picocom. No special config needed. thank you
  19. The rubbish data you see, could depend by not optimal baud rate configuration, by the chip that your usb-ttl dongle mounts, and by kernel driver support of this chip. The nanopi m4 (v2) needs an odd baud rate setting: 1.500.000bps. In my case, a dongle using a FTDI FT232RL chip, I found that under linux by means of 115200 and 9600bps settings, I was able to see kernel output but not the uboot one. 1500000 didn't even work. Before giving up, I did a try under windows, where It actually worked as expected.
  20. I finally managed to get the official buster desktop image for the nanopi-m4 fully working on the version 2 of this board too. Basically, I extracted the working bootloader from the Armbian_5.99.191102_Rockpi-4b_Debian_buster_dev_5.3.0 image (which boots, but doesn't works well on the nanopi-m4 v2) and I burnt it to the https://dl.armbian.com/nanopim4/Debian_buster_default_desktop.7z image. This morning I did some initial tests and it seems that everything is working well. I have prepared a patched image you can try. At the moment, I've tested it only with an SD card, but I guess It'll work on the emmc too. Download it from https://drive.google.com/open?id=1LaJIywiZnZUkLDZ9HkWrRtc0PyfiYGOL You can also apply the patch by yourself: 1) download buster desktop image for nanoPi M4 (version 1) from Armbian's web site https://dl.armbian.com/nanopim4/Debian_buster_default_desktop.7z 2) extract and burn it to an SD card 3) apply the patch I have shared at the link above using the following command, changing sdX with the correct device: sudo dd if=8M_after64ibs_uboot_working_rockpi4image_on_nanopim4v2.dd of=/dev/sdX seek=64 Let me know if it works for you too.
  21. @NicoD I'm using Armbian_5.99.191102_Rockpi-4b_Debian_buster_dev_5.3.0-rc4_minimal.7z as suggested in a previous post by @martinayotte On top of it, I'm remotely running the mate desktop by means of tightvncserver. I'm quite impressed by the responsiveness of the desktop, considered that I'm still using the sd card, and accessing the mate desktop over the (wired) network. Things at the moment seem to work quite well, apart from the browsers, both chromium and firefox. Browsing is very slow and after few minutes the whole desktop gets stuck, forcing me to kill the vncserver. I hope I'll be able to do further tests this evening.
  22. @guidolOK thank you. It looks to me that the firmware gets loaded. But then something goes wrong [ 792.494106] brcmfmac: F1 signature read @0x18000000=0x17224356 [ 792.504431] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4356-sdio for chip BCM4356/2 [ 795.547138] brcmfmac: brcmf_sdio_readshared: invalid sdpcm_shared address 0xFE8B0174 [ 795.547142] brcmfmac: brcmf_sdio_readshared: unable to obtain sdpcm_shared info: rv=-22 (addr=0xfe8b0174)
  23. Hello @pkfox, at friendlyelec's nanopi-m4 product page https://www.friendlyarm.com/index.php?route=product/product&product_id=234 there is a very good description of the board's specs. From that page, you'll find that the wifi (and bluetooth) chip is the "big" one, just behind the antenna connector. Searching the web you'll find that this chip embeds a broadcom wifi plus a bt module. Sadly, this chip needs a firmware blob, which you can install following (for example) this very good explanation page: https://wiki.debian.org/brcm80211
  24. What I have discovered so far is that the wifi chip is a AMPAK AP6356s, which should embed a Broadcom BCM4356. I think first step do is to install firmware-brcm80211. Once done that, trying to modprobe brcmfmac seems that it recognizes the presence of the wifi chip, but can't use it: [12214.330077] brcmfmac: F1 signature read @0x18000000=0x17224356 [12214.339814] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4356-sdio for chip BCM4356/2 [12214.340677] brcmfmac mmc0:0001:1: Direct firmware load for brcm/brcmfmac4356-sdio.friendlyarm,nanopi-m4.txt failed with error -2 [12217.377735] brcmfmac: brcmf_sdio_readshared: invalid sdpcm_shared address 0xFE8B0174 [12217.377739] brcmfmac: brcmf_sdio_readshared: unable to obtain sdpcm_shared info: rv=-22 (addr=0xfe8b0174) An hint might be this post https://forum.khadas.com/t/brcm4356-and-mainline-linux-kernel/5281/2 By the way, I'm using an old Realtek usb wifi dongle, and It's working, so USB seems to work
  25. You were right twice: 1) the installed emmc module prevented the the nanopi-m4_v2 from booting using the the sd card. Once removed the emmc, rockpi4 image boots (but without the green led blinking) 2) with the dev kernel, the green led works too Tnx
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines