Linux: The ultimate VR4300 stress test.

[MarathonMan]

Code: Select all

[    0.000000] Linux version 4.2.4 (tyler@green) (gcc version 5.1.0 (crosstool-NG 1.21.0) ) #84 Sun Oct 25 01:36:01 EDT 2015
[    0.000000] CPU0 revision is: 00018000 (MIPS 4Kc)
[    0.000000] Determined physical RAM map:
[    0.000000]  memory: 0020e000 @ 00000000 (reserved)
[    0.000000]  memory: 001f2000 @ 0020e000 (usable)
[    0.000000] Wasting 16832 bytes for tracking 526 unused pages
[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x0000000000000000-0x00000000003fffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x00000000003fffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000000003fffff]
[    0.000000] Primary instruction cache 2kB, VIPT, 2-way, linesize 16 bytes.
[    0.000000] Primary data cache 2kB, 2-way, VIPT, no aliases, linesize 16 bytes
[    0.000000] Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 1016
[    0.000000] Kernel command line: console=ttyS0
[    0.000000] PID hash table entries: 16 (order: -6, 64 bytes)
[    0.000000] Dentry cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] Memory: 1904K/4096K available (1556K kernel code, 76K rwdata, 244K rodata, 160K init, 53K bss, 2192K reserved, 0K cma-reserved)
[    0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] NR_IRQS:128
[    0.000000] sched_clock: 32 bits at 250 Hz, resolution 4000000ns, wraps every 8589934590000000ns
[    0.000000] Console: colour dummy device 80x25
[    0.000000] console [ttyS0] enabled
[    0.000000] Calibrating delay loop (skipped) preset value.. 250.00 BogoMIPS (lpj=500000)
[    0.000000] pid_max: default: 32768 minimum: 301
[    0.000000] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.000000] futex hash table entries: 256 (order: -1, 3072 bytes)
[    0.000000] io scheduler noop registered
[    0.000000] io scheduler deadline registered
[    0.000000] io scheduler cfq registered (default)
[    0.000000] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[    0.000000] serial8250: ttyS0 at MMIO 0x0 (irq = 6, base_baud = 72000) is a 16450
[    0.000000] List of all partitions:
[    0.000000] No filesystem could mount root, tried: 
[    0.000000] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[    0.000000] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Hopefully, we will have N64 running Linux soon, at which point... we'll really be able to stress-test emulator CPU cores.

Still need a root filesystem, though...

[Narann]

Hopefully, we will have N64 running Linux soon, at which point... we'll really be able to stress-test emulator CPU cores.

Took me few second to be sure I was reading correctly! Awesome! 8-D

Would it be possible to use Everdrive-like cardrige to run this Linux (Cen64Linux)?

I would be very interested by more infos on your setup.

Did this has already been achieved in the paste?

So you mean we could run a linux (Cen64Linux) on a cycle accurate N64 emulator (Cen64N, N for Next!) on a desktop Linux (Linux Mint)?

Still need a root filesystem, though...

I've followed the NEO N64 Myth Menu dev few years ago (I have one. For a first N64 SD cartdrige it was very cool) and I remember it was kindof messy to handle File System stuff because of latency stuff.

Chilly Willy would have more interesting inputs with this.

Edit: Oups, you were talking about "root" filesystem! Is there not a possibility to put it into the 8MB of the N64?

Last question, how this would help you in your Cen64N project?

Anyway, this is a great news! Good job!

[MarathonMan]

Right now, it only boots in an emulator, but yes... that's actual output from a simulated serial port. The only thing stopped me from getting it to work on real hardware/a cart is a missing ELF loader (kind of like GRUB for N64...). That shouldn't be too hard to write, though... just parsing the header and copying data around.

I literally just cloned the Linux source tree, and wrote platform support/drivers for the N64, then compiled it. It really wasn't too hard, surprisingly... never done anything like this before. I only ran into a one bug with the TLB reload handler that I applied a giant hack to.

Technically, yes, you can put any Linux program on it that you compile with gcc. I wouldn't expect much, the kernel takes 2M between the code and data for something that's incredibly stripped down. A GUI won't be running on it anytime soon.

What I'd really like to do is write a block driver for the PI. Essentially, the console would see the ROM (or whole SD card, if a 64drive is present) as a block device. That way, you could put a filesystem on the cart and mount it and load files off it just like a PC...

How will it help CEN64? It'll be the ultimate torture/stress/regression test for the VR4300. Tells you really quickly if you messed up or not. Especially if I can get some SPEC CPU2006 apps or something running on there...

[Narann]

Right now, it only boots in an emulator, but yes... that's actual output from a simulated serial port. The only thing stopped me from getting it to work on real hardware/a cart is a missing ELF loader (kind of like GRUB for N64...). That shouldn't be too hard to write, though... just parsing the header and copying data around.

NEO N64 Myth rely on real cartdrige to boot. Meaning you plug a real N64 cartdrige, when the N64 boot it boot on it but the first executed lines are the ones present in the NEO N64 Myth.

I literally just cloned the Linux source tree, and wrote platform support/drivers for the N64, then compiled it. It really wasn't too hard, surprisingly... never done anything like this before. I only ran into a one bug with the TLB reload handler that I applied a giant hack to.

If your "hack" became nice, any hope to merge with master or is this illegal?

Technically, yes, you can put any Linux program on it that you compile with gcc. I wouldn't expect much, the kernel takes 2M between the code and data for something that's incredibly stripped down. A GUI won't be running on it anytime soon.

I'm not expecting a GUI but even a simple way to write/test RDP code on real hardware without relying on compile->copy to SD->plug->run->restart would be awesome.

What I'd really like to do is write a block driver for the PI. Essentially, the console would see the ROM (or whole SD card, if a 64drive is present) as a block device. That way, you could put a filesystem on the cart and mount it and load files off it just like a PC...

Not sure it would be such trivial. IIRC, the N64 have hard time dealing with low latency access memory. But I'm curious about potential results.
Being able to have a ssh'ed RPi as a dev/dump/debug board would be awesome! We still lack an easy way to develop with RCP. For example, there is no way to dump datas from N64 memory without relying on complex soldering or GameShark. I want to dump real RDP results with various modes to check the hardware accuracy of RDP emulation.

How will it help CEN64? It'll be the ultimate torture/stress/regression test for the VR4300. Tells you really quickly if you messed up or not. Especially if I can get some SPEC CPU2006 apps or something running on there...

Cool!

[MarathonMan]

I think I understand what you're saying about the NEO Myth. Even still, though, you need an ELF loader because the vmlinux image consists of headers and isn't a contiguous section of memory. There are blocks inside that need to be copied and moved to certain locations, etc. Fortunately, many such ELF loaders exist and even if you wanted to write your own, it's fairly trivial.

The hack will still hopefully still work on hardware. Stable enough to boot and use as a hobby anyways. I'll make the source public after I clean it up. It doesn't have anything specific to the N64 in it right now, and is mostly focused on the VR4300, so there's no reason why it should have legal issues stapled to it.

Totally agree with being able to link and run programs without the hassle of getting them on a cart, etc.

[Nacho]

That's amazing!

[asiga]

Another stress test would be the SGI Indy driver in MESS. Yes, it cannot boot IRIX nor Linux (the driver lacks much required functionality for that), but it does boot the PROM.

And, perhaps an even better stress test: GXemul, because it does run NetBSD on an emulated SGI O2. The O2 used the R5000, which has a mips4 instruction set, but maybe NetBSD is compiled for mips3, and in such case it should work.

If your VR4300 emulator works 100% fine on NetBSD running on an emulated MIPS-based computer, it would be quite an intensive test.