U-boot for Marvell Kirkwood boards no longer work after the EABI changes
introduced in commit f772acf8a584067033eff1e231fcd1fb3a00d3d9. This
turns out to be caused by a stack alignment issue. The armv5te
instructions ldrd/strd instructions require 8-byte alignment to work
properly (otherwise
On Mon, 05 Oct 2009 13:37:36 -0500
Tom tom@windriver.com wrote:
Simon Kagstrom wrote:
U-boot for Marvell Kirkwood boards no longer work after the EABI changes
introduced in commit f772acf8a584067033eff1e231fcd1fb3a00d3d9. This
turns out to be caused by a stack alignment issue. The
Hi Wolfgang,
I am using fw_printenv to set few environment variables from Linux. I am
able to see all the environment variables using fw_printenv.
But when i type the command fw_printenv i get the following message first
*Read error on /dev/mtd1: Success*
then u-boot environment variables
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 |2 +-
cpu/mpc85xx/{u-boot-nand.lds =
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 which puts the bss after the reset vector, which is
0xfffc
Abdoulaye Walsimou Gaye wrote:
kevin.morf...@fearnside-systems.co.uk a écrit :
Here are links to the patches and notes on their states:
- [U-boot] [PATCH-ARM] CONFIG_SYS_HZ change for cpu/arm920t/s3c24x0 boards:
http://lists.denx.de/pipermail/u-boot/2009-September/thread.html,
JP said
Dear Peter Tyser,
In message 1254783670-21301-3-git-send-email-pty...@xes-inc.com you wrote:
When U-Boot is relocated from flash to RAM pointers are modified
accordingly. However, pointers initialzed with NULL values should not
be modified so that they maintain their intended NULL value. The
Dear Peter Tyser,
In message 1254784811.24664.968.ca...@localhost.localdomain you wrote:
1. is just a small fix the the existing asm reloc functions. Pretty much
ready but needs some linker tweeks it seems. No idea if other
boards than 85xx also needs a linker tweak or not.
It
Dear Rahanesh,
In message 4acaeea9.1020...@tataelxsi.co.in you wrote:
But when i type the command fw_printenv i get the following message first
*Read error on /dev/mtd1: Success*
then u-boot environment variables are printed.
I gave up trying to reply to your questions. You supply _zero_
Dear Wolfagng,
Wolfgang Denk wrote:
Dear Rahanesh,
In message 4acaeea9.1020...@tataelxsi.co.in you wrote:
But when i type the command fw_printenv i get the following message first
*Read error on /dev/mtd1: Success*
then u-boot environment variables are printed.
I gave up trying to
Dear Rahanesh,
In message 4acb154f.7000...@tataelxsi.co.in you wrote:
I gave up trying to reply to your questions. You supply _zero_
information. We don't know which board this is, which exact version
of U-Boot you are running on it, which modifications you made to the
code you are
Wolfgang Denk w...@denx.de wrote on 06/10/2009 10:58:53:
Dear Peter Tyser,
In message 1254784811.24664.968.ca...@localhost.localdomain you wrote:
1. is just a small fix the the existing asm reloc functions. Pretty much
ready but needs some linker tweeks it seems. No idea if other
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
+ */
Hi
As I consider testing as an important part to ensure high code quality for
any product. It should form part of the global development process.
1) When adding a new board or feature to U-Boot running tests to ensure that
it
works as advertised should be mandatory but not time consuming.
2)
This patch rewrites the miiphybb ( Bit-banged MII bus driver ) in order to
support an arbitrary number of mii buses. This feature is useful when your
board uses different mii buses for different phys and all (or a part) of these
buses are implemented via bit-banging mode.
The driver requires that
This patch rewrites the miiphybb ( Bit-banged MII bus driver ) in order to
support an arbitrary number of mii buses. This feature is useful when your
board uses different mii buses for different phys and all (or a part) of these
buses are implemented via bit-banging mode.
The driver requires that
Signed-off-by: Luigi 'Comio' Mantellini luigi.mantell...@idf-hit.com
---
lib_arm/board.c |7 +++
lib_avr32/board.c|7 +++
lib_blackfin/board.c |7 +++
lib_i386/board.c |9 -
lib_m68k/board.c |7 +++
lib_mips/board.c |7 +++
Signed-off-by: Luigi 'Comio' Mantellini luigi.mantell...@idf-hit.com
---
include/configs/ISPAN.h |4
include/configs/MPC8260ADS.h |3 +++
include/configs/MPC8266ADS.h |4
include/configs/MPC8560ADS.h |4
include/configs/Rattler.h|4
Dear Peter Tyser,
In message 1254830475.22896.43.ca...@ptyser-laptop you 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
On Oct 6, 2009, at 9:01 AM, Wolfgang Denk wrote:
Dear Peter Tyser,
In message 1254830475.22896.43.ca...@ptyser-laptop you 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
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
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 address.
Where is BSS on 44x boards? I dont see any reason we
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
Dear Peter Tyser,
In message 1254839043.24664.1890.ca...@localhost.localdomain 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 address.
My concern was that we use __bss_start and _end to calculate the
Dears,
I'm not able to find the code for Cortex A9, but
in some discussion I saw it is (maybe) planned
to be in cpu/cortex_a9.
Is this correct?
Anyway, can you possibly update me about the current status?
Thx,
Armando
___
U-Boot mailing list
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
Armando VISCONTI wrote:
Dears,
I'm not able to find the code for Cortex A9, but
in some discussion I saw it is (maybe) planned
to be in cpu/cortex_a9.
Is this correct?
Anyway, can you possibly update me about the current status?
Thx,
Armando
I believe you are correct.
Tom
Simon Kagstrom wrote:
U-boot for Marvell Kirkwood boards no longer work after the EABI changes
introduced in commit f772acf8a584067033eff1e231fcd1fb3a00d3d9. This
turns out to be caused by a stack alignment issue. The armv5te
instructions ldrd/strd instructions require 8-byte alignment to work
On Tuesday 06 October 2009 17:22:10 Wolfgang Denk wrote:
My concern was that we use __bss_start and _end to calculate the size of
the bss to zero out. If the bss wraps, I'd be concerned about what gets
cleared as _end would be truncated to a low memory address while
__bss_start would be a
On Mon, Oct 05, 2009 at 11:18:11PM +0200, Wolfgang Denk wrote:
Dear Peter Tyser,
In message 1254773254.24664.657.ca...@localhost.localdomain you wrote:
32 bit alignment of the BSS segment might not be sufficient. Be
careful!
I've tried a few ways to ensure the BSS isn't at
-Original Message-
From: Dieter Kiermaier [mailto:dk-arm-li...@gmx.de]
Sent: Wednesday, September 30, 2009 1:55 PM
To: Simon Kagstrom
Cc: u-boot@lists.denx.de; Prafulla Wadaskar
Subject: Re: [U-Boot] kirkwood (openrd): saveenv will not
work with environment in NAND
Am
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,
bss, etc all in the same general area which is nice, and has
Dear Scott Wood,
In message 20091006171203.ga10...@b07421-ec1.am.freescale.net you wrote:
I don't know all flavours of Power machines, but gcc seems to align
double on 64 bit boundaries. This makes me think it might be needed.
Plus, explicit alignment (cacheline, page, some DMA alignment
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,
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 of putting the bss after
the entire U-Boot image. It keeps U-Boot's
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 implementation of putting the bss
after
the entire U-Boot
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 of
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
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 1254843932.24664.2083.ca...@localhost.localdomain you wrote:
I
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,
and eventually for all Power processor families.
One
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
Your message to mx.ptmail.sapo.pt was rejected.
I said:
.
And mx.ptmail.sapo.pt [212.55.154.36] responded with
554 AV Server permanently rejected message (#5.3.0)
The message headers follow:
---BeginMessage---
-
---End Message---
___
U-Boot
Dear Peter Tyser,
In message 1254870618.24664.3061.ca...@localhost.localdomain you wrote:
I understand that the final addresses in RAM of all the sections are
calculated by U-Boot during relocation based on memory size. However,
True. And nothing is ever written to the bss addresses as
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
When setting up the LAWs for the DDR, if there was an error,
you got the not-so-helpful error text ERROR and nothing
else. Not only is it non-informative, but it is also
pretty frustrating trying to grep for ERROR in the source.
Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com
---
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 is
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,
?
On Wed, Oct 7, 2009 at 11:09 AM, Peter Tyser pty...@xes-inc.com wrote:
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
Some Samsung SoCs, s3c64xx, s5pc100 has own OneNAND controller
and different OneNAND access method.
To support this, each board has own init and set onenand_read_page for it.
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
diff --git a/onenand_ipl/onenand_read.c
Hi Niklaus,
Niklaus Giger wrote:
Hi
As I consider testing as an important part to ensure high code quality for
any product. It should form part of the global development process.
1) When adding a new board or feature to U-Boot running tests to ensure that
it works as advertised should
Remove the predefined static initialization
and generate the map dynamically to reduce
code size.
This patch benefits were pointed out by Peter:
http://www.nabble.com/forum/Permalink.jtp?root=25518020post=25523748page=y
Signed-off-by: Nishanth Menon n...@ti.com
Cc: Peter Tyser pty...@xes-inc.com
SZ definitions are deprecated as indicated by wd here:
http://www.nabble.com/forum/Permalink.jtp?root=25518020post=25584065page=y
Fix by running the following script
I=`cat include/asm-arm/sizes.h |grep SZ_|cut -d ' ' -f2`
I=`cat include/asm-arm/sizes.h |grep SZ_|cut -d ' ' -f4-`
sz_array=( $I )
Export enable_gpmc_cs_config into common header to
prevent warning:
warning: implicit declaration of function 'enable_gpmc_cs_config'
Signed-off-by: Nishanth Menon n...@ti.com
Cc: David B davi...@pacbell.net
Cc: Vikram Pandita vikram.pand...@ti.com
Cc: Richard Woodruff r-woodru...@ti.com
Cc:
gpmc_config should not be a variant as it is board specific
hence make it a const parameter
Signed-off-by: Nishanth Menon n...@ti.com
Cc: David B davi...@pacbell.net
Cc: Vikram Pandita vikram.pand...@ti.com
Cc: Richard Woodruff r-woodru...@ti.com
Cc: Sandeep Paulraj s-paul...@ti.com
Cc: Tom Rix
Fix build warnings by putting specific used variables
under required #ifdefs for removing:
mem.c:227: warning: unused variable 'f_sec'
mem.c:226: warning: unused variable 'f_off'
mem.c:225: warning: unused variable 'size'
mem.c:224: warning: unused variable 'base'
mem.c:222: warning: unused
Defaults are for Infineon DDR timings.
Since none of the supported boards currently do
XIP boot, these seem to be faulty. fix the values
as per the calculations(ACTIMA,B), conf
the sdrc power with pwdnen and wakeupproc bits
Signed-off-by: Nishanth Menon n...@ti.com
Cc: David B davi...@pacbell.net
From: David Brownell davi...@pacbell.net
Start of support of
Texas Instruments Software Development Platform(SDP)
for OMAP3430 - SDP3430
Highlights of this platform are:
Flash Memory devices:
Sibley NOR, Micron 8bit NAND and OneNAND
Connectivity:
3 UARTs and expanded 4 UART ports
This series of patch provides minimal support for
OMAP3430 based SDP3430 platform
Ref:
http://focus.ti.com/general/docs/wtbu/wtbugencontent.tsp?templateId=6123navigationId=12013contentId=28741
Rev 1 of this patch series was discussed in:
Subject: [PATCH] OMAP3: remove SZ definition in config definitions
SZ definitions are deprecated as indicated by wd here:
http://www.nabble.com/forum/Permalink.jtp?root=25518020post=25584065page
=y
Fix by running the following script
I=`cat include/asm-arm/sizes.h |grep SZ_|cut -d ' '
Nishanth,
I was referring to this patch I sent some time back.
And one comment about your patch; I could not see you actually removing the
asm/sizes.h header file. I think that is important as Wolfgang has told us that
he is going to remove that header file.
Thanks,
Sandeep
Subject: [PATCH
On Wed, Oct 7, 2009 at 1:13 PM, Nishanth Menon n...@ti.com wrote:
Remove the predefined static initialization
and generate the map dynamically to reduce
code size.
This patch benefits were pointed out by Peter:
http://www.nabble.com/forum/Permalink.jtp?root=25518020post=25523748page=y
Sorry, there's typo.
Here's fixed patch.
diff --git a/onenand_ipl/onenand_read.c b/onenand_ipl/onenand_read.c
index 8d0df81..47b60b3 100644
--- a/onenand_ipl/onenand_read.c
+++ b/onenand_ipl/onenand_read.c
@@ -110,6 +110,14 @@ static void onenand_generic_init(int
*page_is_4KiB, int *page)
Graeme Russ had written, on 10/06/2009 09:52 PM, the following:
On Wed, Oct 7, 2009 at 1:13 PM, Nishanth Menon n...@ti.com wrote:
Remove the predefined static initialization
and generate the map dynamically to reduce
code size.
This patch benefits were pointed out by Peter:
From: David Brownell davi...@pacbell.net
Sandeep pointed me to:
http://lists.denx.de/pipermail/u-boot/2009-October/062086.html
so the v3 of patch with size fixes
Start of support of
Texas Instruments Software Development Platform(SDP)
for OMAP3430 - SDP3430
Highlights of this platform
Remove the predefined static initialization
and generate the map dynamically to reduce
code size.
This patch benefits were pointed out by Peter:
http://www.nabble.com/forum/Permalink.jtp?root=25518020post=25523748page=y
Additional comments from Graeme Russ on x86
support to be removed:
On Wed, Oct 7, 2009 at 2:38 PM, Nishanth Menon n...@ti.com wrote:
Remove the predefined static initialization
and generate the map dynamically to reduce
code size.
This patch benefits were pointed out by Peter:
http://www.nabble.com/forum/Permalink.jtp?root=25518020post=25523748page=y
Hi
I need to use watchdog timer of OMAP-3530 in U-Boot.
Has anybody used watchdog timer of OMAP3530 successfully?
Kindly provide me links to source.
Thanks
Ratheesh
___
U-Boot mailing list
U-Boot@lists.denx.de
70 matches
Mail list logo
