cakehonolulu

Aha! You got me ;)

Banter aside; I was basically on a tunnel-vision/nerd-snipe/however you want to call it to get it to run; GCC report is still coming. It’s just that I’ve never sent out (a report) to them (gcc) and wasn’t really sure how to proceed (Even though they give out a pretty step-by-shep guide) so I wanted to finish the bringup and then try to make some easy reproduction code (That’s not compiling Linux, that is).

I actually have a comment on GH from one of the many cool people that’s (I think?) maintaining the GCC backend for SuperH.

TL;DR: It’s coming.

It does require an MMU technically, this kernel is built with that in mind but I see no mention of uCLibc whatsoever on the kernel log (Or that I remember out of all the files I saw open). I’ll see if I can pinpoint exactly what it is.

I was actually thinking, if memory is the bottleneck; I could always go with the Saturn instead (Or find a way to have the 32X catridge writes go through…; but I’m no EE unfortunately).

I do recall having a RAM expansion cartridge in mine that could possibly be used to fit more stuff if the main 2MBs it had were too little to hold Linux.

You got me thinking…

Ah, that'd be it then; it would've been such a cool experiment.

Regardless, I don't really know if there's the notion of an SMP-enabled m68k board based on Linux so I would not really know where to start.

For SuperH, I've gotten very lucky because there's a single CPU subtype (J2, https://j-core.org/) which has SMP tidbits that helped me understand what to look for and where in terms of wiring the 32X's CPU subtype.

I actually didn't know the THUMB thing; pretty interesting stuff...

The branch delay slots/load delay slots thing was also something that plagued some MIPS processors back then too; 5th generation of consoles (At least, from Sony, Nintendo and Sega) had either all or a subset of those quirks on their flagship machines.

Hi! Nice to see you here.

Yes so, this was tested within a software context; the ASIC that does the bus arbitration on the side of the 32X has some of the required pins as N/C. They do a much more interesting deep-dive on the link you added.

I initially thought the 68000 side /UWR & /LWR pins were wired to the complimentary 315-5818 ones (Since there wasn't any apparent difference between the pinouts of both).

This makes the setup a bit different since you'd not be addressing the cart's PSRAM, but instead, the 32X's SDRAM. With XIP (Like on the Jaguar port) you could probably pull it off (Not sure if you'd be able to cram the entire Busybox environment but maybe a small program could do it).

Good thing is, this is actual Linux (And not uCLinux) so there's still stuff that can be disabled further if for some reason it can't fit still on the available memory.

That was something I also noticed; I can't say for sure (Since I haven't yet checked) but I feel like I may have done something incorrect when wiring the FRT (The timer) to the secondary, smp-enabled SH2.

The BogoMIPS value is derived from a calibration that Linux does against the timer of choice so it could very well be a reason why.

Not a silly question actually.

There's really clever ways you can get down to scratch that space-saving itch; I'm not knowledgeable about it either (I'm just really bad when it comes to analog signals) but if you really, really needed to shave off even more stuff; I reckon that the video console driver could possibly be reduced to something far more esoteric (That'd need signal processing to get tangible output of). But at that point, just use UART (Which is simple-enough already and should not really starve you out of much memory).

Hi!

Honestly, no idea if Krikkz's Extended SSFv2 is even implemented on MiSTer. I'd have to check but considering the rarity of it I'd be surprised if it was there.

Porting Linux to SH3 is surely easier than what it has been for SH2 (SH7604, more precisely); and considering it has 512MB of RAM you probably can just get away with a non-stripped to the bones Linux image (And initramfs, of course). It surely sounds like a good playground.

It's kinda like "Running DOOM on x"

Hi! I'm basically forwarding UART data from the SH2s over to the M68K using a simple communication channel. Since the SH2s don't really have "direct" access to the Genesis's I/O port (They have TTL UART which caps at 4800 bps) I need this precise schema to have output. Technically speaking it should be simple enough to wire RXD too so you can interact with it. I saw some keyboard prototypes for the Genesis online (Which seem to use the Joypad ports) but I figured no one would have them so why bother writing a driver for it (Which again, would add more complexity to the M68K dispatcher; which does UART and acts as an INTC "master" to forwards IPIs between the 2 SH2s).

As to the Sega CD; it'd probably be cool but this is already super-slow as it is (There's lots of bus contention already from 2 x SH2s and 1 x 68000) so yeah.

Maybe a cool project would be SMP for the 2 68000s (Sega CD + Genesis) but I'm not even sure if there's any form of SMP available for arch/m68k in Linux (If both 68000s are wired you could maybe get away-ish with some simple bringup but can't really say for sure).

After testing the waters with a Linux for Jaguar port; I basically set myself to get similar results on the 32X add-on for the Sega Genesis. Turns out that, even without hardware synchronization primitives, you can get smp-ready Linux: https://github.com/cakehonolulu/linux_ports

Do you happen to be fifteenhex?

Hi! Glad you liked it.

In theory it should be possible I think?

I don't exactly recall the memory differences (Chip RAM vs Fast RAM and all that) but assuming you have enough Chip/Fast RAM and thereabout of a megabyte in a storage medium for the actual kernel binary; I don't see why it should not be possible.

If WHDLoad is a thing on base 500/500+ then you'd be able to fit more stuff on the "userspace" side of things, since 1.44 megs can't really hold much (And having to swap floppies in the way Workbench does it is not something I'm sure can be done on Linux).

The main issue I see is that you'd probably need to "free" up memory by unloading Workbench (If it's loaded) and possibly re-configuring the hardware (So it's in a known good state for Linux), but yeah; it should honestly be feasible.

Hi! Thanks for all your work honestly, I saw the patches and most (If not all...) were necessary to boot the kernel.

As for the mainline stuff: Sure! May I reach out to see how I can help?

Anytime!

As for 80 columns... I'd probably need to choose a different (Narrower) font. With a bit smaller font I reckon it should be feasible to have it (Since current one has 8x8 glyphs).

Thanks! Glad you enjoyed it!

I basically wrote them down as they came to my mind, but I agree. I'm still waiting to find a decently priced Falcon 030...

Absolutely! You could possibly develop a custom mapper that provides extra RAM (I guess memory bank switching would need to happen) plus the ROM but as far as I'm aware it's not available.

I'm awaiting some screenies from a peer that has the flash cart for the Jaguar; don't worry, they'll get added! I have both the Jaguar and the Jaguar CD but don't have the flash cart...

Ah yes, I'm more worried about the actual limits of what the combination of Linux + the initramfs can let us do (Memory wise, mostly).

In theory it should be feasible but I'm not too sure how you'd "adapt" the way of doing things within Linux; the environment is very limited and I can't think of a way to cleanly make the Tom more "accessible" (While again, Tom is already executing the object lists to drive the Linux console). Doesn't help that it'd need additional afterthought not to trip it up with one of the many hardware erratas both Tom & Jerry had...

I think it could be feasible (Like, embedding the utils), but I'm not too sure how I'd handle the "upload" of the RISC code for the Tom (While at the same time it's driving the Linux console) and similar...

Not that I blame you... in comparison with pretty much the rest of cartridge-based systems, the available flash cart is priced higher (And AFAIK no DIY open-source ones exist). AvP is one of the best games to play on the system, it was future technology at the time it came out.

I've actually thought of that, but the memory space is so limited that I feel it'd be impossible. Also considering the fact that no official memory banking solutions exist for the Jaguar... maybe it'd be an interesting technical challenge to have a custom mapper that can do both ROM and RAM.

Hi! Thanks! Though' I must say that it also helped lots that there's still m68k (Heck, even base 68000) arch code on upstream Linux...!

About a minute and a half. It varies by 2~ seconds at most. Could possibly be related to how Linux does the calibrate_delay() stuff? (And well, I'm also not too sure on how deterministic it's supposed to be in terms of time).

This is a deep dive on what is necessary to get Linux on the 68000-based Atari Jaguar. No specialized hardware/flash carts. All runs within the original hardware vision (2 megabytes of RAM) and gets to a Busybox shell. Linux repository with the changes: https://github.com/cakehonolulu/linux_jag

Unfortunately not with PCIem... I don't know how the XNU kernel does PCIe stuff; maybe something can be done there with a Kext module but no idea.

Highly interesting! I kinda wanted not to rely on QEMU as a default "end" for the emulation (As in, I want the end user to be able to choose whatever userspace shim/transport layer/thing they want), but for some of my tests I did forward accesses to QEMU itself (And worked wonders). Thanks for that link! Super cool stuff!

Hi!

PCIEM_EVENT_MMIO_READ is kept for reference on the while (head != tail) loop just to remind the user that there can be more than 1 event registered in terms of access type.

Let's say that you register your watchpoint in READ mode (I still have to change the IOCTL for that as currently is hardcoded for writes: attr.bp_type = HW_BREAKPOINT_W), then you'd be consuming PCIEM_EVENT_MMIO_READ events instead of PCIEM_EVENT_MMIO_WRITE.

The fact that the PCIEM_EVENT_MMIO_READ define is there is to help me remind me to incorporate that missing logic.