On 2017-10-16 23:30, Christian Lamparter wrote:
On Monday, October 16, 2017 10:10:52 PM CEST Roman Yeryomin wrote:
On 2017-10-16 20:32, Christian Lamparter wrote:
> Added John, maybe he has more comments.
(This time with the right mail address - sorry)
>> Changes:
>> - add partitions
>> - enable wifi and ethernet
>> - set max cpu speed to 710MHz
>> - set memory size to 256MB
>> - add image generation
>> - extract pre-cal data from ART partition
>>
>> Wirespeed NAT can be achieved with spreading rx interrupts over
>> different
>> cores. Wifi needs love -- too slow. Could be that latest ath10k helps,
>> didn't test yet.
> That "Wifi needs love" stinks of board-2.bin issues. And we had to deal
> with this before:
> <http://lists.infradead.org/pipermail/ath10k/2016-November/008763.html>
>
> Verify that you have the correct (and up to date) board-2.bin for the
> board.
> please add the board's board-2.bin to the ipq-wifi package.
I don't think it needs some different board data.
bmi id is 17 for the board (taken from ART partition) which exists in
board-2.bin
Also now, after fixing CPU speed (again), I'm getting 550Mbps which is
close to max for open air tests.
I was going to deal with wifi related issues later.
Please don't defere the wireless issue. Fix it now.
Hm? Don't understand this.
There are a lot boards added with something not working. Double
standards?
And in this case it was actually working.
In the mail, Michal Kazior who was working for Qualcomm Atheros at the
time
stated quite clearly:
"Please don't do that. Your basically pushing bogus data as board data
to the device. I'm a ltittle surprised firmware didn't notice. Anyway,
expect the device to misbehave (crash, hang, regulatory violations)
with this "board.bin"."
I don't feed it with board.bin, you refer to irrelevant context.
and also:
"board-2 is a key-value store of actual board files. Some devices,
Exactly, that's why board-2.bin just works.
notably qca61x4 hw3+ and qca4019 need distinct board files to be
uploaded. Otherwise they fail in various ways."
>>
>> +define Device/AP-DK01.1-C1
>> + PROFILES += $$(DEVICE_NAME)
>> + DEVICE_TITLE := QCA AP-DK01.1-C1
>> + BOARD_NAME := ap-dk01.1-c1
>> + DEVICE_DTS := qcom-ipq4019-ap.dk01.1-c1
> This "qcom-ipq4019-ap.dk01.1-c1" is important later on.
>
>> + KERNEL_LOADADDR := 0x80208000
>> + KERNEL_INSTALL := 1
>> + KERNEL_SIZE := 4096k
>> + IMAGE_SIZE := 26624k
>> + FILESYSTEMS := squashfs
>> + $(call Device/FitImage)
> Any reason why this include is not at the top of the define?
This is kernel image generation, right before full image.
Actually I don't understand why it's put on top.
But you did notice that all other devices definitions have it on top as
well?
Are you really sure, that you really want to trigger people with OCD to
do
make a "cleanup" patch later? You could avoid this altogether right
now.
I don't understand this.
I would rather clean this up now and move all the other calls lower. So
they would fit at least some logic.
[...]
>> +@@ -20,6 +20,11 @@
>> + model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK01.1";
>> + compatible = "qcom,ipq4019";
> I think this should be "qcom,ipq4019-ap.dk01.1-c1", "qcom,ipq4019".
> The device-tree folks stick to their rules in the
> usage-model.txt / 2.2 Platform Identification
> <https://www.kernel.org/doc/Documentation/devicetree/usage-model.txt>
I didn't change that. And will not in v3, since I'm going to patch
qcom-ipq4019-ap.dk01.1-c1.dts
This has to be done! Again the usage-model.txt clearly states that:
"The 'compatible' property contains a sorted list of strings starting
with the *exact name of the machine*, followed by an optional list of
boards it is compatible with sorted from most compatible to least."
(Read the rest of 2.2 Platform Identification as well)
I think you forgot what you wrote yourself.
This is dtsi, for dts, the one which should be changed (as you noted
yourself), I agree makes sense, but not dtsi.
Also, Mathias Kresin has plans to use the first "compatible" entry
as an unique identifier for the userspace scripts. (And remove
ipq806x current custom board identifier script that relies on the
model)
That's good, but I cannot rely on plans and have to add custom board
identifier.
Once that's introduced he can change every user, as it's always done
with many other different things.
Currently 01_preinit_do_ipq806x.sh overrides this:
part of this work has already been merged see:
https://github.com/lede-project/source/blob/master/package/base-files/files/lib/preinit/02_sysinfo
Since the "qcom,ipq4019" compatible is already used by the
AP-DK04.1-C1,
this will cause a conflict with your "AP-DK01.1-C1"... And then the
userspace won't know "which is which".
Sure, but again, not for dtsi
Actually it appeared that the board I have is AP-DK01.2-C1
All ref boards differ either with flash configuration (spi/nand/emmc) or
SoC (4019/4029/4018/4028).
And actually all of them have same RAM size (so this is going to be in
dtsi).
>> + clocks {
>> + xo: xo {
>> + compatible = "fixed-clock";
>> diff --git
>>
a/target/linux/ipq806x/patches-4.9/864-02-dts-ipq4019-ap.dk01.1-fix-max-cpu-speed.patch
>>
b/target/linux/ipq806x/patches-4.9/864-02-dts-ipq4019-ap.dk01.1-fix-max-cpu-speed.patch
>> new file mode 100644
>> index 0000000..e9540f4
>> --- /dev/null
>> +++
>>
b/target/linux/ipq806x/patches-4.9/864-02-dts-ipq4019-ap.dk01.1-fix-max-cpu-speed.patch
>> @@ -0,0 +1,15 @@
>> +--- a/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
>> ++++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
>> +@@ -135,3 +135,12 @@
>> + };
>> + };
>> + };
>> ++
>> ++&cpu0_opp_table {
>> ++ /delete-node/ opp@666000000;
>> ++
>> ++ opp@710000000 {
>> ++ opp-hz = /bits/ 64 <710000000>;
>> ++ clock-latency-ns = <256000>;
>> ++ };
>> ++};
> This looks rather familiar. Like exactly a 1:1 copy from the FB4040's
> dts
> right here:
>
https://github.com/lede-project/source/blob/master/target/linux/ipq806x/files-4.9/arch/arm/boot/dts/qcom-ipq4019-fritz4040.dts#L286
> Is this true?
>
> There's a reason to stick with the 666MHz rate though. You should check
I don't think there is. All ipq40xx CPUs are 716.8MHz at max.
The supported frequencies are: 48, 200, 500 and 716.8 MHz
> if the device produces messages like:
> [ 1.399981] cpufreq: cpufreq_online: CPU0: Running at unlisted
> freq: 666000 KHz
> [ 1.400256] cpufreq: cpufreq_online: CPU0: Unlisted initial
> frequency changed to: 710000 KHz
> (From what I know, the SBL actually sets it to 666MHz)
>
> But there's more. If you look at qualcomm's page, it's says that the
> CPU Clock Speed is 717 MHz: <https://www.qualcomm.com/products/ipq4028>
>
> Since you are working for a OEM/ODM. You could please ask what is the
> right MHz table for these devices? Unfortunately, Qualcomm never got
> around to fix this upstream and without an official statement from them
> it's very difficult to push stuff like this upstream.
It looks like it was mostly a limitation introduced by hw instability
(both IC and boards) in early stages.
Mass production chips (at least should) run at full speed.
Hmm...
Could you please ask Qualcomm?
(Also to consider: there are IPQ40XX devices with and without an
heat-sink.
It could be that devices w/o a heat-sink have to have lower clocks
prevent
overheating.)
Reference design boards don't have them and they run at full speed.
>> diff --git
>>
a/target/linux/ipq806x/patches-4.9/864-04-dts-ipq4019-ap.dk01.1-enable-wifi-and-ethernet.patch
>>
b/target/linux/ipq806x/patches-4.9/864-04-dts-ipq4019-ap.dk01.1-enable-wifi-and-ethernet.patch
>> new file mode 100644
>> index 0000000..cc90475
>> --- /dev/null
>> +++
>>
b/target/linux/ipq806x/patches-4.9/864-04-dts-ipq4019-ap.dk01.1-enable-wifi-and-ethernet.patch
>> @@ -0,0 +1,87 @@
>> +--- a/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
>> ++++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
>> +@@ -15,6 +15,7 @@
>> + */
>> +
>> + #include "qcom-ipq4019.dtsi"
>> ++#include <dt-bindings/soc/qcom,tcsr.h>
> please move this to the qcom-ipq4019-ap.dk01.1-c1.dts.
>
>> +
>> + / {
>> + model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK01.1";
>> +@@ -25,6 +26,27 @@
>> + reg = <0x80000000 0x10000000>;
>> + };
>> +
>> ++ reserved-memory {
>> ++ #address-cells = <0x1>;
>> ++ #size-cells = <0x1>;
>> ++ ranges;
>> ++
>> ++ rsvd1@87000000 {
>> ++ reg = <0x87000000 0x0500000>;
>> ++ no-map;
>> ++ };
>> ++
>> ++ wifi_dump@87500000 {
>> ++ reg = <0x87500000 0x600000>;
>> ++ no-map;
>> ++ };
>> ++
>> ++ rsvd2@87B00000 {
>> ++ reg = <0x87b00000 0x500000>;
>> ++ no-map;
>> ++ };
>> ++ };
>
> The wifi_dump area is not needed by the ath10k driver.
> Furthermore, the you could probably get away with reserving
> less memory. From what I know, you only need to reserve space
> for the "QSEE environment", which is located between
> 0x87e00000 and 0x88000000.
wifi_dump == cnss_debug (not sure what this is)
I wouldn't be so sure that it's not needed at all.
QSEE == TZ
And seems your information is incorrect.
Will introduce full map in v3.
I have no information about those.
I think there should be also NSS region...
Do you know, if the IPQ40XX actually has a NSS?
I believe it has. Just called differently.
Qualcomm's IPQ40[1|2][89] pages don't mention anything about a NSS.
And there isn't any special NSS driver in the GPL dumps I have seen.
There is HWNAT block which I believe is the same.
Looks like they call it edma now, looks like it's same engine with
different interface.
From what I know these Network Subsystem (NSS) are only a thing for
the IPQ8064, IPQ8065 and the upcoming IPQ8074 tier.
I could be wrong though. Still waiting for info.
Regards,
Roman
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
