Menu
▾
▴
linux-apus-devel
|
From: schneider <sch...@te...> - 2002-10-07 14:03:35
|
If i start the kernel from my special linuxbootpartition (fast and just the needed stuff in it), the SCSI driver won´t work. If i boot the AmigaOS 3.9, and start the kernel, the driver works!!! Is there a Initerror at the ppc kernel or the scsi driver?? I tried the whole weekend, to get the biest running, lots of rebuilds and printks, just to see there is no prob with the 53c770 driver. Just booted the wrong partition and started linux anyway... and it works. WHY? Is there any way to give the 53c770 a seperate irq number? Axel ps: i still get those ipl messages... |
|
From: Giorgio T. <de...@ip...> - 2002-10-07 17:34:19
Attachments:
dmesg
|
Hello all, as i said time ago i had problems with XFree86 some still remain but one i think i have solved: I had a problem of bad addressing during Xdm (Kdm-Gdm) loading that trashed all the graphics with these symptoms: background sometimes trashed, graphics and widgets in the greetings window become invisible but selectable. Note that these problems was found also before the CyberstormPPC firmware upgrading. After firmware upgrading i have seen that there was some differences between the PCI addressing declaration in apus_pci.c & pm2fb.c files and what the new ROM firmware reported. I attack my dmesg file where is possible to see this adresses difference and some (i think) non-influent Zorro vs. PCI address space conflicts. I have tried the modifies below and now seems that this problem is solved: diff -urN orig/apus_pci.c modif/apus_pci.c --- orig/apus_pci.c Sun Oct 28 12:44:01 2001 +++ modif/apus_pci.c Sun Sep 1 11:46:07 2002 @@ -167,7 +167,9 @@ DEFW(); writel(CVPPC_FB_APERTURE_ONE, apus_hose->cfg_data + PCI_BASE_ADDRESS_1); DEFW(); - writel(CVPPC_FB_APERTURE_TWO, apus_hose->cfg_data + PCI_BASE_ADDRESS_2); + writel(0xe0800000, apus_hose->cfg_data + PCI_BASE_ADDRESS_2); + DEFW(); + writel(CVPPC_FB_APERTURE_TWO, apus_hose->cfg_data + PCI_BASE_ADDRESS_3); DEFW(); writel(CVPPC_ROM_ADDRESS, apus_hose->cfg_data + PCI_ROM_ADDRESS); DEFW(); diff -urN orig/pm2fb.c modif/pm2fb.c --- orig/pm2fb.c Tue Aug 20 14:47:29 2002 +++ modif/pm2fb.c Sun Sep 1 11:47:22 2002 @@ -998,7 +998,8 @@ WR32(p->pci_config, PCI_CACHE_LINE_SIZE, 0xff00); WR32(p->pci_config, PCI_BASE_ADDRESS_0, CVPPC_REGS_REGION); WR32(p->pci_config, PCI_BASE_ADDRESS_1, CVPPC_FB_APERTURE_ONE); - WR32(p->pci_config, PCI_BASE_ADDRESS_2, CVPPC_FB_APERTURE_TWO); + WR32(p->pci_config, PCI_BASE_ADDRESS_2, 0xe0800000); + WR32(p->pci_config, PCI_BASE_ADDRESS_3, CVPPC_FB_APERTURE_TWO); WR32(p->pci_config, PCI_ROM_ADDRESS, CVPPC_ROM_ADDRESS); DEFW(); WR32(p->pci_config, PCI_COMMAND, 0xef000000 | I wish to submit these modifies if you think they have "a sense" . Remaining problems: Note also that the vterminal exchange problem is still present as i wrote time ago. The warbled text problem i signaled succedes only in the X text windows as Xterm or Mozilla and so on. I think this is a driver's limitation because with 1024x768x16 resolution this succedes only when the machine is very stressed but with 1152x864x16 and over this succedes everytime i open a window. With these high resolutions it warbles also the graphics. Every suggestion is welcome. Regards, Giorgio Terzi |
|
From: Michel <mi...@da...> - 2002-10-11 12:50:28
|
On Mon, 2002-10-07 at 19:32, Giorgio Terzi wrote:=20 >=20 > as i said time ago i had problems with XFree86 some still remain > but one i think i have solved: > I had a problem of bad addressing during Xdm (Kdm-Gdm) loading > that trashed all the graphics with these symptoms: background sometimes > trashed, graphics and widgets in the greetings window become invisible > but selectable. > Note that these problems was found also before the CyberstormPPC > firmware upgrading. > After firmware upgrading i have seen that there was some differences betw= een > the PCI addressing declaration in apus_pci.c & pm2fb.c files and what the= new > ROM firmware reported. > I attack my dmesg file where is possible to see this adresses difference > and some (i think) non-influent Zorro vs. PCI address space conflicts. >=20 > I have tried the modifies below and now seems that this problem is solved= : >=20 > diff -urN orig/apus_pci.c modif/apus_pci.c > --- orig/apus_pci.c Sun Oct 28 12:44:01 2001 > +++ modif/apus_pci.c Sun Sep 1 11:46:07 2002 > @@ -167,7 +167,9 @@ > DEFW(); > writel(CVPPC_FB_APERTURE_ONE, apus_hose->cfg_data + PCI_BASE_ADDRESS_1)= ; > DEFW(); > - writel(CVPPC_FB_APERTURE_TWO, apus_hose->cfg_data + PCI_BASE_ADDRESS_2)= ; > + writel(0xe0800000, apus_hose->cfg_data + PCI_BASE_ADDRESS_2); > + DEFW(); > + writel(CVPPC_FB_APERTURE_TWO, apus_hose->cfg_data + PCI_BASE_ADDRESS_3)= ; > DEFW(); > writel(CVPPC_ROM_ADDRESS, apus_hose->cfg_data + PCI_ROM_ADDRESS); > DEFW(); > diff -urN orig/pm2fb.c modif/pm2fb.c > --- orig/pm2fb.c Tue Aug 20 14:47:29 2002 > +++ modif/pm2fb.c Sun Sep 1 11:47:22 2002 > @@ -998,7 +998,8 @@ > WR32(p->pci_config, PCI_CACHE_LINE_SIZE, 0xff00); > WR32(p->pci_config, PCI_BASE_ADDRESS_0, CVPPC_REGS_REGION); > WR32(p->pci_config, PCI_BASE_ADDRESS_1, CVPPC_FB_APERTURE_ONE); > - WR32(p->pci_config, PCI_BASE_ADDRESS_2, CVPPC_FB_APERTURE_TWO); > + WR32(p->pci_config, PCI_BASE_ADDRESS_2, 0xe0800000); > + WR32(p->pci_config, PCI_BASE_ADDRESS_3, CVPPC_FB_APERTURE_TWO); > WR32(p->pci_config, PCI_ROM_ADDRESS, CVPPC_ROM_ADDRESS); > DEFW(); > WR32(p->pci_config, PCI_COMMAND, 0xef000000 | >=20 > I wish to submit these modifies if you think they have "a sense" . Will these modifications also work with older firmware or whatever makes th= e difference? > The warbled text problem i signaled succedes only in the X text windows a= s > Xterm or Mozilla and so on. I think this is a driver's limitation because= =20 > with 1024x768x16 resolution this succedes only when the machine is very=20 > stressed but with 1152x864x16 and over this succedes everytime i open a=20 > window. With these high resolutions it warbles also the graphics. Sounds like bus contention and/or synchronization problems in the 2D acceleration code. --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
|
From: Rene B. <re...@we...> - 2002-10-07 18:09:43
|
On 2002.10.07 16:08 schneider wrote: > If i start the kernel from my special linuxbootpartition (fast and just > the needed stuff in it), the SCSI driver won´t work. > If i boot the AmigaOS 3.9, and start the kernel, the driver works!!! I also use such a start partition, without problems. No start of AmigaOS needed. > Is there a Initerror at the ppc kernel or the scsi driver?? Some parts of the 53c770 isn't configured by the driver (especially the scsi burst mode) and needs to be initialized by the CSPPC-firmware. This is normaly done if the Amiga is switched on. But maybe the different firmware-versions behaves different. As far as I know, the newest can be found at: ftp://ftp.meanmachine.ch/pub/amiga/ppclib Will be nice if you can check out your version. > I tried the whole weekend, to get the biest running, lots of rebuilds > and printks, just to see there is no prob with the 53c770 driver. > Just booted the wrong partition and started linux anyway... and it works. > WHY? > Is there any way to give the 53c770 a seperate irq number? Don't know. "IRQ_AMIGA_PORTS" is used and is stolen from other scsi-drivers. Ciao, Renè |
|
From: Giorgio T. <de...@ip...> - 2002-10-12 09:58:00
|
Alle 14:50, venerd=EC 11 ottobre 2002, Michel D=E4nzer ha scritto: > Will these modifications also work with older firmware or whatever make= s > the difference? Oops, you're right, i haven't tried this, i will try it (downgrading the=20 firmware) this weekend.=20 Test results will follow. > > The warbled text problem i signaled succedes only in the X text windo= ws > > as Xterm or Mozilla and so on. I think this is a driver's limitation > > because with 1024x768x16 resolution this succedes only when the machi= ne > > is very stressed but with 1152x864x16 and over this succedes everytim= e i > > open a window. With these high resolutions it warbles also the graphi= cs. > > Sounds like bus contention and/or synchronization problems in the 2D > acceleration code. I think that what you are saying is also (or something near) the reason why the framebuffer crashes after a vterm exchange from X . Is it possible that X is not signalled to release its resources and go to= =20 sleep ? The few times that i am able to exchange vterms, X is completely killed=20 (also its child tasks) by the system and the Xdm task that remains alive is not able to re-open another X task.=20 I can test it, could you suggest me where to put the hands :-) ? Regards Giorgio Post Scriptum. In my last mail i forgotten to say that after the migration of my Linux=20 partitions from IDE to SCSI hdisks, a strange bug seems disappeared: Sometimes, when connected to internet and using X, something hanged the X task or the whole machine. Now seems solved... (I cross my fingers... :-) ). |
|
From: schneider <sch...@te...> - 2002-10-12 10:26:08
|
Giorgio Terzi wrote: > Alle 14:50, venerdì 11 ottobre 2002, Michel Dänzer ha scritto: > > >>Will these modifications also work with older firmware or whatever makes >>the difference? > > > Oops, you're right, i haven't tried this, i will try it (downgrading the > firmware) this weekend. > Test results will follow. > > >>>The warbled text problem i signaled succedes only in the X text windows >>>as Xterm or Mozilla and so on. I think this is a driver's limitation >>>because with 1024x768x16 resolution this succedes only when the machine >>>is very stressed but with 1152x864x16 and over this succedes everytime i >>>open a window. With these high resolutions it warbles also the graphics. >> >>Sounds like bus contention and/or synchronization problems in the 2D >>acceleration code. > > > I think that what you are saying is also (or something near) the reason > why the framebuffer crashes after a vterm exchange from X . > Is it possible that X is not signalled to release its resources and go to > sleep ? > The few times that i am able to exchange vterms, X is completely killed > (also its child tasks) by the system and the Xdm task that remains alive > is not able to re-open another X task. > I can test it, could you suggest me where to put the hands :-) ? > > Regards > > Giorgio > > Post Scriptum. > In my last mail i forgotten to say that after the migration of my Linux > partitions from IDE to SCSI hdisks, a strange bug seems disappeared: > Sometimes, when connected to internet and using X, something > hanged the X task or the whole machine. Now seems solved... > (I cross my fingers... :-) ). Seems the same problem like i have. Btw: i still have problems with it, sometime it even crashes during init of the scsi disks! Sometimes later... bug is still present. > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-apus-devel > |
|
From: Michel <mi...@da...> - 2002-10-12 12:57:26
|
On Sam, 2002-10-12 at 11:53, Giorgio Terzi wrote: > Alle 14:50, venerd=EC 11 ottobre 2002, Michel D=E4nzer ha scritto: >=20 > > > The warbled text problem i signaled succedes only in the X text windo= ws > > > as Xterm or Mozilla and so on. I think this is a driver's limitation > > > because with 1024x768x16 resolution this succedes only when the machi= ne > > > is very stressed but with 1152x864x16 and over this succedes everytim= e i > > > open a window. With these high resolutions it warbles also the graphi= cs. > > > > Sounds like bus contention and/or synchronization problems in the 2D > > acceleration code. >=20 > I think that what you are saying is also (or something near) the reason > why the framebuffer crashes after a vterm exchange from X . > Is it possible that X is not signalled to release its resources and go to= =20 > sleep ? It does, but one potential problem I see is that the glint driver still lets the driver independent code call fbdevHW functions directly. I've modified the radeon driver in DRI CVS to always go through driver functions and make sure the acceleration engine is idle before calling an fbdevHW function. You may want to take a look at that and try something similar with the glint driver. --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X