Re: Role of qemu-arm

[Alex Bennée]

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


-- 
Alex Bennée