vivek.trivedi@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

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

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

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