Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Boot order preference via sd:/boot_order.txt #39

Closed
wants to merge 1 commit into from

Conversation

PlugNPush
Copy link

@PlugNPush PlugNPush commented Jan 14, 2024

Directly addresses / resolves #38

With this PR proposal, anyone can override the firmware to be booted by B9S.

By default, it will always boot sd:/boot.firm.

But by creating a sd:/boot_order.txt file, you can specify a list of firmwares to be loaded and the first one that is available is going to be selected for loading.

For example, your sd:/boot_order.txt file could look like:

bax.firm
bax/bax.firm
dev.firm

This list acts just like your PCs BIOS: first one in order available gets booted, all the others are skipped.

And of course, if none are available, B9S will always boot the boot.firm firmware so it does not affect its standard behavior.

Note: currently there is no integrity check being made in the process, which means that if the file you are pointing exists on the SD card and is not a valid firmware, the console will NOT boot to boot.firm file in fallback (you will encounter the notification LED status informing that the boot has failed, and B9S will try to boot from CTRNAND as usual for a corrupted firmware).

@SciresM
Copy link
Owner

SciresM commented Jan 15, 2024

I don't think I'm inclined to merge this -- definitely feel free to use this for your personal use, I mean, that's the point of open-source projects.

From my point-of-view:

  1. B9S is basically finalized, and I consider TuxSH to be mostly in charge of the future of the project.
  2. Hitting the SD card more times will slow down boot. Slowing down boot for a feature that seems...niche at best doesn't make sense to me for B9S. I'd rather just suggest people with this usecase use a boot.firm payload which chainloads whatever the secondary file says to do.

@SciresM SciresM closed this Jan 15, 2024
@SciresM
Copy link
Owner

SciresM commented Jan 15, 2024

Sanity check, though, @TuxSH ^

@PlugNPush
Copy link
Author

Understood. Just to make it clear: the goal of this is specifically to not move the regular boot.firm (Luma) so that it can safely be updated by the Universal Updater. Your second point would break this, that’s why I made the fork in the first place :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Feature request: sd:/bootorder.txt
2 participants