Le dimanche 03 février 2008 à 13:54 +0100, Haavard Skinnemoen a écrit :
> I think they should be collected according to board manufacturer or
> brand, not cpu type. So boards/atmel is for boards manufactured by
> Atmel, not all boards that happen to have an Atmel cpu on them.
>
> Or at least tha
On Monday 04 February 2008, Stelian Pop wrote:
> Le dimanche 03 février 2008 à 13:54 +0100, Haavard Skinnemoen a écrit :
> > I think they should be collected according to board manufacturer or
> > brand, not cpu type. So boards/atmel is for boards manufactured by
> > Atmel, not all boards that happ
On Sunday 03 February 2008, Michael Schwingen wrote:
> Stefan Roese wrote:
> > But you need to know what FLASH chips you are using in this case (Intel
> > or AMD/Spansion). But you are right, they are not pin compatible, so it
> > should be fixed for one board and your solution should be ok. The bo
Thanks Stelian
Peter
> -Original Message-
> From: Stelian Pop [mailto:[EMAIL PROTECTED]
> Sent: 04 February 2008 09:43
> To: Haavard Skinnemoen
> Cc: Stefan Roese; u-boot-users@lists.sourceforge.net; Peter Pearse
> Subject: [PATCH ARM] AT91CAP9 support : move board files to
> Atmel vend
Hi Wolfgang,
On Monday 04 February 2008, Wolfgang Denk wrote:
> A possible approach to this problem is to avoid using a global
> register variable and use a plain global variable instead. The
> necessary code for this is already there (just commented out); when I
> implemented this i
Avoid errors for make O=../build and ./MAKEALL hcu4 hcu5.
Signed-off-by: Niklaus Giger <[EMAIL PROTECTED]>
---
board/netstal/hcu4/Makefile | 12
board/netstal/hcu5/Makefile | 10 --
2 files changed, 8 insertions(+), 14 deletions(-)
diff --git a/board/netstal/hcu4/Makefil
Hi Niklaus,
On Monday 04 February 2008, Niklaus Giger wrote:
> Signed-off-by: Niklaus Giger <[EMAIL PROTECTED]>
Thanks for splitting this out. But still I have a question. See below.
> ---
> include/ppc405.h |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/includ
On 2/4/08, Joakim Tjernlund <[EMAIL PROTECTED]> wrote:
> Hi Grant
>
> Can you tell me what happened to the relocation stuff you added
> and why it was disabled?
>
Because it broke on gcc < 4.0.x and gcc > 4.0x. :-( And I didn't
have enough time to figure out what went wrong (nor did I have any
o
Stefan Roese wrote:
>> However, I wonder if it would be possible to simply issue *both* reset
>> commands - if the flash safely ignores the second (unknown) command,
>> this should be fine, but it is relying on undocumented behaviour.
>>
>
> Good idea. Do you (or somebody else) have HW availab
On Mon, Feb 04, 2008 at 12:32:36AM +0100, Wolfgang Denk wrote:
> So far, it is not clear to me what a better choice for a global
> register variable could be (i. e. which register we can chose for our
> purpose without causing the same or other problems.
r2 is generally used for this purpose
On Monday 04 February 2008, Michael Schwingen wrote:
> Stefan Roese wrote:
> >> However, I wonder if it would be possible to simply issue *both* reset
> >> commands - if the flash safely ignores the second (unknown) command,
> >> this should be fine, but it is relying on undocumented behaviour.
> >
Wolfgang Denk wrote:
> Except for the declaration of the variable itself, *nothing* changes.
> What do you mean would become simpler?
A normal global variable is simpler than one that's tied to a specific
register,
wouldn't you say? I wasn't trying to be that insightful.
--
Timur Tabi
Linux
In message <[EMAIL PROTECTED]> you wrote:
>
> > A possible approach to this problem is to avoid using a global
> > register variable and use a plain global variable instead.
>
> Sounds like a good idea to me. If the code works, then this would simplify
> things a great deal. The
Wolfgang Denk wrote:
> A possible approach to this problem is to avoid using a global
> register variable and use a plain global variable instead.
Sounds like a good idea to me. If the code works, then this would simplify
things a great deal. The code that reads and writes the g
Stefan Roese wrote:
> Hi Niklaus,
>
> On Monday 04 February 2008, Niklaus Giger wrote:
>> Signed-off-by: Niklaus Giger <[EMAIL PROTECTED]>
>
> Thanks for splitting this out. But still I have a question. See below.
>
>> ---
>> include/ppc405.h |4
>> 1 files changed, 4 insertions(+), 0
- Fix some coding style violations.
- Use in/out_u16/32 where appropriate.
- Use register names from ppc405.h.
- Fix trace useage for Lauterbach.
- Fix detection of vxWorks EDR.
- Remove obsolete generation HCU2.
- Renamed fixed_hcu4_sdram to init_ppc405_sdram.
Signed-off-by: Niklaus Giger <[EMAIL
Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>> On Mon, Feb 04, 2008 at 12:32:36AM +0100, Wolfgang Denk wrote:
>>> So far, it is not clear to me what a better choice for a global
>>> register variable could be (i. e. which register we can chose for our
>>> purpose without
In message <[EMAIL PROTECTED]> you wrote:
> On Mon, Feb 04, 2008 at 12:32:36AM +0100, Wolfgang Denk wrote:
> > So far, it is not clear to me what a better choice for a global
> > register variable could be (i. e. which register we can chose for our
> > purpose without causing the same or othe
Hi Niklaus,
On Monday 04 February 2008, Niklaus Giger wrote:
> - Fix some coding style violations.
> - Use in/out_u16/32 where appropriate.
> - Use register names from ppc405.h.
> - Fix trace useage for Lauterbach.
> - Fix detection of vxWorks EDR.
> - Remove obsolete generation HCU2.
> - Renamed
Signed-off-by: Niklaus Giger <[EMAIL PROTECTED]>
---
Makefile |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 0f6cc59..b3a1d2f 100644
--- a/Makefile
+++ b/Makefile
@@ -1225,9 +1225,11 @@ G2000_config:unconfig
@$(MKCONFIG) $(@:_config
Signed-off-by: Niklaus Giger <[EMAIL PROTECTED]>
---
include/ppc405.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/include/ppc405.h b/include/ppc405.h
index b5ad38f..fbfb681 100644
--- a/include/ppc405.h
+++ b/include/ppc405.h
@@ -784,6 +784,10 @@
#define reset (
>I may have noted this before, but I suggest you move the CFG_NAND_ADDR
to 0x9000 as done on Bamboo, since 0xd000 is reserved for PCI
memory on 440EP.
I have done this and it didn't make any difference, same
exception
>How is SDR0_CUST0 configured. Please read is in a runn
In message <[EMAIL PROTECTED]> you wrote:
>
> > Except for the declaration of the variable itself, *nothing* changes.
> > What do you mean would become simpler?
>
> A normal global variable is simpler than one that's tied to a specific
> register,
> wouldn't you say? I wasn't trying to be that
Hi u-boot ml,
Hi Tsi Chung Liew,
I have the following error compiling the M5475xxx targets:
[code]
make[1]: Leaving directory `/mnt/devel/idf/u-boot/common'
make -C libfdt/
make[1]: Entering directory `/mnt/devel/idf/u-boot/libfdt'
m68k-elf-ar crv libfdt.a
make[1]: Leaving directory `/mnt/devel/
In message <[EMAIL PROTECTED]> you wrote:
> This patch adds NAND support to the S3C24x0 SoC code in u-boot
>
> Signed-off-by: Harald Welte <[EMAIL PROTECTED]>
Applied, thanks - but ...
> Index: u-boot/cpu/arm920t/s3c24x0/Makefile
>
In message <[EMAIL PROTECTED]> you wrote:
> This patch allows us to use the 'gd' pointer (and thus environment
> and everything else associated with it) from interrupt context on
> arm920t.
>
> Signed-off-by: Harald Welte <[EMAIL PROTECTED]>
Applied, thanks.
Best regards,
Wolfgang Denk
--
DEN
In message <[EMAIL PROTECTED]> you wrote:
>
> This patches allows cpu_init_crit function to be compilled only if
> CONFIG_SKIP_LOWLEVEL_INIT is not defined. At present irrespective of
> CONFIG_SKIP_LOWLEVEL_INIT, cpu_init_crit is always compilled. This is for
> arm926ejs module.
I'm not sure abo
Hello,
in message <[EMAIL PROTECTED]> you wrote:
>
> This Patch removes compiler warning about target cpu not supporting
> interworking for arm926ejs processor.
>
> Signed-off-by: K R Gururaja Hebbar <[EMAIL PROTECTED]>
A more or less identical patch (see entry "[PATCH] Remove warning:
targe
In message <[EMAIL PROTECTED]> you wrote:
>
> This Patch adds if define to bdinfo command to display ethernet information
> only if CONFIG_CMD_NET is defined for arm modules.
>
>
> Signed-off-by: K R Gururaja Hebbar <[EMAIL PROTECTED]>
There were no negative comments to this modification (just
Luigi,
Is the problem you encountered after you implemented the "Move
PPC and M68K ramdiskloading to a common routine" patch or before?
Regards,
TsiChung
-Original Message-
From: Luigi 'Comio' Mantellini [mailto:[EMAIL PROTECTED]
Sent: Monday, February 04, 2008 5:04 PM
To: Lie
On Mon, Feb 04, 2008 at 11:55:47PM +0100, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > This patch adds NAND support to the S3C24x0 SoC code in u-boot
> >
> > Signed-off-by: Harald Welte <[EMAIL PROTECTED]>
>
> Applied, thanks - but ...
>
> > - usb.o usb_ohci.o
> > +
Commit 04a9e1180ac76a7bacc15a6fcd95ad839d65bddb introduced the mpc83xx_spi.c
driver which gets compiled for everyone, but this obviously only builds for
the ppc port. I haven't been following the latest build updates, but the
attached patch is one way to fix things.
Signed-off-by: Mike Frysinger
In message <[EMAIL PROTECTED]> you wrote:
>
> This Patch adds I2C init func call to init sequence for arm boards. This is
> present in ppc,blackfin and other processor init sequence.
>
> Signed-off-by: K R Gururaja Hebbar <[EMAIL PROTECTED]>
Applied, thanks.
Best regards,
Wolfgang Denk
--
DE
In message <[EMAIL PROTECTED]> you wrote:
> allow to use a different server as set in serverip
> add CONFIG_TFTP_FILE_NAME_MAX_LEN to configure the file name length
> if not defined the max length will be at 128
>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <[EMAIL PROTECTED]>
Applied, than
This should get the Blackfin port building/running fine with mainline u-boot
and a bunch of cleanups in the process. More/bigger things to come ...
The following changes since commit 2c5260f711168d5ee91c70ddbb7d897013eefc46:
Ladislav Michl (1):
ARM: AT91RM9200 based boards config cleanu
Hi Wolfgang,
Thanks. Will sure learn about GIT Process.
Regards
Gururaja
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, February 04, 2008 2:19 PM
To: Gururaja Hebbar K R
Cc: u-boot-users@lists.sourceforge.net
Subject: Re: [U-Boot-Users] [PATCH] ARM92
Constantly rebuilding the version header will force useless relinking, so we
simply need to compare the new header with the existing one before updating
it.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
diff --git a/Makefile b/Makefile
index 0f6cc59..7655b23 100644
--- a/Makefile
+++ b/Mak
In message <[EMAIL PROTECTED]> you wrote:
> This patch adds a IRQ demultiplexer callback to the arm920 cpu core code,
> plus a stub implementation of it for the S3C2410.
>
> The purpose is to allow arm920t implementations suhc as the s3c24x0 to
> implement interrupt handlers in u-boot without havi
In message <[EMAIL PROTECTED]> you wrote:
> This patch adds support for CONFIG_SERIAL_MULTI on s3c24x0 CPU's
>
> Signed-off-by: Harald Welte <[EMAIL PROTECTED]>
Applied, thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Mun
In message <[EMAIL PROTECTED]> you wrote:
> According to the OMAP5912 Serial Interfaces Reference Guide (see
> http://focus.ti.com/lit/ug/spru760c/spru760c.pdf, page 150), the
> FIFO_EN enable bit in the FIFO Control Register (FCR) can only be
> changed when the baud clock is not running, i. e. whe
Hello Andy & Jon,
in message <[EMAIL PROTECTED]> Jon wrote:
> Andy Fleming wrote:
> > On Jan 9, 2008 2:35 PM, Timur Tabi <[EMAIL PROTECTED]> wrote:
> >> Update global_data to define i2c1_clk and i2c2_clk to 85xx and 86xx.
> >>
> >> Update the get_clocks() function in 85xx and 86xx to determine the
Wolfgang Denk wrote:
> Hello Andy & Jon,
>
> in message <[EMAIL PROTECTED]> Jon wrote:
>> Andy Fleming wrote:
>>> On Jan 9, 2008 2:35 PM, Timur Tabi <[EMAIL PROTECTED]> wrote:
Update global_data to define i2c1_clk and i2c2_clk to 85xx and 86xx.
Update the get_clocks() function in 85
are found in the git repository at:
git://www.denx.de/git/u-boot-mpc85xx.git
Timur Tabi (1):
85xx,86xx: Determine I2C clock frequencies and store in global_data
cpu/mpc85xx/speed.c |3 +++
cpu/mpc86xx/speed.c |2 ++
include/asm-ppc/global_data.h |6 --
On Feb 4, 2008 5:22 PM, Jon Loeliger <[EMAIL PROTECTED]> wrote:
> >>> On Jan 9, 2008 2:35 PM, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Update global_data to define i2c1_clk and i2c2_clk to 85xx and 86xx.
>
> Update the get_clocks() function in 85xx and 86xx to determine the I2C
>
On Jan 30, 2008 3:28 PM, Kumar Gala <[EMAIL PROTECTED]> wrote:
> When we go to 36-bit physical addresses we need to keep the concept of
> the physical CCSRBAR address seperate from the virtual one.
>
> For the majority of boards CFG_CCSBAR_PHYS == CFG_CCSRBAR
>
> Signed-off-by: Kumar Gala <[EMAIL P
On Feb 1, 2008 10:19 AM, Kumar Gala <[EMAIL PROTECTED]> wrote:
> Added the cpu command that provides a generic mechanism to get status,
> reset, and release secondary cores in multicore processors.
>
> Added support for using the ePAPR defined spin-table mechanism on 85xx.
>
> Signed-off-by: Kumar
On Mon, 4 Feb 2008 17:57:23 -0500
Mike Frysinger <[EMAIL PROTECTED]> wrote:
> Commit 04a9e1180ac76a7bacc15a6fcd95ad839d65bddb introduced the mpc83xx_spi.c
> driver which gets compiled for everyone, but this obviously only builds for
> the ppc port. I haven't been following the latest build update
Hi Wolfgang ,
At Present the call to "cpu_init_crit" in uboot/cpu/arm926ejs/start.S (142)
is under ifndef
#ifndef CONFIG_SKIP_LOWLEVEL_INIT
bl cpu_init_crit
#endif
But the function definition (203) isn't under this ifndef. So irrespective
of CONFIG_SKIP_LOWLEVEL_INIT, this functi
On Monday 04 February 2008, Kim Phillips wrote:
> Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > Commit 04a9e1180ac76a7bacc15a6fcd95ad839d65bddb introduced the
> > mpc83xx_spi.c driver which gets compiled for everyone, but this obviously
> > only builds for the ppc port. I haven't been following th
The address of SH7722 is wrong by old document.
This patch fixes this problem.
Signed-off-by: Nobuhiro Iwamatsu <[EMAIL PROTECTED]>
---
include/asm-sh/cpu_sh7722.h | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/asm-sh/cpu_sh7722.h b/include/asm-sh/cpu_
Signed-off-by:Roger Huang
Add AT2440 EVB support, it's base on Samsung S3C2440 SOC with 64MB SDRAM & 64M NAND. It enable as followed feature:
1. Booting from NAND
2. Follow newer MTD NAND implement
--- 本郵件來自HiNet WebMail ---diff --git a/Makefile b/Makefile
index 0f6cc59..661ee0e 100
On Monday 04 February 2008, Niklaus Giger wrote:
> > Why is 405GPr needed here? Is this register not available in 405GP?
>
> I found the following comments in the Migration guide for the PPC405GP ->
> PPC405GPr (PPC405GP_AN2023_405GPrMigration__v1_01.pdf).
>
> > The 405GPr provides the ability to a
On Tuesday 05 February 2008, Stefan Roese wrote:
> > Therefore I concluded that it is very PPC405GPr specific. But I did not
> > check all other PPC405 variants.
>
> Yes, you seem to be right here. This *is* 405GPr specific. But I don't
> think it is worth adding this CONFIG_405GPr. Right now by se
On Monday 04 February 2008, Stefan Roese wrote:
> > - Fix some coding style violations.
> > - Use in/out_u16/32 where appropriate.
> > - Use register names from ppc405.h.
> > - Fix trace useage for Lauterbach.
> > - Fix detection of vxWorks EDR.
> > - Remove obsolete generation HCU2.
> > - Renamed
Your Friend and Lover http://213.60.136.120/
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
On Monday 04 February 2008, Craig Millen wrote:
> > I may have noted this before, but I suggest you move the CFG_NAND_ADDR
> > to 0x9000 as done on Bamboo, since 0xd000 is reserved for PCI
> > memory on 440EP.
>
> I have done this and it didn't make any difference, same
> exception
I
56 matches
Mail list logo
