[U-Boot-Users] U-Boot on MPC8280

[U-Boot-Users] U-Boot on MPC8280

[Rod Boyce]

This is just my $0.02 worth but I have used our BDI2000 to debug User land
application, Kernel, and device drivers at the same time.  It is an
invaluable tool when tracking down both software and hardware bugs.  In fact
I will start hardware debugging with our BDI before cabling up a Logic
analyzer.  
I can say that without a doubt if we had not use the BDI2000 in this way we
would have ended up redesigning the hardware to get around some perceived
limitations.  Instead I found the software bug and fixed it.  I did all this
in about 3-hours work as well.

I don't use the BDI all the time to debug user mode applications but when
you want to stop the hole processor it is invaluable.  To be able to step
through user code and then jump into the kernel on system calls is just
great.

I cannot tell you how much time our BDI has saved us.  We also have a Vision
ICE in another office I am not completely familiar with the Vision Ice but
compared to the functionality I get from a BDI the Vision Ice is a very poor
second.


Regards,
Rod

-----Original Message-----
From: Wolfgang Denk [mailto:wd at denx.de]
Sent: Thursday, January 08, 2004 4:46 AM
To: David Aldrich
Cc: Matias Sundman (AL/EAB); u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] U-Boot on MPC8280 


Dear David,

in message
<0E8A20F2EB7BD7119C1F00508BB333780E5D7B@tmservermail02.t-modus.nec.co.uk>
you wrote:
> 
> Is it true that the BDI is not suitable for user app debug?  Is this a

Yes, this is true. Well, you _can_ use  it,  but  you  have  manually
navigate  through  the  kernel virtual address space to find what you
are looking for. Sometimes  this  is  necessary  (typically  to  find
kernel  bugs),  but  this is definitely nothing to do for the average
user.

> problem in practice?

No, it is not.

Kernel debugging and application debugging are two separate  weorlds,
like  kernel  address  space  and  user  address  space  are  clearly
separated. There is tools for both of them: for the firmware,  device
drivers  and  kernel  debugging  you  use  the  BDI2000, and for user
applications you use gdbserver or gdb.

Note that this does not mean  any  loss  of  productivity:  both  the
BDI2000  and  gdbserver  "speak" GDB remote protocol, so you will see
absolutely the same user interface.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"If the code and  the  comments  disagree,  then  both  are  probably
wrong."                                                - Norm Schryer


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] U-Boot on MPC8280

[John W. Linville]

Rod Boyce wrote:

>This is just my $0.02 worth but I have used our BDI2000 to debug User land
>application, Kernel, and device drivers at the same time.  It is an
>  
>
Rod,

We, too, have used the BDI2000 in such a fashion.  I agree that it can 
be invaluable when debugging the interaction between a userland 
application and a kernel driver.

Can you describe the method you use to do this?  Our process is a bit 
cumbersome, involving putting a breakpoint in a driver's ioctl() 
function that will only be called by our application.  Once it is hit, 
we use add-symbol-file to get the information for our application's 
binary, and we are able to proceed.  This is on a PowerPC chip, with the 
special "BDI2000 support" hack turned-on.

Is your method any "cleaner"?

Thanks,

John

-- 
John W. Linville
LVL7 Systems, Inc.

[U-Boot-Users] BDI2000 vs Vision-ICE

[Mike Wellington]

People at my place of work are telling me that the
Vision-Ice supports "backtrace" and the BDI2000 does
not.   I looked on the Abatron website and it doesn't
say.  Can anyone confirm or deny this?

By "backtrace", I mean the ability to set a breakpoint,
hit that breakpoint, and be able to see the last N
instructions executed.

-mike wellington
  wellington at lucent.com



John W. Linville wrote:

> Rod Boyce wrote:
> 
>> This is just my $0.02 worth but I have used our BDI2000 to debug User 
>> land
>> application, Kernel, and device drivers at the same time.  It is an
>>  
>>
> Rod,
> 
> We, too, have used the BDI2000 in such a fashion.  I agree that it can 
> be invaluable when debugging the interaction between a userland 
> application and a kernel driver.
> 
> Can you describe the method you use to do this?  Our process is a bit 
> cumbersome, involving putting a breakpoint in a driver's ioctl() 
> function that will only be called by our application.  Once it is hit, 
> we use add-symbol-file to get the information for our application's 
> binary, and we are able to proceed.  This is on a PowerPC chip, with the 
> special "BDI2000 support" hack turned-on.
> 
> Is your method any "cleaner"?
> 
> Thanks,
> 
> John
> 


-- 

=mike wellington
wellington at lucent.com
303.920.6412  Desk
720.434.7559  Cell

[U-Boot-Users] BDI2000 vs Vision-ICE

[Wolfgang Denk]

Dear Mike,

in message <3FFDC547.3010302@lucent.com> you wrote:
> People at my place of work are telling me that the
> Vision-Ice supports "backtrace" and the BDI2000 does
> not.   I looked on the Abatron website and it doesn't
> say.  Can anyone confirm or deny this?
> 
> By "backtrace", I mean the ability to set a breakpoint,
> hit that breakpoint, and be able to see the last N
> instructions executed.

I don't know about the Vision-Ice; but  I've  been  working  (several
years  ago) in a project were we spent a lot of $$$ to buy a SuperTAP
ICE by  Applied  Microsystems  exactly  because  they  promised  this
feature.  It  never  worked  for us. It didn't work at full processor
speed, and the problems where we really wanted a trace did  not  show
up  at  lower  clock  speeds.  The other setup used a MPC8xx with bus
divider  enabled  (CPU  clock  =  2  x  bus  clock).  With   such   a
configuration,  the  CPU does not output the signals you need for the
trace on any pins, so you cannot  get  any  trace  (no  matter  which
vendor's box you buy).

In my experience, this is marketing babble. For the low  level  stuff
("simple  problems"),  a  good logic analyzer is at least as capable,
and for  the  highlevel  ("complicated")  problems  it  doesn't  work
anyway,  and  a plain BDM/JTAG debugger plus a little brain and a lot
of experience gives beter results.

Just my $ 0.02 - ymmv.

Best regards,

Wolfgang Denk

-- 
See us @ Embedded World, Nuremberg, Feb 17 - 19,  Hall 12.0 Booth 440
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
By the way, ALL software projects are done by iterative  prototyping.
Some companies call their prototypes "releases", that's all.

[U-Boot-Users] BDI2000 vs Vision-ICE

[Richard Danter]

Mike Wellington wrote:
> People at my place of work are telling me that the
> Vision-Ice supports "backtrace" and the BDI2000 does
> not.   I looked on the Abatron website and it doesn't
> say.  Can anyone confirm or deny this?

I can't talk about the Abatron, but for vICE there are a couple of 
options which are/were available.

 >
 > By "backtrace", I mean the ability to set a breakpoint,
 > hit that breakpoint, and be able to see the last N
 > instructions executed.

In the old days there was vEVENT. It was a bus trace system which 
captured all accesses from the CPU to any/all peripherals. It was 
available for most of the architectures WR/EST supported. This was EOL'd 
in favour of the LA-Trace.

LA-Trace is a combination of a vPROBE or vICE with a full logic 
analyser. The reason for switching to this was that the old vEVENT could 
not keep up with the newer CPU's running at high (>50MHz) bus speeds.

The problem with both of these options, and any other system using bus 
capture, is that they don't see everything. When the CPU is executing 
code from cache there is nothing visible outside so all you see are the 
code and data read/writes associated with a cache miss. Worse still is 
that when a read occurs the cache will usually get a complete cache 
line, not just the word required. Somtimes the whole line will be used 
(as in sequential code) but not always. It's tricky working out what is 
relevant and what is not. As caches get bigger so this problem gets worse.

The best option is vTRACE, but it is available only on a limited number 
of CPU's. This is beacuse vTrace uses the trace capability built in to 
some CPU's. The best trace capabilities are in the ColdFIRE range - they 
all support data tracing as well as code, but on PowerPC you can get 
code trace on the 405x, 440GP and 56x (NEXUS). There are also some MIPS 
processors which have this capability.

Whilst we are talking about vICE, thought I would just mention that it 
now supports Linux debugging too on some CPUs. That is, it has MMU 
awareness for the 82xx and 405x CPUs so you can debug the kernel and 
loadable modules with full source code. More than that though, they now 
also support some user-land debugging. I spose this is more relevant to 
the linux mailing list though...

Rich

[U-Boot-Users] U-Boot on MPC8280

[Rod Boyce]

John,

The method I use is no less "cleaner" I just start out in userland process
in stead of kernel mode.  Single stepping from Userland to Kernel mode has
never worked I just use two hardware break points one in the kernel and one
in the User process.

Regards,
Rod Boyce.

-----Original Message-----
From: John W. Linville [mailto:linville at lvl7.com]
Sent: Friday, January 09, 2004 1:36 AM
To: Rod Boyce
Cc: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] U-Boot on MPC8280



Is your method any "cleaner"?

Thanks,

John

-- 
John W. Linville
LVL7 Systems, Inc.

[U-Boot-Users] U-Boot on MPC8280

[David Aldrich]

Hi Wolfgang

Thank you very much for your explanation.

Best regards

David

[U-Boot-Users] U-Boot on MPC8280

[David Aldrich]

Hi Wolfgang

May I ask one further question re. the BDI2000?  An article on the
internet states:

"You might be wondering why the BDI2000 only works with kernel-mode code
and not user-land application code. The technical details are beyond the
scope of this AppNote. The 10,000 foot answer is that while the BDI2000
can work with the MMU enabled, it can only work with a single continuous
memory map. Kernel-mode code exists in a single continuous memory map,
which is disjoint from all of the user-land process memory maps. As an
example of the usefulness of this tool in production environments, the
PPC porting engineers at Monta Vista Software use the BDI2000
extensively for kernel bring-up and device driver debug"

Is it true that the BDI is not suitable for user app debug?  Is this a
problem in practice?

Thanks

David

[U-Boot-Users] U-Boot on MPC8280

[Wolfgang Denk]

Dear David,

in message <0E8A20F2EB7BD7119C1F00508BB333780E5D7B@tmservermail02.t-modus.nec.co.uk> you wrote:
> 
> Is it true that the BDI is not suitable for user app debug?  Is this a

Yes, this is true. Well, you _can_ use  it,  but  you  have  manually
navigate  through  the  kernel virtual address space to find what you
are looking for. Sometimes  this  is  necessary  (typically  to  find
kernel  bugs),  but  this is definitely nothing to do for the average
user.

> problem in practice?

No, it is not.

Kernel debugging and application debugging are two separate  weorlds,
like  kernel  address  space  and  user  address  space  are  clearly
separated. There is tools for both of them: for the firmware,  device
drivers  and  kernel  debugging  you  use  the  BDI2000, and for user
applications you use gdbserver or gdb.

Note that this does not mean  any  loss  of  productivity:  both  the
BDI2000  and  gdbserver  "speak" GDB remote protocol, so you will see
absolutely the same user interface.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"If the code and  the  comments  disagree,  then  both  are  probably
wrong."                                                - Norm Schryer

[U-Boot-Users] U-Boot on MPC8280

[George G. Davis]

On Wed, Jan 07, 2004 at 03:24:46PM -0000, David Aldrich wrote:
> Hi Wolfgang
> 
> May I ask one further question re. the BDI2000?  An article on the
> internet states:
> 
> "You might be wondering why the BDI2000 only works with kernel-mode code
> and not user-land application code. The technical details are beyond the
> scope of this AppNote. The 10,000 foot answer is that while the BDI2000
> can work with the MMU enabled, it can only work with a single continuous
> memory map. Kernel-mode code exists in a single continuous memory map,
> which is disjoint from all of the user-land process memory maps. As an
> example of the usefulness of this tool in production environments, the
> PPC porting engineers at Monta Vista Software use the BDI2000
> extensively for kernel bring-up and device driver debug"
> 
> Is it true that the BDI is not suitable for user app debug?  Is this a
> problem in practice?

My US$0.02...

I'm not personally aware of the issues using the BDI2000 to debug user
space code. But in practice you do not need a hardware debugger to
debug user space code. Just use gdb and/or gdbserver to debug your
user space code.

--
Regards,
George

> 
> Thanks
> 
> David
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] U-Boot on MPC8280

[Wolfgang Denk]

In message <20040107155044.GA5255@mvista.com> you wrote:
>
> I'm not personally aware of the issues using the BDI2000 to debug user
> space code. But in practice you do not need a hardware debugger to

I guess you never tried it, did you?

You cannot just set a breakpoint at a user space virtual address...

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Those who hate and fight must stop themselves -- otherwise it is  not
stopped.
	-- Spock, "Day of the Dove", stardate unknown

[U-Boot-Users] U-Boot on MPC8280

[David Aldrich]

Hi

> Do you think that the Windriver equipment ( e.g. VisionPROBE 
> ) is of low quality?
> 
> When looking at the demos, they have been looking a bit 
> sharper than e.g. the BDI2000.

I have seen several posts by Wolfgang giving a poor opinion (to put it
mildly) of the Vision Probe.  However, it is worth noting that Wind
River announced in late 2003 that Vision Probe now supports Linux.  So I
guess they now properly support the MMU etc.  But I can't get much
information about it from Wind River.  Has anyone tried the new version?

David

[U-Boot-Users] U-Boot on MPC8280

[Wolfgang Denk]

In message <0E8A20F2EB7BD7119C1F00508BB333780E5D78@tmservermail02.t-modus.nec.co.uk> you wrote:
> 
> I have seen several posts by Wolfgang giving a poor opinion (to put it
> mildly) of the Vision Probe.  However, it is worth noting that Wind
> River announced in late 2003 that Vision Probe now supports Linux.  So I
> guess they now properly support the MMU etc.  But I can't get much
> information about it from Wind River.  Has anyone tried the new version?

AFAIK they are still limited to a static mapping.


If you check the PowerPC Linux kernel you will find:

"arch/ppc/kernel/head.S":
	...
#ifdef CONFIG_BDI_SWITCH
	/* Add helper information for the Abatron bdiGDB debugger.
	 * ...
#endif
	...
#ifdef CONFIG_BDI_SWITCH
        /* Context switch the PTE pointer for the Abatron BDI2000.
	 * The PGDIR is passed as second argument.
	 */
	...
#endif


I. e. the kernel provides special hooks to update the BDI's knwoledge
about page table use. This is at least an indication that the BDI2000
is not only well supported by the Linux kernel, but  also  the  first
commercial debugger that provided and received such support.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
I have a very small mind and must live with it.    -- Edsger Dijkstra

[U-Boot-Users] U-Boot on MPC8280

[Matias Sundman]

Hi Wolfgang,
Do you think that the Windriver equipment ( e.g. VisionPROBE ) is of low quality?

When looking at the demos, they have been looking a bit sharper than e.g. the BDI2000.

Regards // Matias

-----Original Message-----
From: u-boot-users-admin@lists.sourceforge.net
[mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of Wolfgang
Denk
Sent: den 7 januari 2004 14:58
To: sudhakar rajashekhara
Cc: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] U-Boot on MPC8280 


Hello,

in message <20040107131759.31653.qmail@web10602.mail.yahoo.com> you wrote:
> 
> I am trying to port U-boot-1.0.0 on a board which has
> MPC8280 processor. I have started with RAM boot. I am

As pointed out many times before this is probably  not  a  good  idea
unless you know exactly what you are doing and how U-Boot is working.
If this is one of your first ports of U-Boot and/or if you don;t know
the  processor  really  well  I  recommend to use the standard way of
booting from flash instead.

> using VisionPROBE utility to debug. One of the line

Sincere condolences.

> This line is supposed to move the contents of MSR
> register to R5 register. I am seeing the content of
> these two registers before the execution of the above
> statement and after the execution, using "DR" command.
> But I feel that the above statement is not executed
> properly as the content of R5 register is same even
> after the above line is executed (in my case 40)
> whereas MSR is all ZEROes. Why is it happening so? I

Maybe your debugger is not working as expected...

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
A meeting is an event at which the minutes are kept and the hours are
lost.


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] U-Boot on MPC8280

[Wolfgang Denk]

Dear Matias,

in message <37FB7AA6F5F9814FB634A7BF4C35A6F501213D91@ESEALNT442.al.sw.ericsson.se> you wrote:
> 
> Do you think that the Windriver equipment ( e.g. VisionPROBE ) is of low quality?

First of all I have to point out that I  don't  have  any  first-hand
experience  with  the  Vision*  tools.  My  statement is based on the
collected reports of users of these tools for  PPCBoot,  U-Boot,  and
Linux debugging.

If you search the mailing list you will find many reports from people
who ran into problems using the Vision* tools. With U-Boot there  are
two typical problems: getting the images loaded on the target system,
and debugging after relocation to RAM.

I don't think it is low quality. Actually I think the tools are  high
quality, but they are somewhat limited in operation.


> When looking at the demos, they have been looking a bit sharper
> than e.g. the BDI2000.

The main difference is that the BDI2000 is just  a  debug  interface,
and  the  quality  of  the total system depends on the quality of the
debugger frontend. If you are used  to  working  with  GDB  /  DDD  /
Insight etc. this is all you need.

The Vision* tools provide a complex solution, with some  restrictions
(please correct me if I'm wrong):

* The tools seem to have problems understanding and  loading  certain
  image  formats;  obviously  you cannot simply use a binary image to
  avoid all interpretation of internal data structures, and  the  ELF
  loader  loads  only  the  segments  it knows about (which may cause
  problems with certain Linux images),

* The tools are limited in the way how they support  the  MMU.  AFAIK
  only  a  static  mapping  is  supported, which is not sufficient to
  really debug a system like  Linux  where  you  have  to  deal  with
  dynamic  page tables, dynamically loaded device drivers and modules
  etc.

Maybe the BDI2000 is not as fancy to use, but  at  least  it  does  a
solid job in these areas, and simply works.

Other things to keep in mind:

* I have been told that the price for the Linux version of the  tools
  is  significantly  higher  (2  x  ?)  than the windoze version. The
  BDI2000 in contrast is not only cheaper, but also  OS  independend:
  it will run on any system where you find a GDB.

* Note that you can buy firmware versions of  the  BDI2000  for  most
  well-known debuggers, which might give you the same "sharp look" as
  Vision*  -  but  I  never used any such tools (because usually they
  will cost a lot of $$ and run only  under  Windoze  which  I  don;t
  touch).


Hope this helps.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
IMPORTANT NOTICE TO PURCHASERS: The Entire Physical Universe,  Inclu-
ding  This Product, May One Day Collapse Back into an Infinitesimally
Small Space. Should  Another  Universe  Subsequently  Re-emerge,  the
Existence of This Product in That Universe Cannot Be Guaranteed.

[U-Boot-Users] U-Boot on MPC8280

[sudhakar rajashekhara]

Hi,

I am trying to port U-boot-1.0.0 on a board which has
MPC8280 processor. I have started with RAM boot. I am
using VisionPROBE utility to debug. One of the line
which U-boot executes is as follows.

boot_warm:
        mfmsr   r5   /* save msr contents */

This line is supposed to move the contents of MSR
register to R5 register. I am seeing the content of
these two registers before the execution of the above
statement and after the execution, using "DR" command.
But I feel that the above statement is not executed
properly as the content of R5 register is same even
after the above line is executed (in my case 40)
whereas MSR is all ZEROes. Why is it happening so? I
also want to know whether anyone has sucessfully
ported U-boot to MPC8280?

regards,
Sudhakar.

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

[U-Boot-Users] U-Boot on MPC8280

[Wolfgang Denk]

Hello,

in message <20040107131759.31653.qmail@web10602.mail.yahoo.com> you wrote:
> 
> I am trying to port U-boot-1.0.0 on a board which has
> MPC8280 processor. I have started with RAM boot. I am

As pointed out many times before this is probably  not  a  good  idea
unless you know exactly what you are doing and how U-Boot is working.
If this is one of your first ports of U-Boot and/or if you don;t know
the  processor  really  well  I  recommend to use the standard way of
booting from flash instead.

> using VisionPROBE utility to debug. One of the line

Sincere condolences.

> This line is supposed to move the contents of MSR
> register to R5 register. I am seeing the content of
> these two registers before the execution of the above
> statement and after the execution, using "DR" command.
> But I feel that the above statement is not executed
> properly as the content of R5 register is same even
> after the above line is executed (in my case 40)
> whereas MSR is all ZEROes. Why is it happening so? I

Maybe your debugger is not working as expected...

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
A meeting is an event at which the minutes are kept and the hours are
lost.

[U-Boot-Users] U-Boot on MPC8280

[Yuli Barcohen]

>>>>> Sudhakar Rajashekhara writes:

    Sudhakar> Hi, I am trying to port U-boot-1.0.0 on a board which has
    Sudhakar> MPC8280 processor. I have started with RAM boot. I am
    Sudhakar> using VisionPROBE utility to debug. One of the line which
    Sudhakar> U-boot executes is as follows.

    Sudhakar> boot_warm:
    Sudhakar>         mfmsr r5 /* save msr contents */

    Sudhakar> This line is supposed to move the contents of MSR register
    Sudhakar> to R5 register. I am seeing the content of these two
    Sudhakar> registers before the execution of the above statement and
    Sudhakar> after the execution, using "DR" command.  But I feel that
    Sudhakar> the above statement is not executed properly as the
    Sudhakar> content of R5 register is same even after the above line
    Sudhakar> is executed (in my case 40) whereas MSR is all ZEROes. Why
    Sudhakar> is it happening so? I also want to know whether anyone has
    Sudhakar> sucessfully ported U-boot to MPC8280?

Yes, look at board/mpc8260ads. The port runs on PQ2FADS board on
MPC8280. Our customers use U-Boot on their MPC8270-based boards.

-- 
========================================================================
 Yuli Barcohen       | Phone +972-9-765-1788 |  Software Project Leader
 yuli at arabellasw.com | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================