lanefu

Moderators
  • Content count

    221
  • Joined

  • Last visited


Reputation Activity

  1. lanefu liked a post in a topic by TonyMac32 in Bordsupport - general discussion / project aims   
    A20:
    @Igor
    - legacy kernels should go out due too overall bad kernel quality
    - reboot/poweroff problems on some boards
     
    H3:
    @chwe
    - CSI (camera) doesn't work on mainline, gc2035 needs an small script in legacy to start up properly
    -
    Armlogic:
    @TonyMac32
    - Mainline support effort is still relatively new.  Things like USB, audio, etc are WIP.
    - "Legacy" kernel that is stable is old and EOL (3.14) and I haven't fooled with it.  In that world and all others Amlogic, @balbes150 is the master.
    - Newer legacy kernel is still a work in progress (4.9 w/bugs)
    - u-boot blobs are lame and make using mainline u-boot difficult (need both legacy 2015 and mainline u-boot to get a working image)
    - Lower quality of open source information, all more or less community driven by a very small group, unlike with say Rockchip with a large amount of published info from Rockchip themselves.  Rumor/commits say this may change with newer IoT processors.
     
    Freescale:
    @Igor
    - the legacy kernel is getting obsolete. No point to have it.
    - possible to implement hw video acceleration on mainline kernel
    - Solidrun has new 4.9 kernel, but can be safely ditched for mainline
     
    Rockchip (I suggest only the one we support at the moment, not RK3399):
    @chwe
    - CSI (tinkerboard, rk3288) is supported (RK 4.4 bsp kernel) by kernel (OV6547 OV5640, imx219 - RPI-cam V1.3 resp. V2) but doesn't show up properly when booting)
    @TonyMac32
    - Igor and tkaiser are already seeing this, but mkimage/uboot/trust can be finicky.  luckily that's  a "figure it out and move on" situation, but it is likely to cause headaches.
    - 4.4 kernel is an increasingly old kernel, now 2 LTS's in the past, however still much better than a lot of others (also has a lot of activity)
    - RKwifi is something I don't know the reason for.  I don't know why it exists, I don't know what it does (other than cause problems).  It is a wrapper for some wifi drivers/an rfkill system
    - Rockchip likes to use their own subsystems in many things, like the "MPP" system for media playing.  This has different capabilities per SoC, so may not behave predictably to simply be able to say we know how to use it.
     
     Marvell ARMADA:
    @Igor
    - missing SFP support in mainline
     
    Armbian related scripts:
    @chwe
    - h3consumption is legacy only
    -
     
     
  2. lanefu liked a post in a topic by chwe in Bordsupport - general discussion / project aims   
    Let's try it with an example and lock what happens/if it works...   Such a 'project manager' needs a background in the topic otherwise it's similar to marketing monkey writes product description for *random device*. I suggest we take @zador.blood.stained proposal as a test:
    Is it possible to write a proposal what should be done out of it?
     
     
    IMHO, it can't be a goal that you have to test all images on your own, otherwise armbian has to reduce the supported boards to much less boards. If you look into DL statistic, there are enough people downloading our images, there must be some interest from the community to report bugs (update or fresh download). Can we start with a 'testgroup lite'? IMHO most important (cause most annoying) is to avoid that the device is not bootable after update. As long as you have SSH access via ETH to the device, broken things can be fixed or at least, a backup of the data can made (I agree you should backup your system before the update - but to be honest, we have to accept that people don't do it). To avoid flooding the forum with a lot of junk from the testers group a small webservice might help:
    With a clear statement that we don't suggest that you're test without having a serial console at hand (seems that a lot of user don't think it is necessary to have a usb serial device at home when playing with SBCs - maybe we should 'educate' our 'customers' also in this field....  ). 
     
    Is it possible to have a 'board specific' update mechanism? E.g apt-update/upgrade only updates kernel/u-boot only if it's somehow on a 'positive list'? 
     
    Internet of shitty Things is the 'new' buzzword...  Since people like @Larry Bank and @sgjava strongly push the GPIO issue, we might have a good solution in 2018.  To avoid  more load for the maintainers and keep Armbian as general as possible, I suggest to solve it similar to the OMV project. Means that we can provide a post installation script for a 'ArmbianIoT' but IMO we should avoid providing it in 'standard Armbian'.
     
    A few questions:
    Do we have a nightly desktop policy? Why do we provide desktop in nightly images? Does it make sense to provide such images as long as we can't provide 'basic stability'?
  3. lanefu liked a post in a topic by Igor in armbian for N-1 odroid   
    https://github.com/armbian/build/commit/f6402803c261b7a683eeb091f62a684bfd1ef8e8
    https://github.com/armbian/build/commit/518ef98107a6705ba6649acdb1481cafedc9766d

    Software support is not fast food.
  4. lanefu liked a post in a topic by sgjava in User Space IO is Python 3 and Java 8 bindings for user space GPIO, SPI, I2C and Serial interfaces   
    https://github.com/sgjava/userspaceio
     
    After a lot of work and testing I have produced the User Space IO project! It provides Python 3 and Java 8 bindings for Linux user space GPIO, SPI, I2C and Serial interfaces. This allows cross SBC and cross language development using a common API. I took two best of breed C APIs for Linux user space libgpiod and c-periphery and produced CFFI bindings for Python and JNA bindings for Java. Since all the bindings closely match the C API it's easy to move from language to language. The side effect of using the Java library is that it should work with many different JVM based languages. How about creating your programs in Kotlin or Scala for instance?
     
    GPIO access uses the new gpiod interface and not the deprecated sysfs interface using libgpiod v1.1 (head from git repo). GPIO, SPI, I2C and serial interfaces expose all the low level functionality. I have added some helper methods for handling repetitive functions like building I2C messages, reading words from two registers, etc. You can of course go as low level as you need to. Please use Github to post any issues, pull requests, etc. I have tested Nano Pi Duo for 32 bit and NanoPi Neo +2 for 64 bit compatibility. I'll test more SBCs as I have time. Also, I have deleted https://github.com/sgjava/libgpiod-extra since User Space IO supersedes it.
     
    Based of some of the questions I had in the past please note the following:
    gpiod_ctxless_event_loop_multiple can handle GPIO interrupts Miscellaneous GPIO request flags GPIOD_LINE_REQUEST_FLAG_OPEN_DRAIN, GPIOD_LINE_REQUEST_FLAG_OPEN_SOURCE, GPIOD_LINE_REQUEST_FLAG_ACTIVE_LOW Non-root access using rc.local.
  5. lanefu liked a post in a topic by jernej in H3/H5/A64 DRM display driver   
    Today A83T HDMI driver was merged Now to the H3/H5 driver, which should be more straightforward for mainlining. Seems like with 4.17 there will be no need for DRM patches, except maybe for A64 (depends when Icenowy can get DE2 clocks & SRAM patches merged).
  6. lanefu liked a post in a topic by Petrunin Alex in FFmpeg with Cedrus H264 HW Encoder (H3 - CMOS Camera)   
    Hi all, for today this work ok on H3 (recording from webcam here)
     
    git clone https://github.com/stulluk/FFmpeg-Cedrus.git
    git clone https://github.com/uboborov/ffmpeg_h264_H3.git
    cp /root/ffmpeg_h264_H3/cedrus264.c /root/FFmpeg-Cedrus/libavcodec/cedrus264.c
    cp -R /root/ffmpeg_h264_H3/sunxi /root/FFmpeg-Cedrus/libavcodec/arm
    apt-get install libpulse-dev libv4l-dev libmp3lame-dev libx264-dev
    cd FFmpeg-Cedrus
    ./configure --prefix=/usr --enable-nonfree --enable-gpl --enable-version3 --enable-vdpau --enable-libx264 --enable-libmp3lame --enable-libpulse --enable-libv4l2 
    make -j 4
    make install
    ffmpeg -version
    ffmpeg -h encoder=cedrus264
    ffmpeg -f v4l2 -video_size 1280x720 -i /dev/video0 -pix_fmt nv12 -r 25 -c:v cedrus264 -vewait 5 -qp 30 -t 60 -f mp4 test.mp4 -y
    ====
    And you can use software-encoder, it work better then you expect. Example for slow CPU and bitrate limits
     ffmpeg -f v4l2 -video_size 1280x720 -i /dev/video0 -pix_fmt nv12 -r 25 -c:v libx264 -b:v 4M -maxrate 4M -bufsize 1M -preset ultrafast -t 60  -f mp4 test.mp4 -y
     
     
  7. lanefu liked a post in a topic by Michael Dehn Klit in Orange Pi R1   
    If anybody missed it, there is an openwrt image now.
     
    https://openwrt.org/toh/hwdata/xunlong/xunlong_orange_pi_r1



     
  8. lanefu liked a post in a topic by sgjava in Using Python, CFFI and libgpiod for cross SBC GPIO access   
    On my journey to finding the best solution for cross SBC/cross language GPIO support I went through the same issues as Python by the C side author did it seems and landed on CFFI. This is faster than ctypes and seem more natural to program with. ctypesgen (the code generator) doen't really support Python 3, so I've hit a dead end there. It seems like JNA is still the best choice for Java bindings, so I'm sticking with that for now. In any event I threw together a button press app that uses CFFI and libgrpiod. I'll be updating my bindings project to support this soon.
     
    libgpiod version 1.1.devel
    Name: gpiochip1, label: 1f02c00.pinctrl, lines: 32
    Press button within 5 seconds
    Falling edge timestamp 02/10/2018 19:49:05
    """ Test blocking event using built in button ------------- Should work on any board with a button built in. Just change chip and line value as needed. """ import sys, time from argparse import * from cffi import FFI parser = ArgumentParser() parser.add_argument("--chip", help="GPIO chip number (default 1 '/dev/gpiochip1')", type=int, default=1) parser.add_argument("--line", help="GPIO line number (default 3 button on NanoPi Duo)", type=int, default=3) args = parser.parse_args() ffi = FFI() # Specify each C function, struct and constant you want a Python binding for # Copy-n-paste with minor edits ffi.cdef(""" enum { GPIOD_LINE_EVENT_RISING_EDGE, GPIOD_LINE_EVENT_FALLING_EDGE, }; struct timespec { long tv_sec; long tv_nsec; }; struct gpiod_line { unsigned int offset; int direction; int active_state; bool used; bool open_source; bool open_drain; int state; bool up_to_date; struct gpiod_chip *chip; int fd; char name[32]; char consumer[32]; }; struct gpiod_chip { struct gpiod_line **lines; unsigned int num_lines; int fd; char name[32]; char label[32]; }; struct gpiod_line_event { struct timespec ts; int event_type; }; const char *gpiod_version_string(void); struct gpiod_chip *gpiod_chip_open_by_number(unsigned int num); struct gpiod_line *gpiod_chip_get_line(struct gpiod_chip *chip, unsigned int offset); int gpiod_line_request_falling_edge_events(struct gpiod_line *line, const char *consumer); int gpiod_line_event_wait(struct gpiod_line *line, const struct timespec *timeout); int gpiod_line_event_read(struct gpiod_line *line, struct gpiod_line_event *event); void gpiod_line_release(struct gpiod_line *line); void gpiod_chip_close(struct gpiod_chip *chip); """) lib = ffi.dlopen("libgpiod.so") print "libgpiod version %s" % ffi.string(lib.gpiod_version_string()) gpiod_chip = lib.gpiod_chip_open_by_number(args.chip) # Make sure GPIO chip opened if gpiod_chip != ffi.NULL: print("Name: %s, label: %s, lines: %d" % (ffi.string(gpiod_chip.name), ffi.string(gpiod_chip.label), gpiod_chip.num_lines)) gpiod_line = lib.gpiod_chip_get_line(gpiod_chip, args.line) # Verify we have line if gpiod_line != ffi.NULL: consumer = sys.argv[0][:-3] if lib.gpiod_line_request_falling_edge_events(gpiod_line, consumer) == 0: timespec = ffi.new("struct timespec*") timespec.tv_sec = 5 print("Press button within 5 seconds") rc = lib.gpiod_line_event_wait(gpiod_line, timespec) if rc == 0: print("Timed out") elif rc == 1: event = ffi.new("struct gpiod_line_event*") # Read event off queue lib.gpiod_line_event_read(gpiod_line, event) if event.event_type == lib.GPIOD_LINE_EVENT_RISING_EDGE: print("Rising edge timestamp %s" % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(event.ts.tv_sec))) else: print("Falling edge timestamp %s" % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(event.ts.tv_sec))) else: print("Unable request falling edge for line %d" % args.line) lib.gpiod_line_release(gpiod_line) else: print("Unable to get line %d" % args.line) lib.gpiod_chip_close(gpiod_chip) else: print("Unable to open chip %d" % args.chip)  
  9. lanefu liked a post in a topic by chwe in Orange Pi One Plus   
    Hoped to find something like voltage monitoring (on input) but as far as I understand the manual of the AXP805, there is no such possibility.   Would it make a goods beginners board (as soon as kernel is 'in a good shape') cause it would avoid 'powering gone wrong'...   - anyway, every barrel plug powered board is a bit more beginners friendly..
    I don't follow sunxi mailing list fully (mostly cause I wouldn't understand most of the things discussed there.. ), but as I saw for the A64s PMIC was a bit problematic (handled by AR100, whereas complier for it is not GPL). As I understand, this issue was solved with those commits. Is the H6 also affected by such problems? (Allwinner had PMIC since a long time on the AR100 but it was possible to avoid using it). 
    More experienced users have to decide if it's worth to use this kernel... But nice to see that allwinner publishes this stuff faster than in the past.  btw. for those interested in it: https://github.com/Allwinner-Homlet?tab=repositories there you go.  
  10. lanefu liked a post in a topic by James Kingdon in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    My OPi one+ arrived. I burned the ubuntu image with etcher and it worked fine. I had to manually resize the fs but you expect a few rough edges with a new board.
     
    The bare board runs on the hot side, idling at a reported (but unconfirmed) 48C. Benchmarks quickly push it into throttling at 70C, but even so it is faster (just) than any of my other 4 core boards. I'll add a heatsink and fan and see if I can get the temps under control. If so, and if the board remains reliable it seems like excellent value for money. The H6 looks very promising.
  11. lanefu liked a post in a topic by zador.blood.stained in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    ... or not. Merged here and renamed this thread to include "Orange Pi One Plus" in the title.
  12. lanefu liked a post in a topic by Icenowy in Orange Pi One Plus   
    A 4.9 kernel is released by Allwinner yesterday (as UTC+8).
     
    P.S. AXP805 has only power key (for power down functionality) and DCDC+LDO, like RK805 from RK(used with RK3328, also OTT):-)
  13. lanefu liked a post in a topic by TonyMac32 in RK3399 Orange Pi   
    Gaze longingly at it's many ports and connectors.
  14. manuti liked a post in a topic by lanefu in Docker baseimage for armbian   
    search the docker registry for armhf   then youll find ubuntu and alpine containers to base your builds on.     ioft/armhf-ubuntu:xenial  is one i use a lot
  15. Naguissa liked a post in a topic by lanefu in Meltdown and Spectre   
     
    Frustrated yes, but also a positive step forward.    Sometimes the FUD for stuff like this scares organizations to patch.    I've been trying to get the blessing to do bulk patching for 2 years and finally my company is ready to do it!.
  16. lanefu liked a post in a topic by botfap in Meltdown and Spectre   
    Big digression but:
     
    In regards to @tkaiser negative and pessimistic suggestions to keep dropping board support for problem boards,  I think he is absolutely correct.
     
    While Im not a big Armbian user (we have our own linux based OS stack that we created from scratch and an ubuntu 16.04 derivative we tailored), I do follow its progress quite closely and its clear that there isnt enough engineering resource to support the list of boards that you try to support. Thats not a criticism, its just the reality of any open project. Once you have a board up and running, even at just 25% of completion, every TV Box shitter and their dog wants it all working, right now, on mainline, with 8K support, running from a nokia 3210 charger, etc, etc.
     
    There seems to be enough engineering resource to support about 10 major boards with minor variations. To my mind it would make much more sense and make Armbian a much more valuable project to support less boards to a higher level and to have fully standardised functionality across all "officially" supported boards. Officially supported boards get support for 3/4/5 years or whatever. You dont even try to support a board unless every critical dev on the project has at least one of them.
     
    By standardised Armbian functionality, I mean things like:
    standard Armbian GPIO (+i2c, spi, 1wire, etc) library (@Larry Bank already made a good start here) standard RTC interface, utils and device (we only support 3 RTC drivers) standard NAND interface, layout, device standard GSM interface, utils and device (we only support 5 drivers) standard and predictable network interface naming, handling and utils standard hardware / psu stress test standard sound and video in / out / process utils (standard interface is pretty difficult here I accept) standard remote access interface for cloud control standard config utility standard base OS. pick debian 9 or ubuntu 18.04 for future dev, stop trying to support both (my personal preference is debian but there are good commercial reasons to stick with ubuntu LTS) limited SD card support. dont support any re-badgers (Kingston, entry level sandisk, toshiba, etc ). we only use sandisk extreme plus and sandisk high endurance and have a failure rate of approx 2 in 1000  
    That doesn't mean you cant have another 15 "community" supported boards, but with those there is no promise of full functionality and no official support offered. Those boards need to have community champions (individuals that want to help support specific boards, probably because they have them at home) and automated builds of community supported boards, its just means they dont get factored into long term development planning, support and testing.
     
    What would you rather see from Armbian?
    1) 30+ boards with levels of completion from 20%-95% and different functionality on each (think GPIO, NAND, RTC, GSM, etc)
    2) 10 boards with 90%+ level completion and with standardised Armbian specific functionality across all of them? With 20 more community supported unofficial boards. 
     
    Once you have structure 2 in place then you also have the correct structure to start making money from commercial support offerings. Think Armbian Gold / Pro whatever where you sell commercial support delivered via a cloud interface where the customers can manage all their devices (1-1M) from a web browser. This is what we do.
     
    Controversial suggestion but you should support at least 1 variant of the RasPi. I know the hardware is shit and the RasPi foundation is full of shit but its also the most common SBC on the market. For that reason we do support the RasPi 3 only and while there are concessions to be made we also have roughly 6500 of them on support with our own OS stack at £5/€5 per month per device. We normally manage to get clients off them and onto something better at the next platform refresh.
  17. lanefu liked a post in a topic by valant in Espressobin support development efforts   
     
    esspressobin is affected by insanely high delivery cost instead.
  18. lanefu liked a post in a topic by sgjava in ArmbianIO API proposal   
    I've created Python bindings with Swig using a script that should install all dependencies and create an armbianio module and install locally with pip, so it's globally accessible in Python. I created a PR for Larry, but you can grab it at https://github.com/sgjava/ArmbianIO until the merge happens. I included a simple LED blink program that uses pin 12 (ArmbianIO mapping) for the NanoPi Duo. It would be nice to test other SBCs as well.
  19. Da Xue liked a post in a topic by lanefu in Le Potato general topics   
    Ethernet Patch definitely made my potato solid.  I'm running fresh image now, with consul, nomad, docker and Jira running in a container..  def much faster than on my Opi2e.
     
    Thanks for the patches!
     
    Linux lepotato 4.14.8-meson64 #2 SMP PREEMPT Sun Dec 24 21:03:07 EST 2017 aarch64 aarch64 aarch64 GNU/Linux  
  20. Da Xue liked a post in a topic by lanefu in Le Potato general topics   
    Ethernet Patch definitely made my potato solid.  I'm running fresh image now, with consul, nomad, docker and Jira running in a container..  def much faster than on my Opi2e.
     
    Thanks for the patches!
     
    Linux lepotato 4.14.8-meson64 #2 SMP PREEMPT Sun Dec 24 21:03:07 EST 2017 aarch64 aarch64 aarch64 GNU/Linux  
  21. lanefu liked a post in a topic by Igor in Orange Pi One Plus   
    - H6
    - 1GB
    - gigabit
    - 26pin
    - powering only via DC input
    - PMU AXP805
    - 1 x USB2.0 host and 1 x micro USB 2.0
    - size: 69x47mm
    - weight: 50g
    - price USD20-25




  22. lanefu liked a post in a topic by Igor in Espressobin support development efforts   
     
    Nightly building is back.
    https://beta.armbian.com/pool/main/l/linux-4.14.7-mvebu64/
  23. lanefu liked a post in a topic by TonyMac32 in Le Potato Ethernet Problems   
     
    Thank you for the update, I saw the activity in the lists, I should be able to try the patches out soon to see how they work.  For the short term I've been using a wifi dongle.  
  24. lanefu liked a post in a topic by Da Xue in Le Potato Ethernet Problems   
    BayLibre says they're close to a fix. It's an issue with EEE capability being mis-detected.
  25. lanefu liked a post in a topic by tkaiser in ZFS on Armbian   
    Not just after Oracle killed Solaris few weeks ago the question arose how to continue with ZFS (me being an absolute ZFS fanboi). After reading ZoL (ZFS on Linux) 0.7 release notes it was just a matter of time to give it a try. On an energy efficient x64 board supporting Intel's QuickAssist (QTA) and also on the most appropriate ARM platform we support for these use cases: Clearfog Pro or Helios4 soon. Release notes state to implement a lot of performance improvements (check the performance section above yourself) so let's give it a try:
     
    Since ZoL is said to be compatible with kernel 4.12 max and we switched already to 4.13 with Armada 38x the best idea is to start with current OMV image for Clearfogs since relying on 4.12 kernel. So with a Clearfog it's just grabbing http://kaiser-edv.de/tmp/NumpU8/OMV_3_0_87_Clearfog_Pro_4.12.9.img.xz, letting it boot, wait for the reboot and then access Clearfog through serial console (or access OMV web UI and enable SSH root login -- see release notes). I built most recent 4.12 kernel plus headers available here http://kaiser-edv.de/tmp/NumpU8/zfs-on-linux/
     
    Getting ZFS to work is basically the following: After booting the OMV image ('next' images from dl.armbian.com might work too -- not tested) install headers and kernel package from last link above (you'll be then on kernel 4.12.13), then run armbian-config --> Armbian --> 'Hold -- Freeze kernel and board support packages' to prevent up-/downgrading kernel with 'apt upgrade'. And then simply follow https://github.com/zfsonlinux/zfs/wiki/Building-ZFS
     
    With Armbian/OMV it's just
    wget http://kaiser-edv.de/tmp/NumpU8/zfs-on-linux/linux-image-next-mvebu_5.32_armhf.deb wget http://kaiser-edv.de/tmp/NumpU8/zfs-on-linux/linux-headers-next-mvebu_5.32_armhf.deb dpkg -i linux-image-next-mvebu_5.32_armhf.deb linux-headers-next-mvebu_5.32_armhf.deb apt install build-essential autoconf libtool gawk alien fakeroot zlib1g-dev uuid-dev \ libattr1-dev libblkid-dev libselinux-dev libudev-dev libdevmapper-dev lsscsi ksh Then follow the instructions above. I did in both directories also a 'make install' and finally executed 'ldconfig' to get the libraries that are installed below /usr/local/lib/ working (see here for details). A final 'echo zfs >> /etc/modules' followed by a reboot and ZFS is ready:
    root@clearfogpro:~# zpool create -f test raidz sda sdb sdc root@clearfogpro:~# zpool list NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT test 334G 1.55M 334G - 0% 0% 1.00x ONLINE - root@clearfogpro:~# zpool status pool: test state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM test ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 sda ONLINE 0 0 0 sdb ONLINE 0 0 0 sdc ONLINE 0 0 0 errors: No known data errors root@clearfogpro:~# zfs create -o mountpoint=/var/volumes/raidz -o compression=on test/raidz These are 3 different 120 GB SSDs (SMART output for all of them) as RAIDZ behind 3 different SATA controllers (Transcend in M.2 slot served by Armada 38x directly, Samsung EVO840 attached to an ASM1062 and the Intel 540 behind a Marvell 88SE9215). Armbianmonitor -u: http://sprunge.us/CUHS
     
    Focus of the following tests/research is performance and reliability since it's just a shame that in 2017 users still want to use mdraid/RAID5. A first quick test with 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' failed, without the '-I' iozone is running but results are discouraging (as expected):
    random random kB reclen write rewrite read reread read write 102400 4 5033 4856 242613 243166 18853 168 102400 16 4981 5104 219828 354587 79886 664 102400 512 5006 5069 363717 366405 416668 5330 102400 1024 5029 5068 337919 326607 370943 5335 102400 16384 4856 4878 356314 357925 357245 5087 I better stop with Armbian/Clearfog now and try this on x64 first