PSClassic-Debian
PSClassic-Debian copied to clipboard
donluca
Is it possible to boot up Debian from a USB?
Many psc owners would like the ability to restore any PSC back to stock. Previously the only way to do this without a backup was to use notv37's PlayStation_Classic_rootfs_Rebuilder tool, only problem with this method is it requires FASTBOOT and opening up the PSC.
I would like to have another solution without opening up the PSC and I believe Debian can achieve this. I've restored the rootfs partition from inside of Debian before and it'll be cool if I can create a Bootable Debian USB to make it easier for beginners.
So far I tried editing the debian.img and psc.img kernels inside a hex editor, basically I tried changing root=/dev/mmcblk0p7 to root=/dev/sda, sda1, sdb, sdb1, /media and none of them work. It would just brick the psc and I had to do a FASTBOOT to restore it.
also the way I formatted the usb is I restored it with one of my debian backups. First I loaded the debian usb with the SHELL option. Then i insert a secondary usb and ran these commands.
umount /gaadata mkfs.ext4 /dev/sdb1 mount -o rw /dev/sdb1 /gaadata tar -xzvpf /media/backup.tar.gz -C /gaadata
This project does this already: if you read the main page, you'll see that when you install Debian it first makes a backup of GAADATA on the USB drive and then you can restore back to stock at any time by creating an empty folder called RESTORE at the root of the USB drive.
What you're asking, I believe, is for a way to only make the backup on the USB drive without installing Debian?
what I'm asking is for a way to boot up Debian without the /gaadata partition, to have it boot debian directly from the USB flash drive. basically flashing a USB to ext4 and extracting the linux filesystem onto the USB then booting up with it.
That is a terrible idea, it would take literally forever to boot up from a USB drive, not to mention the immense wear it would put on the drive itself. In addition to that, as mentioned in the README, the USB implementation is utter garbage to the point where USB Audio devices will cause a kernel panic. Using an OS from a USB stick is really asking for trouble as you'll be hammering the USB bus with a constant flow of I/O, so it will probably cause read or, even worse, write corruption from time to time.
It is still possible though, just unzip PSCDebian.zip from the Releases, then unzip PSCSid.tar.gz to the root of another USB drive (which has to be formatted to ext4, this is very important) and then hex edit the kernel to boot from /dev/sda1 (if you only have one usb drive plugged). If you're going the hex editing path and not re-compiling, always remember to pad the kernel image properly so that it ends up having the same size as the data addresses are, obviously, hard coded.
This is edited to boot from /dev/sda1, adjust it to your liking, depending on your setup.
thank you. even if it's slow I'll at least like to try. the hard headed always gotta feel it to believe it, and at the very least, they'll learn something. failure is good thats how people learn.
hopefully it won't be slow to the point of unusable. i mainly want to try it for one purpose and that's to keep the ROOTFS1 partition unmounted, that way i will be able to flash a backup or use FASTBOOT in debian. If it works then I'll make a video tutorial guiding people on how to do it. As you know, FASTBOOT can be frustrating for psc users. But burning a img file with etcher onto a disposable USB might be something that novice users are more willing to do.
looking at the debianUSB.img in a hex editor, i think i see where i went wrong. i padded the /dev/sda1 with zeros like this
damn i was thinking about doing it without the zeros as a afterthought but got lazy. i actually attempted something similar months ago where i changed it from /dev/mmcblk0p9 to /dev/mmcblk0p10, and what i did was i changed fsck.repair=yes to no in order to fit the extra digit. mmcblk0p10 is the USRDATA partition where the save states are stored, i copied the contents of the ROOTFS1 partition and dumped it into the USRDATA and it actually worked. though i couldnt boot anything from the USB with the idea
maybe I'll try that idea again but this time I'll add files to the /media/ directory instead of trying to boot from USB. I just needed ROOTFS1 to be unmounted so i can run FASTBOOT on it.
anyway I'll test it later today and report back. thanks again.
Edit: aw crap, i clicked the close with comment button by mistake lol
Reopened.
You might also want to try and read a bit into how kexec works as it allows you to dynamically load a kernel, triggering a sort of "soft" reboot in order to boot the new kernel you passed through it.
hmm when i set it to sda1 it just boots into debian in /gaadata for some reason. i initially had this problem on my first attempt when i set it to sda1, i did some googling and i found this:
"You should not use sda or sdb. While in practice it is likely that the internal disk will be recognized first and become sda, you don't know for sure. You may also come across a computer with two internal disks, and then sdb will be wrong.
To identify your USB drive, use either the UUID or the label of the partition you want to use. It will be something like
/dev/disk/by-uuid/12345678-1234-1234-1234-123456789abc or
/dev/disk/by-label/usb-drive"
I thought about setting it to the USB label but wasn't sure if i had enough characters for the hex edit. hopefully i wont have to recompile it.
the softmod sounds promising. never heard of such a thing. reminds me of HBL (homebrew enablers) for the psp where we can temporary enable homebrew.
edit: I must have did something wrong, because when I use your debianUSB.img it's attempting to load from the usb. its still blinking green. not sure how long this will take. Woow it went through. i'm gonna mess with this for a while.
performance is surprisingly good. i was expecting it to move at a crawl but i see no difference in navigating and performance. though i did perform the current limit removal mod, i'll try it on a unmodded psc too cuz i imagine there's going to be people out there who will attempt to boot from the front ports.
i do have one issue, i've noticed this around late 2023 or 2024, we can no longer install packages.
would you happen to know if there's a way we can use a archive of the packages? i had to do that with my debian stretch chroot where they no longer support it, and i had to edit a file to point it to a archive site.
if there's a way to have it set to the year 2023 that'll be great.
Good news, i found a way to get packages working again from following this guide https://snapshot.debian.org/
basically i use snapshots. so in the /etc/apt/sources.list file, i changed it to deb https://snapshot.debian.org/archive/debian/20231031T145518Z sid main contrib non-free deb-src https://snapshot.debian.org/archive/debian/20231031T145518Z sid main contrib non-free
when i do a sudo apt-get update i get this error:
E: Release file for https://snapshot.debian.org/archive/debian/20231031T145518Z/dists/sid/InRelease is expired (invalid since 504d 14h 42min 3s). Updates for this repository will not be applied.
to bypass it i gotta enter sudo apt-get -o Acquire::Check-Valid-Until=false update
pretty cool. i'm learning more and more about linux everyday lol now I just needa figure out the exact date when it started having those errors. I suspect it was around the time I started seeing these t64 at the end of packages
I might have pinpointed where the problem started occurring. if I use a snapshot from feb 20 2024, everything is fine. but then I tried one from march 6 2024, and I started seeing these t64 packages.
what's interesting is it's still able to install the t64 packages on this date, march 6 2024. but it installs a bunch of other crap when on Feb it just installed the package i wanted
it seem to be doing some upgrades too. I tried a snapshot from April 24 2024 and i couldnt install anything.
edit: okay i tried removing libzip-dev which is what i just installed and it ask me to autoremove packages i no longer need, however these packages were installed when i installed libzip-dev
I think that's what's causing peoples pscs to brick. they run that apt autoremove thing and suddenly it removes a bunch of other stuff
update: looks like March 4th 2024 is the final day before it started adding those t64 stuff https://snapshot.debian.org/archive/debian/20240304T035651Z
We are unfortunately bound to an ancient custom kernel, so this had to happen at some point.
As I said at the end of the README, I'd encourage people to actively work on trying to make mainline kernel work instead of wasting time on this hack. I think the support for the Meditek SoC in the PSC has been finally merged, so it should now at least recognize the eMMC and USB ports properly.
Due to the kernel partition being limited to 8MB (IIRC) you'd have to store the kernel in IMG format like we're doing and bootstrap it after booting the stock firmware using kexec.
The information you provided here for blocking the updates is valuable, feel free to fork and add your findings so people can keep using Debian on the PSC.
i dont think kexec is supported in the psc kernel. i get a "kexec_load failed function not implemented" error
i imagine it would be possible if compiling a custom kernel to enable it.
It should work with the Debian kernel, try it out if want.
Besides, I'd encourage everyone using the Debian kernel because it has support for a massive amount of devices. Just need to change the root parameter to point to the stock firmware.
I just tried the debian kernel, i hex edit it to boot to mmcblk0p7. Well i'm still getting the kexec error, maybe i'm loading it up wrong. I copied the package files from debian stretch and copied it to the rootfs1 partition.
i would use the debian kernel but for some reason Wifi doesnt work when i'm on Autobleem or Project Eris. Seems to only work when im inside Debian
no worries, I'll just flash the kernel to make it work. btw i just noticed that i can't boot up with the OTG cable, it'll only work if i insert it into the front ports. i removed the current limit on mine so im not sure how it'll perform with the limiter. i'll try it on a stock psc later
I think the support for the Meditek SoC in the PSC has been finally merged, so it should now at least recognize the eMMC and USB ports properly.
I would like to get mainline kernel to work, i wouldnt know where to begin. Does that mean we can get hardware acceleration with the psc if we install the mainline linux? i dont even know what that means lol do we compile debian linux for the psc? is that how it works? most of this stuff goes over most people's heads.
I still dont consider myself a linux user, i mainly use it for the psc only
There's a huge amount of knowledge you need to acquire before even trying to attempt this.
You need to understand how SoCs work, how they boot, how the kernel works and how to compile it.
It's probably too much for someone who's just started.
Regarding kexec: I probably forgot to enable it in the kernel when I compiled it or maybe it wasn't even implemented in the ancient 4.4 kernel we're using. If that's the case we're pretty much out of luck.
Still, it is comforting to know there's a workaround to avoid bricking the Debian installation by forcing Aptitude to use an archive of the packages.
i'll try my hand at compiling the kernel. i would like to have that feature enabled. mainly because users can panic if their usb don't work, so if they see no LED light blinking, and it's not booting up, they may panic and think they bricked it. but if i have a kernel that let's me boot into linux, they can always fallback to booting from the ROOTFS partition that way it'll be less nerve-racking
i'm a bit confused about compiling the kernel, i just went inside the linux-4.4 directory and type make and it's asking me to do a configuration where i gotta select/enable stuff, am i on the right track? and do i have to select this myself or is there like a log somewhere that shows what the psc settings kernel
edit: i cheated, i just downloaded the .config file here and copied it. thank you modmyclassic https://gitlab.com/hwardlaw/modded-ps-classic-kernel
though i am curious on how they determine the configuration. did they do that manually or is the config hidden in sony's source code somewhere. anyway the compilation failed, let me try building it from mmc's repository
I suggest doing some research first, for something like "how to compile linux kernel for ARM device" or something like that.
You first need to know the hardware you're dealing with, then you can either pick a configuration which has already been made for that hardware, modify an existing one or start from scratch. If you don't know what kind of hardware you're dealing with you won't be able to create a correct configuration.
Another thing: I don't know what machine you're using, but your target architecture is armhf (that is, 32-bit ARM with hardware support for floating number operations), so if you're on x86 you need to set up a cross-compiling environment. (again, go look it up).
im using a arm32 chroot with gcc 6.5 and glibc 2.24. im trying to compile it with the instructions given from here: https://gitlab.com/hwardlaw/modded-ps-classic-kernel
though i think the instructions are incomplete:
Run the following to compile in the project's root directory (make sure you have GCC 6.X!): make ARCH-arm CC=arm-linux-gnueabihf-gcc-6
on my first attempt it gave a error and i switched ARCH-arm to ARCH=arm. i believe CC=arm-linux-gnueabihf-gcc-6 is also incorrect, it should be CROSS_COMPILE=, but since im already on a arm32 device my first attempt I just compiled it with make ARCH-arm -j4
it built this file that doesnt seem to resemble any of the psc or debian kernel
it was also over 8mb so i figured it wouldnt work. so then i tried to make clean and compile again, this time i tried running make ARCH=arm aiv8167_rockman_emmc_defconfig to generate a .config file, this is what the psc uses. however i notice it's the stock psc kernel. long story short it also produce a similar file.
i checked the vmlinuz-4.4.22+ file in a hex editor and searched for /dev and i couldnt find any references to mmcblk like the psc and debian.img kernel.
anyway i attempted to compile it again, this time with a toolchain that i built back in 2022 with crosstool-ng. i used a configuration from a Autobleem toolchain, i just edited it to change it to gcc 6.5.0 and gllibc 2.24.
this time i added CROSS_COMPILE=${CROSS} which points to my armv8-pony-linux-gnueabihf- toolchain. i had to edit CONFIG_CROSS_COMPILE="aarch64-linux-android-" in the .config and changed it to CONFIG_CROSS_COMPILE="armv8-sony-linux-gnueabihf-"
anyway after it was done it produced a similar file again. i looked at the psc and debian.img kernel header and i noticed
U-Boot fitImage for Yocto aud Baseline/4.4/aiv8167-rockman-emmc
so im thinking maybe it needs to be in U-boot? so i followed this guide here https://developer.arm.com/documentation/den0013/d/Building-Linux-for-ARM-Systems/Building-the-Linux-kernel
and added make ARCH=arm CROSS_COMPILE=${CROSS} uImage LOADADDR=0x80008000 -j4
i had to add the LOADADDR=0x80008000 or else it errors. anyway it produced a uImage file and when uncompressed it looks like the other previous builds
is there something i'm missing here? i feel like the instructions are incomplete. im going to search around for this U-Boot fitImage thing
If you're using an arm chroot then you don't need to specify extra options for foreign architectures, you just run make and that's it.
I don't remember what was the configuration file they used for the PSC.
You have to specify the various options (such as the partition to boot) in the kernel configuration, just run kconfig (IIRC) if you want a configuration tool with a GUI.
EDIT: the images you've produced look good. Remember that you can compress them either with the outdated lz4 compression method made for the PSC or using kernel compression (you have to specify it in the kernel configuration).
I'm just confused about mines not having the "U-Boot fitImage for Yocto aud Baseline/4.4/aiv8167-rockman-emmc" header
is it okay if it looks like this? I'm reading something about needing a signature or something. at the moment, i'm more focused on trying to get it to look somewhat like the original kernel or the debian kernel
well i finally got a custom kernel to compile. i had to use this Flat Image Tree guide: https://www.gibbard.me/linux_fit_images/
lz4 compression didnt work for some reason, i had to use gzip and set the compression to none. i enabled kexec in the kernel, and it was able to load, but when i execute the new kernel the psc would just shutdown when i tried the debian kernel. i also tried the psc.img and i believe it would restart but no display. it sure would be cool to be able to get exec to run properly. maybe a newer kexec script will work
would it be possible to set up Debian in a way where if it doesn't boot into the main screen after a certain amount of time, it'll fallback to the psc.img kernel by running dd if=/psc.img of=/dev/mmcblk0p1? or even something like a GRUB menu
edit: or better yet, is there a way to map the eject button to call a script to run those commands
The problem is that you need the filesystems to be mounted in order to achieve this.
If the issue lies before the filesystems are mounted you won't be able to flash back the original PSC kernel.
You can create a daemon that starts as soon as the filesystems are mounted and runs in the background watching how much time has passed and, if it goes over the threshold, does a dd of the psc kernel and forcibly reboots.
Look into how systemd and its boot process works.
I see so it'll still take some time for it to mount the filesystem. And i suppose if someone's filesystem is damaged they probably wouldn't be able to run the script. well the good thing with booting from USBs is if something catastrophe were to happen, they can just burn a new linux img with etcher.
though my main concern is for users who aren't using a POWERED USB hub. is it possible to boot from OTG? i tried and it didn't work. I also tried changing the boot sequence to sdb1 and that didnt work either. I removed the current limit from the front ports so im unsure if it'll even work on the stock ones. I just ordered a new PSC so i'll give that a test later.
btw, i notice the mmcblk0p9 (gaadata) partition isn't shown in the Devices list here, is there a way to have that displayed?
I figured out how to get mmcblkp09 to display. Basically i just had to edit etc/fstab and change /dev/mmcblk0p9 to /dev/sda1 and voila it shows
i figure this will give users a more familiar sight. if they see the 16gb partition with all the games in it, they'll be like oh okay these must be where all the stock games are stored. and all these other partitions is where the rootfs and save states are at
i finally finished editing the video https://www.youtube.com/watch?v=TblVeoXKcSM
i'll fork this project later and provide a update for the regular debian installer too
Nice! Thanks for your efforts, I'll probably redirect people to your fork in the main Readme.