Jump to content

lanefu

Members
  • Posts

    1331
  • Joined

  • Last visited

Reputation Activity

  1. Like
    lanefu reacted to gprovost in Kobol Team is taking a short Break !   
    It’s been 3 months since we posted on our blog. While we have been pretty active on Armbian/Kobol forum for support and still working at improving the software support and stability, we have been developing in parallel the new iteration of Helios64 around the latest Rockchip SoC RK3568.
     
    However things haven’t been progressing as fast as we would have wished. Looking back, 2020 has been a very challenging year to deliver a new product and it took quite a toll on the small team we are. Our energy level is a bit low and we still haven’t really recovered. Now with electronic part prices surge and crazy lead time, it’s even harder to have business visibility in an already challenging market.
     
    In light of the above, we decided to go on a full break for the next 2 months, to recharge our battery away from Kobol and come back with a refocused strategy and pumped up energy.
     
    Until we are back, we hope you will understand that communication on the different channels (blog, wiki, forum, support email) will be kept to a minimum for the next 2 months.
     
    Thanks again all for your support.
  2. Like
    lanefu reacted to indianajones in Real time operating system   
    I was able to successfully build and run PREEMPT_RT with a current kernel running Ubuntu focal on a nanopineo, getting these results in cyclictest:
    sudo cyclictest --mlockall --smp --priority=80 --interval=200 --distance=0 # /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 1.41 1.40 1.11 1/154 3261 T: 0 ( 3242) P:80 I:200 C:4589037 Min: 18 Act: 30 Avg: 25 Max: 125 T: 1 ( 3243) P:80 I:200 C:4588573 Min: 17 Act: 23 Avg: 26 Max: 105 T: 2 ( 3244) P:80 I:200 C:4588088 Min: 18 Act: 32 Avg: 27 Max: 111 T: 3 ( 3245) P:80 I:200 C:4587408 Min: 18 Act: 30 Avg: 25 Max: 105  
    Steps to build your own:
     
    1. Build a normal armbian image, using current kernel and ubuntu focal for nanopineo (or your board), mostly to discover the full kernel version that gets built.  Note that, as is mentioned in this thread, the AllWinner-based boards do not get their code from the mainline Linux github repo, but rather from a forked repo at https://github.com/megous/linux/.  This repo is specified in ~/build/config/sources/families/include/sunxi_common.inc.  You do not need to make any changes to that file, I'm just noting it as an FYI.
    ./compile.sh BOARD=nanopineo BRANCH=current RELEASE=focal KERNEL_ONLY=no BUILD_MINIMAL=no BUILD_DESKTOP=no KERNEL_CONFIGURE=no AUFS=no  
    2. Check the kernel version from the build output.  Currently, that version is 5.10.21.  Download the PREEMPT_RT patch that most closely matches the kernel version.  NOTE: maybe you can download *any* RT patch file version that's at least the same or newer, but I went with the same because it makes sense to me:
    cd build/userpatches/kernel/sunxi-current # You'll probably have to mkdir the sunxi-current folder the first time wget https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt/5.10/older/patch-5.10.21-rt34.patch.gz gunzip patch-5.10.21-rt34.patch.gz  
    3.  Build another armbian image, this time with an extra parameter, EXTRAWIFI=no.  I've discovered that the patch-5.10.xx-rtYY.patch files somehow cause at least one of the Realtek Wifi drivers to throw a compiler error (in the rt_spinlock code).  If you need Realtek Wifi (and any other Wifi built by EXTRAWIFI=yes, you'll have to find another solution.  Sorry.
     
    Also, I now set KERNEL_CONFIGURE=yes because I think that it won't let  you choose "Full PREEMPT_RT" without you setting KERNEL_CONFIGURE=yes.  So when prompted during the build, choose option 4 (full PREEMPT):
    ./compile.sh BOARD=nanopineo BRANCH=current RELEASE=focal KERNEL_ONLY=no BUILD_MINIMAL=no BUILD_DESKTOP=no KERNEL_CONFIGURE=yes AUFS=no EXTRAWIFI=no  
    4. From there, just deploy the image like you do any other image.
    uname -a Linux nanopineo 5.10.21-rt34-sunxi #trunk SMP PREEMPT_RT Sun Apr 18 22:21:06 EDT 2021 armv7l armv7l armv7l GNU/Linux  
    Note that I also created a ~/build/userpatches/lib.config file that limited the CPU frequency to a paltry 480Mhz fixed value because I don't have a heat sink on the H3:
    GOVERNOR=performance CPUMIN=480000 CPUMAX=480000  
     
    Q: Is this possible with the legacy kernel?
    A: Probably, if you use EXTRAWIFI=no, but I haven't tested it.  Both legacy and current kernels had compiler failures for various reasons, but most frequently with RealTek.
     
    Q: Will this work for any AllWinner SoC?
    A: I'm pretty sure that any H2/H3 AllWinner will work, as they are the same chipset as the nanopineo I'm using.  I don't know about H5 or A-series.
     
    Q: I thought tparys told you that any version of PREEMPT_RT might not give you the determinism you need to read wiegand?
    A: Yes, and I still agree, but this was just bugging me that I couldn't successfully build one.
     
  3. Like
    lanefu reacted to William Bonnet in Improve autotests script   
    Hi Igor, i started to write such a tool for the same ûrpose as yours, it was a log time ago, for exactly the same target as yours (many things to talk;) )   it under Apache License and github, usung python and simple unit test. BTW i know verwell Ansible, and i'll be very happy to help you
     
    The tool is available under https://github.com/wbonnet/sbit
     
    It looks empty a first i need to push several things if you are interested, i will provide doc and some board auto test. The simpliest is maybe to start talkinng about it here or on IRC. deb packages are also availables online from the DFT project (githhub) also

    i'll look forward to you about this subject in the next days, i my have several other thing to share and contribute
    cheers William
  4. Like
    lanefu reacted to Igor in Improve autotests script   
    Wonderful news! I briefly checked your project and it seems to match our ideas on (unit) testing. I am Ansible newbie, know basics, while @lanefu (US) is more experienced in this and we should all come together on chat - we are hanging out here https://docs.armbian.com/Community_IRC/. Our most active hours starts from lunch break, when US people gets up and evenings, late night, CET.
     
    Thanks!
  5. Like
    lanefu got a reaction from malaga in collect data (temperature & humidity) from DHT22 into csv and sending them over the net   
    to @arox's point.. MQTT is a good fit for this.  

    Mosquito is easy to install.

    Here's an example of doing something similar.. with a different library

     
     
  6. Like
    lanefu reacted to indianajones in Real time operating system   
    NicoD, your YouTube videos are why I chose Armbian.  I think the Armbian tools are awesome, and I'm grateful to those who created and maintain it.
  7. Like
    lanefu reacted to tparys in Real time operating system   
    Are the existing real time classes in the CPU and I/O schedulers not enough in the standard kernel?
     
    Substantial portions of the RT patch set were merged back in kernel 2.6, and we're substantially past that point now.
  8. Like
    lanefu got a reaction from pfeerick in Unable to boot 'focal' or 'buster' images on SOPine Clusterboard   
    Any chance you can share the patched version of the dts.  Will make it easier to add it back into armbian build
  9. Like
    lanefu reacted to binarym in NanoPi R2S: lan0 goes offline with high traffic   
    Hi all !
     
    I faced the same issue with my Nano PI R2S : even with nightly builds, the r8152 randomly hanged and lan0 disappeared.
    I built a minimal armbian buster and revert the driver to previous 1.11 version.
    I also manually modified my /etc/udev/rules.d/70-rename-lan.rules with the following content:
     
    SUBSYSTEM=="net", ACTION=="add", DRIVERS=="rk_gmac-dwmac", KERNEL=="eth0", NAME="wan0" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="r8152", NAME="lan0", RUN+="/usr/sbin/ethtool -K lan0 tx off rx off"  
    It manages correctly my home fiber with ~600Mbps for DL and ~300Mbps for UL.
    Under heavy charge, i didn't experiment lan0 freeze for at least 1h (previously, it froze every 10 minutes).
     
    I guess 2.5Gbps support is lost but:
    For people with 1Gbps network, it's enought. I have serious doubt regarding the ability of R2S to route 2.5Gbps traffic ;-)  
    For people interested and who do not have time/skill/machine for compilation you can download the image here (~950MB uncompressed) : https://drive.google.com/file/d/1RRvmObBDi58TRTnZN661PL0PYFRbAi0_/view?usp=sharing
     
  10. Like
    lanefu reacted to kgblack in Differences Between Armbian and Debian   
    Here's a package comparison I did today of fresh installs (yesterday) of Armbian and Debian. Unfortunately, I forgot to do an update/upgrade of Armbian before listing the packages, so Armbian may appear to be slightly out of date compared to Debian, but the comparison took me too long to repeat it just for that update.
     
    comparison in pdf
    comparison in csv
     
    Here are the 28 Armbian packages I updated after the comparison:
     
    armbian-config armbian-firmware armbian-zsh avahi-autoipd base-files curl
      debian-archive-keyring groff-base iputils-arping iputils-ping libbsd0
      libcurl3-gnutls libcurl4 libnss-myhostname libpam-systemd
      libpython3.7-minimal libpython3.7-stdlib libssl-dev libssl1.1 libsystemd0
      libudev1 linux-libc-dev openssl python3.7 python3.7-minimal systemd
      systemd-sysv udev
     
  11. Like
    lanefu reacted to SteeMan in Make forum messages friendlier -- 2021 Edition!   
    Given the following comment posted in response to the new invalid message discussed above:
     
    "Hi Werner, I didn't realise I'd posted this as a bug I'll post it elsewhere"
     
    I took another look at the language in the big red warning message that is displayed for people posting new topics in the bug tracking forums.  While it would seem obvious to those of us on the inside what we are trying to communicate, to the novice user I think there is room to make it more clear.  To that end I have the following suggested wording changes:
     
    Current text:
     
    Wait!
    To avoid common mistakes when opening issues use this form to make sure you have collected all necessary information and create your issue report at the correct place:
    >> https://armbian.com/bugs <<
    Issue reports that are not following these guidelines will be removed without further notice!
     
    Suggested text:
     
    Important Please Read Before Posting a New Topic (Bug Report)!
     
    You are about to post a new topic in the Armbian Bug Tracker.  Armbian uses the sub-forums under "Bug tracker - supported boards and images only" as it's public facing bug reporting system. If you really intend to report a bug please fill out the following form to supply the necessary information for a valid bug report:
     
    >> https://armbian.com/bugs <<
     
    With limited resources the Armbian project is only able to spend time investigating bugs where all the requested information has been provided and for only the boards/images/software that are supported.  Your bug report will be considered invalid and receive no attention if you do not supply the requested information.
     
    If you only have a question or are looking for help on something in general related to Armbian, you should be submitting your question in one of the "Community forums", such as "Common issues / peer to peer technical support" or "General chit chat", not in this bug reporting forum.

  12. Like
    lanefu got a reaction from Werner in Forum Maintenance tonight. 2020-04-08 0200 GMT   
    maintenance complete
  13. Like
    lanefu reacted to NicoD in Video : Running Debian Buster on the Odroid Go Super and review of the hardware   
    Hi all.
    I recently bought the Odroid Go Super. It is a great handheld for emulation gaming. But that isn't the main reason why I bought it.
    It can also run Linux, tho not Armbian.
    In this video I show how I use Debian Buster from Meveric on the Odroid Go Super and I also review the hardware. Greetings.
     
  14. Like
    lanefu got a reaction from balbes150 in Armbian v21.05 (Jerboa) Release Thread   
    Congratulations!   Are you marrying S905X?    
  15. Like
    lanefu reacted to hexdump in Jetson Nano   
    just a little update: i got the open source nouveau gpu driver working with the mainline kernel finally by using a self compiled xorg server from the latest sources (required - see: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3505), a self compiled mesa 21.0.1 (not sure if this is really required) and the "nouveau.modeset=1" kernel cmdline parameter - what is nice is that it is opengl 4.3
     
    so far the good part, the bad part is that it is extremely slow (glmark2 score of 68) as it is clocked at the lowest gpu frequency by default and trying to increase the gpu frequency via /sys/kernel/debug/dri/128/pstate seems to make the system quite unstable or quickly hangs it (maybe my power supply - 5.1v/3a - is not powerful enough?)
     
    i'm also able to run a wayfire wayland session using the nouveau gpu driver, but it shows quite a few graphical artifacts when scrolling in a terminal or doing other activities - glmark2 score here is 83, but its also for lima or panfrost higher in wayland/wayfire than in xorg/xfce
     
    all in all it looks like the quality of the open source nouveau driver on the jetson nano (maybe even in general?) is not really the best and as it looks to me far behind the quality of the lima and panfrost open source drivers for the mali gpus in other socs
  16. Like
    lanefu got a reaction from guidol in Make forum messages friendlier -- 2021 Edition!   
    Per meeting, we're still trying to improve our responses to "unsupported' inquries.

    current thoughts
     
    * revise "invalid label"
    * focus on moving messages
  17. Like
    lanefu reacted to Palaretri in Can't see eMMC on BPI-P2   
    Hi all,
    I'm working with a BPI-P2 board.
    I installed the last Armbian version for BPI-M2 as the two boards are basically the same except the RJ45 connector and the eMMC.
     
    I installed it on an SD card, and everythig worked perfectly.
     
    Now I need to put the OS on the eMMC and then completely remove the SD card, but I'm struggling.
     
    The default Armbian for BPI-M2 is not intended to support eMMC, so I'm not surprised that with this version the eMMC dosn't show up.
     
    So I tried to modify the dtb and enable the eMMC nodes, and then reboot.
    Here the changes I made:
     
    mmc@1c10000 {
                reg = < 0x1c10000 0x1000 >;
                pinctrl-names = "default";
                pinctrl-0 = < 0x0d >;
                resets = < 0x03 0x08 >;
                reset-names = "ahb";
                interrupts = < 0x00 0x3d 0x04 >;
                status = "okay";
                #address-cells = < 0x01 >;
                #size-cells = < 0x00 >;
                compatible = "allwinner,sun7i-a20-mmc";
                clocks = < 0x03 0x17 0x03 0x4a 0x03 0x4c 0x03 0x4b >;
                clock-names = "ahb\0mmc\0output\0sample";
                vmmc-supply = < 0x0b >;
                vqmmc-supply = < 0x0b >;
                mmc-pwrseq = < 0x0e >;
                bus-width = < 0x04 >;
                non-removable;
                phandle = < 0x44 >;
     
                mmc2-8bit-pins {
                    pins = "PC5\0PC6\0PC8\0PC9\0PC10\0PC11\0PC12\0PC13\0PC14\0PC15\0PC16";
                    function = "mmc2";
                    drive-strength = < 0x1e >;
                    bias-pull-up;
                    allwinner,drive = < 0x03 >;
                    phandle = < 0x54 >;
                };
     
     
    Sadly this wasn't enought, and I still can't see the eMMC.
     
    I read a lot of threads, but I've not been able to find a solution.
    I guess that I have some problems with the uBoot or with the drivers not present in the kernel.
     
    I'm quite new to Linux, and I've never recompiled a kernel or a uBoot.
     
    Please, can someone help me?
     
    Thank you!
  18. Like
    lanefu reacted to zimme in Odroid C2 : no eth0 with latest image   
    I just wanted to write an update on this issue as I've ran into it also, but I figured out a way to make it work.

    My board was in a "broken" state where the network card wasn't working with any of the latest versions of Armbian using a newer u-boot like 21.04-rc3.
    I compiled my own versions to test the latest edge and using u-boot 21.04-rc4, etc. but nothing worked.

    I got it working by accident and I wasn't sure how but then I flashed the sdcard again with a different version and got into the broken state again.

    This lead me down an evening of frantically testing a bunch of things and that's when I discovered a way to get out of this broken state with a newer
    version of u-boot (21.04-rc or later).

    Grab the latest stable image which uses u-boot 21.04-rc3, flash it to an sdcard and boot the board and wait 5 min or something to make sure the board has actually booted (I'm running headless so no monitor connected).
    Once you're sure the board has booted, unplug the network cable and reconnect it. Then wait for a couple of minutes and then power cycle the board and that made the network card work again for me every time I
    got into this broken state.

    Hope it helps someone else and if not I guess that something else made my network card work again.
  19. Like
    lanefu reacted to vmiceli in Defaults for Ethernet coalesce?   
    Hello folks,
     
    I have completed my Armbian NTP server based on the wonderful little NanoPi Neo3. However something bothers me a bit, i.e. how much delay or latency is in eth0 (It is a 1Gbs port).
    By checking the default eth0 settings (ethtool -c eth0) I have the parameters below. In particular rx-usec = 327usec means that when a packet is received, the IRQ to alert the CPU can be delayed up to 327usec. With these settings on the nanopi (NTP server) I get about 1msec delay on the NTP client (Windows PC). By cutting the rx-usecs to 35 usecs I get a delay on the client of  about 450usec, so a massive improvement and 30% faster than rpi 4.
     
    At the moment, in order to change this parameter after boot, I have the two lines below into /etc/rc.local, the delay is needed as the command may be issued before eth0 is ready to accept it (I found this the hard way):
    sleep 10 sudo ethtool -C eth0 rx-usecs 35  
    The question: Is there a place where those eth0 defaults are saved? If there is a config file somewhere or even in the Kernel (I can re-build it) I could change them to a new default and avoid the rc.local hassle and delay.  I guess I like a leaner approach :-)
     
    Thanks!
     
    Enzo

     
     
    root@nanopineo3:~# ethtool -c eth0 Coalesce parameters for eth0: Adaptive RX: off TX: off stats-block-usecs: 0 sample-interval: 0 pkt-rate-low: 0 pkt-rate-high: 0 rx-usecs: 327 rx-frames: 0 rx-usecs-irq: 0 rx-frames-irq: 0 tx-usecs: 100 tx-frames: 25 tx-usecs-irq: 0 tx-frames-irq: 0  
  20. Like
    lanefu reacted to tparys in Avnet MicroZed   
    Foreward: Not sure if this better fits in board bring up, but I can't post there, so feel free to move if appropriate.
     
    I'm looking into the feasibility of using the Armbian build system to generate OS images for the Avnet MicroZed board. This board is based on the Xilinx Zynq 7000 platform, which is a SoC made up of a dual core 500 MHz CPU, and a Artix-7 generation FPGA. The CPU is nothing to write home about, but the FPGA opens up an interesting array of possibilities. Just in case you need an ARM board with 100+ GPIO, over two dozen serial ports, or your own function generator. Really, you're limited only by pin count, FPGA fabric usage, and what you can manage in Vivado. Xilinx also has an active presence on GitHub, and branches for kernels as new as 5.12, so sees active support.
     
    The big rub, is that the Zynq CPU boots off a VFAT partition, that contains a file named "boot.bin". This boot file combines the first stage bootloader (FSBL) and u-boot, and needs to execute a C application to assemble this file. The application is recently open sourced, and previously existing open source software also exists. But I'm not sure how best to integrate that with the build system, or identify that the platform u-boot package depends on this extra package.
  21. Like
    lanefu reacted to Igor in Avnet MicroZed   
    Would come handy sometimes. For the next version of our test gears perhaps.
     
    https://www.armbian.com/olimex-lime-2-emmc/
    160 
     

    FAT is not a problem. https://github.com/armbian/build/blob/master/config/boards/odroidc1.csc#L7-L8 Build system can support weird boot processes - this way:

    https://github.com/armbian/build/blob/master/config/sources/families/mvebu64.conf
    https://github.com/armbian/build/blob/master/config/sources/families/include/meson64_common.inc
     
  22. Like
    lanefu reacted to piter75 in Booting ROCK Pi 4(A/B/C) with mainline u-boot in SPI, NVMe and Armbian v20.11.x   
    I am not sure of that.
     
    My understanding is that we are still building release images from master branch and the removal of this line from targets.conf:
    -rockpi-4b legacy focal cli stable yes means that focal legacy image for rockpi-4b will not be built.
    Lack of focal legacy image among 20.02.3 release images (built after the referred commit was merged) seems to corroborate that theory ;-)
  23. Like
    lanefu reacted to Drakes in H6 Famous Reboot problem   
    Hi all, it's 2021 and this famous reset problem is still a problem with the Allwinner A64. I've made a long article about everything I tried to get a A64 reset to initiate, even low-level register writes, but I'd like to get another set of eyes on this. Maybe I'm missing something obvious?
  24. Like
    lanefu got a reaction from balbes150 in Armbian v21.05 (Jerboa) Release Thread   
    Hi! reminding everyone of meeting
     
     
  25. Like
    lanefu reacted to Salvador Liébana in 640x480 modeline doesnt work   
    many thanks for your time. it did not resolve the problem but it switched to modsetting
     
    Graphics:
      Device-1: display-subsystem driver: rockchip_drm v: N/A bus ID: N/A 
      Device-2: rk3399-dw-hdmi driver: dwhdmi_rockchip v: N/A bus ID: N/A 
      Device-3: rk3399-mali driver: panfrost v: kernel bus ID: N/A 
      Display: x11 server: X.Org 1.20.9 driver: modesetting 
      resolution: 1920x1080~60Hz 
      OpenGL: renderer: Mali T860 (Panfrost) 
      v: 3.1 Mesa 21.1.0-devel (git-befd9fb 2021-03-21 focal-oibaf-ppa) 
     
     
    what component of those it's the faulty or the one without this kind of support if you can guess?
    the thing is we run wine games... and they are very low res. 640x480 and 800x600 are quite common then and it doesnt work at all at those resolutions. 
     
     
    @Kwiboo do you know something about this?

     
     
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines