-
Notifications
You must be signed in to change notification settings - Fork 18
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
update toolchain to nightly-2024-07-30 #322
Conversation
Fyi, upgrading to a recent nightly will also break the Allwinner D1 build due to a new check at link-time:
The issue is in the start-up assembly of riscv-rt and is probably only noticeable with large binaries (like mnemos) and doesn't get hit with microcontrollers. Upgrading |
I'm looking into changing the |
The `mnemos-x86_64-bootloader` image is built by a separate crate `mnemos-x86_64-bootloader`, which includes a build script that runs the post-build workflow to take the `bootloader_api`-compatible kernel binary and turn it into a bootable disk image that links with the actual bootloader. At present, we use a Cargo artifact dependency to build the actual kernel and expose it to the bootloader image build script. This is the ideal solution for this, since it allows the dependency between the build script and the kernel binary to be expressed as a normal Cargo dependency. However, using an artifact dep on a binary that's built for a different target than the crate with the artifact dep is sadly broken: see rust-lang/cargo#12358. We've somehow managed to find a way to avoid this issue in the past, but updating to a recent nightly seems to have brought it back (see #322). Therefore, this PR changes the build script to instead shell out to a new `cargo` invocation that builds the kernel. This is a bit unfortunate, since it means that the build output from building the actual kernel isn't exposed to the user as nicely, and there's probably less build caching. However, it works for now. I've modified the `just build-x86` Just recipe to invoke `cargo check` for the actual x86_64 kernel binary before building the bootable image, to help ensure that the cargo build output is made visible to the user. A nicer long-term solution would be to switch from a build script to using a cargo `xtask`-like builder, that's invoked as a cargo `runner` for that target, with the path to the builder binary passed in on the CLI. This is what [mycelium does][1]. That approach is nicer because it allows the kernel to be built using a normal cargo invocation that's actually visible to the user, instead of secretly in a build script. [1]: https://github.com/hawkw/mycelium/blob/e51eb8aa98e7609490fa674f408db32fd51caa70/.cargo/config.toml#L1-L2
that's good to know, thank you! Though at least on my system I can build, flash and run as-is (Lichee RV). Any idea why it doesn't break? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall, this looks good to me! I left a few comments, mostly about the lint fixes.
platforms/allwinner-d1/README.md
Outdated
After flashing, you should be able to see the hello server outputting `hello\n` | ||
repeatedly on the UART port (which is not port used for FEL!). | ||
Note that mnemOS changes the baud rate to 115200. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems good to mention, but I might also suggest using crowtty
to see kernel traces (and it selects the correct baud rate by default).
platforms/allwinner-d1/README.md
Outdated
@@ -94,11 +94,20 @@ xfel write 0x40000000 platforms/allwinner-d1/boards/target/riscv64imac-unknown-n | |||
xfel exec 0x40000000 | |||
``` | |||
|
|||
After flashing, you should be able to see the hello server outputting `hello\n` | |||
repeatedly on the UART port (which is not port used for FEL!). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tiny nit:
repeatedly on the UART port (which is not port used for FEL!). | |
repeatedly on the UART port (which is not the port used for FEL!). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry for the mess, I had changed the text multiple times and maybe forgot to push my latest version…
currently it reads:
After flashing you can connect using just crowtty serial <UART-DEVICE>
(this is not the FEL device!). Alternatively any serial terminal will do - note
that we use 115200 baud unlike the builtin bootloader which is at 9600.
#[cfg(feature = "thumbv6")] | ||
#[cfg(not(target_has_atomic))] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
perhaps we should just be using the portable-atomic
crate here --- cc @jamesmunns ?
but, we can do that in a separate PR. AFAICT none of this matters since we aren't currently compiling MnemOS for thumbv6m or any other target without atomics...
Interesting 😅 If you haven't done a |
ah, with your build command I do get the error you described. Good news though, this one works for me: the difference seems to be
(side note - are you using the latest nightly or the one specified by the project root's |
Co-authored-by: Eliza Weisman <[email protected]>
Co-authored-by: Eliza Weisman <[email protected]>
Co-authored-by: Eliza Weisman <[email protected]>
Co-authored-by: Eliza Weisman <[email protected]>
Co-authored-by: Eliza Weisman <[email protected]>
Co-authored-by: Eliza Weisman <[email protected]>
…into update-toolchain
Just tried in release mode and indeed that works.
I tend to use the "default" nightly toolchain instead of a specific version from rust-toolchain.toml files (shame on me) |
this PR changes the toolchain to use
nightly-2024-07-30
and fixesplatforms/x86_64
dependencies so it uses root'sCargo.toml
patch section for maitake crates.closes #323
obsoletes #306
TODO for reviewers (roughly ordered by assumed importance):
target_has_atomic
is the right fix ( a9e59b1 )VAddr::of(&DOUBLE_FAULT_STACK)
( 1aecece ) - can't use clippy's suggestedptr::addr_of!
with pinned mycelium (probably best to create dedicated issue)GrantWriter
is never constructed: platforms/allwinner-d1/d1-core/src/drivers/uart.rs:27:8GrantWriter
is never constructed: platforms/esp32c3-buddy/src/drivers/usb_serial.rs:16:8GrantWriter
is never constructed: platforms/esp32c3-buddy/src/drivers/uart.rs:21:8TryFromBits
is never used: platforms/allwinner-d1/d1-core/src/plic.rs:186:7SingleThreadedLinkedListAllocator
is never constructed: source/alloc/src/heap.rs:288:12