Wdr Udma Full Version 33
Angelique Syria
Encoded ring element size to be programmed into the elsize field of the ring's RING_SIZE register. To calculate the encoded size use the formula (log2(size_bytes) - 2), where "size_bytes" cannot be greater than 256 bytes. This calculation is already taken care in below macro.
UDMA ring attach API. This API is used to attach to an already allocated and configured ring. This API differs from ring alloc API in this aspect - it doesn't allocate resource from RM and doesn't configure the ring through sciclient/DMSC API.
Post this attach operation, other standard ring operations can be performed. This API is provided for usecases where a ring is configured by a remote entity and needs to be used for runtime operation from another entity.
UDMA prime descriptor to a exposed/"RING" mode ring - raw version (Takes all physical pointers). This will write the descriptor to the ring memory without setting the doorbell (doesn't commit the push).
Also no cache operation is performed to let the caller do the cache ops once for the entire ring after priming multiple elements. This will yeild better performance instead of doing cache ops for each ring push.
Note: No error check is performed by this API to minimize the CPU cycles. The caller should ensure that the ring is in exposed/"RING" mode and there are enough room in the ring and the ring pointer is non-null.
UDMA read descriptor from a exposed/"RING" mode ring - raw version (Reads physical pointers). This will read the descriptor address from the ring memory without setting the doorbell (doesn't commit the pop).
Also no cache operation is performed to let the caller do the cache ops once for the entire ring after reading multiple elements. This will yeild better performance instead of doing cache ops for each ring pop.
Note: No error check is performed by this API to minimize the CPU cycles. The caller should ensure that the ring is in exposed/"RING" mode and descriptor addresses are in the ring and the ring pointer is non-null. Also make sure that its not reading more than the what Udma_ringGetReverseRingOcc returns.
Note: The count will be positive when ring elements are queued into the ring and count will be negative when ring elements are dequeued from the ring. In case of devices like AM64x with LCDMA ring accelerator, when the count is positive, it sets the forward doorbell of the common ring and when the count is negative, it sets the reverse doorbell of the common ring. For other devices with normal ring accelerator, these sets the doorbell of the ring. Here its meaningful to pass the ringHandle of Free Queue Ring when the count is positive and pass the ringHandle of Completion Queue Ring when the count is negative.
Note: No error check is performed by this API to minimize the CPU cycles. The caller should ensure that the ring is in exposed/"RING" mode and there are enough room in te ring and the ring pointer is non-null.
Note: In case of devices like AM64x with LCDMA ring accelerator, this returns the forward ring occupancy count of the common ring. For other devices with normal ring accelerator, this returns the the occupancy count of the ring. Here its meaningful to pass the ringHandle of Free Queue Ring.
Note: In case of devices like AM64x with LCDMA ring accelerator, this returns the reverse ring occupancy count of the common ring. For other devices with normal ring accelerator, this returns the the occupancy count of the ring. Here its meaningful to pass the ringHandle of Completion Queue Ring.
Note: In case of devices like AM64x with LCDMA ring accelerator, this returns the write index value of the common ring. For other devices with normal ring accelerator, this returns the the read/write index value of the ring. Here its meaningful to pass the ringHandle of Free Queue Ring.
Note: In case of devices like AM64x with LCDMA ring accelerator, this returns the read index value of the common ring. For other devices with normal ring accelerator, this returns the the read/write index value of the ring. Here its meaningful to pass the ringHandle of Completion Queue Ring.
2.3.2 Is the ElpisHD version with HD+ support. I have also included Cerbios Tool, as well as UDMA 4,5 and 6 files. Only use 6 if you have a Startech, basically. if you have a cheapo SATA adapter, use UDMA 4. If you have upgraded your cheapo green adapter with "the resistor", try 5. If you are using IDE, use the non-UDMA descripted file, which is UDMA-2.
Is it possible to change the UDMA version on a softmod running Cerbios? I put an ssd in one of mine and wanted to test out UDMA6 with it. I was half asleep when I installed Cerbios on my first softmodded one and dont remember much. A guy on discord walked me through it.
If you're using a BFM, then I don't think things like that can be done, as they are too low-level. You would probably just be using the UDMA mode of the TSOP bios, which would be the MS bios, if softmodded.
@KaosEngineer Could you please confirm that? I would be curious to know what a BFM is capable of doing, and what it is not, definitively. You are familiar with BFMs, so that's why I am summoning you.
I think I figured out what to do last night. I went back into the discord and read what I did. I ftp'd into nkpatcher to access real C. I deleted the contents of C\nkpatcher, and replaced them with the PBL cfg and xbe, then placed Cerbios.bin file in there. I renamed Emustation to Evoxdash.xbe and put it in C, along with its folders/files.
One thing I noticed is that I can no longer use Dashloader, I tried reinstalling it again and setting UX and Gamers to A and B, but they dont work. The led is green also, used to be orange. He said I can modify that with the Cerbios.ini file and place it in the nkpatcher folder.
I am not entirely sure how the dash is loaded. My original impression was that the Intended installed dash is renamed xboxdash.xbe and that was it. However, I don't think it is this simple. It is possible that Cerbios and nkpatcher are fighting over where to load the dashboard or default .xbe file from. It's entering the realm of mixing a hardmod with a softmod and that is always advised against.
@Rocky5 Could you do us BOTH a favor and shed some light on the topic? You understand softmodding and BFMs more than most people do, I'm sure. And as people can tell, I know nothing really of how a softmod actually achieves it's intended outcome. I am embarrassingly uneducated on the topic and I am not where where to research it.
looks like it failed to open UDMA with the driver, and I noticed in SysConfig gui, it documented that udma channel creation can fail at runtime in SysConfig generated Drivers_open() and listed 3 conditions, which sounds like what I experienced here.
I try toreceive data from the RX channel of the UART in a mix between reading out theFIFO directly and using the uDMA. The reason I do this mix is because i havedifferent frames with different lenghts. For this purpose, the first 3 bytes (header)of each frame are read directly from the FIFO with the driverLib. The header describes the informationof the following data. After that I know exactly how much data follow. Now Ipass this task on to the uDMA in order to receive the further data. Here theudma reports back it has received all the data but it happens too early (notall data are on the UART already).
The header isprocessed as follows. As soon as the FIFO is filled to 2/8 (UART_FIFO_RX2_8) an interrupt (UART_INT_RX) signals that the header shouldbe in the FIFO. They are read out with the usage of driverlib and processed.This code is shown below.
Now I knowexactly how much data has to be received to collect the full frame. This should be done by the uDMA. The uDMA starts to receive data correctly, but reports back a finish much tooearly. Not all data of the frame are on the UART at this time. This is shown in the next recording.
If I compile my code with optlevel=off, the code is slower. That leads to, that the uDMA starts here work later. It means the uDMA begin to collect data from the FIFO when the complete frame already there. In this case it works but it is no oppertunity because i must be fast and the frames can be much bigger as in the example.
Look like uDMA start to collect the data even before data is received in FIFO hence it's reading the stale data. Generally DMA should get triggered only after all the data is in FIFO which DMA will read. You could delay the DMA trigger or check for RXFF bit status to see if FIFO is full and then start the DMA.
Is that the way you prefere: I start the uDMA when the FIFO is full, read the data with the uDMA until the FIFO is empty. I repeat that until all data are received. I see multiple problems with that solution. I can not count the received data and i dont know when my frame is completed.
b37509886e