balbes150

Version 20220419-edge with a 5.18-rc3 kernel and  new version of u-boot-2022.04.

Thank you for all of your work on this! You've made a lot of MangoPi board holders happy 😄

New ver 20220622 for D1 (Nezha Lichee RV Mango MQ pro etc) and StarFive V1 (u740)
add image Debian Sid (server and DE XFCE).

Many do not know, but the correct interpretation of the designation "Armbian" does not come from ARM, but sounds like this. An automated workplace based on ubuntu\debian.
 
 
For those who want to take part in the development of this direction, there is some progress (but this does not mean that it will necessarily be included in the official part of the build system) ....
 
https://forum.armbian.com/topic/21465-armbian-image-and-build-support-for-risc-v/?do=findComment&comment=141582

IMHO this is "incorrect logic", i.e. this is "implicit" behavior, the concept of ".ignore_changes" needs to be changed to a "normal" variable with "explicit" behavior. I would remove this mechanism altogether, and make a "generally accepted" option for using GIT branches (when switching to any branch, only data from this branch is used, without automatic hidden switching to the master branch). The key ".ignore_changes" should be used in relation to the current changes in the current branch in the form of a service message with a user-only solution.
 
Therefore, I propose to change this "implicit" behavior, it is familiar to those who know the system, but creates problems for beginners who are accustomed to the "generally accepted" ways of using GIT (switched to the branch, which means its code is automatically used).
 

As an option, I will close this topic for new user messages and it will only contain announcements and info on new versions. For users' questions - they will create new topics.

Maybe I'm doing something wrong, but after switching to the right branch, it still helps me :
 
./compile.sh LIB_TAG="v22.05"
 
without this key, the system itself switches back to the master branch 
 
ps I would suggest for future discussion, get rid of this parameter in scripts and use a "dumb branch switching system" (i.e., do not check which branch the system is on and use the current one, without auto-switching, or just issue a message, but do not switch without "user permission").

Release is not just freezing the code and generating images. Its a time when we pull together stronger, agree and deal with common goals and ideas. Things we are dealing with are complicated. Linux is complex, our framework is getting there too and only together we can deal with all this.
 
I started on freezing the kernel version. There is also some breakage, some related to our patches, some not. But since we have to freeze it sooner or later, perhaps now its the right time.
 
This brings a few good things at once:
temporally release people that are working close with maintaining kernel code @going@jock@balbes150@amazingfate myself ... this can bring more resources on trying to match with / merge armbian-next. @rpardiniworked for moths on this. Lets review the code and help sorting out bugs. Again. IMHO it is possible to merge, but if code remain unstable by the code freeze date (2022-05-14), we are merging after new images are generated. asking @Contributor/Maintainer board maintainers to engage in images building and testing (currently still from master branch) and bug reporting as earlier as possible (once PR 3736 gets merged) reproducible build framework in release branch. Which is most important long term consequence. Additionally, we would like to finish u-boot upgrade on Rockchip and release major forum refactoring @TonyMac32 @piter75 @balbes150
 
Happy Workers' Day!

I assume Balbes will mention if BT is functional in other kernels than legacy...
 

Hi all.
I made a new video where I explain all the basics of working with Armbian xfce4.
This for the absolute beginners that come from Windows. But a more advanced user can maybe also learn a few things from it.
Here is the video.
Greetings,
NicoD

Presumably this is a crosstalk problem, USB 3.0 uses a high frequency that interferes with WiFi (the chips are too close to each other). Details are available on the khadas official forum.

no, it won't help, these are completely different kernels with a different driver organization.

Because it often enough has happened that user did unknown modifications and blame us for their mistakes. Therefor only official images are supported.

Updating images 20220317 (edge 5.17 and current 5.16).
The operation of the standard procedure for installing the system on eMMC via armbian-config has been verified (i.e. you can install the system on eMMC directly on the Quartz64 itself, no additional adapter is needed to write the eMMC module via USB).
Added support for starting the system from USB media. This greatly simplifies and expands the possibilities of running different systems (for example, during testing). Now you can use not only SD cards, but also any USB media to start (and/or work). For example, I installed and configured the Armbian working system on eMMC (with support for launching from USB) and now I easily launch other Armbian test images from ordinary USB flash drives, which is much easier to handle (no card readers are needed to write SD cards, the cost of USB flash drives is much lower and the choice of which models to use \ buy is much wider).

I recently received a sample of Quartz64. I have added CSC level support for Quartz64a to the ArmbianTV build system, after checking and testing, I plan to send a PR with these changes to the official Armbian build system.
 
The first test images for Quartz64 can be found at the link.

https://disk.yandex.ru/d/xMVoaZXFFcWuog

This has been possible for a long time (available in all versions of Armbian that switched to using extlinux.conf), but requires manual editing of extlinux.conf (changing the parameter that is responsible for loading by default it is enough to change one line).
Please note, extlinux.conf is a standard settings file that is well documented in u-boot. In fact, it is very close to the logic of using grub.cfg

I checked this information, yes there is a problem on T4. A PR with the proposed correction will be sent in the near future.
 
As a temporary solution for already downloaded 5.16 kernel images, you can replace DTB with a new one.
 
 
rk3399-nanopc-t4.dtb

The test version of ArmbianTV 20220324 with a new version of u-boot-2022. Allows you to select different systems when starting on the TV screen from the keyboard. This will allow you to have several different systems on eMMC at once and choose which system to run. Please note, this is a test version and there may be errors in it. I recommend checking its operation by launching it from an SD card.

Updating images 20220317 (edge 5.17 and current 5.16).
The operation of the standard procedure for installing the system on eMMC via armbian-config has been verified (i.e. you can install the system on eMMC directly on the Quartz64 itself, no additional adapter is needed to write the eMMC module via USB).
Added support for starting the system from USB media. This greatly simplifies and expands the possibilities of running different systems (for example, during testing). Now you can use not only SD cards, but also any USB media to start (and/or work). For example, I installed and configured the Armbian working system on eMMC (with support for launching from USB) and now I easily launch other Armbian test images from ordinary USB flash drives, which is much easier to handle (no card readers are needed to write SD cards, the cost of USB flash drives is much lower and the choice of which models to use \ buy is much wider).

Updating images 20220317 (edge 5.17 and current 5.16).
The operation of the standard procedure for installing the system on eMMC via armbian-config has been verified (i.e. you can install the system on eMMC directly on the Quartz64 itself, no additional adapter is needed to write the eMMC module via USB).
Added support for starting the system from USB media. This greatly simplifies and expands the possibilities of running different systems (for example, during testing). Now you can use not only SD cards, but also any USB media to start (and/or work). For example, I installed and configured the Armbian working system on eMMC (with support for launching from USB) and now I easily launch other Armbian test images from ordinary USB flash drives, which is much easier to handle (no card readers are needed to write SD cards, the cost of USB flash drives is much lower and the choice of which models to use \ buy is much wider).

Not AFAIK, and also ISP camera support was planned but I am not sure of the current status. I think those are the two main points why someone would like to stay using legacy.
 
I wanted to do some standard packages for all distros in mainline, but I have been overloaded since some time ago, and I am not sure when will I be able to have a look at it. I will announce if it becomes ready.

Hi, have you tried this way to boot Armbian directly? 
https://wiki.stationpc.com/docs/stationpc/armbian

The described steps are intended for the device, as it leaves the factory, multi-boot is not activated in the factory firmware, you activated it yourself. You have already changed the state of your device (activating multi-boot changes the contents of eMMC and SPI, and changes the entire logic of starting systems from external media, not allowing you to start systems with a new format). In fact, the primary "activation\inclusion of multi-boot" is the transfer of the "old" (which does not know how to launch new systems from external media) version of u-boot to SPI. Until multiloading is fixed to work with new launch formats, multiloading needs to be disabled. I have already written to the Firefly developers what needs to be fixed in the multiload so that it works with all systems (with new and old formats). The correction is simple (just a few lines), but so far there is no answer from them.

The current version of Firefly multi-boot (which is installed in SPI) uses an outdated startup scheme that cannot work with new versions of Armbian. I am communicating with the Firefly developers to fix this issue.
 
Additional settings are needed to get a working image.
In the near future I plan to add CSC settings for quartz64.
 
This hardware is not supported and will not work.
 
Have you updated u-boot according to the instructions for Armbian?

https://en.t-firefly.com/product/industry/itx3588j