On Aug 15, 2008, at 9:23 AM, Zach Sadecki wrote:
Andy Fleming wrote:
On Wed, Jul 9, 2008 at 4:53 PM, Kim Phillips [EMAIL PROTECTED]
wrote:
On Wed, 9 Jul 2008 14:43:46 -0400
Paul Gortmaker [EMAIL PROTECTED] wrote:
Some boards that have external 16550 UARTs don't have a direct
tie
On Aug 7, 2008, at 5:47 AM, Rafal Jaworowski wrote:
Kumar Gala wrote:
Can you try the following patch and see if works for you (make sure
the
resulting image actually boots the board). If so I'll fixup all
the .lds
I changed to match.
Hi Kumar,
Thanks, the code works, although
On Aug 7, 2008, at 3:56 AM, Wolfgang Denk wrote:
Hi custodians,
there are a couple of recent patches which include some bug fixes that
look urgent enough to be included with the upcoming 1.3.4 release (the
last one with the old version number system).
Did we come to resolution on what the
the program headers and not
assigning the .bss to a program header.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
Wolfgang, can you pick this up for 1.3.4 as Andy's on vacation.
- k
board/freescale/mpc8540ads/u-boot.lds | 15 ++-
board/freescale/mpc8541cds/u-boot.lds | 15
the program headers and not
assigning the .bss to a program header.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
Fixes warning with older binutils
board/freescale/mpc8540ads/u-boot.lds | 16 +++-
board/freescale/mpc8541cds/u-boot.lds | 16 +++-
board/freescale/mpc8544ds/u
Anyone know why we pass the image_header_t * to the netbsd loader?
/*
* Booting a (NetBSD) kernel image
*
* This process is pretty similar to a standalone application:
* The (first part of an multi-) image must be a stage-2
loader,
*
if I understand Wolfgang and Jerry they'd like to recode the control
flow of the bootm command in the scripting env u-boot provides.
This seems to imply that we'd require HUSH as the simple parser
doesn't seem to provide any control statements like (if..then..else).
is this correct?
- k
On Aug 7, 2008, at 12:21 PM, Jerry Van Baren wrote:
Kumar Gala wrote:
if I understand Wolfgang and Jerry they'd like to recode the
control flow of the bootm command in the scripting env u-boot
provides.
This seems to imply that we'd require HUSH as the simple parser
doesn't seem
On Aug 7, 2008, at 2:34 PM, Wolfgang Denk wrote:
In any case, I expoect the total numbers of lines of code in U-Boot to
go down by quite an amount - for example, if we manage to get rid of
all the code duplication we have now across architectures.
I doubt this is really going to happen
On Aug 7, 2008, at 2:29 PM, Wolfgang Denk wrote:
In message
[EMAIL PROTECTED] you wrote:
if I understand Wolfgang and Jerry they'd like to recode the control
flow of the bootm command in the scripting env u-boot provides.
This seems to imply that we'd require HUSH as the simple parser
On Aug 7, 2008, at 3:47 PM, Wolfgang Denk wrote:
In message 45CA6EEB-4A74-46FC-A544-
[EMAIL PROTECTED] you wrote:
On Aug 7, 2008, at 2:34 PM, Wolfgang Denk wrote:
In any case, I expoect the total numbers of lines of code in U-
Boot to
go down by quite an amount - for example, if we
memory since we are a Book-E core.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
This is a fix for 1.3.4.
- k
cpu/mpc85xx/start.S | 19 +--
1 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/cpu/mpc85xx/start.S b/cpu/mpc85xx/start.S
index 10fe936..9c8b2a1 100644
if the environment variable 'disable_fdt_boardsetup' is set we skip
doing the ft_board_setup().
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
lib_ppc/bootm.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm.c
index 1182c50..a5b3a45
be relocated to RAM, including the
exception vectors, of course.
Any they are. I'm just removing a second relocation that is a hold
over from how 6xx PPC exception vectors work.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
This is a fix for 1.3.4.
I don't think so. Seems to introduce
On Aug 6, 2008, at 3:21 AM, Wolfgang Denk wrote:
In message [EMAIL PROTECTED]
you wrote:
Add a boot command that supports the ePAPR client interface on
powerpc.
What is the intended use of such a command?
How does it intergrate with with image formats supported by U-Boot?
To me
On Aug 6, 2008, at 3:33 AM, Wolfgang Denk wrote:
Dear Bartek,
in message [EMAIL PROTECTED] you wrote:
The test you're referring to was introduced by commit
75fa002c47171b73fb4c1f2c2fe4d6391c136276 [new uImage] Respect
autostart
setting in linux bootm by Kumar -- he should be better
On Aug 6, 2008, at 8:52 AM, pugazh mahalingam wrote:
Hi,
I'm using MPC8548PC Type N card.
where can I get the U-Boot code for this board. ?
i cannot run the other configuration in this board.
so can you please give the source code to MPC8548PC board.
you should talk to the vendor of that
if the environment variable 'no_ft_board_setup' is set we skip
doing the ft_board_setup().
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
lib_ppc/bootm.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm.c
index d141fae..1fce037 100644
the ePAPR spec has some subtle differences from the current device tree
based boot interface to the powerpc linux kernel. The powerpc linux kernel
currently ignores the differences that ePAPR specifies.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
lib_ppc/bootm.c | 33
On Aug 5, 2008, at 9:33 PM, Jerry Van Baren wrote:
Kumar Gala wrote:
here's a rough start at an outline for the bootm script based on
the code (I've only outlined the Linux/PPC boot case its seems the
most complicated). One of the first things we clearly need is a
imload command
On Aug 6, 2008, at 1:16 PM, Gerry Emon wrote:
Can anyone out there help me. I am doing some new development using
a MPC8349E (Hardware rev 3.1) and using an older version of u-boot
(1.1.3). I require hooks to the get_timer() API to allow me to
place timeout restrictions on areas of
On Aug 6, 2008, at 2:46 PM, Wolfgang Denk wrote:
In message [EMAIL PROTECTED] you
wrote:
It's hit me before when I foolishly try to load something at address
zero -- why do we put u-boot at the end of RAM, and put up with the
relocation weirdness, if not to allow loading things at zero?
On Aug 6, 2008, at 2:41 PM, Wolfgang Denk wrote:
In message 5E53E387-237D-480E-
[EMAIL PROTECTED] you wrote:
one idea is having stages of bootm handled as sub commands:
bootm start args
bootm prep(disable interrupts, stop usb, disable caches)
--- Point of no return here ---
bootm
On Aug 6, 2008, at 2:55 PM, Jerry Van Baren wrote:
Kumar Gala wrote:
On Aug 5, 2008, at 9:33 PM, Jerry Van Baren wrote:
Kumar Gala wrote:
here's a rough start at an outline for the bootm script based on
the code (I've only outlined the Linux/PPC boot case its seems
the most
On Aug 6, 2008, at 3:17 PM, Wolfgang Denk wrote:
In message 9D199630-11FA-4028-8EE6-
[EMAIL PROTECTED] you wrote:
Good point. Why don't we factor this out and make it common code for
all PPC?
Because the relocation is specific to the various interrupt types.
Book-E will need different
On Aug 6, 2008, at 3:36 PM, Wolfgang Denk wrote:
In message 6130E31C-5845-4DCF-
[EMAIL PROTECTED] you wrote:
Ooo, that sounds hard. If we are only re-enabling interrupts/usb/
caches it probably is manageable, but my hackles.
This is a buyer-beware kinda of situation. Think about a case
On Aug 6, 2008, at 3:41 PM, Wolfgang Denk wrote:
In message D5CA3AB9-3AE3-439C-A169-
[EMAIL PROTECTED] you wrote:
Book-E will need different code for handing IVPR/IVORs than
classic.
Umm... the exception code itself may be different, but does this
imply
that the code used to copy /
Stop, this is not correct. filesize gets set when loading the
(compressed) image. It contains the _file_ size, i. e. the sum of
all
included images plus headers etc.
bootm does not touch filesize.
in the method you guys seem to be arguing for we have to return the
address the image was
On Aug 5, 2008, at 5:19 AM, Wolfgang Denk wrote:
In message [EMAIL PROTECTED] you wrote:
My current best thought is to create a new boot simple (boots?
bootsm?) command that contains only the essence of bootm. I would
then
change the command bootm to do a hush script run of the env
On Aug 5, 2008, at 8:36 AM, Jerry Van Baren wrote:
Kumar Gala wrote:
On Aug 5, 2008, at 5:19 AM, Wolfgang Denk wrote:
[snip]
One idea that has been spinning in my mind for some time is to
make
the run command to execute the content of an environment
variable
optional. Instead
Can we drop any functionality from the current bootm?
For example does powerpc still need to support bd_t based booting?
- k
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest
here's a rough start at an outline for the bootm script based on the
code (I've only outlined the Linux/PPC boot case its seems the most
complicated). One of the first things we clearly need is a imload
command. Thoughts on the various disable_{interrupts, usb, caches} ?
- k
bootm
On Aug 5, 2008, at 9:45 AM, Wolfgang Denk wrote:
In message
[EMAIL PROTECTED] you wrote:
Can we drop any functionality from the current bootm?
Any? You mean:
int bootm (...)
{
return 0;
}
:-)
if it were only so easy :)
For example does powerpc
On Aug 5, 2008, at 8:36 AM, Jerry Van Baren wrote:
Kumar Gala wrote:
On Aug 5, 2008, at 5:19 AM, Wolfgang Denk wrote:
[snip]
One idea that has been spinning in my mind for some time is to
make
the run command to execute the content of an environment
variable
optional. Instead
[snip]
As I look at this more and more I think trying to re-encode the
control flow of the bootm command in a script is just insane.
There are too many special cases we have to deal with that we'd
just being moving from C code into the script.
My assumption is that a given
. The current point in the code we do this we have yet to
determine the final size and have yet to do the final fixup of the initrd
information.
If its desirable for the 'fdtcmd' support to have the proper initrd
information a bit of code reorder will be in order.
Signed-off-by: Kumar Gala [EMAIL PROTECTED
On Aug 5, 2008, at 11:50 AM, Kumar Gala wrote:
Added the 'fdtcmd' environment variable as a way to provide 'fdt'
commands
that the user can supply to manipulate the device tree after
ft_board_setup() and before the tree is handled to the kernel.
The idea is that users may want to add
Is this something we'd be willing to put into mainline?
- k
diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm.c
index a872d31..3ebddd3 100644
--- a/lib_ppc/bootm.c
+++ b/lib_ppc/bootm.c
@@ -192,7 +192,8 @@ do_bootm_linux(cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[],
}
#ifdef
. The current point in the code we do this we have yet to determine the
final size and have yet to do the final fixup of the initrd information.
If its desirable for the 'fdtcmd' support to have the proper initrd information
a bit of code reorder will be in order.
Signed-off-by: Kumar Gala [EMAIL PROTECTED
On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote:
In message [EMAIL PROTECTED]
you wrote:
Added the 'fdtcmd' environment variable as a way to provide 'fdt'
commands
that the user can supply to manipulate the device tree after
ft_board_setup()
and before the tree is handled to the
Rafal,
Can you try the following patch and see if works for you (make sure the
resulting image actually boots the board). If so I'll fixup all the .lds
I changed to match.
diff --git a/board/freescale/mpc8555cds/u-boot.lds
b/board/freescale/mpc8555cds/u-boot.lds
index a18b3a7..e7fbe5d 100644
On Aug 4, 2008, at 3:19 PM, Jerry Van Baren wrote:
Kumar Gala wrote:
On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote:
In message Pine.LNX.
[EMAIL PROTECTED] you wrote:
Added the 'fdtcmd' environment variable as a way to provide
'fdt' commands
that the user can supply to manipulate
On Aug 4, 2008, at 3:27 PM, Wolfgang Denk wrote:
In message
[EMAIL PROTECTED] you wrote:
Added the 'fdtcmd' environment variable as a way to provide 'fdt'
commands
that the user can supply to manipulate the device tree after
ft_board_setup()
and before the tree is handled to the
On Aug 4, 2008, at 3:44 PM, Jerry Van Baren wrote:
Kumar Gala wrote:
On Aug 4, 2008, at 3:19 PM, Jerry Van Baren wrote:
Kumar Gala wrote:
On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote:
In message [EMAIL PROTECTED]
you wrote:
Added the 'fdtcmd' environment variable as a way to provide
On Aug 4, 2008, at 3:55 PM, Scott Wood wrote:
Kumar Gala wrote:
On Aug 4, 2008, at 3:27 PM, Wolfgang Denk wrote:
So just run the needed commands before you run bootm as part of
your
boot command sequence.
This doesnt work. Lets say I want to remove a node or property
On Aug 4, 2008, at 4:07 PM, Wolfgang Denk wrote:
In message F388F9D5-B685-4DD8-
[EMAIL PROTECTED] you wrote:
So just run the needed commands before you run bootm as part of
your
boot command sequence.
This doesnt work. Lets say I want to remove a node or property that
If we really want to simplify what bootm does than I think we should
remove ft_board_setup() from lib_ppc/bootm.c and expect any actually
modification of the device tree to have already occurred.
Is this something we'd really be willing to do?
- k
diff --git a/lib_ppc/bootm.c
Its useful to know where the device tree is if we have set 'autostart'
to 'no. We come back to the prompt after a boot command and we can
than post process the device tree but we need to know where it was put
report this back via the env variable 'bootm_fdtaddr'.
Signed-off-by: Kumar Gala [EMAIL
On Aug 1, 2008, at 10:17 AM, Wolfgang Denk wrote:
Hello,
I would like to get your general opinion about moving the
u-boot-users mailing list away from SourceForge and host it on
lists.denx.de instead.
Yes!
- k
-
This
this code came to be is:
bin_at(0) = (char*)(av_[2]) - 2*SIZE_SZ
SIZE_SZ is the size of pointer, and av_ is arry of pointers so:
bin_at(0) = (av_[0])
Going from there to bin_at(0)-fd or bin_at(0)-size should be straight forward.
Signed-off-by: Kumar Gala [EMAIL PROTECTED
/bios_emulator/atibios.o so the files are common since we
do run ATI video cards on some boards
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
board/freescale/mpc8540ads/u-boot.lds | 35
board/freescale/mpc8541cds/u-boot.lds | 36 +++--
board
On Jul 30, 2008, at 11:07 AM, Wolfgang Denk wrote:
In message [EMAIL PROTECTED]
you wrote:
.text :
{
cpu/mpc85xx/start.o (.text)
-cpu/mpc85xx/traps.o (.text)
-cpu/mpc85xx/interrupts.o (.text)
-cpu/mpc85xx/cpu_init.o (.text)
-cpu/mpc85xx/cpu.o (.text)
is 4-byte aligned as the .bss init code expects this.
(Its possible that the end of .bss isn't 4-byte aligned)
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
* fixed the issue with the ATI emu code by ensuring _end is 4-byte aligned.
- k
board/freescale/mpc8540ads/u-boot.lds | 37
On Jul 30, 2008, at 11:07 AM, Wolfgang Denk wrote:
In message [EMAIL PROTECTED]
you wrote:
.text :
{
cpu/mpc85xx/start.o (.text)
-cpu/mpc85xx/traps.o (.text)
-cpu/mpc85xx/interrupts.o (.text)
-cpu/mpc85xx/cpu_init.o (.text)
-cpu/mpc85xx/cpu.o (.text)
Is there any concern with moving .bss outside of the image? On 85xx
the images have historically been a fixed size (512k) and the .bss has
always lived inside of that region. We are now getting to a point
that .text + .data + .bss exceeds 512k. Its easy enough to move .bss
right pass the
In debugging moving the bss outside of the image on 85xx I run into in
issue with the SPD code using fsl_i2c before we are running in ram and
setup the BSS.
It looks like i2c_wait4bus() [in fsl_i2c.c] calls get_timer().
get_timer implemented in lib_ppc/interrupts.c and uses a global
On Jul 29, 2008, at 9:48 AM, Kumar Gala wrote:
In debugging moving the bss outside of the image on 85xx I run into in
issue with the SPD code using fsl_i2c before we are running in ram and
setup the BSS.
It looks like i2c_wait4bus() [in fsl_i2c.c] calls get_timer().
get_timer implemented
be reading/writing
a random location (probably in flash).
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
This is a fix for 1.3.4.
- k
drivers/i2c/fsl_i2c.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c
index
dlmalloc.c:3008: warning: dereferencing type-punned pointer will break
strict-aliasing rules
dlmalloc.c:3012: warning: dereferencing type-punned pointer will break
strict-aliasing rules
dlmalloc.c:3021: warning: dereferencing type-punned pointer will break
strict-aliasing rules
Signed-off-by: Kumar
On Jul 29, 2008, at 4:25 PM, Wolfgang Denk wrote:
In message 2A2FDF2A-7B9D-496C-960C-
[EMAIL PROTECTED] you wrote:
Is there any concern with moving .bss outside of the image? On 85xx
the images have historically been a fixed size (512k) and the .bss
has
always lived inside of that
One topic that come up during OLS in discussions and u-boot BOF was
the idea of driving u-boot configuration from a device tree instead of
from config.h. I was wondering if anyone has actually looked at
doing this.
One question I have is how does (or should) u-boot identify where to
find
On Jul 28, 2008, at 12:40 PM, Grant Likely wrote:
On Mon, Jul 28, 2008 at 10:07:49AM -0500, Kumar Gala wrote:
One topic that come up during OLS in discussions and u-boot BOF was
the idea of driving u-boot configuration from a device tree instead
of
from config.h. I was wondering
On Jul 28, 2008, at 1:13 PM, Wolfgang Grandegger wrote:
Kumar Gala wrote:
One topic that come up during OLS in discussions and u-boot BOF
was the idea of driving u-boot configuration from a device tree
instead of from config.h. I was wondering if anyone has
actually looked
On Jul 10, 2008, at 1:43 PM, Scott Wood wrote:
Wolfgang Denk wrote:
In message [EMAIL PROTECTED]
you wrote:
Try adding -fno-strict-aliasing
No, we don't want to hush up compiler warnings, we want to fix the
problems instead.
It's not silencing a warning (if it were, it'd be a -W
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
common/cmd_mp.c |2 +-
cpu/mpc85xx/mp.c |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/common/cmd_mp.c b/common/cmd_mp.c
index 26a57c5..59d0d15 100644
--- a/common/cmd_mp.c
+++ b/common/cmd_mp.c
@@ -35,7 +35,7
On Jul 14, 2008, at 10:09 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 09:42 Mon 14 Jul , Kumar Gala wrote:
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
common/cmd_mp.c |2 +-
cpu/mpc85xx/mp.c |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/common
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
updated based on comments from Jean.
- k
common/cmd_mp.c |2 +-
cpu/mpc85xx/mp.c |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/common/cmd_mp.c b/common/cmd_mp.c
index 26a57c5..b2a397c 100644
--- a/common
The L2 size detection code was a bit confusing and we kept having to add
code to it to handle new processors. Change the sense of detection so we
look for the older processors that aren't changing.
Also added support for 1M cache size on 8572.
Signed-off-by: Kumar Gala [EMAIL PROTECTED
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
board/freescale/mpc8544ds/mpc8544ds.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/board/freescale/mpc8544ds/mpc8544ds.c
b/board/freescale/mpc8544ds/mpc8544ds.c
index 8c4b040..c39ce11 100644
--- a/board/freescale
Add support for using a PCIe ATI Video card on PCIe2.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
board/freescale/mpc8544ds/u-boot.lds |1 +
include/configs/MPC8544DS.h | 24 ++--
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/board
On Jul 8, 2008, at 4:42 PM, Paul Gortmaker wrote:
I was updating a sbc8560 from u-boot v1.2.0 to git-current, and found
that I'd loose the kernel serial console when the 8250 driver took
over
from udbg0 when using u-boot 1.3.x (booting via tftp'ing the dtb and
the uImage separately)
I
as a shorter path reference.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
common/cmd_fdt.c | 20 +---
1 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/common/cmd_fdt.c b/common/cmd_fdt.c
index 97b9dd7..65c5cdf 100644
--- a/common/cmd_fdt.c
+++ b/common/cmd_fdt.c
@@ -678,9
On Jul 8, 2008, at 2:32 AM, David Saada wrote:
Does this RFC also include support for identifying and initializing
more than one DDR module?
I'm not sure I follow exactly what you are asking? Do you mean using
different DDR modules on different chip selects of the same
controller? or
On Jul 7, 2008, at 10:48 AM, Jon Loeliger wrote:
On Sun, 2008-07-06 at 00:32 +0200, Wolfgang Denk wrote:
Dear Kumar,
in message [EMAIL PROTECTED]
you wrote:
This is a series of patches that are a work-in-progress towards a
new
DDR initialization for the Freescale 8{3,5,6}xxx devices
a feature field to convey useful attributes of the
processor.
(for 85xx we have a single feature to tell if the processor has a
crypto
engine or not).
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
cpu/mpc85xx/cpu.c | 77 +
+
include
On Jul 6, 2008, at 3:04 AM, David Saada wrote:
Kumar Gala-3 wrote:
This is a series of patches that are a work-in-progress towards a
new
DDR initialization for the Freescale 8{3,5,6}xxx devices that have a
common DDR controller.
(Sorry for the previous no subject message - hit
On Jul 2, 2008, at 9:11 AM, Andrew Klossner wrote:
From 03e28f90637703aaef9356dc398adedcdf06cb94 Mon Sep 17 00:00:00
2001
From: Andrew Klossner [EMAIL PROTECTED]
Date: Wed, 2 Jul 2008 07:03:53 -0700
Subject: [PATCH] Change the temp map to ROM to align addresses to
page size.
With a
On Jul 2, 2008, at 9:25 AM, Andrew Klossner wrote:
The MPC8555E and MPC8548E reference manuals are quite specific about
the formula required to change the value of CCSRBAR. This patch
implements that formula.
Those manuals are not correct in their description of updating CCSRBAR.
The
On Jun 26, 2008, at 9:50 AM, Dave Liu wrote:
Current fat.c have three 64KB static array, it makes
the BSS section larger.
Change the static to dynamic allocation.
Signed-off-by: Dave Liu [EMAIL PROTECTED]
---
fs/fat/fat.c | 38 +++---
1 files changed, 35
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
board/freescale/mpc8610hpcd/mpc8610hpcd.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/board/freescale/mpc8610hpcd/mpc8610hpcd.c
b/board/freescale/mpc8610hpcd/mpc8610hpcd.c
index c85f373..0bf21d5 100644
--- a/board
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
board/freescale/mpc8641hpcn/mpc8641hpcn.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/board/freescale/mpc8641hpcn/mpc8641hpcn.c
b/board/freescale/mpc8641hpcn/mpc8641hpcn.c
index cf540fc..b30c6b1 100644
--- a/board
The L2 size detection code was a bit confusing and we kept having to add
code to it to handle new processors. Change the sense of detection so we
look for the older processors that aren't changing.
Also added support for 1M cache size on 8572.
Signed-off-by: Kumar Gala [EMAIL PROTECTED
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
board/freescale/mpc8544ds/mpc8544ds.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/board/freescale/mpc8544ds/mpc8544ds.c
b/board/freescale/mpc8544ds/mpc8544ds.c
index f615b23..1994e77 100644
--- a/board/freescale
This patch fixes the problem.
Signed-off-by: Anatolij Gustschin [EMAIL PROTECTED]
Acked-by: Stefan Roese [EMAIL PROTECTED]
Acked-by: Kumar Gala [EMAIL PROTECTED]
- k
-
Check out the new SourceForge.net Marketplace.
It's
On Jun 10, 2008, at 6:51 PM, Wolfgang Denk wrote:
Dear Kumar,
in message 3F2661BD-8C86-410F-984D-
[EMAIL PROTECTED] you wrote:
Comments and code do not match; you'r actually adding much more
code.
I was just needing the u64 versions and the other stuff came along to
make it work :)
fls64, __ilog2_u64, ffs64 are variants that work on an u64 and fls
is used to implement them.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
Dropped __fls and cleaned up things a bit based on feedback (commit message is
more explicit).
- k
include/asm-ppc/bitops.h | 49
On Jun 11, 2008, at 5:54 AM, Haavard Skinnemoen wrote:
Kumar Gala [EMAIL PROTECTED] wrote:
+/*
+ * fls: find last (most-significant) bit set.
+ * Note fls(0) = 0, fls(1) = 1, fls(0x8000) = 32.
+ */
+static __inline__ int fls(unsigned int x)
+{
+return __ilog2(x) + 1
On Jun 11, 2008, at 9:03 AM, Haavard Skinnemoen wrote:
Kumar Gala [EMAIL PROTECTED] wrote:
On Jun 11, 2008, at 5:54 AM, Haavard Skinnemoen wrote:
Kumar Gala [EMAIL PROTECTED] wrote:
+/*
+ * fls: find last (most-significant) bit set.
+ * Note fls(0) = 0, fls(1) = 1, fls(0x8000) = 32
fls64, __ilog2_u64, ffs64 are variants that work on an u64 and fls
is used to implement them.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
added comment about __ilog2() x == 0 being undefined.
include/asm-ppc/bitops.h | 50 ++
1 files changed
fls64, __ilog2_u64, ffs64 are variants that work on an u64 and fls
is used to implement them.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
Added comment about __ilog2(0) not being generally safe from Haavard Skinnemoen
- k
include/asm-ppc/bitops.h | 52
On Jun 11, 2008, at 5:53 PM, Wolfgang Denk wrote:
In message [EMAIL PROTECTED]
you wrote:
This patch changes the return type of initdram() from long int to
phys_size_t.
This is required for a couple of reasons: long int limits the
amount of dram
to 2GB, and u-boot in general is
On Jun 10, 2008, at 12:57 AM, Kim Phillips wrote:
On Thu, 29 May 2008 03:20:08 -0500 (CDT)
Kumar Gala [EMAIL PROTECTED] wrote:
+struct cpu_type cpu_type_list [] = {
+CPU_TYPE_ENTRY(8533, 8533, 0),
+CPU_TYPE_ENTRY(8533, 8533_E, CPU_FTRS_HAS_CRYPTO),
+CPU_TYPE_ENTRY(8540, 8540
On Jun 10, 2008, at 8:48 AM, Kim Phillips wrote:
On Tue, 10 Jun 2008 08:23:46 -0500
Kumar Gala [EMAIL PROTECTED] wrote:
On Jun 10, 2008, at 12:57 AM, Kim Phillips wrote:
On Thu, 29 May 2008 03:20:08 -0500 (CDT)
Kumar Gala [EMAIL PROTECTED] wrote:
+struct cpu_type cpu_type_list
On Jun 10, 2008, at 11:06 AM, Kim Phillips wrote:
differentiate with local variables of the same name by renaming the
global 'fdt' variable 'working_fdt'.
Signed-off-by: Kim Phillips [EMAIL PROTECTED]
---
applies to current u-boot-fdt.git.
thank you, this was just evil.
- k
LAWs have the concept of priority so its useful to be able to allocate
the lowest (highest number) priority. We will end up using this with the
new DDR code.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
drivers/misc/fsl_law.c| 19 +++
include/asm-ppc/fsl_law.h |1
void ft_cpu_setup(void *blob, bd_t *bd)
{
+ /* delete crypto node if not on an E-processor */
+ if (!IS_E_PROCESSOR(get_svr()))
+ fdt_fixup_crypto_node(blob, 0);
+
This is wrong or you need to fix the IS_E_PROCESSOR() macro.
IS_E_PROCESSOR(svr) should be defined:
svr
print this out. This is mainly to allow the most flexible use
of the name. The device tree code tends to not care about the 'E' suffix.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
Reworked and dropped the flags idea and just use SVR to determine the 'E' bit.
At this point he HW guys
On Jun 10, 2008, at 4:58 PM, Wolfgang Denk wrote:
In message [EMAIL PROTECTED]
you wrote:
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
Comments and code do not match; you'r actually adding much more code.
I was just needing the u64 versions and the other stuff came along to
make it work
This is a series of patches that are a work-in-progress towards a new
DDR initialization for the Freescale 8{3,5,6}xxx devices that have a
common DDR controller.
These patches are also available at:
git://git.kernel.org/pub/scm/boot/u-boot/galak/u-boot.git fsl_ddr
and patch 0002 since its large
Also added a few helper functions for DDR1 DDR2 to print SPD info and
verify the checksum.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
common/Makefile |1 +
common/ddr_spd.c | 504 +
include/ddr_spd.h | 249
1 - 100 of 265 matches
Mail list logo
