How to use this / build a suitable cross-compiler

kernle32dll commented 4 years ago

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 :)

frno7 commented 4 years ago

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

# crossdev -s4 -t mipsr5900el-unknown-linux-gnu

currently producing

% mipsr5900el-unknown-linux-gnu-gcc --version
mipsr5900el-unknown-linux-gnu-gcc (Gentoo 9.2.0 p1) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

and then in the Linux source directory

% make ARCH=mips CROSS_COMPILE=mipsr5900el-unknown-linux-gnu-

using a .config file copied from arch/mips/configs/ps2_defconfig. You probably want to adjust this configuration in some ways. You may need the Glibc patch described in README.md to build R5900 programs other than the kernel.

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.

kernle32dll commented 4 years ago

Hi @frno7 - thanks for the quick and thorough reply!

First, here are the errors I encountered trying to compile Commit c94ed72e624d28f05c2f1f034917fa432d259bc2 (this is the latest commit of branch ps2-v5.2.0 as of writing). All attempts failed at make ... vmlinux - make ... ps2_defconfig worked.

Take note of the differing CROSS_COMPILE values. They correspond to the toolchain names compiled by these repositories.

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 2

ps2dev/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 2

I 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.

frno7 commented 4 years ago

CROSS_COMPILE=mips64r5900el-ps2-elf-

I’m not sure the ps2-elf target will work when compiling the kernel. Could you try mipsr5900el-unknown-linux-gnu instead?

GCC 3.2.3

GCC 3.2.3 is very old and may explain problems like this one:

cc1: unrecognized option '-Werror=strict-prototypes'

I 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 think the mipsr5900el-unknown-linux-gnu target is much more likely to work.

I am also not proficient with using Gentoo. But I will look into its cross-dev mechanism.

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 -mfix-r5900 option for the R5900 short loop bug as described in #8.

On that note - I wasn't aware that GCC actually contains some r5900 stuff - neat.

Indeed! I have submitted recent patches such as the GAS and GCC -mfix-r5900 option and fixes to Glibc.

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?

kernle32dll commented 4 years ago

CROSS_COMPILE=mips64r5900el-ps2-elf-

I’m not sure the ps2-elf target will work when compiling the kernel. Could you try mipsr5900el-unknown-linux-gnu instead?

Unfortunately not, mips64r5900el-ps2-elf is the only toolchain produced by uyjulian/ps2toolchain.

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?

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. However, building Linux for the PS2 is something else entirely. I found scarcely any documentation at all. Most I found either related to the blackrhino / Debian 5 thing, or the original Linux DVD by Sony.

Starting up a wiki seems like a great idea, and I'm glad to help :)

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 -mfix-r5900 option for the R5900 short loop bug as described in #8.

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 :| Make fails with:

make ARCH=mips CROSS_COMPILE=mipsr5900el-unknown-linux-gnu-
[...]
  ./usr/gen_initramfs_list.sh: Cannot open '../initramfs-ps2'
make[1]: *** [usr/Makefile:57: usr/initramfs_data.cpio.xz] Error 1
make: *** [Makefile:1083: usr] Error 2

frno7 commented 4 years ago

Edit: Small addendum - my Gentoo toolchain does not work :| Make fails with:

make ARCH=mips CROSS_COMPILE=mipsr5900el-unknown-linux-gnu-
[...]
  ./usr/gen_initramfs_list.sh: Cannot open '../initramfs-ps2'
make[1]: *** [usr/Makefile:57: usr/initramfs_data.cpio.xz] Error 1
make: *** [Makefile:1083: usr] Error 2

Actually, your tool chain appears to work great! The ../initramfs-ps2 is the directory where you should put your initial root file system. You may of course configure it differently, or disable this altogether. Look for the INITRAMFS_SOURCE parameter in your .config:

linux % grep INITRAMFS_SOURCE .config
CONFIG_INITRAMFS_SOURCE="../initramfs-ps2"

By the way, what kind of screen have you attached and what kind of adapter? PAL? SCART? HDMI? Component video?

kernle32dll commented 4 years ago

Actually, your tool chain appears to work great! The ../initramfs-ps2 is the directory where you should put your initial root file system. You may of course configure it differently, or disable this altogether. Look for the INITRAMFS_SOURCE parameter in your .config:
linux % grep INITRAMFS_SOURCE .config
CONFIG_INITRAMFS_SOURCE="../initramfs-ps2"

Nice! That makes sense. How to you assemble your root fs? Manually, or via some project? Buildroot comes to mind (rickgaiser/linux-dev).

By the way, what kind of screen have you attached and what kind of adapter? PAL? SCART? HDMI? Component video?

PAL console, connected via component video.

frno7 commented 4 years ago

How to you assemble your root fs? Manually, or via some project? Buildroot comes to mind (rickgaiser/linux-dev).

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 initramfs-ps2/bin/busybox.

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 /bin, /dev, /etc, /lib, /mnt, /proc, /root, /sbin, /sys, /tmp, /usr and /var. You will also need an /init file in the root directory. Mine looks like this:

#!/bin/busybox sh

/bin/busybox --install -s

/bin/mount -t devtmpfs devtmpfs /dev

exec 0</dev/console
exec 1>/dev/console
exec 2>/dev/console

exec /sbin/init $*

The last command executes /sbin/init. Mine looks something like this:

#!/bin/sh

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
export PATH

mount -t sysfs none /sys
mount -t tmpfs none /var
mount -t tmpfs none /tmp
mount -t proc none /proc
mkdir /dev/pts
mount -t devpts none /dev/pts
mount -t debugfs none /sys/kernel/debug

modprobe ps2fb mode_option=1920x1080p@50 mode_margin=+13+0

modprobe sif
modprobe iop-memory
modprobe iop-module
modprobe iop-irq
modprobe iop-fio
modprobe iop
modprobe iop-dev9

modprobe sd_mod

modprobe ohci-ps2
modprobe ums-usbat
modprobe usbhid
modprobe hid-generic

uname -a

echo "Welcome!"
sh

while :
do
    sleep 1
done

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:

% cd iopmod
% make CROSS_COMPILE=mipsr5900el-unknown-linux-gnu-
% cp module/*.irx ../initramfs-ps2/lib/firmware/ps2/

Back in the Linux source directory build the device driver modules and have them installed in the root file system as well:

% cd ../linux
% make ARCH=mips CROSS_COMPILE=mipsr5900el-unknown-linux-gnu- modules
% make ARCH=mips CROSS_COMPILE=mipsr5900el-unknown-linux-gnu- \
       INSTALL_MOD_PATH=../initramfs-ps2 INSTALL_MOD_STRIP=1 modules_install

Finally, build the Linux kernel with

% make ARCH=mips CROSS_COMPILE=mipsr5900el-unknown-linux-gnu- vmlinuz

and copy vmlinuz to a USB memory to boot it with uLaunchELF.

Assuming your monitor is able to display 1920x1080p, the provisional commit 5c2634be6d1c485310663502d59f72d2551f9554 (where this screen resolution for simplicity is hardcoded) will display

zimage at:     00803BE0 00BDDE8C
Uncompressing Linux at load address 80010000
Now, booting the kernel...

very early on when the kernel is starting up.

Hope that helps!

kernle32dll commented 4 years ago

Thanks for the thorough explanation! I should be able to get pretty far with this. I will report back as I progress :)

frno7 commented 4 years ago

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.

uyjulian commented 4 years ago

FYI: Floating point support in my toolchain is broken. I haven't fully debugged the issue yet.
Also, ps2toolchain is for baremetal development, so some patches specific to baremetal development are applied. You do not need those patches when compiling for Linux platforms.

kernle32dll commented 4 years ago

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?

kernle32dll commented 4 years ago

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 :man_shrugging:

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.

uyjulian commented 4 years ago

uLaunchELF only checks files for ELF header validity if the file extension is named with the file name ending in the following characters: .elf
See the following: https://github.com/AKuHAK/uLaunchELF/blob/8b4d00e47279a9eecb8d66888ba3bc247b41c6f0/main.c#L1639

frno7 commented 4 years ago

Update, made great progress. After some fiddling around, I got my PS2 to boot!

Congratulations, @kernle32dll!

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.

What do you mean with extracted? cp vmlinuz /mnt/usb/vmlinuz.elf ought to be sufficient. I suppose the wiki should mention that uLaunchELF requires the kernel to have a .elf suffix, as that peculiarity is easy to miss. :)

Initramfs seems to have worked with what you provided above, as I successfully ended up in a busybox shell.

Excellent!

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.

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 # crossdev -s4 -t mipsr5900el-unknown-linux-gnu can be used to obtain an R5900 cross toolchain as well as the basis of an R5900 Gentoo root filesystem in /usr/mipsr5900el-unknown-linux-gnu. As the wiki explains, the R5900 base system can be built from scratch using the command # mipsr5900el-unknown-linux-gnu-emerge -uva --keep-going @system.

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.

kernle32dll commented 4 years ago

What do you mean with extracted? cp vmlinuz /mnt/usb/vmlinuz.elf ought to be sufficient.

I will have to check again, but I had to tar -xvf vmlinuz first, and rename that resulting file to vmlinuz.elf. Really strange.

As for building a Gentoo system: Thanks for the explanation. I will tinker around a bit this week, and come back with the results.

frno7 commented 4 years ago

I will have to check again, but I had to tar -xvf vmlinuz first, and rename that resulting file to vmlinuz.elf. Really strange.

Indeed. I do make -j64 ARCH=mips CROSS_COMPILE=mipsr5900el-unknown-linux-gnu- vmlinuz as the last build step to obtain a vmlinuz kernel file. The command readelf -h vmlinuz displays this:

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           MIPS R3000
  Version:                           0x1
  Entry point address:               0x800000
  Start of program headers:          52 (bytes into file)
  Start of section headers:          4137148 (bytes into file)
  Flags:                             0x20921101, noreorder, 32bitmode, 5900, o32, mips3
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         2
  Size of section headers:           40 (bytes)
  Number of section headers:         15
  Section header string table index: 14

Anyhow, I’m glad you’ve got your kernel working! Feel free to fill in the details in the wiki.

As for building a Gentoo system: Thanks for the explanation. I will tinker around a bit this week, and come back with the results.

Great! Let me know if you need some help.

kernle32dll commented 4 years ago

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).

frno7 commented 4 years ago

My personal favourite of #10 is item (3), that is a specific Graphics Synthesizer device driver /dev/gs. It is by far the most powerful option to make full use of the capabilities of the PlayStation 2. It is also least compatible with existing software, as is any advanced use of the PlayStation 2 hardware. Indeed, gs.h and gif.h have good abstractions, put to use in for example the ps2fb.c driver. Item (2) of #10 is the so-so but most compatible option. Eventually, I hope all options will be available.

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.

rickgaiser commented 4 years ago

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. Perhaps this library can someday be ported to a new /dev/gs interface or DRM interface on newer linux versions.

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.

kernle32dll commented 4 years ago

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 I verified that you are indeed correct in regards to vmlinuz. That tar'ing was so magic that happend as part of my build process.

As for the rootfs. I am kinda stuck....

I formatted my USB stick to have two partitions. The first, fat16 and only containing vmlinuz.elf. The second, containing an ext4 partition build from mipsr5900el-unknown-linux-gnu-emerge -uva --keep-going @system - all so good so far. Using the existing init provided by frno7, I was able to mount that fs (dev/sda2 then) in the shell. I did take some inspiration from BLFS, and this stack overflow post, and tried to build a new init, to automatically mount the root fs:

#!/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 exec /sbin/init $* as the last call, I do end up in the shell as previous. In that shell, I can see that /.root/ is actually not mounted.

So - TL;DR; - I think I do not have access to /dev/sda2 during init, and thus am unable to mount it. Right? If so - how do I get this going? :)

frno7 commented 4 years ago

The second, containing an ext4 partition build from mipsr5900el-unknown-linux-gnu-emerge -uva --keep-going @system - all so good so far.

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.

Using the existing init provided by frno7, I was able to mount that fs (dev/sda2 then) in the shell.

Did you try to exec switch_root into it from the shell? That ought to work too. The shell is supposed to have PID 1.

So - TL;DR; - I think I do not have access to /dev/sda2 during init, and thus am unable to mount it. Right? If so - how do I get this going? :)

Hmm. Don’t you want to modprobe a bunch of things, unless you have compiled USB support into the kernel? The kernel is unable to mount USB devices without the appropriate USB modules loaded. Some of these copied from /sbin/init may be useful to do before attempting to mount:

modprobe sd_mod
modprobe ohci-ps2
modprobe ums-usbat
modprobe usbhid
modprobe hid-generic

I suppose your kernel log says something about failures too?

Also, by setting PATH one can omit /bin/ in /bin/mount and simply do mount, etc.

kernle32dll commented 4 years ago

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.

Unfortunately, I was unable to compile the R5900 QEMU. I will open an issue in your repo when I get to it

Did you try to exec switch_root into it from the shell? That ought to work too. The shell is supposed to have PID 1.

Yup, but it just prints the busybox manual. From what I could gather, it does that when the PID is indeed not 1.

Hmm. Don’t you want to modprobe a bunch of things, unless you have compiled USB support into the kernel? The kernel is unable to mount USB devices without the appropriate USB modules loaded.

Makes sense. I did tinker around with modprobe, but no dice.

I suppose your kernel log says something about failures too?

Dunno, as I am not able to do get to the log :|

frno7 commented 4 years ago

Unfortunately, I was unable to compile the R5900 QEMU. I will open an issue in your repo when I get to it

Please do. R5900 QEMU is extremely useful for building and testing.

Yup, but it just prints the busybox manual. From what I could gather, it does that when the PID is indeed not 1.

What does echo $$ say? Note, you’ll need to start the shell with exec sh to retain PID 1, as opposed to just sh from the init script.

Dunno, as I am not able to do get to the log :|

You’d need modprobe ps2fb mode_option=1920x1080p@50 (or whatever is an appropriate resolution for your monitor) to see the kernel log. Possibly /sbin/modprobe if PATH isn’t set up.

Finally, why not do mount and switch_root in /sbin/init, where things are working and setup a bit more, instead of in the more primitive /init?

TobiX commented 4 years ago

I put a crossdev-built compiler on Docker Hub: https://hub.docker.com/r/tobix/mipsr5900el-toolchain It's just a quick&dirty Dockerfile, pull requests welcome.

Usage:

$ docker run -ti --rm -v $PWD:/work tobix/mipsr5900el-toolchain

frno7 commented 4 years ago

Thank you, @TobiX!

This docker image contains a precompiled mipsr5900el-unknown-linux-gnu for building modern kernel & userspace for a Sony PlayStation 2. It is based on a Gentoo stage 3 image and uses crossdev to build the toolchain.

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.

AKuHAK commented 4 years ago

Its great thing that now we have Docker image!

subject546 commented 4 years ago

The docker image from @TobiX would be very helpful for issue #34. The docker image can be used with any CI environment like Jenkins to create the prebuild releases or binaries.

frno7 commented 4 years ago

Hi @subject546! I’m not using Docker or Jenkins myself. Would you like to contribute by configuring this in some fashion?

subject546 commented 4 years ago

Hi @subject546! I’m not using Docker or Jenkins myself. Would you like to contribute by configuring this in some fashion?

Yes I have experience with docker and Jenkins so I can try to set that up.

Firstly I will try to setup a docker container based on the container from @TobiX that will build a full image. This will also allow me to create a reproducible build guide for compiling with docker (and without).

I have reproduced the results from @TobiX using his dockerimage i can build the "iopmod" modules.

Currently I am trying to figure out steps 3,4 and 5 of the installation wiki because these steps have not yet been clearly described in the wiki (there is a FIXME in all) however it seems that this thread has some additional information therefore I will try the steps above.

Maybe you can give me some pointers to information on how these steps are performed because I am not very experienced in kernel/system building with cross-compiling?

Edit: for future reference it seems busybox can be compiled with emerge-mipsr5900el-unknown-linux-gnu -va busybox (I have never used gentoo so the emerge commands are new to me)

frno7 commented 4 years ago

@subject546, great! Let’s start with step 3, that is building an R5900 Busybox. I’m personally using a fairly old version, and things have apparently changed since then. Most notably, the inability to build R5900 BusyBox as a static executable. I believe this is no longer possible with modern Glibc for MIPS.

The main advantage with a statically linked BusyBox is convenience: only a single file needs to be installed, and it’s easy to play with it using R5900 QEMU. However, it wastes precious space if additional executable files are to be installed, since Glibc would be duplicated inside each file.

There are other standard C libraries such as Musl that I believe still supporting static linking, but it would obviously complicate things to deal with several standard C libraries.

So maybe the best choice is to build a dynamically linked BusyBox, after all, and install the necessary libraries with it. R5900 QEMU handles that too, if the library paths have been set up properly.

In my opinion, the R5900 BusyBox wiki page eventually ought to have a discussion about these issues, and then proceed with the recommended steps, possibly describing various alternatives.

Edit: for future reference it seems busybox can be compiled with emerge-mipsr5900el-unknown-linux-gnu -va busybox (I have never used gentoo so the emerge commands are new to me)

Yes, that sounds reasonable for anyone using Gentoo, which simplifies a lot of things. You may want to try the USE flag static, as shown with equery u sys-apps/busybox. Does it work with the R5900 cross compiler?

subject546 commented 4 years ago

@frno7 I guess that the staticly linked version would be prefered in the current stage then? Since it is easier to handle during development, i believe that you can still use other dynamically linked applications alongside statically linked ones (like busybox in this case) but that is a problem for when you are getting a full environment going, i don't think i'll have to wory about that to much for now.

The busybox compilation completes when using the command mentioned above. emerge-mipsr5900el-unknown-linux-gnu -va busybox The command builds the version busybox-1.31.1-r2, according to the busybox website it seems this is the latest stable release (25 October 2019 -- BusyBox 1.31.1 (stable)) There where no errors during my build.

Also it seems that the binary that has been generated is statically linked. I thought I had read somewhere (when searching for how to build) that statically is the default for busybox, possibly because it is used a lot with embedded applications.

a814210d8504 ~ # ldd /usr/mipsr5900el-unknown-linux-gnu/bin/busybox
        not a dynamic executable
a814210d8504 ~ # file /usr/mipsr5900el-unknown-linux-gnu/bin/busybox
/usr/mipsr5900el-unknown-linux-gnu/bin/busybox: ELF 32-bit LSB executable, MIPS, MIPS-III version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, stripped

I am guessing the next step is to create the INITRAMFS? And that gets compiled with the kernel from this repo as mentioned above? Or does the kernel have to be installed and then compiled into the final INITRAMFS?

Am i correct in stating that the cross compiler (mipsr5900el-unknown-linux-gnu) has now created the needed components of the INITRAMFS in the folder /usr/mipsr5900el-unknown-linux-gnu without the init scripts (as mentioned above)?

frno7 commented 4 years ago

Congratulations, @subject546!

I have now updated the wiki guide on building an R5900 BusyBox using Gentoo Linux. Please review it and, if you like, rebuild your Busybox to try out both alternatives.

I guess that the staticly linked version would be prefered in the current stage then?

I would call it a matter of preference, but yes, it’s fine!

I am guessing the next step is to create the INITRAMFS? And that gets compiled with the kernel from this repo as mentioned above?

Yes, I have now updated the wiki guide on building a PlayStation 2 Linux INITRAMFS root filesystem. It is essentially a summary of the discussions in this issue. Please review it!

Or does the kernel have to be installed and then compiled into the final INITRAMFS?

No, the kernel will embed the INITRAMFS as a compresed archive file. This is done when compiling the kernel.

Am i correct in stating that the cross compiler (mipsr5900el-unknown-linux-gnu) has now created the needed components of the INITRAMFS in the folder /usr/mipsr5900el-unknown-linux-gnu without the init scripts (as mentioned above)?

For a minimal root filesystem, you only need an R5900 Busybox, two init scripts, and the IOP modules installed as firmware (as explained in the guide mentioned above). With these, the system will boot into a shell prompt, assuming you have a video display and a USB keyboard attached.

The entire directory /usr/mipsr5900el-unknown-linux-gnu can certainly function as a root filesystem, but it’s much too large for INITRAMFS, given the memory limitations of PlayStation 2. So one would either have it on a disk, which is a topic of #18, or a USB device. The USB driver however is at this time rather slow.

subject546 commented 4 years ago

It is working so far. The guides do work, with the minor change that initramfs/ps2 should be initramfs-ps2. I have changed this in the wiki page. Further more I am currently compiling with the make ARCH=mips CROSS_COMPILE=mipsr5900el-unknown-linux-gnu- command.

I will test the build on my ps2 and report back. The build should give me the vmlinux elf file that I can load with uLaunchElf if i am not mistaking.

frno7 commented 4 years ago

@subject546, I have now created a Gentoo package app-emulation/qemu-mipsr5900el for R5900 QEMU version 4.2.0. For convenience, I believe one will want to enable its USE flag static-user.

If one defines frno7/gentoo.overlay as a custom Gentoo repository one can simply do emerge -av app-emulation/qemu-mipsr5900el to obtain /usr/bin/qemu-mipsr5900el.

With an R5900 Busybox executable having

$ file /usr/mipsr5900el-unknown-linux-gnu/bin/busybox
/usr/mipsr5900el-unknown-linux-gnu/bin/busybox: ELF 32-bit LSB executable,
MIPS, MIPS-III version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, stripped

one can now do

$ qemu-mipsr5900el /usr/mipsr5900el-unknown-linux-gnu/bin/busybox | head -n1
BusyBox v1.31.1 (2020-06-14 07:37:08 CEST) multi-call binary.

to run R5900 executables on the host system. There is more:

By registering R5900 QEMU in /proc/sys/fs/binfmt_misc, one can run R5900 executables as if they were native for the host:

echo ':qemu-mipsr5900el:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x
00\x02\x00\x08\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\
xff\xfe\xff\xff\xff:/usr/local/bin/qemu-mipsel:' >/proc/sys/fs/binfmt_misc/regis
ter

This is especially useful in combination with chroot, or perhaps even better with schroot, to try out R5900 root filesystems on the host system. For example, the R5900 compiler no longer needs to cross-compile, since it can be run as a native R5900 compiler (as if it was actually running on the PlayStation 2).

Would you be able to try R5900 QEMU in your Docker image?

subject546 commented 4 years ago

@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. The step after that will be to create the image using QEMU meaning that the kernel won't have to be crosscompiled (as it will run native inside the emulated R5900).

frno7 commented 4 years ago

It is working so far. The guides do work, with the minor change that initramfs/ps2 should be initramfs-ps2. I have changed this in the wiki page.

I’m actually transitioning to initramfs/ps2, as it’s more organised when having multiple architectures, but you’re right: at the moment it’s inconsistent with arch/mips/configs/ps2_defconfig, so let’s defer this change.

Further more I am currently compiling with the make ARCH=mips CROSS_COMPILE=mipsr5900el-unknown-linux-gnu- command.

Perhaps it will compile faster with a suitable value for the -j option?

I will test the build on my ps2 and report back. The build should give me the vmlinux elf file that I can load with uLaunchElf if i am not mistaking.

Indeed, but you will want the compressed variant vmlinuz. Also note that uLaunchELF requires an .elf extension.

@frno7, Yes it seems qemu can be run in the docker file without problems.

Great!

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.

Yes, why not!

After this I will try to create a dockerimage that runs all the steps and creates the kernel as automated as possible.

Nice! I suppose that even Windows people will have use for it, now that there is WSL2.

The step after that will be to create the image using QEMU meaning that the kernel won't have to be crosscompiled (as it will run native inside the emulated R5900).

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.

subject546 commented 4 years ago

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 modprobe ps2fb mode_option=1920x1080p@50 mode_margin=+13+0

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: I should probably mention that the version I am currently trying to compile is the ps2-v5.4 branch And the version that works with my ps2 and setup is the one from here

it seems that the other image uses the kernel-loader 3.0 with the following video configuration VideoParameter=crtmode=pal1 video=ps2fb:pal,640x480-32 it seems like they use two partitions with one being the kernel loader and the other being the fs? their sbin/init is softlinked to busybox.

frno7 commented 4 years ago

However i get a bunch of moving stripes on the top 1/3 of my screen. I am suspecting the modprobe ps2fb mode_option=1920x1080p@50 mode_margin=+13+0

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?

Try to remove the mode_option and mode_margin parameters, reverting to defaults:

https://github.com/frno7/linux/blob/baf32bbbd15df3395d96812e05da0a5955de56d7/drivers/video/fbdev/ps2fb.c#L2324

There is a wide selection of standard video modes to choose from:

https://github.com/frno7/linux/blob/baf32bbbd15df3395d96812e05da0a5955de56d7/drivers/video/fbdev/ps2fb.c#L174-L255

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:

# cat /sys/class/graphics/fb0/modes | column
V:1280x1024p-75 V:640x480p-60   S:1920x1080i-60 U:1688x964p-50  S:1280x720p-50
V:1280x1024p-60 U:1688x964p-60  S:1280x720p-60  U:1688x964i-50  S:720x576p-50
V:1024x768p-75  U:1688x964i-60  S:720x480p-60   U:1124x644p-50  S:720x576i-50
V:1024x768p-60  U:1124x644p-60  S:720x480i-60   U:576x460p-50   S:640x512i-50
V:800x600p-75   U:576x384p-60   S:640x448i-60   U:576x460i-50   S:720x288p-50
V:800x600p-60   U:576x384i-60   S:720x240p-60   S:1920x1080p-50 S:640x256p-50
V:640x480p-75   S:1920x1080p-60 S:640x224p-60   S:1920x1080i-50

The fbset command in the sys-apps/fbset package can be used to configure arbitrary video modes, limited only by the hardware.

it seems that the other image uses the kernel-loader 3.0 with the following video configuration VideoParameter=crtmode=pal1 video=ps2fb:pal,640x480-32 it seems like they use two partitions with one being the kernel loader and the other being the fs? their sbin/init is softlinked to busybox.

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.

subject546 commented 4 years ago

@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. However because of this i can not test my busybox build (busybox-R5900.zip) in a chroot (or make an attempt at that) I have done the following steps to add it:

cd /var/db/repos
git clone https://github.com/frno7/gentoo.overlay
chown -R portage:portage /var/db/repos/gentoo.overlay/

then i eddited /etc/portage/repos.conf/frno7.conf with

[localrepo]
location = /var/db/repos/localrepo
masters = gentoo
auto-sync = no

and then i tried:

USE=static-user emerge -v app-emulation/qemu-mipsr5900el > log.txt

i have tried with and without the static-user flag but it did not help.

frno7 commented 4 years ago

@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.

I guess that the displayed pattern comes from this, as explained in https://github.com/frno7/linux/issues/33#issuecomment-529501922:

Assuming your monitor is able to display 1920x1080p, the provisional commit 5c2634b (where this screen resolution for simplicity is hardcoded) will display
zimage at:     00803BE0 00BDDE8C
Uncompressing Linux at load address 80010000
Now, booting the kernel...
very early on when the kernel is starting up.

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?

the qemu build fails on my system (log.txt), possabily i have not defined the custom gentoo repository correctly.

It looks correct to me, especially since your attempt at emerging the package according to your log prints

>>> Emerging (1 of 1) app-emulation/qemu-mipsr5900el-4.2.0::frno7
 * qemu-4.2.0.tar.xz SHA512 size ;-) ...                                 [ ok ]

and so on! The likely error is revealed a few lines further in your log:

ERROR: glib-2.48 gthread-2.0 is required to compile QEMU

A lot of people seem to have this problem with QEMU in recent years. A quick search yields for example:

https://github.com/Xilinx/qemu/issues/40

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 static-user already depends on dev-libs/glib-2.0 and sys-libs/zlib, but maybe that’s not enough?

subject546 commented 3 years ago

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: I just got the emulation/qemu-mipsr5900el package to work. It was (dumbly) easy to install qemu, i had to execute the following commands to satisfy the qemu dependencies: emerge dev-libs/glib and emerge x11-libs/pixman

And the busybox build seems to work within the qemu-mipsr5900el.

$ qemu-mipsr5900el /usr/mipsr5900el-unknown-linux-gnu/bin/busybox | head -n1
BusyBox v1.31.1 (2020-06-14 07:37:08 CEST) multi-call binary.
$ qemu-mipsr5900el /usr/mipsr5900el-unknown-linux-gnu/bin/busybox echo "test"
test

frno7 commented 3 years ago

However I intent to pick up the docker image and make a working version.

Great, @subject546!

It was (dumbly) easy to install qemu, i had to execute the following commands to satisfy the qemu dependencies: emerge dev-libs/glib and emerge x11-libs/pixman

I suppose the proper thing is to have those as ALL_DEPEND dependencies in the app-emulation/qemu-mipsr5900el package. Would you like to try that?

And the busybox build seems to work within the qemu-mipsr5900el.

Nice!

subject546 commented 3 years ago

@frno7 I don't think that a change in the ALL_DEPEND is needed as glib > version 2.0 is already present and the pixman dependency is possibly ruled out by configuring qemu to build without X11 support (I think this can be done with pkg-config as there is a check for that in the "configure" script of qemu). If you think it is needed you can off course add it, I'm not 100% on how to add it as I have not modified gentoo package files before.

frno7 commented 3 years ago

I don't think that a change in the ALL_DEPEND is needed as glib > version 2.0 is already present and the pixman dependency is possibly ruled out by configuring qemu to build without X11 support

@subject546, hmm... then why did you need to do emerge dev-libs/glib manually? The only difference with ALL_DEPEND is that it would be emerged automatically (as it is supposed to be with required dependencies).

(I think this can be done with pkg-config as there is a check for that in the "configure" script of qemu).

Some optional QEMU feature? What name does this feature have in the QEMU configure script? The conf_opts variable in the Gentoo package could disable it.

If you think it is needed you can off course add it, I'm not 100% on how to add it as I have not modified gentoo package files before.

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!

frno7 commented 3 years ago

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:

Program and library sizes are orders of magnitudes smaller. A test compilation of the evtest tool (see issue #22) shrank from 714124 to 131360 bytes for a statically linked executable. That’s more than 5 times smaller.
Musl is expressly designed to allow programs to be statically linked.

It’s easy to try out Musl with Gentoo. Place the patch in /etc/portage/patches/cross-mipsr5900el-unknown-linux-musl/musl/r5900-ll-sc.patch and use the target mipsr5900el-unknown-linux-musl to crossdev. The description in this thread and the wiki guide on building an R5900 cross-compiler remain otherwise the same.

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.

frno7 commented 3 years ago

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.

faissaloo commented 3 years ago

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 glibc-2.13-cross_hacks-3.patch where can I find this patch? I assume that's why I'm getting the following error when trying to build glibc:

configure: WARNING: you should use --build, --host, --target
configure: loading cache config.cache
checking build system type... mipsel-unknown-linux-gnu
checking host system type... mipsr5900el-unknown-linux-gnu
checking for mipsr5900el-unknown-linux-gnu-gcc... no
checking for gcc... gcc
configure: WARNING: using cross tools not prefixed with host triplet
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for gcc... gcc
checking how to run the C preprocessor... gcc -E
checking for mipsr5900el-unknown-linux-gnu-g++... no
checking for mipsr5900el-unknown-linux-gnu-c++... no
checking for mipsr5900el-unknown-linux-gnu-gpp... no
checking for mipsr5900el-unknown-linux-gnu-aCC... no
checking for mipsr5900el-unknown-linux-gnu-CC... no
checking for mipsr5900el-unknown-linux-gnu-cxx... no
checking for mipsr5900el-unknown-linux-gnu-cc++... no
checking for mipsr5900el-unknown-linux-gnu-cl.exe... no
checking for mipsr5900el-unknown-linux-gnu-FCC... no
checking for mipsr5900el-unknown-linux-gnu-KCC... no
checking for mipsr5900el-unknown-linux-gnu-RCC... no
checking for mipsr5900el-unknown-linux-gnu-xlC_r... no
checking for mipsr5900el-unknown-linux-gnu-xlC... no
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
configure: running configure fragment for add-on libidn
configure: running configure fragment for add-on nptl
checking for assembler gnu_indirect_function symbol type support... yes
checking whether .text pseudo-op must be used... yes
checking for assembler global-symbol directive... .globl
checking for assembler .type directive prefix... @
checking sysdep dirs... configure: error: The mipsr5900el is not supported.

frno7 commented 3 years ago

@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.

faissaloo commented 3 years ago

@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

frno7 commented 3 years ago

@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 https://github.com/frno7/linux/issues/33#issuecomment-632284209 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).

frno7 / linux

How to use this / build a suitable cross-compiler #33