Hi Steve, (sorry for the duplicate)
On Mon, 9 Jun 2014 13:45:50 -0700, Steve Rae <s...@broadcom.com> wrote: > > > On 14-06-09 03:23 AM, Albert ARIBAUD wrote: > > Hi Darwin, > > > > On Mon, 2 Jun 2014 17:37:25 -0700, Darwin Rambo <dra...@broadcom.com> > > wrote: > > > >> > >> > >> On 14-06-02 12:26 AM, Albert ARIBAUD wrote: > >>> Hi Darwin, > >>> > >>> On Mon, 26 May 2014 09:11:35 -0700, Darwin Rambo <dra...@broadcom.com> > >>> wrote: > >>> > >>>> Hi Albert, > >>>> > >>>> The previous stage bootloader (which I had no control over) wanted it's > >>>> header to be aligned to a 512 byte MMC block boundary, presumably since > >>>> this allowed DMA operations without copy/shifting. At the same time, I > >>>> didn't want to hack a header into start.S because I didn't want to carry > >>>> another downstream patch. So I investigated if I could shift u-boot's > >>>> base address as a feature that would allow an aligned header to be used > >>>> without the start.S patch. > >>>> > >>>> I know that a custom header patch to start.S would work, and that a > >>>> header plus padding will also work. But I found out that you can align > >>>> the base on certain smaller offsets if you keep the relocation offset at > >>>> nice boundaries like 0x1000 and if the relocation offset is a multiple > >>>> of the maximum alignment requirements of the image. > >>>> > >>>> The original patch I submitted didn't handle an end condition properly, > >>>> was ARM64-specific (wasn't tested on other architectures), and because > >>>> the patch was NAK'd, I didn't bother to submit a v2 patch and consider > >>>> the idea to be dead. I'm happy to abandon the patch. I hope this helps. > >>> > >>> Thanks. > >>> > >>> If I understand correctly, your target has a requirement for storing > >>> the image on a 512-byte boundary. But how does this affect the loading > >>> of the image into RAM, where the requirement is only that the vectors > >>> table be 32-bytes aligned? I mean, if you store the image in MMC at > >>> offset 0x200 (thus satisfying the 512-byte boundary requirement) and > >>> load it to, say, offset 0x10020 in RAM, how is it a problem for > >>> your target? > >>> > >>> If my example above inadequately represents the issue, then can you > >>> please provide a similar but adequate example, a failure case scenario, > >>> so that I can hve a correct understanding of the problem? > >> > >> Hi Albert, > >> > >> The constraints I have that I can't change, are that > >> - the 32 byte header is postprocessed and prepended to the image after > >> the build is complete > >> - the header is at a 512 byte alignment in MMC > >> - the header and image are copied to SDRAM to an alignment like > >> 0x88000000. Thus the u-boot image is linked at and starts at 0x88000020. > >> - the vectors need to be 0x800 aligned for armv8 (.align 11 directive) > > > > So far, so good -- I understand that the link-time location of the > > vectors table is incorrect. > > > >> So the failure case is that when the relocation happens, it relocates to > >> a 0x1000 alignment, say something like 0xffffa000. The relocation offset > >> is not a multiple of 0x1000 (0xffffa000 - 0x88000020) and the relocation > >> fails. > > > > What does "relocation fails" mean exactly, i.e., where and how exactly > > does the relocation code behave differently from expected? I'm asking > > because I don't understand why the relocation offset should be a > > multiple of 0x1000. > > > >> Adjusting the relocation offset to a multiple of 0x1000 (by > >> making the relocation address end in 0xNNNNN020) fixes the issues and > >> allows u-boot to relocate and run from this address without failing. I > >> hope this helps explain it a bit better. > > > > I do understand, however, that if the relocation offset must indeed be a > > multiple of 0x1000, then obviously the vectors table will end up as > > misaligned as it was before relocation. > > > > Also, personally I would like it if the vectors table was always > > aligned as it should, and there are at least three other boards which > > require a prefix/header before their vectors table, as Masahiro (cc:) > > indicated recently, so that makes the problem a generic one: how to > > properly integrate a header in-image (as opposed to an out-of-image > > one, which is just a matter of doing a 'cat', so to speak. > > > > Therefore I'd like a generic solution to this, where the header is > > prepended *and* aligned properly without breaking the start symbol > > alignment constraints. This /might/ be possible by cleverly adding > > a '.header' or '.signature' section to the linker script, possibly > > doing a two-stage link; but this should not require the source code to > > contain ad hoc relocation tricks. > > > > Let me tinker with it in the next few days; I'll try and come up with a > > clean and generic solution to this "in-code header" question. > > > > Thanks again for your explanation! > > > >> Best regards, > >> Darwin > > > > Amicalement, > > > > Perhaps an oversimplified example of the current code would help to > explain this better: > > scenario #1: > CONFIG_SYS_TEXT_BASE 0x88000000 > vectors: .align 11 /* exception vectors need to be on a 0x800 byte > boundary */ > compile/linker produces (before relocation): > _start symbol is at 0x88000000 > vectors symbol is at 0x88000800 > the relocation offset is: 0x77f9b000 > therefore, after relocation: > _start symbol is at 0xfff9b000 (0x88000000+0xfff9b000) > vectors symbol is at 0xfff9b800 (0x88000800+0x77f9b000) > > scenario #2: > CONFIG_SYS_TEXT_BASE 0x88000020 > vectors: .align 11 /* exception vectors need to be on a 0x800 byte > boundary */ > compiler/linker produces (before relocation): > _start symbol is at 0x88000020 > vectors symbol is at 0x88000800 > the relocation offset is: 0x77f9afe0 > therefore, after relocation: > _start symbol is at 0xfff9b000 (0x88000020+0x77f9afe0) > vectors symbol is at 0xfff9b7e0 (0x88000800+0x77f9afe0) > > Note that in scenario #2, after relocation, the vectors are not on a > 0x800 byte boundary anymore. Ok, so technically relocation works as it was told to, just was given "garbage in", with an image with an unaligned base and _start symbol (and an aligned vectors symbol); relocation worked as expected, and aligned base and start, thus not aligning vectors. Now, on to understanding why the CONFIG_SYS_TEXT_BASE is not aligned. Can you provide details from the case where the actual issue has arisen, or even better yet, provide a source tree and build command line, that I could reproduce the build here? > Thanks, Steve Amicalement, -- Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot