I was unsuccessful in getting dualhead working using only the commandline aticonfig tool, so after a bit (actually alot :) of experimenting I was able to get working with using a combination of aticonfig and the Catalyst Control Center (amdcccle) tool.

First thing I did was create an initial xorg.conf configuration file using the command below in shell, which sets up a basic dualhead configuration which can be altered using aticonfig and the Catalyst Control Center.

sudo aticonfig –initial=dual-head –overlay-type=Xv

I then rebooted (I was not always able to reload the driver by just restarting X). I then started the Catalyst Control Center by typing the following in a shell

sudo amdcccle

Its important to use sudo or else you wont be able to change the configuration. In the “Display Manager” section it is possible to setup the multi-display and specify how the screens are arranged. After you set this, reboot once again.

What should happen now is that when you restart you get the same image on both screens (mirrored/cloned). You now need to enter the GNOME Screen Resolution configuration application (which in the default Ubuntu GNOME  setup is located under System – Preferences). Here you should now be able to change the size of the desktop so that it uses the entire screenspace on both screens.

One thing to note is that I also tried the very latest (9.2) ATI FGLRX driver, using this driver I actually got 2 screens in the GNOME Screen Resolution application. They were positioned on top of each other (Mirror Screens was checked), which was  hard to see (and figure out). But you can actually click on the screens and then drag and arrange them so that they match you physical screen configuration. So you may want to try the latest driver if the one in the Ubuntu repositories does not work for you.

For more information, click here.

Below is the output from lspci -vnn

01:06.0 Multimedia video controller [0400]: Conexant Systems, Inc.
CX23880/1/2/3 PCI Video and Audio Decoder [14f1:8800] (rev 05)

    Subsystem: AOPEN Inc. Device [a0a0:6f05]

    Flags: bus master, medium devsel, latency 32, IRQ 17

    Memory at e3000000 (32-bit, non-prefetchable) [size=16M]

    Capabilities: <access denied>

    Kernel driver in use: cx8800

    Kernel modules: cx8800

After some searching I found some information on this card on the  video4linux-list. Turns out that this card is a Leadtek Winfast 2000XP Expert OEM variant, which you can also conclude from searching for ‘LR6611′ in Google.

I used the information from the video4linux-list to configure the card by the following line to /etc/modprobe.d/options

options cx88xx i2c_scan=1 card=5 tuner=38

Now the card will be correctly configured when booting Ubuntu. You can also test the card without rebooting, by entering the following commands in a shell.

sudo rmmod cx8800
sudo rmmod cx88xx
sudo modprobe cx88xx
sudo modprobe cx8800

You can watch TV channels in tvtime now. When scanning for channels, do not worry about the “no signal” message, the scanner will eventually find the available channels.

S-video and video input quality has also greatly improved compared to the default cx88xx settings for this card.

Since I wrote this post 5 months ago I havn’t been experiencing any issues with the EN12000EG when using it at 1200 MHz. However, 22 days ago I rebooted my EN12000EG and by mistake I forgot to set the CPU frequency to 1200 MHz, I didn’t realise this until about a week ago when I saw that the Gnome CPU Scaling Monitor was reporting the CPU frequency as 400 MHz (ondemand governor). For this period of 22 days I’ve been using the server as I normally would, which 5 months ago would freeze the system within a week when using CPU scaling.

My best guess to why this is happening is probably a change in the Linux kernel which either fixed or got around this issue. The kernel I’m currently using is Linux 2.6.24-21-generic i686 GNU/Linux on Ubuntu 8.04 with all updates installed.

You might also want to check the lastest comments, as Sam33 is reporting freezes on Debian Etchnhalf, which he suspects are related to the PATA driver.

Original Post

Little over a month ago I bought and built myself a Mini-ITX computer to use as a headless print/file/media/etc. server. For the motherboard I got a VIA EPIA EN12000EG with a 1200 MHz CPU, because it was passively cooled. I put it inside a Morex 3688 chassis without using the chassis fan. After using it for a while, the system would “randomly” freeze completely. This would typically happend when I “stressed” system, eg. transfering files, printing and using VNC at the same time. There was no rise in CPU temperature when this happend, so I didn’t think it was because the motherboard wasn’t properly cooled without any fans running.

The longest uptime I had until this point was about 6 days, but the computer would often just freeze after a few days use.

So I thought it might be an I/O problem and I therefor updated the 1.07 BIOS to version 1.09, but the only thing I could tell changed was the CPU temperature was now reported as being around 20 °C instead around 45 °C previously with the 1.07 BIOS. Since this didn’t resolve the system freezes either, I then tried to update to Ubuntu 8.04 beta, hoping the issue might have been resolved in the new version, however the system would still freeze on me.

I had a problem with evolution-data-server using 90% of the CPU in Ubuntu 8.04, this is a known bug. I resolved it by just uninstalling evolution-data-server, as I don’t use Evolution.

sudo apt-get remove evolution-data-server

I had earlier found this “EN12000EG Freeze” thread at the VIA forums (registration required), where alot of different solutions had been suggested, I tried some of the easy ones like changing the BIOS settings, but that still didn’t resolve the problem. So I thought I’d try disabling CPU frequency scaling as suggested by rararasputin and this solution has worked for me so far.

First I disabled powernowd by in System -> Administration -> Services. However the cpu scaling software cpufreq is active and uses the On demand CPU scaling governor by default. There are few different ways to change this to the Performance governor, which will keep the CPU at 1200 Mhz. One way is to use the cpufreq-selector in a console like shown below

sudo cpufreq-selector -g performance

Another option, if you are using the Gnome CPU Frequency Scaling Monitor Applet, is that you can select the governor you wish to use using this applet. But first you need to enable user CPU scaling by the following command and answering yes to setting the suid for cpufreq-selector.

dpkg-reconfigure gnome-applets

Now you can left-click on the applet and choose Performance.

A thing to note is that this setting reverts to the default On demand when you reboot your system. I read that you can make it permanent by changing the policy_ac key to Performance in apps -> gnome-power-manager -> cpufreq using gconf-editor, however this doesn’t seem to work for me. Maybe because I use the force=acpi kernel option in /boot/grub/menu.lst and this somehow overrides the setting. If any one knows of a simple solution, please let me know :-)

As you can see from the partial screenshot below, my VIA EN12000EG based server ran for over 11 days before Ubuntu insisted that I reboot due to an update. In the 11 days I had tried to stress the system several times, for instance transfering files while updating Ubuntu over VNC and playing internet radio. Which would often freeze the system earlier, but after disabling cpu scaling, I’ve been unable to freeze the system.

My conclusion is that the VIA EN12000EG hardware has buggy CPU scaling support.

As a side note, I couldn’t get s-video output working with any other driver than the binary CN700 Unichrome Pro Driver. Otherwise everything else worked out of the box with both Ubuntu 7.10 and 8.04.

Update:

rararasputin posted his Openchrome xorg.conf with s-video support in the comments. Download formatted here.

Since this memory card could be used for launching PS2Link directly of the memory card itself or an USB Pendrive and thereby enabling PS2 programming on an unmodified PS2 console, I went ahead and bought one from the Codejunkies webshop (also available from Play-Asia).

I was unfortunate to get a memory card where built-in software was not installed, but after sending an email to Codejunkies, I returned the card to them and some days later I got it back and this time the built-in software did boot when the memory card was inserted to either PS2 memory card slot.

The built-in memory card manager takes about 25 seconds load, for the entire period there is a black screen. Below are some screenshots of the memory manager and how it shows up the PS2 memory card browser.

I was hoping I could just insert an USB pendrive to one of the PS2 USB ports, with PS2Link named RUNME1.ELF and it would boot, however none of my 4 USB pendrives were recognized by the built in memory manager. I tried FAT 12/16/32 file systems, also FAT32 W95 LBA, but none of them seemed to work. One of the pendrives I tried was the 16 MB Pendrive from Datel’s own Max Drive product, which is recognized in the Max Drive memory manager, which looks very similar.

Since the memory manager wasn’t helping me get PS2Link launched, I had to figure out some other way of getting it onto the memory card and so the “hacking” begins :-)

For transfering data to the memory card of my chipped PS2 I used ps2netfs.irx from PS2SDK. This IRX provides an interface to file systems on the PS2 over the network. I used fsclient as the client (part of ps2client package), combined with PS2Link/ps2client. Before you can access the memory cards with ps2netfs, you need to load the memory card IOP modules SIO2MAN and MCMAN from the BIOS. The following 3 commands below load ps2netfs with memory card support.

ps2client -t 1 execiop rom0:SIO2MAN
ps2client -t 1 execiop rom0:MCMAN
ps2client -t 1 execiop host:ps2netfs.irx

Once this was done, I could now browse the Memory Plus memory card.

fsclient dir mc0:

[Contents of mc0:]

drwxrwxrwx          6 04-08-2008 17:01:30 .
drw-rw-rw-          0 04-08-2008 16:53:54 ..
-r-xr-xr-x         14 04-08-2008 16:53:57 BEEXEC-SYSTEM
-r-xr-xr-x         14 04-08-2008 16:55:26 BAEXEC-SYSTEM
drwxrwxrwx          6 04-22-2008 02:29:47 BESLES-00000 MP

The BEEXEC-SYSTEM and BAEXEC-SYSTEM directories contain the same files, to support respectively European (E) and American (A) PS2 models.

fsclient dir "mc0:BEEXEC-SYSTEM"

[Contents of mc0:BEEXEC-SYSTEM]

drwxrwxrwx          0 04-08-2008 16:53:57 .
drwxrwxrwx          0 04-08-2008 16:53:57 ..
-rwxrwxrwx    1344000 04-08-2008 16:54:00 osd110.elf
-rwxrwxrwx    1344000 04-08-2008 16:54:06 osd120.elf
-rwxrwxrwx    1344000 04-08-2008 16:54:11 osd130.elf
-rwxrwxrwx    1344000 04-08-2008 16:54:17 osd140.elf
-rwxrwxrwx    1344000 04-08-2008 16:54:23 osd150.elf
-rwxrwxrwx    1344000 04-08-2008 16:54:29 osd160.elf
-rwxrwxrwx    1344000 04-08-2008 16:54:35 osd170.elf
-rwxrwxrwx    1344000 04-08-2008 16:54:41 osd180.elf
-rwxrwxrwx    1344000 04-08-2008 16:54:47 osd190.elf
-rwxrwxrwx    1344000 04-08-2008 16:54:54 osdmain.elf
-rwxrwxrwx        964 04-08-2008 16:55:13 icon.sys
-rwxrwxrwx      33688 04-08-2008 16:55:19 mcp.ico

These directories are what make booting an ELF of the memory card possible in the first place. Sony included support for updating the OSD (the software which starts when you power on your PS2 without any game in it) of the PS2 in the PS2 BIOS. The OSD looks for a osd1xx.elf on the memory, what ELF filename exactly depends on your PS2 model, hence thats why all the osd1xx.elf files are identical.

The reason this “exploit” hasn’t been discovered earlier is because the OSD ELF’s on the memory must be encrypted with MagicGate or the OSD won’t load the ELF’s. So it’s not really an exploit, just a feature protected by encryption. Even though the Memory Plus is a 64 MB memory card, which will be the main the selling point for the memory card, the more interesting part is the fact that Datel have managed to encrypt inject their own code into already encrypted ELF’s for this GateCrasher based memory card.

Anyway, returning to the original task of getting PS2Link to boot of the memory card. While listing the contents of the “BESLES-00000 MP”, I realised that this is the directory in which the RUNME1.ELF and RUNME2.ELF should be put, as it already contained a RUNME.ELF.

fsclient dir "mc0:BESLES-00000 MP"

[Contents of mc0:BESLES-00000 MP]

drwxrwxrwx          0 04-08-2008 16:56:54 .
drwxrwxrwx          0 04-08-2008 16:56:54 ..
-rwxrwxrwx     763200 04-08-2008 16:56:56 RUNME.ELF
-rwxrwxrwx        964 04-08-2008 16:57:09 icon.sys
-rwxrwxrwx      33688 04-08-2008 16:57:15 mcp.ico

First thing I did was make a copy of RUNME.ELF (should I accidently overwrite it) with the following command.

fsclient copyfrom "mc0:BESLES-00000 MP/RUNME.ELF" mplus-manager.elf

As you might have already guessed from the command above, the RUNME.ELF is the built-in memory card manager of the Memory Plus card. I tried to load the mplus-manager.elf (filename of RUNME.ELF copy) using PS2Link and it runs just fine.

This means that the files in the BEEXEC-SYSTEM and BAEXEC-SYSTEM directories are really just launcher files for the ELF files in the “BESLES-00000 MP” directory. What this also means is that the memory card manager can be replaced by a free one with more features (like support for my pendrives, which work with usb_mass).

I’m would be very interested in hearing from any one who might have a different version of the memory card manager (filesize of mine is 763200 bytes), as another version might have proper USB pendrive support.

I copied PS2LINK.ELF using the following fsclient command

fsclient copyto PS2LINK.ELF "mc0:BESLES-00000 MP/RUNME1.ELF"

I then rebooted my PS2 with the memory card inserted into the first slot and waited more than 25 seconds and nothing happend. So I decided to try something a bit simpler than PS2Link and tried my very own simple Torus demo from The Third Creation and it did boot ;-)

So the fun of debugging begins. The unknown factors in finding the bug(s) which caused PS2Link not to boot are, how is the ELF loaded by the encrypted launcher on the memory card and how is the method different from how ELF’s are normally loaded?

I suspected the issue might be with the arguments passed to PS2Link, as PS2Link uses these to figure out from which device it was booted. So I made a small PS2SDK application which prints the arguments to the screen using scr_printf(). However it turned out that this simple application did not boot of the memory either. In fact, the first line of code in main never got executed (changing BGCOLOR). This could only mean that the issue was within the crt0.s (C runtime entry point) code, so I commented all the code related to argument handling, as the launcher code probably passes garbage arguments to the ELF when it loads it and this case is not handled by crt0.s, which causes the PS2 to hang/crash. After doing this, my simple application did boot of the memory card. I made some quick changes to PS2Link to make it support the altered crt0.s and hardcoded the boot path inside the PS2Link source. And PS2Link booted of the Memory Plus card.

A precompiled version of the PS2Link 1.51 ELF which boots of the Memory Plus memory card is avaliable here.

A real patch should be made for crt0.s, so it would support the arguments passed by the Memory Plus loader without breaking any existing code. This task will require more time than I spent on getting PS2Link running. I will submit a patch for crt0.s once I get the time to develop it, unless some one beats me to it *hint hint* :-) This crt0.s patch is required to make any PS2SDK based applications boot of the memory card.

Once crt0.s is patched, making the required changes to PS2Link should be easy, if the Memory Plus card can be uniquely identified based upon the arguments passed to main().

Update:

Based upon the comment by PS2onCrack, I tried to format my Pendrives yet again to FAT32 and it turns out that one of my 4 pendrives is actually detected by the Memory Plus manager. In order to format it properly under Ubuntu I had to do the following: First find where its mounted with the df command (my pendrive partition mounts at /dev/sdb1). Then umount the partition.

sudo umount /dev/sdb1

Then use fdisk, to change system id of the partition to “W95 FAT32″

sudo fdisk /dev/sdb

Note that I use /dev/sdb (the device) and not /dev/sdb1 (the partition). With fdisk I used the t option (Change system id), then b for “W95 FAT32″, and finally w to writing the changes. I then formatted the partition to FAT32.

sudo mkfs.vfat -F 32 /dev/sdb1

Now my Noname 512 MB pendrive works with the Memory Plus manager. The following pendrives did not work: 1 GB Kingston DataTraveler, Datel Max Drive 16 MB and 256 MB MyCom MP3 Player.

I also realized that patching crt0.s in PS2SDK and making the necessary changes to PS2Link to make it boot of the Memory Plus card is not the best solution, as this will only fix all ELFs compiled against the updated PS2SDK and not all ELFs already available.

So instead I made a small Memory Plus ELF loader, which boots of the memory card and then tries to load an ELF correctly, which should work with most, if not all ELFs.

Download

• MPLUS-LOADER.ELF
• mplus-loader-src.zip (source)
  
• PS2LINK151.ELF (PS2Link 1.51 compiled from Subversion)
  

To make it work, rename MPLUS-LOADER.ELF to either RUNME1.ELF or RUNME2.ELF and put in on the Memory Plus card, as described in the Memory Plus instructions.

Then take the ELF you wish to run (you can test with PS2LINK151.ELF) and rename it EXECUTE1.ELF (if you want to boot it when the Memory Plus card is inserted into memory card port 1, otherwise EXECUTE2.ELF for port 2) and put it either on the Memory Plus card or your USB pendrive.

Now boot the Memory Plus card in port 1, this will now load the Memory Plus ELF loader (RUNME1.ELF), which will then load the EXECUTE1.ELF of either the Memory Plus card or the USB pendrive. If the ELF does not exist, the Memory Plus manager will be booted.

Update 2:

I’ve updated the Memory Plus Loader, so now more ELFs should boot. Tested with uLaunchELF v4.12 and SMS 2.8 (Rev. 1). Also I’ve added a seperate Memory Plus Loader ELF which patches the Memory Plus manager to NTSC mode before starting it. To make it work you just need to add RUNME1.ELF (or RUNME2.ELF) and not have EXECUTE1.ELF (or EXECUTE2.ELF) present, then the Memory Plus manager will be booted in NTSC mode.

Download

• MPLUS-LOADER2.ELF
• MPLUS-LOADER2-NTSC.ELF
• mplus-loader2-src.zip

Update 3:

The Memory Plus Loader has been updated to stop the CD/DVD drive for spinning. It’s now also possible to initialize the CD/DVD drive. The solution was found by ffgriever for the Free McBoot/FreeVast project. There are some people reporting that this does not work with all consoles, however it works with my PAL console :-)

Download

• MPLUS-LOADER3.ELF
• MPLUS-LOADER3-NTSC.ELF
• mplus-loader3-src.zip

This demo is a very overlooked PS2DEV production. I recommend checking it out, if you have a PS2 capable of running CD-R’s. The source code for it is also available in the PS2DEV.org Subversion repository, you can obtain it with the following Subversion command:

svn co svn://svn.ps2dev.org/ps2ware/trunk/BPDemoHarness

The source code will most likely require some tweaking to make it compile against the the current version of PS2SDK.

Cosmito has been doing alot of addition work on my quick PS2 port of doom lately, recently adding sound support. To keep updated on the latest PS2Doom changes,  check Cosmitos website.

Original post:

Doom by id Software seems to available for every platform known to man, except for the PlayStation 2. So I wondered how long it would take to port it over to PS2 and the answer to that question turned out to be less than 3 hours. Using the PS2 port of SDL, gsKit (SDL requires it for video) and PS2SDK, all available from PS2dev.org Subversion repository and a SDL port of Doom available here, I managed to get a very basic (read: hackish) port of Doom running on the PS2 without much effort.

I’ve only tested the port over PS2Link and it will most likely not run from a CD-R. There is no sound, however there is support for sound in PS2 SDL, but does not appear to work with Doom and I havn’t investigated the cause. Saving and loading of games works, as they just save to host/PC. The Dualshock controls are as follow (USB keyboard and mouse are untested)

Left Analog Stick : Move

Cross             : Enter

Square/R1         : CTRL / Fire

Circle/R2         : Space / Open doors

Triangle          : Escape

L1                : x

L2                : y

L1 and L2 are for entering savegame names

I will not continue to work on this port, it was just a quick nostalgic proof of concept port :-)

Download: ps2doom-src.zip ps2doom-bin.zip (Binary includes shareware data)

Update: Follow this thread for further work on this port.

Update 2: A lsdldoom PS2 port by Jason Yu with sound effect support has surfaced. I’ve compiled the source into a single ELF with the DOOM shareware data included, which should run from CD-ROM, USB, etc (not tested). Included in the archive is also a ps2-packer compressed version of DOOM.ELF named DOOMP.ELF.

Download: lsdldoom-ps2-bin.zip

To get the GeForce 7100 working I downloaded Envy and then manually selected the Nvidia 169.09 driver, which was then downloaded and installed. I used nvidia-settings to configure the graphics card.

The sound card (HDA Intel driver) is not supported by the version of ALSA included with Ubuntu 7.10, it is however supported by the latest ALSA version. So in order to get it working I had to download, compile and install the lastest ALSA driver myself, there is a guide available here which describes the process.

The network adapter works out of the box, it uses the forcedeth driver.

My new system would freeze on me after a few hours of use, I suspected the Gigabyte GA-73PVM-S2H motherboard was to blame for this. After checking the Gigabyte website for my motherboard, I saw there was a F5 BIOS update to my F2 version BIOS. Since I use Ubuntu, I couldn’t use their @BIOS Windows utility for updating the BIOS, so I had to use the BIOS built-in Q-Flash which supports updating from an USB stick.

First I downloaded the BIOS update and used Wine to extract the update file from the .EXE update available. When I then first tried to put the update file on my USB memory stick and used Q-Flash I got an BIOS ID checker error. This error is apparently related to the file system used on the memory stick, since after I formated my memory stick to FAT-16 with mkfs.vfat -F 16 /dev/sdc1 (my memory stick shows up at /dev/sdc1, used df to see where your memory stick is located) I was able to update my BIOS successfully, and I havn’t experienced any freezes since.

Update: The tutorial has been updated with a link to instructions on how to build the toolchains in Windows Vista, provided by chip.

Update 2: It appears that the PS2 toolchains, when built in MinGW, do not always generate correct code. If a solution to this problem is found, I will post it here and update the MinGW tutorial. Until then you can follow the progress of overcoming the problem in this thread at the PS2Dev.org forums.

Update 3: ragnarok2040 has now supplied a patch the PS2 toolchains to fix the code generation bug and the ps2toolchain patches have been updated. Today I’ve rebuilt the PS2 toolchains for MinGW and uploaded the new binaries. I’ve tested them and verified that the bug is fixed, great work ragnarok2040!