emk2203
-
Posts
21 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by emk2203
-
-
-
What are the recommended steps to get the M1 boot from eMMC with the current standard Armbian image?
Just skip spi boot, write image to eMMC as usual and boot without a µSD card?
@usual userI would very much like to test your build and would also give feedback after.
I have just discovered the M1 and I think it is necessary to have as many options as possible. There may be interest from others who, like me, are late to the game, but for this we would need to be able to replicate your build. From what you write, it sounds very promising so far.
It would also open the door for more variety in the distributions offered.
-
OK, I solved the issue myself. Thanks to @Myron for his post, but it was much, much easier than that.
I leave this up so the next one who makes a fool out of himself does at least know why.
Solution: I used
xzcat img/Armbian_22.02.1_Orangepizero_jammy_current_5.15.25.img.xz | sudo dd of=/dev/mmcblk0p1 bs=2M status=progress; sync
to write the image. Out of habit, I used mmcblk0p1 instead of the correct mmcblk0.
This is able to run as shown by the working ping, but it obviously botches the initialization process enough to not start the SSH server. After rewriting the image with
xzcat img/Armbian_22.02.1_Orangepizero_jammy_current_5.15.25.img.xz | sudo dd of=/dev/mmcblk0 bs=2M status=progress; sync
everything works as expected.
I think it would be nice to have a command-line option in the manual, not just the reference to Balena Etcher or USBImager. With a command line, I wouldn't have had to resort to trial and error and choosing the wrong option (partition instead of full disk). I am not a fan of black-box programs like the above. If it's necessary to check the integrity of the written image, it's always possible to use
head -c $(stat -c '%s' armbian.img) /dev/mmcblk0 | sha1sum
or similar.
-
My OPi Zero is not accessible via SSH after installing the new supported image Armbian 22.02 Jammy.
After the install, the device is up and ping-able. Any attempt to SSH in with `ssh root@<ip-address>` ends in a `ssh: connect to host 192.168.88.9 port 22: Connection timed out` error. When I reboot the board and try again, it's still the same issue. A ping with `ping 192.168.88.9` works.
For completeness, I tried also with the edge instead of the current jammy image. Same error.
-
I have just installed the inofficial hirsute image on my HC-1 and updated everything to impish (still running the armbian-specific repo with the pointer to hirsute, though).
Happy to report that even with this heavy usage of upgrading, logging on and off numerous times, serving via minidlna and bubbleupnp server etc the machine is rock solid and seems to have no issues. Benchmark just went through, everything looks good.
So when you already have problems, sometimes it pays to go forward and not backward. The inofficial image isn't supported, but trying it doesn't hurt.
-
This error rears its ugly head again in Focal 20.04LTS with the OPi0.
Googling for results for this error (it's exactly the same) gives exactly one google result - this thread.
So, for anyone else stumbling over this, here the solution:
sudo apt purge command-not-found sudo apt --purge autoremove sudo bash -c 'apt update && apt full-upgrade && apt autoremove && apt clean'Unfortunately, a reinstall of the pkg 'command-not-found' brings back the same error.
This package is just for comfort. If you need suggestions for installing packages after entering nonexisting commands, just use another computer for reference. I advise to just leave it uninstalled for now.
-
@balbes150 Are you going to continue the disco variant? I noticed that 5.86 is only debian and bionic again. Very happy with disco on the Odroid N2 here, that's why I am asking.
The only thing I noticed: When trying to install lirc, I get a core dump, and the package remains half installed. Didn't have the time yet to further debug.
-
I am at a loss how to run this on a Odroid N2 with Linux installed. The instructions from the first post seem to assume you have Android.
Is it just putting the img on SD or eMMC and booting from there, like with a standard Armbian install?
-
23 hours ago, tkaiser said:
The sbc-bench -t and -T modes provide different results (and possible insights) since the purpose of this test is to use -T as first run to heat up the board to +70°C for sure, then with the -t 50 you allow the board to cool down to 50°C which means in this mode the thermal mass of the huge heatsink plays an important role. A normal sbc-bench run starts from low load to high load so the heatsink's temperature is constantly rising but always below the SoC temperature and the final temperatures will be lower compared to the situation when the heatsink is in fact hotter than the board when the 'sbc-bench -t 50' run starts.
Would be really interesting if you run with your setup 'sbc-bench.sh -T 70 ; sbc-bench.sh -t 50' as well.
Shows that you shouldn't trust unfounded assumptions. I thought gcc variation would account for 3 - 4% variation at most, but not the 22% I see.
I tried to run the setup you suggested; my SoC won't heat up beyond 69 °C. The temperature fluctuates between 67 and 69 °C, but never reaches 70 °C. Took it off the table and put it back in the box it came in, but this accounts only for 1 K difference. Your benchmark shows for a moment "Heating SoC from 70 °C to 70 °C", but nothing happens, and then the temperature drops again. So, would like to run the test, but cannot get it to work.
I had switched over to the development kernel 4.19rc1, since your table shows 4.17 as kernel version for tests, it should be even better comparable than the 4.4 version from the first test.
@Igor @hjc: With the Armbian Bionic image for download, I couldn't get wireless to work. armbian-config accepted my input for wireless up to the password, but after exiting and restarting, the NanoPi M4 didn't show up on the WLAN. I went to the nightly with the dev version of 4.19rc1. Files were needed from the full Armbian package, but even after switching to full firmware, I still get the error about `brcmfmac4356-sdio.txt` missing shown below. `brcmfmac4356-sdio.bin` is in the full firmware image, but was not in the "lite" firmware package which came with the downloaded Bionic image.
When I google the error, it seems that I need to copy NVRAM contents from the device to the txt file mentioned in the error message.
Any pointer on how to do this is welcome.
Worrisome things from `dmesg`, for zswap, I attached statistics also below:
zswap: default zpool zbud not available zswap: pool creation failed ... rockchip_mmc_get_phase: invalid clk rate ... dwc3 fe800000.dwc3: Failed to get clk 'ref': -2 dwc3 fe800000.dwc3: failed to initialize core ... brcmfmac mmc0:0001:1: Direct firmware load for brcm/brcmfmac4356-sdio.txt failed with error -2 sudo grep -R . /sys/kernel/debug/zswap [sudo] password for emk2203: /sys/kernel/debug/zswap/same_filled_pages:0 /sys/kernel/debug/zswap/stored_pages:0 /sys/kernel/debug/zswap/pool_total_size:0 /sys/kernel/debug/zswap/duplicate_entry:0 /sys/kernel/debug/zswap/written_back_pages:0 /sys/kernel/debug/zswap/reject_compress_poor:0 /sys/kernel/debug/zswap/reject_kmemcache_fail:0 /sys/kernel/debug/zswap/reject_alloc_fail:0 /sys/kernel/debug/zswap/reject_reclaim_fail:0 /sys/kernel/debug/zswap/pool_limit_hit:0 -
On 9/13/2018 at 10:20 AM, tkaiser said:
Test methodology is sbc-bench.sh -T 70 ; sbc-bench.sh -t 50 (reasons why). Full results: Thermal pad and copper shim
I am quite surprised about your results, my own ones with the standard
sudo /bin/bash bin/sbc-bench.sh -cshow significant differences to my NanoPi M4 (4GB). Yes, I have noticed the differences in compiler versions etc., but that you get 8.7 kH/s in CPUMiner and I get 10.6 kH/s is quite a difference - more than 22%. My system also has a copper shim (15x15x1.0mm) and reaches only 66.1 °C after cpuminer. The version is also 1.3.3, same as you used.
-
On 9/13/2018 at 11:05 AM, tkaiser said:
The problem is that 'true' USB-C chargers limit current to 500mA or 900mA if the other end of the USB-C cable is not able to negotiate the demand for higher currents. And those 5V SBC with USB-C right now (Vim2 and now also NanoPi M4) don't do this. They act in 'dumb' mode and require the PSU to provide 'current without asking' which standard compliants USB-C chargers will refuse. So you need a dumb or tolerant charger too.
I've measured booting current with my dumb PSU and this was reported as above 5.6W which would translate to +1100mA which is well above what a standards compliant USB-C charger is allowed to provide to a dumb device.
Yes, I hope this one does well. No chance to test yet since missing the needed adapter (also available in FriendlyELEC's online shop and also a recommendation for those affected then):
The official FriendlyELEC adapter is NOT needed if you have another type.
It is a BULL GN901-G plug converter, impressively built and worth the money, but you can use any other plug adapter as well. I am currently running the NanoPi M4 with an el cheapo adapter for 0.18€/piece, and it works well.*
*) PS: Please take note that these are actually illegal in the EU (and in Japan and most probably US), since they expose the hot plugs if you pull them out halfway. Do not use them with children around.
-
7 hours ago, tkaiser said:
Well, if Libre Computer is interested in getting Armbian on their boards at least some developers need samples. And wrt testing: It's a RK3399 thing so almost everything is already known.
Only interesting: how fast is memory access (are different DRAM initialization BLOBs used or not?), how fast is the eMMC and how well works heat dissipation. So iozone and sbc-bench and done.
To me Renegade Elite looks more like an ARM device for a couple of professional use cases (mainly dealing with cameras and imaging) running Android. But it seems enthousiasts are not scared away by costs and want to run Linux for whatever reasons...
Almost forgot: Of course compatibility testing with various USB-C PSUs might be interesting as well. @gounthar which USB-C chargers do you own? 'Good' ones from this list?
It wouldn't hurt to ask Libre Computer and point out that their not-so-successful campaign (around 68% of target reached) might have been successful if they would have broad and stable support from Armbian.
That was the main road block for me - the software. The fact that they promise mainline kernel, starting from 4.19, actually made me buy it. All ARM devices are sketchy in this regard. With mainline support, I can use the device as long as I like, without falling behind and stuck with old kernels.
-
On 9/9/2018 at 11:30 AM, gounthar said:
Still a few days to go, and there only one choice for eMMC, which is the 128GB.
They probably think that if you want it, you want the maximum amount. Quite similar to high-end phones now.
That said, I hope for Armbian support soon. I bit the bullet and bought one, maybe I sell my old Firefly RK3399 instead.
-
On 8/27/2018 at 6:07 PM, hjc said:
@tkaiser I've managed to boot 4.18 kernel on Firefly RK3399 (those problems on 4.17 seems gone), and ran sbc-bench after editing the dts in the same way (set trip point to 85℃, OC to 2.2/1.8GHz), results are here: http://ix.io/1lmN.
Any chance for you to share your kernel? My first attempt to compile a 4.19rc1 was unsuccessful. Or, let's say the compile went through, but I am still not sure what to put where afterwards. I would like to try with something known to work.
-
On 6/13/2018 at 1:02 PM, codnoscope said:
Have you tried the offical aluminium case for your firefly? There is a internal aluminium "piller" the push against the CPU so the entire case acts as a large heat sink.
For people reading this: Before you get your hopes up, the aluminum case is out of stock, and the Firefly sales rep told me in the chat that there probably won't be a second series. Demand was too low and price too high.
-
How do I get the nightlies? dl.armbian.com has no nightlies, and the info I googled was outdated.
-
Thanks for letting me know, I purged the contents of `/etc/resolvconf/resolv.conf.d/head` to get rid of the `nameserver 8.8.8.8` line. Otherwise, `systemd-resolved` would probably sneak it in again next time it has a chance.
I agree, leaving it in there at image creation time can create a lot of unnecessary confusion. As you said, user's local config should take preference, maybe with a commented line with Google's nameserver and the additional comment `# In case of DNS problems, try uncommenting this for debugging` or similar.
-
@tkaiser: Added the links to the post.
@guidol: Network is default Armbian configuration, didn't mess with it. DHCP comes from router, correctly configured, all other devices work well. PiHole resolves whatever I throw at it. One device with Debian 8.11 has only the information for the PiHole in `/etc/resolv.conf` (coming from the router DHCP) and works excellent.---
Actually, problem solved. I was used to not look at `/etc/resolv.conf` anymore because it's just a dummy file when `systemd-resolved` is used, but in the Armbian version, `/etc/resolv.conf` is a file with `nameserver 8.8.8.8` as the first line. Why is this in there? I use CloudFlare DNS(SEC), and not Google's servers. Definitely didn't enter this.
This is the contents of `/etc/resolv.conf` on my laptop, which I expected to be standard in Armbian as well.
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # 127.0.0.53 is the systemd-resolved stub resolver. # run "systemd-resolve --status" to see details about the actual nameservers. nameserver 127.0.0.53Instead, I had
nameserver 8.8.8.8 nameserver 127.0.0.53 search lan
with the first line now commented out, and now it works on the Armbian machines as well.
Maybe this is in there as an artifact from whatever, but it takes precedence over the `systemd-resolved` nameserver 127.0.0.53. If this a bug of the standard Armbian image?
Well, a lot of writing for nothing, but it helped me debug. Thanks to you all.
-
Setup:
I have a small home network with several SBCs, PCs, NASs and two devices are running Armbian ARMBIAN 5.59, ARMBIAN 5.59 stable Ubuntu 18.04.1 LTS 4.14.65-sunxi for the Orange Pi Zero and ARMBIAN 5.59 testing Ubuntu 18.04.1 LTS 4.14.65-sunxi for the Cubieboard 1. The OPi Zero runs the PiHole application for the whole network. There's a MikroTik router which does DHCP for the network.
Problem:
The Armbian devices are not able to do a local name resolution, a `ping router.lan` or `ping orangepizero.lan` or `ping cubieboard.lan` from either device gives the error: "Name or service not known". A ping by IP is without issues, same problem for services like SSH. All other devices, NAS with FreeNAS 11.2, a My Book Live with a custom Debian 8.11, Hardkernel XU4 and HC1 as well as all PCs with Linux or Windows are able to ping all local devices by name.
The Armbian devices have OK outside connectivity. `ping google.com` is giving the expected results.
Conclusions:
- The problem is restricted to the Armbian machines. PiHole might be the root cause, but all other machines are able to deal with this specific configuration, and both Armbian devices won't resolve local names.
Failed:
sudo dpkg-reconfigure resolvconf
didn't solve the problem. So far, I decided to post here to find a good way to debug this.
A `dig router.lan` (this is the router at 192.168.88.1) from my laptop:
; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> router.lan ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51279 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;router.lan. IN A ;; ANSWER SECTION: router.lan. 547794 IN A 192.168.88.1 ;; Query time: 3 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Fri Aug 24 15:12:14 CEST 2018 ;; MSG SIZE rcvd: 55
A `dig router.lan` from an Armbian device:
; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> router.lan ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 25576 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;router.lan. IN A ;; AUTHORITY SECTION: . 86395 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2018082400 1800 900 604800 86400 ;; Query time: 27 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Fri Aug 24 15:11:50 CEST 2018 ;; MSG SIZE rcvd: 114
I clearly see that the results are different, but don't know how to fix. What's the best approach here?
The results of `armbianmonitor -u` are at http://ix.io/1l7x for the Cubieboard and at http://ix.io/1l7y for the OPi Zero.
-
Thanks for supporting this old board! Just a couple of days ago, I found a Cubieboard 1 in one of my drawers and decided to use it for testing and benchmarking my old 2.5" drives.
While I downloaded and installed the old Xenial version, you put up a version for Bionic after all of these years.
Even though I have to reinstall it now, it's worth having up-to-date versions which I am used to work with.
One question: Why was NAND support dropped in modern kernels? Looking at some of the crufty old stuff still supported in the kernel, it doesn't make much sense to leave out this moderately useful feature.
Odroid M1
in Odroid M1
Posted
@rpardiniThis testing image looks super promising. Basically everything from my wish list satisfied:
Only missing thing for me would be this image based on an Ubuntu userland, but it's just habit. Bookworm is not lacking in comparison.
Going to test it out as soon as I can, but first I need to properly diagnose a Odroid HC4 HDMI bug for eventually RMA'ing the board.