[Qemu-devel] Raspbian in QEMU

[Qemu-devel] Raspbian in QEMU

[Peter Hanzel]

Hello.

I have successfully started Raspbian for Raspberry PI in QEMU.
I am just curious why you must disable ld.so.preload to libcofi_rpi.so

This is optimized library for memset, memcpy:
https://github.com/simonjhall/copies-and-fills.

Use this library some unsupported ARM instruction?

Thanks for any replay.

Re: [Qemu-devel] Raspbian in QEMU

[Peter Maydell]

On 12 March 2014 09:55, Peter Hanzel <hanzelpeter@gmail.com> wrote:
> Hello.
>
> I have successfully started Raspbian for Raspberry PI in QEMU.
> I am just curious why you must disable ld.so.preload to libcofi_rpi.so
>
> This is optimized library for memset, memcpy:
> https://github.com/simonjhall/copies-and-fills.
>
> Use this library some unsupported ARM instruction?

It uses SETEND to switch from little-endian to big-endian
mode; QEMU doesn't implement that.

thanks
-- PMM

Re: [Qemu-devel] Raspbian in QEMU

[Peter Hanzel]

Thanks.

Now it makes sense. Also google now works and led me to
https://github.com/bavison/arm-mem.
And there is SETEND used.

Re: [Qemu-devel] Raspbian in QEMU

[Stefan Weil]

Am 12.03.2014 19:05, schrieb Peter Hanzel:
> Thanks.
> 
> Now it makes sense. Also google now works and led me to
> https://github.com/bavison/arm-mem.
> And there is SETEND used.
> 

It might be possible to handle that special case in QEMU without
implementing setend:

That instruction is only used in the implementation of function memcmp.
When TCG detects a setend instruction, it could check whether the
surrounding code has the signature of that memcmp implementation and add
code which calls a memcmp helper function. The setend instruction and
all the following code of memcmp would be handled as if it were a single
special multi byte machine instruction.

Is that special accelerated implementation of memcmp used in lots of ARM
systems, or is it only used for Raspberry PI? From the copyright in
memcpy.S I'd guess that it is RPi specific, so maybe the need for a QEMU
hack is not urgent enough.

Stefan

PS. Link to previous discussion on setend:
https://lists.gnu.org/archive/html/qemu-trivial/2013-08/msg00086.html
I cc Richard because he was / is involved, too.

Re: [Qemu-devel] Raspbian in QEMU

[Richard Henderson]

On 03/12/2014 11:56 AM, Stefan Weil wrote:
> Am 12.03.2014 19:05, schrieb Peter Hanzel:
>> Thanks.
>>
>> Now it makes sense. Also google now works and led me to
>> https://github.com/bavison/arm-mem.
>> And there is SETEND used.
>>
> 
> It might be possible to handle that special case in QEMU without
> implementing setend:
> 
> That instruction is only used in the implementation of function memcmp.
> When TCG detects a setend instruction, it could check whether the
> surrounding code has the signature of that memcmp implementation and add
> code which calls a memcmp helper function. The setend instruction and
> all the following code of memcmp would be handled as if it were a single
> special multi byte machine instruction.

Ew.  No.  It would be easier to just implement setend, even if badly.

> PS. Link to previous discussion on setend:
> https://lists.gnu.org/archive/html/qemu-trivial/2013-08/msg00086.html
> I cc Richard because he was / is involved, too.

For my part, the endian-aware load/store opcodes I alluded to last
August are now in.


r~

Re: [Qemu-devel] Raspbian in QEMU

[Peter Maydell]

On 12 March 2014 19:41, Richard Henderson <rth@twiddle.net> wrote:
> Ew.  No.  It would be easier to just implement setend, even if badly.

Agreed.

> For my part, the endian-aware load/store opcodes I alluded to last
> August are now in.

Yes, it would be fairly straightforward to implement setend now.
I haven't actually looked at it, though, because the only thing that
uses it is this raspi memcmp code, and there's a workaround
for that. So other things have been higher priority.

thanks
-- PMM

Re: [Qemu-devel] Raspbian in QEMU

[Paolo Bonzini]

Il 12/03/2014 21:01, Peter Maydell ha scritto:
> On 12 March 2014 19:41, Richard Henderson <rth@twiddle.net> wrote:
>> Ew.  No.  It would be easier to just implement setend, even if badly.
>
> Agreed.
>
>> For my part, the endian-aware load/store opcodes I alluded to last
>> August are now in.
>
> Yes, it would be fairly straightforward to implement setend now.
> I haven't actually looked at it, though, because the only thing that
> uses it is this raspi memcmp code, and there's a workaround
> for that. So other things have been higher priority.

I looked at that yesterday and it took me exactly one hour... I'll 
submit it for 2.1 since I'm interested (for non-work reasons) in 
Raspberry Pi emulation.

Paolo

Re: [Qemu-devel] Raspbian in QEMU

[François Revol]

On 20/03/2014 13:36, Paolo Bonzini wrote:
> Il 12/03/2014 21:01, Peter Maydell ha scritto:
>> On 12 March 2014 19:41, Richard Henderson <rth@twiddle.net> wrote:
>>> Ew.  No.  It would be easier to just implement setend, even if badly.
>>
>> Agreed.
>>
>>> For my part, the endian-aware load/store opcodes I alluded to last
>>> August are now in.
>>
>> Yes, it would be fairly straightforward to implement setend now.
>> I haven't actually looked at it, though, because the only thing that
>> uses it is this raspi memcmp code, and there's a workaround
>> for that. So other things have been higher priority.
> 
> I looked at that yesterday and it took me exactly one hour... I'll
> submit it for 2.1 since I'm interested (for non-work reasons) in
> Raspberry Pi emulation.

Just so you don't start rewriting the wheel:

https://github.com/Torlus/qemu/tree/rpi

I'm not sure how far he went yet though.

François.

Re: [Qemu-devel] Raspbian in QEMU

[Paolo Bonzini]

Il 20/03/2014 14:08, François Revol ha scritto:
>> > I looked at that yesterday and it took me exactly one hour... I'll
>> > submit it for 2.1 since I'm interested (for non-work reasons) in
>> > Raspberry Pi emulation.
> Just so you don't start rewriting the wheel:
>
> https://github.com/Torlus/qemu/tree/rpi

No, I'm not going to rewrite it but I'll gladly review it.

Paolo