Re: [U-Boot] [PATCH 3/4] OneNAND: Introduce CONFIG_SYS_IPL_LOAD_ADDR

Acked-by: Kyungmin Park On Sun, Oct 3, 2010 at 2:33 AM, Marek Vasut wrote: > This allows to specify where the OneNAND IPL should load the U-Boot binary. > The > purpose of CONFIG_SYS_LOAD_ADDR is different I believe. > > On PXA, this is needed with OneNAND memories that expose only first 1kb of

Re: [U-Boot] [PATCH 4/4] OneNAND: Use generic_onenand_read_page in IPL

Hi, No it's used another place. that's reason not static function pointer. I'll update it soon. Thank you, Kyungmin Park On Sun, Oct 3, 2010 at 2:33 AM, Marek Vasut wrote: > There apparantly is no reason for having "onenand_read_page" abstracted. > Besides, it's static data which causes trouble

[U-Boot] u-boot cannot jump to board_init_f

Hi, Do you get the following problem while porting the u-boot for CN50XX? U-boot cannot jump to board_init_f. What reasons can lead to this problem? Thanks! Shuyou ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinf

Re: [U-Boot] [PATCH 32/37] Blackfin: blackvme: new board port

Mike: thanks a lot. Wojetk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Troubles accessing a USB mass storage device

l...@gnu.org (Ludovic Courtès) writes: > However, with a μSD card in, with a valid MS-DOS partition table, it > apparently fails to read from it: > > Marvell>> usb part > ## Unknown partition table Further investigation with all the debugging output enabled shows that it’s the ‘test unit ready’ c

Re: [U-Boot] ARM relocation, question to Heiko

On 03/10/10 08:09, Albert ARIBAUD wrote: > Le 02/10/2010 22:39, Reinhard Meyer a écrit : > >> And as an idea, if position independent code is used, only pointers >> in initialized data need adjustment. Cannot the linker emit a table >> of addresses that need fixing? > > IIU Bill C, yes the linker

Re: [U-Boot] ARM relocation, question to Heiko

Le 02/10/2010 22:39, Reinhard Meyer a écrit : > And as an idea, if position independent code is used, only pointers > in initialized data need adjustment. Cannot the linker emit a table > of addresses that need fixing? IIU Bill C, yes the linker can emit the information and the startup code coul

Re: [U-Boot] ARM relocation, question to Heiko

Dear J. William Campbell, > On 10/2/2010 3:17 AM, Joakim Tjernlund wrote: >>> 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. >> You

[U-Boot] [PATCH 37/37] Blackfin: otp: fix build after constification of args[]

The OTP code does a little shuffling of arguments that aren't really necessary, so use a local variable instead to fix build errors now that the args[] parameter is const. Signed-off-by: Mike Frysinger --- common/cmd_otp.c | 13 +++-- 1 files changed, 7 insertions(+), 6 deletions(-) d

[U-Boot] [PATCH 34/37] Blackfin: bf548-ezkit: bump SPI flash size up

The current size used (256KiB) is smaller than the LDR created for the bf548-ezkit, so 'run update' doesn't work correctly. So bump up the size a bit by making this flexible per-board config. Signed-off-by: Mike Frysinger --- include/configs/bf548-ezkit.h |1 + include/configs/bfin_adi_

[U-Boot] [PATCH 36/37] Blackfin: bf537-pnav: increase monitor len

Building this board for parallel flash fills up the bss section and thus fails to link, so bump up the monitor size a bit. Signed-off-by: Mike Frysinger --- include/configs/bf537-pnav.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/bf537-pnav.h b/inclu

[U-Boot] [PATCH 35/37] Blackfin: bf527-ad7160-eval: fix GPIO CS define

Rather than use a hardcoded "7", use the new Blackfin global define. Signed-off-by: Mike Frysinger --- include/configs/bf527-ad7160-eval.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/bf527-ad7160-eval.h b/include/configs/bf527-ad7160-eval.h index fb

[U-Boot] [PATCH 32/37] Blackfin: blackvme: new board port

From: Wojtek Skulski The board includes: * ADSP-BF561 rev. 0.5 * 32-bit SDRAM (2 * MT48LC16M16A2TG or MT48LC32M16A2TG) * Gigabit Ether AX88180 (ASIX) + 88E rev. B2 (Marvell) * SPI boot flash on PF2 (M25P64 8MB, or M25P128 16 MB) * FPGA boot flash on PF3 (M25P64 8MB, or M25P128 16 MB) *

[U-Boot] [PATCH 33/37] Blackfin: fix MMC init output alignment

Signed-off-by: Mike Frysinger --- arch/blackfin/lib/board.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/blackfin/lib/board.c b/arch/blackfin/lib/board.c index 94fbbfe..fcfd174 100644 --- a/arch/blackfin/lib/board.c +++ b/arch/blackfin/lib/board.c @@ -351,7 +351,

[U-Boot] [PATCH 31/37] Blackfin: propagate target cpu defines when building embedded env

Since we're no longer extracting the env from the target ELF file (since upstream wouldn't take that change), we're back to the problem of cpu defines not properly propagating to the env setup stage. So the embedded env built by the host compiler doesn't match the one that is linked into the u-boo

[U-Boot] [PATCH 30/37] Blackfin: cmd_gpio: accept upper case pin names

The intention all along was to accept pin names irrelevant of their case. But I guess I forgot to test/implement support for that. Signed-off-by: Mike Frysinger --- arch/blackfin/cpu/cmd_gpio.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/blackfin/cpu/cmd_gpi

[U-Boot] [PATCH 29/37] Blackfin: bf526-ezbrd: enable BootROM-OOB layout when booting from NAND

We need to use the Blackfin BootROM-specific OOB layout when we boot out of NAND as that is what the on-chip ROM expects. Also need to increase the monitor size a little to accommodate the extra NAND code overhead. Signed-off-by: Mike Frysinger --- include/configs/bf526-ezbrd.h |5 +++-- 1

[U-Boot] [PATCH 28/37] Blackfin: adi config: enable nand lock/unlock support

We use the lock/unlock options in our default nand code, so enabl support for the options. Reported-by: Vivi Li Signed-off-by: Mike Frysinger --- include/configs/bfin_adi_common.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/configs/bfin_adi_common.h b/inclu

[U-Boot] [PATCH 27/37] Blackfin: bct-brettl2: new board port

From: Peter Meerwald Signed-off-by: Peter Meerwald Signed-off-by: Mike Frysinger --- MAINTAINERS|4 + board/bct-brettl2/Makefile | 51 +++ board/bct-brettl2/bct-brettl2.c| 123 + board/bct-brettl2/cled.c | 3

[U-Boot] [PATCH 21/37] Blackfin: support a 3rd gpio cfi pin

From: Peter Meerwald Signed-off-by: Peter Meerwald Signed-off-by: Mike Frysinger --- board/cm-bf537e/gpio_cfi_flash.c | 15 ++- 1 files changed, 14 insertions(+), 1 deletions(-) diff --git a/board/cm-bf537e/gpio_cfi_flash.c b/board/cm-bf537e/gpio_cfi_flash.c index ab6af81..1075c

[U-Boot] [PATCH 26/37] Blackfin: adi config: allow boards to tweak a little more

Let people easily override bootdelay and network settings. Signed-off-by: Mike Frysinger --- include/configs/bfin_adi_common.h | 22 ++ 1 files changed, 14 insertions(+), 8 deletions(-) diff --git a/include/configs/bfin_adi_common.h b/include/configs/bfin_adi_common.h ind

[U-Boot] [PATCH 23/37] Blackfin: adi config: add a hook for boards to append the env

Signed-off-by: Mike Frysinger --- include/configs/bfin_adi_common.h |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/include/configs/bfin_adi_common.h b/include/configs/bfin_adi_common.h index bf3952c..55b8b0b 100644 --- a/include/configs/bfin_adi_common.h +++ b/incl

[U-Boot] [PATCH 24/37] Blackfin: bf527-sdp: new board port

Support for the Blackfin System Development Platform (SDP) base module. Signed-off-by: Mike Frysinger --- MAINTAINERS |1 + board/bf527-sdp/Makefile| 54 +++ board/bf527-sdp/bf527-sdp.c | 32 +++ board/bf527-sdp/config.mk | 36 +

[U-Boot] [PATCH 25/37] Blackfin: cmd_gpio: return gpio value to caller

Make the GPIO command usable in a scripting environment by returning the GPIO value rather than always 0. Signed-off-by: Mike Frysinger --- arch/blackfin/cpu/cmd_gpio.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/blackfin/cpu/cmd_gpio.c b/arch/blackfin/cpu/cmd_

[U-Boot] [PATCH 20/37] Blackfin: cmd_gpio: document/extend input sub-option

The input sub command was missing from the help text, and it didn't show the actual value currently read on the GPIO. This allows people to read the value of input pins. Signed-off-by: Mike Frysinger --- arch/blackfin/cpu/cmd_gpio.c | 27 +-- 1 files changed, 13 insert

[U-Boot] [PATCH 22/37] Blackfin: adi config: add an "all spi flashes" option to unify board lists

Signed-off-by: Mike Frysinger --- include/configs/bf533-stamp.h |5 + include/configs/bf537-stamp.h |5 + include/configs/bf538f-ezkit.h|5 + include/configs/bfin_adi_common.h | 12 4 files changed, 15 insertions(+), 12 deletions(-) diff --git a

[U-Boot] [PATCH 19/37] Blackfin: move CONFIG_BFIN_CPU to board config.mk

The CONFIG_BFIN_CPU option is largely used in the build system, so move it out of the board config.h and into the board config.mk. It'd be nice to keep everything in the config.h, but the patch to extract that value early was rejected. Signed-off-by: Mike Frysinger --- arch/blackfin/config.mk

[U-Boot] [PATCH 14/37] Blackfin: bf537: unify arch header duplication

Signed-off-by: Mike Frysinger --- arch/blackfin/include/asm/mach-bf537/BF534_def.h |2 + arch/blackfin/include/asm/mach-bf537/BF536_cdef.h |4 +- arch/blackfin/include/asm/mach-bf537/BF536_def.h | 13 +-- arch/blackfin/include/asm/mach-bf537/BF537_cdef.h | 173 +

[U-Boot] [PATCH 12/37] Blackfin: bf527-ad7160-eval: convert from old style MMR macros

The old MMR defines are being scrubbed, so convert the driver to use the new standard helper macros. Signed-off-by: Mike Frysinger --- board/bf527-ad7160-eval/bf527-ad7160-eval.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/board/bf527-ad7160-eval/bf527-ad7160-eval.c

[U-Boot] [PATCH 07/37] Blackfin: bfin_mac: convert from old style MMR macros

The old MMR defines are being scrubbed, so convert the driver to use the new standard helper macros. Signed-off-by: Mike Frysinger --- drivers/net/bfin_mac.c | 68 +-- 1 files changed, 36 insertions(+), 32 deletions(-) diff --git a/drivers/net/bfin_

[U-Boot] [PATCH 11/37] Blackfin: cm-bf548: video: convert from old style MMR macros

The old MMR defines are being scrubbed, so convert the driver to use the new standard helper macros. Signed-off-by: Mike Frysinger --- board/cm-bf548/video.c | 23 --- 1 files changed, 12 insertions(+), 11 deletions(-) diff --git a/board/cm-bf548/video.c b/board/cm-bf548/v

[U-Boot] [PATCH 10/37] Blackfin: bf548-ezkit: video: convert from old style MMR macros

The old MMR defines are being scrubbed, so convert the driver to use the new standard helper macros. Signed-off-by: Mike Frysinger --- board/bf548-ezkit/video.c | 21 +++-- 1 files changed, 11 insertions(+), 10 deletions(-) diff --git a/board/bf548-ezkit/video.c b/board/bf548-

[U-Boot] [PATCH 09/37] Blackfin: bf527-ezkit: video: convert from old style MMR macros

The old MMR defines are being scrubbed, so convert the driver to use the new standard helper macros. Signed-off-by: Mike Frysinger --- board/bf527-ezkit/video.c | 76 +++- 1 files changed, 40 insertions(+), 36 deletions(-) diff --git a/board/bf527-ezkit

[U-Boot] [PATCH 08/37] Blackfin: bf537-stamp: post: update old MMR style macros

The old MMR defines are being scrubbed, so convert the driver to use the new standard helper macros. For the GPIO MMR usage, convert to the new GPIO framework. Signed-off-by: Mike Frysinger --- board/bf537-stamp/post-memory.c | 54 +++--- board/bf537-stamp/post.c| 152 +++

[U-Boot] [PATCH 06/37] Blackfin: punt headers for non-existent BF541

There is no BF541 processor variant, so punt headers for it. Signed-off-by: Mike Frysinger --- arch/blackfin/include/asm/blackfin_cdef.h |3 - arch/blackfin/include/asm/blackfin_def.h |5 - arch/blackfin/include/asm/mach-bf548/BF541_cdef.h | 323 - a

[U-Boot] [PATCH 05/37] Blackfin: unify gpio cfi implementations

Signed-off-by: Mike Frysinger --- board/cm-bf527/cm-bf527.c|2 +- board/cm-bf527/gpio_cfi_flash.c | 63 ++ board/cm-bf527/gpio_cfi_flash.h | 10 -- board/cm-bf537e/gpio_cfi_flash.c | 20 +--- board/cm-bf537u/cm-bf537u.c |

[U-Boot] [PATCH 03/37] Blackfin: bfin_spi: add optional DMA support

This moves the last piece from the old spi_flash driver to the new SPI framework -- optional DMA RX support. This typically cuts speeds by ~40% at the cost of additional ~300 bytes. Signed-off-by: Mike Frysinger --- arch/blackfin/include/asm/dma.h | 75 +++ drivers/spi/bfin_sp

[U-Boot] [PATCH 04/37] Blackfin: bfin_sdh: clean up send_cmd

Simplify the command setup and status checking steps, and add a proper timeout to the status polling code to avoid possible infinite hangs. Signed-off-by: Mike Frysinger --- drivers/mmc/bfin_sdh.c | 25 +++-- 1 files changed, 15 insertions(+), 10 deletions(-) diff --git a/

[U-Boot] [PATCH 00/37] Blackfin updates for v2010.12-rc1

The big highlight here are major cleanups of the Blackfin MMR headers. People in the past (mostly Wolfgang ;]) have complained about the amount of duplication seen in these files, so I spent a lot of time unifying them and punting unused crap. I'm still not done, but I'm at least to a "stable" poi

[U-Boot] [RFC PATCH 1/2 v2] nand: allow delayed initialization

Many people like the current nand_init() behavior where it is always initialized during boot and the flash size shown, but there are cases where we are willing to forgo this niceness for speed/functionality. So rather than change the default, introduce a delayed config option people may enable. Th

[U-Boot] [PATCH] cmd_elf: add an option for loading ELFs according to PHDRs

The current ELF loading function does a lot of work above and beyond a simple "loading". It ignores the real load addresses and loads things into their virtual (runtime) address. This is undesirable when we just want it to load an ELF and let the ELF do the actual C runtime init. So add a comman

Re: [U-Boot] [PATCH 2/4] OneNAND: Fixup command table on reloc

Dear Marek Vasut, On 3 October 2010 03:59, Marek Vasut wrote: > Dne So 2. října 2010 20:28:19 Minkyu Kang napsal(a): >> Dear Vasut, >> >> On 3 October 2010 02:33, Marek Vasut wrote: >> > Signed-off-by: Marek Vasut >> > --- >> >  arch/arm/lib/board.c |    6 ++ >> >  common/cmd_onenand.c |  

Re: [U-Boot] [PATCH 2/4] OneNAND: Fixup command table on reloc

Dne So 2. října 2010 20:28:19 Minkyu Kang napsal(a): > Dear Vasut, > > On 3 October 2010 02:33, Marek Vasut wrote: > > Signed-off-by: Marek Vasut > > --- > > arch/arm/lib/board.c |6 ++ > > common/cmd_onenand.c |6 ++ > > 2 files changed, 12 insertions(+), 0 deletions(-) > > >

[U-Boot] Would somebody block this please?

It is already 5th or more same spam email in a row. Does anybody care? --- ** * k...@homeKOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * *

Re: [U-Boot] ARM relocation, question to Heiko

Dear all, thanks for all the info. My AT91 boards will not use relocation for the time being, and if relocation is god-like enforced I will find a way not to use it. I don't need to spend 10% more code for all that trouble. Reinhard ___ U-Boot mailing

Re: [U-Boot] [PATCH 2/4] OneNAND: Fixup command table on reloc

Dear Vasut, On 3 October 2010 02:33, Marek Vasut wrote: > Signed-off-by: Marek Vasut > --- >  arch/arm/lib/board.c |    6 ++ >  common/cmd_onenand.c |    6 ++ >  2 files changed, 12 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c > index 5f2dfd0

[U-Boot] [PATCH 2/4] OneNAND: Fixup command table on reloc

Signed-off-by: Marek Vasut --- arch/arm/lib/board.c |6 ++ common/cmd_onenand.c |6 ++ 2 files changed, 12 insertions(+), 0 deletions(-) diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index 5f2dfd0..07995ba 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@

[U-Boot] [PATCH 4/4] OneNAND: Use generic_onenand_read_page in IPL

There apparantly is no reason for having "onenand_read_page" abstracted. Besides, it's static data which causes trouble. Signed-off-by: Marek Vasut --- onenand_ipl/onenand_read.c |9 +++-- 1 files changed, 3 insertions(+), 6 deletions(-) diff --git a/onenand_ipl/onenand_read.c b/onenand

[U-Boot] [PATCH 3/4] OneNAND: Introduce CONFIG_SYS_IPL_LOAD_ADDR

This allows to specify where the OneNAND IPL should load the U-Boot binary. The purpose of CONFIG_SYS_LOAD_ADDR is different I believe. On PXA, this is needed with OneNAND memories that expose only first 1kb of data, which is insufficient for SDRAM init. U-Boot can then be copied into SRAM. Signe

[U-Boot] [PATCH 1/4] OneNAND: Move largepage_memorybased

This moves "struct nand_bbt_descr largepage_memorybased" into "onenand_default_bbt" as that's the only place where this is used. This also removes an entry from .data section. (For me, this section disappears after relocation). Signed-off-by: Marek Vasut --- drivers/mtd/onenand/onenand_bbt.c |

Re: [U-Boot] ARM relocation, question to Heiko

On 10/2/2010 3:17 AM, Joakim Tjernlund wrote: 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 n

[U-Boot] strcmp UBoot command

Hello. let me introduce myself. I'm low-level developer working on AROS (AROS Research Operating System, http://www.aros.org/). Currently I'm working for Genesi company where I'm responsible for e.g. UBoot port for the EfikaMX Smarttop and smartbook ARM-based machines. See http://www.genesi-usa.co

Re: [U-Boot] [PATCH] OneNAND: Destaticize largepage_memorybased

Dne So 2. října 2010 16:26:07 Marek Vasut napsal(a): > This moves "struct nand_bbt_descr largepage_memorybased" into .data.rel, > which allows it to be PIC with current U-Boot infrastructure for > relocation. > > Also, I squished the ff_patternt into the structure. Please ignore this one, the lin

[U-Boot] [PATCH] OneNAND: Destaticize largepage_memorybased

This moves "struct nand_bbt_descr largepage_memorybased" into .data.rel, which allows it to be PIC with current U-Boot infrastructure for relocation. Also, I squished the ff_patternt into the structure. Signed-off-by: Marek Vasut --- drivers/mtd/onenand/onenand_bbt.c |6 ++ 1 files chan

Re: [U-Boot] x-loader question

On Fri, Oct 1, 2010 at 10:59 PM, John Tobias wrote: > Hi Steve, > Thanks for the response. The processor is OMAP4 and I am in the last stage > of bringing up the board. I took the source code from the omapzoom git tree. > How do I know if pre or post relocation changes? If you took the code from

Re: [U-Boot] Add new NAND flash

Hi Scott Am 01.10.2010 21:52, schrieb Scott Wood: > On Fri, 1 Oct 2010 16:31:40 +0200 >> MT29F16G08CBABA >> The NAND is connected (8 bit wide) to an iMX25 which is booting from >> NOR. So the NAND is only a mass storage device. I am able to read the ID >> of the chip. >> >> 2Ch 48h 04h 46h 85h >

[U-Boot] Guaranteed loan offer**APPLY NOW**contact via email**bt48hrsfinancerdesk...@gmail.com**

We are currently giving out loans to any part of the world at 2% interest rate. If interested, send your name, Resident country and Phone number to Mr. Bernard Thompson with the email address bellow Email: 48hrsfinancerdesk...@gmail.com or call: +447024053959 Regards B&T 48HRS FINANCE LOAN ___

Re: [U-Boot] ARM relocation, question to Heiko

> 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? >

Re: [U-Boot] ARM relocation, question to Heiko

Le 02/10/2010 11:08, Heiko Schocher a écrit : >>> 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

Re: [U-Boot] ARM relocation, question to Heiko

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 Reg

Re: [U-Boot] [PATCH] board_init_r: Removed unused cmdtp variable

Hello Richard, Richard Retanubun wrote: > From 38c6ceb464f63d3705d30d6603624e7d0933f428 Mon Sep 17 00:00:00 2001 > From: Richard Retanubun > Date: Fri, 1 Oct 2010 10:17:26 -0400 > Subject: [PATCH] board_init_r: Removed unused cmdtp variable > > Follow up to commit 620f1f6a64095ed558e68d37f1965d0

Re: [U-Boot] ARM relocation, probably trivial mistake - back to original problem

Hello Reinhard, Reinhard Meyer wrote: > Dear Wolfgang Denk, >>> The environment issues still persist. I am at a loss >>> there now. >>> >>> Observation: the old style commands "setenv", "printenv", etc. >>> work, but any "env" command except for "env" alone crashes. >> OK. If "printenv" works and

Re: [U-Boot] ARM relocation, probably trivial mistake - back to original problem

Hello Wolfgang, Reinhard, Wolfgang Denk wrote: > Dear Reinhard Meyer, > > In message <4ca5d857.5010...@emk-elektronik.de> you wrote: >> The environment issues still persist. I am at a loss >> there now. >> >> Observation: the old style commands "setenv", "printenv", etc. >> work, but any "env" co

Re: [U-Boot] ARM relocation, question to Heiko

Le 02/10/2010 10:10, Reinhard Meyer a écrit : > 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? >>> >>> B

Re: [U-Boot] ARM relocation, question to Heiko

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 an

Re: [U-Boot] ARM relocation, question to Heiko

Le 02/10/2010 09:15, Reinhard Meyer a écrit : > Hello Heiko, > > 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, > Rei

Re: [U-Boot] ARM relocation, question to Heiko

Hello Heiko, 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 ___ U-Boot m