mirror of
https://github.com/u-boot/u-boot.git
synced 2024-12-01 16:43:28 +08:00
14f73ca679
If CFG_MEM_TOP_HIDE is defined in the board config header, this specified memory area will get subtracted from the top (end) of ram and won't get "touched" at all by U-Boot. By fixing up gd->ram_size the Linux kernel should gets passed the now "corrected" memory size and won't touch it either. This should work for arch/ppc and arch/powerpc. Only Linux board ports in arch/powerpc with bootwrapper support, which recalculate the memory size from the SDRAM controller setup, will have to get fixed in Linux additionally. This patch enables this config option on some PPC440EPx boards as a workaround for the CHIP 11 errata. Here the description from the AMCC documentation: CHIP_11: End of memory range area restricted access. Category: 3 Overview: The 440EPx DDR controller does not acknowledge any transaction which is determined to be crossing over the end-of-memory-range boundary, even if the starting address is within valid memory space. Any such transaction from any PLB4 master will result in a PLB time-out on PLB4 bus. Impact: In case of such misaligned bursts, PLB4 masters will not retrieve any data at all, just the available data up to the end of memory, especially the 440 CPU. For example, if a CPU instruction required an operand located in memory within the last 7 words of memory, the DCU master would burst read 8 words to update the data cache and cross over the end-of-memory-range boundary. Such a DCU read would not be answered by the DDR controller, resulting in a PLB4 time-out and ultimately in a Machine Check interrupt. The data would be inaccessible to the CPU. Workaround: Forbid any application to access the last 256 bytes of DDR memory. For example, make your operating system believe that the last 256 bytes of DDR memory are absent. AMCC has a patch that does this, available for Linux. This patch sets CFG_MEM_TOP_HIDE for the following 440EPx boards: lwmon5, korat, sequoia The other remaining 440EPx board were intentionally not included since it is not clear to me, if they use the end of ram for some other purpose. This is unclear, since these boards have CONFIG_PRAM defined and even comments like this: PMC440.h: /* esd expects pram at end of physical memory. * So no logbuffer at the moment. */ It is strongly recommended to not use the last 256 bytes on those boards too. Patches from the board maintainers are welcome. Signed-off-by: Stefan Roese <sr@denx.de> |
||
|---|---|---|
| .. | ||
| bat_rw.c | ||
| board.c | ||
| bootm.c | ||
| cache.c | ||
| extable.c | ||
| interrupts.c | ||
| kgdb.c | ||
| Makefile | ||
| ppccache.S | ||
| ppcstring.S | ||
| ticks.S | ||
| time.c | ||