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, g...@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 _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
