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

[Pavel Machek]

On Mon 2016-07-25 23:57:53, Sebastian Reichel wrote:
> 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.

It looked to me like the failure is config-related. I guess we can
merge a driver that works on n950, and then I can try to get it
working on n900.

Or it should be possible to do .config-bisection and see what went
wrong...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html