From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.5-pre1 X-Received: by 2002:a37:a746:: with SMTP id q67mr27155032qke.93.1595927818903; Tue, 28 Jul 2020 02:16:58 -0700 (PDT) X-Received: by 2002:a05:620a:9db:: with SMTP id y27mr9072288qky.179.1595927818704; Tue, 28 Jul 2020 02:16:58 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.uzoreto.com!feeder1.cambriumusenet.nl!feed.tweak.nl!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 28 Jul 2020 02:16:58 -0700 (PDT) In-Reply-To: <79d9a1d0-8735-460e-a648-c2a27e35a700n@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=95.250.125.238; posting-account=JRF_-woAAABYlsAtkCl_CUxBuQy2SsaQ NNTP-Posting-Host: 95.250.125.238 References: <748b7abb-4bda-4174-aa37-367daaf1c02ao@googlegroups.com> <6cbf26a5-2047-4685-a87b-381bc5fedd5bo@googlegroups.com> <4472b2d0-e872-46c9-8665-af1fea1cc8c4n@googlegroups.com> <62b1618d-e93d-42f4-9970-314685e2c01ao@googlegroups.com> <1603a778-dc76-4c82-88f2-872212871b65n@googlegroups.com> <62b36d1a-6d2c-4c79-a335-20546225544co@googlegroups.com> <79d9a1d0-8735-460e-a648-c2a27e35a700n@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <40d7501a-9b4e-4cbd-a59d-cc0aa858c8e1o@googlegroups.com> Subject: Re: SweetAda 0.1e released From: gabriele.galeotti.xyz@gmail.com Injection-Date: Tue, 28 Jul 2020 09:16:58 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:59565 List-Id: On Tuesday, July 28, 2020 at 2:06:46 AM UTC+2, Roger Mc wrote: > On Tuesday, July 28, 2020 at 2:04:52 AM UTC+10, gabriele.g...@gmail.com w= rote: > > In sweetada context, QEMU is a more or less normal QEMU that is used as= an aid in development. e.g.,if you want to try sweetada code on a MIPS cpu= , or a PowerPC, maybe it is better to exercise on an virtual machine. That'= s why exists a QEMU. QEMU is patched so that every machine it could emulate= s has additional I/Os that normally do not exist in that machine. Like a ge= neric I/O card inside a computer. For example, if you choose a SPARC cpu (a= n thus an emulated machine like a SPARCstation5), it is difficult to have i= mmediate evidence, because you have to low-level program a huge number of t= hings, like the video framebuffer. Instead, you manipulate those simple I/O= and IOEMU lets you visualize them on his own window. QEMU package is a nor= mal QEMU distribution (apart the patches, that I have to make public soon, = just the time to adjust them in a decent form), and IOEMU is an indipendent= library added inside the distribution, but it's nothing more that a GUI ma= nager for widgets, together with a parser for ioemu.cfg configuration files= . Again I will release the source once that the code is cleaned up and stab= le. I make huge changes everyday, and don't want ugly things spreading off = the net.=20 > >=20 > > By the way, you can run QEMU without IOEMU, just delete the library fil= e. Then supply QEMU with your own firmware by standard command line options= . QEMU for sweetada has nothing different.=20 > >=20 > > To be honest, if you want to study QEMU from a low-level point of view,= prepare yourself for a long journey. It's incredibly complicated. And Swee= tada does help you very little in doing that. The focus of sweetada is curr= ently to adapt Ada code to machines.=20 > >=20 > > G >=20 > Great! I finally get the picture (well, almost). > QEMU is /opt/sweetada/bin/qemu-system-x86_64 which starts up like a DOS P= C, booting from ROM and running until it can't find a bootable device. > Also, the QEMU-AArch64 directory gives me plenty of clues. >=20 > My idea is certainly, not to study QEMU from a low-level point of view bu= t to understand its use in the context of sweetada and to understand the ad= aption of Ada code to machines. > My planned first job is to completely identify and understand all interfa= ces between sweetada and QEMU. Well, absolutely. The flow is the following: - make all -> kernel.elf creation - make postbuild --> kernel.rom ROM BIOS image (or whatever is used by the = target) - make run --> execute the "RUN_COMMAND" specified in configuration.in - in the case of PC-x86-64, runsweetada is called - runsweetada parses the START section of ioemu.cfg and executes QEMU for a= PC x86-64 - qemu-system-x86_64 starts, it loads the ROM BIOS image and the emulated C= PU runs sweetada code - if the IOEMU library is present, it parses ioemu.cfg again, looking into = I/O and serialport sections, creates the IOEMU window that displays physica= l I/O ports and starts terminals connected to the serialports of the emulat= ed machine In the case of QEMU-AArch64 nothing changes, obviously the system code is d= ifferent and qemu-system-aarch64 is called. You do not see anything in the = QEMU window because a fictional board gets emulated, which does not have a = VGA screen, only CPU, RAM and some undisplayable peripherals. The image pro= duced by sweetada is not a true ROM image because this fictional board does= not have an easily mappable ROM, so it directly loads the kernel.elf objec= t. Regards