aboutsummaryrefslogtreecommitdiff
path: root/board/sunxi
diff options
context:
space:
mode:
authorTom Rini <trini@konsulko.com>2018-05-01 12:32:37 -0400
committerTom Rini <trini@konsulko.com>2018-05-08 18:50:24 -0400
commitcc95535867f407534b0e59f8b5017f0f729833a9 (patch)
tree9a6b9f2154b50a2df67931688d7f091aa4218ac2 /board/sunxi
parent71412d723161d14f887e548aca42c51d144e3489 (diff)
downloadu-boot-cc95535867f407534b0e59f8b5017f0f729833a9.zip
u-boot-cc95535867f407534b0e59f8b5017f0f729833a9.tar.gz
u-boot-cc95535867f407534b0e59f8b5017f0f729833a9.tar.bz2
bootm.c: Correct the flush_len used in bootm_load_os()
In do_bootm_states when doing BOOTM_STATE_LOADOS we use load_end uninitialized and Coverity notes this now. This however leads down another interesting path. We pass this pointer to bootm_load_os and that in turn uses this uninitialized value immediately to calculate the flush length, and is wrong. We do not know what load_end will be until after bootm_decomp_image is called, so we must only set flush_len after that. All of this also makes it clear that the only reason we pass a pointer for load_end to bootm_load_os is so that we can call lmb_reserve on success. Rather than initialize load_end to 0 in do_bootm_states we can just call lmb_reserve ourself. Reported-by: Coverity (CID: 175572) Cc: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Diffstat (limited to 'board/sunxi')
0 files changed, 0 insertions, 0 deletions