Re: qemu/m68k

Waldemar Brodkorb <[email protected]>
Newsgroups gmane.linux.uclinux.devel
Message-ID <[email protected]>
Hi Greg,
Greg Ungerer wrote,

> Hi Waldemar,
> 
> On 15/08/14 00:18, Waldemar Brodkorb wrote:
> >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 ;)
>
> 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.
 
> 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.

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@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, [email protected]
...
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

_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.