WIP updated homebrew toolchain for PS2

I also encounter the problem with binutils-iop
Code: 
WARNING: `makeinfo' is missing on your system.  You should only need it if
         you modified a `.texi' or `.texinfo' file, or any other file
         indirectly affecting the aspect of the manual.  The spurious
         call might also be the consequence of using a buggy `make' (AIX,
         DU, IRIX).  You might want to install the `Texinfo' package or
         the `GNU make' package.  Grab either from any GNU archive site.
WARNING: `makeinfo' is missing on your system.  You should only need it if
         you modified a `.texi' or `.texinfo' file, or any other file
         indirectly affecting the aspect of the manual.  The spurious
         call might also be the consequence of using a buggy `make' (AIX,
         DU, IRIX).  You might want to install the `Texinfo' package or
         the `GNU make' package.  Grab either from any GNU archive site.
Making clean in .
Making clean in po
Making clean in .
Making clean in po
Making clean in doc
Making clean in .
Making clean in po
Making clean in doc
Making clean in .
Making clean in po
Making clean in doc
Making clean in .
Making clean in po
Configuring for a x86_64-unknown-linux-gnu host.
Copying no to /home/user/Documents/ps2/ps2dev-newtoolchain/ps2dev/iop/iop/sys-include
../../iop/gcc/configure: 193: cd: can't cd to no

Code: 
user@DESKTOP-blahblah:~/Documents/ps2/ps2dev-newtoolchain$ makeinfo --version
texi2any (GNU texinfo) 6.7
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Also later got this one. Umm... what
Code: 
/bin/bash: /home/user/Documents/ps2/ps2dev-newtoolchain/toolchain/build/gcc-ee-stage2/./gcc/xgcc: No such file or directory
Making clean in python
creating cache ./config.cache
*** This configuration is not supported in the following subdirectories:
     ld
    (Any other directories should still work fine.)


Here is the final one. I have received this one on every build so far.
Code: 
make[1]: Entering directory '/home/user/Documents/ps2/ps2dev-newtoolchain/apps/pademu_playground/pademu'
Makefile:28: /iop/Rules.release: No such file or directory
make[1]: *** No rule to make target '/iop/Rules.release'.  Stop.
make[1]: Leaving directory '/home/user/Documents/ps2/ps2dev-newtoolchain/apps/pademu_playground/pademu'
make: *** [Makefile:7: clean] Error 2


These could be buffer overflows
Code: 
src/libhdd.c:167:40: warning: '%s' directive writing up to 255 bytes into a region of size 35 [-Wformat-overflow=]
  167 |   sprintf(hddFs[count].filename, "hdd0:%s", dirEnt.name);
      |                                        ^~   ~~~~~~~~~~~
src/libhdd.c:167:3: note: 'sprintf' output between 6 and 261 bytes into a destination of size 40
  167 |   sprintf(hddFs[count].filename, "hdd0:%s", dirEnt.name);
 
Last edited:
EE toolchain updated to upstream master branches of TODAY! Current state:
  • EE toolchain is tracking the master branches of:
    • gcc (updated 2020-11-07)
    • binutils (updated 2020-11-07)
    • newlib (updated 2020-11-07)
  • IOP toolchain is the same as ps2sdk/ps2toolchain uses (gcc 3.2.3)
  • DVP toolchain is the same as ps2sdk/ps2toolchain uses
It fully compiles and runs OPL (not games, but the GUI can be started and used).

Code: 
mips64r5900el-ps2-elf-gcc --version
mips64r5900el-ps2-elf-gcc (GCC) 11.0.0 20201107 (experimental)
Copyright (C) 2020 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.
 
Hi.

It's a awesome message that there is a project to move out toolchain from ancient GCC.
I will try to test it today on my alpha renderer/game engine for PS2.
It would be great for me to work on the new GCC.

Thanks for you work guys!
 
OPL is now fully working using the GCC 11/master toolchain!

This means we're close to updating the EE toolchain from the ancient GCC 3.2.3 to GCC10. There's still other projects that need to be fixed to compile and run properly on the newer GCC, but having OPL is a big milestone.

Test version can be downloaded here:
https://www.dropbox.com/s/kwsobzmjd4hndvy/OPNPS2LD-0.9.3+.1580-Beta-2b461ea-dirty.ZIP?dl=0

Please test and report bugs here.
Before reporting a bug, make sure it works in the latest OPL (compiled with GCC 3.2.3) first.
 

Attachments

Last edited by a moderator:
I made a quick test with with new OPL (...1580-Beta...) on a real hardware (SCPH-70004).
It boots, in GUI I only messed with graphical settings (changing res), save settings.
I launch one game though USB. Everything was fine.

I mean I have the same problems as with 1562, but currently it is irrelevant.

BTW I additionally uploaded your test build in your attachment, if you don't like you can always delete it,
sorry if I made a wrong decision.
 
Hi jolek, thank you for testing and adding the attachment.

I just noticed I have a little more commits in that build than I intended. So amongst other things it's also got 240p/288p mode in there:
https://gitlab.com/ps2max/Open-PS2-Loader/-/commit/13f1db7682f376794d60d34ef3f91ba7ba8396cc
This may shift the graphics mode you have configured to another mode.

So... it's fun to play with, but be warned if your graphics mode may not be what you're expecting.
 
Thanks for these new V-modes in OPL's GUI.

They are really handy for OLD TVs.
I mean, let's say that on my "modern" TV PAL 640x256p @50Hz 24bit and NTSC 640x224p @60Hz 24bit
GUI looks pixelated (especially a font).
On the other hand with these modes on an old TV I do not have any flickering.

EDIT: I needed to set "H-POZ: -7" and "V-POZ: 2" on PAL 640x256p @50Hz 24bit,
"H-POZ: -11" and "V-POZ: 0" on NTSC 640x224p @60Hz 24bit.
Probably different TVs will need different settings.
 
Last edited:
  • Like
Reactions: TnA
For the gui it's probably better to use 480i and 576i. To reduce flicker on crt's we should add the "reduce flicker" setting lots of games also have.

Verstuurd vanaf mijn Mi Note 10 Lite met Tapatalk
 
  • Like
Reactions: TnA
TnA said:
I figure setting it up, requires the same things like the old SDK&Toolchain, but with the clone-URL being changed, or does it need anything else?
Click to expand...

The installation instructions are in the first post

I have many ps2dev environments on 1 machine. Instead of having global environment variables point to where $PS2DEV, $PS2SDK, etc... are, I set them using a script called "envsetup.sh". So for each terminal I open I first go to the folder where my development environment is, and then execute ". envsetup.sh". Note the "." + space before the "envsetup.sh". This allows me to have as many environments as I like, and I can even compile and test gcc 3.2.3 and gcc 11 at the same time, in different terminals.

The script looks like this (and is part of what you download when following the instructions in the first post):
Code: 
#!/bin/bash

if [ -z "$PS2DEV_ROOT" ]; then
    # if no root defined, then set local PS2DEV_ROOT
    # to enable multiple development environments
    export PS2DEV_ROOT=$PWD/ps2dev
fi

if [ -n "$PS2DEV" ]; then
    if [ "$PS2DEV" == "$PS2DEV_ROOT" ]; then
        echo "PS2DEV environment already set to $PS2DEV"
        return 0
    else
        echo "ERROR: PS2DEV environment set to $PS2DEV"
        echo "                   -> instead of $PS2DEV_ROOT"
        return 1
    fi
fi

mkdir -p ps2dev

# Create needed vars
export PS2DEV=$PS2DEV_ROOT
export PS2SDK=$PS2DEV/ps2sdk
export GSKIT=$PS2DEV/gsKit
export PS2SDKSRC=$PWD/libs/ps2sdk
export GSKITSRC=$PWD/libs/gsKit

# Add binaries to PATH
export PATH=$PATH:$PS2DEV/bin
export PATH=$PATH:$PS2DEV/ee/bin
export PATH=$PATH:$PS2DEV/iop/bin
export PATH=$PATH:$PS2DEV/iop-ppc/bin
export PATH=$PATH:$PS2DEV/dvp/bin
export PATH=$PATH:$PS2SDK/bin

echo "PS2DEV environment set to $PS2DEV"
return 0
Also note that this script causes all executables to be installed locally (in $PWD/ps2dev).
 
Hello guys,
I have been testing the upgrade of binutils and gcc for IOP.
The changes for GCC are minimal, so we're lucky and we can go for latest version without any issue.

However, for Binutils, things are more difficult, because we need to generate a specific IRX format, there are some patches generated previously by @uyjulian and @sp193, these patches are working till version 2.25.1

Version 2.26 and newer ones, produce `Segmentation fault` compiling `ps2sdk`. I have been using `git bisect` trying to find out which one is the guilty commit.

Code: 
5fe2850dd96483f176858fd75c098313d5b20bc2 is the first bad commit
commit 5fe2850dd96483f176858fd75c098313d5b20bc2
Author: H.J. Lu <[email protected]>
Date:   Tue Sep 22 06:08:55 2015 -0700
    Set DF_1_PIE in gld${EMULATION_NAME}_after_parse
    We can't add OPTION_PIE to gld${EMULATION_NAME}_handle_option since
    it has been handled in parse_args in lexsup.c.  This patch moves
    setting DF_1_PIE to gld${EMULATION_NAME}_after_parse.
    ld/
            * emultempl/alphaelf.em (alpha_after_parse): Call
            gld${EMULATION_NAME}_after_parse instead of
            after_parse_default.
            * emultempl/cr16elf.em (cr16elf_after_parse): Likewise.
            * emultempl/crxelf.em (crxelf_after_parse); Likewise.
            * emultempl/hppaelf.em (hppaelf_after_parse): Likewise.
            * emultempl/mipself.em (mips_after_parse): Likewise.
            * emultempl/nds32elf.em (nds32_elf_after_parse): Likewise.
            * emultempl/elf32.em: Don't include ldlex.h.
            (gld${EMULATION_NAME}_after_parse): New function.
            (gld${EMULATION_NAME}_handle_option) [GENERATE_PIE_SCRIPT]
            <OPTION_PIE>: Removed.
            (ld_${EMULATION_NAME}_emulation): Replace after_parse_default
            with gld${EMULATION_NAME}_after_parse.
            * emultempl/ia64elf.em (gld${EMULATION_NAME}_after_parse):
            Renamed to ...
            (ia64elf_after_parse): This.  Call
            gld${EMULATION_NAME}_after_parse instead of after_parse_default.
            (LDEMUL_AFTER_PARSE): Replace gld${EMULATION_NAME}_after_parse
            with ia64elf_after_parse.
    ld/testsuite/
            * ld-elf/pie.d: New test.
 ld/ChangeLog              | 23 +++++++++++++++++++++++
 ld/emultempl/alphaelf.em  |  2 +-
 ld/emultempl/cr16elf.em   |  2 +-
 ld/emultempl/crxelf.em    |  2 +-
 ld/emultempl/elf32.em     | 26 +++++++++++++++++---------
 ld/emultempl/hppaelf.em   |  2 +-
 ld/emultempl/ia64elf.em   |  6 +++---
 ld/emultempl/mipself.em   |  2 +-
 ld/emultempl/nds32elf.em  |  2 +-
 ld/testsuite/ChangeLog    |  4 ++++
 ld/testsuite/ld-elf/pie.d |  8 ++++++++
 11 files changed, 61 insertions(+), 18 deletions(-)
 create mode 100644 ld/testsuite/ld-elf/pie.d

I will keep trying to understand how to solve this issue.

Thanks
 
Good news guys, I have found how to fix it, not sure if it will break something else, but I have tested so far RA working perfectly using binutils 2.26.1
Not sure with this fix how far we can go in binutils till it crashes/fails again.

Thanks
 
Well guys, more good news, I have been able to upgrade Binutils for IOP to 2.35.2. I tested with RA and it is working as expected.
I tried to upgrade to the latest 2.36 version, but I gave up.... I'm not able..., so far I feel happy being upgraded the Binutils to a really recent version.

I'm just waiting for you guys to tell me if OPL is working as expected, if this is the case, then we can create PRs

Thanks
 
Nice to know progress is still being made. I keep following this once in a while, until SDL libs are updated, so I can port my game to PS2 again.
Thank you for all your hard work!
 
Iuri Fiedoruk said:
Nice to know progress is still being made. I keep following this once in a while, until SDL libs are updated, so I can port my game to PS2 again.
Thank you for all your hard work!
Click to expand...
Yeah, I am interested also in SDL2, mainly for the following reasons:

* Simplify environment initialization (like rebooting IOP, mounting storage devices, etc)
* Simplify controller handling
* SDL_Renderer for simplified 2D graphics rendering

I think @fjtrujy was working on that last time I heard.
 
With the new toolchain, it should be possible to use unpatched Binutils/GCC to generate irx files.

It doesn't appear that elfedit can set e_type to arbitrary value, so an additional step will need to be added…

For reference (154680/138)…
ragnarok2040 said:
This is the linkscript I used for binutils-2.23.1 to create iop modules. I had to manually modify the e_type to 0xFF80 in the elf header because I used a standard mipsr3000-unknown-elf toolchain. I've been trying to make a linkscript compatible with ld 2.14 but it doesn't seem to like my map.
Code: 
OUTPUT_FORMAT("elf32-littlemips")
SEARCH_DIR("");
ENTRY(_start)
PHDRS
{
  irxhdr 0x70000080 FLAGS (PF_R);
  defhdr PT_LOAD;
}
SECTIONS
{
  .iopmod (COPY) : ALIGN(4) {
    LONG (DEFINED(_irx_id) ? _irx_id : 0xffffffff) ;
    LONG (_start) ;
    LONG (_gp) ;
    LONG (_text_size) ;
    LONG (_data_size) ;
    LONG (_bss_size) ;
    INPUT_SECTION_FLAGS (!SHF_ALLOC & !SHF_WRITE & !SHF_EXECINSTR) * ( .iopmod )
  } :irxhdr
  . = 0x0 ;
  _ftext = . ;
  .text : {
    CREATE_OBJECT_SYMBOLS
    * ( .text )
    * ( .text.* )
    * ( .init )
    * ( .fini )
  } :defhdr = 0
  _etext  =  . ;
  . = . ;
  _fdata = . ;
  .rodata : {
    * ( .rdata )
    * ( .rodata )
    * ( .rodata1 )
    * ( .rodata.* )
  } = 0
  .data : {
    * ( .data )
    * ( .data1 )
    * ( .data.* )
    CONSTRUCTORS
  }
  . = ALIGN(16) ;
  _gp = . + 0x8000 ;
  .sdata : {
    * ( .lit8 )
    * ( .lit4 )
    * ( .sdata )
    * ( .sdata.* )
  }
  _edata = . ;
  . = ALIGN(4) ;
  _fbss = . ;
  .sbss : {
    * ( .sbss )
    * ( .scommon )
  }
  _bss_start = . ;
  .bss : {
    * ( .bss )
    * ( COMMON )
    . = ALIGN(4) ;
  }
  _end = . ;
  _text_size = _etext - _ftext ;
  _data_size = _edata - _fdata ;
  _bss_size = _end - _fbss ;
  /DISCARD/ : {
    * ( .reginfo )
    * ( .mdebug.* )
    * ( .pdr )
  }
}
IOP_LDFLAGS, if using gcc:
-T$(PS2SDKSRC)/iop/linkscript
-Wl,-q emit relocations, needed
-Wl,-n don't page align data, makes for smaller ELF size, not needed
-Wl,--no-check-sections prevent overlap checks because the irxhdr segment
is marked loadable, even though the section in that segment isn't loaded into memory, prevents warnings
All the modules I tested worked at the time. The linkscript might need some syntax cleanup. I think I created that from an ld --verbose command.
Oh yeah. In iop/kernel/include/irx.h replace the IRX_ID macro with this one otherwise the .iopmod section doesn't get created. And irx names are limited to 64 bytes. I don't think any modules violated that.
Code: 
#define IRX_ID(name, maj, min) \
struct { \
 const char *n; \
 u16 v; \
} _irx_id = { \
        name,IRX_VER(maj, min) \
}; \
const u16 _irx_version __attribute__((section(".iopmod"))) = IRX_VER(maj, min); \
const char _irx_name[] __attribute__((aligned(1),section(".iopmod"))) = name;
These CFLAGS weren't in iop/Rules.make when I was working on the toolchain with MegaMan, so I'm not sure if they'll create a conflict.
Code: 
ifneq ($(IOP_CC_VERSION),3.2.2)
ifneq ($(IOP_CC_VERSION),3.2.3)
IOP_CFLAGS += -msoft-float -mno-explicit-relocs
IOP_IETABLE_CFLAGS := -fno-toplevel-reorder
endif
endif
Click to expand...
 
I did something similar for building PRX (IRX) modules for DECKARD and it worked the same, but I ended-up having to modify some value - perhaps the type again with sed in the makefile. https://www.psx-place.com/threads/hdd-for-ps2-scph75000x-later-models.30696/page-2#post-255399
But I guess another option is to use small 'converter' program which to handle anything that can't be done with the linker file and compile options.
Still I wonder if not using binutils patches is a good variant (I hope there are no special use-cases which this would make very hard to use).

Great work on the PS2 projects overall! :)
 
You must log in or register to reply here.

Similar threads

Back
Top