Dear Graeme Russ,
In message you
wrote:
>
> I think that even the -mrelocatable / .fixup method may not be needed at
> all. -pie / -pic used by themselves creates enough information for an OS
> dynamic loader to relocate an executable, so why not U-Boot? Given that
> the type and location of eac
Dear Peter Tyser,
In message <1254872619.24664.3159.ca...@localhost.localdomain> you wrote:
>
> > Right, that's the current situation.
> >
> > My suggestion was NOT to put the bss at a fixed _offset_ to the
> > U-Boot image, but to a fixed absolute address. My hope is that this
> > migh
Dear Peter Tyser,
In message <1254871741.24664.3117.ca...@localhost.localdomain> you wrote:
>
> > One disadvantage is that we need to relocate it separately, or we will
> > have a gap in the RAm memory map which is IMO not acceptable.
>
> What does "relocating the bss separately" entail?
The rel
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
http://lists.denx.de/mailman/listinfo/u-b
Signer-off-by: Martha Stan
---
include/asm-ppc/immap_512x.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-ppc/immap_512x.h b/include/asm-ppc/immap_512x.h
index 79cdd80..e553bbe 100644
--- a/include/asm-ppc/immap_512x.h
+++ b/include/asm-ppc/immap_512x.h
@
On Wed, Oct 7, 2009 at 2:38 PM, Nishanth Menon 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=25518020&post=25523748&page=y
>
> Additi
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=25518020&post=25523748&page=y
Additional comments from Graeme Russ on x86
support to be removed:
http://w
From: David Brownell
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 are:
Flash Memory de
Graeme Russ had written, on 10/06/2009 09:52 PM, the following:
> On Wed, Oct 7, 2009 at 1:13 PM, Nishanth Menon 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.nabb
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)
On Wed, Oct 7, 2009 at 1:13 PM, Nishanth Menon 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=25518020&post=25523748&page=y
>
> Signed
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
> 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=25518020&post=25584065&page
> =y
>
> Fix by running the following script
> I=`cat include/asm-arm/sizes.h |grep SZ_|cu
This series of patch provides minimal support for
OMAP3430 based SDP3430 platform
Ref:
http://focus.ti.com/general/docs/wtbu/wtbugencontent.tsp?templateId=6123&navigationId=12013&contentId=28741
Rev 1 of this patch series was discussed in:
http://www.nabble.com/forum/Permalink.jtp?root=25518020&
From: David Brownell
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 + IrDA
Ethe
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
Cc: David B
Cc: Vikram Pandita
Cc: Richar
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 variabl
gpmc_config should not be a variant as it is board specific
hence make it a const parameter
Signed-off-by: Nishanth Menon
Cc: David B
Cc: Vikram Pandita
Cc: Richard Woodruff
Cc: Sandeep Paulraj
Cc: Tom Rix
Cc: Dirk Behme
---
cpu/arm_cortexa8/omap3/mem.c |6 +++---
include/asm
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
Cc: David B
Cc: Vikram Pandita
Cc: Richard Woodruff
Cc: Sandeep Paulraj
Cc: Tom Rix
Cc: Dirk Behme
---
include/asm-arm/arch-om
SZ definitions are deprecated as indicated by wd here:
http://www.nabble.com/forum/Permalink.jtp?root=25518020&post=25584065&page=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 )
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=25518020&post=25523748&page=y
Signed-off-by: Nishanth Menon
Cc: Peter Tyser
Cc: Sandeep Paulraj
Cc: To
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 sh
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
---
diff --git a/onenand_ipl/onenand_read.c b/onenand_ipl/onenand_read.c
index 8d0df81..47b60
On Wed, Oct 7, 2009 at 11:09 AM, Peter Tyser 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 speaking, we
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,
> ? LAW_TRGT
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
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
---
cpu/mpc8xxx/ddr/util.c |
> > 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 - i
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
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 r
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:
--- Begin Message ---
-
--- End Message ---
___
U-Boot
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,
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 disadva
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 wro
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 person
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 curr
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
>>
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 k
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
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
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
> -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
>
> 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
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 wou
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 w
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.
To
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
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
U-Boot
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 calcul
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 th
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
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.
> >
>
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
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
Signed-off-by: Luigi 'Comio' Mantellini
---
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
include/configs/SBC8540.h|4
in
Signed-off-by: Luigi 'Comio' Mantellini
---
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 +++
lib_ppc/board.c |7 +
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
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) If
> > --- 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 fix
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
> >
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
> > ---
> > cpu/mpc85xx/config.mk
Wolfgang Denk 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
>
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
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 t
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
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.
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.
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,
>>
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
> 0x
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
> ---
> cpu/mpc85xx/config.mk |2 +-
> cpu/mpc85xx/{u-boot-nand.lds => u-boot-nand.l
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
On Mon, 05 Oct 2009 13:37:36 -0500
Tom 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 armv5te
> > instruc
73 matches
Mail list logo
