Hi Rick!
I’m aware that the elftoaout utility exists, this isn’t really my concern though.
I’m concerned about an upstream solution, preferably with an elftoaout utility being part of the upstream sources.
Adrian Hi Gregor, Adrian
I don't know if this is helpful, but Ubuntu Launchpad has a ppa package for elftoaout which has been built recently.
https://launchpad.net/~likemartinma/+archive/ubuntu/elftoaout
Cheers -- Rick On August 10, 2018 8:12:47 PM ADT, Gregor Riepl < onitake@gmail.com> wrote:
We could modify sparc-utils maybe that it builds on the release architectures similar to what the hppa porters do with their palo package.
I'll have a look. It doesn't look like this package would only build/work on sparc. Usefulness is a different matter - but that's probably outside the scope of acceptance criteria?
Correct. Usefulness doesn't matter. Maybe there is another package or upstream project that offers an elftoaout tool?
So for now, I manually modified the boot image build step to strip with objcopy first, then convert with elftoaout from sparc-utils.
The resulting boot.img is identical to the one installed by grub-ieee1275-bin_2.02+dfsg1-4 - that looks promising! This means we have at least a method to build the boot code without a.out support in objcopy. I also looked into making OpenBoot run the ELF binary directly, but that seems impossible for an unexpected reason: boot.img is written directly into the boot sector of the /boot partition, and there is simply not enough space to accommodate the ELF binary. It's 816 bytes, while the a.out is exactly 512.
I'll discuss integrating the change with the grub2 package maintainer and upstream, if that's ok for you. And I'll take a look at the sparc-utils package, maybe making it build for any instead of just sparc64 (as discussed).
--
Sorry for being brief. Alternate email is rickleir at yahoo dot com
|