pask
-
Posts
29 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by pask
-
-
20 minutes ago, pkfox said:
Hi @pask are you saying I can flash the image you gave a link to and it will boot and wifi will work ? your original images were about 1gb and these are only 300mb ish is this correct ?
I you scroll down the page https://www.armbian.com/nanopi-m4-v2/
you'll find the fat desktop images too.
-
4 hours ago, pkfox said:
Hi Igor, I though I'd start from scratch, so , I flashed the image supplied by @pask , used the wi-fi drivers specified by @martinayotte, and applied the boot loader patch supplied by @pask. All booted fine with wi-fi working , so I attempted to install postgresql. And it worked perfectly, don't know why but I must have screwed something up before - good news is it works, bad news is I don't know why - thanks for your help.
@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.
-
On 11/28/2019 at 11:40 PM, piter75 said:
Took me some time to make the sound working in kernel 5.4.
Branch is now named nanopi-m4v2-bring-up and supports "legacy", "current" and "dev" targets.
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.
-
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.
-
12 hours ago, Enrico said:
Hello I am new here and from Germany,
.
I Need the nanopi as Server for IoBroker (NodeJS). no Desktop needed only minimal System
10 hours ago, Igor said:Wait until you don't read information about support here: https://docs.armbian.com/Release_Changelog/. You can also try to use unofficial test builds but I don't know if they work good enough to rely upon ...
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.
-
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.
-
15 hours ago, lburais said:
minimal and dev
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=no12 hours ago, piter75 said:@pask I have just booted default images (using SD), both minimal: http://ix.io/22yt and desktop: http://ix.io/22zD.
I have enabled verbose boot logging in the branch so maybe we can see where it hangs for you.
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 ... OKMine:
## 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 ... OKOn 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.
-
21 hours ago, piter75 said:
Sorry @pask
That's what happens when a prototype leaves factory without proper testing ;p
It is fixed now in the branch so please pull.
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
-
13 hours ago, piter75 said:
Would you find some time for building and running the Armbian image from my branch:
https://github.com/armbian/build/tree/nanopi-m4v2-u-boot-v2019.10-ddr-miniloader
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 terminatedwhich 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 terminatedwhich I don't have time to catch at the moment as I'm already (very) late for going to work
-
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
-
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
-
2 hours ago, sfx2000 said:
Can't speak for armbian - but there's no difference performance wise on target code between native vs. crossbuilds on GCC - at least not that I've seen.
Since the toolchains are already sorted out for Armbian - is it worth the effort to do a native toolchain? Might be, but someone would have to do that effort.
Openwrt does build native, BTW, but that's because someone did do the effort to make it happen - but again, I've not seen any difference in performance - I'd rather have a stable AMD64 that can build for any supported ARCH, and that problem is already solved.
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.
-
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.
-
37 minutes ago, pkfox said:
Hi Pask, yes definitely in the right way with the long part over the top of the HDMI socket
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.
-
2 hours ago, pkfox said:
Right finally I am getting somewhere thanks to yours and others help. I downloaded and compiled the latest version of picocom and was able to use the baudrate stated in pask's post. Powered up the board and no rubbish this time all plain English text. Hit any key and was rewarded with ( I presume ) the uboot prompt of =>. Inserted the eMMC card and entered "boot". Logged in all ok except there was still only one entry in /dev/ for mmcblk*. Tried again with another eMMC card but no good. I'm starting to think both my cards are f****d. But they can't be because I can dd images to both of them.
Are you sure you inserted the emmc in the right way?
The emmc socket is mechanically symmetrical, not electrically
-
10 hours ago, pkfox said:
As the other thread is getting a bit cluttered I thought I'd start a new one. Thanks to the good work of @pask and others we now have a working image for the M4 v2. However, despite following instructions to the letter. I can't get the board to boot from the eMMC card, in fact I don't think the board even recognizes the card ( I've tried different ones ) Also not being able to connect via a serial cable is hampering my attempts at debugging the boot process. Cany anyone put up a Muppets guide on the steps required to achieve this ?
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)
-
2 hours ago, martinayotte said:
I'm using latest "picocom" which is able to manage 1500000 baud under Linux without issues...
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
-
5 hours ago, pkfox said:
Hi Nico, my board (v2) boots this image fine from the SD card but not from eMMC - also I can't connect via UART ( just see rubbish on screen ) so have no idea why
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.
-
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=64Let me know if it works for you too.
-
2 hours ago, NicoD said:
Did anyone try a desktop? I had build a RockPi4b Bionic 5.3 desktop (with Panfrost) a while ago on the m4v2 and saw a few issues.
Couldn't load volume control, It crashed the desktop and all apps and reopened desktop. Some small weird things gave the same result. (decreasing font size of command taskbar app. Why/How???)
I thought it could be some panfrost issue.
I'm now working with another sbc, so not really time to test it, just wondered if anyone else had seen this. I was using the M4.dtb
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.
-
8 hours ago, guidol said:
also do
cp /lib/firmware/brcm/brcmfmac4356-sdio.txt /lib/firmware/brcm/ brcmfmac4356-sdio.friendlyarm,nanopi-m4.txt
then check if /lib/firmware/brcm/brcmfmac4356-sdio.bin would be loaded?
@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) -
4 hours ago, pkfox said:
Hi Pask, how did you discover what wifi chip is used ? and how do you install firmware-brcm80211 ? sorry for all the questions I'm really keen to understand how these boards work
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
-
4 hours ago, pkfox said:
I have some success - I flashed to the sdcard as you suggested - removed the eMMC card - and it booted - I then added fdtfile=rockchip/rk3399-nanopi-m4.dtb to to the /boot/armbianEnv.txt file and rebooted - voila we have the heartbeat green light. Thanks for all your help all I need now is wi-fi which I assume is going to be difficult ?
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
-
1 hour ago, martinayotte said:
This means it is not "dev" ...
Try this one instead : https://dl.armbian.com/rockpi-4b/nightly/Armbian_5.99.191102_Rockpi-4b_Debian_buster_dev_5.3.0-rc4_minimal.7z
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
Postgresql won't start
in Beginners
Posted
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.