| Message ID | 0833846b9fc9e2260f9aa2c732a12d9dfa329286.1690916314.git.falcon@tinylab.org (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | tools/nolibc: add 32/64-bit powerpc support | expand |
Hi, Willy, Thomas Yuan is helping me to test this series and the tinyconfig series with the latest compilers. His first test found this ppc support failed with stackprotector when using a newer compiler (I used an older compiler without stackprotector for ppc), I'm debugging it, so, please ignore this revision too, of course, if time allows, welcome to take a look at the other patches. His other tests are trying to find out the exact poweroff support options for every architecture one by one, let's fill this gap ... Thanks, Zhangjin > Kernel uses ARCH=powerpc for both 32-bit and 64-bit PowerPC, here adds a > ppc variant for 32-bit PowerPC and uses it as the default variant of > powerpc architecture. > > Users can pass ARCH=powerpc or XARCH=ppc to test 32-bit PowerPC. > > The default qemu-system-ppc g3beige machine [1] is used to run 32-bit > powerpc kernel. > > The pmac32_defconfig is used with extra PMACZILOG console options to > enable normal print. > > Note, zImage doesn't boot due to "qemu-system-ppc: Some ROM regions are > overlapping" error, so, vmlinux is used instead. > > [1]: https://qemu.readthedocs.io/en/latest/system/ppc/powermac.html > > Suggested-by: Willy Tarreau <w@1wt.eu> > Link: https://lore.kernel.org/lkml/ZL9leVOI25S2+0+g@1wt.eu/ > Reviewed-by: Thomas Weißschuh <linux@weissschuh.net> > Signed-off-by: Zhangjin Wu <falcon@tinylab.org> > --- > tools/testing/selftests/nolibc/Makefile | 6 ++++++ > .../testing/selftests/nolibc/configs/nolibc-test-ppc.config | 3 +++ > 2 files changed, 9 insertions(+) > create mode 100644 tools/testing/selftests/nolibc/configs/nolibc-test-ppc.config > > diff --git a/tools/testing/selftests/nolibc/Makefile b/tools/testing/selftests/nolibc/Makefile > index 3c9e3963fbad..29e02b49903a 100644 > --- a/tools/testing/selftests/nolibc/Makefile > +++ b/tools/testing/selftests/nolibc/Makefile > @@ -33,9 +33,11 @@ endif > # architectures where both are equal. > > # configure default variants for target kernel supported architectures > +XARCH_powerpc = ppc > XARCH = $(or $(XARCH_$(ARCH)),$(ARCH)) > > # map from user input variants to their kernel supported architectures > +ARCH_ppc = powerpc > ARCH := $(or $(ARCH_$(XARCH)),$(XARCH)) > > # kernel image names by architecture > @@ -45,6 +47,7 @@ IMAGE_x86 = arch/x86/boot/bzImage > IMAGE_arm64 = arch/arm64/boot/Image > IMAGE_arm = arch/arm/boot/zImage > IMAGE_mips = vmlinuz > +IMAGE_ppc = vmlinux > IMAGE_riscv = arch/riscv/boot/Image > IMAGE_s390 = arch/s390/boot/bzImage > IMAGE_loongarch = arch/loongarch/boot/vmlinuz.efi > @@ -58,6 +61,7 @@ DEFCONFIG_x86 = defconfig > DEFCONFIG_arm64 = defconfig > DEFCONFIG_arm = multi_v7_defconfig > DEFCONFIG_mips = malta_defconfig > +DEFCONFIG_ppc = pmac32_defconfig > DEFCONFIG_riscv = defconfig > DEFCONFIG_s390 = defconfig > DEFCONFIG_loongarch = defconfig > @@ -77,6 +81,7 @@ QEMU_ARCH_x86 = x86_64 > QEMU_ARCH_arm64 = aarch64 > QEMU_ARCH_arm = arm > QEMU_ARCH_mips = mipsel # works with malta_defconfig > +QEMU_ARCH_ppc = ppc > QEMU_ARCH_riscv = riscv64 > QEMU_ARCH_s390 = s390x > QEMU_ARCH_loongarch = loongarch64 > @@ -89,6 +94,7 @@ QEMU_ARGS_x86 = -M pc -append "console=ttyS0,9600 i8042.noaux panic=-1 $( > QEMU_ARGS_arm64 = -M virt -cpu cortex-a53 -append "panic=-1 $(TEST:%=NOLIBC_TEST=%)" > QEMU_ARGS_arm = -M virt -append "panic=-1 $(TEST:%=NOLIBC_TEST=%)" > QEMU_ARGS_mips = -M malta -append "panic=-1 $(TEST:%=NOLIBC_TEST=%)" > +QEMU_ARGS_ppc = -M g3beige -append "console=ttyS0 panic=-1 $(TEST:%=NOLIBC_TEST=%)" > QEMU_ARGS_riscv = -M virt -append "console=ttyS0 panic=-1 $(TEST:%=NOLIBC_TEST=%)" > QEMU_ARGS_s390 = -M s390-ccw-virtio -m 1G -append "console=ttyS0 panic=-1 $(TEST:%=NOLIBC_TEST=%)" > QEMU_ARGS_loongarch = -M virt -append "console=ttyS0,115200 panic=-1 $(TEST:%=NOLIBC_TEST=%)" > diff --git a/tools/testing/selftests/nolibc/configs/nolibc-test-ppc.config b/tools/testing/selftests/nolibc/configs/nolibc-test-ppc.config > new file mode 100644 > index 000000000000..b1975f8253f7 > --- /dev/null > +++ b/tools/testing/selftests/nolibc/configs/nolibc-test-ppc.config > @@ -0,0 +1,3 @@ > +CONFIG_SERIAL_PMACZILOG=y > +CONFIG_SERIAL_PMACZILOG_TTYS=y > +CONFIG_SERIAL_PMACZILOG_CONSOLE=y > -- > 2.25.1
Hi Zhangjin, On Wed, Aug 02, 2023 at 01:21:50PM +0800, Zhangjin Wu wrote: > Hi, Willy, Thomas > > Yuan is helping me to test this series and the tinyconfig series with > the latest compilers. > > His first test found this ppc support failed with stackprotector when > using a newer compiler (I used an older compiler without stackprotector > for ppc), I'm debugging it, so, please ignore this revision too, of > course, if time allows, welcome to take a look at the other patches. > > His other tests are trying to find out the exact poweroff support > options for every architecture one by one, let's fill this gap ... Thanks for notifying us. I strongly suggest that you leave ppc32 aside for now, until the rest is completely validated and merged. It turns out that your willingness to work around some of the oddities met on this one have resulted in a lot of drift away from the "keep it simple" principle and significantly delayed the possibilities to integrate the rest of your work. It would be much saner to only focus on ppc64/ppc64le and figure later how to make ppc32 work (or decide not to support it if it's not worth the effort in the end). Regards, willy
Hi, Willy, Hi Thomas Good news for us ;-) > Hi Zhangjin, > > On Wed, Aug 02, 2023 at 01:21:50PM +0800, Zhangjin Wu wrote: > > Hi, Willy, Thomas > > > > Yuan is helping me to test this series and the tinyconfig series with > > the latest compilers. > > > > His first test found this ppc support failed with stackprotector when > > using a newer compiler (I used an older compiler without stackprotector > > for ppc), I'm debugging it, so, please ignore this revision too, of > > course, if time allows, welcome to take a look at the other patches. > > > > His other tests are trying to find out the exact poweroff support > > options for every architecture one by one, let's fill this gap ... > > Thanks for notifying us. I strongly suggest that you leave ppc32 aside > for now, until the rest is completely validated and merged. It turns Thanks very much, but good progress here ;-) I compared some compilers and at last got the root cause of the ppc32 failure with stackprotector. //// gcc 13.1.0 from mirrors.edge.kernel.org $ make run-user XARCH=ppc -j4 CC=/labs/linux-lab/prebuilt/toolchains/ppc64le/gcc-13.1.0-nolibc/powerpc64-linux/bin/powerpc64-linux-gcc ... Segmentation fault (core dumped) 0 test(s): 0 passed, 0 skipped, 0 failed => status: success See all results in /labs/linux-lab/src/linux-stable/tools/testing/selftests/nolibc/run.out //// gcc 10 from ubuntu ppa $ make run-user XARCH=ppc -j4 CC=/usr/bin/powerpc-linux-gnu-gcc-10 ... 165 test(s): 157 passed, 8 skipped, 0 failed => status: warning See all results in /labs/linux-lab/src/linux-stable/tools/testing/selftests/nolibc/run.out $ grep stack run.out 0 -fstackprotector [OK] And then compared the assemblies, found gcc 13.1.0 insert a bad instruction at the beginning of _start() and break our stack eventually. start: stwu 1,-16(1) Further compared the preprocessed files, found the root cause is the new compiler using 'no_stack_protector' instead of '__optimize__("-fno-stack-protector")'. And the attribute 'no_stack_protector' breaks our "omit-frame-pointer" like the failure with '-O0' we fixed before. I checked some of the other architectures, they didn't have the same issue, but test shows the 'no_stack_protector' attribute does have such compability issue here. I learned the commit message of tools/include/nolibc/compiler.h, seems __optimize__("-fno-stack-protector") is enough for all of the nolibc supported architectures? is it ok for us to simply give up 'no_stack_protector' eventully? otherwise, we should manually disable 'no_stack_protector' for ppc32: #define __no_stack_protector __attribute__((__optimize__("-fno-stack-protector"))) Benefit from the __no_stack_protetor macro, we have no need to input __optimize__("-fno-stack-protector") for every new architecture, it may be the time to only use __optimize__("-fno-stack-protector"), am I missing something? > out that your willingness to work around some of the oddities met on > this one have resulted in a lot of drift away from the "keep it simple" > principle and significantly delayed the possibilities to integrate the > rest of your work. It would be much saner to only focus on ppc64/ppc64le > and figure later how to make ppc32 work (or decide not to support it if > it's not worth the effort in the end). Another test shows, the run target of ppc64le with the big endian gcc 13.1.0 toolchain has test startup failure (although we have verified run-user before, run-user ok! and run with local powerpc64le toolchain ok too!), I'm debugging this now, hope it not cost too much. Another good news is, Yuan has found a working defconfig for ppc32 which has poweroff support and he is helping me narrowing down the exact options, this will eventually make us happy ;-) Thanks & Best regards, Zhangjin > > Regards, > willy
Hi, Willy, Hi Thomas I'm so happy to share with you, we have solved all of the left found issues, include the ones about ppc and the missing poweroff options for the tinyconfig series, will renew both series ;-) > Further compared the preprocessed files, found the root cause is the new > compiler using 'no_stack_protector' instead of > '__optimize__("-fno-stack-protector")'. And the attribute 'no_stack_protector' > breaks our "omit-frame-pointer" like the failure with '-O0' we fixed before. > > I checked some of the other architectures, they didn't have the same issue, but > test shows the 'no_stack_protector' attribute does have such compability issue > here. > > I learned the commit message of tools/include/nolibc/compiler.h, seems > __optimize__("-fno-stack-protector") is enough for all of the nolibc supported > architectures? is it ok for us to simply give up 'no_stack_protector' > eventully? otherwise, we should manually disable 'no_stack_protector' for > ppc32: > > #define __no_stack_protector __attribute__((__optimize__("-fno-stack-protector"))) > Hello, any suggestion here? ;-) BTW, we have found another -O0 + "omit-frame-pointer" regression with gcc 13.1.0 on all architectures ("omit-frame-pointer" will be completely ignored when -O0 passed whatever other internal optimize attribute like 'Os' we used together in commit '4dc4401991fc' for gcc < 11.1.0), Yuan is doing more tests to confirm it, will open another discussion for it. > Benefit from the __no_stack_protetor macro, we have no need to input > __optimize__("-fno-stack-protector") for every new architecture, it may be the > time to only use __optimize__("-fno-stack-protector"), am I missing something? > > > out that your willingness to work around some of the oddities met on > > this one have resulted in a lot of drift away from the "keep it simple" > > principle and significantly delayed the possibilities to integrate the > > rest of your work. It would be much saner to only focus on ppc64/ppc64le > > and figure later how to make ppc32 work (or decide not to support it if > > it's not worth the effort in the end). > > Another test shows, the run target of ppc64le with the big endian gcc 13.1.0 > toolchain has test startup failure (although we have verified run-user before, > run-user ok! and run with local powerpc64le toolchain ok too!), I'm debugging > this now, hope it not cost too much. Just solved this, when -mabi=elfv2 supported by the toolchain (gcc 13.1.0 has this option), kernel will compile with this ABI, to align with kernel, our user space application should use -mabi=elfv2 too if toolchain support it, otherwise, test will simply fails at startup, this solves it: $(call cc-option,-mabi=elfv2) > > Another good news is, Yuan has found a working defconfig for ppc32 which has > poweroff support and he is helping me narrowing down the exact options, this > will eventually make us happy ;-) > We eventually find the missing poweroff option for ppc32, will update the patches with them. we also found such options for all of the nolibc supported architectures, will add them in their tinyconfig support patches. Thanks, Zhangjin > Thanks & Best regards, > Zhangjin > > > > > Regards, > > willy
On 2023-08-03 00:03:58+0800, Zhangjin Wu wrote: > Hi, Willy, Hi Thomas > > I'm so happy to share with you, we have solved all of the left found > issues, include the ones about ppc and the missing poweroff options for > the tinyconfig series, will renew both series ;-) Can we stick to one series at a time? > > Further compared the preprocessed files, found the root cause is the new > > compiler using 'no_stack_protector' instead of > > '__optimize__("-fno-stack-protector")'. And the attribute 'no_stack_protector' > > breaks our "omit-frame-pointer" like the failure with '-O0' we fixed before. > > > > I checked some of the other architectures, they didn't have the same issue, but > > test shows the 'no_stack_protector' attribute does have such compability issue > > here. > > > > I learned the commit message of tools/include/nolibc/compiler.h, seems > > __optimize__("-fno-stack-protector") is enough for all of the nolibc supported > > architectures? is it ok for us to simply give up 'no_stack_protector' > > eventully? otherwise, we should manually disable 'no_stack_protector' for > > ppc32: > > > > #define __no_stack_protector __attribute__((__optimize__("-fno-stack-protector"))) > > > > Hello, any suggestion here? ;-) Patience :-) no_stack_protector is the offically documented mechanism to disable stack protector for a function. As it works for all other architectures this seems like a compiler bug. If we want to work around it I would prefer to have both attributes. > [..] Thomas
On Wed, Aug 02, 2023 at 11:36:30PM +0200, Thomas Weißschuh wrote: > On 2023-08-03 00:03:58+0800, Zhangjin Wu wrote: > > Hi, Willy, Hi Thomas > > > > I'm so happy to share with you, we have solved all of the left found > > issues, include the ones about ppc and the missing poweroff options for > > the tinyconfig series, will renew both series ;-) > > Can we stick to one series at a time? Yes and please this time, let's stick exclusively to what is sufficiently tested for 6.6, otherwise it will have to be delayed. > > > Further compared the preprocessed files, found the root cause is the new > > > compiler using 'no_stack_protector' instead of > > > '__optimize__("-fno-stack-protector")'. And the attribute 'no_stack_protector' > > > breaks our "omit-frame-pointer" like the failure with '-O0' we fixed before. > > > > > > I checked some of the other architectures, they didn't have the same issue, but > > > test shows the 'no_stack_protector' attribute does have such compability issue > > > here. > > > > > > I learned the commit message of tools/include/nolibc/compiler.h, seems > > > __optimize__("-fno-stack-protector") is enough for all of the nolibc supported > > > architectures? is it ok for us to simply give up 'no_stack_protector' > > > eventully? otherwise, we should manually disable 'no_stack_protector' for > > > ppc32: > > > > > > #define __no_stack_protector __attribute__((__optimize__("-fno-stack-protector"))) > > > > > > > Hello, any suggestion here? ;-) > > Patience :-) > > no_stack_protector is the offically documented mechanism to disable > stack protector for a function. As it works for all other architectures > this seems like a compiler bug. Or a limitation. To be honest we're playing with compiler limits by adjusting their optimizations per function. But as long as we don't break what currently works, we can accept to have some limits in a first version (e.g. if ppc32 doesn't support -O0 for now it's not dramatic). Also, some other archs use optimize("Os", "omit-frame-pointer")), maybe that's needed there as well. > If we want to work around it I would prefer to have both attributes. Also if you remember we also used to have a work-around for the function's entry code consisting in renaming _start and having a _start pointer in the asm code itself. That can remain an option to experiment with later. But let's not change everything again at the last minute, all these series have been sufficiently difficult to follow :-( thanks, Willy
On Thu, Aug 03, 2023 at 10:58:55AM +0800, Zhangjin Wu wrote: > Yes, ppc series at first, will renew it today. let's delay the whole tinyconfig > series (include part1) in v6.7, we have no enough time to test them carefully > for v6.6. Thanks. > > > > > Further compared the preprocessed files, found the root cause is the new > > > > > compiler using 'no_stack_protector' instead of > > > > > '__optimize__("-fno-stack-protector")'. And the attribute 'no_stack_protector' > > > > > breaks our "omit-frame-pointer" like the failure with '-O0' we fixed before. > > > > > > > > > > I checked some of the other architectures, they didn't have the same issue, but > > > > > test shows the 'no_stack_protector' attribute does have such compability issue > > > > > here. > > > > > > > > > > I learned the commit message of tools/include/nolibc/compiler.h, seems > > > > > __optimize__("-fno-stack-protector") is enough for all of the nolibc supported > > > > > architectures? is it ok for us to simply give up 'no_stack_protector' > > > > > eventully? otherwise, we should manually disable 'no_stack_protector' for > > > > > ppc32: > > > > > > > > > > #define __no_stack_protector __attribute__((__optimize__("-fno-stack-protector"))) > > > > > > > > > > > > > Hello, any suggestion here? ;-) > > > > > > Patience :-) > > > > > > no_stack_protector is the offically documented mechanism to disable > > > stack protector for a function. As it works for all other architectures > > > this seems like a compiler bug. > > > > Or a limitation. To be honest we're playing with compiler limits by > > adjusting their optimizations per function. But as long as we don't > > break what currently works, we can accept to have some limits in a first > > version (e.g. if ppc32 doesn't support -O0 for now it's not dramatic). > > Also, some other archs use optimize("Os", "omit-frame-pointer")), maybe > > that's needed there as well. > > > > Since it is really related, let's summarize yesterdays's further test here for > a reference: > > Yesterday's test result on randomly chosen x86_64 and riscv64 shows, > from at least gcc 12.3.0 (may differs from archs), even with > optimize("Os", "omit-frame-pointer")), whatever with or without > '-fno-stack-protector', -O0 forbids the per function's > "omit-frame-pointer" as the doc [1] describes (as we discussed before), > that means some imtermediate gcc versions deviate from their docs and > now, the latest gcc version come back to follow its doc [1] and become > even more strict and then breaks our optimize("Os", > "omit-frame-pointer") workaround eventually: > > Most optimizations are completely disabled at -O0 or if an -O level > is not set on the command line, even if individual optimization > flags are specified. Note that the quoted paragraph above is mostly independent. The point here is that optimize("-Os") seems to be ignored then -O0 is passed on the command line. But I'm not that much surprised, because as we said, changing optimizations on the fly is tricky given that some have effects beyond just a function. > So, it is ok for us to simply ignore -O0 currently, let's work on them > in v6.7. Yeah I'm fine with this. In the worst case those using -O0 can also avoid using stack-protector. > > > If we want to work around it I would prefer to have both attributes. > > > > Also if you remember we also used to have a work-around for the > > function's entry code consisting in renaming _start and having a _start > > pointer in the asm code itself. That can remain an option to experiment > > with later. > > Yes, the 'asm' style of _start may be a choice to prevent gcc touching > our startup code. That was the case. We had an earlier version where _start was a label inside the asm statement, resulting in some unused prologue and epilogue for the function around that code. It was a bit ugly and I think it had some shortcomings but we may go back to that later if it brings some value. Willy
Hi, Willy > On Thu, Aug 03, 2023 at 10:58:55AM +0800, Zhangjin Wu wrote: > > Yes, ppc series at first, will renew it today. let's delay the whole tinyconfig > > series (include part1) in v6.7, we have no enough time to test them carefully > > for v6.6. > > Thanks. > To even further simplify the ppc series merge progress, since Yuan have helped me sending the standalone serial console enable patch for pmac32_defconfig [1], and it has gotten a Reviewed-by line from the ppc maintainer, perhaps we can safely expect it in v6.6, so, I plan to delay the nolibc-test-config related stuff and minimize the whole ppc series to only these necessary patches: $ git log --reverse --oneline 813cab75752d9f2bbd71179b0c43c1052515cf48^..HEAD 813cab75752d tools/nolibc: add support for powerpc 122e2610c649 tools/nolibc: add support for powerpc64 f31fe18cf2e2 selftests/nolibc: add XARCH and ARCH mapping support b25c71125154 selftests/nolibc: add test support for ppc 27bc0026f1e7 selftests/nolibc: add test support for ppc64le d70649478ef8 (HEAD -> v6.6-nolibc-202308031233-pure-ppc-v5) selftests/nolibc: add test support for ppc64 After this ppc series, if you are still happy with parts of the left ones, I will renew them. [1]: https://lore.kernel.org/lkml/bb7b5f9958b3e3a20f6573ff7ce7c5dc566e7e32.1690982937.git.tanyuan@tinylab.org/ > > [...] > > So, it is ok for us to simply ignore -O0 currently, let's work on them > > in v6.7. > > Yeah I'm fine with this. In the worst case those using -O0 can also avoid > using stack-protector. > Yeah, let's ignore -O0 here. but must clarify that, even with the default "-Os" from command line, when using gcc 13.1.0, it has '__no_stack_protector' attribute but this attribute breaks 'omit-frame-pointer' and result in segfaults. To avoid touching the common code, I plan to let ppc32 uses its own __no_stack_protector with '__optimize__("-fno-stack-protector")', I hope it is fair enough now ;-) Here is what I have added for arch-powerpc.h in the first patch of the series: /* FIXME: For ppc32, with newer gcc compilers (e.g. gcc 13.1.0), * "omit-frame-pointer" fails with __attribute__((no_stack_protector)) but * works with __attribute__((__optimize__("-fno-stack-protector"))) */ #ifdef __no_stack_protector #undef __no_stack_protector #define __no_stack_protector __attribute__((__optimize__("-fno-stack-protector"))) #endif If you are happy with this, v5 with come with it. Thanks! Best regards, Zhangjin > > Willy
diff --git a/tools/testing/selftests/nolibc/Makefile b/tools/testing/selftests/nolibc/Makefile index 3c9e3963fbad..29e02b49903a 100644 --- a/tools/testing/selftests/nolibc/Makefile +++ b/tools/testing/selftests/nolibc/Makefile @@ -33,9 +33,11 @@ endif # architectures where both are equal. # configure default variants for target kernel supported architectures +XARCH_powerpc = ppc XARCH = $(or $(XARCH_$(ARCH)),$(ARCH)) # map from user input variants to their kernel supported architectures +ARCH_ppc = powerpc ARCH := $(or $(ARCH_$(XARCH)),$(XARCH)) # kernel image names by architecture @@ -45,6 +47,7 @@ IMAGE_x86 = arch/x86/boot/bzImage IMAGE_arm64 = arch/arm64/boot/Image IMAGE_arm = arch/arm/boot/zImage IMAGE_mips = vmlinuz +IMAGE_ppc = vmlinux IMAGE_riscv = arch/riscv/boot/Image IMAGE_s390 = arch/s390/boot/bzImage IMAGE_loongarch = arch/loongarch/boot/vmlinuz.efi @@ -58,6 +61,7 @@ DEFCONFIG_x86 = defconfig DEFCONFIG_arm64 = defconfig DEFCONFIG_arm = multi_v7_defconfig DEFCONFIG_mips = malta_defconfig +DEFCONFIG_ppc = pmac32_defconfig DEFCONFIG_riscv = defconfig DEFCONFIG_s390 = defconfig DEFCONFIG_loongarch = defconfig @@ -77,6 +81,7 @@ QEMU_ARCH_x86 = x86_64 QEMU_ARCH_arm64 = aarch64 QEMU_ARCH_arm = arm QEMU_ARCH_mips = mipsel # works with malta_defconfig +QEMU_ARCH_ppc = ppc QEMU_ARCH_riscv = riscv64 QEMU_ARCH_s390 = s390x QEMU_ARCH_loongarch = loongarch64 @@ -89,6 +94,7 @@ QEMU_ARGS_x86 = -M pc -append "console=ttyS0,9600 i8042.noaux panic=-1 $( QEMU_ARGS_arm64 = -M virt -cpu cortex-a53 -append "panic=-1 $(TEST:%=NOLIBC_TEST=%)" QEMU_ARGS_arm = -M virt -append "panic=-1 $(TEST:%=NOLIBC_TEST=%)" QEMU_ARGS_mips = -M malta -append "panic=-1 $(TEST:%=NOLIBC_TEST=%)" +QEMU_ARGS_ppc = -M g3beige -append "console=ttyS0 panic=-1 $(TEST:%=NOLIBC_TEST=%)" QEMU_ARGS_riscv = -M virt -append "console=ttyS0 panic=-1 $(TEST:%=NOLIBC_TEST=%)" QEMU_ARGS_s390 = -M s390-ccw-virtio -m 1G -append "console=ttyS0 panic=-1 $(TEST:%=NOLIBC_TEST=%)" QEMU_ARGS_loongarch = -M virt -append "console=ttyS0,115200 panic=-1 $(TEST:%=NOLIBC_TEST=%)" diff --git a/tools/testing/selftests/nolibc/configs/nolibc-test-ppc.config b/tools/testing/selftests/nolibc/configs/nolibc-test-ppc.config new file mode 100644 index 000000000000..b1975f8253f7 --- /dev/null +++ b/tools/testing/selftests/nolibc/configs/nolibc-test-ppc.config @@ -0,0 +1,3 @@ +CONFIG_SERIAL_PMACZILOG=y +CONFIG_SERIAL_PMACZILOG_TTYS=y +CONFIG_SERIAL_PMACZILOG_CONSOLE=y