Currently I receive rustc crashes after memory usage get to 3GB (1GB RAM + 2GB SWAP) when building firefox. After looking around why, I found that kernel isn't build with lpae extension.

Although H3 soc supports lpae (Large Physical Address Extension), but kernel has CONFIG_ARM_LPAE flag not set and so we can't use more than 3GB of memory (1GB is reserved for kernel).

(Processors that implement the ARMv7-A Large Physical Address Extension (LPAE), expand the range of accessible physical addresses from 4GB (232 bytes) to 1024GB (240 bytes) a terabyte, by translating 32-bit virtual memory addresses into 40-bit physical memory addresses.)

 

After looking around I found that there isn't any armbian release where this flag is enabled, but other distros have this correctly enabled by default,

debian https://wiki.debian.org/DebianKernel/ARMMP

openwrt

 

I also wonder if used build options are generic or did they make use of CPU extensions. H3 also supports VFPv4 or VFPv4-D32
for H3 example:  -march=armv7ve -mtune=cortex-a7 -mfloat-abi=hard -mfpu=neon-vfpv4

 

my output from
cat /proc/cpuinfo
 

orangepi-PC
    processor       : 3
    model name      : ARMv7 Processor rev 5 (v7l)
    BogoMIPS        : 65.14
    Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
    CPU implementer : 0x41
    CPU architecture: 7
    CPU variant     : 0x0
    CPU part        : 0xc07
    CPU revision    : 5

 

 

 

 

With LPAE enabled, the kernel would be able to work with an overall pool of RAM+SWAP greater than the 32-bit barrier; however, each individual running process would still only have a 32-bit virtual address space and so its slice of the overall pie would still be limited.

 

Are you certain that it's even possible to compile Firefox in an environment where each individual process cannot grow beyond the bounds of a 32-bit virtual address space? In the official Firefox development docs, the only documented workflow for compiling a 32-bit Linux target specifies that it should be cross-compiled from a 64-bit host.

Apologies for being late to the party, and please excuse me for commenting on something which may already have been fixed.

 

What is the difference between enabling the flag, and allowing whatever apps to work if they can, and disabling it so they certainly can't work? Seems to me that enabling it would make most sense, since H3 SOCs support it.

this can easily be answered with a quick web search or AI request for "disadvantage of LPAE on armhf".  As expected, one of the drawbacks is increased use of memory when the benefit of larger addressable memory applies only to few installations and in a limited way.