ps2 linux on usb memory

[SlimSilver]

OH! I sort of figured it was a version16. That link that was given me, those 6s sure look like 8s.

[deba5er]

@Mega Man

I was thinking more about the problem. You have a slim v12, but is USB running stable? Then the problem is probably not caused by RPC.
I want to know if network was working on your v12 before I released kernelloader 2.0? Sorry, I begin to confuse the different answers in this thread and I think there was no answer to this question in this thread before.

Using my ps2linux/run_slim/config.txt (select and load within kernelloader) I ran kloader1.9.elf and it hung with the usb drive access light flashing after the /etc/init.d/neworking script finishes with "Configuring network interfaces: Done

The same configuration with kloader2.0.elf worked. I then changed back to kloader1.9 and ran again as a double-verify and it hung at the same place. So v12 with my config and distro only works with kloader2.0.elf.

[SlimSilver]

Well, like I said. I have no problem helping you lot test some things to get usb working and other drivers to be more compatible with this system.

[deba5er]

@SlimSilver

I appreciate the offer to test and will bear in mind prior to release of v0.8, which has quite a few todos left, and unfortunately the reliable usb boot solution looks toughest of all.

[noiseand]

Voltando ao som no linux do pstwo...

Algum de vocês já testaram placa de som usb?

[noiseand]

Alguma experiência no uso do firefox?

[deba5er]

You can get Firefox 2.0.0.19 from this link until the end of October when it goes offline (there is a chance they will have an archive so that these files will survive on a static webpage after that): http://playstation2-linux.com/files/moz ... tk1.tar.gz

I have used it, and it is too memory intensive to work well with the PS2's 32MB. It is very SLOW.

Você pode obter o Firefox 2.0.0.19 partir deste link até o final de outubro, quando entrar em modo offline (há uma chance que eles terão um arquivo para que esses arquivos vão sobreviver em uma página estática que depois): http://playstation2-linux .com/files/mozilla-ps2/firefox-2.0.0.19.en-US.linux-mipsel-gtk1.tar.gz

Eu tenho usado ele, e ele é muito intensivo de memória para funcionar bem com o PS2 32MB. É muito lento.

[deba5er]

Sound in PS2-Linux on the PSTwo only works under the following conditions according to peterdcrees - the two sound .irx modules from the official Sony PS2-Linux kit Run Time Environment (RTE) are used (place in mc0:/kloader) and nothing is plugged into the USB slots (he notes a conflict).

PS2-som no Linux no PSTwo só funciona sob as seguintes condições de acordo com peterdcrees - o som duas. Módulos IRX da oficial da Sony PS2-kit Linux Run Time Environment (RTE) são utilizados (local em mc0: / kloader) e nada está ligado ao slots USB (ele observa um conflito).

[noiseand]

Entendi, então para usar a placa de som interna eu não posso conectar, mouse, teclado e pendrive na usb? Há conflito de irq ou endereçamento?

Você já tentaram usar uma placa de som externa, é possível? Já testei alguma em pc com linux e deram certo.

Minha idéia é montar uma central multimedia usando o pstwo, baixando videos do youtube em mp4 ou assintindo online mesmo. O dillo não permite isso e o firefox tem travado o console durante o carregamento.

Qualquer tentativa de usar o sms, argon, maxmedia, ps2media, etc, não deram certo, a não ser usando os vídeos em divx, xvid, ou mpg.

[SlimSilver]

Hmm ESR doesnt seem to work for me. It just shows a black screen after the title screen.

[deba5er]

@noiseand

I understand, then to use the internal sound card I can not connect, mouse, keyboard and the USB stick? There were conflicting irq or address?

Peterdcrees noted this problem where the v14+ Slim PSTwo would not work with sound unless he 1) used the RTE modules from the official Sony PS2-Linux kit in the mc0:\kloader directory, and booted PS2-Linux over the network. So for now for Slim users, sound is very difficult to get working.

Peterdcrees notar este problema quando o v14 + PSTwo Slim não iria trabalhar com o som, a menos que 1) os módulos utilizados RTE oficial da Sony PS2-Linux kit no mc0: \ diretório kloader e PS2 iniciou-Linux através da rede. Então, por agora para os usuários Slim, o som é muito difícil conseguir trabalho.

[bruno.bertechini]

What kernel version is being used to boot linux over nfs?

I am using the fat_and_slim_v2 and the following parameters:

ip=dhcp root=/dev/nfs rootfstype=nfs rootflags=0 nfsroot=IP_ADDRESS:/ps2

I am getting RPC errors before init starts...

I guess it is because the modules being loaded.

What is the recommended configuration for this kernel to work over nfs?

Bruno

[bruno.bertechini]

I removed all usb devices and it passed the RPC errors.

Without any usb devices I got into the kernel message:

NFS: mount program didn't pass remote address!

And yes, I am passing ip address as per my previous post.

Any idea guys?

[deba5er]

@bruno.bertechini

Please read this page (3) from the psx-scene forums and look for peterdcrees info. It appears that you may not be able to do this from kernel parameters alone, and you will need a modified initrd. You could do this using my initrd.usb2.install.gz, and drop to the bash shell to enter the commands noted by peterdcrees.

http://psx-scene.com/forums/showthread. ... 799&page=3

I have a samba version working but am not too happy with the speed to post yet. NFS I am sure is more efficient.

[deba5er]

I am running the same SMB (Windows Share) PS2-Linux partition from both version 12 and version 15 PS2 Slims and want to document the difference in case someone (Mega Man?) has an explanation. As of this morning my SMB PS2-Linux distro stability problems are resolved and I'm trying (unsuccessfully so far) to make sound work for the version 15 PS2 (and presumably others).

Kloader2.0.elf, mcboot 1.8b, uLE 4.39
neither PS2 has a hard mod

I use the same memory card, AV cable, controller, power supply, and usb keyboard/mouse combo for these tests. That means the loader and everything else including the configuration files are the same. The only thing different is the swapped version 12 and version 15 consoles. No disc in the consoles for these tests.

Version 12 works with all kloader modules for "restore defaults" slim EXCEPT RTE libsd.irx and sdrdrv.irx <- used to enable sound.

Version 15 in the same configuration works fine EXCEPT will not accept the keyboard/mouse combo (usb) or usb mass-storage device and gets these errors:

hub.c: USB new device connect on bus1/2, assigned device number 13
usb_control/bulk_msg: timeout
usb-ohci.c: unlink URB timeout
usb.c: USB device not accepting new address=13 (error=-145)

The above repeats while a device is connected, incrementing (in the above example had already incremented to "13").

When the device is removed:
hub.c: Cannot enable port 2 of hub 1, disabling port.
hub.c: Maybe the USB cable is bad?
hub.c: failed adding a new device. Address=13

I realize that mixing RTE .irx modules and kernelloader/TGE modules may not be ideal, but since it works so well on the version 12 PS2 I am wondering if someone knows what differences between these two versions would account for this problem so that maybe a fix can be made?

[dlanor]

@deba5er:
I don't have a solution for you, but considering which console models are involved, and that only USB errors are involved, this inescapably reminds me of the problems experienced when using CodeBreaker on these consoles.

CodeBreaker does work on both of them, but on a v14 or later model it will freeze to an almost standstill if any USB device whatsoever is connected (it does still run, but with something uselessly wasting nearly all CPU time). It doesn't matter what type of device it is, even just a mouse or just an empty hub will have the same effect. If any USB device whatsoever is connected to either USB slot this freeze will happen.

This is not at all the same problem you get, but I still think that the basic reason for it is the same, which is this:

In v14 Sony removed the original Dev9 chip, to kill the ability to run HDLoader, but in so doing they also killed the original network interface, which then had to be moved to another chip. This rearrangement of the hardware design apparently also involved some modification of the USB interface (sorry but I have no details on that), which in turn caused some old drivers to malfunction, as it was not possible to make the new hardware implementation fully identical to the old one.

Apparently the change was optimized to keep existing games compatible (which sometimes use USB for alternate controllers), and as luck would have it this also kept most homebrews compatible. But compatibility was lost to USB drivers of both CodeBreaker (which probably made Sony cheer) and of PS2Linux (which Sony stopped caring about long ago).

What now needs to be done is that someone with insight into PS2Linux kernel programming (thus not myself) should rewrite its USB drivers based on the functional USBD.IRX and USBHDFSD.IRX already existing for normal homebrews, since those work perfectly on all PS2 and PSTwo models.

Best regards: dlanor

[deba5er]

@dlanor

Thanks. It's sort of above my head right now. I dug around the ps2 linux kernel and found the io base address and IRQ which are:

from usb-ohci-ps2.c:
/*
* attach OHCI device
*/
ret = hc_add_ohci((struct pci_dev *)NULL, IRQ_SBUS_USB,
(void *)KSEG1ADDR(0x1f801600), 0,
&ps2_ohci, "usb-ohci", "builtin");

from irq.h (decimal not hex):
#define IRQ_SBUS_USB 42

I note this is different in the PS2SDK (from usbhw.h):
#define USB_REGBASE 0xBF801600
#define USB_INTR 0x16

However I may be looking in the wrong places...

Here's what I see while in PS2-Linux:
/proc$ cat interrupts
CPU0
2: 127161 EE INTC V-Blank start
9: 210042 EE INTC timer
16: 0 EE DMAC VIF0 DMA
17: 5219 EE DMAC VIF1 DMA
18: 207072 EE DMAC GIF DMA
19: 0 EE DMAC fromIPU DMA
20: 0 EE DMAC toIPU DMA
21: 120530 EE DMAC SIF0 DMA
22: 66589 EE DMAC SIF1 DMA
24: 0 EE DMAC fromSPR DMA
25: 0 EE DMAC toSPR DMA
33: 1740 GS GS FINISH
42: 0 IOP usb-ohci
ERR: 0

[dlanor]

@dlanor

Thanks. It's sort of above my head right now. I dug around the ps2 linux kernel and found the io base address and IRQ which are:

from usb-ohci-ps2.c:
/*
* attach OHCI device
*/
ret = hc_add_ohci((struct pci_dev *)NULL, IRQ_SBUS_USB,
(void *)KSEG1ADDR(0x1f801600), 0,
&ps2_ohci, "usb-ohci", "builtin");

from irq.h (decimal not hex):
#define IRQ_SBUS_USB 42

I note this is different in the PS2SDK (from usbhw.h):
#define USB_REGBASE 0xBF801600
#define USB_INTR 0x16

However I may be looking in the wrong places...

No. I think you may be onto something right there.

The base addresses 0x1f801600 and 0xBF801600 clearly represent exactly the same range of physical addresses, only remapped to different logical address ranges.

And if the interrupt number is also different (really ?) that could wreak untold havoc with any attempt to really use the device. But then I'm surprised that any access would work at all, to the extent it has done so in our testing. (I could boot one setup made by a v7 on my v15. It was not problem-free, but it did at least boot.)

The address difference may be very related to the difference in how the default video mode can be detected in old VS new console models. For old models it can be done just by checking the contents of a single byte at a known (ROM ?) location, but in newer consoles that byte is not accessible there. Instead it is necessary to make such tests differently (I always read rom0:ROMVER for that). I suspect that Sony may have changed some of the alternate range mapping just to mess things up for unauthorized programmers (including all homebrew).

In any case, it is a definite fact that the normal homebrew drivers for USBD and USBHDFSD work fine on new consoles, so their methods are what you (or some other PS2Linux coder) need to reimplement for new PS2Linux USB modules to be compatible with all PS2 and PSTwo consoles.

Here's what I see while in PS2-Linux:
/proc$ cat interrupts
CPU0
2: 127161 EE INTC V-Blank start
9: 210042 EE INTC timer
16: 0 EE DMAC VIF0 DMA
17: 5219 EE DMAC VIF1 DMA
18: 207072 EE DMAC GIF DMA
19: 0 EE DMAC fromIPU DMA
20: 0 EE DMAC toIPU DMA
21: 120530 EE DMAC SIF0 DMA
22: 66589 EE DMAC SIF1 DMA
24: 0 EE DMAC fromSPR DMA
25: 0 EE DMAC toSPR DMA
33: 1740 GS GS FINISH
42: 0 IOP usb-ohci
ERR: 0

This only shows that the USB driver code has been loaded and initialized, but tells us little about its validity, except that starting it didn't kill the system... But whether it is working correctly or not is anyone's guess given only the above...

Best regards: dlanor

[deba5er]

@Mega Man,

Just wondering if you could help with the USB problem noted above?

[Mega Man]

The renumbering of the USB device happens if the USB interrupts are not working. I got the same behaviour with my v15, when using the sound modules from RTE. As far as I remember, USB was working after changing from "intrelay-direct-rpc.irx" to "intrelay-dev9-rpc.irx". The default configuration is here wrong. I fixed this in CVS. This will not solve the problem on heavy USB load (system hangs).
I currently don't have a way to debug it, because the system hangs before it can print my messages on the screen. The HDD-LED is removed in v15, so I can't use it for debugging. I don't know where to get the serial SIO signals.
I think it is possible to move the USB driver from Linux to IOP side. The old Wii Linux uses a similar solution. So the ps2sdk usbd.irx can be used. I already did this for network. This may be easier than debugging deadlocks.
I don't think that IOP and EE use the same IRQ register. The USB IRQ can't be signaled to EE. One of the intrelay modules is required. The module is running on the IOP side and receives the USB interrupts. Then the module signals an interrupt to the EE. The interrupt number is different. This is not working on the slim PSTwo (including v12), so I used DMA transfers from IOP to EE to signal an interrupt. RPC uses the same DMA transfers.

[dlanor]

I think it is possible to move the USB driver from Linux to IOP side. The old Wii Linux uses a similar solution. So the ps2sdk usbd.irx can be used. I already did this for network. This may be easier than debugging deadlocks.

I agree that this does sound like the best solution, as the current USBD driver of PS2SDK has proven to work very well for normal homebrew on all the PS2/PSTwo models.

I don't think that IOP and EE use the same IRQ register. The USB IRQ can't be signaled to EE. One of the intrelay modules is required. The module is running on the IOP side and receives the USB interrupts. Then the module signals an interrupt to the EE. The interrupt number is different. This is not working on the slim PSTwo (including v12), so I used DMA transfers from IOP to EE to signal an interrupt. RPC uses the same DMA transfers.

Then some such method may still be needed to keep the EE side of the linux kernel happy, but I don't think this will be a problem as you say v12 already differed from older models in this, making it similar instead to the later models like v14 etc. So that method which already works for v12 should also work for v14+, as long as the USBD driver is also replaced as you said above, to work with the new hardware of v14+.

Best regards: dlanor

[deba5er]

@Mega Man

I got the same behaviour with my v15, when using the sound modules from RTE. As far as I remember, USB was working after changing from "intrelay-direct-rpc.irx" to "intrelay-dev9-rpc.irx". The default configuration is here wrong. I fixed this in CVS.

Thanks for the info - I tried many different configurations but could not find one to work with my v15 for RTE two sound modules, working USB keyboard. Can you post yours or PM it?

[noiseand]

Ola!

Pelo que entendi o "kloader2.0.elf" já vem com vários módulos embutidos, correto?

Mas posso colocar aqueles que eu desejar na pasta mc0:/kloader que serão carregados, não é isso?

Por acaso algum de vocês tentou usar os módulos "AUDSRV.IRX", "LIBSD.IRX", "SDRDRV.IRX" e "DMARELAY.IRX"?

Estou com o browser Netfront e ele reconhece a placa de som e rede numa boa, não testei com o pendrive conectado.

Algum sucesso nos 70001?

Já pensaram em montar uma espécie de livecd com o Linux?

Abçs

[deba5er]

@noiseand

Hello!
As I understand the "kloader2.0.elf" comes with several modules built-in, right?
But I put those I want in the mc0: / kloader that will be loaded, is not it?
Did any of you tried to use the modules "AUDSRV.IRX", "LIBSD.IRX", "SDRDRV.IRX" and "DMARELAY.IRX"?
I'm with the Netfront browser and it recognizes the sound card and a good network, not tested with the USB connected.
Some success in the 70,001?
Have you thought about setting up a kind of livecd with Linux?

Abçs

Putting RTE modules in mc0:/kloader is correct.
I have used modules LIBSD.IRX and SDRDRV.IRX (together) from RTE to get sound on version 12 and 15 PS2. There is a known problem with the USB though, which is worse when those modules are loaded (cannot use keyboard/mouse).

I don't have the 70001 model to test.
A livecd would be neat, but at this time I don't have plans for it.

Colocar módulos RTE em mc0: / kloader está correto.
Eu usei módulos LIBSD.IRX e SDRDRV.IRX (em conjunto) de RTE para obter som na versão 12 e 15 de PS2. Há um problema conhecido com o USB, porém, o que é pior quando esses módulos estão carregados (não pode usar teclado / mouse).

Eu não tenho o modelo 70001 para testar.
Um livecd seria ótimo, mas neste momento não tenho planos para ele.

[Mega Man]

@Mega Man

I got the same behaviour with my v15, when using the sound modules from RTE. As far as I remember, USB was working after changing from "intrelay-direct-rpc.irx" to "intrelay-dev9-rpc.irx". The default configuration is here wrong. I fixed this in CVS.

Thanks for the info - I tried many different configurations but could not find one to work with my v15 for RTE two sound modules, working USB keyboard. Can you post yours or PM it?

Now I checked it again and I recognized that changing the module doesn't help. I think that the sound modules were disabled while testing. I decided to find the cause for the problems. My results are (v15):
- USB is not working if libsd.irx and sdrdrv.irx are loaded.
- USB is working if libsd.irx is loaded and sdrdrv.irx is not loaded.
- USB is working if libsd.irx and sdrdrv.irx loaded and "112 SBR_SOUND_INIT" is disabled.

The module freesd.irx has the same behaviour as libsd.irx regarding USB influence.

So I checked what SBR_SOUND_INIT is doing. This calls SdInit() which calls InitSpu2() and this finally does:

Code: Select all

*U32_REGISTER(0x1570) |= 8;

This register is also responsible for enabling USB. After I changed the code it was working:

Code: Select all

*U32_REGISTER(0x1570) |= 8 | 0x08000000;

The 0x08000000 enables the USB OHCI stuff. There seems to be a hardware bug in the newer models. When reading the register there is 0 returned for the bit which disables the USB OHCI stuff.

I generated a patch for libsd.irx:

Code: Select all

 00000d40  80 12 04 00 21 10 43 00  3c 03 42 94 ff ff a5 34  |....!.C.<.B....4|
 00000d50  00 00 01 3c 20 46 24 ac  40 14 02 00 08 00 e0 03  |...< F$.@.......|
 00000d60  25 10 45 00 00 00 00 00  00 00 00 00 00 00 00 00  |%.E.............|
-00000d70  80 bf 09 3c 04 14 29 35  80 bf 08 3c 0c 14 08 35  |...<..&#41;5...<...5|
-00000d80  90 bf 03 3c 00 08 63 34  80 bf 04 3c f0 10 84 34  |...<..c4...<...4|
+00000d70  80 bf 0a 3c 04 14 49 35  00 08 0b 3c 0c 14 48 35  |...<..I5...<..H5|
+00000d80  90 bf 03 3c 00 08 63 34  08 00 6b 35 f0 10 44 35  |...<..c4..k5..D5|
 00000d90  80 bf 06 3c 70 15 c6 34  80 bf 0a 3c 14 10 4a 35  |...<p..4...<..J5|
 00000da0  0b 20 05 3c e1 31 a5 34  80 bf 07 3c 90 bf 02 3c  |. .<.1.4...<...<|
 00000db0  00 00 22 ad 00 00 03 ad  00 00 82 8c 08 00 03 3c  |.."............<|
 00000dc0  25 10 43 00 00 00 82 ac  00 00 c2 8c 14 14 e7 34  |%.C............4|
-00000dd0  08 00 42 34 00 00 c2 ac  00 00 45 ad 08 00 e0 03  |..B4......E.....|
+00000dd0  25 10 4b 00 00 00 c2 ac  00 00 45 ad 08 00 e0 03  |%.K.......E.....|
 00000de0  00 00 e5 ac 90 bf 02 3c  c6 07 42 34 90 bf 05 3c  |.......<..B4...<|
 00000df0  c8 07 a5 34 00 09 03 24  00 00 43 a4 00 02 02 24  |...4...$..C....$|
 00000e00  00 00 a2 a4 03 00 80 10  90 bf 03 3c 00 00 a0 a4  |...........<....|

You need to open libsd.irx in an hexeditor and replace the lines marked with "-" by the lines marked with "+". Check the offset in the first column!

You should verify the SHA1 sum:
b5cb57dba538cd8d4c794710ce8bb2623c3cd14f libsd.irx included in RTE
8a567dc7836d26dca5958f10b3cad477dff409a9 libsd.irx patched to work with USB on slim PSTwo

With the patched libsd.irx the USB stuff is working. I can't test the sound at the moment, because I don't have a working music player installed. Can someone check if the sound is working.

[wisi]

Great news!
Sound and USB work simultaneously!!
- Tested with USB keyboard and a USB HDD.

[deba5er]

@Mega Man

Thanks a bunch for figuring this out. I would have been at it forever...

You note that it applied to the free modules too. Does this mean you might be able to get the free sound modules working?

[noiseand]

Ola!

Mas me ajudem a enter uma coisa, esta incompatiblidade ao tentarmos utilizar usb e som simultâneamente esta no linux ou nos módulos de som?

Falo isso porque temos vários homebrews, como o já citado SMS em que podemos utilizar ambos dispositivos normalmente.

Abçs

[dlanor]

@Mega Man:
@deba5er:
I believe that this new discovery Mega Man made, of a previously read_write register now being write_only in newer PSTwo models, warrants both further investigation and a proper fix at a deeper system level.

Simply patching a single module or two, so as to add some set bits (by pure assumption) apart from what that module is intended to control, this might work for a few special cases, but it is far from an acceptable generic solution. So it is a useful temporary workaround, but for the future something better is needed.

IMO the best generic solution would be to implement the reading and writing of this register, and possibly others like it if there are any, through some kernel function which all modules would be required to use instead of accessing such a register directly.

The new kernel function can then easily keep a shadow copy in RAM of each such register's content, so as to allow proper control of individual bits despite the write_only nature of the hardware registers.

And such a solution would of course remain fully compatible with the older consoles as well, though not really needed for them.

The big drawback with this solution (as for any good solution to this problem) is that all software (modules, applications, the lot) which use direct hardware access to this register will need to be modified and recompiled before valid use in a fully PSTwo-compatible distro.

It's a tall order, but this is what I see as necessary at this point.

Best regards: dlanor

[Mega Man]

Currently I am not working at the free sound modules. I found something that can help me writing the sdrdrv.irx module, but I didn't checked it yet. I added an automatic patch to the CVS version of kernelloader. So newer releases will automatically patch it. This will stay for the RTE modules. For the ps2sdk there can be a cleaner solution. I think Sony didn't recognized the problem. We can't force Sony to make old software compatible to the new slim PSTwo model. Maybe there are only few games which use USB and sound and the problem is fixed in newer games.