Increasing mamba and venom kernel partition to 6MB

@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.

1 Like

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

@solidus1983
Please do not feel the need to apologize, no one is obligated to test this.
:upside_down_face:

2 Likes

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.

corrrupt bootloader

Just in case you had not seen, a somewhat timely conversation, possibly of interest re this.

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.

:rofl:

Context is everything.

1 Like

@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.

1 Like

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.