This has nothing to do with the state of flash. The u-boot environment partition has a checksum at the start, if it doesn't exist or is corrupted (via checksum) then it is ignored.
I did, and it is! . I also saved a variable, still in u-boot (yay!), and in OpenWrt, once I set /etc/fw_env.config to /dev/mtd5 0x4000 0x1000 0x1000 => update in package/boot/uboot-envtools/files/ramips?
Yes, agreed - I may not have said that, but that's what I was meaning. It likely got messed up at some point ... so I went back to OEM, reflashed with the "final" version => all good now!
Sure, the flash instructions on that OpenWrt Device page should be cleaned up and refreshed!
Rolling back to OEM firmware has to be noted also! I posted links to unpack scripts and files. They could be noted there.
The best would be to write the instructions (or include the helper script) on Wiki about extracting rootfs and kernel from the OEM binary (which is a ext2 filesystem, btw.).
But linking to OpenWrt device page is not sufficient, as it's volatile compared to the commit message!
Just "copy-paste" the flash instructions into the commit message, and you are done!
Browse "add support" commits for more hint! git log
Sorry? The code below isn't correct? At least the first two arguments?!
And what happens (to OpenWrt, to u-boot) if you flood your u-boot-env partition (with a script) with long variable names assigned with long values? Lorem ipsum will help!
I would try the following for the third and fourth parameter in the hope that
envsize is the size of the u-boot environment: 0x10000 - 0x4000 = 0xc000, and
secsize is the sector size: the erase size: 0x1000
@981213 suggested me (for mt7621) to use 0x1fc00000:
But I found it to be 0x10000000.
And now, you @arrmo found it as 1C000000 for mt7620:
Looking for OpenWrt image... found at 0xbc200000
I'm afraid that AR71XX_FLASH_START should be renamed to CONFIG_FLASH_START or something like and moved to config.h ... and had to be set up in target/linux/ramips/image/Makefile like KERNEL_LOADADDR or LOADER_PLATFORM.
And because of that, this change should be sent to ML.
When this HT-TM05 PR hits master I would prepare a commit for this.
OK, you're confusing me a bit . I did check, in u-boot, and it does say,
Environment size: 198/4092 bytes
=> So environment is only 1 sector, 0x1000 long ... agreed? And from u-boot, it does seem to start at 1d4000, agreed? So 0x4000 (start), 0x1000 length?
Not quite sure what you're after here. We do have the start address correct, no?
Agreed ... just weird to waste 60 K flash space for that 4 K environment.
Would you try to concatenate that 60K to firmware and try out if it crashes on saveenv?
Yes we do, but it's a negative offset. It works but it doesn't looks good!
root@GL-AR300M-NOR-F5E ~ # fw_setenv --help
Usage: fw_setenv [OPTIONS]... [VARIABLE]...
Modify variables in U-Boot environment
-h, --help print this help.
-v, --version display version
-c, --config configuration file, default:/etc/fw_env.config
-l, --lock lock node, default:/var/lock
-s, --script batch mode to minimize writes
Examples:
fw_setenv foo bar set variable foo equal bar
fw_setenv foo clear variable foo
fw_setenv --script file run batch script
Script Syntax:
key [space] value
lines starting with '#' are treated as comment
A variable without value will be deleted. Any number of spaces are
allowed between key and value. Space inside of the value is treated
as part of the value itself.
Script Example:
netdev eth0
kernel_addr 400000
foo empty empty empty empty empty empty
bar
Edit /etc/fw_env.config to cover the whole partition and try to overflow with OpenWrt!
So seems the limit really is 4K. To your question ... ya, they throw away 65K, but they also limit the kernel to 1.5 MB ...
So just update these addresses (0x4000, 0x1000) => then I'll pull in your latest changes, make sure the build works (locally) ... update the instructions / commit, and push (the "final"?!?!) code?
Just trying to make sure I know what's left to do. Getting a bit confused, sorry.