Re: [LEDE-DEV] [PATCH v3 1/5] ipq806x/nbg6817: add support for ZyXEL NBG6817
Hi! Am 23.10.2016 um 16:38 schrieb Felix Fietkau: > On 2016-10-23 16:25, André Valentin wrote: >> CPU: 2x1.8GHz ARM, RAM: 512MiB >> Storage: 4MiB serial Flash, 3.9GiB MMC >> NIC: 2x1GBit/s, Switch with 5 external and 2 internal ports >> WiFi: Dualband, ath10k 2.4GHz, 5GHz MU-MIMO >> >> For installation copy xx-mmcblk0p4-kernel.bin and >> xx-mmcblk0p5-rootfs-full.bin >> to device. Then run: >> cat xx-mmcblk0p4-kernel.bin > /dev/mmc0blk0p4 >> cat xx-mmcblk0p5-rootfs-full.bin > /dev/mmc0blk0p5 >> reboot -f >> >> For debugging serial console is easily visible on board, no soldering needed. >> >> Signed-off-by: André Valentin >> --- >> .../linux/ipq806x/base-files/etc/board.d/01_leds | 5 + >> .../ipq806x/base-files/etc/board.d/02_network | 7 + >> .../etc/hotplug.d/firmware/11-ath10k-caldata | 6 + >> target/linux/ipq806x/base-files/lib/ipq806x.sh | 3 + >> target/linux/ipq806x/config-4.4| 18 +- >> .../arch/arm/boot/dts/qcom-ipq8065-nbg6817.dts | 341 >> + >> target/linux/ipq806x/image/Makefile| 26 +- >> .../linux/ipq806x/patches-4.4/800-devicetree.patch | 3 +- >> 8 files changed, 401 insertions(+), 8 deletions(-) >> create mode 100644 >> target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8065-nbg6817.dts >> > >> diff --git a/target/linux/ipq806x/image/Makefile >> b/target/linux/ipq806x/image/Makefile >> index b74f1a7..e7d4bf2 100644 >> --- a/target/linux/ipq806x/image/Makefile >> +++ b/target/linux/ipq806x/image/Makefile >> @@ -90,6 +90,19 @@ define Device/TpSafeImage >> endef >> DEVICE_VARS += TPLINK_BOARD_NAME >> >> +define Device/ZyXELImage >> +PROFILES += $$(DEVICE_NAME) >> +FILESYSTEMS := squashfs >> +KERNEL_SUFFIX := -uImage >> +KERNEL = kernel-bin | append-dtb | uImage none | pad-to $$(KERNEL_SIZE) >> +KERNEL_NAME := zImage >> +IMAGES := sysupgrade.tar mmcblk0p5-rootfs.bin mmcblk0p5-rootfs-full.bin >> mmcblk0p4-kernel.bin >> +IMAGE/sysupgrade.tar := sysupgrade-tar >> +IMAGE/mmcblk0p5-rootfs.bin := append-rootfs | pad-rootfs | pad-to >> $$(BLOCKSIZE) >> +IMAGE/mmcblk0p5-rootfs-full.bin := append-rootfs | pad-rootfs | pad-to >> $$(ROOTFS_SIZE) > Please drop the -full.bin, it wastes space. > Change -rootfs.bin to append-rootfs | pad-extra 128k, similar to how it > is handled on the octeon target. That is enough to ensure that it > re-creates the overlay filesystem on first boot. > Change the sysupgrade.tar image to: > > IMAGE/sysupgrade.tar/squashfs := append-rootfs | pad-extra 128k | > sysupgrade-tar rootfs=@ > I would not pad more than the blocksize to the rootfs. My sysupgrade process calculates the offset for the rootfs_data. That would break. That's why I added the full bin, for recovery cases. But I'll drop it. > > - Felix > smime.p7s Description: S/MIME Cryptographic Signature ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v3 3/5] ipq806x/nbg6817: add sysupgrade support
Hi!
Am 23.10.2016 um 16:44 schrieb Felix Fietkau:
> On 2016-10-23 16:25, André Valentin wrote:
>> Add new way of flashing to mmc devices based on rootfs split with loop
>> devices.
>>
>> Signed-off-by: André Valentin
>> ---
>> .../ipq806x/base-files/lib/upgrade/platform.sh | 12 +++
>> .../linux/ipq806x/base-files/lib/upgrade/zyxel.sh | 94
>> ++
>> 2 files changed, 106 insertions(+)
>> create mode 100644 target/linux/ipq806x/base-files/lib/upgrade/zyxel.sh
>>
>> diff --git a/target/linux/ipq806x/base-files/lib/upgrade/zyxel.sh
>> b/target/linux/ipq806x/base-files/lib/upgrade/zyxel.sh
>> new file mode 100644
>> index 000..d228dab
>> --- /dev/null
>> +++ b/target/linux/ipq806x/base-files/lib/upgrade/zyxel.sh
>> @@ -0,0 +1,94 @@
>> +#
>> +# Copyright (C) 2016 lede-project.org
>> +#
>> +
>> +zyxel_get_rootfs() {
>> +local rootfsdev
>> +
>> +if read cmdline < /proc/cmdline; then
>> +case "$cmdline" in
>> +*block2mtd=*)
>> +rootfsdev="${cmdline##*block2mtd=}"
>> +rootfsdev="${rootfsdev%%,*}"
>> +;;
> You can drop the block2mtd part here.
I'll remove it.
>
>> +*root=*)
>> +rootfsdev="${cmdline##*root=}"
>> +rootfsdev="${rootfsdev%% *}"
>> +;;
>> +esac
>> +
>> +echo "${rootfsdev}"
>> +fi
>> +}
>> +
>> +zyxel_do_flash() {
>> +local tar_file=$1
>> +local board=$2
>> +local kernel=$3
>> +local rootfs=$4
>> +local blocksize=65536
>> +
>> +# keep sure its unbound
>> +losetup --detach-all || {
>> +echo Failed to detach all loop devices. Skip this try.
>> +reboot -f
>> +}
>> +
>> +echo "flashing kernel to /dev/${kernel}"
>> +tar xf $tar_file sysupgrade-$board/kernel -O >/dev/$kernel
>> +
>> +echo "flashing rootfs to ${rootfs}"
>> +tar xf $tar_file sysupgrade-$board/root -O >"${rootfs}"
>> +
>> +local offset=$(tar xf $tar_file sysupgrade-$board/root -O | wc -c)
>> +offset=$(( (($offset + $blocksize - 1) / $blocksize) * $blocksize ))
>> +
>> +# Sanity
>> +[ $offset -lt $blocksize ] && {
>> +echo Wrong size for rootfs: $offset
>> +sleep 10
>> +reboot -f
>> +}
>> +
>> +# Mount loop for rootfs_data
>> +losetup -o $offset /dev/loop0 "${rootfs}" || {
>> +echo "Failed to mount looped rootfs_data."
>> +sleep 10
>> +reboot -f
>> +}
>> +
>> +echo "Format new rootfs_data at position ${offset}."
>> +mkfs.ext4 -F -L rootfs_data /dev/loop0
>> +mkdir /tmp/new_root
>> +mount -t ext4 /dev/loop0 /tmp/new_root && {
>> +echo "Saving config to rootfs_data at position ${offset}."
>> +cp -v /tmp/sysupgrade.tgz /tmp/new_root/
>> +umount /tmp/new_root
>> +}
>> +
>> +# Cleanup
>> +losetup -d /dev/loop0 >/dev/null 2>&1
> I think trying to guesstimate the offset for the ext4 part here, when
> fstools already handles some of that is a bit fragile. Things like the
> block size might be changed at some point, so I think it would be a good
> idea to extend fstools to be able deal with this stuff.
I think we need to store the blocksize in the sysupgrade/control. Because it
could
change between 2 firmwares. What dou you think. In this case an fstools patch is
not needed.
Kind regards,
André
smime.p7s
Description: S/MIME Cryptographic Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v3 3/5] ipq806x/nbg6817: add sysupgrade support
On 2016-10-24 09:51, André Valentin wrote:
> Hi!
>
> Am 23.10.2016 um 16:44 schrieb Felix Fietkau:
>> On 2016-10-23 16:25, André Valentin wrote:
>>> Add new way of flashing to mmc devices based on rootfs split with loop
>>> devices.
>>>
>>> Signed-off-by: André Valentin
>>> ---
>>> .../ipq806x/base-files/lib/upgrade/platform.sh | 12 +++
>>> .../linux/ipq806x/base-files/lib/upgrade/zyxel.sh | 94
>>> ++
>>> 2 files changed, 106 insertions(+)
>>> create mode 100644 target/linux/ipq806x/base-files/lib/upgrade/zyxel.sh
>>>
>>> diff --git a/target/linux/ipq806x/base-files/lib/upgrade/zyxel.sh
>>> b/target/linux/ipq806x/base-files/lib/upgrade/zyxel.sh
>>> new file mode 100644
>>> index 000..d228dab
>>> --- /dev/null
>>> +++ b/target/linux/ipq806x/base-files/lib/upgrade/zyxel.sh
>>> @@ -0,0 +1,94 @@
>>> +#
>>> +# Copyright (C) 2016 lede-project.org
>>> +#
>>> +
>>> +zyxel_get_rootfs() {
>>> + local rootfsdev
>>> +
>>> + if read cmdline < /proc/cmdline; then
>>> + case "$cmdline" in
>>> + *block2mtd=*)
>>> + rootfsdev="${cmdline##*block2mtd=}"
>>> + rootfsdev="${rootfsdev%%,*}"
>>> + ;;
>> You can drop the block2mtd part here.
>
> I'll remove it.
>>
>>> + *root=*)
>>> + rootfsdev="${cmdline##*root=}"
>>> + rootfsdev="${rootfsdev%% *}"
>>> + ;;
>>> + esac
>>> +
>>> + echo "${rootfsdev}"
>>> + fi
>>> +}
>>> +
>>> +zyxel_do_flash() {
>>> + local tar_file=$1
>>> + local board=$2
>>> + local kernel=$3
>>> + local rootfs=$4
>>> + local blocksize=65536
>>> +
>>> + # keep sure its unbound
>>> + losetup --detach-all || {
>>> + echo Failed to detach all loop devices. Skip this try.
>>> + reboot -f
>>> + }
>>> +
>>> + echo "flashing kernel to /dev/${kernel}"
>>> + tar xf $tar_file sysupgrade-$board/kernel -O >/dev/$kernel
>>> +
>>> + echo "flashing rootfs to ${rootfs}"
>>> + tar xf $tar_file sysupgrade-$board/root -O >"${rootfs}"
>>> +
>>> + local offset=$(tar xf $tar_file sysupgrade-$board/root -O | wc -c)
>>> + offset=$(( (($offset + $blocksize - 1) / $blocksize) * $blocksize ))
>>> +
>>> + # Sanity
>>> + [ $offset -lt $blocksize ] && {
>>> + echo Wrong size for rootfs: $offset
>>> + sleep 10
>>> + reboot -f
>>> + }
>>> +
>>> + # Mount loop for rootfs_data
>>> + losetup -o $offset /dev/loop0 "${rootfs}" || {
>>> + echo "Failed to mount looped rootfs_data."
>>> + sleep 10
>>> + reboot -f
>>> + }
>>> +
>>> + echo "Format new rootfs_data at position ${offset}."
>>> + mkfs.ext4 -F -L rootfs_data /dev/loop0
>>> + mkdir /tmp/new_root
>>> + mount -t ext4 /dev/loop0 /tmp/new_root && {
>>> + echo "Saving config to rootfs_data at position ${offset}."
>>> + cp -v /tmp/sysupgrade.tgz /tmp/new_root/
>>> + umount /tmp/new_root
>>> + }
>>> +
>>> + # Cleanup
>>> + losetup -d /dev/loop0 >/dev/null 2>&1
>> I think trying to guesstimate the offset for the ext4 part here, when
>> fstools already handles some of that is a bit fragile. Things like the
>> block size might be changed at some point, so I think it would be a good
>> idea to extend fstools to be able deal with this stuff.
>
> I think we need to store the blocksize in the sysupgrade/control. Because it
> could
> change between 2 firmwares. What dou you think. In this case an fstools patch
> is
> not needed.
You're right. I don't think we have a good place to store it though. I
still would prefer to unify the code in fstools anyway instead of
open-coding the same in the shell script.
- Felix
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] regulatory domain information
On 2016-10-19 23:31, Charles wrote: > Hello, > > on a TP-Link WDR3600 v1 (dual-band wifi, ath9k, wireless settings are > attached below, most notably wireless.radioX.country=DE), the output > of command 'iw reg get' is > > with OpenWrt 15.05.1: > > country DE: DFS-ETSI > (2400 - 2483 @ 40), (N/A, 20), (N/A) > (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR > (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS > (5470 - 5725 @ 160), (N/A, 27), (0 ms), DFS > (57000 - 66000 @ 2160), (N/A, 40), (N/A) > > and with current LEDE: > > global > country DE: DFS-ETSI > (2400 - 2483 @ 40), (N/A, 20), (N/A) > (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR, AUTO-BW > (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW > (5470 - 5725 @ 160), (N/A, 27), (0 ms), DFS > (5725 - 5875 @ 80), (N/A, 14), (N/A) > (57000 - 66000 @ 2160), (N/A, 40), (N/A) > > phy#1 > country US: DFS-FCC > (2402 - 2472 @ 40), (N/A, 30), (N/A) > (5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW > (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW > (5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS > (5735 - 5835 @ 80), (N/A, 30), (N/A) > (57240 - 63720 @ 2160), (N/A, 40), (N/A) > > phy#0 > country US: DFS-FCC > (2402 - 2472 @ 40), (N/A, 30), (N/A) > (5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW > (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW > (5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS > (5735 - 5835 @ 80), (N/A, 30), (N/A) > (57240 - 63720 @ 2160), (N/A, 40), (N/A) > > global > country DE: DFS-ETSI > (2400 - 2483 @ 40), (N/A, 20), (N/A) > (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR, AUTO-BW > (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW > (5470 - 5725 @ 160), (N/A, 27), (0 ms), DFS > (5725 - 5875 @ 80), (N/A, 14), (N/A) > (57000 - 66000 @ 2160), (N/A, 40), (N/A) > > Questions: > > 1. Why does LEDE show four regulatory domain blocks while OpenWrt shows >only one? This was added in Linux upstream. LEDE uses a newer version of mac80211. > 2. What does the "country US: DFS-FCC" blocks tell me when radio is set >to an ETSI region country (DE) according to uci? Please try the latest version from my staging tree at: https://git.lede-project.org/?p=lede/nbd/staging.git;a=summary > 3. What does AUTO-BW mean? It means maximum channel bandwidth is determined by the available frequency range. - Felix ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] brcm47xx: open code Makefile entries for all devices
On 20 October 2016 at 08:02, Rafał Miłecki wrote: > From: Rafał Miłecki > > If we want to use some of new features like per device rootfs we will > need this to specify them there. > > Signed-off-by: Rafał Miłecki Pushed with spaces instead of tabs to match other targets. Thanks Felix. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Actual community change and additional developers compared to OpenWrt
Hi Daniel, > Several months after the split it looks like things have pretty much > ended up where they were before the split. It's starting to look > like the talk of encouraging new blood, and being more open and > transparent was more talk than real intention. I am sorry to hear that this is your perception, yet it does not match mine. In my view, the project is transparent about the things being done, discussions are encouraged and new people getting on board. Not sure what you miss exactly or what your perceived problems are. Is it because your PRs are not quickly merged? Many of your PRs had actual errors in them, later you swamped Github with dozens of untested PRs to facilitate discussions, then you went mia, now you're back here accusing the participating people of baseless talking. What exactly is it what you miss, what would you make better and how would you implement your visions? > As much as I've gotten busy with personal issues that landed me in > the hospital (sadly not before I did damage; although I stand by the > statement that there was far too much hostility in the openwrt > private discussions), I'm not sure why a split was necessary to get > to where things are now. LEDE is still pretty much a closed group > with basically the same group of core developers as ever. Not sure what makes you think that this is a closed group, so far anyone with a good contribution record got access when he asked for it, both in LEDE and even back in OpenWrt. Note that being open and encouraging new blood does not mean mindlessly clicking the big green merge button on any proposed Github PR since some quality standards still must be met when merging changes. > I would do more if I could, but I've got problems of my own to deal > with; I joined Facebook to reconnect with old friends because part > of the reason I was so vocal was that I had gotten isolated as well > as unwell, but the bounce back has been slow, and I'm not where I > need to be to work towards a better solution myself. Part of the > problem, I think, is the lack of clear and consistent (and visible) > governance and communication makes the project unappealing for > companies to be interested in paying developers to work on either. What kind of clear and transparent governance discussion do you miss? Ad-hoc decisions are made in IRC or on the lists. Previous attempts to facilitate wider governance discussions just fizzled out with little to no interest in actually tackling the problem. Do you want the project to make a five year plan on what to do when in which time frame? Do you want us to blog about the things we do? Please name concrete examples what could be done better and then lets discuss about it. > It's not enough to have code and commits, there needs to be a > communications strategy as well, or the projects will die. If you feel the need for a broad communication strategy then maybe give it a try yourself and invest time into it; summarize current discussions, raise issues on the list, interview others and blog about IRC chatter, relay information back and forth etc. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] kirkwood: remove redundant code in etc/board.d/02_network
On 23/10/2016 12:42, p.wa...@gmx.at wrote: > From: Paul Wassi > > Remove redundant code: merge boards/cases that share > the same network configuration. > > Signed-off-by: Paul Wassi patch does not apply to current HEAD. what tree did you base this on ? John > --- > linux/kirkwood/base-files/etc/board.d/02_network | 13 - > 1 file changed, 4 insertions(+), 9 deletions(-) > > diff --git a/target/linux/kirkwood/base-files/etc/board.d/02_network > b/target/linux/kirkwood/base-files/etc/board.d/02_network > --- a/target/linux/kirkwood/base-files/etc/board.d/02_network > +++ b/target/linux/kirkwood/base-files/etc/board.d/02_network > @@ -17,13 +17,12 @@ case "$board" in > "iconnect"|\ > "ib62x0"|\ > "nsa310s"|\ > -"pogo_e02") > +"pogo_e02"|\ > +"sheevaplug"|\ > +"sheevaplug-esata") > ucidef_set_interface_lan "eth0" "dhcp" > ;; > -"linksys-audi") > - ucidef_add_switch "switch0" \ > - "0:lan" "1:lan" "2:lan" "3:lan" "4:wan" "5@eth0" "6@eth1" > - ;; > +"linksys-audi"|\ > "linksys-viper") > ucidef_add_switch "switch0" \ > "0:lan" "1:lan" "2:lan" "3:lan" "4:wan" "5@eth0" "6@eth1" > @@ -31,10 +30,6 @@ case "$board" in > "guruplug-server-plus") > ucidef_set_interface_lan "eth0 eth1" "dhcp" > ;; > -"sheevaplug" | \ > -"sheevaplug-esata") > - ucidef_set_interface_lan "eth0" "dhcp" > - ;; > *) > ucidef_set_interface_lan "eth0" > ;; > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev > ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] package/system/mtd: fix usage message
On 24/10/2016 08:41, p.wa...@gmx.at wrote:
> From: Paul Wassi
>
> Minor fix in the usage message on the explanation of the -p option.
>
> Signed-off-by: Paul Wassi
this one also fails to apply
John
> ---
> system/mtd/src/mtd.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/package/system/mtd/src/mtd.c b/package/system/mtd/src/mtd.c
> --- a/package/system/mtd/src/mtd.c
> +++ b/package/system/mtd/src/mtd.c
> @@ -732,7 +732,7 @@ static void usage(void)
> "-ddirectory for jffs2write, defaults
> to \"tmp\"\n"
> "-jintegrate into jffs2 data
> when writing an image\n"
> "-s skip the first n bytes when
> appending data to the jffs2 partiton, defaults to \"0\"\n"
> - "-p write beginning at partition
> offset\n"
> + "-p write beginning at partition
> offset\n"
> "-l the length of data that we want to
> dump\n");
> if (mtd_fixtrx) {
> fprintf(stderr,
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/3 v2] ar71xx: add mac partition to the MR12/MR16
On 21/10/2016 13:54, Chris Blake wrote:
> On the stock Meraki Firmare for the MR12/MR16, a chunk of SPI space
> after u-boot-env is used to store the boards Mac address. Sadly as this
> was removed on any device already on OpenWRT/LEDE, moving forward a new,
> 64k partition named "mac" will be used to store the mac address for the
> device (which is the minimum size). This allows users to properly set
> the correct MAC, without editing the ART partition (which holds the same
> MAC for all devices).
>
> The reason the space is taken from kernel instead of rootfs is currently
> kernels are only 1.3MB, so that way we can leave the current rootfs
> space alone for users who fully utilize the available storage space.
>
> Once this partition is added to a device, you can set your MAC doing the
> following:
>
> mtd erase mac
> echo -n -e '\x00\x18\x0a\x33\x44\x55' > /dev/mtd5
> sync && reboot
>
> Where 00:18:0a:33:44:55 is your MAC address.
>
> This was tested, and confirmed working on both the MR12 and MR16.
>
> Signed-off-by: Chris Blake
Hi,
patch fails to apply. please rebase on current HEAD and resend all 3 patches
John
> ---
> .../linux/ar71xx/files/arch/mips/ath79/mach-mr12.c | 14 +++---
> .../linux/ar71xx/files/arch/mips/ath79/mach-mr16.c | 22
> +++---
> target/linux/ar71xx/image/generic.mk | 4 ++--
> 3 files changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr12.c
> b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr12.c
> index 12c9a1c..dc880c5 100644
> --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr12.c
> +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr12.c
> @@ -42,8 +42,7 @@
>
> #define MR12_WAN_PHYMASKBIT(4)
>
> -#define MR12_WMAC0_MAC_OFFSET 0x120c
> -#define MR12_CALDATA0_OFFSET0x1000
> +#define MR12_CALDATA0_OFFSET0x21000
>
> static struct gpio_led MR12_leds_gpio[] __initdata = {
> {
> @@ -90,8 +89,9 @@ static struct gpio_keys_button MR12_gpio_keys[] __initdata
> = {
>
> static void __init MR12_setup(void)
> {
> - u8 *mac = (u8 *) KSEG1ADDR(0xbfff);
> -
> + u8 *mac = (u8 *) KSEG1ADDR(0xbffd);
> + u8 wlan_mac[ETH_ALEN];
> +
> ath79_register_mdio(0,0x0);
>
> ath79_init_mac(ath79_eth0_data.mac_addr, mac, 0);
> @@ -107,9 +107,9 @@ static void __init MR12_setup(void)
> ARRAY_SIZE(MR12_gpio_keys),
> MR12_gpio_keys);
>
> - ap91_pci_init(mac + MR12_CALDATA0_OFFSET,
> - mac + MR12_WMAC0_MAC_OFFSET);
> + ath79_init_mac(wlan_mac, mac, 1);
> + ap91_pci_init(mac + MR12_CALDATA0_OFFSET, wlan_mac);
>
> }
>
> -MIPS_MACHINE(ATH79_MACH_MR12, "MR12", "Meraki MR12", MR12_setup);
> \ No newline at end of file
> +MIPS_MACHINE(ATH79_MACH_MR12, "MR12", "Meraki MR12", MR12_setup);
> diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr16.c
> b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr16.c
> index 9f08e3d..2897ee5 100644
> --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr16.c
> +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr16.c
> @@ -42,10 +42,8 @@
>
> #define MR16_WAN_PHYMASKBIT(0)
>
> -#define MR16_WMAC0_MAC_OFFSET0x120c
> -#define MR16_WMAC1_MAC_OFFSET0x520c
> -#define MR16_CALDATA0_OFFSET 0x1000
> -#define MR16_CALDATA1_OFFSET 0x5000
> +#define MR16_CALDATA0_OFFSET 0x21000
> +#define MR16_CALDATA1_OFFSET 0x25000
>
> static struct gpio_led MR16_leds_gpio[] __initdata = {
> {
> @@ -92,8 +90,10 @@ static struct gpio_keys_button MR16_gpio_keys[] __initdata
> = {
>
> static void __init MR16_setup(void)
> {
> - u8 *mac = (u8 *) KSEG1ADDR(0xbfff);
> -
> + u8 *mac = (u8 *) KSEG1ADDR(0xbffd);
> + u8 wlan0_mac[ETH_ALEN];
> + u8 wlan1_mac[ETH_ALEN];
> +
> ath79_register_mdio(0,0x0);
>
> ath79_init_mac(ath79_eth0_data.mac_addr, mac, 0);
> @@ -109,10 +109,10 @@ static void __init MR16_setup(void)
> ARRAY_SIZE(MR16_gpio_keys),
> MR16_gpio_keys);
>
> - ap94_pci_init(mac + MR16_CALDATA0_OFFSET,
> - mac + MR16_WMAC0_MAC_OFFSET,
> - mac + MR16_CALDATA1_OFFSET,
> - mac + MR16_WMAC1_MAC_OFFSET);
> + ath79_init_mac(wlan0_mac, mac, 1);
> + ath79_init_mac(wlan1_mac, mac, 2);
> + ap94_pci_init(mac + MR16_CALDATA0_OFFSET, wlan0_mac,
> + mac + MR16_CALDATA1_OFFSET, wlan1_mac);
> }
>
> -MIPS_MACHINE(ATH79_MACH_MR16, "MR16", "Meraki MR16", MR16_setup);
> \ No newline at end of file
> +MIPS_MACHINE(ATH79_MACH_MR16, "MR16", "Meraki MR16", MR16_setup);
> diff --git a/target/linux/ar71xx/image/generic.mk
> b/target/linux/ar71xx/image/generic.mk
> index 04fed88..ee910af 100644
> --- a/target/linux/ar71xx/i
Re: [LEDE-DEV] Actual community change and additional developers compared to OpenWrt
Hi Alberto, > I think it's mostly because of the usual reasons in opensource projects. > Core developers are overloaded, and in what little time they have they > prefer to code (understandable, but same self-defying issues in OpenWRT). IMHO this summarizes the current situation quite nicely and I'd say I agree with it completely. Note that we're trying to slowly dig ourselves out of the hole we made ourselves over the years but it requires time and dedication. I for example would love to lean back a bit and start caring more about community matters and communication but before I can do that, we need to find some more people compensate the missing developer time. > IMHO The only way we can get over this situation is if current core > developers start giving others responsibility over some parts of the > LEDE system/infrastructure, This is what we're trying to do with the Wiki atm. On the infrastructure administration side, I am glad that Ted helps me with handling things and for the wiki hosts we handed administration access directly to the wiki moderators to minimize friction. > put down some decent documentation about > current state of affairs in LEDE programs (what they do now and what > they should do) That is sorely lacking atm ... > and guidelines for checking contributions (mostly for > people that must check if the patch/PR is valid). ... and I partly agree here as well. I would be interested in a more contributor oriented insight at this point. For example it took me a while to realize that being on Github suddenly means that people edit C code via the web interface without any means to syntax / compile / run test their changes or to sign off their commits. The problem of such unsuitable contributions can be tackled from different angles, first by improving documentation and enable people to do better changes in less time and second by lowering the entry barriers somewhat (while increasing developer workload), for example by stating that a "Signed-off-by" in the PR description alone is enough and requiring the developer doing the merge to copy the signoff into the commit. One should keep in mind though that lowering the contribution quality requirements increases the individual workload even more, at least in the short term, until the increased contribution-friendliness eventually leads to more man power in the long run. > I'm taking the linux kernel as a model where things are split up in > subsystems and each subsystem has one or more mantainers. Yes it is not > a headless commune, but it isn't a nazi-like authoritarian regime either > (even if Torvalds likes to shout at people). The Linux kernel is a good goal for a distributed and delegated development model but one must keep the very high entry barrier in mind - it is hard to write kernel code, most people working on it already are professionals, there are no real bug trackers or easy web based pull request choices available and the main contribution channel is very active mailing lists, forcing potential contributors to send proper changes from the get-go. All that is making it easier (or in the case of the Kernel possible at all) for the developers to cope with the steady stream of incoming patches. As a somewhat related anecdote, people already neglected LEDE because it requires real names and sign-offs in its Github pull requests - deeming it a too high burden to invest time. Such contributors would never be able to contribute anything to the Linux kernel. > That way you can have a person that has commit access but can only > commit stuff of his subsystem, and core devs only need to look at stuff > filtered by others (or not if they don't have time). Personally I'd like to move away from the fixed role of core developers but I agree that some kind of multi-tiered system is likely unavoidable. > This is the only way you can have more people in that checks incoming > code and core devs can be less overloaded and can actually take > decisions for the project where needed, or put down developer > documentation (what we have is very outdated and partial). I agree. > I understand that people have a life and all, but a project like this > cannot run headless forever because the 2-3 people that have access are > busy. Solution -> more people with access, each to specific areas. Agreed, we just need volunteers with a somewhat proven track record at this stage. Personally I see no problem with letting more people push directly. > Really, there are already quite a few large-ish and not-so-large PRs > rotting on Github, you can't afford to let them sit there for too long > or the people will lose interest in sending them, and think you are the > same as OpenWRT. Which brings me to another yet unsolved point. There are large PRs (think the Mikrotik changes) which are unsuitable for inclusion as-is, yet too worthwhile to be left rotting. Maturing such change series takes time and needs to be happen in a dedi
Re: [LEDE-DEV] [PATCH V2 0/7] add support for D-Link DAP-2695 rev. A1
On 21/10/2016 17:34, Stijn Tintel wrote: > This patch series adds support for D-Link DAP-2695 rev. A1. > > Both the factory and the sysupgrade can be used to flash the device from > the bootloader. When flashing via the web interface of the stock > firmware, only the factory image can be used. > > With the stock firmware, this device is only usable as a dumb AP. With > LEDE, it is configured as a router by default. The LAN1(PoE) port is > configured as the LAN port, the LAN2 port is configured as the WAN port. > > The only thing that doesn't work, is the 5GHz LED, as it does not seem > to be connected to any of the SoC's GPIOs. > > The WRGG naming comes from the D-Link GPL code. The mkwrggimg utility > also works for the D-Link DAP-2553. For more info, see > https://forum.openwrt.org/viewtopic.php?id=52048 > > Changes since v1: > Remove physical address of the FSF from wrgg.c > Fix endianness detection on musl in mtd > Build relocate stub for generic and legacy images > Remove ucidef_set_interfaces_lan_wan > series looks good feel free to push it Acked-by: John Crispin > Stijn Tintel (7): > firmware-utils: mkwrggimg: new tool for D-Link DAP-2695 > kernel: mtdsplit: add support for WRGG images > mtd: fix endianness detection on musl > mtd: add fixwrgg command > ar71xx/base-files: rename 09_fix-trx-header 09_fix-checksum > ar71xx: build relocate stub for generic and legacy images > ar71xx: add support for D-Link DAP-2695 rev. A1 > > package/boot/uboot-envtools/files/ar71xx | 1 + > package/system/mtd/src/Makefile| 3 +- > package/system/mtd/src/mtd.c | 29 ++- > package/system/mtd/src/mtd.h | 1 + > package/system/mtd/src/seama.c | 1 + > package/system/mtd/src/wrgg.c | 190 ++ > package/system/mtd/src/wrgg.h | 20 ++ > target/linux/ar71xx/base-files/etc/board.d/01_leds | 5 + > .../linux/ar71xx/base-files/etc/board.d/02_network | 3 + > .../etc/hotplug.d/firmware/11-ath10k-caldata | 4 + > .../base-files/etc/uci-defaults/09_fix-checksum| 28 ++ > .../base-files/etc/uci-defaults/09_fix-trx-header | 19 -- > target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 + > .../ar71xx/base-files/lib/upgrade/platform.sh | 13 + > target/linux/ar71xx/config-4.4 | 2 + > .../ar71xx/files/arch/mips/ath79/Kconfig.openwrt | 9 + > target/linux/ar71xx/files/arch/mips/ath79/Makefile | 1 + > .../files/arch/mips/ath79/mach-dap-2695-a1.c | 191 ++ > .../linux/ar71xx/files/arch/mips/ath79/machtypes.h | 1 + > target/linux/ar71xx/image/Makefile | 5 +- > target/linux/ar71xx/image/generic.mk | 29 +++ > target/linux/ar71xx/image/legacy.mk| 6 - > target/linux/generic/config-3.18 | 1 + > target/linux/generic/config-4.1| 1 + > target/linux/generic/config-4.4| 1 + > .../generic/files/drivers/mtd/mtdsplit/Kconfig | 5 + > .../generic/files/drivers/mtd/mtdsplit/Makefile| 1 + > .../files/drivers/mtd/mtdsplit/mtdsplit_wrgg.c | 109 > tools/firmware-utils/Makefile | 1 + > tools/firmware-utils/src/mkwrggimg.c | 282 > + > 30 files changed, 936 insertions(+), 29 deletions(-) > create mode 100644 package/system/mtd/src/wrgg.c > create mode 100644 package/system/mtd/src/wrgg.h > create mode 100644 > target/linux/ar71xx/base-files/etc/uci-defaults/09_fix-checksum > delete mode 100644 > target/linux/ar71xx/base-files/etc/uci-defaults/09_fix-trx-header > create mode 100644 > target/linux/ar71xx/files/arch/mips/ath79/mach-dap-2695-a1.c > create mode 100644 > target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_wrgg.c > create mode 100644 tools/firmware-utils/src/mkwrggimg.c > ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH, v2] kirkwood: remove redundant code in etc/board.d/02_network
From: Paul Wassi Remove redundant code: merge boards/cases that share the same network configuration. Also fix the alphabetical ordering of the cases. Signed-off-by: Paul Wassi --- linux/kirkwood/base-files/etc/board.d/02_network | 15 - 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/target/linux/kirkwood/base-files/etc/board.d/02_network b/target/linux/kirkwood/base-files/etc/board.d/02_network --- a/target/linux/kirkwood/base-files/etc/board.d/02_network +++ b/target/linux/kirkwood/base-files/etc/board.d/02_network @@ -14,16 +14,15 @@ case "$board" in "dockstar"|\ "goflexhome"|\ "goflexnet"|\ -"iconnect"|\ "ib62x0"|\ +"iconnect"|\ "nsa310s"|\ -"pogo_e02") +"pogo_e02"|\ +"sheevaplug"|\ +"sheevaplug-esata") ucidef_set_interface_lan "eth0" "dhcp" ;; -"linksys-audi") - ucidef_add_switch "switch0" \ - "0:lan" "1:lan" "2:lan" "3:lan" "4:wan" "5@eth0" "6@eth1" - ;; +"linksys-audi"|\ "linksys-viper") ucidef_add_switch "switch0" \ "0:lan" "1:lan" "2:lan" "3:lan" "4:wan" "5@eth0" "6@eth1" @@ -31,10 +30,6 @@ case "$board" in "guruplug-server-plus") ucidef_set_interface_lan "eth0 eth1" "dhcp" ;; -"sheevaplug" | \ -"sheevaplug-esata") - ucidef_set_interface_lan "eth0" "dhcp" - ;; *) ucidef_set_interface_lan "eth0" ;; ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH, v2] package/system/mtd: fix usage message
From: Paul Wassi
Minor fix in the usage message on the explanation of the -p option.
Signed-off-by: Paul Wassi
---
system/mtd/src/mtd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/system/mtd/src/mtd.c b/package/system/mtd/src/mtd.c
--- a/package/system/mtd/src/mtd.c
+++ b/package/system/mtd/src/mtd.c
@@ -732,7 +732,7 @@ static void usage(void)
"-ddirectory for jffs2write, defaults to
\"tmp\"\n"
"-jintegrate into jffs2 data when
writing an image\n"
"-s skip the first n bytes when appending
data to the jffs2 partiton, defaults to \"0\"\n"
- "-p write beginning at partition offset\n"
+ "-p write beginning at partition offset\n"
"-l the length of data that we want to
dump\n");
if (mtd_fixtrx) {
fprintf(stderr,
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC] brcm47xx: bump kernel to 4.4
On 23 October 2016 at 19:49, Rafał Miłecki wrote: > On 23 October 2016 at 12:15, wrote: >> As one of LEDE's TODOs is "Bump all kernels to v4.4", I've done >> some testing on two brcm47xx devices (brcm47xx is still on kernel 4.1). >> >> The devices I tested on + bootlog: >> Linksys WRT54GL - https://pwassi.privatedns.org/lede/brcm47xx/#wrt54gl >> ASUS WL500gP V2 - https://pwassi.privatedns.org/lede/brcm47xx/#wl500gpv2 >> >> I know, that there are much more devices on brcm47xx which are untested yet. >> However, these are the ones I have at home to play with and everything seems >> to work fine there. So what do you think about the following 'patch'? > > It breaks Linksys WRT300N V1 and that's why I still didn't bump it. > Last time I talked with Felix we suggested some offset in lzmaloader, > I hope to finally find time to try that... I started working on this today, I reproduce see the issue during a lot of tests until it magically disappeared. Then LEDE started booting on my unit with kernel 4.4. I bumped kernel with some lengthy description (for a further reference, just in case): https://git.lede-project.org/?p=source.git;a=commitdiff;h=06405df7a8da24b7d735b32454c7d3b1f2ebaabc -- Rafał ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Actual community change and additional developers compared to OpenWrt
On 10/24/2016 03:12 PM, Jo-Philipp Wich wrote: > we need to > find some more people compensate the missing developer time. > I'd say that you might want to make some kind of public announcement on the main site about this, stating what kinds of people you need and so on. Maybe also contact Phoronix and other linux-oriented news sites to spread the announcement. It is not obvious that you are also looking for people in key roles. > I would be interested in a more contributor oriented insight at this > point. For example it took me a while to realize that being on Github > suddenly means that people edit C code via the web interface without any > means to syntax / compile / run test their changes or to sign off their > commits. > I'd say that current contribution quality requirements from people doing minor edits are OK, LEDE is a big project. Would be cool to at least have an actual developer proof-read the current developer documentation and copy the correct parts in the LEDE wiki articles, even if raw and ugly. Formatting can be fixed by anyone (probably me) later. > Which brings me to another yet unsolved point. There are large PRs > (think the Mikrotik changes) which are unsuitable for inclusion as-is, > yet too worthwhile to be left rotting. > > Maturing such change series takes time and needs to be happen in a > dedicated staging tree, this is something we simply lack the man power > to do atm. That would be another useful area to have some help in - > having one or more persons who are able to incorporate requested > feedback into otherwise orphaned PRs to shape them up for inclusion. > I'm not sure about what you mean here, why you say "unsuitable for inclusion"? Would they be too disruptive to just merge as-is, at least until you find someone to do proper vetting on them? Consider that you won't get people to mature them so soon anyway, and if you leave them there they will likely rot and that may be worse. For the Mikrotik for example you could try asking the guy that submitted the patch to do this "maturing" after you merged it, for example as he seems to care about his patch, he rebased it for example. Explain him the issue if you can. This is a point where political and social needs (you want to look welcoming and want people to join you) clash with pure development needs (code quality issues). These may be the standards you have to lower, at least until you get more people in and you have the people to ensure higher code quality. Again take this as a suggestion, I don't know why you don't want to merge them and I can't probably comment on that anyway. >> The same about that guy from a wifi community asking the state of >> affairs. You can't let that go unanswered. Bad PR will add up and again >> people will think you are the same as OpenWRT. > > I am not sure what you refer to here exactly. > The mail "[LEDE-DEV] Stability & release plans" by l...@yanosz.net He might be a fake or not, but answering such questions is good usually. -Alberto ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v3 3/5] ipq806x/nbg6817: add sysupgrade support
Hi! Am 24.10.2016 um 10:05 schrieb Felix Fietkau: >> I think we need to store the blocksize in the sysupgrade/control. Because it >> could >> change between 2 firmwares. What dou you think. In this case an fstools >> patch is >> not needed. > You're right. I don't think we have a good place to store it though. I > still would prefer to unify the code in fstools anyway instead of > open-coding the same in the shell script. Okay, but chaning fstools to support that is a bigger thing for me. How do we handle this now? Kind regards, André smime.p7s Description: S/MIME Cryptographic Signature ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC] brcm47xx: bump kernel to 4.4
> I started working on this today, I reproduce see the issue during a > lot of tests until it magically disappeared. Then LEDE started booting > on my unit with kernel 4.4. Oh - that rings a bell. May I point you to a discussion we had earlier this year? http://lists.infradead.org/pipermail/lede-dev/2016-May/000980.html I had this issue on all my WRT54GLs: trunk images stopped booting at "Starting program at 0x80001000". However, if I compiled the images myself (with the exact same configuration as the buildbot), the images would boot fine. I later checked again: buildbot's images did not boot. (It was kernel 4.1 back then, but it's the exact same behaviour as you describe in the commit message) Additionally builtbot's images worked out-of-the-box on an ASUS WL500gP V2. Best regards, P. Wassi ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] regulatory domain information
on 2016-10-24 Felix Fietkau wrote: > On 2016-10-19 23:31, Charles wrote: > > > > Questions: > > > > 1. Why does LEDE show four regulatory domain blocks while OpenWrt shows > >only one? > This was added in Linux upstream. LEDE uses a newer version of mac80211. OK. Problem is, iw as a moving target seems not to be too well documented. Any recommended readings related to how iw reg output should to be interpreted? > > 3. What does AUTO-BW mean? > It means maximum channel bandwidth is determined by the available > frequency range. Thanks! Is that what AVM FritzBoxes call wireless coexistence? Can't see the relation to regulation, which is rather about primary and secondary users /not coexisting/. Well, as I said, some more iw documentation could help understanding (Linux) wireless better. > > 2. What does the "country US: DFS-FCC" blocks tell me when radio is set > >to an ETSI region country (DE) according to uci? > Please try the latest version from my staging tree at: > https://git.lede-project.org/?p=lede/nbd/staging.git;a=summary Oh, I'm not a developer, but building custom images with the image generator so far. With the recent enabling of IPv6 in the kernel so that it cannot be disabled by removing some packages in the image generator, I do have a need to switch to compiling images anyway. Will report back (and more problems) when I have kept up with that. Thanks again! Charles ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Stability & release plans
Hi yanosz, Alberto kindly pointed out that your inquiry didn't receive any response so far, so please excuse the lack of communication. > running a community based wifi network based on OpenWRT I'm thinking > about using lede. Do you have any suggestions on this? The general suggestion is always to stick with whatever works for you - if OpenWrt is solid for you at the moment then it might make sense to stay on it until there are really pressing reasons to change. > For doing so, I see the need for a more less stable base (stable as in: > few bugs, few refactorings / changes over time) Looking at lede at > moment I seed nightly builds and agile moving trunk, only. Exactly, LEDE has no fixed release just yet and is still quite volatile, though slowly stabilizing - at least wrt. structural buildroot changes. > It's essential, that tutorials on wifi node setups are usable over time, > that provided settings are applicable for a reasonable and foreseeable > amount of time and that users are able to install additional packages > (even kernel modules such as batman-adv) weeks / months after a release. Understandable. > From my impression this cannot be done using nightly builds based trunk > snapshots. :-( Correct, snapshots are very volatile and quickly stale (especially wrt. kernel modules) therefor I wouldn't recommend to use them as-is. Whats always an option is mirroring the particular version you're using and the use that instead, this way you at least have access to suitable kmods in the foreseeable future. In such a setup it is also enough to just mirror the packages within the targets/ directory and continue using updated .ipk files from the packages directory. > When lede was founded earlier this year, the goals were [1]: > > "- Building a great embedded Linux distribution with focus on stability > and functionality. Still the goal :) > - Having regular, predictable release cycles coupled with community > provided device testing feedback. Device testing topic fell down to the end of the priority list but its still a goal the project pursues I'd say. > - Establishing transparent decision processes with broad community > participation and public meetings." The transparent decision process is in place. If you see no public decisions on a particular topic it means that there has been none, neither public nor nonpublic. Public meetings still happen, with the last one being a while back. With the few meetings we had so far, it quickly turned out that finding a common date and squeezing every topic into a given time frame is hard, so it was concluded that we should discuss topics on mailing lists instead and only talk about unsolved issues in realtime meetings. > Is this still up to date or has lede's focus changed so far? Those goals still stand and when they're not met then only due to a lack of time or commitment, not due to changed directions in the project. > Please don't get me wrong - I really do appreciate your work and your > doing a very got in job in developing an embedded Linux distribution - > but this not the point. > I'm in the need for a predictable release cycle and a transparent > decision process on upcoming release dates. Since there has been no conclusive agreement (or even a discussion) on specific dates yet, there's not much public chatter to find around this particular topic but let me share my personal plans for the upcoming weeks: Starting with november I'll have some spare time at my hands which I'd like to invest into a second buildbot setup dedicated to building release branches and once this setup is in place, use it to build a release test in order to formalize and nail down the release process mechanics so that we can easily repeat building artifacts in the future. Once the infrastructure for that is in place (right now I assume it'll be around the 2nd week of november) I'd like to kick off a discussion in order to reach an agreement on the release date and goals. I also quickly summarized those plans on our last meeting in june, please refer to http://meetings.lede-project.org/lede-adm/2016/lede-adm.2016-07-20-17.28.log.html#l-177 > If lede's mission has changed so far, please let me know - if not, > please let me know how to get information on upcoming release plans. I hope the statements above clarified things a bit, will follow up with some more detailed plans on the LEDE-ADM list soon. Regards, Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] apm821xx: fix USB LED trigger for WNDR4700
I forgot to mention the builtin sdcard reader in the original post. On Saturday, October 22, 2016 6:10:52 PM CEST Christian Lamparter wrote: > Hello, > > On Saturday, October 22, 2016 11:22:35 AM CEST Rafał Miłecki wrote: > > From: Rafał Miłecki > > > > The old usbdev trigger never supported assigning more than 1 USB port. > > This code we got was never working as expected. Switch to usbport to > > have LED working with both ports. > > > > Signed-off-by: Rafał Miłecki > > I was testing this on the wndr4700. > > # cat /etc/config/system > config led 'led_usb3' > option name 'USB3' > option sysfs 'wndr4700:blue:usb' > option trigger 'usbport' > list port 'usb2-port1' > list port 'usb3-port1' Note: usb1-port1 is not used there. The usb1 "should always" be controlled by the dwc2-usb host and not included in this list. This is because the sd-card reader (the wndr4700 has one that's user accessible on the right hand side) is wired directly to it. Regards, Christian [...] > # lsusb -t > /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M > |__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M > |__ Port 1: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M (ignore the following built-in sd-card reader on the dwc2 controller) > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M > |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M > > > cat /sys/kernel/debug/usb/devices > > T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=5000 MxCh= 2 > B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 > D: Ver= 3.00 Cls=09(hub ) Sub=00 Prot=03 MxPS= 9 #Cfgs= 1 > P: Vendor=1d6b ProdID=0003 Rev= 4.04 > S: Manufacturer=Linux 4.4.26 xhci-hcd > S: Product=xHCI Host Controller > S: SerialNumber=:45:00.0 > C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA > I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub > E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms > > T: Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0 > D: Ver= 3.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 > P: Vendor=0bb4 ProdID=2910 Rev= 1.00 > S: Manufacturer=Intenso > S: Product=Slim Line > S: SerialNumber=0710562A29A29647 > C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=504mA > I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage > E: Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms > E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms > > T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 2 > B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 > D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 > P: Vendor=1d6b ProdID=0002 Rev= 4.04 > S: Manufacturer=Linux 4.4.26 xhci-hcd > S: Product=xHCI Host Controller > S: SerialNumber=:45:00.0 > C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA > I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub > E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms > > T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 > D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 > P: Vendor=090c ProdID=1000 Rev=11.00 > S: Manufacturer=SMI Corporation > S: Product=USB DISK > S: SerialNumber=AA0401297610 > C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA > I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage > E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms > E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=31875us (the dwc2 controller) > T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 1 > B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 > D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 > P: Vendor=1d6b ProdID=0002 Rev= 4.04 > S: Manufacturer=Linux 4.4.26 dwc2_hsotg > S: Product=DWC OTG Controller > S: SerialNumber=4bff8.usbotg > C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA > I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub > E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms (This is the SD-Card reader - it's a GL827L SD/MMC/MS Flash Card Reader and uses usb-storage class driver) > T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 > D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 > P: Vendor=05e3 ProdID=0723 Rev=94.54 > S: Manufacturer=Generic > S: Product=USB Storage > C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA > I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage > E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms > E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Actual community change and additional developers compared to OpenWrt
Hi Jo, >>> Part of the problem, I >>> think, is the lack of clear and consistent (and visible) governance and >>> communication makes the project unappealing for companies to be >>> interested in paying developers to work on either. It's not enough to >>> have code and commits, there needs to be a communications strategy as >>> well, or the projects will die. >> I think it's mostly because of the usual reasons in opensource projects. >> Core developers are overloaded, and in what little time they have they >> prefer to code (understandable, but same self-defying issues in OpenWRT). > IMHO this summarizes the current situation quite nicely and I'd say I > agree with it completely. > > Note that we're trying to slowly dig ourselves out of the hole we made > ourselves over the years but it requires time and dedication. I for > example would love to lean back a bit and start caring more about > community matters and communication but before I can do that, we need to > find some more people compensate the missing developer time. I think some communication from the core team is essential to the overall health of the project. It is difficult to get a sense of direction and priorities from the discussions here or at Github. When the core team is silent on what's going on, people get frustrated because they don't see where the project is going. Even a brief post from the core team to this mailing list, outlining short and/or long term objectives and any other relevant matters, would go a long way towards creating the sense of direction. The communication does not have to perfect, but it has to be regular. IMHO, a half an hour (or less) of someone's time to outline what's going on, on a monthly basis, would be much appreciated by most of us. It would demonstrate that the core team is engaged and cares about the community. -- Val ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Actual community change and additional developers compared to OpenWrt
On 24.10.2016 19:26, Val Kulkov wrote: > Hi Jo, > Part of the problem, I think, is the lack of clear and consistent (and visible) governance and communication makes the project unappealing for companies to be interested in paying developers to work on either. It's not enough to have code and commits, there needs to be a communications strategy as well, or the projects will die. > >>> I think it's mostly because of the usual reasons in opensource projects. >>> Core developers are overloaded, and in what little time they have they >>> prefer to code (understandable, but same self-defying issues in OpenWRT). > >> IMHO this summarizes the current situation quite nicely and I'd say I >> agree with it completely. >> >> Note that we're trying to slowly dig ourselves out of the hole we made >> ourselves over the years but it requires time and dedication. I for >> example would love to lean back a bit and start caring more about >> community matters and communication but before I can do that, we need to >> find some more people compensate the missing developer time. > > I think some communication from the core team is essential to the > overall health of the project. It is difficult to get a sense of > direction and priorities from the discussions here or at Github. When > the core team is silent on what's going on, people get frustrated > because they don't see where the project is going. > > Even a brief post from the core team to this mailing list, outlining > short and/or long term objectives and any other relevant matters, > would go a long way towards creating the sense of direction. The > communication does not have to perfect, but it has to be regular. > IMHO, a half an hour (or less) of someone's time to outline what's > going on, on a monthly basis, would be much appreciated by most of us. > It would demonstrate that the core team is engaged and cares about the > community. +1 a simple grep/posting of the #agreed/#action lines from your meeting logs could be a good start. ..ede ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH v5] base-files: Ensure reset only works if an overlay exists
Currently the reset script will try to run jffs2reset on boards that are running a rw rootfs, such as ext4. This will cause jffs2reset to fail and the board to never reboot while the LED blinks until a manual reboot. This commit does two different things: 1. Disables reset on boards that do not have an overlay mount 2. Disables the Blinking LED after 5 seconds if the board does not support reset Signed-off-by: Chris Blake --- package/base-files/files/etc/rc.button/reset | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/package/base-files/files/etc/rc.button/reset b/package/base-files/files/etc/rc.button/reset index c6dc7cf..4265767 100755 --- a/package/base-files/files/etc/rc.button/reset +++ b/package/base-files/files/etc/rc.button/reset @@ -2,8 +2,12 @@ . /lib/functions.sh +OVERLAY="$( grep ' /overlay ' /proc/mounts )" + case "$ACTION" in pressed) + [ -z "$OVERLAY" ] && return 0 + return 5 ;; timeout) @@ -16,7 +20,7 @@ released) echo "REBOOT" > /dev/console sync reboot - elif [ "$SEEN" -gt 5 ] + elif [ "$SEEN" -gt 5 -a -n "$OVERLAY" ] then echo "FACTORY RESET" > /dev/console jffs2reset -y && reboot & -- 2.7.4 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 1/3 v3] ar71xx: Move MR12 & MR16 from legacy to generic
This moves the Meraki MR12 and Meraki MR16 to the new generic target. Tested and verified working on both devices. Note that kernel/rootfs images are still generated. This is because they are used for the inital flashing process due to the fun pace at which UBoot erases/writes to SPI. Signed-off-by: Chris Blake --- target/linux/ar71xx/image/generic.mk| 26 ++ target/linux/ar71xx/image/legacy-devices.mk | 12 target/linux/ar71xx/image/legacy.mk | 4 3 files changed, 26 insertions(+), 16 deletions(-) diff --git a/target/linux/ar71xx/image/generic.mk b/target/linux/ar71xx/image/generic.mk index 192f1a7..ee910af 100644 --- a/target/linux/ar71xx/image/generic.mk +++ b/target/linux/ar71xx/image/generic.mk @@ -97,6 +97,32 @@ define Device/gl-mifi endef TARGET_DEVICES += gl-mifi +define Device/mr12 + DEVICE_TITLE := Meraki MR12 + DEVICE_PACKAGES := kmod-spi-gpio + BOARDNAME = MR12 + IMAGE_SIZE = 15744k + MTDPARTS = spi0.0:256k(u-boot)ro,256k(u-boot-env)ro,13440k(rootfs),2304k(kernel),128k(art)ro,15744k@0x8(firmware) + IMAGE/kernel.bin = append-kernel + IMAGE/rootfs.bin = append-rootfs | pad-rootfs + IMAGE/sysupgrade.bin = append-rootfs | pad-rootfs | pad-to 13440k | append-kernel | check-size (IMAGE_SIZE) + IMAGES := kernel.bin rootfs.bin sysupgrade.bin +endef +TARGET_DEVICES += mr12 + +define Device/mr16 + DEVICE_TITLE := Meraki MR16 + DEVICE_PACKAGES := kmod-spi-gpio + BOARDNAME = MR16 + IMAGE_SIZE = 15744k + MTDPARTS = spi0.0:256k(u-boot)ro,256k(u-boot-env)ro,13440k(rootfs),2304k(kernel),128k(art)ro,15744k@0x8(firmware) + IMAGE/kernel.bin = append-kernel + IMAGE/rootfs.bin = append-rootfs | pad-rootfs + IMAGE/sysupgrade.bin = append-rootfs | pad-rootfs | pad-to 13440k | append-kernel | check-size (IMAGE_SIZE) + IMAGES := kernel.bin rootfs.bin sysupgrade.bin +endef +TARGET_DEVICES += mr16 + define Device/dr531 DEVICE_TITLE := Wallys DR531 DEVICE_PACKAGES := kmod-usb-core kmod-usb2 diff --git a/target/linux/ar71xx/image/legacy-devices.mk b/target/linux/ar71xx/image/legacy-devices.mk index 2af7598..8522f9e 100644 --- a/target/linux/ar71xx/image/legacy-devices.mk +++ b/target/linux/ar71xx/image/legacy-devices.mk @@ -185,18 +185,6 @@ define LegacyDevice/HORNETUBx2 endef LEGACY_DEVICES += HORNETUBx2 -define LegacyDevice/MR12 - DEVICE_TITLE := Meraki MR12 - DEVICE_PACKAGES := kmod-spi-gpio -endef -LEGACY_DEVICES += MR12 - -define LegacyDevice/MR16 - DEVICE_TITLE := Meraki MR16 - DEVICE_PACKAGES := kmod-spi-gpio -endef -LEGACY_DEVICES += MR16 - define LegacyDevice/PB92 DEVICE_TITLE := Atheros PB92 reference board DEVICE_PACKAGES := kmod-usb-core kmod-usb2 diff --git a/target/linux/ar71xx/image/legacy.mk b/target/linux/ar71xx/image/legacy.mk index 14de229..d4f9594 100644 --- a/target/linux/ar71xx/image/legacy.mk +++ b/target/linux/ar71xx/image/legacy.mk @@ -271,8 +271,6 @@ ew-dorin_mtdlayout_16M=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env),16000k(fir f9k1115v2_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env),14464k(rootfs),1408k(kernel),64k(nvram)ro,64k(envram)ro,64k(art)ro,15872k@0x5(firmware) dlrtdev_mtdlayout=mtdparts=spi0.0:256k(uboot)ro,64k(config)ro,6208k(firmware),64k(caldata)ro,640k(certs),960k(unknown)ro,64k@0x7f(caldata_copy) dlrtdev_mtdlayout_fat=mtdparts=spi0.0:256k(uboot)ro,64k(config)ro,7168k(firmware),640k(certs),64k(caldata)ro,64k@0x66(caldata_orig),6208k@0x5(firmware_orig) -mr12_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,256k(u-boot-env)ro,13440k(rootfs),2304k(kernel),128k(art)ro,15744k@0x8(firmware) -mr16_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,256k(u-boot-env)ro,13440k(rootfs),2304k(kernel),128k(art)ro,15744k@0x8(firmware) pb92_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,2752k(rootfs),896k(kernel),64k(nvram),64k(art)ro,3648k@0x5(firmware) planex_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,7744k(firmware),128k(art)ro ubntxm_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,7552k(firmware),256k(cfg)ro,64k(EEPROM)ro @@ -949,8 +947,6 @@ $(eval $(call SingleProfile,AthLzma,64k,EWDORINAP,ew-dorin,EW-DORIN,ttyATH0,1152 $(eval $(call SingleProfile,AthLzma,64k,EWDORINRT,ew-dorin-router,EW-DORIN-ROUTER,ttyATH0,115200,$$(ew-dorin_mtdlayout_4M),KRuImage,65536)) $(eval $(call SingleProfile,AthLzma,64k,EWDORIN16M,ew-dorin-16M,EW-DORIN,ttyATH0,115200,$$(ew-dorin_mtdlayout_16M),KRuImage,65536)) $(eval $(call SingleProfile,AthLzma,64k,HORNETUBx2,hornet-ub-x2,HORNET-UB,ttyATH0,115200,$$(alfa_mtdlayout_16M),KRuImage,65536)) -$(eval $(call SingleProfile,AthLzma,64k,MR12,mr12,MR12,ttyS0,115200,$$(mr12_mtdlayout),RKuImage)) -$(eval $(call SingleProfile,AthLzma,64k,MR16,mr16,MR16,ttyS0,115200,$$(mr16_mtdlayout),RKuImage)) $(eval $(call SingleProfile,AthLzma,64k,PB92,pb92,PB92,ttyS0,115200,$$(pb92_mtdlayout),KRuImage)) $(eval $(call SingleProfile,AthLzma,64k,TUBE2H16M,tube2h-16M,TUBE2H,ttyATH0,1152
[LEDE-DEV] [PATCH 2/3 v3] ar71xx: add mac partition to the MR12/MR16
On the stock Meraki Firmare for the MR12/MR16, a chunk of SPI space
after u-boot-env is used to store the boards Mac address. Sadly as this
was removed on any device already on OpenWRT/LEDE, moving forward a new,
64k partition named "mac" will be used to store the mac address for the
device (which is the minimum size). This allows users to properly set
the correct MAC, without editing the ART partition (which holds the same
MAC for all devices).
The reason the space is taken from kernel instead of rootfs is currently
kernels are only 1.3MB, so that way we can leave the current rootfs
space alone for users who fully utilize the available storage space.
Once this partition is added to a device, you can set your MAC doing the
following:
mtd erase mac
echo -n -e '\x00\x18\x0a\x33\x44\x55' > /dev/mtd5
sync && reboot
Where 00:18:0a:33:44:55 is your MAC address.
This was tested, and confirmed working on both the MR12 and MR16.
Signed-off-by: Chris Blake
---
.../linux/ar71xx/files/arch/mips/ath79/mach-mr12.c | 15 +++
.../linux/ar71xx/files/arch/mips/ath79/mach-mr16.c | 22 +++---
target/linux/ar71xx/image/generic.mk | 8
3 files changed, 22 insertions(+), 23 deletions(-)
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr12.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr12.c
index 12c9a1c..5a337e5 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr12.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr12.c
@@ -42,8 +42,7 @@
#define MR12_WAN_PHYMASKBIT(4)
-#define MR12_WMAC0_MAC_OFFSET 0x120c
-#define MR12_CALDATA0_OFFSET0x1000
+#define MR12_CALDATA0_OFFSET0x21000
static struct gpio_led MR12_leds_gpio[] __initdata = {
{
@@ -90,8 +89,9 @@ static struct gpio_keys_button MR12_gpio_keys[] __initdata = {
static void __init MR12_setup(void)
{
- u8 *mac = (u8 *) KSEG1ADDR(0xbfff);
-
+ u8 *mac = (u8 *) KSEG1ADDR(0xbffd);
+ u8 wlan_mac[ETH_ALEN];
+
ath79_register_mdio(0,0x0);
ath79_init_mac(ath79_eth0_data.mac_addr, mac, 0);
@@ -107,9 +107,8 @@ static void __init MR12_setup(void)
ARRAY_SIZE(MR12_gpio_keys),
MR12_gpio_keys);
- ap91_pci_init(mac + MR12_CALDATA0_OFFSET,
- mac + MR12_WMAC0_MAC_OFFSET);
-
+ ath79_init_mac(wlan_mac, mac, 1);
+ ap91_pci_init(mac + MR12_CALDATA0_OFFSET, wlan_mac);
}
-MIPS_MACHINE(ATH79_MACH_MR12, "MR12", "Meraki MR12", MR12_setup);
\ No newline at end of file
+MIPS_MACHINE(ATH79_MACH_MR12, "MR12", "Meraki MR12", MR12_setup);
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr16.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr16.c
index 9f08e3d..9da21ea 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr16.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr16.c
@@ -42,10 +42,8 @@
#define MR16_WAN_PHYMASKBIT(0)
-#define MR16_WMAC0_MAC_OFFSET 0x120c
-#define MR16_WMAC1_MAC_OFFSET 0x520c
-#define MR16_CALDATA0_OFFSET 0x1000
-#define MR16_CALDATA1_OFFSET 0x5000
+#define MR16_CALDATA0_OFFSET 0x21000
+#define MR16_CALDATA1_OFFSET 0x25000
static struct gpio_led MR16_leds_gpio[] __initdata = {
{
@@ -92,8 +90,10 @@ static struct gpio_keys_button MR16_gpio_keys[] __initdata =
{
static void __init MR16_setup(void)
{
- u8 *mac = (u8 *) KSEG1ADDR(0xbfff);
-
+ u8 *mac = (u8 *) KSEG1ADDR(0xbffd);
+ u8 wlan0_mac[ETH_ALEN];
+ u8 wlan1_mac[ETH_ALEN];
+
ath79_register_mdio(0,0x0);
ath79_init_mac(ath79_eth0_data.mac_addr, mac, 0);
@@ -109,10 +109,10 @@ static void __init MR16_setup(void)
ARRAY_SIZE(MR16_gpio_keys),
MR16_gpio_keys);
- ap94_pci_init(mac + MR16_CALDATA0_OFFSET,
- mac + MR16_WMAC0_MAC_OFFSET,
- mac + MR16_CALDATA1_OFFSET,
- mac + MR16_WMAC1_MAC_OFFSET);
+ ath79_init_mac(wlan0_mac, mac, 1);
+ ath79_init_mac(wlan1_mac, mac, 2);
+ ap94_pci_init(mac + MR16_CALDATA0_OFFSET, wlan0_mac,
+ mac + MR16_CALDATA1_OFFSET, wlan1_mac);
}
-MIPS_MACHINE(ATH79_MACH_MR16, "MR16", "Meraki MR16", MR16_setup);
\ No newline at end of file
+MIPS_MACHINE(ATH79_MACH_MR16, "MR16", "Meraki MR16", MR16_setup);
diff --git a/target/linux/ar71xx/image/generic.mk
b/target/linux/ar71xx/image/generic.mk
index ee910af..cda2015 100644
--- a/target/linux/ar71xx/image/generic.mk
+++ b/target/linux/ar71xx/image/generic.mk
@@ -101,8 +101,8 @@ define Device/mr12
DEVICE_TITLE := Meraki MR12
DEVICE_PACKAGES := kmod-spi-gpio
BOARDNAME = MR12
- IMAGE_SIZE = 15744k
- MTDPARTS =
spi0.0:256k(u-boot)ro,256k(u-boot-env)ro,13440k(rootfs),2304k(kernel),128k(art)ro,15744k@0x8(
[LEDE-DEV] [PATCH 3/3 v3] ar71xx: Remove switch config for the MR12/MR16
These boards do not have a switch, so they should have never been added to this file in the first place. Signed-off-by: Chris Blake --- .../ar71xx/base-files/etc/uci-defaults/03_network-switchX-migration | 2 -- 1 file changed, 2 deletions(-) diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/03_network-switchX-migration b/target/linux/ar71xx/base-files/etc/uci-defaults/03_network-switchX-migration index ee8f63b..c6b91b7 100644 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/03_network-switchX-migration +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/03_network-switchX-migration @@ -61,8 +61,6 @@ dir-615-c1|\ dir-615-e1|\ dir-615-e4|\ ja76pf|\ -mr-12|\ -mr-16|\ rb-750|\ rb-751|\ tew-632brp|\ -- 2.7.4 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] brcm47xx: add support for per-device rootfs
From: Rafał Miłecki Signed-off-by: Rafał Miłecki --- target/linux/brcm47xx/image/Makefile | 99 ++-- 1 file changed, 95 insertions(+), 4 deletions(-) diff --git a/target/linux/brcm47xx/image/Makefile b/target/linux/brcm47xx/image/Makefile index 8cc336a..5d8e6ff 100644 --- a/target/linux/brcm47xx/image/Makefile +++ b/target/linux/brcm47xx/image/Makefile @@ -142,16 +142,19 @@ define Device/Default endef define Device/standard + DEVICE_TITLE := Image with LZMA loader and LZMA compressed kernel endef define Device/standard-noloader-gz - KERNEL_NAME = vmlinux.gz - IMAGE/trx := trx-without-loader + DEVICE_TITLE := Image with gzipped kernel + KERNEL_NAME = vmlinux.gz + IMAGE/trx := trx-without-loader endef define Device/standard-noloader-nodictionarylzma - KERNEL_NAME = vmlinux-nodictionary.lzma - IMAGE/trx := trx-without-loader + DEVICE_TITLE := Image with LZMA compressed kernel matching CFE decompressor + KERNEL_NAME = vmlinux-nodictionary.lzma + IMAGE/trx := trx-without-loader endef define Device/asus @@ -181,6 +184,7 @@ endef ifeq ($(SUBTARGET),generic) # BCM4705 with tg3 define Device/linksys-wrt300n-v1.1 + DEVICE_TITLE := Linksys WRT300N v1.1 $(Device/linksys) DEVICE_ID := EWC2 VERSION := 1.51.2 @@ -188,6 +192,7 @@ endef TARGET_DEVICES += linksys-wrt300n-v1.1 define Device/linksys-wrt310n-v1 + DEVICE_TITLE := Linksys WRT310N v1 $(Device/linksys) DEVICE_ID := 310N VERSION := 1.0.10 @@ -195,6 +200,7 @@ endef TARGET_DEVICES += linksys-wrt310n-v1 define Device/linksys-wrt350n-v1 + DEVICE_TITLE := Linksys WRT350N v1 $(Device/linksys) DEVICE_ID := EWCG VERSION := 1.04.1 @@ -202,6 +208,7 @@ endef TARGET_DEVICES += linksys-wrt350n-v1 define Device/linksys-wrt610n-v1 + DEVICE_TITLE := Linksys WRT610N v1 $(Device/linksys) DEVICE_ID := 610N VERSION := 1.0.1 @@ -210,6 +217,7 @@ TARGET_DEVICES += linksys-wrt610n-v1 # BCMA SoC with SSB WiFi define Device/linksys-wrt610n-v2 + DEVICE_TITLE := Linksys WRT610N v2 $(Device/linksys) DEVICE_ID := 610N VERSION := 2.0.0 @@ -217,6 +225,7 @@ endef TARGET_DEVICES += linksys-wrt610n-v2 define Device/linksys-e3000-v1 + DEVICE_TITLE := Linksys E3000 v1 $(Device/linksys) DEVICE_ID := 61XN VERSION := 1.0.3 @@ -233,60 +242,70 @@ endif ifeq ($(SUBTARGET),legacy) define Device/asus-wl-300g + DEVICE_TITLE := Asus WL-300g $(Device/asus) PRODUCTID := "WL300g " endef TARGET_DEVICES += asus-wl-300g define Device/asus-wl-320gp + DEVICE_TITLE := Asus WL-320gP $(Device/asus) PRODUCTID := "WL320gP " endef TARGET_DEVICES += asus-wl-320gp define Device/asus-wl-330ge + DEVICE_TITLE := Asus WL-330gE $(Device/asus) PRODUCTID := "WL-330gE" endef TARGET_DEVICES += asus-wl-330ge define Device/asus-wl-500gp-v1 + DEVICE_TITLE := Asus WL-500gP v1 $(Device/asus) PRODUCTID := "WL500gp " endef TARGET_DEVICES += asus-wl-500gp-v1 define Device/asus-wl-500gp-v2 + DEVICE_TITLE := Asus WL-500gP v2 $(Device/asus) PRODUCTID := "WL500gpv2 " endef TARGET_DEVICES += asus-wl-500gp-v2 define Device/asus-wl-500w + DEVICE_TITLE := Asus WL-500W $(Device/asus) PRODUCTID := "WL500W " endef TARGET_DEVICES += asus-wl-500w define Device/asus-wl-520gu + DEVICE_TITLE := Asus WL-520gU $(Device/asus) PRODUCTID := "WL520gu " endef TARGET_DEVICES += asus-wl-520gu define Device/asus-wl-550ge + DEVICE_TITLE := Asus WL-550gE $(Device/asus) PRODUCTID := "WL550gE " endef TARGET_DEVICES += asus-wl-550ge define Device/asus-wl-hdd25 + DEVICE_TITLE := Asus WL-HDD25 $(Device/asus) PRODUCTID := "WLHDD " endef TARGET_DEVICES += asus-wl-hdd25 define Device/dlink-dwl-3150 + DEVICE_TITLE := D-Link DWL-3150 IMAGES := bin IMAGE/bin := trx-with-loader | tailed-bin BIN_TAIL := BCM-5352-2050-000-01 @@ -294,12 +313,14 @@ endef TARGET_DEVICES += dlink-dwl-3150 define Device/edimax-ps1208-mfg + DEVICE_TITLE := Edimax PS-1208MFg IMAGES := bin IMAGE/bin := trx-with-loader | edimax-bin endef TARGET_DEVICES += edimax-ps1208-mfg define Device/huawei-e970 + DEVICE_TITLE := Huawei E970 KERNEL_NAME = vmlinux.gz IMAGES := bin IMAGE/bin := trx-without-loader | huawei-bin @@ -307,6 +328,7 @@ endef TARGET_DEVICES += huawei-e970 define Device/linksys-wrt54g3g + DEVICE_TITLE := Linksys WRT54G3G $(Device/linksys) DEVICE_ID := W54F VERSION := 2.20.1 @@ -314,6 +336,7 @@ endef TARGET_DEVICES += linksys-wrt54g3g define Device/linksys-wrt54g3g-em + DEVICE_TITLE := Linksys WRT54G3G-EM $(Device/linksys) DEVICE_ID := W3GN VERSION := 2.20.1 @@ -321,6 +344,7 @@ endef TARGET_DEVICES += linksys-wrt54g3g-em define Device/linksys-wrt54g3gv2-vf + DEVICE_TITLE := Linksys WRT54G3GV2-VF FILESYSTEMS := $(FS_128K) IMAGES := noheader.bin bin IMAGE/noheader.bin := linksys-pattern-partition | trx-v2-wi
[LEDE-DEV] Apologies; reimplementing delay
Hi all, Sorry for my last couple of messages, I'm re-implementing my delay mechanism so that I don't mess things up again; I do want to help both OpenWrt and LEDE, not create another bad situation; maybe in a week or few the things I'm dealing with will be sorted enough to remove that. At this point I think the best thing I can do is refrain from being too vocal (although I *am* concerned that from a community involvement in decision-making perspective, that nothing has really changed from before the split; aside from those who were part of the splitting group). Regards, Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH RFC] kernel: allow selecting kmod-ssb on TARGET_brcm47xx_mips74k
From: Rafał Miłecki For mips74k subtarget we don't have ssb compiled into to the kernel, so allow using it as package. This can be useful for MIPS74k SoCs with PCIe cards using ssb (like BCM4322). Signed-off-by: Rafał Miłecki --- I'm thinking about switching Linksys WRT610N v2 and Linksys E3000 v1 to the mips74k subtarget. These boards are quite specific because: 1) They use bcma-based BCM4718A1 SoC with wireless core 2) They use ssb-based BCM4322 PCIe wireless card Switching to mips74k subtarget would give them some performance gain due to optimized build. Unfortunately it requires some work on ssb/bcma/b43. Subtarget mips74k has only bcma support built-in, so ssb support should be added as package (kmod-ssb) - this is easy. A bigger problem is b43. Right now we have only 1 b43 package that gets adjusted depending on the brcm47xx subtarget. Devices using mips74k subtarget get b43 with bcma support only. However these 2 Linksys routers should have b43 with both: ssb and bcma. The only way I see to handle this is having 3 b43 packages: 1) b43-ssb 2) b43-bcma 3) b43-ssb-bcma Does it sound like a good idea? Is it acceptable? --- package/kernel/linux/modules/other.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/kernel/linux/modules/other.mk b/package/kernel/linux/modules/other.mk index 38b98f3..abf9512 100644 --- a/package/kernel/linux/modules/other.mk +++ b/package/kernel/linux/modules/other.mk @@ -432,7 +432,7 @@ $(eval $(call KernelPackage,softdog)) define KernelPackage/ssb SUBMENU:=$(OTHER_MENU) TITLE:=Silicon Sonics Backplane glue code - DEPENDS:=@PCI_SUPPORT @!TARGET_brcm47xx @!TARGET_brcm63xx + DEPENDS:=@PCI_SUPPORT @!TARGET_brcm47xx_legacy @!TARGET_brcm47xx_generic @!TARGET_brcm63xx KCONFIG:=\ CONFIG_SSB \ CONFIG_SSB_B43_PCI_BRIDGE=y \ -- 2.9.3 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC] brcm47xx: bump kernel to 4.4
On 24 October 2016 at 18:43, wrote: >> I started working on this today, I reproduce see the issue during a >> lot of tests until it magically disappeared. Then LEDE started booting >> on my unit with kernel 4.4. > > Oh - that rings a bell. > May I point you to a discussion we had earlier this year? > http://lists.infradead.org/pipermail/lede-dev/2016-May/000980.html > > I had this issue on all my WRT54GLs: > trunk images stopped booting at "Starting program at 0x80001000". > However, if I compiled the images myself (with the exact same configuration > as the buildbot), the images would boot fine. > I later checked again: buildbot's images did not boot. > (It was kernel 4.1 back then, but it's the exact same behaviour as you > describe > in the commit message) > Additionally builtbot's images worked out-of-the-box on an ASUS WL500gP V2. It seems I'm experiencing the same crazy problem. Local builds work for me (as explained in commit message), but image from buildbot (https://downloads.lede-project.org/snapshots/targets/brcm47xx/legacy/) doesn't boot. This is some totally crazy thing :| -- Rafał ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC] brcm47xx: bump kernel to 4.4
> It seems I'm experiencing the same crazy problem. Local builds work > for me (as explained in commit message), but image from buildbot > doesn't boot. This is some totally crazy thing :| I opt for staying at 4.4 and not reverting, since the issue already occured on kernel 4.1 for the WRT54GL (and probably other devices as well?). So it's _not_ a 4.1 -> 4.4 issue! The last kernel, that booted fine on my devices (with buildbot images) was OpenWRT 15.05.1 - 3.18.23 As you've experienced yourself: local images also work fine. With 4.1 and 4.4. Best regards, P. Wassi ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] [PATCH] fstools: added f2fs to block-mount, really correct indentation
Hi,
after some recent changes in the fstools repo this patch applies but
causes a compile error. could you please rebase/test/send the patch
there were also a lot of whitespace errors. please use tabs to indent
your c code
John
On 21/10/2016 14:54, Alberto Bursi wrote:
> added the code to recognize and operate the filesystem checker of f2fs
>
> added f2fs to the filesystem whitelist of block so it can mount it on
> /overlay at boot.
>
> Signed-off-by: Alberto Bursi
> ---
> block.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/block.c b/block.c
> index 9de8343..073ad05 100644
> --- a/block.c
> +++ b/block.c
> @@ -687,6 +687,7 @@ static void check_filesystem(struct probe_info *pr)
> pid_t pid;
> struct stat statbuf;
> const char *e2fsck = "/usr/sbin/e2fsck";
> + const char *f2fsck = "/usr/sbin/fsck.f2fs";
> const char *dosfsck = "/usr/sbin/dosfsck";
> const char *ckfs;
>
> @@ -696,6 +697,8 @@ static void check_filesystem(struct probe_info *pr)
>
> if (!strncmp(pr->type, "vfat", 4)) {
> ckfs = dosfsck;
> + } else if (!strncmp(pr->id->name, "f2fs", 4)) {
> + ckfs = f2fsck;
> } else if (!strncmp(pr->type, "ext", 3)) {
> ckfs = e2fsck;
> } else {
> @@ -710,8 +713,12 @@ static void check_filesystem(struct probe_info *pr)
>
> pid = fork();
> if (!pid) {
> - execl(ckfs, ckfs, "-p", pr->dev, NULL);
> - exit(-1);
> + if(!strncmp(pr->id->name, "f2fs", 4)) {
> + execl(ckfs, ckfs, "-f", pr->dev, NULL);
> + exit(-1);
> + } else
> + execl(ckfs, ckfs, "-p", pr->dev, NULL);
> + exit(-1);
> } else if (pid > 0) {
> int status;
>
> @@ -1154,8 +1161,9 @@ static int mount_extroot(char *cfg)
> }
> if (pr) {
> if (strncmp(pr->type, "ext", 3) &&
> + strncmp(pr->id->name, "f2fs", 4) &&
> strncmp(pr->type, "ubifs", 5)) {
> - ULOG_ERR("extroot: unsupported filesystem %s, try
> ext4\n", pr->type);
> + ULOG_ERR("extroot: unsupported filesystem %s, try ext4
> or f2fs\n", pr->type);
> return -1;
> }
>
>
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH v4 4/5] package/basefiles: add mkfs.ext4 and losetup binaries to ramfs list
mkfs.ext4 und losetup are needed for sysupgrade support on mmc devices
with automatic rootfs split (loopback device usage).
Signed-off-by: André Valentin
---
package/base-files/files/lib/upgrade/common.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/package/base-files/files/lib/upgrade/common.sh
b/package/base-files/files/lib/upgrade/common.sh
index bed9c18..4d0e6d5 100644
--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -69,6 +69,8 @@ run_ramfs() { # [...]
install_bin /usr/sbin/ubirmvol
install_bin /usr/sbin/ubimkvol
install_bin /usr/sbin/partx
+ install_bin /usr/sbin/losetup
+ install_bin /usr/sbin/mkfs.ext4
for file in $RAMFS_COPY_BIN; do
install_bin ${file//:/ }
done
--
2.1.4
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH v4 2/5] linux/mtd: add id for mx25u3235f needed by ZyXEL NBG6817
Signed-off-by: André Valentin
---
.../patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch | 10 ++
1 file changed, 10 insertions(+)
create mode 100644
target/linux/generic/patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch
diff --git
a/target/linux/generic/patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch
b/target/linux/generic/patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch
new file mode 100644
index 000..45533e1
--- /dev/null
+++ b/target/linux/generic/patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch
@@ -0,0 +1,10 @@
+--- a/drivers/mtd/spi-nor/spi-nor.c2016-10-09 00:34:19.206155838 +0200
b/drivers/mtd/spi-nor/spi-nor.c2016-10-09 00:37:11.048495602 +0200
+@@ -721,6 +721,7 @@ static const struct flash_info spi_nor_i
+ { "mx25l3205d", INFO(0xc22016, 0, 64 * 1024, 64, SECT_4K) },
+ { "mx25l3255e", INFO(0xc29e16, 0, 64 * 1024, 64, SECT_4K) },
+ { "mx25l6405d", INFO(0xc22017, 0, 64 * 1024, 128, SECT_4K) },
++ { "mx25u3235f", INFO(0xc22536, 0, 64 * 1024, 64, 0) },
+ { "mx25u6435f", INFO(0xc22537, 0, 64 * 1024, 128, SECT_4K) },
+ { "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256, 0) },
+ { "mx25l12855e", INFO(0xc22618, 0, 64 * 1024, 256, 0) },
--
2.1.4
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH v4 0/5] ipq806x: add support for ZyXEL NBG6817
Support for NBG6817 comes with several challenges: -enable mmc support on platform -use fstools rootfs split on block devices ( creates a loop dev with offset ) -extend sysupgrade support to format the loop fs and save config Changes to v3: -build sysupgrade images padded to overlay block size -remove offset calculation from sysupgrade script -remove old code older Changes: -update GPIO definitions Comments are appreciated. André Valentin (5): ipq806x/nbg6817: add support for ZyXEL NBG6817 linux/mtd: add id for mx25u3235f needed by ZyXEL NBG6817 ipq806x/nbg6817: add sysupgrade support package/basefiles: add mkfs.ext4 and losetup binaries to ramfs list package/uboot-envtools: Add support for ZyXEL NBG6817 package/base-files/files/lib/upgrade/common.sh | 2 + package/boot/uboot-envtools/files/ipq | 3 + .../477-mtd-add-spi-nor-add-mx25u3235f.patch | 10 + .../linux/ipq806x/base-files/etc/board.d/01_leds | 5 + .../ipq806x/base-files/etc/board.d/02_network | 7 + .../etc/hotplug.d/firmware/11-ath10k-caldata | 6 + target/linux/ipq806x/base-files/lib/ipq806x.sh | 3 + .../ipq806x/base-files/lib/upgrade/platform.sh | 12 + .../linux/ipq806x/base-files/lib/upgrade/zyxel.sh | 87 ++ target/linux/ipq806x/config-4.4| 18 +- .../arch/arm/boot/dts/qcom-ipq8065-nbg6817.dts | 341 + target/linux/ipq806x/image/Makefile| 25 +- .../linux/ipq806x/patches-4.4/800-devicetree.patch | 3 +- 13 files changed, 514 insertions(+), 8 deletions(-) create mode 100644 target/linux/generic/patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch create mode 100644 target/linux/ipq806x/base-files/lib/upgrade/zyxel.sh create mode 100644 target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8065-nbg6817.dts -- 2.1.4 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH v4 3/5] ipq806x/nbg6817: add sysupgrade support
Add new way of flashing to mmc devices based on rootfs split with loop devices.
Signed-off-by: André Valentin
---
.../ipq806x/base-files/lib/upgrade/platform.sh | 12 +++
.../linux/ipq806x/base-files/lib/upgrade/zyxel.sh | 87 ++
2 files changed, 99 insertions(+)
create mode 100644 target/linux/ipq806x/base-files/lib/upgrade/zyxel.sh
diff --git a/target/linux/ipq806x/base-files/lib/upgrade/platform.sh
b/target/linux/ipq806x/base-files/lib/upgrade/platform.sh
index 8768930..53cdc87 100644
--- a/target/linux/ipq806x/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ipq806x/base-files/lib/upgrade/platform.sh
@@ -9,6 +9,7 @@ platform_check_image() {
ap148 |\
d7800 |\
ea8500 |\
+ nbg6817 |\
r7500 |\
r7500v2 |\
r7800)
@@ -34,6 +35,7 @@ platform_pre_upgrade() {
case "$board" in
ap148 |\
d7800 |\
+ nbg6817 |\
r7500 |\
r7500v2 |\
r7800)
@@ -60,6 +62,16 @@ platform_do_upgrade() {
esac
}
+platform_nand_pre_upgrade() {
+ local board=$(ipq806x_board_name)
+
+ case "$board" in
+ nbg6817)
+ zyxel_do_upgrade "$1"
+ ;;
+ esac
+}
+
blink_led() {
. /etc/diag.sh; set_state upgrade
}
diff --git a/target/linux/ipq806x/base-files/lib/upgrade/zyxel.sh
b/target/linux/ipq806x/base-files/lib/upgrade/zyxel.sh
new file mode 100644
index 000..fc48cb1
--- /dev/null
+++ b/target/linux/ipq806x/base-files/lib/upgrade/zyxel.sh
@@ -0,0 +1,87 @@
+#
+# Copyright (C) 2016 lede-project.org
+#
+
+zyxel_get_rootfs() {
+ local rootfsdev
+
+ if read cmdline < /proc/cmdline; then
+ case "$cmdline" in
+ *root=*)
+ rootfsdev="${cmdline##*root=}"
+ rootfsdev="${rootfsdev%% *}"
+ ;;
+ esac
+
+ echo "${rootfsdev}"
+ fi
+}
+
+zyxel_do_flash() {
+ local tar_file=$1
+ local board=$2
+ local kernel=$3
+ local rootfs=$4
+
+ # keep sure its unbound
+ losetup --detach-all || {
+ echo Failed to detach all loop devices. Skip this try.
+ reboot -f
+ }
+
+ echo "flashing kernel to /dev/${kernel}"
+ tar xf $tar_file sysupgrade-$board/kernel -O >/dev/$kernel
+
+ echo "flashing rootfs to ${rootfs}"
+ tar xf $tar_file sysupgrade-$board/root -O >"${rootfs}"
+
+ # a padded rootfs is needed for overlay fs creation
+ local offset=$(tar xf $tar_file sysupgrade-$board/root -O | wc -c)
+ [ $offset -lt 65536 ] && {
+ echo Wrong size for rootfs: $offset
+ sleep 10
+ reboot -f
+ }
+
+ # Mount loop for rootfs_data
+ losetup -o $offset /dev/loop0 "${rootfs}" || {
+ echo "Failed to mount looped rootfs_data."
+ sleep 10
+ reboot -f
+ }
+
+ echo "Format new rootfs_data at position ${offset}."
+ mkfs.ext4 -F -L rootfs_data /dev/loop0
+ mkdir /tmp/new_root
+ mount -t ext4 /dev/loop0 /tmp/new_root && {
+ echo "Saving config to rootfs_data at position ${offset}."
+ cp -v /tmp/sysupgrade.tgz /tmp/new_root/
+ umount /tmp/new_root
+ }
+
+ # Cleanup
+ losetup -d /dev/loop0 >/dev/null 2>&1
+ sync
+ umount -a
+ reboot -f
+}
+
+zyxel_do_upgrade() {
+ local tar_file="$1"
+ local board=$(cat /tmp/sysinfo/board_name)
+ local rootfs="$(zyxel_get_rootfs)"
+ local kernel=
+
+ [ -b "${rootfs}" ] || return 1
+ case "$board" in
+ nbg6817)
+ kernel=mmcblk0p4
+ ;;
+ *)
+ return 1
+ esac
+
+ zyxel_do_flash $tar_file $board $kernel $rootfs
+
+ return 0
+}
--
2.1.4
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH v4 5/5] package/uboot-envtools: Add support for ZyXEL NBG6817
Signed-off-by: André Valentin --- package/boot/uboot-envtools/files/ipq | 3 +++ 1 file changed, 3 insertions(+) diff --git a/package/boot/uboot-envtools/files/ipq b/package/boot/uboot-envtools/files/ipq index 8cf0ddb..369f90f 100755 --- a/package/boot/uboot-envtools/files/ipq +++ b/package/boot/uboot-envtools/files/ipq @@ -18,6 +18,9 @@ case "$board" in "ea8500") ubootenv_add_uci_config "/dev/mtd10" "0x0" "0x2" "0x2" ;; +"nbg6817") + ubootenv_add_uci_config "/dev/mtdblock9" "0x0" "0x1" "0x1" + ;; esac config_load ubootenv -- 2.1.4 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH v4 1/5] ipq806x/nbg6817: add support for ZyXEL NBG6817
CPU: 2x1.8GHz ARM, RAM: 512MiB
Storage: 4MiB serial Flash, 3.9GiB MMC
NIC: 2x1GBit/s, Switch with 5 external and 2 internal ports
WiFi: Dualband, ath10k 2.4GHz, 5GHz MU-MIMO
For installation copy xx-mmcblk0p4-kernel.bin and xx-mmcblk0p5-rootfs-full.bin
to device. Then run:
cat xx-mmcblk0p4-kernel.bin > /dev/mmc0blk0p4
cat xx-mmcblk0p5-rootfs-full.bin > /dev/mmc0blk0p5
reboot -f
For debugging serial console is easily visible on board, no soldering needed.
Signed-off-by: André Valentin
---
.../linux/ipq806x/base-files/etc/board.d/01_leds | 5 +
.../ipq806x/base-files/etc/board.d/02_network | 7 +
.../etc/hotplug.d/firmware/11-ath10k-caldata | 6 +
target/linux/ipq806x/base-files/lib/ipq806x.sh | 3 +
target/linux/ipq806x/config-4.4| 18 +-
.../arch/arm/boot/dts/qcom-ipq8065-nbg6817.dts | 341 +
target/linux/ipq806x/image/Makefile| 25 +-
.../linux/ipq806x/patches-4.4/800-devicetree.patch | 3 +-
8 files changed, 400 insertions(+), 8 deletions(-)
create mode 100644
target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8065-nbg6817.dts
diff --git a/target/linux/ipq806x/base-files/etc/board.d/01_leds
b/target/linux/ipq806x/base-files/etc/board.d/01_leds
index a7ace1f..53c2a80 100755
--- a/target/linux/ipq806x/base-files/etc/board.d/01_leds
+++ b/target/linux/ipq806x/base-files/etc/board.d/01_leds
@@ -33,6 +33,11 @@ ea8500)
ucidef_set_led_wlan "wifi" "WIFI" "ea8500:green:wifi" "phy0radio"
ucidef_set_led_default "wps" "WPS" "ea8500:green:wps" "0"
;;
+nbg6817)
+ ucidef_set_led_wlan "wlan2g" "WLAN2g" "$board:amber:wifi" "phy1radio"
+ ucidef_set_led_wlan "wlan5g" "WLAN5G" "$board:amber:wifi5" "phy0radio"
+ ucidef_set_led_netdev "wan" "WAN" "$board:white:internet" "eth1"
+ ;;
*)
;;
esac
diff --git a/target/linux/ipq806x/base-files/etc/board.d/02_network
b/target/linux/ipq806x/base-files/etc/board.d/02_network
index b720455..a461033 100755
--- a/target/linux/ipq806x/base-files/etc/board.d/02_network
+++ b/target/linux/ipq806x/base-files/etc/board.d/02_network
@@ -35,6 +35,13 @@ ea8500)
ucidef_set_interface_macaddr "lan" "$hw_mac_addr"
ucidef_set_interface_macaddr "wan" "$hw_mac_addr"
;;
+nbg6817)
+ hw_mac_addr=$(mtd_get_mac_ascii 0:APPSBLENV ethaddr)
+ ucidef_add_switch "switch0" \
+ "1:lan" "2:lan" "3:lan" "4:lan" "6@eth1" "5:wan" "0@eth0"
+ ucidef_set_interface_macaddr "lan" "$hw_mac_addr"
+ ucidef_set_interface_macaddr "wan" "$(macaddr_add $hw_mac_addr 1)"
+ ;;
*)
echo "Unsupported hardware. Network interfaces not intialized"
;;
diff --git
a/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
b/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index c7977e6..f95692a 100644
--- a/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -56,6 +56,9 @@ case "$FIRMWARE" in
hw_mac_addr=$(mtd_get_mac_ascii devinfo hw_mac_addr)
ath10kcal_extract "art" 4096 12064
;;
+ nbg6817)
+ ath10kcal_extract "0:ART" 4096 12064
+ ;;
r7500v2 |\
r7800)
ath10kcal_extract "art" 4096 12064
@@ -72,6 +75,9 @@ case "$FIRMWARE" in
hw_mac_addr=$(mtd_get_mac_ascii devinfo hw_mac_addr)
ath10kcal_extract "art" 20480 12064
;;
+ nbg6817)
+ ath10kcal_extract "0:ART" 20480 12064
+ ;;
r7500v2 |\
r7800)
ath10kcal_extract "art" 20480 12064
diff --git a/target/linux/ipq806x/base-files/lib/ipq806x.sh
b/target/linux/ipq806x/base-files/lib/ipq806x.sh
index ea45381..1bd0e2b 100644
--- a/target/linux/ipq806x/base-files/lib/ipq806x.sh
+++ b/target/linux/ipq806x/base-files/lib/ipq806x.sh
@@ -26,6 +26,9 @@ ipq806x_board_detect() {
*"DB149")
name="db149"
;;
+ *"NBG6817")
+ name="nbg6817"
+ ;;
*"R7500")
name="r7500"
;;
diff --git a/target/linux/ipq806x/config-4.4 b/target/linux/ipq806x/config-4.4
index bc04049..1972e36 100644
--- a/target/linux/ipq806x/config-4.4
+++ b/target/linux/ipq806x/config-4.4
@@ -61,6 +61,7 @@ CONFIG_ARM_THUMB=y
CONFIG_ARM_UNWIND=y
CONFIG_ARM_VIRT_EXT=y
CONFIG_AT803X_PHY=y
+CONFIG_BLK_DEV_LOOP=y
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
CONFIG_BOUNCE=y
@@ -197,11 +198,6 @@ CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_IDE=y
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
-CONFIG_HAVE_KERNEL_GZIP=y
-CONFIG_HAVE_KERNEL_LZ4=y
-CONFIG_HAVE_KERNEL_LZMA=y
-CONFIG_HAVE_KERNEL_LZO=y
-CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_HAVE_MOD_ARCH_SPECIFI
