+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 < [email protected]> 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 <[email protected]> > 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: >> >> 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 -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
