Assuming size(1) gives the size of the BSS is a mistake - it reports
the size of the .bss section in the ELF image, which may not be the
same as the region we mark with the __bss_start..__bss_stop symbols.

We use the size of the BSS in the decompressor to know whether the
kernel will overwrite the appended dtb, by adding the BSS size to the
size of the Image (stored at the end of the compressed data) and adding
the desired address of the decompressed image.

If the BSS size is smaller than it really is, the decompressor can
incorrectly assume that the BSS clearance will not overwrite the DTB.

Here is an illustration:

$ arm-linux-size vmlinux
   text    data      bss      dec     hex filename
8136972 3098076 10240348 21475396 147b044 vmlinux
$ arm-linux-nm vmlinux | grep __bss_
c0ac0e34 B __bss_start
c1484f9c B __bss_stop
$ stat -c %s arch/arm/boot/Image
11243060

In the above case, we are 12 bytes short.  This is caused by the BSS
section being aligned by one of its input sections:

Idx Name          Size      VMA       LMA       File off  Algn
 23 __bug_table   00005d3c  c0abb0f8  c0abb0f8  00acb0f8  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 24 .bss          009c415c  c0ac0e40  c0ac0e40  00ad0e34  2**6
                  ALLOC

Note that there's an additional 12 bytes difference between the file
offset and LMA compared with the bug table - this occurs because one
of the input sections for the .bss section requires a 64 byte
alignment.

Fix this by using 'nm' and perl to obtain the address of the __bss_start
and __bss_stop symbols, using their difference for the size of the BSS.
Tested-by: Tony Lindgren <tony@atomide.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>