has anyone tested the mainline kernel n64 support?

[jshield]

I can get the clbr/linux n64 branch to build and boot using a recent mips64 toolchain, can't seem to get anything more recent to boot, it never gets to a point where the console is initialized. and I can't see any evidence of dmesg in memory.

does anyone have a working config/toolchain?

Cheers,

[clbr]

I tested the upstream kernel after everything was merged (config in this repo), but haven't tried more recent kernels.

[jshield]

cheers, so far I have managed to get the bootloader compiling against the latest libdragon, with a few changes to cover changes to cache invalidation needing to be aligned to 16-byte chunks and can get that to boot a kernel built against your repo in ares, the n64cart fails to mount for reasons I haven't investigated, as far as I can tell the offsets are correct. using the bootloader you built does work (gets to joyterm) for either my build of the kernel or the one that was distributed, so it's clearly a difference in the way libdragon initializes the hardware or the changes to the cache invalidation.

I couldn't get the upstream kernel to boot, I saw you replaced the custom n64rdp driver with some code in init.c to setup simpleframebuffer, but otherwise everything besides some config details don't appear to have changed significantly, it manages to reset the display to black and appears to do nothing, scanning the memory it doesn't appear to even reach early console stage, as I can't find any evidence of the dmesg buffer being populated.

I was hoping to extend ares to emulate some of the common dev carts to start working on drivers for them, in particular enabling direct access to the SDRAM backing the cartridges so I can modify the block driver to be used as a swap device/ramdisk and add in SD card support for mounting rootfs off that.

you wouldn't happen to have a binary I can test of your last working config?

cheers,

[clbr]

Sorry, the only binaries are the ones already posted.

There is no dmesg buffer, at least early on. The early messages go out directly, one char at a time. IIRC during dev I edited the emulator to make some mem address special and had the early prints go to that, then the emu passed them on to the terminal it was running in.

[jshield]

ah yep, that makes sense, I suspect I may have to implement the FIFO part of a dev cart now, so I can do that exact thing.

hmm actually Ares has the ISViewer-64 mapped on its cartridge, so early console could probably log to that as a ring buffer.

Thanks for the advice.

[jshield]

status update:

• Got early printk output by implementing a simple prom_putchar that passes output to "IS Viewer-64" in Ares
• N64s modded with 16Mb RDRAM should work now.
• Managed to sort out n64cart issues and can boot your linux kernel repo to joyterm with my updated bootloader code
• 5.15.85 boots far enough to launch init but fails to mount n64cart, potentially related to refactoring and changes made since initial upstreaming
• 6.1.1 crashes out completely looks like it gets stuck in a loop writing garbage to increasing memory addresses
• haven't tested 6.0

IS Viewer-64 Log: [    0.000000] Linux version 5.15.85-n64 (jshield@vm-js-wrk-001) (mips64-linux-gnuabi64-gcc (Ubuntu 10.3.0-1ubuntu1) 10.3.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #1 Thu Dec 29 06:04:14 UTC 2022

IS Viewer-64 Log:  [    0.000000] printk: bootconsole [early0] enabled
IS Viewer-64 Log:   [    0.000000] CPU0 revision is: 00000b22 (R4300)
IS Viewer-64 Log:  [    0.000000] FPU revision is: 00000b00
IS Viewer-64 Log:    [    0.000000] Initrd not found or empty - disabling initr
IS Viewer-64 Log: [    0.000000] Primary instruction cache 16kB, VIPT, direct mapped, linesize 32 bytes.

IS Viewer-64 Log: [    0.000000] Primary data cache 8kB, direct mapped, VIPT, cache aliases, linesize 16 bytes

IS Viewer-64 Log:   [    0.000000] Zone ranges:
IS Viewer-64 Log:    [    0.000000]   Normal   [mem 0x0000000000000000-0x0000000000ffffff
IS Viewer-64 Log:   [    0.000000] Movable zone start for each node
IS Viewer-64 Log:    [    0.000000] Early memory node range
IS Viewer-64 Log: [    0.000000]   node   0: [mem 0x0000000000000000-0x0000000000ffffff]

IS Viewer-64 Log: [    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000000ffffff]

IS Viewer-64 Log:  [    0.000000] Built 1 zonelists, mobility grouping off.  Total pages: 4040
IS Viewer-64 Log:   [    0.000000] Kernel command line: n64cart.start=2956566528 n64cart.size=864256
IS Viewer-64 Log: [    0.000000] Dentry cache hash table entries: 2048 (order: 2, 16384 bytes, linear)

IS Viewer-64 Log:   [    0.000000] Inode-cache hash table entries: 1024 (order: 1, 8192 bytes, linear)
IS Viewer-64 Log:   [    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
IS Viewer-64 Log:   [    0.000000] Memory: 13760K/16384K available (1741K kernel code, 159K rwdata, 192K rodata, 128K init, 95K bss, 2624K reserved, 0K cma-reserved)
IS Viewer-64 Log:  [    0.000000] NR_IRQS: 8
IS Viewer-64 Log: [    0.000000] clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 40773556198 ns

IS Viewer-64 Log: [    0.000023] sched_clock: 32 bits at 46MHz, resolution 21ns, wraps every 45812984821ns

IS Viewer-64 Log:   [    0.002426] Console: colour dummy device 40x30
IS Viewer-64 Log:  [    0.002976] printk: console [tty0] enabled
IS Viewer-64 Log: [    0.003495] printk: bootconsole [early0] disabled

[jshield]

further followup, a recent change in MIPS land between 6.0 and 6.1 regarding rngseed, means that passing a rngseed value in via the environment is needed at boot, otherwise it appears that it hangs trying to fw_getenv("rngseed") and ends up writing garbage everywhere.

[clbr]

https://lore.kernel.org/lkml/20221001160910.GB13443@alpha.franken.de/T/

fw_getenv should return NULL gracefully according to that patch.

[jshield]

yeah I saw the commit but hadn't looked at LKML yet, I had added some debugging info and it appeared to never get past fw_getenv, I've added passing in rngseed derived from the kernel size and the disk size in the short term and it boots to that point, asking a couple of N64 devs about sources of randomness that might be a little more reliable.

on a side note, I've added preliminary support for the RandNet 64 keyboard over the joybus, and the N64 mouse.

I've also added support for detecting https://github.com/Polprzewodnikowy/SummerCollection/ and using part of the SDRAM as a swap disk.

switched to cramfs, since we aren't likely to need anything more than 256Mb of root, and since multiuser is compiled out, it appears to be a better choice (smaller kernel, less kernel memory footprint)

[clbr]

Consoles generally don't have any other randomness source than the user. Meaning it's not useful to pass any seed from the rom, interrupts caused by user activity is as good as it can be.

(please don't edit the posts, it gets hard to see what is new if I visit after an edit...)

[jshield]

yeah apologies for the edit, seems that passing in the NULL env no longer passes muster, however it is happy with an empty rngseed env var. not sure if that is a bug in the fw_getenv, or if atleast with respect to MIPS platforms the N64 bootloader was the only one to pass an empty env in.

[jshield]

passing a NULL value to env on the entry point also boots so it looks like fw_getenv can't handle an empty but valid env pointer.

[FlyGoat]

Fixed in upstream kernel with torvalds/linux@ee1809e