Hi Wolfgang,
On Wed, 11 Jun 2014 23:16:51 +0200, Wolfgang Denk wrote:
> Dear Steve,
>
> In message <5398a640.3050...@broadcom.com> you wrote:
> >
> > So if I add a "your_header.c" as above, then
> >
> > (1) I need to modify "arch/arm/cpu/armv8/u-boot.lds":
> > . = 0x;
> >
> > +
Dear Steve,
In message <5398a640.3050...@broadcom.com> you wrote:
>
> So if I add a "your_header.c" as above, then
>
> (1) I need to modify "arch/arm/cpu/armv8/u-boot.lds":
> . = 0x;
>
> + . = ALIGN(8);
> + .your_hdr : {
> + KEEP(*(.your_hdr*));
> + }
> +
>
On 14-06-10 11:45 PM, Albert ARIBAUD wrote:
Hi Wolfgang,
On Wed, 11 Jun 2014 06:49:28 +0200, Wolfgang Denk wrote:
Dear Steve,
In message <53979199.5010...@broadcom.com> you wrote:
OK - I think that one of the alternate proposals would be to
conditionally reserve a "32 byte block" prior t
Hi Wolfgang,
On Wed, 11 Jun 2014 06:49:28 +0200, Wolfgang Denk wrote:
> Dear Steve,
>
> In message <53979199.5010...@broadcom.com> you wrote:
> >
> > OK - I think that one of the alternate proposals would be to
> > conditionally reserve a "32 byte block" prior to the _start symbol (in
> > "a
Dear Steve,
In message <53979f6a.90...@broadcom.com> you wrote:
>
> Yes - copied from MMC to RAM, but not really necessary to do this at
> "link stage or earlier" (we do it with a post-processing tool to prepend
> a header onto 'u-boot.bin')
What exactly is the fuction of this post-processing
Dear Steve,
In message <53979199.5010...@broadcom.com> you wrote:
>
> OK - I think that one of the alternate proposals would be to
> conditionally reserve a "32 byte block" prior to the _start symbol (in
> "arch/arm/cpu/armv8/start.S") which would then be filled in by a
> post-processing step.
Dear Albert,
In message you wrote:
>
> 1. A typical ARM binary image is linked to a base address, defined by
>preprocessor macro (aka U-Boot config option) CONFIG_SYS_TEXT_BASE.
We shoul specifically keep in mind here that the "base address" is
defined as the start address of the text segme
On 14-06-10 02:20 PM, Albert ARIBAUD wrote:
Hi Steve,
On Tue, 10 Jun 2014 12:38:42 -0700, Steve Rae wrote:
On 14-06-10 11:13 AM, Wolfgang Denk wrote:
Dear Steve,
In message <539746c4.9040...@broadcom.com> you wrote:
There could be "many" reasons why the CONFIG_SYS_TEXT_BASE is not
ali
On 14-06-10 01:35 PM, Wolfgang Denk wrote:
Dear Steve,
In message <53975ec2.1080...@broadcom.com> you wrote:
I still cannot understand why _start and CONFIG_SYS_TEXT_BASE would
have to be the same. There is no such requirement. What exactly
prevents you from assigning _start a location at
Hi Steve,
On Tue, 10 Jun 2014 12:38:42 -0700, Steve Rae wrote:
>
>
> On 14-06-10 11:13 AM, Wolfgang Denk wrote:
> > Dear Steve,
> >
> > In message <539746c4.9040...@broadcom.com> you wrote:
> >>
> >> There could be "many" reasons why the CONFIG_SYS_TEXT_BASE is not
> >> aligned on a 0x1000 byt
Dear Steve,
In message <53975ec2.1080...@broadcom.com> you wrote:
>
> > I still cannot understand why _start and CONFIG_SYS_TEXT_BASE would
> > have to be the same. There is no such requirement. What exactly
> > prevents you from assigning _start a location at offset 0x20 to the
> > start of th
On 14-06-10 11:13 AM, Wolfgang Denk wrote:
Dear Steve,
In message <539746c4.9040...@broadcom.com> you wrote:
There could be "many" reasons why the CONFIG_SYS_TEXT_BASE is not
aligned on a 0x1000 byte boundary (Darwin has attempted to document his
particular use-case...)
We should be more p
Dear Steve,
In message <539746c4.9040...@broadcom.com> you wrote:
>
> There could be "many" reasons why the CONFIG_SYS_TEXT_BASE is not
> aligned on a 0x1000 byte boundary (Darwin has attempted to document his
> particular use-case...)
We should be more precise here and ask for any _good_ reas
On 14-06-09 10:16 PM, Albert ARIBAUD wrote:
Hi Steve,
(sorry for the duplicate)
On Mon, 9 Jun 2014 13:45:50 -0700, Steve Rae wrote:
On 14-06-09 03:23 AM, Albert ARIBAUD wrote:
Hi Darwin,
On Mon, 2 Jun 2014 17:37:25 -0700, Darwin Rambo
wrote:
On 14-06-02 12:26 AM, Albert ARIBAUD wr
Hi Steve,
(sorry for the duplicate)
On Mon, 9 Jun 2014 13:45:50 -0700, Steve Rae wrote:
>
>
> On 14-06-09 03:23 AM, Albert ARIBAUD wrote:
> > Hi Darwin,
> >
> > On Mon, 2 Jun 2014 17:37:25 -0700, Darwin Rambo
> > wrote:
> >
> >>
> >>
> >> On 14-06-02 12:26 AM, Albert ARIBAUD wrote:
> >>> Hi
On ma, 2014-06-09 at 13:45 -0700, Steve Rae wrote:
>
[snip]
> Note that in scenario #2, after relocation, the vectors are not on a
> 0x800 byte boundary anymore.
>
As long as the compiler emits adrp instructions, which it already does
at -O0, it is not only limited to vectors. No code works as
On 14-06-09 03:23 AM, Albert ARIBAUD wrote:
Hi Darwin,
On Mon, 2 Jun 2014 17:37:25 -0700, Darwin Rambo
wrote:
On 14-06-02 12:26 AM, Albert ARIBAUD wrote:
Hi Darwin,
On Mon, 26 May 2014 09:11:35 -0700, Darwin Rambo
wrote:
Hi Albert,
The previous stage bootloader (which I had no contr
Hi Darwin,
On Mon, 2 Jun 2014 17:37:25 -0700, Darwin Rambo
wrote:
>
>
> On 14-06-02 12:26 AM, Albert ARIBAUD wrote:
> > Hi Darwin,
> >
> > On Mon, 26 May 2014 09:11:35 -0700, Darwin Rambo
> > wrote:
> >
> >> Hi Albert,
> >>
> >> The previous stage bootloader (which I had no control over) want
On 14-06-02 12:26 AM, Albert ARIBAUD wrote:
Hi Darwin,
On Mon, 26 May 2014 09:11:35 -0700, Darwin Rambo
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 operati
Hi Darwin,
On Mon, 26 May 2014 09:11:35 -0700, Darwin Rambo
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 sam
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 c
Hi Wolfgang, Darwin,
On Thu, 15 May 2014 21:19:57 +0200, Wolfgang Denk wrote:
> Setting CONFIG_SYS_TEXT_BASE to something like 0x8820 is extremly
> fishy. If you want to add some header data to your image, you should
> not shift the text segment, but rather include your header in the
> star
Dear Darwin,
In message <5374e64b.1060...@broadcom.com> you wrote:
>
> > This makes no sense to me. CONFIG_SYS_TEXT_BASE is a compile time
> > constant. So the result of all this is always known at compile time,
> > too. I feel you misunderstand that CONFIG_SYS_TEXT_BASE is just the
> > start
On 14-05-15 08:21 AM, Wolfgang Denk wrote:
Dear Darwin,
In message <5374cd55.3010...@broadcom.com> you wrote:
Do you really want to check a define at runtime? Placement is typically
at the end of RAM and allocation goes down, not up as in this patch.
Aren't you overlapping memory here?
Yes, I
Dear Darwin,
In message <5374cd55.3010...@broadcom.com> you wrote:
>
> > Do you really want to check a define at runtime? Placement is typically
> > at the end of RAM and allocation goes down, not up as in this patch.
> > Aren't you overlapping memory here?
>
> Yes, I wanted the runtime check si
Dear Darwin,
In message <5374cc3b.7000...@broadcom.com> you wrote:
>
> I mean that the loader loads u-boot to it's correct address, which is
> offset by a small amount because of a previous header requiring alignment.
> Here's an example. u-boot is compiled to run at 0x8820 because we want
>
On 14-05-14 03:41 PM, Jeroen Hofstee wrote:
Hello Darwin,
On wo, 2014-05-14 at 15:05 -0700, Darwin Rambo wrote:
+#ifdef CONFIG_ARM64
+ /*
+* Fix relocation if u-boot is not on an aligned address.
+*/
+ {
+ int offset = CONFIG_SYS_TEXT_BASE % 4096;
+
On 14-05-14 09:26 PM, Wolfgang Denk wrote:
Dear Darwin Rambo,
In message <1400105145-6628-1-git-send-email-dra...@broadcom.com> you wrote:
If an earlier loader stage requires an image header and a specific
offset, then u-boot's base address (CONFIG_SYS_TEXT_BASE) may be
advanced beyond an alig
Dear Darwin Rambo,
In message <1400105145-6628-1-git-send-email-dra...@broadcom.com> you wrote:
> If an earlier loader stage requires an image header and a specific
> offset, then u-boot's base address (CONFIG_SYS_TEXT_BASE) may be
> advanced beyond an aligned address. In this case the relocation
Hello Darwin,
On wo, 2014-05-14 at 15:05 -0700, Darwin Rambo wrote:
> +#ifdef CONFIG_ARM64
> + /*
> + * Fix relocation if u-boot is not on an aligned address.
> + */
> + {
> + int offset = CONFIG_SYS_TEXT_BASE % 4096;
> + if (offset) {
> +
30 matches
Mail list logo
