Menu
▾
▴
linux-visws-devel — Linux on Visual Workstation development list
You can subscribe to this list here.
| 2002 |
Jan
(29) |
Feb
|
Mar
(6) |
Apr
(6) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(16) |
Oct
(6) |
Nov
(8) |
Dec
(28) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(33) |
Feb
(5) |
Mar
(10) |
Apr
(3) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Florian B. <bo...@un...> - 2003-05-30 14:40:23
|
Hi! Kris Nielander wrote: > Did you also experiment with 32 bit depth ? Or were those altered values > just a coincidence ?? :P Eh, yes - i tried... but without success. My mistake that these experimenatal changes found their way into the patch. I didn't make the framebuffer contain a single red pixel in 32 bit mode. Bcause of this i think this could be a bug in linux fb code or some other place i have no idea of how it works. > I'm running it now on the 2.5.70-mm2 kernel .. Great, i'm just trying with plain 2.5.70 :-) Greetings Florian -- The dream of yesterday Florian Boor is the hope of today Tel: 0271-7411487 | Fax: 0180-5052 5393 9324 and the reality of tomorrow. flo...@bs... | bo...@un... [Robert Hutchings Goddard, 1904] 6C 44 30 4C 43 20 6B 61 16 07 0F AA E6 97 70 A8 |
|
From: Florian B. <bo...@un...> - 2003-05-28 16:33:27
|
Hi all! This patch should make XFree4 in 15 bit depth run correct on SGI 320 framebuffer. Have fun... Greetings Florian -- The dream of yesterday Florian Boor is the hope of today Tel: 0271-7411487 | Fax: 0180-5052 5393 9324 and the reality of tomorrow. flo...@bs... | bo...@un... [Robert Hutchings Goddard, 1904] 6C 44 30 4C 43 20 6B 61 16 07 0F AA E6 97 70 A8 |
|
From: Florian B. <bo...@un...> - 2003-04-23 06:39:28
|
Hello! Steve Allen wrote: > I did manage to get installs of Redhat 7.3 and 8.0 loaded, by using another > PC to load the disk. However, I was unable to get any graphics going in > 8.0, and poorly in 7.3 (screen showing top right 1/4 of the desktop). > > Also, I did get kernel 2.5.65 to compile, but though it loaded, it wouldn't > run. No change of screen once the kernel loaded. All I've been able to > make go is the original la2210.vw kernel. That's possible - especially if you're using the 1600SW screen - in this case you have to tell the kernel to use this device (the old 2.2.10 was able to detect this) Add this to your kernel starting parameters in arc firmware: video=sgivw:monitor:1600sw > - a working kernel config file My one is at home... while i'm not at home... But basically you need this: - Visual Workstation support - VW framebuffer support - USB HID - if you have, Qlogic 1080/1280 SCSI - Serial console (in case of trouble with the framebuffer > - a working xfree86 config file Basically a normal framebuffer configuration, but with 2.5.x there are still some problems: - 32Bit mode seems to be broken - 15Bit mode works with X, but Xrender extensions don't work - 8Bit mode should be ok Greetings Florian -- The dream of yesterday Florian Boor is the hope of today Tel: 0271-7411487 | Fax: 0180-5052 5393 9324 and the reality of tomorrow. flo...@bs... | bo...@un... [Robert Hutchings Goddard, 1904] 6C 44 30 4C 43 20 6B 61 16 07 0F AA E6 97 70 A8 |
|
From: <al...@do...> - 2003-04-21 18:40:56
|
Hi. I've been playing with a 320, trying to get something newer than RedHat 6.2 running on it. I did manage to get installs of Redhat 7.3 and 8.0 loaded, by using another PC to load the disk. However, I was unable to get any graphics going in 8.0, and poorly in 7.3 (screen showing top right 1/4 of the desktop). Also, I did get kernel 2.5.65 to compile, but though it loaded, it wouldn't run. No change of screen once the kernel loaded. All I've been able to make go is the original la2210.vw kernel. So, I'm begging for some help here... What I need is: - to know what RedHat version works (graphics especially) - a working kernel config file - a working xfree86 config file - any other information necessary to make this thing work Thanks, Steve -- Steven R. Allen - SGI Admin Weenie Unix sysadmin: IRIX, Linux, NetBSD (developer), Mac OS X, Solaris I know I don't deserve another chance, but this _is_ America, and as an American, aren't I entitled to one? --Sideshow Bob. |
|
From: Florian B. <bo...@un...> - 2003-04-14 21:11:20
|
Hello all! Now that CeBit is over i had more time to play with my 320. I tried somer things around X and framebuffer. My current state is this: - The framebuffer is 16 bit mode works in 556/5551 bit mode. This mode works OK, X basically supports this too. On x86 platforms the XRender extension doesn't support other color bits mode than 565. This is the reason why gtk based software like gnome* etc. doesn't work. - In 32 bit mode the framebuffer at least works, but i'm not shure if it works correctly. That what i get as output from fbset looks correct. (RGBA mode with 8 bits/color each) X -fbbpp 32 starts with a depth of 24, the weight looks ok, but i have no red in any pixel. Assuming X works correct in 32 bit mode i think this is a bug in the framebuffer code. I looked around a little bit, but i had no success bringing any red pixel at the screen in 32 bit mode :-/ If someone with some more experience with framebuffer code than me would look at this, maybe he could fix this bug faster than me stumbling around and flipping bits :-) Greetings Florian -- The dream of yesterday Florian Boor is the hope of today Tel: 0271-7411487 | Fax: 0180-5052 5393 9324 and the reality of tomorrow. flo...@bs... | bo...@un... [Robert Hutchings Goddard, 1904] 6C 44 30 4C 43 20 6B 61 16 07 0F AA E6 97 70 A8 |
|
From: Steve A. <al...@do...> - 2003-03-26 21:36:52
|
Hi. Trying to install on a VW 320... Using the directions and files available at http://linux-visws.sourceforge.net/ it's able to boot the kernel and load the ramdisk, but when I insert the CDROM for RH6.2 (and press return), the CDROM drive blinks once and does no more. Same with several other versions of RH Linux. So, I've been trying to get 2.4.17 to load. I have managed to build arcloader-2003, but have not managed to make a form of the 2.4.17 kernel that it's happy with. (I'm assuming I need to apply some kind of compression to it because it's too big to fit on the floppy.) A simple gzip -9 just yields a "kernel format unrecognized" error. Same with bzip2. I did a kernel build on a regular RH8.0 system (2.4.18 kernel), then copied its final steps for building a bzImage file. That effort first yielded a "loading gzip compressed kernel image" message, followed by the "kernel format unrecognized" error. Am I headed in the right direction? Barking up the wrong tree? A bit of clue would be appreciated. Thanks, ~Steve |
|
From: Florian B. <bo...@un...> - 2003-03-11 18:50:37
|
Hi! > What about the icons, could this be Pango ? Nope, pango is the font renderer - we should look at Xft... and the X RENDER extention... > As soon as I know more about that 'use' flag, I will check the ebuild of > xfree 4.2.1. This could be interesting... and i'll try to contact the debian X maintainers :-) Greetings Florian -- The dream of yesterday Florian Boor is the hope of today Tel: 0271-7411487 | Fax: 0180-5052 5393 9324 and the reality of tomorrow. flo...@bs... | bo...@un... [Robert Hutchings Goddard, 1904] 6C 44 30 4C 43 20 6B 61 16 07 0F AA E6 97 70 A8 |
|
From: Kris N. <kr...@we...> - 2003-03-11 18:26:57
|
Oi, On Tue, 2003-03-11 at 18:28, Florian Boor wrote: > Hello! > > Kris Nielander wrote: > > Morning, > > > > Could this have anything to do with the fact that the framebuffer's > > visual mode remains in PSEUDOCOLOR at a depth of 16? > > This seems to be the problem (X will only start in 15/16 bit modes)... X does start in other modes (8,15,16,32), though the output on the screen is even worse than the blue and yellow overlay. It being a solid green or blue with here and there some signs of the WM. > but if think i have a very interesting hint: > I mailed the problem to gnome-devel mailinglist. Owen Taylor and Keith Packard > told me that the whole rendering stuff is done by Xft What about the icons, could this be Pango ? > and that there is extra > code for every setting of "-weight". The weight of 556 as on our 320 is usually not > used on other x86 systems. Maybe support for this is not activated in the X server > we use or buggy in Xft. As soon as I know more about that 'use' flag, I will check the ebuild of xfree 4.2.1. > Do you use debian? You may already have guessed, it's gentoo :). Greetings, Kris |
|
From: Florian B. <bo...@un...> - 2003-03-11 17:31:12
|
Hello! Kris Nielander wrote: > Morning, > > Could this have anything to do with the fact that the framebuffer's > visual mode remains in PSEUDOCOLOR at a depth of 16? This seems to be the problem (X will only start in 15/16 bit modes)... but if think i have a very interesting hint: I mailed the problem to gnome-devel mailinglist. Owen Taylor and Keith Packard told me that the whole rendering stuff is done by Xft and that there is extra code for every setting of "-weight". The weight of 556 as on our 320 is usually not used on other x86 systems. Maybe support for this is not activated in the X server we use or buggy in Xft. Do you use debian? Greetings Florian -- The dream of yesterday Florian Boor is the hope of today Tel: 0271-7411487 | Fax: 0180-5052 5393 9324 and the reality of tomorrow. flo...@bs... | bo...@un... [Robert Hutchings Goddard, 1904] 6C 44 30 4C 43 20 6B 61 16 07 0F AA E6 97 70 A8 |
|
From: Kris N. <kr...@we...> - 2003-03-11 09:31:30
|
Morning,
Could this have anything to do with the fact that the framebuffer's
visual mode remains in PSEUDOCOLOR at a depth of 16?
While in X,
darez root # fbset -i
mode "1280x1024-85"
# D: 157.505 MHz, H: 91.149 kHz, V: 85.027 Hz
geometry 1280 1024 1280 1024 16
timings 6349 224 64 44 1 160 3
hsync high
vsync high
rgba 5/11,6/6,5/1,0/0
endmode
Frame buffer device information:
Name : SGI Vis WS FB
Address : 0x1f800000
Size : 8388608
Type : PACKED PIXELS
Visual : PSEUDOCOLOR
XPanStep : 0
YPanStep : 0
YWrapStep : 0
LineLength : 2560
MMIO Address: 0xd0000000
MMIO Size : 16777216
Accelerator : No
My log however reveals that visual is set to the default @ depth 16. The
default being TRUECOLOR. Is this just fbset ?
Greetings,
Kris
On Sun, 2003-03-09 at 11:12, Florian Boor wrote:
> Hello!
>
> > A few mails ago Florian talked about the setting the weight element in XF86Config to 556 and although
> > it resolves the color issue. It is also results to this http://darez.we-dare.net/~kris/gedit.jpg ...
> > Setting the weight element to 565, returns icons and AA-fonts... But it screws with blue and yellow.
> > However doing a screenie of a gedit at that weight setting results to this http://darez.we-dare.net/~kris/gedit2.jpg
> > Looks good right... Well, it doesn't overhere :D .. It still has that nice(?) blue/yellow overlay pattern..
>
> This is really interesting, looks like the rendering engines of GTK run into trouble with
> this framebuffer device :-/ I think it is possible that GTK somewhere gets wrong values
> for color depth or color weight. KDE seems to have no problems with this...
> I'm very bust till end of CeBit, but if i find some minute, i'll try to find out what
> happens.
>
> Greetings
>
> Florian
|
|
From: Florian B. <bo...@un...> - 2003-03-09 10:14:30
|
Hello! > A few mails ago Florian talked about the setting the weight element in XF86Config to 556 and although > it resolves the color issue. It is also results to this http://darez.we-dare.net/~kris/gedit.jpg ... > Setting the weight element to 565, returns icons and AA-fonts... But it screws with blue and yellow. > However doing a screenie of a gedit at that weight setting results to this http://darez.we-dare.net/~kris/gedit2.jpg > Looks good right... Well, it doesn't overhere :D .. It still has that nice(?) blue/yellow overlay pattern.. This is really interesting, looks like the rendering engines of GTK run into trouble with this framebuffer device :-/ I think it is possible that GTK somewhere gets wrong values for color depth or color weight. KDE seems to have no problems with this... I'm very bust till end of CeBit, but if i find some minute, i'll try to find out what happens. Greetings Florian -- The dream of yesterday Florian Boor is the hope of today Tel: 0271-7411487 | Fax: 0180-5052 5393 9324 and the reality of tomorrow. flo...@bs... | bo...@un... [Robert Hutchings Goddard, 1904] 6C 44 30 4C 43 20 6B 61 16 07 0F AA E6 97 70 A8 |
|
From: kris <kr...@we...> - 2003-03-06 15:54:21
|
Goodday to all, A few mails ago Florian talked about the setting the weight element in = XF86Config to 556 and although=20 it resolves the color issue. It is also results to this = http://darez.we-dare.net/~kris/gedit.jpg ... Setting the weight element to 565, returns icons and AA-fonts... But it = screws with blue and yellow. However doing a screenie of a gedit at that weight setting results to = this http://darez.we-dare.net/~kris/gedit2.jpg Looks good right... Well, it doesn't overhere :D .. It still has that = nice(?) blue/yellow overlay pattern.. If anyone could give me a clue... Thanks Best regards, Kris Nielander=20 |
|
From: Andrey P. <pa...@or...> - 2003-02-26 08:02:02
|
Hello all, SGI Visual Workstation support patches are included in 2.5.63. Now stock 2.5.63 compiles and works on my uniprocessor visws/ Please test it, but don't try to use parport_pc because probe_irq_xxx() kludge isn't included. Best regards. -- Andrey Panin | Embedded systems software developer pa...@or... | PGP key: wwwkeys.pgp.net |
|
From: Andrey P. <pa...@or...> - 2003-02-26 05:52:45
|
On Пнд, Фев 24, 2003 at 05:02:47 +1300, Steven Brydon wrote: > I want to build arcloader-2003 so I can use bzImage kernel images - 2.4.17 > kernel images are too big to fit on a floppy. > > Can anyone give me some tips for building i386pe executables as requried for > arcloader-2003? I have various redhat 7.x and redhat 8.0 systems available > for compiling as well as a cygwin environment. 1) you will need a linker capable of generating PE executables, to get such a linker: - download and unpack binutils source tarball; - configure it with ./configure --enable-targets=i386-none-winnt - make ; make install 2) you will also need development files for e2fsprogs and zlib; > FYI. Trying to install redhat 8.0 on a 540. Good luck, we need a tester with working 540 :) -- Andrey Panin | Embedded systems software developer pa...@or... | PGP key: wwwkeys.pgp.net |
|
From: Steven B. <ste...@vi...> - 2003-02-24 04:00:42
|
I want to build arcloader-2003 so I can use bzImage kernel images - = 2.4.17 kernel images are too big to fit on a floppy. Can anyone give me some tips for building i386pe executables as requried = for arcloader-2003? I have various redhat 7.x and redhat 8.0 systems = available for compiling as well as a cygwin environment. FYI. Trying to install redhat 8.0 on a 540. Cheers Steven |
|
From: Florian B. <bo...@un...> - 2003-02-23 18:02:21
|
Hi all! Andrey Panin wrote: > All testers are welcome :) Great! This is very good news...! I suffer from a massive lack of time until CeBit, but i couldn't wait testing... :-) One problem i found: After a make oldconfig with my .config from 2.5.57 this happened: make vmlinux [...] make -f scripts/Makefile.build obj=arch/i386/mach-visws gcc -Wp,-MD,arch/i386/mach-visws/.visws_apic.o.d -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=pentium3 -Iinclude/asm-i386/mach-visws -Iinclude/asm-i386/mach-default -fomit-frame-pointer -nostdinc -iwithprefix include -I../kernel -DKBUILD_BASENAME=visws_apic -DKBUILD_MODNAME=visws_apic -c -o arch/i386/mach-visws/visws_apic.o arch/i386/mach-visws/visws_apic.c arch/i386/mach-visws/visws_apic.c: In function `piix4_master_intr': arch/i386/mach-visws/visws_apic.c:233: `cached_A1' undeclared (first use in this function) arch/i386/mach-visws/visws_apic.c:233: (Each undeclared identifier is reported only once arch/i386/mach-visws/visws_apic.c:233: for each function it appears in.) arch/i386/mach-visws/visws_apic.c:238: `cached_21' undeclared (first use in this function) Looks like a missing include... Greetings Florian -- The dream of yesterday Florian Boor is the hope of today Tel: 0271-7411487 | Fax: 0180-5052 5393 9324 and the reality of tomorrow. flo...@bs... | bo...@un... [Robert Hutchings Goddard, 1904] 6C 44 30 4C 43 20 6B 61 16 07 0F AA E6 97 70 A8 |
|
From: Andrey P. <pa...@or...> - 2003-02-21 12:53:53
|
All testers are welcome :) -- Andrey Panin | Embedded systems software developer pa...@or... | PGP key: wwwkeys.pgp.net |
|
From: Christoph H. <hc...@in...> - 2003-01-30 11:43:07
|
On Thu, Jan 30, 2003 at 02:26:50PM +0300, Andrey Panin wrote: > Probably agreed. But I didn't even try to compile UP kernels for visws. > Added into todo list. Then either test it or add a comment explaining why it's disallowed > The visws support is totally borken now, so why submit this ASAP ? the visw fb driver can't work anyway, so there's no harm if you get this driver update into James' tree (an he'll submit it to Linus with the other fb stuff) soon, but your patch will get a lot smaller and easier to integrate. > This varibable-like macro replaces two #ifndef's in smp.c and smpboot.c > I'm not sure are the really necessary and I can't test it because my visws > has one cpu only (and it's impossible to buy VRM and slot-1 P3 in Russia). I can try to get one or two for you in a second hand store here in Germany for you. sending it to russia will probably be more important than the actual price for them :) |
|
From: Andrey P. <pa...@or...> - 2003-01-30 11:32:54
|
On Чтв, Янв 30, 2003 at 08:54:58 +0000, Christoph Hellwig wrote: > Hi Andrey, > > here some comments, I hope you'll submit visw support to Linus soon Thank you for comments. I'll try to submit it some day. > (and I'll find one somewhere.. :) Please find a 540 if you can :)) > I don't think there's a reason to not allow UP kernels on visws. Probably agreed. But I didn't even try to compile UP kernels for visws. Added into todo list. > IMHO the stext changes should be moved into a single patch in > preparation of the visw support. > > Dito for the i8259 and generic apic code changes (!?) > > Again, GDT changes should be a separate preparation patch. Agreed. > @@ -11,8 +13,15 @@ > ifdef CONFIG_ACPI_PCI > obj-y += acpi.o > endif > -obj-y += legacy.o > > +ifndef CONFIG_X86_VISWS > +obj-y += legacy.o > +endif > > endif # CONFIG_X86_NUMAQ > -obj-y += irq.o common.o > + > +ifndef CONFIG_X86_VISWS > +obj-y += irq.o > +endif > > What about grouping the two ifndefs? I'l take a look at it. > > +#ifdef CONFIG_X86_VISWS > +#define USE_IO > +#endif > + > Separate patch probably. I think you should just submit this > one to jgarzik ASAP, independant of the other bits. > A small cleanup suggestion would be turning USE_IO into a config > option that is implied by CONFIG_X86_VISWS... I hope this kludge will go away. I need to figure out why memory mapped pci io doesn't work on visws. Nobody knows is it fundamental visws hardware problem or the lithium asic needs more tweaking. And how to tweak asic without documentation ? :-/ But people are reporting that pci video cards work under windows... > diff -urN -X /usr/share/dontdiff linux-2.5.59.vanilla/drivers/video/sgivwfb.c linux-2.5.59/drivers/video/sgivwfb.c > --- linux-2.5.59.vanilla/drivers/video/sgivwfb.c Wed Jan 15 20:37:20 2003 > +++ linux-2.5.59/drivers/video/sgivwfb.c Mon Jan 27 19:03:53 2003 > > The fb driver should be a separate patch again. As it doesn't > currently work I'd suggest submitting it to James Simmons ASAP. The visws support is totally borken now, so why submit this ASAP ? > I think this should be include/asm-i386/mach-visws/cobalt.h instead. > > Dito (include/asm-i386/mach-visws/lithium.h) Good point. > diff -urN -X /usr/share/dontdiff linux-2.5.59.vanilla/include/asm-i386/sgi-piix.h linux-2.5.59/include/asm-i386/sgi-piix.h > --- linux-2.5.59.vanilla/include/asm-i386/sgi-piix.h Thu Jan 1 03:00:00 1970 > +++ linux-2.5.59/include/asm-i386/sgi-piix.h Sun Jan 19 18:43:10 2003 > > What's really VisW-specific here (except that Linux doesn't poke the > PIIX that much on normal PeeCees)? IMHO it should be either > include/asm-i386/piix.h or include/asm-i386/mach-visws/piix.h > depending on that. IIRC it contains some defines specific to ns super i/o chip and its connection to piix. So mach-visws/piix.h is better I think. > +#ifdef CONFIG_X86_VISWS > +#define x86_visws 1 > +#else > +#define x86_visws 0 > +#endif > > Do we really need more than CONFIG_X86_VISWS and the mach-$foo > abstraction? This varibable-like macro replaces two #ifndef's in smp.c and smpboot.c I'm not sure are the really necessary and I can't test it because my visws has one cpu only (and it's impossible to buy VRM and slot-1 P3 in Russia). Best regards. -- Andrey Panin | Embedded systems software developer pa...@or... | PGP key: wwwkeys.pgp.net |
|
From: Christoph H. <hc...@in...> - 2003-01-30 08:56:11
|
Hi Andrey, here some comments, I hope you'll submit visw support to Linus soon (and I'll find one somewhere.. :) @@ -380,7 +378,8 @@ Otherwise, say N. config SMP - bool "Symmetric multi-processing support" + bool "Symmetric multi-processing support" if !X86_VISWS + default y if X86_VISWS I don't think there's a reason to not allow UP kernels on visws. diff -urN -X /usr/share/dontdiff linux-2.5.59.vanilla/arch/i386/Makefile linux-2.5.59/arch/i386/Makefile --- linux-2.5.59.vanilla/arch/i386/Makefile Mon Jan 27 18:24:59 2003 +++ linux-2.5.59/arch/i386/Makefile Sun Jan 19 18:43:10 2003 @@ -18,7 +18,7 @@ LDFLAGS := -m elf_i386 OBJCOPYFLAGS := -O binary -R .note -R .comment -S -LDFLAGS_vmlinux := -e stext +LDFLAGS_vmlinux := LDFLAGS_BLOB := --format binary --oformat elf32-i386 CFLAGS += -pipe IMHO the stext changes should be moved into a single patch in preparation of the visw support. --- linux-2.5.59.vanilla/arch/i386/kernel/i8259.c Wed Jan 15 20:37:20 2003 +++ linux-2.5.59/arch/i386/kernel/i8259.c Sun Jan 19 18:43:10 2003 @@ -22,6 +22,7 @@ #include <asm/desc.h> #include <asm/apic.h> #include <asm/arch_hooks.h> +#include <asm/i8259.h> Dito for the i8259 and generic apic code changes (!?) --- linux-2.5.59.vanilla/arch/i386/kernel/trampoline.S Wed Jan 15 20:37:20 2003 +++ linux-2.5.59/arch/i386/kernel/trampoline.S Sun Jan 19 18:43:10 2003 @@ -46,8 +46,8 @@ movl $0xA5A5A5A5, trampoline_data - r_base # write marker for master knows we're running - lidt idt_48 - r_base # load idt with 0, 0 - lgdt gdt_48 - r_base # load gdt with whatever is appropriate + lidt boot_idt - r_base # load idt with 0, 0 + lgdt boot_gdt - r_base # load gdt with whatever is appropriate Again, GDT changes should be a separate preparation patch. @@ -11,8 +13,15 @@ ifdef CONFIG_ACPI_PCI obj-y += acpi.o endif -obj-y += legacy.o +ifndef CONFIG_X86_VISWS +obj-y += legacy.o +endif endif # CONFIG_X86_NUMAQ -obj-y += irq.o common.o + +ifndef CONFIG_X86_VISWS +obj-y += irq.o +endif What about grouping the two ifndefs? diff -urN -X /usr/share/dontdiff linux-2.5.59.vanilla/drivers/net/eepro100.c linux-2.5.59/drivers/net/eepro100.c --- linux-2.5.59.vanilla/drivers/net/eepro100.c Wed Jan 15 20:37:20 2003 +++ linux-2.5.59/drivers/net/eepro100.c Sun Jan 19 18:43:10 2003 @@ -306,6 +306,10 @@ outw(val, port); } +#ifdef CONFIG_X86_VISWS +#define USE_IO +#endif + Separate patch probably. I think you should just submit this one to jgarzik ASAP, independant of the other bits. A small cleanup suggestion would be turning USE_IO into a config option that is implied by CONFIG_X86_VISWS... diff -urN -X /usr/share/dontdiff linux-2.5.59.vanilla/drivers/video/Kconfig linux-2.5.59/drivers/video/Kconfig --- linux-2.5.59.vanilla/drivers/video/Kconfig Mon Jan 27 18:25:07 2003 +++ linux-2.5.59/drivers/video/Kconfig Sun Jan 19 18:43:10 2003 @@ -363,7 +363,7 @@ config FB_SGIVW tristate "SGI Visual Workstation framebuffer support" - depends on FB && VISWS + depends on FB && X86_VISWS Oops, I missed this instance :) diff -urN -X /usr/share/dontdiff linux-2.5.59.vanilla/drivers/video/sgivwfb.c linux-2.5.59/drivers/video/sgivwfb.c --- linux-2.5.59.vanilla/drivers/video/sgivwfb.c Wed Jan 15 20:37:20 2003 +++ linux-2.5.59/drivers/video/sgivwfb.c Mon Jan 27 19:03:53 2003 The fb driver should be a separate patch again. As it doesn't currently work I'd suggest submitting it to James Simmons ASAP. diff -urN -X /usr/share/dontdiff linux-2.5.59.vanilla/include/asm-i386/sgi-cobalt.h linux-2.5.59/include/asm-i386/sgi-cobalt.h --- linux-2.5.59.vanilla/include/asm-i386/sgi-cobalt.h Thu Jan 1 03:00:00 1970 +++ linux-2.5.59/include/asm-i386/sgi-cobalt.h Sun Jan 19 18:43:10 2003 I think this should be include/asm-i386/mach-visws/cobalt.h instead. diff -urN -X /usr/share/dontdiff linux-2.5.59.vanilla/include/asm-i386/sgi-lithium.h linux-2.5.59/include/asm-i386/sgi-lithium.h --- linux-2.5.59.vanilla/include/asm-i386/sgi-lithium.h Thu Jan 1 03:00:00 1970 +++ linux-2.5.59/include/asm-i386/sgi-lithium.h Sun Jan 19 18:43:10 2003 Dito (include/asm-i386/mach-visws/lithium.h) diff -urN -X /usr/share/dontdiff linux-2.5.59.vanilla/include/asm-i386/sgi-piix.h linux-2.5.59/include/asm-i386/sgi-piix.h --- linux-2.5.59.vanilla/include/asm-i386/sgi-piix.h Thu Jan 1 03:00:00 1970 +++ linux-2.5.59/include/asm-i386/sgi-piix.h Sun Jan 19 18:43:10 2003 What's really VisW-specific here (except that Linux doesn't poke the PIIX that much on normal PeeCees)? IMHO it should be either include/asm-i386/piix.h or include/asm-i386/mach-visws/piix.h depending on that. diff -urN -X /usr/share/dontdiff linux-2.5.59.vanilla/include/asm-i386/system.h linux-2.5.59/include/asm-i386/system.h --- linux-2.5.59.vanilla/include/asm-i386/system.h Wed Jan 15 20:37:20 2003 +++ linux-2.5.59/include/asm-i386/system.h Mon Jan 27 18:43:23 2003 @@ -410,4 +410,10 @@ #define BROKEN_ACPI_Sx 0x0001 #define BROKEN_INIT_AFTER_S1 0x0002 +#ifdef CONFIG_X86_VISWS +#define x86_visws 1 +#else +#define x86_visws 0 +#endif Do we really need more than CONFIG_X86_VISWS and the mach-$foo abstraction? diff -urN -X /usr/share/dontdiff linux-2.5.59.vanilla/sound/oss/vwsnd.c linux-2.5.59/sound/oss/vwsnd.c --- linux-2.5.59.vanilla/sound/oss/vwsnd.c Wed Jan 15 20:37:20 2003 +++ linux-2.5.59/sound/oss/vwsnd.c Mon Jan 27 19:04:14 2003 @@ -144,13 +144,11 @@ Again, I think the driver update should be submitted separately and ASAP. |
|
From: Florian B. <bo...@un...> - 2003-01-29 15:05:24
|
Hello! > attached patch adds visws support into 2.5.59 kernel. > All who owns visws with PCI cards installed, please test this patch. First test looks good, AIC7xxx still works :-) (but fails I/O test). I don't get a framebuffer console on boot - after X came up this works too. But this is maybe an error in my append line... Greetings Florian -- The dream of yesterday Florian Boor is the hope of today Tel: 0271-7411487 | Fax: 0180-5052 5393 9324 and the reality of tomorrow. flo...@bs... | bo...@un... [Robert Hutchings Goddard, 1904] 6C 44 30 4C 43 20 6B 61 16 07 0F AA E6 97 70 A8 |
|
From: Andrey P. <pa...@or...> - 2003-01-27 07:53:30
|
Hi all, attached patch adds visws support into 2.5.59 kernel. All who owns visws with PCI cards installed, please test this patch. Best regards. -- Andrey Panin | Embedded systems software developer pa...@or... | PGP key: wwwkeys.pgp.net |
|
From: Andrey P. <pa...@or...> - 2003-01-16 12:51:15
|
On =D0=A1=D1=80=D0=B4, =D0=AF=D0=BD=D0=B2 15, 2003 at 06:01:10 -0800, Dar= ren V Augenstein wrote: > Hello all, >=20 > I have an SGI 540 to which I am interested in installing VISWS-Linux. =20 > I am curious about the current status of the project. What is currently= =20 > working well, what needs fixing? =20 Kernel status in short: - kernel 2.2.10 works; - kernel 2.4.17 probably works too (i didn't test it); - 2.5.xx work in progress, but mostly works. Testers welcome. Hardware support: - no accelerated X and OpenGL; - internal IEEE1394 not supported; - video in/out not supported; - some PCI cards do not work (investigation in progress). Needs fixing: - brains of SGI management !! They don't publish docs :( > Although I'm not much of a kernel hacker, I would be willing to become=20 > involved in the project at the kernel testing level. Great !! We are needing kernel tester with 540 desperately. =20 > Which distribution seems to be the most agreeable to initially install=20 > on the 540? Or is this an issue? As far as major distributions are=20 > concerned, I notice that Patrick Volkerding has put some work into=20 > running Slackware (most recently version 8.0) on the visual workstation= s. Distribution dosn't really matter IMHO, but note that best way to install= =20 Linux on Visws now is: - remove hard drive from visws; - attach it to some random PC; - prepare small boot partition; - install Linux; - return hard drive into visws. Process isn't nice, but works (at least for me :) Best regards. --=20 Andrey Panin | Embedded systems software developer pa...@or... | PGP key: wwwkeys.pgp.net |
|
From: Darren V A. <dv...@bl...> - 2003-01-16 01:53:39
|
Hello all, I have an SGI 540 to which I am interested in installing VISWS-Linux. I = am curious about the current status of the project. What is currently = working well, what needs fixing? Although I'm not much of a kernel = hacker, I would be willing to become involved in the project at the = kernel testing level. Which distribution seems to be the most agreeable to initially install = on the 540? Or is this an issue? As far as major distributions are = concerned, I notice that Patrick Volkerding has put some work into = running Slackware (most recently version 8.0) on the visual = workstations. |
|
From: Andrey P. <pa...@or...> - 2003-01-15 10:46:41
|
On =D0=A1=D1=80=D0=B4, =D0=AF=D0=BD=D0=B2 15, 2003 at 11:26:42 +0100, Flo= rian Boor wrote: > Hi! >=20 > >Do you use 'video=3Dmap:0' boot parameter? Also note, if serial conso= le=20 > >is enabled at boot, framebuffer one doesn't show boot messages. >=20 > No, i used "MEM=3D512M root=3D/dev/sdb1/ video=3Dsgivw:monitor:1600sw" > Serial console was off and if it's on i'd see two tuxes at least... :-) >=20 These two tuxes are a good sign :))=20 They show that both processors are initialized. Kernels >2.5.55 have some changes affecting cpu starting, but looks like I worked them around. --=20 Andrey Panin | Embedded systems software developer pa...@or... | PGP key: wwwkeys.pgp.net |
5252 messages has been excluded from this view by a project administrator.
