Hi,
I mean - it's binary data required to make something work, I don't
know if copyright applies?
Guess we should ask QCA again a bit more. :)
Yes, we likely need a separate repository of board data files indexed
by actual board.
-adrian
___
ath10k
On 9 March 2017 at 14:11, Christian Lamparter wrote:
> On Thursday, March 9, 2017 1:46:00 PM CET Sven Eckelmann wrote:
>> On Donnerstag, 9. März 2017 11:51:13 CET Valo, Kalle wrote:
>> [...]
>> > I haven't followed the discussion very closely, so I might be way off,
>> >
On Thursday, March 9, 2017 1:46:00 PM CET Sven Eckelmann wrote:
> On Donnerstag, 9. März 2017 11:51:13 CET Valo, Kalle wrote:
> [...]
> > I haven't followed the discussion very closely, so I might be way off,
> > but for laptop SMBIOS implementations Waldemar added a variant field to
> >
On Donnerstag, 9. März 2017 13:46:00 CET Sven Eckelmann wrote:
> The board-2.bin would then require entries for bus=ahb,bmi-chip-id=0,bmi-
> board-id=16,variant=RT-AC58U and bus=ahb,bmi-chip-id=0,bmi-board-
> id=17,variant=RT-AC58U.
Small remark: I know the SMBIOS format would be "BDF__
\0" and
On Donnerstag, 9. März 2017 11:51:13 CET Valo, Kalle wrote:
[...]
> I haven't followed the discussion very closely, so I might be way off,
> but for laptop SMBIOS implementations Waldemar added a variant field to
> board-2.bin so that we can have multiple images for the same subsystem
> id. Could
Sven Eckelmann writes:
> On Dienstag, 7. März 2017 08:30:54 CET Adrian Chadd wrote:
>> "use your own bmi ids". :-)
>>
>> (yeah, this is going to make open source firmware for these things
>> more painful than it should be. :( )
>
> Thanks for the reply. I was just
On Dienstag, 7. März 2017 08:30:54 CET Adrian Chadd wrote:
> "use your own bmi ids". :-)
>
> (yeah, this is going to make open source firmware for these things
> more painful than it should be. :( )
Thanks for the reply. I was just informed that the firmware binary will behave
differently
"use your own bmi ids". :-)
(yeah, this is going to make open source firmware for these things
more painful than it should be. :( )
-adrian
On 7 March 2017 at 01:54, Sven Eckelmann wrote:
> Hi Adrian,
>
> On Montag, 30. Januar 2017 08:36:19 CET Adrian Chadd
Hi Adrian,
On Montag, 30. Januar 2017 08:36:19 CET Adrian Chadd wrote:
> If people aren't using unique BMI IDs (which is another question we
> have for QCA) then it's possible you don't have enough information to
> "know" which board data to use, so it has to be overridden by a custom
> package.
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
On Dienstag, 28. Februar 2017 19:22:32 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
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.
On Donnerstag, 9. Februar 2017 15:56:59 CET ako...@codeaurora.org wrote:
[...]
> Thanks for pointing this, I broke the sequence in qsdk while loading cal
> data
> from flash MTD partitions. I will revert these changes in QSDK patch[1].
>
> @@ -224,21 +224,13 @@
> +* from board data
On 2017-02-08 16:33, Sven Eckelmann wrote:
Hi Anilkumar Kolli,
we've noticed that your change in QSDK [1] removed the call to
ath10k_download_and_run_otp in ath10k_download_cal_data after the call
to
ath10k_core_get_board_id_from_otp. We reported [2] this to ath10k when
we
asked for some
Hi Anilkumar Kolli,
we've noticed that your change in QSDK [1] removed the call to
ath10k_download_and_run_otp in ath10k_download_cal_data after the call to
ath10k_core_get_board_id_from_otp. We reported [2] this to ath10k when we
asked for some clarifications regarding the loading process of the
Thanks for the insights
On Montag, 30. Januar 2017 08:36:19 CET Adrian Chadd wrote:
[...]
> * I can't talk about what Christian did, where he got the board data
> from, etc, etc. You mentioned a DK style board, but didn't say which.
model = "Qualcomm Technologies, Inc. IPQ40xx/AP-DK01.1-C1";
[snip]
hi!
ok, so here's what's going on behind the scenes.
* I can't talk about what Christian did, where he got the board data
from, etc, etc. You mentioned a DK style board, but didn't say which.
* For example, the ath10k in the "official" QSDK software reference
platform doesn't work out of
Hi,
I've just tested LEDE-IPQ40XX [1] after the official open QSDK 1.1.3 [2]
was
not able to boot on an ap.dk01.1-c1-like device. This seemed to work
exceptionally well (the device basically worked after the first build) but I
got a little suspicious when looking at the code which it uses
18 matches
Mail list logo