Gentoo Archives: gentoo-mips

From: Joshua Kinard <kumba@g.o>
To: gentoo-mips@l.g.o, Matt Turner <mattst88@g.o>, gentoo-dev@l.g.o
Cc: mips@g.o
Subject: Re: [gentoo-mips] Monthly mips@ project status for April 2018
Date: Mon, 02 Apr 2018 07:37:15
In Reply to: [gentoo-mips] Monthly mips@ project status for April 2018 by Matt Turner
1 On 4/1/2018 11:40 PM, Matt Turner wrote:
2 > I'd like to start giving ~monthly updates on the status of mips@ in
3 > Gentoo.
4 >
5 > Recently I received a Loongson 3A system (quad-core 1.35GHz, 16GB RAM,
6 > AMD graphics) which is significantly faster and more stable than any
7 > other mips system I have.
9 Big or little endian? If little,
12 > == Loongson 3A support ==
13 >
14 > The Loongson 3A system I received requires a number of out of tree
15 > patches to the kernel, gcc, binutils, and glibc. I've seen their
16 > developers working to upstream kernel patches, but it's slow going and
17 > there are a lot of them.
18 >
19 > I haven't seen much work to upstream the other patches. I'm not sure how
20 > to reasonably support hardware requiring so many out-of-tree patches.
22 SGI machines I have access to are in a similar state. Except I'm the only nut
23 playing with these systems it seems, and I've got a massive patch backlog
24 that's no where near the quality that upstream would accept. My git foo is
25 also terrible for maintaining them, given that kernel upstream seems to like
26 one patch for every minor change, it seems.
28 Better BRIDGE support for IP27 (SGI Origin) is where most everything begins. I
29 know //what// needs to be done to unscrew that system (mostly), but I just
30 haven't had time to write the C code that'd do it. Following that, IP30 is
31 branched off of my current IP27 work, so once IP27 support is fixed upstream,
32 IP30 could be split apart and some portions sent in.
34 As far as IP30 goes, it works. Probably the most capable of the available SGI
35 machine support right now. Still suffers from the 2GB RAM limit because
36 something still ain't right in dealing with the 512MB PHYS_OFFSET and the wacky
37 BRIDGE DMA mess.
39 IP32/R5K/RM7K works, too. Still nothing on the R10K/R12K variants. All of
40 this hoopla about Spectre and Meltdown on x86 definitely made my day, though
41 </smirk>
43 Long ways down on my TODO list is to try and port nyef's IP35 work from 4.2.x
44 to something more recent. IP35 could re-use much of the IP27 base (once
45 BRIDGE/PCI is fixed), just with appropriate changes to deal with BEDROCK's
46 design as a successor to the HUB. Plenty of example code from the Altix port
47 in the 2.5.x kernel to reference, too. Would enable faster build machines.
49 Lack of time, though. I need a TARDIS...
52 > == n64 toolchain in n32 system ==
53 >
54 >
55 > n32 (and o32) only offer 31-bits of address space (2GB). That's not
56 > sufficient to link large libraries like webkit-gtk. For n32 systems, I'd
57 > like the toolchain binaries to be n64, to avoid these problems.
59 We'll probably need this to also be able to play with LTO, since that's a
60 significant memory consumer, especially if you use several LTO threads.
63 > == stages and installation media ==
64 >
65 >
66 >
67 > With so many subarchitectures, ABIs, and two byte orderings providing
68 > stages and installation media has been a pain point.
69 >
70 > I'd like to automate as much of this as possible. I really need Kumba to
71 > build a new SGI CD, but well, that bug's been open since 2006.
73 I got a mostly-working netboot image built in December for my IP32 system,
74 based off of uclibc-ng and 4.13.16. Building the image right now needs a fresh
75 stage3 uclibc-ng/mips2, a custom script I wrote in Python, and copy/pasting
76 specific commands. End goal is to take that logic and turn it into a
77 "netboot3" target for Catalyst. I stopped when catalyst-3 debuted, because I
78 didn't get around to looking at the changes from catalyst 2.x to 3.x. But the
79 script works manually, with some post-cleanup commands.
81 However, I held off on publishing anything because the most recent stage builds
82 were done under gcc-6.4.0, and with the resolution of gcc PR81443, I can now
83 run gcc-7.3.x on my SGI systems. I plan on starting another series of stage
84 runs under catalyst 2.x once OpenRC gets fixed for the uclibc-ng target (see
85 bug #650908). Six targets (n32/{mips3,mips4,mips4_r12k}, o32, multilib, &
86 uclibc-ng) takes about a month on my Octane right now. Mostly because gcc's
87 build time is utterly insane.
89 If anyone wants, I can publish the December builds for the SGI big-endian
90 stages. Maybe a few netboot targets if I can find the time, likely based on
91 4.13.x because 4.14/4.15 had the firmware tree stripped out, and there's a
92 quirky bug where input over ssh on my Octane has a very weird, sporadic latency
93 at random, which I think is a bug I'll be forced to bisect down at some point.
95 Also, if anyone has a mips3/mips4/mips4 ISA, big-endian musl stage, hook me up.
96 I'd love to use musl for netboot targets, as even uclibc-ng is pushing ~12MB
97 for a full netboot image, I am still not 100% certain the older SGI machines
98 will take it (namely IP22, not that I even have a working unit anymore).
100 SGI bootable CDs are not impossible (all the tools are still in the tree), but
101 we really need netboot images first. Any future boot CD will be command line
102 only. The X11 world has moved so far ahead, that even if Octane's X11 Impact
103 driver got fixed, I doubt the experience would be anything but "fun".
105 --
106 Joshua Kinard
107 Gentoo/MIPS
108 kumba@g.o
109 6144R/F5C6C943 2015-04-27
110 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943
112 "The past tempts us, the present confuses us, the future frightens us. And our
113 lives slip away, moment by moment, lost in that vast, terrible in-between."
115 --Emperor Turhan, Centauri Republic


Subject Author
Re: [gentoo-mips] Monthly mips@ project status for April 2018 Joshua Kinard <kumba@g.o>