balbes150

I checked it on two rk3328 models. Indeed, even without the correct u-boot on the SD card, the system starts from the SD card. But I have my modified u-boot in eMMC of both models (with support for launching from USB media). Question to all owners of rk3328 \ rk3399 (especially I am interested in those who have Android in eMMC), please check the launch of the Libreelec image for nanopi-k2 from the SD card (after recording the image, you only need to configure DTB, other we do not change). To install to eMMC, it is sufficient to run the installation script (sudo install-rk3328.sh). But before starting, make sure to create a full backup (compressed). Launch the utility (sudo ddbr) and follow the prompts (press the appropriate keys and confirm with Enter).

I will not waste time on a detailed description, but almost everything written is incorrect and erroneous.

Are you sure this is the image you used ? Do you want to run Armbian from an SD card or install Armbian in eMMC ?

Unfortunately, not knowing the language, I can only be an observer and read the discussion (through a computer translator) after the fact.

To get logs, you need the UART console. Search the forum for information about the DTC utility.

Version 20200404. Added the WiFi modules. But I doubt it will help launch the built-in wifi.

The UART console does not depend on firmware. This is a special additional hardware USB-UART, for connecting to another device, details are easy to find by the keyword "UART console". The UART console allows you to get detailed data about the startup process and is needed when something is not working ( in your case, to analyze what is causing the problem in the new firmware 9). But if you go back to the previous firmware, everything should work again without the UART console. Yes, I was forced to change the version so that the system would not be confused when analyzing (the semantics of analysis is a larger version, so it is a newer kernel, if there are two packages with the same name, it takes the first one). arm-64-current aml-s9xxx-current ... rk and alwinner This is the same core. The DEV version is "clean" NEXT kernel from GIT Linux (without additional patches). It changes very quickly and there is no point in releasing it as a separate package (I only collect them as part of the image for quick testing of new features). Support for network repositories is handled by @Igor, so it is better to ask him this question. As far as I know, this requires a lot of space to place and time to keep up to date.

Perhaps this is a feature of publishing new files in the Armbian repository (now there is a huge load on resources and there may be failures). Yes, the update should take place automatically (I fixed the packages for this). P.S. Do not rush, a new version 5.6-rc7 is coming soon. I plan to send it to the Armbian network repo (I have already uploaded some deb files to my site along with the new version of images).

Version 20200404 with a 5.6-rc7 core. In this version, the sound is turned on automatically when you first start (you don't need to do anything manually). Please note that the algorithm for processing audio activation in the new core has changed. If you update the kernel as a separate file in previous versions to the latest version, the sound will stop working. For those who are updating the kernel, additional manual configuration and configuration for audio is required to enable audio.

All sources with documents are regularly updated in my GIT (Build-Armbian).

Yes, the new package is sent to this repo. When it is there, when the update command (apt upgrade) is executed, the new kernel should automatically update.

Version 20200403. Fixed automatic fetching of the kernel from the network repository.

You could not immediately write that your firmware has changed ? I spent a lot of time on unnecessary checks. The new firmware is a different u-boot that is not known to work. Without output from the UART console, I can't help you in any way.

Piteboot does not have the correct system startup priority. If you install a modified version of uboot-SPI in SPI, you can start the system directly from USB (the polling order will be USB - > SD - > eMMC - > piteboot).

I don't see any critical errors. Try waiting 5-7 minutes for the first launch. Or try using a different DTB.

Updating the kernel works the same way. But before updating it, you need to manually rename the /boot/dtb directory to /boot/dtb-old. And then you can run the standard upgrade procedure (apt upgrade). The kernel will update automatically. This only works for those who have correctly configured the DTB in a text file (uEnv.txt) and did not add its own DTB to manual (which is not supported in the kernel).

This is the Armbian-TV version. It has a number of differences that are specially made to support TV boxes. First of all, you need to look at the information in the first message of this topic (there are differences from the official version).

When running, the script displays information on the screen. I need this conclusion.

Everything you need for the 8189 ES \ FS on the 5.6 core is ready and tested, in addition, I added a few more modules 8822xS 8192cu\eu\du (but they are not yet tested, I do not have hardware). I wanted to send a PR, but I stopped it for now (you know the reason).

Show the installation script log.

These changes have long been in the core that I use.

Wait for psychics who will guess what model you have, what image, what steps you take, and so on.

With thes antenna and chip in it, it's a wonder it works at all. The built-in antenna on TV boxes is complete shit.

I will try to enable the driver, but I doubt it will help.

version 20200331 with 5.6 core for s805 and s812 (HDMI does not work). Before I had time to write the announcement, I had already submitted the verification report .... Without adding support to the DTB, there is no point in the driver.