Re: Removing ARCNET stuffs
On Fri, 29 May 2015 12:22:40 +0200, Johnny Billquist wrote: > On 2015-05-29 08:18, Matt Thomas wrote: > > > > I have a Phase IV+ (so I didn't have to much with the physical address) impl ementation but never got around to writing the apps. socket interface is ident ical to DECnet-ULTRIX. DAP is a beast as is CTERM. I could run IP protocols o ver, but then I have IP for that. :) > > I never committed it because I doubted there was interest. Itâs probably > > bi t rotted but I could resurrect it. > > Well, me for one would be interested... > Mee too. It would not include LAT though, would it? Anders
Re: Removing ARCNET stuffs
Andrew Cagney skrev den 2015-06-01 03:24: systems and generates reasonable code. Unfortunately, and sorry PCC (stabs, really?), Feel free to add dwarf, the source is out there, and it wouldn't be especially difficult to do it. I just haven't had time. Stabs was "for free" :-) -- Ragge
xhci current status
Hello,
Thanks to Nick, my xhci patches has been applied to nick-nhusb
branch.
I summarise current problems I found.
Some of them are ongoing to solve, about some of them I have no idea
why they happen.
--
+ HS hub in 3.0 hub under 3.0 port is disconnected and reconnected every
several minutes repeatedly.
I don't know what is culprit yet.
+ Detaching hubs or devices might cause panic.
Especially when the hub that hangs many devices is disconnected.
+ KASSERT(sc->sc_command_addr == 0) in xhci_do_command() may fail.
If two or more threads run xhci_do_command(), all of them except one
should be blocked at mutex_enter. But one of blocked thread can get
sc_lock with sc_command_addr != 0 when cv_timedwait() unlocks sc_lock.
+ usbd_clear_endpoint_stall{,_async}() does not work on xhci.
To clear stall condition, RESET_ENDPOINT command shall be issued priorly
on xhci. Currently this is achieved by running
xhci_clear_endpoint_stall_async() in xhci_handle_event() if
command complete code is STALL.
+ xhci.c cannot handle cross-64k transfer yet.
(It works anyway though.)
+ Aborting xfer is not implemented.
+ Power management is not implemented.
+ Isochronous transfer is not implemented.
+ Stream protocol is not supported.
+ Fresco1100 does not report CSC if the device is connected at boot.
Only PortResetChange is set in change bits.
uhub ignores ports without CSC bit, so cannot detect the device.
+ Conexant CX93010 umodem is not recognized (XACT in ADDRESS_DEVICE).
It can be recognized when many debug messages are printed on console
or under hubs.
Thank you,
--
t-hash
Re: Removing ARCNET stuffs
On 30 May 2015 at 19:09, David Holland wrote: > The reason I floated the idea of forking is that an OS that's > specifically intended to be a high-quality Unix for older hardware can > make a different set of decisions (most notably, it can let C++ go > hang) and this allows avoiding a wide and growing range of problems > that currently affect NetBSD on old hardware. Meanwhile, it would also > (one hopes) allow retaining a critical mass of retrocomputing > enthusiasts in one place, as opposed to having them all gradually > drift away in different directions. Perhaps there are several, for want of a better phrase, "niche" plays here: - remove C++ from base; Since when was UNIX's system compiler C++ Instead there should be small fast modern C compiler that runs on all systems and generates reasonable code. Unfortunately, and sorry PCC (stabs, really?), this one currently doesn't exist, and no one seems to have the time to make it exist, sigh. This isn't to say that NetBSD shouldn't be cross-buildable using GNU or LLVM, just that the above be the default compiler. FreeBSD has clearly nailed itself to LLVM+LLDB and that means a C++ system compiler, and that, in turn means slow compiles on recent machines with lots of ram. And on a related note, the GNU tools - GCC, GOLD, GDB (https://sourceware.org/gdb/wiki/cxx-conversion) - which tend to be used here - are are now all also members of the C++ Borg (is it only time before binutils gets assimilated? :-) so if NetBSD does nothing, it will find itself being lead down FreeBSD's C++ path. (oh and please delete C++ groff, just replace it with that AWK script) - focus more on, and sorry for the marketing term, "scalability" That is being able to run things on smaller and larger systems. This means more focus to algorithms and choices, and less focus on burning ram like no tomorrow. - look at, cough, simulators, cough, as a way to test and develop for less mainstream architectures The build process is sick, figuring out how to get it running on QEMU, say, isn't. Can this work, consistently, across all platforms: qemu-system-XXX -nographic -kernel sys/arch/XXX/compile/QEMU/netbsd -cdrom releasedir/... -sd0 disk.img Andrew
Re: Removing ARCNET stuffs
Yes, I'm being hypocritical :-) On 31 May 2015 at 02:05, matthew green wrote: > > hi Andrew! :) > >> Who is appalled to discover that pc532 support has been removed! > > get your GCC and binutils and GDB pals to put the support back > in the toolchain and we'll have something to talk about :-) > note that we've revived the playstation2 port now that its has > had its toolchain components finally appear in mainline ... ;) Right. It takes time, effort and motivation to maintain code. Not people lamenting lost history :-) -- For reference, this is what I wrote in 2004, when starting the process of removing ns32k support when starting the process of removing NS32k support. It was two releases and roughly another year before the code was completely removed. It probably serves as a useful study given what is being discussed here - extra infrastructure to prop up dieing code just delayed the inevitable :-) * END-OF-LIFE frame compatibility module GDB's internal frame infrastructure has been completely rewritten. The new infrastructure making it possible to support key new features including DWARF 2 Call Frame Information. To aid in the task of migrating old configurations to this new infrastructure, a compatibility module, that allowed old configurations to continue to work, was also included. GDB 6.2 will be the last release to include this frame compatibility module. This change directly impacts the following configurations: h8300-*-* mcore-*-* mn10300-*-* ns32k-*-* sh64-*-* v850-*-* xstormy16-*-*
Re: Removing ARCNET stuffs
Antti Kantee wrote: > On 31/05/15 06:05, matthew green wrote: > > hi Andrew! :) > > > >> Who is appalled to discover that pc532 support has been removed! > > In addition to toolchain support, the hardware was near-extinct at the > time of removal. > > Now, the hardware is no longer near-extinct: > http://cpu-ns32k.net/ > > I used the FPGA pc532 running NetBSD 1.5.x(?) a few weeks back. > Unbelievable experience, especially since I spent quite some time and > effort trying to get a pc532 I had on loan 10+ years ago to function. > > > get your GCC and binutils and GDB pals to put the support back > > in the toolchain and we'll have something to talk about :-) > > Didn't know that things to *talk* about were short in supply... > I was looking for the so called open-source resources of pc532. Can we put it somewhere on the web again? Last time I was checking (not so long ago) and they were off-line. At the moment I'm focused on acorn26, I obtained RISCOS. This port should be saved to put fun into the computing. I work at work with newer ARM CPUs, but the basic ideas are the same in ARMv2/v3 (IRQ, FIQ, RISC, etc) - this isn't only fun but also good for learning - even though I will be just in the platform emulator. Personally (sorry for this) I don't like pcc, so I started clank [1], a clang/llvm clone in plain C with the goal of minimal possible footprint, supporting exclusively the C language, being portable (-lnbcompat) and with interchangeable with clang/llvm compiler parts - being as close to the original as possible to track upstream... I want to save sun2, deC++ base (as the MK option) and in general get acquainted with the llvm internals. This is rather long-term project just in a spare time. Lost of time? Probably, but even in this very early stage I can catch places for enhancement in the big-brother clang/llvm [2]. David, forking NetBSD? Usually teams are more powerful than individuals and they win at end. Forks are valuable only then when they will attract new people and submit patches back to upstream -- this is a relation between DragonflyBSD and FreeBSD. There is also EdgeBSD [3] a good project to prototype features in git. I can see a market share in desktops, I belive we need better support for recent DE, graphical installer (calamares.io is my choice for a NetBSD livecd with preinstalled packages). As someone already stated, if we aren't on desktops we aren't anywhere else. I saw that companies put Ubuntu (ubuntu-core) even on your PCI peripherals, just because people are familiar with this system. This is the reason why I'm for winning back desktop. What to do to make the project easier for newcomers - from a stand point of a new wannabe developer? Improving the contribution platform - well, I am aware of the fact that people are used to the same techniques like in nineties and have the standards set in stone. I can see the following problems: - no central location for patches -- several mailing-lists, PR, private-mails.. - no way to track pending patches -- except pinging developers.. - no standard patch format - extra work on developers to maintain it My proposition is (expressed already before) to set official GitHub mirror and accept there patches and issues at dedicated git branches. I almost stopped to contribute my patches to projects if they are outside GitHub, mailing lists are extra burden to register an account, track traffic, spam and general noise. With the GitHub platform the cost of maintainership will be higher on start and quite low later. No need for extra internal infrastructure except scheduled cvs2git script. [1] https://github.com/krytarowski/clank [2] http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150209/258953.html [3] http://edgebsd.org/
Re: Removing ARCNET stuffs
On 31/05/15 06:05, matthew green wrote: hi Andrew! :) Who is appalled to discover that pc532 support has been removed! In addition to toolchain support, the hardware was near-extinct at the time of removal. Now, the hardware is no longer near-extinct: http://cpu-ns32k.net/ I used the FPGA pc532 running NetBSD 1.5.x(?) a few weeks back. Unbelievable experience, especially since I spent quite some time and effort trying to get a pc532 I had on loan 10+ years ago to function. get your GCC and binutils and GDB pals to put the support back in the toolchain and we'll have something to talk about :-) Didn't know that things to *talk* about were short in supply...
Re: Removing ARCNET stuffs
On 31 May 2015 at 00:09, David Holland wrote: > I'm saying that, fundamentally, if you want to run gcc4 or gcc5 on a > Sparc IPC that you're going to have problems. There is no way around > this, except maybe to float a new compiler with the specific goal of > both being modern and running on 25-year-old hardware. (That's an > enormous project.) I think pcc is currently the only realistic solution, but it still needs a lot of work, and we would want to do this without compromising support for gcc/clang, so it means fixing pcc, as well as adding more architectures. (I would be happy with a no c++ base system to support this). pcc has come a long way, and we could get to a pcc base system for some architectures for 8.0 I think. Justin
