SteeMan

@zhuceluntan Please read the following FAQ post: https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first As is indicated there balbes is no longer involved in supporting Amlogic s905x cpu based boxes. Please do not direct posts directly to a specific user as that is a bad practice. That sends the message the you are expecting a specific volunteer to provide you support and that runs counter to the Armbian community support model. Volunteers help the project in the ways they can, and may use their time to answer the posts they feel they have time to. Obviously if you are engaged in a conversation with a specific person in a thread it is fine to tag them, but to log a new post tagged to a specific person is not good form.

Given the following comment posted in response to the new invalid message discussed above: "Hi Werner, I didn't realise I'd posted this as a bug I'll post it elsewhere" I took another look at the language in the big red warning message that is displayed for people posting new topics in the bug tracking forums. While it would seem obvious to those of us on the inside what we are trying to communicate, to the novice user I think there is room to make it more clear. To that end I have the following suggested wording changes: Current text: Wait! To avoid common mistakes when opening issues use this form to make sure you have collected all necessary information and create your issue report at the correct place: >> https://armbian.com/bugs << Issue reports that are not following these guidelines will be removed without further notice! Suggested text: Important Please Read Before Posting a New Topic (Bug Report)! You are about to post a new topic in the Armbian Bug Tracker. Armbian uses the sub-forums under "Bug tracker - supported boards and images only" as it's public facing bug reporting system. If you really intend to report a bug please fill out the following form to supply the necessary information for a valid bug report: >> https://armbian.com/bugs << With limited resources the Armbian project is only able to spend time investigating bugs where all the requested information has been provided and for only the boards/images/software that are supported. Your bug report will be considered invalid and receive no attention if you do not supply the requested information. If you only have a question or are looking for help on something in general related to Armbian, you should be submitting your question in one of the "Community forums", such as "Common issues / peer to peer technical support" or "General chit chat", not in this bug reporting forum.

I don't see a problem with using the invalid label as it is invalid according to the directions the user has read (or not read). What I think would improve this is giving the user more direction on what to do next. I think some working changes in the post that closes the thread as invalid would be all that is necessary. So instead of: Your issue report is invalid for one or multiple reasons (non-exhaustive enumeration): it has been stated at the wrong place it lacks fundamental requested data it could have been easily solved by a quick search and/or reading documentation unsupported userspace/image/SBC Since you refused to use the bug reporting form carefully and follow the information there as you have been asked for we have no intention to further investigate. Please add missing information if applicable. https://www.armbian.com/bugs Something like: 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 - it is for software that isn't 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") I think this softens the tone and tries to help the user do the right thing. Which they likely still won't

Moved topic to the proper forum for TV Boxes

@lcapriotti thanks for uploading that file. That file is identical to hexdump's sm1-u-boot.bin file linked to above. The mystery remains why you originally had the same issue that I am seeing with the tx3 box not being able to access emmc with this u-boot. But as you report you are no longer having that problem.

@Ruf73 Have you read the Read This First FAQ item: https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first/ I mention that as I want you to have proper expectations on what you are likely to be able to accomplish. Also it would be helpful to hear what you are trying to accomplish? If I read your past posts, it sounds like you have a working environment with a 5.44 build. Why isn't that good enough? As you attempt to go from the legacy kernel of the 5.44 build (3.10.108) to a mainline kernel (5.x) you will certainly end up with less functionality that will work. Why is this you may ask. Well the legacy kernel has all the proprietary and custom code that the device/board manufacturer put together to get this shipped. In mainline kernels all of this needed to be reimplemented from scratch in a clean supported manner for inclusion into mainline kernel. Sometimes the mainline implementation needed to be done without any support from the board manufactures and/or without source code. One area that this is particularly noted is that the formats and contents of the dtb files have changed significantly between legacy kernels and mainline (which is why you can't use an old dtb) The other significant difference as previously mentioned is that mainline does not support nand storage.

@lcapriotti It would help me if you could provide the following information from your TX3 box: 1) what dtb are you using in extlinux.conf 2) what kernel version are you booting with 3) what is the file size of your /boot/u-boot.emmc file

Specifically mainline kernels (i.e. 5.x) do not support nand, only emmc. If you have nand and want to install on it, you are stuck with legacy vendor kernels (3.10 - 4.4, depending on your box).

One of the interesting features of extlinux.conf is the ability to present a boot menu. I have played around with it a bit to have different kernel versions installed and switch between them at boot time. With a boot menu and hdmi support in u-boot, it brings some nice capabilities.

Thank you very much for this information. The most important part of what you said above was that the chainloaded u-boot is relatively simple to build. With that information in hand I could approach your github repository knowing what I was looking for. I was able to successfully rebuild the sm1 chainloaded u-boot that should be identical to the one you have linked to above in this thread. For others who read this thread, this is what you need to do. Follow the instructions found in hexdump0815's github u-boot-misc repository in the file readme.gxy (https://github.com/hexdump0815/u-boot-misc/blob/master/readme.gxy) You only need to look at the 15 lines in the readme file titled: # building u-boot summary is you pull the v2020.10 u-boot source, apply one patch file, choose the correct config file and then run make. The resultant file you want will be named: u-boot.bin @hexdump The patch and instructions mention uEnv.txt, but this build seems to work fine with extlinux/extlinux.conf files for configuration. Is there any reason you added the uEnv.txt support? Other than the fact that this is how balbes150's builds traditionally did their configuration, even though he transitioned to extlinux.conf before he dropped support for amlogic. Next question looking at your patch file, is about the changes to meson64_android.h where you simply remove a bunch of code. What purpose does this code removal serve? Your commit message says "get rid of android gpt verify errors on boot"

Thanks for the pointers. Here is what I am seeing (without a SD card inserted) => mmc list sd@ffe03000: 0 sd@ffe05000: 1 mmc@ffe07000: 2 => mmc dev 0 Card did not respond to voltage select! => mmc dev 1 Card did not respond to voltage select! => mmc dev 2 unable to select a mode I am assuming that device 2 should be the emmc. If I insert a SD card then mmc dev 1 changes (as expected) to: => mmc dev 1 switch to partitions #0, OK mmc1 is current device Note that the post above by @lcapriotti (https://forum.armbian.com/topic/16753-chainloaded-uboot-images-for-amlogic/?tab=comments#comment-119271) is I think reporting the exact same issue on the same hardware (TX3 X3). That post has screen shots of the boot - first screenshot of boot failing from emmc, and the second screenshot of a sucessfull boot from usb. These mirror my testing results. Any pointers on where to go from here?

I moved this to the TV Box General Chat forum, as there is nothing to indicate this is CPU specific. Congrats on getting your box up and running. The issue you are reporting in userland software (i.e. debian software installed on your hardware) likely has nothing to do with armbian. Your best bet is going to continue to follow the paths you have been looking at (debian / openvpn forums) where the specifics of your software are discussed. There aren't many people around these forums that are likely to be able to help on an issue like this. However, you never know and someone may be able to offer some advice.

@hexdump My goal (although I may not have the developer skills to pull it off) is to attempt to do as you suggest. I just haven't had the time recently to make much progress. As I am learning the ropes, the first thing I am trying to do is to re-base the work balbes150 did on a currently supported LTS kernel (5.10) or something newer in the future. Changes introduced in 5.10 have made that difficult, but this weekend I did make some progress. But that led to a situation that I want to ask you about. Since I am picking up on balbes150's work, I am currently following the same methods (using the internal boot loading to chain load a newer boot loader). I am using the u-boots you link to above as they seem necessary to get 5.10 kernels to load from my what I have experienced so far. Things are working pretty good on my s905x2 box (H96MaxX2), I have that box working fine from both SD card and emmc (couldn't boot from usb however). My question for you is related to the s905x3 (TX3X3 box). On this one I can only get booting from usb to work (in fact I am running the box right now with a 5.10.25 kernel from usb). However it appears that there is an issue with your sm1-u-boot.bin and emmc. Since I have things working from usb, I have installed from usb into emmc. AFter removing the usb stick, upon reboot the native uboot correctly loads and starts your chain loaded uboot. So the native uboot is able to read the /boot partition from emmc and chainload the newer uboot. But the sm1-u-boot.bin is not able to detect/configure/use the internal emmc. Since it can't read emmc, it can't read the saved uboot environment so ends up using a default set of environement values and tries to do a network boot. After if fails the network boot, it drops to a busybox shell. I am basing my statement that it can't detect/use emmc based on my exporation of the system from busybox. Do you have any thoughts/suggestions? On another related topic, I have poked around your u-boot repositories and am wondering how difficult it would be for me to acquire the skills to be able to build/re-build your u-boots? I have looked as some of your notes and it looks like there are a lot of steps involved and many of those seem to be manual. Is there a good how-to that is u-boot newbee friendly that would get me to the point of just rebuilding what you have posted?

@isidoros First please read the TV Box Club FAQ item: https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first (short version is that TV boxes are unsupported by Armbian, amlogic bases ones even less so). Second you mention coreelec and libreelce but not armbian in your post. From what I can tell in your logs you aren't running armbian at all. Thus you should be posting for help in a libreelec or coreelec forum as we can't support their software.

Have you read the thread dedicated to TV boxes with your CPU: https://forum.armbian.com/topic/12656-csc-armbian-for-rk322x-tv-boxes

moved topic to the correct forum

@mazdlc Thanks. Would it be possible to create a patch/diff between your dts modifications and those in the mainline kernel source tree? And then post that either here or in your github? That way as the code evolves others could easily pick up your work and port it to newer kernels if necessary in the future.

3.10 kernels are almost 8 years old, and haven't been supported for years. Most armbian work is focused on mainline kernels now days.

Note that guidol's comments above are for supported armbian boards, the TV box builds do not work the same way as they are a fork of the core armbian.

You can't install armbian kernels on the balbes150 TV box builds. The file layouts are not compatible. TV boxes are not supported, there are not upgrade paths for the kernels. (Maybe someday, but not today). Also there are no builds that support the amlogic s9xx cpus after 2020-10-14 as the developer who was working on them dropped support for them at that time.

There are not kernel sources as these TV box builds are not official armbian builds and are unsupported. See the TV Box Club FAQ entry: https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first

Have you read this thread: https://forum.armbian.com/topic/3023-armbian-for-amlogic-s805-and-s802s812 The most recent balbes150 builds for s8xx cpus can be found here: https://users.armbian.com/balbes150 I don't have any s8xx based boxes so I can't provide any more specific instructions, but in looking at the files in the boot directory of the image, the instructions are likely to be similar to the s9xx instructions found in the TV Boxes FAQ (however it looks like these builds still use the uEnv.txt instead of the newer extlinux/extlinux.conf in the s9xx instructions).

I split this from the original thread as this no longer has anything to do with the topic of the original post. Also move to the rockchip box forum.

DTBs are kernel version specific as they are the mapping between the physical hardware and the kernel. While you might be OK with a minor different in kernel versions, a dtb from a 5.x kernel will not work with a 4.4 kernel (4.4 is about five years older than a current 5.x kernel).

This may be related to the issues we are seeing with rebooting: https://forum.armbian.com/topic/16614-armbian-v2102/?tab=comments#comment-120642