Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
On 08/21/2011 09:15 PM, Natalia Portillo wrote: Definitively you don't know how a Mac works, you don't want to know and you don't need to. I do not care about the half of MacOS that Apple burns into ROM which Linux does not use, true. On 08/20/2011 07:23 PM, Natalia Portillo wrote: I hate huge emails. Anyway I can't answer a lot of things you said because of NDAs so doesn't matter. Right, so the emulator you suggested not actually emulating any real hardware devices is either tl;dr, I can't tell you because of NDA, or you don't understand how macs work. *shrug* Have fun with that. You can create your own virtual non-existent hardware (it's done extensively in this world) and patch Linux to boot of it inside qemu. Or you can check for Linux's support for development boards (sure there are one or two) and implement it on qemu based on what Linux's source says. I have, in fact, _seen_ Linux run on an m68k mac, although it was many moons ago. Obviously it _can_ be done. (And I could play with coldfire now, but doing nommu in userspace is fiddly and irritating. Stuff like cris is higher on my todo list than that.) And FOR GOD'S SAKE CHECK THE ** COMPATIBILITY LIST ON LINUX-M68K. No Mac m68k suits your needs for Linux NONE NINGUNO AUCUN KEINER NESSUNO NENHUM. Which is of course why Linux has a mac_defconfig under the m68k directory specifying numerous drivers for actual hardware. It seems unlikely that the powerpc mac99 and g3beige worked just fine for me, but before they swapped the CPU out it all ran by magic. Rob P.S. For context as to what counts as intimidating and magic, Jeri Ellsworth reverse engineered the Amiga chips in an FPGA: http://www.youtube.com/watch?v=5uaDzF99a80
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Le samedi 20 août 2011 à 18:42 -0500, Rob Landley a écrit : On 08/20/2011 06:17 PM, Natalia Portillo wrote: or ancient macintosh support Most of the hardware (but a few required ones like SWIM) is already in QEMU, you need to glue everything, make Toolbox be VERY happy about its environment, make Mac OS boot so it can second-boot Linux (the direct-booter is so buggy it may introduce phantom bugs on the emulation) and implement the MMU. I haven't got a copy of ancient MacOS. Why is the direct booter buggy? I'm happy to track down and isolate phantom bugs, either in the kernel or in qemu. (One nice thing about emulators is you can get deterministic regression tests reasonably easily. :) How do I _use_ the direct booter, anyway? I built mac_defconfig in 3.0 but it only gave me a vmlinux, which faulted on the instruction at address 0. I tried m68k-objdump -O binary vmlinux vmlinux.bin but that wouldnt' bot at all (qemu -kernel refused to load it). For the moment, q800 is not working. Master branch is for m68k-linux-user target. I'm working on m68k-softmmu on the macrom-branch by porting the basiliskII stuff. [Natalia: this allows me to debug the CPU by comparing traces from BasiliskII and traces from qemu, I've found several in supervisor mode] but a ROM will not be required to boot it as the bootloader has the role to collect information from the ROM to pass it the kernel. Qemu will be able to do it and boot directly the kernel (with option --kernel). We can cutpaste parts from the EMILE bootloader. A real machine emulation will require a ROM. But for this part we can have a look to executore (https://github.com/ctm/executor). that Linux could boot on? (I.E. I'm interested in Linux system emulation of non-coldfire m68k. So far that means use aranym.) Linux requires the MMU and an almost complete hardware emulation. Standard m68k emulations (UAE, Aranym and specially BasiliskII) try to patch the OS to work. That's kinda sad. Is there a web page anywhere that elaborates on this? Indeed BasiliskII is anything but a real macintosh emulator, as it patches heavily the Toolbox and Mac OS (that's why Linux and A/UX will never work on it) I believe toolbox is the ancient mac bios, correct? Does Linux need/use it at all? No Regards, Laurent
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
El 21/08/2011, a las 11:04, Laurent Vivier escribió: Le samedi 20 août 2011 à 18:42 -0500, Rob Landley a écrit : On 08/20/2011 06:17 PM, Natalia Portillo wrote: or ancient macintosh support Most of the hardware (but a few required ones like SWIM) is already in QEMU, you need to glue everything, make Toolbox be VERY happy about its environment, make Mac OS boot so it can second-boot Linux (the direct-booter is so buggy it may introduce phantom bugs on the emulation) and implement the MMU. I haven't got a copy of ancient MacOS. Why is the direct booter buggy? I'm happy to track down and isolate phantom bugs, either in the kernel or in qemu. (One nice thing about emulators is you can get deterministic regression tests reasonably easily. :) How do I _use_ the direct booter, anyway? I built mac_defconfig in 3.0 but it only gave me a vmlinux, which faulted on the instruction at address 0. I tried m68k-objdump -O binary vmlinux vmlinux.bin but that wouldnt' bot at all (qemu -kernel refused to load it). For the moment, q800 is not working. Master branch is for m68k-linux-user target. I'm working on m68k-softmmu on the macrom-branch by porting the basiliskII stuff. [Natalia: this allows me to debug the CPU by comparing traces from BasiliskII and traces from qemu, I've found several in supervisor mode] As always, at least there are not so many secret opcodes :p but a ROM will not be required to boot it as the bootloader has the role to collect information from the ROM to pass it the kernel. Qemu will be able to do it and boot directly the kernel (with option --kernel). We can cutpaste parts from the EMILE bootloader. But bypassing the ROM in all cases is not emulating a real Macintosh, is creating a special target for Linux that emulates the same hardware. (Gz for your EMILE, but, buy a tripod :p) A real machine emulation will require a ROM. But for this part we can have a look to executore (https://github.com/ctm/executor). Last time I used Executor it only emulated an OS 6 Toolbox and with a compatibility scarce at best. that Linux could boot on? (I.E. I'm interested in Linux system emulation of non-coldfire m68k. So far that means use aranym.) Linux requires the MMU and an almost complete hardware emulation. Standard m68k emulations (UAE, Aranym and specially BasiliskII) try to patch the OS to work. That's kinda sad. Is there a web page anywhere that elaborates on this? Indeed BasiliskII is anything but a real macintosh emulator, as it patches heavily the Toolbox and Mac OS (that's why Linux and A/UX will never work on it) I believe toolbox is the ancient mac bios, correct? Does Linux need/use it at all? No Regards, Laurent
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
On 08/20/2011 09:02 PM, Natalia Portillo wrote: El 21/08/2011, a las 01:50, Rob Landley escribió: On 08/20/2011 07:23 PM, Natalia Portillo wrote: Linux requires the MMU and an almost complete hardware emulation. Standard m68k emulations (UAE, Aranym and specially BasiliskII) try to patch the OS to work. That's kinda sad. Is there a web page anywhere that elaborates on this? It is a known thing that Linux requires MMU, it appears on the installation guide of all m68k distros. On how and how much they patch the OS, check their sources. Actually coldfire was nommu and thus m68k was one of the first nommu platforms. But what I was talking about was patching the OS. The aranym patches (that i saw) were adding new virtual device drivers. (A bit like virtio, only different implementations.) Indeed BasiliskII is anything but a real macintosh emulator, as it patches heavily the Toolbox and Mac OS (that's why Linux and A/UX will never work on it) I believe toolbox is the ancient mac bios, correct? Does Linux need/use it at all? Yes and no to both. Mac OS is a really complex operating system where everything is divided in little pieces that can be loaded individually and independently (the Grand Unified Model, the reason why resource forks exist). Toolbox is the most important part, the one that resides inside the ROM chip, provides the specific model drivers (and in the II models, loads the video driver from the NuBus card), and loads the rest of the system from the System file inside MacOS. CP/M got split into the BIOS and BDOS halves when Imsai asked Digital Research to give them a driver pack they could tailor to their non-Altair hardware, and then the other half could be board-independent. This seems similarly relevant? No, CP/M's BIOS just initializes the hardware. BDOS contains the drivers. The bios contains the drivers necessary to talk to the hardware you need for booting. BDOS didn't duplicate drivers that were in the BIOS, there was no room. It continue to use them. DOS started as a more or less clone of CP/M, and continued to call into the BIOS for things like disk access. Linux, running on the same hardware, did not use the BIOS, or DOS, after boot. LOADLIN was one option for booting Linux, but not the only one. PC BIOS do the same. DOS continues to make fairly extensive use of BIOS calls after boot. I used to program for DOS, I know this firsthand. Toolbox initializes the drivers, contains the HAL, the kernel, the resource fork manager, the window manager, the mouse pointer, the quickdraw functions. It's like having Windows 3.1 in ROM and the explorer.exe on disk. And Linux uses neither. Why would the mac be different? I'm aware there was an early microkernel-based mac port in the early 90's back before Linux had its 1.0 release, but that wasn't what got merged into the kernel. Linux supports m68k on Atari and Amiga as well as old mac, it doesn't need MacOS installed on Atari or Amiga. It has drivers, which talk directly to chips. It does not expect a boot loader, it's the OS itself, indeed in an specific model the whole OS is contained in ROM. There is a table for OS functions that can be made to point to ROM (implemented on Toolbox) or in RAM (System file, bug or functionality updates). Linux is an OS. It generally doesn't call much out of PC bios or openfirmware and so on after it boots up. You're saying m68k is different? Yes, Mac OS must load Linux, not a bootloader. If Mac OS don't work, your chances of getting Linux to work (on a REAL macintosh emulator) are close to 0. I don't want a real macintosh emulator then, I want qemu to emulate an m68k and give me a board I can get a shell prompt on. I don't care if it's closer to amiga, atari, or mac, since all three share the exact same binary identical root filesystem (at least when you're not using x11 and the drivers therein) and the only difference is kernel .config. BasiliskII patches that table inserting their own functions (for example, the floppy driver is enhanced to provide access to the host disk images, instead of calling to the SWIM chip that will manage the floppy drive in a real macintosh). I'm not even building the floppy driver in my kernel .config. Does Linux really have to use this table instead of having actual drivers that run the chips? (You're saying Linux calls the apple bios to access devices?) Read it again, on Basilisk, Linux will find no storage device at all, no video device, no serial device, no nothing :p Ctrl-alt-google, read the technical manual... http://basilisk.cebix.net/TECH Quote the technical manual at you: More precisely spoken, MacOS under Basilisk II behaves like on a Mac Classic or Mac II because, apart from the CPU, the RAM and the ROM, absolutely no Mac hardware is emulated. Rather, Basilisk II provides replacements (usually in the form of MacOS drivers) for the parts of
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
On 08/21/2011 05:04 AM, Laurent Vivier wrote: Le samedi 20 août 2011 à 18:42 -0500, Rob Landley a écrit : On 08/20/2011 06:17 PM, Natalia Portillo wrote: or ancient macintosh support Most of the hardware (but a few required ones like SWIM) is already in QEMU, you need to glue everything, make Toolbox be VERY happy about its environment, make Mac OS boot so it can second-boot Linux (the direct-booter is so buggy it may introduce phantom bugs on the emulation) and implement the MMU. I haven't got a copy of ancient MacOS. Why is the direct booter buggy? I'm happy to track down and isolate phantom bugs, either in the kernel or in qemu. (One nice thing about emulators is you can get deterministic regression tests reasonably easily. :) How do I _use_ the direct booter, anyway? I built mac_defconfig in 3.0 but it only gave me a vmlinux, which faulted on the instruction at address 0. I tried m68k-objdump -O binary vmlinux vmlinux.bin but that wouldnt' bot at all (qemu -kernel refused to load it). For the moment, q800 is not working. I noticed. :) Master branch is for m68k-linux-user target. I'm working on m68k-softmmu on the macrom-branch by porting the basiliskII stuff. That doesn't emulate real hardware according to the introduction of http://basilisk.cebix.net/TECH so what is there to port? (Closer CPU emulation for the MMU stuff?) but a ROM will not be required to boot it as the bootloader has the role to collect information from the ROM to pass it the kernel. Qemu will be able to do it and boot directly the kernel (with option --kernel). We can cutpaste parts from the EMILE bootloader. If the platform wasn't mummified I'd suggest a device tree conversion... :) A real machine emulation will require a ROM. But for this part we can have a look to executore (https://github.com/ctm/executor). I just want to run Linux on the thing, via -kernel and -append. Rob
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Definitively you don't know how a Mac works, you don't want to know and you don't need to. El 21/08/2011, a las 23:14, Rob Landley escribió: On 08/20/2011 09:02 PM, Natalia Portillo wrote: El 21/08/2011, a las 01:50, Rob Landley escribió: On 08/20/2011 07:23 PM, Natalia Portillo wrote: I hate huge emails. Anyway I can't answer a lot of things you said because of NDAs so doesn't matter. Care to suggest one? I'm not that familiar with what's available in m68k land, I just know how the other dozen hardware platforms I've used work. Sorry no, Google sure finds them, and, you can invent your own. You can create your own virtual non-existent hardware (it's done extensively in this world) and patch Linux to boot of it inside qemu. Or you can check for Linux's support for development boards (sure there are one or two) and implement it on qemu based on what Linux's source says. And FOR GOD'S SAKE CHECK THE ** COMPATIBILITY LIST ON LINUX-M68K. No Mac m68k suits your needs for Linux NONE NINGUNO AUCUN KEINER NESSUNO NENHUM. Regards :p
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
On 08/17/2011 03:46 PM, Bryce Lanham wrote: These patches greatly expand Motorola 68k emulation within qemu, and are what I used as a basis for my Google Summer of Code project to add NeXT hardware support to QEMU. Can I get these patches as a tarball or a git tree or something? Trying to fish them out of either thunderbird of the web archive is a bit tricky, and I'd very much like to test them. Also, it looks like you're adding NeXT target support. What would be involved in adding simple Amiga, Atari, or ancient macintosh support that Linux could boot on? (I.E. I'm interested in Linux system emulation of non-coldfire m68k. So far that means use aranym.) Thanks, Rob
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
On 08/18/2011 02:42 PM, Natalia Portillo wrote: Hi Laurent, El 18/08/2011, a las 15:02, Laurent Vivier escribió: Le 18 août 2011 à 13:12, François Revol re...@free.fr mailto:re...@free.fr a écrit : Le -10/01/-28163 20:59, Laurent Vivier a écrit : Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit : On 08/17/2011 03:46 PM, Bryce Lanham wrote: These patches greatly expand Motorola 68k emulation within qemu, and are what I used as a basis for my Google Summer of Code project to add NeXT hardware support to QEMU. Please don't crap flood the list with a series of 100 patches. Split things into logical chunks such that a series can be reasonably reviewed and applied. And I'm not sure this series of patches is ready for inclusion in qemu mainline as it should break existing m68k emulation... Bryce, you should only post your patches, refering to the repository on which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git , master branch. Btw, are you planning on merging it back someday? Yes... when it will work correctly. I have at least, to rework 680x0 FPU part (80bit fpu) to not break the existing one (64bit fpu). I have to check modified instructions don't break existing m68k emulation. Maybe Bryce can help you I have a build system that builds the same simple Linux system for a dozen different targets (uClibc 0.9.32, Linux 3.0, busybox 1.19.0, binutils 2.17, gcc 4.2.1, make 3.81), boots them all under qemu the same way, and either interactively use them or can automatically build the whole of Linux From Scratch under them (either with a fully native toolchain or with distcc calling out to the cross compiler to speed things up). I would very much like to test m68k. I've been building m68k system images forever (the kernel's some atari variant donated to the project by a user), but have only been able to test them a couple times under aranym, not under qemu. Web page: http://landley.net/aboriginal Prebuilt binary system images for use with qemu: http://landley.net/aboriginal/downloads/binaries Currently, I'm trying to port some parts of BasiliskII into Qemu to be able to boot MacOS 7.6. Why are you planning to port a hack instead of making a full machine emulation? Yay machine emulation. If qemu comes up with an m68k system emulation that has a chance of running Linux, please let me know... Rob
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Le samedi 20 août 2011 à 15:57 -0500, Rob Landley a écrit : On 08/18/2011 06:12 AM, François Revol wrote: Le -10/01/-28163 20:59, Laurent Vivier a écrit : Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit : On 08/17/2011 03:46 PM, Bryce Lanham wrote: These patches greatly expand Motorola 68k emulation within qemu, and are what I used as a basis for my Google Summer of Code project to add NeXT hardware support to QEMU. Please don't crap flood the list with a series of 100 patches. Split things into logical chunks such that a series can be reasonably reviewed and applied. And I'm not sure this series of patches is ready for inclusion in qemu mainline as it should break existing m68k emulation... Bryce, you should only post your patches, refering to the repository on which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git , master branch. Btw, are you planning on merging it back someday? François. I note that I pulled that this morning, did ./configure --disable-werror --target-list=m68k-softmmu, and then ran make, which generated 4 header files and considered itself done. I.E. m68k system emulation doesn't seem to be building in that tree. first off all, this branch is only able to build m68k-linux-user qemu/, then try: cd qemu mkdir build-test cd build-test ../configure --disable-werror --target-list=m68k-softmmu make and let me know what happens... Regards, Laurent
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
On 08/19/2011 03:55 AM, François Revol wrote: Le 19/08/2011 04:14, Natalia Portillo a écrit : Hi, [...] (no need to quote the full thread!) He worked on emulating an abandoned, strange, difficult to get, and undocumented hardware, using your 111 patches, and finished it before the wholy more experienced MESS team. The next-cube emulation is really working ? Yes, it is, absolutely. Cool I need to add this target to my Haiku port... where are the docs for the boot process ? Why are you planning to port a hack instead of making a full machine emulation? Because I'm lazy and dumb: the work is already done, I like cut'n'paste. Yeah, you said it! The work is already done, we have all the hardware emulation that Basilisk substitutes for hacks. I'm not sure of that... no MMU emulation, no Nubus, no ethernet card, no video card, no SWIM, no SCSI, ... useless with a patched ROM. Macs do not have videocards :p, only the Mac II and we're not forced to emulate that one. SWIM is a piece of cake that can be even implemented without ICs, just some logical arrays. NuBus is not required for almost anything, only the video card uses it, and it's present only on the Mac II, a stub will suffice to make Toolbox be happy. Most m68k didn't include a network card, third party ones are stock chips (probably almost all are NE2000, 3COM and PCNET), and Apple integrated ones are also stock, easy to do :p NIC isn't really necessary at first, those things don't netboot anyway, do they ? The hardware I'm interested in is: A) CPU with MMU (FPU is nice but optional) B) At least 256k ram, C) Serial port D) Three hard drives (IDE, SCSI, etc.) E) Hardware clock F) Network card (for distcc) One of the goals of mmy project is to replace cross comiling with native compiling, and that's the set of hardware I need to get a reasonably convenient native development environment running under the emulator. Rob
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
On 08/19/2011 03:08 PM, Anthony Liguori wrote: On 08/19/2011 11:07 AM, Laurent Vivier wrote: Le 19 août 2011 à 17:52, Natalia Portilloclau...@claunia.com a écrit : El 19/08/2011, a las 09:55, François Revol escribió: [snip] Release early, release often :p +1Ok, Ok, I think all m68k core can be submitted except some bitfield operations and fpu instructions. Just need to know how Anthony and Paul want I proceed... Well let's step back here for a minute. The most important problem to solve is for someone to maintain whatever is in the tree consistently (and incrementally) improving what we have. I dunno about maintain and improve, but if an m68k board emulation starts working I can regression test it against Linux system images and make puppy eyes at people when it breaks. (Plus the occasional monkey patch offering The Wrong Fix to motivate people. :) Laurent, if you want to take over m68k and Paul doesn't object, I'm all for it. But that doesn't mean that I want to see 400 commits of stuff that only half works. I'd like to see a systematic approach to either picking a platform and making it robust or fixing what's there already. I would very much like something capable of booting m68k Linux, specifically http://landley.net/aboriginal/downloads/binaries/old/1.0.1/system-image-m68k.tar.bz2 (The kernel in that tarball is randomish, I think some defconfig for atari, but the root filesystem was tested under ananym and worked.) I'm in the process of building a Linux 3.0, uClibc 0.9.32, busybox 1.19.0 variant which should be ready tomorrow-ish, if that would be a better testing base. I'm probably basing it on the atari_defconfig in the 3.0 kernel unless somebody has a better idea. (In case I need to fish out aranym again.) Rob
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
On 08/18/2011 03:51 PM, Laurent Vivier wrote: Le jeudi 18 août 2011 à 21:13 +0100, Natalia Portillo a écrit : Hi Laurent, El 18/08/2011, a las 20:57, Laurent Vivier escribió: Le jeudi 18 août 2011 à 20:42 +0100, Natalia Portillo a écrit : Hi Laurent, Hi Natalia, El 18/08/2011, a las 15:02, Laurent Vivier escribió: Le 18 août 2011 à 13:12, François Revol re...@free.fr a écrit : Le -10/01/-28163 20:59, Laurent Vivier a écrit : Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit : On 08/17/2011 03:46 PM, Bryce Lanham wrote: These patches greatly expand Motorola 68k emulation within qemu, and are what I used as a basis for my Google Summer of Code project to add NeXT hardware support to QEMU. Please don't crap flood the list with a series of 100 patches. Split things into logical chunks such that a series can be reasonably reviewed and applied. And I'm not sure this series of patches is ready for inclusion in qemu mainline as it should break existing m68k emulation... Bryce, you should only post your patches, refering to the repository on which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git , master branch. Btw, are you planning on merging it back someday? Yes... when it will work correctly. I have at least, to rework 680x0 FPU part (80bit fpu) to not break the existing one (64bit fpu). I have to check modified instructions don't break existing m68k emulation. Maybe Bryce can help you I don't know if he is courageous enough to review and push 111 patches ;-) He worked on emulating an abandoned, strange, difficult to get, and undocumented hardware, using your 111 patches, and finished it before the wholy more experienced MESS team. The next-cube emulation is really working ? He is! xD There is no problem for me, he can do... Currently, I'm trying to port some parts of BasiliskII into Qemu to be able to boot MacOS 7.6. Why are you planning to port a hack instead of making a full machine emulation? Because I'm lazy and dumb: the work is already done, I like cut'n'paste. Yeah, you said it! The work is already done, we have all the hardware emulation that Basilisk substitutes for hacks. I'm not sure of that... no MMU emulation, no Nubus, no ethernet card, no video card, no SWIM, no SCSI, ... useless with a patched ROM. You know, nights are not long enough... We only lack the 68k cpu (oh! your patches!!!) and the glue :p this part is not working well as well ... gcc cannot compile linux kernel, some demos fail in gtk-demo, ... I got gcc 4.2.1 with binutils 2.17 to compile the m68k Linux kernel (including 3.0). This kind of regression testing of each new release on various platforms is what I've been doing for the ones I've got working for years now. I'd love to add m68k to it (heck, I've got infrastructure to do nightly builds from upstream -git of the kernel and uClibc and auto-bisect breakage that prevented dropbear and strace from building natively under the result; I admit I haven't put in the effort to follow up on the result yet). But all i've been able to say so far is 'I got it to compile, I can't _run_ it on qemu. (And my aranym setup keeps bit rotting, and hasn't got the right kind of console anyway...) Rob
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
On 08/20/2011 04:16 PM, Laurent Vivier wrote: Le samedi 20 août 2011 à 15:57 -0500, Rob Landley a écrit : On 08/18/2011 06:12 AM, François Revol wrote: Le -10/01/-28163 20:59, Laurent Vivier a écrit : Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit : On 08/17/2011 03:46 PM, Bryce Lanham wrote: These patches greatly expand Motorola 68k emulation within qemu, and are what I used as a basis for my Google Summer of Code project to add NeXT hardware support to QEMU. Please don't crap flood the list with a series of 100 patches. Split things into logical chunks such that a series can be reasonably reviewed and applied. And I'm not sure this series of patches is ready for inclusion in qemu mainline as it should break existing m68k emulation... Bryce, you should only post your patches, refering to the repository on which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git , master branch. Btw, are you planning on merging it back someday? François. I note that I pulled that this morning, did ./configure --disable-werror --target-list=m68k-softmmu, and then ran make, which generated 4 header files and considered itself done. I.E. m68k system emulation doesn't seem to be building in that tree. first off all, this branch is only able to build m68k-linux-user qemu/, then try: cd qemu mkdir build-test cd build-test ../configure --disable-werror --target-list=m68k-softmmu make and let me know what happens... It complained about config-devices.mak not being there... then built for a while until it died with: qapi-generated/qga-qapi-types.c:19:28: error: qga-qapi-visit.h: No such file or directory Rob
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Hi, El 20/08/2011, a las 21:55, Rob Landley escribió: On 08/17/2011 03:46 PM, Bryce Lanham wrote: These patches greatly expand Motorola 68k emulation within qemu, and are what I used as a basis for my Google Summer of Code project to add NeXT hardware support to QEMU. Can I get these patches as a tarball or a git tree or something? Trying to fish them out of either thunderbird of the web archive is a bit tricky, and I'd very much like to test them. Also, it looks like you're adding NeXT target support. What would be involved in adding simple Amiga You would need to add (or copy/paste from UAE) all the Amiga custom chips, the Zorro bus, and implement the MMU (currently is anything but finished in Laurent's words) , Atari, You would need to add (or copy/paste from Aranym) all the Atari Falcon not-so-custom chips, and implement the MMU. or ancient macintosh support Most of the hardware (but a few required ones like SWIM) is already in QEMU, you need to glue everything, make Toolbox be VERY happy about its environment, make Mac OS boot so it can second-boot Linux (the direct-booter is so buggy it may introduce phantom bugs on the emulation) and implement the MMU. that Linux could boot on? (I.E. I'm interested in Linux system emulation of non-coldfire m68k. So far that means use aranym.) Linux requires the MMU and an almost complete hardware emulation. Standard m68k emulations (UAE, Aranym and specially BasiliskII) try to patch the OS to work. Indeed BasiliskII is anything but a real macintosh emulator, as it patches heavily the Toolbox and Mac OS (that's why Linux and A/UX will never work on it) Thanks, Rob
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
On 08/20/2011 04:16 PM, Laurent Vivier wrote: Le samedi 20 août 2011 à 15:57 -0500, Rob Landley a écrit : On 08/18/2011 06:12 AM, François Revol wrote: Le -10/01/-28163 20:59, Laurent Vivier a écrit : Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit : On 08/17/2011 03:46 PM, Bryce Lanham wrote: These patches greatly expand Motorola 68k emulation within qemu, and are what I used as a basis for my Google Summer of Code project to add NeXT hardware support to QEMU. Please don't crap flood the list with a series of 100 patches. Split things into logical chunks such that a series can be reasonably reviewed and applied. And I'm not sure this series of patches is ready for inclusion in qemu mainline as it should break existing m68k emulation... Bryce, you should only post your patches, refering to the repository on which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git , master branch. Btw, are you planning on merging it back someday? François. I note that I pulled that this morning, did ./configure --disable-werror --target-list=m68k-softmmu, and then ran make, which generated 4 header files and considered itself done. I.E. m68k system emulation doesn't seem to be building in that tree. first off all, this branch is only able to build m68k-linux-user qemu/, then try: cd qemu mkdir build-test cd build-test ../configure --disable-werror --target-list=m68k-softmmu make and let me know what happens... Hmmm, there is a q800 target I hadn't noticed. I built the mac_defconfig target and did -kernel vmlinux on that with -nographic and -append console=/dev/ttyS0, and it went: (qemu) QEMU 0.15.50 monitor - type 'help' for more information (qemu) qemu: fatal: Illegal instruction: 7f45 @ D0 = fffb A0 = 0021b24c F0 = c000 D1 = A1 = 002c16fe F1 = c000 D2 = 002c002c A2 = 1000 F2 = c000 D3 = 17b82700 A3 = 002d8eb0 F3 = c000 D4 = A4 = F4 = c000 D5 = A5 = F5 = c000 D6 = A6 = F6 = c000 D7 = A7 = 103c F7 = c000 PC = SR = 2700 - Aborted This sound at all familiar? (Is there a different kernel file I should be using? There's no arch/m68k/boot or arch/m68k/mac/boot I could find. Or is q800 not entirely there?) Thanks, Rob
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
On 08/20/2011 06:17 PM, Natalia Portillo wrote: or ancient macintosh support Most of the hardware (but a few required ones like SWIM) is already in QEMU, you need to glue everything, make Toolbox be VERY happy about its environment, make Mac OS boot so it can second-boot Linux (the direct-booter is so buggy it may introduce phantom bugs on the emulation) and implement the MMU. I haven't got a copy of ancient MacOS. Why is the direct booter buggy? I'm happy to track down and isolate phantom bugs, either in the kernel or in qemu. (One nice thing about emulators is you can get deterministic regression tests reasonably easily. :) How do I _use_ the direct booter, anyway? I built mac_defconfig in 3.0 but it only gave me a vmlinux, which faulted on the instruction at address 0. I tried m68k-objdump -O binary vmlinux vmlinux.bin but that wouldnt' bot at all (qemu -kernel refused to load it). that Linux could boot on? (I.E. I'm interested in Linux system emulation of non-coldfire m68k. So far that means use aranym.) Linux requires the MMU and an almost complete hardware emulation. Standard m68k emulations (UAE, Aranym and specially BasiliskII) try to patch the OS to work. That's kinda sad. Is there a web page anywhere that elaborates on this? Indeed BasiliskII is anything but a real macintosh emulator, as it patches heavily the Toolbox and Mac OS (that's why Linux and A/UX will never work on it) I believe toolbox is the ancient mac bios, correct? Does Linux need/use it at all? Rob
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
El 21/08/2011, a las 00:42, Rob Landley escribió: On 08/20/2011 06:17 PM, Natalia Portillo wrote: or ancient macintosh support Most of the hardware (but a few required ones like SWIM) is already in QEMU, you need to glue everything, make Toolbox be VERY happy about its environment, make Mac OS boot so it can second-boot Linux (the direct-booter is so buggy it may introduce phantom bugs on the emulation) and implement the MMU. I haven't got a copy of ancient MacOS. Why is the direct booter buggy? I'm happy to track down and isolate phantom bugs, either in the kernel or in qemu. (One nice thing about emulators is you can get deterministic regression tests reasonably easily. :) How do I _use_ the direct booter, anyway? I built mac_defconfig in 3.0 but it only gave me a vmlinux, which faulted on the instruction at address 0. I tried m68k-objdump -O binary vmlinux vmlinux.bin but that wouldnt' bot at all (qemu -kernel refused to load it). that Linux could boot on? (I.E. I'm interested in Linux system emulation of non-coldfire m68k. So far that means use aranym.) Linux requires the MMU and an almost complete hardware emulation. Standard m68k emulations (UAE, Aranym and specially BasiliskII) try to patch the OS to work. That's kinda sad. Is there a web page anywhere that elaborates on this? It is a known thing that Linux requires MMU, it appears on the installation guide of all m68k distros. On how and how much they patch the OS, check their sources. Indeed BasiliskII is anything but a real macintosh emulator, as it patches heavily the Toolbox and Mac OS (that's why Linux and A/UX will never work on it) I believe toolbox is the ancient mac bios, correct? Does Linux need/use it at all? Yes and no to both. Mac OS is a really complex operating system where everything is divided in little pieces that can be loaded individually and independently (the Grand Unified Model, the reason why resource forks exist). Toolbox is the most important part, the one that resides inside the ROM chip, provides the specific model drivers (and in the II models, loads the video driver from the NuBus card), and loads the rest of the system from the System file inside MacOS. It does not expect a boot loader, it's the OS itself, indeed in an specific model the whole OS is contained in ROM. There is a table for OS functions that can be made to point to ROM (implemented on Toolbox) or in RAM (System file, bug or functionality updates). BasiliskII patches that table inserting their own functions (for example, the floppy driver is enhanced to provide access to the host disk images, instead of calling to the SWIM chip that will manage the floppy drive in a real macintosh). The Linux bootloader is nothing more than a Mac OS application that loads the Linux kernel and gives it access to the full RAM, where it can (and as you see in the compatibility list, does not so well) access to the whole Macintosh hardware bypassing both Toolbox and System. Not long ago some people discovered a way to substitute the System file (RAM portion of the OS) so the Toolbox loads directly a Linux kernel. This is buggy for a lot of reasons (that was never the intended way, in-ROM drivers may be too buggy, so on). Apple UNIX (A/UX) on the other way provides a full System file (corresponding to Mac OS 7) and then loads its kernel, retaining the original table in memory for Mac OS applications compatibility and the GUI (yeah, while it's a UNIX and contains X11, native applications can be made that while being A/UX ones, use, calls and depend, on the Toolbox and System functions :D) So unless an emulation is complete enough to make the Toolbox happily load a System file, it cannot be called a Macintosh emulator. It will be merely a custom-hardware-emulator capable of running Mac OS (BasiliskII) or Linux-m68k (nothing implemented right now). Saying this of pure memory, BasiliskII patches (and so, does not emulate them really) the following devices: floppy (calls host disk images, not a floppy emulated device, whatever if the image is an hdd, floppy, or cd, it appears as a floppy to the OS), SCSI (there is no scsi emulated at all, the driver is patched to call to host ASPI devices), framebuffer (any combination is available independently of the Toolbox's expected one), NuBus (not present or patched at all), sound (not DAC at all), network (again, no network card at all), graphics accelerators (none emulated, requires NuBus), filesystem code (to make the host folder appear in desktop). Btw, vMac is more loyal to real hardware emulation. And the hardware, and the whole Toolbox and System are heavily documented up to II machines in the Inside Macintosh Volumes. Rob
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
On 08/20/2011 07:23 PM, Natalia Portillo wrote: Linux requires the MMU and an almost complete hardware emulation. Standard m68k emulations (UAE, Aranym and specially BasiliskII) try to patch the OS to work. That's kinda sad. Is there a web page anywhere that elaborates on this? It is a known thing that Linux requires MMU, it appears on the installation guide of all m68k distros. On how and how much they patch the OS, check their sources. Actually coldfire was nommu and thus m68k was one of the first nommu platforms. But what I was talking about was patching the OS. The aranym patches (that i saw) were adding new virtual device drivers. (A bit like virtio, only different implementations.) Indeed BasiliskII is anything but a real macintosh emulator, as it patches heavily the Toolbox and Mac OS (that's why Linux and A/UX will never work on it) I believe toolbox is the ancient mac bios, correct? Does Linux need/use it at all? Yes and no to both. Mac OS is a really complex operating system where everything is divided in little pieces that can be loaded individually and independently (the Grand Unified Model, the reason why resource forks exist). Toolbox is the most important part, the one that resides inside the ROM chip, provides the specific model drivers (and in the II models, loads the video driver from the NuBus card), and loads the rest of the system from the System file inside MacOS. CP/M got split into the BIOS and BDOS halves when Imsai asked Digital Research to give them a driver pack they could tailor to their non-Altair hardware, and then the other half could be board-independent. This seems similarly relevant? It does not expect a boot loader, it's the OS itself, indeed in an specific model the whole OS is contained in ROM. There is a table for OS functions that can be made to point to ROM (implemented on Toolbox) or in RAM (System file, bug or functionality updates). Linux is an OS. It generally doesn't call much out of PC bios or openfirmware and so on after it boots up. You're saying m68k is different? BasiliskII patches that table inserting their own functions (for example, the floppy driver is enhanced to provide access to the host disk images, instead of calling to the SWIM chip that will manage the floppy drive in a real macintosh). I'm not even building the floppy driver in my kernel .config. Does Linux really have to use this table instead of having actual drivers that run the chips? (You're saying Linux calls the apple bios to access devices?) The Linux bootloader is nothing more than a Mac OS application that loads the Linux kernel and gives it access to the full RAM, where it can (and as you see in the compatibility list, does not so well) access to the whole Macintosh hardware bypassing both Toolbox and System. Real hardware needs bootloaders, yes. Read hardware tends to use uboot and grub and so on depending on your platform. On qemu, we have the -kernel option that loads a kernel image into the emulator's ram, and jumps to its entry point. Not long ago some people discovered a way to substitute the System file (RAM portion of the OS) so the Toolbox loads directly a Linux kernel. This is buggy for a lot of reasons (that was never the intended way, in-ROM drivers may be too buggy, so on). Or you can go qemu -kernel so it can call load_elf() or similar. Apple UNIX (A/UX) on the other way provides a full System file (corresponding to Mac OS 7) and then loads its kernel, retaining the original table in memory for Mac OS applications compatibility and the GUI (yeah, while it's a UNIX and contains X11, native applications can be made that while being A/UX ones, use, calls and depend, on the Toolbox and System functions :D) So unless an emulation is complete enough to make the Toolbox happily load a System file, it cannot be called a Macintosh emulator. It will be merely a custom-hardware-emulator capable of running Mac OS (BasiliskII) or Linux-m68k (nothing implemented right now). I'm looking for an emulator capable of running Linux-m68k, yes. Saying this of pure memory, BasiliskII patches (and so, does not emulate them really) the following devices: floppy (calls host disk images, not a floppy emulated device, whatever if the image is an hdd, floppy, or cd, it appears as a floppy to the OS), Linux can loopback mount floppy images, so all I really need is an arbitrary block device that's big and reasonably well performing. SCSI works. SCSI (there is no scsi emulated at all, the driver is patched to call to host ASPI devices), Linux has drivers for rather a lot of scsi chips, we just need to map it at the right location for the driver to find it. framebuffer (any combination is available independently of the Toolbox's expected one), I'm using a serial console on all the other targets. NuBus (not present or patched at all), sound (not DAC at all), Not expecting to use either. network
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
El 21/08/2011, a las 01:50, Rob Landley escribió: On 08/20/2011 07:23 PM, Natalia Portillo wrote: Linux requires the MMU and an almost complete hardware emulation. Standard m68k emulations (UAE, Aranym and specially BasiliskII) try to patch the OS to work. That's kinda sad. Is there a web page anywhere that elaborates on this? It is a known thing that Linux requires MMU, it appears on the installation guide of all m68k distros. On how and how much they patch the OS, check their sources. Actually coldfire was nommu and thus m68k was one of the first nommu platforms. But what I was talking about was patching the OS. The aranym patches (that i saw) were adding new virtual device drivers. (A bit like virtio, only different implementations.) Indeed BasiliskII is anything but a real macintosh emulator, as it patches heavily the Toolbox and Mac OS (that's why Linux and A/UX will never work on it) I believe toolbox is the ancient mac bios, correct? Does Linux need/use it at all? Yes and no to both. Mac OS is a really complex operating system where everything is divided in little pieces that can be loaded individually and independently (the Grand Unified Model, the reason why resource forks exist). Toolbox is the most important part, the one that resides inside the ROM chip, provides the specific model drivers (and in the II models, loads the video driver from the NuBus card), and loads the rest of the system from the System file inside MacOS. CP/M got split into the BIOS and BDOS halves when Imsai asked Digital Research to give them a driver pack they could tailor to their non-Altair hardware, and then the other half could be board-independent. This seems similarly relevant? No, CP/M's BIOS just initializes the hardware. BDOS contains the drivers. PC BIOS do the same. Toolbox initializes the drivers, contains the HAL, the kernel, the resource fork manager, the window manager, the mouse pointer, the quickdraw functions. It's like having Windows 3.1 in ROM and the explorer.exe on disk. It does not expect a boot loader, it's the OS itself, indeed in an specific model the whole OS is contained in ROM. There is a table for OS functions that can be made to point to ROM (implemented on Toolbox) or in RAM (System file, bug or functionality updates). Linux is an OS. It generally doesn't call much out of PC bios or openfirmware and so on after it boots up. You're saying m68k is different? Yes, Mac OS must load Linux, not a bootloader. If Mac OS don't work, your chances of getting Linux to work (on a REAL macintosh emulator) are close to 0. BasiliskII patches that table inserting their own functions (for example, the floppy driver is enhanced to provide access to the host disk images, instead of calling to the SWIM chip that will manage the floppy drive in a real macintosh). I'm not even building the floppy driver in my kernel .config. Does Linux really have to use this table instead of having actual drivers that run the chips? (You're saying Linux calls the apple bios to access devices?) Read it again, on Basilisk, Linux will find no storage device at all, no video device, no serial device, no nothing :p The Linux bootloader is nothing more than a Mac OS application that loads the Linux kernel and gives it access to the full RAM, where it can (and as you see in the compatibility list, does not so well) access to the whole Macintosh hardware bypassing both Toolbox and System. Real hardware needs bootloaders, yes. Read hardware tends to use uboot and grub and so on depending on your platform. On qemu, we have the -kernel option that loads a kernel image into the emulator's ram, and jumps to its entry point. That isn't so simple in Macs Not long ago some people discovered a way to substitute the System file (RAM portion of the OS) so the Toolbox loads directly a Linux kernel. This is buggy for a lot of reasons (that was never the intended way, in-ROM drivers may be too buggy, so on). Or you can go qemu -kernel so it can call load_elf() or similar. Apple UNIX (A/UX) on the other way provides a full System file (corresponding to Mac OS 7) and then loads its kernel, retaining the original table in memory for Mac OS applications compatibility and the GUI (yeah, while it's a UNIX and contains X11, native applications can be made that while being A/UX ones, use, calls and depend, on the Toolbox and System functions :D) So unless an emulation is complete enough to make the Toolbox happily load a System file, it cannot be called a Macintosh emulator. It will be merely a custom-hardware-emulator capable of running Mac OS (BasiliskII) or Linux-m68k (nothing implemented right now). I'm looking for an emulator capable of running Linux-m68k, yes. So the answer to your questions is simple: You don't want a macintosh emulator. :p Saying this of pure memory, BasiliskII patches (and so, does not emulate them
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Le 19/08/2011 04:14, Natalia Portillo a écrit : Hi, [...] (no need to quote the full thread!) He worked on emulating an abandoned, strange, difficult to get, and undocumented hardware, using your 111 patches, and finished it before the wholy more experienced MESS team. The next-cube emulation is really working ? Yes, it is, absolutely. Cool I need to add this target to my Haiku port... where are the docs for the boot process ? Why are you planning to port a hack instead of making a full machine emulation? Because I'm lazy and dumb: the work is already done, I like cut'n'paste. Yeah, you said it! The work is already done, we have all the hardware emulation that Basilisk substitutes for hacks. I'm not sure of that... no MMU emulation, no Nubus, no ethernet card, no video card, no SWIM, no SCSI, ... useless with a patched ROM. Macs do not have videocards :p, only the Mac II and we're not forced to emulate that one. SWIM is a piece of cake that can be even implemented without ICs, just some logical arrays. NuBus is not required for almost anything, only the video card uses it, and it's present only on the Mac II, a stub will suffice to make Toolbox be happy. Most m68k didn't include a network card, third party ones are stock chips (probably almost all are NE2000, 3COM and PCNET), and Apple integrated ones are also stock, easy to do :p NIC isn't really necessary at first, those things don't netboot anyway, do they ? The MMU is your part I won't discuss on it. There is 040 mmu support in ARAnyM (Atari Running on Any Machine), enough to run Linux, that has been backported to UAE (ARAnyM is based on the UAE core), that should give some hints: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=201442 http://www.amigaemulator.org/patches http://www.amigaemulator.org/bin/patches/mmu/uae-0.8.20.2-mmu.diff.gz (though I fixed a bug in handling TTR1 in ARAnyM) It's why I chose to go Falcon first and use ARAnyM for the 68k Haiku port. The 030 or 68551 ones are much more complex though (the 040 one has a fixed table layout, others have fully configurable table size for all the 4 levels). The 060 one is just the 040 with some cache restrictions. I know it's not perfect, but right now, it's better than nothing. There is no 68k cpu emulation complete afaik, I discussed with Ray Arachelian a lot on that when he was working on LisaEm. However emulators are live, Aranym, UAE, LisaEm, BasiliskII. qemu-m68k is quite complete to go live (when it does not break mcoldfire) right now. Bugs are easy to be corrected by more people when they are in main than in a developer's own clone. Leave your little kid go wild, it's old and big enough :p Release early, release often :p François.
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
El 19/08/2011, a las 09:55, François Revol escribió: Le 19/08/2011 04:14, Natalia Portillo a écrit : Hi, [...] (no need to quote the full thread!) He worked on emulating an abandoned, strange, difficult to get, and undocumented hardware, using your 111 patches, and finished it before the wholy more experienced MESS team. The next-cube emulation is really working ? Yes, it is, absolutely. Cool I need to add this target to my Haiku port... where are the docs for the boot process ? NetBSD sources :D Why are you planning to port a hack instead of making a full machine emulation? Because I'm lazy and dumb: the work is already done, I like cut'n'paste. Yeah, you said it! The work is already done, we have all the hardware emulation that Basilisk substitutes for hacks. I'm not sure of that... no MMU emulation, no Nubus, no ethernet card, no video card, no SWIM, no SCSI, ... useless with a patched ROM. Macs do not have videocards :p, only the Mac II and we're not forced to emulate that one. SWIM is a piece of cake that can be even implemented without ICs, just some logical arrays. NuBus is not required for almost anything, only the video card uses it, and it's present only on the Mac II, a stub will suffice to make Toolbox be happy. Most m68k didn't include a network card, third party ones are stock chips (probably almost all are NE2000, 3COM and PCNET), and Apple integrated ones are also stock, easy to do :p NIC isn't really necessary at first, those things don't netboot anyway, do they ? AFAIK, none of them did until PowerPC, and that was OpenFirmware. The MMU is your part I won't discuss on it. There is 040 mmu support in ARAnyM (Atari Running on Any Machine), enough to run Linux, that has been backported to UAE (ARAnyM is based on the UAE core), that should give some hints: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=201442 http://www.amigaemulator.org/patches http://www.amigaemulator.org/bin/patches/mmu/uae-0.8.20.2-mmu.diff.gz (though I fixed a bug in handling TTR1 in ARAnyM) It's why I chose to go Falcon first and use ARAnyM for the 68k Haiku port. The 030 or 68551 ones are much more complex though (the 040 one has a fixed table layout, others have fully configurable table size for all the 4 levels). The 060 one is just the 040 with some cache restrictions. I know it's not perfect, but right now, it's better than nothing. There is no 68k cpu emulation complete afaik, I discussed with Ray Arachelian a lot on that when he was working on LisaEm. However emulators are live, Aranym, UAE, LisaEm, BasiliskII. qemu-m68k is quite complete to go live (when it does not break mcoldfire) right now. Bugs are easy to be corrected by more people when they are in main than in a developer's own clone. Leave your little kid go wild, it's old and big enough :p Release early, release often :p +1 François.
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Le 19 août 2011 à 17:52, Natalia Portillo clau...@claunia.com a écrit : El 19/08/2011, a las 09:55, François Revol escribió: [snip] Release early, release often :p +1Ok, Ok, I think all m68k core can be submitted except some bitfield operations and fpu instructions. Just need to know how Anthony and Paul want I proceed... Regards, Laurent
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit : On 08/17/2011 03:46 PM, Bryce Lanham wrote: These patches greatly expand Motorola 68k emulation within qemu, and are what I used as a basis for my Google Summer of Code project to add NeXT hardware support to QEMU. Please don't crap flood the list with a series of 100 patches. Split things into logical chunks such that a series can be reasonably reviewed and applied. And I'm not sure this series of patches is ready for inclusion in qemu mainline as it should break existing m68k emulation... Bryce, you should only post your patches, refering to the repository on which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git , master branch. Regards, Laurent Regards, Anthony Liguori Bryce Lanham Alexander Paramonov (1): linux-user: Signals processing is not thread-safe. Andreas Schwab (3): m68k: add cas m68k: define fcntl constants m68k: add DBcc instruction. Laurent Vivier (106): linux-user: add qemu-wrapper linux-user: define default cpu model in configure instead of linux-user/main.c linux-user: specify the cpu model during configure linux-user,m68k: display default cpu linux-user: define new environment variables linux-user: define a script to set binfmt using debian flavored tools linux-user: define default cpu model in configure instead of linux-user/main.c m68k: add tcg_gen_debug_insn_start() m68k: define m680x0 CPUs and features m68k: add missing accessing modes for some instructions. m68k: add Motorola 680x0 family common instructions. m68k: add Scc instruction with memory operand. m68k: add DBcc instruction. m68k: modify movem instruction to manage word m68k: add 64bit divide. m68k: add 32bit and 64bit multiply m68k: add word data size for suba/adda m68k: add fpu m68k: add byte, word and memory shift m68k: add byte, word and memory rotate. m68k: add bitfield_mem, bitfield_reg m68k: add variable offset/width to bitfield_reg/bitfield_mem m68k: add cas m68k: allow fpu to manage double data type. m68k: allow fpu to manage double data type with fmove toea m68k: add FScc instruction m68k: add single data type to gen_ea m68k: add linkl instruction m68k: Add fmovecr m68k: correct typo on f64_to_i32() return type. m68k: improve CC_OP_LOGIC m68k: correct neg condition code flags computation Correct invalid use of const void * with const uint8_t * m68k: add EA support for negx m68k: add abcd instruction m68k: add sbcd instruction mm68k: add nbcd instruction m68k: set X flag according size of operand Set X flag correctly for addsub, arith_im, addsubq. m68k: on 0 bit shift, don't update X flag m68k: improve addx instructions Add (byte, word) opsize Add memory access m68k: improve subx,negx instructions Add (byte, word) opsize Add memory access (subx) m68k: improve asl/asr evaluate correclty the missing V flag m68k: use read_imm1() when it is possible m68k: correct shift side effect for roxrl and roxll m68k: asl/asr, clear C flag if shift count is 0 m68k: lsl/lsr, clear C flag if shift count is 0 m68k: correct divs.w and divu.w m68k: correct flags with negl m68k: for bitfield opcodes, correct operands corruption m68k: Correct bfclr in register case. m68k-linux-user: add '--enable-emulop' m68k: correctly compute divsl m68k: correctly compute divul m68k: add m68030 definition m68k: remove dead code m68k: remove useless file m68k-qreg.h m68k: FPU rework (draft) m68k: some FPU debugging macros m68k: more tests m68k: correct compute gen_bitfield_cc() m68k: add fgetexp m68k: add fscale m68k: correct addsubq m68k: add fetox and flogn m68k: initialize FRegs, define pickNaN() m68k: correct cmpa comparison datatype m68k: add flog10 m68k: add cmpm instruction m68k: add ftwotox instruction m68k: better fpu traces m68k: register source operand is always in extended size m68k: add facos instruction m68k: add ftan instruction m68k: add fsin instruction m68k: add fcos instruction m68k: correct fpcr update m68k: add fmod instruction m68k: flush flags before negx instruction. m68k: correct fmovemx FP registers order. m68k: add fatan instruction m68k: correct bfins instruction m68k: fcmp correctly compares infinity. m68k: allows bfins to manage correctly width = 32 m68k: add ftentox instruction m68k: correctly define and manage NaN m68k: don't call gdb_register_coprocessor() twice. m68k: gdb FP registers are 96 bits m68k: add exg instruction m68k: define floatx80_default_inf_high and floatx80_default_inf_low
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Le -10/01/-28163 20:59, Laurent Vivier a écrit : Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit : On 08/17/2011 03:46 PM, Bryce Lanham wrote: These patches greatly expand Motorola 68k emulation within qemu, and are what I used as a basis for my Google Summer of Code project to add NeXT hardware support to QEMU. Please don't crap flood the list with a series of 100 patches. Split things into logical chunks such that a series can be reasonably reviewed and applied. And I'm not sure this series of patches is ready for inclusion in qemu mainline as it should break existing m68k emulation... Bryce, you should only post your patches, refering to the repository on which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git , master branch. Btw, are you planning on merging it back someday? François.
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Le 18 août 2011 à 13:12, François Revol re...@free.fr a écrit : Le -10/01/-28163 20:59, Laurent Vivier a écrit : Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit : On 08/17/2011 03:46 PM, Bryce Lanham wrote: These patches greatly expand Motorola 68k emulation within qemu, and are what I used as a basis for my Google Summer of Code project to add NeXT hardware support to QEMU. Please don't crap flood the list with a series of 100 patches. Split things into logical chunks such that a series can be reasonably reviewed and applied. And I'm not sure this series of patches is ready for inclusion in qemu mainline as it should break existing m68k emulation... Bryce, you should only post your patches, refering to the repository on which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git , master branch. Btw, are you planning on merging it back someday? Yes... when it will work correctly. I have at least, to rework 680x0 FPU part (80bit fpu) to not break the existing one (64bit fpu). I have to check modified instructions don't break existing m68k emulation. Currently, I'm trying to port some parts of BasiliskII into Qemu to be able to boot MacOS 7.6. Regards, Laurent
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
On 08/17/2011 06:30 PM, Bryce Lanham wrote: Ugh, I'm sorry about that. This is why I should test before using unfamiliar tools. Someone suggested using git format-patch/git send-email instead of a big patch. That's definitely preferred actually, but you should look at breaking this into multiple logical/self-contained series for easier review/testing. Apologies, Bryce Lanham On Wed, Aug 17, 2011 at 5:35 PM, Anthony Liguorianth...@codemonkey.ws wrote: On 08/17/2011 03:46 PM, Bryce Lanham wrote: These patches greatly expand Motorola 68k emulation within qemu, and are what I used as a basis for my Google Summer of Code project to add NeXT hardware support to QEMU. Please don't crap flood the list with a series of 100 patches. Split things into logical chunks such that a series can be reasonably reviewed and applied. Regards, Anthony Liguori Bryce Lanham Alexander Paramonov (1): linux-user: Signals processing is not thread-safe. Andreas Schwab (3): m68k: add cas m68k: define fcntl constants m68k: add DBcc instruction. Laurent Vivier (106): linux-user: add qemu-wrapper linux-user: define default cpu model in configure instead of linux-user/main.c linux-user: specify the cpu model during configure linux-user,m68k: display default cpu linux-user: define new environment variables linux-user: define a script to set binfmt using debian flavored tools linux-user: define default cpu model in configure instead of linux-user/main.c m68k: add tcg_gen_debug_insn_start() m68k: define m680x0 CPUs and features m68k: add missing accessing modes for some instructions. m68k: add Motorola 680x0 family common instructions. m68k: add Scc instruction with memory operand. m68k: add DBcc instruction. m68k: modify movem instruction to manage word m68k: add 64bit divide. m68k: add 32bit and 64bit multiply m68k: add word data size for suba/adda m68k: add fpu m68k: add byte, word and memory shift m68k: add byte, word and memory rotate. m68k: add bitfield_mem, bitfield_reg m68k: add variable offset/width to bitfield_reg/bitfield_mem m68k: add cas m68k: allow fpu to manage double data type. m68k: allow fpu to manage double data type with fmove toea m68k: add FScc instruction m68k: add single data type to gen_ea m68k: add linkl instruction m68k: Add fmovecr m68k: correct typo on f64_to_i32() return type. m68k: improve CC_OP_LOGIC m68k: correct neg condition code flags computation Correct invalid use of const void * with const uint8_t * m68k: add EA support for negx m68k: add abcd instruction m68k: add sbcd instruction mm68k: add nbcd instruction m68k: set X flag according size of operand Set X flag correctly for addsub, arith_im, addsubq. m68k: on 0 bit shift, don't update X flag m68k: improve addx instructions Add (byte, word) opsize Add memory access m68k: improve subx,negx instructions Add (byte, word) opsize Add memory access (subx) m68k: improve asl/asr evaluate correclty the missing V flag m68k: use read_imm1() when it is possible m68k: correct shift side effect for roxrl and roxll m68k: asl/asr, clear C flag if shift count is 0 m68k: lsl/lsr, clear C flag if shift count is 0 m68k: correct divs.w and divu.w m68k: correct flags with negl m68k: for bitfield opcodes, correct operands corruption m68k: Correct bfclr in register case. m68k-linux-user: add '--enable-emulop' m68k: correctly compute divsl m68k: correctly compute divul m68k: add m68030 definition m68k: remove dead code m68k: remove useless file m68k-qreg.h m68k: FPU rework (draft) m68k: some FPU debugging macros m68k: more tests m68k: correct compute gen_bitfield_cc() m68k: add fgetexp m68k: add fscale m68k: correct addsubq m68k: add fetox and flogn m68k: initialize FRegs, define pickNaN() m68k: correct cmpa comparison datatype m68k: add flog10 m68k: add cmpm instruction m68k: add ftwotox instruction m68k: better fpu traces m68k: register source operand is always in extended size m68k: add facos instruction m68k: add ftan instruction m68k: add fsin instruction m68k: add fcos instruction m68k: correct fpcr update m68k: add fmod instruction m68k: flush flags before negx instruction. m68k: correct fmovemx FP registers order. m68k: add fatan instruction m68k: correct bfins instruction m68k: fcmp correctly compares infinity. m68k: allows bfins to manage correctly width = 32 m68k: add ftentox instruction m68k: correctly define and manage NaN m68k: don't call gdb_register_coprocessor() twice. m68k: gdb FP registers are 96 bits m68k: add exg instruction m68k: define floatx80_default_inf_high and floatx80_default_inf_low m68k: add bkpt instruction m68k: correctly convert floatx80-long double m68k: use expl() to compute exp_FP0()
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Hi Laurent, El 18/08/2011, a las 15:02, Laurent Vivier escribió: Le 18 août 2011 à 13:12, François Revol re...@free.fr a écrit : Le -10/01/-28163 20:59, Laurent Vivier a écrit : Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit : On 08/17/2011 03:46 PM, Bryce Lanham wrote: These patches greatly expand Motorola 68k emulation within qemu, and are what I used as a basis for my Google Summer of Code project to add NeXT hardware support to QEMU. Please don't crap flood the list with a series of 100 patches. Split things into logical chunks such that a series can be reasonably reviewed and applied. And I'm not sure this series of patches is ready for inclusion in qemu mainline as it should break existing m68k emulation... Bryce, you should only post your patches, refering to the repository on which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git , master branch. Btw, are you planning on merging it back someday? Yes... when it will work correctly. I have at least, to rework 680x0 FPU part (80bit fpu) to not break the existing one (64bit fpu). I have to check modified instructions don't break existing m68k emulation. Maybe Bryce can help you Currently, I'm trying to port some parts of BasiliskII into Qemu to be able to boot MacOS 7.6. Why are you planning to port a hack instead of making a full machine emulation? Regards, Laurent
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Le jeudi 18 août 2011 à 20:42 +0100, Natalia Portillo a écrit : Hi Laurent, Hi Natalia, El 18/08/2011, a las 15:02, Laurent Vivier escribió: Le 18 août 2011 à 13:12, François Revol re...@free.fr a écrit : Le -10/01/-28163 20:59, Laurent Vivier a écrit : Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit : On 08/17/2011 03:46 PM, Bryce Lanham wrote: These patches greatly expand Motorola 68k emulation within qemu, and are what I used as a basis for my Google Summer of Code project to add NeXT hardware support to QEMU. Please don't crap flood the list with a series of 100 patches. Split things into logical chunks such that a series can be reasonably reviewed and applied. And I'm not sure this series of patches is ready for inclusion in qemu mainline as it should break existing m68k emulation... Bryce, you should only post your patches, refering to the repository on which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git , master branch. Btw, are you planning on merging it back someday? Yes... when it will work correctly. I have at least, to rework 680x0 FPU part (80bit fpu) to not break the existing one (64bit fpu). I have to check modified instructions don't break existing m68k emulation. Maybe Bryce can help you I don't know if he is courageous enough to review and push 111 patches ;-) Currently, I'm trying to port some parts of BasiliskII into Qemu to be able to boot MacOS 7.6. Why are you planning to port a hack instead of making a full machine emulation? Because I'm lazy and dumb: the work is already done, I like cut'n'paste. Regards, Laurent
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Hi Laurent, El 18/08/2011, a las 20:57, Laurent Vivier escribió: Le jeudi 18 août 2011 à 20:42 +0100, Natalia Portillo a écrit : Hi Laurent, Hi Natalia, El 18/08/2011, a las 15:02, Laurent Vivier escribió: Le 18 août 2011 à 13:12, François Revol re...@free.fr a écrit : Le -10/01/-28163 20:59, Laurent Vivier a écrit : Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit : On 08/17/2011 03:46 PM, Bryce Lanham wrote: These patches greatly expand Motorola 68k emulation within qemu, and are what I used as a basis for my Google Summer of Code project to add NeXT hardware support to QEMU. Please don't crap flood the list with a series of 100 patches. Split things into logical chunks such that a series can be reasonably reviewed and applied. And I'm not sure this series of patches is ready for inclusion in qemu mainline as it should break existing m68k emulation... Bryce, you should only post your patches, refering to the repository on which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git , master branch. Btw, are you planning on merging it back someday? Yes... when it will work correctly. I have at least, to rework 680x0 FPU part (80bit fpu) to not break the existing one (64bit fpu). I have to check modified instructions don't break existing m68k emulation. Maybe Bryce can help you I don't know if he is courageous enough to review and push 111 patches ;-) He worked on emulating an abandoned, strange, difficult to get, and undocumented hardware, using your 111 patches, and finished it before the wholy more experienced MESS team. He is! xD Currently, I'm trying to port some parts of BasiliskII into Qemu to be able to boot MacOS 7.6. Why are you planning to port a hack instead of making a full machine emulation? Because I'm lazy and dumb: the work is already done, I like cut'n'paste. Yeah, you said it! The work is already done, we have all the hardware emulation that Basilisk substitutes for hacks. We only lack the 68k cpu (oh! your patches!!!) and the glue :p Please don't port Basilisk on top of TCG, I beg to you in the name of some god of your own choice :( (1000 Mb floppies patching .sony instead of implementing SCSI and SWIM, no ethernet controller but a working TCP/IP, oh hell, it's not a Mac, it's a Match!)
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Le jeudi 18 août 2011 à 21:13 +0100, Natalia Portillo a écrit : Hi Laurent, El 18/08/2011, a las 20:57, Laurent Vivier escribió: Le jeudi 18 août 2011 à 20:42 +0100, Natalia Portillo a écrit : Hi Laurent, Hi Natalia, El 18/08/2011, a las 15:02, Laurent Vivier escribió: Le 18 août 2011 à 13:12, François Revol re...@free.fr a écrit : Le -10/01/-28163 20:59, Laurent Vivier a écrit : Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit : On 08/17/2011 03:46 PM, Bryce Lanham wrote: These patches greatly expand Motorola 68k emulation within qemu, and are what I used as a basis for my Google Summer of Code project to add NeXT hardware support to QEMU. Please don't crap flood the list with a series of 100 patches. Split things into logical chunks such that a series can be reasonably reviewed and applied. And I'm not sure this series of patches is ready for inclusion in qemu mainline as it should break existing m68k emulation... Bryce, you should only post your patches, refering to the repository on which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git , master branch. Btw, are you planning on merging it back someday? Yes... when it will work correctly. I have at least, to rework 680x0 FPU part (80bit fpu) to not break the existing one (64bit fpu). I have to check modified instructions don't break existing m68k emulation. Maybe Bryce can help you I don't know if he is courageous enough to review and push 111 patches ;-) He worked on emulating an abandoned, strange, difficult to get, and undocumented hardware, using your 111 patches, and finished it before the wholy more experienced MESS team. The next-cube emulation is really working ? He is! xD There is no problem for me, he can do... Currently, I'm trying to port some parts of BasiliskII into Qemu to be able to boot MacOS 7.6. Why are you planning to port a hack instead of making a full machine emulation? Because I'm lazy and dumb: the work is already done, I like cut'n'paste. Yeah, you said it! The work is already done, we have all the hardware emulation that Basilisk substitutes for hacks. I'm not sure of that... no MMU emulation, no Nubus, no ethernet card, no video card, no SWIM, no SCSI, ... useless with a patched ROM. You know, nights are not long enough... We only lack the 68k cpu (oh! your patches!!!) and the glue :p this part is not working well as well ... gcc cannot compile linux kernel, some demos fail in gtk-demo, ... Please don't port Basilisk on top of TCG, I beg to you in the name of some god of your own choice :( I believe only in Santa Claus, and it's not Christmas. (1000 Mb floppies patching .sony instead of implementing SCSI and SWIM, no ethernet controller but a working TCP/IP, oh hell, it's not a Mac, it's a Match!) Regards, Laurent
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Hi, El 18/08/2011, a las 21:51, Laurent Vivier escribió: Le jeudi 18 août 2011 à 21:13 +0100, Natalia Portillo a écrit : Hi Laurent, El 18/08/2011, a las 20:57, Laurent Vivier escribió: Le jeudi 18 août 2011 à 20:42 +0100, Natalia Portillo a écrit : Hi Laurent, Hi Natalia, El 18/08/2011, a las 15:02, Laurent Vivier escribió: Le 18 août 2011 à 13:12, François Revol re...@free.fr a écrit : Le -10/01/-28163 20:59, Laurent Vivier a écrit : Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit : On 08/17/2011 03:46 PM, Bryce Lanham wrote: These patches greatly expand Motorola 68k emulation within qemu, and are what I used as a basis for my Google Summer of Code project to add NeXT hardware support to QEMU. Please don't crap flood the list with a series of 100 patches. Split things into logical chunks such that a series can be reasonably reviewed and applied. And I'm not sure this series of patches is ready for inclusion in qemu mainline as it should break existing m68k emulation... Bryce, you should only post your patches, refering to the repository on which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git , master branch. Btw, are you planning on merging it back someday? Yes... when it will work correctly. I have at least, to rework 680x0 FPU part (80bit fpu) to not break the existing one (64bit fpu). I have to check modified instructions don't break existing m68k emulation. Maybe Bryce can help you I don't know if he is courageous enough to review and push 111 patches ;-) He worked on emulating an abandoned, strange, difficult to get, and undocumented hardware, using your 111 patches, and finished it before the wholy more experienced MESS team. The next-cube emulation is really working ? Yes, it is, absolutely. He is! xD There is no problem for me, he can do... Currently, I'm trying to port some parts of BasiliskII into Qemu to be able to boot MacOS 7.6. Why are you planning to port a hack instead of making a full machine emulation? Because I'm lazy and dumb: the work is already done, I like cut'n'paste. Yeah, you said it! The work is already done, we have all the hardware emulation that Basilisk substitutes for hacks. I'm not sure of that... no MMU emulation, no Nubus, no ethernet card, no video card, no SWIM, no SCSI, ... useless with a patched ROM. Macs do not have videocards :p, only the Mac II and we're not forced to emulate that one. SWIM is a piece of cake that can be even implemented without ICs, just some logical arrays. NuBus is not required for almost anything, only the video card uses it, and it's present only on the Mac II, a stub will suffice to make Toolbox be happy. Most m68k didn't include a network card, third party ones are stock chips (probably almost all are NE2000, 3COM and PCNET), and Apple integrated ones are also stock, easy to do :p The MMU is your part I won't discuss on it. But porting BasiliskII will not make qemu have an m68k-system, but a macos7-wrapper. And that's the problem with Basilisk, that's why you cannot partition a disk, try MachTen, don't even think on A/UX. If you insist, please name it basilisk2 and let Bryce (he wants to in the future) do the real machines (-M quadra, -M centris, -M IIcx) You know, nights are not long enough... Move to North Pole, I've heard nights are six month long there ^^ We only lack the 68k cpu (oh! your patches!!!) and the glue :p this part is not working well as well ... gcc cannot compile linux kernel, some demos fail in gtk-demo, ... I know it's not perfect, but right now, it's better than nothing. There is no 68k cpu emulation complete afaik, I discussed with Ray Arachelian a lot on that when he was working on LisaEm. However emulators are live, Aranym, UAE, LisaEm, BasiliskII. qemu-m68k is quite complete to go live (when it does not break mcoldfire) right now. Bugs are easy to be corrected by more people when they are in main than in a developer's own clone. Leave your little kid go wild, it's old and big enough :p Please don't port Basilisk on top of TCG, I beg to you in the name of some god of your own choice :( I believe only in Santa Claus, and it's not Christmas. (1000 Mb floppies patching .sony instead of implementing SCSI and SWIM, no ethernet controller but a working TCP/IP, oh hell, it's not a Mac, it's a Match!) Regards, Laurent
[Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
These patches greatly expand Motorola 68k emulation within qemu, and are what I used as a basis for my Google Summer of Code project to add NeXT hardware support to QEMU. Bryce Lanham Alexander Paramonov (1): linux-user: Signals processing is not thread-safe. Andreas Schwab (3): m68k: add cas m68k: define fcntl constants m68k: add DBcc instruction. Laurent Vivier (106): linux-user: add qemu-wrapper linux-user: define default cpu model in configure instead of linux-user/main.c linux-user: specify the cpu model during configure linux-user,m68k: display default cpu linux-user: define new environment variables linux-user: define a script to set binfmt using debian flavored tools linux-user: define default cpu model in configure instead of linux-user/main.c m68k: add tcg_gen_debug_insn_start() m68k: define m680x0 CPUs and features m68k: add missing accessing modes for some instructions. m68k: add Motorola 680x0 family common instructions. m68k: add Scc instruction with memory operand. m68k: add DBcc instruction. m68k: modify movem instruction to manage word m68k: add 64bit divide. m68k: add 32bit and 64bit multiply m68k: add word data size for suba/adda m68k: add fpu m68k: add byte, word and memory shift m68k: add byte, word and memory rotate. m68k: add bitfield_mem, bitfield_reg m68k: add variable offset/width to bitfield_reg/bitfield_mem m68k: add cas m68k: allow fpu to manage double data type. m68k: allow fpu to manage double data type with fmove to ea m68k: add FScc instruction m68k: add single data type to gen_ea m68k: add linkl instruction m68k: Add fmovecr m68k: correct typo on f64_to_i32() return type. m68k: improve CC_OP_LOGIC m68k: correct neg condition code flags computation Correct invalid use of const void * with const uint8_t * m68k: add EA support for negx m68k: add abcd instruction m68k: add sbcd instruction mm68k: add nbcd instruction m68k: set X flag according size of operand Set X flag correctly for addsub, arith_im, addsubq. m68k: on 0 bit shift, don't update X flag m68k: improve addx instructions Add (byte, word) opsize Add memory access m68k: improve subx,negx instructions Add (byte, word) opsize Add memory access (subx) m68k: improve asl/asr evaluate correclty the missing V flag m68k: use read_imm1() when it is possible m68k: correct shift side effect for roxrl and roxll m68k: asl/asr, clear C flag if shift count is 0 m68k: lsl/lsr, clear C flag if shift count is 0 m68k: correct divs.w and divu.w m68k: correct flags with negl m68k: for bitfield opcodes, correct operands corruption m68k: Correct bfclr in register case. m68k-linux-user: add '--enable-emulop' m68k: correctly compute divsl m68k: correctly compute divul m68k: add m68030 definition m68k: remove dead code m68k: remove useless file m68k-qreg.h m68k: FPU rework (draft) m68k: some FPU debugging macros m68k: more tests m68k: correct compute gen_bitfield_cc() m68k: add fgetexp m68k: add fscale m68k: correct addsubq m68k: add fetox and flogn m68k: initialize FRegs, define pickNaN() m68k: correct cmpa comparison datatype m68k: add flog10 m68k: add cmpm instruction m68k: add ftwotox instruction m68k: better fpu traces m68k: register source operand is always in extended size m68k: add facos instruction m68k: add ftan instruction m68k: add fsin instruction m68k: add fcos instruction m68k: correct fpcr update m68k: add fmod instruction m68k: flush flags before negx instruction. m68k: correct fmovemx FP registers order. m68k: add fatan instruction m68k: correct bfins instruction m68k: fcmp correctly compares infinity. m68k: allows bfins to manage correctly width = 32 m68k: add ftentox instruction m68k: correctly define and manage NaN m68k: don't call gdb_register_coprocessor() twice. m68k: gdb FP registers are 96 bits m68k: add exg instruction m68k: define floatx80_default_inf_high and floatx80_default_inf_low m68k: add bkpt instruction m68k: correctly convert floatx80-long double m68k: use expl() to compute exp_FP0() m68k: use exp2l() to compute exp2_FP0() m68k: use logl() to compute ln_FP0() m68k: use log10l() to compute log10_FP0() m68k: correctly load signed word into floating point register m68k: add fcosh instruction m68k: add fasin instruction m68k: add fsincos instruction m68k: add fsinh instruction m68k: add ftanh instruction m68k: add flognp1 instruction m68k: add fatanh instruction m68k: first draft of q800 emulation (not working) m68k: add movec instruction m68k: move from sr can use effective addresse on m68k Peter Bjørn Jørgensen (1): m68k: Added ULL to 64 bit integer in helper.c
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
On 08/17/2011 03:46 PM, Bryce Lanham wrote: These patches greatly expand Motorola 68k emulation within qemu, and are what I used as a basis for my Google Summer of Code project to add NeXT hardware support to QEMU. Please don't crap flood the list with a series of 100 patches. Split things into logical chunks such that a series can be reasonably reviewed and applied. Regards, Anthony Liguori Bryce Lanham Alexander Paramonov (1): linux-user: Signals processing is not thread-safe. Andreas Schwab (3): m68k: add cas m68k: define fcntl constants m68k: add DBcc instruction. Laurent Vivier (106): linux-user: add qemu-wrapper linux-user: define default cpu model in configure instead of linux-user/main.c linux-user: specify the cpu model during configure linux-user,m68k: display default cpu linux-user: define new environment variables linux-user: define a script to set binfmt using debian flavored tools linux-user: define default cpu model in configure instead of linux-user/main.c m68k: add tcg_gen_debug_insn_start() m68k: define m680x0 CPUs and features m68k: add missing accessing modes for some instructions. m68k: add Motorola 680x0 family common instructions. m68k: add Scc instruction with memory operand. m68k: add DBcc instruction. m68k: modify movem instruction to manage word m68k: add 64bit divide. m68k: add 32bit and 64bit multiply m68k: add word data size for suba/adda m68k: add fpu m68k: add byte, word and memory shift m68k: add byte, word and memory rotate. m68k: add bitfield_mem, bitfield_reg m68k: add variable offset/width to bitfield_reg/bitfield_mem m68k: add cas m68k: allow fpu to manage double data type. m68k: allow fpu to manage double data type with fmove toea m68k: add FScc instruction m68k: add single data type to gen_ea m68k: add linkl instruction m68k: Add fmovecr m68k: correct typo on f64_to_i32() return type. m68k: improve CC_OP_LOGIC m68k: correct neg condition code flags computation Correct invalid use of const void * with const uint8_t * m68k: add EA support for negx m68k: add abcd instruction m68k: add sbcd instruction mm68k: add nbcd instruction m68k: set X flag according size of operand Set X flag correctly for addsub, arith_im, addsubq. m68k: on 0 bit shift, don't update X flag m68k: improve addx instructions Add (byte, word) opsize Add memory access m68k: improve subx,negx instructions Add (byte, word) opsize Add memory access (subx) m68k: improve asl/asr evaluate correclty the missing V flag m68k: use read_imm1() when it is possible m68k: correct shift side effect for roxrl and roxll m68k: asl/asr, clear C flag if shift count is 0 m68k: lsl/lsr, clear C flag if shift count is 0 m68k: correct divs.w and divu.w m68k: correct flags with negl m68k: for bitfield opcodes, correct operands corruption m68k: Correct bfclr in register case. m68k-linux-user: add '--enable-emulop' m68k: correctly compute divsl m68k: correctly compute divul m68k: add m68030 definition m68k: remove dead code m68k: remove useless file m68k-qreg.h m68k: FPU rework (draft) m68k: some FPU debugging macros m68k: more tests m68k: correct compute gen_bitfield_cc() m68k: add fgetexp m68k: add fscale m68k: correct addsubq m68k: add fetox and flogn m68k: initialize FRegs, define pickNaN() m68k: correct cmpa comparison datatype m68k: add flog10 m68k: add cmpm instruction m68k: add ftwotox instruction m68k: better fpu traces m68k: register source operand is always in extended size m68k: add facos instruction m68k: add ftan instruction m68k: add fsin instruction m68k: add fcos instruction m68k: correct fpcr update m68k: add fmod instruction m68k: flush flags before negx instruction. m68k: correct fmovemx FP registers order. m68k: add fatan instruction m68k: correct bfins instruction m68k: fcmp correctly compares infinity. m68k: allows bfins to manage correctly width = 32 m68k: add ftentox instruction m68k: correctly define and manage NaN m68k: don't call gdb_register_coprocessor() twice. m68k: gdb FP registers are 96 bits m68k: add exg instruction m68k: define floatx80_default_inf_high and floatx80_default_inf_low m68k: add bkpt instruction m68k: correctly convert floatx80-long double m68k: use expl() to compute exp_FP0() m68k: use exp2l() to compute exp2_FP0() m68k: use logl() to compute ln_FP0() m68k: use log10l() to compute log10_FP0() m68k: correctly load signed word into floating point register m68k: add fcosh instruction m68k: add fasin instruction m68k: add fsincos instruction m68k: add fsinh instruction m68k: add ftanh instruction m68k: add flognp1 instruction m68k: add fatanh instruction m68k: first draft of q800 emulation (not working)
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Ugh, I'm sorry about that. This is why I should test before using unfamiliar tools. Someone suggested using git format-patch/git send-email instead of a big patch. Apologies, Bryce Lanham On Wed, Aug 17, 2011 at 5:35 PM, Anthony Liguori anth...@codemonkey.ws wrote: On 08/17/2011 03:46 PM, Bryce Lanham wrote: These patches greatly expand Motorola 68k emulation within qemu, and are what I used as a basis for my Google Summer of Code project to add NeXT hardware support to QEMU. Please don't crap flood the list with a series of 100 patches. Split things into logical chunks such that a series can be reasonably reviewed and applied. Regards, Anthony Liguori Bryce Lanham Alexander Paramonov (1): linux-user: Signals processing is not thread-safe. Andreas Schwab (3): m68k: add cas m68k: define fcntl constants m68k: add DBcc instruction. Laurent Vivier (106): linux-user: add qemu-wrapper linux-user: define default cpu model in configure instead of linux-user/main.c linux-user: specify the cpu model during configure linux-user,m68k: display default cpu linux-user: define new environment variables linux-user: define a script to set binfmt using debian flavored tools linux-user: define default cpu model in configure instead of linux-user/main.c m68k: add tcg_gen_debug_insn_start() m68k: define m680x0 CPUs and features m68k: add missing accessing modes for some instructions. m68k: add Motorola 680x0 family common instructions. m68k: add Scc instruction with memory operand. m68k: add DBcc instruction. m68k: modify movem instruction to manage word m68k: add 64bit divide. m68k: add 32bit and 64bit multiply m68k: add word data size for suba/adda m68k: add fpu m68k: add byte, word and memory shift m68k: add byte, word and memory rotate. m68k: add bitfield_mem, bitfield_reg m68k: add variable offset/width to bitfield_reg/bitfield_mem m68k: add cas m68k: allow fpu to manage double data type. m68k: allow fpu to manage double data type with fmove toea m68k: add FScc instruction m68k: add single data type to gen_ea m68k: add linkl instruction m68k: Add fmovecr m68k: correct typo on f64_to_i32() return type. m68k: improve CC_OP_LOGIC m68k: correct neg condition code flags computation Correct invalid use of const void * with const uint8_t * m68k: add EA support for negx m68k: add abcd instruction m68k: add sbcd instruction mm68k: add nbcd instruction m68k: set X flag according size of operand Set X flag correctly for addsub, arith_im, addsubq. m68k: on 0 bit shift, don't update X flag m68k: improve addx instructions Add (byte, word) opsize Add memory access m68k: improve subx,negx instructions Add (byte, word) opsize Add memory access (subx) m68k: improve asl/asr evaluate correclty the missing V flag m68k: use read_imm1() when it is possible m68k: correct shift side effect for roxrl and roxll m68k: asl/asr, clear C flag if shift count is 0 m68k: lsl/lsr, clear C flag if shift count is 0 m68k: correct divs.w and divu.w m68k: correct flags with negl m68k: for bitfield opcodes, correct operands corruption m68k: Correct bfclr in register case. m68k-linux-user: add '--enable-emulop' m68k: correctly compute divsl m68k: correctly compute divul m68k: add m68030 definition m68k: remove dead code m68k: remove useless file m68k-qreg.h m68k: FPU rework (draft) m68k: some FPU debugging macros m68k: more tests m68k: correct compute gen_bitfield_cc() m68k: add fgetexp m68k: add fscale m68k: correct addsubq m68k: add fetox and flogn m68k: initialize FRegs, define pickNaN() m68k: correct cmpa comparison datatype m68k: add flog10 m68k: add cmpm instruction m68k: add ftwotox instruction m68k: better fpu traces m68k: register source operand is always in extended size m68k: add facos instruction m68k: add ftan instruction m68k: add fsin instruction m68k: add fcos instruction m68k: correct fpcr update m68k: add fmod instruction m68k: flush flags before negx instruction. m68k: correct fmovemx FP registers order. m68k: add fatan instruction m68k: correct bfins instruction m68k: fcmp correctly compares infinity. m68k: allows bfins to manage correctly width = 32 m68k: add ftentox instruction m68k: correctly define and manage NaN m68k: don't call gdb_register_coprocessor() twice. m68k: gdb FP registers are 96 bits m68k: add exg instruction m68k: define floatx80_default_inf_high and floatx80_default_inf_low m68k: add bkpt instruction m68k: correctly convert floatx80-long double m68k: use expl() to compute exp_FP0() m68k: use exp2l() to compute exp2_FP0() m68k: use logl() to compute ln_FP0() m68k: use log10l() to compute log10_FP0() m68k: correctly load signed word into floating point register
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
On 18 August 2011 00:30, Bryce Lanham blan...@gmail.com wrote: Ugh, I'm sorry about that. This is why I should test before using unfamiliar tools. Someone suggested using git format-patch/git send-email instead of a big patch. git send-email has a --dry-run option which I commend to your attention :-) -- PMM
