Werner

The more interesting question is why do you want to spend cash on a shitty tvbox without proper hardware/software support instead of checking if something that is actually well supported does fit your needs too? All supported devices https://www.armbian.com/download/?device_support=Supported

No. Use code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } armbian-config to freeze firmware and wait until 21.08 is released. Expected by end of August.

In short term, yes. This is the workaround for the issue. However somewhen we need to move forward again. Most likely when this issue is solved upstream. You can try to build a recent u-boot package from scratch using our build tools and then follow this guide: https://docs.armbian.com/User-Guide_Recovery/

https://github.com/armbian/build/issues/3066

None of them.. Read the topic mentioned above again for suggestions to solve.

https://github.com/armbian/build Build one yourself. We do not provide every OS for ever board since it is way too much and our resources are limited.

Mandatory for proper testing. Everyone who tinkers with SBCs should have such a thing. Also they are dirt cheap.

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

Limiting posts for new users is unfortunately necessary to fight spam. Limits are lifted automatically after a few days or instantly by supporting Armbian through a subscription.

Short answer: No. This cannot explained with just a few sentences. Start reading about the differences between x86 and ARM architecture.

Docker?

Moved to proper forums.

Are you willing to pay for the cost? Check personalized support here: https://github.com/armbian/build#support

Probably a mistake since Armbian 21.08 has not been released yet. Should not cause harm though.

Your issue report is not a valid bug report per the Armbian bug reporting instructions (https://www.armbian.com/bugs). With limited resources the Armbian project is only able to spend time on issues where all the requested information has been provided and for only the boards/images/software that are supported. Your report is invalid for one or more of the following reasons (non-exhaustive list): it is for an unsupported board or image (CSC/EOS/WIP/edge) it is for software that is not supported (such as userspace modules installed on top of the core operating system) it has been logged in the wrong forum (for example requests for help that are not actual bug reports) it lacks requested data (armbianmonitor output) it could have been easily solved by a quick search and/or reading documentation Please review what you have submitted and the bug logging instructions (https://www.armbian.com/bugs) and either add the required information or open a new topic in the correct forum (such as Common issues / peer to peer technical support or General chit chat)

Via dpkg. However if you don't know that by yourself I suggest not to try to and end up with a broken system. Grab a fresh image from https://www.armbian.com/helios4/ and boot from that one. Try to recreate the issue.

Which image/s exactly? And Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

All your firmware packages are way outdated. Consider upgrading to supported packages.

Retried with a stable build? Means if somebody in the community has an idea it could get addressed, otherwise not.

Tvboxes are maintained by community members and can be different from official Armbian in any shape or form so documentation might not be matching these images.

Check WIP/CSC menu. Official support for Ebin has been dropped quite a while ago.

Was bored anyways: https://github.com/armbian/build/pull/3057 Checkout PR branch, build image and test.

Feel free to provide PR https://github.com/armbian/build

1st. This thread is about the Station P1, not P2. 2nd. For RK3399 at least it is normal that the boot order is SPI, eMMC, SD. If there is a valid boot loader found on either SPI or eMMC it will boot from there. Armbians workaround for this is to put a bootloader in that redirects on microSD first and if that was unsuccessful to use default order. Other operating systems often don't do that.

Just built a pine64so image without problems*. If the image actually boots and if so is even stable I cannot tell since I do not have such a board. Something is wrong with either your build host or internet connection. I suggest to start over with a clean build host, clean workspace (git clone build repository) and proper internet connection. *had to change uboot version to 2021.07 due to unrelated issues with the rollback to 2020.10