From: <fh...@at...> - 2000-11-27 12:28:20
|
Has anyone tried the driver lately? What happened. I would like to see a dmesg output. Also, some folks tried the original driver and evidently it sort of worked. (I saw this in an old email) If you are one of those people, what kernel version were you using? I also did not see if they where using M68K or APUS. I've been considering reloading M68K Linux to see if getting the driver to work there is easier. After all the NetBSD driver already works. Fred |
From: <gri...@ps...> - 2000-12-04 18:49:40
|
> Has anyone tried the driver lately? Trying.. I have a working kernel, but... > What happened. I would like to see a dmesg output. I tried it as a module with 2.4.0-test11 and I always get an undefined symbol when inderting: kernel_set_cachemode I'll try a compiled-in version soon. Bye, Arno. -- PSINetworks Europe Phone: +31-23-5699846 | One disk to rule them all, Siriusdreef 34 FAX: +31-20-8640234 | 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: <gri...@ps...> - 2000-12-05 19:03:17
|
> I'll try a compiled-in version soon. Tried it, but I see nothing. Do I need a specific boothack version or boot-flags? I'll try a complete rebuild just to be sure.. This is the dmesg I get with a compiled-in 53c770 driver (notice it's absence ;-): Total memory = 127MB; using 512kB for hash table (at c0200000) Linux version 2.4.0-test11 (ar...@ha...) (gcc version 2.95.2 20000220 (Debian GNU/Linux)) #7 Mon Dec 4 21:04:40 CET 2000 Amiga hardware found: [A3000] VIDEO BLITTER AMBER_FF AUDIO FLOPPY A3000_SCSI KEY BOARD MOUSE SERIAL PARALLEL A3000_CLK CHIP_RAM PAULA DENISE_HR AGNUS_HR_PAL MAGI C_REKICK ZORRO3 On node 0 totalpages: 32640 zone(0): 32640 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: video=pm2fb: wd33c93=disconnect:2 root=/dev/sda1 60nsram si ngle amiga_enable_irq: Trying to enable auto-vector IRQ 1 amiga_enable_irq: Trying to enable auto-vector IRQ 3 amiga_enable_irq: Trying to enable auto-vector IRQ 4 amiga_enable_irq: Trying to enable auto-vector IRQ 5 amiga_enable_irq: Trying to enable auto-vector IRQ 7 amiga_enable_irq: Trying to enable auto-vector IRQ 2 amiga_enable_irq: Trying to enable auto-vector IRQ 6 APUS: BATs=1, BUS=67MHz, RAM=60ns, PCI bridge=1 time_init: decrementer frequency = 16.353125 MHz Console: colour dummy device 80x25 Calibrating delay loop... 457.11 BogoMIPS Memory: 126056k available (992k kernel code, 452k data, 220k init, 0k highmem) Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) POSIX conformance testing by UNIFIX PCI: Probing PCI hardware Zorro: Probing AutoConfig expansion devices: 4 devices Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd v1.8 Console: switching to colour frame buffer device 80x30 fb0: CVisionPPC/BVisionPPC (Permedia2), using 8192K of video memory. fb1: Amiga ECS frame buffer device, using 640K of video memory pty: 256 Unix98 ptys configured Amiga mouse installed. SCSI subsystem driver Revision: 1.00 wd33c93-0: chip=WD33c93A/9 no_sync=0xff no_dma=0 debug_flags=0x00 setup_args==disconnect:2,,,,,,,,, Version 1.25 - 09/Jul/1997, Compiled Dec 4 2000 at 21:10:15 scsi0 : Amiga 3000 built-in SCSI sending SDTR 0103016400sync_xfer=40 Vendor: FUJITSU Model: M2909S-512 Rev: 0127 Type: Direct-Access ANSI SCSI revision: 02 sending SDTR 0103015e00sync_xfer=30 Vendor: IBM Model: DORS-32160 Rev: WA0A Type: Direct-Access ANSI SCSI revision: 02 sending SDTR -REJ- Vendor: WANGTEK Model: 5150ES SCSI FA03 Rev: 08 Type: Sequential-Access ANSI SCSI revision: 01 sending SDTR -REJ- Vendor: YAMAHA Model: CRW4260 Rev: 1.0h Type: CD-ROM ANSI SCSI revision: 02 sending SDTR Vendor: SCANNER Model: Rev: V100 Type: Scanner ANSI SCSI revision: 01 CCS Detected scsi disk sda at scsi0, channel 0, id 0, lun 0 Detected scsi disk sdb at scsi0, channel 0, id 1, lun 0 SCSI device sda: 6054834 512-byte hdwr sectors (3100 MB) Partition check: /dev/scsi/host0/bus0/target0/lun0: RDSK p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12 SCSI device sdb: 4226725 512-byte hdwr sectors (2164 MB) /dev/scsi/host0/bus0/target1/lun0: RDSK p1 p2 NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 8192 bind 8192) devfs: v0.102 (20000622) Richard Gooch (rg...@at...) devfs: boot_options: 0x2 VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 220k init NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Adding Swap: 127908k swap-space (priority -1) Bye, Arno. -- PSINetworks Europe Phone: +31-23-5699846 | One disk to rule them all, Siriusdreef 34 FAX: +31-20-8640234 | 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: <gri...@ps...> - 2000-12-07 10:14:35
|
OK.. Undefining the 'PCI for Permedia2' option causes 'CONFIG_PCI' to go away and may help in getting the 53c770 to do a little more.. At least now it doesn't link anymore :-( drivers/scsi/scsidrv.o(.text.init+0x2584): undefined reference to `zorro_find' drivers/scsi/scsidrv.o(.text.init+0x2594): undefined reference to `zorro_get_board' drivers/scsi/scsidrv.o(.text.init+0x25c4): undefined reference to `zorro_config_board' I already got a bit worried when I saw this (among others) when it was compiling 53c770.c: 53c770.c: In function `ncr53c8xx_detect': 53c770.c:10101: warning: implicit declaration of function `zorro_find' 53c770.c:10102: warning: implicit declaration of function `zorro_get_board' 53c770.c:10102: warning: assignment makes pointer from integer without a cast 53c770.c:10108: warning: implicit declaration of function `zorro_config_board' Weren't those calls obsoleted and replaced a while back? At least zorro_find() should be zorro_find_device(bla bla bla). OK.. I'll try to hack it into a compilable format tonight. Bye, Arno. -- PSINetworks Europe Phone: +31-23-5699846 | One disk to rule them all, Siriusdreef 34 FAX: +31-20-8640234 | 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: Michel <da...@re...> - 2000-12-07 13:34:06
|
Arno Griffioen wrote: > Undefining the 'PCI for Permedia2' option causes 'CONFIG_PCI' to go away and > may help in getting the 53c770 to do a little more.. I thought the 53c770 wasn't PCI so I don't understand how that can interfere. 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-12-07 13:43:08
|
hi, > > Undefining the 'PCI for Permedia2' option causes 'CONFIG_PCI' to go away and > > may help in getting the 53c770 to do a little more.. > > I thought the 53c770 wasn't PCI so I don't understand how that can interfere. is it located on the 'PCI bus' of the PowerUP cards though? Perhaps it was easier/cheaper to implement it as such? alan |
From: <gri...@ps...> - 2000-12-07 13:43:31
|
> > Undefining the 'PCI for Permedia2' option causes 'CONFIG_PCI' to go away and > > may help in getting the 53c770 to do a little more.. > > I thought the 53c770 wasn't PCI so I don't understand how that can interfere. Fred's driver is based on the 53c8xx, which is PCI based and that code is still in there. This sort of thing kills the init when CONFIG_PCI is defined: #ifdef CONFIG_PCI static int ncr53c8xx_pci_init(Scsi_Host_Template *tpnt, uchar bus, uchar device_fn, ncr_device *device); #else static int ncr53c770_init(Scsi_Host_Template *tpnt, unsigned long base, unsigned int irq, ncr_device *device); #endif Bye, Arno. -- PSINetworks Europe Phone: +31-23-5699846 | One disk to rule them all, Siriusdreef 34 FAX: +31-20-8640234 | 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: Michel <da...@re...> - 2000-12-07 14:38:35
|
Arno Griffioen wrote: > > > > Undefining the 'PCI for Permedia2' option causes 'CONFIG_PCI' to go away > > > and may help in getting the 53c770 to do a little more.. > > > > I thought the 53c770 wasn't PCI so I don't understand how that can > > interfere. > > Fred's driver is based on the 53c8xx, which is PCI based and that code > is still in there. > > This sort of thing kills the init when CONFIG_PCI is defined: > > #ifdef CONFIG_PCI > static int ncr53c8xx_pci_init(Scsi_Host_Template *tpnt, > uchar bus, uchar device_fn, ncr_device *device); > #else > static int ncr53c770_init(Scsi_Host_Template *tpnt, unsigned long base, > unsigned int irq, ncr_device *device); > #endif This doesn't make sense to me. I guess the 53c8xx code could just be removed from the 53c770 code? 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: <gri...@ps...> - 2000-12-07 14:42:09
|
> > This sort of thing kills the init when CONFIG_PCI is defined: > > > > #ifdef CONFIG_PCI > > static int ncr53c8xx_pci_init(Scsi_Host_Template *tpnt, > > uchar bus, uchar device_fn, ncr_device *device); > > #else > > static int ncr53c770_init(Scsi_Host_Template *tpnt, unsigned long base, > > unsigned int irq, ncr_device *device); > > #endif > > This doesn't make sense to me. I guess the 53c8xx code could just be removed > from the 53c770 code? Or a more elegant solution in which case there wouldn't need to be a separate 53c770 driver, but included in an existing 53c8xx driver. As this is basically development code I don't really care. Just took me a while to figure out why it didn't seem tohave any effect when I compiled in the driver.. Bye, Arno. -- PSINetworks Europe Phone: +31-23-5699846 | One disk to rule them all, Siriusdreef 34 FAX: +31-20-8640234 | 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: <fh...@at...> - 2000-12-08 12:29:16
|
In <200...@su...>, on 12/07/00 at 03:42 PM, gri...@ps... (Arno Griffioen) said: >> > This sort of thing kills the init when CONFIG_PCI is defined: >> > >> > #ifdef CONFIG_PCI >> > static int ncr53c8xx_pci_init(Scsi_Host_Template *tpnt, >> > uchar bus, uchar device_fn, ncr_device *device); >> > #else >> > static int ncr53c770_init(Scsi_Host_Template *tpnt, unsigned long base, >> > unsigned int irq, ncr_device *device); >> > #endif >> >> This doesn't make sense to me. I guess the 53c8xx code could just be removed >> from the 53c770 code? >Or a more elegant solution in which case there wouldn't need to be a >separate 53c770 driver, but included in an existing 53c8xx driver. This is the best solution IMHO. Basically all the current LSI chips have about the same scripts processor and share a lot of the same features. Of course the very new chips began to diverge. All of the 53c8xx drivers I have looked at have the same basic data structures. This is for the 53c810 chip on up. The biggest stumbling point I can see is that the 8xx series of chips is very PCI so the routines that heavily depend on PCI has to have the correct logic figured out to accommodate both. >As this is basically development code I don't really care. Just took me >a while to figure out why it didn't seem tohave any effect when I >compiled in the driver.. I am playing with different driver code at the moment, the sym53c8xx.c code. My reason for switching is that it shares the new style data structures and should be easier to merge into the newest versions, if that ever becomes possible. I have gotten the newer code to get to the cache test, where it fails to execute the SCSI scripts code, though everything looks "right". For example, the correct addresses and so forth appear. There is some very basic problem with making the 53c770 chip work with Linux or PowerPC. The problem has to be PPC or APUS related because those same 53c8xx chips are used in PCI cards that work on a variety of other architectures and Linuxes. I have been trying to figure out what the differences could be. BTW the newer drivers have a sort of generic mb() support as well. I really don't want to start looking at assembly code, but ultimately that may be what has to be done. i.e. find the driver sections that misbehave in the kernel assembler code and see if the code looks "right." (Any tips on how one goes about doing that would be appreciated.) Additionally, Richard Hirst has gotten the 770 chip to work on a HP system. He had to make a few modifications to the actual SCSI routines in the code to take into account small differences between the 8xx and 770 SCSI processors. There is another problem as well. All the PCI based cards have ROMs or NVRAM onboard that store the initial setting of the SCSI chip. The correct initial settings of the 53c770 chip has to be found. Sorry in advance for rambling on and probably repeating myself from previous posts. Fred |
From: Geert U. <ge...@li...> - 2000-12-09 18:40:32
|
On Fri, 8 Dec 2000 fh...@at... wrote: > There is some very basic problem with making the 53c770 chip work with > Linux or PowerPC. The problem has to be PPC or APUS related because those > same 53c8xx chips are used in PCI cards that work on a variety of other > architectures and Linuxes. I have been trying to figure out what the FYI, I have a Sym53c875 PCI card in my PPC CHRP box, which works fine with Linux. 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: F. H. <fh...@at...> - 2000-12-09 22:18:41
|
On Sat, Dec 09, 2000 at 02:45:02PM +0100, Geert Uytterhoeven wrote: > On Fri, 8 Dec 2000 fh...@at... wrote: > > There is some very basic problem with making the 53c770 chip work with > > Linux or PowerPC. The problem has to be PPC or APUS related because those > > same 53c8xx chips are used in PCI cards that work on a variety of other > > architectures and Linuxes. I have been trying to figure out what the > > FYI, I have a Sym53c875 PCI card in my PPC CHRP box, which works fine with > Linux. That's good to hear that I am at least partially wrong then. It's too bad Phase 5 didn't use a LSI PCI SCSI chip. Creating a driver may have been much easier then. BTW I have found another thing I was wrong about. I thought most of the LSI chips had the same or nearly the same script processor. After looking at the scripts.pdf document from the LSI web site, I see that some of the instructions or instruction variations are not supported on the 770 chip. Fred |
From: <gri...@ps...> - 2000-12-11 07:24:04
|
Hi! This is what I get with the '770 driver compiled in. Looks pretty much the same as you posted before: Trying to detect PuP SCSI... ncr53c8xx: 53c770 detected ncr53c770-0: rev=0x00, base=0xf40000, io_port=0x0, irq=12 Storing input new SCRIPT[3772] @c04f8000. new SCRIPTH[3708] @c04f3000. np: ID: 770 REV: 0 FEA: 15382 CLCK: 5 OF: 10 Initialize timer paddr: f40000 paddr2: 0 vaddr: 80f40000 io_port: 0 Peparing... myaddr: 0 myaddr: 7 myaddr: 7 ncr53c770- 0: ID 7, Fast-20, Parity Checking verbose:5 ncr53c770- 0: initial SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 05/c0/20/00/00/04 ncr53c770- 0: final SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 05/82/20/00/08/24 no on-board ram scripth: c04f3000 p_scripth: 84f3000 script: c04f8000 p_script: 84f8000 Resetting for snoop test SCSI reset cleared test: aabbff11 aabbff11 virt_to_phys(np): 84f4080 np: c04f4080 ncr_cache: 00000000 pc: 084f3e50 ncr_cache:ptr: c04f40d8 val: 0 offset: 58 np->ncr_cache: faedbeef ncr_wr: deadfead cache addr: 84f40d8 t_istat: 1 dstat: 84 (1 128) dsp: 84f3e7c dsps: 63 (139411068 99) sstat2: 2 (2) term pc: 84f3e7c CACHE TEST FAILED: host wrote -85082385, ncr read 0 (0). CACHE TEST FAILED: ncr wrote -559022419, host read -85082385. CACHE INCORRECTLY CONFIGURED. ncr53c770- 0: detaching... Bye, Arno. -- PSINetworks Europe Phone: +31-23-5699846 | One disk to rule them all, Siriusdreef 34 FAX: +31-20-8640234 | 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: Alan B. <al...@ms...> - 2000-12-07 16:01:01
|
hi, > > #ifdef CONFIG_PCI > > static int ncr53c8xx_pci_init(Scsi_Host_Template *tpnt, > > uchar bus, uchar device_fn, ncr_device *device); > > #else > > static int ncr53c770_init(Scsi_Host_Template *tpnt, unsigned long base, > > unsigned int irq, ncr_device *device); > > #endif > > This doesn't make sense to me. I guess the 53c8xx code could just be removed > from the 53c770 code? yes, you dont need the if/else at all, just the static int ncr53c_blahblah line alan |