ot into a firmware upgrade initram image’, do the work,
then reboot with new firmware.
The copy to Ramdisk a set of required programs, chroot, then do the work, seems
like it has many potential places to fail.
As it is I’ll slog through what I need to do
ot into a firmware upgrade initram image’, do the work,
then reboot with new firmware.
The copy to Ramdisk a set of required programs, chroot, then do the work, seems
like it has many potential places to fail.
As it is I’ll slog through what I need to do
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
I posted this to the forum, so I’l
at the time…
This is something that new equipment producers face with trying to break into a
market. The existing solution is used till the last gasp.
John Clark.
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
jeclark2006 jeclark2006 37120577 Feb 19 18:04
openwrt-toolchain-mpc85xx-p1020_gcc-5.5.0_musl.Linux-x86_64.tar.bz2
-rw-r--r-- 1 jeclark2006 jeclark2006 1108 Feb 19 18:04 sha256sums
John Clark.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
the
various include files spread through out the OpenWRT build system.
Any help would be appreciated.
John Clark.
——— Last few lines of build process, indicating failure to install. Fortunately
it is due to the fact that I was not ‘root’, that it failed.
make[3]: Entering directory
'
, and the smaller organizations which would use such devices, will
just have to take what they can get.
John Clark.
On Sep 22, 2016, at 4:39 AM, Alexander Couzens wrote:
> Hi Ryan,
>
> IMHO: the only possible solution is to create political pressure to
> remove those rules or to get
Thanks for the patch pointer. I’ll try that…
John.
On Sep 7, 2016, at 1:17 PM, Hauke Mehrtens wrote:
> https://git.lede-project.org/?p=source.git;a=commitdiff;h=f97ad870e11ebe5f3dcf833dda6c83b9165b37cb
___
openwrt-devel mailing list
openwrt-devel@li
dict_size;
};
The question is, how is it that there is this significant difference?
It seems that the structure should have been
struct disk_comp_opts {
__le32 dictionary_size;
__le32 flags;
/* Plus additional OpenWRT elements. */
};
John Clark
>>the sudden deletion of our widely published openwrt.org email
addresses somewhat undermines this
Just so I am not jumping to wrong conclusions, their *.openwrt.org email
addresses were deleted in retaliation for forking OpenWrt? Seriously?
How did you not think that wasn't going to go well
>Could you elaborate more and explain how exactly LEDE is going to fix
the listed problems? And why it's not possible to fix them inside
existing project?
The hasty reasons given and the secret and abrupt severing of ties make me
wonder if a "follow the money" approach will yield more plausible an
:13 wget ->
/bin/uclient-fetch*lrwxrwxrwx1 00 12 Jan 24 12:13
zcat -> /bin/busybox
On Fri, Jan 22, 2016 at 3:27 AM, Bastian Bittorf
wrote:
> * John Clark [22.01.2016 07:55]:
> > Is it intentional that wget is not available by default in th
I figured out the sysupgrade issue with respect to the busybox ->
uclient-fetch update and have submitted a PR to address it:
"[PATCH] base-files: fix sysupgrade 'wget' handling for uclient-fetch"
--John
On 1/22/16 10:18 AM, Felix Fietkau wrote:
On 2016-01-22 14:21,
: John Clark
---
package/base-files/files/lib/upgrade/common.sh | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/package/base-files/files/lib/upgrade/common.sh
b/package/base-files/files/lib/upgrade/common.sh
index adf290c..f894f31 100644
--- a/package/base-files/files/lib
.dtsi file.
Signed-off-by: John Clark
---
sending again to fix typo in the original patch request comment
target/linux/ramips/dts/HLKRM04.dts | 5 +
target/linux/ramips/dts/WIZFI630A.dts | 2 ++
target/linux/ramips/dts/WT1520.dtsi | 2 ++
target/linux/ramips/dts/rt5350.dtsi | 3 --
I have the latest trunk running on a ramips architecture and I have
compiled in Bastian Bittorf's r48451 path fix for the new wget:
https://dev.openwrt.org/changeset/48451
However, I am still having problems getting sysupgrade to work. Is
sysupgrade working for anyone else running the >= r4845
ec2-user ec2-user 1644 Jan 18 08:26 Y1.dtsi
--John
On 1/22/16 3:40 PM, John Clark wrote:
The top half of UARTF on the HLK-RM04 is used for GPIO.
mode 1 mode 2
RIN GPIO14
DSR_N GPIO13
DCD_N GPIO12
DTR_N GPIO11
RXD GPIO10
CTS_N GPIO09
TXD GPIO0
.dtsi file.
Signed-off-by: John Clark
---
Also note that target/linux/ramips/dts/WT1520.dtsi is for the "Nexx WT1520"
and should be named "WT1520.dts" instead. I will send that change through as a
different patch.
target/linux/ramips/dts/HLKRM04.dts | 5 +
target/linu
-rm04 pin & export
i2ci2c_sdgpio1 (pin 8, hlk-rm04:gpio0)
i2ci2c_sclk gpio2 (pin 9, hlk-rm04:gpio1)
reference:
http://www.hlktech.net/product_detail.php?ProId=39
http://cdn.sparkfun.com/datasheets/Wireless/WiFi/RT5350.pdf
Signed-off-by: John Clark
---
target/linux/ra
The RESET button of the HLK-RM04 is connected to GPIO0, linux function 0x198
The WPS button of the HLK-RM04 is connected to GPIO14, linux function 0x211
Signed-off-by: John Clark
---
target/linux/ramips/dts/HLKRM04.dts | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git
The power LED on the HLK-RM04 is hard wired to the power bus and is not under
GPIO control, remove the bogus config for it.
(Note that GPIO0 is actually connected to the RESET button.)
Signed-off-by: John Clark
---
target/linux/ramips/dts/HLKRM04.dts | 9 -
1 file changed, 9 deletions
reported, all of my wget issues should be considered resolved at
this point.
--John
On 1/22/16 10:26 AM, John Clark wrote:
I don't know if I looked at the wrong file or what, but I have
recompiled several times since then so I can't be enitrely certain
anymore.
At this point I also se
-rwxr-xr-x1 root root 12343 Jan 22 12:02 uclient-fetch*
-rw-r--r--1 root root 16687 Jan 22 12:02
/usr/lib/libuclient.so
--John
On 1/22/16 10:18 AM, Felix Fietkau wrote:
On 2016-01-22 14:21, John Clark wrote:
yes, is was dropped with r48386 + 48379
so it *
yes, is was dropped with r48386 + 48379
so it *should* be automatically work with wget -> uclient-fetch
I have updated to the latest trunk commit where I see your /usr/bin/wget
-> /bin/wget patch. I have updated the feeds and symlinks to the latest
and greatest. The packages are currently no
Is it intentional that wget is not available by default in the current
trunk? I noticed this because /sbin/sysupgrade is failing in the
current build of designated driver due to this. I thought I would point
it out.
chaos calmer
~~
CONFIG_BUSYBOX_DEFAULT_WGET=y
CONFIG_BUSYBOX_DEFAULT
> +pinctrl-0;
>> are you sure this bit is correct ?
That is there to override the setting from the parent dtsi file. One
could argue that the parent dtsi file should not be setting up the
function of the uart -- this should in fact be done at the dts file
level. We can see below i
ferences memory chip s25fl064k, which seems to have ever been
used for the HiLink HLK-RM04. While it only causes a nag message in the kernel
log, why not change it to the w25q32 which is commonly found on these devices.
Signed-off-by: John Clark
---
target/linux/ramips/dts/H
Signed-off-by: John Clark
---
target/linux/ramips/dts/HLKRM04.dts | 45 +++--
1 file changed, 33 insertions(+), 12 deletions(-)
diff --git a/target/linux/ramips/dts/HLKRM04.dts
b/target/linux/ramips/dts/HLKRM04.dts
index 13597dc..3c206b9 100644
--- a/target/l
The image name for the HiLink HLK-RM04 module has a typo and should read "RM04"
rather than "RM02"
Backport of r48355
Signed-off-by: John Clark
---
target/linux/ramips/image/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/rami
The image name for the HiLink HLK-RM04 module has a typo and should read "RM04"
rather than "RM02"
Signed-off-by: John Clark
---
target/linux/ramips/image/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/ramips/image/Makefile
b
I apologize for the first two messages (/patch/569488/ and /patch/569490/)
where the patch had unwanted line breaks -- sending this one using git
send-email.
The image name for the HiLink HLK-RM04 module has a typo and should read "RM04"
rather than "RM02"
Signe
Trying again, I see gmail mangled the previous message...
The image name for the HiLink HLK-RM04 module has a typo and should read
"RM04" rather than "RM02"
Signed-off-by: John Clark
---
target/linux/ramips/image/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 delet
The image name for the HiLink HLK-RM04 module has a typo and should read
"RM04" rather than "RM02"
Signed-off-by: John Clark
---
target/linux/ramips/image/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/ramips/image/Makefile
b/targe
On Mar 10, 2015, at 7:21 AM, valent.turko...@gmail.com wrote:
> Can anyone explain to me how NDAs come into this? Because I remember
> one discussions with Mikrotik developer who said that they can't
> release their Atheros driver that they developed as open source
> because they signed NDA with
On Mar 11, 2015, at 2:39 PM, Adam Kuklycz wrote:
> I think what everyone needs to just think and remember for a minute:
>
> * OpenWRT is built by the community and not by highly paid engineers
> * OpenWRT is often far more feature rich than stock firmwares written for
> the devices supported
On Mar 9, 2015, at 1:19 PM, Charlie Smurthwaite wrote:
> On 09/03/15 20:02, valent.turko...@gmail.com wrote:
>> Main issue is that wifi chip manufacturers don't offer open source
>> wifi drivers. If Atheros and Broadcom understood Open source as Intel
>> does then you would get absolutely top sp
use SHA512 for password hashing, rather than the simplistic MD5 that seems to
be the default.
John Clark.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Or is Atheros chips the only offering.
Thanks,
John Clark.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
.
Thanks,
John Clark.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
ave no idea why that is.
So, hence the posting to the OpenWRT list.
John Clark.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
g seems to
match for enabling the 2 cpus, when the kernel boots, the log indicates it is
bringing up the 2nd cpu, and immediately gets the machine check.
Is there some initialization that is not happening, such as invalidating cache,
clearing parity bits, or the like that needs to be done?
Or som
sh' to overcome this lack?
John Clark.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
the standard package list?
Thanks,
John Clark.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
d like to hear about it.
The byte endian problem I believe is a 'red herring', as it appears to be only
a cosmetic 'printout error', where the printout does not properly extract the
number using le16_to_cpu function.
John Clark.
On Oct 31, 2012, at 12:00 PM, Andreas Mohr wr
Has anyone used OpenWRT Linux 3.3.8 kernel, and the included FTDI serial port
interface driver with the Power PC.
I suspect there are byte swapping issues, and would like to know if anyone else
has 'used' the driver and 1) had no problem... or 2) had and fixed a problem.
Thanks
'libevent2' package, but I've not tried to
build a system with LLDPD installed.
John Clark.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
oblem of the support for the P1020 wlan itself, but just how to configure the
build configuration via the menus, or some 'hand work' to do this.
John Clark.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
ashlog_addr variable apparently is used
with an initialization of 0...
By deselecting 'crash log' kernel config option, that allowed the kernel to
boot to a command line prompt.
John Clark.
On Oct 16, 2012, at 11:03 AM, John Clark wrote:
>
> On Oct 15, 2012, a
On Oct 15, 2012, at 8:32 AM, Rainer 'Rei' Schuth wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi
>
> On 10/13/2012 12:21 AM, John Clark wrote:
>> I have been looking and eventually found some set of patches which I have
>> been using t
of patches are:
110-fix_mpc8548_cds.patch
100-fix_mpc8568e_mds.patch
Anyone have some information I'd appreciated it,
John Clark.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
ion' mode and associating with a OpenWRT AP.
Because I'm getting abysmal performance.
Running iPerf in UDP mode, frequently gives 10% packet loss at 10 mbs...
Theplatform I'm using is pretty close to the Atheros AP83 reference
design. I also have tested with a non-OpenWRT
station
up to 30-40 mbs with 'some loss'.
So, the question is, what has happened since last March with the linux
ath9k driver support?
John Clark.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailma
eries does not support this.
So, if anyone has some illuminating comments on this I'd like to hear
about it.
Well, I'm not interested in comments about why drop the bandwidth
down... because I obviously have
some applications that a narrower frequency bandwidth would be benef
Pat Erley schrieb:
On 03/30/10 12:31, John Clark wrote:
What is the reason for this limit? Is it because of a hardware issue, or
certain chip sets don't support more, or
just from an earlier time?
John Clark.
I believe (this is from a vague memory of a chat a while back) that
The symptom seems to be either 1) watchdog timer not being turned off,
or properly reenabled, or 2)
some interrupt is not turned off.
The process of doing a 'bootp' then a subsequent 'bootm' at the command
line works.
John Clark.
What is the reason for this limit? Is it because of a hardware issue, or
certain chip sets don't support more, or
just from an earlier time?
John Clark.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/ma
ot correctly utilize the "ARCH_SUFFIX", and creates an erroneous name.
If I have a chance I'll create a diff file for this.
--
Any information on the AP83 at the machine setup stage would be appreciated.
John Clark.
__
57 matches
Mail list logo
