| Message ID | 20241024082735.42324-3-thuth@redhat.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Re-enable the sh4eb target | expand |
On 24/10/24 05:27, Thomas Huth wrote: > Now that we are aware of binaries that are available for sh4eb, > we should make sure that there are no regressions with this > target and test it regularly in our CI. > > Signed-off-by: Thomas Huth <thuth@redhat.com> > --- > tests/functional/meson.build | 3 +++ > tests/functional/test_sh4eb_r2d.py | 33 ++++++++++++++++++++++++++++++ > 2 files changed, 36 insertions(+) > create mode 100755 tests/functional/test_sh4eb_r2d.py Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
On 10/24/24 03:27, Thomas Huth wrote: > Now that we are aware of binaries that are available for sh4eb, > we should make sure that there are no regressions with this > target and test it regularly in our CI. Any progress on restoring this? Didn't see it in "git pull" just now... > +class R2dEBTest(LinuxKernelTest): > + > + ASSET_TGZ = Asset( > + 'https://landley.net/bin/mkroot/0.8.11/sh4eb.tgz', > + 'be8c6cb5aef8406899dc5aa5e22b6aa45840eb886cdd3ced51555c10577ada2c') Feel free to pull binaries from my site, but from a reliability perspective "some random dude got hit by a bus so a site went down that broke our test infrastructure" seems a bit dodgy. (Even the Internet Archive has been having reliability issues of late, and "as long as Brewster Kahle's dot-com money holds out" seems a similar bus number.) Building it yourself from source seems more reliable. Is there any sort of policy here? I build the toolchains, kernel, and userspace entirely from source and can provide the reproduction sequences for those if you like. It's part of my mkroot project, which is attempting to build small qemu systems for every target supported by all of: 1) qemu 2) linux 3) musl-libc 4) gcc And even do automated smoketests on them showing it can boot, run a shell script, and access a virtual block device and network connection: https://github.com/landley/toybox/blob/master/mkroot/testroot.sh Alas a lot of targets I would LIKE to support are missing something in one or more of those 4 packages. (No sparc in musl, etc.) At the moment this lack is most obvious to me for nommu support. If I want fdpic then linux/fs/Kconfig.binfmt says my options are: config BINFMT_ELF_FDPIC bool "Kernel support for FDPIC ELF binaries" default y if !BINFMT_ELF depends on ARM || ((M68K || RISCV || SUPERH || XTENSA) && !MMU) But gcc's source says my options are: $ grep -lir fdpic gcc/config | xargs dirname | uniq gcc/config/frv gcc/config/sh gcc/config/bfin gcc/config/arm Which is exactly TWO targets that overlap. (There were two more, but Linux commit f5a8eb632b56 removed bfin and frv in 2018, and while I've followed arm-fdpic development since 2016 I have yet to get it to work for me.) (NOMMU support is a bit like eukaryote cells in biology: beneath most people's notice but EVERYWHERE, to the point that ecosystem physically outweighs the "more advanced" one if you add up each instance of both.) While you can do PIE binaries on nommu (which is what buildroot and Buildroot and https://github.com/gregungerer/simple-linux do for the other nommu architectures), that just doesn't scale. If you run two PIE instances of "bash" on nommu it loads two copies of the bash binary into memory, AND each one requires one big contiguous block of memory for the text, rodata, bss, and data segments all together. The point of fdpic is those four segments relocate independently, so multiple instances of the same program can share text and rodata, and also use smaller chunks of memory for bss and data which is much easier to come by in system without an mmu to let virtual mappings collate fragmented physical memory. On nommu memory fragmentation is basically inevitable. Rob P.S. In theory I could try linux's nolibc.h instead of musl but building toybox under that is quite the lift, and I briefly had an llvm hexagon build working instead of gcc (copied from your test stuff, but https://compiler-rt.llvm.org/ is just apocalyptically badly designed that the easy way to get a portable build out of it honestly seems to be to write a new replacement library from scratch).
On 29/10/2024 18.58, Rob Landley wrote: > On 10/24/24 03:27, Thomas Huth wrote: >> Now that we are aware of binaries that are available for sh4eb, >> we should make sure that there are no regressions with this >> target and test it regularly in our CI. > > Any progress on restoring this? Didn't see it in "git pull" just now... I'll make sure to put the patches in my next pull request before the QEMU soft freeze starts next week. >> +class R2dEBTest(LinuxKernelTest): >> + >> + ASSET_TGZ = Asset( >> + 'https://landley.net/bin/mkroot/0.8.11/sh4eb.tgz', >> + 'be8c6cb5aef8406899dc5aa5e22b6aa45840eb886cdd3ced51555c10577ada2c') > > Feel free to pull binaries from my site, but from a reliability perspective > "some random dude got hit by a bus so a site went down that broke our test > infrastructure" seems a bit dodgy. (Even the Internet Archive has been > having reliability issues of late, and "as long as Brewster Kahle's dot-com > money holds out" seems a similar bus number.) > > Building it yourself from source seems more reliable. Is there any sort of > policy here? We don't really have any infrastructure in place for building such assets within the QEMU CI, but the binaries get cached locally after the initial download, so we should at least be able to retrieve them from these caches in case your original site becomes unavailable ... > And even do automated smoketests on them showing it can boot, run a shell > script, and access a virtual block device and network connection: > > https://github.com/landley/toybox/blob/master/mkroot/testroot.sh ... but if you're using github anyway, maybe you could also build the binaries via github actions and publish the assets there? That would make it easier for cloning and reproducing the stuff, I think. Anyway, thank you very much for providing the binaries already on your site, that's really helpful! Thomas
diff --git a/tests/functional/meson.build b/tests/functional/meson.build index d4b675bf63..d642c11516 100644 --- a/tests/functional/meson.build +++ b/tests/functional/meson.build @@ -160,6 +160,9 @@ tests_sh4_system_thorough = [ 'sh4_tuxrun', ] +tests_sh4eb_system_thorough = [ + 'sh4eb_r2d', +] tests_sparc_system_thorough = [ 'sparc_sun4m', diff --git a/tests/functional/test_sh4eb_r2d.py b/tests/functional/test_sh4eb_r2d.py new file mode 100755 index 0000000000..d9c022c8b8 --- /dev/null +++ b/tests/functional/test_sh4eb_r2d.py @@ -0,0 +1,33 @@ +#!/usr/bin/env python3 +# +# Boot a Linux kernel on a r2d sh4eb machine and check the console +# +# SPDX-License-Identifier: GPL-2.0-or-later + +import os +import shutil + +from qemu_test import LinuxKernelTest, Asset +from qemu_test import exec_command_and_wait_for_pattern +from qemu_test.utils import archive_extract +from unittest import skipUnless + +class R2dEBTest(LinuxKernelTest): + + ASSET_TGZ = Asset( + 'https://landley.net/bin/mkroot/0.8.11/sh4eb.tgz', + 'be8c6cb5aef8406899dc5aa5e22b6aa45840eb886cdd3ced51555c10577ada2c') + + def test_sh4eb_r2d(self): + self.set_machine('r2d') + file_path = self.ASSET_TGZ.fetch() + archive_extract(file_path, self.workdir) + self.vm.add_args('-append', 'console=ttySC1 noiotrap') + self.launch_kernel(os.path.join(self.workdir, 'sh4eb/linux-kernel'), + initrd=os.path.join(self.workdir, 'sh4eb/initramfs.cpio.gz'), + console_index=1, wait_for='Type exit when done') + exec_command_and_wait_for_pattern(self, 'exit', 'Restarting system') + shutil.rmtree(os.path.join(self.workdir, 'sh4eb')) + +if __name__ == '__main__': + LinuxKernelTest.main()
Now that we are aware of binaries that are available for sh4eb, we should make sure that there are no regressions with this target and test it regularly in our CI. Signed-off-by: Thomas Huth <thuth@redhat.com> --- tests/functional/meson.build | 3 +++ tests/functional/test_sh4eb_r2d.py | 33 ++++++++++++++++++++++++++++++ 2 files changed, 36 insertions(+) create mode 100755 tests/functional/test_sh4eb_r2d.py