Hi Benoît, On Thu, 3 Jul 2014 22:58:56 +0200, Benoît Thébaudeau <benoit.thebaudeau....@gmail.com> wrote:
> Hi Albert, > > On Thu, Jul 3, 2014 at 3:35 PM, Albert ARIBAUD > <albert.u.b...@aribaud.net> wrote: > > Hi Helmut, > > > > On Thu, 03 Jul 2014 10:19:39 +0200, Helmut Raiger > > <helmut.rai...@hale.at> wrote: > > > >> Hi, > >> > >> On 07/03/2014 01:20 AM, Benoît Thébaudeau wrote: > >> > )Dear Helmut Raiger, > >> > > >> > On Wed, Jul 2, 2014 at 9:04 AM, Helmut Raiger <helmut.rai...@hale.at> > >> > 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. > 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. > 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. > Cordialement, > Benoît Amicalement, -- Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
