From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aneesh V Date: Fri, 01 Jul 2011 17:18:43 +0530 Subject: [U-Boot] [RFC PATCH 6/7] omap: common spl support for OMAP3/4 In-Reply-To: <4E0D999C.1050209@gmail.com> References: <1309352967-5719-7-git-send-email-aneesh@ti.com> <4E0C113B.3070303@denx.de> <4E0C13D0.5040001@ti.com> <461E70CA-D429-4E3E-A43D-E28F71B35631@googlemail.com> <4E0D9314.4050001@ti.com> <4E0D999C.1050209@gmail.com> Message-ID: <4E0DB41B.5010709@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 Dear Andreas, On Friday 01 July 2011 03:25 PM, Andreas Bie?mann wrote: > Dear Aneesh, [snip ..] > But the second part is not clear to me. I saw in your linker, that bss > is placed in SDRAM. In start.S the boundaries for clear_bss are > calculated at compile time to > > ---8<--- > _bss_start_ofs: > .word __bss_start - _start > --->8--- > > Will that also work with e.g. SDRAM adress space is before SRAM, SDRAM > addressing is far away (> 4GiB) ... So in you special case it may work, > but if this is a blueprint for SPL on arm(v7) we should consider this. > Nice catch. Actually, in my original OMAP4 series I tried to add support for disjoint bss to support my case. But now I realize that it works only for non-relocation case and that too only when the bss is at higher address compared to .text Basically disjoint bss is not relocation friendly. So here is what I propose: 1. Modify existing clear_bss sub-routine in start.S to take absolute addresses. 2. In regular u-boot, calculate the relocated bss address and pass to this function. 3. In SPL don't try to calculate the relocated address and directly pass the absolute address. If this is fine I will make the necessary changes in start.S in the next revision. best regards, Aneesh