Chainloaded uboot images for amlogic

[hexdump]

@SteeMan - in case you want to experiment (i.e. not sure if it really works), you might play around with chainloading the g12a-u-boot.bin (s905x2) and sm1-u-boot.bin (s905x3) from https://github.com/hexdump0815/u-boot-misc/releases/tag/200926-01 or gxb-u-boot.bin (s905) or gxl-u-boot.bin (s905x) from https://github.com/hexdump0815/u-boot-misc/releases/tag/200718-01 ... basic chainloading goes like this - https://github.com/hexdump0815/imagebuilder/blob/master/boot/boot-amlogic_gx-aarch64/s905_autoscript.txt - maybe compare it to the balbes150 boot scripts for fancier ways and most probably better armbian integration ... the files mostly exist in a serial version for serial console and another one for hdmi output and usb keyboard input (which sometimes works and sometimes not) ... better ignore the boot-xyz.dd file at the links above - they are for booting amlogic boxes without the legacy u-boot, but using them is quite complicated and risky (you can seriously brick the box worst case)

 

as mentioned all this is without any warranty or support, but it might be a good starting point for experiments

 

good luck and best wishes - hexdump

[SteeMan]

@hexdump  I have been planning to reach out to you to pick your brain.  I noticed that in the last balbes build which supports amlogic that the chainloaded s905x u-boot was from your work.  (Which happens to be the one environment that that is working on 5.10 for me).  I will definitely experiment with what you have as I really want to move all of my boxes to 5.10 as an LTS kernel that includes wireguard support natively.

 

 

[SteeMan]

I moved this to its own thread.

[SteeMan]

As I mentioned I was having problems using the chainloaded u-boots for s905x2 and s905x3 based boxes in loading 5.10 kernels (5.9 and earlier kernels have been working find).  I had a little time this past weekend and I was able to successfully boot a 5.10 kernel using your u-boot mentioned above in place of the one in balbes image for s905x2.  I was also able to do the same with a s905x3 box (boot a 5.10 kernel) but on this one ethernet didn't work.  I didn't have time to investigate anything beyond getting successful boots.

[hexdump]

@SteeMan - nice to hear that the u-boot images are working well - regarding your ethernet problem please give this patch a try: http://lists.infradead.org/pipermail/linux-amlogic/2020-December/009360.html - it fixes some messed up clocks as soon as audio is compiled into the kernel on boxes with gbit ethernet

 

good luck and best wishes - hexdump

[robertoenr]

Hi @hexdump, your work is really interesting!

Do you think the following issue could be solved with your new u-boot? Or it is a different problem?

https://forum.armbian.com/topic/16837-problems-rebooting-amlogic-based-boxes-from-emmc

 

Note: using Armbian 20.10 last from balbes for Amlogic with u-boot 2020.07

In case of "yes" any way to test it? I'm developer but not linux expert.

 

Thanks in advance!

[hexdump]

@robertoenr - it might be related or it might be not - i think there is just one way to find it out and that is to try it

 

good luck and best wishes - hexdump

[robertoenr]

1 hour ago, hexdump said:

@robertoenr - it might be related or it might be not - i think there is just one way to find it out and that is to try it

 

good luck and best wishes - hexdump

 

Sounds like a challenge! Any entry point or way to flash over the balbes image?

 

I've seen that an some files"u-boot-s905",  and "u-boot-s905x" and similar on the /boot partition. In my case renamed the second to "u-boot.ext". Should I must replace this over?

Other doubt I have is if u-boot is located on the eMMC or on the SoC internal flash, because on the previous mentioned issue the boot logo sometimes dissappeared and the reboot/shutdown doesn't work, I think it could be related with u-boot....

 

Sorry about my ignorance, I'm trying Armbian and community to learn more about linux development.

 

[SteeMan]

Let me add my limited knowledge here.  Note that the following comments only apply to amlogic CPUs.  The 'chainloading' of u-boots is designed to utilize the original u-boot that came on the device (stored in emmc) to start booting.  Then after the original u-boot has initialized everything, the secondary u-boot (the chain loaded one) is started to continue the process and load the linux kernel, ramdisk and dtb and launch the linux kernel.  This secondary chain loaded u-boot is stored in the /boot directory and named u-boot.ext.  Thus the installation step to rename the appropriate u-boot file to u-boot.ext (this file could on either SD, USB or emmc depending on where the installation is running from.

The reasons for doing things this way are to try to simplify things such that multiple different TV boxes can be supported.  Theoretically each TV box should have its own custom u-boot to fully boot correctly.  By using the existing manufacturer shipped u-boot we avoid having to build a hundred different u-boots for each device.  The problem is that these original u-boots are buggy and old so they don't support the latest u-boot functionality - like using hdmi output during the boot process.  The chain loaded u-boots are using recent u-boot source code and therefore are better.  Because the hard work of bringing the system up (memory, cpus, other devices) has already been done by the base u-boot, the chain loaded u-boot has a lot less to do and hopefully can be more generic and support multiple different boxes with one u-boot build (per CPU).

[jbolanosg]

On 1/11/2021 at 5:24 PM, SteeMan said:

As I mentioned I was having problems using the chainloaded u-boots for s905x2 and s905x3 based boxes in loading 5.10 kernels (5.9 and earlier kernels have been working find).  I had a little time this past weekend and I was able to successfully boot a 5.10 kernel using your u-boot mentioned above in place of the one in balbes image for s905x2.  I was also able to do the same with a s905x3 box (boot a 5.10 kernel) but on this one ethernet didn't work.  I didn't have time to investigate anything beyond getting successful boots.

Hi @SteeMan, Please inform me what is the step by step you used to boot the 5.10 kernel using @hexdump boot.

 

I have a s905x3 (Tanix TX3) and another s905x2 (Mecool KM3) tv box where I could try the step to step that you indicate.

 

Does that work only with Sdcard or can it also be tested with emmc?

[SteeMan]

@jbolanosg I haven't had time to test hexdump's u-boots much yet.  But the general idea is that you replace the /boot/u-boot.ext file with the appropriate hexdump uboot (g12a-u-boot.bin (s905x2) or sm1-u-boot.bin (s905x3)).  Once you verify that works with a 5.9 kernel, then you can attempt to use a 5.10+ kernel.  The testing I have done in the past was all from SD card.

BTW, the ethernet issue I was seeing I believe is this: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/boot/dts/amlogic?h=v5.11-rc7&id=19f6fe976a61f9afc289b062b7ef67f99b72e7b9 which was just fixed in 5.11.0-rc7, but hasn't yet been fixed in 5.10.y.  I am in the middle of testing that this does or doesn't fix my ethernet issues under 5.10

[robertoenr]

Hi @hexdump @SteeMan I've tried the following u-boot files on my TX3 Mini (GXL S905W), downloaded from here, on the 20.10 Focal with 5.90 kernel last balbes image:

• gxl-u-boot.bin.gz. Uncompressed and renamed to "u-boot.ext". It starts OK from USB and looks the same version as packaged on the balbes image "2020.07-dirty (Jul 26 2020 - 13:24:26 +0200) hexdump-gxl".
• gxl-u-boot.bin-serial.gz. Uncompressed and renamed to "u-boot.ext". It starts OK from USB and this is the version showed "2020.07-dirty (Oct 24 2020 - 11:34:29 +0200) hexdump-gxl".

I suppose that the gxl-u-boot.bin-serial.gz is newer than used on balbes, but I don't know what's the difference with the other. I'll try to install to eMMC in order to see what happens...

 

Does exist a more recent version of u-boot for gxl s905w ?

In my case with the "2020.07-dirty (Jul 26 2020 - 13:24:26 +0200) hexdump-gxl", included on balbes image, installed on the eMMC, the "TX3 Mini" boot logo dissapear and more important: frequently it keeps black screen and does not boot (the black screen shows instead the boot logo).  Do you think this is related to the chainloaded u-boot? When this happens it doesn't show nothing about the "2020.07 dirty..." so I suspect this issue happens BEFORE. What's your opinion from expert side?

 

Update: I've tried the "gxl-u-boot.bin-serial.gz" in eMMC install, and the black-screen-non-booting issue still happens.

 

I upload the original TV Box u-boot dump done by the "install-aml.sh" script called "u-boot-default-aml.img". Could be something wrong with this?

 

[SteeMan]

@robertoenr Based on what you described you have done, you a doing a lot of work you don't need to.

First off, the Oct 14, 2021 Balbes images already have the u-boots from hexdump for the s905x (and therefore s905w) cpu.  The one you downloaded and are trying is the same as what is already in the image.  My comments above all talk about the s905x2 and s905x3 which don't have hexdumps u-boots in the balbes images.

.

My strong recommendation is to do all your testing on an SD card install, get that working the way you want, then copy the working environment from SD card to emmc using the install-aml.sh script.  Experimenting with u-boots and kernels directly in the emmc environment is asking for a bricked box, as any number of simple mistakes can lead to the box not booting correctly.  If you make those same mistakes on and SD card, you simply pop it into another machine and edit/undo what you did and try again.

.

[robertoenr]

10 minutes ago, SteeMan said:

@robertoenr Based on what you described you have done, you a doing a lot of work you don't need to.

First off, the Oct 14, 2021 Balbes images already have the u-boots from hexdump for the s905x (and therefore s905w) cpu.  The one you downloaded and are trying is the same as what is already in the image.  My comments above all talk about the s905x2 and s905x3 which don't have hexdumps u-boots in the balbes images.

.

My strong recommendation is to do all your testing on an SD card install, get that working the way you want, then copy the working environment from SD card to emmc using the install-aml.sh script.  Experimenting with u-boots and kernels directly in the emmc environment is asking for a bricked box, as any number of simple mistakes can lead to the box not booting correctly.  If you make those same mistakes on and SD card, you simply pop it into another machine and edit/undo what you did and try again.

.

 

Thank you do much for the advice!

 

But since the "non-booting-black-screen" issue only happens once installed on eMMC, how can I test it by using SD/USB?

[SteeMan]

@robertoenr

8 minutes ago, robertoenr said:

But since the "non-booting-black-screen" issue only happens once installed on eMMC, how can I test it by using SD/USB?

That wasn't at all clear from your posts that that was the case.  So you have a working SD install, and when you run install-aml.sh to move that install to emmc, that is when you are seeing this issue?

[SteeMan]

@robertoenr FYI.  I just installed into emmc on my Tx3 mini and it boots fine using u-boot-s905x-s912 copied to u-boot.ext along with meson-s905w-tx3-mini.dtb

[robertoenr]

18 minutes ago, SteeMan said:

@robertoenr FYI.  I just installed into emmc on my Tx3 mini and it boots fine using u-boot-s905x-s912 copied to u-boot.ext along with meson-s905w-tx3-mini.dtb

 

Yes, initially usually works, but try to perform this actions:

• Make the internal WIFI works and connect to WIFI network. Mine is AP6330 wifi chip, so use these lines:

sudo mv /lib/firmware/brcm/brcmfmac4330-sdio.txt /lib/firmware/brcm/brcmfmac4330-sdio.txt.old
sudo ln -s  /lib/firmware/brcm/brcmfmac-ap6330-sdio.txt /lib/firmware/brcm/brcmfmac4330-sdio.txt

 

• Try to reboot/shutdown several times (in my case sometimes the previous step is enough to reproduce the fail). If not perform more actions.
• Change the keyboard layout with armbian-config (mine to ES). Try to reboot/shutdown several times.
• Change the timezone with armbian-config (mine to Europe/Madrid). Try to reboot/shutdown again.
• Change the language with "Language support" desktop application. In my case to ES. Reboot again.
• apt-update && apt-upgrade. Reboot again and check.

 

The key is to perform many reboots/shutdowns between steps to provocate the devil

 

Note that my TX3 Mini is 2021 model with board "CS_905W_TX_2C_N_MK_V1.6". It could be not the same as yours. That's the reason why I upload my original u-boot dump.

[robertoenr]

3 hours ago, SteeMan said:

@robertoenr

That wasn't at all clear from your posts that that was the case.  So you have a working SD install, and when you run install-aml.sh to move that install to emmc, that is when you are seeing this issue?

 

Yes, when running from SD/USB the issue is not present. It only fails when installing on eMMC

[hexdump]

@SteeMan already explained very well how my u-boot files are supposed to be used ... some notes regarding those u-boot files: for most of them i built two versions: one with "-serial" in the name - they have serial console support enabled and hdmi/usb kbd support disabled and the other version is without "-serial" and has the serial console disabled and hdmi/usb kbd enabled. i built those two versions as i noted that leaving both consoles (serial plus hdmi/usbkbd) enabled together did not work reliable - it looks like noise on the serial line in this case can confuse u-boot (so that it hangs), especially if wires are connected to the serial console ports on the board but no serial console being connected to them. it might be that the g12a and sm1 version still have the serial port enabled in the hdmi versions - i do not remember exactly anymore if i rebuilt them completely - an easy test would be to check if there is still serial output while booting. an easy cure to avoid serial noise problems in such cases is to simply connect a serial port to usb adapter to them and plug the usb part of that adapter into the box - this way everything is grounded properly and and there is no noise anymore - this works very well for me for my test boxes with serial ports soldered onto them.

 

something which is a bit different with those u-boots is also that they read a files call uEnv.txt instead of the armbianEnv file.

 

best wishes and good luck - hexdump

[lcapriotti]

On my s905x3 (Tanix TX3) I have used sm1-u-boot.bin replacing u-boot.ext on the SD card, and have consistent success in booting from SD card - something that it not the case with the original u-boot from Armbian_20.10_Arm-64_focal_current_5.9.0.img. I can access the emmc once booted from the SD card.

However, the box does not boot after installing into emmc, as the emmc is not recognised.

 

[SteeMan]

@robertoenr FYI, the information in this thread: https://forum.armbian.com/topic/8728-s905w-boot-process

is helpful in learning the boot process (see especially Jock's post).  Jock maintains the builds for rk3228/rk3229 based TV boxes.  His approach is more of a 'pure' armbian environment than the balbes approach of reusing the android boot loader, but his explanation of the process is good.

[hexdump]

@SteeMan - but it is important to be aware that the boot process for rockchip, allwinner and especially amlogic is very different in the detail and for amlogic there is a high risk to brick a box if you try to completely replace the boot loader like it can be done quite easily for allwinner or rockchip. it could even be done for amlogic (i'm running several boxes this way) but its too complicated and risky to do it this way.

 

btw. when installing to emmc it is very important to not overwrite the beginning of the emmc as the legacy u-boot searches for its dtb somewhere there and will not work if it cannot find it. this is why balbes150 did always ignore the first 700 mb of the emmc and later even over a gb to avoid this potential problem.

 

regarding the emmc boot hang if the bootloader is called from emmc there might be some strange interconnection between legacy u-boot and chainloaded u-boot which is hard to impossible to track down as there are too many unknowns (most probably legacy u-boot leaves something around the emmc in a state which is confusing the chainloaded mainline u-boot afterwards). in this situation the only option might be to boot from a small sd card and put the root fs onto emmc.

 

best wishes - hexdump

[robertoenr]

3 hours ago, hexdump said:

regarding the emmc boot hang if the bootloader is called from emmc there might be some strange interconnection between legacy u-boot and chainloaded u-boot which is hard to impossible to track down as there are too many unknowns (most probably legacy u-boot leaves something around the emmc in a state which is confusing the chainloaded mainline u-boot afterwards). in this situation the only option might be to boot from a small sd card and put the root fs onto emmc.

 

The curious thing about the boot hang from eMMC is that, when it happens, you plug the USB with the bootable armbian and start with it once. After that, the issue is fixed. Next time you can boot without the USB and it starts OK from eMMC. It does until the issue happens again randomly other day. From the first time when the issue happen, the boot logo from manufacturer is replaced by a black screen, even when it's repaired with this method.

 

The fact is that the chainloaded u-boot file in eMMC is the same on USB. And the bootloader+legacy u-boot remains the same at the begining on eMMC.

I've seen the issue in a TX3 Mini and on a MXQ PRO 4K 5G, both with S905W, but totaly different boards. Also, @SteeMan and @lgranie have seen the same issue on their TV Boxes frequently.

 

It's like booting from external media on this situation, changes some state...

 

Note: on my 2 TX3 Mini I always must boot armbian from USB. Multi-boot from SD card doesn't work never.

[hexdump]

 @SteeMan - just to come back to what you said about the jock builds for rk3288 and rk322x: i think the only way to get the amlogic tv boxes somehow supported in armbian is that someone is or even better a few people are starting to setup and maintain a proper csc line for them like jock did for rk3288 and rk322x - it will not work in the long term to try to support them based on old balbes150 images and a lot of hacks around them ... i'm not having the time and energy to step in here, but i think all the information should be there based on the research balbes150, various others and me have done around those boxes over the last years, there is just someone needed to sort all this information properly and bring it into the armbian build system

[SteeMan]

@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?

[hexdump]

@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?

 

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.

 

good luck on your path and if you run into concrete problems let me know either here if it has some direct relation to your armbian setup or just create an issue in my u-boot repo in case it is a bit too off topic for here.

 

best wishes - hexdump

[lanefu]

I havent read the whole thread so im just kind of chiming in anyway.

 

 i could be wrong but how the "chainloading" typically works in out world is that the first uboot stage loads...   and then it can pick up the second stage / SPL (secondary program loader) on another device if the first stage uboot is able to do it.

 

Other implementations like petitboot are actually using the system uboot and then loading a tiny linux and using kexec to load kernel from other devices similar to how you might boot another linux. By updatting grub.cfg

[SteeMan]

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?

 

[SteeMan]

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"

 

[lcapriotti]

2 hours ago, SteeMan said:

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?

 

 

Note that since then I was able to have a rock solid boot from emmc, but I lost track on how I was able to achieve it... 

If there is anything I can provide pls let me know