Prbs compiling ps2menu
Prbs compiling ps2menu
Hello,
When I try to compile ps2menu, the assembler barks on the cfc2.ni $3, $28 and ctc2.ni $3, $28 instructions. I've never seen the .ni modifier before but then again I've only been programming R3000. Is .ni a legal modifier and if it is, what does it mean?
When I try to compile ps2menu, the assembler barks on the cfc2.ni $3, $28 and ctc2.ni $3, $28 instructions. I've never seen the .ni modifier before but then again I've only been programming R3000. Is .ni a legal modifier and if it is, what does it mean?
I know I don't answer directly to your questions, but those 4 instructions were added lately to the binutils-2.13.2.1's mips r5900 instruction set patch:
cfc2.i
cfc2.ni
ctc2.i
ctc2.ni
Here is the patch to apply on your binutils's source in order to provide those instructions:
http://www.nobis-crew.org/~pixel/mips-opc.c.diff
cfc2.i
cfc2.ni
ctc2.i
ctc2.ni
Here is the patch to apply on your binutils's source in order to provide those instructions:
http://www.nobis-crew.org/~pixel/mips-opc.c.diff
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.
Thanks guys, ps2menu compiles now but the assembler is emitting warnings saying "Loop length is too short for r5900". I hope they are spurious.
Anyways, I've prb getting any prg running on the PS2. I'm using the Linuxkit, but I can't even get the pre-compiled .elf's in reload1-0.1 to execute. Since that seems so trivial, I'm starting to suspect that it's not due to me screwing up but some other prb, maybe some incompatibility with my PS2. I got the SPCH-50004 model (unmodded by the way). I don't know how long that model has been around but I bought it brand new a copule of days ago. Any hints what the culprit can be and what should I do about it?
Anyways, I've prb getting any prg running on the PS2. I'm using the Linuxkit, but I can't even get the pre-compiled .elf's in reload1-0.1 to execute. Since that seems so trivial, I'm starting to suspect that it's not due to me screwing up but some other prb, maybe some incompatibility with my PS2. I got the SPCH-50004 model (unmodded by the way). I don't know how long that model has been around but I bought it brand new a copule of days ago. Any hints what the culprit can be and what should I do about it?
-
- Site Admin
- Posts: 347
- Joined: Sat Jan 17, 2004 9:49 am
- Location: Melbourne, Australia
- Contact:
I'm not familiar with model numbers.. but I noticed this thread discussing changes required to reload for v9 ps2.
http://forums.ps2dev.org/viewtopic.php?t=29
Hope it helps.
Oobles.
http://forums.ps2dev.org/viewtopic.php?t=29
Hope it helps.
Oobles.
Ok, with that change I got reload to work. However, I also had to change asm ("j\t%0" : : "i" (0xa0001000)); in reload1.c to asm ("j\t%0" : : "i" (0x00001000));. AFAICT, that must be a bug. I find it a little bit strange that it has slipped through unnoticed, but I guess the author has a different toolchain which just ignores the overflow.
I think you'd better change the
asm ("j\t%0" : : "i" (0xa0001000));
into:
asm ("li\t$31, %0\njr\t$31" : : "i" (0xa0001000));
Well, it seems to have more sense to me :)
asm ("j\t%0" : : "i" (0xa0001000));
into:
asm ("li\t$31, %0\njr\t$31" : : "i" (0xa0001000));
Well, it seems to have more sense to me :)
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.
It could be a bug in the toolchain, as "j" is a macro, which is supposed to expand to what pixel posted above (which is itself a macro :). Did you take a look at the generated assembly?boman666 wrote:Ok, with that change I got reload to work. However, I also had to change asm ("j\t%0" : : "i" (0xa0001000)); in reload1.c to asm ("j\t%0" : : "i" (0x00001000));. AFAICT, that must be a bug. I find it a little bit strange that it has slipped through unnoticed, but I guess the author has a different toolchain which just ignores the overflow.
It has to be 0xa0001000 because I don't do an I-cache flush before jumping to the kernel startup code. IIRC I don't do it because redboot, the mostly-broken tool I used to test reload1 had funny issues with both caches (it had a bug that disabled both caches).
That sequence in reload1 is very finnicky, esp. as now I have to detect the start of the patched EELOAD startup. I'll get around to testing more it after my home dev env. is setup.