9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] Plan 9 on a SunPCI card.
@ 2008-04-07 17:48 Jerome Ibanes
  2008-04-08  0:20 ` erik quanstrom
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Jerome Ibanes @ 2008-04-07 17:48 UTC (permalink / raw)
  To: 9fans

I would like to install Plan 9 on a SunPCI IIIpro card (1), currently
located in a "old" Sun Blade 150 (2). This card has an Athlon XP 2200
(1600Mhz) and currently has 768MB of memory; it works in (almost) any pci
sparc v9 system running Solaris/OpenSolaris.

Interestingly enough, this card can either use a harddrive image to boot
(which is more or less a raw drive image located on the Solaris partition
with a somewhat specific 1024 bytes header, which happens to be rather
easy to forge) or a physical harddrive attached to its internal IDE
connector (which is 44 pins, laptop sized).

I haven't found a way to "boot" this card from a cdrom using the plan9
cdrom (3), even when such cdrom is directly attached to this card (please
note that Debian boots fine from there, when a plan9 cdrom is inserted I
get the famous "Operating System not found", although I haven't spent a
lot of time investigating this issue the fact that Debian boots seems not
to indicate a hardware issue). It seems that the internal floppy slot is
not working (by design) and this card can not network (pxe) boot (although
it has a network port) directly (it can network boot thru grub when grub
is compiled with --enable-diskless and support for the right network
chipset, and finally placed on a diskimage, more on this later).

I was able, however to generate a diskimage from a plan 9 raw disk
image (4), 9load starts "normally", but can not find an attached
harddrive (it however displays booting options to be fd0 and ether0):

  pcirouting: South bridge 1106, 3177 not found

might be the issue. By looking at /sys/src/9/pc/pci.c it *seems* that
making a disk image with:

  { 0x1106, 0x3177, viaget, viaset },   /* Viatech VT8235 */

would tremendously help. Do you think the lack of a recognized South
bridge would prevent 9load to find an attached harddrive, or would 9load
use INT13 to do so?

I have also tried to boot this card from network by using grub to do so,
therefore I have generated a disk image with support for the Via Rhine II
chipset (as present on the SunPCI IIIpro) built in into grub but
unfortunately, after fetching 9load via tftp the card cycles almost
immediately. Has anyone been able, or is currently using grub to boot
9load, if so, would any extra parameters be required?

Finally, assuming building 9load with support for the South bridge doesn't
help, could anyone think about any other way to run plan 9 on the SunPCI?


Sincerely,
Jerome Ibanes

References:
(1) SunPCI card: http://www.sun.com/desktop/products/sunpcipro/
(2) Sun Blade: http://www.sun.com/desktop/workstation/sunblade150/
(3) http://plan9.bell-labs.com/plan9/download/plan9.iso.bz2
(4) using this: http://www.oszoo.org/wiki/index.php/Plan9_070107.zip


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [9fans] Plan 9 on a SunPCI card.
  2008-04-07 17:48 [9fans] Plan 9 on a SunPCI card Jerome Ibanes
@ 2008-04-08  0:20 ` erik quanstrom
  2008-04-08  3:02 ` Jerome Ibanes
  2008-04-08  4:13 ` Jerome Ibanes
  2 siblings, 0 replies; 4+ messages in thread
From: erik quanstrom @ 2008-04-08  0:20 UTC (permalink / raw)
  To: 9fans

could you send the output of linux lspci -vvn?

- erik


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [9fans] Plan 9 on a SunPCI card.
  2008-04-07 17:48 [9fans] Plan 9 on a SunPCI card Jerome Ibanes
  2008-04-08  0:20 ` erik quanstrom
@ 2008-04-08  3:02 ` Jerome Ibanes
  2008-04-08  4:13 ` Jerome Ibanes
  2 siblings, 0 replies; 4+ messages in thread
From: Jerome Ibanes @ 2008-04-08  3:02 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: TEXT/PLAIN, Size: 315 bytes --]

>> [...]
>>   pcirouting: South bridge 1106, 3177 not found
>>   { 0x1106, 0x3177, viaget, viaset },   /* Viatech VT8235 */
>> [...]
> could you send the output of linux lspci -vvn?

The output of linux's lspci -vvn is attached to this message, thank you
for looking into this.


Sincerely,
Jerome Ibanes

[-- Attachment #2: Type: TEXT/PLAIN, Size: 6565 bytes --]

00:00.0 0600: 1106:3156
	Subsystem: 1106:3156
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
	Latency: 8
	Region 0: Memory at e8000000 (32-bit, prefetchable) [size=64M]
	Capabilities: [a0] AGP version 2.0
		Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
		Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>
	Capabilities: [c0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:01.0 0604: 1106:b091 (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR+
	Latency: 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	Memory behind bridge: ec000000-ec0fffff
	Prefetchable memory behind bridge: e0000000-e7ffffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
	Capabilities: [80] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:0b.0 0680: 8086:b555 (rev 03)
	Subsystem: 108e:676a
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (8000ns max), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 12
	Region 0: Memory at ec1c0000 (32-bit, non-prefetchable) [size=4K]
	Region 1: I/O ports at d000 [size=256]
	Region 2: Memory at 000d0000 (low-1M, non-prefetchable) [size=64K]
	Region 3: Memory at ec100000 (32-bit, non-prefetchable) [size=512K]
	Region 4: Memory at ec180000 (32-bit, prefetchable) [size=256K]
	Capabilities: [dc] Power Management version 0
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [e4] Vital Product Data
	Capabilities: [ec] #06 [0080]

00:10.0 0c03: 1106:3038 (rev 80) (prog-if 00 [UHCI])
	Subsystem: 1106:3038
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32, Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 11
	Region 4: I/O ports at d400 [size=32]
	Capabilities: [80] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:10.3 0c03: 1106:3104 (rev 82) (prog-if 20 [EHCI])
	Subsystem: 1106:3104
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32, Cache Line Size: 64 bytes
	Interrupt: pin D routed to IRQ 5
	Region 0: Memory at ec1c1000 (32-bit, non-prefetchable) [size=256]
	Capabilities: [80] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:11.0 0601: 1106:3177
	Subsystem: 1106:3177
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Capabilities: [c0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:11.1 0101: 1106:0571 (rev 06) (prog-if 8a [Master SecP PriP])
	Subsystem: 1106:0571
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32
	Interrupt: pin A routed to IRQ 11
	Region 4: I/O ports at dc00 [size=16]
	Capabilities: [c0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:11.5 0401: 1106:3059 (rev 50)
	Subsystem: 11d4:5348
	Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin C routed to IRQ 10
	Region 0: I/O ports at e000 [size=256]
	Capabilities: [c0] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:12.0 0200: 1106:3065 (rev 74)
	Subsystem: 1106:0102
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (750ns min, 2000ns max), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 11
	Region 0: I/O ports at e400 [size=256]
	Region 1: Memory at ec1c2000 (32-bit, non-prefetchable) [size=256]
	Capabilities: [40] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable+ DSel=0 DScale=0 PME-

01:00.0 0300: 5333:8d04 (prog-if 00 [VGA])
	Subsystem: 5333:8d04
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (1000ns min, 63750ns max), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at ec000000 (32-bit, non-prefetchable) [size=512K]
	Region 1: Memory at e0000000 (32-bit, prefetchable) [size=128M]
	[virtual] Expansion ROM at ec080000 [disabled] [size=64K]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [80] AGP version 2.0
		Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA- ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x4
		Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=x4


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [9fans] Plan 9 on a SunPCI card.
  2008-04-07 17:48 [9fans] Plan 9 on a SunPCI card Jerome Ibanes
  2008-04-08  0:20 ` erik quanstrom
  2008-04-08  3:02 ` Jerome Ibanes
@ 2008-04-08  4:13 ` Jerome Ibanes
  2 siblings, 0 replies; 4+ messages in thread
From: Jerome Ibanes @ 2008-04-08  4:13 UTC (permalink / raw)
  To: 9fans

> I haven't found a way to "boot" this card from a cdrom using the plan9
> cdrom (3), even when such cdrom is directly attached to this card (please
> note that Debian boots fine from there, when a plan9 cdrom is inserted I
> get the famous "Operating System not found", although I haven't spent a
> lot of time investigating this issue the fact that Debian boots seems not
> to indicate a hardware issue).

This was an oversight from my part, I am now able to boot a plan 9 (or any
other) bootable cdrom.

> I was able, however to generate a diskimage from a plan 9 raw disk
> image (4), 9load starts "normally", but can not find an attached
> harddrive (it however displays booting options to be fd0 and ether0):
>   pcirouting: South bridge 1106, 3177 not found
> might be the issue. By looking at /sys/src/9/pc/pci.c it *seems* that
> making a disk image with:
>   { 0x1106, 0x3177, viaget, viaset },   /* Viatech VT8235 */
> would tremendously help. Do you think the lack of a recognized South
> bridge would prevent 9load to find an attached harddrive, or would 9load
> use INT13 to do so?

As I understand it, the fact that the South Bridge wasn't recognized
shouldn't prevent 9load for finding more boot devices, especially the
cdrom one. Recognizing the South Bridge shouldn't be a showstopper,
assuming the bios implementation is good, which is a fair assumption here.

Disabling DMA didn't help; but what appears to be confusing is that
/sys/src/boot/pc/sdata.c shows support for the 1106:0571 (please refer to
my previous post which includes the lspci output):

  /sys/src/boot/pc/sdata.c:
    case (0x0571<<16)|0x1106:	/* VIA 82C686 */

  lspci output:
    00:11.1 IDE interface: VIA Technologies, Inc.
    VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
    00:11.1 0101: 1106:0571 (rev 06) (prog-if 8a [Master SecP PriP])


Sincerely,
Jerome Ibanes


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2008-04-08  4:13 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-04-07 17:48 [9fans] Plan 9 on a SunPCI card Jerome Ibanes
2008-04-08  0:20 ` erik quanstrom
2008-04-08  3:02 ` Jerome Ibanes
2008-04-08  4:13 ` Jerome Ibanes

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).