Hi,
>>Removed code to LED init since it is not specific to the ARM CPU, but
>>rather should go in the board/platform specific files.
I second that
Regards
Gururaja
--
View this message in context:
http://www.nabble.com/-PATCH-%3Aarm926ejs%3A-Regression-to-remove-inappropriate-LED-control-
hi:
thanks for your kind help.
As far as I know, the cpu will set the PC to irq/fiq vector when the
these exceptions are triggered. And these pointers are usually at the
beginning position of bootloader, if bootloader wants to pass these
functions to kernel, there may be some instructions like "b x
On Tue, May 20, 2008 at 7:41 AM, loody <[EMAIL PROTECTED]> wrote:
> Dear all:
> I have trace interrupt/Fiq vector in uboot based on smdk2410.
> after we save user registers, we jump to following functions I
> excerpted at the end of mail.
> But these 2 functions seems not really handle the irq/fiq,
Hi all,
I am new to U-boot.I want to implement UBI over U-boot and also want
to port U-boot to one of our devices. Please provide some design
documents and any other documents which will help me gain good
understanding on U-boot.Provide me any info that will help me in
understanding u-boot.
Warm R
Dear all:
I have trace interrupt/Fiq vector in uboot based on smdk2410.
after we save user registers, we jump to following functions I
excerpted at the end of mail.
But these 2 functions seems not really handle the irq/fiq, would
someone please tell me where the real
interrupt handler is?
Is the i
On Mon, 19 May 2008 19:05:04 +0300
David Saada <[EMAIL PROTECTED]> wrote:
> Add support for UPM configuration on the 85xx platform.
> In addition, on the MPC83xx, remove MPC834x precompiler condition, in order
> to support all MPC83xx processors.
>
> Signed-off-by: David Saada <[EMAIL PROTECTED]
cpu/arm926ejs/start.S:
Removed code to LED init since it is not specific to the ARM CPU, but
rather should go in the board/platform specific files.
Signed-off-by: Daniel Allred gmail...>
--- u-boot-1.3.2/cpu/arm926ejs/start.S.orig 2008-05-19 16:06:06.567184000
-0500
+++ u-boot-1.3.2/cpu/ar
In message <[EMAIL PROTECTED]> you wrote:
>
> > If possible, we *want* the preprocessor to remove any code that does
> > not apply for a specific configuration. Generating code just bloats
> > the memory footprint.
>
> Definitely.
>
> But constant expressions are evaluated at compile time. So t
Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>>> Broken ports should be fixed.
>> Maybe we should define it in a non-board-specific header, so as to make
>> the intent clear that it not actually be configurable?
>
> Good idea. But the change fill break some 100 boards.
Yeah,
In message <[EMAIL PROTECTED]> you wrote:
> Change LCRR clock ratio from 2 to 4 to commodate VSC7385.
> Correct TSEC1 vs TSEC2 assignment.
> Define ETHADDR and ETH1ADDR always.
>
> Signed-off-by: York Sun <[EMAIL PROTECTED]>
> Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
> ---
> include/configs/
> If possible, we *want* the preprocessor to remove any code that does
> not apply for a specific configuration. Generating code just bloats
> the memory footprint.
Definitely.
But constant expressions are evaluated at compile time. So the dead
branch (if or else) doesn't generate any object co
In message <[EMAIL PROTECTED]> you wrote:
>
> >>> Fair enough, but the changes that are in York's patch have been tested.
> >>> Considering that the fix window for 1.3.3 is closing fast, we don't have
> >>> the
> >>> bandwidth for additional testing of the additional and unrelated changes
> >>> t
So then should I wait on submitting patches for my board, or will that even
make any sort of difference?
Ron
> Date: Mon, 19 May 2008 15:08:36 -0500
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> CC: u-boot-users@lists.sourceforge.net
> Subject: Re: [U-Boot-Users] New board support patches
In message <[EMAIL PROTECTED]> you wrote:
>
> > +#if CFG_HZ > 10
>
> Shouldn't this be
>
> if (CFG_HZ > 10)
>
> instead?
>
> It's a constant expression, and the compiler optimizes the conditional
> out. Using if() instead of #if ensures that all the code is always parsed,
> so th
In message <[EMAIL PROTECTED]> you wrote:
>
> > Broken ports should be fixed.
>
> Maybe we should define it in a non-board-specific header, so as to make
> the intent clear that it not actually be configurable?
Good idea. But the change fill break some 100 boards.
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
> Hi everybody,
>
> U-Boot v1.3.3 has been released and is available from the git
> repository and the FTP server.
You didn't pick up this patch:
Fix 8313ERDB board configuration
from York Sun, so 1.3.3 is broken on the MPC8313ERDB.
> The Merge Window for v1.3.3 is
> +#if CFG_HZ > 10
Shouldn't this be
if (CFG_HZ > 10)
instead?
It's a constant expression, and the compiler optimizes the conditional
out. Using if() instead of #if ensures that all the code is always parsed,
so the compiler can review it all and signal any problem. Not to ment
Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>> if (state == FL_ERASING)
>> timeo = CFG_HZ * 2 / 5;
>> else
>> timeo = CFG_HZ / 50
>>
>> If we have CFG_HZ values that are within a factor of 2 of wrapping
>> around, the platform should probably do some downward scaling
In message <[EMAIL PROTECTED]> you wrote:
>
> if (state == FL_ERASING)
> timeo = CFG_HZ * 2 / 5;
> else
> timeo = CFG_HZ / 50
>
> If we have CFG_HZ values that are within a factor of 2 of wrapping
> around, the platform should probably do some downward scaling (or we
> should think a
In message <[EMAIL PROTECTED]> you wrote:
> Rewrite the nand_wait() FL_ERASING case to handle CFG_HZ values in the
> MHZ range. This is needed for mips processors, as the timer's timebase
> ticks at CPU clock frequency.
NAK.
This is fundamentally broken, as CFG_HZ must not have "values in the
MH
McMullan, Jason wrote:
> On Mon, 2008-05-19 at 15:26 -0500, Scott Wood wrote:
>> Even though it's MIPS that needs it, it should be flagged as a NAND
>> patch since that's the code it touches.
>
> Totally agree.
>
>> How about this?
>>
>> if (state == FL_ERASING)
>> timeo = CFG_HZ * 2 / 5;
>
On Mon, 2008-05-19 at 15:26 -0500, Scott Wood wrote:
> Even though it's MIPS that needs it, it should be flagged as a NAND
> patch since that's the code it touches.
Totally agree.
> How about this?
>
> if (state == FL_ERASING)
> timeo = CFG_HZ * 2 / 5;
> else
> timeo = CFG_HZ / 50
>
Jason McMullan wrote:
> Rewrite the nand_wait() FL_ERASING case to handle CFG_HZ values in the
> MHZ range. This is needed for mips processors, as the timer's timebase
> ticks at CPU clock frequency.
Even though it's MIPS that needs it, it should be flagged as a NAND
patch since that's the code i
Rewrite the nand_wait() FL_ERASING case to handle CFG_HZ values in the
MHZ range. This is needed for mips processors, as the timer's timebase
ticks at CPU clock frequency.
Signed-off-by: Jason McMullan <[EMAIL PROTECTED]>
---
drivers/mtd/nand/nand_base.c |7 +++
1 files changed, 7 inserti
Hi everybody,
U-Boot v1.3.3 has been released and is available from the git
repository and the FTP server.
The Merge Window for v1.3.3 is open until June 03, 23:59:59 MET.
Release v1.3.4 is scheduled for July 14, but you know that you better
don't hold your breath.
A little statistics [1] - c
Ronald Madrid wrote:
> I have two questions. First, is there any particular way the patches
> should be created for the submission of code for supporting a new board?
>
> Second, this is a question for the Freescale maintainers, my board is
> based on the 8313erdb, and will only support NAND fl
Hello,
I have two questions. First, is there any particular way the patches should be
created for the submission of code for supporting a new board?
Second, this is a question for the Freescale maintainers, my board is based on
the 8313erdb, and will only support NAND flash as its boot ROM. I
David Saada wrote:
> Add support for UPM configuration on the 85xx platform.
> In addition, on the MPC83xx, remove MPC834x precompiler condition, in
> order to support all MPC83xx processors.
>
> Signed-off-by: David Saada <[EMAIL PROTECTED]>
Bad news, David, I think I mislead you with my Optio
This patch continues laying the ground work for moving out-of-assembly
and unifying the SDRAM initialization code for PowerPC 405EX[r]-based
boards.
To do so, this reduces by one the number of nearly-identical DRAM ECC
initialization implementations for PowerPC 4xx processors utilizing a
DDR/DDR2
The following changes since commit 180a90abdae72587c0f679edf8991455e559440d:
Wolfgang Denk (1):
Release v1.3.3
are available in the git repository at:
git://www.denx.de/git/u-boot-mpc86xx.git master
Jon Loeliger (1):
mpc86xx: Removed unused and unconfigured memory test code.
Add support for UPM configuration on the 85xx platform.
In addition, on the MPC83xx, remove MPC834x precompiler condition, in order to
support all MPC83xx processors.
Signed-off-by: David Saada <[EMAIL PROTECTED]>
cpu/mpc83xx/cpu.c |5
cpu/mpc85xx/cpu.c | 66 +++
Besides, other common code exists.
Signed-off-by: Jon Loeliger <[EMAIL PROTECTED]>
---
As per Wolfgang's request.
board/freescale/mpc8610hpcd/mpc8610hpcd.c | 36 -
board/freescale/mpc8641hpcn/mpc8641hpcn.c | 36 -
include/configs/MPC86
On Monday 19 May 2008, Detlev Zundel wrote:
> > To get current values each time we issue the "dtt" command including
> > upon powerup we switch into one-short mode.
>
> If we are in "one-short" mode, shouldn't we add 1 before the printout?
I had to read your mail twice before noticing my error.
>
> Option 1:
> -
> I've been playing with sending patches using Outlook. "Properly
> formatted" patches can be done by changing to a monospace font. This
> can be done either before or after pasting in the patch:
>
> Before pasting in the patch, you can change the format using a monospace
Stefan Roese wrote:
> Some time passed now, and we have only positive feedback to my suggestion. So
> I think we should move on and really switch this custodianship.
>
> Wolfgang, could you please arrange that Scott has access to the repo and list
> him as Custodian?
>
> Thanks.
>
> Scott, we
Hi Stefan,
> To get current values each time we issue the "dtt" command including
> upon powerup we switch into one-short mode.
If we are in "one-short" mode, shouldn't we add 1 before the printout?
Sorry, couldn't resist ;)
Cheers
Detlev
--
error compiling committee.c: too many arguments t
On Tuesday 13 May 2008, Kim Phillips wrote:
> > > Therefore I officially propose Scott Wood as new u-boot-nand-flash
> > > custodian. I would really like to get some feedback on this. Any
> > > comments or other suggestions?
> >
> > Acked-by: Grant Likely <[EMAIL PROTECTED]>
>
> Acked-by: Kim Phil
This allows the header to be included regardless of whether a board's
config file provides NAND-related defininitions.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
include/linux/mtd/nand.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/include/linux/mtd/nand.h b/
David Saada wrote:
>>> As you may have noticed, I've been trying to post some patches, but sending
>>> most of them failed due to line wrapping problems. This is a problem with
>>> the
>>> mailer we use here (outlook). Messing with the mailer didn't help, and so
>>> was
>>> posting via the Nabble
Thank you for your answer. But as you said in the letter, "NOR can be mapped in
its entirety, while with NAND only the first 4KiB gets
mapped, and that code has to fetch the rest of u-boot from NAND and copy it to
RAM before continuing." Why did you also mentioned that there is no need to
modif
From: Haavard Skinnemoen <[EMAIL PROTECTED]>
When compile-testing on powerpc, I get errors like this:
/home/hskinnemoen/work/git/u-boot/net/nfs.c:422: undefined reference to
`__stack_chk_fail_local'
This seems to be because -fstack-protector is on by default, so
let's explicitly disable it on a
>> As you may have noticed, I've been trying to post some patches, but sending
>> most of them failed due to line wrapping problems. This is a problem with the
>> mailer we use here (outlook). Messing with the mailer didn't help, and so was
>> posting via the Nabble forum or my gmail account in tex
Howdy,
I use uboot + linux kernel + ramdisk to start the board. The
kernel and ramdisk (say uImage and Ramdisk)
are stored on my PC. Each time, by typing:
tftp 20 uImage
tftp 60 Ramdisk
these two files are loaded to memory. Then enter "bootm 20 60"
to real boot. Well, I
Adam,
Make sure you have matching common transport sizes in your system - Section
4.4.3.16 RapidIO System Size in the 8548 manual.
Adam Nowak wrote:
> I have to configure the system (u-boot, kernel) and create the RIO
> driver. Could you advise me how to fix my current problem?
>
> a) Kernel l
Jerry Van Baren <[EMAIL PROTECTED]> writes:
> YES! YES! YES! This gets my vote. I marked the start of this thread
> meaning to suggest using temp variables of the right type and get rid of
> the complex casting crap, exactly what you did here.
Ack, but BTW
...whats wrong with the gener
In message <[EMAIL PROTECTED]> you wrote:
> The following changes since commit a38dc3ea8614f8b0c41e432b445a9959b9711295:
> Wolfgang Denk (1):
> TQM8272: fix out-of-tree building
>
> are available in the git repository at:
>
> git://www.denx.de/git/u-boot-ppc4xx.git master
>
> Stefan
46 matches
Mail list logo
