Kumba wrote:
After a ~2 month hiatus, I've got the Octane running and have been building N32 stages for the last week. mips4_r12k_n32 and mips3_n32 are done, but then I discovered a ~2012 uclibc-based stage4, mips3 big-endian, that another Gentoo dev rolled, and have been trying to bit-bang that into updating so I can use it as a seed stage to
finally
create new MIPS uClibc-based stages for generating new netboot images. Install stages are only good if you can boot something to install them with. Last uclibc stages were done in ~2006 or 2007.
I have bad news for you: If you check, you'll find that the FPU won't kick over to FR1 mode, which is required for N32 and N64. It's on my shortlist to try and fix, but my project bandwidth has shifted away from MIPS kernel hacking for the past while.
I had tried a musl-based netboot image, but I have been experimenting with PAGE_SIZE=64K on my Octane/Origin kernels lately, which really helps speed up compiling (shaves ~45mins off of a binutils compile). However, musl seems to hardcode the PAGE_SIZE it was built with somewhere, so if you booted a kernel with PAGE_SIZE=4K with this musl netboot....all sorts of problems cropped up. Glibc is just too bloated to make an all-purpose netboot, as IP22-class systems have severe limitations on the size of the kernel image that can be loaded, and IP32 can get fussy as well.
Interesting (probably bad) news: I have a short C test program that causes my O350 to reliably do
something
weird, and one of the failure modes is a bus error. And it runs perfectly well on my ERLite-3. I
think
it's a TLB thing, but haven't tracked it down beyond getting a test program, which I did hand off to Ralf so that there'd be more than one set of eyes on the problem.
http://paste.lisp.org/display/160204
if you want to take a look.
nyef wrote:
Code:
Select all
* - Greater than 2GB memory causes problems with DMA. This is a long-standing
* problem and patches to fix it by DMA experts would be greatly appreciated!
On my list to hack on once I get a working IP30 setup. IP35 doesn't have a problem with this, and I have some experience with getting DMA working on XBridge and PIC, and BRIDGE is basically XBridge so I don't expect too much trouble on that front.
Hopefully I'll be able to get you a working beta-netboot within the next 1-2 weeks for the Octane, if this uclibc experiment pans out. The DMA thing has been driving me up the wall, because once the 2GB barrier is worked around and I can hunt down some more high-density RAM chips, I can maybe use a ramdisk for some of the compiling to further speed things up.
I'm still keeping an eye out for high-density Octane SIMMs myself, even if I haven't managed to fix (or work around) the bent (and now stripped) screw that's keeping me from getting at the mainboard with the 2x600 CPU module.
nyef wrote:
Code:
Select all
* - Serial support on the Octane uses a very basic UART driver that drives
* the 16550A chip on the IOC3 directly. It does not use interrupts,
* only a polling routine on a timer, which makes it slow and CPU-
* intensive. The baud rate is limited to no more than 38.4kbps on
* this driver. Patches for getting the Altix IOC3 serial driver to
* work (which uses DMA and supports faster baud rates) are welcome.
Working on IP35, using the DMA-based driver. Took a bit to sort out endianness issues and DMA and whatnot, but was fairly straightforward overall.
Got a stand-alone patch for that? Fixes for that are probably distinct from the core IOC3 mess. Would be interesting to see if Octane's DMA situation is sane enough to run that. After I fix the "ttyIOCx" names back to a proper "ttySx" naming scheme...
As part of
http://git.linux-mips.org/cgit/nyef/linux-ip35/log/?h=v4.2-ioc-changes
, there is commit
http://git.linux-mips.org/cgit/nyef/linux-ip35/commit/?h=v4.2-ioc-changes&id=6142674bcb716f1702ec2e364887a4434f75720d
, which is the IOC3 serial magic.
I've got a possible further angle so that we don't have to do this constant "blah, blah, and on SGI MIPS we also have to twiddle this bit in the DMA address" thing. And, now that I'm thinking about it, my patches may not work for you due to the differences between the DMA setup between the IP30 bridge driver and the IP35 bridge driver.
nyef wrote:
Code:
Select all
* - UHCI Cards are known to have issues, but should still have some functionality.
* This issue primarily manifests itself when using pl2303 USB->Serial adapters.
I have a few pl2303 adapters handy, not sure about the UHCI cards, though.
pl2303 converters are junk anyways. I've switched to using the
XS880
from U.S. Converters, which is based off of an FTDI FT232RL chipset and ZyWyn ZT213LEEA serial driver. They're not cheap at about ~$44 a pop, but all of the problems I've had with serial consoles has practically vanished since picking several of these up. Have yet to test them in the Octane, though, but I assume any problems will be in the IP30 code and not tied to these devices or the Linux driver for them.
Yeah, the pl2303 adapters are junk. Realized only after having accumulated three or four of them that they were less than excellent. Promptly started transitioning to using the network interfaces on system controllers where appropriate (an HP iLO, a Sun ALOM), and I'm planning on making a couple more cables for my EL-16 to cover the rest of what I have hooked up via USB-serial adapters. My primary use-case is remote management of a stack of machines over a VPN, so the USB-serial bit was more of a hack to get things working than a real solution.
nyef wrote:
Unfortunately, the IP35 code conflicts a bit with the IP30 code, so merging things is a bit tricky.
Yeah, we still gotta work on that
Getting the IOC3 bits hammered out and upstreamed will simplify things a bit. I just got busy the last two months, and may do so again in the new year (but we'll see).
I'm wondering if it might not make sense for me to create an IP30 branch from my current IP35 tree and basically try to bring it up like a new port, cribbing liberally from your existing patch set.
?
