Re: [Openvortex-dev] CVS update

[Jeff Muizelaar]

On Fri, 23 May 2003, Manuel Jander wrote:

> Hi everyone,
>
> I updated the CVS. Mostly bug fixes and cleanups.

I reverted your changes to acinclude.m4 and toplevel.config.in with the
assumption that they were accidental.

Was all of this intentional?

     int temp, lifeboat=0;
     //int this_8[NR_ADB] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}; /* position */
        int     this_4=0x2;
-    /* f seems priority related.
-     * CAsp4AdbDma::SetPriority is the only place that calls SetAdbCtrl with f 
set to 1
-     * every where else it is set to 0. It seems, however, that 
CAsp4AdbDma::SetPriority
-     * is never called, thus the f related bits remain a mystery for now.
-     */

     do {
                temp = hwread(vortex->mmio, VORTEX_FIFO_ADBCTRL + (fifo << 2));
-               if (lifeboat++ > 0xff)
+               if (lifeboat++ > 0xff) {
+                       printk(KERN_ERR "Vortex: vortex_fifo_setadbctrl 
fail\n");
                        break;
+               }
     } while (temp & FIFO_RDONLY);

        // AU8830 semes to take some special care about fifo content (data).
@@ -710,7 +711,11 @@
                if (!(temp & FIFO_VALID)) {
                        //this_8[fifo] = 0;
                        vortex_fifo_clearadbdata(vortex, fifo, this_4);
+#ifdef CHIP_AU8820
                        temp = (this_4 & 0x1f) << 0xb;
+#else
+                       temp = (this_4 & 0x3f) << 0xc;
+#endif
                        temp = (temp & 0xfffffffd) | ((b & 1) << 1);
                        temp = (temp & 0xfffffff3) | ((priority & 3) << 2);
                        temp = (temp & 0xffffffef) | ((valid & 1) << 4);
@@ -718,24 +723,20 @@
                        temp = (temp & 0xffffffdf) | ((empty & 1) << 5);
 #ifdef CHIP_AU8820
                        temp = (temp & 0xfffbffff) | ((f & 1) << 0x12);
-#endif
-#ifdef CHIP_AU8830
+#else
                        temp = (temp & 0xf7ffffff) | ((f & 1) << 0x1b);
                        temp = (temp & 0xefffffff) | ((f & 1) << 0x1c);
 #endif
-#ifdef CHIP_AU8810
-                       temp = (temp & 0xfeffffff) | ((f & 1) << 0x18);
-                       temp = (temp & 0xfdffffff) | ((f & 1) << 0x19);
-#endif
                }
     } else {
-               if (temp & FIFO_VALID)
+               if (temp & FIFO_VALID) {
 #ifdef CHIP_AU8820
                        temp = ((f & 1) << 0x12) | (temp & 0xfffbffef);
 #else
-                       temp = ((f & 1) << 0x1b) | (temp & 0xe7ffffef) | 
FIFO_BITS;
+                       temp = (temp & 0xf7ffffef) | ((f & 1) << 0x1b);
+                       //temp = ((f & 1) << 0x1b) | (temp & 0xe7ffffef) | 
FIFO_BITS;
 #endif
-               else
+               } else
                        /*if (this_8[fifo])*/ vortex_fifo_clearadbdata(vortex, 
fifo, FIFO_SIZE);
        }
        hwwrite(vortex->mmio, VORTEX_FIFO_ADBCTRL + (fifo << 2), temp);

> Regarding the SRC issue: I not getting the CHip'n Dale bug anymore, but i
> didn't actually solve the bug. I changed the adb allocator a bit, so ADB
> channel 0
> isnt being used. Any other channel semes to work well except adb channel
> 0 !?

Weird...

Some more info on src_setupchannel based on information from the binary
driver.

The following are the only possible values that the function is called
with. (unless it does uses function pointers, or I accidentally missed
any..)

1: edx, cvr:0x2c(esp), b:0, c:0, d:0xc(edx), e:1, f:0, g:0x14(esp),
thsource:1
2: edx, cvr:0x2c(esp), b:0, c:0, d:0xc(edx), e:1, f:0, g:0x14(esp),
thsource:1
3: edx, cvr:0x2c(esp), b:0, c:0, d:0xc(ebx), e:0, f:0, g:0x14(esp),
thsource:0
4: ebp, cvr:0xc(ebx), b:0, c:0, d:0xc(ebx), e:0, f:0, g:0x14(esp),
thsource:0
5: ebp, cvr:0x2c(esp), b:0, c:0, d:0xc(ebx), e:0, f:0, g:0x14(esp),
thsource:0

Anyways it looks like thsource is always equal to e(dirplay).y

The most interesting call is 4. where cvr = 0xc(ebx) as does d...


I have also taken my first thorough look into the windows drivers.
I used IDApro for disassembly and it appears to quite a nice job, although
not having symbols and what looks like excessive inlining makes things
alot more exciting...

Additionaly, I started work on a vxd backend for libbfd (the library used
by objdump, the linker etc.) Currently it can load the file and seperates
the sections. However, there are still code/data sepeartion problems as it
seems most of everything is all in one section...
Aditionally it cannot write out anything useful yet, and the code is a
mess.

I also took a brief look at an old copy of the 4front oss drivers I had
around. They look quite similar to the other linux drivers and have
symbols.

Does anyone have a copy of winxp? It sounds like they have rewritten
drivers and would also be interesting to look at.

All the drivers I have looked at seem to be based somewhat on the same
source base. Maybe no decent hw specifications were ever made... :)

-Jeff