[U-Boot] [PATCH] arm: Allow u-boot to run from offset base address

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Hi Steve,

(sorry for the duplicate)

On Mon, 9 Jun 2014 13:45:50 -0700, Steve Rae <srae@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 <drambo@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 <drambo@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.