@JW0914
A link to show the basics [1] and for details consult denx [2] and the output of fw_printenv on your device

[1] https://www.cyrius.com/debian/kirkwood/ … t-upgrade/
[2] http://www.denx.de/wiki/DULG/Manual

@sera
Thanks! =]

I have no issues using my USB-TTL on the wrt1900ac v1.

What type of USB-TTL cable do you have?  If you have a non-AJ cable, what pitch are your header pins?

Kernel 4.4.11 bombs at 271-uapi-libc-compat.h-do-not-reply-on_GLIBC_.patch

I don't have cycles to dig into it until later in the day...  Hoping someone has a quick fix

Cheers

@doITright

There's no quick fix, that patch needs to be reworked or eliminated.

nitroshift

@nitroshift
I meant to ask before... Do you have firmware builds you'd like me to list under Community Builds in the Wiki?

Thanks for the feedback JW.

I don't think it's the cable because it worked fine on both the 1900 and 1200 for months and just started this recently ONLY on the 1900v1.  Will do some more testing...

Well that sucks...  Everything was just fine on 4.4.10

I am no expert with this stuff so I can't make the call on if it is required
But I can put in the time to re work it if you or someone else can make that call...

Thoughts?

Cheers

It sounds like something circuit related on the board of the v1.  If you're able to find a schematic for the serial port on the board, you could do continuity testing with a multimeter, as well as resistance [ohmage] testing if the schematic lists the volts/amps/ohms.  As if the cable can be ruled out, the only thing it could be would be the serial header on the board

(Last edited by JW0914 on 20 May 2016, 15:51)

That is what I thought until I realized it works fine before loading the OS at preboot Marvel prompt.

and just fyi here are some images of my setup.

Header:

Jack on back of router

Header to Jack inside

Cable

That is quite odd... I'd recommend the following:

• If you soldered anything, redo the soldering
  

  • A bad solder joint would result in an inconsistently closed circuit, or can cause high resistance, thereby degrading the signal (especially on electronics, as, normally, most circuits carry multi-value volts, amps, and ohmage at the same time, with each combination of values meaning something different, i.e. multiplexing)

  • You may already know this:
    

    • A good solder joint will always be shiny once cool; if' it's dull, redo

    • Soldering iron tip should be pre-tinned and applied directly to what's being soldered, with the solder melting via contact with the joint, not the soldering iron.

• If you didn't solder anything, or did and joints are good:
  

  • Get ~6 cotton swabs & some isopropyl alcohol

  • Clean the 3 terminals on the header

  • Clean the inside walls of the 3 pins that are plugged into the header
    

    • Submerge the pins in alcohol for ~5s, then agitate each pin while it's in the alcohol for ~10s (this should breakdown/dislodged any foreign particles)

  • Do the same for the 3.5mm jack terminals (interior & exterior contact surfaces) and it's pins.

The most likely issue is one of the two, or both, above... especially with what you're describing.  Electrical circuits either work or they don't, and if they work sometimes, but not others, it's rarely the PCB.

(Last edited by JW0914 on 20 May 2016, 16:52)

I'm on it, it's not a big rework

Edit: I honestly think this patch can be deleted <- [Edit 3: NOPE Bad Idea], the only thing that's isn't changed is:

@@ -48,8 +48,8 @@
 #ifndef _UAPI_LIBC_COMPAT_H
 #define _UAPI_LIBC_COMPAT_H

-/* We have included glibc headers... */
-#if defined(__GLIBC__)
+/* We have included libc headers... */
+#if !defined(__KERNEL__)

 /* Coordinate with glibc net/if.h header. */
 #if defined(_NET_IF_H)

But if you want to keep it with my corrections, apply this patch with patch -p1 < patchfile at the root of your cloned git repo.

Don't look at the syntaxic colouration, those are patches for patches

Edit 2:
Wait a little, got another one

Applying /home/openwrt/trunk-private/target/linux/generic/patches-4.4/272-uapi-if_ether.h-prevent-redefinition-of-struct-ethhd.patch using plaintext:
patching file include/uapi/linux/if_ether.h
patching file include/uapi/linux/libc-compat.h
Hunk #1 FAILED at 51.

@kirkgbr

Damn, this looks so good, mine isn't that neat

(Last edited by mrfrezee on 20 May 2016, 18:06)

The wifi firmware is only listed there because it is in such a state of flux right now.

If they had given us working code, we wouldn't be jumping on every update that they post hoping that it gets things right this time :-(

So for now, it's needed. Eventually it should stabilize (and become part of the upstream kernel) and can be dropped

re: firmware.img names. I've tripped over too many bugs on different routers at different times with using non-standard names. It's just a good idea to always flash from a file named firmware.img. Since I run Linux to do the flashing, I create a symlink that points at the file I'm actually flashing. Mac users can do the same thing.

While these routers may have options to use non-standard firmware, it's best to train people to do the thing that works on every device.

Thanks for the info about the wifi drivers =]

All 4 models have OEM default firmware names, so as long as the image name matches the OEM default name, there should never be an issue

OEM Default FW Names

• WRT1200AC v1
  

  • caiman.img

• WRT1900AC v1
  

  • blk-mamba.128mb.img

• WRT1900AC v2 and WRT1900ACS v1
  

  • cobra.img

(Last edited by JW0914 on 20 May 2016, 17:22)

Thanks, lots of planning upfront and fortunately i had a spare router to use while modding the primary.

@JW0914 and nitroshift

Just fyi, I just compiled a recent trunk version, threw it on my mamba and now my USB console works fine.

@kirkgbr

Only nitroshift's image had this problem. Last night as I reflashed my router with my own image the console came back up and worked fine.

(Last edited by lifehacksback on 20 May 2016, 18:15)

Thanks for the confirmation.  Exactly my thoughts but didn't wanna point fingers. 

I think it is because nitro is using bash shell for netdata. Maybe not, i'm not sure, since ssh works fine.

@mrfrezee

Yup...  fails on 272 after removing 271

Cheers

EDIT: Trying with both 271 and 272 removed now

(Last edited by doITright on 20 May 2016, 19:40)

*Incoming pun*
I don't think that is how you doitright. You probably have to refactor the code to patch cleanly against the kernel unless it has already been upstreamed.

On a side note:

Here you can find 2 images both with kernel 4.4.10 (4.4.11 on the works), BM patch (Thank you @nitroshift and others), marvell_cesa hw offload.

What is different is the wireless driver it uses, one will have a "20160520-1"(NEW) and the other will be "20160520" (NOTASNEWBUTSTILLPRETTYNEW)

http://tinyurl.com/Lifehacksback-Testing-CC

(Last edited by lifehacksback on 20 May 2016, 19:56)

Do you by chance know what was causing this to occur?

In my build had with that wifi driver some 5 seconds hangs every now and then. About 10% pings to router were timed out.
"20160520-1"(NEW) driver is now working fine for 8 hours.

(Last edited by Bogey on 20 May 2016, 20:05)

@lifehacksback

sometimes we have to bend the rules a bit

don't have time to fix the patch until later tonight and will not use this build even if it finishes with no further errors

EDIT: The build finished fine with those patches removed -> 4.4.11 + new mwlwifi driver

Cheers

(Last edited by doITright on 20 May 2016, 20:46)

@doITright

Just an FYI that there is no need to do the work yourself.  The fork of OpenWRT that is actively maintained has been converted to kernel 4.4.11.  Available on git for all.

No real word from OpenWRT developers in weeks, no commits in over a week.  Shortly I'm going to stop backporting patches from said repository and just convert.

Been there, done that.

I will check it out...  which fork is it (must have missed that info on this thread)?

Cheers