From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zen.linaroharston ([51.148.130.216]) by smtp.gmail.com with ESMTPSA id f16sm7614385wmh.27.2020.06.24.03.14.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jun 2020 03:14:51 -0700 (PDT) Received: from zen (localhost [127.0.0.1]) by zen.linaroharston (Postfix) with ESMTP id 5CBAD1FF7E; Wed, 24 Jun 2020 11:14:50 +0100 (BST) References: <20200619170324.12093-1-peter.maydell@linaro.org> <879e933c-a65c-3706-afa1-5ede1acb062c@ispras.ru> <87o8pba35w.fsf@linaro.org> <7e057989-56b8-195d-247d-9ab0522ff23a@amsat.org> <56ffc60e-f458-e9d4-d89e-4ca70b1ed4e2@trusted-objects.com> User-agent: mu4e 1.5.3; emacs 28.0.50 From: Alex =?utf-8?Q?Benn=C3=A9e?= To: vincent Dupaquis Cc: Peter Maydell , Philippe =?utf-8?Q?Mathieu-D?= =?utf-8?Q?aud=C3=A9?= , qemu-arm Subject: Re: Role of qemu-arm In-reply-to: Date: Wed, 24 Jun 2020 11:14:50 +0100 Message-ID: <87mu4s7oth.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-TUID: mbYeOywGZyHA vincent Dupaquis 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 =C3=A0 15:43, Peter Maydell a =C3=A9crit : >> On Mon, 22 Jun 2020 at 14:03, vincent Dupaquis >> 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 --=20 Alex Benn=C3=A9e