SweetAda 0.1e released

SweetAda 0.1e released

[gabriele.galeotti.xyz]

Hi all. I've just released SweetAda 01.e.

Go to http://www.sweetada.org and download the archive. RTS and LibGCC packages are still valid @ 0.1c.

- general cleanup and cosmetics
- general infrastructure improvements
- QEMU-RISC-V-32 target can do serial output in a terminal
- IntegratorCP target uses LCD VGA
- Malta MIPS target uses a VGA PCI board
- handling of directories in the cpus hierarchy, which allows selective unit overriding
- Insight can be called as a toolchain component
- IOEMU configuration files are now fully consistent

Next days I will to concentrate on generic low-level CPU support, documentation, and restructuring of some redundant units. Let me know, feedback is highly appreciated.

G

Re: SweetAda 0.1e released

[Roger]

On Thursday, July 23, 2020 at 4:03:06 AM UTC+10, gabriele....@gmail.com wrote:
> Hi all. I've just released SweetAda 01.e.
> 
> Go to http://www.sweetada.org and download the archive. RTS and LibGCC packages are still valid @ 0.1c.
> 
> - general cleanup and cosmetics
> - general infrastructure improvements
> - QEMU-RISC-V-32 target can do serial output in a terminal
> - IntegratorCP target uses LCD VGA
> - Malta MIPS target uses a VGA PCI board
> - handling of directories in the cpus hierarchy, which allows selective unit overriding
> - Insight can be called as a toolchain component
> - IOEMU configuration files are now fully consistent
> 
> Next days I will to concentrate on generic low-level CPU support, documentation, and restructuring of some redundant units. Let me know, feedback is highly appreciated.
> 
> G
I have not been able to build with 1e  menu.sh.
The make case statement in menu.sh seems to not get activated.
In particular, no kernel.cfg file is generated.
I copied the make statements from 1d into the 1e  menu.sh  and make occurred until:

[RANLIB]     libplatform.a
[GPRBUILD-C] build.gpr
[GPRBUILD-B] build.gpr
gprbuild: unable to find binder driver /opt/sweetada/libexec/gprbuild/gprbind
make: *** [Makefile:586: kernel_compile_gpr] Error 4

PC-x86-64: start kernel build.

[GPRBUILD-C] build.gpr
[GPRBUILD-B] build.gpr
gprbuild: unable to find binder driver /opt/sweetada/libexec/gprbuild/gprbind
make: *** [Makefile:586: kernel_compile_gpr] Error 4

After this I removed the 1d statements and tried the original 1e menu.sh.
As before ./menu.sh generated nothing.
But I individual menu targets worked from all-clean through configure then
menu.sh all failed with same error:

[RANLIB]     libplatform.a
[GPRBUILD-C] build.gpr
[GPRBUILD-B] build.gpr
gprbuild: unable to find binder driver /opt/sweetada/libexec/gprbuild/gprbind
make: *** [Makefile:586: kernel_compile_gpr] Error 4

Re: SweetAda 0.1e released

[gabriele.galeotti.xyz]

On Saturday, July 25, 2020 at 3:44:57 PM UTC+2, Roger wrote:
> On Thursday, July 23, 2020 at 4:03:06 AM UTC+10, gabriele....@gmail.com wrote:
> > Hi all. I've just released SweetAda 01.e.
> > 
> > Go to http://www.sweetada.org and download the archive. RTS and LibGCC packages are still valid @ 0.1c.
> > 
> > - general cleanup and cosmetics
> > - general infrastructure improvements
> > - QEMU-RISC-V-32 target can do serial output in a terminal
> > - IntegratorCP target uses LCD VGA
> > - Malta MIPS target uses a VGA PCI board
> > - handling of directories in the cpus hierarchy, which allows selective unit overriding
> > - Insight can be called as a toolchain component
> > - IOEMU configuration files are now fully consistent
> > 
> > Next days I will to concentrate on generic low-level CPU support, documentation, and restructuring of some redundant units. Let me know, feedback is highly appreciated.
> > 
> > G
> I have not been able to build with 1e  menu.sh.
> The make case statement in menu.sh seems to not get activated.
> In particular, no kernel.cfg file is generated.
> I copied the make statements from 1d into the 1e  menu.sh  and make occurred until:
> 
> [RANLIB]     libplatform.a
> [GPRBUILD-C] build.gpr
> [GPRBUILD-B] build.gpr
> gprbuild: unable to find binder driver /opt/sweetada/libexec/gprbuild/gprbind
> make: *** [Makefile:586: kernel_compile_gpr] Error 4
> 
> PC-x86-64: start kernel build.
> 
> [GPRBUILD-C] build.gpr
> [GPRBUILD-B] build.gpr
> gprbuild: unable to find binder driver /opt/sweetada/libexec/gprbuild/gprbind
> make: *** [Makefile:586: kernel_compile_gpr] Error 4
> 
> After this I removed the 1d statements and tried the original 1e menu.sh.
> As before ./menu.sh generated nothing.
> But I individual menu targets worked from all-clean through configure then
> menu.sh all failed with same error:
> 
> [RANLIB]     libplatform.a
> [GPRBUILD-C] build.gpr
> [GPRBUILD-B] build.gpr
> gprbuild: unable to find binder driver /opt/sweetada/libexec/gprbuild/gprbind
> make: *** [Makefile:586: kernel_compile_gpr] Error 4

Hi Roger.

Sounds very strange.

1) ----------------------------------------------------------------------

Every executable of the "gprbuild set" has no dependency other than system libraries, so it should not be a library problem (and gprbuild seems running fine because of the steps carried out); gprbind is in another directory, not bin/ but libexec/gprbuild/, relative to the prefix, and gets called by the executable gprbuild.

Could you try to dry-run gprbind directly from the shell? My result is:

gabriele-iMac:sweetada-0.1e root# /opt/sweetada/libexec/gprbuild/gprbind
gprbind: incorrect invocation

(yes, it's an error, but shown by gprbind because it gets no arguments, currently it gets executed fine).

2) -------------------------------------------------------------------

The only difference in menu.sh, 0.1d vs 0.1e, is an "if" test:

0.1d:

   MAKE=/opt/sweetada/bin/make

0.1e:
    SWEETADA_MAKE=/opt/sweetada/bin/make
    if [ -e ${SWEETADA_MAKE} ] ; then
      MAKE=${SWEETADA_MAKE}
    else
      MAKE=make

(I've put a "guess" test to switch to a system make in case). The only reason could be the "-e" test failing. So the shell is not able to find SweetAda's make.

-----------------------------------------------------------------------

If we put together 1) and 2), I would say that maybe your system could have problems in finding executables. Perhaps you have some sort of anti-virus installed? Or, maybe new OSX have restrictive policies in finding them.

Unfortunately gprbuild is a direct build out of AC repository, and it is complicated to go deep in the code.

Try to comment out BUILD_MODE := GPR in the configuration.in, so maybe you are able to successfully build with the standard procedure.

Let's investigate further, let me know.

Re: SweetAda 0.1e released

[gabriele.galeotti.xyz]

On Saturday, July 25, 2020 at 3:44:57 PM UTC+2, Roger wrote:
> On Thursday, July 23, 2020 at 4:03:06 AM UTC+10, gabriele....@gmail.com wrote:
> > Hi all. I've just released SweetAda 01.e.
> > 
> > Go to http://www.sweetada.org and download the archive. RTS and LibGCC packages are still valid @ 0.1c.
> > 
> > - general cleanup and cosmetics
> > - general infrastructure improvements
> > - QEMU-RISC-V-32 target can do serial output in a terminal
> > - IntegratorCP target uses LCD VGA
> > - Malta MIPS target uses a VGA PCI board
> > - handling of directories in the cpus hierarchy, which allows selective unit overriding
> > - Insight can be called as a toolchain component
> > - IOEMU configuration files are now fully consistent
> > 
> > Next days I will to concentrate on generic low-level CPU support, documentation, and restructuring of some redundant units. Let me know, feedback is highly appreciated.
> > 
> > G
> I have not been able to build with 1e  menu.sh.
> The make case statement in menu.sh seems to not get activated.
> In particular, no kernel.cfg file is generated.
> I copied the make statements from 1d into the 1e  menu.sh  and make occurred until:
> 
> [RANLIB]     libplatform.a
> [GPRBUILD-C] build.gpr
> [GPRBUILD-B] build.gpr
> gprbuild: unable to find binder driver /opt/sweetada/libexec/gprbuild/gprbind
> make: *** [Makefile:586: kernel_compile_gpr] Error 4
> 
> PC-x86-64: start kernel build.
> 
> [GPRBUILD-C] build.gpr
> [GPRBUILD-B] build.gpr
> gprbuild: unable to find binder driver /opt/sweetada/libexec/gprbuild/gprbind
> make: *** [Makefile:586: kernel_compile_gpr] Error 4
> 
> After this I removed the 1d statements and tried the original 1e menu.sh.
> As before ./menu.sh generated nothing.
> But I individual menu targets worked from all-clean through configure then
> menu.sh all failed with same error:
> 
> [RANLIB]     libplatform.a
> [GPRBUILD-C] build.gpr
> [GPRBUILD-B] build.gpr
> gprbuild: unable to find binder driver /opt/sweetada/libexec/gprbuild/gprbind
> make: *** [Makefile:586: kernel_compile_gpr] Error 4

Ah, sorry, I forget the kernel.cfg problem.

Are you sure you carry out the right steps? Here a little recap:
1)
edit menu.sh and choose your target by uncommenting it, leave the others commented
2)
execute in the shell "./menu.sh all-clean"
3)
execute in the shell "./menu.sh createkernelcfg"
Some file gets installed, and you should find a proper configured kernel.cfg. Double check. It should replicate your target by means of two variables.
4)
execute in the shell "./menu.sh configure"
You should get a list of parameters.
5)
execute in the shell "./menu.sh all"
Compilation of files.

Let me know if you note something strange.

Re: SweetAda 0.1e released

[Roger Mc]

On Sunday, July 26, 2020 at 2:17:42 AM UTC+10, gabriele.g...@gmail.com wrote:
> On Saturday, July 25, 2020 at 3:44:57 PM UTC+2, Roger wrote:
> > On Thursday, July 23, 2020 at 4:03:06 AM UTC+10, gabriele....@gmail.com wrote: 
> > > Hi all. I've just released SweetAda 01.e. 
> > > 
> > > Go to http://www.sweetada.org and download the archive. RTS and LibGCC packages are still valid @ 0.1c. 
> > > 
> > > - general cleanup and cosmetics 
> > > - general infrastructure improvements 
> > > - QEMU-RISC-V-32 target can do serial output in a terminal 
> > > - IntegratorCP target uses LCD VGA 
> > > - Malta MIPS target uses a VGA PCI board 
> > > - handling of directories in the cpus hierarchy, which allows selective unit overriding 
> > > - Insight can be called as a toolchain component 
> > > - IOEMU configuration files are now fully consistent 
> > > 
> > > Next days I will to concentrate on generic low-level CPU support, documentation, and restructuring of some redundant units. Let me know, feedback is highly appreciated. 
> > > 
> > > G 
> > I have not been able to build with 1e menu.sh. 
> > The make case statement in menu.sh seems to not get activated. 
> > In particular, no kernel.cfg file is generated. 
> > I copied the make statements from 1d into the 1e menu.sh and make occurred until: 
> > 
> > [RANLIB] libplatform.a 
> > [GPRBUILD-C] build.gpr 
> > [GPRBUILD-B] build.gpr 
> > gprbuild: unable to find binder driver /opt/sweetada/libexec/gprbuild/gprbind 
> > make: *** [Makefile:586: kernel_compile_gpr] Error 4 
> > 
> > PC-x86-64: start kernel build. 
> > 
> > [GPRBUILD-C] build.gpr 
> > [GPRBUILD-B] build.gpr 
> > gprbuild: unable to find binder driver /opt/sweetada/libexec/gprbuild/gprbind 
> > make: *** [Makefile:586: kernel_compile_gpr] Error 4 
> > 
> > After this I removed the 1d statements and tried the original 1e menu.sh. 
> > As before ./menu.sh generated nothing. 
> > But I individual menu targets worked from all-clean through configure then 
> > menu.sh all failed with same error: 
> > 
> > [RANLIB] libplatform.a 
> > [GPRBUILD-C] build.gpr 
> > [GPRBUILD-B] build.gpr 
> > gprbuild: unable to find binder driver /opt/sweetada/libexec/gprbuild/gprbind 
> > make: *** [Makefile:586: kernel_compile_gpr] Error 4
> Ah, sorry, I forget the kernel.cfg problem. 
> 
> Are you sure you carry out the right steps? Here a little recap: 
> 1) 
> edit menu.sh and choose your target by uncommenting it, leave the others commented 
> 2) 
> execute in the shell "./menu.sh all-clean" 
> 3) 
> execute in the shell "./menu.sh createkernelcfg" 
> Some file gets installed, and you should find a proper configured kernel.cfg. Double check. It should replicate your target by means of two variables. 
> 4) 
> execute in the shell "./menu.sh configure" 
> You should get a list of parameters. 
> 5) 
> execute in the shell "./menu.sh all" 
> Compilation of files. 
> 
> Let me know if you note something strange.

I reinstalled 0.1e and now it works, at least to the extent that 0.1d works.
Quite strange as I had the same problem on both my computers.
The only thing that I can think of is that on the previous 01e install I just used
./menu.sh  ( without target selection)
which was the method I used for 0.1d. Perhaps this messed something up?
When that didn't work, I inspected 0.1e menu.sh and discovered the need to use target selection;
however, on using target selection, in the order stated in your advice (perhaps eventually), I had the reported problem.
It seems, somehow I messed something up; somehow on both computers!
Thanks for your much appreciated advice.

I still haven't tracked down the Catalina problem. Inspiration comes slowly.
Certainly, the Ada code is working correctly but, somehow the assembly coded outb instructions in x86_64-io don't seem to be having any effect.
Possibly being blocked by Catalina security features?
I currently don't know how to track outb functionality.
I'll keep trying (slooowly)

Re: SweetAda 0.1e released

[Roger Mc]

On Sunday, July 26, 2020 at 11:51:41 AM UTC+10, Roger Mc wrote:

> I still haven't tracked down the Catalina problem. Inspiration comes slowly. 
> Certainly, the Ada code is working correctly but, somehow the assembly coded outb instructions in x86_64-io don't seem to be having any effect. 
> Possibly being blocked by Catalina security features? 
> I currently don't know how to track outb functionality. 
> I'll keep trying (slooowly)
To get better familiarity, I've done some assembler "practice" with nasm and
have installed MPlab X to get some experience interfacing to PICs.

Re: SweetAda 0.1e released

[gabriele.galeotti.xyz]

On Sunday, July 26, 2020 at 3:17:46 PM UTC+2, Roger Mc wrote:
> On Sunday, July 26, 2020 at 11:51:41 AM UTC+10, Roger Mc wrote:
> 
> > I still haven't tracked down the Catalina problem. Inspiration comes slowly. 
> > Certainly, the Ada code is working correctly but, somehow the assembly coded outb instructions in x86_64-io don't seem to be having any effect. 
> > Possibly being blocked by Catalina security features? 
> > I currently don't know how to track outb functionality. 
> > I'll keep trying (slooowly)
> To get better familiarity, I've done some assembler "practice" with nasm and
> have installed MPlab X to get some experience interfacing to PICs.

Nice.

I plan (in the looooong term) to support PICs, but only those with MIPS core, since I have already something. I hope this is your case.

I forgot from last reply, if you decide to do a new installation from scratch, please wait next release, I put some little diagnostics in menu.sh in order to show sensible environment variables, so you can see at once if the script is working well.

Best regards

Re: SweetAda 0.1e released

[gabriele.galeotti.xyz]

On Sunday, July 26, 2020 at 3:51:41 AM UTC+2, Roger Mc wrote:
> On Sunday, July 26, 2020 at 2:17:42 AM UTC+10, gabriele.g...@gmail.com wrote:
> > On Saturday, July 25, 2020 at 3:44:57 PM UTC+2, Roger wrote:
> > > On Thursday, July 23, 2020 at 4:03:06 AM UTC+10, gabriele....@gmail.com wrote: 
> > > > Hi all. I've just released SweetAda 01.e. 
> > > > 
> > > > Go to http://www.sweetada.org and download the archive. RTS and LibGCC packages are still valid @ 0.1c. 
> > > > 
> > > > - general cleanup and cosmetics 
> > > > - general infrastructure improvements 
> > > > - QEMU-RISC-V-32 target can do serial output in a terminal 
> > > > - IntegratorCP target uses LCD VGA 
> > > > - Malta MIPS target uses a VGA PCI board 
> > > > - handling of directories in the cpus hierarchy, which allows selective unit overriding 
> > > > - Insight can be called as a toolchain component 
> > > > - IOEMU configuration files are now fully consistent 
> > > > 
> > > > Next days I will to concentrate on generic low-level CPU support, documentation, and restructuring of some redundant units. Let me know, feedback is highly appreciated. 
> > > > 
> > > > G 
> > > I have not been able to build with 1e menu.sh. 
> > > The make case statement in menu.sh seems to not get activated. 
> > > In particular, no kernel.cfg file is generated. 
> > > I copied the make statements from 1d into the 1e menu.sh and make occurred until: 
> > > 
> > > [RANLIB] libplatform.a 
> > > [GPRBUILD-C] build.gpr 
> > > [GPRBUILD-B] build.gpr 
> > > gprbuild: unable to find binder driver /opt/sweetada/libexec/gprbuild/gprbind 
> > > make: *** [Makefile:586: kernel_compile_gpr] Error 4 
> > > 
> > > PC-x86-64: start kernel build. 
> > > 
> > > [GPRBUILD-C] build.gpr 
> > > [GPRBUILD-B] build.gpr 
> > > gprbuild: unable to find binder driver /opt/sweetada/libexec/gprbuild/gprbind 
> > > make: *** [Makefile:586: kernel_compile_gpr] Error 4 
> > > 
> > > After this I removed the 1d statements and tried the original 1e menu.sh. 
> > > As before ./menu.sh generated nothing. 
> > > But I individual menu targets worked from all-clean through configure then 
> > > menu.sh all failed with same error: 
> > > 
> > > [RANLIB] libplatform.a 
> > > [GPRBUILD-C] build.gpr 
> > > [GPRBUILD-B] build.gpr 
> > > gprbuild: unable to find binder driver /opt/sweetada/libexec/gprbuild/gprbind 
> > > make: *** [Makefile:586: kernel_compile_gpr] Error 4
> > Ah, sorry, I forget the kernel.cfg problem. 
> > 
> > Are you sure you carry out the right steps? Here a little recap: 
> > 1) 
> > edit menu.sh and choose your target by uncommenting it, leave the others commented 
> > 2) 
> > execute in the shell "./menu.sh all-clean" 
> > 3) 
> > execute in the shell "./menu.sh createkernelcfg" 
> > Some file gets installed, and you should find a proper configured kernel.cfg. Double check. It should replicate your target by means of two variables. 
> > 4) 
> > execute in the shell "./menu.sh configure" 
> > You should get a list of parameters. 
> > 5) 
> > execute in the shell "./menu.sh all" 
> > Compilation of files. 
> > 
> > Let me know if you note something strange.
> 
> I reinstalled 0.1e and now it works, at least to the extent that 0.1d works.
> Quite strange as I had the same problem on both my computers.
> The only thing that I can think of is that on the previous 01e install I just used
> ./menu.sh  ( without target selection)
> which was the method I used for 0.1d. Perhaps this messed something up?
> When that didn't work, I inspected 0.1e menu.sh and discovered the need to use target selection;
> however, on using target selection, in the order stated in your advice (perhaps eventually), I had the reported problem.
> It seems, somehow I messed something up; somehow on both computers!
> Thanks for your much appreciated advice.
> 
> I still haven't tracked down the Catalina problem. Inspiration comes slowly.
> Certainly, the Ada code is working correctly but, somehow the assembly coded outb instructions in x86_64-io don't seem to be having any effect.
> Possibly being blocked by Catalina security features?
> I currently don't know how to track outb functionality.
> I'll keep trying (slooowly)

Hi Roger.

Fine, the most important thing is that we have verified that tools run correctly. Maybe it could be useful to delete everything (after a backup) and repeat a fresh installation, so you could check that you have a perfectly aligned layout, without previous mistakes.

Correct me if I'm wrong, I understood that IOEMU window is working and shows I/O widgets cycling, but not in Catalina, is that correct?

In this case maybe there is either a problem in the GUI code or in Catalina handling of windows.

But you can assume safely that Ada code is working since you should see some output in serial terminal.

About the outb instruction, please explain me (even writing down your code) what you are trying to do. outb instructions should behave fine, otherwise you should see a totally dead system.

By the way, apologies if I repeat myself, but try to isolate your code in an application file like the standard one, I'm changing some with/use and simplify units, so expect some minor changes in future release. This way you can change very little in your code. For example, unit x86_64.IO is likely to change in CPU.IO. Ask me if you have difficulties recompiling your code.

Let me know.

Re: SweetAda 0.1e released

[Roger Mc]

On Monday, July 27, 2020 at 8:51:55 PM UTC+10, gabriele.g...@gmail.com wrote:
> On Sunday, July 26, 2020 at 3:51:41 AM UTC+2, Roger Mc wrote: 
> > I reinstalled 0.1e and now it works, at least to the extent that 0.1d works. 
> > Quite strange as I had the same problem on both my computers. 
> > The only thing that I can think of is that on the previous 01e install I just used 
> > ./menu.sh ( without target selection) 
> > which was the method I used for 0.1d. Perhaps this messed something up? 
> > When that didn't work, I inspected 0.1e menu.sh and discovered the need to use target selection; 
> > however, on using target selection, in the order stated in your advice (perhaps eventually), I had the reported problem. 
> > It seems, somehow I messed something up; somehow on both computers! 
> > Thanks for your much appreciated advice. 
> > 
> > I still haven't tracked down the Catalina problem. Inspiration comes slowly. 
> > Certainly, the Ada code is working correctly but, somehow the assembly coded outb instructions in x86_64-io don't seem to be having any effect. 
> > Possibly being blocked by Catalina security features? 
> > I currently don't know how to track outb functionality. 
> > I'll keep trying (slooowly)
> Hi Roger. 
> 
> Fine, the most important thing is that we have verified that tools run correctly. Maybe it could be useful to delete everything (after a backup) and repeat a fresh installation, so you could check that you have a perfectly aligned layout, without previous mistakes. 
>
I just received your message recommending awaiting the next release. 

> Correct me if I'm wrong, I understood that IOEMU window is working and shows I/O widgets cycling, but not in Catalina, is that correct? 
Thats correct. I had the  IOEMU window working and showing I/O widgets cycling under High Sierra but still not under Catalina.
> 
> In this case maybe there is either a problem in the GUI code or in Catalina handling of windows. 
> 
> But you can assume safely that Ada code is working since you should see some output in serial terminal. 
Yes I'm very confident that the  Ada code is working and certainly see output in the serial terminal and the QEMU window.
> 
> About the outb instruction, please explain me (even writing down your code) what you are trying to do. outb instructions should behave fine, otherwise you should see a totally dead system. 
The outb instructions that I was referring to are those in X86_64-io.adb which are invoked by pc.PIC procedures which I have been trying to understand.
My current understanding is that it is PIC procedures in pc.adb that should drive the  I/O widgets cycling in the IOEMU window via the  in X86_64-io outb instructions?
> 
> By the way, apologies if I repeat myself, but try to isolate your code in an application file like the standard one, I'm changing some with/use and simplify units, so expect some minor changes in future release. This way you can change very little in your code. For example, unit x86_64.IO is likely to change in CPU.IO. Ask me if you have difficulties recompiling your code. 

Understood. But, at the moment I'm nowhere near producing my own code and am essentially trying to "reverse engineer" your code in order to understand how things work.

I have spent today coming to grips with MPLAB via various MPLAB tutorials, which also included tutorials on PIC hardware and interfacing.  This, eventually has been quite rewarding but I still have some way to go to reach adequate knowledge.

I've not tried sending files via Google Groups before so I don't know if this works!
If it does this shows my current understanding of the system
/System/Volumes/Data/QEMU/sweetada_run.pdf.zip

Re: SweetAda 0.1e released

[gabriele.galeotti.xyz]

On Monday, July 27, 2020 at 1:34:28 PM UTC+2, Roger Mc wrote:
> On Monday, July 27, 2020 at 8:51:55 PM UTC+10, gabriele.g...@gmail.com wrote:
> > On Sunday, July 26, 2020 at 3:51:41 AM UTC+2, Roger Mc wrote: 
> > > I reinstalled 0.1e and now it works, at least to the extent that 0.1d works. 
> > > Quite strange as I had the same problem on both my computers. 
> > > The only thing that I can think of is that on the previous 01e install I just used 
> > > ./menu.sh ( without target selection) 
> > > which was the method I used for 0.1d. Perhaps this messed something up? 
> > > When that didn't work, I inspected 0.1e menu.sh and discovered the need to use target selection; 
> > > however, on using target selection, in the order stated in your advice (perhaps eventually), I had the reported problem. 
> > > It seems, somehow I messed something up; somehow on both computers! 
> > > Thanks for your much appreciated advice. 
> > > 
> > > I still haven't tracked down the Catalina problem. Inspiration comes slowly. 
> > > Certainly, the Ada code is working correctly but, somehow the assembly coded outb instructions in x86_64-io don't seem to be having any effect. 
> > > Possibly being blocked by Catalina security features? 
> > > I currently don't know how to track outb functionality. 
> > > I'll keep trying (slooowly)
> > Hi Roger. 
> > 
> > Fine, the most important thing is that we have verified that tools run correctly. Maybe it could be useful to delete everything (after a backup) and repeat a fresh installation, so you could check that you have a perfectly aligned layout, without previous mistakes. 
> >
> I just received your message recommending awaiting the next release. 
> 
> > Correct me if I'm wrong, I understood that IOEMU window is working and shows I/O widgets cycling, but not in Catalina, is that correct? 
> Thats correct. I had the  IOEMU window working and showing I/O widgets cycling under High Sierra but still not under Catalina.
> > 
> > In this case maybe there is either a problem in the GUI code or in Catalina handling of windows. 
> > 
> > But you can assume safely that Ada code is working since you should see some output in serial terminal. 
> Yes I'm very confident that the  Ada code is working and certainly see output in the serial terminal and the QEMU window.
> > 
> > About the outb instruction, please explain me (even writing down your code) what you are trying to do. outb instructions should behave fine, otherwise you should see a totally dead system. 
> The outb instructions that I was referring to are those in X86_64-io.adb which are invoked by pc.PIC procedures which I have been trying to understand.
> My current understanding is that it is PIC procedures in pc.adb that should drive the  I/O widgets cycling in the IOEMU window via the  in X86_64-io outb instructions?
> > 
> > By the way, apologies if I repeat myself, but try to isolate your code in an application file like the standard one, I'm changing some with/use and simplify units, so expect some minor changes in future release. This way you can change very little in your code. For example, unit x86_64.IO is likely to change in CPU.IO. Ask me if you have difficulties recompiling your code. 
> 
> Understood. But, at the moment I'm nowhere near producing my own code and am essentially trying to "reverse engineer" your code in order to understand how things work.
> 
> I have spent today coming to grips with MPLAB via various MPLAB tutorials, which also included tutorials on PIC hardware and interfacing.  This, eventually has been quite rewarding but I still have some way to go to reach adequate knowledge.
> 
> I've not tried sending files via Google Groups before so I don't know if this works!
> If it does this shows my current understanding of the system
> /System/Volumes/Data/QEMU/sweetada_run.pdf.zip

OK. Maybe the Catalina problem is an issue we could solve in the near future. If you have an environment that does work, that is very fine, so we have a common base.

Now for the outb instructions.
No, pc.pic instructions do not drive IOEMU graphics widgets. Let me explain. I say again, I do not known your level of knowledge so I will go deep in order to not be misunderstood. Sorry for trivial things.

You are inside an emulated virtual machine, thanks to QEMU. This machine is a more or less standard x86-64 cpu PC machine. In the current PC-x86-64 platform development there are no calls to PC.PIC unit. This is done in the 32-bit platform, which isn't your choice. Maybe you mean PC.PPI, which is the parallel port.

I hope you are not confusing the PIC (programmable interrupt controller) in the PC chipset) with a PIC microcontroller, which are two entirely different context.

And this is done because I had to reprogram the Programmable Interrupt Controller (PIC) that's inside the chipset of every PC. It is needed for proper handling of interrupts (that I have yet to write down for x86-64, unlike the 32-bit platform, which is more "mature").

I/O widgets are excited by instructions in applications.adb. Now, there are two sets of "visible" I/O. One set is 3 I/O ports of the parallel port interface. 

By calling PC.PPI... you read or write something in this ports. So:

applications.adb: calls PPI_DataOut (Value)
pc.adb: PPI_DataOut() implements a calls to CPU.IO.PortOut (Value)

Note that pc.adb with's CPU.ads

Inside cpu.ads, CPU.IO.PortOut is a renaming of x86_64.IO package.
Inside package x86_64.IO, finally, PortOut is implemented as on outb/outw/outl, whatever instructions is picked up by the compiler thanks to overloading on the proper size of the data to be handled. If you want to output an Unsigned_8 value (the right choice because it's an 8-bit port), then

procedure PortOut (Port : in Unsigned_16; Value : in Unsigned_8)

is picked up.

The same also for "control" and "status". Every port is then tied to a widget by IOEMU, which visualize it in real-time.

The there is another set of I/O ports available to be shown in IOEMU, you can read their addresses when QEMU start. You can create an I/O section in qemu.cfg and assign to these ports a widget and then make a PortOut also on them.

If you want to send me a piece of code, you can try gabriele.galeotti@sweetada.org

Re: SweetAda 0.1e released

[Roger Mc]

On Monday, July 27, 2020 at 11:18:47 PM UTC+10, gabriele.g...@gmail.com wrote:
> On Monday, July 27, 2020 at 1:34:28 PM UTC+2, Roger Mc wrote: 
> > On Monday, July 27, 2020 at 8:51:55 PM UTC+10, gabriele.g...@gmail.com wrote: 
> > > On Sunday, July 26, 2020 at 3:51:41 AM UTC+2, Roger Mc wrote: 
> > > > I reinstalled 0.1e and now it works, at least to the extent that 0.1d works. 
> > > > Quite strange as I had the same problem on both my computers. 
> > > > The only thing that I can think of is that on the previous 01e install I just used 
> > > > ./menu.sh ( without target selection) 
> > > > which was the method I used for 0.1d. Perhaps this messed something up? 
> > > > When that didn't work, I inspected 0.1e menu.sh and discovered the need to use target selection; 
> > > > however, on using target selection, in the order stated in your advice (perhaps eventually), I had the reported problem. 
> > > > It seems, somehow I messed something up; somehow on both computers! 
> > > > Thanks for your much appreciated advice. 
> > > > 
> > > > I still haven't tracked down the Catalina problem. Inspiration comes slowly. 
> > > > Certainly, the Ada code is working correctly but, somehow the assembly coded outb instructions in x86_64-io don't seem to be having any effect. 
> > > > Possibly being blocked by Catalina security features? 
> > > > I currently don't know how to track outb functionality. 
> > > > I'll keep trying (slooowly) 
> > > Hi Roger. 
> > > 
> > > Fine, the most important thing is that we have verified that tools run correctly. Maybe it could be useful to delete everything (after a backup) and repeat a fresh installation, so you could check that you have a perfectly aligned layout, without previous mistakes. 
> > > 
> > I just received your message recommending awaiting the next release. 
> > 
> > > Correct me if I'm wrong, I understood that IOEMU window is working and shows I/O widgets cycling, but not in Catalina, is that correct? 
> > Thats correct. I had the IOEMU window working and showing I/O widgets cycling under High Sierra but still not under Catalina. 
> > > 
> > > In this case maybe there is either a problem in the GUI code or in Catalina handling of windows. 
> > > 
> > > But you can assume safely that Ada code is working since you should see some output in serial terminal. 
> > Yes I'm very confident that the Ada code is working and certainly see output in the serial terminal and the QEMU window. 
> > > 
> > > About the outb instruction, please explain me (even writing down your code) what you are trying to do. outb instructions should behave fine, otherwise you should see a totally dead system. 
> > The outb instructions that I was referring to are those in X86_64-io.adb which are invoked by pc.PIC procedures which I have been trying to understand. 
> > My current understanding is that it is PIC procedures in pc.adb that should drive the I/O widgets cycling in the IOEMU window via the in X86_64-io outb instructions? 
> > > 
> > > By the way, apologies if I repeat myself, but try to isolate your code in an application file like the standard one, I'm changing some with/use and simplify units, so expect some minor changes in future release. This way you can change very little in your code. For example, unit x86_64.IO is likely to change in CPU.IO. Ask me if you have difficulties recompiling your code. 
> > 
> > Understood. But, at the moment I'm nowhere near producing my own code and am essentially trying to "reverse engineer" your code in order to understand how things work. 
> > 
> > I have spent today coming to grips with MPLAB via various MPLAB tutorials, which also included tutorials on PIC hardware and interfacing. This, eventually has been quite rewarding but I still have some way to go to reach adequate knowledge. 
> > 
> > I've not tried sending files via Google Groups before so I don't know if this works! 
> > If it does this shows my current understanding of the system 
> > /System/Volumes/Data/QEMU/sweetada_run.pdf.zip
> OK. Maybe the Catalina problem is an issue we could solve in the near future. If you have an environment that does work, that is very fine, so we have a common base. 
> 
> Now for the outb instructions. 
> No, pc.pic instructions do not drive IOEMU graphics widgets. Let me explain. I say again, I do not known your level of knowledge so I will go deep in order to not be misunderstood. Sorry for trivial things. 
> 
> You are inside an emulated virtual machine, thanks to QEMU. This machine is a more or less standard x86-64 cpu PC machine. In the current PC-x86-64 platform development there are no calls to PC.PIC unit. This is done in the 32-bit platform, which isn't your choice. Maybe you mean PC.PPI, which is the parallel port. 
> 
> I hope you are not confusing the PIC (programmable interrupt controller) in the PC chipset) with a PIC microcontroller, which are two entirely different context. 
> 
> And this is done because I had to reprogram the Programmable Interrupt Controller (PIC) that's inside the chipset of every PC. It is needed for proper handling of interrupts (that I have yet to write down for x86-64, unlike the 32-bit platform, which is more "mature"). 
> 
> I/O widgets are excited by instructions in applications.adb. Now, there are two sets of "visible" I/O. One set is 3 I/O ports of the parallel port interface. 
> 
> By calling PC.PPI... you read or write something in this ports. So: 
> 
> applications.adb: calls PPI_DataOut (Value) 
> pc.adb: PPI_DataOut() implements a calls to CPU.IO.PortOut (Value) 
> 
> Note that pc.adb with's CPU.ads 
> 
> Inside cpu.ads, CPU.IO.PortOut is a renaming of x86_64.IO package. 
> Inside package x86_64.IO, finally, PortOut is implemented as on outb/outw/outl, whatever instructions is picked up by the compiler thanks to overloading on the proper size of the data to be handled. If you want to output an Unsigned_8 value (the right choice because it's an 8-bit port), then 
> 
> procedure PortOut (Port : in Unsigned_16; Value : in Unsigned_8) 
> 
> is picked up. 
> 
> The same also for "control" and "status". Every port is then tied to a widget by IOEMU, which visualize it in real-time. 
> 
> The there is another set of I/O ports available to be shown in IOEMU, you can read their addresses when QEMU start. You can create an I/O section in qemu.cfg and assign to these ports a widget and then make a PortOut also on them. 
> 

Many thanks for this which I will study in detail. Nothing is trivial. My "level of knowledge" in this context is low.
I have been confusing the PIC (programmable interrupt controller) in the PC chipset) with a PIC microcontroller which I thought i8259 PIC was referring to.
I think I need to study QEMU and  IOEMU in depth which I hadn't got around to yet.
Actually, perhaps demonstrating my level of ignorance, I'm baffled as to just where QEMU and  IOEMU "are" in the sweetada distribution?
Presumably such a question demonstrates my limited knowledge.
My only clues at the moment are that QEMU and  IOEMU are windows which must be generated somewhere; but so far I haven't been able to discover the "somewhere".
When I first started looking at sweetada, I did install a QEMU system to get some understanding and successfully installed Ubuntu it. But that was just a familiarity exercise which I have since deleted. 

> If you want to send me a piece of code, you can try gabriele...@sweetada.org
This was actually a diagram which I will now update in conformance with your description.
Apparently this Groups message editor is supposed to have a format toolbar from which attachments can be made but no such toolbar shows up on either of my Macs.
Again, your explanations are much appreciated,
Roger

Re: SweetAda 0.1e released

[gabriele.galeotti.xyz]

On Monday, July 27, 2020 at 4:02:48 PM UTC+2, Roger Mc wrote:
> On Monday, July 27, 2020 at 11:18:47 PM UTC+10, gabriele.g...@gmail.com wrote:
> > On Monday, July 27, 2020 at 1:34:28 PM UTC+2, Roger Mc wrote: 
> > > On Monday, July 27, 2020 at 8:51:55 PM UTC+10, gabriele.g...@gmail.com wrote: 
> > > > On Sunday, July 26, 2020 at 3:51:41 AM UTC+2, Roger Mc wrote: 
> > > > > I reinstalled 0.1e and now it works, at least to the extent that 0.1d works. 
> > > > > Quite strange as I had the same problem on both my computers. 
> > > > > The only thing that I can think of is that on the previous 01e install I just used 
> > > > > ./menu.sh ( without target selection) 
> > > > > which was the method I used for 0.1d. Perhaps this messed something up? 
> > > > > When that didn't work, I inspected 0.1e menu.sh and discovered the need to use target selection; 
> > > > > however, on using target selection, in the order stated in your advice (perhaps eventually), I had the reported problem. 
> > > > > It seems, somehow I messed something up; somehow on both computers! 
> > > > > Thanks for your much appreciated advice. 
> > > > > 
> > > > > I still haven't tracked down the Catalina problem. Inspiration comes slowly. 
> > > > > Certainly, the Ada code is working correctly but, somehow the assembly coded outb instructions in x86_64-io don't seem to be having any effect. 
> > > > > Possibly being blocked by Catalina security features? 
> > > > > I currently don't know how to track outb functionality. 
> > > > > I'll keep trying (slooowly) 
> > > > Hi Roger. 
> > > > 
> > > > Fine, the most important thing is that we have verified that tools run correctly. Maybe it could be useful to delete everything (after a backup) and repeat a fresh installation, so you could check that you have a perfectly aligned layout, without previous mistakes. 
> > > > 
> > > I just received your message recommending awaiting the next release. 
> > > 
> > > > Correct me if I'm wrong, I understood that IOEMU window is working and shows I/O widgets cycling, but not in Catalina, is that correct? 
> > > Thats correct. I had the IOEMU window working and showing I/O widgets cycling under High Sierra but still not under Catalina. 
> > > > 
> > > > In this case maybe there is either a problem in the GUI code or in Catalina handling of windows. 
> > > > 
> > > > But you can assume safely that Ada code is working since you should see some output in serial terminal. 
> > > Yes I'm very confident that the Ada code is working and certainly see output in the serial terminal and the QEMU window. 
> > > > 
> > > > About the outb instruction, please explain me (even writing down your code) what you are trying to do. outb instructions should behave fine, otherwise you should see a totally dead system. 
> > > The outb instructions that I was referring to are those in X86_64-io.adb which are invoked by pc.PIC procedures which I have been trying to understand. 
> > > My current understanding is that it is PIC procedures in pc.adb that should drive the I/O widgets cycling in the IOEMU window via the in X86_64-io outb instructions? 
> > > > 
> > > > By the way, apologies if I repeat myself, but try to isolate your code in an application file like the standard one, I'm changing some with/use and simplify units, so expect some minor changes in future release. This way you can change very little in your code. For example, unit x86_64.IO is likely to change in CPU.IO. Ask me if you have difficulties recompiling your code. 
> > > 
> > > Understood. But, at the moment I'm nowhere near producing my own code and am essentially trying to "reverse engineer" your code in order to understand how things work. 
> > > 
> > > I have spent today coming to grips with MPLAB via various MPLAB tutorials, which also included tutorials on PIC hardware and interfacing. This, eventually has been quite rewarding but I still have some way to go to reach adequate knowledge. 
> > > 
> > > I've not tried sending files via Google Groups before so I don't know if this works! 
> > > If it does this shows my current understanding of the system 
> > > /System/Volumes/Data/QEMU/sweetada_run.pdf.zip
> > OK. Maybe the Catalina problem is an issue we could solve in the near future. If you have an environment that does work, that is very fine, so we have a common base. 
> > 
> > Now for the outb instructions. 
> > No, pc.pic instructions do not drive IOEMU graphics widgets. Let me explain. I say again, I do not known your level of knowledge so I will go deep in order to not be misunderstood. Sorry for trivial things. 
> > 
> > You are inside an emulated virtual machine, thanks to QEMU. This machine is a more or less standard x86-64 cpu PC machine. In the current PC-x86-64 platform development there are no calls to PC.PIC unit. This is done in the 32-bit platform, which isn't your choice. Maybe you mean PC.PPI, which is the parallel port. 
> > 
> > I hope you are not confusing the PIC (programmable interrupt controller) in the PC chipset) with a PIC microcontroller, which are two entirely different context. 
> > 
> > And this is done because I had to reprogram the Programmable Interrupt Controller (PIC) that's inside the chipset of every PC. It is needed for proper handling of interrupts (that I have yet to write down for x86-64, unlike the 32-bit platform, which is more "mature"). 
> > 
> > I/O widgets are excited by instructions in applications.adb. Now, there are two sets of "visible" I/O. One set is 3 I/O ports of the parallel port interface. 
> > 
> > By calling PC.PPI... you read or write something in this ports. So: 
> > 
> > applications.adb: calls PPI_DataOut (Value) 
> > pc.adb: PPI_DataOut() implements a calls to CPU.IO.PortOut (Value) 
> > 
> > Note that pc.adb with's CPU.ads 
> > 
> > Inside cpu.ads, CPU.IO.PortOut is a renaming of x86_64.IO package. 
> > Inside package x86_64.IO, finally, PortOut is implemented as on outb/outw/outl, whatever instructions is picked up by the compiler thanks to overloading on the proper size of the data to be handled. If you want to output an Unsigned_8 value (the right choice because it's an 8-bit port), then 
> > 
> > procedure PortOut (Port : in Unsigned_16; Value : in Unsigned_8) 
> > 
> > is picked up. 
> > 
> > The same also for "control" and "status". Every port is then tied to a widget by IOEMU, which visualize it in real-time. 
> > 
> > The there is another set of I/O ports available to be shown in IOEMU, you can read their addresses when QEMU start. You can create an I/O section in qemu.cfg and assign to these ports a widget and then make a PortOut also on them. 
> > 
> 
> Many thanks for this which I will study in detail. Nothing is trivial. My "level of knowledge" in this context is low.
> I have been confusing the PIC (programmable interrupt controller) in the PC chipset) with a PIC microcontroller which I thought i8259 PIC was referring to.
> I think I need to study QEMU and  IOEMU in depth which I hadn't got around to yet.
> Actually, perhaps demonstrating my level of ignorance, I'm baffled as to just where QEMU and  IOEMU "are" in the sweetada distribution?
> Presumably such a question demonstrates my limited knowledge.
> My only clues at the moment are that QEMU and  IOEMU are windows which must be generated somewhere; but so far I haven't been able to discover the "somewhere".
> When I first started looking at sweetada, I did install a QEMU system to get some understanding and successfully installed Ubuntu it. But that was just a familiarity exercise which I have since deleted. 
> 
> > If you want to send me a piece of code, you can try gabriele...@sweetada.org
> This was actually a diagram which I will now update in conformance with your description.
> Apparently this Groups message editor is supposed to have a format toolbar from which attachments can be made but no such toolbar shows up on either of my Macs.
> Again, your explanations are much appreciated,
> Roger

I sensed the strange PIC problem.

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 emulates has additional I/Os that normally do not exist in that machine. Like a generic I/O card inside a computer. For example, if you choose a SPARC cpu (an thus an emulated machine like a SPARCstation5), it is difficult to have immediate evidence, because you have to low-level program a huge number of things, 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 normal 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 manager 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 stable. I make huge changes everyday, and don't want ugly things spreading off the net.

By the way, you can run QEMU without IOEMU, just delete the library file. Then supply QEMU with your own firmware by standard command line options. QEMU for sweetada has nothing different.

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 Sweetada does help you very little in doing that. The focus of sweetada is currently to adapt Ada code to machines.

G

Re: SweetAda 0.1e released

[Roger Mc]

On Tuesday, July 28, 2020 at 2:04:52 AM UTC+10, gabriele.g...@gmail.com wrote:
> 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 emulates has additional I/Os that normally do not exist in that machine. Like a generic I/O card inside a computer. For example, if you choose a SPARC cpu (an thus an emulated machine like a SPARCstation5), it is difficult to have immediate evidence, because you have to low-level program a huge number of things, 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 normal 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 manager 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 stable. I make huge changes everyday, and don't want ugly things spreading off the net. 
> 
> By the way, you can run QEMU without IOEMU, just delete the library file. Then supply QEMU with your own firmware by standard command line options. QEMU for sweetada has nothing different. 
> 
> 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 Sweetada does help you very little in doing that. The focus of sweetada is currently to adapt Ada code to machines. 
> 
> G

Great! I finally get the picture (well, almost).
QEMU is /opt/sweetada/bin/qemu-system-x86_64 which starts up like a DOS PC, booting from ROM and running until it can't find a bootable device.
Also, the QEMU-AArch64 directory gives me plenty of clues.

My idea is certainly, not to study QEMU from a low-level point of view but to understand its use in the context of sweetada and to understand the adaption of Ada code to machines.
My planned first job is to completely identify and understand all interfaces between sweetada and QEMU.

Re: SweetAda 0.1e released

[gabriele.galeotti.xyz]

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 wrote:
> > 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 emulates has additional I/Os that normally do not exist in that machine. Like a generic I/O card inside a computer. For example, if you choose a SPARC cpu (an thus an emulated machine like a SPARCstation5), it is difficult to have immediate evidence, because you have to low-level program a huge number of things, 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 normal 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 manager 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 stable. I make huge changes everyday, and don't want ugly things spreading off the net. 
> > 
> > By the way, you can run QEMU without IOEMU, just delete the library file. Then supply QEMU with your own firmware by standard command line options. QEMU for sweetada has nothing different. 
> > 
> > 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 Sweetada does help you very little in doing that. The focus of sweetada is currently to adapt Ada code to machines. 
> > 
> > G
> 
> Great! I finally get the picture (well, almost).
> QEMU is /opt/sweetada/bin/qemu-system-x86_64 which starts up like a DOS PC, booting from ROM and running until it can't find a bootable device.
> Also, the QEMU-AArch64 directory gives me plenty of clues.
> 
> My idea is certainly, not to study QEMU from a low-level point of view but to understand its use in the context of sweetada and to understand the adaption of Ada code to machines.
> My planned first job is to completely identify and understand all interfaces 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 CPU 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 physical I/O ports and starts terminals connected to the serialports of the emulated machine

In the case of QEMU-AArch64 nothing changes, obviously the system code is different 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 produced 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 object.

Regards

Re: SweetAda 0.1e released

[Roger Mc]

On Tuesday, July 28, 2020 at 7:16:59 PM UTC+10, gabriele.g...@gmail.com wrote:
> 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 wrote: 
> > > 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 emulates has additional I/Os that normally do not exist in that machine. Like a generic I/O card inside a computer. For example, if you choose a SPARC cpu (an thus an emulated machine like a SPARCstation5), it is difficult to have immediate evidence, because you have to low-level program a huge number of things, 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 normal 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 manager 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 stable. I make huge changes everyday, and don't want ugly things spreading off the net. 
> > > 
> > > By the way, you can run QEMU without IOEMU, just delete the library file. Then supply QEMU with your own firmware by standard command line options. QEMU for sweetada has nothing different. 
> > > 
> > > 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 Sweetada does help you very little in doing that. The focus of sweetada is currently to adapt Ada code to machines. 
> > > 
> > > G 
> > 
> > Great! I finally get the picture (well, almost). 
> > QEMU is /opt/sweetada/bin/qemu-system-x86_64 which starts up like a DOS PC, booting from ROM and running until it can't find a bootable device. 
> > Also, the QEMU-AArch64 directory gives me plenty of clues. 
> > 
> > My idea is certainly, not to study QEMU from a low-level point of view but to understand its use in the context of sweetada and to understand the adaption of Ada code to machines. 
> > My planned first job is to completely identify and understand all interfaces 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 CPU 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 physical I/O ports and starts terminals connected to the serialports of the emulated machine 
> 
> In the case of QEMU-AArch64 nothing changes, obviously the system code is different 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 produced 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 object. 
> 
> Regards
Thanks Gabriele.  As usual, very helpful.

Re: SweetAda 0.1e released

[Dennis Lee Bieber]

On Mon, 27 Jul 2020 07:02:45 -0700 (PDT), Roger Mc <rogermcm2@gmail.com>
declaimed the following:


>Many thanks for this which I will study in detail. Nothing is trivial. My "level of knowledge" in this context is low.
>I have been confusing the PIC (programmable interrupt controller) in the PC chipset) with a PIC microcontroller which I thought i8259 PIC was referring to.

	Heh -- until the interrupt controller was called out, when following
this thread, my first thought for PIC was Position-Independent-Code
(something more commonly found in Motorola instruction sets than Intel --
jumps/branches/calls being done relative to current Program Counter value,
not to absolute memory addresses. The reviled segmented memory of the 8086
offered a form of PIC -- code running in 64kB could be loaded on any
16-byte multiple, with the relevant segment register set to the start of
that boundary)


-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
	wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/