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

[Pali Rohár]

On Friday 22 July 2016 00:52:58 Sebastian Reichel wrote:
> Hi,
> 
> 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...

-- 
Pali Rohár
pali.rohar at gmail.com