At present, at least the GL-AR300M and GL-AR750S are partitioned for 2 MB kernels. This will soon not be sufficient as ath79-nand kernels are already at close to 2,000,000 bytes.
The GL-AR750S U-Boot source is not up to date (it does not have any commits that resolve the ARP issue of late last year), which leads me question the GL-AR300M source as well. As a result, I cannot accurately determine if the supplied U-Boot can load and boot a 4 MB kernel.
Would you be able to make a definitive statement on if the U-Boot for the GL-AR750S and that for the GL-AR300M can reliably load and boot a 4 MB kernel?
Edit:
Also, is there a technical reason why the GL-AR750S U-Boot was not configured to be able to boot a NAND-resident kernel?
That might be a wee bit ugly for ath79-nand targets… one time item for older targets moving to ath79, and there a moment of agony vs a lifetime of ache, perhaps
I’ve been very focused on nor with ar150 on ar71xx, but if I were to port changes over to ar300m ath79, I would already be over the 2MB limit and be in trouble.
The ar750s uboot is probably another topic to avoid the multi-bug syndrome.
The sysupgrade part looks robust for the all-NOR and all-NAND cases. It’s ugly for the kernel on NOR and file system on NAND cases.
The AR750S U-Boot source shows a compiled-in limit of 2 MB for the kernel for upload through U-Boot in a couple places. The AR300M doesn’t have a similar limitation that I could find (likely as it doesn’t split the firmware to flash it).
I have yet to determine if the kernel loader will handle in excess of 2 MB for either device. What I see in the public U-Boot sources doesn’t seem to agree with what I see on the serial console. (I am not a U-Boot expert, so I may be mistaken.)
Yep, it’s the split boot targets that might take a hit - that’s why I mentioned “wee-bit ugly”
I’ve got a AR300m sitting on the shelf, might have to bring it online to check out, but I’m thinking the gl-inet devs can check, and it’s their choice whether to migrate to ath79 or not, as they can still support the branch they’re on.
I suspect that ar300m, and the ar750s, they’re in maintenance mode, as shipping code is in place for the 3.x releases on the openwrt branch they’re on.
Thank you for your information, we will test and adjust.
We can start the kernel from nand without any problems, but the kernel has no UBI file system management, which could easily cause irreparable failure, so we put the kernel in nor.
At present, many devices do not support UBI uboot, if you put kerner in nand, how to solve the bad block problem?