[Debian-coldfire-devel] Linux on coldfire

[Wouter Verhelst]

On Tue, Mar 07, 2006 at 12:16:43AM +0100, Christian T. Steigies wrote:
> There was no mail on this list in february, or did I misconfigure my mail
> filters again?

No; there just wasn't any mail :-)

> On Thu, Jan 26, 2006 at 01:46:16PM -0600, Stephen R Marenka wrote:
> > On Thu, Jan 26, 2006 at 08:17:05AM -0600, Stephen R Marenka wrote:
> > 
> > > This [1] would seem like a good start, but requires a user account 
> > > with freescale.
> > > 
> > > [1] <http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=CWB-MCF547X-548X-2-6-KL&parentCode=CW_BSP&nodeId=01272600610332>
> > 
> > So now I have an account, an iso, and am playing with ltib in 
> > preparation to actually booting into linux. Baby steps.
> > 
> > It looks like 2.6.10, gcc 3.4.3, binutils 2.15.
> 
> I got that far now also:
> 
> Linux version 2.6.10 (mattw at etna) (gcc version 3.4.0) #1 Mon Dec 12 16:51:05 MST 2005
> starting up linux rev 0.2: startmem 0xc02cc000, size 61MB
> Built 1 zonelists
> Kernel command line: root=/dev/ram
> PID hash table entries: 512 (order: 9, 8192 bytes)
> RTC driver is not initialized yet, returning 1970.
> Console: colour dummy device 80x25
> Dentry cache hash table entries: 16384 (order: 3, 65536 bytes)
> Inode-cache hash table entries: 8192 (order: 2, 32768 bytes)
> Memory: 62160k/65536k available (2104k kernel code, 1064k data, 112k init)
> Mount-cache hash table entries: 1024 (order: 0, 8192 bytes)
> NET: Registered protocol family 16
> Linux/m68k PCI BIOS32 revision 0.05
> ColdFire PCI Host Bridge (Rev. 0) detected
> PCI: Probing PCI hardware
> ColdFire internal SEC driver version 0.11
> 
> and hangs...
> 
> How do I set the root device to nfs, with set cl? Does not work for me yet,
> any pointers? I haven't flashed anything yet, I run it all from RAM.
> 
> But the thing that looks promising is this:
> 
> root at skeeve:/tftpboot/ltib/rootfs/bin>file busybox
> busybox: setuid ELF 32-bit MSB executable, Motorola 68020, version 1 (SYSV), for GNU/Linux 2.4.3, dynamically linked (uses shared libs), stripped
> 
> So userspace programs might work out of the box?

No, that only means that the ELF format is the same on classic m68k and
on coldfire. If you use an instruction that doesn't exist on coldfire,
you'll either have a SIGILL, or the system misbehaving.

Try creating a .s file with this contents:
---cut here---
.LC0:
	.string "%d\n"
	.text
	.align 2
	.globl main
	.type main, at function
main:
	link %a6,#-4
	moveq #0,%d0
	moveq #1,%d1
	abcd %d1,%d0
	move %d0,-(%sp)
	pea .LC0
	jbsr printf
	unlk %a6
	rts
	.size main, .-main
---cut here---

and compile it like this:

gcc -o foo foo.s

Make sure to do that with a Debian toolchain. Also, using as directly
won't work, because then you haven't linked in everything else which is
necessary to create a working executable. Now try to run that on your
board. You'll get a SIGILL for the abcd opcode, which doesn't exist on
ColdFire. It will, however, run perfectly on classic m68k hardware
(output should be "65536").

> BTW my board/dBUG says:
> ColdFire MCF547X on the M5474LITE
> Did I get a "small" one?

IIRC, yes. Easy to check: if you have one PCI slot, you have a 'small'
one; if you have two, you've got a 'large' one.

BTW, speaking of assemblers: my changes to binutils have been completed
a while back, so should be ready. I haven't tested them yet (there seems
to be a problem with shipping...), but I don't think there's much I
could've done wrong (it's basically just checking a huge table of
opcodes and marking those that appear on both architectures as "ok").
For those who care, you can pull binutils out of svn, compile it (be
sure to use "--target=m68k-linux" if you're not compiling on an m68k
box), and then use the '-mcf68' flag. If you want or need to use gcc to
get there, use -Wa,-mcf68 (exactly as written, i.e., no spaces). Testers
are welcome :-)

That means we're now ready to go modifying gcc. Which I don't feel as
confident about as binutils; anyone else feel up to the challenge?

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4