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
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()
--
2.47.0On 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
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>
© 2016 - 2024 Red Hat, Inc.