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
