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 [email protected] "This signature fought the Time Wars, time and again."
On Mon, Aug 12, 2019 at 8:20 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]
