Open SunnyVibrant opened 1 week ago
github-actions[bot]
commented
1 week ago Hi @SunnyVibrant! We appreciate you submitting your first issue for our open-source project. 🌟
Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙
henrikbrixandersen
commented
1 week ago Can you reproduce this issue on current main branch?
SunnyVibrant
commented
1 week ago Can you reproduce this issue on current
mainbranch? @henrikbrixandersen @teburd Thank you for your prompt response, your support is well appreciated!! Can you please confirm llext is supported in nRF9160 platform??
Yes, we can reproduce llext issue in the main branch.
Zephyr Project LLEXT Module Testing, I also have attached the logs for reference. Logs_github.txt
We took the code from the main branch of the Zephyr repository: Zephyr Main Branch We built the LLEXT module from this sample: LLEXT Module
Case 1: Basic Build, no changes
After flashing the build, we observed the following logs from the device:
Booting nRF Connect SDK v2.7.99-cs2-d73b286ff6d9
Using Zephyr OS v3.6.99-3d01dcc251bf
[00:00:00.393,615]
Case 2: Adding a Build Flag We added the following flag to the prj.conf file: CONFIG_HELLO_WORLD_MODE=m Here are the console logs from the device.
Booting nRF Connect SDK v2.7.99-cs2-d73b286ff6d9
Using Zephyr OS v3.6.99-3d01dcc251bf
[00:00:00.383,514]
Case 3: Modifying the Code We commented out the following line from hello_world_ext.c in the module: printk("Hello, world, from an llext!\n");
Here are the logs after flashing the modified build:
Booting nRF Connect SDK v2.7.99-cs2-d73b286ff6d9
Using Zephyr OS v3.6.99-3d01dcc251bf
[00:00:00.285,400]
teburd
commented
1 week ago Does zephyrs test suite for llext pass on this board? I’d review the test suite and compare the various tests and Kconfig option set there. Let me know if the test suite fails in any way!
SunnyVibrant
commented
1 week ago Does zephyrs test suite for llext pass on this board? I’d review the test suite and compare the various tests and Kconfig option set there. Let me know if the test suite fails in any way!
@teburd Thank you for your response! We didn't run the llext test suites. We will run those tests and provide an update. Meanwhile, could you please confirm if llext is supported on the nRF9160?
teburd
commented
1 week ago llext works on cortex-m armv7m, and this is a well supported architecture. That said there are some things that may/may not work out, there's various elf linkages, the need to use EXPORT_SYMBOL() to expose the symbol to the elf loader, and so on. The tests cover all this and verify everything works. The sample requires building in a particular way from what I recall though @pillo79 might have a better answer.
Running the tests should work!
SunnyVibrant
commented
1 week ago llext works on cortex-m armv7m, and this is a well supported architecture. That said there are some things that may/may not work out, there's various elf linkages, the need to use EXPORT_SYMBOL() to expose the symbol to the elf loader, and so on. The tests cover all this and verify everything works. The sample requires building in a particular way that may from what I recall though @pillo79 might have a better answer.
Running the tests should work!
@pillo79 good morning!!
Thank you very much for your continued support. Any assistance you provide is highly appreciated.
Could you kindly help us by providing a list of the required changes and steps to make llext work on the nRF9160 board?
We are specifically looking for guidance on configuration changes (like prj.conf), adjustments related to Relocatable ELF handling, and any relevant build instructions for the llext test suites, including the order in which the modules should be built.
Your help in this matter would be invaluable.
SunnyVibrant
commented
1 week ago @teburd Awesome, good to hear this from you. Thank you very much for your support.
SunnyVibrant
commented
1 week ago @teburd @pillo79 Hello, We ran llext test suites and see that test case: test_load_unload_hello_world fails with system halt.
Here are the test suite logs llext_test_suite_logs.txt
START - test_load_unload_hello_world D: Loading relocatable or shared elf D: Finding ELF tables... D: section 0 at 2cc: name 0, type 0, flags 0, addr 0, size 0 D: section 1 at 2f4: name 31, type 1, flags 6, addr 0, size 36 D: section 2 at 31c: name 27, type 9, flags 40, addr 0, size 24 D: section 3 at 344: name 37, type 1, flags 3, addr 0, size 0 D: section 4 at 36c: name 43, type 8, flags 3, addr 0, size 0 D: section 5 at 394: name 48, type 1, flags 2, addr 0, size 47 D: section 6 at 3bc: name 60, type 1, flags 2, addr 0, size 8 D: section 7 at 3e4: name 56, type 9, flags 40, addr 0, size 16 D: section 8 at 40c: name 74, type 1, flags 30, addr 0, size 35 D: section 9 at 434: name 83, type 1879048195, flags 0, addr 0, size 54 D: section 10 at 45c: name 1, type 2, flags 0, addr 0, size 272 D: symtab at 10 D: section 11 at 484: name 9, type 3, flags 0, addr 0, size 65 D: strtab at 11 D: section 12 at 4ac: name 17, type 3, flags 0, addr 0, size 99 D: shstrtab at 12 D: Allocate and copy strings... D: Mapping ELF sections... D: section 0 name D: Not copied section D: section 1 name .text D: section 2 name .rel.text D: Not copied section .rel.text D: section 3 name .data D: section 4 name .bss D: section 5 name .rodata D: section 6 name .exported_sym D: section 7 name .rel.exported_sym D: Not copied section .rel.exported_sym D: section 8 name .comment D: Not copied section .comment D: section 9 name .ARM.attributes D: Not copied section .ARM.attributes D: section 10 name .symtab D: Not copied section .symtab D: section 11 name .strtab D: Not copied section .strtab D: section 12 name .shstrtab D: Not copied section .shstrtab D: Allocate and copy sections... D: Counting exported symbols... D: symbol count 17 D: unhandled symbol 1, name hello_world_ext.c, type tag 4, bind 0, sect 65521 D: unhandled symbol 2, name , type tag 3, bind 0, sect 1 D: unhandled symbol 3, name , type tag 3, bind 0, sect 3 D: unhandled symbol 4, name , type tag 3, bind 0, sect 4 D: unhandled symbol 5, name , type tag 3, bind 0, sect 5 D: unhandled symbol 6, name $d, type tag 0, bind 0, sect 5 D: unhandled symbol 7, name number, type tag 1, bind 0, sect 5 D: unhandled symbol 8, name $t, type tag 0, bind 0, sect 1 D: unhandled symbol 9, name $d, type tag 0, bind 0, sect 1 D: unhandled symbol 10, name , type tag 3, bind 0, sect 6 D: unhandled symbol 11, name $d, type tag 0, bind 0, sect 6 D: unhandled symbol 12, name test_entry_sym, type tag 1, bind 0, sect 6 D: unhandled symbol 13, name , type tag 3, bind 0, sect 8 D: unhandled symbol 14, name , type tag 3, bind 0, sect 9 D: function symbol 15, name test_entry, type tag 2, bind 1, sect 1 D: unhandled symbol 16, name printk, type tag 0, bind 1, sect 0 D: Allocating memory for symbol table... D: Copying symbols... D: function symbol 0 name test_entry addr 0x20009ec1 D: Linking ELF... D: relocation section .rel.text (2) linked to section 10 has 3 relocations D: relocation 2:0 info 502 (type 2, sym 5) offset 24 sym_name sym_type 3 sym_bind 0 sym_ndx 5 I: found section symbol addr 0x20009f40 I: writing relocation symbol type 2 sym 5 at addr 0x20009ed8 addr 0x20009f40 D: 2 20009ed8 20009f40 D: relocation 2:1 info 1002 (type 2, sym 16) offset 28 sym_name printk sym_type 0 sym_bind 1 sym_ndx 0 I: found symbol printk at 0x11f45 I: writing relocation symbol printk type 2 sym 16 at addr 0x20009edc addr 0x11f45 D: 2 20009edc 11f45 printk D: relocation 2:2 info 502 (type 2, sym 5) offset 32 sym_name sym_type 3 sym_bind 0 sym_ndx 5 I: found section symbol addr 0x20009f40 I: writing relocation symbol type 2 sym 5 at addr 0x20009ee0 addr 0x20009f40 D: 2 20009ee0 20009f40 D: relocation section .rel.exported_sym (7) linked to section 10 has 2 relocations D: relocation 7:0 info 502 (type 2, sym 5) offset 0 sym_name sym_type 3 sym_bind 0 sym_ndx 5 I: found section symbol addr 0x20009f40 I: writing relocation symbol type 2 sym 5 at addr 0x20009cc0 addr 0x20009f40 D: 2 20009cc0 20009f40 D: relocation 7:1 info f02 (type 2, sym 15) offset 4 sym_name test_entry sym_type 2 sym_bind 1 sym_ndx 1 I: found section symbol test_entry addr 0x20009ec1 I: writing relocation symbol test_entry type 2 sym 15 at addr 0x20009cc4 addr 0x20009ec1 D: 2 20009cc4 20009ec1 test_entry D: sym 0x20009ec1 name test_entry in 0x20009e84 D: loaded module, .text at 0x20009ec0, .rodata at 0x20009f40 I: Loaded extension hello_world E: MPU FAULT E: Instruction Access Violation E: r0/a1: 0x20009ec1 r1/a2: 0x00015f60 r2/a3: 0x00000000 E: r3/a4: 0x00000000 r12/ip: 0x00000000 r14/lr: 0x00012207 E: xpsr: 0x61000000 E: Faulting instruction address (r15/pc): 0x20009ec0 E: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0 E: Current thread: 0x20008218 (test_load_unload_hello_world) E: Halting system
pillo79
commented
1 week ago Hello @SunnyVibrant and thanks for following up. This is consistent with your previous logs - it appears the MPU is enabled and prevents the CPU from running from "a data buffer" (the way it sees the loaded LLEXT). On most ARM targets, you have two options to work around this:
CONFIG_ARM_MPU, so this check (and many others) are simply not performed, orCONFIG_USERSPACE (if the platform allows) so LLEXT can use the userspace API to update the memory layout and access restrictions.This should have been picked up automatically by the test suite build though.
I don't have that board, but I tried to build it both via west build and west twister and the results differ.
west build tests/subsys/llext/simple -p -T llext.simple.readonly -b nrf9160dk/nrf9160does NOT use arch-specific flags in testcase.yaml (but interestingly, does properly set STORAGE_WRITABLE!), and results in a non-working build. Instead, the following does use the proper set of flags:
west twister -nv -p nrf9160dk/nrf9160 -T tests/subsys/llext/simple/ -s llext.simple.readonly(the output in this case is in the arcane twister-out/nrf9160dk_nrf9160/tests/subsys/llext/simple/llext.simple.readonly folder). Can you try flashing that to see if it works properly?
@teburd any idea if this difference is expected behavior? I'm guessing not!
SunnyVibrant
commented
4 days ago Hello @SunnyVibrant and thanks for following up. This is consistent with your previous logs - it appears the MPU is enabled and prevents the CPU from running from "a data buffer" (the way it sees the loaded LLEXT). On most ARM targets, you have two options to work around this:
- disable
CONFIG_ARM_MPU, so this check (and many others) are simply not performed, or- enable
CONFIG_USERSPACE(if the platform allows) so LLEXT can use the userspace API to update the memory layout and access restrictions.This should have been picked up automatically by the test suite build though. I don't have that board, but I tried to build it both via
west buildandwest twisterand the results differ.west build tests/subsys/llext/simple -p -T llext.simple.readonly -b nrf9160dk/nrf9160does NOT use arch-specific flags in
testcase.yaml(but interestingly, does properly setSTORAGE_WRITABLE!), and results in a non-working build. Instead, the following does use the proper set of flags:west twister -nv -p nrf9160dk/nrf9160 -T tests/subsys/llext/simple/ -s llext.simple.readonly(the output in this case is in the arcane
twister-out/nrf9160dk_nrf9160/tests/subsys/llext/simple/llext.simple.readonlyfolder). Can you try flashing that to see if it works properly?@teburd any idea if this difference is expected behavior? I'm guessing not!
@pillo79 Thank you!! Thank you!! We will try those steps and keep you updated on this.
Describe the bug
We are using the nRF9160-DK (ARM platform) and are running the llext examples. However, we encounter a NULL return when calling
llext_find_sym(). Could you please confirm if there are any architecture limitations or known issues related to using llext on the nRF9160-DK?We are using the module below to verify the llext functionality: https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/subsys/llext/modules
Here are the configurations we tried:
We commented the
printkstatement, and a crash is observed. Logs are provided in the link below: Crash logs: https://drive.google.com/file/d/1TWCxfk2OyxBhDFBD4J0x43b8Su7x49Sn/view?usp=sharingCode reference: https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/subsys/llext/modules/src/hello_world_ext.c#L24
Thank you for your support!
To Reproduce Steps to reproduce the behavior:
samples/subsys/llext/modulesllext_find_sym()Expected behavior
llext_find_sym()should not return NULL when using llext on the nRF9160-DK, and the example should run without crashing.Impact This issue is a showstopper as it prevents us from verifying the llext functionality on the nRF9160-DK.
Logs and console output Crash logs: https://drive.google.com/file/d/1TWCxfk2OyxBhDFBD4J0x43b8Su7x49Sn/view?usp=sharing Logs https://drive.google.com/file/d/1TWCxfk2OyxBhDFBD4J0x43b8Su7x49Sn/view?usp=drive_link
Environment (please complete the following information):