balbes150

Ver 20201226. Added support for HDMI audio.

There is no "new" kernel for P1, I use the rockchip64 kernel (all patches are regular from the build system only added patches for DTB), the difference is only in the kernel configuration + adding drivers for WiFi.

Try using my "armbian-tv-next" branch to build images for P1\M1. It has changes that use a different kernel for legacy. I am not creating a PR yet, until it is agreed with the rest of the interested developers which legacy kernel is best to use for P1\M1.

Armbian ver 20201225 kernel 5.10 https://yadi.sk/d/KIvG9oQzIuvUyw?w=1

You do your job well. It is not necessary to know everything, in the modern world only specialization in a narrow direction will allow you to achieve good results. Unfortunately, the number of "narrow specialists" who work on the development of Armbian is scanty and they have a huge load ....

I planned to create a simple DEB package with these files for easy installation as a dependency of the build environment, but so far there is not enough free time for this (after creating the package, it still needs to be placed in a network repository and check how it will work on different versions of distributions). So for now, I limit myself to "simple dumb copying" and including these files in all my images. p.s. Unfortunately, those who want to help, at least in such simple operations, are not observed. Everyone wants to get everything for free, beautiful and that everything would work out of the box ....

https://forum.libreelec.tv/thread/1506-s812-miii-plus-2gb-16gb-emmc/?postID=148128#post148128

Start by building a server image, it doesn't need a lot of packets and traffic.

You have specified a kernel-only build. I recommend that you start setting build parameters via the GUI (run the command without parameters). ./compile.sh The system will offer you a graphical interface for sequentially selecting all the parameters and at the output you will get a non-compressed image that you can write to the media.

If have a native build, on the one hand, significantly expand the list of possible images with different DE, with different sets of packages, and on the other hand, no build and place all possible versions on the site, users can build the desired version of the system with arbitrary sets of DE and packages in them. They can also build their own kernel variants with changing the necessary options in the kernel configuration.

By the way, I have a native build of the server image on T4 with the NVMe module takes only 70-80 minutes (this is a clean build, taking into account the download of all sources). For P1, I do not yet have a module for installing NVMe (but this is in the plans). I am currently testing and debugging a native build of desktop images (XFCE \ Mate\KDE etc).

What model do you want to run on ? You can take these files (need two files\libraries) from your x86 host system, or from any of my images (ArmbianTV\Armbian for M1\P1). Or from my GIT (these libraries are included in all my builds, so that users can easily run the build themselves on any ARM device). by the way, the site has versions of images with these libraries for n2 and t4. https://users.armbian.com/balbes150/

Tested on Firefly Station M1 (rk3328). Everything works, including 4k video playback. great job @JMCC

I have a minimum M1 (1 RAM 8 GB eMMC) and it works quite well. I consider it optimal for media playback and as a minimal desktop. Even now, with the main core 5.10, it works with a remote control (which is included), LAN, WiFi, analog sound and HDMI sound (it remains to solve the issue with BT). There is a working version of Buster + media script from @JMCC, it runs KODI and Gst player with 4K. More information about support can be found at this link. http://bbs.t-firefly.com/forum.php?mod=viewthread&tid=2803&extra=page%3D1

https://www.stationpc.com/thread-126-1-1.html

I just used other sources and kernel configuration.

you forgot to add these libraries manually (or you need to use images where this is already done). by the way, you also have access to the arm server and you can run the build on it (there are already these libraries) and the build time will not be very large.

armbiantv uses a different configuration scheme (via the extlinux.conf file), but in the original image everything is already configured for P1. Strangely, you describe the behavior (no DE startup) that is typical for SD card issues. Can you try the images from this link ? after writing the image to the sd card, you do not need to change anything. https://yadi.sk/d/Wczf3oWLMo5n6Q?w=1

can you check more images from the ArmbianTV (they use a common kernel with LE with improvement for media) directory with the 5.10 kernel ? It's interesting to know if your screen resolution will work or not. it is also advisable to check the versions of images of different DE (mate\kde-plazma etc), it is interesting to find out if these DE have their own features of working with the screen..

Throw away this intel shit. use the native build on rk3399. This is faster and without any stupid Trojans in Intel x86. You use the source code from Friendlyelec , they are significantly worse. It is better to use the ones that go for rockchip64-legacy (there are also sources for analog audio 8323\8388) https://github.com/150balbes/build/blob/armbian-tv/config/boards/station-p1.conf#L3 https://github.com/150balbes/build/blob/armbian-tv/config/sources/families/include/rockchip64_common.inc#L51 And the kernel config that WiFi works with. https://github.com/150balbes/build/blob/armbian-tv/config/kernel/linux-rockchip64-p1-legacy.config PS I wanted to create a PR with the change, but so far I have suspended it until we discuss and agree on these changes.

If you find such versions, share the link.

i have everything working. i recommend trying really tested images on p1. http://bbs.t-firefly.com/forum.php?mod=viewthread&tid=2781&page=1#pid13344

Results of a quick test of the native build using the Desktop version. For tests, I tried to build several options - XFCE \ MATE \ KDE in the "minimum" and "maximum" configuration for Station P1\M1 with the current and legacy core. The "minimal" configuration is an option where no group is selected on the last package selection screen. "Maximum" configuration-all package groups are marked. The build (native) runs without errors and the output is working images. Offer. Add the "standard" options in the settings (the necessary packages are selected automatically without additional user steps), this option is equal in the set of installed packages to the current position (the set of packages is equal to those that are currently installed in DE XFCE master branch). The "maximum" is automatically marked for all the available this DE packages (options). Custom setting ("minimum") when entering it, as now, no packages are marked, the user can, not specify anything, then the output will be the "minimum" version of DE or the user chooses the necessary groups\packages.

Have you ever tried to catch bugs and create patches for these modules ? It is much easier for me to devote my time to updating the source code once a month (or 1-2 weeks) (when I know exactly what I need to do and know exactly where to expect possible problems) than to find out in emergency mode why the build process that just worked suddenly crashes and the mass build process of all images breaks down.

In recent weeks, I have been testing a new approach to using the source code for external WiFi modules (RTL). Previously, I regularly got build environment crash issues due to unpredictable source updates for EXTRAWIFI. These sources are scattered in different places and absolutely do not predictably change, breaking the kernel build. I'm tired of tracking such situations and regularly spending time creating emergency patches to restore the build process (or having to temporarily disable the EXTRAWIFI build). I compiled and placed all the sources in one controlled GIT. I still have them my GIT, but if your decide to switch to a new version of the build, it is advisable to transfer them to the Armbian shared resource in the future. The advantages of this option - full control the process of updating source, no need to create and change a bunch of different patches in the build system, eliminates the problem of correct encodings in the source code (when creating the patch turns into a quest with many unknowns), it is possible to have several stable and working versions of the source code for different kernel versions, further it is possible to simplify the patch adding the source code to build kernel, restricted to "dumb" copying (source code pre-fix and does not require complex manipulatsy). As new versions are released, you can slowly check their compatibility, add the necessary fixes to the source code, and only after checking, include the new code in the use of the General build system. This is a test version of the code. https://github.com/150balbes/build/blob/armbian-tv/lib/compilation-prepare.sh https://github.com/150balbes/wifi P.S. By the way, I checked the build of all the modules with the source code for Rockchip-legacy, it was enough to add only two new options and all the modules are assembled normally.