Live data from Hacker News

New Linux port for the Nintendo 64

lore.kernel.org

161–170 of 205 posts

Re: New Linux port for the Nintendo 64

#161

Earlier quoted context omitted.

> By the way, you wouldn't find any routers running a meger 512KB of RAM. This is not true in general, although true for modern devices. There are older router models that cannot run linux. A few years back I unsuccessfully tried to flash a very minimal > We are just pointing out that you massively misunderstand how micro kernels work If someone points out, that linux kernel can be reduced in size and that there are…

> This is not true in general. There are older models that which cannot run linux. A few years back I uncessfully tried to flash a very minimal How long ago was "a few years ago"? What model number was that? DD-WRT has been ported to the Archer series but if you're talking a ZyNOS based router then you're probably out of luck. Those ZyNOS devices are the real bottom end of the market though. Even the ISP routers here…

> How long ago was "a few years ago"? What model number was that? DD-WRT has been ported to the Archer series but if you're talking a ZyNOS based router then you're probably out of luck. Those ZyNOS devices are the real bottom end of the market though.

This brings back memories :) http://www.ixo.de/info/zyxel_uclinux/ Sure, we are talking about low-end (real bottom) devices and date models here. I cannot recall the model number, but I think we both agree that routers that cannot run linux exist, although not very common (anymore).

> Any OS designed around kernels, memory safety etc would be useless in general for constrained devices.

How about QNX then?

"QNX is a commercial Unix-like real-time operating system, aimed primarily at the embedded systems market. QNX was one of the first commercially successful microkernel operating systems. As of 2020, it is used in a variety of devices including cars and mobile phones." - https://en.wikipedia.org/wiki/QNX

They are "aimed primarily at the embedded systems market", their latest release is from "7.1 / July 2020; 5 months ago" and they are operating their business model since 1982.

Re: New Linux port for the Nintendo 64

#162

Earlier quoted context omitted.

> This is not true in general. There are older models that which cannot run linux. A few years back I uncessfully tried to flash a very minimal How long ago was "a few years ago"? What model number was that? DD-WRT has been ported to the Archer series but if you're talking a ZyNOS based router then you're probably out of luck. Those ZyNOS devices are the real bottom end of the market though. Even the ISP routers here…

> How long ago was "a few years ago"? What model number was that? DD-WRT has been ported to the Archer series but if you're talking a ZyNOS based router then you're probably out of luck. Those ZyNOS devices are the real bottom end of the market though. This brings back memories :) http://www.ixo.de/info/zyxel_uclinux/ Sure, we are talking about low-end (real bottom) devices and date models here. I cannot recall the m…

> This brings back memories :) http://www.ixo.de/info/zyxel_uclinux/ Sure, we are talking about low-end (real bottom) devices here.

So not just low-end, but a decade old device that was already low-end upon it's release. That's hardly a fair argument to bring to the discussion.

> How about QNX then?

QNX wouldn't run on something with Sure, if you want to strip out graphics libraries and all the other stuff and just run it as a hypervisor for your own code you could get those hardware requirements right down. But then you're not left with something POSIX compliant, not even useful for the N64. And frankly you could still get a smaller footprint by rolling your own.

The selling point of QNX is a RT kernel, security by design and a common base for a variety of industry hardware. But if you're writing something for the N64 then none of those concerns are relevant (and my earlier point about a resident OS for the N64 being redundant is still equally valid for QNX).

Also smart phones are neither embedded nor "constrained" devices. I have no idea what the computing hardware is like in your average car but I'd wager it varies massively by manufacturer and model. I'd also wager QNX isn't installed on every make and model of car either.

* I should caveat that by saying, yes it's possible to write something partially POSIX compliant which could target really small devices. There might even be a "UNIX" for the C64. But it's a technical exercise, like this N64 port of Linux. It's not a practical usable OS. Which is the real crux of what we're getting at.

Re: New Linux port for the Nintendo 64

#163

Earlier quoted context omitted.

> How long ago was "a few years ago"? What model number was that? DD-WRT has been ported to the Archer series but if you're talking a ZyNOS based router then you're probably out of luck. Those ZyNOS devices are the real bottom end of the market though. This brings back memories :) http://www.ixo.de/info/zyxel_uclinux/ Sure, we are talking about low-end (real bottom) devices and date models here. I cannot recall the m…

> This brings back memories :) http://www.ixo.de/info/zyxel_uclinux/ Sure, we are talking about low-end (real bottom) devices here. So not just low-end, but a decade old device that was already low-end upon it's release. That's hardly a fair argument to bring to the discussion. > How about QNX then? QNX wouldn't run on something with Sure, if you want to strip out graphics libraries and all the other stuff and just r…

> So not just low-end, but a decade old device that was already low-end upon it's release. That's hardly a fair argument to bring to the discussion.

Fair enough, I agreed that I should have come up with an better example. But before going down another rabbit hole, just replace router with any modern embedded chip you like, that cannot run linux as example.

Regarding QNX, I don't know their current requirements but what impresses me:

"To demonstrate the OS's capability and relatively small size, in the late 1990s QNX released a demo image that included the POSIX-compliant QNX 4 OS, a full graphical user interface, graphical text editor, TCP/IP networking, web browser and web server that all fit on a bootable 1.44 MB floppy disk."

> I should caveat that by saying, yes it's possible to write something partially POSIX compliant which could target really small devices.

Yeah, I think here's a interesting overview of some http://www.microkernel.info

I wonder how many of them are POSIX compliant (or partially) and what their requirements are. GNU/Hurd certainly is.

Re: New Linux port for the Nintendo 64

#164
post #148

Earlier quoted context omitted.

Really, the term "micro" is about size, not functionality. The fact is, the Linux kernel can be compiled with features to suit constrained environments. It is just that these features are determined at build time, not run time.

Yes, that is true but there are limits as I've explained here: https://news.ycombinator.com/item?id=25544271 Also quite interesting this question already came up on Quora https://www.quora.com/What-is-the-smallest-in-size-Linux-ker... and also on many other websites: https://superuser.com/a/370588

Your argument doesn't make any sense. You are saying microkernels are more modular in feature selection than monolithic kernels. That is not an inherent property if microkernels, nor is it true in practice. Nothing says a monolithic kernel can't have much more fine grained build time feature control than a microkernel where only entire services can be disabled (by not running them). Any reasonable monolithic kernel targeting embedded systems, including Linux but also anything smaller, will have a ton of build time options to slim down the system as needed.

A microkernel with feature control at the process/service level would actually have much worse feature control than Linux, because Linux build time configuration options are often quite a bit more finer grained than that. For example, you can build Linux for uniprocessor systems, which makes global build-time changes that disable certain kinds of locks, which makes it smaller globally. A microkernel could or could not have the same build-time feature; it is not guaranteed to.

As others have pointed out, microkernels have performance overhead and that reason alone makes them unsuitable for an N64. On a game console you need all the performance you can get.

Re: New Linux port for the Nintendo 64

#165

This is, of course, cool. No doubt. I have an EverDrive 64 and I’ll probably test this out later today or tomorrow. I am skeptical that this would be the preferred way to port emulators or graphical games. You’re not getting a budget SGI workstation out of this, because the OS kernel itself is only a small part. The N64 is built around a chip called the Reality Control Processor, or RCP. This contains the RSP, stripp…

> This is the hard part of programming the N64, and it’s not something that’s addressed by swapping out the OS kernel.

On the other hand , this might massively improve the turnaround time on RSP programming (which is something I've actively been trying to learn), since it'll be that much easier to edit and run microcode without having to bake entirely-new ROMs in the process: I'd just need a serial console (or even a framebuffer console on top of whatever the RSP's rendering) and an assembler (or, at the very least, something to turn hexadecimal input into binary data to DMA over - we're only talking 4K each of code and data here, after all).

Re: New Linux port for the Nintendo 64

#166

Earlier quoted context omitted.

That's more than plenty. (It won't be running Gtk4 or Qt6 of course.)

Check out this article on the project: https://www.phoronix.com/scan.php?page=news_item&px=Nintendo... > It's also noted that Linux on the Nintendo 64 is still a big buggy and "constantly flirting with [out of memory]." If you're running out of ram with just a shell that definitely doesn't leave much left. And there's no storage device, so you can't swap.

> And there's no storage device, so you can't swap.

There's the cartridge. And yes, while technically that's supposed to be ROM, flashcarts like the EverDrive are able to get creative with that, and I can see that being a viable pathway to achieving something approximately resembling swapping.

Re: New Linux port for the Nintendo 64

#167
post #5

> "But why", I hear from the back. Having Linux available makes it easier to port emulators and fb or console games. > Most importantly, because I can. Good. All I can say is at least it is something different to what I keep seeing on HN. (React, Rust, Kubernetes, JAMstack, JavaScript, etc.) Probably present this somewhere in a conference (CCC, FOSDEM, etc). Who knows who could be looking at this.

Have you noticed any change in those patterns since the Christmas vacations began around Dec 19th?

Re: New Linux port for the Nintendo 64

#168

Earlier quoted context omitted.

> That’s a different argument to the one you opened with. "A microkernel would be a good fit for such constrainted environments." No, that's exactly my argument. My argument is that the linux kernel (even if you strip everything out and create the most tiny linux kernel) is still too big for many constrained environments, e.g. a old router with 512 KiB memory (there are many devices that cannot run linux). However, i…

> "A microkernel would be a good fit for such constrainted environments." As the GP said, micro kernels have a performance overhead swapping data between rings. That overhead would bite hard on something running a NEC VR4300 clocked at 93.75 MHz. A monolithic kernel is the way to go. Just not Linux specifically. > My argument is that the linux kernel (even if you strip everything out and create the most tiny linux ke…

Nintendo actual devices use microkernel based designs.

We are way past the usual FUD against microkernels.

Re: New Linux port for the Nintendo 64

#169
post #150

Earlier quoted context omitted.

> Linux is the obvious choice for most... but the GPL licensing makes it very difficult for a lot others Linux stayed on GPL2 instead of upgrading to GPL3 precisely to allow others freely using Linux in their commercial devices. In other words: they made the intentional choice of making it legally easy to embed Linux in proprietary hardware products (aka. Tivoization , which GPL2 allows but GPL3 forbids)

That's true. GPL2 is better for commercialization than GPL3 is. However, BSD, MIT, Apache are much much better than any GPL version, including AGPL.

Yeah PS4 has done wonders to upstream FreeBSD.

Re: New Linux port for the Nintendo 64

#170

Earlier quoted context omitted.

Yes, that is true but there are limits as I've explained here: https://news.ycombinator.com/item?id=25544271 Also quite interesting this question already came up on Quora https://www.quora.com/What-is-the-smallest-in-size-Linux-ker... and also on many other websites: https://superuser.com/a/370588

Your argument doesn't make any sense. You are saying microkernels are more modular in feature selection than monolithic kernels. That is not an inherent property if microkernels, nor is it true in practice. Nothing says a monolithic kernel can't have much more fine grained build time feature control than a microkernel where only entire services can be disabled (by not running them). Any reasonable monolithic kernel t…

The problem is that you can only slim down linux so much. If the tiniest possible linux does not fit on your chip, then it simply does not fit, end of the story for linux in this case. However, there are tiny microkernels e.g. with less than 50.000 lines of C code that can fit on such a device + leave some room for a small application e.g. also smaller than 50.000 lines of C that also fits. This is all I want to say. And yes, I agree with all the other points/drawbacks including performance that people mention here.
Post reply on HN