[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#825024: linux: add MIPS r6 and N32 support



On Mon, May 23, 2016 at 7:24 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> Control: tag -1 - moreinfo
>
> On Mon, 2016-05-23 at 11:14 +0800, YunQiang Su wrote:
>> On Mon, May 23, 2016 at 2:30 AM, Ben Hutchings <ben@decadent.org.uk> wrote:
>> >
>> > Control: tag -1 moreinfo
>> >
>> > On Sun, 2016-05-22 at 22:52 +0800, YunQiang Su wrote:
>> > >
>> > > Package: src:linux
>> > > Version: 4.5 - 4.6
>> > >
>> > > Hi, this patch add mipsn32 and mipsn32el support and also add
>> > > 6 MIPS r6 architectures.
>> > >
>> > > mipsn32 and mipsn32el have same flavors with mips64 and mips64el.
>> > Since we have multiarch it is not necessary to duplicate kernel
>> > packages with identical configurations in multiple Debian
>> > architectures.  All the N32 architectures should be used in multiarch
>> > configurations together with the corresponding 64-bit architectures.
>> > (The same should be true for O32 architectures, but that won't happen
>> > until the corresponding 64-bit architectures are in the main archive.)
>> I won't push N32 architecture to the main Debian archive.
>> I just wish the code in the upstream, so I will not have to maintain another
>> git repo, and merge patches again and again.
>>
>> In fact, I may build a standalone N32 private archive in future.
>
> I will still insist that N32 architectures do not have their own
> kernels, only userland packages (linux-libc-dev, linux-kbuild, linux-
> perf, etc.)

Yes, so mipsn32/mipsn32el architectures has the same flavors with
mips64/mips64el.

N32 here is about 2 new architectures named mipsn32/mipsn32el.
To make these architectures installable, they must have their own
kernel packages, like
linux-image-4.6.0-1-loongson-3_$(THE_VERSION).mipsn32el.deb.

This package has the same content with:

linux-image-4.6.0-1-loongson-3_$(THE_VERSION).mips64el.deb.

>
>> > [...]
>> > >
>> > > --- a/debian/config/defines
>> > > +++ b/debian/config/defines
>> > > @@ -13,8 +13,16 @@ arches:
>> > >   m68k
>> > >   mips
>> > >   mipsel
>> > > + mipsn32
>> > > + mipsn32el
>> > >   mips64
>> > >   mips64el
>> > > + mipsr6
>> > > + mipsr6el
>> > > + mipsn32r6
>> > > + mipsn32r6el
>> > > + mips64r6
>> > > + mips64r6el
>> > [...]
>> >
>> > This is ridiculous.  12 different Debian architectures for MIPS?!  If
>> > you want to make ARM look like a better choice, this sort of
>> > fragmentation of binary compatibility is a good way to do it.
>> >
>> > Why are there new Debian architectures specifically for R6, given that
>> > Debian architectures correspond to ABIs and not specific CPU
>> > requirements (e.g.. i386's CPU requirements have graudally moved up
>> > from 386 to 686-class)?
>> Please see the talk on
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807340
>>
>> MIPS R6 is a new release of MIPS32 and MIPS64.
>> R6 is not fully compatible with R5-,
>> as it adds and *removes* some instructions, and add emulation
>> of the removed instructions in kernel,
>> so old binaries can still run on new R6 CPUs.
>
> That's quite amazing.  But it's even worse that that - the architecture
> reference you linked to says some of the removed instructions'
> encodings have been reassigned to new instructions.  This seems to make
> emulation impossible.
>
>> While for the new CPUs, we still wish they can have their own architectures.
>
> I suppose they will have to.
>
> Ben.
>
>> In future, we may add them to the official Debian archive,
>> while now, it is just a prepare.
>
>
> --
> Ben Hutchings
> You can't have everything.  Where would you put it?



-- 
YunQiang Su


Reply to: