Hi,
I've just been bitten by build problems with outdated MIPS code for one of my CLs (not for the first time), and I've been wondering if it's maybe time that we drop the architecture port completely. It was added 5 years ago to support a Chrome OS project that never ended up going anywhere and has been sitting in the tree unused and unsupported ever since. The only SoC/board building it is that old abandoned Chrome OS project for which there's probably not even any hardware around anymore (or if there is, nobody wants to spend time with it). There's no maintainer or even anybody who really reads MIPS assembly or understands the architecture's intricacies paying attention to it, and it keeps causing trouble when we try to pull it along with overarching refactorings. I think at some point, if nobody wants to use it and there's no future use case on the horizon, we should consider pulling the plug.
Some examples of stuff that causes problems:
1. There's no 64-bit division support (even soft-division) because we have no code to implement the required libgcc function, and nobody knows enough MIPS assembly to fix that. We need to keep several hacks around in generic code (e.g. printf()) where code doesn't use 64-bit division even though it probably should or has a special #if CONFIG(ARCH_MIPS) case to deal with this. 2. The read/write8/16/32() functions in libpayload take arguments in (value, addr) order, whereas for all other architectures they have long since been standardized to take (addr, value). This means you can't submit any generic code that does direct MMIO without wrapping it in #if !CONFIG(ARCH_MIPS). There are a bunch of depthcharge drivers left still using that old convention... I don't have time/interest refactoring all of those and I don't think anybody else does either.
We could either drop it right away, or (if we think that's too sudden) schedule it for deletion after the next coreboot release (4.11 in December(?)). What do people think?
I agree it could be dropped. If the need ever arises it could be resurrected and fixed.
-vb
On Mon, Aug 12, 2019 at 5:19 PM Julius Werner jwerner@chromium.org wrote:
Hi,
I've just been bitten by build problems with outdated MIPS code for one of my CLs (not for the first time), and I've been wondering if it's maybe time that we drop the architecture port completely. It was added 5 years ago to support a Chrome OS project that never ended up going anywhere and has been sitting in the tree unused and unsupported ever since. The only SoC/board building it is that old abandoned Chrome OS project for which there's probably not even any hardware around anymore (or if there is, nobody wants to spend time with it). There's no maintainer or even anybody who really reads MIPS assembly or understands the architecture's intricacies paying attention to it, and it keeps causing trouble when we try to pull it along with overarching refactorings. I think at some point, if nobody wants to use it and there's no future use case on the horizon, we should consider pulling the plug.
Some examples of stuff that causes problems:
- There's no 64-bit division support (even soft-division) because we
have no code to implement the required libgcc function, and nobody knows enough MIPS assembly to fix that. We need to keep several hacks around in generic code (e.g. printf()) where code doesn't use 64-bit division even though it probably should or has a special #if CONFIG(ARCH_MIPS) case to deal with this. 2. The read/write8/16/32() functions in libpayload take arguments in (value, addr) order, whereas for all other architectures they have long since been standardized to take (addr, value). This means you can't submit any generic code that does direct MMIO without wrapping it in #if !CONFIG(ARCH_MIPS). There are a bunch of depthcharge drivers left still using that old convention... I don't have time/interest refactoring all of those and I don't think anybody else does either.
We could either drop it right away, or (if we think that's too sudden) schedule it for deletion after the next coreboot release (4.11 in December(?)). What do people think?
+1. Better to retire the code sooner than let it deteriorate into a less and less useful state.
On Tue, Aug 13, 2019 at 7:53 AM Vadim Bendebury (вб) via coreboot < coreboot@coreboot.org> wrote:
I agree it could be dropped. If the need ever arises it could be resurrected and fixed.
-vb
On Mon, Aug 12, 2019 at 5:19 PM Julius Werner jwerner@chromium.org wrote:
Hi,
I've just been bitten by build problems with outdated MIPS code for one of my CLs (not for the first time), and I've been wondering if it's maybe time that we drop the architecture port completely. It was added 5 years ago to support a Chrome OS project that never ended up going anywhere and has been sitting in the tree unused and unsupported ever since. The only SoC/board building it is that old abandoned Chrome OS project for which there's probably not even any hardware around anymore (or if there is, nobody wants to spend time with it). There's no maintainer or even anybody who really reads MIPS assembly or understands the architecture's intricacies paying attention to it, and it keeps causing trouble when we try to pull it along with overarching refactorings. I think at some point, if nobody wants to use it and there's no future use case on the horizon, we should consider pulling the plug.
Some examples of stuff that causes problems:
- There's no 64-bit division support (even soft-division) because we
have no code to implement the required libgcc function, and nobody knows enough MIPS assembly to fix that. We need to keep several hacks around in generic code (e.g. printf()) where code doesn't use 64-bit division even though it probably should or has a special #if CONFIG(ARCH_MIPS) case to deal with this. 2. The read/write8/16/32() functions in libpayload take arguments in (value, addr) order, whereas for all other architectures they have long since been standardized to take (addr, value). This means you can't submit any generic code that does direct MMIO without wrapping it in #if !CONFIG(ARCH_MIPS). There are a bunch of depthcharge drivers left still using that old convention... I don't have time/interest refactoring all of those and I don't think anybody else does either.
We could either drop it right away, or (if we think that's too sudden) schedule it for deletion after the next coreboot release (4.11 in December(?)). What do people think?
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
I think that's a good idea.
In the meantime, how are we doing to deal with the drivers in depthcharge using write32(v, a)? Should we just remove them as well?
On Tue, Aug 13, 2019 at 2:13 PM David Hendricks david.hendricks@gmail.com wrote:
+1. Better to retire the code sooner than let it deteriorate into a less and less useful state.
On Tue, Aug 13, 2019 at 7:53 AM Vadim Bendebury (вб) via coreboot < coreboot@coreboot.org> wrote:
I agree it could be dropped. If the need ever arises it could be resurrected and fixed.
-vb
On Mon, Aug 12, 2019 at 5:19 PM Julius Werner jwerner@chromium.org wrote:
Hi,
I've just been bitten by build problems with outdated MIPS code for one of my CLs (not for the first time), and I've been wondering if it's maybe time that we drop the architecture port completely. It was added 5 years ago to support a Chrome OS project that never ended up going anywhere and has been sitting in the tree unused and unsupported ever since. The only SoC/board building it is that old abandoned Chrome OS project for which there's probably not even any hardware around anymore (or if there is, nobody wants to spend time with it). There's no maintainer or even anybody who really reads MIPS assembly or understands the architecture's intricacies paying attention to it, and it keeps causing trouble when we try to pull it along with overarching refactorings. I think at some point, if nobody wants to use it and there's no future use case on the horizon, we should consider pulling the plug.
Some examples of stuff that causes problems:
- There's no 64-bit division support (even soft-division) because we
have no code to implement the required libgcc function, and nobody knows enough MIPS assembly to fix that. We need to keep several hacks around in generic code (e.g. printf()) where code doesn't use 64-bit division even though it probably should or has a special #if CONFIG(ARCH_MIPS) case to deal with this. 2. The read/write8/16/32() functions in libpayload take arguments in (value, addr) order, whereas for all other architectures they have long since been standardized to take (addr, value). This means you can't submit any generic code that does direct MMIO without wrapping it in #if !CONFIG(ARCH_MIPS). There are a bunch of depthcharge drivers left still using that old convention... I don't have time/interest refactoring all of those and I don't think anybody else does either.
We could either drop it right away, or (if we think that's too sudden) schedule it for deletion after the next coreboot release (4.11 in December(?)). What do people think?
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
In the meantime, how are we doing to deal with the drivers in depthcharge using write32(v, a)? Should we just remove them as well?
Yes, when the architecture gets removed, all SoC and board code (including in payloads) that depends on it has to be removed as well, of course.
Okay, so all I've heard for now are supporting voices, and it doesn't sound like anyone is particularly concerned about timeline (i.e. needing to wait until after the next release or something). I've uploaded a patch to kill it as https://review.coreboot.org/34919. If anyone feels that we shouldn't do this, please yell.
On Tue, Aug 13, 2019 at 1:11 PM Julius Werner jwerner@chromium.org wrote:
In the meantime, how are we doing to deal with the drivers in depthcharge using write32(v, a)? Should we just remove them as well?
Yes, when the architecture gets removed, all SoC and board code (including in payloads) that depends on it has to be removed as well, of course.
Hello! If no one objects, then I'll go and push for it. Simply because the only MIPS ones I know of are the very proprietary ones used for certain routers. And I do know that the vendor behind those processors practically requires an NDA before any company can go ahead and even design a development board for them. ----- Gregg C Levine gregg.drwho8@gmail.com "This signature fought the Time Wars, time and again."
On Mon, Aug 12, 2019 at 8:20 PM Julius Werner jwerner@chromium.org wrote:
Hi,
I've just been bitten by build problems with outdated MIPS code for one of my CLs (not for the first time), and I've been wondering if it's maybe time that we drop the architecture port completely. It was added 5 years ago to support a Chrome OS project that never ended up going anywhere and has been sitting in the tree unused and unsupported ever since. The only SoC/board building it is that old abandoned Chrome OS project for which there's probably not even any hardware around anymore (or if there is, nobody wants to spend time with it). There's no maintainer or even anybody who really reads MIPS assembly or understands the architecture's intricacies paying attention to it, and it keeps causing trouble when we try to pull it along with overarching refactorings. I think at some point, if nobody wants to use it and there's no future use case on the horizon, we should consider pulling the plug.
Some examples of stuff that causes problems:
- There's no 64-bit division support (even soft-division) because we
have no code to implement the required libgcc function, and nobody knows enough MIPS assembly to fix that. We need to keep several hacks around in generic code (e.g. printf()) where code doesn't use 64-bit division even though it probably should or has a special #if CONFIG(ARCH_MIPS) case to deal with this. 2. The read/write8/16/32() functions in libpayload take arguments in (value, addr) order, whereas for all other architectures they have long since been standardized to take (addr, value). This means you can't submit any generic code that does direct MMIO without wrapping it in #if !CONFIG(ARCH_MIPS). There are a bunch of depthcharge drivers left still using that old convention... I don't have time/interest refactoring all of those and I don't think anybody else does either.
We could either drop it right away, or (if we think that's too sudden) schedule it for deletion after the next coreboot release (4.11 in December(?)). What do people think? _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-
David Hendricks -
Gregg Levine -
Hung-Te Lin -
Julius Werner -
Vadim Bendebury (вб)