-
Posts
14500 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Everything posted by Igor
-
Stable, weekly and CI builds https://www.armbian.com/orangepi-5/
-
untilThis week meeting topics: 1. Checking the progress of Armbian-next 2. Armbian short description 3. Mainlining of patches General goal of weekly meetings: To discuss the three (3) issues of the week Discussions will be documented to respective Jira tickets so they can be tracked Three (3) new issues will be selected from Jira for the next meeting The purpose of a weekly developers meeting is to coordinate development of the build engine, continuous integration, operating system features and low level support. Meetings are hosted located on Zoom (Video) and IRC and Discord (Text). While we would prefer you attend on Zoom when possibly, we will also monitor text chat during the call for those unable to join Zoom. Please RSVP either way. Do you want to participate or help in some way? Meetings are focused in developers top level topics and its expected that understand embedded software development, software testings or operating system management. In term of programming languages, knowledge of at least BASH & Python is expected. Since meetings are held in public, any registered community member can join and listen. If you want to suggest issues for the next week, you have to be recognized Armbian contributor. If you want to become one, resolve at least one intermediate level issue and tell us something about you. This is needed to efficiently communicate and to give you access to our organisation infrastructure Jira, Github, hardware lab and servers. @Contributor/Maintainer
-
The reasons why we don't officially deal with this HW is lack of people / resources / time. We would like to hire few developers to offload, but nobody wants to finance consumer needs and competition. If few dollars is to much, you are welcome to use builds with random support status and fix problems on your own. This hardware is even in automated testing setup, but equipment for checking HDMI output is limited. Not even sure why we have this HW in test system.
-
Giving us more work is pointless as we are years behind. Scope of desired changes from users side exceeds developers capacity for quite a lot. This is all what we can do in order to start moving this project (improving this application in all aspects, including UX) forward:
-
Make lowest download speed limit configurable
Igor replied to atone's topic in Framework and userspace feature requests
This download function certainly needs to be addressed in some way. On a side note - with upgrading to NEXT, all external compilers are go away. We would like to keep those things in Jira (invite was sent to your email, feel free to tackle/improve info on any other issue) -
Doesn't boot with 3A images?
-
Event -> Video (with transcripts and comments) 1. Merging NEXT (updated slides) We discussed progress made in past week (Jira Epic) and set limited expectations for following week due to holidays season. We will try to enable rootfs caching CI at first (which has to be compatible with master) and Docker image creation next (which probably isn't?) 2. Unifying boot process Most single board computers needs good overlay handling so moving them to complete generic image is likely / in short term not possible. We still can not count on DTBless or DT from u-boot only, well support from vendor SPI. If we want to move like everything to UEFI and keep things operation / loose no feature, its a lot of work. Sorting out u-boots and going extlinux way with support for multiple kernels (NEXT/CURRENT) might be the best mid-way. 3. When 6.2 and 6.1, current / edge Keeping and stabilising 6.1 at EDGE for few months, waiting that it will be tagged as LTS for sure. Keeping new things like 3588 / 3568 at their own kernel branches, CURRENT = 6.1, EDGE = 6.2 (at once) @rpardini @JetHomeDid I forget to mention something important?
-
2
-
This weeks meeting topics: Merging NEXT Unifying boot process When 6.2 and 6.1, current / edge General goal of weekly meetings: To discuss the three (3) issues of the week Discussions will be documented to respective Jira tickets so they can be tracked Three (3) new issues will be selected from Jira for the next meeting The purpose of a weekly developers meeting is to coordinate development of the build engine, continuous integration, operating system features and low level support. Meetings are hosted located on Zoom (Video) and IRC and Discord (Text). While we would prefer you attend on Zoom when possibly, we will also monitor text chat during the call for those unable to join Zoom. Please RSVP either way. Do you want to participate or help in some way? Meetings are focused in developers top level topics and its expected that understand embedded software development, software testings or operating system management. In term of programming languages, knowledge of at least BASH & Python is expected. Since meetings are held in public, any registered community member can join and listen. If you want to suggest issues for the next week, you have to be recognized Armbian contributor. If you want to become one, resolve at least one intermediate level issue and tell us something about you. This is needed to efficiently communicate and to give you access to our organisation infrastructure Jira, Github, hardware lab and servers.
-
Event | Recording This weeks meeting topics: Merging of next generation build framework Primary goal is to understand benefits it is bringing as we all will need to sacrifice some time in order to review it, then merge and fix remaining bug. Despite our current system produces images, we have many bugs and dirty workarounds that this upgrade is addressing. The future of rockchip64 family Main goal is to make it maintainable again. GitHub development and review process Main goal is to motivate people to take more responsibility for reviewing and merging. Define clear rules. Conclusions: Everyone interested should watch a recording (~1h) and place a comment below. Comments will be discussed here and / or at next meeting. Before we can do anything in real regarding merging NEXT, we need to clean patches but also address several things, starting with those: Making a tool / module for patch generation (@rpardini) Preparing guidelines for review and contribution (@giddy) Move repo management from the build system (@igor) How to help? Cleaning the patches! (helper is here) armbian-next_-_meeting_21.dec.2022.pdf
-
Coordinating development of armbian-config refactoring: https://github.com/armbian/configng @joekhoobyar
-
Donations are very rare so I am happy, but they don't give you any service. This is your free willing contribution to cover small % of things that we already fixed for you. Remember that you are not paying for software in any way. If you want that research is done you need to become at least a gold partner. For your 5$ I can't hire anyone to look into your problem. Especially not myself. Welcome to the custom hardware world. Trick that works with Allwinner devices, doesn't work with Amlogic ... just wait, perhaps someone knows, I don't.
-
Workaround? yes (armbian-config, alternative kernels, choose previous one - 5.10.something), fix? With this, there is nothing we can do but wait like you that Hardkernel fix it.
-
Current only working software for this HW is very old stuff anyway Vendors objectives are different than ours. They want to sell hardware and they want to have control over software. By doing on their own, they control it and they don't help their competitors. It this aspect it makes sense. But yes, I totally agree. Research has been done on the topic, we know many pros and cons and I think we do agree to some point. https://forum.armbian.com/topic/20847-the-boot-process-and-various-devices/ A good topic to discuss it next week - how to proceed from current stage? @ManoftheSea Too early? If preparation and transition is not done well, we also have a lottery. It is nice that you experiment with all this, I know others also did some. We found some issues and we need to make some decisions ...
-
This weeks meeting topics: Merging of next generation build framework Primary goal is to understand benefits it is bringing as we all will need to sacrifice some time in order to review it, then merge and fix remaining bug. Despite our current system produces images, we have many bugs and dirty workarounds that this upgrade is addressing. The future of rockchip64 family Main goal is to make it maintainable again. GitHub development and review process Main goal is to motivate people to take more responsibility for reviewing and merging. Define clear rules. Goal of the weekly meetings: To discuss the three (3) issues of the week Discussions will be documented to respective Jira tickets so they can be tracked Three (3) new issues will be selected from Jira for the next meeting Conclusions: Everyone interested should watch a recording (~1h) and place a comment below. Comments will be discussed here or at next meeting. Before we can do anything in real regarding merging NEXT, we need to clean patches but also address several things, starting with those: Making a tool / module for patch generation (@rpardini) Preparing guidelines for review and contribution (@giddy) Move repo management from the build system (@igor) How can anyone help? Cleaning the patches! The purpose of a weekly developers meeting is to coordinate development of the build engine, continuous integration, operating system features and low level support. Meetings are hosted located on Zoom (Video) and IRC and Discord (Text). While we would prefer you attend on Zoom when possibly, we will also monitor text chat during the call for those unable to join Zoom. Please RSVP either way. Do you want to participate or help in some way? Meetings are focused in developers top level topics and its expected that understand embedded software development, software testings or operating system management. In term of programming languages, knowledge of at least BASH & Python is expected. Since meetings are held in public, any registered community member can join and listen. If you want to suggest issues for the next week, you have to be recognized Armbian contributor. If you want to become one, resolve at least one intermediate level issue and tell us something about you. This is needed to efficiently communicate and to give you access to our organisation infrastructure Jira, Github, hardware lab and servers. armbian-next_-_meeting_21.dec.2022.pdf
-
Those are developers preview builds, where you can check what works and at some point it will be good enough for some uses cases. In a couple of years, it will be functional on the level of kernel 5.10.y. Download is possible from CI pipeline: https://github.com/armbian/build/releases Boot log: This board is looking for maintainer(s) and (this) forum moderator (contact @Werner).
-
-
-
Just a reminder, if someone wants to fix it.
-
https://www.armbian.com/rock-5b/
-
Many of us are using Armbian not just on ARM single board computers but also on servers (bare metal & virtual). We use our builds since we trust it more then Debian, Ubuntu, not to mention other distributions that are recklessly updating and one ends up as an OS tester and not OS user. Personally I use Armbian Jammy on Ryzen 9 workstation with great success. My primary use case is development / productivity. For the road I used to have 13" Dell notebook which recently suddenly died. It was out of warranty so I had to get something new. After some testings of various devices I settled with 12th Gen Intel i5-1240P powered Lenovo. Then I tried many general purpose distros to see how well they work and all had some (minor) troubles ... We are having UEFI images (common image) since some time, but UEFI nor desktops were fine tuned nor ready for such performance daily driver desktop usage. We were close, but not close enough to just run it. Past two weeks we have been lifting general UEFI support, fixed many bugs and what came out is "Armbian ultimate developers desktop build". - improved support in GRUB (armbian wallpaper) & HiDPI GRUB support - all preinstalled applications are normal apt packages - current 5.15.y kernel, Jammy userland (5.19.y has some strange issues) - snapd is not installed (user can install it) - HiDPI support (automated adjustments on big screen resolutions) - NVIDIA graphics acceleration with proprietary driver (x86 only) - Intel graphics acceleration also works out of the box - preinstalled Google Chrome (x86 only) - preinstalled Microsoft Visual Studio Code (x86 only) - ZFS 2.1.5 ready (apt install zfsutils-linux zfs-dkms) - face unlock works perfectly fine on this laptop - installation to SSD drive to dual boot with Windows 10/11 is supported Armbian classical way by transferring actual live image to the prepared partition via nand-sata-install. All you need to do is prepare spare space on your drive, Windows 10/11 or Linux, UEFI support (most if not all hardware for past 10 years has it). I have tweaked images (XFCE, Gnome, Cinnamon) a bit to my personal needs, but making changes is welcome. Nice to have: disk encryption within nand-sata-install, small bug fixing, additional DEs. Currently we have CLI, XFCE, Gnome and Cinnamon. Others are too buggy. https://www.armbian.com/uefi-x86/ https://www.armbian.com/uefi-arm64/ Please report where it works and how (well)!
-
Preparation Supported build environment is Ubuntu Focal 20.04 x64 (minimal iso image). a guest inside a VirtualBox or other virtualization software, a guest managed by Vagrant . This uses Virtualbox (as above) but does so in an easily repeatable way. Please check the Armbian with Vagrant README for a quick start HOWTO, inside a Docker , systemd-nspawn or other container environments (example), running natively on a dedicated PC or a server (not recommended), 20GB disk space or more and 2GB RAM or more available for the VM, container or native OS, superuser rights (configured sudo or root access). Execution apt-get -y install git git clone https://github.com/armbian/build cd build ./compile.sh This will download all necessary sources, execute compilation and/or build a boot-able image. Most of things will be cached so next run will be extremely faster! Real time examples: Documentation