lanefu reacted to counterpoint in Armbian Buster problems with iptables and ipset
Thanks very much. Sorry for the slow response - I'm only allowed one post per 24 hours. I seem to have a solution. As mentioned above, I took the image from https://www.armbian.com/odroid-hc1/
To be more specific, I used the one with the large image at the right hand side of the page, just below the picture of an HC1. Looking more carefully, it uses kernel 4.14.y. Not being knowledgeable about kernel versions, I assumed that the highlighted image was the best to use. However, I later looked down the page, and tried using the download link https://dl.armbian.com/odroidxu4/Buster_current_minimal which uses kernel 5.4. Why would people prefer an old kernel? Anyway, everything seems to work as I would expect with no need for selecting legacy elements or anything unusual.
With the other image, I was not able to find a package called iptables-legacy, only one called iptables. Reinstalling it and rebooting didn't make a difference.
In case they are still of interest, the answers to your questions are:
root@backup:~# find /lib/modules/|fgrep -i tables /lib/modules/4.14.187-odroidxu4/kernel/net/ipv6/netfilter/nf_tables_ipv6.ko /lib/modules/4.14.187-odroidxu4/kernel/net/ipv6/netfilter/ip6_tables.ko /lib/modules/4.14.187-odroidxu4/kernel/net/ipv4/netfilter/nf_tables_ipv4.ko /lib/modules/4.14.187-odroidxu4/kernel/net/ipv4/netfilter/ip_tables.ko /lib/modules/4.14.187-odroidxu4/kernel/net/ipv4/netfilter/arp_tables.ko /lib/modules/4.14.187-odroidxu4/kernel/net/ipv4/netfilter/nf_tables_arp.ko /lib/modules/4.14.187-odroidxu4/kernel/net/netfilter/nf_tables_netdev.ko /lib/modules/4.14.187-odroidxu4/kernel/net/netfilter/nf_tables.ko /lib/modules/4.14.187-odroidxu4/kernel/net/netfilter/nf_tables_inet.ko /lib/modules/4.14.187-odroidxu4/kernel/net/bridge/netfilter/ebtables.ko /lib/modules/4.14.187-odroidxu4/kernel/net/bridge/netfilter/nf_tables_bridge.ko root@backup:~# armbianmonitor -u System diagnosis information will now be uploaded to http://ix.io/2rqQ
lanefu reacted to dolphs in Allwinner H5 phased out?
@sfx2000 @Kevin Sewell @guidol @5kft- Looks like NEO3 entered the arena with rk3328 chipset guess this will be adapted shortly by armbian in this section.
I believe in theory this board could run on 1,4Ghz just like the NEO2 Black does, for now I skip this one
lanefu reacted to andrw in 4k HDMI output
Is there any thread of feature requests specific for RK3399? Or should I go to feature requests forum?
Connecting 1920*1200 display to rockpro64 by hdmi->dvi cable and can't get native resolution by any way. Seems like EDID is not read and kernel config DRM_LOAD_EDID_FIRMWARE is not set.
This board is my only PC for now, is it possible to enable this kernel option in armbian images?
lanefu reacted to sgjava in Java Periphery released!
Java Periphery has finally been released! Java Periphery is a high performance library for GPIO, LED, PWM, SPI, I2C, MMIO and Serial peripheral I/O interface access in userspace Linux. This will replace User Space IO. I'm seeing GPIO write speeds of 500K/s from userspace. Compared to User Space IO and libgopid speeds of 2K/s. I switched from JNA wrapper generation to JNI wrapper generation. The build process is much simpler (only single install.sh) and building libgpiod is no longer required. The API follows c-periphery, python-periphery and lua-periphery. This should cover the widest array of SBCs and languages around.
Java Periphery should work on Armbian/Ubuntu/Debian, but also other non-Armbian distributions. If you run into issues please use Github issues to report.
Nano Pi Duo
13:30:43.065 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running write test with 10000000 samples 13:31:23.062 [main] INFO com.codeferm.periphery.demo.GpioPerf - 500613.25 writes per second 13:31:23.065 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running read test with 10000000 samples 13:31:54.471 [main] INFO com.codeferm.periphery.demo.GpioPerf - 318440.91 reads per second Nano Pi Neo Plus 2
15:06:51.946 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running write test with 10000000 samples 15:07:22.522 [main] INFO com.codeferm.periphery.demo.GpioPerf - 654964.63 writes per second 15:07:22.524 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running read test with 10000000 samples 15:07:46.696 [main] INFO com.codeferm.periphery.demo.GpioPerf - 413770.27 reads per second
lanefu reacted to sfx2000 in Allwinner H5 phased out?
Allwinner will continue to make chips of any variant as long as there is a minimum order quantity (MOQ) commitment upfront with cash to spin up the fab...
Might take a volume commitment - they will definitely make that happen, if the volume is enough to be profitable...
Olimex went thru this exercise with the Allwinner T2/A20 chip...
Just takes the money to make it happen...
lanefu reacted to yam1 in Triple screen works fine under Focal
Picture from Neo Core with 3 ili9341 2.8 screens running at 48 mhz (horizontal splits seems to work better than vertical splits), with mpv playback configuration:
lanefu reacted to Heisath in Espressonbin 2.5Gbps, anyone?
The information you linked indicating there is 2.5Gbps mode is always only for the chip (Armada 3700) used on the espressobin. This Marvell chip does have the 2.5Gbps interface. That is also the reason it is explained on Marvell github.
The espressobin itself has all 3 ethernet ports wired through one switch with only RGMII going in. As can be seen here: http://wiki.espressobin.net/tiki-index.php?page=Block+diagram
As only one RGMII is feeding all 3 ports I dont think 2.5Gbps will be possible on any of them.
lanefu reacted to gprovost in Helios4 Support
Not sure which country you are but on amazon you can find the following good replacement : https://www.amazon.com/dp/B07NCG1P8X
You might have to look for the same product ref. on the correct market place according to your country.
While for sure our bandwidth is more focus on Helios64, we are still supporting Helios4, and no plan to change that ;-)
For instance latest Armbian 20.05 Kagu still actively includes Helios4. Ok we will still need to put a post on our blog about that and link the image in our wiki :/
lanefu reacted to Icenowy in A try on utilizing H6 PCIe with "Virtualization"
As we know, the PCIe on H6 is buggy, which doesn't offer linear address, and Linux cannot support such kind of configuration.
However, the Cortex-A53 cores used by H6 supports virtualization, which can be used to change the order of the address space.
Recently, I tried to make use of virtualization to provide linear mapping of PCIe, and I succeed in making an Intel 6205 wireless card working.
The hypervisor code is at https://github.com/Icenowy/aw-el2-barebone . It's intended to start before U-Boot, and located at 0x40010000.
A U-Boot fork that is patched to load the hypervisor is at https://github.com/Icenowy/u-boot/tree/h6-load-hyp , and a kernel that utilizes the wrapped PCIe (and patched to reserve memory for the hypervisor) is at https://github.com/Icenowy/linux/tree/h6-pcie-wrapped .
In order to let the hypervisor start before U-Boot, BL31 needs to be built with `PRELOADED_BL33_BASE=0x40010000` in make parameter -- this will change the EL2 entrypoint to the hypervisor. Mainline ATF from ARM works.
Contributions to the hypervisor is welcomed.
(In addition, abusing virtualization in such way will prevent us from using KVM. But I think more people will want PCIe instead of KVM, right?)
lanefu got a reaction from Tido in Need your help - what else beside Etcher
I've updated our canned response to below.... I saw no need to revoke Etcher's status.. as it is easier to install, but I updated it's description to be more....accurate
Armbian's archives can be uncompressed with 7-Zip on Windows, Keka on OS X and 7z on Linux.
Images shall only be written with imaging tools that validate burning results. This saves you from corrupted SD card contents.
USBImager a lightweight cross-platform imaging tool Balena Etcher an electron / node.js based cross-platform imaging tool
lanefu reacted to TonyMac32 in Armbian v20.05 (Kagu) Planning Thread
I don't see any reason not to, the patchset is a lot of backported stuff anyway.
I have a cranky Asus board here that kernel panics on boot with our 4.4 (sounds familiar), I might scab the device tree into something mainline likes and skip legacy for the moment.
@Lanefu, we need to make sure the big patch isn't "undoing" any of the other patches, I got most of it cleaned up, but not all.
Sent from my Pixel using Tapatalk
lanefu reacted to barish in Espressobin support development efforts
Despite of all the seemingly bad news, I boldly ordered a batch of 10 EspressoBin V7 recently. Globalscale promised to test them for me for stability (I am not interested in squeezing out the last bit of performance), and I tested them again after reception: They all seem to run stable with Ubuntu Xenial (the "newest" image provided by Globalscale) and with Armbian kernel 4.19.59-mvebu64.
Since there is still a few weeks till they go on duty, if anyone is interested in a particular test on them, I am willing to do so. I am not into kernel development, so I would need some instruction. ;-)
lanefu reacted to Igor in THE testing thread
One test board from this topic will be installed at this location and another at my desk and elsewhere. We will try to join them.
After test boards come, some more coding has to be done. Also to have better overview over the test process. Currenlty test results looks like this: https://dl.armbian.com/_test-reports/2020-05-03_15.57.22.html Its still more or less a data collection without any proper analysis ...