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
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
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
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
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
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
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
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
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
> 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?
>
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
___
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
>
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
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
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
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
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
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 |
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
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
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
@@
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
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
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. *
*
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(-)
> >
>
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 |
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
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
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
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/
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
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 |
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
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 +++
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
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-
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
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_
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
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 +
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
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
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
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_
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 +
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
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
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
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
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
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
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
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
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,
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)
*
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
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
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_
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
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
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
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
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
Mike:
thanks a lot.
Wojetk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
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
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
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
67 matches
Mail list logo
