Re: [OpenWrt-Devel] [PATCH] ramips: HooToo HT-TM02 factory image generation.
Hi,
What is the reason has this been rejected? Do I need to change
something?
Thanks,
Vittorio
Il 28.12.2014 13:34 Vittorio G (VittGam) ha scritto:
The mkhootoofw.sh is a shell script, because official factory images
are shell scripts by themselves, and it made more sense to me to just
use a shell script on the build host to put the pieces for the
factory
image file together, rather than reimplement the wheel in C.
The hootoo_mtd_writer is a stripped-down and modified version of mtd
that includes support for flashing at an offset in the MTD. This is
needed for the HooToo, because the only usable partition for factory
flashing is the one labeled "ALL", and we don't want to flash the
u-boot, u-boot-env and factory partitions too...
The hootoo_mtd_writer binary has been compiled using the toolchain
contained in the GPL tarball provided by HooToo. (It seems to me from
some tests that this is the only way to get executables running on
the
stock kernel...)
In order to update the firmware from the web interface you need to
put a FAT-formatted pendrive in the router USB port, since the
original firmware needs this as temporary storage, because the RAM is
quite bloated. Then you upload the OpenWrt factory image generated by
mkhootoofw.sh, and the script kills unneeded services and partitions
to free up RAM, backs up the original firmware on the pendrive,
extracts the hootoo_mtd_writer and the sysupgrade image, flashes the
sysupgrade image and then reboots.
I've tested the resulting image on the factory firmware, and it
successfully installed OpenWrt on my HT-TM02.
Signed-off-by: Vittorio Gambaletta
--- a/target/linux/ramips/image/Makefile
+++ b/target/linux/ramips/image/Makefile
@@ -317,6 +317,15 @@
fi
endef
+# Build HooToo factory images
+define BuildFirmware/HooToo8M/squashfs
+ $(call BuildFirmware/Default8M/$(1),$(1),$(2),$(3))
+ [ -e "$(call sysupname,$(1),$(2))" ] && \
+ $(SCRIPT_DIR)/download.pl "$(DL_DIR)" "hootoo_mtd_writer"
"3d72349cbb1d8e96086a084a6940304d"
"https://github.com/VittGam/hootoo_mtd_writer/releases/download/1.0/";
&& \
+ mkhootoofw.sh "$(DL_DIR)/hootoo_mtd_writer" "$(call
sysupname,$(1),$(2))" "$(call imgname,$(1),$(2))-factory.bin"
+endef
+BuildFirmware/HooToo8M/initramfs=$(call
BuildFirmware/OF/initramfs,$(1),$(2),$(3))
+
#
# RT288X Profiles
#
@@ -480,7 +489,7 @@
endef
Image/Build/Profile/HLKRM04=$(call
BuildFirmware/HLKRM04/$(1),$(1),hlk-rm04,HLKRM04,HLK-RM02)
-Image/Build/Profile/HT-TM02=$(call
BuildFirmware/Default8M/$(1),$(1),ht-tm02,HT-TM02)
+Image/Build/Profile/HT-TM02=$(call
BuildFirmware/HooToo8M/$(1),$(1),ht-tm02,HT-TM02)
Image/Build/Profile/M3=$(call BuildFirmware/Poray4M/$(1),$(1),m3,M3)
--- a/tools/firmware-utils/Makefile
+++ b/tools/firmware-utils/Makefile
@@ -76,6 +76,7 @@
define Host/Install
$(INSTALL_BIN) $(HOST_BUILD_DIR)/bin/* $(STAGING_DIR_HOST)/bin/
+ $(INSTALL_BIN) src/mkhootoofw.sh $(STAGING_DIR_HOST)/bin/
endef
$(eval $(call HostBuild))
--- /dev/null
+++ b/tools/firmware-utils/src/mkhootoofw.sh
@@ -0,0 +1,88 @@
+#!/bin/sh
+#
+# HooToo Factory Firmware Generator for OpenWrt
+# Copyright (C) 2014 Vittorio Gambaletta
+#
+# This is free software, licensed under the GNU General Public
License v2.
+# See /LICENSE for more information.
+#
+# Sources for the hootoo_mtd_writer utility, which must be compiled
with the GPL
+# toolchain provided by HooToo for it to work on the factory kernel,
can be
+# found at: https://github.com/VittGam/hootoo_mtd_writer
+#
+# Usage: mkhootoofw.sh path-to-hootoo_mtd_writer
path-to-openwrt-sysupgrade.bin path-to-openwrt-factory.bin
+#
+
+# Write the shellscript stub
+cat > "${3}.tmp" <<'EOF'
+SKIP=57
+
+echo "Checking firmware checksum..."
+[ "$CRCSUM" != "`sed '1,3d' "$0" | cksum | sed -e 's/ /Z/' -e 's/
/Z/' | cut -dZ -f1`" ] && {
+ echo "Firmware checksum error!"
+ exit 1
+}
+echo "Firmware checksum OK"
+
+echo "Killing unneeded services..."
+killall -9 fileserv ioos upnpd led_control owndns ownhttp vstddns
udhcpc udhcpd udevd minidlna smbd nmbd
+sleep 1
+
+echo "Unmounting unneeded mounts..."
+umount /etc
+umount /boot/tmp
+umount /usr/local/samba/var
+umount /opt
+umount /var
+
+echo "Backing up original firmware..."
+BKPDIRBASE="/data/UsbDisk1/Volume1/OpenWrt-HooToo-Backup-`sed
's/:/-/g' < /sys/class/net/ra0/address`-"
+BKPDIRNUM=1
+BKPDIR="${BKPDIRBASE}${BKPDIRNUM}"
+while [ -e "$BKPDIR" ]; do
+ BKPDIRNUM=$((${BKPDIRNUM}+1))
+ BKPDIR="${BKPDIRBASE}${BKPDIRNUM}"
+done
+echo "Backup directory: ${BKPDIR}"
+
+mkdir "$BKPDIR"
+cp /dev/mtdblock* "${BKPDIR}/" || {
+ echo "Backup failed!"
+ exit 1
+}
+sync && echo 3 > /proc/sys/vm/drop_caches
+echo "Backup OK"
+
+echo "Extracting OpenWrt firmware..."
+tail -n +$SKIP "$0" | tar xv -C /tmp/ || {
+ echo "Extraction of firmware failed!"
+ exit 1
+}
+chmod +x /tmp/hootoo_mtd_writer
+sync && echo 3 > /proc/sys/vm/drop_caches
+
+echo "Writing OpenWrt firmware..."
+cd /tmp/
[OpenWrt-Devel] [PATCH] [RESEND] [v2] base-files: Use 200ms LED timing as before for the new phase preinit_regular.
This restores normal pre-r43715 200ms blink-period for the System LED we're all
accustomed to see while our OpenWrt routers are booting.
Failsafe possibility will now be signalled with a new 100ms blinking, which is
easily recognizable from the normal 200ms booting.
So no existing user will be scared by a new 500ms LED pattern, since such a
slow pattern could easily be mistaken for something wrong... I was like "ok why
my router is collapsing now, is this a bad flash, a kernel panic, or what else"
when I've seen it for the first time ;)
Sorry for not having explained myself better in v1 of this patch.
Original:
Preinit, failsafe is possible: 200ms
Preinit, failsafe not possible anymore, booting normally: 200ms
Failsafe entered: 50ms
Now (after preinit_regular has been introduced):
Preinit, failsafe is possible: 200ms
Preinit, failsafe not possible anymore, booting normally: 500ms *here is the
"offending" change*
Failsafe entered: 50ms
With my proposed patch:
Preinit, failsafe is possible: 100ms *indicate this condition with a new
timing, that prompts the user to press the key if they want to start failsafe*
Preinit, failsafe not possible anymore, booting normally: 200ms *keep this as
before*
Failsafe entered: 50ms
Signed-off-by: Vittorio Gambaletta
diff --git a/package/base-files/files/lib/functions/leds.sh
b/package/base-files/files/lib/functions/leds.sh
index 4ac8145..d4d4512 100644
--- a/package/base-files/files/lib/functions/leds.sh
+++ b/package/base-files/files/lib/functions/leds.sh
@@ -60,7 +60,7 @@ status_led_blink_fast() {
}
status_led_blink_preinit() {
- led_timer $status_led 200 200
+ led_timer $status_led 100 100
}
status_led_blink_failsafe() {
@@ -68,5 +68,5 @@ status_led_blink_failsafe() {
}
status_led_blink_preinit_regular() {
- led_timer $status_led 500 500
+ led_timer $status_led 200 200
}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Strange LED behavior on ramips
Hi everybody, Is nobody else experiencing this on their ramips/rt5350-based router? Cheers, Vittorio G Il 25.12.2014 02:55 Vittorio G (VittGam) ha scritto: Hi everybody, I've got some HooToo HT-TM02 rt5350-based routers, and I've noticed a quite weird thing with LEDs. It seems that the LED handling gets halted for ~100ms every second. I'm linking to a video to explain this behavior. Here I've set the timer trigger for the blue LED to 50ms of delay_on/delay_off (like when in failsafe): https://server2.vittgam.net/openwrt-hootoo.mp4 The halting happens even with other delay times, even on the other green LED, and it is also noticeable when using other triggers, like netdev. I think the issue is with the rt5350 LED and/or GPIO driver, so does this happen to other ramips routers as well? Cheers, and Happy Xmas Vittorio G ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] netifd + split dns servers
On Thu, Jan 8, 2015 at 5:43 PM, Nikos Mavrogiannopoulos wrote: > Currently a protocol can register a dns server with netifd using the > proto_add_dns_server function. That however, does not allow > registering a DNS server for a specific domain. I checked the netifd > code and there is no provision for that. Would it make sense to add > such functionality to netifd, or should I make openconnect directly > register its split-dns servers with dnsmasq? > > regards, > Nikos Netifd writes the dns servers in /tmp/resolv.conf.auto which are read by dnsmasq. However I don't see a way to pass DNS servers for a specific domain via the resolv.conf.auto file to dnsmasq unless changes are done in dnsmasq. If such functionality needs to be supported; the changes will not only be limited to netifd. And netifd rewriting dnsmasq.conf seems a bit hacky too me Br, Hans ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] netifd + split dns servers
On Fri, Jan 9, 2015 at 9:48 AM, Hans Dedecker wrote: > On Thu, Jan 8, 2015 at 5:43 PM, Nikos Mavrogiannopoulos > wrote: >> Currently a protocol can register a dns server with netifd using the >> proto_add_dns_server function. That however, does not allow >> registering a DNS server for a specific domain. I checked the netifd >> code and there is no provision for that. Would it make sense to add >> such functionality to netifd, or should I make openconnect directly >> register its split-dns servers with dnsmasq? > Netifd writes the dns servers in /tmp/resolv.conf.auto which are read > by dnsmasq. > However I don't see a way to pass DNS servers for a specific domain > via the resolv.conf.auto file to dnsmasq unless changes are done in > dnsmasq. > If such functionality needs to be supported; the changes will not only > be limited to netifd. > And netifd rewriting dnsmasq.conf seems a bit hacky too me The resolv.conf format is very limited, if you rely on it you can only register global dns servers, and that's all. With dnsmasq, to support split-dns you need to configure a config directory for dnsmasq, and then place files in it that contain with the following format: server=/domain/address.ip regards, Nikos ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: HooToo HT-TM02 factory image generation.
On 09/01/2015 09:16, Vittorio G (VittGam) wrote:
> Hi,
>
> What is the reason has this been rejected? Do I need to change
> something?
>
> Thanks, Vittorio
>
> Il 28.12.2014 13:34 Vittorio G (VittGam) ha scritto:
>> The mkhootoofw.sh is a shell script, because official factory
>> images are shell scripts by themselves, and it made more sense to
>> me to just use a shell script on the build host to put the pieces
>> for the factory image file together, rather than reimplement the
>> wheel in C.
>>
>> The hootoo_mtd_writer is a stripped-down and modified version of
>> mtd that includes support for flashing at an offset in the MTD.
>> This is needed for the HooToo, because the only usable partition
>> for factory flashing is the one labeled "ALL", and we don't want
>> to flash the u-boot, u-boot-env and factory partitions too...
>>
>> The hootoo_mtd_writer binary has been compiled using the
>> toolchain contained in the GPL tarball provided by HooToo. (It
>> seems to me from some tests that this is the only way to get
>> executables running on the stock kernel...)
>>
>> In order to update the firmware from the web interface you need
>> to put a FAT-formatted pendrive in the router USB port, since
>> the original firmware needs this as temporary storage, because
>> the RAM is quite bloated. Then you upload the OpenWrt factory
>> image generated by mkhootoofw.sh, and the script kills unneeded
>> services and partitions to free up RAM, backs up the original
>> firmware on the pendrive, extracts the hootoo_mtd_writer and the
>> sysupgrade image, flashes the sysupgrade image and then reboots.
>>
>> I've tested the resulting image on the factory firmware, and it
>> successfully installed OpenWrt on my HT-TM02.
>>
>> Signed-off-by: Vittorio Gambaletta
>>
>> --- a/target/linux/ramips/image/Makefile +++
>> b/target/linux/ramips/image/Makefile @@ -317,6 +317,15 @@ fi
>> endef
>>
>> +# Build HooToo factory images +define
>> BuildFirmware/HooToo8M/squashfs +$(call
>> BuildFirmware/Default8M/$(1),$(1),$(2),$(3)) +[ -e "$(call
>> sysupname,$(1),$(2))" ] && \ +$(SCRIPT_DIR)/download.pl
>> "$(DL_DIR)" "hootoo_mtd_writer"
>> "3d72349cbb1d8e96086a084a6940304d"
>> "https://github.com/VittGam/hootoo_mtd_writer/releases/download/1.0/";
>>
>>
&& \
>> +mkhootoofw.sh "$(DL_DIR)/hootoo_mtd_writer" "$(call
>> sysupname,$(1),$(2))" "$(call imgname,$(1),$(2))-factory.bin"
>> +endef +BuildFirmware/HooToo8M/initramfs=$(call
>> BuildFirmware/OF/initramfs,$(1),$(2),$(3)) +
this bit is really bad. you cannot install a binary from a random
source and use that to flash the unit. the tool needs to be compiled
during the build process
>> # # RT288X Profiles # @@ -480,7 +489,7 @@ endef
>> Image/Build/Profile/HLKRM04=$(call
>> BuildFirmware/HLKRM04/$(1),$(1),hlk-rm04,HLKRM04,HLK-RM02)
>>
>> -Image/Build/Profile/HT-TM02=$(call
>> BuildFirmware/Default8M/$(1),$(1),ht-tm02,HT-TM02)
>> +Image/Build/Profile/HT-TM02=$(call
>> BuildFirmware/HooToo8M/$(1),$(1),ht-tm02,HT-TM02)
>>
>> Image/Build/Profile/M3=$(call
>> BuildFirmware/Poray4M/$(1),$(1),m3,M3)
>>
>> --- a/tools/firmware-utils/Makefile +++
>> b/tools/firmware-utils/Makefile @@ -76,6 +76,7 @@
>>
>> define Host/Install $(INSTALL_BIN) $(HOST_BUILD_DIR)/bin/*
>> $(STAGING_DIR_HOST)/bin/ +$(INSTALL_BIN) src/mkhootoofw.sh
>> $(STAGING_DIR_HOST)/bin/ endef
>>
>> $(eval $(call HostBuild)) --- /dev/null +++
>> b/tools/firmware-utils/src/mkhootoofw.sh @@ -0,0 +1,88 @@
>> +#!/bin/sh +# +# HooToo Factory Firmware Generator for OpenWrt +#
>> Copyright (C) 2014 Vittorio Gambaletta +#
>> +# This is free software, licensed under the GNU General Public
>> License v2. +# See /LICENSE for more information. +# +# Sources
>> for the hootoo_mtd_writer utility, which must be compiled with
>> the GPL +# toolchain provided by HooToo for it to work on the
>> factory kernel, can be +# found at:
>> https://github.com/VittGam/hootoo_mtd_writer +# +# Usage:
>> mkhootoofw.sh path-to-hootoo_mtd_writer
>> path-to-openwrt-sysupgrade.bin path-to-openwrt-factory.bin +# +
>> +# Write the shellscript stub +cat > "${3}.tmp" <<'EOF' +SKIP=57
>> + +echo "Checking firmware checksum..." +[ "$CRCSUM" != "`sed
>> '1,3d' "$0" | cksum | sed -e 's/ /Z/' -e 's/ /Z/' | cut -dZ -f1`"
>> ] && { +echo "Firmware checksum error!" +exit 1 +} +echo
>> "Firmware checksum OK" + +echo "Killing unneeded services..."
>> +killall -9 fileserv ioos upnpd led_control owndns ownhttp
>> vstddns udhcpc udhcpd udevd minidlna smbd nmbd +sleep 1 + +echo
>> "Unmounting unneeded mounts..." +umount /etc +umount /boot/tmp
>> +umount /usr/local/samba/var +umount /opt +umount /var + +echo
>> "Backing up original firmware..."
>> +BKPDIRBASE="/data/UsbDisk1/Volume1/OpenWrt-HooToo-Backup-`sed
>> 's/:/-/g' < /sys/class/net/ra0/address`-" +BKPDIRNUM=1
>> +BKPDIR="${BKPDIRBASE}${BKPDIRNUM}" +while [ -e "$BKPDIR" ]; do +
>> BKPDIRNUM=$((${BKPDIRNUM}+1)) +
>> BKPDIR="${BKPDIRBASE}${BKPDIRNUM}" +done +echo "
[OpenWrt-Devel] cmake.mk: ignores package CFLAGS
If you look at include/cmake.mk you will notice followiing: -DCMAKE_BUILD_TYPE=Release It means that CMake uses CMAKE_C_FLAGS_RELEASE I've created package and tested it using two variants: 1) TARGET_CFLAGS=-DFOO This is what I got: grep FOO build_dir/target-*/test/CMakeCache.txt CMAKE_CXX_FLAGS:STRING='-DFOO ' CMAKE_C_FLAGS:STRING='-DFOO ' My app was compiled *without* FOO 2) CMAKE_OPTIONS=-DCMAKE_C_FLAGS_RELEASE="-DFOO" This is what I got: grep FOO build_dir/target-*/test/CMakeCache.txt CMAKE_C_FLAGS_RELEASE:STRING=-DFOO My app was compiled *with* FOO I think there is a bug in cmake.mk. Since we use -DCMAKE_BUILD_TYPE=Release we can't really relay on CFLAGS="$(TARGET_CFLAGS) $(EXTRA_CFLAGS)" because it will result in CMAKE_C_FLAGS instead of CMAKE_C_FLAGS_RELEASE -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 uqmi] Add command for listing device capabilities
On 2015-01-08 19:08, Sławomir Demeszko wrote: > Signed-off-by: Sławomir Demeszko > --- > > Sorry, it seems my compiler doesn't suport -Wtautological-compare option, > and I was not warned about this. This condition could be removed, but > as I read it is unspecified if enums are signed or unsigned, it depends > on compiler, so I cast it to signed for comparison. I can't test it, > but should get rid of the warning. Applied, thanks. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Install .pc files of Python
On 2015-01-08 23:28, Szilárd Pfeiffer wrote: > Hi, > > .pc files are not copied to the install directory, so python (as a > library) cannot be checked from configure.ac by PKG_CHECK_MODULES. It > caused problem during the port of Zorp GPL to OpenWrt. Possible solution > is attached. > > Best regards, > Szilárd Pfeiffer Python is maintained on the packages GitHub repository: https://github.com/openwrt/packages You should submit an issue or pull request there. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Install .pc files of Python
I've already picked up the patch and looking into. Was going to come back with an answer, but I have some other stuff to look into. @Szilárd: if you want, you can also do a PR on Github. If not, then I'll apply your patch. Looks good to me. On Fri, Jan 9, 2015 at 12:25 PM, Felix Fietkau wrote: > On 2015-01-08 23:28, Szilárd Pfeiffer wrote: > > Hi, > > > > .pc files are not copied to the install directory, so python (as a > > library) cannot be checked from configure.ac by PKG_CHECK_MODULES. It > > caused problem during the port of Zorp GPL to OpenWrt. Possible solution > > is attached. > > > > Best regards, > > Szilárd Pfeiffer > Python is maintained on the packages GitHub repository: > https://github.com/openwrt/packages > You should submit an issue or pull request there. > > - Felix > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [packages] dnsmasq: add option --quiet-dhcp
The --quiet-dhcp setting increases privacy by omitting DHCP lease logs
including MAC addresses.
Signed-off-by: Lars Kruse
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -123,6 +123,7 @@ dnsmasq() {
append_bool "$cfg" nonwildcard "--bind-interfaces"
append_bool "$cfg" fqdn "--dhcp-fqdn"
append_bool "$cfg" proxydnssec "--proxy-dnssec"
+ append_bool "$cfg" quiet_dhcp "--quiet-dhcp"
append_parm "$cfg" dhcpscript "--dhcp-script"
append_parm "$cfg" cachesize "--cache-size"
--
I created the above patch with quilt. Hopefully the format is suitable.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [packages] dnsmasq: add option --quiet-dhcp
On 07.01.2015 23:50, Lars Kruse wrote:
>
> The --quiet-dhcp setting increases privacy by omitting DHCP lease logs
> including MAC addresses.
>
> Signed-off-by: Lars Kruse
>
> --- a/package/network/services/dnsmasq/files/dnsmasq.init
> +++ b/package/network/services/dnsmasq/files/dnsmasq.init
> @@ -123,6 +123,7 @@ dnsmasq() {
> append_bool "$cfg" nonwildcard "--bind-interfaces"
> append_bool "$cfg" fqdn "--dhcp-fqdn"
> append_bool "$cfg" proxydnssec "--proxy-dnssec"
> + append_bool "$cfg" quiet_dhcp "--quiet-dhcp"
>
> append_parm "$cfg" dhcpscript "--dhcp-script"
> append_parm "$cfg" cachesize "--cache-size"
would make sense to use 'quietdhcp' instead of 'quiet_dhcp', as the other
options seem to ommit the dashes too.
..ede
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [packages] dnsmasq: add option --quiet-dhcp
The --quiet-dhcp setting increases privacy by omitting DHCP lease logs
including MAC addresses.
Signed-off-by: Lars Kruse
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -123,6 +123,7 @@ dnsmasq() {
append_bool "$cfg" nonwildcard "--bind-interfaces"
append_bool "$cfg" fqdn "--dhcp-fqdn"
append_bool "$cfg" proxydnssec "--proxy-dnssec"
+ append_bool "$cfg" quietdhcp "--quiet-dhcp"
append_parm "$cfg" dhcpscript "--dhcp-script"
append_parm "$cfg" cachesize "--cache-size"
--
> would make sense to use 'quietdhcp' instead of 'quiet_dhcp', as the other
> options seem to ommit the dashes too.
correct - I forgot Jow's previous comment ...
Lars
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] netifd + split dns servers
Our dnsmasq init script registers /tmp/dnsmasq.d as an additional configuration dir, so you can place files there and restart it. However I'm not sure as to how much we want netifd to do dnsmasq-specific stuff or how we would do it. Of course the bad thing here again is that dnsmasq doesn't support soft-reloading and every time you restart it you lose your dns cache etc. etc. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] curl: enable "https" protocol
Provide optional --enable-https flag for curl. Signed-off-by: Lars Kruse --- a/package/network/utils/curl/Config.in +++ b/package/network/utils/curl/Config.in @@ -53,6 +53,10 @@ config LIBCURL_HTTP bool "Enable HTTP support" default y +config LIBCURL_HTTPS + bool "Enable HTTPS support" + default n + config LIBCURL_IMAP bool "Enable IMAP support" default n --- a/package/network/utils/curl/Makefile +++ b/package/network/utils/curl/Makefile @@ -37,6 +37,7 @@ PKG_CONFIG_DEPENDS := \ LIBCURL_GNUTLS \ LIBCURL_GOPHER \ LIBCURL_HTTP \ + LIBCURL_HTTPS \ LIBCURL_IMAP \ LIBCURL_LDAP \ LIBCURL_LDAPS \ @@ -112,6 +113,7 @@ CONFIGURE_ARGS += \ $(if $(CONFIG_LIBCURL_GOPHER),--enable,--disable)-gopher \ $(if $(CONFIG_LIBCURL_GNUTLS),--with-gnutls="$(STAGING_DIR)/usr",--without-gnutls) \ $(if $(CONFIG_LIBCURL_HTTP),--enable,--disable)-http \ + $(if $(CONFIG_LIBCURL_HTTPS),--enable,--disable)-https \ $(if $(CONFIG_LIBCURL_IMAP),--enable,--disable)-imap \ $(if $(CONFIG_LIBCURL_LDAP),--enable,--disable)-ldap \ $(if $(CONFIG_LIBCURL_LDAPS),--enable,--disable)-ldaps \ -- Sending again with correct formatting. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] procd/inittab with a delayed console
Hello Owen,
I was wondering, is the kernel driver for your console not placed in
/etc/modules-boot.d ?
/sbin/init executes procd, but prior to doing this executes kmodloader
to load all modules in /etc/modules-boot.d. If your module is mentioned
in this directory, this should load your console driver, thus making it
available before procd checks /etc/inittab.
This, to me, seems the most logical solution, as consoles should be
available to the init process early on during boot, and not hot-plugged
in afterwards. Do you agree?
To put modules in /etc/modules-boot.d, make sure that their
KernelPackage definition contains:
AUTOLOAD:=$(call AutoLoad,,,1)
Where is the load order and is the name of your kernel
module (or modules). The presence of the ,1 argument indicates whether
the module is placed in /etc/modules-boot.d or /etc/modules.d.
Kind regards,
Michel Stam
Embedded System Engineer
--- Begin Message ---
Hi,
I'm not sure if this is a bug with procd's implementation of inittab or
if I'm just doing something wrong in my inittab. However, we have a
board that has multiple serial console ports, one of which relies on a
kernel module and procd refuses to start a console on the second port.
What seems to be happening is that procd loads inittab before the kernel
modules are loaded, therefore the tty device doesn't exist yet and the
check for dev_exist() fails and procd never forks a worker for that console.
I was able to fix it for my board with the following patch, but I'm not
sure if this is would be the entire fix for the problem since it seems
like fork_worker() should be a little more graceful in handling tty
devices that don't exist yet.
Any thoughts or suggestions on better ways to fix this?
Thanks,
Owen
diff --git a/inittab.c b/inittab.c
index 2efbf4d..7b12e10 100644
--- a/inittab.c
+++ b/inittab.c
@@ -161,7 +161,7 @@ static void askfirst(struct init_action *a)
{
int i;
- if (!dev_exist(a->id) || (console && !strcmp(console, a->id))) {
+ if (console && !strcmp(console, a->id)) {
DEBUG(4, "Skipping %s\n", a->id);
return;
}
--
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] netifd + split dns servers
On Fri, Jan 9, 2015 at 12:25 PM, Steven Barth wrote: > Our dnsmasq init script registers /tmp/dnsmasq.d as an additional > configuration dir, so you can place files there and restart it. However I'm > not sure as to how much we want netifd to do dnsmasq-specific stuff or how > we would do it. Well I think that depends on how common use case is to have a dns server per domain. Currently I think I can handle that in openconnect directly, but if any other vpn application would like to do that, they'll have to duplicate that code. > Of course the bad thing here again is that dnsmasq doesn't support > soft-reloading and every time you restart it you lose your dns cache etc. > etc. Interestingly it supports the 'servers-file' option which would allow re-loading the domain specific servers without a restart. But even in that case the cache will be cleared. regards, Nikos ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: HooToo HT-TM02 factory image generation.
Il 09.01.2015 10:48 John Crispin ha scritto: +mkhootoofw.sh "$(DL_DIR)/hootoo_mtd_writer" "$(call sysupname,$(1),$(2))" "$(call imgname,$(1),$(2))-factory.bin" +endef +BuildFirmware/HooToo8M/initramfs=$(call BuildFirmware/OF/initramfs,$(1),$(2),$(3)) + this bit is really bad. you cannot install a binary from a random source and use that to flash the unit. the tool needs to be compiled during the build process Unfortunately the factory image uses an ancient version of uclibc, so binaries compiled with the newer version bundled with OpenWrt do not work on it... Anyway I've compiled that binary using the toolchain provided by HooToo, and the build is reproducible, so you or anybody else can easily verify that I'm not lying. :) Please let me know if you have a better solution, because in fact this is not quite clean. Cheers, Vittorio ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: HooToo HT-TM02 factory image generation.
Le 9 janv. 2015 07:09, "Vittorio G (VittGam)" a écrit : > > Il 09.01.2015 10:48 John Crispin ha scritto: > +mkhootoofw.sh "$(DL_DIR)/hootoo_mtd_writer" "$(call sysupname,$(1),$(2))" "$(call imgname,$(1),$(2))-factory.bin" +endef +BuildFirmware/HooToo8M/initramfs=$(call BuildFirmware/OF/initramfs,$(1),$(2),$(3)) + >> >> >> >> this bit is really bad. you cannot install a binary from a random >> source and use that to flash the unit. the tool needs to be compiled >> during the build process > > > Unfortunately the factory image uses an ancient version of uclibc, so binaries compiled with the newer version bundled with OpenWrt do not work on it... Anyway I've compiled that binary using the toolchain provided by HooToo, and the build is reproducible, so you or anybody else can easily verify that I'm not lying. :) > > Please let me know if you have a better solution, because in fact this is not quite clean. What about a statically linked binary at least? > > Cheers, > Vittorio > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] info about distance optimization
I found there exist distance optimization entry in Luci's wifi configure page. I think it's interesting and want to go further about it. Hardware driver programming is not too difficult for me. Anyone have any idea where should I start from? Thinks~ -- Best Regards, Zhao Zhang, Undergraduate from Dept. of Computer Science & Technology, Ocean University of China, Qingdao, China, 266100 Phone 18678430893 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Port for Edimax BR-6435ND (RALink 3352F)
Hi, as per https://dev.openwrt.org/wiki/SupportDonate [and subsequently jow_laptop's comment on irc to write to openwrt-devel] I'm writing here to offer one or two Edimax BR-6435ND as donation to get an openwrt build for them. Apparently the RAlink RT3352 already has seen some attention (https://dev.openwrt.org/search?q=RT3352&noquickjump=1&changeset=on&ticket=on), so my uneducated guess is that it should be relatively easy to get openwrt running. I've already collected some info about the router my posts here: https://forum.openwrt.org/viewtopic.php?id=54627 and https://wikidevi.com/wiki/Intellinet_300N_Wireless_Dual-Band_Router , to make it easier to assess the situation. Thanks in advance, geotti ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/4] mvsw61xx: rework chip recognition
Recognizes 88E6171/6172/6176 at the moment.
Signed-off-by: Claudio Leite
---
.../linux/generic/files/drivers/net/phy/mvsw61xx.c | 27 --
.../linux/generic/files/drivers/net/phy/mvsw61xx.h | 14 ---
2 files changed, 31 insertions(+), 10 deletions(-)
diff --git a/target/linux/generic/files/drivers/net/phy/mvsw61xx.c
b/target/linux/generic/files/drivers/net/phy/mvsw61xx.c
index 7199de0..865bd11 100644
--- a/target/linux/generic/files/drivers/net/phy/mvsw61xx.c
+++ b/target/linux/generic/files/drivers/net/phy/mvsw61xx.c
@@ -740,8 +740,8 @@ static int mvsw61xx_probe(struct platform_device *pdev)
struct mvsw61xx_state *state;
struct device_node *np = pdev->dev.of_node;
struct device_node *mdio;
+ char *model_str;
u32 val;
- u16 reg;
int err;
state = kzalloc(sizeof(*state), GFP_KERNEL);
@@ -776,17 +776,28 @@ static int mvsw61xx_probe(struct platform_device *pdev)
state->base_addr = MV_BASE;
}
- reg = r16(state->bus, state->is_indirect, state->base_addr,
- MV_PORTREG(IDENT, 0)) & MV_IDENT_MASK;
- if (reg != MV_IDENT_VALUE) {
- dev_err(&pdev->dev, "No switch found at 0x%02x\n",
+ state->model = r16(state->bus, state->is_indirect, state->base_addr,
+ MV_PORTREG(IDENT, 0)) & MV_IDENT_MASK;
+
+ switch(state->model) {
+ case MV_IDENT_VALUE_6171:
+ model_str = MV_IDENT_STR_6171;
+ break;
+ case MV_IDENT_VALUE_6172:
+ model_str = MV_IDENT_STR_6172;
+ break;
+ case MV_IDENT_VALUE_6176:
+ model_str = MV_IDENT_STR_6176;
+ break;
+ default:
+ dev_err(&pdev->dev, "No compatible switch found at 0x%02x\n",
state->base_addr);
err = -ENODEV;
goto out_err;
}
platform_set_drvdata(pdev, state);
- dev_info(&pdev->dev, "Found %s at %s:%02x\n", MV_IDENT_STR,
+ dev_info(&pdev->dev, "Found %s at %s:%02x\n", model_str,
state->bus->id, state->base_addr);
dev_info(&pdev->dev, "Using %sdirect addressing\n",
@@ -808,7 +819,7 @@ static int mvsw61xx_probe(struct platform_device *pdev)
state->dev.vlans = MV_VLANS;
state->dev.cpu_port = state->cpu_port0;
state->dev.ports = MV_PORTS;
- state->dev.name = MV_IDENT_STR;
+ state->dev.name = model_str;
state->dev.ops = &mvsw61xx_ops;
state->dev.alias = dev_name(&pdev->dev);
@@ -839,6 +850,8 @@ mvsw61xx_remove(struct platform_device *pdev)
static const struct of_device_id mvsw61xx_match[] = {
{ .compatible = "marvell,88e6171" },
+ { .compatible = "marvell,88e6172" },
+ { .compatible = "marvell,88e6176" },
{ }
};
MODULE_DEVICE_TABLE(of, mvsw61xx_match);
diff --git a/target/linux/generic/files/drivers/net/phy/mvsw61xx.h
b/target/linux/generic/files/drivers/net/phy/mvsw61xx.h
index bd9d60a..d61d21f 100644
--- a/target/linux/generic/files/drivers/net/phy/mvsw61xx.h
+++ b/target/linux/generic/files/drivers/net/phy/mvsw61xx.h
@@ -190,9 +190,16 @@ enum {
};
#define MV_INDIRECT_ADDR_S 5
-#define MV_IDENT_MASK 0xffc0
-#define MV_IDENT_VALUE 0x1700
-#define MV_IDENT_STR "MV88E617x"
+#define MV_IDENT_MASK 0xfff0
+
+#define MV_IDENT_VALUE_61710x1710
+#define MV_IDENT_STR_6171 "MV88E6171"
+
+#define MV_IDENT_VALUE_61720x1720
+#define MV_IDENT_STR_6172 "MV88E6172"
+
+#define MV_IDENT_VALUE_61760x1760
+#define MV_IDENT_STR_6176 "MV88E6176"
#define MV_PVID_MASK 0x0fff
@@ -200,6 +207,7 @@ struct mvsw61xx_state {
struct switch_dev dev;
struct mii_bus *bus;
int base_addr;
+ u16 model;
bool registered;
bool is_indirect;
--
2.2.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/4] mvsw6171: rename to 'mvsw61xx'
In preparation for properly supporting switches
beyond the 88E6171.
Signed-off-by: Claudio Leite
---
target/linux/generic/config-3.14 | 2 +-
target/linux/generic/config-3.18 | 2 +-
.../linux/generic/files/drivers/net/phy/mvsw6171.c | 866 -
.../linux/generic/files/drivers/net/phy/mvsw6171.h | 230 --
.../linux/generic/files/drivers/net/phy/mvsw61xx.c | 866 +
.../linux/generic/files/drivers/net/phy/mvsw61xx.h | 230 ++
.../generic/patches-3.14/733-phy_mvsw6171.patch| 23 -
.../generic/patches-3.14/733-phy_mvsw61xx.patch| 23 +
.../generic/patches-3.18/733-phy_mvsw6171.patch| 23 -
.../generic/patches-3.18/733-phy_mvsw61xx.patch| 23 +
target/linux/kirkwood/config-3.14 | 2 +-
target/linux/kirkwood/config-3.18 | 2 +-
.../linux/kirkwood/patches-3.14/160-ea4500.patch | 2 +-
.../linux/kirkwood/patches-3.18/160-ea4500.patch | 2 +-
14 files changed, 1148 insertions(+), 1148 deletions(-)
delete mode 100644 target/linux/generic/files/drivers/net/phy/mvsw6171.c
delete mode 100644 target/linux/generic/files/drivers/net/phy/mvsw6171.h
create mode 100644 target/linux/generic/files/drivers/net/phy/mvsw61xx.c
create mode 100644 target/linux/generic/files/drivers/net/phy/mvsw61xx.h
delete mode 100644 target/linux/generic/patches-3.14/733-phy_mvsw6171.patch
create mode 100644 target/linux/generic/patches-3.14/733-phy_mvsw61xx.patch
delete mode 100644 target/linux/generic/patches-3.18/733-phy_mvsw6171.patch
create mode 100644 target/linux/generic/patches-3.18/733-phy_mvsw61xx.patch
diff --git a/target/linux/generic/config-3.14 b/target/linux/generic/config-3.14
index 7b6055a..d888954 100644
--- a/target/linux/generic/config-3.14
+++ b/target/linux/generic/config-3.14
@@ -2144,7 +2144,7 @@ CONFIG_MTD_SPLIT_SQUASHFS_ROOT=y
# CONFIG_MUTEX_SPIN_ON_OWNER is not set
# CONFIG_MV643XX_ETH is not set
# CONFIG_MVMDIO is not set
-# CONFIG_MVSW6171_PHY is not set
+# CONFIG_MVSW61XX_PHY is not set
# CONFIG_MVSWITCH_PHY is not set
# CONFIG_MWAVE is not set
# CONFIG_MWL8K is not set
diff --git a/target/linux/generic/config-3.18 b/target/linux/generic/config-3.18
index ce2ec5c..ab9d071 100644
--- a/target/linux/generic/config-3.18
+++ b/target/linux/generic/config-3.18
@@ -2244,7 +2244,7 @@ CONFIG_MTD_SPLIT_SQUASHFS_ROOT=y
# CONFIG_MUTEX_SPIN_ON_OWNER is not set
# CONFIG_MV643XX_ETH is not set
# CONFIG_MVMDIO is not set
-# CONFIG_MVSW6171_PHY is not set
+# CONFIG_MVSW61XX_PHY is not set
# CONFIG_MVSWITCH_PHY is not set
# CONFIG_MWAVE is not set
# CONFIG_MWL8K is not set
diff --git a/target/linux/generic/files/drivers/net/phy/mvsw6171.c
b/target/linux/generic/files/drivers/net/phy/mvsw6171.c
deleted file mode 100644
index 48bb3fc..000
--- a/target/linux/generic/files/drivers/net/phy/mvsw6171.c
+++ /dev/null
@@ -1,866 +0,0 @@
-/*
- * Marvell 88E6171 switch driver
- *
- * Copyright (c) 2014 Claudio Leite
- *
- * Based on code (c) 2008 Felix Fietkau
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License v2 as published by the
- * Free Software Foundation
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include "mvsw6171.h"
-
-MODULE_DESCRIPTION("Marvell 88E6171 Switch driver");
-MODULE_AUTHOR("Claudio Leite ");
-MODULE_LICENSE("GPL v2");
-MODULE_ALIAS("platform:mvsw6171");
-
-/*
- * Register access is done through direct or indirect addressing,
- * depending on how the switch is physically connected.
- *
- * Direct addressing: all port and global registers directly
- * accessible via an address/register pair
- *
- * Indirect addressing: switch is mapped at a single address,
- * port and global registers accessible via a single command/data
- * register pair
- */
-
-static int
-mvsw6171_wait_mask_raw(struct mii_bus *bus, int addr,
- int reg, u16 mask, u16 val)
-{
- int i = 100;
- u16 r;
-
- do {
- r = bus->read(bus, addr, reg);
- if ((r & mask) == val)
- return 0;
- } while (--i > 0);
-
- return -ETIMEDOUT;
-}
-
-static u16
-r16(struct mii_bus *bus, bool indirect, int base_addr, int addr, int reg)
-{
- u16 ind_addr;
-
- if (!indirect)
- return bus->read(bus, addr, reg);
-
- /* Indirect read: First, make sure switch is free */
- mvsw6171_wait_mask_raw(bus, base_addr, MV_INDIRECT_REG_CMD,
- MV_INDIRECT_INPROGRESS, 0);
-
- /* Load address and request read */
- ind_addr = MV_INDIRECT_READ | (addr << MV_INDIRECT_ADDR_S) | reg;
- bus->write(bus, base_addr, MV_INDIRECT_REG_CMD,
- ind_addr);
-
- /* Wait until it's ready */
- mvsw6171_wait_mask_raw(bus, base_addr, MV_INDIRECT_REG_CMD,
-
[OpenWrt-Devel] [PATCH 4/4] mvsw61xx: track and set per-VLAN port state in STU
Since the driver doesn't know anything about (M)STP
we just hard-set the ports to be enabled if they are
part of the VLAN.
Signed-off-by: Claudio Leite
---
.../linux/generic/files/drivers/net/phy/mvsw61xx.c | 38 ++
.../linux/generic/files/drivers/net/phy/mvsw61xx.h | 1 +
2 files changed, 32 insertions(+), 7 deletions(-)
diff --git a/target/linux/generic/files/drivers/net/phy/mvsw61xx.c
b/target/linux/generic/files/drivers/net/phy/mvsw61xx.c
index 7ddb13e..116f6cf 100644
--- a/target/linux/generic/files/drivers/net/phy/mvsw61xx.c
+++ b/target/linux/generic/files/drivers/net/phy/mvsw61xx.c
@@ -2,6 +2,7 @@
* Marvell 88E61xx switch driver
*
* Copyright (c) 2014 Claudio Leite
+ * Copyright (c) 2014 Nikita Nazarenko
*
* Based on code (c) 2008 Felix Fietkau
*
@@ -27,6 +28,7 @@
MODULE_DESCRIPTION("Marvell 88E61xx Switch driver");
MODULE_AUTHOR("Claudio Leite ");
+MODULE_AUTHOR("Nikita Nazarenko ");
MODULE_LICENSE("GPL v2");
MODULE_ALIAS("platform:mvsw61xx");
@@ -333,6 +335,7 @@ static int mvsw61xx_set_vlan_ports(struct switch_dev *dev,
state->vlans[vno].mask = 0;
state->vlans[vno].port_mode = 0;
+ state->vlans[vno].port_sstate = 0;
if(state->vlans[vno].vid == 0)
state->vlans[vno].vid = vno;
@@ -348,6 +351,8 @@ static int mvsw61xx_set_vlan_ports(struct switch_dev *dev,
mode = MV_VTUCTL_EGRESS_UNTAGGED;
state->vlans[vno].port_mode |= mode << (pno * 4);
+ state->vlans[vno].port_sstate |=
+ MV_STUCTL_STATE_FORWARDING << (pno * 4 + 2);
}
/*
@@ -447,7 +452,7 @@ static int mvsw61xx_set_enable_vlan(struct switch_dev *dev,
static int mvsw61xx_vtu_program(struct switch_dev *dev)
{
struct mvsw61xx_state *state = get_state(dev);
- u16 v1, v2;
+ u16 v1, v2, s1, s2;
int i;
/* Flush */
@@ -466,14 +471,32 @@ static int mvsw61xx_vtu_program(struct switch_dev *dev)
mvsw61xx_wait_mask_s(dev, MV_GLOBALREG(VTU_OP),
MV_VTUOP_INPROGRESS, 0);
- sw16(dev, MV_GLOBALREG(VTU_VID),
- MV_VTU_VID_VALID | state->vlans[i].vid);
+ /* Write per-VLAN port state into STU */
+ s1 = (u16) (state->vlans[i].port_sstate & 0x);
+ s2 = (u16) ((state->vlans[i].port_sstate >> 16) & 0x);
+
+ sw16(dev, MV_GLOBALREG(VTU_VID), MV_VTU_VID_VALID);
+ sw16(dev, MV_GLOBALREG(VTU_SID), i);
+ sw16(dev, MV_GLOBALREG(VTU_DATA1), s1);
+ sw16(dev, MV_GLOBALREG(VTU_DATA2), s2);
+ sw16(dev, MV_GLOBALREG(VTU_DATA3), 0);
+
+ sw16(dev, MV_GLOBALREG(VTU_OP),
+ MV_VTUOP_INPROGRESS | MV_VTUOP_STULOAD);
+ mvsw61xx_wait_mask_s(dev, MV_GLOBALREG(VTU_OP),
+ MV_VTUOP_INPROGRESS, 0);
- v1 = (u16)(state->vlans[i].port_mode & 0x);
- v2 = (u16)((state->vlans[i].port_mode >> 16) & 0x);
+ /* Write VLAN information into VTU */
+ v1 = (u16) (state->vlans[i].port_mode & 0x);
+ v2 = (u16) ((state->vlans[i].port_mode >> 16) & 0x);
+ sw16(dev, MV_GLOBALREG(VTU_VID),
+ MV_VTU_VID_VALID | state->vlans[i].vid);
+ sw16(dev, MV_GLOBALREG(VTU_SID), i);
+ sw16(dev, MV_GLOBALREG(VTU_FID), 0);
sw16(dev, MV_GLOBALREG(VTU_DATA1), v1);
sw16(dev, MV_GLOBALREG(VTU_DATA2), v2);
+ sw16(dev, MV_GLOBALREG(VTU_DATA3), 0);
sw16(dev, MV_GLOBALREG(VTU_OP),
MV_VTUOP_INPROGRESS | MV_VTUOP_LOAD);
@@ -514,8 +537,6 @@ static int mvsw61xx_update_state(struct switch_dev *dev)
if (!state->registered)
return -EINVAL;
- mvsw61xx_vtu_program(dev);
-
/*
* Set 802.1q-only mode if vlan_enabled is true.
*
@@ -568,6 +589,8 @@ static int mvsw61xx_update_state(struct switch_dev *dev)
sw16(dev, MV_PORTREG(CONTROL2, i), reg);
}
+ mvsw61xx_vtu_program(dev);
+
return 0;
}
@@ -615,6 +638,7 @@ static int mvsw61xx_reset(struct switch_dev *dev)
state->vlans[i].mask = 0;
state->vlans[i].vid = 0;
state->vlans[i].port_mode = 0;
+ state->vlans[i].port_sstate = 0;
}
state->vlan_enabled = 0;
diff --git a/target/linux/generic/files/drivers/net/phy/mvsw61xx.h
b/target/linux/generic/files/drivers/net/phy/mvsw61xx.h
index 8bd6f9a..61e134c 100644
--- a/target/linux/generic/files/drivers/net/phy/mvsw61xx.h
+++ b/target/linux/generic/files/drivers/net/phy/mvsw61xx.h
@@ -249,6 +249,7 @@ struct mvsw61xx_state {
u16 mask;
u16 vid;
u32 port_mode;
+
[OpenWrt-Devel] [PATCH 3/4] mvsw61xx: clean up and expand register definitions
- eliminate MV_CPUPORT; not necessary since we define
the CPU port(s) via Device Tree
- add STU and expand VTU operations
- update register names to match those of 88E61xx rather than
mvswitch's 88E6060
- use more consistent formatting
Signed-off-by: Claudio Leite
---
.../linux/generic/files/drivers/net/phy/mvsw61xx.c | 14 ++---
.../linux/generic/files/drivers/net/phy/mvsw61xx.h | 65 ++
2 files changed, 50 insertions(+), 29 deletions(-)
diff --git a/target/linux/generic/files/drivers/net/phy/mvsw61xx.c
b/target/linux/generic/files/drivers/net/phy/mvsw61xx.c
index 865bd11..7ddb13e 100644
--- a/target/linux/generic/files/drivers/net/phy/mvsw61xx.c
+++ b/target/linux/generic/files/drivers/net/phy/mvsw61xx.c
@@ -454,7 +454,7 @@ static int mvsw61xx_vtu_program(struct switch_dev *dev)
mvsw61xx_wait_mask_s(dev, MV_GLOBALREG(VTU_OP),
MV_VTUOP_INPROGRESS, 0);
sw16(dev, MV_GLOBALREG(VTU_OP),
- MV_VTUOP_INPROGRESS | MV_VTUOP_VALID);
+ MV_VTUOP_INPROGRESS | MV_VTUOP_PURGE);
/* Write VLAN table */
for (i = 1; i < dev->vlans; i++) {
@@ -467,7 +467,7 @@ static int mvsw61xx_vtu_program(struct switch_dev *dev)
MV_VTUOP_INPROGRESS, 0);
sw16(dev, MV_GLOBALREG(VTU_VID),
- MV_VTUOP_VALID | state->vlans[i].vid);
+ MV_VTU_VID_VALID | state->vlans[i].vid);
v1 = (u16)(state->vlans[i].port_mode & 0x);
v2 = (u16)((state->vlans[i].port_mode >> 16) & 0x);
@@ -585,7 +585,7 @@ static int mvsw61xx_reset(struct switch_dev *dev)
/* Disable all ports before reset */
for (i = 0; i < dev->ports; i++) {
reg = sr16(dev, MV_PORTREG(CONTROL, i)) &
- ~MV_PORTCTRL_ENABLED;
+ ~MV_PORTCTRL_FORWARDING;
sw16(dev, MV_PORTREG(CONTROL, i), reg);
}
@@ -602,9 +602,9 @@ static int mvsw61xx_reset(struct switch_dev *dev)
state->ports[i].pvid = 0;
/* Force flow control off */
- reg = sr16(dev, MV_PORTREG(FORCE, i)) & ~MV_FORCE_FC_MASK;
- reg |= MV_FORCE_FC_DISABLE;
- sw16(dev, MV_PORTREG(FORCE, i), reg);
+ reg = sr16(dev, MV_PORTREG(PHYCTL, i)) & ~MV_PHYCTL_FC_MASK;
+ reg |= MV_PHYCTL_FC_DISABLE;
+ sw16(dev, MV_PORTREG(PHYCTL, i), reg);
/* Set port association vector */
sw16(dev, MV_PORTREG(ASSOC, i), (1 << i));
@@ -624,7 +624,7 @@ static int mvsw61xx_reset(struct switch_dev *dev)
/* Re-enable ports */
for (i = 0; i < dev->ports; i++) {
reg = sr16(dev, MV_PORTREG(CONTROL, i)) |
- MV_PORTCTRL_ENABLED;
+ MV_PORTCTRL_FORWARDING;
sw16(dev, MV_PORTREG(CONTROL, i), reg);
}
diff --git a/target/linux/generic/files/drivers/net/phy/mvsw61xx.h
b/target/linux/generic/files/drivers/net/phy/mvsw61xx.h
index d61d21f..8bd6f9a 100644
--- a/target/linux/generic/files/drivers/net/phy/mvsw61xx.h
+++ b/target/linux/generic/files/drivers/net/phy/mvsw61xx.h
@@ -2,6 +2,7 @@
* Marvell 88E61xx switch driver
*
* Copyright (c) 2014 Claudio Leite
+ * Copyright (c) 2014 Nikita Nazarenko
*
* Based on code (c) 2008 Felix Fietkau
*
@@ -16,8 +17,6 @@
#define MV_PORTS 7
#define MV_PORTS_MASK ((1 << MV_PORTS) - 1)
-#define MV_CPUPORT 6
-
#define MV_BASE0x10
#define MV_SWITCHPORT_BASE 0x10
@@ -28,8 +27,8 @@
enum {
MV_PORT_STATUS = 0x00,
- MV_PORT_FORCE = 0x01,
- MV_PORT_PAUSE = 0x02,
+ MV_PORT_PHYCTL = 0x01,
+ MV_PORT_JAMCTL = 0x02,
MV_PORT_IDENT = 0x03,
MV_PORT_CONTROL = 0x04,
MV_PORT_CONTROL1= 0x05,
@@ -37,8 +36,10 @@ enum {
MV_PORT_VLANID = 0x07,
MV_PORT_CONTROL2= 0x08,
MV_PORT_ASSOC = 0x0b,
- MV_PORT_RXCOUNT = 0x10,
- MV_PORT_TXCOUNT = 0x11,
+ MV_PORT_RX_DISCARD_LOW = 0x10,
+ MV_PORT_RX_DISCARD_HIGH = 0x11,
+ MV_PORT_IN_FILTERED = 0x12,
+ MV_PORT_OUT_ACCEPTED= 0x13,
};
#define MV_PORTREG(_type, _port) MV_SWITCHPORT(_port), MV_PORT_##_type
@@ -56,18 +57,19 @@ enum {
#define MV_PORT_STATUS_SPEED_MASK (3 << 8)
enum {
- MV_PORTCTRL_BLOCK = (1 << 0),
- MV_PORTCTRL_LEARN = (2 << 0),
- MV_PORTCTRL_ENABLED = (3 << 0),
+ MV_PORTCTRL_DISABLED= (0 << 0),
+ MV_PORTCTRL_BLOCKING
Re: [OpenWrt-Devel] procd/inittab with a delayed console
"Stam, Michel [FINT]" wrote: > This, to me, seems the most logical solution, as consoles should be > available to the init process early on during boot, and not hot-plugged > in afterwards. Do you agree? Well, I don't. What about a usb serial port? I'd like to plug in the usb cable, providing vbus to power up a cp210x, which then becomes a new /dev/ttyUSBxxx and I'd like inittab to offer me a console there. It's not there at boot though... Sincerely, Karl P___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] procd/inittab with a delayed console
Am Freitag, 9. Januar 2015, 17:51:48 schrieb Karl Palsson: > > "Stam, Michel [FINT]" wrote: > > This, to me, seems the most logical solution, as consoles should be > > available to the init process early on during boot, and not hot-plugged > > in afterwards. Do you agree? > > > Well, I don't. What about a usb serial port? I'd like to plug in the > usb cable, providing vbus to power up a cp210x, which then becomes a new > /dev/ttyUSBxxx and I'd like inittab to offer me a console there. It's not > there at boot though... +1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] procd/inittab with a delayed console
On 15-01-09 09:51 AM, Karl Palsson wrote: "Stam, Michel [FINT]" wrote: This, to me, seems the most logical solution, as consoles should be available to the init process early on during boot, and not hot-plugged in afterwards. Do you agree? Well, I don't. What about a usb serial port? I'd like to plug in the usb cable, providing vbus to power up a cp210x, which then becomes a new /dev/ttyUSBxxx and I'd like inittab to offer me a console there. It's not there at boot though... This is actually very close to what we're doing on this board, it has two console ports: one is a UART which the bootloader and kernel are using, and a second console port which is really just a USB device controller. The UART lines are a pain to get to without a soldering iron so under AA and BB we would just connect a laptop into the USB port and get a console on the router. However, it's not quite real hotplugging since /dev/ttyGS0 is present whenever the driver is loaded, just that it depends on the USB gadget drivers which get loaded a little too late for inittab to find it. Hotplugging does sound like a cool feature though. Cheers, Owen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] procd/inittab with a delayed console
Michel, Thanks for the suggestion, this particular driver was being loaded from /etc/modules.d, however even when I moved it into /etc/modules-boot.d it still doesn't create /dev/ttyGS0 in time for procd to start the console. I'll try fiddling around with the load order to see if I can get it working without my changes to procd Thanks, Owen On 15-01-09 04:33 AM, Stam, Michel [FINT] wrote: Hello Owen, I was wondering, is the kernel driver for your console not placed in /etc/modules-boot.d ? /sbin/init executes procd, but prior to doing this executes kmodloader to load all modules in /etc/modules-boot.d. If your module is mentioned in this directory, this should load your console driver, thus making it available before procd checks /etc/inittab. This, to me, seems the most logical solution, as consoles should be available to the init process early on during boot, and not hot-plugged in afterwards. Do you agree? To put modules in /etc/modules-boot.d, make sure that their KernelPackage definition contains: AUTOLOAD:=$(call AutoLoad,,,1) Where is the load order and is the name of your kernel module (or modules). The presence of the ,1 argument indicates whether the module is placed in /etc/modules-boot.d or /etc/modules.d. Kind regards, Michel Stam Embedded System Engineer ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [mvebu] use mvsw61xx
Use Claudio's renamed mvsw6171 driver. Depends upon https://patchwork.ozlabs.org/patch/427183/ patchset. Signed-off-by: Mark Milburn --- target/linux/mvebu/config-3.14 | 2 +- target/linux/mvebu/config-3.18 | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/target/linux/mvebu/config-3.14 b/target/linux/mvebu/config-3.14 index 17a5d64..d3f6584 100644 --- a/target/linux/mvebu/config-3.14 +++ b/target/linux/mvebu/config-3.14 @@ -209,7 +209,7 @@ CONFIG_MVEBU_DEVBUS=y CONFIG_MVEBU_MBUS=y CONFIG_MVMDIO=y CONFIG_MVNETA=y -CONFIG_MVSW6171_PHY=y +CONFIG_MVSW61XX_PHY=y CONFIG_MV_XOR=y CONFIG_NEED_DMA_MAP_STATE=y # CONFIG_NEON is not set diff --git a/target/linux/mvebu/config-3.18 b/target/linux/mvebu/config-3.18 index 54639f8..9b2b480 100644 --- a/target/linux/mvebu/config-3.18 +++ b/target/linux/mvebu/config-3.18 @@ -247,7 +247,7 @@ CONFIG_MVEBU_DEVBUS=y CONFIG_MVEBU_MBUS=y CONFIG_MVMDIO=y CONFIG_MVNETA=y -CONFIG_MVSW6171_PHY=y +CONFIG_MVSW61XX_PHY=y CONFIG_MV_XOR=y CONFIG_NEED_DMA_MAP_STATE=y # CONFIG_NEON is not set -- 2.2.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: HooToo HT-TM02 factory image generation.
Il 09.01.2015 16:17 Florian Fainelli ha scritto: What about a statically linked binary at least? Of course I've missed the obvious thing here. :) Thanks for the suggestion! I'm going to try this as soon as I've some spare time (in a week or so). Otherwise the code is on my github if you want to try to do it in the meantime (and you have the hardware...). Cheers, Vittorio G ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] How to acces init mtd partition on RB2011-UiAS
Hi, How can I access to init mtd partition? Actually I'm only seeing this: dev:size erasesize name mtd0: 0004 0002 "booter" mtd1: 003c 0002 "kernel" mtd2: 07c0 0002 "rootfs" I would like to access to mtd partition: routerboot, hard_config, bios and softconfig from the user space. thanks! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
