[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-arm
Subject:    Re: AHCI problems with Cubieboard A10
From:       Patrick Wildt <mail () patrick-wildt ! de>
Date:       2014-11-22 18:20:03
Message-ID: B0D4C39E-3E27-48B4-A593-A93AEDE9F7FF () patrick-wildt ! de
[Download RAW message or body]


> Am 22.11.2014 um 17:04 schrieb Edwin Amsler <edwinguy@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 <edwinguy@gmail.com> wrote:
> 
> > First patch applied. Building now…
> > 
> > Will report back tomorrow.
> > 
> > On Nov 20, 2014, at 5:04 PM, Patrick Wildt <mail@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 <edwinguy@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
> > > > 
> > > 
> > 
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]