Big Endian au1550

Big Endian au1550

[JP Foster]

Hi all,
In the linux-mips cvs big endian operation of the au1550 is not
selectable. Is there a reason for this?
what would I need to do to get big endian support?

The chip does run big endian, as I have yamon running on it here.
And a previously the linux-mips kernel allowed this.
The kernel will compile big end but I get an oops as the kernel
starts up 

Thanks
JP


VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Break instruction in kernel code in arch/mips/kernel/traps.c::do_bp,
line 557[#1]:
Cpu 0
$ 0   : 00000000 1000fc00 00000000 10000000
$ 4   : 00000001 00000001 fffb6ccf 00000000
$ 8   : 10000000 00000008 803c0000 00100100
$12   : 811c5edd fffffffa ffffffff 0000000a
$16   : 1000fc01 803e7bc0 803c0000 80380000
$20   : 803d0000 80380000 803d0000 00000000
$24   : 00000008 811c5df9
$28   : 811c4000 811c5e40 811c5e40 80103900
Hi    : 00000000
Lo    : 00000000
epc   : 8033f818 preempt_schedule_irq+0xcc/0xd8     Not tainted
ra    : 80103900 ret_from_fork+0x0/0x8
Status: 1000fc02    KERNEL EXL
Cause : 00800024
PrId  : 03030200
Modules linked in:
Process swapper (pid: 1, threadinfo=811c4000, task=803e7bc0)
Stack : 803fbbf4 803fbbe0 1000fc01 8012f7b8 1000fc01 80379420 803c0000
00000000
        80103900 80100c00 811c5ed8 00000000 00000000 80247490 803fbb80
813b396c
        00000000 1000fc00 00000001 811c4008 00000001 00000001 803c0028
0000000b
        002d4cae 801fc8ec 00000018 00100100 811c5edd fffffffa ffffffff
0000000a
        1000fc01 80379420 803c0000 80380000 803d0000 80380000 803d0000
00000000
        ...
Call Trace:
 [<8012f7b8>] irq_exit+0x4c/0x5c
 [<80103900>] ret_from_fork+0x0/0x8
 [<80100c00>] au1000_IRQ+0x120/0x1a0
 [<80247490>] class_device_create_file+0x20/0x34
 [<801fc8ec>] memset_partial+0x30/0x6c
 [<8012f9c8>] __tasklet_schedule+0xb8/0xec
 [<8012f9e0>] __tasklet_schedule+0xd0/0xec
 [<803b3ffc>] kbd_init+0x184/0x22c
 [<80210480>] alloc_tty_driver+0x24/0x64
 [<80247fc4>] class_simple_device_add+0xe0/0x178
 [<803b4484>] vty_init+0xf8/0x128
 [<803b3784>] tty_init+0x1d0/0x1fc
 [<803b3428>] rand_initialize+0x128/0x1f0
 [<803b33f0>] rand_initialize+0xf0/0x1f0
 [<803b1c50>] init_iso9660_fs+0x60/0x9c
 [<80100508>] init+0x9c/0x274
 [<8010541c>] kernel_thread_helper+0x10/0x18
 [<8010540c>] kernel_thread_helper+0x0/0x18

Re: Big Endian au1550

[Ralf Baechle]

On Wed, Feb 23, 2005 at 11:22:16AM +0000, JP Foster wrote:

> Hi all,
> In the linux-mips cvs big endian operation of the au1550 is not
> selectable. Is there a reason for this?
> what would I need to do to get big endian support?
> 
> The chip does run big endian, as I have yamon running on it here.
> And a previously the linux-mips kernel allowed this.
> The kernel will compile big end but I get an oops as the kernel
> starts up 

I recently rewrote the endianes selection in the Kconfig menus.  The
individual platforms will now have to explicitly select
SYS_SUPPORTS_LITTLE_ENDIAN rsp. SYS_SUPPORTS_BIG_ENDIAN to indicate
which endianess they support.  I know that Alchemy supports big endian
operation in hardware but no idea if all the Linux code is working
properly, so I've been conservative and choose to limit the system
to little endian until somebody reports big endianess support to be
actually working.

  Ralf

Re: Big Endian au1550

[JP Foster]

Fair enough. Has anyone got big-endian au1xxx working ever?
I'm reasonably flexible to use mipsel, since this is a new board,
although all our other products are mipseb.

Since big doesn't work as far as I can see. This must a regression
as I'm sure I had built a running kernel a month or two back.
Currently building a pre-christmas linux-mips snapshot to see if that
works.

If that doesn't work I'll just start using a mipsel version as I would
be wary of using big endian if no one else is.

JP


On Wed, 2005-02-23 at 11:45 +0000, Ralf Baechle wrote:
>
>I recently rewrote the endianes selection in the Kconfig menus.  The
>individual platforms will now have to explicitly select
>SYS_SUPPORTS_LITTLE_ENDIAN rsp. SYS_SUPPORTS_BIG_ENDIAN to indicate
>which endianess they support.  I know that Alchemy supports big endian
>operation in hardware but no idea if all the Linux code is working
>properly, so I've been conservative and choose to limit the system
>to little endian until somebody reports big endianess support to be
>actually working.
>
>  Ralf

Re: Big Endian au1550

[Ralf Baechle]

On Wed, Feb 23, 2005 at 12:05:13PM +0000, JP Foster wrote:

> Fair enough. Has anyone got big-endian au1xxx working ever?
> I'm reasonably flexible to use mipsel, since this is a new board,
> although all our other products are mipseb.
> 
> Since big doesn't work as far as I can see. This must a regression
> as I'm sure I had built a running kernel a month or two back.
> Currently building a pre-christmas linux-mips snapshot to see if that
> works.
> 
> If that doesn't work I'll just start using a mipsel version as I would
> be wary of using big endian if no one else is.

Plenty of machines are using big endian and can't even be configured to
little endian, so even in case you're hitting a problem it can't be
very significant or even fundamental.

  Ralf

Re: Big Endian au1550

[Dan Malek]

On Feb 23, 2005, at 7:05 AM, JP Foster wrote:

> Fair enough. Has anyone got big-endian au1xxx working ever?

The only issues with big endian Au1xxx is the USB and potentially
PCI.  There have been recent patches posted for USB that could
fix this.  The PCI problem is with the read/write/in/out macros.
They were never written properly and I haven't checked to see
if this was corrected in 2.6.

That aside, I have worked on several big endian Au1xxx projects
that are successful.  I never found a way, aside from #ifdefs for
byte sex in generic files, to make the same source compile in
either mode.  It's a fairly low priority on my list of other Au1xxx 
projects :-)

The Linux sources have worked, and if they currently don't we
should fix them.


	-- Dan

Re: Big Endian au1550

[Ralf Baechle]

On Wed, Feb 23, 2005 at 10:03:01AM -0500, Dan Malek wrote:

> >Fair enough. Has anyone got big-endian au1xxx working ever?
> 
> The only issues with big endian Au1xxx is the USB and potentially
> PCI.  There have been recent patches posted for USB that could
> fix this.  The PCI problem is with the read/write/in/out macros.
> They were never written properly and I haven't checked to see
> if this was corrected in 2.6.
> 
> That aside, I have worked on several big endian Au1xxx projects
> that are successful.  I never found a way, aside from #ifdefs for
> byte sex in generic files, to make the same source compile in
> either mode.  It's a fairly low priority on my list of other Au1xxx 
> projects :-)
> 
> The Linux sources have worked, and if they currently don't we
> should fix them.

So I guess this would apply to all Alchemy-based platforms and thus I
should offer big endian on all of them again?

  Ralf

Re: Big Endian au1550

[Dan Malek]

On Feb 23, 2005, at 10:06 AM, Ralf Baechle wrote:

> So I guess this would apply to all Alchemy-based platforms and thus I
> should offer big endian on all of them again?

Yes, big endian should be an option.  If it doesn't work, it
should get fixed :-)

Thanks.


	-- Dan

Re: Big Endian au1550

[Ralf Baechle]

On Wed, Feb 23, 2005 at 12:02:47PM -0500, Dan Malek wrote:

> >So I guess this would apply to all Alchemy-based platforms and thus I
> >should offer big endian on all of them again?
> 
> Yes, big endian should be an option.  If it doesn't work, it
> should get fixed :-)

Okay.  I don't know which of the Alchemy systems are capable of supporting
big endian at all - some might not due to unavailable firmware for example.
So I guess I'll leave cooking a patch to you or Pete.

  Ralf

Re: Big Endian au1550

[Dan Malek]

On Mar 4, 2005, at 12:23 PM, Ralf Baechle wrote:

> Okay.  I don't know which of the Alchemy systems are capable of 
> supporting
> big endian at all -

They all will.

>  some might not due to unavailable firmware for example.

Well, you can (and I have) changed the mode when booting the
kernel from what the boot rom initialized.  It's not pretty, but it 
works.

> So I guess I'll leave cooking a patch to you or Pete.

OK.


	-- Dan

Re: Big Endian au1550

[Thomas Sailer]

On Wed, 2005-02-23 at 10:03 -0500, Dan Malek wrote:

> The only issues with big endian Au1xxx is the USB and potentially
> PCI.  There have been recent patches posted for USB that could
> fix this.  The PCI problem is with the read/write/in/out macros.

Last time I tried (about a month ago using the then current linux-mips
2.6 CVS tree), USB host didn't work neither in big nor little endian
mode on my AMD Pb1000. Ethernet and Serial worked either way.

Tom

Re: Big Endian au1550

[Pete Popov]

Thomas Sailer wrote:
> On Wed, 2005-02-23 at 10:03 -0500, Dan Malek wrote:
> 
> 
>>The only issues with big endian Au1xxx is the USB and potentially
>>PCI.  There have been recent patches posted for USB that could
>>fix this.  The PCI problem is with the read/write/in/out macros.
> 
> 
> Last time I tried (about a month ago using the then current linux-mips
> 2.6 CVS tree), USB host didn't work neither in big nor little endian
> mode on my AMD Pb1000. Ethernet and Serial worked either way.

We've been doing all the 2.6 work on the Db1x boards. The Pb1x need 
an uplift as well, but I don't know if we'll have time to do it.

Pete

Re: Big Endian au1550

[JP Foster]

On Wed, 2005-02-23 at 18:00 +0000, Pete Popov wrote:
>Thomas Sailer wrote:
>> On Wed, 2005-02-23 at 10:03 -0500, Dan Malek wrote:
>> 
>> 
>>>The only issues with big endian Au1xxx is the USB and potentially
>>>PCI.  There have been recent patches posted for USB that could
>>>fix this.  The PCI problem is with the read/write/in/out macros.
>> 
>> 
>> Last time I tried (about a month ago using the then current linux-mips
>> 2.6 CVS tree), USB host didn't work neither in big nor little endian
>> mode on my AMD Pb1000. Ethernet and Serial worked either way.
>
>We've been doing all the 2.6 work on the Db1x boards. The Pb1x need 
>an uplift as well, but I don't know if we'll have time to do it.
>
>Pete
>

Great, but I still can't get a running kernel from cvs mips-linux for
a DB1550 board. Is it perhaps the toolchain? I'm using gcc-3.4.1 perhaps
that is too recent. 

Tried mipsel last night and got the same result as big end so I suspect
it may be my compiler/binutils combination. Is there are recommended
toolchain for mips. Should I go build gcc-2.95 and binutils 2.12 ?

JP

Re: Big Endian au1550

[Peter Popov]

> Great, but I still can't get a running kernel from
> cvs mips-linux for
> a DB1550 board. Is it perhaps the toolchain? I'm
> using gcc-3.4.1 perhaps that is too recent.

Either that or something broke recently. I'll boot a
kernel tonight to make sure it still ok. 

> Tried mipsel last night and got the same result as
> big end so I suspect
> it may be my compiler/binutils combination. Is there
> are recommended
> toolchain for mips. Should I go build gcc-2.95 and
> binutils 2.12 ?

2.95 is too old. We're using 3.3.3 and binutils 2.15.
We're working on making a toolkit available soon, or
you can try ELDK3.0.

Pete

Re: Big Endian au1550

[JP Foster]

>2.95 is too old. We're using 3.3.3 and binutils 2.15.
>We're working on making a toolkit available soon, or
>you can try ELDK3.0.
>

Thanks I'll try that. Thanks to everyone for all their help and advice.
I *WILL* get this built. It usually isn't this hard :)

-- 
jp.foster@exterity.co.uk
Digital Simplicity

Re: Big Endian au1550

[JP Foster]

Yeah! 
Got it working withgcc 3.4.1. Trying again with latest linux-mips and 
it runs as far as borking that it can't find rootfs unknown block,
but I assume that has to do with initramfs.  

---------
VFS: Cannot open root device "<NULL>" or unknown-block(0,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
---------

Do I need to disable ramdisk support for this?


I think there were config options enabled that were causing the crash,
pared it down to just the network and ethernet and serial console and it
works, just had to patch this to get the compile working 

Index: mips/Kconfig
===================================================================
RCS file: /home/cvs/linux/arch/mips/Kconfig,v
retrieving revision 1.142
diff -r1.142 Kconfig
88a89
>       select SYS_SUPPORTS_BIG_ENDIAN
Index: mips/kernel/process.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/process.c,v
retrieving revision 1.75
diff -r1.75 process.c
169,172c169,172
<       gp[EF_CP0_EPC] = regs->cp0_epc;
<       gp[EF_CP0_BADVADDR] = regs->cp0_badvaddr;
<       gp[EF_CP0_STATUS] = regs->cp0_status;
<       gp[EF_CP0_CAUSE] = regs->cp0_cause;
---
> //    gp[EF_CP0_EPC] = regs->cp0_epc;
> //    gp[EF_CP0_BADVADDR] = regs->cp0_badvaddr;
> //    gp[EF_CP0_STATUS] = regs->cp0_status;
> //    gp[EF_CP0_CAUSE] = regs->cp0_cause;

These must be compiler defined or something.

Thanks everyone. The compiler was built from uclibc buildroot and set
for mips1


-- 
jp.foster@exterity.co.uk
Digital Simplicity

Re: Big Endian au1550

[Clem Taylor]

> Great, but I still can't get a running kernel from cvs mips-linux for
> a DB1550 board. Is it perhaps the toolchain? I'm using gcc-3.4.1 perhaps
> that is too recent.
> 
> Tried mipsel last night and got the same result as big end so I suspect
> it may be my compiler/binutils combination. Is there are recommended
> toolchain for mips. Should I go build gcc-2.95 and binutils 2.12 ?

I'm not sure about mipseb, but I've used both crosstool and buildroot
to build toolchains to compile a mipsel 2.6.10 kernel for the
DBAu1550. The kernel is the linux-mips cvs head from a few weeks ago.
Right now I'm using gcc 3.4.3 and binutils 2.15.94.0.2 20041220 that
was built with a recent buildroot checkout.

When I first tried to compile the 2.6.10 I was using
crosstool-0.28-rc37 and I ran into some binutils issues. I ended up
using gcc-3.4.1-glibc-2.3.2 with binutils-050110 (I'm not sure where I
got that). When I switched to buildroot I was able to use the latest
tools it had support for.

                                --Clem

RE: Big Endian au1550

[Prashant Viswanathan]

 
> On Wed, 2005-02-23 at 11:45 +0000, Ralf Baechle wrote:
> >
> >I recently rewrote the endianes selection in the Kconfig menus.  The
> >individual platforms will now have to explicitly select
> >SYS_SUPPORTS_LITTLE_ENDIAN rsp. SYS_SUPPORTS_BIG_ENDIAN to indicate
> >which endianess they support.  I know that Alchemy supports big endian
> >operation in hardware but no idea if all the Linux code is working
> >properly, so I've been conservative and choose to limit the system
> >to little endian until somebody reports big endianess support to be
> >actually working.
> >
> >  Ralf
>
>
> Fair enough. Has anyone got big-endian au1xxx working ever?
> I'm reasonably flexible to use mipsel, since this is a new board,
> although all our other products are mipseb.
> 
> Since big doesn't work as far as I can see. This must a regression
> as I'm sure I had built a running kernel a month or two back.
> Currently building a pre-christmas linux-mips snapshot to see if that
> works.
> 
> If that doesn't work I'll just start using a mipsel version as I would
> be wary of using big endian if no one else is.
> 
> JP

I have Au1550 running in big endian mode and Linux kernel running on it. The
Linux kernel was compiled big endian using BE toolchain.

Prashant

Big Endian au1550

[Prashant Viswanathan]

Is there a reason why the default configuration file doesn't support Big
Endian for the dbAu1550? 

Even if I edit .config to set the endianness to "BIG" it seems to change to
"Little Endian" every time a make is run.

Thanks
Prashant

Re: Big Endian au1550

[Manish Lachwani]

Prashant Viswanathan wrote:

>Is there a reason why the default configuration file doesn't support Big
>Endian for the dbAu1550? 
>
>Even if I edit .config to set the endianness to "BIG" it seems to change to
>"Little Endian" every time a make is run.
>
>Thanks
>Prashant
>
>
>  
>
In arch/mips/Kconfig,

config CPU_LITTLE_ENDIAN
        bool "Generate little endian code"
        default y if ACER_PICA_61 || CASIO_E55 || DDB5074 || DDB5476 || 
DDB5477 || MACH_DECSTATION
|| IBM_WORKPAD || LASAT || MIPS_COBALT || MIPS_ITE8172 || MIPS_IVR || 
SOC_AU1X00 || NEC_OSPREY || OLIVETTI_M700 || SNI_RM200_PCI || 
VICTOR_MPC30X || ZAO_CAPCELLA
        default n if MIPS_EV64120 || MIPS_EV96100 || MOMENCO_OCELOT || 
MOMENCO_OCELOT_G || SGI_IP22 || SGI_IP27 || SGI_IP32 || TOSHIBA_JMR3927
        help
          Some MIPS machines can be configured for either little or big 
endian
          byte order. These modes require different kernels. Say Y if your
          machine is little endian, N if it's a big endian machine.

So, it appears that if you have SOC_AU1X00 set, it will always be 
configured little endian.

Thanks
Manish Lachwani

RE: Big Endian au1550

[Prashant Viswanathan]

> Prashant Viswanathan wrote:
> 
> >Is there a reason why the default configuration file doesn't support Big
> >Endian for the dbAu1550?
> >
> >Even if I edit .config to set the endianness to "BIG" it seems to change
> to
> >"Little Endian" every time a make is run.
> >
> >Thanks
> >Prashant
> >
> >
> >
> >
> In arch/mips/Kconfig,
> 
> config CPU_LITTLE_ENDIAN
>         bool "Generate little endian code"
>         default y if ACER_PICA_61 || CASIO_E55 || DDB5074 || DDB5476 ||
> DDB5477 || MACH_DECSTATION
> || IBM_WORKPAD || LASAT || MIPS_COBALT || MIPS_ITE8172 || MIPS_IVR ||
> SOC_AU1X00 || NEC_OSPREY || OLIVETTI_M700 || SNI_RM200_PCI ||
> VICTOR_MPC30X || ZAO_CAPCELLA
>         default n if MIPS_EV64120 || MIPS_EV96100 || MOMENCO_OCELOT ||
> MOMENCO_OCELOT_G || SGI_IP22 || SGI_IP27 || SGI_IP32 || TOSHIBA_JMR3927
>         help
>           Some MIPS machines can be configured for either little or big
> endian
>           byte order. These modes require different kernels. Say Y if your
>           machine is little endian, N if it's a big endian machine.
> 
> So, it appears that if you have SOC_AU1X00 set, it will always be
> configured little endian.

Is there a reason for this? 

Many months ago I was able to build a big-endian image and load it on my
dbAu1550 (also configured to be BE). I just decided to update and now I find
that it is almost as if it is not meant to be built BE.

Re: Big Endian au1550

[ppopov]

Prashant Viswanathan wrote:

>>Prashant Viswanathan wrote:
>>
>>    
>>
>>>Is there a reason why the default configuration file doesn't support Big
>>>Endian for the dbAu1550?
>>>
>>>Even if I edit .config to set the endianness to "BIG" it seems to change
>>>      
>>>
>>to
>>    
>>
>>>"Little Endian" every time a make is run.
>>>
>>>Thanks
>>>Prashant
>>>
>>>
>>>
>>>
>>>      
>>>
>>In arch/mips/Kconfig,
>>
>>config CPU_LITTLE_ENDIAN
>>        bool "Generate little endian code"
>>        default y if ACER_PICA_61 || CASIO_E55 || DDB5074 || DDB5476 ||
>>DDB5477 || MACH_DECSTATION
>>|| IBM_WORKPAD || LASAT || MIPS_COBALT || MIPS_ITE8172 || MIPS_IVR ||
>>SOC_AU1X00 || NEC_OSPREY || OLIVETTI_M700 || SNI_RM200_PCI ||
>>VICTOR_MPC30X || ZAO_CAPCELLA
>>        default n if MIPS_EV64120 || MIPS_EV96100 || MOMENCO_OCELOT ||
>>MOMENCO_OCELOT_G || SGI_IP22 || SGI_IP27 || SGI_IP32 || TOSHIBA_JMR3927
>>        help
>>          Some MIPS machines can be configured for either little or big
>>endian
>>          byte order. These modes require different kernels. Say Y if your
>>          machine is little endian, N if it's a big endian machine.
>>
>>So, it appears that if you have SOC_AU1X00 set, it will always be
>>configured little endian.
>>    
>>
>
>Is there a reason for this? 
>  
>
It's the more common configuration.

>Many months ago I was able to build a big-endian image and load it on my
>dbAu1550 (also configured to be BE). I just decided to update and now I find
>that it is almost as if it is not meant to be built BE.
>  
>
BE should be fine too.  We should fix this in Kconfig.

Pete

Re: Big Endian au1550

[JP]

I can confirm that BE works fine on the db1550 board. Just add line

select SYS_SUPPORTS_BIG_ENDIAN

to the db1550 section of arch/mips/Kconfig. That allows you to choose
BE.

I guess all the alchemy boards will work LE and BE. At least allowing
the setting will mean they get tested rather than folk getting put off
by the fact they can't select it.

JP

On Wed, 2005-04-27 at 20:57 -0700, ppopov@embeddedalley.com wrote:
> Prashant Viswanathan wrote:
> 
> >>Prashant Viswanathan wrote:
> >>
> >>    
> >>
> >>>Is there a reason why the default configuration file doesn't support Big
> >>>Endian for the dbAu1550?
> >>>
> >>>Even if I edit .config to set the endianness to "BIG" it seems to change
> >>>      
> >>>
> >>to
> >>    
> >>
> >>>"Little Endian" every time a make is run.
> >>>
> >>>Thanks
> >>>Prashant
> >>>
> >>>
> >>>
> >>>
> >>>      
> >>>
> >>In arch/mips/Kconfig,
> >>
> >>config CPU_LITTLE_ENDIAN
> >>        bool "Generate little endian code"
> >>        default y if ACER_PICA_61 || CASIO_E55 || DDB5074 || DDB5476 ||
> >>DDB5477 || MACH_DECSTATION
> >>|| IBM_WORKPAD || LASAT || MIPS_COBALT || MIPS_ITE8172 || MIPS_IVR ||
> >>SOC_AU1X00 || NEC_OSPREY || OLIVETTI_M700 || SNI_RM200_PCI ||
> >>VICTOR_MPC30X || ZAO_CAPCELLA
> >>        default n if MIPS_EV64120 || MIPS_EV96100 || MOMENCO_OCELOT ||
> >>MOMENCO_OCELOT_G || SGI_IP22 || SGI_IP27 || SGI_IP32 || TOSHIBA_JMR3927
> >>        help
> >>          Some MIPS machines can be configured for either little or big
> >>endian
> >>          byte order. These modes require different kernels. Say Y if your
> >>          machine is little endian, N if it's a big endian machine.
> >>
> >>So, it appears that if you have SOC_AU1X00 set, it will always be
> >>configured little endian.
> >>    
> >>
> >
> >Is there a reason for this? 
> >  
> >
> It's the more common configuration.
> 
> >Many months ago I was able to build a big-endian image and load it on my
> >dbAu1550 (also configured to be BE). I just decided to update and now I find
> >that it is almost as if it is not meant to be built BE.
> >  
> >
> BE should be fine too.  We should fix this in Kconfig.
> 
> Pete
> 
-- 
mailto:jaypee@hotpop.com
http://jaypee.org.uk

RE: Big Endian au1550

[Prashant Viswanathan]

> I can confirm that BE works fine on the db1550 board. Just add line
> 
> select SYS_SUPPORTS_BIG_ENDIAN
> 
> to the db1550 section of arch/mips/Kconfig. That allows you to choose
> BE.
> 
> I guess all the alchemy boards will work LE and BE. At least allowing
> the setting will mean they get tested rather than folk getting put off
> by the fact they can't select it.
> 
> JP

Thanks.

Actually I had BE working many months ago. I just did an update to get the
latest and greatest stuff. It would be good if Kconfig was "fixed" to allow
BE selection.

Prashant