[uClinux-dev] qemu/m68k

Hi Waldemar,

Post by Waldemar Brodkorb
Hi uClinux hackers,
I am trying to build a Linux System for Qemu/m68k to do runtime
testing of a uClibc spin-off called uClibc-ng.
(http://www.uclibc-ng.org)
I am really a newbie regarding MMU-less Linux systems, so don't be
to critical ;)
My toolchain (gcc 4.8.3, binutils 2.24) seems to work, because I can
Linux version 3.15.8 (wbx at kop-brodkorbw) (gcc version 4.8.3 (GCC) ) #25 Thu Aug 14 16:09:16 CEST 2014
uClinux/COLDFIRE(m520x)
COLDFIRE port done by Greg Ungerer, gerg at snapgear.com
Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16320
Kernel command line: console=ttyS0,19200 ro rootfstype=tmpfs
...
Starting Linux (built with OpenADK).
Freeing unused kernel memory: 1128K (4021e000 - 40338000)
qemu: fatal: Trying to execute code outside RAM or ROM at 0x0001eedc
qemu-system-m68k --version
QEMU emulator version 2.1.0, Copyright (c) 2003-2008 Fabrice Bellard
I am using elf2flt from git://wh0rd.org/elf2flt.git to produce flat
binaries.
$ file bin/busybox
$ bin/busybox: BFLT executable - version 4 gotpic
Does anyone have an advice what is wrong here?
The uClinux website have some links to a cvs repository, which are
no longer reachable. Is there a temporary problem?

I don't know what happened to the CVS there. Not sure if it will
be coming back.

Post by Waldemar Brodkorb
Where does the latest version of elf2flt is available?

Hmmm. Well, that is a good question. I don't know where the
definitive version really is anymore.

Anyway, I can give you a starting point that works for me. I have
used the tools I generated at:

http://www.uclinux.org/pub/uClinux/m68k-elf-tools/tools-20101118/m68k-uclinux-tools-20101118.sh

for a couple of years now. They generate working systems that
run on real hardware and also under qemu. The source for generating
those tools is there in that same directory:

http://www.uclinux.org/pub/uClinux/m68k-elf-tools/tools-20101118/

I only use it for building Coldfire targets.

That is building the uclinux-dist:

http://www.uclinux.org/pub/uClinux/dist/

That is a 3.10 kernel, but you can take any linus kernel and use
that with the same result. The uClibc in there may have some changes
over a stock 0.9.33.

A good place to start debugging these types of user space problems
is with the kernel trace option of flat files. So use the flthdr tool
to enable the kernel trace flag (-k) on the generated flat files,
then build you rootfs with those. Then at least you can see where
you app is in RAM.

Regards
Greg

Waldemar Brodkorb

2014-08-15 18:12:29 UTC

Hi Greg,
Greg Ungerer wrote,

Post by Greg Ungerer
Hi Waldemar,

I don't know what happened to the CVS there. Not sure if it will
be coming back.

May be yu could remove the dead links? Do you have access to the
webserver? Or you could setup a git repository for it?
I can help with it, if you need admin or technical information about
it.

Post by Greg Ungerer
Anyway, I can give you a starting point that works for me. I have
http://www.uclinux.org/pub/uClinux/m68k-elf-tools/tools-20101118/m68k-uclinux-tools-20101118.sh
for a couple of years now. They generate working systems that
run on real hardware and also under qemu. The source for generating
http://www.uclinux.org/pub/uClinux/m68k-elf-tools/tools-20101118/
I only use it for building Coldfire targets.
http://www.uclinux.org/pub/uClinux/dist/
That is a 3.10 kernel, but you can take any linus kernel and use
that with the same result. The uClibc in there may have some changes
over a stock 0.9.33.
A good place to start debugging these types of user space problems
is with the kernel trace option of flat files. So use the flthdr tool
to enable the kernel trace flag (-k) on the generated flat files,
then build you rootfs with those. Then at least you can see where
you app is in RAM.

Yeah, thanks a lot. Kernel trace helped. I got further booting up
the system. I am not really sure, what my problem was, but now I get
to the first shell (busybox hush). I think my elf2flt setup was
br0ken or -msep-data in CFLAGS fixed it.
My bootlog with a strace output of hush:
http://openadk.org/coldfire.txt

Do you have a suggestion why I get a segfault after first executed
command? Similar behaviour Thomas Petazzoni have seen, while he was
trying to run buildroot in Qemu/m68k. See here:
http://lists.busybox.net/pipermail/buildroot/2012-April/052585.html

BTW: I compiled uClinux, but the result does not start in Qemu.
I used CONFIG_DEFAULTS_FREESCALE_M5208EVB to configure it.
Is there a reason you use -m5307 for gcc, instead of -m5208?

Without the kernel patch from Thomas you get no output.
Without the Qemu patch from Thomas you get:
qemu-system-m68k -nographic -kernel image.elf
qemu: hardware error: mcf_intc_write: Bad write offset 28

With kernel and qemu patch I get:
Linux version 3.10.0-uc0 (wbx at kop-brodkorbw) (gcc version 4.5.1 (GCC) ) #3 Fri Aug 15 19:52:04 CEST 2014
uClinux/COLDFIRE(m520x)
COLDFIRE port done by Greg Ungerer, gerg at snapgear.com
...
qemu: hardware error: mcf_fec_read: Bad address 0x1c4

Disabling FEC ethernet driver gets me too:
uclinux[mtd]: probe address=0x401e91b8 size=0x0
uclinux[mtd]: set ROMfs to be root filesystem
Creating 1 MTD partitions on "ram":
0x000000000000-0x000000000000 : "ROMfs"
mtd: partition "ROMfs" is out of reach -- disabled
TCP: cubic registered
NET: Registered protocol family 17
end_request: I/O error, dev mtdblock0, sector 2
EXT2-fs (mtdblock0): error: unable to read superblock
VFS: Cannot open root device "(null)" or unknown-block(31,0): error
-5
Please append a correct "root=" boot option; here are the available
partitions:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,0)

Which version of Qemu are you using to bootup uClinux?

Thanks in advance
Waldemar

Greg Ungerer

2014-08-16 14:08:12 UTC

Hi Waldemar,

Post by Waldemar Brodkorb
Hi Greg,
Greg Ungerer wrote,

Post by Greg Ungerer
Hi Waldemar,

I don't know what happened to the CVS there. Not sure if it will
be coming back.

May be yu could remove the dead links? Do you have access to the
webserver? Or you could setup a git repository for it?
I can help with it, if you need admin or technical information about
it.

Apparently the hard disk failed in the cvs.uclinux.org server. It will
be coming back, I don't have an ETA for that though.

There is some talk of putting up a git tree for it. Will keep this list
posted on progress towards that.

No, I haven't seen that behavior. Is it a hush problem?
Maybe try a simpler shell to see if you get the same result.

Post by Waldemar Brodkorb
BTW: I compiled uClinux, but the result does not start in Qemu.
I used CONFIG_DEFAULTS_FREESCALE_M5208EVB to configure it.
Is there a reason you use -m5307 for gcc, instead of -m5208?

Historical I would think. The original code was developed before
gcc had a -m5208 option. Probably never been updated.

Post by Waldemar Brodkorb
Without the kernel patch from Thomas you get no output.
qemu-system-m68k -nographic -kernel image.elf
qemu: hardware error: mcf_intc_write: Bad write offset 28
Linux version 3.10.0-uc0 (wbx at kop-brodkorbw) (gcc version 4.5.1 (GCC) ) #3 Fri Aug 15 19:52:04 CEST 2014
uClinux/COLDFIRE(m520x)
COLDFIRE port done by Greg Ungerer, gerg at snapgear.com
...
qemu: hardware error: mcf_fec_read: Bad address 0x1c4

Hmmm, yeah, it does stop there. Not sure why. I will need to look
more closely at that.

Post by Waldemar Brodkorb
uclinux[mtd]: probe address=0x401e91b8 size=0x0
uclinux[mtd]: set ROMfs to be root filesystem
0x000000000000-0x000000000000 : "ROMfs"
mtd: partition "ROMfs" is out of reach -- disabled
TCP: cubic registered
NET: Registered protocol family 17
end_request: I/O error, dev mtdblock0, sector 2
EXT2-fs (mtdblock0): error: unable to read superblock
VFS: Cannot open root device "(null)" or unknown-block(31,0): error
-5
Please append a correct "root=" boot option; here are the available
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,0)
Which version of Qemu are you using to bootup uClinux?

I am using a 1.2.50 modified with the patches I link to at:

http://marc.info/?l=uclinux-dev&m=134881405711207&w=2

I sent those to the qemu devel list, I don't know if they ever got merged.

The next problem is due to the way images are put together by
default for ColdFire dev board targets. The romfs appended to the
kernel doesn't load by default on qemu.

The solution I use for this (to not have to modify the build) is to start
up qemu halted for the target:

qemu-system-m68k -s -S -nographic -machine mcf5208evb -kernel
images/image.elf

And then connect with a m68k-linux-gdb then do:

target remote localhost:1234
load images/image.elf
file linux-3.x/vmlinux

The resuming the target (c) starts up the image and it will have the
romfs in memory.

You can modify the kernel config and build to use a compiled in initrd too.
You don't have to mess with gdb as well then.

Regards
Greg

Waldemar Brodkorb

2014-08-21 20:25:09 UTC

Hi Greg,

Post by Waldemar Brodkorb
Do you have a suggestion why I get a segfault after first executed
command? Similar behaviour Thomas Petazzoni have seen, while he was
http://lists.busybox.net/pipermail/buildroot/2012-April/052585.html

No, I haven't seen that behavior. Is it a hush problem?
Maybe try a simpler shell to see if you get the same result.

Okay, it seems a problem with my uClibc version or configuration.
Still investigating. But using the sash from uClinux works fine
with my own kernel.

Post by Waldemar Brodkorb
qemu: hardware error: mcf_fec_read: Bad address 0x1c4

Hmmm, yeah, it does stop there. Not sure why. I will need to look
more closely at that.

Did you found anything?

BTW: Are Cisco devices not official supported by uClinux?
I recently had the luck to find an old Cisco 1000 Series router
with a M68360 Motorola CPU. I like to use it probably for some
runtime testing, if I can boot Linux on it.

best regards
Waldemar

Greg Ungerer

2014-08-22 00:40:01 UTC

Hi Waldemar,

No, I haven't seen that behavior. Is it a hush problem?
Maybe try a simpler shell to see if you get the same result.

Okay, it seems a problem with my uClibc version or configuration.
Still investigating. But using the sash from uClinux works fine
with my own kernel.

Ok, at least that gives you a working base to go from.

Post by Waldemar Brodkorb
qemu: hardware error: mcf_fec_read: Bad address 0x1c4

Hmmm, yeah, it does stop there. Not sure why. I will need to look
more closely at that.

Did you found anything?

Yep. The problem is that the FEC driver is writing to registers
that don't exist in the FEC hardware module on the ColdFire
family. Support for some of the extended registers used on
the FEC are used on ARM implementations, and they had added
support for those in more recent years.

I never picked those up on real hardware. Accesses to those
on addresses cause no (visible) problems.

Anyway, attached is a patch I propose to fix it. I will be
sending this to the linux net-dev list soon.

Post by Waldemar Brodkorb
BTW: Are Cisco devices not official supported by uClinux?
I recently had the luck to find an old Cisco 1000 Series router
with a M68360 Motorola CPU. I like to use it probably for some
runtime testing, if I can boot Linux on it.

I don't think anything is "official" in uClinux really :-)

There is some old and probably very crufty support for the 68360
in mainline. Not sure what platforms it was used on.

Regards
Greg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-net-fec-do-not-read-write-undefined-registers-on-Col.patch
Type: text/x-diff
Size: 3970 bytes
Desc: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20140822/979f40de/attachment.bin>

Geert Uytterhoeven

2014-08-22 07:12:32 UTC

Hi Greg,

Post by Waldemar Brodkorb
qemu: hardware error: mcf_fec_read: Bad address 0x1c4

Hmmm, yeah, it does stop there. Not sure why. I will need to look
more closely at that.

Did you found anything?

Yep. The problem is that the FEC driver is writing to registers
that don't exist in the FEC hardware module on the ColdFire
family. Support for some of the extended registers used on
the FEC are used on ARM implementations, and they had added
support for those in more recent years.
I never picked those up on real hardware. Accesses to those
on addresses cause no (visible) problems.
Anyway, attached is a patch I propose to fix it. I will be
sending this to the linux net-dev list soon.

Instead of sprinkling the driver with (more) #ifdefs, wouldn't it be
better to use FEC_QUIRK_* flags in fec_devtype / platform data?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Greg Ungerer

2014-08-22 13:18:37 UTC

Hi Geert,

Post by Waldemar Brodkorb
Hi Greg,

Post by Waldemar Brodkorb
qemu: hardware error: mcf_fec_read: Bad address 0x1c4

Hmmm, yeah, it does stop there. Not sure why. I will need to look
more closely at that.

Did you found anything?

Yep. The problem is that the FEC driver is writing to registers
that don't exist in the FEC hardware module on the ColdFire
family. Support for some of the extended registers used on
the FEC are used on ARM implementations, and they had added
support for those in more recent years.
I never picked those up on real hardware. Accesses to those
on addresses cause no (visible) problems.
Anyway, attached is a patch I propose to fix it. I will be
sending this to the linux net-dev list soon.

Instead of sprinkling the driver with (more) #ifdefs, wouldn't it be
better to use FEC_QUIRK_* flags in fec_devtype / platform data?

This patch only added one more #ifdef... But your right, it
would be nice to have a lot less. I'll take another look at this.

Thanks
Greg

Waldemar Brodkorb

2014-08-25 20:35:42 UTC

Hi Greg,
Greg Ungerer wrote,

Post by Greg Ungerer
Hi Waldemar,

No, I haven't seen that behavior. Is it a hush problem?
Maybe try a simpler shell to see if you get the same result.

Okay, it seems a problem with my uClibc version or configuration.
Still investigating. But using the sash from uClinux works fine
with my own kernel.

Ok, at least that gives you a working base to go from.

Okay, after further investigation and deeper digging in the uClinux
buildsystem I found partially a solution to my problem.
uCLinux uses a gcc wrapper and is linking executables with
-nostdlib and manually adding the needed C libraries and startup
files.
I have just used -static, but this pulled in crtbegin.o and crtend.o
from gcc. I now use a gcc wrapper with a modified spec file, so that
crtbegin.o/crtend.o is not added to my binary.
Furthermore I added following patch to my gcc:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54584

Both changes required to create a working BFLT executable.
Otherwise elf2flt seems to pick up the data section of crtbegin.o,
which ends up with a BFLT file with a wrong data start.

I can provide more details and output of readelf of the sh.gdb files,
if required. I am not sure if this can be fixed in the linker script
used by elf2flt.

But I still don't get an interactive shell working. I use simpleinit
and sash. The output of Qemu is:
Starting Linux (built with OpenADK).
Freeing unused kernel memory: 432K (401a0000 - 4020c000)
Shell invoked to run file: /etc/rc
Command: echo Starting OpenADK
Starting OpenADK
Command: hostname openadk
Command: mount -t proc proc /proc
Command: mount -t sysfs sys /sys
Command: mkdir -m 755 /dev/pts
Command: mount -t devpts devpts /dev/pts
Command: mount -t tmpfs -o size=8M tmpfs /tmp
Command: chmod 1777 /tmp
Command: mkdir -p /var/log
Command: mkdir -p /var/run
Command: mkdir -p /var/tmp
Command: mdev -s
Command: mount
rootfs on / type rootfs (rw)
devtmpfs on /dev type devtmpfs (rw,relatime,mode=0755)
proc on /proc type proc (rw,relatime)
sys on /sys type sysfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
tmpfs on /tmp type tmpfs (rw,relatime,size=8M)
Command: ifconfig lo 127.0.0.1 up
Execution Finished, Exiting

openadk login: Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b

My inittab is:
s0:linux:/sbin/getty -L -n 38400 ttyS0
1:linux:/sbin/getty -L -n 38400 ttyS1

I have taken a look into the coldfire example from qemu.org. They
are using simpleinit and busybox msh. I tried busybox hush, instead
of sash, but without success. msh seems no longer available in
busybox. Does uClinux provide a interactive shell?

(need to try the uClinx system with the gdb method. I am just using kernel with initramfs
piggyback)

Post by Waldemar Brodkorb
qemu: hardware error: mcf_fec_read: Bad address 0x1c4

Hmmm, yeah, it does stop there. Not sure why. I will need to look
more closely at that.

Did you found anything?

Yep. The problem is that the FEC driver is writing to registers
that don't exist in the FEC hardware module on the ColdFire
family. Support for some of the extended registers used on
the FEC are used on ARM implementations, and they had added
support for those in more recent years.
I never picked those up on real hardware. Accesses to those
on addresses cause no (visible) problems.
Anyway, attached is a patch I propose to fix it. I will be
sending this to the linux net-dev list soon.

Great! I will test it really soon. Or may be your upcoming patch.

thanks
Waldemar

Waldemar Brodkorb

2014-08-29 06:32:43 UTC