[OpenWrt-Devel] support for Sagemcom F@ST2804V7
Hello, Is it possible to add support for Sagemcom F@ST2804V7 ? I tried openwr...@st2704v2-squashfs-cfe.bin and some others (barrier_breaker) on it, bootlog (via serial port) says: Kernel panic - not syncing: unable to detect bcm963xx board. If it is possible, i will supply all required information/data. P.S. Openwrt works if I change board ID in CFE to F@ST2704V2(with 'b' command) Best regards, Eugene ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 07/12] cli: fix printing option values occupying multiple lines.
On 15 December 2014 at 16:46, Yousong Zhou yszhou4t...@gmail.com wrote:
Signed-off-by: Yousong Zhou yszhou4t...@gmail.com
---
cli.c | 40 ++--
1 file changed, 30 insertions(+), 10 deletions(-)
diff --git a/cli.c b/cli.c
index 6fbbfe9..85a24d8 100644
--- a/cli.c
+++ b/cli.c
@@ -168,18 +168,36 @@ static void cli_perror(void)
uci_perror(ctx, appname);
}
-static void uci_show_value(struct uci_option *o)
+static void uci_print_value(FILE *f, const char *v)
+{
+ fprintf(f, ');
+ while (*v) {
+ if (*v != '\'')
+ fputc(*v, f);
+ else
+ fprintf(f, '\\'');
+ v++;
+ }
+ fprintf(f, ');
+}
+
+static void uci_show_value(struct uci_option *o, bool quote)
{
struct uci_element *e;
bool sep = false;
switch(o-type) {
case UCI_TYPE_STRING:
- printf(%s\n, o-v.string);
+ if (quote)
+ uci_print_value(stdout, o-v.string);
+ else
+ printf(%s, o-v.string);
+ printf(\n);
break;
case UCI_TYPE_LIST:
uci_foreach_element(o-v.list, e) {
- printf(%s%s, (sep ? delimiter : ), e-name);
+ printf(%s, (sep ? delimiter : ));
+ uci_print_value(stdout, e-name);
sep = true;
}
While `config_foreach` works okay with this change. I may note that
this will break usages like the following
network=$(uci get sockd.instance0.internal_network)
status=$(ifstatus $network)
where option `internal_network` is of list type, thus the value will
be quoted resulting a call to ifstatus like the following.
ifstatus 'vpn'
which is invalid of course. Anyway, I think `config_foreach` should
be used in such cases.
Regards.
yousong
printf(\n);
@@ -190,13 +208,13 @@ static void uci_show_value(struct uci_option *o)
}
}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 07/12] cli: fix printing option values occupying multiple lines.
On 16 December 2014 at 16:28, Yousong Zhou yszhou4t...@gmail.com wrote:
On 15 December 2014 at 16:46, Yousong Zhou yszhou4t...@gmail.com wrote:
Signed-off-by: Yousong Zhou yszhou4t...@gmail.com
---
+static void uci_show_value(struct uci_option *o, bool quote)
{
struct uci_element *e;
bool sep = false;
switch(o-type) {
case UCI_TYPE_STRING:
- printf(%s\n, o-v.string);
+ if (quote)
+ uci_print_value(stdout, o-v.string);
+ else
+ printf(%s, o-v.string);
+ printf(\n);
break;
case UCI_TYPE_LIST:
uci_foreach_element(o-v.list, e) {
- printf(%s%s, (sep ? delimiter : ), e-name);
+ printf(%s, (sep ? delimiter : ));
+ uci_print_value(stdout, e-name);
sep = true;
}
While `config_foreach` works okay with this change. I may note that
this will break usages like the following
network=$(uci get sockd.instance0.internal_network)
status=$(ifstatus $network)
where option `internal_network` is of list type, thus the value will
be quoted resulting a call to ifstatus like the following.
ifstatus 'vpn'
which is invalid of course. Anyway, I think `config_foreach` should
be used in such cases.
It's `config_list_foreach`, sorry for the typo.
yousong
Regards.
yousong
printf(\n);
@@ -190,13 +208,13 @@ static void uci_show_value(struct uci_option *o)
}
}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH RFC 3/5] target: Add board notion support
On 2014-12-12 16:21, Maxime Ripard wrote: Even though we always build all the board images for a given target, some options widely differ from one board to another when it comes to hardware configuration. Such an option for example is the NAND setup, which depends on the NAND chip itself, that obviously varies from one board to another. This kind of options used to be declared either globally for one platform, which would enforce a fragile default, or through alternate profiles, that would result in an unusable image that would still be compiled if we chose the wrong one. Introduce a new notion of boards, that would be defined in the $(PLATFORM_DIR)/boards directory, to set up this kind of board specific options, that we always want to be in-use, no matter what profile is used. Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com The current image building code and the various hacks that different platforms use to match images to profiles is a complete mess. I've started implementing a new set of templates for declaring images, which will be simpler, more coherent and will allow better control over which images will be built with which subtarget/profile. It will also support parallel building. I would like to avoid adding more API stuff that depends on the current bad design. Since this patch seems to be adding nothing but a simple include statement and a wrapper for appending stuff to a variable, I'd like to leave it out and open code that stuff in the target image makefile instead, until the new image code is ready. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Current state of extroot, how to use it, what about ubi(fs)
I've spent few hours today trying to understand extroot. I've failed :( Of course I was trying to use wiki pages: http://wiki.openwrt.org/doc/howto/extroot http://wiki.openwrt.org/doc/uci/fstab 1) Main question Is the following sentence true at all? The configuration of extroot is very simple and is done entirely in /etc/config/fstab. It seems that /etc/init.d/fstab uses block umount and block mount only. I was reading the source code (fstools-2014-12-15/block.c) and it seems that block mount doesn't really handle extroot at all. I think some kind of extroot support is provided in block extroot, but I don't fully understand it. It seems to be looking for partitions rootfs and then rootfs_data ignoring whatever is set in /etc/config/fstab. If mount extroot is really supposed to be used, is there any way to point some external device (without MTD partitions) as extroot? I got confused. 2) UBI and UBIFS support I guess it's too new to be documented and I don't understand it much from the code. It seems that if there isn't rootfs MTD partition, then the code will look for rootfs UBI volume. The same applies to the rootfs_data. But what if my serial flash contains rootfs + rootfs_data partitions and I still want to use some UBI volume on another flash (NAND one)? -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] iproute2: bump version from 3.16.0 to 3.17.0
Signed-off-by: Russell Senior russ...@personaltelco.net --- package/network/utils/iproute2/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/network/utils/iproute2/Makefile b/package/network/utils/iproute2/Makefile index f6d2801..9aea05e 100644 --- a/package/network/utils/iproute2/Makefile +++ b/package/network/utils/iproute2/Makefile @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=iproute2 -PKG_VERSION:=3.16.0 +PKG_VERSION:=3.17.0 PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz PKG_SOURCE_URL:=http://kernel.org/pub/linux/utils/net/iproute2/ -PKG_MD5SUM:=6c823b40fdcfa7b8120743349a52ac18 +PKG_MD5SUM:=b741a02c6dda5818d18011d572874493 PKG_BUILD_PARALLEL:=1 PKG_LICENSE:=GPL-2.0 -- 2.1.3 -- Russell Senior, President russ...@personaltelco.net ___ 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 Mon, Dec 15, 2014 at 2:17 PM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Sat, Dec 13, 2014 at 07:50:52PM +0100, Jonas Gorski wrote: 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. So, I just gave the union of all the config symbol a try, and while it fixes some issues, it also shows up something unexpected (logic, actually, but I didn't think of that). The differences that we have now are for the options that we enable through another way than the config-version file itself (like the target configuration, or the openwrt makefiles directly), that in turn have options that depends on them with a default to yes, and that we don't want to enable. In short, something like config FOO bool 'Some option' config BAR bool 'Some other option' depends on FOO default y If FOO is not enabled, the defconfig won't have any information on BAR, which means that if FOO gets enabled somehow, BAR will be set to y. I guess that in such a case, it should be up to the one that enables the FOO option to also enforce a BAR value if the default is not ok. That would be easy to do for the target configuration files, but not that much whenever it's a package that enables that option for example. And putting it in the global configuration kind of defeats the original purpose of this patch set. So I guess we should define a policy on this. What do you think? AFAIR, there are two places for out-of-config config symbols: a) config/Config-kernel.in, where several config symbols are directly exposed as KERNEL_foo. There we can add appropriate additional config symbols with our desired defaults (as is already done for a few). b) KernelPackages in their KCONFIG sections. Adding the appropriate BAR=n to the defintion that enables FOO should be sufficient. Did you find any further kernel config options not covered by these? Of course these are then two places which cannot be cleaned up automatically, but they aren't new, and I don't think we can't get rid of it. Btw, how do you propose to keep the list of symbols required current? I doubt creating the union is a fast process. If you used a script for that, I think it would be nice to also add it to scripts/, else nobody will bother to do it again, and in a few kernel releases the generic config-foo will then contain a lot of clutter again. Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/5] ar8216: patch series with more smaller improvements
On Tue, Dec 16, 2014 at 8:12 AM, Heiner Kallweit hkallwe...@gmail.com wrote: 1/5 Remove unused function parameter in ar8327_led_register 2/5 Factor out chip-specific parameters from ar8xxx_probe_switch 3/5 Create helpers mii_read32 / mii_write32 for 32 bit MII ops. 4/5 Remove read/write/rmw member functions from ar8xxx_priv 5/5 Inline function ar8xxx_create_mii Nitpick for future patch sets / versions: if you don't have anything to write in the cover letter, then just don't add one ;-) Also git format-patch --cover-letter will add a nice template cover letter to your patches, so you don't have to manually copy the patch subjects. Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] iproute2: bump version from 3.16.0 to 3.17.0
applied, thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Current state of extroot, how to use it, what about ubi(fs)
On 16/12/2014 11:23, Gergely Kiss wrote: Hi Rafał, please allow me to comment on your 2nd point as I was the one who recently published the patch to make extroot functionality work with UBIFS. It seems that if there isn't rootfs MTD partition, then the code will look for rootfs UBI volume. The same applies to the rootfs_data. That's correct. But what if my serial flash contains rootfs + rootfs_data partitions and I still want to use some UBI volume on another flash (NAND one)? I'm not sure I understand what you mean here. Are there any devices out there with multiple flash chips on-board? As far as I know, UBI cannot work on top of block devices (eg. USB flashes, SD cards), only raw flash chips so I can't really imagine what exact use-case you mean. Could you please clarify? Thanks, Gergely On 16 December 2014 at 11:00, Rafał Miłecki zaj...@gmail.com wrote: I've spent few hours today trying to understand extroot. I've failed :( Of course I was trying to use wiki pages: http://wiki.openwrt.org/doc/howto/extroot http://wiki.openwrt.org/doc/uci/fstab 1) Main question Is the following sentence true at all? The configuration of extroot is very simple and is done entirely in /etc/config/fstab. It seems that /etc/init.d/fstab uses block umount and block mount only. I was reading the source code (fstools-2014-12-15/block.c) and it seems that block mount doesn't really handle extroot at all. I think some kind of extroot support is provided in block extroot, but I don't fully understand it. It seems to be looking for partitions rootfs and then rootfs_data ignoring whatever is set in /etc/config/fstab. If mount extroot is really supposed to be used, is there any way to point some external device (without MTD partitions) as extroot? I got confused. 2) UBI and UBIFS support I guess it's too new to be documented and I don't understand it much from the code. It seems that if there isn't rootfs MTD partition, then the code will look for rootfs UBI volume. The same applies to the rootfs_data. But what if my serial flash contains rootfs + rootfs_data partitions and I still want to use some UBI volume on another flash (NAND one)? -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel Hi, I think this is where this discussion started and Rafal explains a bit more about the hardware: https://lists.openwrt.org/pipermail/openwrt-devel/2014-December/029717.html Regards, Flavio ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 1/4] brcm63xx: add bcm6345-gpio driver
On Mon, Dec 15, 2014 at 3:46 PM, Álvaro Fernández Rojas
nolt...@gmail.com wrote:
Please add a description for your bindings in
Documentation/devicetree/bindings/gpio
Signed-off-by: Álvaro Fernández Rojas nolt...@gmail.com
---
v2: use vendor for DT properties.
diff --git a/target/linux/brcm63xx/config-3.14
b/target/linux/brcm63xx/config-3.14
index dd27f47..f94c567 100644
--- a/target/linux/brcm63xx/config-3.14
+++ b/target/linux/brcm63xx/config-3.14
@@ -76,6 +76,7 @@ CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_GPIOLIB=y
+CONFIG_GPIO_BCM6345=y
CONFIG_GPIO_DEVRES=y
CONFIG_GPIO_SYSFS=y
# CONFIG_HAMRADIO is not set
diff --git a/target/linux/brcm63xx/config-3.18
b/target/linux/brcm63xx/config-3.18
index e3cf020..7957d02 100644
--- a/target/linux/brcm63xx/config-3.18
+++ b/target/linux/brcm63xx/config-3.18
@@ -80,6 +80,7 @@ CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_GPIOLIB=y
+CONFIG_GPIO_BCM6345=y
CONFIG_GPIO_DEVRES=y
CONFIG_GPIO_SYSFS=y
# CONFIG_HAMRADIO is not set
diff --git
a/target/linux/brcm63xx/patches-3.14/374-GPIO-add-bcm6345-driver.patch
b/target/linux/brcm63xx/patches-3.14/374-GPIO-add-bcm6345-driver.patch
new file mode 100644
index 000..847933b
--- /dev/null
+++ b/target/linux/brcm63xx/patches-3.14/374-GPIO-add-bcm6345-driver.patch
@@ -0,0 +1,244 @@
+--- /dev/null
b/drivers/gpio/gpio-bcm6345.c
+@@ -0,0 +1,216 @@
++/*
++ * This file is subject to the terms and conditions of the GNU General
Public
++ * License. See the file COPYING in the main directory of this archive
++ * for more details.
++ *
++ * Copyright (C) 2008 Maxime Bizon mbi...@freebox.fr
++ * Copyright (C) 2008-2011 Florian Fainelli flor...@openwrt.org
++ * Copyright (C) 2014 Álvaro Fernández Rojas nolt...@gmail.com
++ */
++
++#include linux/kernel.h
++#include linux/module.h
++#include linux/spinlock.h
++#include linux/platform_device.h
++#include linux/gpio.h
++
++enum bcm6345_gpio_reg {
++ GPIO_REG_CTL_HI = 0,
++ GPIO_REG_CTL_LO,
++ GPIO_REG_DATA_HI,
++ GPIO_REG_DATA_LO,
++ GPIO_REG_MAX
++};
++
++struct bcm6345_gpio_chip {
++ struct gpio_chip chip;
++ u8 regs[GPIO_REG_MAX];
I don't think we need to be that flexible, as there are essentially
only two (three) layouts: bcm6345 and everything else, so we can cover
these through appropriate compatible strings (the arm chips and the
newest mips one have five registers instead of two for a total of 160
gpios).
Also the reg property should only cover what you need, not the whole
gpio range. So only e.g. 0xfffe0404 0x8 in case of bcm6345, and
0xfffe0400 0x10 / 0xfffe0080 0x10 / 0x1080 0x10 for anything
else.
Or add both as separate resources and use reg-names to distinguish them.
You could also use the length of the registers to infer the offsets of
the hi/lo registers, and don't need to tell bcm6345 and later apart.
++
++ spinlock_t lock;
++ void __iomem *membase;
++};
++
++static inline struct bcm6345_gpio_chip *to_bcm6345_gpio(struct gpio_chip
*chip)
++{
++ struct bcm6345_gpio_chip *bg;
++
++ bg = container_of(chip, struct bcm6345_gpio_chip, chip);
++
++ return bg;
++}
++
++static inline u32 bc_gpio_r32(struct bcm6345_gpio_chip *bg, u8 reg)
Please call this bcm6345_gpio_read32.
++{
++ return ioread32be(bg-membase + bg-regs[reg]);
++}
++
++static inline void bc_gpio_w32(struct bcm6345_gpio_chip *bg, u8 reg, u32
val)
And this one bcm6345_gpio_write32
++{
++ iowrite32be(val, bg-membase + bg-regs[reg]);
++}
++
++static void bcm6345_gpio_set(struct gpio_chip *chip, unsigned gpio, int
value)
++{
++ struct bcm6345_gpio_chip *bg = to_bcm6345_gpio(chip);
++ unsigned long flags;
++ u32 mask, val;
++ u8 reg;
++
++ if (gpio 32) {
++ reg = GPIO_REG_DATA_LO;
++ mask = BIT(gpio);
++ } else {
++ reg = GPIO_REG_DATA_HI;
++ mask = BIT(gpio - 32);
++ }
I would suggest doing something similar like I did for the reverse
order of the interrupt registers.
Let the bcm6456_gpio_chip have
u8 data_reg[2];
u8 dir_reg[2];
which you then populate on probe with { 0x0 }, { 0x4 } for bcm6345,
and { 0x4, 0x0 } and { 0xc, 0x8 }
Then you can do just
reg = bg-data_reg[gpio / 32];
mask = BIT(gpio % 32);
...
val = bcm6345_gpio_read32(bg, reg);
...
This will also make it easy to expand it for support of more than 64 gpios.
++
++ spin_lock_irqsave(bg-lock, flags);
++ val = bc_gpio_r32(bg, reg);
++ if (value)
++ val |= mask;
++ else
++ val = ~mask;
++ bc_gpio_w32(bg, reg, val);
++ spin_unlock_irqrestore(bg-lock, flags);
++}
++
++static int bcm6345_gpio_get(struct gpio_chip *chip, unsigned gpio)
++{
++ struct bcm6345_gpio_chip *bg =
Re: [OpenWrt-Devel] support for Sagemcom F@ST2804V7
Take a look at this patch: http://patchwork.openwrt.org/patch/6751/ First of all you need to find your router's board id. If changing the board id CFE works then you have a some kind of solution. 2014-12-16 9:26 GMT+01:00, Eugene jek...@yandex.ru: Hello, Is it possible to add support for Sagemcom F@ST2804V7 ? I tried openwr...@st2704v2-squashfs-cfe.bin and some others (barrier_breaker) on it, bootlog (via serial port) says: Kernel panic - not syncing: unable to detect bcm963xx board. If it is possible, i will supply all required information/data. P.S. Openwrt works if I change board ID in CFE to F@ST2704V2(with 'b' command) Best regards, Eugene ___ 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] Current state of extroot, how to use it, what about ubi(fs)
Sorry, I haven't read that post earlier. So, is this simply about mounting an additional UBIFS partition at boot time? If so, I believe the best solution would be to extend the functionality of fstab with a simple (shell) script, as suggested in the fstab wiki: BTRFS, JFS, *UBI* [...] are not supported in /etc/config/fstab. Use manual scripting. Would that be possible? Regards, Gergely On 16 December 2014 at 14:39, Flávio Silveira f...@terra.com.br wrote: On 16/12/2014 11:23, Gergely Kiss wrote: Hi Rafał, please allow me to comment on your 2nd point as I was the one who recently published the patch to make extroot functionality work with UBIFS. It seems that if there isn't rootfs MTD partition, then the code will look for rootfs UBI volume. The same applies to the rootfs_data. That's correct. But what if my serial flash contains rootfs + rootfs_data partitions and I still want to use some UBI volume on another flash (NAND one)? I'm not sure I understand what you mean here. Are there any devices out there with multiple flash chips on-board? As far as I know, UBI cannot work on top of block devices (eg. USB flashes, SD cards), only raw flash chips so I can't really imagine what exact use-case you mean. Could you please clarify? Thanks, Gergely On 16 December 2014 at 11:00, Rafał Miłecki zaj...@gmail.com wrote: I've spent few hours today trying to understand extroot. I've failed :( Of course I was trying to use wiki pages: http://wiki.openwrt.org/doc/howto/extroot http://wiki.openwrt.org/doc/uci/fstab 1) Main question Is the following sentence true at all? The configuration of extroot is very simple and is done entirely in /etc/config/fstab. It seems that /etc/init.d/fstab uses block umount and block mount only. I was reading the source code (fstools-2014-12-15/block.c) and it seems that block mount doesn't really handle extroot at all. I think some kind of extroot support is provided in block extroot, but I don't fully understand it. It seems to be looking for partitions rootfs and then rootfs_data ignoring whatever is set in /etc/config/fstab. If mount extroot is really supposed to be used, is there any way to point some external device (without MTD partitions) as extroot? I got confused. 2) UBI and UBIFS support I guess it's too new to be documented and I don't understand it much from the code. It seems that if there isn't rootfs MTD partition, then the code will look for rootfs UBI volume. The same applies to the rootfs_data. But what if my serial flash contains rootfs + rootfs_data partitions and I still want to use some UBI volume on another flash (NAND one)? -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel Hi, I think this is where this discussion started and Rafal explains a bit more about the hardware: https://lists.openwrt.org/pipermail/openwrt-devel/2014-December/029717.html Regards, Flavio ___ 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] Current state of extroot, how to use it, what about ubi(fs)
On Tue, 16 Dec 2014 16:06:27 +0100, Gergely Kiss mail.g...@gmail.com wrote: Please don't top-post. Sorry, I haven't read that post earlier. So, is this simply about mounting an additional UBIFS partition at boot time? If so, I believe the best solution would be to extend the functionality of fstab with a simple (shell) script, as suggested in the fstab wiki: BTRFS, JFS, *UBI* [...] are not supported in /etc/config/fstab. Use manual scripting. Would that be possible? Regards, Gergely On 16 December 2014 at 14:39, Flávio Silveira f...@terra.com.br wrote: On 16/12/2014 11:23, Gergely Kiss wrote: Hi Rafał, please allow me to comment on your 2nd point as I was the one who recently published the patch to make extroot functionality work with UBIFS. It seems that if there isn't rootfs MTD partition, then the code will look for rootfs UBI volume. The same applies to the rootfs_data. That's correct. But what if my serial flash contains rootfs + rootfs_data partitions and I still want to use some UBI volume on another flash (NAND one)? I'm not sure I understand what you mean here. Are there any devices out there with multiple flash chips on-board? As far as I know, UBI cannot work on top of block devices (eg. USB flashes, SD cards), only raw flash chips so I can't really imagine what exact use-case you mean. Could you please clarify? Thanks, Gergely On 16 December 2014 at 11:00, Rafał Miłecki zaj...@gmail.com wrote: I've spent few hours today trying to understand extroot. I've failed :( Of course I was trying to use wiki pages: http://wiki.openwrt.org/doc/howto/extroot http://wiki.openwrt.org/doc/uci/fstab 1) Main question Is the following sentence true at all? The configuration of extroot is very simple and is done entirely in /etc/config/fstab. It seems that /etc/init.d/fstab uses block umount and block mount only. I was reading the source code (fstools-2014-12-15/block.c) and it seems that block mount doesn't really handle extroot at all. I think some kind of extroot support is provided in block extroot, but I don't fully understand it. It seems to be looking for partitions rootfs and then rootfs_data ignoring whatever is set in /etc/config/fstab. If mount extroot is really supposed to be used, is there any way to point some external device (without MTD partitions) as extroot? I got confused. 2) UBI and UBIFS support I guess it's too new to be documented and I don't understand it much from the code. It seems that if there isn't rootfs MTD partition, then the code will look for rootfs UBI volume. The same applies to the rootfs_data. But what if my serial flash contains rootfs + rootfs_data partitions and I still want to use some UBI volume on another flash (NAND one)? -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel Hi, I think this is where this discussion started and Rafal explains a bit more about the hardware: https://lists.openwrt.org/pipermail/openwrt-devel/2014-December/029717.html Regards, Flavio Rafal, what about mtdconcat? Imre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] dnsmasq packages
Hi, to be able to build dnsmasq with DNS auth and/or IPSET and/or DNSSEC support people are currently forced to enable the whole IPv6 stuff. Current package layout: dnsmasq: --- dnsmasq-dhcpv6: +DHCPv6 (depends on IPv6) dnsmasq-full: +DNS auth, +IPSET, +DHCPv6, +DNSSEC (depends on IPv6) Build sizes (checked with dnsmasq 2.72, ar71xx) are about base size: 130.8 kB IPSET: +1 kB DNS auth:+6-7 kB dhcpv6: +27.7 kB dnssec: +19 kB (incl. trust-anchors.conf) (IPv6 enabled: +4.5 kB) My suggestion would be to extend/change the package layout to dnsmasq-mini: --- dnsmasq: +DNS Auth, +IPSET dnsmasq-dhcpv6: +DNS auth, +IPSET, +DHCPv6 (depends on IPv6) dnsmasq-dnssec: +DNS auth, +IPSET, +DNSSEC dnsmasq-full: +DNS auth, +IPSET, +DHCPv6, +DNSSEC (depends on IPv6) Does that sound reasonable ? Regards, Frank Schäfer ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dnsmasq packages
Hi, I would prefer to make it configurable like libcurl, busybox and others so select the option you need during compile. Base inside OpenWrt should be without any options, because dnsmasq is only used as IPv4 DHCP. Have you ever check the funny thing happen, if you select more than 1 (*) inside menuconfig ? You get a funny build because they are build inside the same build directory and installed in any order. So who win the install. In the past I also got broken packages, if I select more than 1 (*) or (M). NEVER select more then one inside menuconfig!!! I think the Makefile needs a redesign anyway. Christian Am 16.12.2014 um 18:25 schrieb Frank Schäfer: Hi, to be able to build dnsmasq with DNS auth and/or IPSET and/or DNSSEC support people are currently forced to enable the whole IPv6 stuff. Current package layout: dnsmasq: --- dnsmasq-dhcpv6: +DHCPv6 (depends on IPv6) dnsmasq-full: +DNS auth, +IPSET, +DHCPv6, +DNSSEC (depends on IPv6) Build sizes (checked with dnsmasq 2.72, ar71xx) are about base size: 130.8 kB IPSET: +1 kB DNS auth:+6-7 kB dhcpv6: +27.7 kB dnssec: +19 kB (incl. trust-anchors.conf) (IPv6 enabled: +4.5 kB) My suggestion would be to extend/change the package layout to dnsmasq-mini: --- dnsmasq: +DNS Auth, +IPSET dnsmasq-dhcpv6: +DNS auth, +IPSET, +DHCPv6 (depends on IPv6) dnsmasq-dnssec: +DNS auth, +IPSET, +DNSSEC dnsmasq-full: +DNS auth, +IPSET, +DHCPv6, +DNSSEC (depends on IPv6) Does that sound reasonable ? Regards, Frank Schäfer ___ 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] Current state of extroot, how to use it, what about ubi(fs)
On 16 December 2014 at 16:30, Imre Kaloz ka...@openwrt.org wrote: On Tue, 16 Dec 2014 16:06:27 +0100, Gergely Kiss mail.g...@gmail.com wrote: On 16 December 2014 at 14:39, Flávio Silveira f...@terra.com.br wrote: On 16/12/2014 11:23, Gergely Kiss wrote: I'm not sure I understand what you mean here. Are there any devices out there with multiple flash chips on-board? As far as I know, UBI cannot work on top of block devices (eg. USB flashes, SD cards), only raw flash chips so I can't really imagine what exact use-case you mean. Could you please clarify? I think this is where this discussion started and Rafal explains a bit more about the hardware: https://lists.openwrt.org/pipermail/openwrt-devel/2014-December/029717.html Rafal, what about mtdconcat? That would be nice because I could use space available on the serial flash. So far I assumed to ignore that extra ~10 MiB and focus on NAND mostly. However I'm not sure if this will be possible without heavy changes. I have rootfs_data (JFFS2) partition on serial flash. I would need to concat it with my UBI partition on NAND flash. 1) I'm afraid it may be complex to change the way OpenWrt treats rootfs_data. It's coded in many places. 2) Concanation has to be handled in the kernel. There isn't any DT driver I could use for bcm53xx. Guess I'd need to write once 3) I have no idea if UBI can work well on concan-ated partition. In theory yes, but in practice? UBI cares pretty much about wearing I believe. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Current state of extroot, how to use it, what about ubi(fs)
On 16 December 2014 at 16:06, Gergely Kiss mail.g...@gmail.com wrote: So, is this simply about mounting an additional UBIFS partition at boot time? If so, I believe the best solution would be to extend the functionality of fstab with a simple (shell) script, as suggested in the fstab wiki: BTRFS, JFS, *UBI* [...] are not supported in /etc/config/fstab. Use manual scripting. Would that be possible? I could implement that, but is it going to help? This block extroot is really confusing for me. Does it really look for entries in /etc/config/fstab? Or does it hardcode to use rootfs / rootfs_data partitions? Could you explain what's the point of all these find_block_mtd(rootfs, fs, sizeof(fs)); find_block_ubi_RO(libubi, rootfs, fs, sizeof(fs)); find_block_mtd(rootfs_data, fs_data, sizeof(fs_data)); find_block_ubi(libubi, rootfs_data, fs_data, sizeof(fs_data)); in the main_extroot? Also, in my case there is rootfs_data MTD partition. I could create UBI volume rootfs_data on NAND flash, but block extroot will still pick the MTD partition. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ar7: Remove linux-3.10 leftovers
The config-3.10 got removed in r43632, so bye-bye to patches-3.10 as well.
Signed-off-by: Sedat Dilek sedat.di...@gmail.com
---
.../ar7/patches-3.10/001-mips-ar7-fix-serial.patch | 28 --
target/linux/ar7/patches-3.10/110-flash.patch | 22 --
.../linux/ar7/patches-3.10/120-gpio_chrdev.patch | 28 --
.../patches-3.10/160-vlynq_try_remote_first.patch | 300 -
.../200-free-mem-below-kernel-offset.patch | 15 --
.../ar7/patches-3.10/300-add-ac49x-platform.patch | 85 --
.../ar7/patches-3.10/310-ac49x-prom-support.patch | 20 --
.../patches-3.10/320-ac49x-mtd-partitions.patch| 35 ---
.../linux/ar7/patches-3.10/500-serial_kludge.patch | 28 --
target/linux/ar7/patches-3.10/920-ar7part.patch| 118
.../ar7/patches-3.10/925-actiontec_leds.patch | 95 ---
.../linux/ar7/patches-3.10/950-cpmac_titan.patch | 52
12 files changed, 826 deletions(-)
delete mode 100644 target/linux/ar7/patches-3.10/001-mips-ar7-fix-serial.patch
delete mode 100644 target/linux/ar7/patches-3.10/110-flash.patch
delete mode 100644 target/linux/ar7/patches-3.10/120-gpio_chrdev.patch
delete mode 100644
target/linux/ar7/patches-3.10/160-vlynq_try_remote_first.patch
delete mode 100644
target/linux/ar7/patches-3.10/200-free-mem-below-kernel-offset.patch
delete mode 100644 target/linux/ar7/patches-3.10/300-add-ac49x-platform.patch
delete mode 100644 target/linux/ar7/patches-3.10/310-ac49x-prom-support.patch
delete mode 100644 target/linux/ar7/patches-3.10/320-ac49x-mtd-partitions.patch
delete mode 100644 target/linux/ar7/patches-3.10/500-serial_kludge.patch
delete mode 100644 target/linux/ar7/patches-3.10/920-ar7part.patch
delete mode 100644 target/linux/ar7/patches-3.10/925-actiontec_leds.patch
delete mode 100644 target/linux/ar7/patches-3.10/950-cpmac_titan.patch
diff --git a/target/linux/ar7/patches-3.10/001-mips-ar7-fix-serial.patch
b/target/linux/ar7/patches-3.10/001-mips-ar7-fix-serial.patch
deleted file mode 100644
index f556ee2..000
--- a/target/linux/ar7/patches-3.10/001-mips-ar7-fix-serial.patch
+++ /dev/null
@@ -1,28 +0,0 @@
-From 443ab715a40881d6c9ba11b027ba154bac904cb0 Mon Sep 17 00:00:00 2001
-From: Oswald Buddenhagen oswald.buddenha...@gmx.de
-Date: Sat, 10 May 2014 23:19:08 +0200
-Subject: [PATCH] MIPS/AR7: ensure that serial ports are properly set up
-
-without UPF_FIXED_TYPE, the data from the PORT_AR7 uart_config entry is
-never copied, resulting in a dead port.
-
-Signed-off-by: Oswald Buddenhagen oswald.buddenha...@gmx.de
- arch/mips/ar7/platform.c | 1 +
- 1 file changed, 1 insertion(+)
-
-diff --git a/arch/mips/ar7/platform.c b/arch/mips/ar7/platform.c
-index 7e2356f..e4f47d3 100644
a/arch/mips/ar7/platform.c
-+++ b/arch/mips/ar7/platform.c
-@@ -581,6 +581,7 @@ static int __init ar7_register_uarts(void)
- uart_port.type = PORT_AR7;
- uart_port.uartclk = clk_get_rate(bus_clk) / 2;
- uart_port.iotype= UPIO_MEM32;
-+ uart_port.flags = UPF_FIXED_TYPE;
- uart_port.regshift = 2;
-
- uart_port.line = 0;
---
-1.8.5.3.2.g3dbf181
-
diff --git a/target/linux/ar7/patches-3.10/110-flash.patch
b/target/linux/ar7/patches-3.10/110-flash.patch
deleted file mode 100644
index e12eec5..000
--- a/target/linux/ar7/patches-3.10/110-flash.patch
+++ /dev/null
@@ -1,22 +0,0 @@
a/drivers/mtd/Makefile
-+++ b/drivers/mtd/Makefile
-@@ -16,7 +16,7 @@ obj-$(CONFIG_MTD_OF_PARTS) += ofpart.o
- obj-$(CONFIG_MTD_REDBOOT_PARTS) += redboot.o
- obj-$(CONFIG_MTD_CMDLINE_PARTS) += cmdlinepart.o
- obj-$(CONFIG_MTD_AFS_PARTS) += afs.o
--obj-$(CONFIG_MTD_AR7_PARTS) += ar7part.o
-+obj-$(CONFIG_MTD_AR7_PARTS) += ar7part.o titanpart.o
- obj-$(CONFIG_MTD_BCM63XX_PARTS) += bcm63xxpart.o
- obj-$(CONFIG_MTD_BCM47XX_PARTS) += bcm47xxpart.o
- obj-$(CONFIG_MTD_MYLOADER_PARTS) += myloader.o
a/arch/mips/ar7/platform.c
-+++ b/arch/mips/ar7/platform.c
-@@ -199,7 +199,7 @@ static struct resource physmap_flash_res
- .name = mem,
- .flags = IORESOURCE_MEM,
- .start = 0x1000,
-- .end= 0x107f,
-+ .end= 0x11ff,
- };
-
- static const char *ar7_probe_types[] = { ar7part, NULL };
diff --git a/target/linux/ar7/patches-3.10/120-gpio_chrdev.patch
b/target/linux/ar7/patches-3.10/120-gpio_chrdev.patch
deleted file mode 100644
index 15bc6c3..000
--- a/target/linux/ar7/patches-3.10/120-gpio_chrdev.patch
+++ /dev/null
@@ -1,28 +0,0 @@
a/drivers/char/Kconfig
-+++ b/drivers/char/Kconfig
-@@ -464,6 +464,15 @@ config MWAVE
- To compile this driver as a module, choose M here: the
- module will be called mwave.
-
-+config AR7_GPIO
-+ tristate TI AR7 GPIO Support
-+ depends on AR7
-+ help
-+Give userspace access to the GPIO pins on the Texas Instruments AR7
-+processors.
-+
-+If compiled as a module, it will be called ar7_gpio.
-+
- config SCx200_GPIO
-
Re: [OpenWrt-Devel] Current state of extroot, how to use it, what about ubi(fs)
On 12/16/2014 07:35 PM, Rafał Miłecki wrote: Does it really look for entries in /etc/config/fstab? Or does it hardcode to use rootfs / rootfs_data partitions? Could you explain what's the point of all these find_block_mtd(rootfs, fs, sizeof(fs)); find_block_ubi_RO(libubi, rootfs, fs, sizeof(fs)); find_block_mtd(rootfs_data, fs_data, sizeof(fs_data)); find_block_ubi(libubi, rootfs_data, fs_data, sizeof(fs_data)); in the main_extroot? To be the honest, I'm not very familiar with the sources, I only made some slight enhancements to a patch created by a forum member, see https://forum.openwrt.org/viewtopic.php?pid=257518#p257518 Maybe the developer who wrote the code originally could answer that. I suspect those functions are there so in case extroot fails, the code can revert to the flash partition to avoid having an unbootable system. Not sure of you read already but the bottom of this article might help understanding the logic: http://wiki.openwrt.org/doc/howto/extroot/extroot.theory Also, in my case there is rootfs_data MTD partition. I could create UBI volume rootfs_data on NAND flash, but block extroot will still pick the MTD partition. Well, that's how it works now but you can always create a patch if you want to change that behaviour. Regards, Gergely ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] dnsmasq: allow de-selecting features from -full variant.
Signed-off-by: Yousong Zhou yszhou4t...@gmail.com
---
package/network/services/dnsmasq/Makefile | 27 ++--
.../network/services/dnsmasq/files/dnsmasq.init|5
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/package/network/services/dnsmasq/Makefile
b/package/network/services/dnsmasq/Makefile
index a530225..2da593d 100644
--- a/package/network/services/dnsmasq/Makefile
+++ b/package/network/services/dnsmasq/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
PKG_NAME:=dnsmasq
PKG_VERSION:=2.72
-PKG_RELEASE:=1
+PKG_RELEASE:=2
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
PKG_SOURCE_URL:=http://thekelleys.org.uk/dnsmasq
@@ -72,6 +72,26 @@ define Package/dnsmasq/conffiles
/etc/dnsmasq.conf
endef
+define Package/dnsmasq/config/Default
+ if PACKAGE_$(1)-$(2)
+ config PACKAGE_dnsmasq_$(2)_dhcpv6
+bool Build with DHCPv6 support.
+default y
+ config PACKAGE_dnsmasq_$(2)_dnssec
+bool Build with DNSSEC support.
+default y
+ config PACKAGE_dnsmasq_$(2)_auth
+bool Build with the facility to act as an authoritative DNS server.
+default y
+ config PACKAGE_dnsmasq_$(2)_ipset
+bool Build with ipset support.
+select PACKAGE_kmod-ipt-ipset
+default y
+ endif
+endef
+
+Package/dnsmasq-full/config=$(call Package/dnsmasq/config/Default,dnsmasq,full)
+
Package/dnsmasq-dhcpv6/conffiles = $(Package/dnsmasq/conffiles)
Package/dnsmasq-full/conffiles = $(Package/dnsmasq/conffiles)
@@ -85,7 +105,10 @@ ifeq ($(BUILD_VARIANT),nodhcpv6)
endif
ifeq ($(BUILD_VARIANT),full)
- COPTS += -DHAVE_DNSSEC
+ COPTS += $(if
$(CONFIG_PACKAGE_dnsmasq_$(BUILD_VARIANT)_dhcpv6),,-DNO_DHCP6) \
+ $(if
$(CONFIG_PACKAGE_dnsmasq_$(BUILD_VARIANT)_dnssec),-DHAVE_DNSSEC) \
+ $(if
$(CONFIG_PACKAGE_dnsmasq_$(BUILD_VARIANT)_auth),,-DNO_AUTH) \
+ $(if
$(CONFIG_PACKAGE_dnsmasq_$(BUILD_VARIANT)_ipset),,-DNO_IPSET)
COPTS += $(if $(CONFIG_LIBNETTLE_MINI),-DNO_GMP,)
else
COPTS += -DNO_AUTH -DNO_IPSET
diff --git a/package/network/services/dnsmasq/files/dnsmasq.init
b/package/network/services/dnsmasq/files/dnsmasq.init
index 942acd7..209952b 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -85,6 +85,10 @@ append_address() {
xappend --address=$1
}
+append_ipset() {
+ xappend --ipset=$1
+}
+
append_interface() {
local ifname=$(uci_get_state network $1 ifname $1)
xappend --interface=$ifname
@@ -135,6 +139,7 @@ dnsmasq() {
append_parm $cfg local --server
config_list_foreach $cfg server append_server
config_list_foreach $cfg address append_address
+ config_list_foreach $cfg ipset append_ipset
config_list_foreach $cfg interface append_interface
config_list_foreach $cfg notinterface append_notinterface
config_list_foreach $cfg addnhosts append_addnhosts
--
1.7.10.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dnsmasq packages
Hi, On 17 December 2014 at 02:02, Christian Schoenebeck christian.schoeneb...@gmail.com wrote: Hi, I would prefer to make it configurable like libcurl, busybox and others so select the option you need during compile. Base inside OpenWrt should be without any options, because dnsmasq is only used as IPv4 DHCP. Have you ever check the funny thing happen, if you select more than 1 (*) inside menuconfig ? You get a funny build because they are build inside the same build directory and installed in any order. So who win the install. In the past I also got broken packages, if I select more than 1 (*) or (M). NEVER select more then one inside menuconfig!!! I think the Makefile needs a redesign anyway. I just resent my patch serving this purpose [1]. I only tried it with ipset though. [1] http://patchwork.ozlabs.org/patch/422142/ yousong Christian Am 16.12.2014 um 18:25 schrieb Frank Schäfer: Hi, to be able to build dnsmasq with DNS auth and/or IPSET and/or DNSSEC support people are currently forced to enable the whole IPv6 stuff. Current package layout: dnsmasq: --- dnsmasq-dhcpv6: +DHCPv6 (depends on IPv6) dnsmasq-full: +DNS auth, +IPSET, +DHCPv6, +DNSSEC (depends on IPv6) Build sizes (checked with dnsmasq 2.72, ar71xx) are about base size: 130.8 kB IPSET: +1 kB DNS auth:+6-7 kB dhcpv6: +27.7 kB dnssec: +19 kB (incl. trust-anchors.conf) (IPv6 enabled: +4.5 kB) My suggestion would be to extend/change the package layout to dnsmasq-mini: --- dnsmasq: +DNS Auth, +IPSET dnsmasq-dhcpv6: +DNS auth, +IPSET, +DHCPv6 (depends on IPv6) dnsmasq-dnssec: +DNS auth, +IPSET, +DNSSEC dnsmasq-full: +DNS auth, +IPSET, +DHCPv6, +DNSSEC (depends on IPv6) Does that sound reasonable ? Regards, Frank Schäfer ___ 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 mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] dnsmasq: allow de-selecting features from -full variant.
applied, thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 0/1] TARGET : add sheevaplug and derivatives
KIRKWOOD : add sheevaplug and derivatives
ADD some kirkwood FDT
- SheevaPlug
- SheevaPlug with eSATA
- GuruplugServerPlus
- Topkick1281P2
With (CC) TRUNK OpenWRT build (QUICK HOWTO) :
INTERRUPT
### INITIALIZE
Marvell nand erase.part root
### PREPARE
Marvell ubi part root
Marvell ubi remove rootfs
Marvell ubi create rootfs
### UPGRADE
Marvell usb reset
Marvell fatload usb 0:1 0x80
sheevaplug/openwrt/openwrt-kirkwood-sheevaplug-rootfs.ubifs
Marvell ubi write 0x80 rootfs ${filesize}
Marvell reset
Gérald Kerma (1):
KIRKWOOD : add sheevaplug and derivatives
target/linux/kirkwood/image/Makefile | 12 +
target/linux/kirkwood/profiles/120-plug.mk | 80 ++
2 files changed, 92 insertions(+)
create mode 100644 target/linux/kirkwood/profiles/120-plug.mk
--
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/1] KIRKWOOD : add sheevaplug and derivatives
ADD some kirkwood FDT - SheevaPlug - SheevaPlug with eSATA - GuruplugServerPlus - Topkick1281P2 Signed-off-by: Gérald Kerma drea...@doukki.net --- target/linux/kirkwood/image/Makefile | 12 + target/linux/kirkwood/profiles/120-plug.mk | 80 ++ 2 files changed, 92 insertions(+) create mode 100644 target/linux/kirkwood/profiles/120-plug.mk diff --git a/target/linux/kirkwood/image/Makefile b/target/linux/kirkwood/image/Makefile index 5227ed2..ede7cb3 100644 --- a/target/linux/kirkwood/image/Makefile +++ b/target/linux/kirkwood/image/Makefile @@ -138,6 +138,18 @@ Image/InstallKernel/Template/IOMEGA_IX2_200=$(call Image/InstallKernel/Template, Image/BuildKernel/Template/POGOE02=$(call Image/BuildKernel/Template,pogo_e02) Image/InstallKernel/Template/POGOE02=$(call Image/InstallKernel/Template,pogo_e02) +Image/BuildKernel/Template/SHEEVAPLUG=$(call Image/BuildKernel/Template,sheevaplug) +Image/InstallKernel/Template/SHEEVAPLUG=$(call Image/InstallKernel/Template,sheevaplug) + +Image/BuildKernel/Template/SHEEVAPLUGSATA=$(call Image/BuildKernel/Template,sheevaplug-esata) +Image/InstallKernel/Template/SHEEVAPLUGSATA=$(call Image/InstallKernel/Template,sheevaplug-esata) + +Image/BuildKernel/Template/GuruplugServerPlus=$(call Image/BuildKernel/Template,guruplug-server-plus) +Image/InstallKernel/Template/GuruplugServerPlus=$(call Image/InstallKernel/Template,guruplug-server-plus) + +Image/BuildKernel/Template/Topkick1281P2=$(call Image/BuildKernel/Template,topkick) +Image/InstallKernel/Template/Topkick1281P2=$(call Image/InstallKernel/Template,topkick) + define Image/BuildKernel $(call Image/BuildKernel/Template/$(PROFILE)) endef diff --git a/target/linux/kirkwood/profiles/120-plug.mk b/target/linux/kirkwood/profiles/120-plug.mk new file mode 100644 index 000..3e45ca9 --- /dev/null +++ b/target/linux/kirkwood/profiles/120-plug.mk @@ -0,0 +1,80 @@ +# +# Copyright (C) 2014 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +define Profile/SHEEVAPLUG + NAME:=Globalscale Technologies SheevaPlug + PACKAGES:= \ + kmod-mmc kmod-mvsdio kmod-usb2 kmod-usb-storage \ + kmod-of-i2c kmod-i2c-core kmod-i2c-mv64xxx \ + kmod-ata-core uboot-envtools +endef + +define Profile/SHEEVAPLUG/Description + Package set compatible with Globalscale Technologies SheevaPlug board. +endef + +SHEEVAPLUG_UBIFS_OPTS:=-m 2048 -e 126KiB -c 4096 +SHEEVAPLUG_UBI_OPTS:=-m 2048 -p 128KiB -s 512 + +$(eval $(call Profile,SHEEVAPLUG)) + +define Profile/SHEEVAPLUGSATA + NAME:=Globalscale Technologies eSATA SheevaPlug + PACKAGES:= \ + kmod-mmc kmod-mvsdio kmod-usb2 kmod-usb-storage \ + kmod-of-i2c kmod-i2c-core kmod-i2c-mv64xxx \ + kmod-ata-core kmod-ata-marvell-sata \ + uboot-envtools +endef + +define Profile/SHEEVAPLUGSATA/Description + Package set compatible with Globalscale Technologies eSATA SheevaPlug board. +endef + +SHEEVAPLUGSATA_UBIFS_OPTS:=-m 2048 -e 126KiB -c 4096 +SHEEVAPLUGSATA_UBI_OPTS:=-m 2048 -p 128KiB -s 512 + +$(eval $(call Profile,SHEEVAPLUGSATA)) + +define Profile/GuruplugServerPlus + NAME:=Globalscale Technologies Guruplug Server Plus + PACKAGES:= \ + kmod-mmc kmod-mvsdio kmod-usb2 kmod-usb-storage \ + kmod-of-i2c kmod-i2c-core kmod-i2c-mv64xxx \ + kmod-ata-core kmod-ata-marvell-sata \ + kmod-btmrvl kmod-btmrvl-sdio kmod-libertas kmod-libertas-sdio \ + uboot-envtools +endef + +define Profile/GuruplugServerPlus/Description + Package set compatible with Globalscale Technologies Guruplug Server Plus board. +endef + +GuruplugServerPlus_UBIFS_OPTS:=-m 2048 -e 126KiB -c 4096 +GuruplugServerPlus_UBI_OPTS:=-m 2048 -p 128KiB -s 512 + +$(eval $(call Profile,GuruplugServerPlus)) + +define Profile/Topkick1281P2 + NAME:=Univeral Scientific Industrial Co. Topkick-1281P2 + PACKAGES:= \ + kmod-mmc kmod-mvsdio kmod-usb2 kmod-usb-storage \ + kmod-of-i2c kmod-i2c-core kmod-i2c-mv64xxx \ + kmod-ata-core kmod-ata-marvell-sata \ + uboot-envtools +endef + +define Profile/Topkick1281P2/Description + Package set compatible with Univeral Scientific Industrial Co. Topkick-1281P2 board. +endef + +Topkick1281P2_UBIFS_OPTS:=-m 2048 -e 126KiB -c 4096 +Topkick1281P2_UBI_OPTS:=-m 2048 -p 128KiB -s 512 + +$(eval $(call Profile,Topkick1281P2)) + + -- 2.1.3 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar8216: phy_init and bug report 18415
On Nov 28, 2014 3:24 PM, Weedy weedy2...@gmail.com wrote: On Nov 28, 2014 5:23 AM, Heiner Kallweit hkallwe...@gmail.com wrote: Anybody with a 8216-based device who can test this? Me me me, me me. 4300 currently running trunk with 43332 reverted. I am at your service. Is the current trunk fixed? You never replied after this. Do I need to keep 43332 reverted to keep autoneg working? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
