Hi Martin,
>>>>>>> As Marcel suggested we can assume that the information in the DSDT is
>>>>>>> correct so that we can get rid of the config blob also for x86
>>>>>>> platforms (assuming that the only useful information in the config
>>>>>>> blobs is the UART configuration).
>>>>>> in my tests I tried to send only the firmware without the config to my
>>>>>> RTL8723BS. unfortunately the last firmware chunk (sent to the
>>>>>> controller) times out in that case (even if I set a proper baudrate
>>>>>> before or if I specify no baudrate at all and keep the serdev at
>>>>>> 115200)
>>>>>
>>>>> What's in the config blobs besides UART configuration?
>>>>
>>>> is anybody writing a rtlfw.c tool (like nokfw.c) so that we can print out what we actually have in these config files?
>>>>
>>>>> It's odd because reading into hciattach_rtk.c it seems that the config
>>>>> file is actually only used by the userspace tools (hciattach) to
>>>>> retrieve the UART configuration and nothing else, whereas in the
>>>>> kernel driver the config blob is appended to the firmware.
>>>>
>>>> Frankly, I am inclined to not use the config file even for DT based system and just allow specifying the UART settings via normal DT properties like we do for Broadcom and others.
>>>
>>> so I googled for a few config files and this is what this turns into:
>>>
>>> Analyzing rtl8723d_config_1000000_noflow.dms
>>> Signature: 0x8723ab55
>>> Data length: 41
>>> len=1 offset=f4,{ 01 }
>>> len=2 offset=f6,{ 81 00 }
>>> len=2 offset=fa,{ 12 80 }
>>> len=16 offset=0c,{ 04 50 00 00 50 c5 ea 19 e1 1b fd af 5b 01 a4 0b }
>>> len=1 offset=d9,{ 0f }
>>> len=1 offset=e4,{ 08 }
>>> Analyzing rtl8723d_config.dms
>>> Signature: 0x8723ab55
>>> Data length: 41
>>> len=1 offset=f4,{ 01 }
>>> len=2 offset=f6,{ 81 00 }
>>> len=2 offset=fa,{ 12 80 }
>>> len=16 offset=0c,{ 02 80 92 04 50 c5 ea 19 e1 1b fd af 5f 01 a4 0b }
>>> len=1 offset=d9,{ 0f }
>>> len=1 offset=e4,{ 08 }
>>> Analyzing rtl8822b_config.bin
>>> Signature: 0x8723ab55
>>> Data length: 8
>>> len=1 offset=d9,{ 0f }
>>> len=1 offset=e4,{ 08 }
>>>
>>> The first two are some UART based ones and the last one is USB based.
>>>
>>> So the 0x3c offset seems to be the BD_ADDR and 0x0c offset is the UART configuration. It would be good to know which settings the other ones control.
> this matches my findings from the hciattach_rtk tool for rtl8723bs_bt
> and rtl8723ds_bt
>
>>> Also the 16 octet UART config blob seems to be decoded like this:
>>>
>>> uart_config {
>>> le32 baudrate;
>>> u8[8] reserved1;
>>> u8 flowctl;
>>> u8[3] reserved2;
>>> }
>>>
> I could not find this in any of the rtl8723bs_bt or rtl8723ds_bt sources
> so thank you for sharing this (even though this descriptin is missing
> a few bytes)!
>
>>> Actually hciattach_rtk just takes the baud rate and and hardware flow control bit out of this file. That is clearly two things that are better written in plain text in the DT file.
> this matches my findings apart from that hciattach_rtk also appends
> the config blob to the "firmware patch" that is being uploaded to the
> device
> if you are brave you can have a look at [0]
so this makes kinda sense. If you do not load the config file, you end up with the ROM defaults for all their “efuse” settings. Since it is essentially just a memory area where the config file overwrites defaults, this is all fine.
They have to extract the UART settings out of it since they also need to handled special during the firmware loading / boot process. This is also means if there is no config file or not UART settings in the config file, the process should use the default values.
>> so this is actually some funny stuff if you start to understand it.
>>
>> Analyzing rtl8723b_config.dms
>> Signature: 0x8723ab55
>> Data len: 38
>> len=8 offset=00f4,{ 01 00 00 00 05 50 00 00 }
>> len=16 offset=000c,{ 02 80 92 04 50 c5 ea 19 e1 1b f1 af 5f 01 a4 0b },UART_CONFIG
>> len=1 offset=0027,{ 63 }
>> len=1 offset=00fe,{ 01 }
>> Analyzing rtl8723d_config_1000000_noflow.dms
>> Signature: 0x8723ab55
>> Data len: 41
>> len=1 offset=00f4,{ 01 }
>> len=2 offset=00f6,{ 81 00 }
>> len=2 offset=00fa,{ 12 80 }
>> len=16 offset=000c,{ 04 50 00 00 50 c5 ea 19 e1 1b fd af 5b 01 a4 0b },UART_CONFIG
>> len=1 offset=00d9,{ 0f }
>> len=1 offset=00e4,{ 08 }
>>
>> Seems like Realtek really defines memory offsets in this file and they can be defined in various different ways.
> wow, that is interesting - I was wondering why they called it "offset"
> instead of "config_id" (or something similar)
It makes sense, they are just “patching” their configuration space.
>> So 00f4,{ 01 00 00 00 05 50 00 00 } defines the whole PCM settings for interface 1 and 2. And 00f4,{ 01 } + 00f6,{ 81 00 } + 00fa,{ 12 80 } is the same PCM settings, but with only pieces of it defined.
>>
>> This also means a 000c,{ 04 50 00 00 50 } for just setting the baud rate is as valid if flow control defaults to off and all other values are actual defaults. So code inside hciattach_rtk.c is also kind faulty on how it handles the flow control bit. It works if the config files all have offset 000c in it, but if not, then they are going funky.
>>
>> Since these are efuse settings, I really wonder if there is just a HCI vendor command to read out the defaults and we use that to compare. And what I would really like to know is what these settings are suppose to change. Since even for USB, we are actually not even applying them.
> the idea with the vendor command to read out existing memory is interesting
>
> based on the code in "btrtl.c" it seems that we are applying the
> settings from the config blob.
> we are simply appending it at the end of the "firmware patch", see [1]
I am pretty sure it is all the same for USB and UART.
>> Anyway, I am certain that for Realtek UART devices, we just want to specify max-speed DT property like we do with the others. And then maybe a flow-control DT property to control that one (following what nfcmrvl.txt does). We can use the rtlfw tool that I wrote to extract the values from Realtek provided config files. Frankly the PCM settings we have to deal with as well at some point. But that is also missing for Broadcom and others.
> just to make sure I understand you correctly: would you generate the
> config blob in-memory (in a function in btrtl.c) and hardcode all
> unknown bits (the reserved bits in the UART config entry for example)
> or would you mandate that a config blob is present (so
> request_firmware can fetch it) for "high-speed" operation?
>
> for PCM: I cannot test that anyways since the Amlogic platform does
> not have audio support yet
>
>> Also if there is no config file, we should be able to just assume no flow control, 115200 baud rate and H:5 as protocol. That means that almost all chips will just work. They are just slow since we do not deal with the max-speed setting.
> my problem so far was that uploading the firmware patch without
> appending a config blob (see [1]) broke the UART communication (it was
> not 115200 baud as before, and I also tried other speeds such as
> 1500000 and 1000000 baud - neither worked)
> however, extracting the existing values from the efuse using a vendor
> command might give a hint why (maybe they are fallling back to some
> exotic baudrate in that case, etc…)
Have you tried to just create a config file with just the signature 0x8723ab55 and data len set to 0. So essentially an empty config file. I am curious if such a default config is good enough to get things working. Or if they have actually faulty defaults in their ROM that need overwriting to make things fly.
Btw. I am curious why the UART speed is in that file anyway if we have to change it anyway via HCI command. So normally the boot UART speed is what is needed to know, not what final high speed we are using. So this is a bit odd.
I wonder if just loading the config file if present and then use a DT property max-speed to select the speed (even if it is different from the config file).
For me this means that we can have a general config file on disk, but actually allow overwriting the UART speed via DT. Otherwise we might just want to add extra offset entries for the config blob loading from disk and extend it with the DT values. So it would be some sort of overload.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
