From: Heiko Schocher <hs@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] ARM relocation, question to Heiko
Date: Sat, 02 Oct 2010 11:08:23 +0200 [thread overview]
Message-ID: <4CA6F687.1080600@denx.de> (raw)
In-Reply-To: <4CA6E8E5.2090605@emk-elektronik.de>
Hello Reinhard,
Reinhard Meyer wrote:
> Dear Albert ARIBAUD,
>>> I try to understand how the relocation process could handle pointers (to
>>> functions or other data) in const or data sections.
>>> Your code cannot know what is data and what is a pointer that needs
>>> adjustment?
>>>
>>> Best Regards,
>>> Reinhard
>> Hi Reinhart,
>>
>> Short answer - the relocation process does not handle pointers inside
>> data structures.
>>
>> And yes, this means the content arrays of pointers such as init_sequence
>> is not relocated. Been there, done that, can give you one of the
The init_sequence should not called anymore after relocation, as it is
the init_sequence ... or?
>> tee-shirts I got :)
>>
>> ATM I have not found a way to fix this, except making the code which
>> uses the pointers aware that the are location-sensitive and fix them
>> when using them.
>
> That means that things like this cannot work (with relocation),
> unless adding the relocation offset before using the pointer:
Yep, you have to fix these pointers after relocation ...
> const struct {
> const u8 shift;
> const u8 idcode;
> struct spi_flash *(*probe) (struct spi_slave *spi, u8 *idcode);
> } flashes[] = {
> #ifdef CONFIG_SPI_FLASH_SPANSION
> { 0, 0x01, spi_flash_probe_spansion, },
> #endif
[...]
> #ifdef CONFIG_SPI_FRAM_RAMTRON
> { 6, 0xc2, spi_fram_probe_ramtron, },
> # ifdef CONFIG_SPI_FRAM_RAMTRON_NON_JEDEC
> { 0, 0xff, spi_fram_probe_ramtron, },
> # endif
> # undef IDBUF_LEN
> # define IDBUF_LEN 9 /* we need to read 6+3 bytes */
> #endif
> };
>
> And I think there are more places of this type in u-boot...
Yes, maybe. But relocation as I did for arm, also works
on m68k, sparc, mips, avr32 and they must do also this
fixups, so for common functions (except the new env handling,
which I think got never tested on this architectures?) should
work ...
As I just searching in code: there is a env_relocate()
function (which get called from arch/arm/lib/board.c board_init_r()),
but it did not the necessary work for subcommandtable fixup...
I think this should be the right place to do this ... or?
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
next prev parent reply other threads:[~2010-10-02 9:08 UTC|newest]
Thread overview: 113+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-30 13:57 [U-Boot] ARM relocation, probably trivial mistake Reinhard Meyer
2010-09-30 14:08 ` Stefano Babic
2010-09-30 14:20 ` Reinhard Meyer
2010-09-30 15:39 ` Heiko Schocher
2010-09-30 16:06 ` Reinhard Meyer
2010-09-30 15:38 ` Heiko Schocher
2010-09-30 17:43 ` Wolfgang Denk
2010-10-01 5:25 ` Heiko Schocher
2010-10-01 5:40 ` Albert ARIBAUD
2010-10-01 5:53 ` Heiko Schocher
2010-10-01 6:39 ` Reinhard Meyer
2010-10-01 6:57 ` Heiko Schocher
2010-10-01 8:45 ` Wolfgang Denk
2010-10-01 7:01 ` Albert ARIBAUD
2010-10-01 7:42 ` [U-Boot] ARM relocation, probably trivial mistake - back to original problem Reinhard Meyer
2010-10-01 8:27 ` Heiko Schocher
2010-10-01 10:44 ` Reinhard Meyer
2010-10-01 10:55 ` Wolfgang Denk
2010-10-01 11:03 ` Reinhard Meyer
2010-10-01 11:21 ` Wolfgang Denk
2010-10-01 11:37 ` Reinhard Meyer
2010-10-01 11:59 ` Wolfgang Denk
2010-10-01 12:22 ` Reinhard Meyer
2010-10-01 12:47 ` Reinhard Meyer
2010-10-01 12:55 ` Wolfgang Denk
2010-10-01 14:55 ` Reinhard Meyer
2010-10-02 8:53 ` Heiko Schocher
2010-10-01 15:47 ` Steve Sakoman
2010-10-02 7:15 ` [U-Boot] ARM relocation, question to Heiko Reinhard Meyer
[not found] ` <4CA6E517.9040701@fr<1286167382.22760.19.camel@ptyser-laptop>
2010-10-02 7:53 ` Albert ARIBAUD
2010-10-02 8:10 ` Reinhard Meyer
2010-10-02 8:26 ` Albert ARIBAUD
2010-10-03 18:04 ` Wolfgang Denk
2010-10-02 9:08 ` Heiko Schocher [this message]
2010-10-02 9:29 ` Albert ARIBAUD
2010-10-03 18:05 ` Wolfgang Denk
2010-10-02 10:17 ` Joakim Tjernlund
2010-10-02 16:21 ` J. William Campbell
2010-10-02 18:33 ` Reinhard Meyer
2010-10-03 18:22 ` Wolfgang Denk
2010-10-02 20:39 ` Reinhard Meyer
2010-10-02 21:09 ` Albert ARIBAUD
2010-10-02 23:07 ` Graeme Russ
2010-10-03 7:10 ` Albert ARIBAUD
2010-10-03 8:44 ` Graeme Russ
2010-10-03 8:58 ` Albert ARIBAUD
2010-10-03 15:36 ` J. William Campbell
2010-10-03 16:47 ` Albert ARIBAUD
2010-10-03 17:54 ` Albert ARIBAUD
2010-10-03 18:43 ` Wolfgang Denk
2010-10-04 5:41 ` Heiko Schocher
2010-10-03 18:29 ` Wolfgang Denk
2010-10-03 19:26 ` J. William Campbell
2010-10-04 5:52 ` Heiko Schocher
2010-10-03 18:14 ` Wolfgang Denk
2010-10-03 18:54 ` J. William Campbell
2010-10-03 19:52 ` Albert ARIBAUD
2010-10-03 18:03 ` Wolfgang Denk
2010-10-03 18:34 ` Albert ARIBAUD
2010-10-03 18:45 ` Wolfgang Denk
2010-10-04 6:08 ` Heiko Schocher
2010-10-04 6:40 ` Albert ARIBAUD
2010-10-04 7:27 ` Reinhard Meyer
2010-10-04 8:28 ` Albert ARIBAUD
2010-10-04 8:57 ` Heiko Schocher
2010-10-04 9:27 ` Albert ARIBAUD
2010-10-04 10:01 ` Joakim Tjernlund
2010-10-04 9:58 ` Graeme Russ
2010-10-04 14:17 ` Albert ARIBAUD
2010-10-04 14:25 ` Rogan Dawes
2010-10-04 15:24 ` Albert ARIBAUD
2010-10-04 16:31 ` Stefan Roese
2010-10-04 21:31 ` Albert ARIBAUD
2010-10-04 7:44 ` Albert ARIBAUD
2010-10-04 4:43 ` Peter Tyser
2010-10-04 6:08 ` Wolfgang Denk
2010-10-04 7:36 ` Joakim Tjernlund
2010-10-04 8:08 ` Albert ARIBAUD
2010-10-04 8:28 ` Joakim Tjernlund
2010-10-04 8:33 ` Albert ARIBAUD
[not found] ` <OF05779DA1.EF3C4954-ONC12577B2.00307A0D-C12577B2.0030B9C0@tran <4CAA1613.80002@comcast.net>
2010-10-04 8:52 ` Joakim Tjernlund
2010-10-04 9:10 ` Albert ARIBAUD
2010-10-04 10:13 ` Wolfgang Denk
2010-10-04 15:28 ` J. William Campbell
2010-10-04 15:52 ` Albert ARIBAUD
2010-10-04 17:06 ` Wolfgang Denk
2010-10-04 17:59 ` J. William Campbell
2010-10-04 18:43 ` Joakim Tjernlund
2010-10-04 21:10 ` Wolfgang Denk
2010-10-05 7:26 ` Joakim Tjernlund
2010-10-04 17:04 ` Graeme Russ
2010-10-04 17:14 ` Wolfgang Denk
2010-10-04 8:27 ` Wolfgang Denk
2010-10-02 8:49 ` [U-Boot] ARM relocation, probably trivial mistake - back to original problem Heiko Schocher
2010-10-01 12:49 ` Wolfgang Denk
2010-10-01 14:48 ` Reinhard Meyer
2010-10-04 7:44 ` [U-Boot] AT91 clock and timer cleanups (was: ARM relocation, probably trivial mistake - back to original problem) Reinhard Meyer
2010-10-04 8:32 ` Wolfgang Denk
2010-10-04 8:42 ` [U-Boot] AT91 clock and timer cleanups Reinhard Meyer
2010-10-04 8:49 ` Wolfgang Denk
2010-10-04 8:52 ` Reinhard Meyer
2010-10-04 9:03 ` Wolfgang Denk
2010-10-04 9:12 ` Reinhard Meyer
2010-10-04 14:58 ` Reinhard Meyer
2010-10-04 17:00 ` Wolfgang Denk
2010-10-04 17:15 ` Reinhard Meyer
2010-10-04 17:32 ` Wolfgang Denk
2010-10-04 19:22 ` Reinhard Meyer
2010-10-01 8:48 ` [U-Boot] ARM relocation, probably trivial mistake - back to original problem Wolfgang Denk
2010-10-01 9:50 ` Reinhard Meyer
2010-10-01 8:03 ` [U-Boot] ARM relocation, probably trivial mistake Wolfgang Denk
2010-10-01 7:51 ` Wolfgang Denk
2010-10-01 8:28 ` Heiko Schocher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CA6F687.1080600@denx.de \
--to=hs@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.