[U-Boot] [PATCH] 8313erdb: Set guarded bit on BAT that covers the end of the address space.

[Norbert van Bolhuis <nvbolhuis@aimvalley.nl>]

Aha!
It seems like the root cause of this problem:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/53025/match=nasty+gunzip+problem+mpc8313e+rdb

As a MPC8313E(-RDB) user I'm happy no more checkstops will occur
for some kernels. I'm even more happy I took over the BAT settings
from MPC8315ERDB.h for our custom MPC8313 board
(MPC8315ERDB.h doesn't have this problem as far as i can tell)




Scott Wood wrote:
> This board currently sets DBAT6 to cover all of the final 256MiB of
> address space; however, not all of this space is covered by a device.  In
> particular, flash sits at 0xfe000000-0xfe7fffff, and nothing is mapped
> at the far end of the address space.
> 
> In zlib, there is a loop that references p[-1] if p is non-NULL.  Under
> some circumstances, this leads to the CPU speculatively loading from
> 0xfffffff8 if p is NULL.  This leads to a machine check.
> 
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> Note that there are likely other board with the same issue.
> 
>  include/configs/MPC8313ERDB.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/include/configs/MPC8313ERDB.h b/include/configs/MPC8313ERDB.h
> index 0ef4eba..21aedee 100644
> --- a/include/configs/MPC8313ERDB.h
> +++ b/include/configs/MPC8313ERDB.h
> @@ -544,7 +544,7 @@
>  #define CONFIG_SYS_IBAT5U	(CONFIG_SYS_IMMR | BATU_BL_256M | BATU_VS | BATU_VP)
>  
>  /* SDRAM @ 0xF0000000, stack in DCACHE 0xFDF00000 & FLASH @ 0xFE000000 */
> -#define CONFIG_SYS_IBAT6L	(0xF0000000 | BATL_PP_10)
> +#define CONFIG_SYS_IBAT6L	(0xF0000000 | BATL_PP_10 | BATL_GUARDEDSTORAGE)
>  #define CONFIG_SYS_IBAT6U	(0xF0000000 | BATU_BL_256M | BATU_VS | BATU_VP)
>  
>  #define CONFIG_SYS_IBAT7L	(0)