How to use this / build a suitable cross-compiler #33
Comments
|
Hello @kernle32dll! What kind of compiler errors do you have, especially using GCC 9.1.0? I’m using the Gentoo crossdev package to build a MIPS R5900 cross-compiler with currently producing and then in the Linux source directory using a You will also need a suitable root file system with for example Busybox compiled for the R5900, as well as appropriate init scripts, etc. Yes, this Linux 5.x kernel can be launched directly from uLaunchELF. I believe Rick Gaiser’s toolbox is made for Linux 2.6, that cannot be started directly from uLaunchELF. It uses a kernelloader instead. |
|
Hi @frno7 - thanks for the quick and thorough reply! First, here are the errors I encountered trying to compile Commit c94ed72 (this is the latest commit of branch ps2-v5.2.0 as of writing). All attempts failed at Take note of the differing uyjulian/ps2toolchain at d69f958 - GCC 9.1.0 make ARCH=mips CROSS_COMPILE=mips64r5900el-ps2-elf- vmlinux
SYSTBL arch/mips/include/generated/asm/syscall_table_32_o32.h
SYSTBL arch/mips/include/generated/asm/syscall_table_64_n32.h
SYSTBL arch/mips/include/generated/asm/syscall_table_64_n64.h
SYSTBL arch/mips/include/generated/asm/syscall_table_64_o32.h
SYSHDR arch/mips/include/generated/uapi/asm/unistd_n32.h
SYSHDR arch/mips/include/generated/uapi/asm/unistd_n64.h
SYSHDR arch/mips/include/generated/uapi/asm/unistd_o32.h
SYSNR arch/mips/include/generated/uapi/asm/unistd_nr_n32.h
SYSNR arch/mips/include/generated/uapi/asm/unistd_nr_n64.h
SYSNR arch/mips/include/generated/uapi/asm/unistd_nr_o32.h
HOSTCC arch/mips/tools/elf-entry
HOSTCC arch/mips/boot/tools/relocs_32.o
HOSTCC arch/mips/boot/tools/relocs_64.o
HOSTCC arch/mips/boot/tools/relocs_main.o
HOSTLD arch/mips/boot/tools/relocs
UPD include/config/kernel.release
WRAP arch/mips/include/generated/uapi/asm/bpf_perf_event.h
WRAP arch/mips/include/generated/uapi/asm/ipcbuf.h
WRAP arch/mips/include/generated/asm/current.h
WRAP arch/mips/include/generated/asm/device.h
WRAP arch/mips/include/generated/asm/dma-contiguous.h
WRAP arch/mips/include/generated/asm/emergency-restart.h
WRAP arch/mips/include/generated/asm/export.h
WRAP arch/mips/include/generated/asm/irq_work.h
WRAP arch/mips/include/generated/asm/local64.h
WRAP arch/mips/include/generated/asm/mcs_spinlock.h
WRAP arch/mips/include/generated/asm/mm-arch-hooks.h
WRAP arch/mips/include/generated/asm/msi.h
WRAP arch/mips/include/generated/asm/parport.h
WRAP arch/mips/include/generated/asm/percpu.h
WRAP arch/mips/include/generated/asm/preempt.h
WRAP arch/mips/include/generated/asm/qrwlock.h
WRAP arch/mips/include/generated/asm/qspinlock.h
WRAP arch/mips/include/generated/asm/sections.h
WRAP arch/mips/include/generated/asm/trace_clock.h
WRAP arch/mips/include/generated/asm/unaligned.h
WRAP arch/mips/include/generated/asm/user.h
WRAP arch/mips/include/generated/asm/word-at-a-time.h
WRAP arch/mips/include/generated/asm/xor.h
UPD include/generated/uapi/linux/version.h
UPD include/generated/utsrelease.h
HOSTCC scripts/genksyms/genksyms.o
YACC scripts/genksyms/parse.tab.c
HOSTCC scripts/genksyms/parse.tab.o
LEX scripts/genksyms/lex.lex.c
YACC scripts/genksyms/parse.tab.h
HOSTCC scripts/genksyms/lex.lex.o
HOSTLD scripts/genksyms/genksyms
HOSTCC scripts/kallsyms
HOSTCC scripts/conmakehash
HOSTCC scripts/sortextable
HOSTCC scripts/asn1_compiler
HOSTCC scripts/extract-cert
CC scripts/mod/empty.o
HOSTCC scripts/mod/mk_elfconfig
MKELF scripts/mod/elfconfig.h
HOSTCC scripts/mod/modpost.o
CC scripts/mod/devicetable-offsets.s
UPD scripts/mod/devicetable-offsets.h
HOSTCC scripts/mod/file2alias.o
HOSTCC scripts/mod/sumversion.o
HOSTLD scripts/mod/modpost
CC kernel/bounds.s
UPD include/generated/bounds.h
UPD include/generated/timeconst.h
CC arch/mips/kernel/asm-offsets.s
UPD include/generated/asm-offsets.h
CALL scripts/checksyscalls.sh
CALL scripts/atomic/check-atomics.sh
CC init/main.o
mips64r5900el-ps2-elf-ld: unrecognised emulation mode: elf32ltsmip
Supported emulations: elf32lr5900n32 elf32lr5900
make[1]: *** [scripts/Makefile.build:279: init/main.o] Error 1
make[1]: *** Deleting file 'init/main.o'
make: *** [Makefile:1071: init] Error 2ps2dev/ps2toolchain at d590834 - GCC 3.2.3 make ARCH=mips CROSS_COMPILE=ee- vmlinux
SYSTBL arch/mips/include/generated/asm/syscall_table_32_o32.h
SYSTBL arch/mips/include/generated/asm/syscall_table_64_n32.h
SYSTBL arch/mips/include/generated/asm/syscall_table_64_n64.h
SYSTBL arch/mips/include/generated/asm/syscall_table_64_o32.h
SYSHDR arch/mips/include/generated/uapi/asm/unistd_n32.h
SYSHDR arch/mips/include/generated/uapi/asm/unistd_n64.h
SYSHDR arch/mips/include/generated/uapi/asm/unistd_o32.h
SYSNR arch/mips/include/generated/uapi/asm/unistd_nr_n32.h
SYSNR arch/mips/include/generated/uapi/asm/unistd_nr_n64.h
SYSNR arch/mips/include/generated/uapi/asm/unistd_nr_o32.h
HOSTCC arch/mips/tools/elf-entry
HOSTCC arch/mips/boot/tools/relocs_32.o
HOSTCC arch/mips/boot/tools/relocs_64.o
HOSTCC arch/mips/boot/tools/relocs_main.o
HOSTLD arch/mips/boot/tools/relocs
UPD include/config/kernel.release
WRAP arch/mips/include/generated/uapi/asm/bpf_perf_event.h
WRAP arch/mips/include/generated/uapi/asm/ipcbuf.h
WRAP arch/mips/include/generated/asm/current.h
WRAP arch/mips/include/generated/asm/device.h
WRAP arch/mips/include/generated/asm/dma-contiguous.h
WRAP arch/mips/include/generated/asm/emergency-restart.h
WRAP arch/mips/include/generated/asm/export.h
WRAP arch/mips/include/generated/asm/irq_work.h
WRAP arch/mips/include/generated/asm/local64.h
WRAP arch/mips/include/generated/asm/mcs_spinlock.h
WRAP arch/mips/include/generated/asm/mm-arch-hooks.h
WRAP arch/mips/include/generated/asm/msi.h
WRAP arch/mips/include/generated/asm/parport.h
WRAP arch/mips/include/generated/asm/percpu.h
WRAP arch/mips/include/generated/asm/preempt.h
WRAP arch/mips/include/generated/asm/qrwlock.h
WRAP arch/mips/include/generated/asm/qspinlock.h
WRAP arch/mips/include/generated/asm/sections.h
WRAP arch/mips/include/generated/asm/trace_clock.h
WRAP arch/mips/include/generated/asm/unaligned.h
WRAP arch/mips/include/generated/asm/user.h
WRAP arch/mips/include/generated/asm/word-at-a-time.h
WRAP arch/mips/include/generated/asm/xor.h
UPD include/generated/uapi/linux/version.h
UPD include/generated/utsrelease.h
HOSTCC scripts/genksyms/genksyms.o
YACC scripts/genksyms/parse.tab.c
HOSTCC scripts/genksyms/parse.tab.o
LEX scripts/genksyms/lex.lex.c
YACC scripts/genksyms/parse.tab.h
HOSTCC scripts/genksyms/lex.lex.o
HOSTLD scripts/genksyms/genksyms
HOSTCC scripts/kallsyms
HOSTCC scripts/conmakehash
HOSTCC scripts/sortextable
HOSTCC scripts/asn1_compiler
HOSTCC scripts/extract-cert
CC scripts/mod/empty.o
Assembler messages:
Error: -mgp64 used with a 32-bit ABI
cc1: unrecognized option `-Werror=strict-prototypes'
cc1: unrecognized option `-Werror=implicit-function-declaration'
cc1: unrecognized option `-Werror=implicit-int'
cc1: unrecognized option `-Wno-maybe-uninitialized'
cc1: unrecognized option `-Wno-unused-but-set-variable'
cc1: unrecognized option `-Wdeclaration-after-statement'
cc1: unrecognized option `-Wvla'
cc1: unrecognized option `-Wno-pointer-sign'
cc1: unrecognized option `-fno-PIE'
cc1: unrecognized option `-fstack-protector-strong'
make[1]: *** [scripts/Makefile.build:279: scripts/mod/empty.o] Error 1
make: *** [Makefile:1117: prepare0] Error 2I dug trough some interesting forum posts (1, 2, 3), but am not much wiser now. My suspicion is that these toolchains contain gcc-level changes to make them run directly on the EE. But I am far out of me league here. I am also not proficient with using Gentoo. But I will look into its cross-dev mechanism. I will probably dust of my CLFS-Fu and try to build a GCC cross-compiler myself. On that note - I wasn't aware that GCC actually contains some r5900 stuff - neat. Well, I think I'll leave it at that for now. Thanks again for your response! I will come back to this when I have a working compiler. |
I’m not sure the
GCC 3.2.3 is very old and may explain problems like this one:
I think the
Gentoo isn’t required, but I’m using it myself. One nice property with Gentoo is that one can build a comprehensive R5900 Linux system, in particular in combination with R5900 QEMU user mode emulation. There are few Linux MIPS distributions available these days, and as far as I know none of them apply the necessary
Indeed! I have submitted recent patches such as the GAS and GCC There remain some rough edges to get started with this Linux kernel for the PlayStation 2. I believe most of the problems are related to lack of descriptions and how-to guides for tools, configurations, making root file systems, etc. Help is appreciated. Perhaps we could start a wiki here if you would like to start things up? |
Unfortunately not,
Indeed. Most documentation I could find was outdated, and it took me a good while to come up with a toolchain that compiles ELF files which can be run. Starting up a wiki seems like a great idea, and I'm glad to help :)
I did some quick tests on my system locally, but failed to build glibc. Bummer. I think I was able to conjure up a toolchain via Gentoo running in Docker tough (crossdev is awesome). But I lack time for further testing right now. I will continue this in the next few days. I did export the (albeit lengthy) log of crossdev, and will analyze it. With this, I should come up with a generic script and/or guide to get a working compiler toolchain. Edit: Small addendum - my Gentoo toolchain does not work :| |
Actually, your tool chain appears to work great! The By the way, what kind of screen have you attached and what kind of adapter? PAL? SCART? HDMI? Component video? |
Nice! That makes sense. How to you assemble your root fs? Manually, or via some project? Buildroot comes to mind (rickgaiser/linux-dev).
PAL console, connected via component video. |
Nowadays I do it manually. Your Gentoo crossdev compiler should be able to easily cross compile both Busybox and Dropbear (an SSH daemon for remote login) from sources. Static executables are the simplest to begin with. Copy the Busybox executable to In fact, you should now be able to build a reasonably complete Gentoo distribution for the PlayStation 2, but since that is too much to put into initramfs, I recommend postponing it for another day! You will need some standard directories in your root file system, for example The last command executes I have a USB wifi device based on the rt2800usb driver that is also setup along with Dropbear, for remote login and scripting over a network. Before building the Linux kernel, you will want to have some IOP modules installed as firmware in the root file system, to be able to use USB devices of any kind (keyboard, memory, wifi, Ethernet, etc.). Clone iopmod and do something like this: Back in the Linux source directory build the device driver modules and have them installed in the root file system as well: Finally, build the Linux kernel with and copy Assuming your monitor is able to display 1920x1080p, the provisional commit 5c2634b (where this screen resolution for simplicity is hardcoded) will display very early on when the kernel is starting up. Hope that helps! |
|
Thanks for the thorough explanation! I should be able to get pretty far with this. I will report back as I progress :) |
|
As a side node, R5900 QEMU user mode emulation can be used to try out your R5900 Busybox executable, and your root file system with some additional configuration. Also, Schroot is often very convenient as an easy to use container. It can be combined with R5900 QEMU too. |
|
FYI: Floating point support in my toolchain is broken. I haven't fully debugged the issue yet. |
|
So, I finally got time to get back to this. I was able to procure a vmlinuz file via gentoo crossdev, but uLaunchELF just states that it aint an ELF file. Any next steps? |
|
Update, made great progress. After some fiddling around, I got my PS2 to boot! I extracted the vmlinuz file, which contained a file of the same name. That I renamed to "vmlinuz.elf", and voila, I was able to boot it via uLaunchELF. Not sure why tho 🤷♂️ Initramfs seems to have worked with what you provided above, as I successfully ended up in a busybox shell. So, where to go from here? I suppose I should now compile a full gentoo system for some more fun. Not sure about how to integrate that though. I think I should do some reading up over at LFS. |
|
uLaunchELF only checks files for ELF header validity if the file extension is named with the file name ending in the following characters: |
Congratulations, @kernle32dll!
What do you mean with extracted?
Excellent!
Crossdev can easily build a base system for you. The Gentoo base system wiki has ARM as the target in the example code, but simply change that to the R5900 target. It describes how to chroot into the target environment using QEMU, but I usually use schroot with QEMU instead. There is an R5900 QEMU that can emulate the R5900 for your base system. The command You will want to have a mass storage device to put your base system onto, because a RAM disk will not have enough capacity. There are two main options: a USB device or an ATA device. The ATA device driver is not quite working yet, though. I hope this helps! For a complete Linux system on the PlayStation 2, Gentoo is probably the best choice at this time. |
I will have to check again, but I had to As for building a Gentoo system: Thanks for the explanation. I will tinker around a bit this week, and come back with the results. |
Indeed. I do Anyhow, I’m glad you’ve got your kernel working! Feel free to fill in the details in the wiki.
Great! Let me know if you need some help. |
|
Small update. I did not have time to look at the open FS points yet. But something else caught my interest. Is there currently any way to display something more fun than the shell? I have seen #10 , but it does not seem like anything working has dropped from this yet? My first thought went to https://github.com/ps2dev/gsKit, but this is intended to be used with the PS2SDK, and a corresponding toolchain. But maybe it is possible to salvage something from that. #35 made me aware of the gs.h header file. Maybe that might be worthwhile to tinker with. My goal would be to write a small C program, which does nothing but put "something" on the screen via GS (the gsKit examples are pretty good). |
|
My personal favourite of #10 is item (3), that is a specific Graphics Synthesizer device driver To proceed with #1, which is the item I’m currently busy with, I’m planning on implementing a Direct Rendering Manager (DRM) console driver, to replace the current frame buffer console driver. Note, #1 currently weights in at 120 patches and 12000 lines of code just for the basics, so a substantial amount of work remains to have it merged officially into the kernel. One important prerequisite for both items (2) and (3) is the use of scatter-gather DMA, to manage noncontinuous physical memory. The PlayStation 2 has hardware for it (and a great many other things), but having it working with pagable virtual memory etc. is another matter. I’m unfamiliar with gsKit, but I do think it is possible to implement a portable GS library that works with both PS2SDK and Linux. |
|
In the old ps2linux project there have been interfaces to use the GS. They allowed full HW access. The latest linux versions supporting this interface can be found here. There are some nice graphical examples included in those releases somewhere. There also used to be a great OpenGL 1.2 subset library (ps2stuff + ps2gl) created by SCEA and released under LGPL. Making use of not only the GS, but also VU0 and VU1. It could run on both linux and bare-metal. I've been trying to get it working on ps2sdk with some degree of success. Sources: ps2stuff ps2gl. gsKit is simple. It only uses the GS, it does not use VU0 or VU1. But perhaps this library can also be ported to use a new /dev/gs interface or DRM interface on newer linux versions. |
|
I have put gs stuff on hold for now. My cross-compiler-fu is not that good, and I will get back to it after I have running a rootfs. @frno7 As for the rootfs. I am kinda stuck.... I formatted my USB stick to have two partitions. The first, fat16 and only containing #!/bin/busybox sh
/bin/busybox --install -s
# adapted from
# https://stackoverflow.com/a/38349741
ROOT="/.root"
ROOT_DEV="/dev/sda2"
/bin/echo "init from initramfs"
# mount temporary filesystems
/bin/mount -n -t devtmpfs devtmpfs /dev
/bin/mount -n -t proc proc /proc
/bin/mount -n -t sysfs sysfs /sys
/bin/mount -n -t tmpfs tmpfs /run
# mount new root
[ -d ${ROOT} ] || /bin/mkdir -p ${ROOT}
/bin/mount -t ext4 ${ROOT_DEV} ${ROOT}
exec 0</dev/console
exec 1>/dev/console
exec 2>/dev/console
# switch to new rootfs and exec init
exec /sbin/switch_root ${ROOT} "/sbin/init" "$@"However, this does - nothing. So, when using the previous So - TL;DR; - I think I do not have access to |
That’s great! Have you verified that it works with R5900 QEMU too? You should be able to schroot into it and play around, much as if it was running on real PlayStation 2 hardware.
Did you try to
Hmm. Don’t you want to I suppose your kernel log says something about failures too? Also, by setting PATH one can omit |
Unfortunately, I was unable to compile the R5900 QEMU. I will open an issue in your repo when I get to it
Yup, but it just prints the busybox manual. From what I could gather, it does that when the PID is indeed not 1.
Makes sense. I did tinker around with modprobe, but no dice.
Dunno, as I am not able to do get to the log :| |
Please do. R5900 QEMU is extremely useful for building and testing.
What does
You’d need Finally, why not do |
|
I put a crossdev-built compiler on Docker Hub: https://hub.docker.com/r/tobix/mipsr5900el-toolchain Usage: |
|
Thank you, @TobiX!
The wiki describes two alternatives to building an R5900 cross compiler. Would you like to add your Docker as a third one? By the way, do you think making Gentoo packages for the PS2 kernel and root filesystem would be a good idea? @AKuHAK and others have asked for precompiled releases too, as described in #34. |
|
Its great thing that now we have Docker image! |
|
@frno7, Yes it seems qemu can be run in the docker file without problems. But using dockerfiles it seems this process might even be optimized, using the dockerfile as the chroot. see the article here where they do something similar for ARM. However I will first try to get a working kernel using the compiling steps I have now created (see startToEndCompile.txt). I had a problem with the container on my laptop meaning I have to redo all steps. After this I will try to create a dockerimage that runs all the steps and creates the kernel as automated as possible. |
I’m actually transitioning to
Perhaps it will compile faster with a suitable value for the
Indeed, but you will want the compressed variant
Great!
Yes, why not!
Nice! I suppose that even Windows people will have use for it, now that there is WSL2.
Note: There is a heavy performance penalty to compiling via QEMU, so that would be significantly slower than cross-compiling. The kernel build system is quite good at cross compilation, except that x86 apparently is buggy as a target. My main system is POWER9 and it would cross-compile faster than the target x86 machines in my vicinity. I suppose everyone else has x86 as a host rather than target, which would explain why nobody cares to fix it. |
|
Alright I have the "vmlinuz" file and added the ".elf" extention ```mv vmlinuz vmlinuz.elf". I copied it to my usb drive that i used to boot an older version of ps2 linux (that worked). However i get a bunch of moving stripes on the top 1/3 of my screen. I am suspecting the My screen is a old monochrome CRT with composite video input so it might not play well with the current configuration. What are the other options for the mode_option? Edit: it seems that the other image uses the kernel-loader 3.0 with the following video configuration |
Try to remove the linux/drivers/video/fbdev/ps2fb.c Line 2324 in baf32bb There is a wide selection of standard video modes to choose from: linux/drivers/video/fbdev/ps2fb.c Lines 174 to 255 in baf32bb In total, there are currently 34 video modes (shown below) provided for convenience. All of them are calculated from first principles so one can adjust margins, clock speeds, etc. or even invent new modes. See #10 for a more detailed discussion. Notice that the syntax is slightly different here: The
Almost all pieces of code have been rewritten since version 2.6, so these configurations no longer apply. Most importantly: the kernel loader is no longer used. The new frame buffer module is much faster, requires less memory and supports arbitary video modes. The main limitation is the lack of memory mapping (mmap), since the Graphics Synthesizer has local frame buffer memory that is not directly accessible from the main bus, and a virtual frame buffer isn’t emulated at this time. |
|
@frno7 it seems the video mode is not the problem here, since when i use the lowest PAL, NTSC modes or no mode it does not work and displays the same pattern. possibly i have made a different mistake somewhere. the qemu build fails on my system (log.txt), possabily i have not defined the custom gentoo repository correctly. then i eddited and then i tried: i have tried with and without the static-user flag but it did not help. |
I guess that the displayed pattern comes from this, as explained in #33 (comment):
You may want to double-check your init scripts, and the INITRAMFS, for potential problems. For example, are you using symlinks pointing to your files or directories, so that the INITRAMS stores unreachable symlinks rather than the intended file or directory?
It looks correct to me, especially since your attempt at emerging the package according to your log prints and so on! The likely error is revealed a few lines further in your log: A lot of people seem to have this problem with QEMU in recent years. A quick search yields for example: https://wrightturn.wordpress.com/2015/09/02/error-glib-2-12-gthread-2-0-is-required-to-compile-qemu/ The most likely problem is a missing package dependency, and the question is only which one. I guess your Docker image is fairly minimal, as compared to a normal desktop or server environment where the required package dependencies often happen to be preinstalled. The USE flag |
|
Hello, I have been away for a while since I could not get it to work and I had other things going on in this time. However I intent to pick up the docker image and make a working version. Quick update: And the busybox build seems to work within the qemu-mipsr5900el. |
Great, @subject546!
I suppose the proper thing is to have those as
Nice! |
|
@frno7 |
@subject546, hmm... then why did you need to do
Some optional QEMU feature? What name does this feature have in the QEMU
I can certainly help you with the package modifications, as I think they are very easy to do, once we figure out which features to disable and what package dependencies are needed! |
|
I’ve posted a patch to have the Musl C standard library support the R5900. Musl has at least two very significant advantages compared with the GNU C library:
It’s easy to try out Musl with Gentoo. Place the patch in Hopefully the Musl maintainers will accept the patch, and once it’s generally available I plan to update the wiki to recommend Musl and mention the GNU C library as an alternative. |
|
I’ve also updated R5900 QEMU to version 5.2.0. @subject546, its dependencies have changed and it might work better in your particular set-up. |
|
https://github.com/frno7/linux/wiki/Building-an-R5900-cross-compiler-from-sources#build-and-install-a-provisional-gnu-glibc-2-13 says that I need |
|
@faissaloo, I’ve fixed the link to the patch, and moved the GNU libc source build page, since we are preparing a Musl source build page alternative (which you eventually might find easier). Note: Since I’m using Gentoo, I haven’t tried the source build myself. |
|
@frno7 Do you know what commit/version that patch was made for? I've tried both glibc-2.13 and glibc-2.10.1 and it applies to neither |
|
@faissaloo, the GNU libc source build guide was a contribution I received some months ago. I only use the Gentoo guide myself. Perhaps the scripts that came with the guide could be of some help? Alternatively, Docker as explained in #33 (comment) if that’s convenient? Or the Musl source build guide if you’d like to try something brand new (and so far only compiled with Gentoo). |
|
The wiki now has a page on using an R5900 cross compiler with Docker. |
|
When everything is done and we passed through the step of the kernel compilation, there might be a case that we would like to make a changes to the initramfs only. Suppose I made that change, so is it possible to rebuild the kernel right without it's cleaning and it's total re-compiling? |
|
@Arch91, exactly. Simply rerun |
|
Precompiled kernels are now available for download from the actions menu. The wiki remains to be updated, and greatly simplified. For details, see |
Hi,
I'm currently tinkering around with my PS2, and PS2 development in general. I am able to compile (and to some extend write) code that runs on the console (simple ELF files, loaded via uLaunchELF). Looking for something more interesting, I ended up with this most interesting repository.
However, its not entirely clear what this repository provides, and how to use it. For starters, I was unable to procure any cross-compiler that would be able to compile any branch I tested (mainly 5.2), encountering different errors each time. For reference, I tested cross-compilers build by https://github.com/ps2dev/ps2toolchain, https://github.com/ps2homebrew/ps2toolchain (branch uyjworking) and https://github.com/uyjulian/ps2toolchain (branch uyjworking), using GCC 3.2.3, 7.3.0 and 9.1.0 respectively.
Additionally, I am intrigued by the README stating that no additional kernelloader is required. As such, I would be interested how this repo fares against e.g. https://github.com/rickgaiser/linux-dev (disclaimer: I was unable to compile anything runnable from that Repo - yet).
Any info shedding some light on the matters would be heartily welcome :)
The text was updated successfully, but these errors were encountered: