On Thu, 2009-10-08 at 13:30 +0200, Alessandro Rubini wrote:
From: Alessandro Rubini rub...@unipv.it
Signed-off-by: Alessandro Rubini rub...@unipv.it
Acked-by: Andrea Gallo andrea.ga...@stericsson.com
---
lib_generic/string.c | 17 +
1 files changed, 13 insertions(+), 4
On Thu, 2009-10-08 at 08:53 -0700, J. William Campbell wrote:
Peter Tyser wrote:
On Thu, 2009-10-08 at 22:54 +1100, Graeme Russ wrote:
Out of curiosity, I wanted to see just how much of a size penalty I am
incurring by using gcc -fpic / ld -pic on my x86 u-boot build. Here
On Thu, 2009-10-08 at 18:00 +0200, Alessandro Rubini wrote:
No interest in the suggestion to not require count to be an exact
multiple of 4/8?
Actually, I wrote about that in my patch 0/3.
Sorry, I should have read more thoroughly.
I don't think it would be that hard to update the logic
On Thu, 2009-10-08 at 20:23 +0200, Alessandro Rubini wrote:
That's true, but I think the most important case is lcd scrolling,
where it's usually a big power of two -- that's where we had the #ifdef,
so the problem was known, I suppose.
I think the most important case for *you* is lcd
On Fri, 2009-10-09 at 09:02 +1100, Graeme Russ wrote:
On Fri, Oct 9, 2009 at 8:23 AM, Wolfgang Denk w...@denx.de wrote:
Dear Graeme Russ,
In message d66caabb0910081358h5b013922tf7f9dce4cce41...@mail.gmail.com
you wrote:
Once the reloc branch has been merged, how many arches are
It seems like a clean solution. Adding a bss-aware fixup routine or
putting the bss after the U-Boot image both seem good to me. The
bss-aware fixup routine has a clearer readelf output and slightly more
complicated code while the bss-after-uboot change has a misleading
readelf output
Hi Alessandro,
--- a/lib_generic/string.c
+++ b/lib_generic/string.c
@@ -449,7 +449,16 @@ char * bcopy(const char * src, char * dest, int count)
void * memcpy(void * dest,const void *src,size_t count)
{
char *tmp = (char *) dest, *s = (char *) src;
+ u32 *d32 = (u32 *)dest,
at link time.
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
Changes since v1:
- Updated commit title and description
- Cleaned up logic to determine if we need to fixup bss address
cpu/mpc85xx/u-boot.lds | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/cpu
Hi Jocke,
v2: included ppc4xx too.
Looks like cpu/74xx_7xx is missing too:(
cpu/mpc512x/start.S |6 --
cpu/mpc5xx/start.S |6 --
cpu/mpc5xxx/start.S |6 --
cpu/mpc8220/start.S |6 --
cpu/mpc824x/start.S |6 --
cpu/mpc8260/start.S |6 --
On Tue, 2009-10-06 at 09:28 +0200, Wolfgang Denk wrote:
Dear Peter Tyser,
In message 1254783670-21301-2-git-send-email-pty...@xes-inc.com you wrote:
This allows for fancy conditionals and inclusions
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
cpu/mpc85xx/config.mk
On Tue, 2009-10-06 at 09:32 +0200, Wolfgang Denk wrote:
Dear Peter Tyser,
In message 1254783670-21301-1-git-send-email-pty...@xes-inc.com you wrote:
It looks like the 85xx platform is the only one which has boards
with the bss at 0x0. It uses a slightly different linker script
format
--- a/cpu/mpc85xx/u-boot.lds.S
+++ b/cpu/mpc85xx/u-boot.lds.S
@@ -131,6 +131,14 @@ SECTIONS
. = RESET_VECTOR_ADDRESS + 0x4;
+ /*
+ * Make sure that the bss segment doesn't start at 0x0, otherwise its
+ * address won't be updated during relocation fixups
+ */
On Tue, 2009-10-06 at 09:07 -0500, Kumar Gala wrote:
This whole bss at 0x0 is a myth to me.
Do a readelf on most MPC8548 boards, eg MPC8548CDS. __bss_start is
also
located at 0x0 for these boards, which is the issue this patch
attempted
to address.
I know that this _is_ the
On Tue, 2009-10-06 at 17:04 +0200, Wolfgang Denk wrote:
Dear Kumar Gala,
In message 1de23de0-b901-4e15-845c-43889ee0b...@kernel.crashing.org you
wrote:
...
But bss is NOLOAD, and the actual location in the flash is just a
fiction - we never use anything of this but the start
Hi Wolfgang,
So far U-Boot is actually a 32 bit boot loader; address calculations
like this just wrap around. So far this has not caused problems yet;
what has caused problems is that we can have overlapping sections on
4xx. Also it's probably overkill that each board has it's own linker
On Tue, 2009-10-06 at 19:51 +0200, Wolfgang Denk wrote:
Dear Peter Tyser,
In message 1254843932.24664.2083.ca...@localhost.localdomain you wrote:
I personally like the current implementation of putting the bss after
the entire U-Boot image. It keeps U-Boot's code, malloc pool, stack
On Tue, 2009-10-06 at 13:34 -0700, J. William Campbell wrote:
Peter Tyser wrote:
On Tue, 2009-10-06 at 19:51 +0200, Wolfgang Denk wrote:
Dear Peter Tyser,
In message 1254843932.24664.2083.ca...@localhost.localdomain you wrote:
I personally like the current implementation
On Tue, 2009-10-06 at 15:46 -0500, Kumar Gala wrote:
On Oct 6, 2009, at 1:08 PM, Peter Tyser wrote:
On Tue, 2009-10-06 at 19:51 +0200, Wolfgang Denk wrote:
Dear Peter Tyser,
In message 1254843932.24664.2083.ca...@localhost.localdomain you
wrote:
I personally like the current
On Tue, 2009-10-06 at 15:34 -0700, J. William Campbell wrote:
Peter Tyser wrote:
On Tue, 2009-10-06 at 13:34 -0700, J. William Campbell wrote:
Peter Tyser wrote:
On Tue, 2009-10-06 at 19:51 +0200, Wolfgang Denk wrote:
Dear Peter Tyser,
In message
On Wed, 2009-10-07 at 01:07 +0200, Wolfgang Denk wrote:
Dear Peter Tyser,
In message 1254862383.24664.2742.ca...@localhost.localdomain you wrote:
What's the advantage of having the bss not be located next to U-Boot?
One advantage is that we might chose the same address for all boards
The values all changed and are dependent on RAM size, but their
relationship to one another didn't - they all just increased by
0x7fff. So practically speaking, we do need to know where the bss
is at link time - its address is not dynamic like the malloc pool or
stack - its tied
On Tue, 2009-10-06 at 18:43 -0500, Peter Tyser wrote:
The values all changed and are dependent on RAM size, but their
relationship to one another didn't - they all just increased by
0x7fff. So practically speaking, we do need to know where the bss
is at link time - its address
Hi Paul,
diff --git a/cpu/mpc8xxx/ddr/util.c b/cpu/mpc8xxx/ddr/util.c
index 4451989..d0f61a8 100644
--- a/cpu/mpc8xxx/ddr/util.c
+++ b/cpu/mpc8xxx/ddr/util.c
@@ -89,16 +89,16 @@ __fsl_ddr_set_lawbar(const common_timing_params_t
*memctl_common_params,
?
Hi Wolfgang,
My fix to the linker script was to change:
__bss_start = .;
into:
__bss_start = . | 4;
ie, a big hack, but it did work:) I'll take a peek at a more proper
link script workaround.
32 bit alignment of the BSS segment might not be sufficient. Be
careful!
I've tried
This allows for fancy conditionals and inclusions
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
cpu/mpc85xx/config.mk |2 +-
cpu/mpc85xx/{u-boot-nand.lds = u-boot-nand.lds.S} |0
cpu/mpc85xx/{u-boot.lds = u-boot.lds.S} |0
3 files changed, 1
a NULL value.
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
cpu/mpc85xx/u-boot.lds.S |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/cpu/mpc85xx/u-boot.lds.S b/cpu/mpc85xx/u-boot.lds.S
index a347cd1..ef3de66 100644
--- a/cpu/mpc85xx/u-boot.lds.S
+++ b/cpu
they don't have this issue.
I verified this by running MAKEALL and printing the bss address
as well.
A few bytes of RAM are wasted for boards which used to have the
bss at 0x0 FWIW.
These changes should be applied to the reloc branch.
Peter Tyser (2):
85xx: Preprocess link scripts
85xx: Ensure BSS
Hi Jocke,
There are a few change which would further improve relocation that Jocke
and I want to get merged. Whether these improvements occur in this
release or the next is not a big deal to me.
1. Fix relocation of NULL pointers.
eg the following code would print the relocation
On Sat, 2009-10-03 at 14:13 +0200, Wolfgang Denk wrote:
Dear Joakim Tjernlund,
In message
of3474ed49.c18da041-onc1257644.0033adeb-c1257644.00341...@transmode.se you
wrote:
It seems discussion stopped here. Is it correct forme to assume that
there is no patch available yet that is
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
This should be squashed with the top-most commit in the
reloc branch.
Ideally we could fold
[PATCH/RFC] arm/microblaze/nios/nios2/sh: Remove relocation fixups
into the reloc branch too so we don't have to increment XF_VERSION
again in the next
On Mon, 2009-09-28 at 09:34 +0200, Joakim Tjernlund wrote:
Peter Tyser pty...@xes-inc.com wrote on 28/09/2009 06:31:28:
On Sun, 2009-09-27 at 15:15 +0200, Joakim Tjernlund wrote:
Wolfgang Denk w...@denx.de wrote on 23/09/2009 20:23:14:
Dear Peter Tyser,
In message
snip
Anyhow, I have also been thinking/working on making U-boot
fully PIC and reached a important conclusion. The GOT holds absolute
ptr values and there is not much one can do about it sans modifying
gcc.
So before u-boot is relocated to RAM one must manually add
On Mon, 2009-09-28 at 16:41 +0200, Joakim Tjernlund wrote:
Peter Tyser pty...@xes-inc.com wrote on 28/09/2009 14:45:46:
On Mon, 2009-09-28 at 09:34 +0200, Joakim Tjernlund wrote:
Peter Tyser pty...@xes-inc.com wrote on 28/09/2009 06:31:28:
On Sun, 2009-09-27 at 15:15 +0200, Joakim
On Sun, 2009-09-27 at 15:15 +0200, Joakim Tjernlund wrote:
Wolfgang Denk w...@denx.de wrote on 23/09/2009 20:23:14:
Dear Peter Tyser,
In message 1253710639.3968.19.ca...@ptyser-laptop you wrote:
My fix to the linker script was to change:
__bss_start = .;
into:
__bss_start
On Thu, 2009-09-24 at 11:21 +0200, Stefan Roese wrote:
On Wednesday 23 September 2009 19:51:24 Niklaus Giger wrote:
Adds a HCU5 board specific cmd reghcu5 to dump about 140 internal
register which define the HW configuration. Needed for documentation
purposes and to compare different
snip
+ switch (ppc440epx_reg[i].address) {
+ case 0x00b0:
+ value = mfdcr ( 0x00b0 );
Please drop the spaces around the braces:
value = mfdcr(0x00b0);
Also in the other cases below.
snip
On Thu, 2009-09-24 at 00:31 +0200, Wolfgang Denk wrote:
Dear Peter Tyser,
In message 1253550038-16734-1-git-send-email-pty...@xes-inc.com you wrote:
This series attempts to fix relocation to RAM for ppc boards.
I split the patches up pretty liberally, let me know if you'd like
them
On Wed, 2009-09-23 at 13:51 +0200, Joakim Tjernlund wrote:
NULL is an absolute value and should not be relocated.
After this correction code like:
void weak_fun(void) __attribute__((weak));
printf(weak_fun:%p\n, weak_fun);
will still print null after relocation.
Signed-off-by: Joakim
I made the same changes recently, but ran into an issue that prevented
me from sending the change upstream. Some boards/arches have the bss at
address 0 and later relocate it, unlike every other NULL pointer. If
you don't fix up the bss address, the board will not function. If you
Hi Niklaus,
+enum REGISTER_TYPE {
+ DCR,/* Directly Accessed DCR's */
+ IDCR1, /* Indirectly Accessed DCR to SDRAM0_CFGADDR
and SDRAM0_CFGDATA */
+ IDCR2, /* Indirectly Accessed DCR to EBC0_CFGADDR and
EBC0_CFGDATA */
+
In message 1253550038-16734-14-git-send-email-pty...@xes-inc.com you wrote:
Now that proper relocation is supported, the reloc_off field is no longer
necessary.
Note that the location of the standalone application jump table pointer
in the global data structure is affected by this
On Thu, 2009-09-24 at 00:31 +0200, Wolfgang Denk wrote:
Dear Peter Tyser,
In message 1253550038-16734-1-git-send-email-pty...@xes-inc.com you wrote:
This series attempts to fix relocation to RAM for ppc boards.
I split the patches up pretty liberally, let me know if you'd like
them
scripts for ppc
boards:)
Peter Tyser (13):
ppc: Enable full relocation to RAM
ppc: Check for compilers that don't support relocation
ppc: Remove board.c relocation fixups
ppc: Remove pci config table pointer relocation fixups
ppc: Remove extable relocation fixups
ppc
in the global data structure is affected by this change, breaking
execution of standalone applications compiled for previous versions of
U-Boot.
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
I apparently forgot to send this yesterday with the rest of the
relocation patches.
If the ppc relocation series
On Tue, 2009-09-22 at 10:03 -0500, Tom wrote:
Minkyu Kang wrote:
Adds new board SMDKC100 that uses s5pc100 SoC
Signed-off-by: Minkyu Kang mk7.k...@samsung.com
Signed-off-by: HeungJun, Kim riverful@samsung.com
---
Changes since v1:
- arrange env values for more readable
- make
Please include a brief readme doc/README.s5pc1xx similar to README.omap
Hi Tom,
Others may disagree, but I'm personally opposed to creating
Slugfest over documentation!
Nothing gets me more worked up than a documentation discussion:)
I can see you point. If you have the board you
:)
Peter Tyser (13):
ppc: Enable full relocation to RAM
ppc: Check for compilers that don't support relocation
ppc: Remove board.c relocation fixups
ppc: Remove pci config table pointer relocation fixups
ppc: Remove extable relocation fixups
ppc: Remove board-specific command table
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
lib_ppc/board.c | 50 --
1 files changed, 0 insertions(+), 50 deletions(-)
diff --git a/lib_ppc/board.c b/lib_ppc/board.c
index e8509ee..4123e73 100644
--- a/lib_ppc/board.c
+++ b/lib_ppc/board.c
-off-by: Peter Tyser pty...@xes-inc.com
---
lib_ppc/Makefile |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/lib_ppc/Makefile b/lib_ppc/Makefile
index 60ea0c9..399b41e 100644
--- a/lib_ppc/Makefile
+++ b/lib_ppc/Makefile
@@ -42,6 +42,12 @@ SRCS := $(SOBJS-y:.o=.S
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
lib_ppc/extable.c | 26 ++
1 files changed, 6 insertions(+), 20 deletions(-)
diff --git a/lib_ppc/extable.c b/lib_ppc/extable.c
index 91e2b3d..7408d5c 100644
--- a/lib_ppc/extable.c
+++ b/lib_ppc/extable.c
@@ -53,27
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
board/digsy_mtc/cmd_mtc.c | 30 --
board/digsy_mtc/digsy_mtc.c |2 --
board/inka4x0/inka4x0.c | 10 --
board/inka4x0/inkadiag.c| 28
include/configs/inka4x0.h
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
board/freescale/mpc8548cds/mpc8548cds.c |7 ---
board/mpl/common/pci.c | 18 --
board/sbc8548/sbc8548.c |6 --
3 files changed, 0 insertions(+), 31 deletions(-)
diff --git a/board
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
drivers/net/tsec.c | 49 -
1 files changed, 0 insertions(+), 49 deletions(-)
diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
index 5c3d261..3f74118 100644
--- a/drivers/net/tsec.c
+++ b
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
post/board/lwmon/sysmon.c | 17 +
post/board/lwmon5/sysmon.c | 17 +
2 files changed, 2 insertions(+), 32 deletions(-)
diff --git a/post/board/lwmon/sysmon.c b/post/board/lwmon/sysmon.c
index 79a5151..fc828b2
PPC boards are the only users of the current FPGA code which is littered
with manual relocation fixups. Now that proper relocation is supported
for PPC boards, remove FPGA manual relocation.
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
board/esd/pmc440/fpga.c |6 +-
board
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
board/mpl/common/memtst.c | 26 --
board/mpl/mip405/mip405.c |3 +--
board/mpl/pati/pati.c |2 --
board/mpl/vcma9/vcma9.c |3 ---
4 files changed, 1 insertions(+), 33 deletions(-)
diff --git a/board/mpl
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
board/prodrive/p3mx/p3mx.c | 10 --
include/configs/p3mx.h |1 -
2 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/board/prodrive/p3mx/p3mx.c b/board/prodrive/p3mx/p3mx.c
index 0247bb8..05eca52 100644
--- a/board
-Boot.
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
Would others prefer an empty ulong take reloc_off's place so old
standalone apps don't break? Or perhaps we should move the jump
table pointer to the first item in global_data to prevent breakage
every time global_data is modified
Add #ifdefs where necessary to not perform relocation fixups. This
allows boards/architectures which support relocation to trim a decent
chunk of code.
Note that this patch doesn't add #ifdefs to architecture-specific code
which does not support relocation.
Signed-off-by: Peter Tyser pty...@xes
On Mon, 2009-09-21 at 12:49 -0400, Paul Gortmaker wrote:
On Mon, Sep 21, 2009 at 12:20 PM, Peter Tyser pty...@xes-inc.com wrote:
Signed-off-by: Peter Tyser pty...@xes-inc.com
It looks like something happened during the send of your patches;
it seems the long log of what you are trying
to quickly
determine which boards are broken.
As a side benefit, no empty $BOARD.ERR files are generated by MAKEALL.
Previously, each board had a corresponding $BOARD.ERR file, even if the
board compiled cleanly.
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
Changes since v1:
- Fix issue where
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
MAKEALL |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/MAKEALL b/MAKEALL
index fd06d8d..1e7ec20 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -9,7 +9,7 @@ trap print_stats 0
if [ $BUILD_NCPUS -gt 1 ]
then
- JOBS=-j
Using the common 86xx fdt fixups removes some board-specific code and
should make the mpc8610hpcd easier to maintain in the long run.
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
board/freescale/mpc8610hpcd/mpc8610hpcd.c | 14 +-
2 files changed, 1 insertions(+), 14 deletions
+# Print statistics when ctrl-c is pressed
+trap print_stats; exit 2
Why only on signal 2? Usually we use 1 2 3 15 in such cases.
2's the only case I've ever used for MAKEALL, I'll add the other cases
as you suggest.
Also, you might add 0 here and then...
@@ -932,3 +956,5 @@ do
On Fri, 2009-09-18 at 21:21 -0500, Nishanth Menon wrote:
This is questionable if this is really required
as the av_ static initalized values should have
been loaded to sdram as part of the boot process
and initialization should have been done.
Is there a reason you need to do this fixup?
to quickly
determine which boards are broken.
As a side benefit, no empty $BOARD.ERR files are generated by MAKEALL.
Previously, each board had a corresponding $BOARD.ERR file, even if the
board compiled cleanly.
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
Changes since v1:
- Fix issue where
On Sat, 2009-09-19 at 10:37 -0500, Nishanth Menon wrote:
Peter Tyser said the following on 09/19/2009 09:03 AM:
On Fri, 2009-09-18 at 21:21 -0500, Nishanth Menon wrote:
This is questionable if this is really required
as the av_ static initalized values should have
been loaded
On Thu, 2009-09-17 at 09:06 +0200, Joakim Tjernlund wrote:
When preparing the ppc relocation patches I noticed that the gcc
-mrelocatable compiler flag increases the .reloc section by 3 or 4
Kbytes. I did a compile test, and this increase pushes the ALPR board
back over
On Fri, 2009-09-18 at 16:52 +0200, Joakim Tjernlund wrote:
Peter Tyser pty...@xes-inc.com wrote on 18/09/2009 16:28:35:
On Thu, 2009-09-17 at 09:06 +0200, Joakim Tjernlund wrote:
When preparing the ppc relocation patches I noticed that the gcc
-mrelocatable compiler flag
Sorry, I don't have an example. Just a guess, weak function references:
void weak_fun(void) __attribute__ ((weak));
if (weak_fun)
weak_fun();
Using default weak functions as well as overridden weak functions both
definitely work. So the pointers must be being updated
to quickly
determine which boards are broken.
As a side benefit, no empty $BOARD.ERR files are generated by MAKEALL.
Previously, each board had a corresponding $BOARD.ERR file, even if the
board compiled cleanly.
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
MAKEALL | 30
to quickly
determine which boards are broken.
As a side benefit, no empty $BOARD.ERR files are generated by MAKEALL.
Previously, each board had a corresponding $BOARD.ERR file, even if the
board compiled cleanly.
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
Changes since v1:
- Fix issue where
to quickly
determine which boards are broken.
As a side benefit, no empty $BOARD.ERR files are generated by MAKEALL.
Previously, each board had a corresponding $BOARD.ERR file, even if the
board compiled cleanly.
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
Changes since v1:
- Fix issue where
On Thu, 2009-09-17 at 09:06 +0200, Joakim Tjernlund wrote:
When preparing the ppc relocation patches I noticed that the gcc
-mrelocatable compiler flag increases the .reloc section by 3 or 4
Kbytes. I did a compile test, and this increase pushes the ALPR board
back over 256K (it
On Wednesday 16 September 2009 15:32:26 Wolfgang Denk wrote:
The reorganization of the ARM custodian setup has caused some changes
to the workflow, and I wonder if we should allow for a longer merge
window?
What do you think about stretching the MW by another week (with or
without
On Mon, 2009-09-14 at 23:26 +0200, Wolfgang Denk wrote:
Dear Peter Tyser,
In message 1252709159-22326-1-git-send-email-pty...@xes-inc.com you wrote:
** This patch is only meant to allow others to test relocation, it
should not be applied!! **
This patch is a quick hack to enable
are
also removed.
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
Changes since v1:
- Removed all references to autoscript and autoscript_uname, previously
just the autoscr command was removed.
README |8
board/LEOX/elpt860/README.LEOX
Remove board-specific #ifdefs for calling misc_init_r() during
initializtion
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
include/configs/CCM.h|1 +
include/configs/CPCI405.h|1 +
include/configs/CPCI4052.h |1 +
include/configs/CPCI405AB.h |1
Remove board-specific #ifdefs for calling phy_reset() during
initializtion
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
include/configs/CCM.h|1 +
include/configs/ELPT860.h|1 +
include/configs/IP860.h |1 +
include/configs/IVML24.h |2 ++
include
Hi Kumar,
I see you guys set LCRR in the config.h. You are using
LCRR_CLKDIV_4. Do you think this means clk/4? (I ask because the
defines aren't correct, and wasn't sure about your expectation).
I faintly remember punching the numbers for LCRR a while back, then
blindly replacing the
:
clk/4: CLKDIV = 2
clk/8: CLKDIV = 4
clk/16: CLKDIV = 8
Ensure that the MPC86xx and MPC85xx still get the same behavior and make
the the defines reflect their logical view (not the value of the field).
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
Acked-by: Peter Tyser pty...@xes
On Tue, 2009-09-15 at 23:11 -0500, Kumar Gala wrote:
On Sep 15, 2009, at 10:32 PM, Peter Tyser wrote:
On Tue, 2009-09-15 at 22:26 -0500, Kumar Gala wrote:
For some reason the CLKDIV field varies between SoC in how it
interprets
the bit values.
All 83xx and early (e500v1) PQ3
On Mon, 2009-09-14 at 23:26 +0200, Wolfgang Denk wrote:
Dear Peter Tyser,
In message 1252709159-22326-1-git-send-email-pty...@xes-inc.com you wrote:
** This patch is only meant to allow others to test relocation, it
should not be applied!! **
This patch is a quick hack to enable
** This patch is only meant to allow others to test relocation, it
should not be applied!! **
This patch is a quick hack to enable proper relocation on powerpc
boards. I tested on some mpc85xx-based boards.
I updated the common ppc config.mk and u-boot.lds in cpu/ as needed, but
didn't bother
Hi Wolfgang,
Does anyone out there by chance have a failure case for gcc 4.0.0,
because I can't seem to reproduce the issues others had in the past.
Do you have an up-to-date patch that can be used for such testing?
I just sent an example patch (ppc: Relocation test patch) that others
On Thu, 2009-08-27 at 12:49 -0500, Scott Wood wrote:
Peter Tyser wrote:
On Thu, 2009-08-27 at 10:38 -0500, Scott Wood wrote:
Someone tried to get proper relocation working a while ago, but ran into
toolchain bugs. Maybe current toolchains are better...
X-ES's board's in U-Boot fully
On Sun, 2009-09-06 at 19:59 +0200, Dirk Behme wrote:
Jean-Christophe PLAGNIOL-VILLARD wrote:
On 09:12 Sun 06 Sep , Dirk Behme wrote:
Jean-Christophe PLAGNIOL-VILLARD wrote:
On 07:37 Sat 05 Sep , Dirk Behme wrote:
Dear Jean-Christophe,
Jean-Christophe PLAGNIOL-VILLARD wrote:
On Sun, 2009-09-06 at 20:40 +0200, Dirk Behme wrote:
Peter Tyser wrote:
On Sun, 2009-09-06 at 19:59 +0200, Dirk Behme wrote:
Jean-Christophe PLAGNIOL-VILLARD wrote:
On 09:12 Sun 06 Sep , Dirk Behme wrote:
Jean-Christophe PLAGNIOL-VILLARD wrote:
On 07:37 Sat 05 Sep , Dirk Behme
On Fri, 2009-09-04 at 10:12 -0500, Timur Tabi wrote:
Wolfgang Denk wrote:
Wrong Question. I don't know enough about the I2C protocol. Why is
i2c_wait4bus necessary?
Ok, why is it necessary?
Freescale's I2C core supports multiple masters. I'd guess that
i2c_wait4bus() is used to ensure
Thanks for cleaning this up Marcel. I had a few comments though. Your
patch appears to be line wrapped. Please use git to send the patch or
configure your email client not to line-wrap.
On Fri, 2009-09-04 at 14:37 +, Marcel ziswiler wrote:
Move the memory node fixup of the MPC8260ADS,
Hi Marcel,
This patch also appears to be line wrapped.
Best,
Peter
On Fri, 2009-09-04 at 14:41 +, Marcel ziswiler wrote:
Signed-off-by: Marcel Ziswiler marcel.ziswi...@noser.com
---
board/ep8248/ep8248.c| 22 +-
include/configs/ep8248.h | 53
On Fri, 2009-09-04 at 10:30 -0500, Timur Tabi wrote:
Peter Tyser wrote:
If this is the case, the timeout should be the maximum (or reasonable
maximum) time an I2C transaction could take.
How long is that? Is one millisecond good enough?
The timeout in i2c_wait4bus() could potentially
(-)
Acked-by: Wolfgang Denk w...@denx.de
Tested-by: Peter Tyser pty...@xes-inc.com
Acked-by: Peter Tyser pty...@xes-inc.com
Looks good to me,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
On Thu, 2009-09-03 at 08:25 -0500, Kumar Gala wrote:
On Aug 7, 2009, at 3:57 PM, Peter Tyser wrote:
diff --git a/cpu/mpc85xx/mp.c b/cpu/mpc85xx/mp.c
index 76f02a4..53fc3be 100644
--- a/cpu/mpc85xx/mp.c
+++ b/cpu/mpc85xx/mp.c
@@ -129,7 +129,7 @@ ulong get_spin_addr(void)
ulong
Hi Marcel,
On Thu, 2009-09-03 at 14:52 +, Marcel Ziswiler wrote:
ep8248: add support for device tree and secondary Ethernet interface.
This commit message shouldn't be necessary since its identical to your
commit subject.
snip
+
+#if defined(CONFIG_OF_BOARD_SETUP)
On Thu, 2009-08-27 at 10:38 -0500, Scott Wood wrote:
On Thu, Aug 27, 2009 at 01:54:47AM -0400, Mike Frysinger wrote:
On Thursday 27 August 2009 01:11:32 Stefan Roese wrote:
On Thursday 27 August 2009 03:55:57 Mike Frysinger wrote:
+int phy_init(void)
+{
+ /* Initialize the
Hi Eric,
On Tue, 2009-08-25 at 08:57 -0500, Eric Millbrandt wrote:
Reset any i2c devices that may have been interrupted by a system reset.
Normally this would be accomplished by clocking the line until SCL and SDA
are released and then sending a start condtiion (From an Atmel datasheet).
But
On Mon, 2009-08-24 at 18:10 -0500, Scott Wood wrote:
Andy Fleming wrote:
On Mon, Aug 24, 2009 at 2:32 PM, Kim Phillips
kim.phill...@freescale.comwrote:
if you don't have firmware installed for the PHY to come to life, this
wait can be painful - let's give the option to avoid it if we
Hi Dirk,
snip
Third, I don't like the mixing of board and vendor name as directory
names. It seems to me that where you think you know the vendor, you
use the vendor name, and where you seem to not know it, you use the
board name. So, to be consistent, and to overcome vendor name issue
Hi Wolfgang,
There was a fair amount of grey area as far as environment variable naming
for those variables that used to refernce autoscr.
Why actually?
I guess because we don't see eye-to-eye:)
I tended to lean toward using script in the variable name as I thought
that was a lot
401 - 500 of 892 matches
Mail list logo
