update toolchain to nightly-2024-07-30

[spookyvision]

this PR changes the toolchain to use nightly-2024-07-30 and fixes platforms/x86_64 dependencies so it uses root's Cargo.toml patch section for maitake crates.

closes #323

obsoletes https://github.com/tosc-rs/mnemos/pull/306

TODO for reviewers (roughly ordered by assumed importance):

• [ ] ensure target_has_atomic is the right fix ( a9e59b1d96fbe998caf9bee5535e5c0c58a561ca )
• [ ] warning: transmute used without annotations --> platforms/allwinner-d1/d1-core/src/drivers/smhc.rs:521:58
• [ ] interior mutable const lint
• [ ] VAddr::of(&DOUBLE_FAULT_STACK) ( 1aecece ) - can't use clippy's suggested ptr::addr_of! with pinned mycelium (probably best to create dedicated issue)
• [ ] warning: struct GrantWriter is never constructed: platforms/allwinner-d1/d1-core/src/drivers/uart.rs:27:8
• [ ] warning: struct GrantWriter is never constructed: platforms/esp32c3-buddy/src/drivers/usb_serial.rs:16:8
• [ ] warning: struct GrantWriter is never constructed: platforms/esp32c3-buddy/src/drivers/uart.rs:21:8
• [ ] warning: trait TryFromBits is never used: platforms/allwinner-d1/d1-core/src/plic.rs:186:7
• [ ] warning: struct SingleThreadedLinkedListAllocator is never constructed: source/alloc/src/heap.rs:288:12

[jspngh]

Fyi, upgrading to a recent nightly will also break the Allwinner D1 build due to a new check at link-time:

relocation R_RISCV_JAL out of range: 1633230 is not in [-1048576, 1048575]; references 'abort'

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. The most recent version of riscv-rt should be okay to use (the issue is still present, but only in case of multiple harts).

Upgrading riscv and riscv-rt might be a good idea, but might also be a lot of work, since I think we also need to upgrade to embedded-hal(-async) v1.0.0. An alternative is to use a patched version of riscv-rt v0.11.0

[hawkw]

I'm looking into changing the mnemos-x86_64-bootloader build script so that we no longer use Cargo artifact deps, but I'll probably try to do that in a separate PR that we can rebase this onto.

[spookyvision]

Fyi, upgrading to a recent nightly will also break the Allwinner D1 build due to a new check at link-time

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?

[jspngh]

Fyi, upgrading to a recent nightly will also break the Allwinner D1 build due to a new check at link-time

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?

Interesting 😅 I'm running cargo build -p mnemos-d1 --bin mq-pro (same for lichee-rv) on your update-toolchain branch using the latest nightly, and I do run into the issue I described.

If you haven't done a cargo clean recently, could you give that a try?

[spookyvision]

Interesting 😅 I'm running cargo build -p mnemos-d1 --bin mq-pro (same for lichee-rv) on your update-toolchain branch using the latest nightly, and I do run into the issue I described. If you haven't done a cargo clean recently, could you give that a try?

ah, with your build command I do get the error you described. Good news though, this one works for me: just build-d1 mq-pro

the difference seems to be --profile release; here's the fully expanded command:

❯ just build-d1 mq-pro
       Found cargo-objcopy
cargo build --profile release --package mnemos-d1 --bin mq-pro

(side note - are you using the latest nightly or the one specified by the project root's rust-toolchain.toml?)

[jspngh]

ah, with your build command I do get the error you described. Good news though, this one works for me: just build-d1 mq-pro

the difference seems to be --profile release; here's the fully expanded command:

❯ just build-d1 mq-pro
       Found cargo-objcopy
cargo build --profile release --package mnemos-d1 --bin mq-pro

Just tried in release mode and indeed that works. I wonder if it's due to the binary being smaller because of optimization or the abort symbol being placed at a different location. In any case, I think we can postpone upgrading riscv(-rt) to a different PR.

(side note - are you using the latest nightly or the one specified by the project root's rust-toolchain.toml?)

I tend to use the "default" nightly toolchain instead of a specific version from rust-toolchain.toml files (shame on me) and that was the latest nightly at the time of writing.