Repository navigation
Replies: 18 comments 52 replies
|
Hmm... GCC 9.2 is quite old, maybe that’s a problem? Have you tried booting I use the |
|
I tried out that vmlinuz-pal-ps2-main-77174dd4. Using binwalk terminal utility, I extracted vmlinux from vmlinuz-pal-ps2-main-77174dd4 to compare with the kernelconfig I'm using (which is actually arch/mips/configs/ps2_defconfig) - there are some differences:
have no effect anymore. I had to find out what exactly I must to write instead... Otherwise, stdout goes to somewhere else. After those fixes, I finally could run till that "Welcome!" introduction. I noticed that One of the things I wanted to talk about is ll/sc instructions handling mechanic. Currently, they (transformed by the toolchain into lwc0/swc0) are handled by a Reserved Instruction traps exception with a further appropriate ll or sc emulation. All that long process for "ll" opcode, and the same longness for "sc" opcode. How it should be called, this one for musl-1.2.5: Same for glibc: Updated the codes here. Tested them out, so I consider it is worthy to take place! What would you say? The alternative use of syscall instead of two RI-exceptions must significantly speed things up! |
The latest INITRAMFS has two important improvements:
I suppose any speedup depends on the circumstances. Some programs probably don’t use LL/SC much at all. Given that it’s a significant effort to replace them, I guess it would be good to have some benchmarks to prove that LL/SC indeed are causing a noticeable performance degradation. |
Well, I changed those /dev/console lines to
Any program linked with -lc have them. For example, that busybox included in your current releases have 33 pares of lwc0/swc0: Each ll and sc instruction triggers Reserved Instruction exception. That leads to the whole stack of registers is saved due to entering kernel mode. Then, searching and comparing the value of the Reserved Instruction to find out what exactly should be emulated. Next, emulation process obviously. After that, restoring the previously saved stack of registers with a concomitant other stuff (like interruptions and etc) processing, and at last, returning to the userspace. The straight Compare and Set realization as a syscall path should be at least twice as short. Doing a syscall - that leads to the whole stack of registers is saved due to entering kernel mode. Next, compare, set. After that, restoring the previously saved stack of registers with a concomitant other stuff (like interruptions and etc) processing, and at last, returning to the userspace. Also, the resulted binary of the resolved with CAS code, is slightly smaller due to all those asm volatile of the ll/sc pares replaced to the jump to the syscall.
Well, I have an installation of toolchain with glibc-2.34 which have the experimental updates I noticed above. Also I noticed, that it is slightly unstable:
despite that, as for a test benchmark, how about 100.000 iterations of 2 processes are processing the same variable with a time passed - by the method of RI exception and by the method of syscall? To compare them between each other. |
Yeah, why not? It’s a fairly advanced technical topic you’ve chosen to dig deeply into. But hey, by putting sufficient effort into it, you might find something. :-) |
|
Alright. The empirical tests with those CAS codes produced some interesting results. To see the difference, one must compile the atomic_bench.c . It is an applet in busybox.
Benchmark test image. CAS over syscall is faster than ll/sc emulation through RI exception in ~3.39 times.
|
|
Alright, maybe the next one will be more interesting. — this way 2 GPRs t4 and t5 are surviving at their whole 128bit. To keep them in the thread_info space, which is attaching to the each process individually. The advantage of this method is that way t4 and t5 are automatically survives by default, so even userspace programs are alright with them! Updated: those edits in thread_info.h should not be used as is. They are not fully enough - something else is interrupting/corrupting as well, after which the bits 127-32 of registers are not surviving. |
|
To be honest, I’m not sure about the benefits of attempting to optimise LL/SC. You’re perfectly welcome to maintain a patch of this kind, of course, but I’m not going to work on it myself. |
|
Hey again. I was making some attempts to successfully transfer a packet from the Linux side (kernel module) to the IOP (.irx) by preparing a SifRpc background server. The goal was to witness the ff_count value changing sequentially in the first byte of g_rpc_buffer on the IOP. Instead, an unexpected layout corruption was encountered. When dumping the exact 16 bytes received by the IOP RPC handler, the target buffer did not contain my raw safe_send_buffer data starting at index 0 at all. I verified and proved on both sides that the server address on the IOP side correctly matches the address identified, again, on by both sides. I'm not sure how it happens... What I am doing wrong? Are SIF1 transfers fully operational under this driver implementation? |
Hmm... If I recall the manual correctly, the IOP DMA actually only requires a 4-byte alignment. So 16-byte alignment works too, for sure, but is excessive.
The problem here most likely is Lines 67 to 69 in 77174dd If you Line 278 in 77174dd So it seems this Lines 503 to 506 in 77174dd
The use of
Yes, I believe so, because if you |
|
Thank you very much, that worked like a charm ^_^
|
|
Congratulations! Looking briefly at the attached code, some clean-ups will be needed, eventually. A prototype demonstrating these features is valuable nonetheless! Indeed, getting anything to work is often the most difficult step, due to lack of hardware documentation, etc. Starting out with the gamepad was a good choice too, as it’s one of the simplest drivers. It looks like you’ve made some use of Is SIO2 DMA a possibility? (Mentioned in issue #22.) |
Indeed! Every single step of the new concept was tested in advance using them (like pr_info("quack\n")) XD
well... I am not that competent of a person to give a definitive answer to that issue. To be honest, I don't fully grasp the inner workings of DMA channels, all those control bits... |
The i.LINK (Firewire) driver has byte-swap issues, apparently, see #24 (comment). I’m not aware of a similar issue with the SIO2. The gamepad driver is related to the memory card accessory driver, see issue #21, where SIO2 DMA presumably will be much more important due to significantly larger volumes of data. So learning how to use SIO2 DMA seems inevitable, and also how to multiplex gamepad and memory card data with the same DMA hardware? :-) By the way, if you feel adventurous about the IOP, frno7/iopmod#1 is a pretty good issue to start with! The problem being, why doesn’t the |
|
I'd like to introduce an other thing first.
I created the thread on sourceware bugzilla, but eventually handled the things by myself. Please, look at this: — that makes GCC utilizing the r5900's special 'plzcw' instruction everywhere possible (particularly __ctzsi2 is a part of all floating point software calculations, which are using while issue №3 inconcluded, and __clzsi2 is using almost everywhere in libc). And an independent standalone place in the kernel: — I would not say the loading speeded up at the speed of light, but anyway, whatever makes it better while staying stable :D Check with an objdump to grep for 'plzcw' to see how many!
hmm... What are your thoughts about it? Did you notice some... I dunno how to say... non-standard behavior? And, IOP processor, it is MIPSel R3000A , right? Any known limits from MIPS-I ? Any known instruction expands? And about SIO2 DMA. The channels for (that's why I am asking the question about channel number), the channel 5, IOP_DMAC_PIO - it is disabled since loaded to initramfs and module gamepad activated, but the gamepads are working... |
It’s an interesting optimisation! Perhaps the patch could be maintained on a separate branch with optional optimisations? I’d like to defer similar ‘micro-optimisations’ to a later stage, after the completion of major parts such as FPU support (issue #3), MMI support (issue #5), Graphics Synthesizer support (#10), etc.
The Linux kernel crashes during boot if IOP modules are compiled with
Yes, but I suspect it might be a tooling bug, perhaps during the linking of the IRX files, with the
I don’t know, really. This DMA stuff in the IOP is almost completely unknown to me as well. Asking questions and revealing answers by finding obscure documentation, as well as trial and error on actual hardware, are all part of the adventure. Prototypes demonstrating features are excellent. DMA is one of the most efficient, and complex, features of PlayStation 2 hardware. :-) |
|
@Arch91, I’ve now quickly tested your gamepad driver contribution, and it seems to work nicely. Thanks! :-) How would you like to be credited for your code? Full legal name and email in the commits? Or some alias? I will most likely need to rewrite a lot of it during clean-up, but it’ll be based on your work. I’ve made a provisional These two MIPS program files can then be copied to the INITRAMFS (or some other usable place) for testing on PlayStation 2 hardware: $ file /usr/mipsr5900el-unknown-linux-musl/usr/bin/evtest
evtest: ELF 32-bit LSB executable, MIPS, MIPS-III version 1 (SYSV), statically linked, stripped
$ file /usr/mipsr5900el-unknown-linux-musl/usr/bin/fftest
fftest: ELF 32-bit LSB executable, MIPS, MIPS-III version 1 (SYSV), statically linked, strippedI should probably add some paragraphs about how to do this on the wiki page for the PlayStation 2 controllers, for anyone else wanting to test the gamepads. Plus, the wiki page will have to be expanded with the nifty new gamepad features! |
|
Alright. Let it be "Tested-by" |
|
Tamed it B)
|
Congratulations! Yes, the red light blinks nicely. :-)
Instead of a DMA command queue, a driver would most likely have a state machine. The A simple state machine can be made with a combination of functions and C In your code, each piece of code between each In principle, each state could decide for itself what the next state must be. For example, if the current state discovers a DMA transfer failure, it could transition into a failed state (that could, for example, reset the controller logic); on success, it could transition to the next command state, and so on. State machine are often very compact, resource efficient, easy to reason about, and sufficiently powerful for this kind of use.
This piece of code handles DMA for the USB driver. Notice that this is the EE writing within address space of the IOP: linux/drivers/usb/host/ohci-ps2.c Lines 54 to 64 in 77174dd
Indeed, this is a serious problem. However, I think it’ll be much easier to start by implementing the gamepad and memory card drivers separately, so that only one of these two drivers can be used at any one time. When both drivers work as expected, in isolation, we can work out how to make them efficiently share resources such as SIO2 DMA. |
oh those technical terms in English... or in any other language... ><. I understood that the code executes every 5000... I dunno... IOP ticks? But what exactly triggers the IRX processing? - I mean, is it a hardware interrupt firing every 5000 ticks, or is it a scheduled event? |
No worries, I’ll take care of those technical bits. :-)
It’s 5000 μs (microseconds), often denoted by id_(39) void thbase_us_to_sys_clock(u32 usec, struct iop_sys_clock *sys_clock) alias_(USec2SysClock);First, 5000 μs is converted by thbase_us_to_sys_clock(5000, &next_event);
thbase_set_alarm(&next_event, event_alarm, NULL);In the function You’ll also notice that I’m going to improve that code, so that it’ll use two different semaphores: one semaphore for the 200 Hz events, and another semaphore for the SIO2 IRQ. These semaphores shouldn’t be mixed up.
Notice in the document PAD low-level specs by [RO]man that the SIO2 seems to transmit exactly the same number of bytes as it receives. I’m guessing bytes are transmitted and received simultaneously, meaning that when the last byte has been transmitted, the last byte has also been received at the same time. Could that be true? Someone on the internet has surely figured out the electrical wire protocol for PlayStation 2 controllers already? :-) Of course, it may well be the case that commands cannot be sent too often, that there must be some delay between subsequent commands. These things are still unclear to me as well...
Hmm...
|
|
Half is understood, half is accepted as given. Thanks for the explanations! I'm gonna prove, that there HAS TO be a delay between the commands! It's needed in principle, not necessary exactly 5000 μs. Test2: comment the AA, BB and CC pr_infos. You'll see that the success criteria are not met: MADR idiffers from the zx_buf values by only '0x08'; the upper 2 bytes of BCR contain 0001 for CH11 and 0000 for CH12; the highest byte of CHCR contain 01 for CH 11 and 4_0_ for CH12. Test3: make AA pr_infos uncomment, and leave both BB and CC commented. You'll see that the success criteria are not met in this test as well: MADR differs from the zx_buf values by only '0x10'; the upper 2 bytes of BCR contain 0001 for CH11 and 0000 for CH12; the highest byte of CHCR contain 01 for CH 11 and 40 for CH12. Test4: make both AA and BB pr_infos uncomment, and leave only CC one commented. You'll see that the success criteria are not met in this test either: MADR differs from the zx_buf values by only '0x18'; the upper 2 bytes of BCR contain 0001 for CH11 and 0000 for CH12; the highest byte of CHCR contain 01 for CH 11 and 40 for CH12. pr_infos obviously do not directly influence to the DMA mechanism. From that, I am making a conclusion, that it must be because IOP is physically spending the time for preparing and printing those pr_infos, and while it spends time for it, DMA transmittions (particularly which matters for a write one) gain enough time to complete successfully. |
|
I’m somewhat more than half-way through rewriting the gamepad driver. I’m hoping to have a testable driver to publish within a couple of days, or so. The Apart from using interrupts, it has a few other notable features. For example, device discovery (‘plug-and-play’) runs economically at 2 Hz, so on average it takes a bit less than 0.5 s for the gamepad driver to discover that a controller has been attached. In general, a port can run at different speeds depending on whether a device is attached, is passive (idle), is active (not idle), and so on: enum { /* Times in us */
CONTROLLER_DISCOVERY_POLL = 500000, /* 2 Hz device discovery */
CONTROLLER_QUERY_POLL = 100000, /* 10 Hz device query */
CONTROLLER_ACTIVE_POLL = 5000, /* 200 Hz device active */
CONTROLLER_PASSIVE_POLL = 100000, /* 10 Hz device passive */
CONTROLLER_IDLE_TIME = 180*1000000, /* Idle after 180 seconds */
};Also, ports 1 and 2 have completely independent timings. For example, an active device on port 1 can run fast at 200 Hz, while port 2 stays much slower at 2 Hz for device discovery, simultaneously. I’m also considering making a memory card accessory driver (issue #21). :-) |
|
OMG, yey! I'm curios how did you separate the ports, and what kind of mechanism of 'Hz action initiating' is looping in memory now! Meanwhile, I just completed the benchmark test for showing the rough values of what time each command spends for the completion.
beware the DMA channel BUS monopolization by the device }:[... |
You’ll be able to examine the new gamepad driver soon. :-)
This is promising! May I suggest amending the results with timing measurements in μs? Here’s a sketch of a system clock reader: static u64 read_clock(void)
{
struct iop_sys_clock sys_clock = { };
int err = thbase_get_system_time(&sys_clock);
if (err < 0) {
pr_err("%s: thbase_get_system_time failed with %d: %s\n",
__func__, err, iop_error_message(err));
return 0;
}
u32 s = 0;
u32 us = 0;
thbase_sys_clock_to_us(&sys_clock, &s, &us);
return (u64)s * 1000000 + us;
}Now measurements are easy: const u64 t0 = read_clock();
... code to measure ...
const u64 t1 = read_clock();
const u64 dt = t1 - t0; /* Time taken in μs */It’s possible to make even more accurate measurements, by postponing
Why not put all
I’m sure it will be challenging, but we’re going to make the best of it, won’t we? :-) |
ehm... no. And I'll explain why. The measurement must be processing after the very start of the transmittion to its completion. The start/resume is launched by
no-no-no... That comment is meant to explain why the chain of commands works when pr_infos are enabled between them, but fails when they are disabled. And the pr_info with the measurement results are indeed presented at the end. |
|
By the way, for testing, I think |
|
@Arch91, a new gamepad driver is now available for testing:
I’m happy with how it turned out, but I’ve only really tested it with a DualShock 2. It makes use of interrupts, with a state machine, but not (yet) DMA. These timings can be adjusted, for example: enum { /* Times in us */
CONTROLLER_DISCOVERY_POLL = 500000, /* 2 Hz device discovery */
CONTROLLER_QUERY_POLL = 100000, /* 10 Hz device query */
CONTROLLER_ACTIVE_POLL = 5000, /* 200 Hz device active */
CONTROLLER_PASSIVE_POLL = 100000, /* 10 Hz device passive */
CONTROLLER_SCHEDULE_TIME = 4000, /* Schedule at least 4 ms */
CONTROLLER_IDLE_TIME = 10*1000000, /* Idle after 10 seconds */
};It’s a bit too chatty in the kernel log now, but I think I’ll change some of the info prints to module debug later on. Are you ready to test it? :-) |
I bet you are the only person in the world who has a network on kernel 5.X XD. As for me, I usually test everything on USB. Centuries will pass before I handle the technique of pseudo-reboots... I even lazy to cut out the USB Wi-Fi drivers from my default kernel config ^) ooh! New function! I like it! But seeing many structs in a gamepad .irx driver code is @_@ I think I wouldn't dare to make any attempts if the code had looked this complex from the beginning :) To be able to compile the kernel modules now, I had to do this: Now, regarding the test. - those I see about DualShock 1. Meanwhile... I updated my scripts for building the toolchain |
I’ve just written a detailed wiki tutorial on how to configure networking for the PlayStation 2. Remote commands from your workstation to the PlayStation 2 via Sometimes when I make new kernel modules I also make them unloadable (with
Yeah, I’ve had wifi on my PlayStation 2 as well. It works, but Ethernet is simpler for everyone else. ;-) |
Ah, yes, such functions are added on a need-to-use-basis.
True, complexity comes with many features, unfortunately. But there are still plenty of simpler things to implement for PlayStation 2 Linux. :-)
Thanks! Please review my updated kernel patch, as well as IOP patch. Are you ready to stamp it with a
It is, but it was useful while debugging the thing. The updated patch adjusts idle to 180 seconds.
Hmm, meaning that the gamepad driver automatically switches from digital to analog? No, but maybe the input driver could have a flag or something, so that games etc. could switch between analog and digital, if they wish to do so. I don’t think the gamepad driver itself should switch on its own, though.
Thanks, I believe this is fixed in the updated patch!
Thanks, fixed! I didn’t have a DualShock 1 to test with, though.
Great, thanks, see updated patches!
I’m hearing forward to trying a demonstration of this sound driver. :-) |
Applied'n'tested. Compiled flawlessly.
Now, in test with jstest, it shows axes presented. For a gamepad, to be physically able to provide the axis states, we have to enlight the ANALOG. For DS1 axes are not working in the current driver state! Please, check it. As for the naming - yep, I saw "DualShock", the first.
I think you made a mistake by writing "digital to analog" when you actually meant "digital to pressure"... Even taking that into account, I do not quite understand what you meant by that.
- I'll sign nothing without 0x79 "pressure" mode! XD Holding my DS2 gamepad processed by the current driver feels bright and powerful, but I also feel like I am kind'a holding a eunuch ^) |
Nice manual! But as for me, the majority of all the tests I do on real hardware are regarding kernel stuff, not userspace. New optimization propose! - it should triggers during memory clearing operations for blocks larger than 64 bytes. Benchmark tests using perf shows, before the patch: After the patch: As a conclusion, it makes writing zeros to RAM ~17% faster. |
|
A new gamepad driver is now available for testing:
It supports key pressures, and another optimisation:
Nice microoptimisation. :-) |
|
recompiled and tested. Had to recompile jstest, and for it, I had to re-install the kernel-headers due to the updated file input-event-codes.h |
Hmm, yes, perhaps It isn’t a kernel crash, is it? I’ve tested the new driver with
Yes, it reports everything available. :-) By the way, it would be nice to let the application (game, etc.) force digital or analog, if it wants to. In my opinion the kernel device driver shouldn’t force anything by itself, but a game (or some other application) might want to force a particular mode. I don’t know if the input event device framework supports forcing modes, though.
DMA is planned, but I want to clean-up and tune the gamepad driver a bit before that. I’ve made extensive DMA preparations, though, for example by moving all SIO2 action to a single |
No, I mean a bit another. I see those -32767 (min) <-> 32767 (max) values in jstest . It corresponds to the bytes 0 <-> 255 . - this is correct. |
|
Soundwise initiation borne fruit! I and AI tamed the noise generator B) Surgical addresses manual writting while looking to the appropriate functions did the trick. And the file I was looking for by is PS2SDK's iop/sound/ahx/src/spu2.c To say in advance, this is the maximum I wanted to do. Next step is up to the real developers, better to those who were dealing with those drivers from PS2SDK. |
Nice!
Heh, thanks for the advice. :-)
It’s a valuable prototype, nonetheless. Sure, a lot of work remains for a ‘real’ device driver, but one has to start somewhere. :-) By writing to machine registers directly, this latest version is also much more useful than the first one in #91 (comment), because it doesn’t rely on |
|
I’ve measured SIO2 transmission performance, by
Given that the IOP operates at approximately 30 MHz, 1 μs is roughly 30 processor cycles. Note that the closed and idle modes are normally at 2 Hz and 10 Hz, respectively. However, the two controllers are independent, and don’t always “time up” on the same SIO2 transmission, particularly when they are low frequency. The likelihood of the two controllers sharing the same SIO2 transmission is much greater at the frequent 200 Hz active digital and analog modes. We can compute how much time the IOP spends on the (active) analog mode: By the same computation, the (active) digital mode needs 2 %. The idle mode 0.2 %, and the closed mode 0.03 %. The two latter modes are practically negligible, barely using any IOP computational resources at all. With the additional code (apart from the SIO2) managing the controllers, I guess that the total for the (active) analog mode is perhaps 5 % of IOP time. I don’t think DMA would be faster for the IOP, since the amount of tx and rx data is low. However, it will probably work much better in combination with memory card SIO2 transactions. |
|
Well, I believe that even 21μs is the enough pause to switch the context to work somewhere else. I wrote two codes:
Another thing I was thinking about is that at some of your messages you were saying that you implemented the separated threads for port 0 and port 1. But let's imagine the driver will ever became able to handle MX4SIO boards, to handle a linux loaded from that device. I suppose, most of the time SIO2 channels will be occupied by that block device with the high frequency large data DMA transactions, and there will be just a small pauses/windows for switching to the call of gamepads - and I believe particularly in that moment there must be processed all the input SIO2 devices, not just one of them. What do you think? And an another one:
In the process I was rewriting the code logic to DMA 'rails', I had to avoid the use of thbase_set_alarm function. Thanks to the semaphores (and taking that global one which can be used in share in future for SIO2 block devices), the thread could approximate into the simple: So. As my understanding about the alarm, alarm is a high-priority interruption, which triggers the abandoning the other processes immidiately with swtiching to the alarm caller. Is that how really threads queue must be processed? |
Honestly, no. Not every official manual is on hand yet. I relied on ps2tek and the way things look in the PS2SDK. Also, while working with the SPU, I've been reference-reading the SPU Manual overview.
A "prototype" and a "high-quality driver" are not 0 and 1. There is a wide spectrum of improvements between them, where attention is shifted from one feature to another. Needless to say, I didn't post these prototypes here looking for "nice, good boy" respond, and the comments in the code aren't there because of my writing inclinations alike. Those are the shared representation of the experience of how exactly certain aspects were handled in the code, and to shed light on the specific moments where I got stuck. It’s the kind of experience that might spark ideas in others on how to improve things. Perfection doesn’t just appear out of nowhere right away.
and those missing details are exactly what I tried to capture in the comments inside the attached files.
Excuse me for the umpteenth time for my misunderstanding of what exactly is supposed to be achieved by using Chain mode in particular. Not Linked List, neither Burst, nor Sliced, but specifically Chain. First point. While I was sending audio files to the SPU RAM, I tried experimenting with both Linked List and Chain modes on the IOP. According to ps2tek, how Chain mode should be activated is described in the CHCR register specifications: I already had a working setup for uploading audio files to the SPU RAM via the SPU2 DMA channel using Sliced mode, and I verified that the transfer actually works. In Sliced mode, I write 0x00000201 to the CHCR register. According to the theoretical manuals, the indicators for a successful DMA transaction in Chain mode should be: Second point. DMA modes are not as freely selectable as it might seem at first glance. Third point. Where exactly is the practical need for Chain jumps here?!? Where in the described above is there a logical, practical place for DMAtags and Chain mode? What makes Sliced mode so unacceptable here? |
It’d be much more efficient for the EE to let the IOP shuffle these samples instead. In general, all drivers should off-load as much work as possible from the EE.
Reducing unnecessary EE interrupts would also be an improvement.
No, user allocated ALSA buffers can be noncontinuous, and that is why DMA tags and chain mode are more efficient. That was quoted from the manual above: [chain mode] reduces processing such as data sorting before transfer. The IOP also needs to handle unaligned EE buffers. Ideally, the EE should only need to send the IOP a small packet of ALSA buffer pointers, with the corresponding EE memory mapped for DMA, and then let the IOP do the rest (including noncontinuous DMA transfers) by itself. The case of ALSA buffers that are larger than available EE memory must also be handled, whereby pages are mapped and unmapped, as needed, for DMA in a streaming fashion. A fairly solid understanding of the kernel memory subsystem is needed to get it working properly. :-) |
The IOP is basically a Playstation 1, with some additions. You can find a lot of info searching that way, like: |
And, PS2SDK's sound projects do the exact same thing — byte shuffling is done on the IOP side. I've given this some thought, and considering the clock speed difference between the EE and IOP, as well as how busy the IOP might be, I concluded that it might be better to let the EE handle the shuffling. That said, I'm not entirely sure how heavy the IOP load typically gets. Is it fine for the IOP to handle shuffling 8 KB block per sound period? Will it still have enough time to service other hardware units? If this isn't an issue for the IOP, then yeah, why not. EE's life would be more miraculous :p
Sure thing, I can not argue with that. This is one of the things I relied to AI. So, actually you mean Chain Mode on EE side. Honestly again, I was not digging EE's DMA transactions at all. Both for gamepad and sound drivers I relied EE->IOP SIF DMA transactions to that sif_cmd_opt_data function. No doubts, it worths investigation. It might be the situation with triggering other than Sliced only modes is different on EE side for SIF channels.
Excuse my non-tech slang, but in ALSA minimum prototype this is the place where the samples are coming from: In my understanding, I thought that this way the kernel globally defines the piece of RAM and forces all the launched ALSA related programs to write their samples there. I can not imagine that the samples can be scattered, like 1.4kb here, 3.8 kb there, 2.1 kb in other point... If so, how their starts could be determined then?..
Yes, I've come across that website before. Unlike ps2tek, it has a description of how Linked-list mode could be used in theory. Since you paid attention to that website, by the way, please, pay attention to this part: Note, that according to that, on PS1, Linked-list mode was using in GPU DMAC only. The rest, the common is Sliced. ...::ooh, it was rickgaiser::... Hi! Respect for you kernel 3.x for PS2 those times! For those, who do not believe me and who don't scare to get own hands dirty in investigation of SPU DMA channels behaviour, |
Thanks, @rickgaiser! That resource was new to me (although I knew about Nocash PSXSPX.)
The IOP, at 33 MHz, should be absolutely fine. Consider 48 kHz stereo samples, with 33E6 / 48E3 = 687.5 cycles/sample. If needed, an IOP sample shuffling routine can be hand-optimised in assembly too. IOP tasks can have priorities, as I understand them, and for sound, the conversion should have a high (almost real-time) priority compared to other tasks such as mass media IO. In general, for the Linux kernel, I think that:
Yes, the EE is the most important part for chain mode, and I believe the IOP should use DMA tags for this. The IOP probably only needs fixed DMA bounce buffers, and so IOP chain mode may not be necessary. In the unlikely case that IOP DMA has a stall control function, like the EE, which mutually synchronises DMA transfers, it would be very nice. :-)
ALSA has a sophisticated API. The
Making DMA work properly for sound, will make many other drivers a lot easier to implement as well: the ATA driver, the SIO2 memory card driver, etc. should all use EE/IOP DMA including DMA tags and chain mode in similar ways. Remember, though, that all drivers must be able to cooperate when running simultaneously. :-)
Posting zip files in comments isn’t the best way to share source code at Git Hub: Please consider using the Git version control software, with repositories, branches and tags for your code. :-) Also, regarding the |
I'm not familiar with it, and I have no clue what its purpose is...
At first, I just took that phrase way too literally :) Like, a pages release or memory zeroing mechanism implemented by blasting zeros through an "unneeded" DMA channel XD But yeah, as for zero-copy itself, I had gotten it before - it's about allocations instead of writing.
Well, those conceptual prototypes aren't really meant for public teaching. Sure, they clearly demonstrate how a specific feature is implemented, but where? - it's either in the iopmod project or the Linux kernel. For someone to actually test them, they’d need to know how to build the kernel, set up and use a cross-compiler, have a real console capable of running it, and on top of all that, have an interest in PS2 kernel + iopmod programming. There's a higher chance of Apophis hitting Earth than anyone actually doing that... It’s more likely intended to spark your interest/inspiration to port some of these concepts into your code ;)
It's better for you to not see how it is identified in the system then XD Anyway, I never aimed to maintain the Linux kernel or mainlining anything matching strict standards. Also, what did you do to the gamepad driver I posted?! - you violated it with renaming every single function, stripping the analog mode out of the three digital/analog/pressure modes, skipping implementing the DMA with pauses, and at times it even felt like where I wrote 2+3, you wrote 3+2 just to make it look different XD I'm kidding, of course. But seriously, all of this is just an attempt to make things work. The final word is always up to you. Now, regarding SIF0/1 DMA transfers.
The theory. EE side: IOP side: The practice. EE matches the expected with theory, everything is alright here. But I did manage to transmit 64KB in a single chunk this way, and then, to prove that it wasn't just ghost data running around, I passed it to the SPU, and it successfully played it. Another thing is the absence of a function to receive incoming SIF1 DMA transfers in the logic of the sifman_set_dma_intr function, if we are to believe how it is designed in the PS2SDK — or more precisely, the set_dma_inner function. With it, it is possible to queue a DMA transaction for execution with an interrupt upon its completion, but only for outgoing transfers via SIF0! It turns out that incoming SIF1 DMA transactions are both deprived of a completion interrupt and forced to compete with others like them in a way that is completely unincluded by the sifman queue logic. After a successful Normal<->Slice DMA transfer, how could one avoid to try the chain mode? I saw: and decided to do a test run right away: How to share SIF0/1 DMA transactions, and simultaneously how it would be possible to use sifcmd and sifrpc while doing so, is a question for a month-long round-table meeting... I see the theoretical concept of chain_source->chain_destination on SIF channels as follows:
What are the advantages compared to Slice mode: However, as for a practical use case where it is absolutely necessary or highly beneficial to use chain mode because sliced mode falls short, I still fail to see one to this day. It is not obvious to me which tag the end bit should be inserted into — whether it should go into the tag that carries the final transfer after which there are no more transfers, OR if another almost-empty tag with the end bit raised is required. The theoretical concept, as I see it, somewhat breaks down against what is written in sifman.c of the PS2SDK: - this chcr value, it is Slice mode! How'so?! And this write to BCR, where the upper 16 bits are preserved... All of this completely throws me off... I thought that maybe this was an implementation error in sifman.c within the PS2SDK itself (after all, we are all human, bags of meat, everyone makes mistakes), but after checking out the sifman_set_dchain function on practice, I actually saw the value 0x40000300 in CHCR... This is weird. I expected 0x41000600. So, much like the Vatican and its library, the console once again refuses to reveal the secrets of the chain mode to me }:p |
Hmm, I don’t know what that can be, really.
In a fully functional sound driver, the following test must work:
Virtual memory makes the sound memory buffer appear continuous to the user application. However, to the kernel, and more importantly to DMA, that’s absolutely not the case for physical memory, which is divided into pages of 4 KiB each. So this 50 MiB file is divided into 12800 pages, which the driver is unable to pin for DMA all at once (since the whole file doesn’t fit in physical memory). Some pages may be in physical memory, but most of them won’t be at any single time. The driver must ask the kernel to pin for DMA a small portion of the most needed pages (those that are about to be played instantly), and also make sure that the kernel can evict from physical memory those pages that the sound driver no longer needs (because they have already been played). To top it off, kernel page ordering is completely arbitrary, and for the sound driver that’s practically random physical order. That’s where chain mode comes in, because it can jump around in physical EE memory and fetch bits and pieces for the IOP as needed. :-) |
|
hmm... I can not argue with that - I really have a lack of memory conception understanding. And they are usually grasping by themselves only when I stuck in some stage while practicing. Maybe I will figure it out one day. As for now, I see it this way:
so, like, ALSA always provides the continuous memory area, or even if it not, the buffer address variable will be dynamically changing by itself, so gathering the buffer's exact location in memory is rather the unneeded part... But again, it is only my imagination/understanding, didn't deal with the related things in practice yet.
Can ata be the reason? I suppose, those sifcmd/sifrpc realizations are DMA functioning in chain mode perhaps. |
ALSA is a complex framework, supporting a wide range of hardware for 28 years now. I don’t know much about it, but it might have multiple, alternative, APIs that are more-or-less efficient for a given piece of hardware. PlayStation 2 hardware is fairly advanced, especially considering the programmability of the IOP. Within ALSA, you might find a ‘simple’ API matching your description. However, since that kind of API doesn’t do zero copy, it wouldn’t be a particularly good fit for PlayStation 2 hardware. Searching the internet for the keywords
Seems unlikely, unless you’ve loaded the
Yeah, I think we would need some kind of DMA queue, eventually, perhaps with a semaphore like you say, a mutex, or spinlock, or some such. I think we should ignore all built-in Sony BIOS drivers for the IOP, and instead make our own, tailored, modern and more efficient for Linux. :-) |
Uh oh!
There was an error while loading. Please reload this page.
Hello again, frno7 ! Long live to your PS2Linux 5.x kernels project :D
While I was in a business trip, I wrote TEN functions which I'd like to test on the real hardware in PS2Linux on your kernel. Four of those functions, if my suppose is correct, eventually can automatically speed up the particular things in ps2dev community a little bit. And other things... I'd like to test before to even talk about them.
...However, even though I archived the scripts and config-files, patches, which are leading to the 'working those days' toolchain, but following them, the result is I simply can not run the kernel/initrd to the "Welcome!" stage. Can you, please, help in re-freshing my building knowledges to find out what I am doing wrong?
Kernel headers:
make ARCH=mips headers_install INSTALL_HDR_PATH=/usr/local/ps2/mipsr5900el-unknown-linux-gnu
binutils-2.34. It's configure flags:
--prefix=/usr/local/ps2 --target=mipsr5900el-unknown-linux-gnu --enable-shared --enable-plugins --disable-werror
gcc-9.2.0, st1. It's configure flags:
--prefix=/usr/local/ps2 --target=mipsr5900el-unknown-linux-gnu --enable-languages=c --includedir=/usr/local/ps2/mipsr5900el-unknown-linux-gnu/include --disable-nls --disable-shared --disable-libssp --disable-libmudflap --disable-threads --disable-libgomp --disable-libquadmath --disable-target-libiberty --disable-target-zlib --without-ppl --without-cloog --with-headers=no --disable-libada --disable-libatomic --with-llsc=no --with-float=soft --disable-multilib
glibc-2.13, glibc-ports-2.13.
mkdir build
cd build
echo "libc_cv_forced_unwind=yes" > config.cache
echo "libc_cv_c_cleanup=yes" >> config.cache
configure flags:
mipsel-linux --prefix=/usr/local/ps2/mipsr5900el-unknown-linux-gnu --build=i686-pc-linux-gnu --host=mipsr5900el-unknown-linux-gnu --enable-shared --with-headers=/usr/local/ps2/mipsr5900el-unknown-linux-gnu/include --enable-add-ons --with-tls --with-__thread --without-fp --cache-file=config.cache
gcc-9.2.0, st2. Flags:
--prefix=/usr/local/ps2 --target=mipsr5900el-unknown-linux-gnu --enable-languages=c,c++ --includedir=/usr/local/ps2/mipsr5900el-unknown-linux-gnu/include --enable-libatomic --with-llsc=yes --with-float=soft --disable-multilib
glibc-2.30.
mkdir build
cd build
echo "libc_cv_forced_unwind=yes" > config.cache
echo "libc_cv_c_cleanup=yes" >> config.cache
configure flags:
mipsel-linux --prefix=/usr/local/ps2/mipsr5900el-unknown-linux-gnu --build=i686-pc-linux-gnu --host=mipsr5900el-unknown-linux-gnu --enable-shared --with-headers=/usr/local/ps2/mipsr5900el-unknown-linux-gnu/include --enable-add-ons --with-tls --with-__thread --without-fp --disable-experimental-malloc --with-pkgversion="GNU libc v2.30, nothing special" --cache-file=config.cache
gcc-9.2.0, final st. configure flags:
--prefix=/usr/local/ps2 --target=mipsr5900el-unknown-linux-gnu --enable-languages=c,c++ --includedir=/usr/local/ps2/mipsr5900el-unknown-linux-gnu/include --enable-libatomic --with-llsc=yes --with-float=soft --disable-multilib
busybox-1.28.0.
I have a .config file for it from those times I could questionlessly build things by myself. Moved the folder with the installed files to the same directory level which has kernel source. Folder name: "initramfs-ps2". And inside it:
mkdir {dev,lib,proc,sys,mnt,newroot}
mkdir lib/firmware/ps2
cp init-for-busybox.sh init || exit -1
cp actual_init-for-busybox.sh sbin/init
iopmod
cp arch/mips/configs/ps2_defconfig .config
make ARCH=mips CROSS_COMPILE=mipsr5900el-unknown-linux-gnu- oldconfig
make ARCH=mips CROSS_COMPILE=mipsr5900el-unknown-linux-gnu- -j 4 modules
make ARCH=mips CROSS_COMPILE=mipsr5900el-unknown-linux-gnu- -j 4 vmlinuz
make ARCH=mips CROSS_COMPILE=mipsr5900el-unknown-linux-gnu- INSTALL_MOD_PATH=$INITRAMFS_DIR INSTALL_MOD_STRIP=1 modules_install
make ARCH=mips CROSS_COMPILE=mipsr5900el-unknown-linux-gnu- -j 4 vmlinuz
mv vmlinuz /path/to/my_flashdrive/PS2Linux_v5.4.211.ELF
It starts.
As far as I remember, next the screen must flash once (as a result of the /sbin/init's "modprobe ps2fb mode_option=1920x1080p@50") and relocate to an other screen with the "live" things we can operate.
Also, I remember that to be witnessing "initrd not found or empty - disabling initrd" is alright when we have initramfs. I even remember that I edited the code of that message to something else XD to be not confused.
And also, I tried to download pal initrd from the releases of your kernel, unpacked it, saw that it includes busybox, .irx modules but no kernel modules, so I added kernel modules compiled by me and injected into the kernel as initramfs - no result. Can not really suppose what is the case... Initramfs is building and sticking inside the kernel but actually the kernel expects the outside initrd, I dunno?.. Any suggestions?
btw, is it ok to see a bloomed text in the kernel initial run screen resolution as it is on my picture?
All reactions