Hi Albert,
On Sun, Oct 25, 2015 at 5:29 AM, Albert ARIBAUD albert.u.boot@aribaud.net wrote:
On Mon, 12 Oct 2015 00:02:57 +0200, Albert ARIBAUD (3ADEV) albert.aribaud@3adev.fr wrote:
TFTP source and destination port variable names are 'tftpsrcp' and 'tftpdstp' in the code, but 'tftpsrcport' and 'tftpdstport' in the README file. Fix the README.
Add environment variable 'tftptimeoutcountmax'. As per the comments about the global variable tftp_timeout_count_max, make sure tftptimeoutcountmax is nonnegative.
Introduce configuration option CONFIG_NET_TFTP_VARS, which controls whether environment variables tftpblocksize, tftptimeout, and tftptimoueoutcountmax are read by the TFTP client code. CONFIG_NET_TFTP_VARS defaults to y but can be set to n by targets with to tight size contraints.
Make bf527-ezkit set CONFIG_NET_TFTP_VARS to n to keep the target size below limit.
Joe, does it work for bf527-ezkit?
Apparently it is OK to break these boards. It seems it is already broken in the now-current master.
+(bf537-stamp) u-boot.bin exceeds file size limit: +(bf537-stamp,bf527-ezkit-v2,bf527-ezkit,bf526-ezbrd) limit: 262144 bytes +(bf537-stamp) actual: 263088 bytes +(bf537-stamp) excess: 944 bytes +(bf537-stamp) make[1]: *** [u-boot.bin] Error 1 +(bf527-ezkit-v2,bf527-ezkit,bf526-ezbrd) u-boot.ldr exceeds file size limit: +(bf527-ezkit-v2) actual: 262752 bytes +(bf527-ezkit-v2) excess: 608 bytes +(bf527-ezkit-v2,bf527-ezkit,bf526-ezbrd) make[1]: *** [u-boot.ldr] Error 1 +(bf527-ezkit) actual: 262876 bytes +(bf527-ezkit) excess: 732 bytes +(bf526-ezbrd) actual: 263056 bytes +(bf526-ezbrd) excess: 912 bytes +(bct-brettl2) bfin-elf-ld.bfd: u-boot section `.bss' will not fit in region `ram' +(bct-brettl2) bfin-elf-ld.bfd: region `ram' overflowed by 212 bytes
The only new regression with the patches I'm testing (this includes your v4) is this:
+(bf538f-ezkit) bfin-elf-ld.bfd: region `ram' overflowed by 256 bytes
I'm tired of fighting for a byte here or there. I agree that we should not just bloat needlessly, but these boards are simply too close to the limit to be reasonable. I guess they will be broken frequently until someone turns off some features on them.
Acked-by: Joe Hershberger joe.hershberger@ni.com