> Am 22.11.2014 um 17:04 schrieb Edwin Amsler <edwin...@gmail.com>: > > I managed to cull the list here and only send to Patrick. Blarg. > > This definitely worked for me though!
Great! > > Is there something I can do to get these patches into mainline OpenBSD? I’ll > scout around for the best practices on that. I also need to see if I can find > this `aalm` person so proper attribution can be made. > > Also, is there a reason sxiahci_detach() was removed? In theory the device is > stuck on die so good luck *physically* detaching it, but are there other > cases where hardware detach might be called? Suspend for example? > Detach and activate routines should exist and call ahci_detach() and ahci_activate() appropriately, see sys/dev/pci/ahci_pci.c or sys/arch/armv7/imx/imxahci.c. Don’t remember why the code was removed. :/ > > On Nov 20, 2014, at 10:46 PM, Edwin Amsler <edwin...@gmail.com> wrote: > >> First patch applied. Building now… >> >> Will report back tomorrow. >> >> On Nov 20, 2014, at 5:04 PM, Patrick Wildt <m...@patrick-wildt.de> wrote: >> >>> There’s a quirk in sunxi’s AHCI. The following stuff might fix it. >>> >>> https://github.com/bitrig/bitrig/commit/6342a27bfe4dc590f8e266e370f54846a766a737 >>> https://github.com/bitrig/bitrig/commit/9859ab07da261ebb4f561ff2b5bc5802b63ac57c#diff-cdba5a121488fee7d94cd9f33f4c1c53R1 >>> >>>> Am 20.11.2014 um 23:49 schrieb Edwin Amsler <edwin...@gmail.com>: >>>> >>>> Hard drives attached to the SATA port of my Cubieboard aren’t working. >>>> >>>> It seems like the hardware is initialized properly, but the drive that is >>>> attached to the SATA port never becomes ready. >>>> >>>> For u-boot, I’m using the branch from the sunxi Github repo. It doesn’t >>>> come with SATA support compiled in, so in theory it’s not touching >>>> important registers here. I have also used mainline u-boot and tested that >>>> the SATA does work there and that it could read the partition table from >>>> different disks (couldn’t get OBSD to boot there). The hardware shouldn’t >>>> be the problem here. >>>> >>>> Full `dmesg` output can be found here: >>>> http://pastebin.com/B1Ckzre1 >>>> >>>> And here’s the relevant bits: >>>> ahci0 at sunxi0 GHC 0x80000000<AE> AHCI 1.1 >>>> ahci0: capabilities >>>> 0x6726ff80<NCQ,SSNTF,SALP,SAL,SCLO,SAM,SPM,PMD,SSC,PSC,CCCS>, 1 ports, 32 >>>> cmds, gen 2 (3Gbps) >>>> ahci0: ports implemented: 0x00000001 >>>> ahci0.0: port reset >>>> ahci0: device on port 0 didn't come ready, TFD: 0x80<BSY> >>>> ahci0.0: soft reset >>>> ahci0.0: stopping the port, softreset slot 31 was still active. >>>> ahci0: unable to communicate with device on port 0 >>>> scsibus0 at ahci0: 32 targets >>>> >>>> Now, what’s the best way to figure out what the problem is here? I’ve >>>> started building the kernel so if someone has patches for me to test with, >>>> I’m definitely game to try them out. >>>> >>>> Also, is this better to post on a different mailing list? >>>> >>>> Thanks, >>>> >>>> Edwin >>>> >>> >> > >
