From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?= Date: Fri, 4 Jul 2014 23:29:16 +0200 Subject: [U-Boot] SPL broken on i.mx31 platforms In-Reply-To: References: <53B2B8B8.7010406@hale.at> <53B3AF0E.1010105@hale.at> <53B5121B.809@hale.at> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Albert, On Fri, Jul 4, 2014 at 10:50 AM, Albert ARIBAUD wrote: > On Thu, 3 Jul 2014 22:58:56 +0200, Beno?t Th?baudeau > wrote: >> On Thu, Jul 3, 2014 at 3:35 PM, Albert ARIBAUD >> wrote: >> > On Thu, 03 Jul 2014 10:19:39 +0200, Helmut Raiger >> > wrote: >> >> On 07/03/2014 01:20 AM, Beno?t Th?baudeau wrote: >> >> > On Wed, Jul 2, 2014 at 9:04 AM, Helmut Raiger wrote: >> >> >>> the commit 41623c91 breaks the SPL on i.mx31 platforms. >> >> > Here, you are talking about mx31pdk, right? >> >> Actually im talking TT-01, but it has no contributed NAND boot code (which I >> >> was working on), but it should hit mx31pdk in the same way. >> >> This should answer Albert's question about the board. >> > >> > It does, thanks -- but I fail to see any SPL code built for TT-01. >> > You're getting SPL issues with another target, right? >> >> Helmut seems to be working on a custom TT-01 variant (or just with a >> specific hardware configuration using dip switches, or jumpers, etc.) >> using the i.MX31 NAND internal boot rather than the mainline boot >> source. >> >> >> >> No, it will only be a minor change, I think, but I thought there might >> >> >> have been an additional intention behind the change to position >> >> >> dependent code. One could link the first part to 0xB8000000 >> >> >> (the original position of the SPL when loaded by the IPL) and >> >> >> the part after the relocation to CONFIG_SPL_TEXT_BASE. >> >> > Actually, the ROM bootloader first copies the first NAND page to >> >> > 0xB8000000. Then, the SPL placed here but linked at >> >> > CONFIG_SPL_TEXT_BASE copies itself to CONFIG_SPL_TEXT_BASE in order >> >> > to free the NFC buffer so that it can be used by the SPL. There is >> >> > no relocation going on at this stage, but only a copy, and the SPL >> >> > code size is limited to 2 kiB. Then, the SPL does its NAND load job >> >> > towards CONFIG_SYS_TEXT_BASE and starts executing the non-SPL >> >> > binary, which then relocates itself according to the heap size, etc. >> > >> > Ok, I think I'm getting it, but actually you don't need PIC (your code >> > won't run at arbitrary locations), you need VMAs vs LMAs (your code >> > will run partly at one location, partly at another, but will be loaded >> > at only one of these locations). >> > >> > Therefore, we should be able to manage this in the linker script, by >> > basically defining two output sections: the first one with a VMA and >> > LMA equal to 0xB8000000 both, and which would contain the 'copier' code; >> > and the second one with a VMA equal to CONFIG_SPL_TEXT_BASE (so that it >> > links properly for running at that address) and a LMA equal to 0xB800000 >> > (so that it gets lumped with the first section in the less-than-2K ELF >> > file produced by the linker. >> > >> > (actually we'd have several output sections with VMA==LMA, but it >> > does not affect the core of the idea.) >> > >> > Does it make sense to you? >> >> It makes sense to me. That should work, but it'd be better to avoid >> adding a custom linker script. A simple fix in vectors.S would be >> preferable if possible. Also, the __image_copy_start stuff should be >> taken care of with such a change. > > I do not intend to have this in a custom linker script; I want this to > be in the common ARM SPL linker script (I hope it is what Helmut's > TT-01 changes use) -- I also want to get rid of all custom linker > scripts in the ARM par of U-Boot, but I could not get this done for > 2014.07. Looks good. >> BTW, I see that you skipped arch/arm/cpu/arm1136/u-boot-spl.lds in >> commit 41623c91 (addition of "*(.vectors)"). Was it intentional? > > Not that I can remember: I did modify the arm1136 start.S, so te linker > scripts should have followed. OK. There seems to be the same issue for board/ait/cam_enc_4xx/u-boot-spl.lds . All the ARM arch and ARM boards linker scripts should probably be rechecked. >> It silently changes woodburn_sd because the fallback exception vectors no >> longer exist. This should not cause a build error because the _start >> symbol is duplicated in this linker script. The board may also boot >> correctly with this, but the default vectors can be useful in some >> cases, especially for debugging exceptions. > > Can you post a patch today? I'll pull it in a PR I'll do today before > COB. Sorry, I can't before next week at best.