lanefu

Administrators
  • Content Count

    744
  • Joined

  • Last visited


Reputation Activity

  1. Like
    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  
  2. Like
    lanefu reacted to austerus in Cloud-Init   
    Hello,
     
    I've fairly new to ArmBian and as I'm trying to setup a cluster of Rock64's, I'm wondering if there's any support for using cloud-init (user-data) to be able to setup a board on boot?
     
    Thanks!
  3. Like
    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
  4. Like
    lanefu reacted to andrw in 4k HDMI output   
    Some additional info:
     
    https://www.kernel.org/doc/html/latest/admin-guide/edid.html
     
    https://forum.pine64.org/showthread.php?tid=7935
     
    https://forums.gentoo.org/viewtopic-t-973418-start-0.html
     
  5. Like
    lanefu got a reaction from NicoD in 4k HDMI output   
    Thank you.. ticket created

    https://armbian.atlassian.net/browse/AR-354
  6. Like
    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?
  7. Like
    lanefu reacted to balbes150 in Armbian v20.08 (Caple) Planning Thread   
    Building a 6-hour kernel on an i7 is a new joke ?   
    rk3399 builds a complete Armbian image (along with the core and other packages) in 50 minutes. 
    Even the weak s905x2 collects the entire Armbian image in 200 minutes. 
  8. Like
    lanefu reacted to martinayotte in Armbian v20.08 (Caple) Planning Thread   
    2h00 PM GMT make it 10h00AM EDT for me, will be drinking my second coffee cup ...
  9. Like
    lanefu reacted to goathunter in pine64: massive date/time clock problem   
    Update: It's been a little over two weeks now, and all three of my Pines are running Ubuntu 20.04 LTS with the 5.4-43 kernel, and all have been running without problem.
  10. Like
    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  
  11. Like
    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...
  12. Like
    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:
     
    vo=x11
    autofit=720x320
    geometry=100%x100%
    video-aspect=72:32
    sws-scaler=fast-bilinear
    hwdec=vdpau
    hwdec-codecs=all
    fs=yes
    video-sync=audio
     
     
  13. Like
    lanefu reacted to tkaiser in Odroid N2 single CPU handling all the interrupts?   
    https://github.com/armbian/build/commit/1a04b50674626cf0165c84ef463c2b9e3df07061#commitcomment-40258499
  14. Like
    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.
  15. Like
    lanefu reacted to ingamedeo in A try on utilizing H6 PCIe with "Virtualization"   
    Confirmed working on Orange Pi 3 based on Allwinner H6, kernel 5.4.7 with pcie-wrapped. No particular changes needed apart from new dts.
    Link here: https://github.com/ingamedeo/orangepi3-h6-mainline
  16. Like
    lanefu got a reaction from gounthar in Orange pi 4   
    I've been trying rosetta on kernel 5.6 and 5.7 and it just seems like it overheats and drops dead pretty quick with rosetta.  showing those temps also   have you had much luck there?

    I'm cranking CPU max back now to try again.
  17. Like
    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 :/
     
     
     
  18. Like
    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?)
  19. Like
    lanefu reacted to Igor in Armbian 20.05.x   
  20. Like
    lanefu got a reaction from OrangePee in Need your help - what else beside Etcher   
    added annotation that it may container spyware
  21. Like
    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.
     
    Approved Tools:
    USBImager a lightweight cross-platform imaging tool Balena Etcher an electron / node.js based cross-platform imaging tool
  22. Like
    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

  23. Like
    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. ;-)
  24. Like
    lanefu got a reaction from Werner in THE testing thread   
    that's super awesome @Igor!
  25. Like
    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 ...