elf2uf2 on s390x: ERROR: Not an ELF file #104
Comments
|
I guess this would be fixed by raspberrypi/pico-sdk#329 ? |
|
Thank you! In the mean-time I had this patch cooked up: --- a/tools/elf2uf2/main.cpp 2023-06-13 22:27:33.000000000 +0000
+++ b/tools/elf2uf2/main.cpp 2024-06-05 08:20:56.156138030 +0000
@@ -11,6 +11,7 @@
#include <cstring>
#include <cstdarg>
#include <algorithm>
+#include <endian.h>
#include "boot/uf2.h"
#include "elf.h"
@@ -101,6 +103,20 @@
if (1 != fread(&eh_out, sizeof(eh_out), 1, in)) {
return fail(ERROR_READ_FAILED, "Unable to read ELF header");
}
+ eh_out.common.magic = le32toh(eh_out.common.magic);
+ eh_out.common.type = le16toh(eh_out.common.type);
+ eh_out.common.machine = le16toh(eh_out.common.machine);
+ eh_out.common.version2 = le32toh(eh_out.common.version2);
+ eh_out.entry = le32toh(eh_out.entry);
+ eh_out.ph_offset = le32toh(eh_out.ph_offset);
+ eh_out.sh_offset = le32toh(eh_out.sh_offset);
+ eh_out.flags = le32toh(eh_out.flags);
+ eh_out.eh_size = le16toh(eh_out.eh_size);
+ eh_out.ph_entry_size = le16toh(eh_out.ph_entry_size);
+ eh_out.ph_num = le16toh(eh_out.ph_num);
+ eh_out.sh_entry_size = le16toh(eh_out.sh_entry_size);
+ eh_out.sh_num = le16toh(eh_out.sh_num);
+ eh_out.sh_str_index = le16toh(eh_out.sh_str_index);
if (eh_out.common.magic != ELF_MAGIC) {
return fail(ERROR_FORMAT, "Not an ELF file");
}
@@ -154,6 +175,16 @@
if (eh.ph_num != fread(&entries[0], sizeof(struct elf32_ph_entry), eh.ph_num, in)) {
return fail_read_error();
}
+ for (int i = 0; i < eh.ph_num; i++) {
+ entries[i].type = le32toh(entries[i].type);
+ entries[i].offset = le32toh(entries[i].offset);
+ entries[i].vaddr = le32toh(entries[i].vaddr);
+ entries[i].paddr = le32toh(entries[i].paddr);
+ entries[i].filez = le32toh(entries[i].filez);
+ entries[i].memsz = le32toh(entries[i].memsz);
+ entries[i].flags = le32toh(entries[i].flags);
+ entries[i].align = le32toh(entries[i].align);
+ }
}
return 0;
}I also rebased the patch from raspberrypi/pico-sdk#329 onto my local pico-sdk version and: It works fine, thank you! |
|
Transfering this over to picotool, as that's where the elf2uf2 functionality is now I believe that I have fixed this (in a different way to raspberrypi/pico-sdk#329) for the @josch Could you test the new picotool and see if this issue has actually been fixed for big-endian systems? |
Thank you for working on this! I tried building the new pico-sdk and picotool 2.0 but there seems to be a build dependency loop here and I'm unsure how I am supposed to resolve it. When building pico-sdk 2.0 I get: And when trying to build picotool I get: How am I as a distribution packager supposed to resolve this in practice? Thank you! |
|
Picotool doesn’t require a built SDK, it just requires some of the SDK header files, so you should be able to build picotool first and then build the SDK. I’m not familiar with packaging, but I hope that should be possible? |
|
Additionally, if you’re looking into packaging pico-sdk and picotool then I’d be happy to answer any other questions you have about them |
But if building picotool requires SDK header files, then i need to build the SDK first to create a package containing these header files. But I cannot build the SDK without picotool. If there is no way around this, then I will have to merge both source packages into one because either one cannot be build without having the source of the other available.
It's already packaged: But with version 2.0 there seems to be a circular dependency between the two. Maybe there is some cmake flag i can pass to break this cycle? |
|
You can pass -DPICO_NO_PICOTOOL=1 to the SDK build, and it will skip anything that requires picotool, which for building the SDK is just the UF2s for the test programs. So that flag should be fine for just building the docs. Also, looking at that package, you don’t currently have a pioasm binary - it might be helpful to build and install that (either as part of the sdk, or a separate package), which can be done by |
|
Thank you, I implemented both your suggestions. That was very helpful, thanks! I'll upload pico-sdk 2.0 to experimental soon and am now stuck with also updating picotool to 2.0: #139 |
If you don't mind I'd like to abuse this issue for another packaging related question. Both pico-sdk as well as picotool are now in Debian unstable in version 2.0: Now suppose somebody wants to use that package in their project. Lets look at this minimal reproducer: cmake_minimum_required(VERSION 3.13)
include(/usr/src/pico-sdk/pico_sdk_init.cmake)
project(hello_world)
pico_sdk_init()
add_executable(hello_world hello.c)
target_link_libraries(hello_world pico_stdlib)
pico_add_extra_outputs(hello_world)#include <stdio.h>
#include "pico/stdlib.h"
int main() {
setup_default_uart();
printf("Hello, world!\n");
return 0;
}But trying to build this will fail with: So it cannot find picotool. The picotool Debian package installs the cmake files: So why does Thanks! |
|
Ah yes - you'll need commit 6ad9c23 as well, which changes the install dir to You'll probably also want to take raspberrypi/pico-sdk#1865 as well, which applies the same fix to pioasm |
|
Aha! raspberrypi/pico-sdk#1865 reminds me of a very similar fix that I already did to pico-sdk to fix the pioasm cmake installation path: https://sources.debian.org/src/pico-sdk/2.0.0-1/debian/patches/pioasm.cmake.patch/ As you can see from that patch, I chose to let it install to In any case, I'll apply your patch and report back once everything is built. Thanks! |
|
Okay, no that picotool 2.0 and pico-sdk 2.0 are both finally in Debian and building on all architectures, lets get back to the original problem of s390x. Right now, the test script, which compiles a "hello world" program as I posted above, succeeds on all architectures except for s390x: https://ci.debian.net/packages/p/pico-sdk/testing/s390x/51562659/ I can have a closer look on real s390x hardware later, but maybe you already have some theories that I could check? Not sure if this is picotool or pico-sdk related? |
|
Ah yes, it fails in the |
|
Random guess (I know nothing about "exotic" architectures or OSes), but could this be related to #133 ? |
|
Could you try setting |
You mean like this? cmake_minimum_required(VERSION 3.13)
set(PICO_NO_UF2 ON)
include(pico_sdk_import.cmake)
project(hello_world)
pico_sdk_init()
add_executable(hello_world hello.c)
target_link_libraries(hello_world pico_stdlib)
pico_add_extra_outputs(hello_world)With that setting, the build will succeed but i guess that's because |
|
Can you try this patch to picotool? |
Thank you, with that I get: So I guess success? I'll add that patch to the Debian package and upload it again so that it can run on the CI servers. Thank you! |
|
It looks like more is required - that patch fixes the ELF handling, but the UF2 is being written with big-endian ints when they should be little. I've got a docker container up and running with qemu emulation of s390x, so I can now test big-endian handling and will see if I can get something working |
Thank you! With the patch you pasted 12 hours ago, running |
Hi,
I have this
CMakeLists.txt:and this hello-world program (yes this program is not even making use of the pico sdk but the problem is also there if we add that):
On s390x the build will fail like this:
I added some printfs into
tools/elf2uf2/main.cppto investigate the values ofELF_MAGICandeh_out.common.magicinread_and_check_elf32_headerand got this:There seems to be an endian problem somewhere? The
fileutility seems to think that myhello_world.elfhas the correct magic:Any ideas?
The text was updated successfully, but these errors were encountered: