Re: [OpenWrt-Devel] [PATCH][ar71xx] Routerboard 951G Switch Fix
Hi, On 10/12/2014 22:33, Chris Green wrote: > On Wed, Dec 10, 2014 at 01:40:42PM -0700, Davey Hutchison wrote: >> Fix pll_1000 value for eth0. Traffic would not flow from the eth0 interface. >> The new PLL enables delay, use ath79_setup_ar934x_eth_cfg to also enable >> AR934X_ETH_CFG_RXD_DELAY. >> >> Signed-off-by: Davey Hutchison >> >> --- target/linux/ar71xx/files/arch/mips/ath79/mach-rb95x.c >> +++ target/linux/ar71xx/files/arch/mips/ath79/mach-rb95x.c >> @@ -199,6 +199,7 @@ >> return; >> >> ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0 | >> + AR934X_ETH_CFG_RXD_DELAY | >> AR934X_ETH_CFG_SW_ONLY_MODE); >> >> ath79_register_mdio(0, 0x0); >> @@ -209,6 +210,7 @@ >> ath79_init_mac(ath79_eth0_data.mac_addr, ath79_mac_base, 0); >> ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII; >> ath79_eth0_data.phy_mask = BIT(0); >> +ath79_eth0_pll_data.pll_1000 = 0x3e00; >> >> ath79_register_eth(0); > > This needs to be in mach-rb2011.c as well. > i will hopefully get round to looking at this today. first i could not find my rs232 usb keyspan thingy, then i failed to find the poe injector .. do these board have uboot ? if so the easiest way would be to enter uboot, start a tftp to make sure the network is configured and then use the md command to display the relevant register. John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][RESEND] [tools] toolchain: ensure tools are built and staged before preparing toolchain
On Fri, Dec 12, 2014 at 12:03 PM, Felix Fietkau wrote: > On 2014-12-09 11:47, John Szakmeister wrote: >> This fixes an issue where the toolchain/prepare step could run, but some >> of the necessary host tools might be missing. >> >> Signed-off-by: John Szakmeister >> --- >> This is a resend of a patch I sent earlier >> (https://lists.openwrt.org/pipermail/openwrt-devel/2014-October/028422.html). >> I didn't receive any feedback, but it has enabled me to build >> correctly with a parallel build. >> >> Makefile | 2 +- >> toolchain/Makefile | 4 >> 2 files changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/Makefile b/Makefile >> index 91b6946..edb75fd 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -38,7 +38,7 @@ else >>include tools/Makefile >>include toolchain/Makefile >> >> -$(toolchain/stamp-install): $(tools/stamp-install) >> +$(toolchain/stamp-prepare): $(tools/stamp-install) >> $(target/stamp-compile): $(toolchain/stamp-install) $(tools/stamp-install) >> $(BUILD_DIR)/.prepared >> $(package/stamp-compile): $(target/stamp-compile) $(package/stamp-cleanup) >> $(package/stamp-install): $(package/stamp-compile) >> diff --git a/toolchain/Makefile b/toolchain/Makefile >> index 36c6ed3..b260a36 100644 >> --- a/toolchain/Makefile >> +++ b/toolchain/Makefile >> @@ -82,6 +82,10 @@ ifndef DUMP_TARGET_DB >> $(TOOLCHAIN_DIR)/stamp/.gcc-initial_installed: >> endif >> >> +$(eval $(call stampfile,$(curdir),toolchain,prepare)) >> $(eval $(call >> stampfile,$(curdir),toolchain,install,$(TOOLCHAIN_DIR)/stamp/.gcc-initial_installed,,$(TOOLCHAIN_DIR))) >> + >> +$($(curdir)/stamp-install): $($(curdir)/stamp-prepare) > This doesn't look right to me, I don't think we should add the > toolchain/prepare step as an intermediate target for the regular build > process. > How about just adding this line to Makefile and leaving out the rest: > > toolchain/prepare: $(tools/stamp-install) Who will depend on the toolchain/prepare to make sure that it happens before toolchain/install? I couldn't find this happening automatically in the Makefiles, that's why I went through the work of setting up the intermediate target. Trying your version locally fails. -John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][RESEND] [tools] toolchain: ensure tools are built and staged before preparing toolchain
On Sat, Dec 13, 2014 at 4:28 AM, John Szakmeister wrote: [snip] >> This doesn't look right to me, I don't think we should add the >> toolchain/prepare step as an intermediate target for the regular build >> process. >> How about just adding this line to Makefile and leaving out the rest: >> >> toolchain/prepare: $(tools/stamp-install) > > Who will depend on the toolchain/prepare to make sure that it > happens before toolchain/install? I couldn't find this > happening automatically in the Makefiles, that's why I went > through the work of setting up the intermediate target. > > Trying your version locally fails. Turns out this second version doesn't work either. One of my branches had the first version of the fix in it. FWIW, the first thing I tried was the following, but it didn't seem like the right approach--though it does work correctly: commit 161c49cdbc0b81d3e6072dc788cb5432760e Author: John Szakmeister Date: Wed Sep 17 06:47:58 2014 -0400 toolchain: ensure tools are built and staged before preparing toolchain This fixes an issue where the toolchain/prepare step could run, but some of the necessary host tools might be missing. Signed-off-by: John Szakmeister diff --git a/toolchain/Makefile b/toolchain/Makefile index 36c6ed3..f534cbc 100644 --- a/toolchain/Makefile +++ b/toolchain/Makefile @@ -74,7 +74,7 @@ endif # prerequisites for the individual targets $(curdir)/ := .config prereq -$(curdir)//prepare = $(STAGING_DIR)/.prepared $(TOOLCHAIN_DIR)/info.mk +$(curdir)//prepare = $(STAGING_DIR)/.prepared $(TOOLCHAIN_DIR)/info.mk tools/install $(curdir)//compile = $(1)/prepare $(curdir)//install = $(1)/compile ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][RESEND] [tools] toolchain: ensure tools are built and staged before preparing toolchain
On 2014-12-13 10:43, John Szakmeister wrote: > On Sat, Dec 13, 2014 at 4:28 AM, John Szakmeister > wrote: > [snip] >>> This doesn't look right to me, I don't think we should add the >>> toolchain/prepare step as an intermediate target for the regular build >>> process. >>> How about just adding this line to Makefile and leaving out the rest: >>> >>> toolchain/prepare: $(tools/stamp-install) >> >> Who will depend on the toolchain/prepare to make sure that it >> happens before toolchain/install? I couldn't find this >> happening automatically in the Makefiles, that's why I went >> through the work of setting up the intermediate target. >> >> Trying your version locally fails. > > Turns out this second version doesn't work either. One of my > branches had the first version of the fix in it. FWIW, the > first thing I tried was the following, but it didn't seem like > the right approach--though it does work correctly: How do you reproduce the failure on your system? I've been building with -j8 and higher for a long time now without seeing anything from toolchain/ being built before tools/ - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][RESEND] [tools] toolchain: ensure tools are built and staged before preparing toolchain
On Sat, Dec 13, 2014 at 5:11 AM, Felix Fietkau wrote: > On 2014-12-13 10:43, John Szakmeister wrote: >> On Sat, Dec 13, 2014 at 4:28 AM, John Szakmeister >> wrote: >> [snip] This doesn't look right to me, I don't think we should add the toolchain/prepare step as an intermediate target for the regular build process. How about just adding this line to Makefile and leaving out the rest: toolchain/prepare: $(tools/stamp-install) >>> >>> Who will depend on the toolchain/prepare to make sure that it >>> happens before toolchain/install? I couldn't find this >>> happening automatically in the Makefiles, that's why I went >>> through the work of setting up the intermediate target. >>> >>> Trying your version locally fails. >> >> Turns out this second version doesn't work either. One of my >> branches had the first version of the fix in it. FWIW, the >> first thing I tried was the following, but it didn't seem like >> the right approach--though it does work correctly: > How do you reproduce the failure on your system? I've been building with > -j8 and higher for a long time now without seeing anything from > toolchain/ being built before tools/ That's exactly what I do (except I use 4 jobs), but I see it descend into toolchain first (well, after doing some other setup), and it breaks when trying to setup the kernel headers. I did find it slightly easier to reproduce with `make -j4 toolchain/install` after a `make dirclean`: <<< :: make -j4 toolchain/install Collecting package info: done Collecting target info: done Checking 'working-make'... ok. Checking 'case-sensitive-fs'... ok. Checking 'getopt'... ok. Checking 'fileutils'... ok. Checking 'working-gcc'... ok. Checking 'working-g++'... ok. Checking 'ncurses'... ok. Checking 'zlib'... ok. Checking 'gawk'... ok. Checking 'unzip'... ok. Checking 'bzip2'... ok. Checking 'perl'... ok. Checking '/usr/bin/python2.7'... ok. Checking 'wget'... ok. Checking 'git'... ok. Checking 'gnutar'... ok. Checking 'svn'... ok. Checking 'libssl'... ok. Checking 'openssl'... ok. Checking 'gnu-find'... ok. Checking 'getopt-extended'... ok. Checking 'file'... ok. Checking 'non-root'... ok. Checking 'openssl'... ok. Checking '/usr/include/openssl/ssl.h'... ok. Checking 'xsltproc'... ok. Checking 'rsync'... ok. Checking 'xgettext'... ok. make[1] toolchain/install make[2] -C toolchain/gdb prepare make[2] -C toolchain/binutils prepare make[2] -C toolchain/gcc/minimal prepare make[2] -C toolchain/kernel-headers prepare make -r toolchain/install: build failed. Please re-run make with V=s to see what's going on make: *** [toolchain/install] Error 1 >>> This is in on master with no patches. :-( -John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][ar71xx] Routerboard 951G Switch Fix
On Sat, Dec 13, 2014 at 09:01:09AM +0100, John Crispin wrote: > Hi, > > On 10/12/2014 22:33, Chris Green wrote: > > On Wed, Dec 10, 2014 at 01:40:42PM -0700, Davey Hutchison wrote: > >> Fix pll_1000 value for eth0. Traffic would not flow from the eth0 > >> interface. > >> The new PLL enables delay, use ath79_setup_ar934x_eth_cfg to also enable > >> AR934X_ETH_CFG_RXD_DELAY. > >> > >> Signed-off-by: Davey Hutchison > >> > >> --- target/linux/ar71xx/files/arch/mips/ath79/mach-rb95x.c > >> +++ target/linux/ar71xx/files/arch/mips/ath79/mach-rb95x.c > >> @@ -199,6 +199,7 @@ > >>return; > >> > >>ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0 | > >> + AR934X_ETH_CFG_RXD_DELAY | > >> AR934X_ETH_CFG_SW_ONLY_MODE); > >> > >>ath79_register_mdio(0, 0x0); > >> @@ -209,6 +210,7 @@ > >>ath79_init_mac(ath79_eth0_data.mac_addr, ath79_mac_base, 0); > >>ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII; > >>ath79_eth0_data.phy_mask = BIT(0); > >> + ath79_eth0_pll_data.pll_1000 = 0x3e00; > >> > >>ath79_register_eth(0); > > > > This needs to be in mach-rb2011.c as well. > > > > > i will hopefully get round to looking at this today. first i could not > find my rs232 usb keyspan thingy, then i failed to find the poe injector .. > > do these board have uboot ? if so the easiest way would be to enter > uboot, start a tftp to make sure the network is configured and then use > the md command to display the relevant register. > I'm using the COM port on my PC (yes, it has a real one!) to do things to my rb-2011uias-2hnd. It took me w while to produce a correctly wired DB-9 to RJ-45 cable but I managed in the end. By 'uboot' do you mean the ability to change boot source etc. by hitting a key on reboot? This is what I'm doing to load openwrite. Reboot the rb-2011uias-2hnd, hit a key on the serial port and then tell it to boot from ethernet using tftp. It's pretty straightforward. I can probably submit a patch for mach-rb2011.c parallelling the above one this week-end. -- Chris Green ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: add an extra check on board_name for ath10k firmware patchs
On Sat, Dec 13, 2014 at 08:25:35AM +0100, John Crispin wrote: > Hi lynxis, > > ah the stray ath10k fw warning ... thanks, one todo less on my list :) > Is this the:- md5sum: can't open '/lib/firmware/ath10k/QCA988X/hw2.0/firmware-3.bin': No such file or directory -- Chris Green ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][RESEND] [tools] toolchain: ensure tools are built and staged before preparing toolchain
On 2014-12-13 11:22, John Szakmeister wrote: > On Sat, Dec 13, 2014 at 5:11 AM, Felix Fietkau wrote: >> On 2014-12-13 10:43, John Szakmeister wrote: >>> On Sat, Dec 13, 2014 at 4:28 AM, John Szakmeister >>> wrote: >>> [snip] > This doesn't look right to me, I don't think we should add the > toolchain/prepare step as an intermediate target for the regular build > process. > How about just adding this line to Makefile and leaving out the rest: > > toolchain/prepare: $(tools/stamp-install) Who will depend on the toolchain/prepare to make sure that it happens before toolchain/install? I couldn't find this happening automatically in the Makefiles, that's why I went through the work of setting up the intermediate target. Trying your version locally fails. >>> >>> Turns out this second version doesn't work either. One of my >>> branches had the first version of the fix in it. FWIW, the >>> first thing I tried was the following, but it didn't seem like >>> the right approach--though it does work correctly: >> How do you reproduce the failure on your system? I've been building with >> -j8 and higher for a long time now without seeing anything from >> toolchain/ being built before tools/ > > That's exactly what I do (except I use 4 jobs), but I see it descend > into toolchain first (well, after doing some other setup), and it > breaks when trying to setup the kernel headers. I did find it > slightly easier to reproduce with `make -j4 toolchain/install` after a > `make dirclean`: How about this patch? diff --git a/toolchain/Makefile b/toolchain/Makefile index 36c6ed3..7f8d62f 100644 --- a/toolchain/Makefile +++ b/toolchain/Makefile @@ -74,7 +74,7 @@ endif # prerequisites for the individual targets $(curdir)/ := .config prereq -$(curdir)//prepare = $(STAGING_DIR)/.prepared $(TOOLCHAIN_DIR)/info.mk +$(curdir)//prepare = $(STAGING_DIR)/.prepared $(TOOLCHAIN_DIR)/info.mk $(tools/stamp-install) $(curdir)//compile = $(1)/prepare $(curdir)//install = $(1)/compile ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][RESEND] [tools] toolchain: ensure tools are built and staged before preparing toolchain
On Sat, Dec 13, 2014 at 6:08 AM, Felix Fietkau wrote: [snip] > How about this patch? > > diff --git a/toolchain/Makefile b/toolchain/Makefile > index 36c6ed3..7f8d62f 100644 > --- a/toolchain/Makefile > +++ b/toolchain/Makefile > @@ -74,7 +74,7 @@ endif > > # prerequisites for the individual targets > $(curdir)/ := .config prereq > -$(curdir)//prepare = $(STAGING_DIR)/.prepared $(TOOLCHAIN_DIR)/info.mk > +$(curdir)//prepare = $(STAGING_DIR)/.prepared $(TOOLCHAIN_DIR)/info.mk > $(tools/stamp-install) > $(curdir)//compile = $(1)/prepare > $(curdir)//install = $(1)/compile This works! Thank you. -John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips:Add support for Aigale Ai-BR100
2014-12-13 15:04 GMT+08:00 Yousong Zhou : > > Hi, gch > > On 13 December 2014 at 10:41, 郭传鈜 wrote: > > Aigale Ai-BR100 is a router with mt7620a soc. > > There are only 2 lights on the board (WAN and WLAN) so I used the wlan > > light as the status led. > > > > IIRC, there are 3 LEDs, but one of them is for power supply indication > and cannot be controlled with software :) > > > Signed-off-by: 郭传鈜 > > --- > > target/linux/ramips/base-files/etc/board.d/01_leds | 4 + > > .../linux/ramips/base-files/etc/board.d/02_network | 1 + > > target/linux/ramips/base-files/etc/diag.sh | 3 + > > target/linux/ramips/base-files/lib/ramips.sh | 3 + > > .../ramips/base-files/lib/upgrade/platform.sh | 1 + > > target/linux/ramips/dts/AIBR100.dts| 106 > > + > > target/linux/ramips/image/Makefile | 3 + > > target/linux/ramips/mt7620/profiles/aigale.mk | 20 > > 8 files changed, 141 insertions(+) > > create mode 100644 target/linux/ramips/dts/AIBR100.dts > > create mode 100644 target/linux/ramips/mt7620/profiles/aigale.mk > > > > > > > diff --git a/target/linux/ramips/image/Makefile > > b/target/linux/ramips/image/Makefile > > index e0eb8c2..c5478ce 100644 > > --- a/target/linux/ramips/image/Makefile > > +++ b/target/linux/ramips/image/Makefile > > @@ -770,6 +770,8 @@ Image/Build/Profile/MT7620a=$(call > > BuildFirmware/Default8M/$(1),$(1),mt7620a,MT7 > > Image/Build/Profile/MT7620a_MT7610e=$(call > > BuildFirmware/Default8M/$(1),$(1),mt7620a_mt7610e,MT7620a_MT7610e) > > Image/Build/Profile/MT7620a_MT7530=$(call > > BuildFirmware/Default8M/$(1),$(1),mt7620a_mt7530,MT7620a_MT7530) > > Image/Build/Profile/MT7620a_V22SG=$(call > > BuildFirmware/Default8M/$(1),$(1),mt7620a_v22sg,MT7620a_V22SG) > > +br100_mtd_size=8126464 > > +Image/Build/Profile/AIBR100=$(call > > BuildFirmware/CustomFlash/$(1),$(1),ai-br100,AIBR100,$(br100_mtd_size),Ai-BR) > > Hmm, I remembered that I had to use an initramfs image for OEM > installation since boa HTTP server of the OEM firmware uses file size > of uploaded firmware instead of ih_size in the uimage header to do CRC > checksum. > Sorry,I don't know how the image is checked :-( > > Image/Build/Profile/RP-N53=$(call > > BuildFirmware/Default8M/$(1),$(1),rp_n53,RP-N53) > > whr_300hp2_mtd_size=7012352 > > Image/Build/Profile/WHR300HP2=$(call > > BuildFirmware/CustomFlash/$(1),$(1),whr-300hp2,WHR-300HP2,$(whr_300hp2_mtd_size)) > > @@ -799,6 +801,7 @@ define Image/Build/Profile/Default > > $(call Image/Build/Profile/MT7620a_MT7610e,$(1)) > > $(call Image/Build/Profile/MT7620a_MT7530,$(1)) > > $(call Image/Build/Profile/MT7620a_V22SG,$(1)) > > + $(call Image/Build/Profile/AIBR100,$(1)) > > $(call Image/Build/Profile/RP-N53,$(1)) > > $(call Image/Build/Profile/DIR-810L,$(1)) > > $(call Image/Build/Profile/WHR300HP2,$(1)) > > diff --git a/target/linux/ramips/mt7620/profiles/aigale.mk > > b/target/linux/ramips/mt7620/profiles/aigale.mk > > new file mode 100644 > > index 000..e58ac43 > > --- /dev/null > > +++ b/target/linux/ramips/mt7620/profiles/aigale.mk > > @@ -0,0 +1,20 @@ > > +# > > +# Copyright (C) 2014 OpenWrt.org > > +# > > +# This is free software, licensed under the GNU General Public License v2. > > +# See /LICENSE for more information. > > +# > > + > > +define Profile/AIBR100 > > + NAME:=Aigale Ai-BR100 > > + PACKAGES:=\ > > + kmod-usb-core \ > > + kmod-usb-ohci \ > > + kmod-ledtrig-usbdev \ > > + kmod-usb2 > > +endef > > kmod-ledtrig-usbdev should be optional. > > >yousong ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for qca956x soc
On 2014-12-12 16:13, Weijie Gao wrote: > This patch adds soc support for QCA9561 and TP9343. > TP9343 is a reduced version of QCA9561, which can be found in TP-LINK routers > in China. > The qca956x_wmac has not yet been supported by ath9k. > > tested on TL-WDR6500 and TL-WR882N v1 (Chinese version) > > Signed-off-by: Weijie Gao At a first glance, this patch looks good, though I'm a bit surprised about the odd chip name TP9343, which I can't find many mentions of. What codebase is this patch based on? Can I find a public kernel source somewhere? Thanks, - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for qca956x soc
在 2014/12/13 23:16, Felix Fietkau 写道: > On 2014-12-12 16:13, Weijie Gao wrote: >> This patch adds soc support for QCA9561 and TP9343. >> TP9343 is a reduced version of QCA9561, which can be found in TP-LINK >> routers in China. >> The qca956x_wmac has not yet been supported by ath9k. >> >> tested on TL-WDR6500 and TL-WR882N v1 (Chinese version) >> >> Signed-off-by: Weijie Gao > At a first glance, this patch looks good, though I'm a bit surprised > about the odd chip name TP9343, which I can't find many mentions of. > What codebase is this patch based on? Can I find a public kernel source > somewhere? > > Thanks, > > - Felix Hi, I uses the QSDK open-source found in https://www.codeaurora.org/xwiki/bin/QSDK/WebHome. Most of the QCA956X source codes are from this website. I have disassembled the uboot of a TP9343's factory fimware, and found it is nearly the same as the QCA956X except that it does not have USB and PCIe interfaces. There is no reference code of TP9343, so I wrote its support myself. Pictures of TP9343 SoC can be found here: http://www.right.com.cn/forum/thread-143640-1-1.html Weijie ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v4 4/4] kernel: 3.18: Strip off all the useless options
On Fri, Dec 12, 2014 at 06:45:06PM +0100, Jonas Gorski wrote: > On Fri, Dec 12, 2014 at 5:02 PM, Maxime Ripard > wrote: > > Now that we use the defconfigs, we can remove all the options at their > > default > > value. > > This causes a lot of kernel-config changes for e.g bcm63xx_smp with > 3.18, several of which are unwanted (e.g. enabling of the FPU > emulator). > > How did you determine which of these symbols were unneeded? I let Kconfig do that job. The only thing I did was copying the old config-3.18 as .config, and did a make savedefconfig. If somethings are missing, they're probably enabled either in your target config-3.18 or through the openwrt code itself. > > Here a diff of the resulting .config with patches 1-3 applied > (before), and with patch 4 in addition applied (after) > > --- config-3.18-before 2014-12-12 18:39:08.385702153 +0100 > +++ config-3.18-after 2014-12-12 18:33:58.197708840 +0100 > @@ -167,9 +167,9 @@ > # CONFIG_PREEMPT is not set > # CONFIG_KEXEC is not set > # CONFIG_CRASH_DUMP is not set > -# CONFIG_SECCOMP is not set > +CONFIG_SECCOMP=y That one is odd. It's probably because SECCOMP has a default y on MIPS, and I used an ARM configured kernel. > CONFIG_MIPS_O32_FP64_SUPPORT=y > -# CONFIG_MIPS_FPU_EMULATOR is not set > +CONFIG_MIPS_FPU_EMULATOR=y Same thing here. > CONFIG_USE_OF=y > CONFIG_BOOT_RAW=y > CONFIG_LOCKDEP_SUPPORT=y > @@ -262,7 +262,7 @@ > # CONFIG_KALLSYMS_UNCOMPRESSED is not set > CONFIG_BPF=y > CONFIG_EXPERT=y > -# CONFIG_SGETMASK_SYSCALL is not set > +CONFIG_SGETMASK_SYSCALL=y Ditto. > # CONFIG_SYSFS_SYSCALL is not set > # CONFIG_SYSCTL_SYSCALL is not set > CONFIG_KALLSYMS=y > @@ -276,7 +276,7 @@ > CONFIG_SIGNALFD=y > CONFIG_TIMERFD=y > CONFIG_EVENTFD=y > -CONFIG_BPF_SYSCALL=y > +# CONFIG_BPF_SYSCALL is not set Hmmm, that symbol seem to have been introduced in 3.18-rc3. I probably used an earlier kernel. > CONFIG_SHMEM=y > # CONFIG_AIO is not set > # CONFIG_ADVISE_SYSCALLS is not set > @@ -311,6 +311,7 @@ > CONFIG_HAVE_ARCH_JUMP_LABEL=y > CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y > CONFIG_HAVE_ARCH_SECCOMP_FILTER=y > +CONFIG_SECCOMP_FILTER=y Same as SECCOMP I guess. > CONFIG_HAVE_CC_STACKPROTECTOR=y > # CONFIG_CC_STACKPROTECTOR is not set > CONFIG_CC_STACKPROTECTOR_NONE=y > @@ -406,7 +407,11 @@ > # > CONFIG_PCIEPORTBUS=y > # CONFIG_PCIEAER is not set > -# CONFIG_PCIEASPM is not set > +CONFIG_PCIEASPM=y Ditto. > +# CONFIG_PCIEASPM_DEBUG is not set > +CONFIG_PCIEASPM_DEFAULT=y > +# CONFIG_PCIEASPM_POWERSAVE is not set > +# CONFIG_PCIEASPM_PERFORMANCE is not set > CONFIG_MMU=y > # CONFIG_PCCARD is not set > # CONFIG_HOTPLUG_PCI is not set > @@ -418,7 +423,7 @@ > # > CONFIG_BINFMT_ELF=y > CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y > -# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set > +CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y Another default y option > CONFIG_BINFMT_SCRIPT=y > # CONFIG_HAVE_AOUT is not set > # CONFIG_BINFMT_MISC is not set > @@ -528,7 +533,7 @@ > CONFIG_NETFILTER=y > # CONFIG_NETFILTER_DEBUG is not set > CONFIG_NETFILTER_ADVANCED=y > -# CONFIG_BRIDGE_NETFILTER is not set > +CONFIG_BRIDGE_NETFILTER=y This one seems to be enforced by the netfilter module. > # > # Core Netfilter Configuration > @@ -636,6 +641,7 @@ > CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m > # CONFIG_NETFILTER_XT_MATCH_NFACCT is not set > # CONFIG_NETFILTER_XT_MATCH_OWNER is not set > +# CONFIG_NETFILTER_XT_MATCH_PHYSDEV is not set > # CONFIG_NETFILTER_XT_MATCH_PKTTYPE is not set > # CONFIG_NETFILTER_XT_MATCH_QUOTA is not set > # CONFIG_NETFILTER_XT_MATCH_RATEEST is not set > @@ -657,7 +663,7 @@ > # > CONFIG_NF_DEFRAG_IPV4=m > CONFIG_NF_CONNTRACK_IPV4=m > -# CONFIG_NF_CONNTRACK_PROC_COMPAT is not set > +CONFIG_NF_CONNTRACK_PROC_COMPAT=y default y > # CONFIG_NF_LOG_ARP is not set > CONFIG_NF_LOG_IPV4=m > CONFIG_NF_REJECT_IPV4=m > @@ -966,7 +972,7 @@ > # > # CONFIG_MTD_LPDDR is not set > CONFIG_MTD_SPI_NOR=y > -# CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set > +CONFIG_MTD_SPI_NOR_USE_4K_SECTORS=y Ditto. > # CONFIG_MTD_UBI is not set > CONFIG_DTC=y > CONFIG_OF=y > @@ -1201,7 +1207,9 @@ > # CONFIG_FORCEDETH is not set > CONFIG_NET_VENDOR_OKI=y > # CONFIG_ETHOC is not set > -# CONFIG_NET_PACKET_ENGINE is not set > +CONFIG_NET_PACKET_ENGINE=y > +# CONFIG_HAMACHI is not set > +# CONFIG_YELLOWFIN is not set Again... > CONFIG_NET_VENDOR_QLOGIC=y > # CONFIG_QLA3XXX is not set > # CONFIG_QLCNIC is not set > @@ -1304,9 +1312,9 @@ > CONFIG_PPP=m > # CONFIG_PPP_BSDCOMP is not set > # CONFIG_PPP_DEFLATE is not set > -CONFIG_PPP_FILTER=y > +# CONFIG_PPP_FILTER is not set > # CONFIG_PPP_MPPE is not set > -CONFIG_PPP_MULTILINK=y > +# CONFIG_PPP_MULTILINK is not set > CONFIG_PPPOE=m > CONFIG_PPP_ASYNC=m > # CONFIG_PPP_SYNC_TTY is not set > @@ -1345,7 +1353,10 @@ > # > # Userland interfaces > # > -# CONFIG_INPUT_MOUSEDEV is not set > +CONFIG_INPUT_MOUSEDEV=m > +CONFIG_INPUT_MOUSEDEV_PSAUX=y > +CONFIG_IN
[OpenWrt-Devel] rootfs_data on separated flash
Hi, this partially a continuation of the "Some standard partition name for extra user data?" thread. Summary: 1) I have device with serial flash (16 MiB) and NAND flash (128 MiB). 2) Serial flash contains 2 partitions: "bootloader" and "firmware". 3) Bootloader writes supplied image to the "firmware" partition. 4) I want to use NAND flash for UBI with "rootfs_data" volume. Of course standard OpenWrt image contains: kernel + rootfs (SquashFS) + JFFS2 mark To support my device I would need to: 1) Stop "squashfs-split" (mtdsplit_squashfs.c) from creating "rootfs_data" right after "rootfs". I could modify mtdsplit_squashfs.c to understand some new mark like a "DONT_SPLIT" (similar to the 0xdeadc0de mark for JFFS2). 2) Add some preinit script that will prepare UBI on NAND (as bootloader won't help me). The tricky part is cleaning UBI's "rootfs_data" volume after every firmware flash. I would need some trick to detect if "rootfs_data" was already erased once or not. Maybe I could use some marks again? Something like a) "DONT_SPLIT FIRSTBOOT" b) "DONT_SPLIT UBIREADY" ? What do you think about this? -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Can we have "init" call for diag.sh (set_state)?
On 11 December 2014 at 21:17, John Crispin wrote:
> On 11/12/2014 20:59, Rafał Miłecki wrote:
>> Let me simplify booting process into following stages:
>> 1) preinit (LED blinking with medium freq)
>> 2) init (LED blinking with medium freq)
>> 3) done (LED state on)
>>
>> The problem is this duplicated "medium freq" and that diag.sh
>> (set_state) has only two of above stages:
>> 1) preinit
>> 2) done
>> So we can't signal that OpenWrt went from preinit to init and e.g.
>> failsafe is not accessible anymore.
>>
>> Could we change it? Is that OK if we add something like
>> init)
>> status_led_blink_init
>> with some low blinking frequency?
>>
>> The purpose of that is to let user know it's too late for entering a
>> failsafe mode.
>>
>
> sure sound like a good idea, wanna cook a patch ?
Sure. I played with it a bit, and there is one thing I'm not sure about.
1) Technically
It makes more sense to change change LED blinking when OpenWrt enters
"init" stage (after "preinit"). That would simply require
START=00
boot() {
set_state init
}
in the /etc/init.d/setstate
2) Practically
For user it makes more sense to know when the failsafe mode can (not)
be entered. This would simply require
set_state preinit_post_failsafe_wait
at the end of /lib/preinit/30_failsafe_wait
Which would be better to implement?
--
Rafał
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH][ar71xx] Mikrotik Routerboard RB2011 switch fix
This patch is the same as the Routerboard 951G fix, I've built this and tested it on my rb-2011uias-2hnd. However we should check that it also works on other/older RB2011 routers which did work OK with the unpatched code. diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-rb2011.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-rb2011.c index b73fae6..951ab94 100644 --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-rb2011.c +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-rb2011.c @@ -270,6 +270,7 @@ static int __init rb2011_setup(u32 flags) rb2011_nand_init(); ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0 | + AR934X_ETH_CFG_RXD_DELAY | AR934X_ETH_CFG_SW_ONLY_MODE); ath79_register_mdio(1, 0x0); @@ -283,7 +284,7 @@ static int __init rb2011_setup(u32 flags) ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII; ath79_eth0_data.phy_mask = BIT(0); ath79_eth0_data.mii_bus_dev = &ath79_mdio0_device.dev; - ath79_eth0_pll_data.pll_1000 = 0x0600; + ath79_eth0_pll_data.pll_1000 = 0x3e00; ath79_register_eth(0); -- Chris Green ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v4 4/4] kernel: 3.18: Strip off all the useless options
On Sat, Dec 13, 2014 at 5:03 PM, Maxime Ripard wrote: > On Fri, Dec 12, 2014 at 06:45:06PM +0100, Jonas Gorski wrote: >> On Fri, Dec 12, 2014 at 5:02 PM, Maxime Ripard >> wrote: >> > Now that we use the defconfigs, we can remove all the options at their >> > default >> > value. >> >> This causes a lot of kernel-config changes for e.g bcm63xx_smp with >> 3.18, several of which are unwanted (e.g. enabling of the FPU >> emulator). >> >> How did you determine which of these symbols were unneeded? > > I let Kconfig do that job. > > The only thing I did was copying the old config-3.18 as .config, and > did a make savedefconfig. > > If somethings are missing, they're probably enabled either in your > target config-3.18 or through the openwrt code itself. > >> >> Here a diff of the resulting .config with patches 1-3 applied >> (before), and with patch 4 in addition applied (after) >> >> --- config-3.18-before 2014-12-12 18:39:08.385702153 +0100 >> +++ config-3.18-after 2014-12-12 18:33:58.197708840 +0100 >> @@ -167,9 +167,9 @@ >> # CONFIG_PREEMPT is not set >> # CONFIG_KEXEC is not set >> # CONFIG_CRASH_DUMP is not set >> -# CONFIG_SECCOMP is not set >> +CONFIG_SECCOMP=y > > That one is odd. It's probably because SECCOMP has a default y on > MIPS, and I used an ARM configured kernel. [snip uninteresting remainder of diff] > Ok, I think most of it is because of options enabled by default. I > wonder why that happens, but I also wonder why it hasn't been picked > up by my tests. I already somewhat expected that. So make savedefconfig then likely dropped any non-generic non-arm config symbols regardless whether they are at their default or non-default values, causing these discrepancies on non-arm targets. The safest would be to create the reduced config-* as the union of all target's savedefconfig results, but only using one for each ARCH might also suffice. > What configuration are you using? Do you have any modifications of > some sort (beside the switch to 3.18?) All I did was switch to 3.18, then did a make target/linux/compile (so it generated and "cleaned up" the .config in build_dir/target-*/linux-*/). I might have a few non-default values in the openwrt-buildroot config, but I did not have any local patches applied. One other thing I just noticed: this currently makes "make kernel_*config" unusable. "make kernel_oldconfig" will ask about about everything that is at its defaultvalue, while finishing any *config will result all default values to be added to the config-* in target/linux//. This might be easily fixable by running make savedefconfig first before the openwrt scripts create the difference from the generic config-* and the new .config for the new target config-* Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3 1/2] [boot/uboot-kirkwood] Pogoplug v4 support
Add support for Pogoplug v4 devices to uboot-kirkwood. This version of
the patch works with the 2014.10 version of uboot which did away with
boards.cfg.
This is almost entirely based on mibodhi's work at
https://github.com/mibodhi/u-boot-kirkwood . All I did was tweak it and
bring it over to the new world order of uboot and hook it into openwrt's
build system.
Signed-off-by: Nathaniel Wesley Filardo
<8s9k8ugo5jgpi3u067229bbackmqi...@cmx.ietfng.org>
diff --git a/package/boot/uboot-kirkwood/Makefile
b/package/boot/uboot-kirkwood/Makefile
index 89caaf1..9bacda3 100644
--- a/package/boot/uboot-kirkwood/Makefile
+++ b/package/boot/uboot-kirkwood/Makefile
@@ -66,6 +66,10 @@ define uboot/pogo_e02_second_stage
TITLE:=second stage U-Boot for Cloud Engines Pogoplug E02
endef
+define uboot/pogo_v4
+ TITLE:=U-Boot for Cloud Engines Pogoplug V4
+endef
+
define uboot/sheevaplug
TITLE:=U-Boot for SheevaPlug
endef
@@ -75,7 +79,7 @@ UBOOTS:= \
goflexhome \
ib62x0 ib62x0_second_stage \
iconnect iconnect_second_stage \
- pogo_e02 pogo_e02_second_stage \
+ pogo_e02 pogo_e02_second_stage pogo_v4 \
sheevaplug
define Package/uboot/template
diff --git a/package/boot/uboot-kirkwood/patches/010-kirkwood_mmc.patch
b/package/boot/uboot-kirkwood/patches/010-kirkwood_mmc.patch
new file mode 100644
index 000..238b714
--- /dev/null
+++ b/package/boot/uboot-kirkwood/patches/010-kirkwood_mmc.patch
@@ -0,0 +1,785 @@
+diff -uNwr /dev/null b/drivers/mmc/kirkwood_mmc.c
+--- /dev/null 1969-12-31 19:00:00.0 -0500
b/drivers/mmc/kirkwood_mmc.c 2014-11-28 01:11:29.681477900 -0500
+@@ -0,0 +1,480 @@
++/*
++ * (C) Copyright 2014 bodhi
++ *
++ * Based on
++ *
++ * (C) Copyright 2014
++ *
++ * Based on
++ *
++ * Driver for Marvell SDIO/MMC controller
++ *
++ * (C) Copyright 2012
++ * Marvell Semiconductor
++ * Written-by: Gérald Kerma
++ * See file CREDITS for list of people who contributed to this
++ * project.
++ *
++ * This program is free software; you can redistribute it and/or
++ * modify it under the terms of the GNU General Public License as
++ * published by the Free Software Foundation; either version 2 of
++ * the License, or (at your option) any later version.
++ *
++ * This program is distributed in the hope that it will be useful,
++ * but WITHOUT ANY WARRANTY; without even the implied warranty of
++ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
++ * GNU General Public License for more details.
++ *
++ * You should have received a copy of the GNU General Public License
++ * along with this program; if not, write to the Free Software
++ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
++ * MA 02111-1307 USA
++ */
++
++#include
++#include
++#include
++#include
++#include
++#include
++#include
++
++#include
++
++#define DRIVER_NAME "kwsdio"
++
++static int kw_mmc_setup_data(struct mmc_data *data)
++{
++ u32 ctrl_reg;
++
++#ifdef DEBUG
++ printf("%s, data %s : blocks=%d blksz=%d\n", DRIVER_NAME,
++ (data->flags & MMC_DATA_READ) ? "read" : "write",
++ data->blocks, data->blocksize);
++#endif
++
++ /* default to maximum timeout */
++ ctrl_reg = kwsd_read(SDIO_HOST_CTRL);
++ ctrl_reg |= SDIO_HOST_CTRL_TMOUT(SDIO_HOST_CTRL_TMOUT_MAX);
++ kwsd_write(SDIO_HOST_CTRL, ctrl_reg);
++
++ if (data->flags & MMC_DATA_READ) {
++ kwsd_write(SDIO_SYS_ADDR_LOW,(u32)data->dest & 0x);
++ kwsd_write(SDIO_SYS_ADDR_HI,(u32)data->dest >> 16);
++ } else {
++ kwsd_write(SDIO_SYS_ADDR_LOW,(u32)data->src & 0x);
++ kwsd_write(SDIO_SYS_ADDR_HI,(u32)data->src >> 16);
++ }
++
++ kwsd_write(SDIO_BLK_COUNT, data->blocks);
++ kwsd_write(SDIO_BLK_SIZE, data->blocksize);
++
++ return 0;
++}
++
++static int kw_mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, struct
mmc_data *data)
++{
++ int timeout = 10;
++ int err;
++ ushort waittype = 0;
++ ushort resptype = 0;
++ ushort xfertype = 0;
++ ushort resp_indx = 0;
++
++#ifdef CONFIG_MMC_DEBUG
++ printf("cmdidx [0x%x] resp_type[0x%x] cmdarg[0x%x]\n", cmd->cmdidx,
cmd->resp_type, cmd->cmdarg);
++#endif
++
++ udelay(1);
++
++#ifdef CONFIG_MMC_DEBUG
++ printf("%s: cmd %d (hw state 0x%04x)\n", DRIVER_NAME, cmd->cmdidx,
kwsd_read(SDIO_HW_STATE));
++#endif
++
++ /* Checking if card is busy */
++ while ((kwsd_read(SDIO_HW_STATE) & CARD_BUSY)) {
++ if (timeout == 0) {
++ printf("%s: card busy!\n", DRIVER_NAME);
++ return -1;
++ }
++ timeout--;
++ udelay(1000);
++ }
++
++ /* Set up for a data transfer if we have one */
++ if (data) {
++ if ((err = kw_mmc_setup_data(data)))
++ return err;
++ }
++
++ resptype = SDIO_CMD_INDEX(cmd->cmdidx);
++
++ /* Ana
Re: [OpenWrt-Devel] [PATCH] [package] fstools: make extroot functionality work with ubifs
Hi John,
thanks for your comments!
I'm about to fix the issues you mentioned and repost the patch soon.
Regards,
Gergely
On 13 December 2014 at 08:23, John Crispin wrote:
> Hi,
>
> thanks for the patch, code looks good however
>
> * the patch is whitespace mangled and line broken.
> * this will build always build with ubi support even if the target has
> no UBI. please add a config option so that is selectable whether ubi is
> enabled.
>
> John
>
> On 13/12/2014 00:43, Gergely Kiss wrote:
>> From: Gergely Kiss
>>
>> Fix extroot functionality for devices where rootfs is on a ubifs partition
>>
>> Signed-off-by: Gergely Kiss
>> Tested-by: Gergely Kiss
>> ---
>> Originally created by forum user "Hiro.AK47" for the 14.07 branch.
>> I've created a new diff to make it work with the master branch.
>>
>> Tested on a Netgear WNDR4300 router, working fine in both overlay and
>> pivot root modes.
>>
>> diff -rupN fstools.old/block.c fstools.new/block.c
>> --- fstools.old/block.c2014-12-12 17:32:23.833641055 +0100
>> +++ fstools.new/block.c2014-12-12 17:36:59.532478289 +0100
>> @@ -35,6 +35,7 @@
>> #include
>>
>> #include "libblkid-tiny/libblkid-tiny.h"
>> +#include "libubi/libubi.h"
>>
>> #define ERROR(fmt, ...) do { \
>> syslog(LOG_ERR, fmt, ## __VA_ARGS__); \
>> @@ -823,13 +824,70 @@ static int find_block_mtd(char *name, ch
>> return 0;
>> }
>>
>> +static int find_ubi_vol(libubi_t libubi, char *name, int *dev_num, int
>> *vol_id)
>> +{
>> + int dev = 0;
>> +
>> + while (ubi_dev_present(libubi, dev))
>> + {
>> + struct ubi_dev_info dev_info;
>> + struct ubi_vol_info vol_info;
>> +
>> + if (ubi_get_dev_info1(libubi, dev++, &dev_info))
>> + continue;
>> + if (ubi_get_vol_info1_nm(libubi, dev_info.dev_num,
>> name, &vol_info))
>> + continue;
>> +
>> + *dev_num = dev_info.dev_num;
>> + *vol_id = vol_info.vol_id;
>> +
>> + return 0;
>> + }
>> +
>> + return -1;
>> +}
>> +
>> +static int find_block_ubi(libubi_t libubi, char *name, char *part, int plen)
>> +{
>> + int dev_num;
>> + int vol_id;
>> + int err = -1;
>> +
>> + err = find_ubi_vol(libubi, name, &dev_num, &vol_id);
>> + if (!err)
>> + snprintf(part, plen, "/dev/ubi%d_%d", dev_num, vol_id);
>> +
>> + return err;
>> +}
>> +
>> +static int find_block_ubi_RO(libubi_t libubi, char *name, char *part, int
>> plen)
>> +{
>> + int dev_num;
>> + int vol_id;
>> + int err = -1;
>> +
>> + err = find_ubi_vol(libubi, name, &dev_num, &vol_id);
>> + if (!err)
>> + snprintf(part, plen, "/dev/ubiblock%d_%d", dev_num, vol_id);
>> +
>> + return err;
>> +}
>> +
>> static int check_extroot(char *path)
>> {
>> struct blkid_struct_probe *pr = NULL;
>> char fs[32];
>>
>> -if (find_block_mtd("rootfs", fs, sizeof(fs)))
>> -return -1;
>> + if (find_block_mtd("rootfs", fs, sizeof(fs))) {
>> + int err = -1;
>> + libubi_t libubi;
>> +
>> + libubi = libubi_open();
>> + err = find_block_ubi_RO(libubi, "rootfs", fs, sizeof(fs));
>> + libubi_close(libubi);
>> + if (err)
>> + return -1;
>> + }
>>
>> list_for_each_entry(pr, &devices, list) {
>> if (!strcmp(pr->dev, fs)) {
>> @@ -933,6 +991,7 @@ static int main_extroot(int argc, char *
>> char fs[32] = { 0 };
>> char fs_data[32] = { 0 };
>> int err = -1;
>> +libubi_t libubi;
>>
>> if (!getenv("PREINIT"))
>> return -1;
>> @@ -947,8 +1006,13 @@ static int main_extroot(int argc, char *
>>
>> find_block_mtd("rootfs", fs, sizeof(fs));
>> if (!fs[0]) {
>> -ERROR("extroot: unable to locate rootfs mtdblock\n");
>> -return -2;
>> + libubi = libubi_open();
>> + find_block_ubi_RO(libubi, "rootfs", fs, sizeof(fs));
>> + libubi_close(libubi);
>> + if (!fs[0]) {
>> + ERROR("extroot: unable to locate rootfs
>> mtdblock / ubiblock\n");
>> + return -2;
>> + }
>> }
>>
>> pr = find_block_info(NULL, NULL, fs);
>> @@ -975,6 +1039,24 @@ static int main_extroot(int argc, char *
>> }
>> }
>>
>> + memset(fs_data, 0, sizeof(fs_data));
>> + libubi = libubi_open();
>> + find_block_ubi(libubi, "rootfs_data", fs_data, sizeof(fs_data));
>> + libubi_close(libubi);
>> + if (fs_data[0]) {
>> + char cfg[] = "/tmp/ubifs_cfg";
>> +
>> + mkdir_p(cfg);
>> + if (!mount(fs_data, cfg, "ubifs", MS_NOATIME, NULL)) {
>> + err = mount_extroot(cfg);
>> + umount2(cfg, MNT_DETACH);
>> + }
>> + if (err
Re: [OpenWrt-Devel] kirkwood gcc/binutils woe?
On Wed, Dec 10, 2014 at 10:12:53PM +0100, Harald Geyer wrote:
> Hi!
>
> I ran into the same issue just a few days ago on mxs. Probably most,
> if not all arm targets are affected.
Applying your patch does, indeed, get me a little closer to a working
compiler. However, when I run
$ gcc -v -o hello hello.c
[...]
/usr/lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.8.3/collect2 --eh-frame-hdr
-dynamic-linker /lib/ld-uClibc.so.0 -X -m armelf_linux_eabi -o hello
/usr/lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.8.3/crt1.o
/usr/lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.8.3/crti.o
/usr/lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.8.3/crtbegin.o
-L/usr/lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.8.3
-L/usr/lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.8.3/../../.. /tmp/ccjOqw9X.o
-lgcc_s -lc -lgcc_s /usr/lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.8.3/crtend.o
/usr/lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.8.3/crtn.o
/usr/bin/ld: cannot find -lgcc
collect2: error: ld returned 1 exit status
Well, yes, that's true...
$ find / -name \*libgcc\*
/lib/libgcc_s.so.1
/usr/lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.8.3/libgcc_s.so.1
/usr/lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.8.3/libgcc_s.so
/usr/lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.8.3/libgcc.map
/usr/lib/opkg/info/libgcc.list
/usr/lib/opkg/info/libgcc.control
Grepping about at random I find that
/usr/lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.8.3/libgcc_s.so contains the
directive
> GROUP ( libgcc_s.so.1 -lgcc )
So I think the desire to save space expressed in
feeds/packages/devel/gcc/README is well-intentioned but possibly stale, so
maybe the following, too? Maybe we should be removing libgcc_pic.a but not
libgcc.a?
diff --git a/devel/gcc/Makefile b/devel/gcc/Makefile
index c8d8733..8966955 100644
--- a/devel/gcc/Makefile
+++ b/devel/gcc/Makefile
@@ -106,7 +106,6 @@ define Package/gcc/install
ln -s $(REAL_GNU_TARGET_NAME)-gcc $(1)/usr/bin/gcc
ln -s $(REAL_GNU_TARGET_NAME)-gcc
$(1)/usr/bin/$(REAL_GNU_TARGET_NAME)-gcc-$(PKG_VERSION)
cp -ar $(PKG_INSTALL_DIR)/usr/lib/gcc $(1)/usr/lib
- $(RM)
$(1)/usr/lib/$(PKG_NAME)/$(REAL_GNU_TARGET_NAME)/$(PKG_VERSION)/*.a
cp -ar $(TOOLCHAIN_DIR)/include
$(1)/usr/lib/$(PKG_NAME)/$(REAL_GNU_TARGET_NAME)/$(PKG_VERSION)
cp -a $(TOOLCHAIN_DIR)/lib/*.{o,so*}
$(1)/usr/lib/$(PKG_NAME)/$(REAL_GNU_TARGET_NAME)/$(PKG_VERSION)
cp -a $(TOOLCHAIN_DIR)/lib/*nonshared*.a
$(1)/usr/lib/$(PKG_NAME)/$(REAL_GNU_TARGET_NAME)/$(PKG_VERSION)
diff --git a/devel/gcc/README b/devel/gcc/README
index 6cbc80d..828bd28 100644
--- a/devel/gcc/README
+++ b/devel/gcc/README
@@ -1,8 +1,5 @@
Native GCC that runs on target.
-To save disk space, this GCC only supports dynamic linking on the target box,
-there are no static libraries shipped.
-
For now, this was only tested on a mips target. Others to be done...
- Christian Beier
\ No newline at end of file
+ Christian Beier
Thanks for your help so far!
--nwf;
> nwf writes:
> > > root@OpenWrt:/tmp# gcc -o hello hello.c
> > > /usr/bin/ld: unrecognised emulation mode: armelf_linux_eabi
> > > Supported emulations: armelf_linux armelf armelfb armelfb_linux
> > > collect2: error: ld returned 1 exit status
> >
> > And I'm really not sure what that means or what to do about it.
>
> Looks like binutils is built for OABI while gcc is built for EABI.
> Since at least mxs is actually using EABI I think gcc is right and
> binutils is wrong.
>
> Try if the following patch solves the problem. (Don't have my test
> board around right now.)
>
> diff --git a/package/devel/binutils/Makefile b/package/devel/binutils/Makefile
> index ff968b9..4aefeca 100644
> --- a/package/devel/binutils/Makefile
> +++ b/package/devel/binutils/Makefile
> @@ -48,6 +48,8 @@ endef
> TARGET_CFLAGS += $(FPIC) -Wno-unused-value
>
> CONFIGURE_ARGS += \
> + --host=$(REAL_GNU_TARGET_NAME) \
> + --target=$(REAL_GNU_TARGET_NAME) \
> --enable-shared \
> --enable-install-libiberty \
> --enable-install-libbfd
>
> HTH,
> Harald
pgpQouquLePi9.pgp
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Should these UCI defaults be the same for all Mikrotik RB2011 variants?
In the UCI defaults:- build_dir/target-mips_34kc_uClibc-0.9.33.2/root-ar71xx/etc/uci-defaults/03_network-switchX-migration there is the following section:- db120 |\ rb-2011l | \ rb-2011uas-2hnd) migrate_switch_name "eth0" "switch0" migrate_switch_name "eth1" "switch1" ;; My RB2011's board name is rb-2011uias-2hnd so the above initialisation won't be executed. I suspect there are quite a few other names that may be generated for different models. Should they just be added as they are found or would it be better to do some sort of pattern matching? While I'm about it, what exactly does the above default setup do? My rb-2011uias-2hnd seems to work OK without it. -- Chris Green ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] kernel: mtdsplit_uimage: use more generic header verify function
Some devices have uImage headers after some extra headers (e.g. Edimax
devices). To support such cases our verify callback function should be
allowed to return header offset, not just a boolean value.
Signed-off-by: Rafał Miłecki
---
Hi Tomasz,
I was looking at the patch you submitted
PATCH [kernel]: proper support for Edimax uimages
http://patchwork.openwrt.org/patch/6555/
and was thinking about some better solution.
I didn't like the fact that you added Edimax specific workaround to the
supposed-to-be-generic __mtdsplit_parse_uimage.
So I came with the idea of modifying our callback function. With this
patch you should be able to re-write your uimage_verify_edimax to simply
return 20 instead of true.
Of course we will also need to do something like:
header_offset = find_header(buf, buf_size);
header = offset + header_offset;
---
.../generic/files/drivers/mtd/mtdsplit_uimage.c| 37 +++---
1 file changed, 26 insertions(+), 11 deletions(-)
diff --git a/target/linux/generic/files/drivers/mtd/mtdsplit_uimage.c
b/target/linux/generic/files/drivers/mtd/mtdsplit_uimage.c
index 7dad63c..2f723bd 100644
--- a/target/linux/generic/files/drivers/mtd/mtdsplit_uimage.c
+++ b/target/linux/generic/files/drivers/mtd/mtdsplit_uimage.c
@@ -71,10 +71,16 @@ read_uimage_header(struct mtd_info *mtd, size_t offset,
return 0;
}
+/**
+ * __mtdsplit_parse_uimage - scan partition and create kernel + rootfs parts
+ *
+ * @find_header: function to call for a block of data that will return offset
+ * of a valid uImage header if found
+ */
static int __mtdsplit_parse_uimage(struct mtd_info *master,
struct mtd_partition **pparts,
struct mtd_part_parser_data *data,
- bool (*verify)(struct uimage_header *hdr))
+ size_t (*find_header)(u_char *buf, size_t
len))
{
struct mtd_partition *parts;
struct uimage_header *header;
@@ -106,11 +112,16 @@ static int __mtdsplit_parse_uimage(struct mtd_info
*master,
if (ret)
continue;
- if (!verify(header)) {
+ ret = find_header((u_char *)header, sizeof(*header));
+ if (ret < 0) {
pr_debug("no valid uImage found in \"%s\" at offset
%llx\n",
master->name, (unsigned long long) offset);
continue;
}
+ if (ret > 0) {
+ pr_warn("extra header offsets are not supported yet\n");
+ continue;
+ }
uimage_size = sizeof(*header) + be32_to_cpu(header->ih_size);
if ((offset + uimage_size) > master->size) {
@@ -189,28 +200,30 @@ err_free_parts:
return ret;
}
-static bool uimage_verify_default(struct uimage_header *header)
+static size_t uimage_verify_default(u_char *buf, size_t len)
{
+ struct uimage_header *header = (struct uimage_header *)buf;
+
/* default sanity checks */
if (be32_to_cpu(header->ih_magic) != IH_MAGIC) {
pr_debug("invalid uImage magic: %08x\n",
be32_to_cpu(header->ih_magic));
- return false;
+ return -EINVAL;
}
if (header->ih_os != IH_OS_LINUX) {
pr_debug("invalid uImage OS: %08x\n",
be32_to_cpu(header->ih_os));
- return false;
+ return -EINVAL;
}
if (header->ih_type != IH_TYPE_KERNEL) {
pr_debug("invalid uImage type: %08x\n",
be32_to_cpu(header->ih_type));
- return false;
+ return -EINVAL;
}
- return true;
+ return 0;
}
static int
@@ -236,9 +249,11 @@ static struct mtd_part_parser uimage_generic_parser = {
#define FW_MAGIC_WNDR3700 0x33373030
#define FW_MAGIC_WNDR3700V20x33373031
-static bool uimage_verify_wndr3700(struct uimage_header *header)
+static size_t uimage_verify_wndr3700(u_char *buf, size_t len)
{
+ struct uimage_header *header = (struct uimage_header *)buf;
uint8_t expected_type = IH_TYPE_FILESYSTEM;
+
switch be32_to_cpu(header->ih_magic) {
case FW_MAGIC_WNR612V2:
case FW_MAGIC_WNR2000V3:
@@ -250,14 +265,14 @@ static bool uimage_verify_wndr3700(struct uimage_header
*header)
expected_type = IH_TYPE_KERNEL;
break;
default:
- return false;
+ return -EINVAL;
}
if (header->ih_os != IH_OS_LINUX ||
header->ih_type != expected_type)
- return false;
+ return -EINVAL;
- return true;
+ return 0;
}
static int
--
1.8.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https:/
Re: [OpenWrt-Devel] [PATCH][ar71xx] Routerboard 951G Switch Fix
The boot loader on these boards is routerboot. I do not know if routerboot provides a md like command or not. Sent from my iPhone > On Dec 13, 2014, at 1:01 AM, John Crispin wrote: > > Hi, > >> On 10/12/2014 22:33, Chris Green wrote: >>> On Wed, Dec 10, 2014 at 01:40:42PM -0700, Davey Hutchison wrote: >>> Fix pll_1000 value for eth0. Traffic would not flow from the eth0 >>> interface. >>> The new PLL enables delay, use ath79_setup_ar934x_eth_cfg to also enable >>> AR934X_ETH_CFG_RXD_DELAY. >>> >>> Signed-off-by: Davey Hutchison >>> >>> --- target/linux/ar71xx/files/arch/mips/ath79/mach-rb95x.c >>> +++ target/linux/ar71xx/files/arch/mips/ath79/mach-rb95x.c >>> @@ -199,6 +199,7 @@ >>>return; >>> >>>ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0 | >>> + AR934X_ETH_CFG_RXD_DELAY | >>> AR934X_ETH_CFG_SW_ONLY_MODE); >>> >>>ath79_register_mdio(0, 0x0); >>> @@ -209,6 +210,7 @@ >>>ath79_init_mac(ath79_eth0_data.mac_addr, ath79_mac_base, 0); >>>ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII; >>>ath79_eth0_data.phy_mask = BIT(0); >>> +ath79_eth0_pll_data.pll_1000 = 0x3e00; >>> >>>ath79_register_eth(0); >> >> This needs to be in mach-rb2011.c as well. > > > i will hopefully get round to looking at this today. first i could not > find my rs232 usb keyspan thingy, then i failed to find the poe injector .. > > do these board have uboot ? if so the easiest way would be to enter > uboot, start a tftp to make sure the network is configured and then use > the md command to display the relevant register. > >John > ___ > 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] [PATCH v2] uboot-envtools: enable UBI support per default on oxnas
Signed-off-by: Daniel Golle --- package/boot/uboot-envtools/Config.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/boot/uboot-envtools/Config.in b/package/boot/uboot-envtools/Config.in index 9fd8103..bd3585c 100644 --- a/package/boot/uboot-envtools/Config.in +++ b/package/boot/uboot-envtools/Config.in @@ -1,7 +1,7 @@ config UBOOT_ENVTOOLS_UBI bool "Support environment in UBI volume" depends on PACKAGE_uboot-envtools - default n + default @TARGET_oxnas help Add support for reading and writing U-Boot environment stored in UBI volume(s). -- 2.1.3 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] gemini: merge register ethernet patches into one
Signed-off-by: Roman Yeryomin
---
.../121-arm-gemini-nas4220-register-ethernet.patch | 79
.../121-arm-gemini-register-ethernet.patch | 210 +
.../122-arm-gemini-wbd111-register-ethernet.patch | 41
.../123-arm-gemini-wbd222-register-eth.patch | 43 -
.../124-arm-gemini-rut100-register-ethernet.patch | 47 -
5 files changed, 210 insertions(+), 210 deletions(-)
delete mode 100644
target/linux/gemini/patches-3.10/121-arm-gemini-nas4220-register-ethernet.patch
create mode 100644
target/linux/gemini/patches-3.10/121-arm-gemini-register-ethernet.patch
delete mode 100644
target/linux/gemini/patches-3.10/122-arm-gemini-wbd111-register-ethernet.patch
delete mode 100644
target/linux/gemini/patches-3.10/123-arm-gemini-wbd222-register-eth.patch
delete mode 100644
target/linux/gemini/patches-3.10/124-arm-gemini-rut100-register-ethernet.patch
diff --git
a/target/linux/gemini/patches-3.10/121-arm-gemini-nas4220-register-ethernet.patch
b/target/linux/gemini/patches-3.10/121-arm-gemini-nas4220-register-ethernet.patch
deleted file mode 100644
index db95648..000
---
a/target/linux/gemini/patches-3.10/121-arm-gemini-nas4220-register-ethernet.patch
+++ /dev/null
@@ -1,79 +0,0 @@
a/arch/arm/mach-gemini/board-nas4220b.c2011-04-21
13:19:09.878432930 +0200
-+++ b/arch/arm/mach-gemini/board-nas4220b.c2011-04-21
13:30:37.555082365 +0200
-@@ -28,9 +28,27 @@
-
- #include
- #include
-+#include
-
- #include "common.h"
-
-+static struct mdio_gpio_platform_data ib4220b_mdio = {
-+ .mdc= 22,
-+ .mdio = 21,
-+ .phy_mask = ~(1 << 1),
-+};
-+
-+static struct platform_device ib4220b_phy_device = {
-+ .name = "mdio-gpio",
-+ .id = 0,
-+ .dev= { .platform_data = &ib4220b_mdio, },
-+};
-+
-+static struct gemini_gmac_platform_data ib4220b_gmac_data = {
-+ .bus_id[0] = "gpio-0:01",
-+ .interface[0] = PHY_INTERFACE_MODE_RGMII,
-+};
-+
- static struct gpio_led ib4220b_leds[] = {
- {
- .name = "nas4220b:orange:hdd",
-@@ -107,9 +125,39 @@
- },
- };
-
-+static void __init ib4220b_gmac_init(void)
-+{
-+ unsigned int val;
-+
-+ val = readl((void __iomem*)(IO_ADDRESS(GEMINI_GLOBAL_BASE) +
-+ GLOBAL_IO_DRIVING_CTRL));
-+ val |= (0x3 << GMAC0_PADS_SHIFT) | (0x3 << GMAC1_PADS_SHIFT);
-+ writel(val, (void __iomem*)(IO_ADDRESS(GEMINI_GLOBAL_BASE) +
-+ GLOBAL_IO_DRIVING_CTRL));
-+
-+ val = (0x0 << GMAC0_RXDV_SKEW_SHIFT) | (0xf << GMAC0_RXC_SKEW_SHIFT) |
-+ (0x7 << GMAC0_TXEN_SKEW_SHIFT) | (0xb << GMAC0_TXC_SKEW_SHIFT) |
-+ (0x0 << GMAC1_RXDV_SKEW_SHIFT) | (0xf << GMAC1_RXC_SKEW_SHIFT) |
-+ (0x7 << GMAC1_TXEN_SKEW_SHIFT) | (0xa << GMAC1_TXC_SKEW_SHIFT);
-+ writel(val, (void __iomem*)(IO_ADDRESS(GEMINI_GLOBAL_BASE) +
-+ GLOBAL_GMAC_CTRL_SKEW_CTRL));
-+
-+ writel(0x, (void __iomem*)(IO_ADDRESS(GEMINI_GLOBAL_BASE) +
-+ GLOBAL_GMAC0_DATA_SKEW_CTRL));
-+ writel(0x, (void __iomem*)(IO_ADDRESS(GEMINI_GLOBAL_BASE) +
-+ GLOBAL_GMAC1_DATA_SKEW_CTRL));
-+
-+ val = readl((void __iomem*)(IO_ADDRESS(GEMINI_GLOBAL_BASE) +
-+ GLOBAL_ARBITRATION1_CTRL)) & ~BURST_LENGTH_MASK;
-+ val |= (0x20 << BURST_LENGTH_SHIFT) | GMAC0_HIGH_PRIO | GMAC1_HIGH_PRIO;
-+ writel(val, (void __iomem*)(IO_ADDRESS(GEMINI_GLOBAL_BASE) +
-+ GLOBAL_ARBITRATION1_CTRL));
-+}
-+
- static void __init ib4220b_init(void)
- {
- gemini_gpio_init();
-+ ib4220b_gmac_init();
- platform_register_uart();
- platform_register_pflash(SZ_16M, NULL, 0);
- platform_device_register(&ib4220b_led_device);
-@@ -96,6 +144,8 @@
- platform_device_register(&ib4220b_key_device);
- platform_register_rtc();
- platform_register_watchdog();
-+ platform_device_register(&ib4220b_phy_device);
-+ platform_register_ethernet(&ib4220b_gmac_data);
- }
-
- MACHINE_START(NAS4220B, "Raidsonic NAS IB-4220-B")
diff --git
a/target/linux/gemini/patches-3.10/121-arm-gemini-register-ethernet.patch
b/target/linux/gemini/patches-3.10/121-arm-gemini-register-ethernet.patch
new file mode 100644
index 000..d5bab9e
--- /dev/null
+++ b/target/linux/gemini/patches-3.10/121-arm-gemini-register-ethernet.patch
@@ -0,0 +1,210 @@
+--- a/arch/arm/mach-gemini/board-nas4220b.c2011-04-21
13:19:09.878432930 +0200
b/arch/arm/mach-gemini/board-nas4220b.c2011-04-21
13:30:37.555082365 +0200
+@@ -28,9 +28,27 @@
+
+ #include
+ #include
++#include
+
+ #include "common.h"
+
++static struct mdio_gpio_platform_data ib4220b_mdio = {
++ .mdc= 22,
++ .mdio = 21,
++ .phy_mask = ~(1 << 1),
++};
++
++static struct platform_device ib4220b_phy_device = {
++ .name = "mdio-gpio",
++ .id = 0,
[OpenWrt-Devel] [PATCH 2/2] gemini: update usb driver and merge registers into one patch
Signed-off-by: Roman Yeryomin
---
.../gemini/files/drivers/usb/host/ehci-fotg2.c | 258 +
.../gemini/patches-3.10/130-usb-ehci-fot2g.patch | 223
.../130-usb-ehci-gemini-fot2gxx-support.patch | 611 -
.../131-arm-gemini-add-usb-platform-device.patch | 75 ---
.../patches-3.10/132-arm-gemini-register-usb.patch | 65 +++
.../132-arm-gemini-wbd111-register-usb.patch | 24 -
.../133-arm-gemini-wbd222-register-usb.patch | 10 -
.../134-arm-gemini-rut100-register-usb.patch | 10 -
.../135-arm-gemini-nas4220-register-usb.patch | 11 -
9 files changed, 546 insertions(+), 741 deletions(-)
create mode 100644 target/linux/gemini/files/drivers/usb/host/ehci-fotg2.c
create mode 100644 target/linux/gemini/patches-3.10/130-usb-ehci-fot2g.patch
delete mode 100644
target/linux/gemini/patches-3.10/130-usb-ehci-gemini-fot2gxx-support.patch
delete mode 100644
target/linux/gemini/patches-3.10/131-arm-gemini-add-usb-platform-device.patch
create mode 100644
target/linux/gemini/patches-3.10/132-arm-gemini-register-usb.patch
delete mode 100644
target/linux/gemini/patches-3.10/132-arm-gemini-wbd111-register-usb.patch
delete mode 100644
target/linux/gemini/patches-3.10/133-arm-gemini-wbd222-register-usb.patch
delete mode 100644
target/linux/gemini/patches-3.10/134-arm-gemini-rut100-register-usb.patch
delete mode 100644
target/linux/gemini/patches-3.10/135-arm-gemini-nas4220-register-usb.patch
diff --git a/target/linux/gemini/files/drivers/usb/host/ehci-fotg2.c
b/target/linux/gemini/files/drivers/usb/host/ehci-fotg2.c
new file mode 100644
index 000..4d95f2e
--- /dev/null
+++ b/target/linux/gemini/files/drivers/usb/host/ehci-fotg2.c
@@ -0,0 +1,258 @@
+/*
+ * Gemini EHCI Host Controller driver
+ *
+ * Copyright (C) 2014 Roman Yeryomin
+ * Copyright (C) 2012 Tobias Waldvogel
+ * based on GPLd code from Sony Computer Entertainment Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include "ehci.h"
+
+#define DRV_NAME "ehci-fotg2"
+
+#define HCD_MISC 0x40
+
+#define OTGC_SCR 0x80
+#define OTGC_INT_STS 0x84
+#define OTGC_INT_EN0x88
+
+#define GLOBAL_ISR 0xC0
+#define GLOBAL_ICR 0xC4
+
+#define GLOBAL_INT_POLARITY(1 << 3)
+#define GLOBAL_INT_MASK_HC (1 << 2)
+#define GLOBAL_INT_MASK_OTG(1 << 1)
+#define GLOBAL_INT_MASK_DEV(1 << 0)
+
+#define OTGC_SCR_ID(1 << 21)
+#define OTGC_SCR_CROLE (1 << 20)
+#define OTGC_SCR_VBUS_VLD (1 << 19)
+#define OTGC_SCR_A_SRP_RESP_TYPE (1 << 8)
+#define OTGC_SCR_A_SRP_DET_EN (1 << 7)
+#define OTGC_SCR_A_SET_B_HNP_EN(1 << 6)
+#define OTGC_SCR_A_BUS_DROP(1 << 5)
+#define OTGC_SCR_A_BUS_REQ (1 << 4)
+
+#define OTGC_INT_APLGRMV (1 << 12)
+#define OTGC_INT_BPLGRMV (1 << 11)
+#define OTGC_INT_OVC (1 << 10)
+#define OTGC_INT_IDCHG (1 << 9)
+#define OTGC_INT_RLCHG (1 << 8)
+#define OTGC_INT_AVBUSERR (1 << 5)
+#define OTGC_INT_ASRPDET (1 << 4)
+#define OTGC_INT_BSRPDN(1 << 0)
+
+#define OTGC_INT_A_TYPE( \
+ OTGC_INT_ASRPDET | \
+ OTGC_INT_AVBUSERR | \
+ OTGC_INT_OVC | \
+ OTGC_INT_RLCHG |\
+ OTGC_INT_IDCHG |\
+ OTGC_INT_APLGRMV\
+ )
+#define OTGC_INT_B_TYPE( \
+ OTGC_INT_AVBUSERR | \
+ OTGC_INT_OVC | \
+ OTGC_INT_RLCHG |\
+ OTGC_INT_IDCHG \
+ )
+
+
+static void fotg2_otg_init(struct usb_hcd *hcd)
+{
+ u32 val;
+
+ writel(GLOBAL_INT_POLARITY | GLOBAL_INT_MASK_HC |
+ GLOBAL_INT_MASK_OTG | GLOBAL_INT_MASK_DEV,
+ hcd->regs + GLOBAL_ICR);
+
+ val = readl(hcd->regs + OTGC_SCR);
+ val &= ~(OTGC_SCR_A_SRP_RESP_TYPE | OTGC_SCR_A_SRP_DET_EN |
+OTGC_SCR_A_BUS_DROP | OTGC_SCR_A_SET_B_HNP_EN);
+ val |= OTGC_SCR_A_BUS_REQ;
+ writel(val, hcd->regs + OTGC_SCR);
+
+ writel(OTGC_INT_A_TYPE, hcd->regs + OTGC_INT_EN);
+
+ /* setup MISC register, fixes timing problems */
+ val = readl(hcd->regs + HCD_MISC);
+ val |= 0xD;
+ writel(val, hcd->regs + HCD_MISC);
+
+ writel(~0, hcd->regs + GLOBAL_ISR);
+ writel(~0, hcd->regs + OTGC_INT_STS);
+}
+
+static
Re: [OpenWrt-Devel] Can we have "init" call for diag.sh (set_state)?
On 13/12/2014 19:12, Rafał Miłecki wrote:
> On 11 December 2014 at 21:17, John Crispin
> wrote:
>> On 11/12/2014 20:59, Rafał Miłecki wrote:
>>> Let me simplify booting process into following stages: 1)
>>> preinit (LED blinking with medium freq) 2) init (LED blinking
>>> with medium freq) 3) done (LED state on)
>>>
>>> The problem is this duplicated "medium freq" and that diag.sh
>>> (set_state) has only two of above stages: 1) preinit 2) done So
>>> we can't signal that OpenWrt went from preinit to init and
>>> e.g. failsafe is not accessible anymore.
>>>
>>> Could we change it? Is that OK if we add something like init)
>>> status_led_blink_init with some low blinking frequency?
>>>
>>> The purpose of that is to let user know it's too late for
>>> entering a failsafe mode.
>>>
>>
>> sure sound like a good idea, wanna cook a patch ?
>
> Sure. I played with it a bit, and there is one thing I'm not sure
> about.
>
> 1) Technically It makes more sense to change change LED blinking
> when OpenWrt enters "init" stage (after "preinit"). That would
> simply require START=00 boot() { set_state init } in the
> /etc/init.d/setstate
>
> 2) Practically For user it makes more sense to know when the
> failsafe mode can (not) be entered. This would simply require
> set_state preinit_post_failsafe_wait at the end of
> /lib/preinit/30_failsafe_wait
>
> Which would be better to implement?
>
Hi,
outline which you would choose and explain your decision please
John
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
