i think is better you use qemu/kvm
https://at.projects.genivi.org/wiki/dis ... celeration

Hello,
I have CUH-7116B FW5.05 (God of War bundle) and Linux kernel hangs with white light, When disconnect USB drive, the console switched off.
I wrote the code to enumerate devices from ACPI MCFG Table.
So my console has AMD devices as any others, but Sony devices are "Baikal", not Aeolia or Belize.
In Linux kernel drivers from Ps3ItaTeam, branch 4.14.93 (https://github.com/Ps3itaTeam/ps4-linux) Baikal devices are listed as compatible with Aeolia and Belize.
After enumerating the devices and getting the BARs for them, I have executed the glue device probing code from \drivers\ps4\ps4-apcie.c :

Codice: Seleziona tutto

static int apcie_glue_init(struct apcie_dev *sc)
{
glue_set_region(sc, AEOLIA_FUNC_ID_PCIE, 2, 0xbf018000, 0x7fff);
   sc_info("Aeolia chip revision: %08x:%08x:%08x\n",
      ioread32(sc->bar2 + APCIE_REG_CHIPID_0),
      ioread32(sc->bar2 + APCIE_REG_CHIPID_1),
      ioread32(sc->bar2 + APCIE_REG_CHIPREV));
…
}


Line glue_set_region were executed, but ioread32 lines for chipset info make PS4 hang with the same symptoms I have when starting bzImage.
So probably offsets (APCIE_REG_CHIPID, APCIE_REG_CHIPID_1, APCIE_REG_CHIPREV) are different for Baikal Glue device.
Here the extract from my enumeration klog:

Codice: Seleziona tutto

kernel_init()
Kernel base = ffffffff9bfbc000
Direct map base = ffff88f600000000
pmap_protect patch successful (found at 0xffffffff9c29f0ca)
pmap_protect(pmap, 0xffffffff9cad8000, 0xffffffff9cae0000, 7)
Testing global variable access (write protection)...
OK.
Kernel interface initialized
Installing sys_kexec to system call #153
kexec_init() successful

PS4 Linux Loader for 5.05 by valentinbreiz
kernel base is:0xffffffff9bfbc000
uaddr is:0x00000002002dc000
sys_kexec invoked
sys_kexec(0x8887a0020, 6193616, 0x888d90020, 4081343, "panic=0 clocksource=tsc console=tty0 console=ttyS0,115200n8 console=uart8250,mmio32,0xd0340000 video=HDMI-A-1:1920x1080-24@60 consoleblank=0 net.ifnames=0 drm.debug=0 amdgpu.dpm=0 pci=nobios acpi_rsdp=0xe0000 pcie_aspm=off")

dumpMCFG started
Skipping FACP
Skipping APIC

MCFG found, length=60
MMIO[0].baseAddressECM=0x00000000f8000000
MMIO[0].pciSegmentGroup=0
MMIO[0].startPCIBus=0
MMIO[0].endPCIBus=63
...

[bus=0, dev=0, func=4] headerType=80
--vendorId: 104D, deviceId: 90DB (This is Sony Baikal PCI Express Glue and Miscellaneous Devices)
--status: 0x10, command: 0x546
--classCode: 0x8, subclass: 0x80, progIF: 0x4, revisionId: 0x0
--bar#0[type=mem, noOfBits=64, addr=0xc8000000(barLow=c8000004, barHigh=0), size=0, prefetchable=0]
--bar#2[type=mem, noOfBits=64, addr=0xc8800000(barLow=c8800004, barHigh=0), size=0, prefetchable=0]
--bar#4[type=mem, noOfBits=64, addr=0xc9000000(barLow=c9000004, barHigh=0), size=0, prefetchable=0]
--subsystemVendorId: 104D,  subsystemId: 90DF
--capabilitiesPointer: 80,  reserved0: 0
--cardbusCISpointer: 0
apcie glue probe

__raw_writel(0x7fff, [b]0xffff88f6[/b]c91c80d0)
__raw_writel(0xbf018000, [b]0xffff88f6[/b]c91c80d4)
Device capabilities for ven=104d, dev=90db at address ffff88f6f8004000 ...
----Start enum capabilities...
Skipping capability=0x10 at address ffff88f6f8004080 ...
----MSICapabilities.MSIEnable=1
----MSICapabilities.MultipleMessageCapable=5
----MSICapabilities.MultipleMessageEnable=5
----MSICapabilities.address64Capable=1
----MSICapabilities.messageAddress[low=0x3eeff000, high=0x0, full=0x3eeff000]
----MSICapabilities.messageData=160
----PMCapabilities.Version=0x3
----PMCapabilities.PME Support[PMED3Cold=0, PMED3Hot=0, PMED2=0, PMED1=0, PMED0=0, D2=0, D1=0]
----PMCapabilities.DeviceSpecificInitialization=0x0
----PMCapabilities.ControlStatus=0
----PMCapabilities.PMEEnable=0
----PMCapabilities.PowerState=0
...done
...


I also tried to comment out these "chipset info lines", rebuild bzImage and run it with Linux payloader.
It still does not work but symptoms are a little bit different:
still white light, black screen but connected USB drive on, then switches off, then switches on again.
It might mean, Linux kernel now continue probing drivers and reach probe for "Baikal USB 3.0 xHCI Host Controller " (vendorId: 104D, deviceId: 90DE) where it disables and re-enables USB power (PowerManagement states D0->D3->D0).

Does anybody know how to get the BAR offsets for "Sony Baikal PCI Express Glue and Miscellaneous Devices"? Maybe some other suggestions? Maybe there is some spec for similar PCIe Glue devices? Or these offsets were retrieved by reverse-engineering of PS4 firmware?
I also can try to read PCI Express Vendor Specific Info for this device, if it exists.
Thanks.

Also would like to add the following info:
If you have symptoms like me (black screen+white light+hang), there is probability you have similar PS4 with Baikal PCI Express Glue and Miscellaneous Devices which hangs on reading chip info from memory this device memory.

The code that changes the light colour from white to blue on normal boot is a part of this glue device driver (\drivers\ps4\ps4-apcie-icc.c)

Codice: Seleziona tutto

void do_icc_init(void) {
   u8 svc = 0x10;
   u8 reply[0x30];
   static const u8 led_config[] = {
      3, 1, 0, 0,
         0x10, 1, /* Blue: on */
            2, 0xff, 2, 1, 0x00,
         0x11, 1, /* White: off */
            2, 0x00, 2, 1, 0x00,
         0x02, 3, /* Orange: delay and pulse, loop forever */
            1, 0x00, 4, 1, 0xbf,
            2, 0xff, 5, 1, 0xff,
            2, 0x00, 5, 1, 0xff,
   };
...


And this code is either not reached at all or glue-device is not properly initialized and unable to send ICC messages.
Please correct me if I'm wrong.

[Rancid(o)]

Also would like to add the following info:
If you have symptoms like me (black screen+white light+hang), there is probability you have similar PS4 with Baikal PCI Express Glue and Miscellaneous Devices which hangs on reading chip info from memory this device memory.

The code that changes the light colour from white to blue on normal boot is a part of this glue device driver (\drivers\ps4\ps4-apcie-icc.c)

Codice: Seleziona tutto

void do_icc_init(void) {
   u8 svc = 0x10;
   u8 reply[0x30];
   static const u8 led_config[] = {
      3, 1, 0, 0,
         0x10, 1, /* Blue: on */
            2, 0xff, 2, 1, 0x00,
         0x11, 1, /* White: off */
            2, 0x00, 2, 1, 0x00,
         0x02, 3, /* Orange: delay and pulse, loop forever */
            1, 0x00, 4, 1, 0xbf,
            2, 0xff, 5, 1, 0xff,
            2, 0x00, 5, 1, 0xff,
   };
...


And this code is either not reached at all or glue-device is not properly initialized and unable to send ICC messages.
Please correct me if I'm wrong.

Interesting.. Can you send me a kernel dump via PM?

I've found in my kernel dump references to APCIE_REG_CHIPID_0, APCIE_REG_CHIPID_1 and APCIE_REG_CHIPREV but they are for Aeolia..

Hopefully we can get this solved before the PS5 comes out.

Good day. I have PS4Pro CUH7016B and try lunch payload for internal drive.
https://www.psxhax.com/threads/installi ... load.6800/
Payload starts and I get rescueshell. Wrote there commands:
install-hdd.sh
start-psxitarch.sh
but system can't read the drive
It's not work for PRO?

[Rancid(o)]

Internal drive can be recognized just from CUH-10XXX/11XXX for now

Interesting.. Can you send me a kernel dump via PM?

I've found in my kernel dump references to APCIE_REG_CHIPID_0, APCIE_REG_CHIPID_1 and APCIE_REG_CHIPREV but they are for Aeolia..

Did you ever get that kernel dump, Rancid? I've been patiently waiting for well over a year for someone to fix Linux for CUH-2015A, and nobody seems to give a damn!

can you update the graphic driver in the git

Hi rancid(o),

I created a linux and linux-headers package (5.0.17) for archlinux, so that I can install packages without using dkms. However when I install those packages, arch triggers an initramfs recompile which will probably prevent the ps4 from booting into it (I haven't test it yet) so I would need to know how the initramfs from psxita was build.
I have looked inside the initramfs from psxita and the default one that arch builds, but they are very different. One more thing is that Arch boots from vmlinuz-linux and not from bzImage, so I would need to figure out how to change that.