Re: [OpenWrt-Devel] [PATCH v2 2/2] ipq40xx: add support for AVM FRITZ!Repeater 3000

2019-03-10 Thread David Bauer 
Hello Christian,

On 10.03.19 20:27, Christian Lamparter wrote:
> On Saturday, March 9, 2019 12:20:54 AM CET David Bauer wrote:
>> Hardware
>> 
>> CPU:   Qualcomm IPQ4019
>> RAM:   256M (NANYA NT5CC128M16JR-EK)
>> FLASH: 128M NAND (Macronix MX30LF1G18AC-XKI)
>> ETH:   Qualcomm QCA8072
>> WiFi2: IPQ4019 2T2R 2SS b/g/n
>> WiFi5: IPQ4019 2T2R 2SS n/ac
>> WiFi5: QCA9984 4T4R 4SS n/ac
>> LED:- Connect green/blue/red
>> - Power green
>> BTN:   WPS/Connect
>> UART:  115200n8 3.3V
>>VCC - RX - TX - GND (Square is VCC)
>>
>> Installation
>> 
>> 1. Grab the uboot for the Device from the 'u-boot-fritz3000'
>>subdirectory. Place it in the same directory as the 'eva_ramboot.py'
>>script. It is located in the 'scripts/flashing' subdirectory of the
>>OpenWRT tree.
>>
>> 2. Assign yourself the IP address 192.168.178.10/24. Connect your
>>Computer to one of the boxes LAN ports.
>>
>> 3. Connect Power to the Box. As soon as the LAN port of your computer
>>shows link, load the U-Boot to the box using following command.
>>
>>> ./eva_ramboot.py --offset 0x8500 192.168.178.1 uboot-fritz3000.bin
>>
>> 4. The U-Boot will now start. Now assign yourself the IP address
>>192.168.1.70/24. Copy the OpenWRT initramfs (!) image to a TFTP
>>server root directory and rename it to 'FRITZ3000.bin'.
>>
>> 5. The Box will now boot OpenWRT from RAM. This can take up to two
>>minutes.
>>
>> 6. Copy the U-Boot and the OpenWRT sysupgrade (!) image to the Box using
>>scp. SSH into the Box and first write the Bootloader to both previous
>>kernel partitions.
>>
>>> mtd write /path/to/uboot-fritz3000.bin uboot0
>>> mtd write /path/to/uboot-fritz3000.bin uboot1
>>
>> 7. Remove the AVM filesystem partitions to make room for our kernel +
>>rootfs + overlayfs.
>>
>>> ubirmvol /dev/ubi0 --name=avm_filesys_0
>>> ubirmvol /dev/ubi0 --name=avm_filesys_1
>>
>> 8. Flash OpenWRT peristently using sysupgrade.
>>
>>> sysupgrade -n /path/to/openwrt-sysupgrade.bin
>>
>> Signed-off-by: David Bauer 
>> ---
>> diff --git a/target/linux/ipq40xx/image/Makefile 
>> b/target/linux/ipq40xx/image/Makefile
>> index 3a7ecf39eb..49ff71c6bc 100644
>> --- a/target/linux/ipq40xx/image/Makefile
>> +++ b/target/linux/ipq40xx/image/Makefile
>> @@ -130,6 +130,15 @@ define Device/avm_fritzbox-7530
>>  endef
>>  TARGET_DEVICES += avm_fritzbox-7530
>>  
>> +define Device/avm_fritzrepeater-3000
>> +$(call Device/FitImageLzma)
>> +DEVICE_DTS := qcom-ipq4019-fritzrepeater-3000
>> +DEVICE_TITLE := AVM Fritz!Repeater 3000
>> +DEVICE_PACKAGES := ath10k-firmware-qca9984-ct fritz-caldata 
>> ipq-wifi-avm_fritzrepeater-3000
> The fritz-tffs-nand was just added to openwrt. 
> 
> 
> 
> Should I add it in place? (And for the 7530 as well?)

I will submit a follow-up patch regarding tis topic as it was merged
without this issue addressed. I have already prepared a patch for this,
but will test it tomorrow on all 3 affected devices (7530, 3000 and 7412).

Best wishes
David

> 
> Cheers,
> Christian
> 
> 
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [sdwalker/sdwalker.github.io] f42bd8: This week's update

2019-03-10 Thread Stephen Walker 
  Branch: refs/heads/master
  Home:   https://github.com/sdwalker/sdwalker.github.io
  Commit: f42bd84e21e3e0b6d2696c97a8df3e17600c488d
  
https://github.com/sdwalker/sdwalker.github.io/commit/f42bd84e21e3e0b6d2696c97a8df3e17600c488d
  Author: Stephen Walker 
  Date:   2019-03-10 (Sun, 10 Mar 2019)

  Changed paths:
M uscan/index-18.06.html
M uscan/index.html

  Log Message:
  ---
  This week's update



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2 2/2] ipq40xx: add support for AVM FRITZ!Repeater 3000

2019-03-10 Thread Christian Lamparter 
On Saturday, March 9, 2019 12:20:54 AM CET David Bauer wrote:
> Hardware
> 
> CPU:   Qualcomm IPQ4019
> RAM:   256M (NANYA NT5CC128M16JR-EK)
> FLASH: 128M NAND (Macronix MX30LF1G18AC-XKI)
> ETH:   Qualcomm QCA8072
> WiFi2: IPQ4019 2T2R 2SS b/g/n
> WiFi5: IPQ4019 2T2R 2SS n/ac
> WiFi5: QCA9984 4T4R 4SS n/ac
> LED:- Connect green/blue/red
> - Power green
> BTN:   WPS/Connect
> UART:  115200n8 3.3V
>VCC - RX - TX - GND (Square is VCC)
> 
> Installation
> 
> 1. Grab the uboot for the Device from the 'u-boot-fritz3000'
>subdirectory. Place it in the same directory as the 'eva_ramboot.py'
>script. It is located in the 'scripts/flashing' subdirectory of the
>OpenWRT tree.
> 
> 2. Assign yourself the IP address 192.168.178.10/24. Connect your
>Computer to one of the boxes LAN ports.
> 
> 3. Connect Power to the Box. As soon as the LAN port of your computer
>shows link, load the U-Boot to the box using following command.
> 
>> ./eva_ramboot.py --offset 0x8500 192.168.178.1 uboot-fritz3000.bin
> 
> 4. The U-Boot will now start. Now assign yourself the IP address
>192.168.1.70/24. Copy the OpenWRT initramfs (!) image to a TFTP
>server root directory and rename it to 'FRITZ3000.bin'.
> 
> 5. The Box will now boot OpenWRT from RAM. This can take up to two
>minutes.
> 
> 6. Copy the U-Boot and the OpenWRT sysupgrade (!) image to the Box using
>scp. SSH into the Box and first write the Bootloader to both previous
>kernel partitions.
> 
>> mtd write /path/to/uboot-fritz3000.bin uboot0
>> mtd write /path/to/uboot-fritz3000.bin uboot1
> 
> 7. Remove the AVM filesystem partitions to make room for our kernel +
>rootfs + overlayfs.
> 
>> ubirmvol /dev/ubi0 --name=avm_filesys_0
>> ubirmvol /dev/ubi0 --name=avm_filesys_1
> 
> 8. Flash OpenWRT peristently using sysupgrade.
> 
>> sysupgrade -n /path/to/openwrt-sysupgrade.bin
> 
> Signed-off-by: David Bauer 
> ---
> diff --git a/target/linux/ipq40xx/image/Makefile 
> b/target/linux/ipq40xx/image/Makefile
> index 3a7ecf39eb..49ff71c6bc 100644
> --- a/target/linux/ipq40xx/image/Makefile
> +++ b/target/linux/ipq40xx/image/Makefile
> @@ -130,6 +130,15 @@ define Device/avm_fritzbox-7530
>  endef
>  TARGET_DEVICES += avm_fritzbox-7530
>  
> +define Device/avm_fritzrepeater-3000
> + $(call Device/FitImageLzma)
> + DEVICE_DTS := qcom-ipq4019-fritzrepeater-3000
> + DEVICE_TITLE := AVM Fritz!Repeater 3000
> + DEVICE_PACKAGES := ath10k-firmware-qca9984-ct fritz-caldata 
> ipq-wifi-avm_fritzrepeater-3000
The fritz-tffs-nand was just added to openwrt. 



Should I add it in place? (And for the 7530 as well?)

Cheers,
Christian




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] About 802.11s mesh on IPQ4019, ath10k-ct and ct-firmware

2019-03-10 Thread Sven Eckelmann 
On Sunday, 10 March 2019 18:03:51 CET Ben Greear wrote:
[...]
> > [2] 
> > https://github.com/openwrt/openwrt/pull/1862/commits/c1e80f1b6e673912437422e4900facb409e41143#diff-132b371dc289dab58843cae7f9c430f5
> 
> So, both of the patches above need to be applied to ath10k-ct 4.19 driver?
> 
> > [3] https://patchwork.ozlabs.org/patch/1051204/
> 
> I can apply this one to the 4.19 ath10k-ct driver too, I just am not using 
> 4.19 internally,
> so...well, no local testing.

Both were examples were the behavior of ath10k and ath10k-ct in OpenWrt were 
out of sync for a while. Both should now behave the same because Hauke/
Christian added them. But similar problems might happen in the future. Both
will hopefully find their way in the official ath10k driver (patchwork one 
is - I've tried to poke Kalle regarding the first one from PR 1862).


Regarding the second patch in PR 1862:

You should at least think about how to handle your private rate modification 
code. It conflicts with the official way to set the mgmt/mcast/bcast rates.
The second patch in the PR 1862 is just a workaround for this default
(mis)behavior of ath10k-ct. Maybe you have a different behavior in mind but
at least by default, it should not set an arbitrary mcast_rate for
meshpoint/ibss interfaces when the user specified something else via
OpenWrt's mcast_rate in /etc/config/wireless.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] About 802.11s mesh on IPQ4019, ath10k-ct and ct-firmware

2019-03-10 Thread Ben Greear 




On 03/10/2019 12:22 AM, Sven Eckelmann wrote:

On Sunday, 10 March 2019 05:52:00 CET Xuebing Wang wrote:
[...]

Are there anyone building 802.11s routers based on tag 18.06.1, 18.06.2
or branch openwrt-18.06?


Most(?) companies and community projects just throw the 802.11s forwarding/
routing part away and are running their preferred Layer2/Layer3 mesh protocol
(bmxd/6/7, olsrd(2), babeld, batman-adv, ...) over it. But yes, they are still
require the meshpoint interface support in ath10k+firmware.

A project I am more familiar (and is using 18.06.x) is freifunk-gluon [1].
They just select the ath10k-firmware-* (from kvalo/linux-firmware) for
meshpoint setups and ath10k-firmware*-ct for IBSS setups.

As far as I know, this will still be possible with OpenWrt 19.xx). And this
should also work the same when you want to run 802.11s+HWMP over it.


I noticed that in OpenWRT master branch ath10k-ct and
ath10k-firmware-qca4019-ct are enabled by default, but they are not
enabled in tag 18.06.2.


Regarding ath10k vs. ath10k-ct - yes, this is a rather unfortunate situation
that we have two different drivers. ath10k-ct is basically ath10k with a
~7000 lines patch on top. You just have to keep in mind that there are some
hacks in it which may break standard ath10k/mac80211 features [2]. So you
cannot always assume that this can be reported to the ath10k people. And some
of the changes in the mac80211 ath10k could be missing in ath10k-ct [3,4]. So
you have to figure out yourself which driver better fits your needs.

Kind regards,
Sven

[1] https://github.com/freifunk-gluon/gluon
[2] 
https://github.com/openwrt/openwrt/pull/1862/commits/c1e80f1b6e673912437422e4900facb409e41143#diff-132b371dc289dab58843cae7f9c430f5


So, both of the patches above need to be applied to ath10k-ct 4.19 driver?


[3] https://patchwork.ozlabs.org/patch/1051204/


I can apply this one to the 4.19 ath10k-ct driver too, I just am not using 4.19 
internally,
so...well, no local testing.


[4] https://github.com/openwrt/openwrt/pull/1077


It should be pretty easy for someone to write a patch to extend 'fwcfg' feature 
in ath10k-ct
to support this, or just hack in a commit similar to what you did to the stock 
driver if needed.

I'll very likely accept a patch that enables tweaking this based on fwcfg API.

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Trunk tl wdr4900 v1 boot fails on bootloader CRC check

2019-03-10 Thread Alberto Bursi 


On 10/03/19 22:33, Sami Olmari wrote:


On Sun, Mar 10, 2019 at 4:20 PM Alberto Bursi 
mailto:bobafetthotm...@gmail.com>> wrote:



On 10/03/19 21:32, Sami Olmari via openwrt-devel wrote:
> Okay it wasn't
>

https://github.com/openwrt/openwrt/commit/576c69938bb38c7edfa23f220eb30cb5c1d0a726

> nor the immediately next one
>

https://github.com/openwrt/openwrt/commit/0fbd3d23aadee0d95beef4f077a866dae7f4841a

> so it's still unclear what commit really breaks this... but I'll
try
> to keep looking.. :)
>
> --
>  Sami Olmari
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org

> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


The issue isn't a specific commit.

The issue is the kernel is too big.

The bootloader of this device only reads 0x29F000 bytes in hex or

2748416 bytes, around 2.6Mb in decimal.


In the Github PR (1) they see they can only work around this by

making an u-boot bootloader that can be loaded instead of the kernel.

Then this u-boot will load the kernel with no limitations.


-Alberto


[1] https://github.com/openwrt/openwrt/pull/1773



Shouldn't this alleviate that? 
https://github.com/openwrt/openwrt/commit/576c69938bb38c7edfa23f220eb30cb5c1d0a726


"
Currently, the image creation process for the TP-Link tl-wdr4900-v1
needs a fixed sized kernel and places the rootfs partition at a
fixed offset. With the upcoming move to 4.19 the kernel will no
longer fit into the existing allocated space for the kernel
partition.

This patch converts the device to utilize the established
tplink,firmware mtdsplitter, which can deal with a dynamic
kernel/rootfs size.

"

Not that I really know too good, I'm still just eager user more than 
developer... Anyway, All I can then hope a fix is introduced... I am more than 
willing to alpha/betatest :)

--
  Sami Olmari



No it does not. That patch solves kernel size issue for OpenWrt, but not 
for bootloader.


The bootloader will still only read 2.6MB from flash, where the kernel 
partition was in stock firmware.


If the kernel is bigger than that, it will not be all read and will fail.

This is why they want to make a second u-boot bootloader,

so the main bootloader will load and execute the second bootloader

that will then load and execute the kernel. Other devices in OpenWrt do 
this, it's not a new thing.


Follow the Github PR thread and see if they can fix this.

-Alberto

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Trunk tl wdr4900 v1 boot fails on bootloader CRC check

2019-03-10 Thread Sami Olmari via openwrt-devel 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Sun, Mar 10, 2019 at 4:20 PM Alberto Bursi 
wrote:

>
> On 10/03/19 21:32, Sami Olmari via openwrt-devel wrote:
> > Okay it wasn't
> >
> https://github.com/openwrt/openwrt/commit/576c69938bb38c7edfa23f220eb30cb5c1d0a726
> > nor the immediately next one
> >
> https://github.com/openwrt/openwrt/commit/0fbd3d23aadee0d95beef4f077a866dae7f4841a
> > so it's still unclear what commit really breaks this... but I'll try
> > to keep looking.. :)
> >
> > --
> >  Sami Olmari
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
>
> The issue isn't a specific commit.
>
> The issue is the kernel is too big.
>
> The bootloader of this device only reads 0x29F000 bytes in hex or
>
> 2748416 bytes, around 2.6Mb in decimal.
>
>
> In the Github PR (1) they see they can only work around this by
>
> making an u-boot bootloader that can be loaded instead of the kernel.
>
> Then this u-boot will load the kernel with no limitations.
>
>
> -Alberto
>
>
> [1] https://github.com/openwrt/openwrt/pull/1773
>



Shouldn't this alleviate that?
https://github.com/openwrt/openwrt/commit/576c69938bb38c7edfa23f220eb30cb5c1d0a726

"

Currently, the image creation process for the TP-Link tl-wdr4900-v1
needs a fixed sized kernel and places the rootfs partition at a
fixed offset. With the upcoming move to 4.19 the kernel will no
longer fit into the existing allocated space for the kernel
partition.

This patch converts the device to utilize the established
tplink,firmware mtdsplitter, which can deal with a dynamic
kernel/rootfs size.

"

Not that I really know too good, I'm still just eager user more than
developer... Anyway, All I can then hope a fix is introduced... I am
more than willing to alpha/betatest :)

-- 

 Sami Olmari
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Trunk tl wdr4900 v1 boot fails on bootloader CRC check

2019-03-10 Thread Alberto Bursi 



On 10/03/19 21:32, Sami Olmari via openwrt-devel wrote:
Okay it wasn't 
https://github.com/openwrt/openwrt/commit/576c69938bb38c7edfa23f220eb30cb5c1d0a726 
nor the immediately next one 
https://github.com/openwrt/openwrt/commit/0fbd3d23aadee0d95beef4f077a866dae7f4841a 
so it's still unclear what commit really breaks this... but I'll try 
to keep looking.. :)


--
 Sami Olmari
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel



The issue isn't a specific commit.

The issue is the kernel is too big.

The bootloader of this device only reads 0x29F000 bytes in hex or

2748416 bytes, around 2.6Mb in decimal.


In the Github PR (1) they see they can only work around this by

making an u-boot bootloader that can be loaded instead of the kernel.

Then this u-boot will load the kernel with no limitations.


-Alberto


[1] https://github.com/openwrt/openwrt/pull/1773


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Trunk tl wdr4900 v1 boot fails on bootloader CRC check

2019-03-10 Thread Sami Olmari via openwrt-devel 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Okay it wasn't
https://github.com/openwrt/openwrt/commit/576c69938bb38c7edfa23f220eb30cb5c1d0a726
nor the immediately next one
https://github.com/openwrt/openwrt/commit/0fbd3d23aadee0d95beef4f077a866dae7f4841a
so it's still unclear what commit really breaks this... but I'll try to
keep looking.. :)

-- 
 Sami Olmari

On Sun, Mar 10, 2019 at 2:07 PM Sami Olmari via openwrt-devel <
openwrt-devel@lists.openwrt.org> wrote:

> The sender domain has a DMARC Reject/Quarantine policy which disallows
> sending mailing list messages using the original "From" header.
>
> To mitigate this problem, the original message has been wrapped
> automatically by the mailing list software.
>
>
> -- Forwarded message --
> From: Sami Olmari 
> To: openwrt-devel ,
> paweldembi...@gmail.com, chunk...@gmail.com
> Cc:
> Bcc:
> Date: Sun, 10 Mar 2019 14:06:24 +0200
> Subject: Trunk tl wdr4900 v1 boot fails on bootloader CRC check
> So, current trunk for tp-link WDR4900 v1 fails to boot properly. It fails
> bootloader CRC check.
>
> Serial log:
>
> ## Booting kernel from Legacy Image at 0200 ...
>Image Name:   Linux-4.14.105
>Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>Data Size:2908775 Bytes = 2.8 MiB
>Load Address: 0100
>Entry Point:  01000588
>Verifying Checksum ... Bad Data CRC
> ERROR: can't get kernel image!
>
> This happends on snapshot downloadable from openwrt site as well as latest
> as of now buildroot trunk image. Also no matte do one upload an sysupgrade
> for updating workin openwrt image or throw in factory image with
> serial+tftp recovery, endresult is same.
>
> I'm trying to narrow down at what commit exactly this got broken, but this
> will take some time... My initial suspect would be around commit
> 576c69938bb38c7edfa23f220eb30cb5c1d0a726 but I might be wrong...
>
> Anyway I wanted to report this ASAP as it will brick any WDR4900 v1 out
> there still existing :)
>
> --
>  Sami Olmari
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Trunk tl wdr4900 v1 boot fails on bootloader CRC check

2019-03-10 Thread Christian Lamparter 
On Sunday, March 10, 2019 1:06:24 PM CET Sami Olmari wrote:
> So, current trunk for tp-link WDR4900 v1 fails to boot properly. It fails
> bootloader CRC check.
> 
> Serial log:
> 
> ## Booting kernel from Legacy Image at 0200 ...
>Image Name:   Linux-4.14.105
>Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>Data Size:2908775 Bytes = 2.8 MiB
>Load Address: 0100
>Entry Point:  01000588
>Verifying Checksum ... Bad Data CRC
> ERROR: can't get kernel image!
> 
> This happends on snapshot downloadable from openwrt site as well as latest
> as of now buildroot trunk image. Also no matte do one upload an sysupgrade
> for updating workin openwrt image or throw in factory image with
> serial+tftp recovery, endresult is same.
> 
> I'm trying to narrow down at what commit exactly this got broken, but this
> will take some time... My initial suspect would be around commit
> 576c69938bb38c7edfa23f220eb30cb5c1d0a726 but I might be wrong...
> 
> Anyway I wanted to report this ASAP as it will brick any WDR4900 v1 out
> there still existing :)
> 

Pawel Dembicki has already started a PR about this some time ago.

|Boot command read only 0x29F000 data from flash.
|Bigger images causes crc error. It can't be changed.

And there's a round-about way of making it work too.
https://github.com/openwrt/openwrt/pull/1773#issuecomment-461082045

However, It's not like you can just come up with something unless
you want to invest your own time to hunt down a viable fix.

Regards,
Christian



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Trunk tl wdr4900 v1 boot fails on bootloader CRC check

2019-03-10 Thread Sami Olmari via openwrt-devel 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
So, current trunk for tp-link WDR4900 v1 fails to boot properly. It fails
bootloader CRC check.

Serial log:

## Booting kernel from Legacy Image at 0200 ...
   Image Name:   Linux-4.14.105
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:2908775 Bytes = 2.8 MiB
   Load Address: 0100
   Entry Point:  01000588
   Verifying Checksum ... Bad Data CRC
ERROR: can't get kernel image!

This happends on snapshot downloadable from openwrt site as well as latest
as of now buildroot trunk image. Also no matte do one upload an sysupgrade
for updating workin openwrt image or throw in factory image with
serial+tftp recovery, endresult is same.

I'm trying to narrow down at what commit exactly this got broken, but this
will take some time... My initial suspect would be around commit
576c69938bb38c7edfa23f220eb30cb5c1d0a726 but I might be wrong...

Anyway I wanted to report this ASAP as it will brick any WDR4900 v1 out
there still existing :)

-- 
 Sami Olmari
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] coverity results are now public

2019-03-10 Thread Alexander Couzens 
> > I changed the project to allow everybody to view the defects.  
> 
> can you please try harder? :-) I can view some stats, but no details
> about actual defects. Am I doing it wrong?

maybe it needs another run of the coverity scan. but I set it already
to the option to allow everybody.

If it's still not work, just ask to view the defects and I'll accept
you.

best,
lynxis


pgpbvrvWMSk7i.pgp
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] About 802.11s mesh on IPQ4019, ath10k-ct and ct-firmware

2019-03-10 Thread Sven Eckelmann 
On Sunday, 10 March 2019 05:52:00 CET Xuebing Wang wrote:
[...]
> Are there anyone building 802.11s routers based on tag 18.06.1, 18.06.2 
> or branch openwrt-18.06?

Most(?) companies and community projects just throw the 802.11s forwarding/
routing part away and are running their preferred Layer2/Layer3 mesh protocol 
(bmxd/6/7, olsrd(2), babeld, batman-adv, ...) over it. But yes, they are still 
require the meshpoint interface support in ath10k+firmware.

A project I am more familiar (and is using 18.06.x) is freifunk-gluon [1]. 
They just select the ath10k-firmware-* (from kvalo/linux-firmware) for 
meshpoint setups and ath10k-firmware*-ct for IBSS setups.

As far as I know, this will still be possible with OpenWrt 19.xx). And this 
should also work the same when you want to run 802.11s+HWMP over it.

> I noticed that in OpenWRT master branch ath10k-ct and 
> ath10k-firmware-qca4019-ct are enabled by default, but they are not 
> enabled in tag 18.06.2.

Regarding ath10k vs. ath10k-ct - yes, this is a rather unfortunate situation 
that we have two different drivers. ath10k-ct is basically ath10k with a  
~7000 lines patch on top. You just have to keep in mind that there are some 
hacks in it which may break standard ath10k/mac80211 features [2]. So you 
cannot always assume that this can be reported to the ath10k people. And some 
of the changes in the mac80211 ath10k could be missing in ath10k-ct [3,4]. So 
you have to figure out yourself which driver better fits your needs.

Kind regards,
Sven

[1] https://github.com/freifunk-gluon/gluon
[2] 
https://github.com/openwrt/openwrt/pull/1862/commits/c1e80f1b6e673912437422e4900facb409e41143#diff-132b371dc289dab58843cae7f9c430f5
[3] https://patchwork.ozlabs.org/patch/1051204/
[4] https://github.com/openwrt/openwrt/pull/1077

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel