* Martin Blumenstingl [23.11.2016 07:22]:
> +xor() {
> + local ret="0x$1"
> +
> + shift 1
> + while [[ "$1" ]]; do
> + local val="0x$1"
> + ret=$((${ret:-0} ^ ${val:-0}))
> + shift 1
> + done
> +
> + printf "%02x" "$ret"
> +}
minor stuff:
pl
On 2016-11-22 23:48, Bastian Bittorf wrote:
> * Bastian Bittorf [22.11.2016 23:47]:
>> answer myself: CONFIG_TARGET_ROOTFS_PARTSIZE is unset?
>>
>> see 'Image/Build/squashfs' in 'uml/Image/Makefile'
>
> indeed, it works when i set it manually and i can boot into UML:
I updated the commit to allo
Hello Christian,
On Tuesday, November 22, 2016 11:54:44 PM CET Christian Mehlis wrote:
> I updated to your current staging branch 947e53a1 (which includes the
> musl update). Now compile stops in a problem with the backports package,
> which does not match the "new" kernel?!
>
> /home/c/source/
Am 22.11.2016 um 23:54 schrieb Christian Mehlis:
> Hi Christian,
>
> I updated to your current staging branch 947e53a1 (which includes the musl
> update). Now compile stops in a problem with the backports package, which
> does not match the "new" kernel?!
>
> /home/c/source/build_dir/target-arm
There are two types of swapping the EEPROM data in the ath9k driver.
Before this series one type of swapping could not be used without the
other.
The first type of swapping looks at the "magic bytes" at the start of
the EEPROM data and performs swab16 on the EEPROM contents if needed.
The second t
This moves the extraction of the eeprom/calibration data to a hotplug
firmware script. Additionally it modifies all .dts to configure ath9k
directly from within the .dts.
The owl-loader approach enables support on devices with exotic eeprom
data locations (such as unaligned positions on the flash
This series uses devicetree to configure the devices with ath9k wifi
chips.
The first two patches are preparing PCIe for OF support (PCI devices
are already configured via devicetree properly, so we don't have to
do anything here).
The third patch backports the ath9k devicetree bindings to our
mac
This allows specifying PCI devices as children of the PCIe controller
node to pass configuration data to them.
Signed-off-by: Martin Blumenstingl
---
.../lantiq/patches-4.4/0151-lantiq-ifxmips_pcie-use-of.patch | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git
a/targ
This allows adding devices to the PCIe controller in the .dts files.
Signed-off-by: Martin Blumenstingl
---
target/linux/lantiq/dts/vr9.dtsi | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/target/linux/lantiq/dts/vr9.dtsi b/target/linux/lantiq/dts/vr9.dtsi
index
These patches add support for configuring ath9k based devices via
devicetree. This was tested on PCI(e) based devices. This should work
for AHB based devices as well (adding more AHB specific properties may
still be needed) as soon as the ath79 platform is ready to populate the
ath9k wmac via devic
These properties allow overriding the settings from the EEPROM
which indicate whether a band is enabled or not.
Setting this property is only needed when the RF circuit does not
support the 2.4GHz or 5GHz band while it is enabled nevertheless in the
EEPROM.
These patches will be replaced with a fu
Hi Christian,
I updated to your current staging branch 947e53a1 (which includes the
musl update). Now compile stops in a problem with the backports package,
which does not match the "new" kernel?!
/home/c/source/build_dir/target-arm_cortex-a7+neon-vfpv4_musl-1.1.16_eabi/linux-ipq40xx/compat-w
* Bastian Bittorf [22.11.2016 23:47]:
> answer myself: CONFIG_TARGET_ROOTFS_PARTSIZE is unset?
>
> see 'Image/Build/squashfs' in 'uml/Image/Makefile'
indeed, it works when i set it manually and i can boot into UML:
root@uml:/ df -h
FilesystemSize Used Available Use% Mounted
* Bastian Bittorf [22.11.2016 23:01]:
> * Felix Fietkau [22.11.2016 22:42]:
> > > here the build-error with "inodes full".
> > > (the same images works, if i just raise the inodes to 2048)
> > Try disabling the ext4 image via make menuconfig.
>
> sorry, does not help. i did:
> make menuconfig (u
Hi,
Am Tue, 22 Nov 2016 10:12:53 -
schrieb Karl Palsson :
> [..]
> The life of the "service start|stop|status" really wasn't
> very long.
I just looked up the changelog of sysvinit-utils in Debian: this wrapper was
introduced in 2009. Seven years is not that bad, I guess.
Anyway: the wrapp
On 11/22/2016 11:12 AM, Karl Palsson wrote:
>
>
> If it looks like debian and out of date unsupported
> centos/redhat, but is actually completely different, is it really
> helpful to make it look like something it's not?
>
Well, some secondary options (that can be added if someone thinks are
re
* Felix Fietkau [22.11.2016 22:42]:
> > here the build-error with "inodes full".
> > (the same images works, if i just raise the inodes to 2048)
> Try disabling the ext4 image via make menuconfig.
sorry, does not help. i did:
make menuconfig (unselect ext4)
make clean
make BUILD_LOG=1
(build abor
Hi Daniel,
Regarding (Phase 2 - ubus rpc proxy), I had opened a thread in October:
https://lists.openwrt.org/pipermail/openwrt-devel/2016-October/042252.html
Currently we are working on a solution where multiple OpenWrt devices share a
common ubus which allows us to control all devices from a s
On 2016-11-22 21:28, Bastian Bittorf wrote:
> * Felix Fietkau [22.11.2016 18:17]:
>> > I tested it and it's usable with 16M rootfs.
>> Here's some more information: it creates the overlay filesystem with a
>> block size of 1K, and it has 3493 free inodes after booting up.
>
> Does not work here,
* Felix Fietkau [22.11.2016 18:17]:
> > I tested it and it's usable with 16M rootfs.
> Here's some more information: it creates the overlay filesystem with a
> block size of 1K, and it has 3493 free inodes after booting up.
Does not work here, with some additional packages (like olsrd + olsrd2
+r
Hi Rafal,
> On 25 October 2016 at 9:41, Rafał Miłecki wrote:
> Anyway I finally debugged this local vs. buildbot difference to the
> CONFIG_KERNEL_KALLSYMS. Images from buildbot have this symbol enabled
> which slightly increases kernel size. Enough to stop it from booting
> on WRT300N v1.
Yeste
On 2016-11-22 18:04, Felix Fietkau wrote:
> On 2016-11-22 17:57, David Lang wrote:
>> On Tue, 22 Nov 2016, Felix Fietkau wrote:
>>
>>> On 2016-11-22 17:48, David Lang wrote:
On Tue, 22 Nov 2016, Felix Fietkau wrote:
> On 2016-11-22 17:43, David Lang wrote:
>> On Tue, 22 Nov 2016,
On 2016-11-22 17:57, David Lang wrote:
> On Tue, 22 Nov 2016, Felix Fietkau wrote:
>
>> On 2016-11-22 17:48, David Lang wrote:
>>> On Tue, 22 Nov 2016, Felix Fietkau wrote:
>>>
On 2016-11-22 17:43, David Lang wrote:
> On Tue, 22 Nov 2016, Felix Fietkau wrote:
>
>>> On a 16M filesy
On Tue, 22 Nov 2016, Felix Fietkau wrote:
On 2016-11-22 17:48, David Lang wrote:
On Tue, 22 Nov 2016, Felix Fietkau wrote:
On 2016-11-22 17:43, David Lang wrote:
On Tue, 22 Nov 2016, Felix Fietkau wrote:
On a 16M filesystem, we probably want to use a 1K block size and have an inode
for eve
On 2016-11-22 17:43, David Lang wrote:
> On Tue, 22 Nov 2016, Felix Fietkau wrote:
>
>>> On a 16M filesystem, we probably want to use a 1K block size and have an
>>> inode
>>> for every couple of blocks.
>> I'd say on a 16M filesystem we probably want to use squashfs+ext4
>> instead of plain ext4
On 2016-11-22 17:48, David Lang wrote:
> On Tue, 22 Nov 2016, Felix Fietkau wrote:
>
>> On 2016-11-22 17:43, David Lang wrote:
>>> On Tue, 22 Nov 2016, Felix Fietkau wrote:
>>>
> On a 16M filesystem, we probably want to use a 1K block size and have an
> inode
> for every couple of blo
On Tue, 22 Nov 2016, Felix Fietkau wrote:
On 2016-11-22 17:43, David Lang wrote:
On Tue, 22 Nov 2016, Felix Fietkau wrote:
On a 16M filesystem, we probably want to use a 1K block size and have an inode
for every couple of blocks.
I'd say on a 16M filesystem we probably want to use squashfs+e
On Tue, 22 Nov 2016, Felix Fietkau wrote:
On a 16M filesystem, we probably want to use a 1K block size and have an inode
for every couple of blocks.
I'd say on a 16M filesystem we probably want to use squashfs+ext4
instead of plain ext4 and avoid the inode issue altogether.
I'm not sure I und
On 2016-11-22 15:41, David Lang wrote:
> changing the blocksize doesn't really address the problem of too few inodes,
> except indirectly in that the default number of inodes is calculated from the
> number of blocks on the filesystem.
>
> In the case of LEDE, we tend to have fewer large files o
in arch/mips/pci/pci-mt7621.c
we have #define GPIO_PERST that is always set.
This has the side effect of setting gpio pin 7,8 and 19 to gpio and set
the output value to 0.
I could understand gpio19(perst) if there was some hardware errata that
made the perst function not working and this cod
Don't create a hole in the array of configs if there's a directory. Such
a hole would be mistaken for the end of the array.
Signed-off-by: Michal 'vorner' Vaner
---
file.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/file.c b/file.c
index 81047a4..6fc46bb 10
Hello
It was pointed to me by a user that when the /etc/config contains
subdirectories, uci show lists everything only up to the first subdirectory and
then stops.
It turns out the uci_list_config_files returns an array which has holes (NULLs)
in places of the subdirectories, as it tries to filte
On Tue, 22 Nov 2016, Jo-Philipp Wich wrote:
1)
detect via makefile if PARTITION is small and autoadjust BLOCKSIZE
(if not given)
iirc the blocksize setting is a choice menu, so it is always defined.
2)
set BLOCKSIZE default to 1K via x86/UML-Makefile
It was explicitly raised to 4k for x86
Yes, it also works on my target!
Thanks.
On Tue, Nov 22, 2016 at 3:07 PM, Bjørn Mork wrote:
> Felix Fietkau writes:
>
>> On 2016-11-22 14:10, Mogens Lauridsen wrote:
>>> Seems like a better fix, but it doesn't work. uqmi hangs, so I suspect
>>> that EM7455 has misunderstood the command. I have
Felix Fietkau writes:
> On 2016-11-22 14:10, Mogens Lauridsen wrote:
>> Seems like a better fix, but it doesn't work. uqmi hangs, so I suspect
>> that EM7455 has misunderstood the command. I have removed/replaced the
>> ustream_write(..,..,.., true) and after the changes below it works.
>> I gues
On 2016-11-22 14:10, Mogens Lauridsen wrote:
> Seems like a better fix, but it doesn't work. uqmi hangs, so I suspect
> that EM7455 has misunderstood the command. I have removed/replaced the
> ustream_write(..,..,.., true) and after the changes below it works.
> I guess it has something to do with
Felix Fietkau writes:
> On 2016-11-22 12:47, Mogens Lauridsen wrote:
>> Hi,
>>
>> I found a memory overwrite causing a crash when using uqmi and
>> qmi-via-mbim such as:
>> uqmi -m -d /dev/cdc-wdm0 --get-signal-info
>>
>> The problem is missing space for mbim header, which is assumed in
>> qmi_
Seems like a better fix, but it doesn't work. uqmi hangs, so I suspect
that EM7455 has misunderstood the command. I have removed/replaced the
ustream_write(..,..,.., true) and after the changes below it works.
I guess it has something to do with the write being split in two.
I don't know what the m
On 2016-11-22 12:47, Mogens Lauridsen wrote:
> Hi,
>
> I found a memory overwrite causing a crash when using uqmi and
> qmi-via-mbim such as:
> uqmi -m -d /dev/cdc-wdm0 --get-signal-info
>
> The problem is missing space for mbim header, which is assumed in
> qmi_request_start():
>
> if (qmi->is_
Hi,
I found a memory overwrite causing a crash when using uqmi and
qmi-via-mbim such as:
uqmi -m -d /dev/cdc-wdm0 --get-signal-info
The problem is missing space for mbim header, which is assumed in
qmi_request_start():
if (qmi->is_mbim) {
buf -= sizeof(struct mbim_command_messag
Hi,
neither the scripts nor the buildbots have an actual problem, its just
that the buildbots clone the Git repo in a way that there is no remote
declared, so the getver.sh logic detects all changes as local.
I'll see if I can fix it during the next few days on the buildbot side,
but it is low pr
Hi,
On Thu, Nov 17, 2016 at 07:25:21AM +0100, Rafał Miłecki wrote:
> If something goes wrong and script can't find upstream revision it will
> return something like:
> r2220
> which looks like a valid upstream revision 2220. We cant' distinguish it
> from e.g. 2200 upstream commits and 20 local on
Jo-Philipp Wich wrote:
> Hi Alberto,
>
> personally I like the service wrapper since it alligns the
> service handling with Debian and older CentOS / Redhat distros.
If it looks like debian and out of date unsupported
centos/redhat, but is actually completely different, is it really
helpful to
Hi,
> 1)
> detect via makefile if PARTITION is small and autoadjust BLOCKSIZE
> (if not given)
iirc the blocksize setting is a choice menu, so it is always defined.
> 2)
> set BLOCKSIZE default to 1K via x86/UML-Makefile
It was explicitly raised to 4k for x86 to reduce wear on MMC storage
which
* Jo-Philipp Wich [22.11.2016 10:08]:
> a huge block size on small partition simply makes no sense. If you
> already configure 16MB partitions then you can as well change block size
> from 4K to 1K or 512B as well since you're deviating from the defaults
> anyway.
>
> Having different code paths
On 22/11/2016 09:51, Jo-Philipp Wich wrote:
> Hi Alberto,
>
> personally I like the service wrapper since it alligns the service
> handling with Debian and older CentOS / Redhat distros.
>
> In its current form though, the script is not providing enough
> functionality to justify its existence
Hi Alberto,
personally I like the service wrapper since it alligns the service
handling with Debian and older CentOS / Redhat distros.
In its current form though, the script is not providing enough
functionality to justify its existence since the same effect can be
achieved through an alias in /e
From: Paul Wassi
Update fuse+libfuse to upstream 2.9.7. Drop the patch for CVE-2015-3202,
which is already integrated in the newer version. Rework the other patches.
Also switch PKG_SOURCE from @SF to libfuse's github releases.
Signed-off-by: Paul Wassi
---
Compile/run-tested in combination wit
Hi,
a huge block size on small partition simply makes no sense. If you
already configure 16MB partitions then you can as well change block size
from 4K to 1K or 512B as well since you're deviating from the defaults
anyway.
Having different code paths for small and huge partitions is annoying
and
Hi Jonas,
thanks for pointing me to
> The kernel led naming rules are described in [1]
In the meantime I already did a list of all kirkwood devices
in LEDE (and of course their LED's names).
Depending on where they come from (Kernel or LEDE),
I'll send patches to.
Best regards,
P. Wassi
___
Hello guys,
i'm new to this mailing list and got a recommendation from a OpenWRT
developer to it.
My problem is, i want to automatically build an squashfs image for
raspberry PI and OpenWRT.
All of this work done by hand works successfully, but i'm not so
familiar with the Makefiles
specially the
51 matches
Mail list logo