The OpenWRT 24.10 for Enterasys WS-AP3715i is found unable to boot, but older version can, later, the reporter found the cause of this issue to be that an early commit forgot to change the load address linked into the simpleImage for WS-AP3715i which should be patched into the file arch/powerpc/boot/wrapper of Linux kernel, but changed the load address declared in the uImage header, making the simpleImage for WS-AP3715i not loaded to its destined address. This issue was fixed by the reporter via unifying the load address for most mpc85xx targets using the simpleImage format in a a dedicated patch file.
This issue suggests that the simpleImages (at least those used in OpenWRT) are not position-independent, but necessary to load to a specific address to run. Inspecting the build process, we found that these simpleImages are initially linked as an elf executable, which contains the load address in the header, but later converted to flat binary form with objcopy(1), and all information present on elf format is lost during the process. Besides, the elf executable intermediates are only generated during the build process of OpenWRT, and not shipped with the OpenWRT image builder.
Even so, the final simpleImage may still contain hints about its destined load address. Most importantly, the file arch/powerpc/boot/crt0.S has p_start: .long _start, meaning this file defines a symbol p_start, which will have the value identical to another symbol _start, which is defined in arch/powerpc/boot/zImage.lds.S and marks the entry point (also the load address) for simpleImages. Even all symbol is lost during the conversion from elf to
flat binary, the offset of symbol p_start may proves to be fixed, and we could craft a program to find it from the simpleImages in flat binary form.
At this point, we want to utilize AI to craft the program, so we described our goal, allowed input and exemplar data
in description.md, provided crt0.S, zImage.lds.S, a simpleImage file with known load address and the corresponding elf form for the AI to analyse. We originally allow the usage of libbfd, libctf, libopcodes, but AI did not use them in the final generated program. Instead, the generated program works by finding the code pattern around the entry point of the p_base() function defined in crt0.S, which should be seldom changed, and p_start lies on a fixed offset related to p_base(). Reading the value stored at the address of p_start could obtain the real load address. The program should work until either the entry of p_base() or the offset to p_start changes.
Before the final result, the AI also generated many ridiculous, even deceitful program, caused by a description not precise enough for the goal and constraint. For example, the penultimate generation is a program taking the elf file as input and output the load address, but this can be done simply with objdump -f, and the elf form should not be considered available in the expected use case. After describing these constraint precisely, the AI could generate the expected code.