[U-Boot] SPARC support

Hi All!
For several years, my organization has built and maintained boards SPARCH-architecture processors (specifically Gaisler's implementation of the LEON3), and we have depended on u-boot as our primary bootloader. But when attempting to update u-boot this morning, we were disappointed to find that the SPARC support was completely removed last March with commits:
936478e797a87bcd4e002bf70430b6f58584b155
54f302f1197a490c2c4e3564c698ecd090d5013b
What was the reasoning for completely removing support for SPARC? What will it take to get it back in?
Thanks!
-Travis Waters

On Mon, Feb 12, 2018 at 07:28:14PM +0000, Travis Waters wrote:
Hi All!
For several years, my organization has built and maintained boards SPARCH-architecture processors (specifically Gaisler's implementation of the LEON3), and we have depended on u-boot as our primary bootloader. But when attempting to update u-boot this morning, we were disappointed to find that the SPARC support was completely removed last March with commits:
936478e797a87bcd4e002bf70430b6f58584b155
54f302f1197a490c2c4e3564c698ecd090d5013b
What was the reasoning for completely removing support for SPARC? What will it take to get it back in?
It was removed due to a lack of active maintainers. Last year when I removed it, I know a few people reached out to other groups in private to see if anyone wanted to maintain it, and no one stood up. I would be happy to have SPARC re-introduced, so long as: - It builds with a modern toolchain such as https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/6.4.0/ or https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/7.3.0/ - It does not add anything to scripts/config_whitelist.txt - Someone is going to be active in maintaining the port and doing the driver conversions to DM as they need to be done. - A real nice bonus would be hooking up QEMU and Travis-CI and test.py so that a basic level of functionality can be confirmed and tested every time.
Thanks!

Thanks for the update, Tom. I think those are all fair assertions. Was Gaisler ever approached as a maintainer, or have they just been unable to keep up? We will approach Gaisler again and find out what's going on with their side. We certainly have a vested interest in it so I may be able to talk the powers-that-be into maintaining if Gaisler won't commit.
-Travis
-----Original Message----- From: Tom Rini [mailto:trini@konsulko.com] Sent: Monday, February 12, 2018 1:16 PM To: Travis Waters Travis.Waters@sdl.usu.edu Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] SPARC support
On Mon, Feb 12, 2018 at 07:28:14PM +0000, Travis Waters wrote:
Hi All!
For several years, my organization has built and maintained boards SPARCH-architecture processors (specifically Gaisler's implementation of the LEON3), and we have depended on u-boot as our primary bootloader. But when attempting to update u-boot this morning, we were disappointed to find that the SPARC support was completely removed last March with commits:
936478e797a87bcd4e002bf70430b6f58584b155
54f302f1197a490c2c4e3564c698ecd090d5013b
What was the reasoning for completely removing support for SPARC? What will it take to get it back in?
It was removed due to a lack of active maintainers. Last year when I removed it, I know a few people reached out to other groups in private to see if anyone wanted to maintain it, and no one stood up. I would be happy to have SPARC re-introduced, so long as: - It builds with a modern toolchain such as https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/6.4.0/ or https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/7.3.0/ - It does not add anything to scripts/config_whitelist.txt - Someone is going to be active in maintaining the port and doing the driver conversions to DM as they need to be done. - A real nice bonus would be hooking up QEMU and Travis-CI and test.py so that a basic level of functionality can be confirmed and tested every time.
Thanks!
-- Tom

On Mon, Feb 12, 2018 at 08:40:44PM +0000, Travis Waters wrote:
Thanks for the update, Tom. I think those are all fair assertions. Was Gaisler ever approached as a maintainer, or have they just been unable to keep up? We will approach Gaisler again and find out what's going on with their side. We certainly have a vested interest in it so I may be able to talk the powers-that-be into maintaining if Gaisler won't commit.
I believe that in the end I simply never got a reply from the previous maintainers, one of whom was at Gaisler and one at Spaceteq. Thanks!
participants (2)
-
Tom Rini
-
Travis Waters