> From: Mark Cave-Ayland <[email protected]> > Date: Mon, 14 Aug 2017 06:31:34 +0100 > > On 13/08/17 16:52, Kaashif Hymabaccus wrote: > > > Hello Mark, > > > > I have a Sun Ultra 5 with the following dmesg: > > > > console is /pci@1f,0/pci@1,1/ebus@1/se@14,400000:a > > Copyright (c) 1982, 1986, 1989, 1991, 1993 > > The Regents of the University of California. All rights reserved. > > Copyright (c) 1995-2017 OpenBSD. All rights reserved. > > https://www.OpenBSD.org > > > > OpenBSD 6.1-current (GENERIC) #225: Fri Aug 11 19:58:43 MDT 2017 > > [email protected]:/usr/src/sys/arch/sparc64/compile/GENERIC > > real mem = 536870912 (512MB) > > avail mem = 512393216 (488MB) > > mpath0 at root > > scsibus0 at mpath0: 256 targets > > mainbus0 at root: Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 270MHz) > > cpu0 at mainbus0: SUNW,UltraSPARC-IIi (rev 1.3) @ 269.802 MHz > > cpu0: physical 16K instruction (32 b/l), 16K data (32 b/l), 256K external > > (64 b/l) > > psycho0 at mainbus0 addr 0xfffc4000: SUNW,sabre, impl 0, version 0, ign 7c0 > > psycho0: bus range 0-2, PCI bus 0 > > psycho0: dvma map c0000000-dfffffff > > pci0 at psycho0 > > ppb0 at pci0 dev 1 function 1 "Sun Simba" rev 0x11 > > pci1 at ppb0 bus 1 > > ebus0 at pci1 dev 1 function 0 "Sun PCIO EBus2" rev 0x01 > > auxio0 at ebus0 addr 726000-726003, 728000-728003, 72a000-72a003, > > 72c000-72c003, 72f000-72f003 > > power0 at ebus0 addr 724000-724003 ivec 0x25 > > "SUNW,pll" at ebus0 addr 504000-504002 not configured > > sab0 at ebus0 addr 400000-40007f ivec 0x2b: rev 3.2 > > sabtty0 at sab0 port 0: console > > sabtty1 at sab0 port 1 > > comkbd0 at ebus0 addr 3083f8-3083ff ivec 0x29: no keyboard > > comms0 at ebus0 addr 3062f8-3062ff ivec 0x2a > > wsmouse0 at comms0 mux 0 > > lpt0 at ebus0 addr 3043bc-3043cb, 30015c-30015d, 700000-70000f ivec 0x22: > > polled > > "fdthree" at ebus0 addr 3023f0-3023f7, 706000-70600f, 720000-720003 ivec > > 0x27 not configured > > clock1 at ebus0 addr 0-1fff: mk48t59 > > "flashprom" at ebus0 addr 0-fffff not configured > > audioce0 at ebus0 addr 200000-2000ff, 702000-70200f, 704000-70400f, > > 722000-722003 ivec 0x23 ivec 0x24: nvaddrs 0 > > audio0 at audioce0 > > hme0 at pci1 dev 1 function 1 "Sun HME" rev 0x01: ivec 0x7e1, address > > 08:00:20:19:39:20 > > nsphy0 at hme0 phy 1: DP83840 10/100 PHY, rev. 1 > > machfb0 at pci1 dev 2 function 0 "ATI Mach64" rev 0x9a > > machfb0: ATY,GT-B, 1152x900 > > wsdisplay0 at machfb0 mux 1 > > wsdisplay0: screen 0 added (std, sun emulation) > > pciide0 at pci1 dev 3 function 0 "CMD Technology PCI0646" rev 0x03: DMA, > > channel 0 configured to native-PCI, channel 1 configured to native-PCI > > pciide0: using ivec 0x7e0 for native-PCI interrupt > > wd0 at pciide0 channel 0 drive 0: <IC35L120AVV207-0> > > wd0: 16-sector PIO, LBA48, 117800MB, 241254720 sectors > > wd0(pciide0:0:0): using PIO mode 4, DMA mode 2 > > atapiscsi0 at pciide0 channel 1 drive 0 > > scsibus1 at atapiscsi0: 2 targets > > cd0 at scsibus1 targ 0 lun 0: <LITE-ON, DVDRW SOHW-1693S, KS0A> ATAPI > > 5/cdrom removable > > wd1 at pciide0 channel 1 drive 1: <FUJITSU MPG3204AT E> > > wd1: 16-sector PIO, LBA, 19546MB, 40031712 sectors > > cd0(pciide0:1:0): using PIO mode 4, DMA mode 2 > > wd1(pciide0:1:1): using PIO mode 4, DMA mode 2 > > ppb1 at pci0 dev 1 function 0 "Sun Simba" rev 0x11 > > pci2 at ppb1 bus 2 > > vscsi0 at root > > scsibus2 at vscsi0: 256 targets > > softraid0 at root > > scsibus3 at softraid0: 256 targets > > bootpath: /pci@1f,0/pci@1,1/ide@3,0/disk@0,0 > > root on wd0a (f52f0bbc65e53556.a) swap on wd0b dump on wd0b > > > > It has a PCI hme card and it works great. > > > > I would be happy to help if you want to test some diff or program, but > > I am not knowledgeable enough to comment on the inner workings of the > > hme driver. > > Great, thanks for the information - the fact that the nsphy0 has been > detected correctly means that the access still works. Looks like I'll > have to go digging deeper.
The OpenBSD code uses %asi if necessary to let the hardware do the byteswapping. Howver, I think the psycho(4) host bridge also does an implicit byteswap. Always has been a bit confusing to me. But the code defenitely works correctly on real hardware.
