Hi,
Attached is the updated kernel patch to support brcm47xx BCMA NAND flash.
I have used latest trunk source code to create this patch. I have tested it on
Netgear WNR3500Lv2.
Thanks to Florian and Hauke for their comments.
Regards,
Tathagata
9991-bcm47xx-bcma-nandflash.patch
Description:
This enables support for ECDSA keys in openssl and since it is supported
in openSSH since version 5.7 ECDSA keys can be then used by
openssh-{server,keygen,client} and are automaticaly generated on sshd start.
- tested to be working on routerstation PRO with trunk r30744
Signed-off-by: Ondrej
On 2/27/12 9:55 PM, Adam Gensler wrote:
> Good idea, see inline:
>
> On 2/27/12 11:14 PM, Philip Prindeville wrote:
>> Two questions:
>>
>> If you keep 29981 (and above) and set LINUX_VERSION back to 2.6.39.4 what
>> happens?
>
> [adam] Works fine, 29981 with kernel 2.6.39.4 on the alix2 target
Good idea, see inline:
On 2/27/12 11:14 PM, Philip Prindeville wrote:
Two questions:
If you keep 29981 (and above) and set LINUX_VERSION back to 2.6.39.4 what
happens?
[adam] Works fine, 29981 with kernel 2.6.39.4 on the alix2 target boots
without traces in dmesg.
If you build a x86/gen
Two questions:
If you keep 29981 (and above) and set LINUX_VERSION back to 2.6.39.4 what
happens?
If you build a x86/generic kernel with LINUX_VERSION=3.2.2 what happens?
On 2/27/12 9:01 PM, Adam Gensler wrote:
> Confirmed, this issue first appears when the kernel was bumped to 3.2.1
> in thi
You should be able to get a stack trace with gdb and the unstripped kernel, or
else just do it by hand with:
.tmp_System.map
in your build_dir/linux-x86_alix2/linux-3.2.2/ directory.
Maybe someone else like Felix or Jo-Philipp can give better suggestions?
-Philip
On 2/27/12 5:53 PM, Adam Gen
Confirmed, this issue first appears when the kernel was bumped to 3.2.1
in this change set:
https://dev.openwrt.org/changeset/29981/trunk
29980, which still uses 2.6.39.4 works fine. 29981, which moves to 3.2.1
has the previously mentioned traces in dmesg on boot up.
On 2/27/12 7:53 PM, Adam
On Mon, Feb 27, 2012 at 5:04 PM, Russell Senior
wrote:
> I build from trunk. I selected (=y) it from menuconfig under kernel
> and wireless. You can search in menuconfig with '/'.
Ah, I have a /etc/config/wireless file now and the radio is finally
doing something! Thanks guys for pointing me i
By symbolic addresses you mean building it with the symbol table?
CONFIG_KERNEL_KALLSYMS=y
Doing so corrects the problem, making it impossible to debug. If you
mean something else please let me know and I'll be happy to try it.
Being stuck on pre-3 revisions in trunk on the x86 alix2 targe
> "Brian" == Brian Hutchinson writes:
Brian> So if I want immediate relief from this, I should drop back to
Brian> Backfire and turn on madwifi in makemenuconfig?
>> Except for the recently 'gain calibration timeout' problem which
>> recently I helped bisect and which nbd fixed, ath5k has b
On Mon, Feb 27, 2012 at 4:19 PM, Russell Senior
wrote:
>> "Brian" == Brian Hutchinson writes:
>
> Brian> So if I want immediate relief from this, I should drop back to
> Brian> Backfire and turn on madwifi in makemenuconfig?
>
> Except for the recently 'gain calibration timeout' problem which
> "Brian" == Brian Hutchinson writes:
Brian> So if I want immediate relief from this, I should drop back to
Brian> Backfire and turn on madwifi in makemenuconfig?
Except for the recently 'gain calibration timeout' problem which
recently I helped bisect and which nbd fixed, ath5k has been wor
On Mon, Feb 27, 2012 at 4:12 PM, Jonathan Bither wrote:
> If you wanted immediate relief you could also just select the right driver
> for your card ;-). Ath5k is the replacement for Madwifi. By selecting ath5k
> in trunk your radios should operate fine.
I thought that as I looked at the loaded m
If you wanted immediate relief you could also just select the right
driver for your card ;-). Ath5k is the replacement for Madwifi. By
selecting ath5k in trunk your radios should operate fine.
On 02/27/2012 04:08 PM, Brian Hutchinson wrote:
So if I want immediate relief from this, I should dr
So if I want immediate relief from this, I should drop back to
Backfire and turn on madwifi in makemenuconfig?
About the only Atheros boxes I have to test with are these two RB411's
(one with regular R52 radio and one with the high power version of the
R52 radio) and a Buffalo WZR-HP-G300NH (which
You can follow the recent changes and discussions here on the developer list.
The main issue seems to be how iwinfo does not recognise the physical
limitations of the wifi equipment. Everything is 27dBm (possibly from
CRDA database?) although in reality it is anywhere between 20dBm and
30dBm depen
Hanno,
Do we happen to have a list of known issues so that we can work on
getting them resolved instead of reverting back to mac80211?
On 02/27/2012 03:15 PM, Hanno Schupp wrote:
I am not a developer, but I can tell you the ath9k is for b/g/n cards,
so that may be the reason. You should use ei
I am not a developer, but I can tell you the ath9k is for b/g/n cards,
so that may be the reason. You should use either ath5k or madwifi
driver. Personally I found many issues with ath5k integration into
openwrt still unresolved in terms of card and device recognition and
am consequently in the pro
Hi,
These boxes use to be working but I recently upgraded them to the
latest trunk and now my wireless cards are no longer detected.
No /etc/config/wireless and trying to generate the file with wifi
detect does nothing. Not sure what is going on since everything looks
OK.
lsmod output is at the
Al 27/02/12 18:45, En/na Robert Ryan ha escrit:
> I've been looking around for the right place to patch this but I'm having
> difficulty finding a similar file that's not lantiq-specific. Can anyone
> point me in the right direction? I've looked in the entire
> target/linux/ramips/rt305x and arc
This package provides a replacement channel driver for asterisk's
chan_skinny. With extended functionality and feature support (shared
lines, realtime config, custom device state and more)
More informatin on http://chan-sccp-b.sourceforge.net and
http://sourceforge.net/projects/chan-sccp-b.
I've been looking around for the right place to patch this but I'm having
difficulty finding a similar file that's not lantiq-specific. Can anyone
point me in the right direction? I've looked in the entire
target/linux/ramips/rt305x and arch/mips/include/asm/mach-ralink but can't
find anything
On
Hello,
> > >> It would be make life easier if there is the possibility to flash
> > >> directly from dd-wrt webif.
> > >
> > > most likely true... i will investigate how to do so
> > DD-Wrt normally awaits a TRX flash image (HDR0 header) with the
> > "noheader" flag set.
> > See https://foru
Hi,
Le 02/25/12 17:56, Jo-Philipp Wich a écrit :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi.
I think it should be handled in mtd, rewriting the complete image only
because a single block had a transient erase problem is a bit excessive imo.
It also means that sysupgrade would loop forev
Hi Hauke,
I have modified my patch according to your comments except in two cases.
"We want to build one image supporting devices with serial and with nand flash.
This makes it just possible to support one flash type at a time."
Right now flash type can be either NAND or SERIAL. If we want to ha
25 matches
Mail list logo
