Re: Role of qemu-arm

[vincent Dupaquis]

The libraries in this case do not make any interaction with I/O. We take
control over them through GDB to be able to run them & test them.

They can be linked into a ELF binary (indeed this is how we test them,
we link them with a dummy binary and take control over it using the
debug interface).

Regading the priviledged instructions, I do not understand the question,
we only use available core instructions (I do not remember about
priviledged instructions in Cortex-Mx.

Le 24/06/2020 à 12:14, Alex Bennée a écrit :
> vincent Dupaquis <v.dupaquis@trusted-objects.com> writes:
>
>> Indeed, for us it has an interest, as we do libraries running on
>> cortex-Mx cores. We are not linked to any specific board and can run
>> on any.
> Do the libraries use any privileged instructions?
> How do they interact with I/O?
> Can they be linked into an ELF binary?
>
>> Currently, we are using a basic board (the netduino2), and do not make
>> use of any peripherals (that's the goal of our project, being able to be
>> used on any board, with the right core). We do not even use the IT
>> controller.
>>
>> You are right to say that there is no need of having 'plain cpu'
>> emulation, as long as you can use any existing simulated board model.
>> So, as long as there is
>>
>> By the way, my original question was on the usage of qemu-arm, and I
>> have my response now :) It has no interest for cortex-Mx devices.
> So I believe some of the gcc m-profile test suite runs under qemu-arm
> with semihosting for this reason. You may need to wrap a little test
> harness around your libraries to get this to work though.
>
>> Best regards,
>>
>> Vincent.
>>
>> Le 22/06/2020 à 15:43, Peter Maydell a écrit :
>>> On Mon, 22 Jun 2020 at 14:03, vincent Dupaquis
>>> <v.dupaquis@trusted-objects.com> wrote:
>>>>     It is a shame, so I suppose I'll have to stay with my emulation
>>>> using netduino2 or so ...
>>>>
>>>>     That was the reason why I tried to use qem-arm, which is probably
>>>> crashing because what you just suggested.
>>> qemu-arm is for "I'm a linux userspace binary"; if your code is
>>> a userspace binary then you can use it...
>>>
>>>>     Is there a way of pointing-out the interest for the feature ?
>>> I'm afraid we don't support or have any plan to support
>>> "just run a CPU, no peripherals". I don't think there's much
>>> utility in it -- M-profile needs the interrupt controller,
>>> almost any setup wants to have a UART for I/O, and you need
>>> some actual RAM, which then leaves you with the question of
>>> what address to put the RAM at. At that point you're not
>>> really "just a CPU", you're "a minimalist board that doesn't
>>> correspond to any real hardware". We've found from experience
>>> that emulating things which don't correspond to something
>>> in the real world is not really maintainable and supportable
>>> in the long term.
>>>
>>> If your code will genuinely run on any M-profile board,
>>> just pick whichever one seems most useful and ignore
>>> the devices you don't need to use. (I like the mps2-an385,
>>> it has a bit more RAM than most.)
>>>
>>> thanks
>>> -- PMM
>
-- 

*Vincent Dupaquis*
Software security & Cryptography expert
06 24 58 17 05
/Europarc de Pichaury Bâtiment B8 1330 rue Guillibert de la Lauzière
13290 Aix-en-Provence/

www.trusted-objects.com <http://www.trusted-objects.com>