Message ID | 20231219-sam-sparc32-sunset-v3-v1-0-64bb44b598c5@ravnborg.org |
---|---|
Headers | show |
Series | sparc32: sunset sun4m and sun4d | expand |
On Tue, 19 Dec 2023 at 23:03, Sam Ravnborg via B4 Relay <devnull+sam.ravnborg.org@kernel.org> wrote: > > This is the second attempt to sunset sun4m and sun4d. > See [1] for the inital attempt. > > The sun4m and sun4d parts of the kernel have seen no real interest > for several years now. Last time a few people surfaced, but it was > either due to a personal project or for nostalgic reasons. > It is time to let go and drop the parts of sparc32 that in reality > are not in use. > > LEON from Frontgrade Gaisler is the only real user of sparc32, > and this patchset reduces sparc32 to what is required by LEON. > > The defconfig is first adapted to the one used by Gaisler. > Then the patches removes sun4m and sun4d specific > implementations such as small drivers, SMP support, IRQ suppor etc. > > Removing sun4m and sun4d support allowed removal of the run time > patching of the code as well as a lot of assembler code. > The result is a much cleaner assembler code that is easier to > understand and thus maintain and extend. > > So far the code builds but it has seen no run-time testing. > > If anyone can tell me how to boot a linux kernel with the leon_genric > machine with QEMU that would be super as this would be a minimal > testing that others can reproduce as well. > I assume QEMU needs a few patches to make it work, but maybe I > just failed to use the right bootloader. > > TODO before this can be applied: > - Ack from davem - as he is the principal sparc maintainer > - Tested-by: preferably on a target or QEMU (see above) > I expect bugs as there are some involved changes! > > Ideas for the future > - Apply the most relevant downstream Gaisler patches > - The ones introducing CAS should have preference as we then > can drop the cmpxchg emulation > - Adjust defconfig to include all Gaisler drivers to make sure they > see build time coverage > - Move the leon bits from leon files to the general files > - Add leon smp support to smp_32.c > - Add leon irq support to irq_32.c > - Integrate leom_mm support with srmmu and drop some of the > function operations that are no longer needed > - The current sparc32 code assume the bootloader uses the prom > provided by sun. Maybe migrate over to a more modern device tree > way of working. > - Drop some of the homegrown memory allocators and use memblocks > > [1]: https://lore.kernel.org/all/20201218184347.2180772-1-sam@ravnborg.org/ > > Sam > > --- > Sam Ravnborg (27): > sparc32: Update defconfig to LEON SMP > sparc32: Drop sun4m/sun4d support from head_32.S > sparc32: Drop floppy support > sparc32: Drop sun4m specific led driver > sparc32: Drop sun specific power management drivers > sparc32: Drop auxio support > sparc32: Drop run-time patching of ipi trap > sparc32: Drop patching of interrupt vector > sparc32: Drop sun4m/sun4d specific irq handling > sparc32: Drop sun4d/sun4m smp support > sparc32: Drop pcic support > sparc32: Drop mbus support > sparc32: Drop unused function __get_{phys,iospace} > sparc32: Drop unused mmu models > sparc32: Drop check for sparc_model > sparc32: Drop use of sparc_config > sparc32: Drop run-time patching of ASI instructions > sparc32: Drop support for 7 register windows > sparc32: Drop additional sun4d bits > sparc32: Drop unused prom ranges support > sparc32: Drop unused iommu support > sparc32: Drop sun4m irq support > sparc32: Drop unused trampoline code > sparc32: Drop config SPARC_LEON > sparc32: Drop sbus support > sbus: char: Drop now unused uctrl driver > fbdev/p9100: Drop now unused driver p9100 > > arch/sparc/Kconfig | 54 +-- > arch/sparc/configs/sparc32_defconfig | 170 +++---- > arch/sparc/include/asm/asmmacro.h | 22 - > arch/sparc/include/asm/auxio_32.h | 73 +-- > arch/sparc/include/asm/cpu_type.h | 18 - > arch/sparc/include/asm/elf_32.h | 2 - > arch/sparc/include/asm/fb.h | 8 +- > arch/sparc/include/asm/floppy.h | 2 - > arch/sparc/include/asm/floppy_32.h | 393 ---------------- > arch/sparc/include/asm/io-unit.h | 59 --- > arch/sparc/include/asm/io_32.h | 83 ---- > arch/sparc/include/asm/iommu.h | 2 - > arch/sparc/include/asm/iommu_32.h | 122 ----- > arch/sparc/include/asm/irq_32.h | 2 - > arch/sparc/include/asm/mbus.h | 97 ---- > arch/sparc/include/asm/mxcc.h | 138 ------ > arch/sparc/include/asm/obio.h | 226 --------- > arch/sparc/include/asm/oplib_32.h | 11 - > arch/sparc/include/asm/pcic.h | 130 ------ > arch/sparc/include/asm/pgtable_32.h | 24 - > arch/sparc/include/asm/pgtsrmmu.h | 33 +- > arch/sparc/include/asm/ross.h | 192 -------- > arch/sparc/include/asm/sbi.h | 116 ----- > arch/sparc/include/asm/sections.h | 3 - > arch/sparc/include/asm/swift.h | 107 ----- > arch/sparc/include/asm/switch_to_32.h | 1 - > arch/sparc/include/asm/timer_32.h | 1 + > arch/sparc/include/asm/tsunami.h | 65 --- > arch/sparc/include/asm/turbosparc.h | 126 ----- > arch/sparc/include/asm/viking.h | 255 ----------- > arch/sparc/include/asm/winmacro.h | 11 +- > arch/sparc/kernel/Makefile | 8 +- > arch/sparc/kernel/apc.c | 196 -------- > arch/sparc/kernel/auxio_32.c | 139 ------ > arch/sparc/kernel/cpu.c | 1 - > arch/sparc/kernel/devices.c | 10 +- > arch/sparc/kernel/entry.S | 413 +---------------- > arch/sparc/kernel/etrap_32.S | 50 +- > arch/sparc/kernel/head_32.S | 255 +---------- > arch/sparc/kernel/ioport.c | 55 +-- > arch/sparc/kernel/irq.h | 85 +--- > arch/sparc/kernel/irq_32.c | 133 +----- > arch/sparc/kernel/kernel.h | 53 +-- > arch/sparc/kernel/led.c | 146 ------ > arch/sparc/kernel/leon_kernel.c | 53 +-- > arch/sparc/kernel/leon_pmc.c | 16 +- > arch/sparc/kernel/leon_smp.c | 3 - > arch/sparc/kernel/of_device_32.c | 18 +- > arch/sparc/kernel/pcic.c | 840 ---------------------------------- > arch/sparc/kernel/pmc.c | 100 ---- > arch/sparc/kernel/process_32.c | 10 - > arch/sparc/kernel/rtrap_32.S | 73 ++- > arch/sparc/kernel/setup_32.c | 115 ----- > arch/sparc/kernel/smp_32.c | 102 +---- > arch/sparc/kernel/sun4d_irq.c | 519 --------------------- > arch/sparc/kernel/sun4d_smp.c | 415 ----------------- > arch/sparc/kernel/sun4m_irq.c | 478 ------------------- > arch/sparc/kernel/sun4m_smp.c | 275 ----------- > arch/sparc/kernel/time_32.c | 68 +-- > arch/sparc/kernel/trampoline_32.S | 127 +---- > arch/sparc/kernel/ttable_32.S | 9 +- > arch/sparc/kernel/vmlinux.lds.S | 5 - > arch/sparc/kernel/wof.S | 61 +-- > arch/sparc/kernel/wuf.S | 41 +- > arch/sparc/mm/Makefile | 4 +- > arch/sparc/mm/hypersparc.S | 414 ----------------- > arch/sparc/mm/io-unit.c | 286 ------------ > arch/sparc/mm/iommu.c | 455 ------------------ > arch/sparc/mm/mm_32.h | 4 - > arch/sparc/mm/srmmu.c | 836 +-------------------------------- > arch/sparc/mm/srmmu_access.S | 83 ---- > arch/sparc/mm/swift.S | 256 ----------- > arch/sparc/mm/tsunami.S | 132 ------ > arch/sparc/mm/viking.S | 284 ------------ > arch/sparc/prom/Makefile | 1 - > arch/sparc/prom/init_32.c | 2 - > arch/sparc/prom/misc_32.c | 2 - > arch/sparc/prom/ranges.c | 114 ----- > drivers/sbus/char/Kconfig | 8 - > drivers/sbus/char/Makefile | 1 - > drivers/sbus/char/uctrl.c | 435 ------------------ > drivers/usb/host/Kconfig | 2 +- > drivers/usb/host/ehci-hcd.c | 4 +- > drivers/usb/host/uhci-hcd.c | 2 +- > drivers/video/fbdev/Kconfig | 10 +- > drivers/video/fbdev/Makefile | 1 - > drivers/video/fbdev/p9100.c | 372 --------------- > sound/sparc/Kconfig | 1 + > 88 files changed, 318 insertions(+), 10809 deletions(-) > --- > base-commit: bee0e7762ad2c6025b9f5245c040fcc36ef2bde8 > change-id: 20231219-sam-sparc32-sunset-v3-4751ea89da2d > > Best regards, > -- > Sam Ravnborg <sam@ravnborg.org> > > Hi everyone, These changes will now effectively make the sparc32 port into a port that is only really supported by a rather specific sparc32 implementation delivered by Gaisler. I will therefore suggest to remove any remaining references to sparc32 and replaced them with leon, to symbolize the end of common sparc32 support. Best regards, Kjetil Oftedal
Hi Mark, On Wed, Dec 20, 2023 at 11:30:27AM +0000, Mark Cave-Ayland wrote: > On 20/12/2023 10:47, Arnd Bergmann wrote: > > > On Wed, Dec 20, 2023, at 09:54, John Paul Adrian Glaubitz wrote: > > > On Wed, 2023-12-20 at 08:36 +0000, Arnd Bergmann wrote: > > > > All of these were found through inspection rather than testing, > > > > so there is a good chance that other fatal kernel bugs prevent > > > > testing in qemu, at least until the fixes from Andreas' tree > > > > are included. > > > > > > Andreas has fixes for these issues? > > > > Not sure, all I know is that > > > > - Andreas has some fixes for Leon in his tree > > - Sam is unable to boot mainline in qemu > > - There is an unknown set of bugs in sparc32 since it has not > > been tested for many years without Andreas' patches > > > > it appears that the qemu developers are still testing the sun4m > > model against old Linux and Solaris installations [1], but > > failure to run the leon3 model could still be any combination > > of kernel, qemu or configuration problems. > > > > Arnd > > > > [1] https://wiki.qemu.org/Documentation/Platforms/SPARC#Compatibility > > Hi all: I'm one of the QEMU sun4m and sun4u maintainers so thought it would > be worth a few comments here. I can imagine that the proposal to drop sun4m from the kernel is then not the best news this December - sorry about that. > > My SPARC work on QEMU is unsponsored, so of course it is reliant upon me > finding time between work and family to fix various bugs. This means that I > simply don't have the time to constantly build and test the latest kernels: > what generally happens is that someone pings me a regression bug report when > something breaks and provides a test kernel/rootfs for me to look at. In the > past both Rob Landley and Guenter Roeck have often flagged regressions and > kindly provided these for me. > > Other than that I just assume that everything is still working against the > upstream kernel. It is a fantastic tool that we can build and boot a kernel using qemu and your work is appreciated - thanks! > > The leon3_generic machine is maintained by different people so I'd suggest > contacting them: see [1] for their contact details. I see there is an > avocado boot test for the leon3_generic machine included within the QEMU > source tree, but it uses a downloadable image of HelenOS rather than Linux. Thanks for the pointer, I will try to reach out to them when I have something a bit more solid than "it does not work". I tried to hack around a little in qemu and I have an idea where things goes wrong. The leon_generic assumes another address layout than what is used by the kernel, so the very first jump to a kernel address fails. Sam
Hi Sam, On Wed, 2023-12-20 at 16:22 +0100, Sam Ravnborg wrote: > > The leon3_generic machine is maintained by different people so I'd suggest > > contacting them: see [1] for their contact details. I see there is an > > avocado boot test for the leon3_generic machine included within the QEMU > > source tree, but it uses a downloadable image of HelenOS rather than Linux. > > Thanks for the pointer, I will try to reach out to them when I have > something a bit more solid than "it does not work". > > I tried to hack around a little in qemu and I have an idea where things > goes wrong. The leon_generic assumes another address layout than what is > used by the kernel, so the very first jump to a kernel address fails. I would argue that before we start introducing larger changes to arch/sparc, we should settle the maintainership question first. Once we have an active maintainer again, we can have a more extended discussion about what to keep and how to name things. Adrian
On 2023-12-20 18:25, John Paul Adrian Glaubitz wrote: > Hi Sam, > > On Wed, 2023-12-20 at 16:22 +0100, Sam Ravnborg wrote: >>> The leon3_generic machine is maintained by different people so I'd suggest >>> contacting them: see [1] for their contact details. I see there is an >>> avocado boot test for the leon3_generic machine included within the QEMU >>> source tree, but it uses a downloadable image of HelenOS rather than Linux. >> >> Thanks for the pointer, I will try to reach out to them when I have >> something a bit more solid than "it does not work". >> >> I tried to hack around a little in qemu and I have an idea where things >> goes wrong. The leon_generic assumes another address layout than what is >> used by the kernel, so the very first jump to a kernel address fails. The MKLINUXIMG second stage bootloader sets up MMU tables and the SPARC OPENPROM interface for LEON systems, so you need to run the vmlinux image through that. You can find it (and our other Linux related releases) via https://gaisler.com/index.php/downloads/linux. The manual is at https://www.gaisler.com/doc/mklinuximg.pdf and the latest release at https://gaisler.com/anonftp/linux/linux-2.6/kernel/mklinuximg-2.0.15.tar.bz2 With a sparc-linux-gcc in the PATH (or using CROSS_COMPILE to point out a toolchain stem) you can do: mklinuximg vmlinux image.ram and then run the resulting image.ram in e.g. QEMU 8.2.0 with qemu-system-sparc -nographic -M leon3_generic -m 256 -kernel image.ram This at least boots the kernel and let me log in when quickly testing a few images with root filesystems in initramfs, admittedly with our kernel patches in place. > I would argue that before we start introducing larger changes to arch/sparc, > we should settle the maintainership question first. Once we have an active > maintainer again, we can have a more extended discussion about what to keep > and how to name things. I agree. Cheers, Andreas