linux-kernel - Re: Microblaze image hanging in qemu with 3.15-rc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 24 Apr 2014 06:38:41 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	monstr@...str.eu
CC:	linux-kernel@...r.kernel.org
Subject: Re: Microblaze image hanging in qemu with 3.15-rc

On 04/23/2014 11:16 PM, Michal Simek wrote:
> On 04/23/2014 05:45 PM, Guenter Roeck wrote:
>> On Wed, Apr 23, 2014 at 04:12:59PM +0200, Michal Simek wrote:
>>> On 04/23/2014 03:38 PM, Guenter Roeck wrote:
>>>> On 04/22/2014 10:32 PM, Michal Simek wrote:
>>>>> Hi Guenter,
>>>>>
>>>>>
>>>>> On 04/22/2014 07:23 PM, Guenter Roeck wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> when trying to run a microblaze image with 3.15-rc1 or 3.15-rc2 in qemu,
>>>>>> I get the following hangup. This used to work with earlier kernels
>>>>>> with the same configuration.
>>>>>>
>>>>>> Is this a known problem, or is something wrong with my configuration
>>>>>> or with my qemu command line ?
>>>>>
>>>>> Is this BE/LE version? Which qemu do you use?
>>>>
>>>> BE.
>>>>
>>>> file vmlinux:
>>>>
>>>> vmlinux: ELF 32-bit MSB  executable, version 1 (SYSV), statically linked, BuildID[sha1]=5e1872c08df2956eddaed6fc1f6528a8540375b7, not stripped
>>>>
>>>> qemu-system-microblaze --version:
>>>>
>>>> QEMU emulator version 1.7.0, Copyright (c) 2003-2008 Fabrice Bellard
>>>>
>>>> gcc --version:
>>>>
>>>> microblaze-linux-gcc (GCC) 4.8.0
>>>> Copyright (C) 2013 Free Software Foundation, Inc.
>>>> This is free software; see the source for copying conditions.  There is NO
>>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>>>
>>>>> There is endian autodetection in timer and intc driver
>>>>> which can caused this problem.
>>>>>
>>>> Is this new code ? I didn't see the problem in 3.13 (same compile options,
>>>> same configuration, same compiler, same qemu version).
>>>
>>> yes it was added to 3.15-rc1.
>>>
>>> Try to rever this one
>>> a66a626 microblaze: Use asm-generic/io.h
>>>
>>> but the problem is probably here because you are not getting proper
>>> reaction from qemu model.
>>> a1715bb microblaze: Make timer driver endian aware
>>> 1aa1243 microblaze: Make intc driver endian aware
>>>
>>> I have tested it on the latest petalinux qemu and there shouldn't be
>>> any problem.
>>>
>> Hi Michal,
>>
>> qemu 2.0.0 still has the problem. Bisect points to
>>
>> commit a66a626538af65cbfc611e2b2fce500ed3f24518
>> Author: Michal Simek <michal.simek@...inx.com>
>> Date:   Thu Feb 7 15:12:24 2013 +0100
>>
>>      microblaze: Use asm-generic/io.h
>>
>> as the culprit, so you were right on the money. Reverting this commit
>> fixes the problem.
>
> yep. But it is just side effect of previous two commits I have mentioned.
> Can you just please check if you are setting up correct IO functions?
>
> 	write_fn = timer_write32;
> 	read_fn = timer_read32;
>
> 	write_fn(TCSR_MDT, timer_baseaddr + TCSR0);
> 	if (!(read_fn(timer_baseaddr + TCSR0) & TCSR_MDT)) {
> 		write_fn = timer_write32_be;
> 		read_fn = timer_read32_be;
> 	}
> git
>

The read returns 0x1, so the access functions are not updated. If I change the code
to force the update to the _be versions, the calibration loop still hangs (obviously,
because then the result is 0x01000000, which is really wrong).

>> Assuming this is in fact a problem with qemu, can you point me to a set
>> of qemu patches necessary to fix it ? Also, do you know if there are plans
>> to send the patches upstream ? I don't find anything related in the qemu
>> repository (though of course I may have missed it).
>
> Yes, it should be qemu issue. I am not aware about particular qemu patches
> but you can try to use https://github.com/Xilinx/qemu
> but now sure if Peter updating this repository.
>
Last commit in that repository is from a year ago, so it looks like he doesn't
update it.

> Anyway if you look at code above and I expect that the problem is just
> that autodetection is broken in your qemu it should be pretty simple
> to fix it.
>
Not sure I understand what you'd expect qemu to return in this case,
and why it worked previously. Any idea ?

Thanks,
Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/