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
Add useful stage-2 examples/hello and cleanups #155
Merged
samueldr
merged 20 commits into
NixOS:master
from
samueldr-wip:feature/less-confusing-default
May 31, 2020
Merged
Add useful stage-2 examples/hello and cleanups #155
samueldr
merged 20 commits into
NixOS:master
from
samueldr-wip:feature/less-confusing-default
May 31, 2020
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This didn't end up being something that's being worked on. It probably was entirely confusing for everyone as it wasn't documented, and didn't actually do anything useful most of the time. Rather than polluting the build with some one-off special cases like this, we'll implement an "installer" as an example system, if we even want an installer. It's not planned yet *how* users should install, it may not even be an installer type system. This also rewords the "successful default build failure" message.
Its documentation, which was really wrong, tells me this was something that was either lost early on, or never implemented.
samueldr
force-pushed
the
feature/less-confusing-default
branch
2 times, most recently
from
May 31, 2020 22:48
ee1f762
to
bfa1c95
Compare
This allows filesystem generation to be re-configured without overriding all options.
This allows wrapping an applet into a script that will start it.
It will end up re-used soon.
Then, the simulator is re-tooled to use it, and the new wrapper thingy.
We know that the loader is at "/loader" in our initrd. Use that knowledge.
The examples/hello system can be used by users that want to boot a minimal, and cross-compilable system. This is better than a "raw" build of the root of the Mobile NixOS repo since it provides a stage-2 application stating the system booted successfully.
It's not very good :/
samueldr
force-pushed
the
feature/less-confusing-default
branch
from
May 31, 2020 22:57
bfa1c95
to
a01f543
Compare
11 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cleanups
The first batch of commits is about cleaning up some confusing things in the Mobile NixOS tree, in addition to allowing the following feature to be possible.
Useful stage-2
The
examples/hello
example system is a new fully-cross-compilable (verified for aarch64) system. The intent is to allow end-users to validate the state of their device as much as possible without relying on pre-built images flashed on top of the confusing default build.This adds a small app made using the same libraries as the boot GUI, which starts at stage-2.
It currently allows validating the display has the right ordering. The other options are more as informational points.
In the future, I would like to add more in-depth tests, e.g. listing LEDs, showing all input events.
But for now, this is sufficient. This gives a sane target that allows users to test the full boot process.
Note that, by design, the stage-1 for that system will not boot the default "NIXOS_SYSTEM" image. This allows a user to flash this (smaller) filesystem image to the
system
partition, while keeping the bigger demo system onuserdata
. The user can then boot to any of the two by only either changing the boot.img, using the recovery partition, or using fastboot (assuming an android-based device).