Strange, i have only the 1g version and use the gxl_p212_1g.dtb. I have no idea, i can only say, that the Box runs with installed coreelec.
CoreELEC (official) nightly_20200723 (Amlogic-ng.arm) has been successfully migrated from USB Flash Drive to eMMC with the Team CoreELEC ceemmc command line tool.
These instructions are for MS Windows 10 but can easily be modified for other environments.
Step 1 can be skipped if the TV Box is already running the latest Nougat 7.1 Firmware
- Update to the latest NexBox A95X Nougat 7.1 Firmware
- With the Rufus utility, create a 2 GB bootable USB Flash Drive containing CoreELEC -ng nightly_20200723
- Boot the TV-Box from USB and enable SSH
- Create SSH tunnel from Windows 10 PC with Putty and run ceemmc -x
NOTE: I had to run ceemmc -x twice.
I noticed the first time the ceemmc command line tool only migrated the flash partition. After running the command again, both flash and storage partition were migrated.
Here is the Putty capture log: https://pastebin.com/AAT6nAjU
The log shows
storage partition was copied successful on first time already. It was only ~4MB so maybe you where thinking nothing was copied.
Nothing was migrated to storage the first time the command was executed, regardless of what the log says. Executing the command again migrated the data to storage.
This is not uncommon to me and known to happen even more frequently with LibreELEC (yes I know, different kernel and team) 7.xx’s installtointernal command line tool. It can be the reason of the JeOS sitting forever at the boot logo. The work around is to execute the command line tool again. Some boxes just work that way and need to have the command migration tool executed twice for successful migration.
The box was with android 7.1 and then “installtointernal” since 9.0.0 or even before (i don’t remember). Never has any issue. Only this time when i tried to update to -ng builds.
This is my Putty capture log when using “ceemmc -x”: https://pastebin.com/c19NvaCg
Next week i will try some tests with flash back stock android and then flash -ng builds in dual and single boot.
I would suggest to try and execute ceemmc -x twice, without restarting the box, eq: you run it once, choose option 1 and follow the instructions. Once it says success, run ceemmc -x immediately again, without restarting the box, this time choose option 4.
Once completed, remove the installation media and reboot from within CE (power menu / reboot).
It it still doesn’t work, I would say, go ahead and re-flash the firmware. There is a link to the latest firmware in my original post.
Thank you for you attention. But as you see in my Putty capture log, I only have 3 options.
Once completed, remove the installation media and reboot from withing CE (power menu / reboot).
This fixed the issue! Before i was removing the sdcard/usb and disconnecting the power supply.
Thank you so much @Betatester
Latest nightly has an issue with the power LED: after powering on, initially the LED goes from red to blue (approx. 6 seconds) then back red. Normally the LED is constant blue when the box is running and red when the box is off.
Please try to change the LED by sysfs:
there should be a file called
you can set it by:
echo 'default-on' > linux,default-trigger
echo 'none' > linux,default-trigger
I am not 100% sure about the path but it should be this one. Then report which setting is the correct one, thx.
The location doesn’t exist: https://pastebin.com/yVe3KpZd
ok checked it now:
echo 'none' > /sys/class/leds/sys_led/trigger
echo 'default-on' > /sys/class/leds/sys_led/trigger
ok. That does work for the active session. Upon reboot, the setting is lost and the light is red again. Shall we continue this as private message?
Just tell me the correct value. I know it’s gone on reboot as it’s a live change only. You will need to fdtput it in dtb until the default got changed.
turns the LED on.
Then please try:
mount -o rw,remount /flash fdtput -t s /flash/dtb.img /gpioleds/sys_led linux,default-trigger default-on sync reboot
Then please check if the function is same like with nightly 20200722. (same behavior on boot)
After a update you have to use fdtput again, but the fdtput cmd will start working from 20200723, before it will fail as it got changed on 0723.
Hi, I’ve tried the above and it works… LED stays on (blue)… remembers throught reboot… I did not detect any other issues. As you say the next nightly resets the change
I changed the sys_led to ‘default-on’. Please check again tomorrow with next nightly if it works correct then.
A minor cosmetic bug appears to have snuck into July 23rd’s nightly -ng build, affecting the LED behavior of the NexBox A95X-B7N. This was carried over to the builds from the 24rd and 25th.
The builds prior to July 23rd are unaffected. The July 26th nightly build should resolve this.
For now there is a workaround via SSH:
Workaround for nightly -ng builds 23, 24 and 25/07
This turns the LED blue when the unit is powered on, the LED returns to red when powered off:
echo ‘none’ > /sys/class/leds/sys_led/trigger
echo ‘default-on’ > /sys/class/leds/sys_led/trigger
This makes the changes permanent till the next update:
mount -o rw,remount /flash
fdtput -t s /flash/dtb.img /gpioleds/sys_led linux,default-trigger default-on
So far no big issues with -ng builds. I just notice one thing and i will explain here.
If i power on the box and then power on the TV +/- 5 seconds after, a green screen will appear and then after a couple of seconds it turns really dark green and stays there.
If i power on then at same time -> no issues
If i power on the box and then the TV +/- 15 seconds after -> no issues
If i power on the tv first and then the box -> no issues
What happens, after the screen turns dark green, if you power the TV off, wait 5 seconds, and then turn the TV back on?