Subject: Big Endian au1550

From: JP Foster <[email-masked]>
Date: Wed, 23 Feb 2005 11:22:16 +0000

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

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 23 Feb 2005 11:23:39 +0000

> The kernel will compile big end but I get an oops as the kernel

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

---

From: JP Foster <[email-masked]>
Date: Wed, 23 Feb 2005 12:05:13 +0000

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

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 23 Feb 2005 13:17:17 +0000

> 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

---

From: Dan Malek <[email-masked]>
Date: Wed, 23 Feb 2005 10:03:01 -0500

> 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

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 23 Feb 2005 15:06:17 +0000

> The Linux sources have worked, and if they currently don't we

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

  Ralf

---

From: Thomas Sailer <[email-masked]>
Date: Wed, 23 Feb 2005 17:57:36 +0100

> 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

---

From: Dan Malek <[email-masked]>
Date: Wed, 23 Feb 2005 12:02:47 -0500

> 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

---

From: Pete Popov <[email-masked]>
Date: Wed, 23 Feb 2005 09:47:22 -0800

> 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

---

From: JP Foster <[email-masked]>
Date: Thu, 24 Feb 2005 10:04:55 +0000

>an uplift as well, but I don't know if we'll have time to do it.

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

---

From: Peter Popov <[email-masked]>
Date: Thu, 24 Feb 2005 08:15:41 -0800 (PST)

> 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. 

> toolchain for mips. Should I go build gcc-2.95 and

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

---

From: Clem Taylor <[email-masked]>
Date: Thu, 24 Feb 2005 11:19:51 -0500

> 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

---

From: JP Foster <[email-masked]>
Date: Thu, 24 Feb 2005 17:09:26 +0000

>We're working on making a toolkit available soon, or

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 :)

-- 
[email-masked]
Digital Simplicity

---

From: JP Foster <[email-masked]>
Date: Fri, 25 Feb 2005 17:29:56 +0000

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

-- 
[email-masked]
Digital Simplicity