What's new

RT-AC68U V3 Merlin Supported?

  • 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!

It still shows as an RT-AC68U, which would be why there's no special odmpid for it. It's just a newer hardware revision.
But I've never seen in not fill in something for odmpid in nvram....it's used in many other places.
 
But I've never seen in not fill in something for odmpid in nvram....it's used in many other places.

My disassembly of the code indicates Asus calls both nvram_match() and nvram_get_int() inside is_ac68u_v3_series() however I'm not skilled enough with objdump to have the strings referred inline, so I don't know what are the two variables it checks there. Based on what I see referred there, I think they might be checking the PA. How about this?

Code:
nvram get PA

Because I see one of the values they check is for the value 8527 inside that function.

Code:
     9d8:    ebfffffe     bl    0 <nvram_get_int>
     9dc:    e302314f     movw    r3, #8527    ; 0x214f
     9e0:    e1500003     cmp    r0, r3
     9e4:    13a00000     movne    r0, #0
     9e8:    03a00001     moveq    r0, #1

So if that nvram_get_int returns 8527, the function returns 1 (is a V3), if not, it returns 0 (is NOT a V3).
 
nvram get PA outputs on mine

Code:
joao@RT-AC68U-AE08:/tmp/home/root# nvram get PA
8527

There's the answer then to detecting V3. PA will be set to 8527 on the V3 revision. Different PA probably means you also need an updated SDK to support that model. The previous nvram_match() check is quite possibly on modelid.
 
There's the answer then to detecting V3. PA will be set to 8527 on the V3 revision.
Looking at the code, it looks like they took an AC66U_B1 and updated the PA to make the 68U V3. Not sure I need an updated SDK, but at a minimum do need updated wireless drivers. Unfortunately, the new wireless drivers break at least the method used to get the wireless connect data. Right now I think the V3 probably is not going to be supported on my fork.
 
Not sure I need an updated SDK, but at a minimum do need updated wireless drivers.

That`s what I meant, since the driver is part of the SDK.
 
Right now I think the V3 probably is not going to be supported on my fork.
Well...I had to dig a little further :)

Got the new driver working on my fork and have a development build that should support the V3. There may be some led's that need tweaking, but will need an actual tester to verify (sorting through all those gpio settings gives me a headache)
 
Well...I had to dig a little further :)

Got the new driver working on my fork and have a development build that should support the V3. There may be some led's that need tweaking, but will need an actual tester to verify (sorting through all those gpio settings gives me a headache)
Can you share on of your test builds? :)
 
Well...I had to dig a little further :)

Got the new driver working on my fork and have a development build that should support the V3. There may be some led's that need tweaking, but will need an actual tester to verify (sorting through all those gpio settings gives me a headache)
Imma test this out on my version 3 in a bit. I will given you feeds back. Great work john.
 
Imma test this out on my version 3 in a bit. I will given you feeds back. Great work john.
It's not up yet.....it's a 47D1 build.....I'll make a separate thread when it's up.

Didn't want to put it up until I had some runtime on my non-V3 router.
Also, while I don't expect any major problems, the first folks to try it should be prepared to possibly have to recover the previous code via mini-web server or restoration tool.
 

Latest threads

Sign Up For SNBForums Daily Digest

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