| Message ID | 20231219-sam-sparc32-sunset-v3-v1-0-64bb44b598c5@ravnborg.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | sparc32: sunset sun4m and sun4d | expand |
On Tue, Dec 19, 2023, at 22:03, Sam Ravnborg via B4 Relay wrote: > 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 One note about the CAS -- as far as I can tell, the absence of the futex() syscall on sparc32 kernels means that no glibc from the past decade can work correctly as it now requires futex for its internal locking, though it does work on sparc64 kernels in compat32 mode as well as the LEON3 kernel that adds futex support. There have been a number of other bugs in sun4m/sun4d support that ended up making the system unusable during the same timeframe, I remember sysvipc being broken in native 32-bit mode (but again not in compat mode) and I think Al Viro has a list of things that he fixed over the years. 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. Arnd
From: Arnd Bergmann > Sent: 20 December 2023 08:37 > > On Tue, Dec 19, 2023, at 22:03, Sam Ravnborg via B4 Relay wrote: > > 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 > > One note about the CAS -- as far as I can tell, the absence > of the futex() syscall on sparc32 kernels means that no glibc > from the past decade can work correctly as it now requires futex > for its internal locking, though it does work on sparc64 kernels > in compat32 mode as well as the LEON3 kernel that adds futex > support. Does the glibc mutex 'fast path' also require a CAS instruction? Presumably having CAS also removes the 'really horrid (tm)' code required to make all the bitmap operations atomic? Seems a shame to lose old sparc32 support when (I think) the sun3 in my cupboard would still work - if only it had a working psu. (The 110/220V switch wasn't connected and the FET wasn't rated for 450V. UK mains can be 240+10% if you are near a substation.) David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
On Wed, Dec 20, 2023, at 09:34, David Laight wrote: > From: Arnd Bergmann >> Sent: 20 December 2023 08:37 >> >> On Tue, Dec 19, 2023, at 22:03, Sam Ravnborg via B4 Relay wrote: >> > 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 >> >> One note about the CAS -- as far as I can tell, the absence >> of the futex() syscall on sparc32 kernels means that no glibc >> from the past decade can work correctly as it now requires futex >> for its internal locking, though it does work on sparc64 kernels >> in compat32 mode as well as the LEON3 kernel that adds futex >> support. > > Does the glibc mutex 'fast path' also require a CAS instruction? I think that depends on whether glibc is built for a CPU with CAS or not. If it's built for 32-bit sparcv9 or leon, it should use CAS and crash on sparcv8 without CAS. If it's built for pure sparcv8, it should try to use an emulation that is incompatible with the kernel futex syscall. > Presumably having CAS also removes the 'really horrid (tm)' code > required to make all the bitmap operations atomic? Yes, but I'm not sure this is implemented in the leon3 tree. With CAS enabled, at least asm/atomic.h, asm/bitops.h, asm/cmpxchg.h and asm/spinlock.h can be implemented as efficiently as they are in the 64-bit version. > Seems a shame to lose old sparc32 support when (I think) the sun3 > in my cupboard would still work - if only it had a working psu. > (The 110/220V switch wasn't connected and the FET wasn't rated > for 450V. UK mains can be 240+10% if you are near a substation.) sun3 support has never worked upstream. There is an old series from 20 years ago that made it work but nobody ever tried to get it merged. Arnd
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? Adrian
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
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. 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. 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. ATB, Mark. [1] https://gitlab.com/qemu-project/qemu/-/blob/master/MAINTAINERS?ref_type=heads#L1696
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
Hi Andreas. Congratulation being the new sparc co-maintainer! On Tue, Dec 19, 2023 at 11:03:05PM +0100, Sam Ravnborg via B4 Relay wrote: > This is the second attempt to sunset sun4m and sun4d. > See [1] for the inital attempt. I have now verified that the kernel can boot with qemu. There was a bug in the uart driver that is fixed and upstream, and then using the instructions you provided I could use buildroot with an external kernel tree to get a booting kernel. Assuming you agree with the patchset how do you want me to move forward? I can rebase on top of the latest -rc and collect acks if that helps. Arnd promised to pick up the patches until you got a git tree up, but I do not expect Arnd to pick up anything unless you have acked or reviewed said patch(es). If I rebase the patch-set I will likely include a few bug-fix patches that was prepared in the meantime. I can also send them as a separate series, no worries. Sam
Hi Sam, On Sun, 2024-02-04 at 20:21 +0100, Sam Ravnborg wrote: > Assuming you agree with the patchset how do you want me to move forward? > I can rebase on top of the latest -rc and collect acks if that helps. > > Arnd promised to pick up the patches until you got a git tree up, > but I do not expect Arnd to pick up anything unless you have acked or > reviewed said patch(es). > > If I rebase the patch-set I will likely include a few bug-fix patches that > was prepared in the meantime. > I can also send them as a separate series, no worries. I met with Andreas this weekend and he got GPG signatures from at least me and Geert which he needs for his kernel.org account. Please give him a few more days, maybe be even 2-3 weeks to get everything up and comfortable with the whole process. The more patches Andreas can review and merge himself, the better. And since your patches have been laying around for some time already, I don't think that waiting a little longer will be a problem. Thanks, Adrian
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,