This patch adds support for routers using a PCB marked XDX-RN502J
V2.0, such as some unbranded routers like this:
http://www.mediafire.com/?8acv87h6snn9fj6
http://www.mediafire.com/?do7xonw7scor4kn
http://www.mediafire.com/?1ad49zvx3e7jyix
http://www.mediafire.com/?i46cqiq66maa197
http://www.alie
That router is made by Win-star I believe, its sold to anyone and everyone.
On Sat, Feb 25, 2012 at 7:44 PM, bruno schwander wrote:
> This patch adds support for routers using a PCB marked XDX-RN502J
> V2.0, such as some unbranded routers like this:
>
> http://www.mediafire.com/?8acv87h6snn9fj6
>
Hi Tathagata Das,
I had a look at bthe patch and added some comments, if bcma_nflash_init
is not needed any more where is struct bcma_nflash initilized?
Hauke
On 02/23/2012 02:27 PM, Tathagata Das wrote:
> Hi,
> Attached is the updated kernel patch to support brcm47xx BCMA NAND flash. I
> hav
hi peter!
i see, which means you use gpio pins "J33" of rspro, right?
And i saw your other email about asking of luci interface.
http://luci.subsignal.org/trac
here is toppage of luci and there is informations
which describe how to create luci-pages and luci API.
If you have more question about l
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 from to linux ... [e]MTD do_erase_oneblock():
so
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 f
-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 forever in case of a really
fatal issue, like when the im
Does anyone else have any thoughts into this? Other suggestions I can
try? Seems someone else is seeing the same issue as I've found the
following output sitting on pastebin:
http://pastebin.com/djNfNa3t
These errors match the errors I'm seeing on my system exactly.
I've since reverted to tru
> 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.
on our boxes we remove all (!) running
programs and unload all (!) kernel-modules
before invok
> It also means that sysupgrade would loop forever in case of a
> really
> fatal issue, like when the image is too large for the given mtd
> partition.
maybe we should limit the loop to X times?
> I'd say the mtd util should perform 3-5 consecutive tries in case
> of a
> block erase problem and t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> maybe we should limit the loop to X times?
That would still mean needlessly rewriting good blocks X times.
Your loop approaches the problem several layers too high.
~ Jow
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Us
> That would still mean needlessly rewriting good blocks X times.
> Your loop approaches the problem several layers too high.
you are right.
so "just" the error-handling within the
sysupgrade-script. fire telnet + landev?
(because reboot = dead/brick)
bye, bastian
___
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> so "just" the error-handling within the
> sysupgrade-script. fire telnet + landev?
Yes, that'd be a good solution - plus maybe netmsg to send the usual UDP
broadcast stating that something is broken.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4
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
> My machine too has significant free memory, but I suspect
> the memory relates to some kernel memory issues, rather
> than megabytes of free user space memory.
>
> Chill. And I recommend use of your shift key ;-)
Thanks for your feedback. I'am fine with shift 8-)
and just misunderstood you...
Signed-off-by: Galen Seitz
Signed-off-by: Russell Senior
---
net/ddns-scripts/files/usr/lib/ddns/services |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/net/ddns-scripts/files/usr/lib/ddns/services
b/net/ddns-scripts/files/usr/lib/ddns/services
index 82461d2..1e6b6
A couple of other things to try. I build with:
CONFIG_USE_EGLIBC=y
CONFIG_EGLIBC_VERSION_2_13=y
and I use the default gcc.
On 2/25/12 10:48 AM, Adam Gensler wrote:
> Does anyone else have any thoughts into this? Other suggestions I can
> try? Seems someone else is seeing the same issue as I'v
On Fri, Feb 24, 2012 at 11:25 AM, Christian Gagneraud
wrote:
> Hi there,
>
> I'm currently trying to add a new device (based on a ATSAM9G20), and during
> development I would like to boot it on a NFS root.
> Unfortunately I noticed that a couple of firstboot/preinit/init scripts are
> messing up
18 matches
Mail list logo
