LibreELEC 9.0 / Kodi 18.X for Minix X8,X8H,X8H+

These SoCs are designed to look for code at a specific address as they fire up and basically they get it all from U-boot as the system is being brought up. This is somewhat of a oversimplified statement but good enough for this purpose.

When u-boot starts it reads its stored environment variables which tell it how and what to look for as it starts to run. Typically the standard variables basically just tell it to look in internal storage for the images to load into ram and use. So u-boots environment needs to be changed to tell it to include looking elsewhere then just internal for images to load to ram.

This is where the autoscripts come in. aml_autoscript is the script that contains the environment changes that need to be fed into the running u-boot to add and store to static memory the variables to tell it to check for either of the files listed below and if so call them.

Then theres the S805_autoscript or S905_autoscript files that are the routines that actually make the choosen method and go do it. Unfortunately a remnant of some of the current methods are strickly based on whether or not the sd-card is present when the running u-boot pulls the system up.

So to fix that the level of checking needs to go further then just looking to see if the sd-card is inserted or not at boot time.

Adding some variables or register checks can be used to make u-boot realize that its actually booting up on internal and from that point forward treat anything plugged in the slot as strictly external storage. How one goes about creating that extra start up intelligence is up to you as theres more then just one way.

The aml_autoscript is capable of being used for a lot of other things as well but in this case i have confined its use to the subject of multi-boot.

Because of the way its being used in this case thats why people like balbes refers to only having to install the multiboot once. because typically after the initial use of the aml_autoscript U-boots environment has now been altered and stored in static memory to check elsewhere when booting. Its only after something else rewrites or restores the original u-boot environment that you need to re-apply the multiboot patch, either that or if theres a new multi-boot itself being used.

hope that helps.

Quote from buzzmarshall

Depending on how the bootloader code is setup this probably is a byproduct of some of the current popular methods of creating a multi-boot and because of the way u-boot has been altered to handle this type of multiboot. If the internal u-boot sees the card it thinks it needs to use it to pullup the system and run from there.

Other methods of creating a multi-boot that use different code in u-boots monitor to set things up different so it can realize to just treat the sd card as external flash can be done as well tho.

Not sure why so many people have problems with changing ip's and mac's tho as i have never had those issues and at any given time i probably have a least 6 boxes or more running on my network. Personally i always use static IP's and once set they never change as well as the mac's i set. Normally i just set them in a script that runs once the box boots up but i have also slipped streamed them into the box's u-boot as well and they always seem to stick...

very interesting... so in our case the right bootloader code should instruct to boot from the SD first (for the purpose of flashing new images) but only if a boot file system exist, otherwise boot from internal.

If I m correct and if it is doable, can somebody with more code knowledge do it? also can the bootloader be updated without need to reflash the device?

sasagr I don't know if it's included in these builds but you can prevent u-boot from trying to boot from SD card/any external media by resetting uenv variables to default values. Run this command: fw_setenv upgrade_step 1 and reboot. If you will ever want to boot from SD card again, you will need to use toothpick/reset method.

Quote from kszaq

sasagr I don't know if it's included in these builds but you can prevent u-boot from trying to boot from SD card/any external media by resetting uenv variables to default values. Run this command: fw_setenv upgrade_step 1 and reboot. If you will ever want to boot from SD card again, you will need to use toothpick/reset method.

I did it as you instructed

##############################################

# LibreELEC #

# LibreELEC – Just enough OS for KODI #

##############################################

LibreELEC (community): LE9-Kodi_18.2 (X8-X8H.arm)

LibreELEC:~ # fw_setenv upgrade_step 1

LibreELEC:~ # reboot

inserted the SD card (that was successfully mounted) before reboot cmd

and I got the message on TV screen:

Error in mount_flash: mount_part: Unknown file system

i need to remove the SD card again to have a successful boot from internal

Am I giving the wrong command or at a wrong level?

sasagr I looked at the source code, it works a bit different than my old builds... Try this: keep aml_autoscript on SD card but remove s805_autoscript from it. Then boot once with SD card inserted and use toothpick method. After this the box should be able to boot from internal again and no s805_autoscript on SD card would prevent box from booting from SD.

Ive not looked at the actual build's sources in this project but just patching the install to flash script to just rem out the s805 script as part of the install process would work in most cases, then if you ever wanted to reboot from the card just unrem the file.

sometimes its just easier to restore the default uenv values, unless the autoscript was doing more then just installing the s805/s905 calls then maybe doing a uenv restore wasn't good as it would undue the other things that script was doing as well.

it kinda comes down to what method is being used by the coder doing the build. in the end i found rather then trying to keep track and up with what all the others were doing to just build a smarter set of scripts that allow the running u-boot to better understand whats going on and work appropriately. some boxes with bigger internal storage i have partiioned up and installed mulitple setups and have more like a grub style loader. Its probably not for everybody but this lets me easily check and compare my builds with a simple reboot and not having to constantly change and re-install systems. I also you tftp to work on u-boot while developing.

actually i just added a M8S project to Datrh's LE9-Kodi18.2 and am currently compiling to see how well it works as i have probably 50+ M8S boxes sitting here from a dealer here in Can that went tits up after the government charged them (iNL3d), so it would be nice to make them work and get rid of them as they all have 4.4.2 on them which makes them useless but for something like libreelec they would still be fine.

I don't know what is happening now... I m not managing to boot from SD anymore.

I flashed the last image 18.2 to the SD, I renamed the "boot_autoscript" to "boot.scr", deleted the s805_autoscript file.

Reboot the device while holding reset switch for 5 -6 sec and I m still getting the same error in mount_flash message.

Changed SD, though it is the one I have used the very first time I flashed the device, but same result.

If you have any suggestion, otherwise I will try again tomorrow

not sure what to say as i kinda was just vaguely following the post and have not really looked at the way his build is handling the multiboot. Im currently building his build with a added project and will check it at home once the build is done (im building it here at work).

I wonder if resetting the uenv the way kszaq suggested earlier removed the multiboot patch from the resident u-boot which would mean you need to go back to how you originally installed everything again.

If you had a serial port i would say start the box up while watching the serial port and hit the enter key immediately as that will freeze u-boot and dump you out into a command line where you can check the uenv variables and see whats going on.

i just quickly looked at the projects sources and see its a bit different then what i typically see so maybe once i get home and can test this build and see whats what i may be better suited to try and help.

I think the multi boot is still there... I mean without SD it boots from internal storage without any issue. With the SD in it tries to read the SD for a boot file system but for some reason it does not find it, I may need to try another way to flash the SD card. I have "forced" the boot from the SD card with the reset method but eventually there is no need. I can also enter in the recovery mode.

Otherwise I have no serial cable. At this stage if anything can be done it has to be either from ssh once libreelec from internal is up or from recovery.

But as I said I will try tomorrow to reflash the SD card again. now time for some sleep

ok. I did a few tests. I can boot successfully from the SD only with if the SD card as the image as per post #1 (including the rename of the boot_autoscript to boot.scr). Deleting the s805 script makes the SD card unbootable and it gives me the error in mount_flash error at start up.

If it can help my device is the X8H

I was tempted to try to remove the aml script instead of the s805 but I m not so brave

Hi all,

I just re-flashed my x8h plus with X8H_PLUS_LOLLIPOP_RC2_NEWBOOT.img, but I can see only black screen after switch on.

is this behaviour OK?

Quote from kodlz

Hi all,

I just re-flashed my x8h plus with X8H_PLUS_LOLLIPOP_RC2_NEWBOOT.img, but I can see only black screen after switch on.

is this behaviour OK?

When I flashed my X8h Plus it took at least 5 minutes to build up the "system caches", so patience is needed.

Quote from datrh

to be able to shutdown , you need to reflash the box

My Files

It has been tested on the X8-H with success.

I need both Android and LibreELEC, I flashed my X8-H with minix_x8_x8plus_x8_h_newbootloader_FW9.img, but it seems, that in this firmware video acceleration does not work.

YouTube, Vanced, SPMC & MX Player do not play video with HW acceleration. If I switch decoder in MX Player to SW decoder, video plays.

In official firmware X8_X8PLUS_X8H_FW009.img everything works.

Quote from datrh

this is weird want it doesn't seems that i've changed the dtb between 18.1 and 18.2.

If fixed IP = "fixed" on 18.2, I am tempted to install to internal.

Quote from Klaver7

If fixed IP = "fixed" on 18.2, I am tempted to install to internal.

This will probably be due to the fact that version 18.1 didn't have a fixed IP on the LAN. I think it couldn't be set manually either in libreelec fixed IP and after both restart and shutdown it came back to DHCP with the new IP including MAC. Of course, it was not possible to book in the router. As far as I can remember, in version 18 I set IP manually on the LAN in libreelec and this version kept the IP address but changed the MAC address after restart or shutdown. Every time I wanted to reserve an IP address in the router at 18.1, the IP including MAC was changed.

And as I wrote in the 18.2 version, Wi-Fi holds both IP and MAC and can be permanently booked in the router. I want to write that if it is OK in version 18.2 on Wi-Fi and not on LAN, so probably not the problem with us.

I'm not talking about static IP on the LAN, I'm trying to give feedback on x8h +, with DHCP, IP reservation including MAC permanently on LAN.

My connection is a 200/50 optic with dynamic IP no problem otherwise.

I'm not a networker, but if you can't fix it on x8h + then I'll try to set up a static IP for minix in the router.

I'm also sorry for worse English I just try to describe the problem on x8h +.

Thank you for your understanding