SteeMan
-
Posts
1962 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by SteeMan
-
-
Moved post to the correct forum
-
@Sevillano I'm not quite sure what steps/instructions you are following. But start by reading the two TV Box FAQ posts: https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first and https://forum.armbian.com/topic/17106-installation-instructions-for-tv-boxes-with-amlogic-cpus
There aren't steps that require you to compile the entire system on a virtual machine. So I am assuming you are trying to perform a regular build of armbian, but armbian doesn't support TV boxes. That is why this forum exists and there are the forked builds that attempt to get a working environment on amlogic based boxes.
You will most likely need to find an original android firmware and restore your emmc to a good working android before moving forward.
-
I am assuming you can still run from the SD card. What steps did you take to install to emmc? What dtb are you using (have you tried others), what u-boot.ext file are you using?
-
17 hours ago, Daniel Cagarrinho said:
wen I reboot the box the os cannot start properly
Can you provide anymore information? When you say the box doesn't start properly what exactly do you mean. Especially as you also said you have wifi working. Those two sentences seem to contradict each other, so there must be more information that you could share. Also is this happening from an install on SD or emmc? When did it stop working? What changes did you make between successfully working and your new problems?
-
When you say you are trying to flash Armbian_20.10_Arm-64_buster_current_5.9.0.img.xz what do you mean by that? Specifically what steps are you doing? Are you following the instructions in fhe FAQ: https://forum.armbian.com/topic/17106-installation-instructions-for-tv-boxes-with-amlogic-cpus
-
@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.
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
-
-
31 minutes ago, lanefu said:
Interesting I'll have to learn more about extlinux.conf
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.
-
17 hours ago, hexdump said:
i can only encourage you to try to build your own u-boot - this is how i started as well ... you just need patience and time to move forward ... building amlogic u-boot is not really easy and a lot of steps are required (this is actually the reason why i started this u-boot repo to kind of document all the info, which is usually spread across many places in once place), but the good thing is that the u-boot binary you need for chainloading is just the result of a simple u-boot compile and you can ignore all those many signing etc. steps required if you want to build a full mainline u-boot for amlogic ... this (full mainline u-boot) is working too but far from easy and there is always the risk to brick the box if it is too non-standard - i have a few amlogic boxes working this way, but this approach is nothing i would recommend in general, especially as the chainloading is working quite well.
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"
-
16 hours ago, hexdump said:
@SteeMan - on my s905x3 box the emmc has died, so i cannot test it there right now, but i'm very sure that it was working before at some point ... it might be that the mmc/emmc setup of your box is a bit different than normal and thus the chainloaded u-boot fails ... what you can try is to interrupt the chainloaded u-boot and then play around with the mmc command - "mmc list" might be a good start and list you all the mmc devices u-boot knows about and which can be sd card, emmc and sdio (which is usually the wifi card using the mmc connection as well) - after you have that list you can go through them and see which are discovered as sd/emmc via "mmc dev 0" (same for 1 and 2 if they are shown with mmc list) and then "mmc info" - sd card and emmc you can then usually distinguish by the size shown if you have different sized ones (the sdio port usually does not respond, so you should end up with two working mmc info, one for sd and one for emmc) - if you only get one working here then emmc is indeed not detected properly and you'll have to look deeper - if all are well, then maybe somewhere in the boot scripts an id number is wrong?
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.
x96 Max+ VFD/LED display
in Amlogic CPU Boxes
Posted
First please read the following FAQ item in the TV Box FAQ: https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first
In that FAQ post you will see that no one is any longer supporting amlogic s9xx TV boxes. So you have the following hurdles: TV boxes are not supported by Armbian. The developer (bables150) who was working on these boxes in his community fork no longer is (but he never supported the x905x3 even when he was working on amlogic), and this is such a low priority type of item, that it wouldn't likely get attential anyway (see the setting expectations part of the FAQ item).
Since you posted this same question three times in the forums, I will be deleting the duplicate posts, leaving this one.