balbes150

If @JMCC adds a script for the main kernel, then any version can be used. Personally, I like the latest Hirsute. I am testing the latest versions (Hirsute and Sid) and see a significant improvement regarding Focal and Bullsey. As far as I know (when building LE with the main core), the main core now has all the components for HW. I am quite satisfied with the main core, even without HW, it is enough for full-screen video in 1080p mode (this is the main mode I use, 4k is too small for the desktop). I regularly update all the latest images on the site http://bbs.t-firefly.com/forum.php?mod=redirect&goto=findpost&ptid=2781&pid=13344&fromuid=636914 I don't have N2+. I try not to release versions for hardware that I don't have (this creates a lot of problems for me, users ask questions and describe problems, but I can't test and fix them, so I avoid creating such variants).

The old LEGACY kernel does not see NVMe. Need to understand the configuration and DTS. But there's no time for that yet.

I checked it again now. NVMe works with all ArmbianTV and Armbian images with the main core. I didn't check the legacy kernel. Here is a screenshot. Please note, the hat is very sensitive to the contact fit, if you put it on too tightly, NVMe does not work. You need to slightly raise the hat over the main board, so that there is no contact with other elements. https://yadi.sk/i/cWmayDV-hH0D5Q Disk /dev/mtdblock0: 16 MiB, 16777216 bytes, 32768 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/mmcblk2: 29.12 GiB, 31268536320 bytes, 61071360 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x72dd71e9 Device Boot Start End Sectors Size Id Type /dev/mmcblk2p1 30720 1038335 1007616 492M c W95 FAT32 (LBA) /dev/mmcblk2p2 1040384 61071359 60030976 28.6G 83 Linux Disk /dev/nvme0n1: 232.91 GiB, 250059350016 bytes, 488397168 sectors Disk model: Samsung SSD 970 EVO 250GB Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x95cda040 Device Boot Start End Sectors Size Id Type /dev/nvme0n1p1 2048 488396799 488394752 232.9G 83 Linux Disk /dev/sda: 14.73 GiB, 15795748864 bytes, 30851072 sectors Disk model: Transcend 16GB Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0xd59e383c Device Boot Start End Sectors Size Id Type /dev/sda1 32768 1081343 1048576 512M e W95 FAT16 (LBA) /dev/sda2 1081344 30542559 29461216 14G 83 Linux armbianmonitor https://yadi.sk/d/iw5-pIbZWEucmQ

Yes, it is possible. I unscrewed the nut and pulled the connector out of the housing. The antenna can be installed on the corner, which is fixed on the mounting posts. I don't need WiFi , so the antenna is just lying around next to P1 (I don't disconnect the connector from the board). Is there a possibility of its malfunction ? What image and with what settings are you trying ?

But note that the PoE contacts must be isolated so that they do not touch the power connector housing. And no need to disconnect the WiFi antenna connector from the board, it does not interfere with the installation of the hat I pay attention, when I checked, I did not insert the connectors to the full depth, I controlled that the board did not touch and did not bend. I was left with about 1-2 mm of contacts not inserted into the connector. The Samsung EVO 970 256Gb NVMe module is perfectly detected and works on ArmbianTV. I haven't tested NVMe on other systems.

Is it possible to run some functions (such as enabling or disabling overlay) directly from the command line without using the GUI ?

Still, there is a benefit from the native build, there is a possibility of maneuver ...

Yes, this is a temporary solution. By the way, it is possible to create a ROOTFS cache (and placement on mirrors for download during the build process, as it was previously) for official versions (DE XFCE with a full set of groups + a version for the CLI). Everything else is at the discretion of the users (self-assembly).

Can you try to build rootfs on the ARM server (native build) and then try to use it on x86 (use a ready-made cache)? For me, this solved all the QUEMU error issues on x86.

Can you see the detailed error log itself ?

An interesting result is that if add (mark) a browser group for Bullseye DE XFCE (in which one additional firefox package is esm), the build goes without errors. This means that the dependencies of the Firefox package have the necessary packages for QUEMU to work.

Checked the minimal version of DE XFCE - gives an error. This means that among the packages that are included in the lists of additional groups, there is something that allows quemu to work correctly. Now I will look for this "something".

Checked out from Bullseye. The build of the full desktop on x86 passes without the quemu error, but the build of the CLI version gives an error. Perhaps the description of the CLI packages is missing some package that is critical for quemu. I want to try playing around with the package composition for the CLI.

It looks like my zsh installation error when building on an x86 PC has the same source (quemu error). But the oddity is that the buils image CLI sid gives an error, the XFCE sid assembly (when using all the additional groups) has no error.

I tested the native build of the image using Bullseye (XFCE) on the latest DESKTOP branch . The minimal (basic) configuration works without errors. For the full configuration (when all grupps are checked), you need to remove the libreoffice-style-tango package. I removed the link to the BUSTER package, copied the file package, and deleted the libreoffice-style-tango package. The full build is error-free.

To all fans of shit, I recommend reading it. It is better to spend money on a good device once than to throw money away in the empty space and then suffer and try to finish and redo it without having a normal result and a future. https://www.thanassis.space/stationm1.html

Firefly Station M1 (rk3328) https://www.thanassis.space/stationm1.html

Yes

New Image 20210123 for H6, kernel 5.10.9 https://yadi.sk/d/0a41swJcEAZ0SQ?w=1 https://mega.nz/folder/j9QSDQSQ#6WpasOlbZYIInfw6yo4phQ/folder/K9BRjSaZ

Have you tried asking the Firefly developers what they would add to the Android "root" firmware ? Perhaps they can immediately include this in their firmware. I have been using this mode for a long time in all ArmbianTV builds kernel 5.10, everything works well on M1.

@ballerburg9005 I read what you write and once again I was convinced-you are a banal troll, who, hiding behind beautiful slogans, is trying to get support for the shit that you bought. You're trying to convince other users to buy this shit ($30 aml tv boxes), and then try to get support by relying on a lot of idits who will follow this advice and buy this shit. There is no point in proving anything to the troll, it is useless. I wouldn't be surprised if you turned out to be a banal peddler of this shit. If you are such a freedom fighter, here is a ready - made solution for your ideas about freedom-Station M1\P1. This is a completely finished product for the most "average Joe". It does not need to alter anything for normal cooling, you do not need to assemble it from different parts, you do not need to spend time on debugging software, etc.And most importantly, this equipment has guaranteed support, and for every taste - Android or Linux (Armbian Slarm Freebsd and bunch of different specialized distributions for different tasks, etc.). But you don't need it, you want to make others work for the shit that you like (profitable) . P.S. About the inner kitchen of AML and the device, I know much more than you and my refusal to support them is based on real knowledge, but I'm not going to waste time explaining everything to you in detail and convincing you. The only advice I can give to anyone reading this is to absolutely avoid this shit.

I checked the Renegade Elite hat on Station P1. Connected (with some additional steps), everything worked. NVMe is visible and can be used for system placement or other needs. But there is a nuance with the physical placement of the hat. I had to remove the WiFi antenna connector and add an insulator to the plane of the power connector, it touches the hat at the location of the POE elements. Also, because of this, it will not be possible to insert the hat contacts completely, to the full depth. And you need to replace the racks with lower ones, the regular ones are too high.

I have a Renegade Elite with a hat for M2, I wonder if it fits P1 or not. If it fits, I can try using it on P1. https://www.loverpi.com/collections/libre-computer-project/products/libre-computer-mezzanine-for-roc-rk3399-pc https://www.firefly.store/goods.php?id=95 I'll have to take my Renegade Elite apart and check it out.

No, I meant the hat itself for p1. I have a Renegade Elite with a hat for M2, I wonder if it fits P1 or not. If it fits, I can try using it on P1.

For TV boxes, there is no official Armbian, so there is no point in wasting time on this, on each TV box, the process will be different and users will be tormented by questions about why they do not find the elements that you will tell about.