Re: [Qemu-devel] experience with SDL2, event loop & main thread

> On 12 Dec 2016, at 16:51, Fam Zheng <f...@redhat.com> wrote: > > On Mon, 12/12 15:22, Liviu Ionescu wrote: >> so, back to square one; any suggestion on how to avoid the periodic timer >> required to poll SDL system events? > > Good question, I've mis

Re: [Qemu-devel] experience with SDL2, event loop & main thread

> On 12 Dec 2016, at 14:28, Fam Zheng wrote: > > ... Take a look at event_notifier_set_handler() and event_notifier_set(). > ... qemu_bh_new() and qemu_bh_schedule(). > > Both can register a callback that will be called in main loop once fired. ok, thank you, I'll consider

Re: [Qemu-devel] experience with SDL2, event loop & main thread

> On 12 Dec 2016, at 12:36, Fam Zheng wrote: > > an EventNotifier in the main thread which is notified by the vCPU > thread upon a new graphics operation? the idea of using notifications is ok, but I could not figure out what api to use to implement it. can you provide more

Re: [Qemu-devel] experience with SDL2, event loop & main thread

> On 12 Dec 2016, at 11:39, Fam Zheng wrote: > > ... I myself know next to nothing about SDL project. ok, neither do I. do you have any comments on the current situation of the SDL integration in QEMU? any comments on the conclusions I reached after integrating SDL2 into

Re: [Qemu-devel] experience with SDL2, event loop & main thread

> On 12 Dec 2016, at 09:39, Fam Zheng wrote: > >> any idea how difficult would be to push any changes to SDL? > > Not sure I understand this question, could you be more specific? I guess making SDL run asynchronously will need some major changes to the SDL source code, not

Re: [Qemu-devel] experience with SDL2, event loop & main thread

> On 12 Dec 2016, at 05:35, Fam Zheng wrote: > > Isn't it possible to notify the main thread with an EventNotifier and process > the deferred events in its handler? ideally, the SDL main loop might be re-implemented asynchronously, for example using a pipe to pass the events,

[Qemu-devel] experience with SDL2, event loop & main thread

given the reported problems with the SDL integration, here are some things I learned while updating GNU ARM Eclipse QEMU to use SDL2 (SDL1 is already issuing various warnings when running on macOS 10.12, and anyway it has several limitations). --- initially I expected that the project

Re: [Qemu-devel] QEMU for Windows - UI status

> On 10 Dec 2016, at 16:33, Stefan Weil wrote: > > I started testing with SDL 2.0 today. A default build for Windows > is not usable, I recently migrated GNU ARM Eclipse QEMU to SDL 2, and it works just fine on Windows, Linux and macOS. The graphical interactions with the

Re: [Qemu-devel] Support for using TCG frontend as a library

> On 2 Dec 2016, at 12:24, Peter Maydell wrote: > > Right, but if you have a bug which requires your application to > sit there processing for half an hour (or even five minutes) > before it appears, it's nice not to spend that time. fully agree. for physical targets,

Re: [Qemu-devel] Support for using TCG frontend as a library

> On 2 Dec 2016, at 11:40, Peter Maydell wrote: > >> ... integrate this feature in the usual debugging workflow. > > The most useful approach is that you can set up a complicated > situation (eg "boot my embedded RTOS, start application"), > snapshot at that point,

Re: [Qemu-devel] Support for using TCG frontend as a library

> On 1 Dec 2016, at 21:13, Peter Maydell wrote: > > You need a QCOW2 disk to store the snapshots on, ... > Taking savevm snapshots doesn't need any cooperation > from the guest OS .. > I don't know whether anybody's tested this with M profile: does your Stellaris

Re: [Qemu-devel] Support for using TCG frontend as a library

> On 1 Dec 2016, at 16:38, Peter Maydell wrote: > ... network device backends ... is a fair bit of work. yes, that's a good point, and I also plan to add Ethernet support to some of my boards, but I need first to fix some issues that I consider more important, like

Re: [Qemu-devel] Support for using TCG frontend as a library

> On 1 Dec 2016, at 14:38, Peter Maydell wrote: > > ... clean up QEMU's code so > that it is less interdependent ... that's a good idea anyway, but this does not address the current issue. if I'd have a separate library with ARM TCG, for Cortex-M emulation I'd

Re: [Qemu-devel] Support for using TCG frontend as a library

> On 1 Dec 2016, at 10:50, Paolo Bonzini wrote: > >> But why only linux-user and not full system emulation too? > > It would simplify the library. The front-end and helpers have some > differences > between usermode and softmmu, and the latter is much more intertwined

Re: [Qemu-devel] Support for using TCG frontend as a library

> On 29 Nov 2016, at 18:26, Paolo Bonzini wrote: > > ... It's pretty clean! ... if you manage to make the TCG frontend as a library, it would be great to check that it can also be used from C++. the current QEMU headers prevent this, by using C++ reserved words (like

[Qemu-devel] GNU ARM Eclipse QEMU: support for active graphical buttons added

For those interested in Cortex-M boards emulation: http://gnuarmeclipse.github.io/blog/2016/11/28/qemu-v2-7-0-20161128-released/ Any feedback is highly appreciated. Regards, Liviu

Re: [Qemu-devel] GPIO input?

> On 28 Nov 2016, at 11:34, Peter Maydell wrote: > > You might prefer to use the named-gpios ... I already did so, thank you. Liviu

[Qemu-devel] GPIO input?

I added graphical buttons to GNU ARM Eclipse QEMU, and I can already trigger actions when a button is pushed/released, so currently I can reset the STM32F4DISCOVERY board clicking the reset button on the board picture. Now I want to implement the user button, which on this board is connected to

Re: [Qemu-devel] macOS 10.12 Sierra, Xcode 8 & clock_gettime()

> On 26 Oct 2016, at 18:32, G 3 wrote: > > -isysroot /Developer/SDKs/MacOSX10.6.sdk yes, this is a compiler command line option pointing to an existing folder, but `/Developer/` is no longer in use for quite some time, and Apple does not provide any official way to

Re: [Qemu-devel] macOS 10.12 Sierra, Xcode 8 & clock_gettime()

> On 26 Oct 2016, at 17:32, G 3 wrote: > > Maybe changing the base SDK from Mac OS 10.12 to say Mac OS 10.6 might fix > the problem. any suggestion how to do this? for my linux and windows builds I use docker images, and I'm quite happy with this setup, it is

Re: [Qemu-devel] macOS 10.12 Sierra, Xcode 8 & clock_gettime()

> On 25 Oct 2016, at 17:21, Paolo Bonzini wrote: > > ... If you add the attribute to the test, configure will detect it or not > depending on -mmacosx-version-min, at least in theory. aha. so your suggestion is to extend configure to add CONFIG_HAVE_CLOCK_GETTIME, add

Re: [Qemu-devel] macOS 10.12 Sierra, Xcode 8 & clock_gettime()

> On 25 Oct 2016, at 16:48, Paolo Bonzini wrote: > > Perhaps you can add a configure test for clock_gettime, and define a > symbol CONFIG_HAVE_CLOCK_GETTIME if clock_gettime exists. I thought of this, but if I run the build on 10.12, configure will identify

Re: [Qemu-devel] macOS 10.12 Sierra, Xcode 8 & clock_gettime()

> On 25 Oct 2016, at 14:40, Paolo Bonzini wrote: > > > ... I think you need to use -mmacosx-version-min=10.10 or something like > that, ... I tried this, and I also tried "export MACOSX_DEPLOYMENT_TARGET=10.11", but they did not help. in this case, the decision to refer

Re: [Qemu-devel] macOS 10.12 Sierra, Xcode 8 & clock_gettime()

> On 25 Oct 2016, at 13:02, Peter Maydell wrote: > > Does "build on 10.12, run on earlier versions" work apart from > that problem? with a little help from a friend, the latest macOS build for GNU ARM Eclipse QEMU seems fully functional, the STM32F4DISCOVERY blinky

Re: [Qemu-devel] macOS 10.12 Sierra, Xcode 8 & clock_gettime()

> On 25 Oct 2016, at 13:02, Peter Maydell wrote: > > ... Does "build on 10.12, run on earlier versions" work apart from > that problem? it is a challenge for me to test, since I don't have a 10.11 at hand; I'll try to have an answer in the evening, but I expect it'll

[Qemu-devel] macOS 10.12 Sierra, Xcode 8 & clock_gettime()

In Xcode 8 (more or less mandatory after upgrading to Sierra), Apple added support for `clock_gettime(CLOCK_MONOTONIC, )`, which is not bad in itself. Unfortunately, with this addition, a QEMU built on 10.12 runs **only** on 10.12; on previous versions it fails with something like: ``` $

Re: [Qemu-devel] ARM Cortex-M issues

> On 30 Aug 2016, at 10:38, Peter Maydell wrote: > > ... the only thing > you can do is test it on the RTOSes you have to hand. which, in the end, is a highly effective way. it does not identifies bugs related to features not used by the RTOS, but otherwise it is

Re: [Qemu-devel] ARM Cortex-M issues

> On 29 Aug 2016, at 23:30, Bill Paul wrote: > > I just wish all of this was in once place. me too. my sources are public, and I support anyone who wants to take parts of them to improve the main source tree. unfortunately I do not have the resources to do this. :-( >

Re: [Qemu-devel] ARM Cortex-M issues

> On 29 Aug 2016, at 20:59, Bill Paul wrote: > > I recently started tinkering with ChibiOS as part of a small personal project > ... I did most of the development for the µOS++/CMSIS++ (http://micro-os-plus.github.io) on STM32F4DISCOVERY board, emulated by GNU ARM

Re: [Qemu-devel] invalid runstate transition: 'prelaunch' -> 'prelaunch'

Peter, Can you confirm that adding a new transition definition is ok for the context I'm using it? I had no problems so far, just wanted to be sure. Thank you, Liviu > On 27 Jul 2016, at 22:40, Liviu Ionescu <i...@livius.net> wrote: > > Hi, > > I just upgraded

[Qemu-devel] invalid runstate transition: 'prelaunch' -> 'prelaunch'

Hi, I just upgraded GNU ARM Eclipse QEMU to 2.6.0 and ran into a problem. The console reads: ``` GNU ARM Eclipse 64-bits QEMU v2.6.0 (qemu-system-gnuarmeclipse). Board: 'STM32F4-Discovery' (ST Discovery kit for STM32F407/417 lines). Device: 'STM32F407VG' (Cortex-M4 r0p0, MPU), Flash: 1024 kB,

[Qemu-devel] GNU ARM Eclipse QEMU: Use BASEPRI to disable interrupts on Cortex-M

Most of the development of my µOS++ / CMSIS++ RTOS was done on GNU ARM Eclipse QEMU and/or as a 64-bits user process on macOS. However, on QEMU, initially I encountered some strange behaviour when configuring the critical sections to use BASEPRI; when using DI/EI everything was fine. These

[Qemu-devel] GNU ARM Eclipse QEMU: Display more Cortex-M registers in GDB server

Inspired by the J-Link GDB server, I added more specific Cortex-M registers to the list of registers published by the GDB server implemented by the GNU ARM Eclipse QEMU. Here is how the registers are seen by Eclipse: If someone is planing to make these registers visible in QEMU, my patches

Re: [Qemu-devel] [RFC] target-arm: fix semihosting ram base issue

> On 18 Jun 2016, at 01:22, Tsung-Han Lin wrote: > > ... It seems like to me that the issue is the default address assumed by > qemu, which is 0x0. > (since Eclipse QEMU uses the same code, I believe they have the same problem.) it uses the same main code, but with many

Re: [Qemu-devel] [RFC] target-arm: fix semihosting ram base issue

> On 17 Jun 2016, at 05:37, Tsung-Han Lin wrote: > > Hi, I made some changes to TRY TO fix the ARM semihosting issue ... > This problem has been bothering me for quite a while. semihosting was the first thing I fixed in GNU ARM Eclipse QEMU, and since then I use it

Re: [Qemu-devel] GUI for peripherals

> On 01 Jun 2016, at 12:28, KONRAD Frederic wrote: > > ... I think Liviu did something about this: ... I confirm that GNU ARM Eclipse QEMU implements animated LEDs. In other words, toggling a GPIO pin connected to a led toggles the content of a rectangular area on

Re: [Qemu-devel] Any progress with the Cortex-M4 emulation?

> On 07 Apr 2016, at 03:46, Michael Davidsaver wrote: > > ... don't hesitate to appropriate, or ignore, what I've done so far. ... > https://github.com/mdavidsaver/qemu/tree/fixirq2 from what I see here, the nvic is still one big monolithic device. as I said before, I

Re: [Qemu-devel] Any progress with the Cortex-M4 emulation?

> On 07 Apr 2016, at 01:04, Peter Maydell wrote: > > ... Somebody needs to do the necessary work to fix the > code review issues. ... in this case I'll probably wait for this process to be completed and reevaluate the situation by then. regards, Liviu

Re: [Qemu-devel] Any progress with the Cortex-M4 emulation?

> On 06 Apr 2016, at 17:42, Peter Maydell <peter.mayd...@linaro.org> wrote: > > On 6 April 2016 at 13:52, Liviu Ionescu <i...@livius.net> wrote: >> >> I also have on my TODO list to implement the SCB registers used >> during exception processing (MMFAR, B

Re: [Qemu-devel] Any progress with the Cortex-M4 emulation?

> On 06 Apr 2016, at 15:02, Peter Maydell <peter.mayd...@linaro.org> wrote: > > On 5 April 2016 at 22:57, Liviu Ionescu <i...@livius.net> wrote: >> (I know that from time to time this question pops up, but) is >> there anyone working or planning to work on th

[Qemu-devel] Any progress with the Cortex-M4 emulation?

(I know that from time to time this question pops up, but) is there anyone working or planning to work on the M4 emulation? If not, I might give it a try, perhaps it is not as mission impossible as it looks like. Except the lazy processing of exception save/restore which must be implemented,

Re: [Qemu-devel] segmentation fault in object.c:type_initialize_interface() if interface not defined

> On 04 Apr 2016, at 00:30, Peter Maydell <peter.mayd...@linaro.org> wrote: > > On 3 April 2016 at 18:56, Liviu Ionescu <i...@livius.net> wrote: >> well, to summarise, I notified you that in certain conditions, >> due to an non-obvious dependency that does no

Re: [Qemu-devel] segmentation fault in object.c:type_initialize_interface() if interface not defined

> On 03 Apr 2016, at 20:01, Peter Maydell wrote: > > ... This is you changing QEMU to not compile a file that was > previously always compiled. If you do that then it's > not surprising if things might break when you move to an > upstream version, that's all. well, to

Re: [Qemu-devel] segmentation fault in object.c:type_initialize_interface() if interface not defined

> On 03 Apr 2016, at 19:43, Peter Maydell <peter.mayd...@linaro.org> wrote: > > On 3 April 2016 at 16:40, Liviu Ionescu <i...@livius.net> wrote: >> >>> On 03 Apr 2016, at 15:28, Peter Maydell <peter.mayd...@linaro.org> wrote: >> >>>

Re: [Qemu-devel] segmentation fault in object.c:type_initialize_interface() if interface not defined

> On 03 Apr 2016, at 15:28, Peter Maydell wrote: > since hw/arm/boot.o is in obj-y it should always be built, not necessarily, in my build configuration I have if's that exclude most of the files non related to Cortex-M. in previous versions boot.o was not needed.

[Qemu-devel] segmentation fault in object.c:type_initialize_interface() if interface not defined

I just updated GNU ARM Eclipse QEMU to 2.5.1 and initially I had some problems, main() failed quite early, in the first call to `find_default_machine()`. After several debug sessions, I identified the problem to be a null pointer when a referred interface is not defined. In my Cortex-M specific

Re: [Qemu-devel] Call for build instructions for FreeBSD and MacOSX

> On 22 Mar 2016, at 11:18, Alex Bennée wrote: > > ... putting up some > simple instructions for people that are not familiar with these systems. the GNU ARM Eclipse QEMU build procedure is documented at http://gnuarmeclipse.github.io/qemu/build-procedure/

Re: [Qemu-devel] [Qemu-discuss] TCP options ipv4 and ipv6 have no effect

> On 02 Oct 2015, at 21:20, Sair, Umair wrote: > >> On linux it always runs on IPv4 >> and on Windows, it always runs on IPv6. Can you please help me out in >> resolving this problem? I remember I had the same problem when building GNU ARM Eclipse QEMU. You can take a

Re: [Qemu-devel] Compiling Qemu from Cygwin

> On 22 Sep 2015, at 03:00, Mike Ladouceur wrote: > > Sorry, at this point, I've moved to compiling from Ubuntu as you suggested > earlier. another option, suitable for production environments, where repeatability is important, is to use Docker images. you can take

Re: [Qemu-devel] Win32 stdio not working if SDL is enabled

On 14 Aug 2015, at 15:15, Daniel P. Berrange berra...@redhat.com wrote: On Fri, Aug 14, 2015 at 12:14:15PM +0100, Daniel P. Berrange wrote: On Thu, Aug 13, 2015 at 07:48:47PM +0200, Stefan Weil wrote: ... that's a feature of SDL 1.2: stdout and stderr are by default redirected to files

Re: [Qemu-devel] QEMU 2.4 for Windows - current status

On 05 Aug 2015, at 14:03, Stefan Weil s...@weilnetz.de wrote: Fix sigsetjmp for w64 http://repo.or.cz/w/qemu/ar7.git/commit/8fa9c07c9a33174905e67589bea6be3e278712cb I tried to apply your patch to my branch and I got: Running QEMU make install... CCgnuarmeclipse-softmmu/cpu-exec.o

Re: [Qemu-devel] QEMU 2.4 for Windows - current status

On 05 Aug 2015, at 19:56, Paolo Bonzini pbonz...@redhat.com wrote: ... I am not sure why things break for Stefan... I confirm Stefan's conclusion, neither in my configuration adding #include qemu-common.h ... in cpu-exec.c makes any difference. however adding: #if defined(_WIN64) #ifdef

Re: [Qemu-devel] QEMU 2.4 for Windows - current status

On 05 Aug 2015, at 23:30, Stefan Weil s...@weilnetz.de wrote: ... As I already said, this modification is needed for all versions of QEMU, and it will stay unfixed in 2.4.0 which is nearly finished. your patch is already in my branch, and I already publicly released GNU ARM Eclipse QEMU

[Qemu-devel] STM32F407-Discovery led blinking video

as planned, the GNU ARM Eclipse QEMU branch is now fully functional for simple LED blinking applications. the board image is displayed in a SDL window and the LEDs are coloured rectangles shown over the image. a short demo video is available from:

Re: [Qemu-devel] [RFC] CMSIS based Cortex-M MCU definitions

since this reply actually refers to CMSIS, I moved the discussion on the other thread. On 09 Jul 2015, at 05:42, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: On Wed, Jul 8, 2015 at 6:50 PM, Liviu Ionescu i...@livius.net wrote: ... my interest is to generate the entire MCU

Re: [Qemu-devel] [RFC] peripheral/register/bitfield objects - new MCU model

On 08 Jul 2015, at 23:22, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: ... an RFC on list for something very similar, if you want to weigh in or find it useful, let me know! yes, if you are not in a hurry to commit your patches, I guess together we can find a suitable solution.

[Qemu-devel] [RFC] CMSIS based Cortex-M MCU definitions

one interesting consequence of using a peripheral/register/bitfield model is that it allows to partly automate the creation of a new MCU. the natural source for peripheral registers and bitfields are the SVD files, while the natural source for MCU families/subfamilies/devices are the CMSIS

[Qemu-devel] [RFC] peripheral/register/bitfield objects - new MCU model

as anyone who did it knows, describing memory mapped peripherals is tedious. as far as I know, qemu support ends at defining memory regions and implementing the read/write callbacks for all accesses in this region. while implementing several Cortex-M devices (currently STM32F103, F107, F407,

Re: [Qemu-devel] [RFC] peripheral/register/bitfield objects - new MCU model

On 08 Jul 2015, at 23:22, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: I have an RFC on list for something very similar, if you want to weigh in or find it useful, let me know! This is a real problem. https://lists.nongnu.org/archive/html/qemu-devel/2015-04/msg03612.html ok,

Re: [Qemu-devel] [PATCH v2] thread-win32: fix GetThreadContext() permanently fails

sorry for being partly off-topic, but the last time I checked the windows builds, there was a problem on win64, applications using timers (like Cortex-M SysTick) failed. the tests were performed both with my fork and with Stefan's official version, with the same results. I saw there were

Re: [Qemu-devel] reset strategy?

On 29 Jun 2015, at 20:37, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: Are are these two devices really not connected to any bus? in my emulation, these devices are created with object_new() and not connected to the sysbus or to any other bus. how do they work? just fine

Re: [Qemu-devel] reset strategy?

On 29 Jun 2015, at 02:15, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: cpu_reset(CPU(cm_state-cpu)); This should be managed by the bootloader. you mean via 'boot.c: arm_load_kernel()'? I'm not using it, since on Cortex-M there is no kernel to load.

[Qemu-devel] reset strategy?

I migrated most of the qdev_* calls to object_* and device_* calls. however, after I switched from qdev_create() to object_new(), I noticed that without the sysbus, there is no automated mechanism to reset the peripherals attached to the mcu. my solution was to manually propagate the reset to

Re: [Qemu-devel] reset strategy?

On 27 Jun 2015, at 21:03, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: Try this after object creation (see xlnx-zynqmp init fn): qdev_set_parent_bus(DEVICE(s-gic), sysbus_get_default()); ah, sure, I already tried this, if I set the bus, everything works as before. but

Re: [Qemu-devel] [RFC] QDev explicit constructors destructors

On 23 Jun 2015, at 23:10, Liviu Ionescu i...@livius.net wrote: another solution would look like: DeviceState *dev = my_dev_alloc(NULL, TYPE_MYTYPE); my_dev_prop_set_string(dev, param, something); my_dev_realize(dev); my_dev_prop_set_uint32(dev, xyz, 123); which obviously

Re: [Qemu-devel] [RFC] QDev explicit constructors destructors

On 24 Jun 2015, at 11:29, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: Peter C, is this solution acceptable? Settable props are generally acceptable, but it is unusual for a machine init routine. ok, I managed to restructure my code to get rid of the explicit constructor.

Re: [Qemu-devel] [RFC] QDev explicit constructors destructors

On 24 Jun 2015, at 17:18, Andreas Färber afaer...@suse.de wrote: ... our Coding Style. sorry, but I checked both QEMU Coding Style and QEMU Coding Guidelines and could not find any rule forbidding the use of blocks for introducing local scopes. regards, Liviu

Re: [Qemu-devel] [RFC] QDev explicit constructors destructors

On 24 Jun 2015, at 16:50, Andreas Färber afaer...@suse.de wrote: You're still doing the {...} thing I asked you not to do. thank you for your suggestions. right now I'm more concerned on which APIs to use, and my current understanding is that you prefer direct QOM calls over QDev, which

Re: [Qemu-devel] [RFC] QDev explicit constructors destructors

On 24 Jun 2015, at 17:11, Liviu Ionescu i...@livius.net wrote: ... it might very well be C++, with some wrappers ... unfortunately this is not technically feasible, for many reasons, one of them being the 'struct Object' member named 'class' :-( regards, Liviu

Re: [Qemu-devel] [RFC] QDev explicit constructors destructors

On 23 Jun 2015, at 13:39, Andreas Färber afaer...@suse.de wrote: ... that spares indentation. indentation? I'm not doing it manually, I just press a key combination in my Eclipse and indentation is done auto-magically. Please don't add new infrastructure with qdev in the name, qdev was

Re: [Qemu-devel] [RFC] QDev explicit constructors destructors

On 23 Jun 2015, at 17:25, Andreas Färber afaer...@suse.de wrote: ... I honestly don't understand what you're arguing here... Your code examples are not telling. :-( Are you maybe missing that there are dynamic QOM properties in addition to the qdev properties you use in your examples?

Re: [Qemu-devel] [RFC] QDev explicit constructors destructors

On 23 Jun 2015, at 21:31, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: List discussions should be fine, regardless of release cycle phase. I apologise to all those who considered my messages not appropriate for this list or for this moment. ... usually you see these kind of

Re: [Qemu-devel] [RFC] QDev explicit constructors destructors

On 23 Jun 2015, at 23:57, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: Give it a go and let me know where it gets stuck. I sent you a Skype invitation, but apparently it did not pass through. could you try from your side (my id is 'ilg-ul'). regards, Liviu

Re: [Qemu-devel] [RFC] QDev explicit constructors destructors

On 23 Jun 2015, at 21:31, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: I will review it on list and see if I can think of alternate construction sequence. I suggest your review should start from use cases like this: DeviceState *dev = my_dev_alloc(NULL, TYPE_MYTYPE);

Re: [Qemu-devel] [RFC] QDev explicit constructors destructors

On 23 Jun 2015, at 10:47, Markus Armbruster arm...@redhat.com wrote: Copying Andreas. Hallo Andreas! Liviu

Re: [Qemu-devel] [RFC] QDev explicit constructors destructors

after some more experimenting, here are the conclusions: - I added a new .construct pointer to all my classes: void (*construct)(Object *obj, void *data); the 'data' pointer is optional, for qdev calls, parameters should be passed via properties. - constructors should manually call their

Re: [Qemu-devel] [PATCH] target-arm: default empty semihosting cmdline

Peter, it looks like I forgot to Cc: you for this patch: On 21 Jun 2015, at 10:24, Liviu Ionescu i...@livius.net wrote: If neither explicit semihosting args nor -kernel are used, make SYS_GET_CMDLINE return an empty string. Signed-off-by: Liviu Ionescu i...@livius.net --- target-arm

Re: [Qemu-devel] [RFC] Cortex-M different revisions

On 21 Jun 2015, at 17:09, Peter Maydell peter.mayd...@linaro.org wrote: Non-buggy guest code should not care whether it is running on an r2p1 or an r2p0, probably not, but code developed on an emulated r2 might very well break on a physical r0. I think these should probably be cpu

Re: [Qemu-devel] [RFC] Cortex-M different revisions

On 21 Jun 2015, at 23:58, Peter Maydell peter.mayd...@linaro.org wrote: There's lots of code that will run on QEMU but break on real hardware. no doubt about it. however, this shouldn't be the rule, if the efforts are reasonable, I see no reasons for not improving the emulation quality

[Qemu-devel] [PATCH] target-arm: default empty semihosting cmdline

If neither explicit semihosting args nor -kernel are used, make SYS_GET_CMDLINE return an empty string. Signed-off-by: Liviu Ionescu i...@livius.net --- target-arm/arm-semi.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/target-arm/arm-semi.c b/target-arm/arm

[Qemu-devel] [RFC] Cortex-M different revisions

while studying the details of cortex-m cores, I ran into the many differences between existing revisions, especially for cortex-m3, which are numerous and some significative, like stack alignment. for example for m3, the changes from r0p0 to r1p0/r1p1 are one full page of details, like

Re: [Qemu-devel] [PATCH v5 0/2] semihosting: clean up and add --semihosting-config arg

On 20 Jun 2015, at 23:19, Peter Maydell peter.mayd...@linaro.org wrote: For ARM, that's an empty command string. this is too complicated, and currently not documented. the natural method to specify that there are no args is... to add no args to the command line. Does arg='' work in the

Re: [Qemu-devel] [PATCH v5 0/2] semihosting: clean up and add --semihosting-config arg

On 19 Jun 2015, at 00:43, Peter Maydell peter.mayd...@linaro.org wrote: On 18 June 2015 at 17:00, Leon Alrae leon.al...@imgtec.com wrote: Just a rebase of v4 as there were changes in qemu_opt_foreach API. Regards, Leon Thanks; applied to target-arm.next. I merged target-arm.next to

Re: [Qemu-devel] [PATCH v5 0/2] semihosting: clean up and add --semihosting-config arg

On 20 Jun 2015, at 22:49, Peter Maydell peter.mayd...@linaro.org wrote: as you can see, it tries to use the kernel name as command line, which exceeds the application small buffer size. It only does that if you didn't specify the arguments the new way (at least that is the intention).

[Qemu-devel] [RFC] add --image command line for use with non-linux machines

Due to the problems that I recently faced with the semihosting patches, that impair functionality for maintaining compatibility with existing linux machines, I added the following to my GNU ARM Eclipse branch: - DEFHEADING(Microcontroller/Cortex-M specific:)

Re: [Qemu-devel] [RFC] add --image command line for use with non-linux machines

On 21 Jun 2015, at 00:53, Peter Maydell peter.mayd...@linaro.org wrote: I do think we should improve our handling of image file loading. If we want ELF image loading we need to support it on *all* boards and *all* CPU architectures. and how do you suggest to proceed? what would be

Re: [Qemu-devel] How to trigger faults for missing peripherals?

On 18 Jun 2015, at 13:21, Peter Maydell peter.mayd...@linaro.org wrote: ... do_unassigned_access is the QOM CPUClass hook for this, this hook seems associated with the Trying to execute code outside RAM or ROM at 0x error, which is a bit different, I want to catch read/write accesses, not

[Qemu-devel] How to trigger faults for missing peripherals?

In order to make the Cortex-M emulation accurate, I would need to configure the missing address ranges to trigger memory faults. I noticed that the emulator defines a memory range to cover the entire 64-bits memory space. Is it possible to make it trigger exceptions? If not, what would be the

[Qemu-devel] [RFC] STM32 MCUs support

. + * + * Copyright (c) 2014 Liviu Ionescu + * Copyright (c) 2010 Andre Beckus + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation, either version 2 of the License

[Qemu-devel] String properties defaults must be dynamically allocated

I don't know if this is a bug or a feature (to me it looks like a bug), but if the string pointer associated with a string property is initialised during inits with a pointer to a static string, the next qdev_prop_set_string() will fail attempting to free the static object. the workaround is

Re: [Qemu-devel] [RFC] generic-gpio-led stm32-gpio-led

On 17 Jun 2015, at 03:25, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: ... connecting a gpio_out to a gpio_in seems not possible, gpio_in irqs are parented to the device and parenting them to the gpio_out fail with the parent != 0 assertion. This should work. Can I see

Re: [Qemu-devel] [RFCv2] generic-gpio-led

. + * + * Copyright (c) 2015 Liviu Ionescu + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation, either version 2 of the License, or + * (at your option) any later version

[Qemu-devel] [RFC] generic-gpio-led stm32-gpio-led

/include/hw/display/generic-gpio-led.h @@ -0,0 +1,96 @@ +/* + * Generic GPIO connected LED device emulation. + * + * Copyright (c) 2015 Liviu Ionescu + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published

Re: [Qemu-devel] [PATCH v4 2/2] semihosting: add --semihosting-config arg sub-argument

would it be possible to have all the semihosting patches ready for 2.4? regards, Liviu

Re: [Qemu-devel] [PATCH V3] Target-arm: Add the Cortex-M4 CPU

On 16 Jun 2015, at 14:21, Peter Maydell peter.mayd...@linaro.org wrote: ... I think we can get this into QEMU for 2.4. that would be really great, I have quite a lot of M4 MCUs in my Cortex-M branch. Liviu

Re: [Qemu-devel] [RFC] generic-gpio-led stm32-gpio-led

On 16 Jun 2015, at 19:10, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: +bool use_stderr; Why do you want to switch between stderr and stdout? I wasn't sure which one is more appropriate, I first used stdout then tried stderr. I think stderr is more correct, yes, that

Re: [Qemu-devel] [RFC] generic-gpio-led stm32-gpio-led

On 16 Jun 2015, at 19:10, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: ... In my proposal the machine model would do this. qdev_connect_gpio_out_named(mcu, name, index, qdev_get_gpio_in(gpio_dev, 0)); Or something like that. connecting a gpio_out to a gpio_in seems not

Re: [Qemu-devel] [RFC] generic-gpio-led stm32-gpio-led

On 16 Jun 2015, at 21:19, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: Your autoformatter does a surprisingly good job of getting close to qemu coding style. Can the rules just be tweaked any maybe QEMU coding style can be added to eclipse? this is exactly what I did, I took the

[Qemu-devel] [RFC] QDev explicit constructors destructors

The .instance_init construction method available in the current QOM provides an equivalent of the C++ default constructor, that works just fine as long as there is no need to pass additional data to the construction logic. One natural solution would be to add an explicit constructor, like in

Re: [Qemu-devel] [RFC] QDev explicit constructors destructors

On 15 Jun 2015, at 13:48, Liviu Ionescu i...@livius.net wrote: ... add an explicit constructor, like in C++. ... the DeviceClass structure ... qdev_construct() ... For more generality, the new construct/destruct pointers can be added directly to the QOM ObjectClass, and the functions

<    1   2   3   4   5   >