From: Steven Saunderson essat2...@gmail.com
Sent: Thursday, 26 February 2015, 9:50
Subject: Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for
Bluetooth
I've just added a brcm_bt_reset program to my repository
https://github.com/phelum/CT_Bluetooth . This resets
I've just added a brcm_bt_reset program to my repository
https://github.com/phelum/CT_Bluetooth
. This resets the BCM20710 and leaves it in UART-enabled mode as required
by the download program. So now the download program (should be generic)
doesn't have to call an initialise script
On Friday, February 27, 2015 at 1:36:43 AM UTC+11, Al Thomas wrote:
Why do you use mmap to access the GPIOs and not write to the sysfs files
from within the C program?
mmap seems good because it avoids the indirection (and interface
differences across kernel releases) imposed by the
On Friday, February 27, 2015 at 12:19:48 PM UTC+11, Al Thomas wrote:
Do the 3.4 kernel and standard Broadcom program work together without the
restart program? If so then maybe the restart program should just be for
new kernels with DTS support.
I've had trouble with the BT firmware
From: Steven Saunderson essat2...@gmail.com
Sent: Thursday, 26 February 2015, 21:57
Subject: Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for
Bluetooth
On Friday, February 27, 2015 at 1:36:43 AM UTC+11, Al Thomas wrote:
Why do you use mmap to access the GPIOs and not write
From: Steven Saunderson essat2...@gmail.com
Sent: Wednesday, 25 February 2015, 6:30
Subject: Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for
Bluetooth
I think the host UART driver ( serial8250 ) should be dealing with the
handshaking. It is hopefully just a question
Until yesterday I used sun7i-a20-cubietruck.dtb generated from files
supplied with the Linux 3.19.0-rc6 kernel. With this .dtb the Bluetooth
UART is accessed via /dev/ttyS2. This is different from the 3.4 kernels
which provide access via /dev/ttyS1.
Now I've generated a new .dtb using the
On Tuesday, February 24, 2015 at 8:24:32 AM UTC+11, Al Thomas wrote:
Your description of handshaking made me wonder if that was the problem.
Are you aware there are two serial protocols available on the chip? H4 uses
the control lines and H5 that seems to use SLIP. Page 30 of the BCM20710
From: Steven Saunderson essat2...@gmail.com
Sent: Tuesday, 24 February 2015, 10:28
Subject: Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for
Bluetooth
Today I've tested asserting and negating RTS at various times.
Host RTS must be asserted at the end of the reset pulse
On Wednesday, February 25, 2015 at 12:51:13 AM UTC+11, Al Thomas wrote:
Host RTS must be asserted at the end of the reset pulse and for 30ms after
to get the device to assert its RTS (our CTS). Since I check for CTS
before sending this causes the program to time out.
The timing is
From: Steven Saunderson essat2...@gmail.com
Sent: Monday, 23 February 2015, 8:43
Subject: Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for
Bluetooth
I've checked stty. The -clocal option causes patchram to hang when opening the
serial port. The crtscts option doesn't
On Monday, February 23, 2015 at 7:14:45 AM UTC+11, Al Thomas wrote:
It looks as though modifying the Broadcom program allows you to use the
ioctls on the Linux UART driver because it is written in C so it is easier
for you to access the ioctl. Have you heard of or used stty ? I've just
On Monday, February 23, 2015 at 7:14:45 AM UTC+11, Al Thomas wrote:
It looks as though modifying the Broadcom program allows you to use the
ioctls on the Linux UART driver because it is written in C so it is easier
for you to access the ioctl. Have you heard of or used stty ? I've just
From: Steven Saunderson essat2...@gmail.com
Sent: Sunday, 22 February 2015, 3:16
Subject: Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for
Bluetooth
Due to a reply in another forum I've uploaded my files to
https://github.com/phelum/CT_Bluetooth and might get some
On Saturday, February 21, 2015 at 10:50:42 PM UTC+11, Al Thomas wrote:
The maximum UART speed is stated to be 4Mbps in the datasheet. Have you
got as far as using the highest rate and if so when do you switch over to
using it?
I tried increasing the bps to 1152000 but it didn't work.
From: Steven Saunderson essat2...@gmail.com
Sent: Saturday, 21 February 2015, 6:06
Subject: Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel
My bluetooth testing is to a mobile phone for wireless broadband. I haven't
tested any other bluetooth functions.
Thanks
Hi Al,
My bluetooth testing is to a mobile phone for wireless broadband. I
haven't tested any other bluetooth functions.
The BT_WAKE pin seems irrelevant to me. After reading the datasheet I'm
setting it low now.
Thanks for the details from the linux-sunxi page. With kernel 3.4 this is
From: Steven Saunderson essat2...@gmail.com
Sent: Friday, 20 February 2015, 1:50
Subject: Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel
Thanks for the .dts patch info. I've updated my .dts but it doesn't help
with the firmware load. I haven't seen any mainline version
My particular issue is downloading the bluetooth firmware to the AP6210.
With the 3.4 kernel I can toggle the BT_REST pin (via gpio PH18) and then
open a serial connection (via uart2) and download. This works reliably.
With the 3.19 kernel the AP6210 didn't respond.
I've just found that if
From: Steven Saunderson essat2...@gmail.com
Sent: Thursday, 19 February 2015, 20:43
Subject: Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel
My particular issue is downloading the bluetooth firmware to the AP6210.
With the 3.4 kernel I can toggle the BT_REST pin (via gpio PH18
On Friday, February 20, 2015 at 9:42:13 AM UTC+11, Al Thomas wrote:
Not tried this myself, but does the DTS at:
https://github.com/wens/linux/commit/b3df2aa9dfb48d58ee590c9686dfc0e3946de5fc
help at all? Atleast to upload the firmware.
I'm not sure mainline AP6210 driver for BT works
On Thursday, February 19, 2015 at 12:34:40 PM UTC+11, Chen-Yu Tsai wrote:
Mine is also using irqs 41 and 42. You should look at /proc/interrupts.
You'll see that 41 and 42 are the interrupt numbers used in the kernel.
The real IRQ is between GIC and the last column, which says which
Hi,
On Thu, Feb 19, 2015 at 8:18 AM, Steven Saunderson essat2...@gmail.com wrote:
Hi,
I'm running 3.19 on my CT and can't get the internal UARTs to work. The two
UARTs I'm testing are /dev/ttyS0 (debug port) and /dev/ttyS2 (connects to BT
half of AP6210).
With the 3.4 kernel, ttyS0 uses
Hi,
I'm running 3.19 on my CT and can't get the internal UARTs to work. The
two UARTs I'm testing are /dev/ttyS0 (debug port) and /dev/ttyS2 (connects
to BT half of AP6210).
With the 3.4 kernel, ttyS0 uses irq 33 and the BT UART uses irq 35. But
with the 3.19 kernel, according to
24 matches
Mail list logo
