> 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 a
> 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
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
> 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 be
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
/home/ilg/Work/xpack-dev-tools/qemu-riscv-xpack.git/build/win32-x64/xpacks/.bin/x86_6
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 ?
> 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
> On 17 Mar 2023, at 18:55, Thomas Huth wrote:
>
> This reverts commit 1d0a8eba38c028ea02c6e0b68f0a4c9a3cbf...
Thank you, Thomas!
Liviu
> 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 accurat
> 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 qui
> 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
> 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 ha
> 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 s
> 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 0x4000_,
> 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 SYS_HEA
> 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 in
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"
"enable=on,target=nati
> 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 ~ %
/Users/ilg/Library/xPacks/@xpack-dev-tools/
> 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
> 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 s
> 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 same
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 Files/WKS
> 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
> 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
> 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 can
> 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, the
> 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 version
> 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 test
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
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 em
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 pre
> 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 n
> 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 the
> 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
> 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,
> 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, wh
> 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
yea
> 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 QEM
> 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
>> support, and
> 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.
Liv
> 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 .../share/qe
> 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*.
> 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
> 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 b
> 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.
The
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 th
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 qemu-system-risc
> 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
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
'NSP
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, s
> 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 applications,
> 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
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.
> 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.
In
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 SV
> 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 month
> 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 o
> 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 t
> 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 precise
> 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
Code,
> 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 python
> 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 th
> 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
> 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 homebr
> 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 registe
> 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 nest
> 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 seems
> 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 who
> 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 n
> 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
> 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, inst
> 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 (v
> 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
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 lis
> 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 Lin
> 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,
> 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 B
> 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 A
> 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 sing
> 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++ framework/R
> 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 spec
> On 12 Mar 2019, at 16:09, Eric Blake wrote:
>
> I personally prefer - over _
+1
> 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
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 can
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 h
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 include
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 M
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 point
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
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
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 Rel
> 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 that prevented the direct C
> 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.
the original CMSIS license
> 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.
if you are not comfortable
> 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 binaries);
I'm not a lawyer either,
> 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
files, read by the executable
> On 9 Jan 2017, at 18:16, Peter Maydell wrote:
>
> On 28 December 2016 at 18:49, Liviu Ionescu wrote:
>> The latest release of GNU ARM Eclipse QEMU (2.8.0-20161227) introduced
>> a new technology for implementing peripherals, based on standard
>> CMSIS SVD definiti
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 v
> 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 all graphic calls are
> 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. I'll do this,
but a
1 - 100 of 406 matches
Mail list logo
