SteeMan

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

Igor, could you point me to a description and/or the fix for this issue? This is an issue that I am having with meson64 based TV boxes and it has also been reported by others in the TV Box club. I want to see if this fix addresses the issues we have been seeing - or if we have a different issue.

@Mohammad Shami Please read the two posts in the TV Box Club's FAQ forum

@andress187267If you think docker is essential for your use cases, we welcome your contributions to the armbian community to make that happen. That is what open source is all about. We certainly need many more volunteers to do all the work around here.

@zaqwsx12 Please read the FAQ post in the TV boxes FAQ forum: https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first Note that balbes150 no longer supports Amlogic CPUs. There are other posts in the TV box forums that describe building your own kernel. Please search the archives.

Moved thread to the TV box club forum for Amlogic boxes.

@lary I move your post to the appropriate forum. There are two items in the TV box club FAQ and you should read both of them. The first is about status of support of TV boxes and the second talks about how to install on Amlogic boxes like you apparently have.

@Slackstick The image name you have quoted doesn't resemble any armbian build I am aware of. Where did you find this image you are trying to install? If it isn't armbian based then this is not the correct place to be asking your question.

Moved to a new thread as this was posted in a thread dealing with a different box.

It wasn't dropped, it was never added. The legacy 3.x kernels are the vendor supplied kernels which take a base kernel and add a bunch of customizations on top (some with and some without source code). The mainline kernels are the kernels that have the hardware support integrated into the mainline code base. Because the vendors don't provide much if any support for their hardware/software, they generally don't care about getting their proprietary code/features into the mainline kernel tree. Thus while moving from the vendor kernel to the mainline kernel you end up loosing functionality. I wouldn't personally use a legacy vendor kernel. There is no support, no bug fixes, no security fixes.