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 hav
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
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 simpl
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 bec
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
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
---
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,
* whi
On Aug 7, 2008, at 8:22 AM, Wolfgang Denk wrote:
> In message [EMAIL PROTECTED]> you wrote:
>>
>>> 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 numbe
On Aug 7, 2008, at 8:21 AM, Wolfgang Denk wrote:
> In message
> <[EMAIL PROTECTED]> you wrote:
>>
>>> ./MAKEALL MPC8555CDS
>>> Configuring for MPC8555CDS board...
>>> ppc_85xx-ld: u-boot: warning: allocated section `.bss' not in
>>> segment
>>> textdata bss dec hex filename
>
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/mpc85
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
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
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 mat
So I proposed something like:
bootm load_os
bootm load_fdt
so I figured trying to expand on what load_os does might be useful.
input:
ENV:bootm_low
ENV:bootm_size
BOOTMAP_SZ
image specifier (a standalone uImage, a multi-uImage, a FIT specifier)
output:
ERROR: if image doesn't pass validity chec
>>> 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
On Aug 6, 2008, at 3:41 PM, Wolfgang Denk wrote:
> In message [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 / re
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. Thi
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
On Aug 6, 2008, at 3:26 PM, Wolfgang Denk wrote:
> In message
> <[EMAIL PROTECTED]> you wrote:
>>
>>> Note that you cannot recover / restore after starting to uncompress
>>> the image, because usually you will overwrite the exception vectors.
>>
>> Normally that is true.. however there are some
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
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
>> bootm prep(disable interrupts, stop usb, disable caches)
> --- Point of no return here
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 thing
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 o
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 w
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
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
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 th
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 shou
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
ase U-Boot
> for example to install a new version.
>
> All references to flash memory must 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.
>>
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
Add a boot command that supports the ePAPR client interface on powerpc.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
lib_ppc/bootm.c | 63 +++
1 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/lib_ppc/bootm.c b/l
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'.
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
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 CO
On Aug 5, 2008, at 4:40 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
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.
>
&
u-boot binary. 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
[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 b
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
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
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 script:
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 Li
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
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
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 b/lib_ppc/bootm
On Aug 4, 2008, at 4:07 PM, Wolfgang Denk wrote:
> In message [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
>> ft_board_setup(
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
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]
>>&
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
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
>
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 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 handl
u-boot
binary. 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
On Aug 1, 2008, at 10:32 AM, Wolfgang Denk wrote:
> Hello,
>
> I would like to get your general opinion about changing the U-Boot
> version numbering scheme.
>
> To be honest, I never really understood myself how this is supposed
> to work and if the next version should be 1.3.4 or 1.4.0 or
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
On Jul 9, 2008, at 12:02 PM, Jerry Van Baren wrote:
>
> Thinking out loud... we could define the syntax that a leading "*"
> indicates the first part of the path is a dereference of /aliases.
>
> Assuming
> /aliases/soc = /[EMAIL PROTECTED]
> /aliases/ethernet0 = /[EMAIL PROTECTED]/.../enet0
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'.
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/mp
nd 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
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/mp
ivers/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
pointer will break
strict-aliasing rules
The logic of how 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)->siz
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 o
encing type-punned pointer will break
strict-aliasing rules
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 poi
could 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_
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()
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
timesta
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
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 wonder
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
>&
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
fin
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, i
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
Add new L1/L2 SPRs related to e500mc cache config and control.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
include/asm-ppc/processor.h | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/include/asm-ppc/processor.h b/include/asm-ppc/proce
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/fre
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 P
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/
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 ++--
>>
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
I'm running with gcc-4.3 from fedora 9. I get the following warnings:
dlmalloc.c: In function ‘malloc_extend_top’:
dlmalloc.c:1971: error: dereferencing type-punned pointer will break
strict-aliasing rules
dlmalloc.c:1999: error: dereferencing type-punned pointer will break
strict-aliasing ru
On Jul 9, 2008, at 10:17 AM, Jerry Van Baren wrote:
> Kumar Gala wrote:
>> If the path we are trying to print doesn't exist see if it matches an
>> aliases. We don't do anything fancy at this point, but just strip
>> the
>> leading '/' if it
s could be used
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_fd
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
On Jul 8, 2008, at 2:32 AM, David Saada wrote:
>
>> > < 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 something else?
>>
>> - k
> Kumar - the current SPD DDR c
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
On Jul 7, 2008, at 10:57 AM, Wolfgang Denk wrote:
> Dear Becky,
>
> in message <[EMAIL PROTECTED]> you
> wrote:
>>
>> I see the following when I build for 8641HPCN on the latest tree:
>>
>> bootm.c: In function ‘do_bootm_linux’:
>> bootm.c:208: warning: cast from pointer to integer of different
gcc-4.3.x generates the following:
bootm.c: In function 'do_bootm_linux':
bootm.c:208: warning: cast from pointer to integer of different size
bootm.c:215: warning: cast from pointer to integer of different size
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
lib_ppc/bootm.
On Jul 5, 2008, at 5:32 PM, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]>
> you wrote:
>> When we building with gcc-4.3.x on a ppc host we get the following
>> warnings:
>>
>> dlmalloc.c: In function 'malloc_extend_top':
>> dlmalloc.c:1971: warning: dereferencing type-punned pointer w
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 c
ree setup).
>>
>> Also, we add 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
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 cur
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.
>
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 cha
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
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
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/fre
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 P
On Jun 16, 2008, at 3:55 PM, Kim Phillips wrote:
> Delete the crypto node if not on an E-processor. If on 8360 or 834x
> family,
> check rev and up-rev crypto node (to SEC rev. 2.4 property values)
> if on an 'EA' processor, e.g. MPC8349EA.
>
> Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
>
; before 'ver'
>> make[1]: *** [4xx_pcie.o] Error 1
>>
>> This patch fixes the problem.
>>
>> Signed-off-by: Anatolij Gustschin <[EMAIL PROTECTED]>
>
> Acked-by: Stefan Roese <[EMAIL PROTECTED]>
Acked-by: Kumar Gala <[EMAIL PROTEC
1 - 100 of 373 matches
Mail list logo
