On 5/31/23 21:08, Yousong Zhou wrote:
Not that I got any clue, but this looks very suspicious that you saw
the supposed-to-go-through-tunnel packet at an intermediate router
(the openwrt device).
I don't know exactly what happened here, but I didn't see it again.
In any case, it turns out
On 5/31/23 10:20, Peter Naulls wrote:
On 5/30/23 21:09, Yousong Zhou wrote:
On Wed, 31 May 2023 at 06:38, Peter Naulls wrote:
Thanks for you patience, more:
I ran the connection instead over a wired WAN connection instead of the cell
WWAN link, and the problem is the same. This points
On 5/30/23 21:09, Yousong Zhou wrote:
On Wed, 31 May 2023 at 06:38, Peter Naulls wrote:
Is it that your dns traffic is not going through the tunnel? curl
-vvv should reveal the IP address it tries to connect. One
possibility is that maybe the resolv result does not work.
Yes, a DNS
On 5/30/23 18:16, Yousong Zhou wrote:
On Wednesday, 31 May 2023, Peter Naulls wrote:
]
I am afraid the above is still single direction traffic.
Sorry, quite so. I finished this email in the middle of something else. There
is return traffic:
To Google, which works.
16:57:11.936911
I'm trying to track down a problem whereby using Windows VPN, some websites are
accessible and some aren't. The problem is 100% OpenWrt, since it works over
my regular WiFi router.
Here's what I know (or think I know):
All the VPN traffic uses UDP port 4500. This is (or should be) a
On 5/7/23 13:19, Hauke Mehrtens wrote:
I check from time to time which companies in the US are looking for OpenWrt
experts [0] to get an overview who is using it. About 10% to 30% of these job
offers require clearance. It looks like the US military and US intelligence
community is using
On 5/2/23 09:31, Enrico Mioso wrote:
On Tue, May 02, 2023 at 09:24:52AM -0400, Peter Naulls wrote:
On 5/2/23 07:26, Enrico Mioso wrote:
Another impression I have, is that the OpenWrt project is very important for
many yet under-resourced.
There are some important tasks that would help
On 5/2/23 07:26, Enrico Mioso wrote:
On Mon, May 01, 2023 at 04:56:36PM -0400, Peter Naulls wrote:
On 5/1/23 16:42, Dave Taht wrote:
one of the constraints OpenWrt has been placed under, historically, is the need
to fit in small flash memoris, so fitting some libraries and infrastructure
On 5/1/23 16:42, Dave Taht wrote:
How a ragtag bunch of unincorporated (mostly?) peacenik hippie types
can co-exist with devices being built by militaries out of this stuff
I have few ideas. I prefer to shrink the world, and produce stable,
secure, software, for everyone that wants it, but I
For those of you who track the small but very real OpenWrt job market, you may
have seen there's a creep into Defense/Clearance jobs. Here's but one example:
https://careers-bluehalo.icims.com/jobs/3844/job
As a self-declared pacifist (and anyway, dual citizen which would limit my
ability
On 2/21/23 11:02, Peter Naulls wrote:
On 2/15/23 10:17, Chuanhong Guo wrote:
Hi!
What to try next, thanks!
It looks like the detected spare size and ECC strength matches between the
two drivers, according to the u-boot message and kernel log.
Maybe you can try dumping the nand controller
On 2/28/23 09:07, Felix Baumann wrote:
one issue I see here is that there are MT7621 devices like the Asus RT-AX53U
that don't save their environment to their u-boot-env partition by default.
You still need to execute saveenv while connected via serial.
Note: the device doesn't have a
On 2/28/23 06:46, Bjørn Mork wrote:
Peter Naulls writes:
On 2/27/23 17:23, Hauke Mehrtens wrote:
This will add uboot-envtools to all devices. uboot-envtools is not
included in all DEVICE_PACKAGES now, should we explicitly remove it
from device definitions which do not had it before
On 2/27/23 17:23, Hauke Mehrtens wrote:
Build firmware images for Ralink MT7621 based boards.
This will add uboot-envtools to all devices. uboot-envtools is not included in
all DEVICE_PACKAGES now, should we explicitly remove it from device definitions
which do not had it before?
The
On 2/20/23 09:48, Peter Naulls wrote:
On 2/16/23 17:17, Alexander Papazoglou wrote:
My first guess would be that your microcontroller code doesn't handle repeated
starts properly. All of the i2ctransfer commands you've shown involve at least
one repeated start with the new driver but perhaps
On 2/23/23 01:43, Rafał Miłecki wrote:
On 22.02.2023 21:02, Peter Naulls wrote:
config device
option 'lan1'
This line is clearly wrong. See how you specify device name in above section.
Perhaps it is "clear" but there's much in OpenWrt that isn't obvious up front,
On 2/22/23 15:34, Robert Marko wrote:
option 'lan1'
option macaddr 34:BA:9A:CC:DD:EE
This should work as long as its in single quotes.
I corrected the quotes, but no joy.
Also, cant you fixup the MAC in 02_networking or in preinit?
Yes, I have a preinit script, but
Due to some missing flash values, I need to do a later user space lookup for
possible missing values stored "elsewhere" to fix up the MAC address.
According to:
https://openwrt.org/docs/guide-user/base-system/basic-networking
Something like this should work:
config device
option
On 2/15/23 10:17, Chuanhong Guo wrote:
Hi!
What to try next, thanks!
It looks like the detected spare size and ECC strength matches between the
two drivers, according to the u-boot message and kernel log.
Maybe you can try dumping the nand controller setup registers and compare
the
On 2/16/23 17:17, Alexander Papazoglou wrote:
My first guess would be that your microcontroller code doesn't handle repeated
starts properly. All of the i2ctransfer commands you've shown involve at least
one repeated start with the new driver but perhaps not with the old one. To
verify, you
On 2/16/23 13:59, Jan Breuer wrote:
On 16. 2. 2023 16:21, Peter Naulls wrote:
On 2/15/23 13:31, Peter Naulls wrote:
I'm trying to track yet another vendor vs current OpenWrt driver mishandling.
x00
Can you please provide info about the exact SoC and hardware you are using?
Hi Jan
On 2/15/23 13:31, Peter Naulls wrote:
I'm trying to track yet another vendor vs current OpenWrt driver mishandling.
x00
In particular, for the first read attempt, the value is always the first
value sent as part of the last write. i.e, 3 in this case. After, that,
it's always 0 (the correct
I'm trying to track yet another vendor vs current OpenWrt driver mishandling.
In my vendor kernel:
[2.243263] i2c-mt7621 1e000900.i2c: clock 100KHz, re-start not support
Which is this driver:
* drivers/i2c/busses/i2c-mt7621.c
*
* Copyright (C) 2013 Steven Liu
* Copyright (C) 2016
On 2/13/23 15:01, Peter Naulls wrote:
ich might be the misreporting.
In our driver, it comes out as:
[ 16.091826] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB
size: 128
[ 16.107083] mt7621-nand 1e003000.nand: ECC strength adjusted to 12 bits
I tried adjusting
On 2/11/23 08:10, Chuanhong Guo wrote:
Hi!
# nanddump -a /dev/mtd2
ECC failed: 8
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 128
Dumping data starting at 0x and ending at 0x0004...
libmtd: error!: MEMGETBADBLOCK
On 2/10/23 22:41, Chuanhong Guo wrote:
Hi!
16.163318] 8 fixed-partitions partitions found on MTD device mt7621-nand
From the datasheet here:
https://www.mxic.com.tw/Lists/Datasheet/Attachments/8858/MX30LF1G28AD,%203V,%201Gb,%20v1.3.pdf
The MX30LF1G28AD actually have 2K+128 flash layout, so
This is the boot on the vendor legacy code - OpenWrt 18.06ish, with kernel
4.14.131, with probably a bunch of their customizations, but:
[9.398860] [NAND]select ecc bit:12, sparesize :112 spare_per_sector=28
[9.412077] nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xf1
[
On 2/7/23 18:35, Eric Montellese wrote:
Hello all,
As I'm sure those on this list are aware, OpenWrt is used extensively in the
commercial router world.
That would be an understatement, we do for one.
At NETGEAR, I am working to find a satisfactory solution to an annoying little
corporate
.
Signed-off-by: Peter Naulls
diff --git a/target/linux/ramips/dts/mt7621_atel-ei.dts b/target/linux/ramips/dts/mt7621_atel-ei.dts
new file mode 100755
index 00..2dcbd7b932
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_atel-ei.dts
@@ -0,0 +1,177 @@
+/dts-v1/;
+
+#include "mt7621
This is elfutils-0.188 in master. No doubt I'm using a bad toolchain combo - I
brought the config over from my 22.03 build:
CONFIG_GCC_VERSION="11.3.0"
CONFIG_BINUTILS_VERSION_2_38=y
configure:3994: mipsel-openwrt-linux-musl-gcc -Os -pipe -mno-branch-likely
-mips32r2 -mtune=24kc
On 1/24/23 14:48, Nick wrote:
Hey,
We have testing-support for 5.15 in almost all targets, so we may be able to
release it shortly [0]? WIP 6.1 support is already underway in OpenWrt [1]. We
are using GCC 12 as our default compiler version[2]. Binutils has been updated
to version 2.40. Could
as debug.
Signed-off-by: Peter Naulls
---
--- a/src/odhcpd.c 2023-01-24 13:29:56.080616097 -0500
+++ b/src/odhcpd.c 2023-01-24 13:30:19.284692423 -0500
@@ -207,7 +207,7 @@
ssize_t sent = sendmsg(socket, , MSG_DONTWAIT);
if (sent < 0)
- syslog(LOG_ERR, "Failed to send to %s%%%
On 1/22/23 13:58, Daniel Santos wrote:
[snip]
Thanks Daniel and all the others (to many to mention). Yes, I should have read
the datasheet much earlier, so in the end I really have only myself to blame.
The fix was simply to add back in the "rgmii2" group back into the gpio group.
I
I posted previously on GPIOs, which caused some debate; this may or may not
be relevant, but I'd be remiss to not mention it:
http://lists.openwrt.org/pipermail/openwrt-devel/2022-October/039593.html
I've been chasing an issue with GPIO mapping in for an mt7621 on the OpenWrt
5.10.161 etc
On 12/30/22 15:42, Jo-Philipp Wich wrote:
Hi,
[...]
I renamed the new cookies to "http-sysauth" and "https-sysauth", to work
around this and it seems to do the right thing. But there is still a fault
here.
Already fixed with
On 12/22/22 15:56, Peter Naulls wrote:
On 12/22/22 13:50, Oscar Hjelm wrote:
I’m not familiar with the luci interface, but to help you get started:
- One workaround would be to use a different cookie name on the new secure
cookies (or a new name on the older cookies, if that is preferred
I see this warning in Firefox (OpenWrt 22.03):
Loading mixed (insecure) display content
“http://192.168.113.1/luci-static/resources/icons/loading.gif?0.046104145623280135”
on a secure page
This happens when the sysupgrade dialog is processing on an https luci. It
doesn't cause any real
On 12/22/22 13:50, Oscar Hjelm wrote:
I’m not familiar with the luci interface, but to help you get started:
- One workaround would be to use a different cookie name on the new secure
cookies (or a new name on the older cookies, if that is preferred). The two
cookies could co-exist.
Yes,
Some background. I have two versions of OpenWrt code:
One is legacy version based upon a mismash of versions, but is approximately
luci code from mid-2021. The webserver is http only. I'm able to change this
code for bug fixes, but don't want to pull in anything too large.
The other is
I've been experimenting with making the overlay encrypted as part of our
security requirements.
There are a couple of things needed to make this work - first, cryptsetup and
other kernel modules need to be brought in. This also needs the upstream kernel
patch to block2mtd that I posted last
In 22.03, px5-mbedtls isn't bothering to check if the output was opened:
--- a/package/utils/px5g-mbedtls/px5g-mbedtls.c
+++ b/package/utils/px5g-mbedtls/px5g-mbedtls.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
@@ -70,6 +71,11 @@ static void
On 11/29/22 12:37, Daniel Golle wrote:
I thought you are on a device with actual block storage.
For your case I also can't come up with anything better which works
out-of-the-box for NOR flash. Supporting fscrypt in JFFS2 would be more
elegant, but that's a bit more demanding than just using
On 11/29/22 11:50, Daniel Golle wrote:
There is nothing wrong with that use-case, and it can even be
interesting for other downstream users. Encrypted rootfs_data is
generally a good idea, especially when rootfs_data is used to store
private key material (think: VPN keys) or other kind of
On 11/29/22 10:32, Daniel Golle wrote:
On Tue, Nov 29, 2022 at 10:23:48AM -0500, Peter Naulls wrote:
This backports the upstream label feature in block2mtd to the 5.10.x kernel
in 22.03:
https://github.com/torvalds/linux/blob/master/drivers/mtd/devices/block2mtd.c
Where are we using
This backports the upstream label feature in block2mtd to the 5.10.x kernel in
22.03:
https://github.com/torvalds/linux/blob/master/drivers/mtd/devices/block2mtd.c
--- a/drivers/mtd/devices/block2mtd.c 2022-11-29 07:35:32.382695321 -0500
+++ b/drivers/mtd/devices/block2mtd.c 2022-11-29
Our vendor has put calibration data into flash for the onboard WiFi. They've
made some changes which I have to their supplied 4.14.131 driver to read from
the "factory" flash partition to read calibration data.
As per my previous post on u-boot, getting exact details out of them
has proved
On 11/17/22 14:33, Petr Štetiar wrote:
Daniel Golle [2022-11-17 17:01:43]:
Hi,
Add swig/host to build dependencies.
this doesn't looks like a cleanup as commit subject suggests, but rather
contrary :-)
Thanks all in any case for looking at this. We have a possible need to modify
our
I needed to add this in my build:
diff --git a/package/boot/uboot-mediatek/Makefile
b/package/boot/uboot-mediatek/Makefile
index 9d823ec698..ac8e5dd0f3 100644
--- a/package/boot/uboot-mediatek/Makefile
+++ b/package/boot/uboot-mediatek/Makefile
@@ -3,7 +3,7 @@ include
The 2.4.9 version of expat in OpenWrt 22.03 contains the following CVEs:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-43680
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-40674
Suggest either update to 2.5.0 (as per master) or application of the upstream
patches, etc:
On 11/3/22 14:49, Peter Naulls wrote:
Another one from our security scan:
File: /usr/sbin/px5g
Issue: RET NOT ASSIGNED in function 'FUN_000281b0' at address 0x281c0 while
calling 'mbedtls_rsa_check_pub_priv'
Issue: RET NOT ASSIGNED in function 'FUN_000285e8' at address 0x285f8 while
calling
On 11/3/22 12:01, Etienne Champetier wrote:
Hi Peter,
Can you resend this as a proper patch ready to be applied ?
Or as a PR on Github if this is easier for you ?
Sorry, retry. I wasn't 100% sure of the filename setup for submitted
patches. I've got a couple more to come.
As per:
Another one from our security scan:
File: /usr/sbin/px5g
Issue: RET NOT ASSIGNED in function 'FUN_000281b0' at address 0x281c0 while
calling 'mbedtls_rsa_check_pub_priv'
Issue: RET NOT ASSIGNED in function 'FUN_000285e8' at address 0x285f8 while
calling 'mbedtls_ecp_check_pub_priv'
I'm not
https://nvd.nist.gov/vuln/detail/CVE-2021-46848
Against openwrt-22.03
--- /dev/null
+++ b/libs/libtasn1/patches/099-CVE-2020-15888.patch
@@ -0,0 +1,11 @@
+--- a/lib/int.h2022-11-03 10:15:01.065656767 -0400
b/lib/int.h2022-11-03 10:15:39.333658083 -0400
+@@ -97,7 +97,7 @@
On 10/25/22 18:20, openwrt-devel-requ...@lists.openwrt.org wrote:
From: Nathan Lutchansky
My hands are tied, we gotta do the dance.
I mean this as gently as possible, but I think what a lot of us are
missing is the benefit to the OpenWrt project to carry an increased
maintenance burden in
On 10/25/22 20:45, Reuben Dowle wrote:
My opinion is that openwrt should try and move to a newer version of lua. This
old 5.1.5 version appears to be unmaintained, and there does not seem to be the
resources within the openwrt community to change that.
So I naively adjusted the lua5.3
Lua 5.1.5 would appear to have CVEs below against it.
The patches to this in OpenWrt are significant, but dated, with the
last bug fix seeming to be from 2019, so it's hard to say if
these are addressed:
https://github.com/openwrt/openwrt/tree/openwrt-22.03/package/utils/lua/patches
On 10/25/22 17:45, Michael Richardson wrote:
So, it needs to bound to *all* the IPv6 "LAN" IPs.
That means:
a) the ULA that is created.
b) the LL-IPv6 that are always present
c) the GUA IPv6 that is delegated
Sorry, I badly paraphrased. The requested change was for IPv4 only. I
On 10/25/22 17:25, Reuben Dowle wrote:
I have myself gone through the process of getting an openwrt based product
through a security audit.
The issue of HTTP listening on all interfaces also came up in my audit, but the
auditors were happy with the explanation that the firewall prevented
On 10/25/22 16:40, Karl Palsson wrote:
Peter Naulls wrote:
If they see what they want to see, then why should anyone else
get involved in their wish fulfilment?
Security review is fine, security should not be entertained, and
certainly foisted on other people?
Karl, not sure where you're
On 10/25/22 14:53, Luiz Angelo Daros de Luca wrote:
is much easier to let the firewall zones deal with that.
As aside, they don't see the iptables tool in the system, and don't
understand that that's been deprecated (although I since did add it
for some unrelated legacy usage), and think
The default uhttpd configuration has this:
# HTTP listen addresses, multiple allowed
list listen_http0.0.0.0:80
list listen_http[::]:80
Now, I know there's lots of practical reasons for this to be the case,
and I know also that the firewall setup in OpenWrt is
On 10/24/22 18:21, Hauke Mehrtens wrote:
Hauke, thanks for replying!
I also prefer if the CVE number is named in the patch. If this is missing
somewhere you could send a patch or pull request to rename the patch.
I'm afraid I don't have any explicit examples, but I'll let you know if
find
On 10/23/22 23:35, Phillip Lougher wrote:
On Thu, Oct 20, 2022 at 6:01 PM Peter Naulls wrote:
What you probably want is the following
% mksquashfs test test.sqsh -action "chmod(ugo-w)@perm(/ugo+w)"
It is, fantastic, thank you.
I added to include/image.mk:
--- a/include/imag
I don't know if this is intentional, or some side effect of my build setup, but
the OpenWrt 22.03 libstdc++ library has some build strings in it.
$ strings
build_dir/target-mipsel_24kc_musl/root-ramips/usr/lib/libstdc++.so.6.0.29 | grep
home
...
This is of course from ca-certificates 20211016
$ openssl x509 -enddate -noout -in
build_dir/target-mipsel_24kc_musl/root-ramips/etc/ssl/certs/Cybertrust_Global_Root.crt
notAfter=Dec 15 08:00:00 2021 GMT
$ openssl x509 -enddate -noout -in
Apologies for the obtuseness of the previous email about the squashfs
permissions - that's related to the following, but a different topic. I can now
say that we're undergoing a security review for our system which is very much
based upon OpenWrt 22.03.
If you have ever done this, you'll
Yes, I know. Bear with me. Laugh if you must.
# ls -l /rom/
...
drwxr-xr-x4 root root98 Oct 20 13:53 www
I'd like to remove the writable bits from the squashfs image - /www is
particular concern because of security paranoia.
Now I realize that:
1. This is contrary to
On 10/19/22 05:51, Lukas Zeller wrote:
Hi,
Lukas, thanks for this. I've read through everything and I agree with your
concerns. I'll note also that Linus W's commentary is from 2018.
On 19 Oct 2022, at 08:55, Petr Štetiar wrote:
IMO there should be `ugpiod` daemon available over ubus,
On 10/18/22 17:10, Lukas Zeller wrote:
.
Just not any more - the mt7621 had this too. I currently patch it back into
22.03's gpio-mt7621.c for my builds and set base in the DTS, see [3]
I can follow the rationale to get rid of legacy GPIOs, but in the context
of experimenting platforms, where
On 10/18/22 15:55, Martin Blumenstingl wrote:
Hello Peter,
On Tue, Oct 18, 2022 at 9:34 PM Peter Naulls wrote:
Looks like there was some code loss when the driver came from an earlier kernel
series. Without this, my MT7621 board starts its GPIO offsets at 416 (why that
number, I don't know
Looks like there was some code loss when the driver came from an earlier kernel
series. Without this, my MT7621 board starts its GPIO offsets at 416 (why that
number, I don't know):
--- a/drivers/gpio/gpio-mt7621.c2022-10-18 15:03:42.596454871 -0400
+++ b/drivers/gpio/gpio-mt7621.c
On 02/11/2013 12:04 PM, Aleksander Morgado wrote:
Hey,
I'm trying to prepare an update of udev/libudev to latest upstream. As
you may already know, udev/libudev sources are now within systemd. I'm
not fully sure how to handle this issue; so I'm hoping to get some
advice here. Comments welcome!
This is not strictly on topic for this list, so I'll keep this pretty short.
I'm after a developer to work in the Bay Area on OpenWrt stuff. You should
be a junior/mid level developer willing to learn new skills but who knows
the basics of embedded development. We do lots of other stuff, but
On 08/01/2012 09:03 PM, LEO Airwarosu Yoichi Shinoda wrote:
On 2012/08/01, at 22:39, Peter Naulls wrote:
The problem here is that the LED handling is done in the wrong
order. I submitted a fix/patch(?) for this months ago, but
it seems to have been ignored or lost. I can dig it out
again
On 07/31/2012 11:45 PM, LEO Airwarosu Yoichi Shinoda wrote:
The problem of wmac based leds on WZR-HP-AG300H stimulated
some research on status of led support on other buffalo
units with wmac based leds.
The following results and observations are based on the
trunk revision r32910.
COMMON
-
On 07/30/2012 09:51 PM, LEO Airwarosu Yoichi Shinoda wrote:
Peter and folks,
I believe Peter meant WZR-HP-AG300H.
Last night, I did some research on behaviors of leds on WZR-HP-AG300H,
and located controls for all remaining leds on wmacs.
Awesome, seems to work fine. Thanks.
On 07/27/2012 07:35 PM, LEO Airwarosu Yoichi Shinoda wrote:
On 2012/07/28, at 8:04, Peter Naulls wrote:
On 07/27/2012 04:00 PM, LEO Airwarosu Yoichi Shinoda wrote:
Folks,
Please ignore this particular (additional) patch.
I've started to learn how uci-defaults work.
Also, and unless
On 07/27/2012 04:00 PM, LEO Airwarosu Yoichi Shinoda wrote:
Folks,
Please ignore this particular (additional) patch.
I've started to learn how uci-defaults work.
Also, and unless I've missed some very recent patch, we're still sans
full support of all the LEDs on the AG300N. Anyone want to
On 04/19/2012 05:41 AM, Mirko Vogt wrote:
I also noticed complains about glibc - however every time I ask people
why in particular they chose glibc over eglibc I didn't get any
meaningful response. glibc is de facto unmaintained in OpenWrt and I'd
actually like to purge it out - still I'm
On 04/17/2012 11:15 AM, Mirko Vogt wrote:
Hey Emmanuel,
I levelled up all versions of eglibc to i's latest revisions of its
respective branches ( https://dev.openwrt.org/changeset/31300 ) and
therewith I guess broke eglibc version 2.12 which I'd like to purge out
anyway. Is there any reason for
On 02/25/2012 07:13 AM, Bastian Bittorf wrote:
Remembering the old days, where we had floppy-drives?
Now we have MTD. sad but true, in case of any error during
sysupgrade regarding mtd, there are no further checks
and we are f*cked:
###
Performing system upgrade...
Unlocking linux ...
Writing
On 02/25/2012 10:15 AM, Bastian Bittorf wrote:
cause is, but what I have seen is that the mtd utility
needs to retry sometimes, and that [e] condition
is a temporary Out of memory error. At least, on ar71xx.
out of memory doesnt satisfy me.
And? I'm telling you what the error is at this
Hi guys, I mention in case anyone is interested. I've started work on
an OpenWrt port to the Bulogics gateway. I've documented here:
http://wiki.openwrt.org/toh/bulogics/smartgrid
I'm actually a bit beyond that, have found serial port, etc, etc. I
think the software/kernel itself is pretty
On 02/06/2012 08:52 AM, jonsm...@gmail.com wrote:
Most ARM CPUs have boot ROMs for getting the initial image out of
flash. I'm referring to the boot loader that loads uboot, not uboot.
The ARM CPUs I've worked with search for a signature in flash, if they
can't find a valid signature they load
On 01/25/2012 02:50 PM, Philip Prindeville wrote:
I'm told that my patches languish because they are for 2.6.39.4 (or
whatever)
and I'm encouraged to go to a newer kernel... but I can't because all of the
churn with the ath9k goes untested and tends to be extremely destabilizing to
the ath5k
On the G300NH (v1), the router LED is turned on at boot completion
to indicate it's running. Or at least, that's the intent of the
done script. But the led script which sets up the mappings has
START=96, but the done script is 95. So it never gets turned on.
I fixed that in my setup by
Add support for the Rainforest Automation Zigbee dongle.
This is against 2.6.39 only, however Linux 3.2 does not have this
ID either.
Signed-of-by: Peter Naulls pe...@chocky.org
Index: target/linux/generic/patches-2.6.39/823-usb_serial_ftdi_add_more_devices.patch
On 01/16/2012 01:49 PM, jonsm...@gmail.com wrote:
I can't get any of the glibc versions to build on ARM. I wanted to use
glibc as a way of eliminating ulibc as the source of the bug. They all
fail with various compile errors.
Less than 2.7 complains about binutils.
cue weekly response
2.7 is
I'm seeing this:
Realtek RTL8366S ethernet switch driver version 0.2.2
[1.01] rtl8366s rtl8366s: using GPIO pins 19 (SDA) and 20 (SCK)
[1.01] rtl8366s rtl8366s: unknown chip id ()
[1.02] rtl8366s rtl8366s: chip detection failed, err=-19
[1.03] eth0: Atheros
On 01/11/2012 07:16 PM, Mark Deneen wrote:
Quick question, since I don't know the full story here.. but the
buffalo gpl source for u-boot for the G300NH is available. The NH2
u-boot source is MIA, though.
http://opensource.buffalo.jp/gpl_wireless.html
It's in the G300NH tarball. The source
On 01/12/2012 02:26 AM, Florian Fainelli wrote:
Hello Peter,
The system seemed otherwise ok, but I didn't test beyond this.
Can you describe how you run into this error? Just so that we can reproduce and
fix the problem.
Should have provided more details. I had to rebuild the kernel to
I think this is the same kernel I've been using a long time on
WZR-HP-G300NH, (that is, not the preemptive options I
mentioned yesterday), but I did recently turn on debugging.
I think this may help explain some occasional flash failures
we've been seeing (this is the only one with a serial
For comedy value, I enabled preemption in my G300NH build:
124.49] BUG: scheduling while atomic: swconfig/811/0x0002
[ 124.50] 2 locks held by swconfig/811:
[ 124.50] #0: (genl_mutex){+.+...}, at: [8021cd20] genl_rcv+0x14/0x34
[ 124.51] #1:
On 01/07/2012 03:25 AM, Florian Fainelli wrote:
Le samedi 07 janvier 2012 00:32:31, Peter Naulls a écrit :
On 01/06/2012 08:10 AM, Peter Naulls wrote:
As an alternative, I'm looking at first jumping to an ar71xx version
of u-boot (as per OpenWrt build), all I should need to add
On 01/06/2012 07:06 AM, Paolo Pisati wrote:
On 01/06/2012 11:48 AM, Florian Fainelli wrote:
Then this might be an entirely different issue. Try to run the kexec'd
kernel uncached and see if that helps (there is a MIPS-specific Kconfig
option to do that).
but is kexec working at all on MIPS
On 01/06/2012 02:48 AM, Florian Fainelli wrote:
Then this might be an entirely different issue. Try to run the kexec'd kernel
uncached and see if that helps (there is a MIPS-specific Kconfig option to do
that).
CONFIG_MIPS_L1_CACHE_SHIFT=5 ? There's other related stuff in
arch/mips/Kconfig
On 01/06/2012 08:10 AM, Peter Naulls wrote:
As an alternative, I'm looking at first jumping to an ar71xx version
of u-boot (as per OpenWrt build), all I should need to add to that
is flash support for the G300NH(2). Perhaps that puts the system
in more consistent state before starting Linux
I'm trying to use kexec as a fallback/flash mechanism. But something is going
wrong:
http://pastebin.com/0uvNnMQd
So the device halts after/during the serial port setup, and returns to boot
loader. Anyone want to suggest what might be going wrong, or where to
start looking?
On 01/05/2012 09:43 AM, Florian Fainelli wrote:
Hello,
You should enable kernel debugging in your kexec'd kernel and see whether the
serial port is being left with IRQs disabled from the original kernel.
I turned on kernel debug, but I'm unsure what exactly I'm looking at.
It may be that
On 01/04/2012 08:55 AM, Jo-Philipp Wich wrote:
Hi.
Error: bad register name `%sil'
You probably need a patch similar to this:
http://old-list-archives.xen.org/archives/html/xen-devel/2009-05/binBCldaQtw31.bin
Apart from that, there are still a number of pending patches required for
1 - 100 of 128 matches
Mail list logo
