Re: QCA4019: calibration files and board files

[Christian Lamparter <chunkeey@googlemail.com>]

On Tuesday, February 28, 2017 7:22:32 PM CET Rajkumar Manoharan wrote:
> On 2017-02-27 23:58, Sven Eckelmann wrote:
> > It looks to me now that this information is contradicting your 
> > implementation
> > (which now loads the data from 0:ART partition [1] like pre-cal data 
> > [2] and
> > then loads the board-2.bin [3]).
> > 
> Both reading from ART and loading pre-cal data file are same.
> 
> > I have doubt regarding his explanation but I got no actual spec - only
> > information which seems to be contradicting (or to vague) . Is is 
> > possible
> > to get some confirmation from you about whether the data from the 0:ART
> > partition is pre-cal data or not and whether the board-2.bin should be
> > used when the data from 0:ART is used.
> > 
> In QCA4019 platform, only radio specific calibration (pre-cal-data) is 
> stored in flash.
> Board specific contents are read from board-2.bin. For each radio 
> appropriate board data should be loaded. To fetch correct board data
> from board-2.bin bundle, pre-cal/radio specific caldata should be
> loaded first to get proper board id.
> 
> > My understanding until now was that:
> > 
> >  * pre-cal data + board-2.bin info == actual calibration data
> > 
> Correct.
>
> >  * pre-cal data == some incomplete calibration data from somewhere else
> >                    (he never specified it - just that it exists)
> >  * calibration data == incomplete calibration data from 0:ART
> >                        (what I've described in the past as pre-cal 
> > data)
> >  * (pre-cal or calibration data) + board-2.bin info == actual 
> > calibration data
> > 
> > Would be nice if this confusion could be cleared up by you.
> > 
> Following methods are used to read radio specific caldata.
> 
> 1) In some platform which lags DT support, init.d script is used to read
> the calibrations content from flash memory and write it in file system 
> at boot time.
> This is done by dd command.
> 
> 2) DT entry “qcom,ath10k-pre-calibration-data" is used to pass 
> calibration data
> from flash to driver. But it needs CoreBSB support to transfer the 
> contents from flash to device tree.
>
> qcom,pre-calibration-data ==> only radio specific calibration.
> qcom,calibration-data ==> {radio specific + board specific calibration}.
> 
> 3) Reading calibration data directly from ART partition by mtd_read 
> operation. This one can be removed from QSDK either by init script
> or by DT support.
> 
> "qcom,calibration-data" is used for qca988x on AP148 plaform. 
> Here calibration data mean both radio + board contents.
> Always calibration content are stored in ART partition.

Ok. Thanks for the clarification.

So, pre-cal data (from flash) + board-2 (from fs) is the 
right way for now.

However, this is a bit of a problem for LEDE/OpenWRT.

You see: The board-2.bin will have to be baked into the rootfs-image
of the LEDE/OpenWRT firmware.
But in order to do that, the board-2.bin needs to be extracted from
the vendor's binary firmware image (via unsquashfs). Or if we are 
lucky: from the source archive, if the vendor left them in there.

The problem is: these raw board.bin files sourced from the binary
firmware image lack a redistributable license.
And therefore they can't be shipped with LEDE/OpenWRT. 
(The raw board.bin files from the source archive [1] are usually
in the  madwifi-11n directory, which has a redistributable 
license file [2] and can be converted to board-2.bin with the 
ath10k-bdencoder [3]. But there's no explicit statement that
this is possible.)

The way I see it atm, developers would need to ask the vendors
for  permission and LEDE/OpenWRT needs to setup something like
a board-2.bin repository (similar to linux-firmware [0]) for 
all the IPQ40XX devices (and future devices?)...

...

Is there a way around this problem? 
Can somebody ask around in the Legal Department? And clarify if:

1. Whenever the board-2.bin are copyright-able in the first place?
   INAL. These files just contain calibration values/parameters
   and no programs. From what I know facts/numbers are not copyright-able.
   But I don't know if it applies here or not. And if there is a
   difference between US/Europe/China/... laws.

2. What license these board.bin files should have.
   They are generated by the halphy_tools' eepromUtil utility.
   Are these files all original, or do they classify as
   derived works?

3. Most importantly: Can this be handled differently for future devices?
   Like adding a redistributable license text inside the board.bin files?
   (Like a header or trailer. A trailer would have the advantage that if
   the caldata length is fixed (like 12064 bytes for IPQ40XX), the trailer
   won't be uploaded to the device. So a trailer can be easily added to 
   existing files).

(4. Any workaround?
    Like trying to get by with just the precal-data from flash like in [4]?)

Thanks,
Christian

[0] <https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/README>
[1] <https://github.com/paul-chambers/netgear-r7800/tree/master/git_home/madwifi-11n.git/halphy_tools/host/eepromUtil/release_ipq4019>
[2] <https://github.com/paul-chambers/netgear-r7800/blob/master/git_home/madwifi-11n.git/COPYING>
[3] <https://github.com/qca/qca-swiss-army-knife/blob/master/tools/scripts/ath10k/ath10k-bdencoder>
[4] <https://www.mail-archive.com/ath10k@lists.infradead.org/msg05911.html>

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k