15 ms·
I know the guy that heads up the team that did this work -- he and I spent 2+ years fighting Broadcom's old, god-awful bluetooth code. Our whole team used to pl
by mondoshawan 6y ago
I know the guy that heads up the team that did this work -- he and I spent 2+ years fighting Broadcom's old, god-awful bluetooth code. Our whole team used to play what-if games about replacing the thing while massive code dumps came in from vendors, making the task ever larger.
Zach, if you're reading this, HUGE kudos to holding the line in replacing that, and double kudos for doing it in a verifiable, sane language!
- dukoid 6y agoI really hope it will fare better than NewBlue and BlueDroid... https://www.androidpolice.com/2020/09/14/the-rise-and-fall-of-newblue-googles-attempt-to-fix-bluetooth-on-chrome-os/ https://www.androidpolice.com/2020/09/14/the-rise-and-fall-o...
- mondoshawan 6y agoBluedroid is the old stack. Zach and co started the floride project to clean it up, but it seems GD is their attempt to totally rewrite it.
- dmitrygr 6y agoNewBlue died because I quit Google. I started that project and was its main motive force.
- mondoshawan 6y ago> NewBlue died because I quit Google. I started that project and was its main motive force. Unclear why you're being downvoted here -- I seem to remember you, and I definitely remember hearing about NewBlue while we were working on Bluedroid. At the time it wasn't clear what happened. When did you leave?
- dmitrygr 6y agoI am also not sure about the downvotes, but c'est la vie. I was dmitrygr@, i left apr 2019
- parwan98 6y ago> fighting Broadcom's old, god-awful bluetooth code Correction: god-awful host side bluetooth code. There is still the bluetooth firmware residing on the BCMxxx chip (or Qualcomm chip) - >1MB of god-awfulerer closed-source code, half of it is in ROM (with limited number of available patch slots), full of bugs. You can see it crash from time to time in the kernel debug logs (and auto-restart itself)
- FredFS456 6y agoFor more illustrations of bugs/vulns in the firmware: https://www.youtube.com/watch?v=7tIQjPjjJQc&t=1986s https://www.youtube.com/watch?v=7tIQjPjjJQc&t=1986s
- kevincox 6y agoDo you have any more info about ROM patch slots? I have never heard of this before. I assume this is a small amount of r/w memory that is somehow overlaid over specific locations in the ROM?
- parwan98 6y agoCorrect. It's a small table of: address1, 4 bytes overlay data address2, 4 bytes overlay data etc The data is overlayed over the specified addresses, in runtime. On some chips its 8 bytes instead of 4. On a typical Broadcom/Cypress chip you have 128 or 256 entries. By the time the chip is 2-3 years in the market and still getting firmware updates, ~98% of them are used by existing firmware, so there are only 5-10 free entries by the time the chip is considered "obsolete". Case in point: the Broadcom/Cypress BCM43455 chip on the raspberry pi is almost out of patch entries. Broadcom have switched to their usual tactic of stalling for years on known, reproducible bug reports.
- ed25519FUUU 6y ago> Case in point: the Broadcom/Cypress BCM43455 chip on the raspberry pi is almost out of patch entries. Broadcom have switched to their usual tactic of stalling for years on known, reproducible bug reports. And it's still really buggy. I had to write a service on the RPI and the only way to reliably connect was to restart bluetooth before every attempt. That kind of fix makes a person feel dirty.
- seanalltogether 6y agoAny insight into why Apple seems to have a much better bluetooth stack? I do a lot of BLE development that has to work cross platform, and we see constant GATT connection issues on android compared to almost none on ios.
- f6v 6y agoA wild guess: less hardware variability.
- Nextgrid 6y agoCould it be because they only have a handful of hardware variants to support, vs hundreds on Android? Presumably, the stack itself is somewhat sane on both sides, but the hardware's bugs, poorly specified or undefined behavior is constantly throwing wrenches in the machinery - Apple managed to fix most of them for the hardware they support, but Android has no chance as they have to support hundreds of different chips.
- seanalltogether 6y agoPossibly, but half the guys on the dev/qa team have google pixel devices and even they throw connection errors fairly regularly.
- w0m 6y agoIt's having to support every phone that introduces the instability even the refernece devices.
- solarkraft 6y agoThis is not specific to bluetooth or drivers, but I don't fully buy the thesis/deflection that Apple just has a much smaller set of hardware to support. I run a hackintosh system myself and it's more stable than Windows. I'm starting to think Apple just has stronger general QC. Windows is just as glitchy and crashy on Surface devices as anywhere else. The counter point does apply to drivers, but it's really not just that.
- 6y ago
- burnte 6y agoIt's almost impossible to be worse than the existing Bluewooth stack. IT's the single biggest problem I have with Google phones and it's shameful it took this long to fix.
- nindalf 6y agoI wouldn’t assume it’s fixed yet. Even if they’ve managed to write bug free code, you’re still at the mercy of driver supplied by the chip manufacturer.
- centimeter 6y agoBroadcom seems to pump out a lot of garbage in general. The SoCs on the raspberry pis are particularly terrible.
- PragmaticPulp 6y agoCan you shed some light on what we’re actually looking at here? I see some Rust but most of the actual BT stack looks to be C++ code. Is the HN headline accurate?
- Wohlf 6y agoDid you miss this on the main page? > We are missing Rust support in our GN toolchain so we currently build the Rust libraries as a staticlib and link in C++.
- PragmaticPulp 6y agoRight, but the headline suggests the BlueTooth stack is being rewritten in Rust while the code seems to suggest that the stack is in C++ still. There isn’t much Rust code in the directory relative to all of the C++ 4K lines of Rust is not a BlueTooth stack.