Hi Alex, On Sat, Mar 2, 2019 at 10:30 AM 陆朱伟 <alex_lu@xxxxxxxxxxxxxx> wrote: > > Hi Martin, > Thanks for your information. thank you for the quick reply! > The config is related to eFuse in chips. I'm sorry that the details can't be open. > Only some special configurations are related to the host platforms, such as UART working baudrate, hardware flow control, PCM settings, etc. These are the settings for HCI UART and PCM Interface. > Most of configurations are only relevant to chips. please let me repeat this with my own words to see if I understand the "config blob" correctly. Feel free to correct me if anything is wrong: - the data in the config blob "patches" eFuse values at runtime (non-persistent) - we know the offsets of the UART_CONFIG, PCM_SETTING and BD_ADDR - these can be "board specific" (like baud rate, flow control, ...) - most other values from the "config blob" are "chip specific" - meaning they are identical for each board and they only depend on the chip do you have any suggestions how we can support multiple boards (the main goal of this whole discussion is: how to do this "correct")? so far different approaches were discussed (not only in this thread, but also in the past): - use a separate config blob for each board. this means that whenever a new board is supported (for example by adding a .dts for it to the mainline kernel) then Bluetooth won't work out-of-the-box unless a config is provided. - specify the properties of the connection to the chip (for example by adding a device-tree property for the speed, flow control, ...) and generate the config based on the device-tree properties. - (I am open for other suggestions, please let us know if you have any) I would like to hear your opinion on this topic and especially the reasons behind your suggestions. Best regards Martin
