Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Foxlet

Member
  • Content Count

    35
  • Joined

  • Last visited

Awards


This user doesn't have any awards

1 Follower

About Foxlet

  • Title
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yep, I wonder if hardware accelerated encoding + XSHM wasn't enabled.
  2. Yep! It's natively supported as a boot mechanism from Linux -> Linux (used in the server space where a full reboot can take minutes, and in bootloaders like Petitboot), and a version for XNU has been implemented in order to dual-boot jailbroken iPhones. Windows support is a larger challenge as source is lacking for important components like the Kernel and HAL, although there are workarounds such as emulating EFI boot services as part of kexec. Implementing any of this won't be trivial though.
  3. If we limit ourselves to just running the kernel (XNU) and a simple userland, that's already possible to a degree with qemu-system-arm64. A RasPi with KVM support could speed up performance reasonably enough to be usable, and this is more likely the route you might see come up once Big Sir is publicly available. Doing the same on bare metal is slightly more difficult, since it depends on Apple's policies going forward. If they continue to publish source code releases on https://opensource.apple.com/, and these include the ARM64 targets and Platform Experts that Big Sir will add, then with enough effort you could end up running it on a Pi, sans support for any included hardware until kernel extensions are written for them. The binaries themselves won't run on a Pi as-is though, the firmware stack between both platforms are very different, with Apple Silicon Macs using something more akin to LLB/iBoot as seen on iOS devices.
  4. I find it interesting that this slide wasn't directly posted. Even if direct boot isn't supported officially by Apple, at the very least something like kexec should be possible to run Linux from the rootfs, unless they change their minds on being able to disable Secure Boot/SIP.
  5. PCIe itself is pretty flexible, you could send messages over a serial line if one was up to the task. The problem is that Android itself doesn't really support mainline Mesa, it has its own version of the 3D libraries which may not necessarily support desktop GPUs. The best bet would be to run an ARM version of desktop Linux with mainline libraries, but that's going into custom ROM territory and probably outside LTT's scope. Also, the drivers your linked are for 32-bit legacy ARM devices, which won't work on 64-bit smartphones (most of them nowadays).
  6. I'm mostly fond of XNU and the Unix heritage of the system. It delivers the capabilities of power-user-friendly BSD with the integration of Cocoa in the UI. It's also the only other system with mainstream support for graphics applications (something that Linux still lacks currently). The other side is the challenge of running the OS on exotic hardware. I have a mixture of real Macs and Hackintoshes on AMD architectures, being able to use the OS across systems is great in most situations.
  7. MSRs haven't been an issue since XCPM debuted in the Mavericks kernel.
  8. Compatibility with macOS isn't down to generic brands, but more so the particular on-board hardware that exists in a motherboard. Networking, sound, and on-board I/O are all under consideration when picking a model. Outside of that, UEFI compatibility also matters, badly written firmwares will break the boot process from Clover -> XNU either due to memory fragmentation (KASLR fail) or driver issues.
  9. One could also build a custom ROM to allow any selection of applications on the system.
  10. You don't need any of that reasoning. Codesigning is verified when boot.efi is loaded, and again when boot.efi passes control to XNU. The boot device is irrelevant as long as it can pass the two conditions. UEFI will still be able to access all the other block devices attached to the system.
  11. It wouldn't be usable under Windows, as the feature needed for GPU acceleration (iommu passthrough) just doesn't work without KVM support. There's some experimental accelerator support for CPUs, so at best you'll have a slow experience.
  12. I have a mid-2009 MacBook Pro (on a Core2Duo), XNU can still work on Penryn+ processors to a degree, but I didn't involve any of dosdude's patchers (for various safety reasons).
  13. macOS-Simple-KVM now has support for macOS Catalina, by the way. Instructions to set it up are on the same page. https://github.com/foxlet/macOS-Simple-KVM/tree/catalina
  14. You don't need a dongle for Ethernet, plenty of boards use a chipset for which drivers exist natively.
  15. Assuming Android blobs can be found for graphics, yes, it would be a very good contender (although the touch-oriented interface might hinder it in that regard).
×