September-17th-2018, 03:00 PM
Well Jonas, I tried my best to get the container running bluetooth fine after a software restart. But I failed. I remember the time I created this container and failing already. And things did not improve ...
Whenever the command
hciattach /dev/ttyAMA0 bcm43xx 921600 noflow
is called again - means loading the bluetooth chip with firmware and attach it to the bluez stack - it will fail. It comes back with "Initialization time out".
As a consequence the restart of the container will not get managed to bring the bluez stack up and running again.
This is not a specific netPI problem and happens on a standard Raspberry Pi 3 too. It seems that within the command the function
static int init_uart(char *dev, struct uart_t *u, int send_break, int raw)
fails to get in touch with the BCM43 chip ... but the reason I don't know. If you goole the term "Initialization time out" you find several discussions having the same problem.
So I am sorry I can't help any futher. Maybe others know better.
Thx
Armin
Whenever the command
hciattach /dev/ttyAMA0 bcm43xx 921600 noflow
is called again - means loading the bluetooth chip with firmware and attach it to the bluez stack - it will fail. It comes back with "Initialization time out".
As a consequence the restart of the container will not get managed to bring the bluez stack up and running again.
This is not a specific netPI problem and happens on a standard Raspberry Pi 3 too. It seems that within the command the function
static int init_uart(char *dev, struct uart_t *u, int send_break, int raw)
fails to get in touch with the BCM43 chip ... but the reason I don't know. If you goole the term "Initialization time out" you find several discussions having the same problem.
So I am sorry I can't help any futher. Maybe others know better.
Thx
Armin
„You never fail until you stop trying.“, Albert Einstein (1879 - 1955)
