emmc install issues with Tronsmart Vega S95 Telos

[DWP]

Hello and thanks for this great posting. I have a Tronsmart Vega S95 Telos. The boot logo from AmLogic says simply S905 and that matches my understanding of the unit.

 

I managed to boot Armbian from the SD card using the reset button. I played with it for a while and all seemed very good. So I went ahead and executed the /root/install-aml-s905-emmc.sh script. In general it seemed to work. Took a huge amount of time, especially in copying USR. But it did complete. However, when trying to boot thereafter all I get is a black screen for many minutes. Finally, I gave up and pulled the plug.

 

Has anyone any idea what I might be doing wrong here? Thanks so much.

[DWP]

As an update... I mis-spoke earlier when I said all I get upon reboot is a black screen. What I get when I reboot is the Android that was installed before I did all this. This implies that the whole copy to emmc did nothing. Here is a link to some shots of the progress of the /root/install-aml-s905-emmc.sh if that can help point out the problem. Thanks again!

[SteeMan]

Moved to separate thread

[SteeMan]

That script is fairly easy to follow the logic if you look at it.  I don't have a s905 based box, so I can't test it personally.

It would appear based on your report that the script misidentified the sd card as the emmc and overwrote the sd card (which is why you can still boot android), but that is just a guess.

[DWP]

Hi SteeMan and thanks!

 

I have continued to fiddle with all of this. When I started, I was NOT on the true, stock, Android firmware for this box. I had installed alternate ROM. I finally considered this and went to the stock firmware before I started this process over again. I also more closely read your post (having glossed over the important part about looking for other dtb files (perhaps it would be good to BOLD that) and found there is one for my specific box - or so it seems based on the name. This way, things looked a bit more clean during the initial boot from burned SdCard, etc.

 

Having done this (but perhaps it was the same before - only I had not noticed it), once the copy script completes if I reboot the device without removing the SdCard, I find that the device does in fact boot directly into Armbian and starts the desktop. However, if I remove the SdCard and reboot, I get Android still. So it would appear that part of the boot code has made it into EMMC but also that the entire reset of the system did NOT.

 

When the system runs directly at power on the disk layout looks like this. I assume that mmcblk0 is the SdCard. Is this right?

 

Here is fdisk -x output:

 

Disk /dev/mmcblk0: 59.64 GiB, 64037584896 bytes, 125073408 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x80e20d40

Device         Boot   Start       End   Sectors Id Type                Start-C/H/S   End-C/H/S Attrs
/dev/mmcblk0p1         8192   1056767   1048576 ea Linux extended boot     0/130/3    65/199/6
/dev/mmcblk0p2      1056768 123797504 122740737 83 Linux                  65/199/7 1023/254/63


Disk /dev/mmcblk1: 14.56 GiB, 15634268160 bytes, 30535680 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mmcblk1boot0: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mmcblk1boot1: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/zram0: 961.96 MiB, 1008689152 bytes, 246262 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/zram1: 50 MiB, 52428800 bytes, 12800 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

 

After looking at the output of the install script and its source, I can see it has latched onto mmcblk1 as the emmc target. But in the code is it looking for mmcblk1p1 for the boot part and mmcblk1p2 for the root part. Neither exists it seems. There are mmcblkboot0 and 1 but I am not sure what might be done with them as they are smallish (4MB).

 

I am in really far over my head here...

 

Cheers

Edited December 9, 2022 by DWP
Added more info. Thanks!

[SteeMan]

The script is supposed to create the p0 and p1 partitions you say are missing:

(from install-aml-s905-emmc.sh)

...

mkfs.vfat -n "BOOT_EMMC" $PART_BOOT

...

mke2fs -F -q -t ext4 -L ROOT_EMMC -m 0 $PART_ROOT

 

[DWP]

Thanks once again SteeMan!

 

I see those lines in the script too.  So this is confusing to me. In the output of the script's execution, seen here, those commands appear to fail as the files in /dev are not there. This is also seen in the fdisk output and looking for them with ls /dev. And I just don't know why this might be or what to do about it.

 

One thing I might try is that the stock firmware I installed was the latest edition. Perhaps I should try flashing the earliest and re-try all of this? Maybe things were different originally?

 

Cheers

[DWP]

Well, I installed the very most ancient firmware I could find for this box. However, nothing I could do would make the box boot from the SdCard. I re-created it, still nothing. Rats!

[DWP]

SteeMan,

 

I have looked at the documentation for the mkfs.vfat and mke2fs commands and it sure looks to me like these commands expect the device named on the command line to exist. There does seem to be an option on mkfs.vfat (-C) that will create something but that is not what the script is doing. It seems to fully expect that the files in /dev will exist. And they clearly do not on my box. I have no idea why.

 

Thanks

[SteeMan]

So I have been looking at the two scripts in /root (install-aml.sh and install-aml-s905-emmc.sh).  Basically the only difference between the two is that s905 version assumes that p0 and p1 exist, where the other version creates the partitions.  Since I didn't author these scripts (but now find myself maintaining them), I don't know why this difference exists in the scripts.  And since I don't have an s905 box, I've never been able to test the s905 version.

 

Since you seem to have an s905 box that doesn't have the partitions that the one script expects, you could try to run install-aml.sh instead.  It seems you have the ability to restore the andoid image if necessary.  So unless you really brick the box hard, you should be able to recover if the other script doesn't work.

[DWP]

Thanks once again SteeMan! I went ahead and ran the install-aml.sh and it appeared to do the right thing. I saw it created the mmcblk1p0 and 1 partitions on mmcblk1. It did leave behind some of the other partitions like mmcblk1boot0 and mmcblk1boot1 but that didn't worry me too much. Here is the results of an lsblk command.

 

Once the install script was completed, I shut down the system and removed power. I then removed the SdCard and re-powered the system. I waited and waited but got nothing but a black screen. Rats!

 

I again removed power, re-installed the SdCard, and re-powered. I waited and waited but got nothing but a black screen. Double rats!

 

So I again flashed the Android firmware, let it complete its install, shutdown and booted again from the SdCard. I note that I had to once again use the reset button in order to get into armbian. However, this seems to have been needed only for the 1st boot and since then I am back to where I was.

 

So I wonder if I need to do something with the u-boot that is different? Like use the 905-x version instead of the plain 905 version?

 

One step forward, one step back 🙂

 

Cheers! And thanks again for all of your time and help.

 

 

[hexdump]

@DWP - running s905 from emmc is very complex and far from easy - you can have a look at this thread to get an idea about this topic:

 

[DWP]

Thanks hexdump. Until now I have been following SteeMan's excellent discourse on this subject. Since I have a Tronsmart Vega S95 Telos with stock firmware flashed, and since the downloaded distro seems to have a DTB named for this specific device as well as a uboot for plain, old s905 CPUs, I had hoped things would be easier. I had little trouble getting things running from the SdCard and perhaps I have to live with that. It may be ok for my minimal needs (running Heyu). But I had hoped to get things going from emmc. I am in way over my head - as my posts prove - so this may just not be attainable.

 

Cheers

[SteeMan]

@hexdump Thanks for that link.  I just read through the whole thread and this other one that is referenced therein (https://forum.armbian.com/topic/18902-s905-failed-to-boot-from-emmc).

It is clear that no one has been able to work around the fact that the mbr info is incompatible with the android uboot on the s905 based on all the smart people that have looked at the problem.

The workaround that @pista used is the best out there, but because it directly writes the boot files (kernel, etc) to emmc, it isn't a good solution IMHO as it is not compatible with a standard apt update of the kernel (which the new aml-s9xx-box builds support)

 

I have found that the "op hub" fork perhaps has found a solution by using the ampart tool (https://github.com/7Ji/ampart)

 

Since I don't have an s905 box, I really can't do much.  And since the s905 boxes are by now ancient it isn't really worth my time to get one and go down this rabbit hole.  However I do plan to remove from the aml-s9xx-box builds the install-aml-s905-emmc.sh script as I don't see how as written it can ever work and update the install instructions accordingly.

 

 

[hexdump]

@SteeMan - interesting, i did not know about ampart, but as you said: for s905 it is better to still just run from sd card as trying to boot from emmc is quite complicated and risky to brick the device