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) {
> +
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
will not be done correctly for some sections such as vectors and rodata
string tables, which will show
31 matches
Mail list logo
