out of the box factory on mamba it seems that uboot is configured to read in a 4MB kernel from a certain address.
the kernel partition as defined by the Linux device tree (DTS) is 40MB(, yes 40MB)
BUT
the root partition is overlapped into the kernel partition and is 37MB
leaving only 3MB for the actual kernel
these patches merely reduce the root to 36MB, allowing the kernel to grow up to the 4MB
as 4MB is the max for this uboot without having to modify uboot
uboot is completely unmodified with these patches
uboot being unmodified and the layout of the "factory" flash images is why you can keep oem/stock compatible
--
as to why uboot is set to 4MB, but OpenWrt only 3MB, that is unknown to us
I can share another successful story of migrating from well known davidc build to this one. As the author suggests, the hard-self-building way works(such a nice way of stress-test the cpu), and baking nlbw into rom is an easy process. Thanks a lot for your work!
However, I'm curious is there any way of interactive merging of multiple config.seeds or configs in general? I have in mind a case where I want to bring my own packages into further releases. Should I use quilt, mark all important for me packages then apply the newly created diff into all new .config file, or should I use another tool?
Thanks @SkewedZeppelin! I hope you don't mind me re-phrasing your explanation Re: Linux Device Tree so please bear with me, or simply tell me to go RTFM
You said "kernel partition as defined by the Linux device tree (DTS) is 40MB (yes 40MB) BUT the root partition is overlapped into the kernel partition and is 37MB leaving only 3MB for the actual kernel"
So the size of the generated root partition is constrained at 37MB in the normal build process (for unknown, possibly historical reasons) and that's what your patch is reducing down to 36MB in order to end up with more usable space for the kernel. Thus environment variables (alt_kern_addr and alt_kern_size) merely only tell uBoot where to start reading and how much to read in order to load the kernel in memory. And since alt_kern_size already references a 4MB "chunk" then uBoot will happily read and load an extra 1MB of code instead of 1MB of 0x00 padding, so that's what you meant by "uBoot being unmodified - did I get this right?
probably a newb question but I have the 3200acm and I see on your build - mamba and venom I think mamba is 1900 version and venom is 32x... so what I have to do to resize and upgrade to new kernel?
thanks
@PerkelSimon
If you are currently running a recent OpenWrt snapshot and not 19.xx series you should be able to install with keep settings checked.
If you are on 19.xx or earlier you need to manually migrate to DSA from swconfig.
These builds aside from a handful of patches and configs are vanilla from master/trunk.
I can confirm I can flash your resized build on my venom from the stock linksys firmware and can switch back to the linksys firmware from resized build.
By the time OpenWrt fully supports 5.10, I am sure that WireGuard will be working.
iirc it is just some build issues, nothing big blocking it.
--
None of my builds are 5.10, as OpenWrt is still 5.4.
There is a wiki page detailing the update policy, but I can't seem to find it.
Basically don't rush to prevent constant rebasing.
You mentioned earlier that you keep OEM in the alternative partition set.
That error is likely expected then, as it doesn't see the right magic values at the start of it.
That shouldn't show if you had a resized version flashed on both, as would be usual.
As long as you don't see any other issues such as settings not saving, it should be OK.
Thanks @SkewedZeppelin for the explanation! You're right, I kept the OEM firmware on the 1st partition and always flash from there. I was a little worried as I mistakenly loaded the configuration files from a mamba to a cobra once when I started using your build. I learned that lesson now
I hope this question is not too dumb. Can some of the postbuild items you reference on your website " Anything to change after install?" not be executed in an automated way at first boot using something like UCI?
Hi @SkewedZeppelin is there a way to include a set of configuration files in your build so router comes up pre-configured upon first boot after being flashed?