Re: qemu/m68k

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