Is the firmware 32 or 64 bit?

[ttc0419]

According to the output of ```uname -m``` on my ax6000, the kernel is aarch64. However, most of libs are in /lib, which are 32bit. The glibc in /lib64 is not even enough to build other applications that depend on glibc extensions like libresolve. So, what's the point of having a aarch64 environment? Is there a aarch64 only version of the firmware?

 

[RMerlin]

Is there a aarch64 only version of the firmware?

No.

 

[treeskygrass]

No.

 

[01tt01f]

armv8 has AES,wondering if Merlin is 32bit,then does Merlin make use of the AES in the SOC?

 

[Tech9]

AES instructions are used for OpenVPN encryption on both stock Asuswrt and Asuswrt-Merlin.

The reason routers with ARMv8 CPU are 2-3 times faster on OpenVPN compared to routers with ARMv7 CPU without AES.

 

[RMerlin]

armv8 has AES,wondering if Merlin is 32bit,then does Merlin make use of the AES in the SOC?

You can use the AES optimized operands even in 32-bit. I compile openssl with -march=armv8-a

 

[coxhaus]

I thought 32 bit is dying?

 

[L&LD]

32-bit is dead.

 

[RMerlin]

I thought 32 bit is dying?

The embedded market is not the same as the PC market. Different needs.

 

[Tech9]

Different needs and different profit margins. In this business every dollar counts. Moving to 64-bit will require more hardware, storage and memory. This means higher manufacturing costs. Higher development costs on top. The end result for this type of devices will be about the same to what we have now.

 

[RMerlin]

Different needs and different profit margins. In this business every dollar counts. Moving to 64-bit will require more hardware, storage and memory. This means higher manufacturing costs. Higher development costs on top. The end result for this type of devices will be about the same to what we have now.

Software compatibility as well. Moving to 64-bit isn't just a matter of flipping the compiler switch, some code need to be rewritten to support it. There are portions of the code that are close to 20 years old at this point, and were written back before mainstream CPUs started to support 64-bit.

I think I remember that in the early HND days, Asus had a few userspace components compiled as 64-bit. Strongswan was one of them (which meant the firmware had to contain both a 32-bit and a 64-bit version of the OpenSSL libraries). It was eventually all moved to 32-bit, however the kernel itself was kept at 64-bit, since that part was already fully compatible, and it _might_ provide small performance gains in networking or kernel-side crypto.

There isn't much to be gained by the userspace code to be moved to 64-bit. It would mostly increase memory usage, and end users would never really notice any performance difference, since about nothing in the firmware requires native handling of 64-bit integers, or the use of larger address space.

 

[Tech9]

Indeed. Trouble and expenses for nothing.

 

[L&LD]

There are portions of the code that are close to 20 years old at this point, and were written back before mainstream CPUs started to support 64-bit.

And that is the reason 32-bit is dead.

Many excuses/business reasons not to upgrade. Few real reasons for an actual long-term perspective.

 

[RMerlin]

Few real reasons for an actual long-term perspective.

Give one good practical reason to justify the effort to move it to 64-bit.

Aren't you the one always complaining about the cost of new routers? Rewriting Asuswrt to fully run 64-bit native would probably amount to many hundred thousand of dollars of additional development costs. Are you willing to see these routers get even more expensive to cover the increased development costs?

It's not happening, and it's perfectly fine.

 

[L&LD]

One reason? Longevity.

The one-time cost to implement isn't a factor. It will hardly make a dent over millions of units. Yes, I think the effort would be more than worth it.

They get more expensive either way. I want to see progress, at least.

 

[RMerlin]

One reason? Longevity.

If longevity is the goal, then my personal opinion is that Asuswrt needs a major rewrite, far more than just being adapted for 64-bit compatibility. Its current monolithic design is far more limiting than that than the fact it runs on a 32-bit architecture, as it tries to handle far too added features with no clear separation into individual services.

Rewriting only parts of it to make it compile with 64-bit userspace will not resolve any of the other issues that will limit its longevity much sooner. Things like the fact it doesn't support the SMB 3.x protocol yet will hit a wall long before the 32-bit userspace component will, since Broadcom won't drop 32-bit support with their embedded CPUs anytime soon. Just like Intel kept running 16-bit code well after they had added AMD64 support.

 

[L&LD]

I agree with the ground-up rewrite. Beginning with everything being moved to 64-bit too, of course.

It's well past its due date to do so.

 

[RMerlin]

I agree with the ground-up rewrite. Beginning with everything being moved to 64-bit too, of course.

Does the Broadcom SDK even support 64-bit userspace?

 

[L&LD]

Then something like the Intel N100 or better should be used, if Broadcom's SDK doesn't (I don't know nor care if it does, I care about the complete/final package, not just the mere 'specs').

But Asus will keep pushing what is being bought.

 

[RMerlin]

Then something like the Intel N100 or better should be used, if Broadcom's SDK doesn't (I don't know nor care if it does, I care about the complete/final package, not just the mere 'specs').

But Asus will keep pushing what is being bought.

The Intel N100 is just a CPU. That`s lacking the wifi and network switch required for a full router. And your product BoM just went up significantly versus an embedded SoC, and throughput probably went down as well due to the lack of any traffic accelerator that Qualcomm and Broadcom include in their SoC, which is what allows them to route and NAT traffic well over 5-6 Gbps.