Menu
▾
▴
linux-apus-devel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(210) |
Jun
(169) |
Jul
(167) |
Aug
(128) |
Sep
(218) |
Oct
(120) |
Nov
(86) |
Dec
(71) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(91) |
Feb
(179) |
Mar
(52) |
Apr
(56) |
May
(183) |
Jun
(62) |
Jul
(63) |
Aug
(49) |
Sep
(36) |
Oct
(35) |
Nov
(72) |
Dec
(30) |
| 2002 |
Jan
(53) |
Feb
(61) |
Mar
(56) |
Apr
(13) |
May
(1) |
Jun
(7) |
Jul
(80) |
Aug
(73) |
Sep
(30) |
Oct
(29) |
Nov
(8) |
Dec
(40) |
| 2003 |
Jan
(10) |
Feb
(2) |
Mar
(4) |
Apr
(9) |
May
(3) |
Jun
(19) |
Jul
(64) |
Aug
(53) |
Sep
(28) |
Oct
(7) |
Nov
(3) |
Dec
(21) |
| 2004 |
Jan
(11) |
Feb
(30) |
Mar
(18) |
Apr
(1) |
May
(13) |
Jun
(18) |
Jul
(13) |
Aug
|
Sep
(9) |
Oct
(5) |
Nov
|
Dec
|
| 2005 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(10) |
Aug
(21) |
Sep
(7) |
Oct
(10) |
Nov
(6) |
Dec
|
| 2006 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
(2) |
Sep
(6) |
Oct
(10) |
Nov
(8) |
Dec
(3) |
| 2007 |
Jan
(3) |
Feb
(6) |
Mar
(1) |
Apr
(6) |
May
(10) |
Jun
(7) |
Jul
(13) |
Aug
(8) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
|
From: Michel <dae...@st...> - 2000-09-23 21:56:36
|
Marek Szyprowski wrote:
> In current version there is a problem with build-in parranel port support.
> Athough the driver works, it dosn't work correctly. Problems apprears when I
> try to print some gfx - I get garbage, but not picture. (printing of ANSI
> texts works).
You're lucky, I never managed to print anything but garbage with the new
driver.
> After looking in source I noticed, that kernel uses "parport",
> "parport_amiga" and "lp" driver for build-in parranel port (and printer)
> support. In older kernel version another drivers ("lp_m68k" and
> "lp_intern") were used for parranel port.
> How could I enable "lp_m68k" driver compilation?
Enable parallel printer support near the bottom of the General Setup as a
module.
> I think that finding correct values for timeout once again won't take me
> much time.
Please supply a patch when you have fixed it!
> My second question is about scsi driver for BlizzPCC+. Why, always when I
> use any tool for playing music CD i got a message from kelnel like this
> one:
> scsi0 : datain+dataout for command 0x42 02 40 01 00 00 00 00 10 00
> scsi0 : datain+dataout for command 0x42 02 40 01 00 00 00 00 10 00
> scsi0 : datain+dataout for command 0x47 00 00 00 02 00 49 00 4a 00
> 53c7xx: Non-aligned buffer with datain && dataout
>
> (repeated many, many times).
>
> How could I disable this? (its vey anoying...)
But it works? Have you enabled SCSI logging or similar?
Michel
--
Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and The DRI Project
|
|
From: <fh...@at...> - 2000-09-23 21:10:25
|
Anyone care to comment on any of this? The first address is the physical address of the 53c770 SCSI. This should be correct. I got the address from Ralph Schmidt. paddr: f40000 When the ioremap_nocache is run using the physical address the virtual address comes out to be this: vaddr: 80f40000 The np->reg variable is set to the virtual address and uses that address to access the chip registers. How is the kernel using this virtual address to translate to the physical address required to access the chip registers? should I be using virt_to_phys() to access all SCSI chip registers? There is no such thing as an I/O port (at least in the PC sense) on the Amiga? io_port: 0 Someone told me on a linux news group to use check_mem_region() /request_mem_region() instead of check_region()/request_region() in the driver, although it appears that the latter functions are again aimed toward the PC style hardware that has I/O ports. What does those functions do on APUS, if anything? Also, the "mem" versions of those functions are not in the 2.2.10 kernel I have been using. Are they new in the 2.3/2.4 kernels? Fred |
|
From: Christian T. S. <ct...@de...> - 2000-09-23 20:55:42
|
On Fri, Sep 22, 2000 at 08:37:33PM +0200, Michael Schmitz wrote: > I know just barely enough to screw up a xfree build, and I don't have a > fast m68k for builds. Just in case you were about to ask. Well, ask me, I know barely enough to circumvent the glitches in the debian package to make 3.3.6 build. Ok, here comes the problem. I made patches for two Imakefile errors, build fails now here: gcc -o pcitweak -O2 -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -L../../../../../exports/lib pcitweak.o -L../os-support -lxf86_os -L../dummylib -ldummy -Wl,-rpath-link,../../../../../exports/lib pcitweak.o: In function `main': pcitweak.o(.text+0x138): undefined reference to `xf86scanpci' pcitweak.o(.text+0x2a6): undefined reference to `xf86scanpci' pcitweak.o(.text+0x2b8): undefined reference to `pciTag' pcitweak.o(.text+0x2d2): undefined reference to `pciReadByte' pcitweak.o(.text+0x2f0): undefined reference to `pciReadWord' pcitweak.o(.text+0x306): undefined reference to `pciReadLong' pcitweak.o(.text+0x338): undefined reference to `pciWriteByte' pcitweak.o(.text+0x350): undefined reference to `pciWriteWord' pcitweak.o(.text+0x360): undefined reference to `pciWriteLong' collect2: ld returned 1 exit status make[7]: *** [pcitweak] Error 1 make[7]: Leaving directory `/build/xfree86-4.0.1/build-tree/xc/programs/Xserver/hw/xfree86/etc' In free86-4.0.1/build-tree/xc/programs/Xserver/hw/xfree86/os-support/bus some *Pci.c files for several arches exist, but none for m68k. The files say, they need kernel 2.2 for /proc/bus/pci, I am running 2.2.10, but I only have /proc/bus/zorro, but not pci... so maybe it would not make sense to add m68k to the Imakefile? However, without pci, I have some problems to get xfree4.0 to build, see error messages above. I think (anybody with a clue correct me please) that XF4.0 requires some pci functions, or some major rework in the (I)Makefiles and whatnot. So if somebody has a proposal (dummy, or maybe some "real" pci functions for m68k) or maybe even a patch, I'd be happy to hear about it. Christian |
|
From: Marek S. <ma...@st...> - 2000-09-23 20:02:38
|
Hi,
Few day ago I managed to download lates stable kernel source and I compiled
my own kernel. In current version there is a problem with build-in parranel
port support. Athough the driver works, it dosn't work correctly. Problems
apprears when I try to print some gfx - I get garbage, but not picture.
(printing of ANSI texts works). I have everything (printing filtres)
configured properly, because printer worked with previous version of kernel
(last one, which source was avaible on sunsite ftp).
After looking in source I noticed, that kernel uses "parport",
"parport_amiga" and "lp" driver for build-in parranel port (and printer)
support. In older kernel version another drivers ("lp_m68k" and
"lp_intern") were used for parranel port. They also didn't worked as good
as they could (were very slow), but after changing some timeouts in driver
code I got nice printer driver. Now I don't have source of that driver (I
forgot and deleted it when I deleted all kernel source, because I need some
space on drive), but I have that driver compiled as module. It works well,
even with latest kernel (I just have to disable "parport" driver).
How could I enable "lp_m68k" driver compilation? I think that finding
correct values for timeout once again won't take me much time.
My second question is about scsi driver for BlizzPCC+. Why, always when I
use any tool for playing music CD i got a message from kelnel like this
one:
scsi0 : datain+dataout for command 0x42 02 40 01 00 00 00 00 10 00
scsi0 : datain+dataout for command 0x42 02 40 01 00 00 00 00 10 00
scsi0 : datain+dataout for command 0x47 00 00 00 02 00 49 00 4a 00
53c7xx: Non-aligned buffer with datain && dataout
(repeated many, many times).
How could I disable this? (its vey anoying...)
Regards
--
Marek March Szyprowski ........... mailto:ma...@st... ...
... happy AmigaOS user ... A1200, 603e/210 & 040/30, BVision, SCSI
http://www.staszic.waw.pl/~march (Linux/APUS & 3D Games for Amiga)
|
|
From: Ken T. <ke...@we...> - 2000-09-23 01:50:32
|
On Thu, 21 Sep 2000, Frank Petzold wrote: > On Thu, Sep 21, 2000 at 06:41:15PM +1100, Ken Tyler wrote: > > Is affs still broken ? > AFFS works for me (in -test7). Gave it a go with test8 - no good. It looks like it has a problem similar to last time, copy a file to an affs partition (where the file does not exist), md5sum matches OK. Copy again over the just made copy, the second copy fails md5sum checksum. Last time the problem was to do with extension block caching, maybe something similar this time - I know how it works now ! Ken. |
|
From: Michael S. <sc...@op...> - 2000-09-22 18:37:52
|
> I propose somebody write some patches to make xfree4.0 compile instead. That > would help many more people, than writing drivers for not yet existing > hardware for not yet quite dead computers. Wasn't there some xfree developer > around? It seems to me the very basic m68k support is missing in xfree The previous m68k xfree developer (Geert, in case you forgot) asked for takers quite a while ago. So AFAIK there's no m68k developer for xfree right now. I know just barely enough to screw up a xfree build, and I don't have a fast m68k for builds. Just in case you were about to ask. Michael |
|
From: <p2...@mi...> - 2000-09-22 14:22:27
|
On Fri, Sep 22, 2000 at 02:49:58PM +0200, Kolbjørn Barmen wrote: > On Fri, 22 Sep 2000, p2 wrote: > > > > Voodoo3 anyone? > > > > > > > I have voodoo3 working on PPC. Only 8 bit graphics for the moment though. > > Text console is accelerated. > > Using the Mediator? > No, on a CHRP board with GoldenGate II chipset and 604e CPU. But most big endian issues with the code are solved. PCI I/O space access is required however... Peter. |
|
From: Alan B. <al...@ms...> - 2000-09-22 14:12:04
|
hi, > The problem is that AFAIK the Mediator only gives access to the memory space > via the ZIII window. The X 4 drivers (like all Linux PCI drivers I guess) > assume a contiguous memory space. I guess this could be solved with MMU > tricks, but is it worth the trouble? The Predator board will offer contiguous > memory for PPC boards. thats if it comes, most people i know think that the predator is vapour - I'm still to be convinced as to how a BUSBoard can hang off the delicate PPC connector ;-) > > - of course, if m68k doesnt have XFree4 yet, then that *is* an issue > > Does m68k even have PCI yet? 8-) surely some 68k machines have had PCI already, n'est pas? alan |
|
From: Creasey <sa...@oh...> - 2000-09-22 14:00:28
|
On Fri, 22 Sep 2000, Alan Buxey wrote: > drivers - for 3dfx, ATI, Virge etc etc, yes? - of course, if m68k doesnt > have XFree4 yet, then that *is* an issue I'm almost ashamed to admit this, but XF4 does build on a sun3(linux). :) didn't get to actually test the X server (though it built). no kbd/monitor... everything else worked like a champ. So it should be plenty possible :) -- Sam "UN-altered REPRODUCTION and DISSEMINATION of this IMPORTANT Information is ENCOURAGED, ESPECIALLY to COMPUTER BULLETIN BOARDS." -- Robert E. McElwaine |
|
From: Michel <dae...@st...> - 2000-09-22 13:40:34
|
Alan Buxey wrote: > > I propose somebody write some patches to make xfree4.0 compile instead. > > That would help many more people, than writing drivers for not yet > > existing hardware for not yet quite dead computers. Wasn't there some > > xfree developer around? It seems to me the very basic m68k support is > > missing in xfree 4.0.1, at least what I get in the debian package. And I > > am pretty sure m68k support has not been removed by the debian > > maintainer... > > i dont see the issue. this uses standard PCI calls - so, once you know > where the PCI memory lies you should be able to use the current XFree4 > drivers - for 3dfx, ATI, Virge etc etc, yes? The problem is that AFAIK the Mediator only gives access to the memory space via the ZIII window. The X 4 drivers (like all Linux PCI drivers I guess) assume a contiguous memory space. I guess this could be solved with MMU tricks, but is it worth the trouble? The Predator board will offer contiguous memory for PPC boards. > - of course, if m68k doesnt have XFree4 yet, then that *is* an issue Does m68k even have PCI yet? Michel -- Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and The DRI Project |
|
From: Alan B. <al...@ms...> - 2000-09-22 13:32:34
|
hi, > > http://www.vesalia.de/shop.cgi?V02b0f16525e401075585955520b514e01101f0954414752050140090a1e311155796c21263c67237144192639787d6b335e272b661b5 > Its still vapourware: http://www.amiga-news.de/index.shtml (sorry, german) > Official Annoucement from Elbox whats still vapour-ware? the Elbox Mediator PCI BUSBoard for the A1200 certainly isnt, I saw one in action 2 weeks ago. It was using a VirgeS3 PCI gfx card (basic driver changes for AmigaOS cybergfx to use) and was running very happily at 1280x1024 in 16bit. > I propose somebody write some patches to make xfree4.0 compile instead. That > would help many more people, than writing drivers for not yet existing > hardware for not yet quite dead computers. Wasn't there some xfree developer > around? It seems to me the very basic m68k support is missing in xfree > 4.0.1, at least what I get in the debian package. And I am pretty sure m68k > support has not been removed by the debian maintainer... i dont see the issue. this uses standard PCI calls - so, once you know where the PCI memory lies you should be able to use the current XFree4 drivers - for 3dfx, ATI, Virge etc etc, yes? - of course, if m68k doesnt have XFree4 yet, then that *is* an issue alan |
|
From: <ko...@nv...> - 2000-09-22 12:57:38
|
On Fri, 22 Sep 2000, p2 wrote: > > Voodoo3 anyone? > > > > I have voodoo3 working on PPC. Only 8 bit graphics for the moment though. > Text console is accelerated. Using the Mediator? -- kolla |
|
From: Christian T. S. <ct...@de...> - 2000-09-22 12:47:17
|
On Fri, Sep 22, 2000 at 02:16:34PM +0200, Arno Griffioen wrote: > We're gonna need drivers... > > http://www.vesalia.de/shop.cgi?V02b0f16525e401075585955520b514e01101f0954414752050140090a1e311155796c21263c67237144192639787d6b335e272b661b5 Its still vapourware: http://www.amiga-news.de/index.shtml (sorry, german) Official Annoucement from Elbox [...] Aufgrund der Tatsache, dass keine dieser PCI-Lösungen bisher auf dem Markt erhältlich sind, ist es derzeit nicht möglich, dem Wahrheitsgehalt beider Varianten auf den Zahn zu fühlen. I propose somebody write some patches to make xfree4.0 compile instead. That would help many more people, than writing drivers for not yet existing hardware for not yet quite dead computers. Wasn't there some xfree developer around? It seems to me the very basic m68k support is missing in xfree 4.0.1, at least what I get in the debian package. And I am pretty sure m68k support has not been removed by the debian maintainer... Christian -- http://www.debian.org/~cts/debian-m68k/potato |
|
From: <p2...@mi...> - 2000-09-22 12:38:38
|
On Fri, Sep 22, 2000 at 02:16:34PM +0200, Arno Griffioen wrote: > We're gonna need drivers... > > http://www.vesalia.de/shop.cgi?V02b0f16525e401075585955520b514e01101f0954414752050140090a1e311155796c21263c67237144192639787d6b335e272b661b5 > > Voodoo3 anyone? > I have voodoo3 working on PPC. Only 8 bit graphics for the moment though. Text console is accelerated. Peter. |
|
From: <gri...@ps...> - 2000-09-22 12:16:38
|
We're gonna need drivers... http://www.vesalia.de/shop.cgi?V02b0f16525e401075585955520b514e01101f0954414752050140090a1e311155796c21263c67237144192639787d6b335e272b661b5 Voodoo3 anyone? Bye, Arno. -- PSINetworks Europe Fax: +31-23-5699841 | One disk to rule them all, Siriusdreef 34 Tel: +31-23-5699840 | One disk to bind them, 2132WT Hoofddorp+--------------------------------+ One disk to hold the files The Netherlands | * Musical Interlude * | And in the darkness grind 'em ----------------+--------------------------------+------------------------------ We say Retribution, We say Vengeance is bliss, We say Revolution, With a Cast-Iron fist! (Megadeth, 'The Disintegrators') -------------------------------------------------------------------------------- |
|
From: Ken T. <ke...@we...> - 2000-09-21 20:04:29
|
On Thu, 21 Sep 2000, Frank Petzold wrote: > AFFS works for me (in -test7). OK, it was reported as broken early on. I'll give it try. Ken. |
|
From: Geert U. <ge...@li...> - 2000-09-21 11:14:44
|
On Wed, 20 Sep 2000 fh...@at... wrote:
> Can someone explain to me how APUS is using memory
> in relation to a driver? If I request a region,
> check_region()/request_region(), for I/O where
> will the kernel most likely map that memory.
The *_region() functions only _reserve_ regions, they don't map it.
{request,release}_region() is meant for I/O space, which the Amiga doesn't
have.
{request,release}_mem_region() is meant for memory space, which is what you
have on Amiga.
Before you can access memory space, you have to ioremap() the region.
> Also on the APUS Amiga how to a get memory to be non
> cachable?
ioremap() does this by default.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: <fp...@zu...> - 2000-09-21 10:56:13
|
On Thu, Sep 21, 2000 at 06:41:15PM +1100, Ken Tyler wrote: > > Compiled and booted 2.4 today - hooray ! > > Is affs still broken ? > > If yes, what's wrong with it and how 'dangerous' is it considering my affs > test partition is on the same drive as ext2 partitions. AFFS works for me (in -test7). -- Frank Petzold, IBM Zurich Research Laboratory, Säumerstrasse 4, CH-8803 Rüschlikon/Switzerland, Tel. +41-1-724-84-42 Fax. +41-1-724-89-56 Business email: fp...@zu... Private email: pe...@he... The opinions expressed here are mine and not necessarily those of IBM. |
|
From: Ken T. <ke...@us...> - 2000-09-21 10:40:30
|
CVSROOT: /cvsroot/linux-apus Module name: 2.2 Repository: 2.2/include/asm-ppc/ Changes by: ke...@sl.... 00/09/21 03:40:29 Modified files: 2.2/arch/ppc/amiga/: time.c 2.2/arch/ppc/amiga/time.c 2.2/arch/ppc/kernel/apus_setup.c 2.2/arch/ppc/kernel/time.c 2.2/drivers/sound/dmasound.c 2.2/include/asm-ppc/machdep.h ke...@we... 2.2/arch/ppc/kernel/: apus_setup.c time.c 2.2/arch/ppc/amiga/time.c 2.2/arch/ppc/kernel/apus_setup.c 2.2/arch/ppc/kernel/time.c 2.2/drivers/sound/dmasound.c 2.2/include/asm-ppc/machdep.h ke...@we... 2.2/drivers/sound/: dmasound.c 2.2/arch/ppc/amiga/time.c 2.2/arch/ppc/kernel/apus_setup.c 2.2/arch/ppc/kernel/time.c 2.2/drivers/sound/dmasound.c 2.2/include/asm-ppc/machdep.h ke...@we... 2.2/include/asm-ppc/: machdep.h 2.2/arch/ppc/amiga/time.c 2.2/arch/ppc/kernel/apus_setup.c 2.2/arch/ppc/kernel/time.c 2.2/drivers/sound/dmasound.c 2.2/include/asm-ppc/machdep.h ke...@we... Log message: Disable power led heartbeat (CONFIG_HEARTBEAT) while sound is active. (from 2.3 kernel) |
|
From: Ken T. <ke...@we...> - 2000-09-21 07:41:50
|
Compiled and booted 2.4 today - hooray ! Is affs still broken ? If yes, what's wrong with it and how 'dangerous' is it considering my affs test partition is on the same drive as ext2 partitions. Ken. |
|
From: Ken T. <ke...@we...> - 2000-09-21 07:26:07
|
Hello all, I've re-done the filter-heartbeat-dmasound patch for 2.2, now its done the way Geert suggested - it is much better. Not commited it yet as I had another hiccup with cvs, I've lost the top level CVS directory, is it because I'm in the dir when I do things, and don't specify it on the cvs command line ? Or is it make mrproper ? Because 2.2 is a link to 2.2_orig ? About kb beeps, they are a bit intrusive, is it worth turning them off when sound is playing ? Is there an easy way to see if sound is active ? The beeps come out as tone, tone+noise or just noise when sound is active anyway, has anyone looked at why ? Along the way I found that the recent versions of esound rpm from helix-gnome don't work at all well. 'esound-0.2.17-1_helix_1.ppc.rpm' off the LinuxPPC 2000 CD is the latest I could find that works. Ken |
|
From: Michel <dae...@st...> - 2000-09-20 17:28:21
|
Robert Ramiega wrote: > If possible it could be real nice if some info about this support channel > and how to get there would be included on linux-apus.sourceforge.net I've put something up: http://linux-apus.sourceforge.net/irc.php There's also a link on the left side of the template. Thanks to Robert etc. for putting the channel up! Michel -- Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and The DRI Project |
|
From: <fh...@at...> - 2000-09-20 11:44:45
|
Can someone explain to me how APUS is using memory in relation to a driver? If I request a region, check_region()/request_region(), for I/O where will the kernel most likely map that memory. Also on the APUS Amiga how to a get memory to be non cachable? I may have asked these questions before. If so....sorry. Fred |
|
From: Robert R. <ro...@pl...> - 2000-09-19 21:14:02
|
Hi! First of all sorry for posting to both lists but i would like to get as much audience as i can. Today me and Frank Petzold (aka Rastan on IRC) decided to move #linux-apus from EFnet to much bigger IRC net called IRCnet: IRCnet Servers: >130 Locations: Australia, Austria, Belgium, Croatia, Czech Rep., Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Italy, Japan, Latvia, Malaysia, Netherlands, Norway, Poland, Russia, Slovakia, Slovenia, Sweden, Switzerland, Taiwan, UK, USA Max users: >68,000 According to irchelp.org IRCnet is the biggest IRC network out there. List of IRC servers is available at http://irc.tu-ilmenau.de/all_servers/ I think it's to big to attach it. #linux-apus (or actually people that will eventually gather there) is trying to offer help in installing and using linux-apus. If possible it could be real nice if some info about this support channel and how to get there would be included on linux-apus.sourceforge.net TIA -- Robert Ramiega | ro...@pl... IRC: _Jedi_ | Don't underestimate UIN: 13201047 | http://www.plukwa.net/ | the power of Source |
|
From: Michel <da...@re...> - 2000-09-19 12:42:51
|
Alan Buxey wrote: > > I disagree. What's so hard about 'cp -R modules/* /lib/modules/' ? I > > consider that easier than having to figure out how to use tar. You could > > put in a script which does that and maybe runs depmod -a or whatever. > > I'll work on this...would just keeping them in a plain .tar be a start > anyway? That would be better, still I don't see the need for a tarball. Wouldn't it even be easier for you to just cp -R the modules? Michel -- Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and the DRI project |
107 messages has been excluded from this view by a project administrator.
