Repository navigation
Errors when trying to cross compile to ARM #22
Copy link
Copy link
Open
Description
Compiling on a x86 computer for an arm target :
cargo build --release --example rust-logo --target arm-unknown-linux-gnueabi
The error is :
# ./rust-logo
./rust-logo: /lib/libc.so.6: version `GLIBC_2.28' not found (required by ./rust-logo)
./rust-logo: /lib/libc.so.6: version `GLIBC_2.18' not found (required by ./rust-logo)
./rust-logo: /lib/libc.so.6: version `GLIBC_2.33' not found (required by ./rust-logo)
./rust-logo: /lib/libc.so.6: version `GLIBC_2.32' not found (required by ./rust-logo)
./rust-logo: /lib/libc.so.6: version `GLIBC_2.34' not found (required by ./rust-logo)
This is because the target linux system is an "old" linux which I can't upgrade : https://linux-sunxi.org/Bookeen_Cybook_Muse
I tried to build with musleabi to avoid the dependency on libc6 :
cargo build --release --example rust-logo --target armv7-unknown-linux-musleabi
with config :
cat ~/.cargo/config.toml
[target.armv7-unknown-linux-musleabi]
linker = "/home/arthur/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin/rust-lld"
This works for a "Hello World" rust binary, but doesn't for rust-framebuffer :
The result is :
# ./rust-logo
thread 'main' panicked at examples/rust-logo/main.rs:15:61:
called `Result::unwrap()` on an `Err` value: BmpError { kind: BmpIoError(Os { code: 2, kind: NotFound, message: "No such file or directory" }), details: "BMP Error: Io Error" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
# RUST_BACKTRACE=1 ./rust-logo
thread 'main' panicked at examples/rust-logo/main.rs:15:61:
called `Result::unwrap()` on an `Err` value: BmpError { kind: BmpIoError(Os { code: 2, kind: NotFound, message: "No such file or directory" }), details: "BMP Error: Io Error" }
stack backtrace:
0: rust_begin_unwind
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:645:5
1: core::panicking::panic_fmt
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:72:14
2: core::result::unwrap_failed
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/result.rs:1649:5
3: rust_logo::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels
Activity
arthurlutz commentedon Feb 26, 2024
Oh in case there is a way to compile for libc6 2.11.1 here is the info about the target system :
Roysten commentedon Feb 26, 2024
Your musl attempt looks like it could work. Did you copy the bmp image to the arm target as well? The example expects the image to be in the directory
examples/rust-logo/rust-logo.bmprelative to the executable.arthurlutz commentedon Feb 26, 2024
Thanks for taking a look at this, copied the bmp over, got a new error :
Roysten commentedon Feb 26, 2024
Could you try building without --release? Then we can see the actual line numbers at which it is failing.
arthurlutz commentedon Mar 11, 2024
(Sorry for the delay) :
I don't see a lot of difference but you might find some more useful info :
Roysten commentedon Mar 11, 2024
Okay, now we can at least see at which line it fails. It appears to be line 18, which sets the graphics mode. Could you comment out this line and line 33 just for testing? You should still get the logo on the screen but some of the text may be visible through it. If this solves the issue we can further investigate why this ioctl fails on your device.
arthurlutz commentedon Mar 13, 2024
With lines 18 and 33 commented I get the following error :
There might be something particular with this framebuffer, maybe there are some hints in https://github.com/allepet/nolim-ebook-sdk/blob/master/main.c (if you can read C code)...
(thanks again for debugging this with me)
arthurlutz commentedon Mar 13, 2024
I added some println to get the collected info at the beginning of the function :
Roysten commentedon Mar 13, 2024
arthurlutz commentedon Mar 13, 2024
🎉 It doesn't crash anymore ! ... but... it doesn't display anything either (yet!)
The yres_virtual seems to be 1200 (so 2x600), does that make sense ?
For the "nothing is displayed" can we try out to print the image elsewhere in the resolution ?
As shown in the image https://static.mamot.fr/media_attachments/files/111/561/908/190/422/354/original/04aee109f157f1dc.jpg the top of the screen is broken, (but since the image is 512x512 I would have expected for part of it to show...)
arthurlutz commentedon Mar 13, 2024
Maybe I'm missing some eink specific command to refresh the screen from the framebuffer, something similar to https://github.com/allepet/nolim-ebook-sdk/blob/master/eink_lib.h#L46 ?
Roysten commentedon Mar 17, 2024
Yes that could be the case. Looking through the kernel code of the device the 0x402 ioctl seems to be used for updating the eink display: https://github.com/BOOKEEN/kernel-linux-3.0/blob/0aeda9a8538f2e2dcdfee92b5740a6bcc33c3662/include/linux/drv_display_sun4i.h#L802. You could try adding a new function to the framebuffer library which does this ioctl. I can help with that if required.
Also note that they are opening
/dev/dispinstead of/dev/fb0.arthurlutz commentedon Mar 18, 2024
I'm trying some things from the shell before trying them in rust, but with no luck. Not sure what I'm supposed to do (am attempting to force the screen update after writing to the framebuffer with the rust program) :
On the rust side I don't know either what I should be doing, I searched for ioctl and found a bunch of crates : https://docs.rs/releases/search?query=ioctl which one do you recommend for my use case ?
pftbest commentedon Sep 10, 2024
I ran into the same ioctl issue on some arm dev board, commenting out
set_kd_modecalls fixed it. Then I got length mismatch too, fixed it by taking minimum of both sidesafter this 2 changes examples run just fine