[Pkg-n900-maint] Packaging phone functionality for Debian/N900

[Sebastian Reichel]

On Mon, Jul 25, 2016 at 04:50:55PM +0200, Pali Rohár wrote:
> On Friday 22 July 2016 00:52:58 Sebastian Reichel wrote:
> > On Thu, Jul 21, 2016 at 11:55:51PM +0200, Pali Rohár wrote:
> > > On Thursday 21 July 2016 23:46:31 Sebastian Reichel wrote:
> > > > On Thu, Jul 21, 2016 at 08:51:08AM +0200, Pavel Machek wrote:
> > > > > First, thanks for the great project. Debian is usable on N900 now.
> > > > 
> > > > From the kernel-side cameras and bluetooth are still missing,
> > > > though. I got my H4+ driver working on N950 last week. It's
> > > > still broken on N900, though (if you are curious search for
> > > > "This fails on N900" in drivers/bluetooth/hci_h4p.c). My
> > > > current guess is, that the bcm2048 requires more carful flow
> > > > control handling.
> > > > 
> > > > https://git.kernel.org/cgit/linux/kernel/git/sre/linux-n900.git/log/?
> > > > h=n950-bluetooth
> > > 
> > > Maybe add extensive logging of what is sending via uart and compare old 
> > > working Pavel's driver with your new?
> > > Or some timing issue?
> > 
> > I did that already quite some time ago before I had the N950 and
> > nothing interesting came up. "06 0a 00 a1 01 00 00 4c 00 96 00 00"
> > is the very first packet being send by both drivers. The working
> > N950 proves, that the correct bytes are being sent (the negotiation
> > packet is the same for N900 and N950).
> > 
> > I can also rule incorrect RTS/CTS behaviour after reset resulting in
> > possible stale byte, since the bcm2048 answers alive check packets.
> > 
> > Next thought was, that maybe the new driver is sending to fast, but
> > the error is already being sent after the first three bytes. Since
> > the alive check works and is 4 bytes, that can also be ruled out.
> > (and that should not happen with flow control anyways)
> > 
> > Suspicious is, that the error is sent after the first byte of a u16
> > value. So the data may be sent too slow. I doubt that, though. The
> > omap3-serial module has a 64 byte transmission FIFO, which is big
> > enough to handle all of the bytes. Unfortunately the serial lines
> > cannot easily be probed with an oscilloscope. *That* would be really
> > helpful.
> > 
> > I also contacted Ville Tervo last week, but he did not remember such
> > a problem and did not see any obvious mistakes in the driver.
> 
> Maybe some misconfigured clocks? Or some bad declaration in DTS file? Or
> power management? IIRC Pavel also modified n900 DTS file to make his
> driver working...

All of that can be ruled out, since the alive check package works
correctly.

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-n900-maint/attachments/20160725/c01e80d8/attachment.sig>