Prbs compiling ps2menu

Discuss the development of software, tools, libraries and anything else that helps make ps2dev happen.

Moderators: cheriff, Herben

Post Reply
boman666
Posts: 33
Joined: Fri Jan 30, 2004 10:25 am
Location: Hell

Prbs compiling ps2menu

Post by boman666 »

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?
pixel
Posts: 791
Joined: Fri Jan 30, 2004 11:43 pm

Post by pixel »

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
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.
Oobles
Site Admin
Posts: 347
Joined: Sat Jan 17, 2004 9:49 am
Location: Melbourne, Australia
Contact:

Post by Oobles »

You should fix up your compiler by adding those instructions, however, if you're really lazy. You can change the instructions in your ps2menu source to cfc and ctc instead. I was told that this will produce the same output.
boman666
Posts: 33
Joined: Fri Jan 30, 2004 10:25 am
Location: Hell

Post by boman666 »

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?
Oobles
Site Admin
Posts: 347
Joined: Sat Jan 17, 2004 9:49 am
Location: Melbourne, Australia
Contact:

Post by Oobles »

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.
boman666
Posts: 33
Joined: Fri Jan 30, 2004 10:25 am
Location: Hell

Post by boman666 »

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.
pixel
Posts: 791
Joined: Fri Jan 30, 2004 11:43 pm

Post by pixel »

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 :)
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.
boman666
Posts: 33
Joined: Fri Jan 30, 2004 10:25 am
Location: Hell

Post by boman666 »

Agreed, that's a better solution since that's probably what the author intended. By the way, what's the purpose of the KSeg0/KSeg1?
mrbrown
Site Admin
Posts: 1537
Joined: Sat Jan 17, 2004 11:24 am

Post by mrbrown »

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 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?

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.
boman666
Posts: 33
Joined: Fri Jan 30, 2004 10:25 am
Location: Hell

Post by boman666 »

Thanks for the clarification. I haven't written any mipsassembler in about 6 years and I didn't remember j was a macro. Anyways, my toolchain, as you suggested, was probably broken in some way because the address became negative when I compiled ps2menu.
Post Reply