forums.ps2dev.org

Hi everyone,
I'm trying to port linux 2.6.21.1 to PS2, as a test environment i've used the emulator PCSX2. I've managed to make the kernel boot, and display some graphics. This works perfectly under the emulator, but on a real PS2 it doesn't work. I've two ipothesis about that

1) PCSX2 runs invalid code for a real PS2
2) To run the kernel on my PS2 i use uLauchElf as a loader, maybe it is not able to run an app as specific as the linux kernel.

Can you find an explanation for this problem?

If you have access to a PS2 that can run unlicensed code, you really should be running ps2link instead. You'd be able to easily compile and run code on the real hardware with console output for debugging.

http://ps2dev.org/ps2/Loaders/PS2_side_ ... Link_v1.46

Also, if you don't mind sharing the source there may be a few folk here who can help you out. If it is already working in an emulator then you're probably very close to it working on real hardware.

Thanks for the reply, i'm going to clean up the code a bit and post a patch.
I think the reason for the kernel not booting on the PS2 is the scrict requirement of a certain load address, that uLauchElf doens't consider when loading the kernel. To make it work under the emulator i had to set the load address in the kernel to 0x200000 or (strangely enough) PCSX2 would crash. Would that address be respected by the loader?

Both ps2link and eLaunchElf should be using the LoadExecPS2 syscall, which respects the load address specified in the elf file.

I've taken a look at uLaunchElf (http://www.sksapps.com/launchers/uLaunchELF_v4.12.zip) and it seems that it loads the elf manually and then it calls ExecPS2...

alexp wrote:I think the reason for the kernel not booting on the PS2 is the scrict requirement of a certain load address, that uLauchElf doens't consider when loading the kernel. To make it work under the emulator i had to set the load address in the kernel to 0x200000 or (strangely enough) PCSX2 would crash. Would that address be respected by the loader?

I assume that you're talking about the loader code of uLE here.

For most PS2 devices yes, the load address should be respected, but not for ELFs loaded from HDD, due to special reasons. You can study the code yourself in the subproject folder "loader/" inside the main source folder of uLE.

alexp wrote:I've taken a look at uLaunchElf (http://www.sksapps.com/launchers/uLaunchELF_v4.12.zip) and it seems that it loads the elf manually and then it calls ExecPS2...

That much is true, but the loading is for most cases done by "SifLoadElf", which should itself respect the load address specified in an ELF header.

But files on HDD are a special case, and will instead be loaded by the internal function "tLoadElf", which uses a fixed boot address of 0x01800000.

Note that the loader methods used by uLE were modified repeatedly through v3.46-v3.50 to regain PS2Link compatibility which was lost in some of its then recent releases, and also to gain/maintain mutual launch compatibility with other launch programs. (eg: myPS2)

If necessary I'm willing to repeat similar adaptions again, but please understand that my emphasis here is on the word 'necessary'.

Surely it must be simpler for you to either change the load address of your kernel ELF, or to use a slightly changed boot procedure (non-HDD boot device, or perhaps even using PS2Link). After all, if I understand you correctly, you already modified the load address once before just to adapt to an emulator, so doing it again to gain the ability to run the kernel on real hardware must be even more worthwhile.

I'm also open to suggestions for improving the uLE loader so that it can always respect load address in ELF headers properly, but such changes will not be released until we've verified that old compatibilities are unaffected.

Best regards: dlanor

dlanor wrote: For most PS2 devices yes, the load address should be respected, but not for ELFs loaded from HDD, due to special reasons. You can study the code yourself in the subproject folder "loader/" inside the main source folder of uLE.

I'm loading the kernel from a usb pendrive, it seems that the code is loaded by SifLoadElf indeed is such cases. Am I wrong?

dlanor wrote: Surely it must be simpler for you to either change the load address of your kernel ELF, or to use a slightly changed boot procedure (non-HDD boot device, or perhaps even using PS2Link). After all, if I understand you correctly, you already modified the load address once before just to adapt to an emulator, so doing it again to gain the ability to run the kernel on real hardware must be even more worthwhile.

The problem is: i don't now what is the "right" load address. When PCSX2 was crashing, the kernel was loaded in KSEG0. Maybe that's not possible. Now the code is loaded at 0x100000 and that should be normal main memory

alexp wrote:I'm loading the kernel from a usb pendrive, it seems that the code is loaded by SifLoadElf indeed is such cases. Am I wrong?

No, you're quite right. That's exactly how it should work.

The problem is: i don't now what is the "right" load address.

It's not really a question of 'right' VS 'wrong', but simply a matter of finding a working compromise. And the only sure way to do that is to first find out the reason why your current attempts are failing.

When PCSX2 was crashing, the kernel was loaded in KSEG0. Maybe that's not possible. Now the code is loaded at 0x100000 and that should be normal main memory

That area should not conflict with the usage of uLE, though it might cause problems for PS2Link. I'm not absolutely sure of that, but it seems likely considering the changes we had to make to the 'loader' of uLE to keep it compatible with the newer PS2Link versions.

As you may have noticed the current uLE loader itself resides at:
LOADADDR = 0x90000
STACKADDR = 0xA8000
STACKSIZE = 0x04000

But the older versions of it used the following addresses:
LOADADDR = 0x90000
STACKADDR = 0xB0000
STACKSIZE = 0x08000

And that usage caused serious compatibility problems with newer PS2Link versions, implying that they somehow use an area that overlaps the address range 0xAC000-0xB7FFF at least partly, and which might very well extend even further, beyond the limit 0x100000 where your program starts. I'm not sure if it does extend so far though, but it is a distinct possibility.

I think you need to study the PS2Link sources as well to resolve these potential issues.

Another possibility that needs to be considered is that your crashing is simply due to some action of your kernel during its initialization that is somehow incompatible with how real PS2 hardware works, even though it may have worked fine with the PCSX2 emulation.

Perhaps it would be useful for you to compile a special test version of the kernel, which simply displays a simple message showing basic boot success/failure. Then we could all try it with various launchers to find its real limitations.

Best regards: dlanor

I've managed to make the kernel boot, or so it seems. The problem in the end was not related to the loader actually, but was more a compiler/linker issue. To build such a new kernel i could not use the gcc from ps2toolchain, so i had to build a cross compiler myself (gcc 4.2.0) and after a bit of tries i found out that i had to compile a 64 bit kernel, and then convert the vmlinux elf to a 32bit one using objcopy. Now early printk is the next step.

This is the first signal of life from linux on the ps2, i'm sorry the imgae looks crappy, but it's acquired throught a cheap tv-in card

Nice work... this is running on the bare hardware with no RTE?

Yes, of course. Nothing strange about this actually. As far as I know the RTE is used to get access to I/O devices, and at this stage the kernel doesn't do anything like that.

I'm curious about this... Is it "regular" linux not PS2 linux package, right ?

I'm working on a modified linux version from linux-mips.com.
Of course that is not from Sony's PS2 linux package

PS: dlanor, if you are still following this thread, i found out that probably the reason why i cannot load the kernel at 0x8010000 is that i'm accessing kseg0 in user mode, is there a simple way to make ulauchelf change the mode to kernel?

alexp wrote:I'm working on a modified linux version from linux-mips.com.
Of course that is not from Sony's PS2 linux package

That's good to know. (Though I already assumed it.)

We certainly wouldn't want yet another Linux version whose stuff would be illegal to share with others in the PS2 community.

PS: dlanor, if you are still following this thread,

I always check new PS2-related posts on this site regularly, even when I don't post anything, so I'm still following this thread and will continue to do so.

i found out that probably the reason why i cannot load the kernel at 0x8010000 is that i'm accessing kseg0 in user mode, is there a simple way to make ulauchelf change the mode to kernel?

I really can't say, as I'm not that well informed on MIPS-specific CPU behaviour. I got my grounding in low level programming with much older and mainly work-related stuff, starting with 8080 and 6502 etc, later followed by 16/32 bit CPUs like 8086 and the 680xx family. But I didn't get much reason to study MIPS processors until I got involved with the PS2 homebrew scene, so all MIPS-specific details I know are those I've picked up since starting this hobby.

But if you can suggest some experiments to make then I'm willing to test it. But I don't want to risk losing compatibility to any normal ELFs in adding any new launch mode for yours, so any changes made will have to be verified as working both with your kernel and with normal ELFs.

That's not saying that a single method must be found that caters identically to both kinds of ELF, as we may also implement a secondary launch mode, allowing a launch to be made in kernel mode, if/when we have a working method for doing that. Then some changes can be made to the main config menu to allow ELFs to be linked for launching either in the traditional manner or in an alternate manner, the first of which would be your kernel mode launch.

We always intended to add more launch modes to uLE anyway, for other purposes (command line parameters etc), but so far there have been very few programs (almost none) that could use such features, so we haven't gotten around to it.

Best regards: dlanor

alexp wrote: PS: dlanor, if you are still following this thread, i found out that probably the reason why i cannot load the kernel at 0x8010000 is that i'm accessing kseg0 in user mode, is there a simple way to make ulauchelf change the mode to kernel?

It is possible for your application to put itself in kernel mode if thats what you need. Provided you do so early enough, and the PS2 kernel and exception vectors are still in place, there's a syscall you can make where the kernel sets kmode and returns. There's even a function which wraps this somewhere in ps2sdk. (enter_kmode or similar, iirc)

cherrif wrote:It is possible for your application to put itself in kernel mode if thats what you need.

The problem is my app need to be _loaded_ in kseg0. So the loader itself must run in kernel mode. I think I'm going to write a simple bootloader myself.

dlanor wrote:But if you can suggest some experiments to make then I'm willing to test it.

I've a modified version of demo1.elf from ps2tut_01, that tries to write a byte in kseg0. Normally the apps goes black screen, because it's running in user mode. But if I add a simple assembler snippet that puts the processor in kernel mode, the the write access is succesfull and the demo goes on as always. If you want this demo as a test case i can send you the code

alexp wrote:

dlanor wrote:But if you can suggest some experiments to make then I'm willing to test it.

I've a modified version of demo1.elf from ps2tut_01, that tries to write a byte in kseg0. Normally the apps goes black screen, because it's running in user mode. But if I add a simple assembler snippet that puts the processor in kernel mode, the the write access is succesfull and the demo goes on as always.

And does that 'snippet' work effectively this way even when the ELF file is launched by uLE ? If so, then it seems you've already solved your main problem, as that is then also what your kernel needs to do. (Or rather a 'preloader' ELF that in turn launches the kernel after switching to kernel mode.)

If you want this demo as a test case i can send you the code

Yes, please do, or rather post it here in this thread. Even if you no longer need uLE changes to have it launch your kernel, I'm always interested in such solutions, and since that may be the ultimate fix for the issue raised in this thread, you should be well on-topic posting the code right here.

Best regards: dlanor

I have written a loader for linux-2.4, but there was a problem that an alignment exception was raised when interrupts in linux are activated. I believe that this exception was raised in the my loader and occurs when interrupts are enabled. I didn't find the error yet. When linux ignores this interrupt it started.

http://freenet-homepage.de/ps2dev/kernelloader.tgz

Kernel is loaded in user space and later copied into correct space. ELF program headers need to be configured accordingly.

The "kernel" directory shows an example how to print something on the screen in kernel mode. This is needed for debug output, because IOP is not accessible.

There is also mrbrown's sbios included which can be used to communicate with IOP, but I didn't figured out how to set RPC up.

Hi. I was just pointed to this thread from my PS2 thread over at the Gentoo Forums. I am totally astounded by this since I had struggled to get Linux versions beyond 2.4.20 and gcc versions beyond 3.0.4 to work. I admit my knowledge was quite lacking but I was learning as I went. You've just jumped light years ahead though. I always knew it would be possible to boot a 64-bit 2.6 kernel without the RTE but I didn't think anyone was going to come up with it just like that.

I am unsure about just how far you've got. Is that one line all we've seen so far? I'm guessing most of the drivers still have to be updated? I have a framebuffer driver working on 2.4.20 if you're interested but I guess the simple text-mode VGA driver will suffice for now.

Which processor type are you building for? As far as I understand it, without any R5900-specific modifications, only MIPS I will work due to the R5900 being not quite compatible with any of the later types. I thought MIPS I wasn't capable of 64-bit though? Please enlighten me.

I'm not sure how much use I'd be but I'm willing to help with updating some of the drivers. If we can get this fully working, I'll then be able to focus my efforts on Gentoo PS2.

I'm quite curious about this thread on (non Sony official) Linux on PS2.
But I'm wondering about the PS2 memory limitations for running a modern distribution... So only a very cut down I see possible.

In this case, what is the possiblity of having a GUI/window manager (a light weight one, of course) ?

There's obviously a lot to be said about that. I've been basing Gentoo PS2 on uClibc in order to minimise the memory usage by applications. I've also been investigating certain other possibilities such as graphical applications without X. This can be achieved using things such as the framebuffer, DirectFB, DFBGTK, DirectFBGL and so on. The existing PS2 driver for SDL is probably also worth a look.

I don't want to drive this thread off topic with talk about such things though. This is my Gentoo thread and this is the Gentoo PS2 Trac.

hi,
i've got quite far in the boot sequence now. next thing i've to do is writing a console driver, but now i'm under examination at university, so i've to wait until second half of july at least. i'm not yet releasing a patch because the code isn't quite in shape, ps2 seems to have a 32 bit address space, but i can manage to run only 64 bit kernel, so there are a bunch of hacks around to build a 64bit with 32bit address space. i still have to find a proper way to load the kernel in kseg0.

The kernel is compiled for an r4600 cpu, but there are a bunch of hacks to the gcc code, to force it not to use 64bit instruction not supported by r5900.

About memory limitation: we can always run a lightweight environment like xfce, of course my project is more oriented to get a kernel run for educational purpose and not really focused on make a working distribution.

Anyway, the long term plan is to use the libraries developed for ps2sdk as a backend for i/o drivers, do you think that will be possible?

Good luck with your exams. The word still gives me the jitters after two years.

That sounds like a fairly managable hack. I think that's roughly what the older gcc patches did too but there was a lot of other stuff in there that tried to use the processor's extra capabilities, such as the 128-bit instructions. This made it difficult to work out the real reason why I couldn't quite get gcc 3.2.2 working under Linux. I never did manage to figure it out. I quickly taught myself MIPS assembly recently in an attempt to understand the problem better but I haven't had time to get back into it since then.

Did you make changes to binutils too? We managed to bring the old patches up to date for version 2.16.1. Despite the problems with gcc, I'm confident that binutils was working properly. If this is of any use to you, let me know.

I have never actually used the ps2sdk myself since I come from the Linux side of the fence rather than the ps2dev side. These two communities seem to have grown apart since the Independence Exploit was discovered. Maybe this can bring them closer together again. :) I had wondered myself about whether it would be possible to use the ps2sdk. Technically speaking, I can see no reason why not. I'm not sure if it could simply be linked in statically. If that isn't possible then the code could at least be incorporated somehow. But legally speaking, there may be a license issue. It seems that the AFL is not GPL compatible. :( I suspect this may change with GPL 3 though. Let's hope we don't have to wait too much longer for it. It looked as though the kernel wouldn't be switching to it for a while but I think it's looking more likely now.

I said that the VGA text console driver would suffice but I think I was wrong about that. Even if you're using the VGA adapter, you still need to use a driver that works with the GS. The driver that was written for the original distribution was not all that pretty. I seriously recommend the framebuffer driver instead. The only problem with it is that you can't run programs that attempted to use the GS directly as some of the home brew stuff did. I never verified this myself though. Maybe that can be addressed somehow. The driver was original written for 2.2.1 but I managed to port it all the way up to 2.4.33, despite never having hacked the kernel before. I don't have that particular patch to hand but here is the patch against MontaVista's 2.4.17 kernel. I should add that 2.4.33 didn't work in general but I was at least able to see the kernel booting on the framebuffer.

I understand that you don't want to let the code out at this point in time but I would seriously appreciate a sneak preview. What you've managed to achieve is what I'd been aiming for and I'd really like to know how you did so that I can understand if for myself. I'd keep it close to my chest too if you wanted, though having said that, I'm not sure if that's actually allowed under the GPL. Damn licenses! Heh.

Finally, I found this. Not sure if it helps with the KSEG0 issue at all. I was just trying to remind myself what it was.

I decided to look into the license issue a little further. From what I gather, using the SDK together with the Linux kernel would be legal as long as no binaries are distributed. Everyone would have to build the kernel from source. Could be worse! With any luck, the AFL will turn out to be GPL3 compatible and the kernel will make the switch.

Chewi wrote:With any luck, the AFL will turn out to be GPL3 compatible and the kernel will make the switch.

... Torvalds position on that is still unclear, anyway license issues are not my primary concern. SDK code can always be called as a program in userspace when linux is up and running.

*Waiting patiently for patches / build instructions*

I assume the serial port would be useful for debugging the kernel to be?
http://www.kanshima.net/mirrors/ee-sio/ps2-ee-sio.html

Haha you wouldn't catch me trying something like that. My hands are shakey as hell.

Here you are a bit of patches, the included readme should explain a bit what to do. http://allievi.sssup.it/tatiana/linux-2 ... s2.tar.bz2

That's fantastic, thanks. I'll definitely be having a play with this. Keep us posted on any developments.