Re: [Openvortex-dev] CVS update

[Will DeRousse]

Yes I have winxp, I'll see if I can find the vxd(s) for you.

Will

On Sat, 24 May 2003 09:39:54 -0400 (EDT)
Jeff Muizelaar <address@hidden> wrote:

> 
> 
> 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
> 
> 
> 
> _______________________________________________
> Openvortex-dev mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/openvortex-dev
>