Boot the kernel directly off a memory card

[frno7]

At the moment, the simplest method to boot the PlayStation 2 Linux kernel is to use uLaunchELF. It would be faster and simpler to boot it directly off a PlayStation 2 memory card (SCPH-10020) accessory.

[sp193]

I am not sure what you were hoping for, but only signed software can be booted from the memory card. And the software will still be booted by the EE kernel, after being located by the browser.

[frno7]

I had the impression that the Free MC Boot was not officially signed, which implied that any kind of software including the Linux kernel could be booted with an appropriate workaround. Are you informed on the details of the Free MC Boot?

[sp193]

It is signed. A really long time ago, it used to be that the FMCB installer would use a vulnerability in MagicGate to embed the FMCB installer within. But the logic remaiks: the software within the boot ROM (the EE and IOP kernels) were designed to only accept signed code from user-writable devices like the memory card. This mechanism that boots FMCB, is the update-booting mechanism.

Even if the Sony MagicGate DRM was not involved, the fact that the EE kernel would still be used to boot the update will still prevent the kernel from being booted directly.

[frno7]

Who signed the Free MC Boot as an update-boot? Is it possible to obtain the capability to sign software? I am rather unfamiliar with the steps and the restrictions of the boot process.

[sp193]

It was an anonymous contribution, from long ago. It is also possible to boot an update from the HDD unit.

Both the EE and IOP share the same boot ROM and reset vector, but the code branches according to the CPUID. Each CPU will boot its own kernel. The EE kernel will boot OSDSYS from ROM, which is the browser. The browser may attempt to locate and boot updates from other devices.

The PPC device that replaced the IOP also seems to share the boot ROM, but it has its own ROM image (DECKARD) at the end of the chip instead.

[uyjulian]

You can sign updates yourself (using data generated from the private keys, but not the keys itself) using SCEDoormat.

[frno7]

Thanks, @uyjulian! I will look into that.

[TnA-Plastic]

Oh, I haven't seen that before...

First off... YES, @SP193 has quite some insight into the project, because he is the one responsible for EVERY update in relation to FMCB 1.9x and all FHDB-Releases! ;)

Second... If you have any questions regarding the boot-mechanism or the OSDSYS-Update-Mechanism just ask and I am quite sure we can answer your questions!

Like @uyjulian said, SCEDoormat by @krHACKen [kHn] (which is using KELF-Gen v3) is the best way to create multi-region-compatible KryptoELFs nowadays.

[frno7]

Many thanks, @TnA-Plastic! I very much hope we can revisit this topic once the initial code has been merged with mainline Linux.

[TobiX]

There is now a new exploit which allows booting ELF directly from DVD: https://cturt.github.io/freedvdboot.html

[frno7]

Thanks, @TobiX! That could function as a live disc, and would certainly simplify the installation!

As a sidenote: the cd/dvd drive is a mechanical part that frequently fails after long use. If one wants to use Linux for a long period of time, and access more than will fit in 32 MiB of RAM, one most likely want to eventually install Linux on a solid state device, to reduce wear.

[faissaloo]

There is now a new exploit which allows booting ELF directly from DVD: https://cturt.github.io/freedvdboot.html

For the record I've tried to boot Maximus 32's Linux 3.8 via Kernelloader using FreeDVDBoot and I wasn't able to do it directly but could do it manually via uLaunchELF so I've written a patch for wLaunchELF that allows you to specify what you want to launch using AUTOSTART_ELF= in a LAUNCHELF.CNF which should workaround this: https://github.com/faissaloo/wLaunchELF
Since you're not using kernelloader this might not even end up being an issue, but if it is that's a potential solution.

[frno7]

Thanks, @faissaloo! As it stands the 5.x Linux kernel would most likely fail an early boot due to incomplete hardware initialisation. This would, of course, be very good to fix, so that the kernel could initialise all hardware by itself. One important detail here is that it doesn’t use any Sony BIOS services whatsoever, unlike 3.8 kernels and earlier that use them extensively. Would you like to contribute?

For example, the Graphics Synthesizer module currently assumes a hardware reset has already been done (by Free MC Boot, wLaunchELF or suchlike):

https://github.com/frno7/linux/blob/00a55c7e3a39f56e0e703a02dda5f52075b8f46a/drivers/ps2/gs.c#L300-L314

[faissaloo]

Thanks, @faissaloo! As it stands the 5.x Linux kernel would most likely fail an early boot due to incomplete hardware initialisation.This would, of course, be very good to fix, so that the kernel could initialise all hardware by itself. One important detail here is that it doesn’t use any Sony BIOS services whatsoever, unlike 3.8 kernels and earlier that use them extensively. Would you like to contribute?

Given the fact I booted PS2 Linux for the first time last week and have never done kernel development I don't think I'm familiar enough to make meaningful contributions just yet, but I'll probably continue playing around with the kernel, I'll probably spend today trying to get this one built.

For example, the Graphics Synthesizer module currently assumes a hardware reset has already been done (by Free MC Boot, wLaunchELF or suchlike):

https://github.com/frno7/linux/blob/00a55c7e3a39f56e0e703a02dda5f52075b8f46a/drivers/ps2/gs.c#L300-L314

Just for my understanding, why's that code been deadened? Will calling gs_reset() after something else has already reset the gs break things?

[TnA-Plastic]

1. Are you trying to port the newest Linux-Kernel and create a base, to make it easier to port future versions of it @frno7?
2. Kernel-Loader allows accessing content on a Video-DVD and also autobooing from there. It is not possible to use the FDVDB-ESR-Patcher-GUI on it, but the image needs to be manually created and the FDVDB-IFOs need to be at the same LBA.

[frno7]

Just for my understanding, why's that code been deadened? Will calling gs_reset() after something else has already reset the gs break things?

That particular reset doesn’t quite bring back the GS to a useful state, but since uLaunchELF already has it going I didn’t, at the time, proceed investigating why it failed. I assume some more bit-fiddling is needed. See issue #10 for a more general discussion about the GS. See also issue #9 for the special early printk thing, where one most likely should start this effort since that is the very first thing the kernel does, and it helps a lot too see those prints instead of a black screen if it crashes. Note: The code in #9 is not cleaned up in any way, but almost no kernel experience is needed in dealing with it. If you would be able to fixup #9 that would be very nice indeed.

Not to scare you off, but some kinds of hardware reset are quite elaborate. The SIF might be the worst case yet:

https://github.com/frno7/linux/blob/00a55c7e3a39f56e0e703a02dda5f52075b8f46a/drivers/ps2/sif.c#L740-L781

I believe the GS is simpler. :)

[frno7]

1. Are you trying to port the newest Linux-Kernel and create a base, to make it easier to port future versions of it @frno7?

@TnA-Plastic, the base submission weighs in at 120 patches on top of a mainline Linux kernel, currently sitting at Linux version 5.4. See issue #1 for the initial PlayStation 2 Linux kernel patch submission posted to the MIPS Linux kernel mailing list in September 2019. Currently there a couple of dozen patches with extra features.

2. Kernel-Loader allows accessing content on a Video-DVD and also autobooing from there. It is not possible to use the FDVDB-ESR-Patcher-GUI on it, but the image needs to be manually created and the FDVDB-IFOs need to be at the same LBA.

What are FDVDB, ESR, IFO and LBA?

[TnA-Plastic]

FDVDB = Free DVD Boot = DVD-Player-based exploit, to execute/boot/load custom code. You can use it for an automatically booting Linux-Disc for the PS2.

ESR = an app to access ESR-Patched discs (usually used for burned games).

IFO = the Index-files on Video-DVDs.

LBA = Logical Block Adressing The FDVDB-Files (IFOs) need to be at the same LBA, where they are in the pre-built ISOs. The second IFO can be replaced by a program like Kernel-Loader!

[faissaloo]

The second IFO can be replaced by a program like Kernel-Loader!

@TnA-Plastic Just to clarify the second IFO can't be kernel loader, I've tried it and it just gives you a black screen which is why I created my wLaunchELF fork.

[TnA-Plastic]

Did you keep the LBAs? If you did not, a black screen is normal!

If it still doesn't work, I am sure the ELF-Loader/Payload in FDVDB can be updated!

[faissaloo]

The only thing I changed was the second IFO

[TnA-Plastic]

"Changed"... Well... IN a pre-built ISO, or did you try to create a new ISO?

Check the LBAs! You can do that via tools like ISO Buster, etc.

[faissaloo]

Oh hang on I see what you're talking about, I'm using a PS2 slim so I don't need to worry about the LBA requirements of https://github.com/CTurt/FreeDVDBoot#replacing-the-initial-program---phat
I created a new one formatted as UDF as per https://github.com/CTurt/FreeDVDBoot#step-2-make-an-image according to https://github.com/CTurt/FreeDVDBoot#replacing-the-initial-program---slim and all that's needed there is to replace the IFO, I've done it before successfully with uLaunchELF

[TnA-Plastic]

If it doesn't work, than the ELF-Loader in FDVDB's Payload might be at fault. Maybe it is lacking an IOP-Reset or so...

How big is the Kernel-Loader ELF btw.?

[AKuHAK]

It is still useless until the public beta will be accessible for the community or at least until we can see a working compilation guide. As for now, the only creator has access to actual binaries (as I know). @faissaloo if you were able to compile this stuff could you please point the steps so I can reproduce it and probably create automated GitHub Action for compiling it through GitHub CI.

[AKuHAK]

I don't think that comparing payloads should be done at this point. This app still needs a predefined environment for use, and but FreeDVDBoot sets some registers in an unknown state. It even wLaunchELF isn't perfect for these purposes.

[faissaloo]

@AKuHAK I wasn't able to compile it myself but the binaries under Filesystems/ work fine.

How big is the Kernel-Loader ELF btw.?

@TnA-Plastic Kernelloader 3.0:

KLOADER.ELF 

Elf file type is EXEC (Executable file)
Entry point 0x1b00008
There is 1 program header, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x001000 0x01b00000 0x01b00000 0x142e98 0x18305c RWE 0x1000

 Section to Segment mapping:
  Segment Sections...
   00     .text .data .sdata .sbss .bss 
-rw-r--r-- 1 faissaloo faissaloo 1327244 May 18  2015 KLOADER.ELF

[TnA-Plastic]

Hm... AFAIK ELFs on FDVDB can be 2MB. It might be the load-adress.

I think it was mentioned in one of your links, where it should not overwrite something.

[AKuHAK]

@AKuHAK I wasn't able to compile it myself but the binaries under Filesystems/ work fine.

Could you please point me more directly. I cant find any 'Filesystems/'.

[faissaloo]

@AKuHAK I wasn't able to compile it myself but the binaries under Filesystems/ work fine.

Could you please point me more directly. I cant find any 'Filesystems/'.

@AKuHAK https://github.com/CTurt/FreeDVDBoot/tree/master/Filesystems

Hm... AFAIK ELFs on FDVDB can be 2MB. It might be the load-adress.

I think it was mentioned in one of your links, where it should not overwrite something.

@TnA-Plastic I double checked those before hand, they're very low addresses and shouldn't have been the issue