Re: /util/cpuinfo-aarch64.c:58:22: error: 'HWCAP_USCAT' undeclared

> On 1 Apr 2024, at 23:04, Marcin Juszkiewicz > wrote: > > So ask Ubuntu Pro team for support? I did not ask for support, I just notified the community of an issue I encountered while building the latest sources, driven by a sincere desire to improve the project. If this bothered you, I

Re: /util/cpuinfo-aarch64.c:58:22: error: 'HWCAP_USCAT' undeclared

> On 1 Apr 2024, at 21:48, Richard Henderson > wrote: > > You were told back in September that Ubuntu 18.04 is no longer supported. Sorry, I missed that. BTW, according to ubuntu.com: "With Ubuntu Pro, the 18.04 LTS will be fully supported until 2028.". Regards, Liviu

Re: /util/cpuinfo-aarch64.c:58:22: error: 'HWCAP_USCAT' undeclared

same behaviour for 8.2.2; same workaround. > On 2 Sep 2023, at 21:11, Liviu Ionescu wrote: > > When trying to build 8.1.0 on an Ubuntu 18.04 aarch64, I get the above error. > > The offending code in `/util/cpuinfo-aarch64.c` is: > > ```c > #ifdef CONFIG_LINUX

Re: Error: .seh_endproc used in segment '.text' instead of expected '.text$qemu_close_socket_osfhandle'

> On 2 Sep 2023, at 21:43, Liviu Ionescu wrote: > > ... With the same build scripts, compiling QEMU 7.1.0 was ok, the problem was > introduced in the last year. I also tried 7.2.5, and it passed the build, with the same scripts and the same toolchain, so the problem seems to

Error: .seh_endproc used in segment '.text' instead of expected '.text$qemu_close_socket_osfhandle'

When compiling 8.1.0 for Windows (with mingw-w64-gcc on Linux), I got the following error: ``` [634/1917] Compiling C object libqemuutil.a.p/util_oslib-win32.c.obj FAILED: libqemuutil.a.p/util_oslib-win32.c.obj

/util/cpuinfo-aarch64.c:58:22: error: 'HWCAP_USCAT' undeclared

When trying to build 8.1.0 on an Ubuntu 18.04 aarch64, I get the above error. The offending code in `/util/cpuinfo-aarch64.c` is: ```c #ifdef CONFIG_LINUX unsigned long hwcap = qemu_getauxval(AT_HWCAP); info |= (hwcap & HWCAP_ATOMICS ? CPUINFO_LSE : 0); info |= (hwcap & HWCAP_USCAT ?

Re: Peter Maydell

> On 28 Mar 2023, at 12:38, cavin narsinghani > wrote: > >  > Yes, I agree. That statement was from Nov 2020. I would say that things got significantly better in the last few years. ;-) Liviu

Re: [PATCH] Revert "docs/about/deprecated: Deprecate 32-bit arm hosts for system emulation"

> On 17 Mar 2023, at 18:55, Thomas Huth wrote: > > This reverts commit 1d0a8eba38c028ea02c6e0b68f0a4c9a3cbf... Thank you, Thomas! Liviu

Re: dropping 32-bit host support

> On 16 Mar 2023, at 10:36, Thomas Huth wrote: > > ... It will take another year (or maybe more) until the deprecation will turn > into a real unsupported state. I assume by that point in time, more and more > RPi users will have switched to a 64-bit OS instead. There is an easy and

Re: dropping 32-bit host support

> On 16 Mar 2023, at 09:57, Liviu Ionescu wrote: > > I'm not targeting RPi2; there are a lot of RPi4 with less than 8GB RAM (most > of them, actually), and even more RPi3, with even less RAM), and people > prefer to continue using the 32-bit OS on them, which works qu

Re: dropping 32-bit host support

> On 16 Mar 2023, at 09:29, Philippe Mathieu-Daudé wrote: > > Hi Liviu, > >> or the countless 32-bit Raspberry Pi? >> my xPack binary tools, which include qemu arm & qemu riscv, are also >> available for arm 32-bit, and the analytics show about the same number of >> downloads for 32-bit as

Re: TARGET_SYS_HEAPINFO and Cortex-A15 memory map

> On 26 Jul 2022, at 13:56, Peter Maydell wrote: > > ... If you're able to figure out what your original failing binary > setup was and repro the problem again, please send me the executable. Thank you for investigating. I'll try to revert my projects to running from flash, and, if still

Re: TARGET_SYS_HEAPINFO and Cortex-A15 memory map

> On 25 Jul 2022, at 20:33, Peter Maydell wrote: > > ... I'll try a setup with code in flash and > data in RAM, that sounds like it might be a way to cause the > problem if there's not much code and a lot of data (because > then the remaining space in the flash is larger than the > remaining

Re: TARGET_SYS_HEAPINFO and Cortex-A15 memory map

> On 25 Jul 2022, at 19:02, Peter Maydell wrote: > > > We document what the guest can assume about the virt board > memory layout here: > > https://www.qemu.org/docs/master/system/arm/virt.html#hardware-configuration-information-for-bare-metal-programming > > Flash at 0, RAM at

Re: TARGET_SYS_HEAPINFO and Cortex-A15 memory map

> On 25 Jul 2022, at 18:43, Peter Maydell wrote: > > ... the memory map for the 'virt' board doesn't change for the a72 > versus the a15. In both cases, the memory from 0x0 to 0x0800 > is the flash memory. So QEMU is incorrect to have reported that as > the place to put the heap in

Re: TARGET_SYS_HEAPINFO and Cortex-A15 memory map

> On 2 Jun 2022, at 21:36, Liviu Ionescu wrote: > > ... SYS_HEAPINFO... > > 0x0400 - heap base > 0x0800 - heap limit > 0x0800 - stack base > 0x0 - stack limit For Cortex-A72 I see similar values: 0x4400 0x4800 0x4800 0x4000 just that

TARGET_SYS_HEAPINFO and Cortex-A15 memory map

I'm experiencing some issues with the startup code for an emulated Cortex-a15 machine I plan to use for running unit-tests. I'm starting QEMU with: .../qemu-system-arm "--machine" "virt" "--cpu" "cortex-a15" "--nographic" "-d" "unimp,guest_errors" "--semihosting-config"

Re: AArch64 semihosting?

> On 26 May 2022, at 14:08, Peter Maydell wrote: > I confirm that, started via "-kernel aarch64-boot-libgloss.elf", with a single "--semihosting-config", the app ran properly, displayed the printf() output and no longer crashed. ``` ilg@wksi ~ %

Re: AArch64 semihosting?

> On 26 May 2022, at 13:01, Peter Maydell wrote: > > Yes, I can reproduce this. Ok, it seems you diagnosed it pretty quickly, great! > Did you intend to pass '-s' (allow gdbstub connection) but not > '-S' (wait on startup for gdb to connect and say "continue"), > by the way? Oops! I forgot

Re: AArch64 semihosting?

> On 26 May 2022, at 11:20, Peter Maydell wrote: > > QEMU also shares code for those two architectures' semihosting > implementation. Then it seems to be a difference between Arm 64-bit and Arm 32-bit (which is fine). After fixing the AArch64 tests I'll get to RISC-V, which should run the

Re: AArch64 semihosting?

> On 26 May 2022, at 11:20, Peter Maydell wrote: > > ... can you provide us with > a reproduce case (eg the binary you used here)? Sure. I'll try to attach it to this message, it is only 64K. The command I used to run the test is in the previous message. Please confirm that you get the

AArch64 semihosting?

I'm trying to set-up an environment for running unit-tests on AArch64, and I'm constantly getting crashes: ``` ilg@wksi ~ % /Users/ilg/Library/xPacks/@xpack-dev-tools/qemu-arm/6.2.0-1.1/.content/bin/qemu-system-aarch64 "--machine" "virt" "--cpu" "cortex-a57" "--kernel" "/Users/ilg/My

Re: [PATCH] Add --with-branding-prefix and QEMU_BRANDING_PREFIX

> On 14 Feb 2022, at 14:28, Daniel P. Berrangé wrote: > > In a .git checkout, pkgversion defaults to "git describe --match 'v*' --dirty" > See scripts/qemu-version.sh I see. I would say that this is a different use case. Thank you, Liviu

Re: [PATCH] Add --with-branding-prefix and QEMU_BRANDING_PREFIX

> On 14 Feb 2022, at 14:06, Peter Maydell wrote: > > ... but the "v6.2.0-1-xpack-arm" pkgversion suffix works for this > purpose too. Currently I do not use any --pkgversion in my builds, so I guess that this is automatically generated by the meson script, and reflects the name of a custom

Re: [PATCH] Add --with-branding-prefix and QEMU_BRANDING_PREFIX

> On 8 Feb 2022, at 21:58, Peter Maydell wrote: > > I've cc'd some people who might have an opinion on whether this > something we want to add upstream. ... Well, given the comments received, it is obvious that we have different use cases, and, in my opinion, a one-size-fits-all approach

Re: [PATCH] Add --with-branding-prefix and QEMU_BRANDING_PREFIX

> On 9 Feb 2022, at 13:30, Peter Maydell wrote: > > gcc doesn't prepend the pkgversion string to the greeting. ... > ... and 'gcc --version' prints the version as: > gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 Right, strictly speaking, GCC prints the program name, then the greeting message,

Re: [PATCH] Add --with-branding-prefix and QEMU_BRANDING_PREFIX

> On 9 Feb 2022, at 11:57, Stefan Hajnoczi wrote: > > > Is the existing ./configure --with-pkgversion= option not enough? My understanding of --with-pkgversion=, based on the fact that in QEMU this string is appended to the version, was that it is a suffix that describes a specific

Re: [PATCH] Add --with-branding-prefix and QEMU_BRANDING_PREFIX

> On 8 Feb 2022, at 21:58, Peter Maydell wrote: > > I've cc'd some people who might have an opinion on whether this > something we want to add upstream. (Patch/thread below for context.) Sure. For a better understanding of the reason why I found this useful: I use QEMU extensively in CI

Re: [PATCH] Add --with-branding-prefix and QEMU_BRANDING_PREFIX

The 4th attempt... Not that this would be a significant patch, but I would like to proceed with other improvements. Thank you, Liviu > On 27 Jan 2022, at 14:23, Liviu Ionescu wrote: > > Any chance for someone to take a look at this proposal? > > Thank you, > > Liv

Re: [PATCH] Add --with-branding-prefix and QEMU_BRANDING_PREFIX

Any chance for someone to take a look at this proposal? Thank you, Liviu > On 20 Jan 2022, at 13:35, Liviu Ionescu wrote: > > It is usual for various distributions to identify themselves by > prepending a string to the greeting message, for example > 'xPack QEMU emulato

[PATCH] Add --with-branding-prefix and QEMU_BRANDING_PREFIX

It is usual for various distributions to identify themselves by prepending a string to the greeting message, for example 'xPack QEMU emulator version 6.2.0 (v6.2.0-2-xpack-arm)'. To achieve this, a new configuration option (--with-branding-prefix=) was added, which, if not empty, adds a string

Re: [PATCH] Add --with-branding-prefix and QEMU_BRANDING_PREFIX

> On 20 Jan 2022, at 13:35, Liviu Ionescu wrote: > > It is usual for various distributions to identify themselves by > prepending a string to the greeting message, for example > 'xPack QEMU emulator version 6.2.0 (v6.2.0-2-xpack-arm)'. > > To achieve this, a new

Re: ui/cocoa.m compile error (Cocoa -> SDL)

> On 17 Jan 2022, at 18:19, Philippe Mathieu-Daudé wrote: > > The consensus was UI should not be addressed within QEMU itself, but > via an external helper, eventually using D-Bus. D-Bus support has been > recently merged: > https://www.qemu.org/docs/master/interop/dbus.html Thank you for

Re: ui/cocoa.m compile error (Cocoa -> SDL)

> On 17 Jan 2022, at 15:30, Liviu Ionescu wrote: > > I will try to rebuild using --with-cocoa on newer systems, to validate the > rest of the build. I confirm that after reverting to --with-cocoa, both Intel and Apple Silicon builds are able to emulate Thomas' vexpress-a9 proje

Re: ui/cocoa.m compile error (Cocoa -> SDL)

> On 17 Jan 2022, at 16:06, Peter Maydell wrote: > > This is newer versions of macOS being stricter about enforcing that > some operations are only permitted on the correct thread. Older versions > let QEMU/SDL get away with doing them on the "wrong" thread, which > all happened to work. Ah,

Re: ui/cocoa.m compile error (Cocoa -> SDL)

> On 17 Jan 2022, at 14:51, Liviu Ionescu wrote: > > it crashes with ... I can try to investigate, perhaps it is only a small > mistake somewhere. I did some new tests, and I confirm that on a macOS 11.6 running on a MacMini 2020 M1 it throws the exception, as shown before,

Re: ui/cocoa.m compile error (Cocoa -> SDL)

> On 17 Jan 2022, at 13:35, Peter Maydell wrote: > > (2) the "use SDL" option seems to have worked for at least > some people in the past: SDL worked nicely for me too in the past, qemu-system-gnuarmeclipse was configured with SDL for all platforms and it worked unchanged in the last 4-5

Re: ui/cocoa.m compile error (Cocoa -> SDL)

> On 17 Jan 2022, at 13:35, Peter Maydell wrote: > > ... the macOS host support in QEMU is not very well > maintained, so the default is "it doesn't change" BTW, my main development platform is macOS, both Intel and Apple Silicon, so if someone is willing to improve macOS host support in

Re: ui/cocoa.m compile error (Cocoa -> SDL)

> On 17 Jan 2022, at 11:41, Thomas Huth wrote: > > On 10/01/2022 11.33, Liviu Ionescu wrote: >> I now have successful builds on all platforms, including on macOS 11 with >> Apple Silicon and macOS 10.13 with Intel, but I had to disable Cocoa >> supp

Re: /usr/shared/qemu binaries

> On 13 Jan 2022, at 19:13, Paolo Bonzini wrote: > > There must be lots of zeros in there. I confirm, when compressed, those files get significantly smaller. > Maybe we should tell QEMU to unpack firmware .gz or .lzo files? That would be great. I think `.gz` files are easier to create.

Re: /usr/shared/qemu binaries

> On 12 Jan 2022, at 15:56, Peter Maydell wrote: > > Those are UEFI firmware images which are suitable for using with > the arm/aarch64 "virt" board. Then it would probably be useful to keep them. For the xPack QEMU Arm package, I ended up with the following script: ``` cd

Re: /usr/shared/qemu binaries

> On 11 Jan 2022, at 00:55, Alistair Francis wrote: > > I would expect them to just be referred to by QEMU internally. I checked and there are indeed several files referred internally. > My guess would be keep *arm*/*aarch64*, keymaps, npcm7xx_bootrom.bin, > efi-* and linuxboot*/multiboot*.

Re: /usr/shared/qemu binaries

> On 11 Jan 2022, at 00:55, Alistair Francis wrote: > > they are referred to internally, Ok, so things are a bit more complicated than I hoped. I'll search for the names in the source code, and keep those referred internally. Thank you, Liviu

Re: /usr/shared/qemu binaries

> On 10 Jan 2022, at 14:10, Alistair Francis wrote: > > My guess would be keep *arm*/*aarch64*, keymaps, npcm7xx_bootrom.bin, > efi-* and linuxboot*/multiboot*. That should ensure that everything > works for you, but I'm just guessing here. Do you know if those files are referred internally

Re: ui/cocoa.m compile error

> On 10 Jan 2022, at 12:44, Peter Maydell wrote: > > ... On Linux this tends to take the form > of dropping support for older versions of various dependencies > and compilers. My build environment uses modern tools (like GCC 11, etc), but compiled from sources on an older Linux release.

Re: ui/cocoa.m compile error (Cocoa -> SDL)

I now have successful builds on all platforms, including on macOS 11 with Apple Silicon and macOS 10.13 with Intel, but I had to disable Cocoa support, and enable SDL support. The resulting binaries (qemu-system-arm/aarch64/riscv32/riscv64) start, but I could not tell if the lack of Cocoa in

/usr/shared/qemu binaries

I successfully built two QEMU 6.2 binary packages, one with Arm and one with RISC-V, each with standalone variants for Linux Intel, Linux Arm, Windows Intel, macOS Intel and macOS Arm. Each package includes only the relevant executables (qemu-system-arm/aarch64 and respectively

Re: ui/cocoa.m compile error

> On 8 Jan 2022, at 00:16, Peter Maydell wrote: > > ... In this > specific case, NSPasteboardTypeOwner seems to be part of > an API introduced in 10.14 (Mojave). Thank you for the details, this explains the error. > So the upstream answer, I'm afraid, is that you should > upgrade to a newer

ui/cocoa.m compile error

Hi, I'm building 6.2.0 on macOS, and on a recent macOS 11.6 with Apple Silicon the build passes, but on a slightly older macOS 10.13, which is my base platform for Intel macOS builds, compiling ui/cocoa.m fails: ``` ../../sources/qemu-6.2.0.git/ui/cocoa.m:1766:52: error: unknown type name

Re: Mac OS - Standalone Installer

On Thu, 15 Apr 2021 at 01:16, Richard Hill wrote: > > ... a standalone installer for QEMU for Mac OS? > The xPack QEMU Arm is distributed as standalone archives, for all platforms, including macOS: https://github.com/xpack-dev-tools/qemu-arm-xpack/releases They do not even require install,

Re: Malfunctionning qemu-system-arm ?

> On 9 Mar 2021, at 17:58, vincent Dupaquis > wrote: > > Thanks for the responses, I'll have a check on this. It is based on a bit old version of QEMU, but it is fully functional for the peripherals used by the CubeMX initialisations. I use it to run unit-tests, as semihosted

Re: Malfunctionning qemu-system-arm ?

> On 15 Feb 2021, at 17:09, vincent Dupaquis > wrote: > > ... stuck on the starting HAL_init() call. HAL requires, amongst other things, the clock registers, since it sets the PLLs for the desired frequencies. xPack QEMU Arm [1] implements these registers, and is able to properly run the

Re: A brief look at deprecating our JSON extensions over RFC 8259

On Mon, 22 Feb 2021 at 17:27, Daniel P. Berrangé wrote: > > IMHO we should deprecate and eventually remove single quotes +1 If a JSON cannot be directly processed by the standard JavaScript parser, it should not be used. Regards, Liviu -- Sent from my iPad via Gmail.

Re: About creating machines on the command line

> On 14 Jan 2021, at 12:56, Luc Michel wrote: > > ... But yes the goal here is to rely on QEMU's already existing device models > to dynamically create a machine. I did not check the current QEMU device models, so I might be wrong, but I think that the scope might be slightly different.

Re: About creating machines on the command line

I know it does not answer your question directly, but you might find useful to take a look at the solution used in the xPack QEMU Arm (formerly GNU ARM Eclipse QEMU). In this fork I dynamically create the peripheral registers when QEMU starts, by reading a JSON file, converted from the CMSIS

Re: Peter Maydell

> On 20 Nov 2020, at 10:54, Paolo Bonzini wrote: > > new m1 ... Richard Henderson and Joelle van Dyne are working on it Ok, it's good to know that someone takes care of this. Personally I think that the new Apple hardware is great, but to match developer needs it might need a few more

Re: Peter Maydell

> On 20 Nov 2020, at 07:43, cavinnarsingh...@gmail.com wrote: > > This issue is about the Qemu > Will the Qemu work on the new m1 macbook pro? > And if yes, when will the arm version of Qemu be available for public I already distribute a binary version of the xPack QEMU Arm fork which runs

Re: [RFC] QEMU as Xcode project on macOS

> On 10 Sep 2020, at 13:45, Daniel P. Berrangé wrote: > > AFAICT both MacPorts and HomeBrew can be installed into custom locations, > at least if you do a "from source" install of them, rather than using the > pre-built packages. Yes, I use this for HomeBrew, but generally you cannot select

Re: [RFC] QEMU as Xcode project on macOS

> On 10 Sep 2020, at 13:14, Christian Schoenebeck > wrote: > > The way to go for devs on Mac is: 3rd party libs should not be installed into > global space, rather be built & linked either as dynamic frameworks > (including > assets) or as static libs. Then apps always run with the

Re: [RFC] QEMU as Xcode project on macOS

> On 10 Sep 2020, at 12:20, Paolo Bonzini wrote: > > --python=/path/to/python3 --meson=internal > > and the build will automatically use that same Python executable to run > the scripts. Ok, good to know. My standalone meson is intended for integration into Eclipse and Visual Studio

Re: [RFC] QEMU as Xcode project on macOS

> On 9 Sep 2020, at 22:16, Peter Maydell wrote: > > ... You still need a Python 3.5 or better for the other scripts > QEMU has as part of its build process, so you will still > need a python other than the Apple /usr/bin/python to build > even if you have a standalone meson with its own

Re: [RFC] QEMU as Xcode project on macOS

> On 9 Sep 2020, at 21:56, Christian Schoenebeck wrote: > > ... However you would > still be opted out from (4.) all those Xcode IDE features that make > development such efficient. Could you elaborate? I thought that a standalone meson can be used with any environment, it just reduces

Re: [RFC] QEMU as Xcode project on macOS

> On 9 Sep 2020, at 20:32, Christian Schoenebeck wrote: > > And being forced to use Meson > on Mac with all its Python dependencies does not make it easier. FYI, I'm working on a cross-platform standalone meson package, a .tar.gz that you can install in any location and includes the python

Re: [RFC] QEMU as Xcode project on macOS

> On 9 Sep 2020, at 16:30, Peter Maydell wrote: > > My experience with homebrew has been pretty good overall. Homebrew is fine for use cases that don't mind it is a rolling distribution. :-( For complex builds it is safer to lock the environment to certain known to work versions, and

Re: instance_init() and the realize() functions

> On 18 Jul 2020, at 12:43, Peter Maydell wrote: > > Note that for a lot > of device state struct members (where they correspond to guest > registers state), you want to set their values in the > device's reset method, not in instance_init or realize. > That's because the guest-visible

Re: instance_init() and the realize() functions

> On 18 Jul 2020, at 10:09, Pratik Parvati wrote: > > The class_init() function is straight forward (it is similar to the > constructor in C++ OOP The C++ constructor initialises class **instances**, i.e. C++ objects, not C++ classes. In QEMU, the OOP functionality is implemented with

Re: Separate notifications from list messages?

> On 10 Jul 2020, at 14:43, Thomas Huth wrote: > > ... The Gitlab messages that you > can see currently on the list are from the main repository, not from a > contributor's private repo! I don't know why we should worry about contributor's private repos, but anyway, the GitLab workflow

Re: Separate notifications from list messages?

> On 10 Jul 2020, at 11:54, Daniel P. Berrangé wrote: > > This wasn't a mistake - it was very delibrate, precisely so that all > involved in QEMU development will see the failures, instead of expecting > a handful of people to take all the work of dealing with failures. In > general anyone

Re: Separate notifications from list messages?

> On 10 Jul 2020, at 11:49, Daniel P. Berrangé wrote: > > This was an explicit configuration choice to make the CI failure reports > appear on the list, rather than expecting one or two people to be > responsible for watching the CI. I'm not familiar with your workflow, it might be so, but

Re: Separate notifications from list messages?

> On 10 Jul 2020, at 11:43, Philippe Mathieu-Daudé wrote: > > On 7/10/20 10:32 AM, Peter Maydell wrote: >> On Fri, 10 Jul 2020 at 09:25, Liviu Ionescu wrote: >>>> On 10 Jul 2020, at 11:09, Peter Maydell wrote: >>>> >>>> What sort of not

Re: Separate notifications from list messages?

> On 10 Jul 2020, at 11:32, Peter Maydell wrote: > > ... Do we expect any other > kinds to appear as we make more use of gitlab? I have zero experience with gitlab, but on github yes, most project activity can trigger notifications. this is not a problem in itself. the problem is that,

Re: Separate notifications from list messages?

> On 10 Jul 2020, at 11:09, Peter Maydell wrote: > > What sort of notifications are we talking about here ? For example: ... Received: from mg.gitlab.com (74.90.74.34.bc.googleusercontent.com [34.74.90.74]) by smtp-out-n18.prod.us-west-2.postgun.com with SMTP id 5f074fb9a33b1a3dd4571072

Re: Separate notifications from list messages?

> On 10 Jul 2020, at 07:19, Thomas Huth wrote: > > ... creating a qemu-notify mailing list for notification e-mails? In GitHub it is possible to 'Watch' projects, and when doing so, you get various notifications. Isn't something similar available in GitLab too? Liviu

Separate notifications from list messages?

Now, with the migration to GitLab under way, could you consider separating the notifications sent by GitLab from the messages exchanged on the list? I mean allowing those interested in receiving the notifications to explicitly subscribe to them, and no longer sending all of them to the full

Re: deprecation of in-tree builds

> On 31 Mar 2020, at 15:07, Kevin Wolf wrote: > > Thanks for declaring my workflow irrelevant, I guess... Sorry if this happened, it was not intended. The intention was to point out that there are also other use cases of running the QEMU builds, different from those specific to building

Re: deprecation of in-tree builds

> On 31 Mar 2020, at 13:19, Peter Maydell wrote: > > > ... the behaviour > if they're run from some other (manually created) build directory > would remain as it is today. Great! Then for now a strongly worded warning displayed at the end of the build (to be clearly visible) should do it,

Re: deprecation of in-tree builds

> On 31 Mar 2020, at 10:48, Paolo Bonzini wrote: > > On 30/03/20 16:37, Kevin Wolf wrote: >> If manually dealing with separate build directories is inconvenient >> today, It may be for some, but it isn't for all, perhaps we should not generalise and get the wrong conclusions. In the xPack

Re: Semihosting, arm, riscv, ppc and common code

> On 16 Jan 2020, at 04:04, Benjamin Herrenschmidt > wrote: > > ... I agree, which is also why I want to use the same interface for > powerpc, it will simply make life easier for everybody. I don't know the current implementation in QEMU, but I suggest you also take a look at the current

Re: Semihosting, arm, riscv, ppc and common code

> On 15 Jan 2020, at 23:28, Richard Henderson > wrote: > > For risc-v, the odd nop-full semi-hosting call sequence That unfortunate call sequence was the least worst compromise that the RISC-V design team could agree on. :-( The actual problem was that the RISC-V instruction set has a

Re: Semihosting, arm, riscv, ppc and common code

> On 15 Jan 2020, at 14:01, Alex Bennée wrote: > > ... AFAIK the main users of arm linux user > are compiler test cases for M-profile CPUs. I confirm, generally unit tests. But not necessarily, I used QEMU as the main development platform for the Cortex-M port of µOS++, a C/C++

Re: Semihosting, arm, riscv, ppc and common code

> On 14 Jan 2020, at 08:25, Benjamin Herrenschmidt > wrote: > > I noticed that the bulk of arm-semi.c (or riscv-semi.c) is trivially > made completely generic by doing a couple of changes: Last year I did a similar exercise in OpenOCD, where I took the Arm semihosting code from the Arm

Re: [Qemu-devel] Naming convention for file names

> On 12 Mar 2019, at 16:09, Eric Blake wrote: > > I personally prefer - over _ +1

Re: [Qemu-devel] converting build system to Meson?

> On 7 Mar 2019, at 20:18, Peter Maydell wrote: > > On Thu, 7 Mar 2019 at 18:17, Marc-André Lureau >> ... deprecate ... in-srcdir > > Do we need to bother to deprecate it? It doesn't affect end-users, > only those who build QEMU, and the change is easy... no problems for the GNU MCU Eclipse

Re: [Qemu-devel] Is there a way to package QEMU binaries?

On 12 June 2018 at 10:44:09, Peter Xu (pet...@redhat.com) wrote: > But it'll still be good if we can have a single package to play around > with. If there is no known way to do, we can try to figure a way out. you can take a look at: https://github.com/gnu-mcu-eclipse/qemu-build the scripts

Re: [Qemu-devel] Cortex M0 emulation tasks

On 7 June 2018 at 13:36:30, Stefan Hajnoczi (stefa...@gmail.com) wrote: > If you do want to upstream the code you linked, please let us know > the > details of how you want to do it and how long it might take. Maybe > there is a way to work together on it... yes, I considered this, but I do not

Re: [Qemu-devel] Cortex M0 emulation tasks

On 4 June 2018 at 14:10:08, Stefan Hajnoczi (stefa...@gmail.com) wrote: > What is the status of the Cortex M0 in that source tree? Is it complete? all supported Cortex-M devices run blinky demos using the official CMSIS initialisations, but I would not qualify them as complete. they also

Re: [Qemu-devel] Cortex M0 emulation tasks

On 2 June 2018 at 17:15:15, Stefan Hajnoczi (stefa...@gmail.com) wrote: > > I have put together a basic Cortex M0 ARMv6-M CPU that can serve > as > the basis for this work. Please see the RFC patches that I've sent > separately. you can also take a look at the Cortex-M implementation in the GNU

Re: [Qemu-devel] release retrospective, next release timing, numbering

On 2 May 2018 at 11:13:49, Thomas Huth (th...@redhat.com) wrote: > https://qemu.weilnetz.de/doc/qemu-doc.html#Deprecated-features Thank you, Thomas. > It took quite a while to get a consensus on that policy, so I don't > think that we want to sacrifice that for semver. ok, this might be a

Re: [Qemu-devel] release retrospective, next release timing, numbering

On 2 May 2018 at 10:59:07, Daniel P. Berrangé (berra...@redhat.com) wrote: > Our deprecation policy lets us include incompatible > changes in *any* release. can you elaborate on this? where is this policy defined? thank you, Liviu

Re: [Qemu-devel] release retrospective, next release timing, numbering

On 2 May 2018 at 10:38:09, Cornelia Huck (coh...@redhat.com) wrote: > > > >> a) Bump major version once a year, so we'll have 3.0, 3.1, > 3.3, > > >> 4.0, 4.1, 4.2, 5.0, ...etc We missed the first release this > > >> year, so we would only have 3.0 and 3.1 this year. > > >> > > >> b) Bump major

Re: [Qemu-devel] Apparently fpu/softfloat.c:1374 is reachable (-> binary images)

On 9 March 2018 at 13:58:06, Michael Clark (m...@sifive.com) wrote: > ... Hopefully we’ll have binary images for the various artefacts > on the Releases section on all of the riscv repos, > ... > It will be great when binaries are included with the GitHub Releases/tags > assuming we use GitHub

Re: [Qemu-devel] Qemu c++ build question

> On 17 Jan 2018, at 03:14, Ancuta, Cristian wrote: > > I'm currently working on implementing an emulation target in QEMU and the > implementation is in C++. it might not be the answer you expect, but last time I tried to do a similar thing I encountered a problem

Re: [Qemu-devel] CMSIS SVD based peripheral definitions

> On 17 Jan 2017, at 13:09, Peter Maydell wrote: > > losing the license info and attribution inside the SVD files there is no license info or attribution. the files themselves were created by the silicon vendors, but are distributed by ARM, inside the CMSIS Packs.

Re: [Qemu-devel] CMSIS SVD based peripheral definitions

> On 16 Jan 2017, at 21:23, Peter Maydell wrote: > > doing that is somewhere between "grey area" and > "GPL violation". too bad for GPL. :-( the fact is that I'll continue to improve support for Cortex-M in my branch of QEMU, and the SVD definitions are part of it.

Re: [Qemu-devel] CMSIS SVD based peripheral definitions

> On 16 Jan 2017, at 20:17, Peter Maydell wrote: > > "reading data that shipped with QEMU > and where QEMU won't work at all without it" (the data files > are clearly part of the program as a whole and the GPL > applies to them even if they don't happen to be

Re: [Qemu-devel] CMSIS SVD based peripheral definitions

> On 9 Jan 2017, at 19:31, Peter Maydell wrote: > > FSF's view is that Apache 2.0 is not compatible with GPLv2: I can't dispute this, but does't the GPLv2 requirements apply to the qemu executable only? my JSON files are not compiled into the binary, but are data

Re: [Qemu-devel] CMSIS SVD based peripheral definitions

> On 9 Jan 2017, at 18:16, Peter Maydell <peter.mayd...@linaro.org> wrote: > > On 28 December 2016 at 18:49, Liviu Ionescu <i...@livius.net> wrote: >> The latest release of GNU ARM Eclipse QEMU (2.8.0-20161227) introduced >> a new technology for implementi

[Qemu-devel] CMSIS SVD based peripheral definitions

CMSIS SVD - The latest release of GNU ARM Eclipse QEMU (2.8.0-20161227) introduced a new technology for implementing peripherals, based on standard CMSIS SVD definitions (http://www.keil.com/pack/doc/CMSIS/SVD/html/index.html). The SVD files are large XML files produced by the silicon

Re: [Qemu-devel] regression in 2.8: unable to exit screen grab in SDL mode

> On 16 Dec 2016, at 10:26, Thomas Huth wrote: > > ... so I would recommend to keep the SDL code in QEMU. SDL 1.2 is largely deprecated now, when I upgraded to macOS 10.12 I suddenly started to have various problems. so I decided to upgrade GNU ARM Eclipse to SDL 2. if

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

> On 13 Dec 2016, at 09:04, Fam Zheng wrote: > > using qemu_bh_schedule_idle in the QEMU main loop and poll event there > periodically. ok, so my TODO list includes two items: to move user events on an event notifier and to run the SDL_PollEvent() on qemu_bh_schedule_idle.

  1   2   3   4   5   >