• Posts

  • Joined

  • Last visited

Reputation Activity

  1. Like
    jeanrhum reacted to Igor in Armbian 21.08 has been released   
    Armbian is an established Linux for single board computers that is used in enterprise, IOT micro services and various hobby deployments. Recent desktop improvements bring the platform on-par with key players in the Linux desktop arena while keeping the key advantage – you can easily build your own Linux distribution.
    Armbian provides stable releases every three months. They are driven by CURRENT LTS kernel. Adventurers which likes rolling releases, can check EDGE releases which are using latest daily kernel builds with fresh packages from sid, hirsute or impish userland.
    Armbian has powerful build system which can build a whole Linux distribution, an OS image or a kernel. Key advantages are simplicity, speed and excellent hardware support. Provides native or cross compilation.
    This release is hard work of exceptional individuals who have contributed their time and expertise into this release. Many thanks to – in alphabetic order:

    @balbes150 @AristoChen @belegdol @Werner@Heisath @iav @Igor @Icenowy @lanefu @jock @piter75@Rich Neese@rpardini@going @tkaiser @tparys @TonyMac32 @Azq2 @henkiejan1 @juanesf @psztoch, @redchenjs @Uglymotha

    Special thanks to users and vendors @orangepi, @friendlyelec, @khadas and @olimex that understand the importance of our work and supports the project with donations of cash, hardware & expertise.

    minimal, server or XFCE, Cinnamon and Budgie desktop fast and effective automated language selection on first run regular stable and daily beta & EDGE updates CLI is powered with ZSH or BASH added automated kernel upgrade on EDGE 5.13.y kernels added mainline based SPI boot support for Odroid HC4 added Qemu virtual Armbian builds added CSC images for Tinkerboard 2, Rockpi N10, added ZFS upgrade to v2.1 improved Github Actions CI and CDN network added Cinnamon and Budgie desktop enabled 3D support wherever its possible and works reasonble well added Khadas VIM1-3 & Edge boards, Avnet Microzed enabled VPU support for Rockchip added legacy kernel support for OrangepiZero2, Nvidia Jetson declare Ubuntu Hirsute and Debian Bullseye packages as stable added Ubuntu Impish and Debian Sid as beta build targets added KDE plasma DE as a beta build target
    What’s Left
    long term armbian-config refactoring upgrading Rockchip u-boot from 2010.y to latest resolving Allwinner boot troubles on last u-boot enable 3D on Meson G12 / SM1 infrastructure improvements: mirros, runners, publishing.  
    Tough Decisions
    Odroid C4/HC4 boot problem has to remain unresolved in CURRENT 5.10.y kernel since fixing it would break Khadas boards. Problem was properly solved in EDGE kernel. We had to disable 3D on latest Amlogic boards due to instability Leaving behind published Deepin, Enlightenment, Gnome, i3, KDE plasma, Mate, Xmonad desktop due to space constrains and lack of maintenance. These options are still available within the build tool.  
    Known problems
    XFCE desktop is missing package gvfs-backends and xarchiver bullseye doesn’t properly detect locales Helios64 eMMC IO errors with CURRENT kernel OrangepiZero2 EDGE kernel based image doesn’t boot. Will be fixed in bug fix release.  
  2. Like
    jeanrhum reacted to balbes150 in Firefly Station P2 (rk3568) M2 (rk3566)   
    Good news. Full-fledged working images (20210826) of ArmbianTV for P2 are ready. All the equipment works in them and you can start and configure the system via an HDMI monitor and a keyboard/mouse. 
  3. Like
    jeanrhum reacted to balbes150 in Firefly Station P2 (rk3568) M2 (rk3566)   
    For those who are interested in reducing the price of Firefly RK3566\rk3568 boards. I am trying to convince Firefly representatives of the need to add rk3566\rk3568 boards without the eMMC module to the line of products sold. This will significantly reduce the price. This is especially noticeable on the variants of the eMMC module with 64\128GB. For those who plan to use these models with SATA or NVMe (after the version of the u-boot loader for SPI is finalized, for direct launch with SATA\NVMe). At the first stage, to fully start the entire system with SATA\NVMe, you can use the bootloader from the SD card. I invite everyone interested to express their opinion, so that Firefly representatives could assess the prospect of such an option for delivery.
  4. Like
    jeanrhum reacted to balbes150 in Firefly Station P2 (rk3568) M2 (rk3566)   
    I received samples of P2 and M2. the first impressions are very positive. I checked the launch of the official versions of Ubuntu 18.04 from Fyrefly. Everything starts and works from the SD card. The startup process is very simple, I downloaded the image, unpacked it, wrote it to the SD card, connected it to P2\M2, turned on the power and the system automatically updated the bootloader in eMMC, rebooted and the Ubuntu system automatically started from the SD card (the regular Station system in eMMC is saved and works if there is no SD card).
    I really liked the mechanism for connecting SATA devices (SSD\HDD) to P2, it is very simple. I immediately connected a 240GB SSD drive. It was automatically detected and appeared in the system. WiFi antennas on P2 are full-fledged and large, they obviously did not save money here and will ensure proper operation. 
  5. Like
    jeanrhum reacted to lanefu in Armbian the Virtual Machine   
    Been dreaming of this one for a while.  Finally got a weekend to focus on it recently.  I'm hoping someone is eager to take what I've done and move It along some more.

    Here's what we have so far.

    * a linux 'family' called virtual.conf
    * a kernel config called linux-virtual-current.config
    * a board called virtual-qemu.wip
    The result is a full HVM accelerated armbian image with a kernel compiled with all the virtio drivers for disk, network and video.   Also a u-boot.bin made for qemu that can boot the image when used as the qemu bios/firmware
    I've ran it as a VM on ubuntu using plain qemu on a Ampere eMag box.. and using UTM (qemu) on Apple M1 in MacOS

    this is using u-boot, not uEFI.. and you need to copy the u-boot.bin manually from cache/sources/u-boot...../u-boot.bin and use it as your chosen bios for qemu.  I left some quick breadcrumbs on how to launch within the board config file.
    I want to keep the u-boot option, but obviously we need this to support uEFI booting to be viable for the masses.

    Next steps:

    * automatically resize and convert resulting image to qcow2 format
    * solve how to add cloud-init to image
    * solve for installing grubEFI for booting and whatever partition layout is needed
    * figure a proper way to write uboot to the image so thet qemu can boot without loading as a bios
    * strip extra hardware drivers out of kernel and make this thing lean

    PS Did I mention Desktop Works too?

  6. Like
    jeanrhum got a reaction from malaga in How to install Docker on a banana-Pi system: ... and separate the config-data in a smart way   
    Hi Malaga,
    Your question is not directly related to armbian or any relevant OS for a given board, but it is more a question about docker itself and how it manages data:
    On dockerhub, you'll find most images where the data specific to the encapsulated software is binded to a local folder by setting the relevant volume. Look for instance to this image: where -v /path/to/appdata:/config defines the location where your can access to the config files from the host operating system and -v /path/to/data:/data corresponds to the data stored with nextcloud so that you can target any local drive properly configured and mounted from the host operating system.
  7. Like
    jeanrhum got a reaction from lanefu in Need Quick python enhancement for our dl-redirect   
    I tried something:
  8. Like
    jeanrhum reacted to lanefu in Req: Build my Dream Compute SBC   
    Suggestion for a (near future) product.
    We're still lacking a good SBC out in the wild for small clusters.. Recent SoC performance is good.. Currently all the homelab and k8s nerds are just using RPI4s because they have a header for POE support.    We know there are better options.

    We had pitched this to orange pi but weren't receptive. Just sharing my idea here.
    A Lean SBC exclusively for server tasks.
    "The Ultimate Homelab SBC"

    Real 802.11at POE+ means only 1 cable for your compute node
    Use SPI flash for custom provisioning configuration
    Optimized for Compute
    "Ready for clustering and kubernetes"
    Has the Performance and Storage you need to easily deploy for clustered computing

    Suggested Reference Specs
    RK3399K or similar performant SoC Gigabit Ethernet 4G Dual Channel LPDDR4 16-32gig EMMC SPI flash 128mbit/16megabyte No Wifi No bluetooth No audio No CSI No HDMI USB 3 802.11af/at support or support for RPI4 style 6 pin POE hat All Ports in rear? holes for additional heatsink mounting options
  9. Like
    jeanrhum got a reaction from legogris in Review of Station M1: a perfect home server!   
    Station M1 is based on a firefly board quite similar to roc-rk3328-cc. However, the M1 has a different layout with all ports on the left or on the right, and it is enclosed in a metal case used also as a heat sink. The device tree is also different (rk3328-roc-pc instead of rk3328-roc-cc) and by default a smooth android 10 system is installed on emmc. Additionally, the powering of this board is ensured by a 5V USB-C port instead of a micro-usb for the roc-cc. You can find official pictures and specifications here.
    My M1 has 2GB ram and 16GB emmc but variants with 4GB ram and more emmc storage can be bought. Currently, an armbian CSC image can be downloaded (bullseye or focal) or built using armbian buiding system.
    I tried several images and all boots fine with almost everything working out of the box for a server use case. Here is the log of armbianmonitor with a buster build from the end of january 2021 with kernel 5.10.9:
    Idle the temperature goes under 40°C in a room where the temperature is about 21°C and the metal case is not warm. Running sbc-bench in this context produces these results:
    The temperature never goes over 61°C without any throttling. Compared to some other rk3328 SBCs, the M1 is cooler and this is mainly due to its metal case.
    After general configuration with armbian-config, installing openmediavault and docker were as easy as possible, since they are also available through armbian-config in the softy menu.
    After connecting an usb3 drive, I got an efficient nas system for a personal use. It can also be considered as a home-server while running several additional services thanks to docker (home-assistant, zigbee2mqtt, pyload, etc.). With this use case, the 4 A53 cores and 2 GB of ram are more than enough and all is running smoothly.
    I also use other similar arm boards and here is my comparison:
    - an amlogic S912 TV box with 3GB ram and GBit ethernet using armbianTV: 2GB is enough in my case and rk3328 is better supported than s912. Moreover, s912 is not officially supported by armbian, and latest armbianTV images are not compatible. The USB3 port on M1 is also a great improvement over USB2 for s912. TV boxes may also have unrecognized wifi chips whereas M1 has working wifi (and bluetooth ? not tested).
    - Librecomputer lafrite 1GB: it is officially supported by armbian and it works well. Its main drawbacks compared to M1 is only 1GB, USB2 and only 100MBits ethernet, but it is much cheaper.
    - Pine64 Pineh64 model B: IMO it is the real competitor to the M1. It has similar features with USB3 and GBE. It is officially supported by armbian and it has a more powerful SoC (Allwinner H6: 1.8Ghz 4xA53 with mali 720 gpu). However, this board is much warmer than M1 since in the same room its temperature is greater than 60°C while idle and throttling may occur on moderate to heavy loads. For moderate use case M1 is enough.
    What to expect in the future:
    - We can hope that this SBC becomes quickly officially supported, since the CSC release is already very mature (in my opinion).
    - The main element that can be missing with mainline kernel for some use cases is the GPU (for desktop use) and VPU, but they are available on 4.4 kernel.
    Another review of the M1 (using also armbian):
    Official forum:
  10. Like
    jeanrhum got a reaction from Werner in Recommendation needed for affordable sbc   
    If you want integrated wifi, several sbc can be used and some others will require an usb wifi dongle. The key
    For instance, the pineH64-B with 2 or 3GB of ram may do the job quite well and you can add an emmc module:
    A similar device is Orange Pi Lite 2.
    If you want something closer to a tv box, station M1 is also a nice choice even if it is only community supported for now:
    If you want a stronger cpu, any of the armbian supported sbc based on rk3399 will answer your needs (check for wifi in case it is not integrated on some boards, eg. rock pi 4A).
  11. Like
    jeanrhum got a reaction from lanefu in Available software with Softy / armbian-config   
    For this software, I prefer to use the docker official installation method with standard linux install over docker:
  12. Like
    jeanrhum reacted to Igor in Available software with Softy / armbian-config   
    This one is integrated and it should work.
  13. Like
    jeanrhum reacted to Werner in bat - cat with syntax highlight and other stuff   
    Stumbled across while digging through Github.
    Its like code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } cat but has syntax highlight and other cool stuff. Nicely they provide arm and arm64 binaries for lazy people
  14. Like
    jeanrhum got a reaction from Werner in Implement Device Tree Editor   
    Testers needed. More especially, people with samsung, nexell or even marvell are expected.
    The main issue for now is the way the dtb is named and located in the boot folder. I tried to infer it using the comptible property of the device tree, but I don't own all supported hardware .
    I already tested sucessfully on several kernels (aml 4.20, rk and aw on 5.8, 5.9).
  15. Like
    jeanrhum reacted to balbes150 in Board Bring Up Station P1 rk3399, M1 rk3328
  16. Like
    jeanrhum got a reaction from TRS-80 in Implement Device Tree Editor   
    First pull request for me:
    It is a basic implementation with my humble knowledge in bash. It may be improved by experts if possible.
    I tested on my armbian dev config and it seems to work. I hope to have follow the right way to make a PR since it is my first one.
  17. Like
    jeanrhum got a reaction from Igor in Implement Device Tree Editor   
    First pull request for me:
    It is a basic implementation with my humble knowledge in bash. It may be improved by experts if possible.
    I tested on my armbian dev config and it seems to work. I hope to have follow the right way to make a PR since it is my first one.
  18. Like
    jeanrhum got a reaction from jock in Implement Device Tree Editor   
    First pull request for me:
    It is a basic implementation with my humble knowledge in bash. It may be improved by experts if possible.
    I tested on my armbian dev config and it seems to work. I hope to have follow the right way to make a PR since it is my first one.
  19. Like
    jeanrhum got a reaction from Werner in Implement Device Tree Editor   
    First pull request for me:
    It is a basic implementation with my humble knowledge in bash. It may be improved by experts if possible.
    I tested on my armbian dev config and it seems to work. I hope to have follow the right way to make a PR since it is my first one.
  20. Like
    jeanrhum reacted to Learnincurve in Pine A64 MIPI DSI mainline   
    Issue is finally fixed in (at least) nightly builds !
    There is now a "pine64-7inch-lcd" overlay in /boot/dtb//allwinner/overlay
    Just add
    to armbianEnv.txt and screen magically works.
    A BIG thank you to the team for fixing this! Pine64 is now ready for mainline kernel goodness!

  21. Like
    jeanrhum reacted to JMCC in Khadas VIM2 csc   
    I see your point. You are used to deal with some profile of TV-box user, with high expectations and little technical knowledge. I personally would not call "dangerous" the standard approach of erasing eMMC in order to replace it for Armbian, it is what we do in many other boards. I have personally done it, the method is documented in official Khadas documentation, as well as the method for flashing the original Android again. But, again, I see your point, that it can be somehow "dangerous" for someone who has no clue of what he is doing.
    So I think a sane approach is to keep the the same way as we have been doing all along with, which has not produced many complaints so far. The option in the build script is there, but we don't publish images among the supported boards, nor specify the method to install them. That way, only users with enough knowledge to use the build script will have those images. At least, for the time being, this may change in the future of course.
    Besides that, I have developed a new function for the bash script, that grabs the meson-gxm boot blobs from the amlogic-boot-fip repo, as well as some patch to fix CPU scheduling in AML S912. These things can be useful if/when we start to support the Tartiflette.
    I'm making a PR with all these changes.
  22. Like
    jeanrhum got a reaction from gounthar in AllWinner H616 boards   
    I think this could be an interesting soc, but in how many months (or years)?
    This soc is not referenced in sunxi status matrix and nothing is planned in kernel 5.11, so I fear that support is not even started from their side. Maybe it's close enough to h6, but I didn't see any information about somebody able to start linux with it and it has a different gpu.
  23. Like
    jeanrhum got a reaction from Werner in Armbian Donations   
    I gave some bucks for this powerful server. Paypal was perfect for me. Long live to armbian!
    I hope the target will be attained soon.
  24. Like
    jeanrhum reacted to xwiggen in SBC with proper software support for hardware video transcoding   
    The  transcoding is handled by the jellyfin-ffmpeg package, which is basically a fork of ffmpeg. You can specify your own path to ffmpeg binary in settings, as the supplied binary is linked with raspberry libs (which is the only rpi specific code of jellyfin).
    Raspberry pi is ok for VPU.
    @Wernertry jellyfin on your NEO3 and compile ffmpeg with --enable-version3 --enable-rkmpp --enable-drm
    Personally I don't use transcoding but leave it all to the RPI3 (LibreElec) which happily plays all formats from SMB except for 10bit x265.
  25. Like
    jeanrhum reacted to Learnincurve in Pine A64 MIPI DSI mainline   
    I updated the system with the new dtb package and edited the tree again, this time without the feiyang panel.  Here are the the .dts snippets for dsi and d-phy:
      dsi@1ca0000 {                         compatible = "allwinner,sun50i-a64-mipi-dsi";                         reg = <0x1ca0000 0x1000>;                         interrupts = <0x00 0x59 0x04>;                         clocks = <0x02 0x1c>;                         resets = <0x02 0x05>;                         phys = <0x44>;                         phy-names = "dphy";                         status = "okay";                         #address-cells = <0x01>;                         #size-cells = <0x00>;                         phandle = <0x8d>;                         vcc-dsi-supply = <0x04>;                         port {                                 endpoint {                                         remote-endpoint = <0x45>;                                         phandle = <0x20>;                                 };                         };                 };                 d-phy@1ca1000 {                         compatible = "allwinner,sun50i-a64-mipi-dphy\0allwinner,sun6i-a31-mipi-dphy";                         reg = <0x1ca1000 0x1000>;                         clocks = <0x02 0x1c 0x02 0x71>;                         clock-names = "bus\0mod";                         resets = <0x02 0x05>;                         status = "okay";                         #phy-cells = <0x00>;                         phandle = <0x44>;                 };  
    This time, dmesg is at least not displaying any mipi or dsi-related errors:
    # dmesg | grep dsi
    [    2.318045] sun4i-drm display-engine: bound 1ca0000.dsi (ops 0xffff800010daf360)
    ~# dmesg | grep mipi
    [    2.275838] vcc-mipi: Bringing 2900000uV into 3300000-3300000uV
    so definitely closer.
    Now I'm going to re-visit the thread and armbian documentation to see what needs to be done to enable.