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