On 2021-04-13 08:39, Rafał Miłecki wrote:
On 13.04.2021 00:46, Sven Roederer wrote:
since some days my master builds failing for ath79-generic. I was able
to
narrow it to running "mkmylofw for compex_wpj344-16m".
The tool runs till the drive is full, currently my "compex_wpj344-16m-
squashfs-cpximg-6a08.bin.new" is 161GB and growing ...
Has anyone else seen this?
I'll check to see which of the relevant 6 commit trigger this during
the next
days.
This is caused by the commit a2f66229450d ("firmware-utils: fix few
random warnings").
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=a2f66229450dc2f7647c19ac83f3948e809406c2
Above change fixed C macro and affected following line of code:
len = ALIGN(len,4) - block->size;
In compex_wpj344-16m case we have
len: 0
block->size: 5967872
which results in len calculation as follows:
len = ALIGN(0,4) - 5967872
Old macro resulted in:
(0+(4-1)) & ~(4-1) - 5967872
^ subtraction happens first
New macro results in:
((0+(4-1)) & ~(4-1)) - 5967872
^ AND happens first
With new macro final len value is -5967872
That results in write_out_padding() trying to write a lot of data.
So the old code was working accidentally. It resulted in calculating
len
incorrectly but somehow that unexpected "0" value was working just
fine.
The original code comes from Florian from the 2007 commit 7b564bfdcbef
("Fix potential unligned access with MyLoader based devices, thanks
Juhos")
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=7b564bfdcbef05f68d8a658caf832c6832705e1f
Sven, Florian: any chance you know how that code:
/* align next block on a 4 byte boundary */
len = ALIGN(len,4) - block->size;
was meant to behave originally?
Please check commit d4f2c2914a65 ("firmware-utils: mkmylofw: fix blocks
padding")
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=d4f2c2914a6547ef6067dd0968c4970e913f17f0
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
