MiSTer updater script

[SegaMan]

thx @locutus73

It´s clear now to me

[Locutus73]

MiSTer.ini is on github since beginning:
https://github.com/MiSTer-devel/Main_Mi ... MiSTer.ini

No Sorg, he was referring to the optional updater ini (do you remember you suggested this mechanism?)

Regards.
Locutus73

[Locutus73]

thx @locutus73

It´s clear now to me

Thank you... but it isn't still clear to me how making the README more noob user friendly...

Regards.

Locutus73

[MattE888]

Locutus73, your instructions are very clear and I didn't have any problems. So I'm totally fine how it is! However, if you are wanting to super polish the documentation, it could be more consistent with how the MiSTer files and documentation are presented. The MiSTer has a totally separate ini file that is linked to, that can be downloaded. If the updater script documentation had a separate ini file to link to and for people to download, that would be more consistent with the MiSTer files and documentation.

edit: I just noticed that esmith13 was recommending this too. My only real addition to his request is that I'm pointing out that consistency with the MiSTer files and documentation(by including a separate downloadable ini file) is probably a good thing.

Also, thanks so much for adding core filters to that ini file. Very nice!!!!

[SegaMan]

thx @locutus73

It´s clear now to me

Thank you... but it isn't still clear to me how making the README more noob user friendly...

Regards.

Locutus73

I think a finished (downloadable) example of update.ini/mister_updater.ini file on your github page could be helpful.

[Locutus73]

ini examples added.

Regards.

Locutus73

[SegaMan]

Ok, one thing to know for me

When i use update.sh

it downloads the latest mister_updater.sh and run it.

Will it than use the mister_updater.ini (i created with my settings)?

[Locutus73]

Ok, one thing to know for me

When i use update.sh

it downloads the latest mister_updater.sh and run it.

Will it than use the mister_updater.ini (i created with my settings)?

It will use update.ini or whatever you call the script you launch through the OSD.

Regards.

Locutus73

[SegaMan]

Ok.

Then i put the user option selection (https://github.com/MiSTer-devel/Updater ... sh#L41-L90) into update.ini and when launching the update.sh it will use this settings?

[Locutus73]

Ok.

Then i put the user option selection (https://github.com/MiSTer-devel/Updater ... sh#L41-L90) into update.ini and when launching the update.sh it will use this settings?

Correct... usually I put only the options I customize in the ini.

Regards.

Locutus73

[SegaMan]

Thx for help

[Sorgelig]

by the way, to load the rbf you can use command fpga:
fpga <path_to_rbf>

it will load rbf and trigger the reset. So, this loading is a little slower than load through menu, but should be ok for specific needs.

[Locutus73]

by the way, to load the rbf you can use command fpga:
fpga <path_to_rbf>

it will load rbf and trigger the reset. So, this loading is a little slower than load through menu, but should be ok for specific needs.

Oh, great! Thanx!

Locutus73

[Locutus73]

by the way, to load the rbf you can use command fpga:
fpga <path_to_rbf>

it will load rbf and trigger the reset. So, this loading is a little slower than load through menu, but should be ok for specific needs.

With trigger the reset do you mean the FPGA/core reset? Does this command reset/force main MiSTer to reload the ini or do I have to kill and relaunch it? If I have to relaunch MiSTer, do you prefer the rbf to be called first or later (I guess later), I mean something like.

Code: Select all

killall MiSTer
/media/fat/MiSTer >/dev/ttyS0 2>/dev/ttyS0 </dev/null &
fpga/media/fat/menu.rbf

For loading a new ini and resetting the main menu.

Thank you in advance.
Regards.

Locutus73

[Sorgelig]

just try and you will see.

[Locutus73]

just try and you will see.

Ok, as soon as I am home I'll fiddle with it.

Ciao.

Locutus73

[Sorgelig]

You don't need to kill the MiSTer.
Just fpga /media/fat/menu.rbf will do everything.

[Locutus73]

You don't need to kill the MiSTer.
Just fpga /media/fat/menu.rbf will do everything.

Thnx, I just tested fpga /media/fat/menu.rbf, but I see on the serial console a full reboot (I see u-boot messages), so it seems equivalent to reboot now, at least if I use menu.rbf; am I wrong?

Thank you in advance.
Regards.

Locutus73

[Sorgelig]

Thnx, I just tested fpga /media/fat/menu.rbf, but I see on the serial console a full reboot (I see u-boot messages), so it seems equivalent to reboot now, at least if I use menu.rbf; am I wrong?

As i've told earlier, core loading will trigger the reset of HPS part.

[Locutus73]

Thnx, I just tested fpga /media/fat/menu.rbf, but I see on the serial console a full reboot (I see u-boot messages), so it seems equivalent to reboot now, at least if I use menu.rbf; am I wrong?

As i've told earlier, core loading will trigger the reset of HPS part.

Yeah I see... It's just that in the first post you just said reset and I was projecting my hope for just a "core reset" or "MiSTer executable reset", not a proper system reset. It's just that some users are asking if there's a way to apply the ini settings without rebooting, but that's not a major issue to me.

Thank you.

Locutus73

[high5]

Hey, thanks for the script. Works like a charm for me.

Just a small note from a first time MiSTer and update-script user. After I prepared the SD card I did not update any MiSTer-components manually so the scripts-options was not present in OSD. Did execute update.sh via ssh for the first time and after that everything also works via OSD.

[Sorgelig]

Thnx, I just tested fpga /media/fat/menu.rbf, but I see on the serial console a full reboot (I see u-boot messages), so it seems equivalent to reboot now, at least if I use menu.rbf; am I wrong?

As i've told earlier, core loading will trigger the reset of HPS part.

Yeah I see... It's just that in the first post you just said reset and I was projecting my hope for just a "core reset" or "MiSTer executable reset", not a proper system reset. It's just that some users are asking if there's a way to apply the ini settings without rebooting, but that's not a major issue to me.

Thank you.

Locutus73

i didn't think about loading the core outside the MiSTer as it's beyond the scope of MiSTer usage. So it's workaround way - so can't expect smoothness of this way.
Actually INI file re-read with every core load. So, if you change some settings in INI and then load the core from OSD then it will use new settings from ini. Probably it will be enough in most cases. If you want to change the settings for current core, then simple kill and load MiSTer will apply new ini settings without reloading the core.

As for loading the core from shell without reset - i will think about it. If you have an idea how to send the command to MiSTer binary - tell me.

[Locutus73]

New mister_updater.sh:
Version 1.8 - 2019-01-15 - Using /media/fat/#Scripts/.mister_updater as work directory, you can safely delete MiSTer_yyyymmdd, menu_yyyymmdd.rbf and release_yyyymmdd.rar from SD root now; using empty files as semaphores and corrected a minor bug about their target directories; improved user option comments.

https://github.com/MiSTer-devel/Updater_script_MiSTer

Regards.

Locutus73

[Shazz]

by the way, to load the rbf you can use command fpga:
fpga <path_to_rbf>

it will load rbf and trigger the reset. So, this loading is a little slower than load through menu, but should be ok for specific needs.

Would it be possible to add an optional parameter to the fpga command to automatically mount a virtuak disk/rom ?

[jayp76]

@Locutus73

I have a suggestion to your script. Wouldn't it be more user friendly for custom setups to have for e.g DOWNLOAD_NEW_CORES="true" or REPOSITORIES_FILTER="xxx" in a separete file. Because if everybody uses your update.sh script, it automatically uses the default value of said options.
If every user has this in a seperate file, the user could keep his own default values, that are not overwritten by the updater script.