From: Sandra Loosemore <sloosemore@baylibre.com>
To: gcc@gcc.gnu.org, binutils@sourceware.org,
gdb-patches@sourceware.org, libc-alpha@sourceware.org,
Chung-Lin Tang <cltang@baylibre.com>,
andrew@reenigne.org, Yao Qi <qiyaoltc@gmail.com>
Cc: Dinh Nguyen <dinguyen@kernel.org>,
qemu-devel@nongnu.org, newlib@sourceware.org
Subject: Deprecation/removal of nios2 target support
Date: Wed, 17 Apr 2024 21:27:23 -0600 [thread overview]
Message-ID: <55a1bc52-b435-463e-8be1-4b23e44393a0@baylibre.com> (raw)
Tomorrow I plan to push patches to mark the nios2 target as obsolete in
GCC 14.
Background: Intel has EOL'ed the Nios II processor IP and is now
directing their FPGA customers to a RISC-V platform instead.
https://www.intel.com/content/www/us/en/content-details/781327/intel-is-discontinuing-ip-ordering-codes-listed-in-pdn2312-for-nios-ii-ip.html
The Nios II hardware on loan from Intel that we were using for testing
at Mentor Graphics/Siemens was returned around the first of the year.
For some time we had been using QEMU to test the nios2-elf target, but
we never had a QEMU test harness set up that would boot the Linux
kernel, and user-mode QEMU on this target is too buggy/unmaintained to
use for primary testing. So the current situation is that none of the
listed maintainers for any of the GNU toolchain components have access
to a fully working test configuration any more, we have all moved on to
new jobs and different projects, Intel has also moved on to a different
platform, and our former contacts on Intel's Nios II team have moved on
as well. It seems like it's time to pull the plug.
Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove
support from all toolchain components after the release is made. I'm
not sure there is an established process for obsoleting/removing support
in other components; besides binutils, GDB, and GLIBC, there's QEMU,
newlib/libgloss, and the Linux kernel. But, we need to get the ball
rolling somewhere.
I did do some GCC testing on both ELF and Linux Nios II targets around
the end of December and another round about a month ago, so I believe
GCC 14 will pretty much be in working order. Beyond that, though, I
think it would be better to remove support promptly, rather than having
it hang around in an unmaintained/untestable zombie state, getting ever
more bit-rotten.
-Sandra
next reply other threads:[~2024-04-18 3:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-18 3:27 Sandra Loosemore [this message]
2024-04-18 5:53 ` Thomas Huth
2024-04-18 12:49 ` Marek Vasut
2024-04-18 15:44 ` Joseph Myers
2024-04-18 15:57 ` Joel Sherrill
2024-04-18 16:06 ` Jeff Law
2024-04-18 17:00 ` Sandra Loosemore
2024-04-18 18:41 ` Arnd Bergmann
2024-04-19 3:50 ` Marek Vasut
2024-04-19 12:05 ` Dinh Nguyen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55a1bc52-b435-463e-8be1-4b23e44393a0@baylibre.com \
--to=sloosemore@baylibre.com \
--cc=andrew@reenigne.org \
--cc=binutils@sourceware.org \
--cc=cltang@baylibre.com \
--cc=dinguyen@kernel.org \
--cc=gcc@gcc.gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=libc-alpha@sourceware.org \
--cc=newlib@sourceware.org \
--cc=qemu-devel@nongnu.org \
--cc=qiyaoltc@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).