PS3 Running Full Linux as a Native PS3 App (.pkg) — Why hasn't this been done yet?

Germanic

Forum Noob
Given current custom firmware capabilities, why hasn't anyone packaged a full Linux kernel as a .pkg installable app that runs directly from the XMB with unrestricted access to the PS3's hardware (Cell, RSX, SPUs), bypassing the limitations of OtherOS and the hypervisor?
 
Given current custom firmware capabilities, why hasn't anyone packaged a full Linux kernel as a .pkg installable app that runs directly from the XMB with unrestricted access to the PS3's hardware (Cell, RSX, SPUs), bypassing the limitations of OtherOS and the hypervisor?

Question already asked: https://www.psx-place.com/threads/how-to-get-rid-of-ps3-os-and-just-have-linux.34790/

Making a kernel and loading somewhere is not enough, you need a bootloader. And for that already exists with OtherOS, AsbestOS, and OtherOS++.

HyperVisor can't be removed.
 
Question already asked: https://www.psx-place.com/threads/how-to-get-rid-of-ps3-os-and-just-have-linux.34790/

Making a kernel and loading somewhere is not enough, you need a bootloader. And for that already exists with OtherOS, AsbestOS, and OtherOS++.

HyperVisor can't be removed.
You're absolutely right that a bootloader is required — but I'm not referring to using OtherOS, nor AsbestOS-style boot chains. I'm asking why no one has compiled a Linux kernel into a native PS3 .self executable (like a homebrew game), installed via .pkg, and run from XMB as a standalone ELF that acts as its own bootloader and jumps straight to the kernel.
Current custom firmwares like Rebug with full LV2 patches already allow unrestricted access to RSX, SPUs, and low-level MMIO — many homebrews already do this. So, theoretically, you could wrap a minimal loader around a Linux image and launch it directly, skipping both the hypervisor and OtherOS chains entirely.
I'm not saying it's easy — just strange that it hasn't been fully implemented and documented, especially since the hardware is now fully open via CFW.
 
It's technically possible to drop the whole PS3 OS by implement "whole" hardware support into linux kernel literally, compile it as lv0 binary so lv0ldr could load and run it. This way you're the only one who run on cell. Equal to generic PC where you control the whole system.

This requires ALL of internal hardware docs. The most realistic way to done is to steal WHOLE PS3 OS source code from Sony to use it as reference.

Good luck with that.

You're absolutely right that a bootloader is required — but I'm not referring to using OtherOS, nor AsbestOS-style boot chains. I'm asking why no one has compiled a Linux kernel into a native PS3 .self executable (like a homebrew game), installed via .pkg, and run from XMB as a standalone ELF that acts as its own bootloader and jumps straight to the kernel.
Current custom firmwares like Rebug with full LV2 patches already allow unrestricted access to RSX, SPUs, and low-level MMIO — many homebrews already do this. So, theoretically, you could wrap a minimal loader around a Linux image and launch it directly, skipping both the hypervisor and OtherOS chains entirely.
I'm not saying it's easy — just strange that it hasn't been fully implemented and documented, especially since the hardware is now fully open via CFW.

The way you're thinking is weird, why are you want to limit yourself by wanting to run linux under lv2? Current implementation of linux is running under lv1 so it's equal to lv2, requesting stuff through hvcall.

If you want to truly run code as bare metal then read my post above. You need all internal hardware knowledge to do it. Since lv1 handles all that hard part for you and you want it gone so you need to implement EVERYTHING yourself.(on linux kernel).

By converting to lv2 elf is equally to normal games, you're limit yourself even more. It pretty much impossible to do it since linux kernel requires stuff that lv2 syscall didn't provide.

If what you want is boot linux from XMB then what BadWDSD did is exactly that. It replaces lv2 kernel file path with petitboot, then ask lv1 to reload lv2. Petitboot end up loaded instead. It runs under same permission as lv2 kernel. lv1 is still there of course.

See last part of video:

Also petitboot itself IS linux kernel being repurposed as bootloader. You can replace it with normal distro kernel image if you want to bypass it.

Guess I will summary it:

Current implementation is like this:

Retail games: Bare metal -> lv1 (Hypervisor) -> lv2 (Kernel) -> lv2 elf (Games/XMB)
OtherOS: Bare metal -> lv1 (Hypervisor) -> Linux kernel


If want you want is this:
Bare metal -> Linux kernel

Then you need whole PS3 OS source to do it. PS3 Hardware is custom, while Cell can run generic PPC code. Other hardware like RSX/Southbridge and a lot more driver must be implemented into linux kernel through MMIO. This MMIO knowledge requires full PS3 OS source.
 
Last edited by a moderator:
I'm asking why no one has compiled a Linux kernel into a native PS3 .self executable (like a homebrew game), installed via .pkg, and run from XMB as a standalone ELF that acts as its own bootloader and jumps straight to the kernel.

Because of the absurd complexity, the lack of hardware resources of the PS3 (by your own logic, Linux would still be loaded on GameOS), the unneeded need (OtherOS was made for just that purpose). Also, you can't skip the HyperVisor that way (because GameOS depends on HV). It's there by design.

As @aomsin2526 said before, loading a Linux kernel on PS3 bare metal would require the full factory specifications and documents in order to implement it and bypass all the decryption steps on the boot chain.
 
Maybe he means more of a "front-end" to load Linux stuff using hypervisor to set everything up and reboot into custom kernel.

Just thinking out loud :)

I dont know sh*t about running Linux on ps3 to be honest, except what I learned recently with BadWDSD testing.
 
I'm not aiming for bare-metal Linux or trying to bypass the hypervisor entirely. I'm fully aware of the privilege levels and how LV1 manages hardware. What I'm interested in is something more like how Termux works on Android.
I want to package a minimal Linux environment (maybe BusyBox-based, or something like Alpine or Buildroot) into a .pkg that launches from the XMB and drops me into a terminal—chroot or userspace only is fine. It doesn't need to run a full Linux kernel separately or handle hardware initialization directly.
Think of it as a terminal emulator or portable Linux shell that runs as a userland app. It could even piggyback on the LV2 environment using syscall extensions (like peek/poke or HV proxies), and leverage patched CFW features to enhance access. I'm not trying to boot Linux, I'm trying to simulate it as an application.
This way, we avoid the complexities of replacing or bypassing LV1, and instead embrace it—just like we already do with homebrew, RetroArch, or emulators. If we can run a PSX emulator with custom syscalls and direct RSX access, why not a minimal shell with busybox or a bash prompt?


In fact, multiMAN already includes something kind of like this
 

Attachments

  • Root Multiman.png
    Root Multiman.png
    228.2 KB · Views: 44
Last edited by a moderator:
I see the point. HV for OOS limiting eg usage of RSX to 256MiB, yet I dunno if VSH not have limitations other than HDD access (which any CFW lifting), just different.

OOS needs bootloader place in eFlash/VFLASH (which messing with emerinit on Fats) + eventually another region on HDD for OOS system. For me, current way how deal with OtherOS is a torture. If Linux could be run with VSH in bg like any game, that would not require any extra steps (very invasive steps), and extra struggle. Plus, user could easily boot many different operating systems, each completely separated from each other and without touching dedicated for OOS region, and without partitioning it. Very easy to install or backup. I only see benefits from that approach.
 
I was originally going to ask too but now I'm curious if a Terminal like homebrew could be made instead of just OtherOS emulator for GUI only. You need to setup sources though for packages that work on PPC64
 
Back
Top