[OpenWrt-Devel] Regarding change "ath79: move lzma-loader to the end of available RAM"

2020-02-28 Thread Christopher Hill 
Hello,

I was looking at this recent change [1] to move the lzma-loader in
ath79, which has comment:


"In certain cases, the uncompressed initramfs image will overwrite
the lzma-loader, which is currently only 10 MB away from kernel image
start. To prevent this, change LZMA_TEXT_START to 24 MB, so loader
and compressed image have 8 MB at the end of RAM and uncompressed
image has 24 MB available."


I bring this up as I'm (slowly) porting a Mikrotik rb493g for ath79 [2]
and I believe I need additional change in this area.

Looking at the older ar71xx image
"openwrt-19.07.0-ar71xx-mikrotik-vmlinux-initramfs-lzma.elf" binwalk
shows "LZMA compressed data, properties: 0x6D, dictionary size: 8388608
bytes, uncompressed size: 7543556 bytes" and this boots fine.

Building an ath79 image from latest git sources and running binwalk
shows "LZMA compressed data, properties: 0x6D, dictionary size: 8388608
bytes, uncompressed size: 12491705 bytes"

i.e. instead of a 7MB image, it's now a 12MB image.

I was thinking the lzma-loader change would mean this is OK, however it
will not boot.

So...

I added configuration "default TARGET_INITRAMFS_COMPRESSION_LZMA if
TARGET_ath79" and this reduces the generated image to "uncompressed
size: 8396454 bytes"

i.e. an 8MB image, and this will boot.


Perhaps this is an issue with RouterBOOT booter 6.41, or the rb4xx
series boards and this new location?


Thanks,
Chris


N.B. If I add LuCI to this smaller image it grows to "uncompressed size:
8752277 bytes" and this will also not boot.



[1]
https://github.com/openwrt/openwrt/commit/071a6372762d289b2fa5a8d1a138eff944c93c9e

[2]
https://github.com/ch6574/openwrt/commit/deeb9203f73a396ddca89aa8b2ce69c47974afe5

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

Re: [OpenWrt-Devel] [PATCHv2 1/3] tools/pkg-config: Replace with pkgconf

2020-02-28 Thread Rosen Penev 
On Fri, Feb 28, 2020 at 2:03 AM Petr Štetiar  wrote:
>
> Rosen Penev  [2019-12-25 12:51:33]:
>
> > On Wed, Dec 25, 2019 at 3:17 AM Petr Štetiar  wrote:
> > >
> > > Rosen Penev  [2019-11-28 11:19:31]:
> > >
> > > > pkgconf is a newer, actively maintained implementation of pkg-config
> > >
> > > I'm wondering if that `actively maintained` part still holds true.
> >
> > It does. The team has management issues it seems. They've publicly
> > stated they want to move away from GitHub:
> > https://github.com/pkgconf/pkgconf.github.io/issues/1
> >
> > So you would think based on the URL of the download that development
> > moved here: https://git.dereferenced.org/pkgconf/pkgconf#
> >
> > But there's also a third place where development seems to have moved:
> > https://git.sr.ht/~kaniini/pkgconf/log
> >
> > Seems it's a mess.
>
> So how to sort this out?
>
> I'm simply in favor of keeping the current pkg-config, because the suggested
> replacement doesn't seem like a worth considering yet, but maybe I read it
> wrong.
It's more portable and smaller. And as stated, it is still fairly active.
>
> -- ynezz

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

Re: [OpenWrt-Devel] [PATCH] build: refactor JSON info files

2020-02-28 Thread Petr Štetiar 
Paul Spooren  [2020-02-28 13:09:46]:

> > > To archive the previous behaviour the option JSON_INDIVIDUAL_JSON_INFO
> > > can be set.
> > Why do we need to preserve that previous behaviour?
> 
> Two reasons:
> 
> * We have to create those files anyway before a merge because image creation
> happens in parallel, so no single overview can be added to. If this is a
> wrong assumption please step in

Ok, but we don't need two different config options for that. One for single
file JSON output and another one for amalgamated JSON.

> * For ImageBuilders it is convenient to have a per profile file.

I don't follow here.

> I'd be in favor of keeping it if you wouldn't mind. It would be disabled for
> buildbots and users per default.

I don't like an idea of having *two* different options for *one* functionality
for no reason. Initial idea was JSON for online builders, so thats *one* config
option to me.

> I'm looking into this issue but haven't figured it out yet. Either the JSON
> generation or file writing is broken. The odd thing about it is that it also
> happens if a file is opened only once (as in only a single image is
> created), so it is unlikely an issue with parallel writing into a file... If
> anyone has ideas, please share.

What about some graceful error handling, outputing the broken JSON file? Maybe
it's another Docker filesystem related hiccup?

-- ynezz

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

Re: [OpenWrt-Devel] [PATCH] build: refactor JSON info files

2020-02-28 Thread Paul Spooren 

Hi,


This PR refactors the JSON creation to store individual files in
$(KDIR)/tmp and create an single overview file called `profiles.json` in
the target dir.

As before, this creation is enabled by default only for the BUILDBOT.

To archive the previous behaviour the option JSON_INDIVIDUAL_JSON_INFO
can be set.

Why do we need to preserve that previous behaviour?


Two reasons:

* We have to create those files anyway before a merge because image 
creation happens in parallel, so no single overview can be added to. If 
this is a wrong assumption please step in
* For ImageBuilders it is convenient to have a per profile file. It does 
not add much complexity as the file is simply copied.


I'd be in favor of keeping it if you wouldn't mind. It would be disabled 
for buildbots and users per default.



FYI those individual files are broken[1] on some buildhosts (8C/16T, E5-2650) 
anyway:

  Traceback (most recent call last):
   File "/builds/ynezz/openwrt/scripts/json_add_image_info.py", line 49, in 

 device_info = json.load(json_file)
   File "/usr/lib/python3.5/json/__init__.py", line 268, in load
 parse_constant=parse_constant, object_pairs_hook=object_pairs_hook, **kw)
   File "/usr/lib/python3.5/json/__init__.py", line 319, in loads
 return _default_decoder.decode(s)
   File "/usr/lib/python3.5/json/decoder.py", line 342, in decode
 raise JSONDecodeError("Extra data", s, end)
  json.decoder.JSONDecodeError: Extra data: line 35 column 2 (char 823)

Would be nice to fix that and making this errors fatal so it's more visible and
can be fixed sooner then later.
I'm looking into this issue but haven't figured it out yet. Either the 
JSON generation or file writing is broken. The odd thing about it is 
that it also happens if a file is opened only once (as in only a single 
image is created), so it is unlikely an issue with parallel writing into 
a file... If anyone has ideas, please share.

+jsonoverviewimageinfo: FORCE

nitpickbutyoucanusedashorundescoreifyouwantforsuchmultiwordtargetsormakethetargetnameshorter
 :)
No this is a value comment and no nit pick, I just assumed wrongly that 
dashes/underscores should be avoided as they're not used in the Makefile 
so far.

1. 
https://ynezz.gitlab.io/-/openwrt/-/jobs/447337426/artifacts/logs/target/linux/install.txt


Best,
Paul


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

Re: [OpenWrt-Devel] [PATCH 1/6] build: Add auto file tracking / uninstall for Host/Install

2020-02-28 Thread Petr Štetiar 
Jeffery To  [2019-06-15 02:35:29]:

Hi,

> This adds automatic file tracking and uninstallation (similar to that
> for Build/InstallDev) for files installed by Host/Install.

seems like patches 2 and 3 were superseded, and patch 1 doesn't apply anymore
so I've marked the series as changes requested.

Could you perhaps next time consider some cover letter, explaining why is this
useful and should be merged?

-- ynezz

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

Re: [OpenWrt-Devel] [PATCH] build: Remove STAGING_DIR_HOST references for InstallDev/UninstallDev

2020-02-28 Thread Petr Štetiar 
Jeffery To  [2019-06-09 06:00:47]:

Hi,

> Build/InstallDev no longer places a file list in
> $(STAGING_DIR_HOST)/packages; this change removes the creation of
> $(STAGING_DIR_HOST)/packages and the attempted removal of a
> STAGING_DIR_HOST file list during package clean.

that's clear, ok.

> This also changes the host directory passed to Build/UninstallDev from
> $(STAGING_DIR_HOST) to $(STAGING_DIR)/host, to match the directory
> passed to Build/InstallDev.

Late night, but I see following:

 include/package.mk: $(call 
Build/InstallDev,$(TMP_DIR)/stage-$(PKG_DIR_NAME),$(TMP_DIR)/stage-$(PKG_DIR_NAME)/host)

> - $(call Build/UninstallDev,$(STAGING_DIR),$(STAGING_DIR_HOST))
> + $(call Build/UninstallDev,$(STAGING_DIR),$(STAGING_DIR)/host)

So that description doesn't correspond with the change.

> Signed-off-by: Jeffery To 
> ---
>  include/package.mk | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/include/package.mk b/include/package.mk
> index 569ad647d6..348f75fba7 100644
> --- a/include/package.mk
> +++ b/include/package.mk
> @@ -195,7 +195,7 @@ define Build/CoreTargets
>$(STAMP_INSTALLED) : export PATH=$$(TARGET_PATH_PKG)
>$(STAMP_INSTALLED): $(STAMP_BUILT)
>   rm -rf $(TMP_DIR)/stage-$(PKG_DIR_NAME)
> - mkdir -p $(TMP_DIR)/stage-$(PKG_DIR_NAME)/host $(STAGING_DIR)/packages 
> $(STAGING_DIR_HOST)/packages
> + mkdir -p $(TMP_DIR)/stage-$(PKG_DIR_NAME)/host $(STAGING_DIR)/packages
>   $(foreach hook,$(Hooks/InstallDev/Pre),\
>   $(call 
> $(hook),$(TMP_DIR)/stage-$(PKG_DIR_NAME),$(TMP_DIR)/stage-$(PKG_DIR_NAME)/host)$(sep)\
>   )
> @@ -314,9 +314,9 @@ clean-build: $(if $(wildcard 
> $(PKG_BUILD_DIR)/.autoremove),force-clean-build)
>  
>  clean: force-clean-build
>   $(CleanStaging)
> - $(call Build/UninstallDev,$(STAGING_DIR),$(STAGING_DIR_HOST))
> + $(call Build/UninstallDev,$(STAGING_DIR),$(STAGING_DIR)/host)
>   $(Build/Clean)
> - rm -f $(STAGING_DIR)/packages/$(STAGING_FILES_LIST) 
> $(STAGING_DIR_HOST)/packages/$(STAGING_FILES_LIST)
> + rm -f $(STAGING_DIR)/packages/$(STAGING_FILES_LIST)
>  
>  dist:
>   $(Build/Dist)

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

Re: [OpenWrt-Devel] [PATCH] imx6: backport lsm9ds1 imu support for GW553x

2020-02-28 Thread Tim Harvey 
On Fri, Feb 28, 2020 at 1:06 PM Petr Štetiar  wrote:
>
> Hi Tim,
>
> commit description is nice (and required), can you add it next time? No need
> for v2, I'll add something myself to all your patches this time.
>
> BTW it's quite helpful to include the upstream kernel version used for the
> backport and include it in the patch filename, for example:
>
>  005-v5.7-ARM-dts-imx6qdl-gw553x-add-lsm9ds1-iio-imu-magn-supp.patch
>

Petr,

Ok - will make sure I add that in the future. This particular one just
recently got accepted and I'm not sure if it will be pulled into a
later 5.6-rc or will land in 5.7 (likely the latter).

Tim

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

Re: [OpenWrt-Devel] [PATCH] build: refactor JSON info files

2020-02-28 Thread Petr Štetiar 
Paul Spooren  [2020-02-15 13:27:03]:

Hi,

> This PR refactors the JSON creation to store individual files in
> $(KDIR)/tmp and create an single overview file called `profiles.json` in
> the target dir.
> 
> As before, this creation is enabled by default only for the BUILDBOT.
> 
> To archive the previous behaviour the option JSON_INDIVIDUAL_JSON_INFO
> can be set.

Why do we need to preserve that previous behaviour?

FYI those individual files are broken[1] on some buildhosts (8C/16T, E5-2650) 
anyway:

 Traceback (most recent call last):
  File "/builds/ynezz/openwrt/scripts/json_add_image_info.py", line 49, in 

device_info = json.load(json_file)
  File "/usr/lib/python3.5/json/__init__.py", line 268, in load
parse_constant=parse_constant, object_pairs_hook=object_pairs_hook, **kw)
  File "/usr/lib/python3.5/json/__init__.py", line 319, in loads
return _default_decoder.decode(s)
  File "/usr/lib/python3.5/json/decoder.py", line 342, in decode
raise JSONDecodeError("Extra data", s, end)
 json.decoder.JSONDecodeError: Extra data: line 35 column 2 (char 823)

Would be nice to fix that and making this errors fatal so it's more visible and
can be fixed sooner then later.

> +jsonoverviewimageinfo: FORCE

nitpickbutyoucanusedashorundescoreifyouwantforsuchmultiwordtargetsormakethetargetnameshorter
 :)

1. 
https://ynezz.gitlab.io/-/openwrt/-/jobs/447337426/artifacts/logs/target/linux/install.txt

-- ynezz

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

Re: [OpenWrt-Devel] RFT: Add support for kernel 5.4

2020-02-28 Thread Stefan Lippers-Hollmann 
Hi

On 2020-02-28, John Crispin wrote:
> On 28.02.20 21:30, Stefan Lippers-Hollmann wrote:
> > On 2020-02-28, m...@adrianschmutzler.de wrote:
> >>> On 2020-02-28, Koen Vandeputte wrote:
[...]
> > ath79 with kernel 4.14 has already been (mostly) broken by "ath79: add
> > new ar934x spi driver" (ebf0d8dadeca443121f4f597c51bf6591e341caf), which
> > does break the (shared between all kernel versions) DTS definitions for
> > NAND based ath79 devices (breaking compilation with kernel 4.14).
> >
> > Because of "FS#2524 - ath79-tiny: TP-Link TL-WR941ND v2.4: Marvel
> > MV88E6060 regression between kernel v4.14 and v4.19"
> > https://bugs.openwrt.org/index.php?do=details_id=2524 I still do
> > regularly build ath79 with kernel 4.14, but in order to finish the build
> > I do need to comment out the affected devices:
[...]
> >
> > Admittedly, the affected TL-WR941ND v2 (4/32) is barely worth the effort
> > anymore.
[...]
> sorry for being dense here. what are you trying to tell us ? is there a
> bug for which you propose a patch or is this a report or just a rant ?
> honestly cant figure it out

Neither, nor. It's merely a report that kernel 4.14 support (albeit
technically present in source) for ath79 isn't functional anymore (and
hasn't been for a few weeks) anyways, regardless of the introduction of
kernel 5.4 and its changes to ag71xx. Kind of answering Adrian's previous
question "By moving ag71xx to files-4.19 on ath79, I suspect 4.14 is broken
now on this target."

Beyond that, I'm merely explaining why I'm still regularly looking at ath79
with kernel 4.14 (because of the aforementioned regression in MV88E6060
on top of kernel 4.19). While I still regularly build for this device and
sometimes boot it up/ flash a fresh (kernel 4.14 based) build, I'm well
aware that this device is far beyond its prime (4/32, buggy draft-n AR9103
wireless) and don't actively use it anymore. Therefore I consider this
flyspray bug more as a heads-up (while ath79 with MV88E6060 is rare, the
underlying cause for this regression might have further impact), than in
any way, shape or form 'important' - and I'd consider commenting out
"tplink_tl-wr941-v2" (or removing its support altogether) a valid
'solution' (just retaining images for it in its current state in master is
problematic, as they are broken and because the device requires serial
access for recovering; no push-button tftp recovery provided by the OEM
bootloader).

Regards
Stefan Lippers-Hollmann

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

Re: [OpenWrt-Devel] [PATCH] imx6: backport lsm9ds1 imu support for GW553x

2020-02-28 Thread Petr Štetiar 
Hi Tim,

commit description is nice (and required), can you add it next time? No need
for v2, I'll add something myself to all your patches this time.

BTW it's quite helpful to include the upstream kernel version used for the
backport and include it in the patch filename, for example:

 005-v5.7-ARM-dts-imx6qdl-gw553x-add-lsm9ds1-iio-imu-magn-supp.patch

Cheers,

Petr

> Signed-off-by: Tim Harvey 
> ---
>  ...6qdl-gw553x-add-lsm9ds1-iio-imu-magn-supp.patch | 73 
> ++
>  1 file changed, 73 insertions(+)
>  create mode 100644 
> target/linux/imx6/patches-5.4/005-ARM-dts-imx6qdl-gw553x-add-lsm9ds1-iio-imu-magn-supp.patch

...

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

Re: [OpenWrt-Devel] RFT: Add support for kernel 5.4

2020-02-28 Thread Stefan Lippers-Hollmann 
On 2020-02-28, Stefan Lippers-Hollmann wrote:
[...]
> does break the (shared between all kernel versions) DTS definitions for
> NAND based ath79 devices (breaking compilation with kernel 4.14).

Obviously this not meant to read NAND, but the more modern SOCs using
this new SPI driver (only applied to patches-4.19/ config-4.19) and its
different DTS definitions.

Sorry about the misleading typo.

Regards
Stefan Lippers-Hollmann

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

Re: [OpenWrt-Devel] RFT: Add support for kernel 5.4

2020-02-28 Thread John Crispin 

On 28.02.20 21:30, Stefan Lippers-Hollmann wrote:

Hi

On 2020-02-28, m...@adrianschmutzler.de wrote:

Hi,


On 2020-02-28, Koen Vandeputte wrote:

[...]

All supported targets have been provided with kernel 5.4 as the "Testing
kernel".
This means you can enable 5.4 by selecting "Global --> use the testing kernel
version" within menuconfig.


Thanks for your work.

By moving ag71xx to files-4.19 on ath79, I suspect 4.14 is broken now on
this target.
So, we should either copy that to files-4.14 as well or remove the
remaining 4.14 files there as well (where I'd prefer the latter).


ath79 with kernel 4.14 has already been (mostly) broken by "ath79: add
new ar934x spi driver" (ebf0d8dadeca443121f4f597c51bf6591e341caf), which
does break the (shared between all kernel versions) DTS definitions for
NAND based ath79 devices (breaking compilation with kernel 4.14).

Because of "FS#2524 - ath79-tiny: TP-Link TL-WR941ND v2.4: Marvel
MV88E6060 regression between kernel v4.14 and v4.19"
https://bugs.openwrt.org/index.php?do=details_id=2524 I still do
regularly build ath79 with kernel 4.14, but in order to finish the build
I do need to comment out the affected devices:

$ grep \# ath79-k414.diff
+#TARGET_DEVICES += tplink_cpe210-v1
+#TARGET_DEVICES += tplink_cpe220-v2
+#TARGET_DEVICES += tplink_cpe510-v1
+#TARGET_DEVICES += tplink_cpe510-v2
+#TARGET_DEVICES += tplink_cpe510-v3
+#TARGET_DEVICES += tplink_cpe610-v1
+#TARGET_DEVICES += tplink_tl-wdr3500-v1
+#TARGET_DEVICES += tplink_tl-wdr3600-v1
+#TARGET_DEVICES += tplink_tl-wdr4300-v1
+#TARGET_DEVICES += tplink_tl-wdr4300-v1-il
+#TARGET_DEVICES += tplink_tl-wr842n-v2
+#TARGET_DEVICES += tplink_wbs210-v2
+#TARGET_DEVICES += tplink_wbs510-v1
+#TARGET_DEVICES += tplink_wbs510-v2
+#TARGET_DEVICES += ubnt_bullet-m-xw
+#TARGET_DEVICES += ubnt_lap-120
+#TARGET_DEVICES += ubnt_litebeam-ac-gen2
+#TARGET_DEVICES += ubnt_nanobeam-ac
+#TARGET_DEVICES += ubnt_nanostation-ac
+#TARGET_DEVICES += ubnt_nanostation-ac-loco
+#TARGET_DEVICES += ubnt_nanostation-loco-m-xw
+#TARGET_DEVICES += ubnt_nanostation-m-xw
+#TARGET_DEVICES += comfast_cf-e120a-v3
+#TARGET_DEVICES += dlink_dir-825-c1
+#TARGET_DEVICES += dlink_dir-835-a1
+#TARGET_DEVICES += iodata_etg3-r
+#TARGET_DEVICES += iodata_wn-ag300dgr
+#TARGET_DEVICES += ocedo_raccoon
+#TARGET_DEVICES += pcs_cap324
+#TARGET_DEVICES += pcs_cr3000
+#TARGET_DEVICES += pcs_cr5000
+#TARGET_DEVICES += pisen_wmb001n
+#TARGET_DEVICES += qihoo_c301
+#TARGET_DEVICES += sitecom_wlr-7100
+#TARGET_DEVICES += teltonika_rut955
+#TARGET_DEVICES += wd_mynet-n750
+#TARGET_DEVICES += wd_mynet-wifi-rangeextender
+#TARGET_DEVICES += winchannel_wb2000
+#TARGET_DEVICES += zbtlink_zbt-wd323

Admittedly, the affected TL-WR941ND v2 (4/32) is barely worth the effort
anymore.

Regards
Stefan Lippers-Hollmann

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



sorry for being dense here. what are you trying to tell us ? is there a 
bug for which you propose a patch or is this a report or just a rant ? 
honestly cant figure it out

   John

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

Re: [OpenWrt-Devel] RFT: Add support for kernel 5.4

2020-02-28 Thread Stefan Lippers-Hollmann 
Hi

On 2020-02-28, m...@adrianschmutzler.de wrote:
> Hi,
>
> > On 2020-02-28, Koen Vandeputte wrote:
[...]
> > All supported targets have been provided with kernel 5.4 as the "Testing
> > kernel".
> > This means you can enable 5.4 by selecting "Global --> use the testing 
> > kernel
> > version" within menuconfig.
>
> Thanks for your work.
>
> By moving ag71xx to files-4.19 on ath79, I suspect 4.14 is broken now on
> this target.
> So, we should either copy that to files-4.14 as well or remove the
> remaining 4.14 files there as well (where I'd prefer the latter).

ath79 with kernel 4.14 has already been (mostly) broken by "ath79: add
new ar934x spi driver" (ebf0d8dadeca443121f4f597c51bf6591e341caf), which
does break the (shared between all kernel versions) DTS definitions for
NAND based ath79 devices (breaking compilation with kernel 4.14).

Because of "FS#2524 - ath79-tiny: TP-Link TL-WR941ND v2.4: Marvel
MV88E6060 regression between kernel v4.14 and v4.19"
https://bugs.openwrt.org/index.php?do=details_id=2524 I still do
regularly build ath79 with kernel 4.14, but in order to finish the build
I do need to comment out the affected devices:

$ grep \# ath79-k414.diff
+#TARGET_DEVICES += tplink_cpe210-v1
+#TARGET_DEVICES += tplink_cpe220-v2
+#TARGET_DEVICES += tplink_cpe510-v1
+#TARGET_DEVICES += tplink_cpe510-v2
+#TARGET_DEVICES += tplink_cpe510-v3
+#TARGET_DEVICES += tplink_cpe610-v1
+#TARGET_DEVICES += tplink_tl-wdr3500-v1
+#TARGET_DEVICES += tplink_tl-wdr3600-v1
+#TARGET_DEVICES += tplink_tl-wdr4300-v1
+#TARGET_DEVICES += tplink_tl-wdr4300-v1-il
+#TARGET_DEVICES += tplink_tl-wr842n-v2
+#TARGET_DEVICES += tplink_wbs210-v2
+#TARGET_DEVICES += tplink_wbs510-v1
+#TARGET_DEVICES += tplink_wbs510-v2
+#TARGET_DEVICES += ubnt_bullet-m-xw
+#TARGET_DEVICES += ubnt_lap-120
+#TARGET_DEVICES += ubnt_litebeam-ac-gen2
+#TARGET_DEVICES += ubnt_nanobeam-ac
+#TARGET_DEVICES += ubnt_nanostation-ac
+#TARGET_DEVICES += ubnt_nanostation-ac-loco
+#TARGET_DEVICES += ubnt_nanostation-loco-m-xw
+#TARGET_DEVICES += ubnt_nanostation-m-xw
+#TARGET_DEVICES += comfast_cf-e120a-v3
+#TARGET_DEVICES += dlink_dir-825-c1
+#TARGET_DEVICES += dlink_dir-835-a1
+#TARGET_DEVICES += iodata_etg3-r
+#TARGET_DEVICES += iodata_wn-ag300dgr
+#TARGET_DEVICES += ocedo_raccoon
+#TARGET_DEVICES += pcs_cap324
+#TARGET_DEVICES += pcs_cr3000
+#TARGET_DEVICES += pcs_cr5000
+#TARGET_DEVICES += pisen_wmb001n
+#TARGET_DEVICES += qihoo_c301
+#TARGET_DEVICES += sitecom_wlr-7100
+#TARGET_DEVICES += teltonika_rut955
+#TARGET_DEVICES += wd_mynet-n750
+#TARGET_DEVICES += wd_mynet-wifi-rangeextender
+#TARGET_DEVICES += winchannel_wb2000
+#TARGET_DEVICES += zbtlink_zbt-wd323

Admittedly, the affected TL-WR941ND v2 (4/32) is barely worth the effort
anymore.

Regards
Stefan Lippers-Hollmann

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

[OpenWrt-Devel] [PATCH] imx6: add support for Gateworks GW5907/GW5910/GW5912/GW5913

2020-02-28 Thread Tim Harvey 
- backport dts patches from 5.6:
ARM: dts: imx: Add GW5912 board support
ARM: dts: imx: Add GW5913 board support
ARM: dts: imx: Add GW5910 board support
ARM: dts: imx: Add GW5907 board support
- add support for board names in lib/imx6.sh
- add support for and net device config in /etc/board.d/02_network

Signed-off-by: Tim Harvey 
---
 .../linux/imx6/base-files/etc/board.d/02_network   |   6 +-
 target/linux/imx6/base-files/lib/imx6.sh   |  20 +
 .../001-ARM-dts-imx-Add-GW5907-board-support.patch | 496 +
 .../002-ARM-dts-imx-Add-GW5910-board-support.patch | 597 +
 .../003-ARM-dts-imx-Add-GW5913-board-support.patch | 449 
 .../004-ARM-dts-imx-Add-GW5912-board-support.patch | 565 +++
 6 files changed, 2132 insertions(+), 1 deletion(-)
 create mode 100644 
target/linux/imx6/patches-5.4/001-ARM-dts-imx-Add-GW5907-board-support.patch
 create mode 100644 
target/linux/imx6/patches-5.4/002-ARM-dts-imx-Add-GW5910-board-support.patch
 create mode 100644 
target/linux/imx6/patches-5.4/003-ARM-dts-imx-Add-GW5913-board-support.patch
 create mode 100644 
target/linux/imx6/patches-5.4/004-ARM-dts-imx-Add-GW5912-board-support.patch

diff --git a/target/linux/imx6/base-files/etc/board.d/02_network 
b/target/linux/imx6/base-files/etc/board.d/02_network
index 6ec6673..13a140a 100755
--- a/target/linux/imx6/base-files/etc/board.d/02_network
+++ b/target/linux/imx6/base-files/etc/board.d/02_network
@@ -13,7 +13,11 @@ case "$board" in
 cubox-i |\
 *gw51xx |\
 *gw52xx |\
-*gw5904)
+*gw5904 |\
+*gw5907 |\
+*gw5910 |\
+*gw5912 |\
+*gw5913)
ucidef_set_interface_lan 'eth0'
;;
 *gw53xx |\
diff --git a/target/linux/imx6/base-files/lib/imx6.sh 
b/target/linux/imx6/base-files/lib/imx6.sh
index 68caaff..63fff0f 100755
--- a/target/linux/imx6/base-files/lib/imx6.sh
+++ b/target/linux/imx6/base-files/lib/imx6.sh
@@ -81,6 +81,26 @@ imx6_board_detect() {
name="gw5904"
;;
 
+   "Gateworks Ventana i.MX6 DualLite/Solo GW5907" |\
+   "Gateworks Ventana i.MX6 Dual/Quad GW5907")
+   name="gw5907"
+   ;;
+
+   "Gateworks Ventana i.MX6 DualLite/Solo GW5910" |\
+   "Gateworks Ventana i.MX6 Dual/Quad GW5910")
+   name="gw5910"
+   ;;
+
+   "Gateworks Ventana i.MX6 DualLite/Solo GW5912" |\
+   "Gateworks Ventana i.MX6 Dual/Quad GW5912")
+   name="gw5912"
+   ;;
+
+   "Gateworks Ventana i.MX6 DualLite/Solo GW5913" |\
+   "Gateworks Ventana i.MX6 Dual/Quad GW5913")
+   name="gw5913"
+   ;;
+
"SolidRun Cubox-i Solo/DualLite" |\
"SolidRun Cubox-i Dual/Quad")
name="cubox-i"
diff --git 
a/target/linux/imx6/patches-5.4/001-ARM-dts-imx-Add-GW5907-board-support.patch 
b/target/linux/imx6/patches-5.4/001-ARM-dts-imx-Add-GW5907-board-support.patch
new file mode 100644
index 000..a4e9604
--- /dev/null
+++ 
b/target/linux/imx6/patches-5.4/001-ARM-dts-imx-Add-GW5907-board-support.patch
@@ -0,0 +1,496 @@
+From 125120298dc05bb55a8874f07aa3f4bb6056bfb3 Mon Sep 17 00:00:00 2001
+From: Robert Jones 
+Date: Wed, 8 Jan 2020 07:44:21 -0800
+Subject: [PATCH 1/4] ARM: dts: imx: Add GW5907 board support
+
+The Gateworks GW5907 is an IMX6 SoC based single board computer with:
+ - IMX6Q or IMX6DL
+ - 32bit DDR3 DRAM
+ - FEC GbE Phy
+ - bi-color front-panel LED
+ - 256MB NAND boot device
+ - Gateworks System Controller (hwmon, pushbutton controller, EEPROM)
+ - Digital IO expander (pca9555)
+ - Joystick 12bit adc (ads1015)
+
+Signed-off-by: Robert Jones 
+Reviewed-by: Tim Harvey 
+Signed-off-by: Shawn Guo 
+---
+ arch/arm/boot/dts/Makefile|   2 +
+ arch/arm/boot/dts/imx6dl-gw5907.dts   |  14 ++
+ arch/arm/boot/dts/imx6q-gw5907.dts|  14 ++
+ arch/arm/boot/dts/imx6qdl-gw5907.dtsi | 399 ++
+ 4 files changed, 429 insertions(+)
+ create mode 100644 arch/arm/boot/dts/imx6dl-gw5907.dts
+ create mode 100644 arch/arm/boot/dts/imx6q-gw5907.dts
+ create mode 100644 arch/arm/boot/dts/imx6qdl-gw5907.dtsi
+
+diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
+index 1e9e1af..9ee80e2 100644
+--- a/arch/arm/boot/dts/Makefile
 b/arch/arm/boot/dts/Makefile
+@@ -422,6 +422,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
+   imx6dl-gw560x.dtb \
+   imx6dl-gw5903.dtb \
+   imx6dl-gw5904.dtb \
++  imx6dl-gw5907.dtb \
+   imx6dl-hummingboard.dtb \
+   imx6dl-hummingboard-emmc-som-v15.dtb \
+   imx6dl-hummingboard-som-v15.dtb \
+@@ -493,6 +494,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
+   imx6q-gw560x.dtb \
+   imx6q-gw5903.dtb \
+   imx6q-gw5904.dtb \
++  imx6q-gw5907.dtb \
+   imx6q-h100.dtb \
+   imx6q-hummingboard.dtb \
+   imx6q-hummingboard-emmc-som-v15.dtb \
+diff --git a/arch/arm/boot/dts/imx6dl-gw5907.dts 
b/arch/arm/boot/dts/imx6dl-gw5907.dts
+new file mode 100644
+index ..3fa2822
+--- /dev/null

[OpenWrt-Devel] [PATCH] imx6: backport lsm9ds1 imu support for GW553x

2020-02-28 Thread Tim Harvey 
Signed-off-by: Tim Harvey 
---
 ...6qdl-gw553x-add-lsm9ds1-iio-imu-magn-supp.patch | 73 ++
 1 file changed, 73 insertions(+)
 create mode 100644 
target/linux/imx6/patches-5.4/005-ARM-dts-imx6qdl-gw553x-add-lsm9ds1-iio-imu-magn-supp.patch

diff --git 
a/target/linux/imx6/patches-5.4/005-ARM-dts-imx6qdl-gw553x-add-lsm9ds1-iio-imu-magn-supp.patch
 
b/target/linux/imx6/patches-5.4/005-ARM-dts-imx6qdl-gw553x-add-lsm9ds1-iio-imu-magn-supp.patch
new file mode 100644
index 000..6a6c828
--- /dev/null
+++ 
b/target/linux/imx6/patches-5.4/005-ARM-dts-imx6qdl-gw553x-add-lsm9ds1-iio-imu-magn-supp.patch
@@ -0,0 +1,73 @@
+From 62e7f0b553038e3a1a1b2b067dd1fbdacd634e37 Mon Sep 17 00:00:00 2001
+From: Robert Jones 
+Date: Fri, 14 Feb 2020 13:02:41 -0800
+Subject: [PATCH] ARM: dts: imx6qdl-gw553x: add lsm9ds1 iio imu/magn support
+
+Add one node for the accel/gyro i2c device and another for the separate
+magnetometer device in the lsm9ds1.
+
+Signed-off-by: Robert Jones 
+Signed-off-by: Shawn Guo 
+---
+ arch/arm/boot/dts/imx6qdl-gw553x.dtsi | 31 +++
+ 1 file changed, 31 insertions(+)
+
+diff --git a/arch/arm/boot/dts/imx6qdl-gw553x.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw553x.dtsi
+index a106689..ee85031 100644
+--- a/arch/arm/boot/dts/imx6qdl-gw553x.dtsi
 b/arch/arm/boot/dts/imx6qdl-gw553x.dtsi
+@@ -173,6 +173,25 @@
+   pinctrl-0 = <_i2c2>;
+   status = "okay";
+ 
++  magn@1c {
++  compatible = "st,lsm9ds1-magn";
++  reg = <0x1c>;
++  pinctrl-names = "default";
++  pinctrl-0 = <_mag>;
++  interrupt-parent = <>;
++  interrupts = <2 IRQ_TYPE_EDGE_RISING>;
++  };
++
++  imu@6a {
++  compatible = "st,lsm9ds1-imu";
++  reg = <0x6a>;
++  st,drdy-int-pin = <1>;
++  pinctrl-names = "default";
++  pinctrl-0 = <_imu>;
++  interrupt-parent = <>;
++  interrupts = <13 IRQ_TYPE_LEVEL_HIGH>;
++  };
++
+   ltc3676: pmic@3c {
+   compatible = "lltc,ltc3676";
+   reg = <0x3c>;
+@@ -426,6 +445,12 @@
+   >;
+   };
+ 
++  pinctrl_imu: imugrp {
++  fsl,pins = <
++  MX6QDL_PAD_GPIO_18__GPIO7_IO13  0x1b0b0
++  >;
++  };
++
+   pinctrl_ipu1_csi0: ipu1csi0grp {
+   fsl,pins = <
+   MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA120x1b0b0
+@@ -449,6 +474,12 @@
+   >;
+   };
+ 
++  pinctrl_mag: maggrp {
++  fsl,pins = <
++  MX6QDL_PAD_GPIO_2__GPIO1_IO02   0x1b0b0
++  >;
++  };
++
+   pinctrl_pcie: pciegrp {
+   fsl,pins = <
+   MX6QDL_PAD_GPIO_0__GPIO1_IO00   0x1b0b0
+-- 
+2.7.4
+
-- 
2.7.4


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

[OpenWrt-Devel] Enquiries

2020-02-28 Thread chinazzcxzhuyunfu 
Dear Mr.

We are a large comprehensive industrial company in Henna, China. The company 
has hardware and electronic enterprises, import and export companies. 
Technology transfer, technical training. Overseas agent and other business.

According to the current demand of our national market, we urgently need to 
import a batch of disposable medical and N95 mask manufacturing machines. We 
learned from our import and export platform that you are a professional 
manufacturer of this machine. Send e - mail inquiries. If you can supply us 
with this product, please send us the information and price as soon as 
possible. If your price is acceptable to us. Let's discuss the details of the 
deal. Looking forward to your reply.

 

Best Regards！

 

The general manager：Zhu fulai

Henan Changxu Import & Export Trading Co., Ltd

Address: No. 22, Jinshui district Dongfeng Road, Zhengzhou City.(China).

Note: If you are not the manufacturer of this product, please delete our Email.











--

网易VIP邮箱提醒：安全收发邮件，务必核实往来邮件地址、银行账号等机密信息，请通过电话或视频等多种方式确认信息真实性，提高警惕，请勿轻易透露个人重要信息。
Alert message of Netease Vipmail：Never provide your password, security 
questions, verification codes, or any other personal important information 
details to anyone else.
You can identify mail message by telephone,video-chat or other ways.You should 
make sure that your email address, bank account and other confidential 
information as secure as possible. Thank you for keeping your email account 
secure.___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] RFT: Add support for kernel 5.4

2020-02-28 Thread mail 
Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Koen Vandeputte
> Sent: Freitag, 28. Februar 2020 17:54
> To: OpenWrt Development List 
> Subject: [OpenWrt-Devel] RFT: Add support for kernel 5.4
> 
> Hi All,
> 
> After a lot of hard work from many people involved, I'm very pleased to
> announce initial support for kernel 5.4 has been pushed to master with
> already a nice amount of available targets.
> 
> If you are interested, feel free to test, send fixes or send patches for
> supporting 5.4 on other targets besides the ones mentioned below.
> 
> All supported targets have been provided with kernel 5.4 as the "Testing
> kernel".
> This means you can enable 5.4 by selecting "Global --> use the testing kernel
> version" within menuconfig.

Thanks for your work.

By moving ag71xx to files-4.19 on ath79, I suspect 4.14 is broken now on this 
target.
So, we should either copy that to files-4.14 as well or remove the remaining 
4.14 files there as well (where I'd prefer the latter).

If I receive positive feedback on this, I'd prepare the patch myself.

Best

Adrian

> 
> 
> *Big fat warning*
> 
> While a ton of effort has been conducted, trying to prevent mayhem and
> fixing as many bugs as possible, support for 5.4 is still considered to be
> experimental at this point until extended testing has been conducted.
> 
> If you would like to try it, please make sure you are able to debrick your
> device if required.
> If you still try it without any way of debricking it, you are doing so *at 
> your
> own risk*
> 
> 
> Following targets are currently available and have been runtime tested:
> 
> - apm821xx
> - ath79
> - bcm53xx
> - imx6
> - ipq40xx
> - mediatek
> - mpc85xx
> - x86_64
> 
> Completely untested but provided as a baseline:
> 
> - ipq807x
> 
> 
> Following targets are near completion and should be added hopefully next
> week:
> 
> - cns3xxx
> - octeontx
> 
> 
> Kind Regards,
> 
> Koen
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/2] kernel: 5.4: backport fxos8700 accel support from 5.5

2020-02-28 Thread Tim Harvey 
Signed-off-by: Tim Harvey 
---
 ...-iio-imu-Add-support-for-the-FXOS8700-IMU.patch | 912 +
 1 file changed, 912 insertions(+)
 create mode 100644 
target/linux/generic/backport-5.4/800-v5.5-iio-imu-Add-support-for-the-FXOS8700-IMU.patch

diff --git 
a/target/linux/generic/backport-5.4/800-v5.5-iio-imu-Add-support-for-the-FXOS8700-IMU.patch
 
b/target/linux/generic/backport-5.4/800-v5.5-iio-imu-Add-support-for-the-FXOS8700-IMU.patch
new file mode 100644
index 000..59435e9
--- /dev/null
+++ 
b/target/linux/generic/backport-5.4/800-v5.5-iio-imu-Add-support-for-the-FXOS8700-IMU.patch
@@ -0,0 +1,912 @@
+From 84e5ddd5c46ea3bf0cad670da32028994cad5936 Mon Sep 17 00:00:00 2001
+From: Robert Jones 
+Date: Mon, 14 Oct 2019 11:49:21 -0700
+Subject: [PATCH] iio: imu: Add support for the FXOS8700 IMU
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+FXOS8700CQ is a small, low-power, 3-axis linear accelerometer and 3-axis
+magnetometer combined into a single package. The device features a
+selectable I2C or point-to-point SPI serial interface with 14-bit
+accelerometer and 16-bit magnetometer ADC resolution along with
+smart-embedded functions.
+
+FXOS8700CQ has dynamically selectable accelerationfull-scale ranges of
+±2 g/±4 g/±8 g and a fixed magnetic measurement range of ±1200 μT.
+Output data rates (ODR) from 1.563 Hz to 800 Hz are selectable by the user
+for each sensor. Interleaved magnetic and acceleration data is available
+at ODR rates of up to 400 Hz. FXOS8700CQ is available in a plastic QFN
+package and it is guaranteed to operate over the extended temperature
+range of –40 °C to +85 °C.
+
+TODO: Trigger and IRQ configuration support
+
+Datasheet:
+  http://cache.freescale.com/files/sensors/doc/data_sheet/FXOS8700CQ.pdf
+
+Signed-off-by: Robert Jones 
+Signed-off-by: Jonathan Cameron 
+---
+ drivers/iio/imu/Kconfig |  27 ++
+ drivers/iio/imu/Makefile|   5 +
+ drivers/iio/imu/fxos8700.h  |  10 +
+ drivers/iio/imu/fxos8700_core.c | 649 
+ drivers/iio/imu/fxos8700_i2c.c  |  71 +
+ drivers/iio/imu/fxos8700_spi.c  |  59 
+ 6 files changed, 821 insertions(+)
+ create mode 100644 drivers/iio/imu/fxos8700.h
+ create mode 100644 drivers/iio/imu/fxos8700_core.c
+ create mode 100644 drivers/iio/imu/fxos8700_i2c.c
+ create mode 100644 drivers/iio/imu/fxos8700_spi.c
+
+diff --git a/drivers/iio/imu/Kconfig b/drivers/iio/imu/Kconfig
+index f3c7282..60bb102 100644
+--- a/drivers/iio/imu/Kconfig
 b/drivers/iio/imu/Kconfig
+@@ -40,6 +40,33 @@ config ADIS16480
+ 
+ source "drivers/iio/imu/bmi160/Kconfig"
+ 
++config FXOS8700
++  tristate
++
++config FXOS8700_I2C
++  tristate "NXP FXOS8700 I2C driver"
++  depends on I2C
++  select FXOS8700
++  select REGMAP_I2C
++  help
++Say yes here to build support for the NXP FXOS8700 m+g combo
++sensor on I2C.
++
++This driver can also be built as a module. If so, the module will be
++called fxos8700_i2c.
++
++config FXOS8700_SPI
++  tristate "NXP FXOS8700 SPI driver"
++  depends on SPI
++  select FXOS8700
++  select REGMAP_SPI
++  help
++Say yes here to build support for the NXP FXOS8700 m+g combo
++sensor on SPI.
++
++This driver can also be built as a module. If so, the module will be
++called fxos8700_spi.
++
+ config KMX61
+   tristate "Kionix KMX61 6-axis accelerometer and magnetometer"
+   depends on I2C
+diff --git a/drivers/iio/imu/Makefile b/drivers/iio/imu/Makefile
+index 4a69588..5237fd4 100644
+--- a/drivers/iio/imu/Makefile
 b/drivers/iio/imu/Makefile
+@@ -14,6 +14,11 @@ adis_lib-$(CONFIG_IIO_ADIS_LIB_BUFFER) += adis_buffer.o
+ obj-$(CONFIG_IIO_ADIS_LIB) += adis_lib.o
+ 
+ obj-y += bmi160/
++
++obj-$(CONFIG_FXOS8700) += fxos8700_core.o
++obj-$(CONFIG_FXOS8700_I2C) += fxos8700_i2c.o
++obj-$(CONFIG_FXOS8700_SPI) += fxos8700_spi.o
++
+ obj-y += inv_mpu6050/
+ 
+ obj-$(CONFIG_KMX61) += kmx61.o
+diff --git a/drivers/iio/imu/fxos8700.h b/drivers/iio/imu/fxos8700.h
+new file mode 100644
+index ..6dfb8d7
+--- /dev/null
 b/drivers/iio/imu/fxos8700.h
+@@ -0,0 +1,10 @@
++/* SPDX-License-Identifier: GPL-2.0 */
++#ifndef FXOS8700_H_
++#define FXOS8700_H_
++
++extern const struct regmap_config fxos8700_regmap_config;
++
++int fxos8700_core_probe(struct device *dev, struct regmap *regmap,
++  const char *name, bool use_spi);
++
++#endif  /* FXOS8700_H_ */
+diff --git a/drivers/iio/imu/fxos8700_core.c b/drivers/iio/imu/fxos8700_core.c
+new file mode 100644
+index ..7b47be4
+--- /dev/null
 b/drivers/iio/imu/fxos8700_core.c
+@@ -0,0 +1,649 @@
++// SPDX-License-Identifier: GPL-2.0
++/*
++ * FXOS8700 - NXP IMU (accelerometer plus magnetometer)
++ *
++ * IIO core driver for FXOS8700, with support for I2C/SPI busses
++ *
++ * TODO: Buffer, trigger, and IRQ support
++ */
++#include 
++#include

[OpenWrt-Devel] [PATCH 2/2] kernel: iio: add fxos8700 driver support

2020-02-28 Thread Tim Harvey 
Signed-off-by: Tim Harvey 
---
 package/kernel/linux/modules/iio.mk | 50 +
 1 file changed, 50 insertions(+)

diff --git a/package/kernel/linux/modules/iio.mk 
b/package/kernel/linux/modules/iio.mk
index cd46697..558abf4 100644
--- a/package/kernel/linux/modules/iio.mk
+++ b/package/kernel/linux/modules/iio.mk
@@ -294,3 +294,53 @@ define KernelPackage/iio-tsl4531/description
 endef
 
 $(eval $(call KernelPackage,iio-tsl4531))
+
+
+define KernelPackage/iio-fxos8700
+  SUBMENU:=$(IIO_MENU)
+  TITLE:=Freescale FXOS8700 3-axis accelerometer driver
+  DEPENDS:=+kmod-iio-core +kmod-regmap-core
+  KCONFIG:= CONFIG_FXOS8700
+  FILES:=$(LINUX_DIR)/drivers/iio/imu/fxos8700_core.ko
+  AUTOLOAD:=$(call AutoLoad,56,fxos8700)
+endef
+
+define KernelPackage/iio-fxos8700/description
+ Support for Freescale FXOS8700 3-axis accelerometer.
+endef
+
+$(eval $(call KernelPackage,iio-fxos8700))
+
+
+define KernelPackage/iio-fxos8700-i2c
+  SUBMENU:=$(IIO_MENU)
+  TITLE:=Freescale FXOS8700 3-axis acceleromter driver (I2C)
+  DEPENDS:=+kmod-iio-fxos8700 +kmod-i2c-core +kmod-regmap-i2c
+  KCONFIG:= CONFIG_FXOS8700_I2C
+  FILES:=$(LINUX_DIR)/drivers/iio/imu/fxos8700_i2c.ko
+  AUTOLOAD:=$(call AutoLoad,56,fxos8700_i2c)
+endef
+
+define KernelPackage/iio-fxos8700-i2c/description
+ Support for Freescale FXOS8700 3-axis accelerometer
+ connected via I2C.
+endef
+
+
+$(eval $(call KernelPackage,iio-fxos8700-i2c))
+
+define KernelPackage/iio-fxos8700-spi
+  SUBMENU:=$(IIO_MENU)
+  DEPENDS:=+kmod-iio-fxos8700 +kmod-regmap-spi
+  TITLE:=Freescale FXOS8700 3-axis accelerometer driver (SPI)
+  KCONFIG:= CONFIG_FXOS8700_SPI
+  FILES:=$(LINUX_DIR)/drivers/iio/imu/fxos8700_spi.ko
+  AUTOLOAD:=$(call AutoLoad,56,fxos8700_spi)
+endef
+
+define KernelPackage/iio-fxos8700-spi/description
+ Support for Freescale FXOS8700 3-axis accelerometer
+ connected via SPI.
+endef
+
+$(eval $(call KernelPackage,iio-fxos8700-spi))
-- 
2.7.4


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

Re: [OpenWrt-Devel] RFT: Add support for kernel 5.4

2020-02-28 Thread Koen Vandeputte 



On 28.02.20 18:22, Ansuel Smith wrote:


Hi All,

After a lot of hard work from many people involved, I'm very
pleased to
announce
initial support for kernel 5.4 has been pushed to master with
already a
nice amount
of available targets.

If you are interested, feel free to test, send fixes or send
patches for
supporting 5.4 on other targets besides the ones mentioned below.

All supported targets have been provided with kernel 5.4 as the
"Testing
kernel".
This means you can enable 5.4 by selecting "Global --> use the
testing
kernel version" within menuconfig.


*Big fat warning*

While a ton of effort has been conducted, trying to prevent mayhem
and
fixing as many bugs as possible,
support for 5.4 is still considered to be experimental at this point
until extended testing has been conducted.

If you would like to try it, please make sure you are able to debrick
your device if required.
If you still try it without any way of debricking it, you are
doing so
*at your own risk*


Following targets are currently available and have been runtime
tested:

- apm821xx
- ath79
- bcm53xx
- imx6
- ipq40xx
- mediatek
- mpc85xx
- x86_64

Completely untested but provided as a baseline:

- ipq807x


Following targets are near completion and should be added
hopefully next
week:

- cns3xxx
- octeontx


Kind Regards,

Koen


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org

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


Ipq806x is pretty much done and I think can be pushed as a testing 
kernel, should I create a PR on GitHub?



Yes please.


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

Re: [OpenWrt-Devel] RFT: Add support for kernel 5.4

2020-02-28 Thread Ansuel Smith 
> Hi All,
>
> After a lot of hard work from many people involved, I'm very pleased to
> announce
> initial support for kernel 5.4 has been pushed to master with already a
> nice amount
> of available targets.
>
> If you are interested, feel free to test, send fixes or send patches for
> supporting 5.4 on other targets besides the ones mentioned below.
>
> All supported targets have been provided with kernel 5.4 as the "Testing
> kernel".
> This means you can enable 5.4 by selecting "Global --> use the testing
> kernel version" within menuconfig.
>
>
> *Big fat warning*
>
> While a ton of effort has been conducted, trying to prevent mayhem and
> fixing as many bugs as possible,
> support for 5.4 is still considered to be experimental at this point
> until extended testing has been conducted.
>
> If you would like to try it, please make sure you are able to debrick
> your device if required.
> If you still try it without any way of debricking it, you are doing so
> *at your own risk*
>
>
> Following targets are currently available and have been runtime tested:
>
> - apm821xx
> - ath79
> - bcm53xx
> - imx6
> - ipq40xx
> - mediatek
> - mpc85xx
> - x86_64
>
> Completely untested but provided as a baseline:
>
> - ipq807x
>
>
> Following targets are near completion and should be added hopefully next
> week:
>
> - cns3xxx
> - octeontx
>
>
> Kind Regards,
>
> Koen
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Ipq806x is pretty much done and I think can be pushed as a testing kernel,
should I create a PR on GitHub?

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

[OpenWrt-Devel] [PATCH] kernel: can: add MCP251x CAN controller module support

2020-02-28 Thread Tim Harvey 
Signed-off-by: Tim Harvey 
---
 package/kernel/linux/modules/can.mk | 17 +
 1 file changed, 17 insertions(+)

diff --git a/package/kernel/linux/modules/can.mk 
b/package/kernel/linux/modules/can.mk
index c2c7411..3bf0359 100644
--- a/package/kernel/linux/modules/can.mk
+++ b/package/kernel/linux/modules/can.mk
@@ -146,6 +146,23 @@ endef
 $(eval $(call KernelPackage,can-gw))
 
 
+define KernelPackage/can-mcp251x
+  TITLE:=MCP251x SPI CAN controller
+  KCONFIG:=\
+   CONFIG_SPI=y \
+   CONFIG_CAN_MCP251X
+  FILES:=$(LINUX_DIR)/drivers/net/can/spi/mcp251x.ko
+  AUTOLOAD:=$(call AutoProbe,can-mcp251x)
+  $(call AddDepends/can)
+endef
+
+define KernelPackage/can-mcp251x/description
+ Microchip MCP251x SPI CAN controller
+endef
+
+$(eval $(call KernelPackage,can-mcp251x))
+
+
 define KernelPackage/can-raw
   TITLE:=Raw CAN Protcol
   KCONFIG:=CONFIG_CAN_RAW
-- 
2.7.4


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

[OpenWrt-Devel] [PATCH] kernel: iio: add st-accel driver modules

2020-02-28 Thread Tim Harvey 
Signed-off-by: Tim Harvey 
---
 package/kernel/linux/modules/iio.mk | 54 +
 1 file changed, 54 insertions(+)

diff --git a/package/kernel/linux/modules/iio.mk 
b/package/kernel/linux/modules/iio.mk
index cd46697..aaccbde 100644
--- a/package/kernel/linux/modules/iio.mk
+++ b/package/kernel/linux/modules/iio.mk
@@ -278,6 +278,60 @@ endef
 $(eval $(call KernelPackage,iio-si7020))
 
 
+define KernelPackage/iio-st_accel
+  SUBMENU:=$(IIO_MENU)
+  TITLE:=STMicroelectronics accelerometer 3-Axis Driver
+  DEPENDS:=+kmod-iio-core
+  KCONFIG:= \
+   CONFIG_IIO_ST_ACCEL_3AXIS \
+   CONFIG_IIO_ST_SENSORS_CORE
+  FILES:= \
+   $(LINUX_DIR)/drivers/iio/accel/st_accel.ko \
+   $(LINUX_DIR)/drivers/iio/common/st_sensors/st_sensors.ko
+endef
+
+define KernelPackage/iio-st_accel/description
+ This package adds support for STMicroelectronics accelerometers:
+  LSM303DLH, LSM303DLHC, LIS3DH, LSM330D, LSM330DL, LSM330DLC,
+  LIS331DLH, LSM303DL, LSM303DLM, LSM330, LIS2DH12, H3LIS331DL,
+  LNG2DM, LIS3DE, LIS2DE12
+endef
+
+$(eval $(call KernelPackage,iio-st_accel))
+
+
+define KernelPackage/iio-st_sensors-i2c
+  SUBMENU:=$(IIO_MENU)
+  TITLE:=STMicroelectronics accelerometer 3-Axis Driver (I2C)
+  DEPENDS:=+kmod-iio-st_accel +kmod-i2c-core
+  KCONFIG:= CONFIG_IIO_ST_ACCEL_I2C_3AXIS
+  FILES:=$(LINUX_DIR)/drivers/iio/common/st_sensors/st_sensors_i2c.ko
+  AUTOLOAD:=$(call AutoLoad,56,st_sensors_i2c)
+endef
+
+define KernelPackage/iio-st_sensors-i2c/description
+ This package adds support for STMicroelectronics I2C based accelerometers
+endef
+
+$(eval $(call KernelPackage,iio-st_sensors-i2c))
+
+
+define KernelPackage/iio-st_sensors-spi
+  SUBMENU:=$(IIO_MENU)
+  TITLE:=STMicroelectronics accelerometer 3-Axis Driver (SPI)
+  DEPENDS:=+kmod-iio-st_accel
+  KCONFIG:= CONFIG_IIO_ST_ACCEL_SPI_3AXIS
+  FILES:=$(LINUX_DIR)/drivers/iio/common/st_sensors/st_sensors_spi.ko
+  AUTOLOAD:=$(call AutoLoad,56,st_sensors_spi)
+endef
+
+define KernelPackage/iio-st_sensors-spi/description
+ This package adds support for STMicroelectronics SPI based accelerometers
+endef
+
+$(eval $(call KernelPackage,iio-st_sensors-spi))
+
+
 define KernelPackage/iio-tsl4531
   SUBMENU:=$(IIO_MENU)
   DEPENDS:=+kmod-i2c-core +kmod-iio-core
-- 
2.7.4


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

[OpenWrt-Devel] RFT: Add support for kernel 5.4

2020-02-28 Thread Koen Vandeputte 

Hi All,

After a lot of hard work from many people involved, I'm very pleased to 
announce
initial support for kernel 5.4 has been pushed to master with already a 
nice amount

of available targets.

If you are interested, feel free to test, send fixes or send patches for 
supporting 5.4 on other targets besides the ones mentioned below.


All supported targets have been provided with kernel 5.4 as the "Testing 
kernel".
This means you can enable 5.4 by selecting "Global --> use the testing 
kernel version" within menuconfig.



*Big fat warning*

While a ton of effort has been conducted, trying to prevent mayhem and 
fixing as many bugs as possible,
support for 5.4 is still considered to be experimental at this point 
until extended testing has been conducted.


If you would like to try it, please make sure you are able to debrick 
your device if required.
If you still try it without any way of debricking it, you are doing so 
*at your own risk*



Following targets are currently available and have been runtime tested:

- apm821xx
- ath79
- bcm53xx
- imx6
- ipq40xx
- mediatek
- mpc85xx
- x86_64

Completely untested but provided as a baseline:

- ipq807x


Following targets are near completion and should be added hopefully next 
week:


- cns3xxx
- octeontx


Kind Regards,

Koen


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

Re: [OpenWrt-Devel] [PATCH 2/2] ramips: fix and tidy up DTS for D-Link DIR-810L

2020-02-28 Thread Roger Pueyo Centelles | Guifi.net 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 ---
Hi Adrian,

I tested the patches on the device. I sysupgraded from the current
master and everything seems OK.

- Partitions

root@OpenWrt:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 0003 1000 "u-boot"
mtd1: 0001 1000 "u-boot-env"
mtd2: 0001 1000 "factory"
mtd3: 0001 1000 "factory5g"
mtd4: 0001 1000 "Wolf_Config"
mtd5: 0008 1000 "MyDlink"
mtd6: 0008 1000 "Jffs2"
mtd7: 0069 1000 "firmware"
mtd8: 00198a90 1000 "kernel"
mtd9: 004f7570 1000 "rootfs"
mtd10: 001d4000 1000 "rootfs_data"

- Button codes OK both

- No missing functionalities

I noticed, however, that the green "Internet" LED blinks to the LAN4
port, while -I guess- it should blink to the INTERNET (wan/eth0.2) port.
But this was already happening before, it's not related to your patch.

Roger

El 27/2/20 a les 14:46, Adrian Schmutzler ha escrit:
> This patch addresses several issues for D-Link DIR-810L:
>
> - add correct button codes
> - harmonize button node names
> - use generic flash@0
> - remove unused pin groups from state_default
> - improve sorting of properties
>
> The patch is only build-tested.
>
> Signed-off-by: Adrian Schmutzler 
>
> ---
>
> If somebody owns this device, I'd be delighted about a test of both patches
> in general as well as if somebody would test if higher SPI frequency is
> possible.
>
> ---
>  .../ramips/dts/mt7620a_dlink_dir-810l.dts  | 18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/target/linux/ramips/dts/mt7620a_dlink_dir-810l.dts 
> b/target/linux/ramips/dts/mt7620a_dlink_dir-810l.dts
> index 0b1ca26ba4..514e9cc354 100644
> --- a/target/linux/ramips/dts/mt7620a_dlink_dir-810l.dts
> +++ b/target/linux/ramips/dts/mt7620a_dlink_dir-810l.dts
> @@ -23,20 +23,20 @@
>   reset {
>   label = "reset";
>   gpios = < 1 GPIO_ACTIVE_LOW>;
> - linux,code = ;
> + linux,code = ;
>   };
>  
>   wps {
>   label = "wps";
>   gpios = < 2 GPIO_ACTIVE_LOW>;
> - linux,code = ;
> + linux,code = ;
>   };
>   };
>  
>   leds {
>   compatible = "gpio-leds";
>  
> - led_power_green: power {
> + led_power_green: power_green {
>   label = "dir-810l:green:power";
>   gpios = < 9 GPIO_ACTIVE_HIGH>;
>   };
> @@ -46,7 +46,7 @@
>   gpios = < 12 GPIO_ACTIVE_HIGH>;
>   };
>  
> - power2 {
> + power_orange {
>   label = "dir-810l:orange:power";
>   gpios = < 13 GPIO_ACTIVE_HIGH>;
>   };
> @@ -56,7 +56,7 @@
>   {
>   status = "okay";
>  
> - m25p80@0 {
> + flash@0 {
>   compatible = "jedec,spi-nor";
>   reg = <0>;
>   spi-max-frequency = <1000>;
> @@ -119,7 +119,7 @@
>  
>  _default {
>   gpio {
> - ralink,group = "mdio", "rgmii1", "i2c", "wled", "uartf";
> + ralink,group = "i2c", "uartf";
>   ralink,function = "gpio";
>   };
>  };
> @@ -130,9 +130,10 @@
>  };
>  
>   {
> - mediatek,port4 = "ephy";
>   pinctrl-names = "default";
>   pinctrl-0 = <_pins>;
> +
> + mediatek,port4 = "ephy";
>  };
>  
>   {
> @@ -140,9 +141,10 @@
>  };
>  
>   {
> - ralink,mtd-eeprom = < 0x0>;
>   pinctrl-names = "default";
>   pinctrl-0 = <_pins>;
> +
> + ralink,mtd-eeprom = < 0x0>;
>   mtd-mac-address = < 0x28>;
>  };
>  


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

Re: [OpenWrt-Devel] [PATCHv2 1/3] tools/pkg-config: Replace with pkgconf

2020-02-28 Thread Petr Štetiar 
Rosen Penev  [2019-12-25 12:51:33]:

> On Wed, Dec 25, 2019 at 3:17 AM Petr Štetiar  wrote:
> >
> > Rosen Penev  [2019-11-28 11:19:31]:
> >
> > > pkgconf is a newer, actively maintained implementation of pkg-config
> >
> > I'm wondering if that `actively maintained` part still holds true.
>
> It does. The team has management issues it seems. They've publicly
> stated they want to move away from GitHub:
> https://github.com/pkgconf/pkgconf.github.io/issues/1
> 
> So you would think based on the URL of the download that development
> moved here: https://git.dereferenced.org/pkgconf/pkgconf#
> 
> But there's also a third place where development seems to have moved:
> https://git.sr.ht/~kaniini/pkgconf/log
> 
> Seems it's a mess.

So how to sort this out?

I'm simply in favor of keeping the current pkg-config, because the suggested
replacement doesn't seem like a worth considering yet, but maybe I read it
wrong.

-- ynezz

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

Re: [OpenWrt-Devel] [PATCH v2] ramips: add TRENDnet TEW-810DR support

2020-02-28 Thread Heppler, J. Scott 

On Feb 27, 2020: 14:44, Adrian Schmutzler wrote:

-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
Behalf Of Heppler, J. Scott
Sent: Donnerstag, 27. Februar 2020 14:29
To: openwrt-de...@openwrt.org
Subject: Re: [OpenWrt-Devel] [PATCH v2] ramips: add TRENDnet TEW-810DR
support

On Feb 27, 2020: 13:37, Adrian Schmutzler wrote:
>Hi,
>
>> -Original Message-
>> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
>> Behalf Of Heppler, J. Scott
>> Sent: Donnerstag, 27. Februar 2020 03:39
>> To: openwrt-de...@openwrt.org
>> Subject: [OpenWrt-Devel] [PATCH v2] ramips: add TRENDnet TEW-810DR
support
>>
>> Signed-off-by: J. Scott Heppler 
>>
>> ramips: add support for TRENDnet TEW-810DR
>>
>> Exact hardware clone for the D-Link DIR-810L.  See OpenWRT device pages
>> and review the PCB photos, boot logs and MTP flash partitions.
>> https://openwrt.org/toh/trendnet/trendnet_tew-810dr_1.0_1.1
>> https://openwrt.org/toh/d-link/dir-810l
>>
>> Specification:
>>
>> * MediaTek MT7620A (580 Mhz)
>> * 8 MB of FLASH
>> * 64 MB of RAM
>> * 5x 10/100 Mbps Ethernet (1 WAN and 4 LAN)
>> * UART header on PCB (57600 8n1)
>> * 2x BiColor LED (GPIO-controlled)
>> * 2x button - power and reset
>> * U-boot bootloader
>>
>> Installation:
>>
>> The sysupgrade.bin image needs to have a cameo hardware ID appended
>> with ncc_att_hwid.  ncc_att_hwid is available in the GPL Source
>> download for either the TEW-810DR or DIR-810L and is located at
>> source/user/wolf/cameo/ncc/hostTools
>> The invocation is:
>> ncc_att_hwid -f tew-810-squashfs-factory.bin -a -m “TEW-810DR”
>> -H “1.0R” -r “WW” -c “1.0”
>> More information is available in the device page for TEW-810DR linked
>> above The appended image can then be flash via the Web rescue interface
>> 192.168.10.1 or TFTP's to the same IP address.  Subsequent upgrades
>> can be done using the Luci web interface or the ssh command line per the
>> OpenWRT documentation
>> ---
>>  .../ramips/dts/mt7620a_trendnet_tew-810dr.dts | 157
++
>>  target/linux/ramips/image/mt7620.mk   |  10 ++
>>  .../mt7620/base-files/etc/board.d/02_network  |   3 +-
>>  3 files changed, 169 insertions(+), 1 deletion(-)
>>  create mode 100644 target/linux/ramips/dts/mt7620a_trendnet_tew-
810dr.dts
>>
>> diff --git a/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
>> b/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
>> new file mode 100644
>> index 00..eb38110801
>> --- /dev/null
>> +++ b/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
>
>shared DTSI with dir-810l ?


Device Tree Usage in OpenWRT (DTS) does not really go into this.  Can
you give me some guidance?  What naming conventions would be used for
the new dtsi?  Can a dts include 2 dtsi's?  Is it OK to chain 2 dtsi's?


I'm worried about altering the DIR-810L code.  I do not have the D-Link
to test and it was submitted by someone else.


I will send a some patches for the DIR-810L in a minute. Those should make it 
easier to move a lot of code into a shared DTSI. Obviously, stuff that still 
deviates would be kept in the DTSes.


>
>> @@ -0,0 +1,157 @@
>> +/dts-v1/;
>> +
>> +#include "mt7620a.dtsi"
>> +
>> +#include 
>> +#include 
>> +
>> +/ {
>> +  compatible = "trendnet,tew-810dr", "ralink,mt7620a-soc";
>> +  model = "TRENDnet TEW-810DR";
>> +
>> +  aliases {
>> +  led-boot = _power_green;
>> +  led-failsafe = _power_green;
>> +  led-running = _power_green;
>> +  led-upgrade = _power_green;
>> +  label-mac-device = 
>> +  };
>> +
>> +  keys {
>> +  compatible = "gpio-keys";
>> +
>> +  reset {
>> +  label = "reset";
>> +  gpios = < 1 GPIO_ACTIVE_LOW>;
>> +  linux,code = ;
>> +  };
>> +
>> +  wps {
>> +  label = "wps";
>> +  gpios = < 2 GPIO_ACTIVE_LOW>;
>> +  linux,code = ;
>
>Why not use the proper codes on these?  Would the code also need to be
>altered on the DIR-810L?  Can you point me to reference?


See my patch for DIR-810L coming in a minute.

Essentially duplicated your 2 patches.



>
>> +  };
>> +  };
>> +
>> +  leds {
>> +  compatible = "gpio-leds";
>> +
>> +  led_power_green: power {
>
>led_power_green: power_green {
>
>> +  label = "dir-810l:green:power";
>
>That would be one of the few parts where both devices will be different (and
which would not belong into a shared DTSI). But if you didn't even change the
name, have you actually checked whether the LED GPIOs are the same?
The Trendnet also has 2 pairs of green/orange LEDs


So, what's the second green LED then?

One my TEW-732BR, it flashes with in/out packets to br-lan , glows
steady at rest.



>
>> +  gpios = < 9 GPIO_ACTIVE_HIGH>;
>> +