Open vmlemon opened 5 years ago
Related, but not on the same critical path, is the UNIX FFS/UFS driver (https://github.com/vmlemon/Orion/issues/8), which belongs in a different part of the system architecture, and would require us to have a working VFS, PCI support, SATA drivers, and other luxuries, before we can even get there.
https://elinux.org/images/e/e2/Engaging_Device_Trees_0.pdf has some interesting information, on PS3's device tree implementation, at least.
http://www.ki.nu/hardware/ps3/ has tools/information, regarding NetBSD, on PS3
The Linux drivers are at https://github.com/torvalds/linux/tree/master/drivers/ps3, and a device tree (is it the same as the hardware itself provides, via Open Firmware?) is supposedly available from https://github.com/westerndigitalcorporation/RISC-V-Linux/blob/master/linux/arch/powerpc/boot/dts/ps3.dts.
Completely useless, except for reference purposes (it's GPL'd source code, written to the Linux kernel API, and it's only the drivers, without any other hardware initialisation code, or headers), but I've checked in the dummy DTS, and Linux driver source to https://github.com/vmlemon/Orion/commit/72f0f14a908051465e92ae3724acb0fadf732111, and https://github.com/vmlemon/Orion/commit/3ba6c4f2366ac05454f1404f67d5af9d3b564e73, in case it disappears, in the future.
Also imported the FreeBSD PS3 driver/enlightenments (most of it is self-contained, including Open Firmware access), at https://github.com/vmlemon/Orion/commit/d7f319cd0cc1bf9b1ead6e709c83205b5b1c3d9b
Looking at the ps3-hvcall.S, quickly, it includes machine/asm.h, which is defined by https://github.com/freebsd/freebsd/blob/master/sys/powerpc/include/asm.h.
ASENTRY
is structured to be #define ASENTRY(y) _ENTRY(ASMNAME(y)); _PROF_PROLOGUE
, which in turn pulls in #define ASMNAME(asmsym) asmsym
, #define CNAME(csym) csym
, #define ENTRY(y) _ENTRY(CNAME(y)); _PROF_PROLOGUE
.
The prologue stuff is pretty hairy:
#if defined(PROF) || (defined(_KERNEL) && defined(GPROF))
# ifdef __powerpc64__
# define _PROF_PROLOGUE mflr 0; \
std 3,48(1); \
std 4,56(1); \
std 5,64(1); \
std 0,16(1); \
stdu 1,-112(1); \
bl _mcount; \
nop; \
ld 0,112+16(1); \
ld 3,112+48(1); \
ld 4,112+56(1); \
ld 5,112+64(1); \
mtlr 0; \
addi 1,1,112
# else
# define _PROF_PROLOGUE mflr 0; stw 0,4(1); bl _mcount
# endif
#else
# define _PROF_PROLOGUE
#endif
FreeBSD's OpenFirmware headers are in https://github.com/freebsd/freebsd/tree/master/sys/dev/ofw
The current status, right now, is that I'm still working on #22, which involves untangling a lot of stuff in kernel/src/platform
, and probably figuring out what to keep from kernel/src/arch/powerpc64.nicta
, but I've moved over the low-hanging fruit (kernel/src/platform/ofpower64/ps3-hvcall.S
, which needs some kernel-space headers importing from FreeBSD, and kernel/src/ps3-hvcall.h
, which seems fairly self-contained).
In Italian, but https://www.slideshare.net/vindem/cell-programming-1 has some interesting information on the Cell SDK, and I have a copy of the "Cell Broadband Engine Linux Reference Implementation Application Binary Interface Specification" document, which details some of the ELF extensions, necessary to interface with SPEs.
Notes on the PS3 SELF ABI: https://www.psdevwiki.com/ps3/SELF_File_Format_and_Decryption
PVRs documented in https://github.com/torvalds/linux/blob/master/arch/powerpc/kernel/cputable.c
At some stage, once we've got a big-endian PowerPC build working properly, we should start implementing drivers for the PS3 hypercalls, and hardware, and updating the POWER code, to recognise a Cell BBE.
Ideally, a lot of this stuff would be implemented in the main userland OS server, but to begin with, we can probably copy the approach taken with XICS (the IBM RTC), and leach off of the kernel's Open Firmware support.
FreeBSD has the repository at https://github.com/freebsd/freebsd/tree/master/sys/powerpc/ps3, which seems to be fairly clean code, and there's supposed to be details of a NetBSD port, at https://www.psdevwiki.com/ps3/NetBSD_on_PS3.
There's also Sony's official Linux drivers, but since they're GPL'd, we could probably only use them as either high-level documentation, or as a userland component, under a Linux compatibility shim.