I currently working on usbd and I tried to send messages over the usb bus. But I have the problem that there is nothing written to memory (e.g. the frame counter in hcca). I tried the same initialization on x86. Everything is working on x86 with an ohci pci card. So the code seems generally correct. There are two possible problems:
1. The allocated memory with AllocSysMemory() is no physical memory. Did anybody know how to get physical memory addresses? The original usbd driver also use the same virtual address ranges, so I think that this is not the problem.
2. The ohci chip is not correctly initialized or don't have access to physical memory (Need to be activated or something like that).
So I want to know which chip is used in the playstation 2. Is the chip from Sony? I don't want to open my playstation and I can't find any good pictures of the board. What are the differences to standard ohci specification at usb.org? Is there a circuit diagram available?
Which usb ohci chip is in the ps2?
If I'm not mistaken, this chip is built-in inside the IOP, so, it won't help opening the PS2 anyway.
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.
Ok, you are right. I found a description at http://playstation2-linux.com/download/ ... #id2717231 , which says it. There is also mentioned that the IOP doesn't have a MMU. So the used addresses in usbd should be accepted by the ohci. Sony seems to hide information about the IOP, I can't find any information.pixel wrote:If I'm not mistaken, this chip is built-in inside the IOP, so, it won't help opening the PS2 anyway.
Is there an gdbstub for the iop available, so I can try to debug it. Did somebody know of a ps2 emulator which include a gdbstub?
If I remember right, the IOP has some similar devices to the "1394 Lead Vehicle" from LSI. The datasheet below has alot of info about the USB host controller, just remember the base address on the PS2 is 0x1F80_0000 (0xBF80_0000) not 0xBFFF_0C00.
http://www.lsilogic.com/files/docs/tech ... eadveh.pdf
Also, the ps2linux kernel talks directly to the USB host controller, so might be worth checking out their source too.
Hope this helps a bit.
http://www.lsilogic.com/files/docs/tech ... eadveh.pdf
Also, the ps2linux kernel talks directly to the USB host controller, so might be worth checking out their source too.
Hope this helps a bit.
Thanx.jbit wrote:If I remember right, the IOP has some similar devices to the "1394 Lead Vehicle" from LSI.
Also, the ps2linux kernel talks directly to the USB host controller, so might be worth checking out their source too.
The usb ohci registers seems to be similar, because the register at offset 0x80 is also in the ps2 (at 0x84 seems to be a unknown register). These registers are not defined by ohci. I think the usb function interface of the "1394 Lead Vehicle" is not in the ps2.
When I made a reset (ps2client reset), none of the ohci registers are changed. So the usb chip is still running. But the chip doesn't write to memory anymore. If it does, this would be very bad, because the driver is not loaded anymore and memory will be overwritten, which could be used for other modules. So there must be a different register which is reseted. What does a reset do, what is reseted?
I don't find any special code in ps2linux, which could activate the write to memory. But if IOP and EE could use the ohci interface, then something must select whether to write to IOP-Memory or to EE-Memory. As far as I know the memory is not shared between IOP and EE. I guess this must be part of the sif registers.
I will try whether usbd works on EE. This could be the default memory where the ohci chip will write to.
I'm not 100% sure on all the mappings (it's one thing I intend to look into more, when I'm not writing 3d stuff), but I know alot of SBUS address space is shared with the Emotion Engine. Off the top of my head I can remember at least DEV9, the USB controller and IOP ram being mapped. However, AFAIK, the interrupts and DMA arn't mapped, so you'd need to do them on the IOP.
I remember the USB host controller that I used (on totally unrelated hardware) having local ram though, not accessing host ram. But that may have just been because of the devices embedded nature.
I remember the USB host controller that I used (on totally unrelated hardware) having local ram though, not accessing host ram. But that may have just been because of the devices embedded nature.