From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aneesh V Date: Thu, 01 Dec 2011 15:46:49 +0530 Subject: [U-Boot] [PATCH] devkit8000: Move CONFIG_SYS_TEXT_BASE out of bss In-Reply-To: <4ED750F0.7060607@compulab.co.il> References: <1322672741-27396-1-git-send-email-simonschwarzcor@gmail.com> <4ED73189.4090507@compulab.co.il> <4ED750F0.7060607@compulab.co.il> Message-ID: <4ED75411.1080401@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Igor, On Thursday 01 December 2011 03:33 PM, Igor Grinberg wrote: > On 12/01/11 11:07, Simon Schwarz wrote: >> Hi Igor, >> >> this only affects Boards with SPL support - and only devkit8000. >> >> The SPL has its .bss section in SD-RAM while the rest is in SRAM - >> CONFIG_SYS_TEXT_BASE was in the same area as .bss. This caused trouble >> as the header of the u-boot.img was written before >> CONFIG_SYS_TEXT_BASE. In the described case this messed with the >> pointer to the mcc datastructure - therefore the u-boot.img file >> failed to be read. > > Thank you very much for the explanation. > > So as to my understanding, what happens is: > 1) The SPL initializes the SDRAM > 2) Copies its .bss section to SDRAM > 3) Starts loading the U-Boot image and overwrites the .bss section > Is the above correct? > > If it is, then why do we need the .bss in SDRAM? U-Boot FAT implementation uses 3 buffers each of size 64 KB. > Aren't there enough space in SRAM? SRAM doesn't have space for such huge buffers. > Also, is this what X-Loader did in first place? Yes, x-loader had these buffers in SDRAM too. But instead of putting the .bss in SDRAM, x-loader made these huge arrays into pointer variables that were then made to point to the SDRAM. br, Aneesh