Hello all,
I have the following problem: https://gitlab.postmarketos.org/postmarketOS/pmbootstrap/-/issues/2635
In short, what is happening is the following:
- The kernel boots and outputs via UART when I build the kernel with the following:
make LLVM=1 ARCH="$arm" CC="${CC:-gcc}"
- The kernel doesn't boot and there is no output via UART when I build the kernel with the following:
make LLVM=1 ARCH="$arm"
The only difference being: CC="${CC:-gcc}". Is this expected? I think this was present in the Linux kernel ever since Rust was enabled for ARMv7, and I never encountered it because postmarketOS was originally building the first way.
Thanks,
Rudraksha
On Sun, Dec 14, 2025 at 12:54 AM Rudraksha Gupta guptarud@gmail.com wrote:
- The kernel boots and outputs via UART when I build the kernel with the
following:
make LLVM=1 ARCH="$arm" CC="${CC:-gcc}"
- The kernel doesn't boot and there is no output via UART when I build
the kernel with the following:
make LLVM=1 ARCH="$arm"
The only difference being: CC="${CC:-gcc}". Is this expected?
It depends on what that resolves to, i.e. your environment etc., i.e. that is resolved before Kbuild is called.
The normal way of calling would be the latter anyway -- with the former you are setting a custom `CC` (either whatever you have there or the `gcc` default). By default, `LLVM=1` means `CC=clang`.
So it could be that you are using a completely different compiler (even Clang vs. GCC, or different versions, and so on). Hard to say. And depending on that, you may end up with a very different kernel image. Even substantial Kconfig options may get changed etc.
I would suggest comparing the kernel configuration of those two ways (attaching them here could also be nice to see what compilers you are using and so on).
Cc'ing Kbuild too so that they are in the loop.
I hope that helps.
Cheers, Miguel
On 12/13/25 22:06, Miguel Ojeda wrote:
On Sun, Dec 14, 2025 at 12:54 AM Rudraksha Gupta guptarud@gmail.com wrote:
- The kernel boots and outputs via UART when I build the kernel with the
following:
make LLVM=1 ARCH="$arm" CC="${CC:-gcc}"
- The kernel doesn't boot and there is no output via UART when I build
the kernel with the following:
make LLVM=1 ARCH="$arm"
The only difference being: CC="${CC:-gcc}". Is this expected?
It depends on what that resolves to, i.e. your environment etc., i.e. that is resolved before Kbuild is called.
Sorry about that, I should've specified in the original email. The CC resolves to armv7-alpine-linux-musleabihf-gcc.
When both LLVM=1 and the CC=gcc are used, I can insmod the sample rust modules just fine. However, if I only use LLVM=1, my phone doesn't output anything over UART, and I assume that it fails to boot. Interestingly enough, if I just specify LLVM=1 (with no CC=gcc), and remove the rust related configs from the pmos.config fragment, then my phone boots and I can see logs over UART.
The normal way of calling would be the latter anyway -- with the former you are setting a custom `CC` (either whatever you have there or the `gcc` default). By default, `LLVM=1` means `CC=clang`.
So it could be that you are using a completely different compiler (even Clang vs. GCC, or different versions, and so on). Hard to say. And depending on that, you may end up with a very different kernel image. Even substantial Kconfig options may get changed etc.
I would suggest comparing the kernel configuration of those two ways (attaching them here could also be nice to see what compilers you are using and so on).
postmarketOS uses kernel config fragments and tracks the latest linux-next:
- https://gitlab.postmarketos.org/postmarketOS/pmaports/-/blob/master/device/t...
- https://gitlab.postmarketos.org/postmarketOS/pmaports/-/blob/master/device/t...
- build recipe: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/blob/master/device/t...
The only thing that changed was whether CC=gcc was specified or not:
https://gitlab.postmarketos.org/postmarketOS/pmaports/-/commit/b9102ac5718b8...
Cc'ing Kbuild too so that they are in the loop.
I hope that helps.
Thanks for your help! Always appreciate your presence. :)
Cheers, Miguel
On Sat, 13 Dec 2025 23:34:31 -0800 Rudraksha Gupta guptarud@gmail.com wrote:
On 12/13/25 22:06, Miguel Ojeda wrote:
On Sun, Dec 14, 2025 at 12:54 AM Rudraksha Gupta guptarud@gmail.com wrote:
- The kernel boots and outputs via UART when I build the kernel with the
following:
make LLVM=1 ARCH="$arm" CC="${CC:-gcc}"
- The kernel doesn't boot and there is no output via UART when I build
the kernel with the following:
make LLVM=1 ARCH="$arm"
The only difference being: CC="${CC:-gcc}". Is this expected?
It depends on what that resolves to, i.e. your environment etc., i.e. that is resolved before Kbuild is called.
Sorry about that, I should've specified in the original email. The CC resolves to armv7-alpine-linux-musleabihf-gcc.
When both LLVM=1 and the CC=gcc are used, I can insmod the sample rust modules just fine. However, if I only use LLVM=1, my phone doesn't output anything over UART, and I assume that it fails to boot. Interestingly enough, if I just specify LLVM=1 (with no CC=gcc), and remove the rust related configs from the pmos.config fragment, then my phone boots and I can see logs over UART.
Which drivers have you enabled that use Rust? Just having core Rust infrastructure enabled shouldn't cause issues on its own, apart from slightly bigger kernel image.
If just enabling Rust but none of Rust drivers cause issue, I would start looking at
1) if there're any symbols somehow being overwritten by the Rust object files.
2) if the size of kernel is pushed above a certain threshold that your bootloader/firmware is unhappy.
Best, Gary
On 12/14/25 8:34 AM, Rudraksha Gupta wrote:
On 12/13/25 22:06, Miguel Ojeda wrote:
On Sun, Dec 14, 2025 at 12:54 AM Rudraksha Gupta guptarud@gmail.com wrote:
- The kernel boots and outputs via UART when I build the kernel with the
following:
make LLVM=1 ARCH="$arm" CC="${CC:-gcc}"
- The kernel doesn't boot and there is no output via UART when I build
the kernel with the following:
make LLVM=1 ARCH="$arm"
The only difference being: CC="${CC:-gcc}". Is this expected?
It depends on what that resolves to, i.e. your environment etc., i.e. that is resolved before Kbuild is called.
Sorry about that, I should've specified in the original email. The CC resolves to armv7-alpine-linux-musleabihf-gcc.
When both LLVM=1 and the CC=gcc are used, I can insmod the sample rust modules just fine. However, if I only use LLVM=1, my phone doesn't output anything over UART, and I assume that it fails to boot. Interestingly enough, if I just specify LLVM=1 (with no CC=gcc), and remove the rust related configs from the pmos.config fragment, then my phone boots and I can see logs over UART.
Did you try other architectures / devices as well (especially can you reproduce it on qemu-arm)?
Did you try a LLVM=1 build without rust enabled?
The normal way of calling would be the latter anyway -- with the former you are setting a custom `CC` (either whatever you have there or the `gcc` default). By default, `LLVM=1` means `CC=clang`.
So it could be that you are using a completely different compiler (even Clang vs. GCC, or different versions, and so on). Hard to say. And depending on that, you may end up with a very different kernel image. Even substantial Kconfig options may get changed etc.
I would suggest comparing the kernel configuration of those two ways (attaching them here could also be nice to see what compilers you are using and so on).
postmarketOS uses kernel config fragments and tracks the latest linux-next:
https://gitlab.postmarketos.org/postmarketOS/pmaports/-/blob/master/device/t...
https://gitlab.postmarketos.org/postmarketOS/pmaports/-/blob/master/device/t...
build recipe: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/blob/master/device/t...
The only thing that changed was whether CC=gcc was specified or not:
https://gitlab.postmarketos.org/postmarketOS/pmaports/-/commit/b9102ac5718b8...
I'm not familiar with pmbootstrap, what is required to reproduce this? Do I just need to use the edge channel with linux-next or is something special required?
I might habe time to look into trying to reproduce it this week, but I'm not sure. I have a armv7 based asus-flo device to try it out. Its not very well supported, but It should be sufficient for this.
Cheers, Christian
linux-stable-mirror@lists.linaro.org
-
Christian Schrefl -
Gary Guo -
Miguel Ojeda -
Rudraksha Gupta