+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 <
I agree it could be dropped. If the need ever arises
it could be
resurrected and fixed.
On Mon, Aug 12, 2019 at 5:19 PM Julius Werner <jwerner(a)chromium.org>
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?
coreboot mailing list -- coreboot(a)coreboot.org
To unsubscribe send an email to coreboot-leave(a)coreboot.org