[U-Boot-Users] Configuring U-Boot for MPC8349E in little endian mode

[U-Boot-Users] Configuring U-Boot for MPC8349E in little endian mode

[vivek.trivedi at wipro.com]

Hi,
We are using MPC8349E based board in big endian mode. It is working fine
with U-Boot 1.1.3 .
Now due to some reason we have to configure 8349E in little endian mode.
I have modified RCW, HID2 and MSR registers for this and built the
U-Boot with -mlittle-endian(gcc 3.4.3) and -EL (ld option ).
 
Now code is starting properly in Start.S but it is jumping to alignment
vector(0x600) whenever it hits a branch instruction(b , bl).
Then it stops at 0x63F in alignment exception vector handler.
 
Has any one tried configuring U-Boot for MPC8349E in little endian mode
...?
We have also tried to build U-Boot with -mstrict-align option, but it
has not helped us.
Are we missing any alignment option in gcc for compiling U-Boot.
 
Any help will be appreciated.
 
 
Thanks,
Vivek Trivedi
 

[U-Boot-Users] Configuring U-Boot for MPC8349E in little endian mode

[Wolfgang Denk]

In message <47230CE166B64744B0120173E4C2161E04D531CF@BLR-EC-MBX01.wipro.com> you wrote:
>
> We are using MPC8349E based board in big endian mode. It is working fine
> with U-Boot 1.1.3 .

Yes. Big endian is the natural byte order for PowerPC.

> Now due to some reason we have to configure 8349E in little endian mode.

Don't. You're on the road to trouble. Stop now.

Figure out what "some reason" is, and how to  solve  it  differently,
i. e. in a sane way.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You see things; and you say ``Why?'' But I dream  things  that  never
were; and I say ``Why not?''
       - George Bernard Shaw _Back to Methuselah_ (1921) pt. 1, act 1

[U-Boot-Users] Configuring U-Boot for MPC8349E in little endian mode

[David Hawkins]

Hi Vivek

> Now due to some reason we have to configure 8349E in little endian mode.

Perhaps you could explain why you feel you need to use
little-endian mode. Readers of the list could offer
some constructive comments.

Regards,
Dave

[U-Boot-Users] Configuring U-Boot for MPC8349E in little endian mode

[vivek.trivedi at wipro.com]

Hi,
Thanks all for quick response.

Sorry, I forgot to tell that we are using MPC8349E processor with a
"e300 core".
And it is clearly mentioned in the e300 core datasheet that, it supports
"True little-endian mode for compatibility with other true little-endian
devices".

So, according to data sheet I have done following changes in U-Boot to
configure it in true little endian mode:
RCWH for little endian mode and enable the Little-endian mode in e300
core registers MSR bit LE and HID2 registers bit LET.

After doing these settings core is able to fetch RCW from flash and
execute some assembly code in Start.S. 
But I am not able to understand why e300 core(i.e. MPC8349E in True) is
not executing branch instruction(b , bl) only  and jumping to alignment
exception vector handler(0x600).

Do, I need to enable some -m alignment flag in U-Boot build so that
e300-core can execute branch instructions.
Is the e300-core is not able to interpret branch instruction(b , bl) in
true little endian mode...?

Has any one tried to configure and run U-Boot for MPC8349E
processor(e300 core) in true little endian mode...?
Are missing any other setting in U-Boot for little endian operation...?

We want to configure MPC8349E in little endian as some other PCI
devices(DSPs) are operating in little endian.

Any help/suggestion will be appreciated.


Thanks,
Vivek Trivedi



In message
<47230CE166B64744B0120173E4C2161E04D531CF@BLR-EC-MBX01.wipro.com> you
wrote:
>
> We are using MPC8349E based board in big endian mode. It is working 
> fine with U-Boot 1.1.3 .

Yes. Big endian is the natural byte order for PowerPC.

> Now due to some reason we have to configure 8349E in little endian
mode.

Don't. You're on the road to trouble. Stop now.

Figure out what "some reason" is, and how to  solve  it  differently, i.
e. in a sane way.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You see things; and you say ``Why?'' But I dream  things  that  never
were; and I say ``Why not?''
- George Bernard Shaw _Back to Methuselah_ (1921) pt. 1, act 1

 

-----Original Message-----
From: Vivek Trivedi (WT01 - Embedded & Product Engineering) 
Sent: Wednesday, April 30, 2008 9:05 PM
To: u-boot-users at lists.sourceforge.net
Cc: kim.phillips at freescale.com; Vivek Trivedi (WT01 - Embedded & Product
Engineering)
Subject: Configuring U-Boot for MPC8349E in little endian mode

Hi,
We are using MPC8349E based board in big endian mode. It is working fine
with U-Boot 1.1.3 .
Now due to some reason we have to configure 8349E in little endian mode.
I have modified RCW, HID2 and MSR registers for this and built the
U-Boot with -mlittle-endian(gcc 3.4.3) and -EL (ld option ).
 
Now code is starting properly in Start.S but it is jumping to alignment
vector(0x600) whenever it hits a branch instruction(b , bl).
Then it stops at 0x63F in alignment exception vector handler.
 
Has any one tried configuring U-Boot for MPC8349E in little endian mode
...?
We have also tried to build U-Boot with -mstrict-align option, but it
has not helped us.
Are we missing any alignment option in gcc for compiling U-Boot.
 
Any help will be appreciated.
 
 
Thanks,
Vivek Trivedi
 

[U-Boot-Users] Configuring U-Boot for MPC8349E in little endian mode

[Kumar Gala]

>
>
> We want to configure MPC8349E in little endian as some other PCI
> devices(DSPs) are operating in little endian.

Why should the fact that the DSPs over PCI being little endian impact  
how you run the 8349?  All the u-boot and linux drivers deal with this  
for every PCI device I'm aware of and run the 8349 (and all PowerPC  
chips) in big-endian mode.

All access to the PCI device registers are wrapped in functions that  
do the proper byte swapping for you.

- k

[U-Boot-Users] Configuring U-Boot for MPC8349E in little endian mode

[Jerry Van Baren]

vivek.trivedi at wipro.com wrote:
> Hi,
> Thanks all for quick response.
> 
> Sorry, I forgot to tell that we are using MPC8349E processor with a
> "e300 core".
> And it is clearly mentioned in the e300 core datasheet that, it supports
> "True little-endian mode for compatibility with other true little-endian
> devices".

Put on your "marketing filter" glasses when reading this.  You will find 
words like "true" and "compatibility"  disappear and the sentence 
becomes meaningless.

The documentation says it can be done and, indeed, it *can*[1].  It 
looks like the e300 core is easier than "traditional" PowerPCs (hence 
the addition of "true" to the marketing line above).  What the 
documentation doesn't say is *how difficult* it is do to it.  Empirical 
evidence would indicate that it is hard.

> So, according to data sheet I have done following changes in U-Boot to
> configure it in true little endian mode:
> RCWH for little endian mode and enable the Little-endian mode in e300
> core registers MSR bit LE and HID2 registers bit LET.
> 
> After doing these settings core is able to fetch RCW from flash and
> execute some assembly code in Start.S. 
> But I am not able to understand why e300 core(i.e. MPC8349E in True) is
> not executing branch instruction(b , bl) only  and jumping to alignment
> exception vector handler(0x600).

Read and understand the endian discussion in the Programming 
Environments Manual as well as the e300 core.
   <http://www.freescale.com/files/product/doc/MPCFPE32B.pdf>

Flipping the endian configuration bit in the HRCW is just the start of 
your struggle (if you chose to continue).  I don't know of anybody that 
runs PowerPCs in little endian mode[1] because, while it can be done, 
the pain of making it work is much higher than byteswapping the data as 
necessary.

Note that the exception handling is configured separately to run in 
big/little endian.  You can be running little endian in your user 
applications and big endian in your exceptions (and OS).  Ouch.

Some types of data accesses cause the exception you are seeing and it is 
your job to field the exception, determine the desired load/store 
operation, and fix it up.  This is done in the misaligned exception 
handler (while running in big endian mode).

 From the alignment exception description in the e300 Core Reference 
Manual Table 5-2. Interrupts and Exception Conditions:

An alignment interrupt is caused when the core cannot perform a memory 
access for any of the reasons described below:
* The instruction is lswi, lswx, stswi, stswx, and the core is in 
little-endian mode. Note that PowerPC little-endian mode is not 
supported on the e300 core.

See also in the e300 Core Reference Manual section 3.2.4.3.7 Integer 
Load and Store String Instructions

> Do, I need to enable some -m alignment flag in U-Boot build so that
> e300-core can execute branch instructions.
> Is the e300-core is not able to interpret branch instruction(b , bl) in
> true little endian mode...?

Nope, not that simple.

> Has any one tried to configure and run U-Boot for MPC8349E

Extremely unlikely, especially since nobody responded to your initial 
email with useful advice on how to implement LE.

Wolfgang's advice (and others) is very good advice: you really don't 
want to do little endian.

> processor(e300 core) in true little endian mode...?
> Are missing any other setting in U-Boot for little endian operation...?

Nope, not that simple.

> We want to configure MPC8349E in little endian as some other PCI
> devices(DSPs) are operating in little endian.

Byteswapping as necessary is very likely to be a simpler solution. 
Nearly everybody byteswaps rather than running in little endian mode. 
Heed the wisdom of the crowds.

Note that there are byteswap instructions in the PowerPC instruction 
set.  For your DSP data, you will likely find it is easier to run 
through it and byteswap it as the first (incoming) or last (outgoing) 
thing done to it than try to run little endian.

> Any help/suggestion will be appreciated.
> 
> 
> Thanks,
> Vivek Trivedi

Best regards,
gvb

[1] Windows NT 3.1 ran little endian on PowerPC.  That is the *only* 
PowerPC little endian use that I'm aware of.

Ref:
   <http://support.microsoft.com/kb/102025>

[U-Boot-Users] Configuring U-Boot for MPC8349E in little endian mode

[David Hawkins]

Hi Vivek,

> Sorry, I forgot to tell that we are using MPC8349E processor
> with a "e300 core". And it is clearly mentioned in the e300
> core datasheet that, it supports "True little-endian mode
> for compatibility with other true little-endian devices".

Data sheets need to be read in the wider context of knowing
how the devices are 'typically used'. Just because a core
can operate in little-endian, doesn't mean you should :)

> So, according to data sheet I have done following changes
> in U-Boot to configure it in true little endian mode

The convention for this processor, and pretty much all
other PowerPCs is to operate in big-endian mode.

> We want to configure MPC8349E in little endian as some
> other PCI devices(DSPs) are operating in little endian.
> 
> Any help/suggestion will be appreciated.

The PowerPC should be operated in big-endian mode, so that you
have the wider support of the community. There is absolutely
no reason to operate the processor in little-endian mode
just because you want to talk to little-endian processors
over the little-endian PCI bus.

The overhead of any required byte-swapping functions is
negligible.

Regardless of what mode your PowerPC host operates versus
your DSPs, you will have to use a communications protocol
that enforces data alignment and format, eg. a C-structure
on the DSP will more than likely not have the same layout
as the same C-structure compiled on the PowerPC. There
is the issue of endianness, but also the issue of alignment
and packing. As such you would write an encode/serialization
function to send data, and a decode/deserialization function
to decode data.

There are standardized machine independent binary formats
already defined, eg. XDR as used by NFS, and CDR as used
by CORBA. Application code written using this technique is
transparent to the endianness of the underlying processor.

I use little-endian x86 hosts to communicate with about 20
little-endian DSPs, or big-endian PowerPCs (MPC8349EAs).
The devices communicate using CDR. I use the ACE C++ library
and its CDR encode/decode functions on the x86 and PowerPCs,
while on the DSPs, I use C-structures and pack/unpack them
to match the equivalent CDR encoded functions. The overhead
of data conversion is insignificant.

I hope that given this insight you will understand why
you are recommended to operate the processor in its
'standard' big-endian mode.

Cheers,
Dave

[U-Boot-Users] Configuring U-Boot for MPC8349E in little endian mode

[vivek.trivedi at wipro.com]

Hi,
Thanks all for quick response.

Actually we are having a huge application for video capture which is
presently running on x86 based board having some DSPs. As per the data
sheet of MPC8349E(e300 core), MPC8349E can be configured in true little
endian mode.

So, if we are able to configure MPC8349E(e300 core) in true little
endian mode, we can utilize our huge x86 based application on MPC8349E. 
That is why we want to know whether MPC8349E(e300 core) is tested on
true little endian mode till now..?

If it has been tested in true little endian mode what are the necessary
settings in U-Boot except RCWH change, LE bit field in MSR register and
LET bit field in HID2 register.

If MPC8349E(e300 core) is not tested in true little endian mode till
now, what could be the reason ..? 
What are the drawbacks/problems we could face during the little endian
configuration of MPC8349E(e300-core)..?

Please give your suggestions/comments on this.
Any help/comment will be appreciated.


Thanks,
Vivek Trivedi


 
>
>
> We want to configure MPC8349E in little endian as some other PCI
> devices(DSPs) are operating in little endian.

Why should the fact that the DSPs over PCI being little endian impact
how you run the 8349?  All the u-boot and linux drivers deal with this
for every PCI device I'm aware of and run the 8349 (and all PowerPC
chips) in big-endian mode.

All access to the PCI device registers are wrapped in functions that do
the proper byte swapping for you.

- k


-----Original Message-----
From: Vivek Trivedi (WT01 - Embedded & Product Engineering) 
Sent: Friday, May 02, 2008 11:45 AM
To: Vivek Trivedi (WT01 - Embedded & Product Engineering);
'u-boot-users at lists.sourceforge.net'
Cc: 'kim.phillips at freescale.com'
Subject: RE: Configuring U-Boot for MPC8349E in little endian mode

Hi,
Thanks all for quick response.

Sorry, I forgot to tell that we are using MPC8349E processor with a
"e300 core".
And it is clearly mentioned in the e300 core datasheet that, it supports
"True little-endian mode for compatibility with other true little-endian
devices".

So, according to data sheet I have done following changes in U-Boot to
configure it in true little endian mode:
RCWH for little endian mode and enable the Little-endian mode in e300
core registers MSR bit LE and HID2 registers bit LET.

After doing these settings core is able to fetch RCW from flash and
execute some assembly code in Start.S. 
But I am not able to understand why e300 core(i.e. MPC8349E in True) is
not executing branch instruction(b , bl) only  and jumping to alignment
exception vector handler(0x600).

Do, I need to enable some -m alignment flag in U-Boot build so that
e300-core can execute branch instructions.
Is the e300-core is not able to interpret branch instruction(b , bl) in
true little endian mode...?

Has any one tried to configure and run U-Boot for MPC8349E
processor(e300 core) in true little endian mode...?
Are missing any other setting in U-Boot for little endian operation...?

We want to configure MPC8349E in little endian as some other PCI
devices(DSPs) are operating in little endian.

Any help/suggestion will be appreciated.


Thanks,
Vivek Trivedi



In message
<47230CE166B64744B0120173E4C2161E04D531CF@BLR-EC-MBX01.wipro.com> you
wrote:
>
> We are using MPC8349E based board in big endian mode. It is working 
> fine with U-Boot 1.1.3 .

Yes. Big endian is the natural byte order for PowerPC.

> Now due to some reason we have to configure 8349E in little endian
mode.

Don't. You're on the road to trouble. Stop now.

Figure out what "some reason" is, and how to  solve  it  differently, i.
e. in a sane way.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You see things; and you say ``Why?'' But I dream  things  that  never
were; and I say ``Why not?''
- George Bernard Shaw _Back to Methuselah_ (1921) pt. 1, act 1

 

-----Original Message-----
From: Vivek Trivedi (WT01 - Embedded & Product Engineering)
Sent: Wednesday, April 30, 2008 9:05 PM
To: u-boot-users at lists.sourceforge.net
Cc: kim.phillips at freescale.com; Vivek Trivedi (WT01 - Embedded & Product
Engineering)
Subject: Configuring U-Boot for MPC8349E in little endian mode

Hi,
We are using MPC8349E based board in big endian mode. It is working fine
with U-Boot 1.1.3 .
Now due to some reason we have to configure 8349E in little endian mode.
I have modified RCW, HID2 and MSR registers for this and built the
U-Boot with -mlittle-endian(gcc 3.4.3) and -EL (ld option ).
 
Now code is starting properly in Start.S but it is jumping to alignment
vector(0x600) whenever it hits a branch instruction(b , bl).
Then it stops at 0x63F in alignment exception vector handler.
 
Has any one tried configuring U-Boot for MPC8349E in little endian mode
...?
We have also tried to build U-Boot with -mstrict-align option, but it
has not helped us.
Are we missing any alignment option in gcc for compiling U-Boot.
 
Any help will be appreciated.
 
 
Thanks,
Vivek Trivedi
 

[U-Boot-Users] Configuring U-Boot for MPC8349E in little endian mode

[Timur Tabi]

vivek.trivedi at wipro.com wrote:
> Hi,
> Thanks all for quick response.
> 
> Actually we are having a huge application for video capture which is
> presently running on x86 based board having some DSPs. As per the data
> sheet of MPC8349E(e300 core), MPC8349E can be configured in true little
> endian mode.

It would be a lot easier if you modified the application to work on big-endian
and little-endian.  Just look through the code in places where the endian
matters, and add cpu_to_be32() and be32_to_cpu() (or similar functions).

The only time this will be real problem is with DMA, since on 83xx you cannot
modify the data during a DMA transfer.

-- 
Timur Tabi
Linux kernel developer at Freescale

[U-Boot-Users] Configuring U-Boot for MPC8349E in little endian mode

[David Hawkins]

Hi Vivek,

Just to clarify these comments:

> It would be a lot easier if you modified the application to work on big-endian
> and little-endian.  Just look through the code in places where the endian
> matters, and add cpu_to_be32() and be32_to_cpu() (or similar functions).

When you are dealing with a driver, register accesses need to be
in a specific format. The MPC8349EA has some of its registers
in big-endian format, and others in little-endian format.
Regardless of the mode you operate your processor, you will
*have* to use the correct byte-swap functions.

> The only time this will be real problem is with DMA, since on 83xx you cannot
> modify the data during a DMA transfer.
> 

DMA would be used to move a block of data, not to manipulate
a register. If encode/decode functions are used to move blocks
of data, then the data is in byte-stream format, which does
not change when the endian-order of the processor changes.
Each byte occurs in the same order.

You mention you are trying to re-use an existing code base.
Keep in mind that just because the old code works, doesn't mean it
is good code. If the code was not written to be endian-neutral,
then it wasn't portable in the first place, so should be
corrected.

Cheers,
Dave

[U-Boot-Users] Configuring U-Boot for MPC8349E in little endian mode

[Timur Tabi]

David Hawkins wrote:

> When you are dealing with a driver, register accesses need to be
> in a specific format. The MPC8349EA has some of its registers
> in big-endian format, and others in little-endian format.
> Regardless of the mode you operate your processor, you will
> *have* to use the correct byte-swap functions.

That's why we use cpu_to_be32() to write to big-endian registers.  On a
big-endian processor, this macro doesn't modify the parameter.  So,

	*p = be32_to_cpu(12);

will be compiled to

	*p = 12;

On a little-endian process, the macro will do a byte-swap.

This macro, and others like it, eliminates the need to have two different
versions of the code.

> DMA would be used to move a block of data, not to manipulate
> a register.

I can see you've never written an audio driver before.  The data itself has
endianness, and the register may require the data to appear in one endian or
another.  If

-- 
Timur Tabi
Linux kernel developer at Freescale

[U-Boot-Users] Configuring U-Boot for MPC8349E in little endian mode

[David Hawkins]

Hi Timur,

>> When you are dealing with a driver, register accesses need to be
>> in a specific format. The MPC8349EA has some of its registers
>> in big-endian format, and others in little-endian format.
>> Regardless of the mode you operate your processor, you will
>> *have* to use the correct byte-swap functions.
> 
> That's why we use cpu_to_be32() to write to big-endian registers.  On a
> big-endian processor, this macro doesn't modify the parameter.  So,
> 
> 	*p = be32_to_cpu(12);
> 
> will be compiled to
> 
> 	*p = 12;
> 
> On a little-endian process, the macro will do a byte-swap.
> 
> This macro, and others like it, eliminates the need to have two different
> versions of the code.

Sure. I wasn't pointing out the clarification to you, but to
Vivek as it seemed like he had limited experience with
endianness issues.

>> DMA would be used to move a block of data, not to manipulate
>> a register.
> 
> I can see you've never written an audio driver before.  The
> data itself has endianness, and the register may require
> the data to appear in one endian or another.  If

Note that I'm was not trying to be antagonistic here, so
no offense was intended in any my response to your message.
It seemed to me that Vivek was not very experienced with
endianness issues so wanted to clarify your application
examples - to Vivek.

I haven't written an audio driver, so I'm interested in
learning more.

So are you saying you would DMA to a register with a specific
endianness. The two situations I can think of with a DMA
controller moving data that requires a specific endianness
are;

1) DMA controller scatter-gather descriptor entries.
    These would normally consist of source, destination,
    length, and next pointers in a specific endianness
    format.

2) DMA from memory to a FIFO destination address that expects
    little-endian format 16-bit values.

In either case, you would use the byte-conversion routines to
serialize the descriptor entries in memory, or in the source buffer,
into the correct endianness before performing enabling the DMA.
So the discussion on serializing data into a source buffer
applies to this case too.

If Vivek's application correctly serializes any endian-specific
data before using the MPC8349EA DMA controller, then he should
have no issues.

Does an audio driver differ in any respect to the above situations?

Thanks for the feedback.

Cheers,
Dave

[U-Boot-Users] Configuring U-Boot for MPC8349E in little endian mode

[Timur Tabi]

David Hawkins wrote:

> So are you saying you would DMA to a register with a specific
> endianness.

Typically, yes.  Theoretically, a device could be programmed to handle any
number of bit- and byte-endianness, but I haven't found one.  Most of them time,
it's just a shift register and so which means the bit and the bytes have to be
in the same order.  The result is that the endianness of the host processor has
to to match the endianness of the audio samples.

The Freescale SSI has this problem.  When the SSI is on an i.MX, it only
supports little-endian samples.  On an MPC8610, it only supports big-endian samples.

> The two situations I can think of with a DMA
> controller moving data that requires a specific endianness
> are;
> 
> 1) DMA controller scatter-gather descriptor entries.
>     These would normally consist of source, destination,
>     length, and next pointers in a specific endianness
>     format.

I don't think this applies.  The descriptor entries are "manually programmed";
that is, you write to individual fields in the descriptor one at a time.

> 2) DMA from memory to a FIFO destination address that expects
>     little-endian format 16-bit values.

Yes, this is what audio drivers do.

> In either case, you would use the byte-conversion routines to
> serialize the descriptor entries in memory, or in the source buffer,
> into the correct endianness before performing enabling the DMA.

Very true.  However, this means that if the original data is in the wrong
endian, you have to have a middle layer that modifies the data when copying from
the source buffer to the DMA buffer.  This adds overhead.

> If Vivek's application correctly serializes any endian-specific
> data before using the MPC8349EA DMA controller, then he should
> have no issues.

Yes, but it may take him weeks to find all the places in the where the
endianness matters.

> Does an audio driver differ in any respect to the above situations?

Not really.

-- 
Timur Tabi
Linux kernel developer at Freescale

[U-Boot-Users] Configuring U-Boot for MPC8349E in little endian mode

[David Hawkins]

Hi Timur,

>> In either case, you would use the byte-conversion routines to
>> serialize the descriptor entries in memory, or in the source buffer,
>> into the correct endianness before performing enabling the DMA.
> 
> Very true.  However, this means that if the original data is in
> the wrong endian, you have to have a middle layer that modifies
> the data when copying from the source buffer to the DMA buffer. 
> This adds overhead.

This would be the key question for Vivek then.

Does his highest volume data set have any endianness issues
that need to be resolved?

>> If Vivek's application correctly serializes any endian-specific
>> data before using the MPC8349EA DMA controller, then he should
>> have no issues.
> 
> Yes, but it may take him weeks to find all the places in the where the
> endianness matters.

Indeed.

Conversely, it may take months to get a little-endian PowerPC
port working!

:)

Cheers,
Dave