[Buildroot] Undo [PATCH v2] Mark MIPS I, II, III and IV as deprecated

[Buildroot] Undo [PATCH v2] Mark MIPS I, II, III and IV as deprecated

[Joshua Kinard]

Per this thread/patch here:
http://lists.busybox.net/pipermail/buildroot/2013-November/082976.html

I'd like to point out that these CPU ISAs are not completely "deprecated"
nor rare.  Well, MIPS-I and MIPS-II might be "rare", but MIPS-III and
MIPS-IV are the minimum required ISAs for old SGI systems, which are most
plentiful on eBay.  Gentoo and Debian support Indy, Indigo2, and O2-based
systems, most of which need MIPS-IV (the R4x00 Indy's and I2's need MIPS-III
at a minimum).

I've been looking at buildroot as a way to quickly generate a working root
filesystem for netboot images, but I ran into a side-effect of this patch
when building 'attr':

/usr/space/buildroot/buildroot-2013.11/output/host/usr/lib/gcc/mips-buildroot-linux-uclibc/4.8.2/../../../../mips-buildroot-linux-uclibc/bin/ld:
/tmp/ccHuCGCg.o: linking mips:8000 module with previous mips:isa32 modules

/usr/space/buildroot/buildroot-2013.11/output/host/usr/lib/gcc/mips-buildroot-linux-uclibc/4.8.2/../../../../mips-buildroot-linux-uclibc/bin/ld:
failed to merge target specific data of file /tmp/ccHuCGCg.o

I was passing '-march=mips4' to the build, which resulted in the error.
After finding this patch, activating BR2_DEPRECATED, and selecting "mips
iv", the build completed fine.

Does deprecation imply removal at some point in the future?  I'd argue in
favour of keeping them around, but either restricting them to a
machine-specific build (such as creating a sub-family for SGI systems and
setting them there), and keeping the new defaults for mips/mipsel at
mips32/mips64 ISAs.

Thanks!,

-- 
Joshua Kinard
Gentoo/MIPS
kumba at gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: OpenPGP digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140204/786b0989/attachment.asc>

[Buildroot] Undo [PATCH v2] Mark MIPS I, II, III and IV as deprecated

[Markos Chandras]

On 02/05/2014 03:39 AM, Joshua Kinard wrote:
> Per this thread/patch here:
> http://lists.busybox.net/pipermail/buildroot/2013-November/082976.html
>
> I'd like to point out that these CPU ISAs are not completely "deprecated"
> nor rare.  Well, MIPS-I and MIPS-II might be "rare", but MIPS-III and
> MIPS-IV are the minimum required ISAs for old SGI systems, which are most
> plentiful on eBay.  Gentoo and Debian support Indy, Indigo2, and O2-based
> systems, most of which need MIPS-IV (the R4x00 Indy's and I2's need MIPS-III
> at a minimum).
>
> I've been looking at buildroot as a way to quickly generate a working root
> filesystem for netboot images, but I ran into a side-effect of this patch
> when building 'attr':
>
> /usr/space/buildroot/buildroot-2013.11/output/host/usr/lib/gcc/mips-buildroot-linux-uclibc/4.8.2/../../../../mips-buildroot-linux-uclibc/bin/ld:
> /tmp/ccHuCGCg.o: linking mips:8000 module with previous mips:isa32 modules
>
> /usr/space/buildroot/buildroot-2013.11/output/host/usr/lib/gcc/mips-buildroot-linux-uclibc/4.8.2/../../../../mips-buildroot-linux-uclibc/bin/ld:
> failed to merge target specific data of file /tmp/ccHuCGCg.o
>
> I was passing '-march=mips4' to the build, which resulted in the error.
> After finding this patch, activating BR2_DEPRECATED, and selecting "mips
> iv", the build completed fine.
>
> Does deprecation imply removal at some point in the future?  I'd argue in
> favour of keeping them around, but either restricting them to a
> machine-specific build (such as creating a sub-family for SGI systems and
> setting them there), and keeping the new defaults for mips/mipsel at
> mips32/mips64 ISAs.
>
> Thanks!,
>
>
Hi Joshua,

I know they are still supported in Linux distribution. I build the 
Gentoo stages myself :)
The point of this patch is that, as buildroot is moving forwards, more 
and more packages fail to build if you happen to select an old MIPS ISA 
and this situation is unlikely to be improved in the future.
The deprecation indeed means that this support will go away in a year.
Or maybe we can keep them for longer period? Or maybe change 
BR2_DEPRECATED to BR2_UNSUPPORTED or something? Would that be better?
Thomas, do you think this would be acceptable?

-- 
markos

[Buildroot] Undo [PATCH v2] Mark MIPS I, II, III and IV as deprecated

[Arnout Vandecappelle]

On 05/02/14 04:39, Joshua Kinard wrote:
> Per this thread/patch here:
> http://lists.busybox.net/pipermail/buildroot/2013-November/082976.html
> 
> I'd like to point out that these CPU ISAs are not completely "deprecated"
> nor rare.  Well, MIPS-I and MIPS-II might be "rare", but MIPS-III and
> MIPS-IV are the minimum required ISAs for old SGI systems, which are most
> plentiful on eBay.  Gentoo and Debian support Indy, Indigo2, and O2-based
> systems, most of which need MIPS-IV (the R4x00 Indy's and I2's need MIPS-III
> at a minimum).
> 
> I've been looking at buildroot as a way to quickly generate a working root
> filesystem for netboot images, but I ran into a side-effect of this patch
> when building 'attr':
> 
> /usr/space/buildroot/buildroot-2013.11/output/host/usr/lib/gcc/mips-buildroot-linux-uclibc/4.8.2/../../../../mips-buildroot-linux-uclibc/bin/ld:
> /tmp/ccHuCGCg.o: linking mips:8000 module with previous mips:isa32 modules
> 
> /usr/space/buildroot/buildroot-2013.11/output/host/usr/lib/gcc/mips-buildroot-linux-uclibc/4.8.2/../../../../mips-buildroot-linux-uclibc/bin/ld:
> failed to merge target specific data of file /tmp/ccHuCGCg.o
> 
> I was passing '-march=mips4' to the build, which resulted in the error.
> After finding this patch, activating BR2_DEPRECATED, and selecting "mips
> iv", the build completed fine.
> 
> Does deprecation imply removal at some point in the future?  I'd argue in
> favour of keeping them around, but either restricting them to a
> machine-specific build (such as creating a sub-family for SGI systems and
> setting them there), and keeping the new defaults for mips/mipsel at
> mips32/mips64 ISAs.

 The reason that we mark it as deprecated is to indicate that we intend
to remove it, but to give people the chance to react on it. If you are
interested in keeping this architecture alive and to provide patches for
it, then we can un-deprecate it.

 To continue maintaining this architecture, we need someone who:

- can suggest a few good toolchain defconfigs to be used in the autobuilders;

- can provide patches for autobuilder failures;

- can occasionally do run-time testing on real hardware to check if it
actually works.

 So, Joshua, are you game?

 If yes, please provide a patch that removes the deprecation for MIPS III
and IV, and try if you actually build and run a useful system. It's
probably also a good idea if you can immediately run-time test some of
the tricky packages (libffi, libglib2, python, perl, lua).


 Regards,
 Arnout

> 
> Thanks!,
> 
> 
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 880 bytes
Desc: OpenPGP digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140205/dba3efe5/attachment.asc>

[Buildroot] Undo [PATCH v2] Mark MIPS I, II, III and IV as deprecated

[Joshua Kinard]

On 02/05/2014 3:52 PM, Arnout Vandecappelle wrote:
> On 05/02/14 04:39, Joshua Kinard wrote:
>> Per this thread/patch here:
>> http://lists.busybox.net/pipermail/buildroot/2013-November/082976.html
>>
>> I'd like to point out that these CPU ISAs are not completely "deprecated"
>> nor rare.  Well, MIPS-I and MIPS-II might be "rare", but MIPS-III and
>> MIPS-IV are the minimum required ISAs for old SGI systems, which are most
>> plentiful on eBay.  Gentoo and Debian support Indy, Indigo2, and O2-based
>> systems, most of which need MIPS-IV (the R4x00 Indy's and I2's need MIPS-III
>> at a minimum).
>>
>> I've been looking at buildroot as a way to quickly generate a working root
>> filesystem for netboot images, but I ran into a side-effect of this patch
>> when building 'attr':
>>
>> /usr/space/buildroot/buildroot-2013.11/output/host/usr/lib/gcc/mips-buildroot-linux-uclibc/4.8.2/../../../../mips-buildroot-linux-uclibc/bin/ld:
>> /tmp/ccHuCGCg.o: linking mips:8000 module with previous mips:isa32 modules
>>
>> /usr/space/buildroot/buildroot-2013.11/output/host/usr/lib/gcc/mips-buildroot-linux-uclibc/4.8.2/../../../../mips-buildroot-linux-uclibc/bin/ld:
>> failed to merge target specific data of file /tmp/ccHuCGCg.o
>>
>> I was passing '-march=mips4' to the build, which resulted in the error.
>> After finding this patch, activating BR2_DEPRECATED, and selecting "mips
>> iv", the build completed fine.
>>
>> Does deprecation imply removal at some point in the future?  I'd argue in
>> favour of keeping them around, but either restricting them to a
>> machine-specific build (such as creating a sub-family for SGI systems and
>> setting them there), and keeping the new defaults for mips/mipsel at
>> mips32/mips64 ISAs.
> 
>  The reason that we mark it as deprecated is to indicate that we intend
> to remove it, but to give people the chance to react on it. If you are
> interested in keeping this architecture alive and to provide patches for
> it, then we can un-deprecate it.
> 
>  To continue maintaining this architecture, we need someone who:
> 
> - can suggest a few good toolchain defconfigs to be used in the autobuilders;
> 
> - can provide patches for autobuilder failures;
> 
> - can occasionally do run-time testing on real hardware to check if it
> actually works.
> 
>  So, Joshua, are you game?

Forgive me on my lack of knowledge on the history of the MIPS-I through
MIPS-IV issues with regards to buildroot, but technically, maintaining this
arch (really ISA) shouldn't be all that problematic.  The MIPS-I through
MIPS-IV ISAs are the parents of the mips32r*/mips64r* ISAs, so
theoretically, one should be able to compile buildroot w/ MIPS-I and it
should run, albeit w/ reduced performance, on virtually any MIPS platform
that currently exists.

I've primarily stuck w/ SGI's systems, so I haven't ventured out into the
newer MIPS ISAs, but selecting, say, MIPS-IV in menuconfig is basically just
saying the minimum CPU requirement for the generated code is that of SGI's
R8000 processor (which originally defined the MIPS-IV ISA back in the
1990's).  That code should run on everything from an R5000 up to the latest
64bit MIPS processor.  So if I cooked up a netboot rootfs that boots and
runs on my O2, anyone else on this list running a 64bit MIPS CPU should be
able to bundle the same rootfs into a netboot kernel for their platform and
it run as well.

What are some of the issues encountered in the past (outside of the obvious
linker mismatches that I ran into) that triggered the original deprecation
patch?  I admit that my knowledge is probably dated, so some pointers to
help me better understand the problem that the deprecation patch tries to
solve would be greatly appreciated.


Right now, in menuconfig, the "Target Architecture Variant" for MIPS
platforms is just a flat list of the various ISAs, and I suspect this
creates the conflict/confusion that may have caused people build errors in
the past.  Understanding the differences in the various MIPS ISAs can be
challenging sometimes, and even some of SGI's own documentation on this
topic contradicted itself in the past.  I think it really should be a
tree-like selection, such that if mips32r2 is selected, it also implies MIPS-II:

MIPS-I (32bit, R2000/R3000)
  |
  |-MIPS-II (32bit, R6000)
      |-mips32r1
      |   |-mips32r2
      |
    MIPS-III (64bit, R4x00)
      |
    MIPS-IV (64bit, R8000/R5000/RM7000/R1x000+)
      |-mips64r1
          |-mips64r2

Problem is, I don't think menuconfig has the ability to do that type of
layout in the "select 1 from the group" choice menu it currently offers for
this subitem.  If it can, that'd be the approach I'd use for this menu item,
as well as providing help text so that users can be guided into selecting
the correct ISA for their target platform.


>  If yes, please provide a patch that removes the deprecation for MIPS III
> and IV, and try if you actually build and run a useful system. It's
> probably also a good idea if you can immediately run-time test some of
> the tricky packages (libffi, libglib2, python, perl, lua).

Currently, my initial build attempts have all been cross-compiles on my
amd64 machine.  My SGI O2 only has a 350MHz CPU in it (the fastest currently
supported by Linux for that machine), so it'd take a few days for a full
build I figure.  Mostly because of gcc (16+ hours for 4.8.x these days, and
it goes up every new version).  My build also targets a headless, or at
least, a configuration w/o X11, due to size limits on the kernel image that
this machine can successfully netboot.

As far as patches, I can probably work something up.  However, I am not
familiar with buildroot's source tree, submission process, guidelines, code
style, etc, so anything I submit would need many eyeballs.  I played with it
for a few days on the 2013.05 release, before the deprecation patch was
added, and then switched to other priorities.  I just got back around to
trying it again last weekend, when I ran into the problem that spurred this
thread.

Thanks!

-- 
Joshua Kinard
Gentoo/MIPS
kumba at gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: OpenPGP digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140205/784f977a/attachment-0001.asc>

[Buildroot] Undo [PATCH v2] Mark MIPS I, II, III and IV as deprecated

[Arnout Vandecappelle]

On 06/02/14 00:11, Joshua Kinard wrote:
> On 02/05/2014 3:52 PM, Arnout Vandecappelle wrote:
>> On 05/02/14 04:39, Joshua Kinard wrote:
[snip]
>>> Does deprecation imply removal at some point in the future?  I'd argue in
>>> favour of keeping them around, but either restricting them to a
>>> machine-specific build (such as creating a sub-family for SGI systems and
>>> setting them there), and keeping the new defaults for mips/mipsel at
>>> mips32/mips64 ISAs.
>>
>>  The reason that we mark it as deprecated is to indicate that we intend
>> to remove it, but to give people the chance to react on it. If you are
>> interested in keeping this architecture alive and to provide patches for
>> it, then we can un-deprecate it.
>>
>>  To continue maintaining this architecture, we need someone who:
>>
>> - can suggest a few good toolchain defconfigs to be used in the autobuilders;
>>
>> - can provide patches for autobuilder failures;
>>
>> - can occasionally do run-time testing on real hardware to check if it
>> actually works.
>>
>>  So, Joshua, are you game?
> 
> Forgive me on my lack of knowledge on the history of the MIPS-I through
> MIPS-IV issues with regards to buildroot, but technically, maintaining this
> arch (really ISA) shouldn't be all that problematic.  The MIPS-I through
> MIPS-IV ISAs are the parents of the mips32r*/mips64r* ISAs, so
> theoretically, one should be able to compile buildroot w/ MIPS-I and it
> should run, albeit w/ reduced performance, on virtually any MIPS platform
> that currently exists.

 Not so, because there are quite a few packages that use assembly with
newer ISA for things like atomics, userspace mutexes, etc.

> 
> I've primarily stuck w/ SGI's systems, so I haven't ventured out into the
> newer MIPS ISAs, 

 Don't worry about the newer ISA's, our friends at imgtec are dealing
with those.


> but selecting, say, MIPS-IV in menuconfig is basically just
> saying the minimum CPU requirement for the generated code is that of SGI's
> R8000 processor (which originally defined the MIPS-IV ISA back in the
> 1990's).  That code should run on everything from an R5000 up to the latest
> 64bit MIPS processor.

... but packages that use assembly for the latest 64bit MIPS processor
will not run or even build on the R8000.

>  So if I cooked up a netboot rootfs that boots and
> runs on my O2, anyone else on this list running a 64bit MIPS CPU should be
> able to bundle the same rootfs into a netboot kernel for their platform and
> it run as well.
> 
> What are some of the issues encountered in the past (outside of the obvious
> linker mismatches that I ran into) that triggered the original deprecation
> patch?  I admit that my knowledge is probably dated, so some pointers to
> help me better understand the problem that the deprecation patch tries to
> solve would be greatly appreciated.

 I think mainly new packages that don't support these old architectures.
So maintaining an old architecture is mainly a matter of marking packages
as not supported on it. grep for BR2_avr32 in the packages directory and
you'll get an idea.

> 
> 
> Right now, in menuconfig, the "Target Architecture Variant" for MIPS
> platforms is just a flat list of the various ISAs, and I suspect this
> creates the conflict/confusion that may have caused people build errors in
> the past.  Understanding the differences in the various MIPS ISAs can be
> challenging sometimes, and even some of SGI's own documentation on this
> topic contradicted itself in the past.  I think it really should be a
> tree-like selection, such that if mips32r2 is selected, it also implies MIPS-II:

 But that is not true: a rootfs built for mips32r2 will not run on MIPS-II.


> MIPS-I (32bit, R2000/R3000)
>   |
>   |-MIPS-II (32bit, R6000)
>       |-mips32r1
>       |   |-mips32r2
>       |
>     MIPS-III (64bit, R4x00)
>       |
>     MIPS-IV (64bit, R8000/R5000/RM7000/R1x000+)
>       |-mips64r1
>           |-mips64r2
> 
> Problem is, I don't think menuconfig has the ability to do that type of
> layout in the "select 1 from the group" choice menu it currently offers for
> this subitem.  If it can, that'd be the approach I'd use for this menu item,
> as well as providing help text so that users can be guided into selecting
> the correct ISA for their target platform.

 You could have a first choice that selects MIPS-I/II/III/IV, and a
second choice that selects the variant within the subarchitecture.
However, with only 8 options I don't see much point. Reordering so that
the mips32 options come before MIPS-III does seem like a good idea though.

 I would BTW keep the variants that you don't have an immediate use for
deprecated. So perhaps keep only MIPS-IV, if that's what you need.

> 
> 
>>  If yes, please provide a patch that removes the deprecation for MIPS III
>> and IV, and try if you actually build and run a useful system. It's
>> probably also a good idea if you can immediately run-time test some of
>> the tricky packages (libffi, libglib2, python, perl, lua).
> 
> Currently, my initial build attempts have all been cross-compiles on my
> amd64 machine.  My SGI O2 only has a 350MHz CPU in it (the fastest currently
> supported by Linux for that machine), so it'd take a few days for a full
> build I figure.  Mostly because of gcc (16+ hours for 4.8.x these days, and
> it goes up every new version).  My build also targets a headless, or at
> least, a configuration w/o X11, due to size limits on the kernel image that
> this machine can successfully netboot.

 We're obviously talking about cross-compiling, that's the only thing
that buildroot can do. And headless is not an issue either - buildroot
anyway doesn't provide a desktop environment.

> 
> As far as patches, I can probably work something up.  However, I am not
> familiar with buildroot's source tree, submission process, guidelines, code
> style, etc, so anything I submit would need many eyeballs.  I played with it
> for a few days on the 2013.05 release, before the deprecation patch was
> added, and then switched to other priorities.  I just got back around to
> trying it again last weekend, when I ran into the problem that spurred this
> thread.

 The manual is in pretty good shape, with extensive submission
guidelines. With your gentoo background I'm sure you'll get the hang of
it quickly.


 Regards,
 Arnout

> 
> Thanks!
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 880 bytes
Desc: OpenPGP digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140206/fe4b48be/attachment.asc>