Hi Waldemar,
On 16/08/14 04:12, Waldemar Brodkorb wrote:
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.
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.
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
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.
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.
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
Hmmm, yeah, it does stop there. Not sure why. I will need to look
more closely at that.
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?
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
_______________________________________________
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
