https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118280
--- Comment #35 from Neal Frager <neal.frager at amd dot com> --- (In reply to Álvaro Gámez Machado from comment #34) > (In reply to Neal Frager from comment #33) > > Hi Alvaro, > > > > Just to clarify, you are right that our long term solution is to move to > > Microblaze-V (RISC-V). While we had good reasons for developing Microblaze, > > we believe open cores are the better solution moving forward. The idea of > > Microblaze-V is that we keep all the IPs, interrupt controller solution and > > peripherals, such that you can literally migrate from Microblaze to > > Microblaze-V by only changing the toolchain from microblaze to risc-v. > > Peripherals and register addressing will remain the same. > > I've considered migrating to some of the RISC-V open cores out there, but > right now it's not worth it to me due to all the impedance mismatch between > those cores frameworks (spinalhdl anyone?) and the standard Vivado workflow > (either via GUI or batch mode); not to speak of the issue of connecting > wishbone cores to AXI ones, etc. So definitely, as long as Microblaze exists > in some form that allows ease of use, in our particular case, we'll be > priming that above performance and other metrics of the core. > > Although, given the pricing of the smaller Zynq SoCs, in future designs we > may be going for a small Zynq-7000 instead of an Artix, which would > completely all the soft core issues. Zynq-7000 is also well supported in buildroot, and we are guaranteeing availability and maintenance until at least 2040. https://www.amd.com/en/blogs/2024/amd-supports-new-long-lifecycle-fpga-designs-thro.html > > > We are not far from enabling Linux on our Microblaze-V core, and you can > > expect to see this in our 2026.x releases. > > That's great news, thank you! > > > In spite of all this, we are keeping Microblaze going for companies such as > > yours, so you have time to make the transition to Microblaze-V. You can > > expect that the GCC toolchain will still get fixed should new bugs be found, > > but we will not be doing any new active development for the Microblaze. > > Thanks! > > > If you apply the following two patches to GCC-15, you can use the latest GCC > > v15.2.0 to build Linux running on the Microblaze, so you can indeed update > > to the latest toolchain version. The first of these two patches has already > > been committed upstream. The second is a work around solution with > > development in progress. > > > > https://github.com/buildroot/buildroot/blob/master/package/gcc/15.2.0/0002- > > MicroBlaze-Enhance-support-for-atomics.-Fix-PR118280.patch > > > > https://github.com/buildroot/buildroot/blob/master/package/gcc/15.2.0/0003- > > gcc-config-microblaze-fix-ira-for-GCC15.patch > > These two patches were already included in buildroot, so I didn't need to > include them myself, but they are not enough. Please, check out > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103383 I needed that patch also > to solve an issue related to swap endianness, frequently used in network > related code. Thank you for sharing this bug report. I was not aware of it. At the moment, no one from AMD is actively monitoring microblaze gcc bug reports, which I believe is the root cause of the problem. We can only fix issues we are aware of. That said, I hope you can understand that this is why we want to move forward with arm and risc-v based products. This way we do not need to be gcc experts which is not our core business. In the future, could I ask your help in getting our attention when you identify issues like this one? The best way to do so is to report the issue directly with us using the link below. You can share the GCC bugzilla with your message. https://adaptivesupport.amd.com/s/article/How-do-I-get-support-for-Xilinx-technical-issues?language=en_US Best regards, Neal Frager AMD
