@solidus1983
venom DTS as currently in OpenWrt only has a 3MB partition.
Its uboot however will handle 6MB.
This patch changes it to use the full 6MB at the cost of 3MB from root.
I wonder if the semantics around
root@OpenWrt:/etc/config# cat system
config system
option compat_version '1.1'
could be utilised to force people to the right upgrade.
Looks easy enough
I have gone back to unpatched image and was wondering if you still have a patched one loaded
root@mamba:/etc# cat fw_env.config
/dev/mtd1 0x0 0x40000 0x20000
what that may look like.
Mine is the same on patched build.
That is the uboot environment variables block.
Shouldn't be affected by this.
I just remember people running into an issue with that back when trying to get a venom running on a rango image. Thanks.
If this works you should push it for inclusion in 21.xx
Ya, maybe a PR, I'm guessing there will need to be a little discussion regarding the migration to / from strategy.
I will clean them up and file a pull request on the GitHub repo for comments sometime soon.
Venom also still needs to be tested. I don't have one.
I want to make a patch for the compatibility version.
Not sure if I should make all of mvebu 1.2 or just let them desync and only have mamba/venom 1.2 and the rest 1.1.
Just doing a normal compile atm will patch after and recompile again with the adjustments.
As for Desync if we are talking about sysupgrade i think put them all to 1.2 with a warning you've done that and that downgrading will require a full flash image rather then a sysupgrade image.
Edit: Will not be able to do testing to Wednesday at the earliest might be even later. Need to fully test my new build r15697 (5.4.95) first. However I take it's a simple git am with the correct patch.
However I do suggest making a PR as someone might be able to test it before me this saving time waiting. Sorry @SkewedZeppelin
this is fantastic progress.
i have a wrt32x which i converted to a wrt3200acm according to an old method which included replacing the u-boot but am excited to try this.
once this is stablized, is there a way to change the default u-boot (i.e. a new u-boot image) so that the new environment values are re-created as defaults? it would also be helpful to default to 'silent=0' .
I said i would, then things changed as a man of my word that means i have to appologise.
Right looking in the patch folder can only see mamba versions of the patch.
Also my builds has
CONFIG_ALL_KMODS=y
CONFIG_ALL_NONSHARED=y
Thus far no issues with booting and it running fine. However point me to the patch and i will get one compiled for testing myself.
Edit: Found your patch for venom, applied and now compiling.
Dude you just had me panic there saying corrupt bootloader, Just compiling a new version with a patch that changes kernel side and then you place that in.
Context is everything.
@SkewedZeppelin Just a quick question, I take it i should be able to keep the Alt partition at my new R15697 and if i have issues with R15671 (new build currently compiling) i should be able to power cycle it 3 times to switch to the alt partition without issues?
Yes, you should be able to boot the alternate partition without issue.
regarding u-boot changes and corrupt bootloader:
this is a likely result if you don't use the tollkit for building u-boot (which is beyond me).
i had to use the kwboot recovery method after i attempted to modify the u-boot default values in the image. some u-boot versions have an integrity check which includes checksum and my clumsy alteration of the env vars did not account for this integrity check - resulting in brick.