Re: [OpenWrt-Devel] [PATCH 2/2] ath79: GL.iNet AR300M family: Correct DTS LED definitions

[Szabolcs Hubai]

Jeff Kletsky  ezt írta (időpont: 2019. febr. 6., Sze, 2:25):
>
>
> On 2/5/19 4:19 PM, Szabolcs Hubai wrote:
> > Hi Jeff,
> >
> > sorry for being late in the topic, but that [1] red "status" LED is
> > GL-AR300M-Lite specific, and isn't suitable for the original GL-AR300M
> > model, IMHO.
> >
> >
> > Here are my points:
> >
> > I opened my GL-AR300MD's case (a limited, dualband model), and it has
> > a "GL-AR300M-V1.3.1" print on it's PCB.
> > It has the exactly same pinouts as it could be seen on the
> > documentation page [2] (picture attached) and it's WLAN LED is red,
> > the other two, LAN and SYS (in DTS: "status") are green.
> >
> > I'm unsure how are the LED colors in the other GL-AR300M sub-models.
> >
> I checked the GL.iNet site and the video of the GL-AR300M at
> 
> published in January, 2017, shows two green and a red LED,
> consistent with your description.
>
> On the other hand, GL.iNet's source shows them as all "green"
> (as is the AR300M-Lite I have in hand)
>
> 
>
> I'm fine with leaving the color alone or being consistent with current
> production
> and the OEM's definitions. Shoot, my Archer C7 v2 has "blue" LEDs under
> OpenWrt.
> Too bad that doesn't actually change the color of them ;)
>
> The GPIO assignments are still in need of correction, as far as I can
> tell, for all variants.
>
>
> Jeff
>
>

My GL-AR300MD is pretty old, I bought it when that debrick video was created. :)

It would be nice, that you could introduce the Lite support with red
"status" LED color.
And the GL-AR300M model "status" LED should have at least a comment
about this inconsistency to avoid the "fixes" to change it back and
forth.
It is also possible that the newly produced versions of GL-AR300M (not
just the -Lite edition) has the new colors.


Yup, the GPIO change was correct.



Szabolcs

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

Re: [OpenWrt-Devel] [PATCH 2/2] ath79: GL.iNet AR300M family: Correct DTS LED definitions

[Jeff Kletsky]

On 2/5/19 4:19 PM, Szabolcs Hubai wrote:

Hi Jeff,

sorry for being late in the topic, but that [1] red "status" LED is
GL-AR300M-Lite specific, and isn't suitable for the original GL-AR300M
model, IMHO.


Here are my points:

I opened my GL-AR300MD's case (a limited, dualband model), and it has
a "GL-AR300M-V1.3.1" print on it's PCB.
It has the exactly same pinouts as it could be seen on the
documentation page [2] (picture attached) and it's WLAN LED is red,
the other two, LAN and SYS (in DTS: "status") are green.

I'm unsure how are the LED colors in the other GL-AR300M sub-models.


I checked the GL.iNet site and the video of the GL-AR300M at

published in January, 2017, shows two green and a red LED,
consistent with your description.

On the other hand, GL.iNet's source shows them as all "green"
(as is the AR300M-Lite I have in hand)



I'm fine with leaving the color alone or being consistent with current 
production
and the OEM's definitions. Shoot, my Archer C7 v2 has "blue" LEDs under 
OpenWrt.

Too bad that doesn't actually change the color of them ;)

The GPIO assignments are still in need of correction, as far as I can 
tell, for all variants.



Jeff



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

Re: [OpenWrt-Devel] [PATCH] usbgadget: Add new package

[Michael Heimpold]

Hi,

Am Dienstag, 5. Februar 2019, 18:39:55 CET schrieb Petr Štetiar:
> Michael Heimpold  [2019-02-02 10:09:40]:
> 
> Hi,
> 
> > I would prefer to have "config gadget " to configure one
> > (multi-function) gadget and then have individual "config function <...>"
> > section to configure one function for a referenced gadget.  I think the
> > functions are orthogonal and thus "acm+rndis" looks like wrong approach
> > for
> > me.
> 
> I'm not sure I follow, please can you provide example configs? Thanks.

I hope the following will illustrate my idea (it should just show the idea,
no deeper sense):
I assume a CPU with two USB device ports, e.g. ci_hdrc.0 and ci_hdrc.1.
On ci_hdrc.0 a gadget with serial console and network is configured, on
ci_hdrc.1 a CD-ROM and a camera.

config gadget gadget1
option manufacturer 'OpenWrt'
option product 'OpenWrt USB CDC/ACM'
option serial_number '007'
option usb_vid '0xbeef'
option usb_pid '0x1234'
option udc_dev 'ci_hdrc.0'
option disabled 0

config configuration config1
option gadget gadget1
option maxpower 120

config function console1
option gadget gadget1
option type 'acm'
option disabled 0

config function network1
option gadget gadget1  
option type 'rndis'
option host_addr 00:01:02:04:05:06
option dev_addr 00:01:02:04:05:07
option disabled 0

config gadget gadget2
option manufacturer 'OpenWrt'
option product 'OpenWrt USB CDC/ACM'
option serial_number '007'
option usb_vid '0xbeef'
option usb_pid '0x1235'
option udc_dev 'ci_hdrc.1'
option disabled 0

config function msd
option gadget gadget2
option type 'mass_storage'
option file '/path/to/backing/file'
option removable 1
option cdrom 1
option disabled 0

config function network
option gadget gadget2
option type 'uvc'
option disabled 1

Cheers,
mhei




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

Re: [OpenWrt-Devel] [PATCH] treewide: dts: Unify naming of gpio-keys nodes

[Christian Lamparter]

Hello,

I've just pushed the remaining patches. Except for lantiq.
But these are moving along in Mathias Kresin' staging tree:


Thanks,
Christian



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

Re: [OpenWrt-Devel] ath79: ar71xx: Upgrade: tl-wr842n-v1 has Wrong BOARDNAME in ar71xx Builds

[Petr Štetiar]

Adding Marcin to Cc loop.

Jeff Kletsky  [2019-02-01 11:33:46]:

> As a result, users upgrading that device to ath79 will not have a seamless
> experience, requiring manual intervention.

Yes, it's a known deficiency, I'm not sure how to handle it properly at this
point of time. Maybe we should provide some additional checks in sysupgrade on
ar71xx just for those devices?

> I'm hesitant to suggest that the TL-MR3420 be added to SUPPORTED_DEVICES for
> tl-wr842n-v2 under ath79, as I believe the MR3420 is a 4/32 device and the
> WR842N v1 is a 8/32 device. Some idiot uninformed user
> might suggest that TL-MR3420 users try to flash the 8 MB image.

Well I've suggested it as well, but it wasn't considered safe[1].

1. https://github.com/openwrt/openwrt/pull/1625

-- ynezz

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

Re: [OpenWrt-Devel] [PATCH] usbgadget: Add new package

[Petr Štetiar]

Michael Heimpold  [2019-02-02 10:09:40]:

Hi,

> I would prefer to have "config gadget " to configure one
> (multi-function) gadget and then have individual "config function <...>"
> section to configure one function for a referenced gadget.  I think the
> functions are orthogonal and thus "acm+rndis" looks like wrong approach for
> me.

I'm not sure I follow, please can you provide example configs? Thanks.

-- ynezz

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

[OpenWrt-Devel] buildbots: offer zsync support for snapshots

[Paul Spooren]

Hi,

tl;dr: please run zsyncmake[0] on created snapshot SDK and IB archives

I'm offering a web service to download custom firmware images via an
API[1], this includes snapshot images. To stay up to date, all snapshot
ImageBuilders are daily re-downloaded. While being convenient for some
developers, this introduces quite some traffic. Would it be possible to
offer a .zsync file to allow delta downloads?

The command would be something like

    zsyncmake openwrt-imagebuilder*
    zsyncmake openwrt-sdk*

Paul

/mnt/worker/updater/imagebuilder/openwrt/snapshots# du -sh
14G .

[0]: https://linux.die.net/man/1/zsyncmake
[1]: https://chef.libremesh.org/


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