theres a big performance difference - particularly on arm

And I also want to challenge myself and go through debugging hell to make something work.

yeah thats definately aros development lol

the lack of decent debugging tools has long been a thorn in our side

qemu has a gdb stub that can be used. unfortuately, it's a pain in the ass when you have dynamically loaded elf files, and like I discovered, it sucks at emulating real hardware for driver development.

Looks like the only device I seem to be able to enumerate is the onboard ethernet adapter. I keep getting transaction errors trying to send setup packets to my keyboards and mice. I hate this thing. I get errors, and it's nearly impossible to find out what's wrong.

Why do the virtual root hubs for XHCI and EHCI have bProtocol set to 0? https://github.com/aros-development-team/AROS/blob/master/rom/usb/pciusbhc/xhci/pcixhci_commands.c#L150 According to the USB spec, a value of 0 there means that the hub only supports full speed and low speed.

This message was deleted.

https://github.com/aros-development-team/AROS/tree/master/rom/usb/pciusb is the correct driver

ah

huh, KPrintF doesn't accept %i, but %d works.

What's the recommended way to delay for a certain time? This doesn't appear to be working. https://github.com/NinjaCowboy/AROS/blob/rpi-native/arch/arm-native/soc/broadcom/2708/usb/dwc2/dwc2.c#L313

Oh, I forgot OpenDevice

@Fabian Schmieder hi, nice to see you

Really great to see raspi 5 support, do you have lot of work left you haven't comited yet?

I'm also curious how you dealt with x18 register in the mac hosted PR.

Not that much: File: rom/exec/openlibrary.crom/exec/opendevice.c Fix: SMP race / deadlock: Replaces EXEC_UNLOCK_LIST with EXEC_UNLOCK_LIST_AND_PERMIT. Prevents deadlocks on multicore systems (RPi4/5, x86 SMP). File: rom/graphics/setfont.c Fix: NULL pointer crash: Guards against a crash on SetFont(rp, NULL) and restores the DefaultFont in a standards-compliant way. File: workbench/c/Shell/Shell.c Fix: Background shell fix: Prevents cli_Background from being overwritten by IsInteractive() in background processes (e.g. via RunCommand). File: workbench/devs/AHI/Drivers/RPiI2S/ Fix: I2S audio DAC HATs: AHI driver for external I2S sound cards (HiFiBerry DAC, IQaudIO, PCM5102A, MAX98357A) on RPi4 (GPIO 18-21) and RPi5 (RP1 I2S).

I have a lot of SMP work waiting to be merged, but still only for ARM (not aarch64 yet) so that will probably not interfere with your work. But you haven't touched the graphics drive right? (other than the vc6 gallium)

Reason I'm asking is that I want to avoid us doing the same thing

nope...left gfx alone besides gallium.

I saw that you have added an nvme driver as well, does that work with 500+ built-in in nvme storage?

Didnt test it with 500+ - but it should. I could try it out; bought a 500+ some weeks ago and never found time to run it.

BTW: I did a lot of testing of my own RPi4 port with QEMU which worked really good; I found a few pitfalls and documented it; should I PR that doc?

@Fabian Schmieder I'm currently also working on an ethernet driver for the raspi 4 btw

@Fabian Schmieder which toolchain do you use?

Hello @Fabian Schmieder, it’s really good to see more people working on hosted AROS for Apple Silicon. I’ve been working on the same target for some time as part of Macaros, with the AROS-specific changes kept in AROS-AArch64. Macaros remains a hosted system, but its display and input implementation has developed into a fairly complete Cocoa/Metal host: dynamic display modes, resizing, fullscreen, Retina scaling, keyboard modifiers and keymaps, wheel input, clipboard sharing, menus, settings, diagnostics and control tooling. It would be great if you could look through my implementation and share your thoughts. There is considerable overlap, but the architectures differ: your backend is integrated directly into

AROSBootstrap

and

HostInterface

, while ours keeps the macOS host behind

hostlib.resource

and a versioned dylib interface. It would be useful to discuss which parts should converge upstream and which should remain Macaros-specific. There are also a few details in the merged patch that may deserve another look: •

cpu_aarch64.h

now refers to

regs.r

and

regs.pstate

, while the current AArch64

ExceptionContext

uses

x

and

cpsr

. • The change appears to remove the per-task FP/NEON storage and initialisation used to preserve vector state across task switches. •

cocoa_display.m

is added as a linker object, but I could not find the corresponding Objective-C compilation rule. • macOS normally reports Shift, Option and Command changes through

flagsChanged:

, rather than ordinary `keyDown:`/`keyUp:` events. • After resizing, pointer coordinates need converting from the scaled window coordinates back to the fixed guest framebuffer. • Running AROS on a background pthread needs careful scheduler-signal masking so timer signals cannot land on AppKit or other host threads. • The IOSurface-to-compositor step is zero-copy, but

UpdateRect

still copies from the ChunkyBM buffer into the IOSurface. The

jit_write_protect

hook is interesting too. I already have a working

MAP_JIT

path with write protection and instruction-cache invalidation for the 68k JIT, although I currently expose that through the host-library bridge. Comparing the two designs could be valuable. None of this is meant to diminish the work, it’s genuinely encouraging to have more people exploring this area. I would be very happy to compare notes, share the tests and problems we have already encountered, and hear your opinion about the Macaros approach.

@Gareth Davidson Just curious, but on what system did you experience this problem? github.com/aros-development-team/AROS/pull/1058

@bsek I imagine some optimization (probably in clang) uses a function from stdc, causing the shared library to be pulled in

Hi everyone! I have been lurking around in this project for a short while. I've been looking at it from an Apple Silicon angle. I've also looked at the work @John Knipper has been doing on Macaros. Not a C/C++ expert by any means, but continuously learning. I noticed during my early testing that, on darwin-aarch64, the display driver appears to load twice during boot. Not sure if anyone else has noticed the same thing? On Linux, this goes unnoticed because the X11 driver's disk startup returns when x11gfx.hidd is already loaded. The Cocoa driver on darwin has no such check and ends up with two CocoaGfx instances and two input poller tasks (haven't been able to check on Windows). I'm proposing a small change in

rom/dos/cliinit.c

to prevent this, and I would love to open my first PR in the project for it.

Hi @Espen Otterstad, welcome and thanks for looking into that. Make the change, test it, and go ahead, open the PR.