Igor

Well, that's active enough I have seen some bits regarding eMMC in the commit logs ... while we use mainline u-boot sources, where some parts might be missing. Perhaps it's only a configuration issue. Support for eMMC is hard to implement without eMMC boards and time for R&D.

OK, then there are no simple ways. Next try is to dig into and build this u-boot: https://github.com/SolidRun/u-boot/tree/v2018.01-solidrun-imx6 it seems the only option left.

4.17.y or higher still needs a lot of work.

What about if you add this: sudo apt-get install dirmngr

Yes, complete. It's different u-boot, different boot scripts ...

They were merged into (testing) DEV branch, U-boot 2018.03 ... You can find images on the bottom of the download page. I have to note that I can't test this since we don't have a board with eMMC.

https://github.com/armbian/build/commit/10e206519089b8ff81b0dd6a6f3caa6c1adba04d Untested.

It's planned to create a separate forum for Armada powered devices, it's planned to upgrade a kernel for Espresso ... but we extremely lack time/resources for that. If you volunteer to get this forum mess in order by taking moderator duties and move topics into new subforum/in order ... this problem might be already solved. The offer contains editorial rights for this: https://www.armbian.com/espressobin/

My clean Bionic for testing doesn't complain about anything. One test kernel compilation also succeeds ...

Until I can't, don't have any logical explanation and there are no other reports ... it can be due to problems on your side. Let's wait for a while.

Don't worry about that. It works as expected. When you are shutting the board down ... you don't need this. I think it's written in the script why modules are unloading. If you are messing with startup services, a warranty is void Until this is not replicated on a clean system, a problem does not exist. We pay attention.

Did you update bootloader on your eMMC? You only need to do this once. Boot from SD, got to nand-sata-install ... and select "Update bootloader" ... after that, your eMMC is capable to boot Armbian ... which doesn't use FAT boot partition and our fixed u-boot fix this.

https://forum.armbian.com/search/?&q=orange high temperatures&search_and_or=or

No need. We have a script for adding zram swap. Are thee still any problems?

Can't reproduce. http://ix.io/1eFh Works fast as expected. cat /etc/apt/apt.conf.d/02-armbian-compress-indexes Acquire::GzipIndexes "true"; Acquire::CompressionTypes::Order:: "gz";

Yes, it succeeds, but why, for what is waiting? Dependency issues?

Good catch. This comes with new BSP rework. Will be investigated further. Can you provide armbianmonitor -u from one of those?

No, there are no specific reasons. If you need something in a configuration, simply add it: https://github.com/armbian/build/blob/master/config/kernel/linux-rockchip-default.config and submit changed config. Changes come to the beta repository in 24h hours, if build succeeds, and in next major release when it's out. Rockchip kernel is under heavy changes and there are some known ongoing issues. I can't give you a warranty that this beta kernel will work as expected. ATM. Check this: https://forum.armbian.com/topic/7498-nanopc-t4/?tab=comments#comment-56635 If you don't need any video-related features, better move to a modern kernel and edit this configuration: https://github.com/armbian/build/blob/master/config/kernel/linux-rockchip-next.config if things you need are not present.

Well, this is set now and I guess if we add some # CMA=16 with some explanation to /boot/armbianEnv.txt ... we are done. This is wrong but I don't think it has any impact on anything. We haven't seen much useful information in /proc/cpuinfo ... and those are probably solo actions from Allwinner/FriendlyArm. Kernel 4.4? Tells zero information if you don't provide at least kernel version. I only did some inspection to their work on top of 4.14 and 4.17 and extract what was relevant.

How to determine the value of CMA from userspace?

No, I mixed this a bit. DEV = 4.17, CMA=16 while NEXT = 4.14, CMA=128 ... so only our DEV configs (also 32bit I see now) was broken here. I can control this if they upgrade with our tool, our desktop ... while for others is a bit more tricky.

Since we are not paying attention to this free issues seriously it is hard to be completely certain. We have many other problems than dealing with this in detail. Those few packages are known, while the rest is known that it's free ... but unless someone makes a study on this ... we will not put a label "Stallman free" (besides this and that) Yes, we use u-boot bootloader but certain boards (Amlogic, Samsung, ...) uses closed source 1st stage loader available only as a blob, and that is certainly not free software.

https://github.com/armbian/build/commit/731b5672780d813ac5e2cc34d5a3aa5195a92d23 I added there as well. We already have it in 32bit configuration for some time, but it was forgotten here. Then perhaps we can enforce this kind of logic: if BUILD_DESKTOP="no" add cma=16 ... else #cma=16 # enable if you run this headless to release 104Mb of memory reserved for graphics operations?

Yes! That was the problem. Thanks for the hint. Solution for current images is adding extraboardargs=cma=128M to /boot/armbianEnv.txt.

Both. I tested ob Banana M2+ and K1+, Opi Prime.