On Monday 18 February 2013 04:30:14 Chirag Chhatriwala wrote:
Tijs:
Are you using your settings on vlan0ports & vlan1ports
OR
vlan1ports & vlan2ports
I had a glance at vlanports assignment in OpenWRT, Tomato and DD-WRT and I
found that openwrt uses vlan[01]ports (according to the patchfile provided by
Hauke https://dev.openwrt.org/changeset/35597)
Tomato and DD-WRT use vlan[12]ports for port assignments.
All this is armchair programming as I have yet to receive my UART module and
cable to work with the E4200. However, I do want to get to the bottom of this
issue given that I want to understand the openwrt assignment using
vlan[01]ports and not vlan[12]ports (unlike Tomato & DD-WRT).
I apologize if I'm cross referencing the two alternatives to OpenWRT but thats
the only info I can go on so far.
Thanks,
Chirag
On Mon, Feb 18, 2013 at 3:12 AM, Tijs Van Buggenhout <t...@able.be> wrote:
On Thursday 14 February 2013 18:35:48 Chirag Chhatriwala wrote:
Hi All,
I'm trying to get additional info.
Hauke: per your latest response indicating the
changeset: https://dev.openwrt.org/changeset/35597
This will not work for E4200v1.
I just dug a few things from the tomato source tree.
Line 36: http://repo.or.cz/w/tomato.git/blob/tomato-
RT:/release/src/router/shared/id.c
Shows much of the E4200 v1 board related identification
Also: http://repo.or.cz/w/tomato.git/blob/tomato-
RT:/release/src/router/rc/init.c
shows vlan[01]ports initializations settings, which do not match the patch you
mention.
I am not sure what else is needed to make sure the proper initializations are
in place for the switch to come up. Wifi (according to broadcom-wl) should
just work. However, I'm worried more about the switch.
Thanks,
Chirag
On Thu, Feb 14, 2013 at 7:41 AM, Hauke Mehrtens <ha...@hauke-m.de> wrote:
On 02/14/2013 07:30 AM, Nathan Hintz wrote:
> On Wed, 2013-02-13 at 19:03 -0800, Nathan Hintz wrote:
>> On Wed, 2013-02-13 at 22:46 +0100, Hauke Mehrtens wrote:
>>> On 02/13/2013 10:33 PM, Chirag Chhatriwala wrote:
>>>> Hi All,
>>>>
>>>> I've notcied a huge deal of progress with bgmac in the recent month and
>>>> was willing to help bring support for the E4200v1. I own one of these
>>>> devices but I'm not too familiar with the entire driver process. Also, I
>>>> haven't flashed anything via serial/uart or JTAG as I'm simply familiar
>>>> with flashing via tftp method.
>>>>
>>>> I've reached out to Rafal and Nathan for advice as well.
>>>>
>>>> Firstly, I wanted to know if there is anyone who owns one of these and
>>>> can help with enabling OpenWrt support. I can certainly help in any way
>>>> I can. I'm sure there are several folks out there who own one of these
>>>> and I could mean a lot to revive their E4200v1 with OpenWrt support.
>>>>
>>>> I simply wish I had another one of these to donate to the OpenWrt devs
>>>> for the cause.
>>>>
>>>> Thanks,
>>>> Chirag
>>>>
>>> Hi Chirag,
>>>
>>> Your device should work, at least Ethernet wifi probably not. When you
>>> have a serial console connected to your device just flash OpenWrt or
>>> boot it from the network and report your results.
>>>
>>> Hauke
>>> _______________________________________________
>>> openwrt-devel mailing list
>>> openwrt-devel@lists.openwrt.org
>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>>
>> Will the ethernet work if the device is not recognized
>> by /etc/init.d/netconfig? It sounded like it had a different nvram
>> value for "boardtype"?
>>
>> I've never booted my E3000 from the network, and tftp only works for me
>> from a serial console using "upgrade code.bin" (I think my CFE is
>> possibly broken). What command do you use when you boot from the
>> network; and do you need a factory ".bin" image, or does the generic
>> ".trx" work for this?
>>
>> Thanks,
>>
>> Nathan
>
> Hi Hauke:
>
> I saw that /etc/init.d/netconfig has additional "boardtype" values
> added. Is the E4200v1 one of those added? Chirag didn't have an nvram
> dump, but he had a reference to a tomato issue that indicated it might
> be "0xF52C". Also, a patch had been added to the set maintained at
> http://www.znau.edu.ua/temp/asus-rt-n16/2012-12-08T15-25/003-openwrt4716-
TARGET_brcm4716-Linksys-E2000.patch
> that indicated the E2000 has a "boardtype" of "0x04EF"; although the
> same tomato reference has that one in lower case for WRT320N/E2000.
This list would have never been complete so now it is checked where the
CPU port is and if it is port 8, this port is used instead of port 5 in
the default switch configuration, see [0].
Hauke
[0]: https://dev.openwrt.org/changeset/35597
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
437 case MODEL_E4200:
438 dirty |= check_nv("vlan1ports", "0 1 2 3 8*");
439 dirty |= check_nv("vlan2ports", "4 8");
I've been using the same settings for the e3200 (port 4 is wan/internet port).
Regards,
Tijs
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Hi Chirag,
I may only hope that a certain vlan number for either LAN/WAN doesn't keep the
switch/ethernet driver from working properly. Normally I configure vlan 0 for
LAN, and vlan 1 for WAN, as openwrt has always done, but have also tried with
vlan 1 and 2. I managed this by calling robocfg directly (not using nvram
variables). For example:
$ robocfg switch disable vlans enable reset vlan 0 ports "0 1 2 3 8*" vlan 1
ports "4 8" switch enable
You can easily change the command line to work with vlan 1 and vlan 2, as
such:
$ robocfg switch disable vlans enable reset vlan 1 ports "0 1 2 3 8*" vlan 2
ports "4 8" switch enable
You can check the vlan configuration by issuing 'robocfg show'. The last part
of the output should visualise the vlan configuration of the switch.
Note that I'm able to configure the switch, but for the e3200 there is still
missing some piece, as it seems to be unable for the switch to deliver packets
to the ethernet driver and vice versa... The ports are working on the physical
layer (auto negotiation etc), the ports will see the MAC address of the remote
side to which it is connected, but the link with the ethernet driver is still
failing/missing?.
I see interrupts for tx packets in the ethernet driver, but they never get
send out from the switch. Rx packets never generate an interrupt in the
ethernet driver...
Regards,
Tijs_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
