What's new

Unofficial Build 380.58

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Isn't 380_1355 available for the AC-5300?

There's most likely almost no difference between 1354 and 1355 - not worth the trouble of merging. Point was there's no GPL for the 1574 release someone mentioned (or any newer release).
 
Can one assume this firmware is safe to run unlike the HGGomes firmwares that had so many people up in arms ?
 
Can one assume this firmware is safe to run unlike the HGGomes firmwares that had so many people up in arms ?

I don't see any effective difference?

With no offence meant to jacabrera or hggomes, we end users are simply taking their word for what is provided.
 
I remember merlin saying earlier that the rtn66u is not stable with the 58 build. anything new make it better? anybody using the newest builds on a rtn66u? i'm currently running the latest 380.57.
 
I remember merlin saying earlier that the rtn66u is not stable with the 58 build. anything new make it better? anybody using the newest builds on a rtn66u? i'm currently running the latest 380.57.

I am and I don't see any issue. It seems fine on my end with my casual usage. Many of the features I don't make use of so I can't really comment but from the WAN point of view, things seem fine.
 
I remember merlin saying earlier that the rtn66u is not stable with the 58 build. anything new make it better? anybody using the newest builds on a rtn66u? i'm currently running the latest 380.57.

I didn't say it wasn't stable, just that it wasn't confirmed as stable - only the RT-AC88/AC3100/AC5300 have been confirmed as such. All other models are relying on out-of-sync binary blobs, so I cannot guarantee that they are fully compatible with the newer GPL code.
 
I am and I don't see any issue. It seems fine on my end with my casual usage. Many of the features I don't make use of so I can't really comment but from the WAN point of view, things seem fine.


K sounds good. Thanks for the info. And thanks as well merlin. Thanks for clearing that up. My mistake. Hope you get better soon.
 
Interesting observation using Alpha 2 on an AC88U.

I don't recall seeing this Bad eraseblock message in older firmwares:

Jul 31 20:00:18 kernel: Northstar brcmnand NAND Flash Controller driver, Version
Jul 31 20:00:18 kernel: NAND device: Manufacturer ID: 0xc8, Chip ID: 0xd1 (Unkno
Jul 31 20:00:18 kernel: Spare area=64 eccbytes 56, ecc bytes located at:
Jul 31 20:00:18 kernel: 2 3 4 5 6 7 8 9 10 11 12 13 14 15 18 19 20 21 22 23 24
Jul 31 20:00:18 kernel: Available 7 bytes at (off,len):
Jul 31 20:00:18 kernel: (1,1) (16,2) (32,2) (48,2) (0,0) (0,0) (0,0) (0,0)
Jul 31 20:00:18 kernel: Scanning device for bad blocks
Jul 31 20:00:18 kernel: Bad eraseblock 220 at 0x000001b80000
Jul 31 20:00:18 kernel: Bad eraseblock 233 at 0x000001d20000
Jul 31 20:00:18 kernel: Bad eraseblock 690 at 0x000005640000
Jul 31 20:00:18 kernel: Bad eraseblock 989 at 0x000007ba0000
Jul 31 20:00:18 kernel: Options: NO_AUTOINCR,NO_READRDY,
Jul 31 20:00:18 kernel: Creating 1 MTD partitions on "brcmnand":
Jul 31 20:00:18 kernel: 0x000004000000-0x000008000000 : "brcmnand"

Does the new Broadcom SDK have a new NAND driver? Or, is my NAND having problems?

Some good information :)
http://wiki.openmoko.org/wiki/NAND_bad_blocks
 
Works good on my 87U, I just have one problem, I also have a AC66U, in repeater mode running alpha2 and it wants to reboot itself about every 10 mins. But it does this only in the repeater mode, if I run the 66U just default mode, everything works the way it should. Did some testing and it will reboot itself when I run only the 380.57 in repeater mode... Once I downgraded back to 378.56_2 everything worked the way it should(in repeater mode) I tried Hgghomes firmware, just to see, and Yes it does the same .. Yes I have cleared the Vram, factory reset, done it all to make sure I had a clean start
 
Interesting observation using Alpha 2 on an AC88U.

I don't recall seeing this Bad eraseblock message in older firmwares:

Jul 31 20:00:18 kernel: Northstar brcmnand NAND Flash Controller driver, Version
Jul 31 20:00:18 kernel: NAND device: Manufacturer ID: 0xc8, Chip ID: 0xd1 (Unkno
Jul 31 20:00:18 kernel: Spare area=64 eccbytes 56, ecc bytes located at:
Jul 31 20:00:18 kernel: 2 3 4 5 6 7 8 9 10 11 12 13 14 15 18 19 20 21 22 23 24
Jul 31 20:00:18 kernel: Available 7 bytes at (off,len):
Jul 31 20:00:18 kernel: (1,1) (16,2) (32,2) (48,2) (0,0) (0,0) (0,0) (0,0)
Jul 31 20:00:18 kernel: Scanning device for bad blocks
Jul 31 20:00:18 kernel: Bad eraseblock 220 at 0x000001b80000
Jul 31 20:00:18 kernel: Bad eraseblock 233 at 0x000001d20000
Jul 31 20:00:18 kernel: Bad eraseblock 690 at 0x000005640000
Jul 31 20:00:18 kernel: Bad eraseblock 989 at 0x000007ba0000
Jul 31 20:00:18 kernel: Options: NO_AUTOINCR,NO_READRDY,
Jul 31 20:00:18 kernel: Creating 1 MTD partitions on "brcmnand":
Jul 31 20:00:18 kernel: 0x000004000000-0x000008000000 : "brcmnand"

Does the new Broadcom SDK have a new NAND driver? Or, is my NAND having problems?
Hello, im also having same issue after flashing alpha2 on my new RT-AC88U, i still can send it back to vendor to get a new one unit... should i?

Aug 1 02:00:15 kernel: Northstar brcmnand NAND Flash Controller driver, Version 0.1 (c) Broadcom Inc. 2012
Aug 1 02:00:15 kernel: NAND device: Manufacturer ID: 0xc8, Chip ID: 0xd1 (Unknown NAND 128MiB 3,3V 8-bit)
Aug 1 02:00:15 kernel: Spare area=64 eccbytes 56, ecc bytes located at:
Aug 1 02:00:15 kernel: 2 3 4 5 6 7 8 9 10 11 12 13 14 15 18 19 20 21 22 23 24 25 26 27 28 29 30 31 34 35 36 37 38 39 40 41 42 43 44 45 46 47 50 51 52 53 54 55 56 57 58 59 60 61 62 63
Aug 1 02:00:15 kernel: Available 7 bytes at (off,len):
Aug 1 02:00:15 kernel: (1,1) (16,2) (32,2) (48,2) (0,0) (0,0) (0,0) (0,0)
Aug 1 02:00:15 kernel: Scanning device for bad blocks
Aug 1 02:00:15 kernel: Bad eraseblock 763 at 0x000005f60000
Aug 1 02:00:15 kernel: Options: NO_AUTOINCR,NO_READRDY,
Aug 1 02:00:15 kernel: Creating 1 MTD partitions on "brcmnand":
Aug 1 02:00:15 kernel: 0x000004000000-0x000008000000 : "brcmnand"
 
I have my AC68 since 2 years , and maybe flashed 100 hundred times.I see this everytime "Bad eraseblock 00007898". No need to panic :)
Its seems to be normal for a Nand chip
 
Hello, im also having same issue after flashing alpha2 on my new RT-AC88U, i still can send it back to vendor to get a new one unit... should i?

Aug 1 02:00:15 kernel: Northstar brcmnand NAND Flash Controller driver, Version 0.1 (c) Broadcom Inc. 2012
Aug 1 02:00:15 kernel: NAND device: Manufacturer ID: 0xc8, Chip ID: 0xd1 (Unknown NAND 128MiB 3,3V 8-bit)
Aug 1 02:00:15 kernel: Spare area=64 eccbytes 56, ecc bytes located at:
Aug 1 02:00:15 kernel: 2 3 4 5 6 7 8 9 10 11 12 13 14 15 18 19 20 21 22 23 24 25 26 27 28 29 30 31 34 35 36 37 38 39 40 41 42 43 44 45 46 47 50 51 52 53 54 55 56 57 58 59 60 61 62 63
Aug 1 02:00:15 kernel: Available 7 bytes at (off,len):
Aug 1 02:00:15 kernel: (1,1) (16,2) (32,2) (48,2) (0,0) (0,0) (0,0) (0,0)
Aug 1 02:00:15 kernel: Scanning device for bad blocks
Aug 1 02:00:15 kernel: Bad eraseblock 763 at 0x000005f60000
Aug 1 02:00:15 kernel: Options: NO_AUTOINCR,NO_READRDY,
Aug 1 02:00:15 kernel: Creating 1 MTD partitions on "brcmnand":
Aug 1 02:00:15 kernel: 0x000004000000-0x000008000000 : "brcmnand"

Some good information :)
http://wiki.openmoko.org/wiki/NAND_bad_blocks
 
I dont understand it... can you explain for noobish like me? :$

Well, from what I have been reading. It's quite normally the NAND flash/memory gets shipped with blocks that are already bad.
Even during normal erase/write cycles, some bad blocks may develop. Nothing to worry about :)
 
I am Sad Merlin is away, hope he get well soom, I am also sic in the last months, but here here all day's.

And I have to thank jacabera very much for is effort, thanks jacabera, My 5300 working very well.
I hope that all those who have been quick to criticize this project stand up and take notice of the recent turn of events. This project is one heartbeat away from being stopped in its tracks, frozen in time as it were with little, if any, hope of resumption. I miss Eric's presence greatly as do many others but life is always more important.

And a special thanks to jacabera without whose efforts, we AC87x users would be stranded. Merlin is the saving grace for this platform and without him, and now jacabera, I probably would have had to upgrade to something else.

Eric rest up & get well soon my friend. I will keep your swift and speedy recovery in my prayers. :(
 
I hope that all those who have been quick to criticize this project stand up and take notice of the recent turn of events. This project is one heartbeat away from being stopped in its tracks, frozen in time as it were with little, if any, hope of resumption. I miss Eric's presence greatly as do many others but life is always more important.

And a special thanks to jacabera without whose efforts, we AC87x users would be stranded. Merlin is the saving grace for this platform and without him, and now jacabera, I probably would have had to upgrade to something else.

Eric rest up & get well soon my friend. I will keep your swift and speedy recovery in my prayers. :(

100% +1
Thanks to both for all their efforts!
I greatly appreciate it as do many others.

To think I started to consider going back to stock! Wow too close
 

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top