Running AIX with 2 GiB of RAM and beyond

Trying to find out how much RAM can be given to a PPC PReP machine. In the IBM 40p the PCI host controller is sitting at 0x80000000, which means that in theory 2 GiB can be easily given:

QEMU PReP/40p, Serial #0, 2 GiB memory installed
Open Firmware, built  June 14, 2020 13:25:09
Copyright (c) 1995-2000, FirmWorks.
Copyright (c) 2014,2017,2019,2020 Artyom Tarasenko.

Rebooting with command: boot /pci/scsi@1/disk@0,0:1
Boot device: /pci/scsi@1/disk@0,0:1  Arguments: 

Saving Base Customize Data to boot disk
Starting the sync daemon
Starting the error daemon
System initialization completed.
Starting Multi-user Initialization
 Performing auto-varyon of Volume Groups 
 Activating all paging spaces 
0517-075 swapon: Paging device /dev/hd6 is already active.

And it even is recognized by AIX 5.1:

AIX Version 5
(C) Copyrights by IBM and by others 1982, 2000.
Console login: root
*******************************************************************************
*                                                                             *
*                                                                             *
*  Welcome to AIX Version 5.1!                                                *
*                                                                             *
*                                                                             *
*  Please see the README file in /usr/lpp/bos for information pertinent to    *
*  this release of the AIX Operating System.                                  *
*                                                                             *
*                                                                             *
*******************************************************************************

#  lsattr -El mem0 
size     2048 Total amount of physical memory in Mbytes  False
goodsize 2048 Amount of usable physical memory in Mbytes False
# 

Now I wonder, there were some 32 bit  RS/6000 machines with 3 GiB RAM, where there any PReP machines among them?

Playing with z/OS on Hercules

My new toy. Initially one of the data sets were damaged, but after all I managed to get the networking, including FTP and SSH work.

TSO login, that's easy

L CICS. Now what?

The 3270 terminals work out of the box. The networing had to be set up.

System log. Finally no red lines.

For some reason ssh is only allowed for the webadm user,  but it's possible to su - ibmuser.

and since OMVS is working, I can ssh

Maybe it's time to learn Cobol now :-)

PReP/40p updates

Sent the qemu patches for the upstream review. Also fixed a couple of issues in OFW: clock rush and interrupt routing for the PCNet (it still used interrupt 13, which was correct in 2017, but has been changed meanwhile).

Will update the links in the how-to shortly.

/Stay tuned

The next How-To

Nearly 10 years after writing Solaris/SPARC under QEMU How-To, now it’s time for the AIX/PReP under QEMU How-To.

Back then my strategy was using the Power-On Self Tests and other tests from the original firmware to verify and improve qemu-system-sparc.

This time I took a different approach as some tests are synthetic and check some typical hardware-specific problems like broken and shorted wires or faulty memory chips. The result of IBM firmware diagnostics is something like “replace your motherboard” – which is not exactly helpful to find out for instance whether there is a problem with the interrupt or DMA emulation. And yeah, there are some problems with the DMA emulation, that’s why qemu-system-ppc -M 40p can not use IDE CD-ROMs under AIX, and probably some other DMA devices like sound card (haven't tried it yet).

The approach this time was making the emulation good enough and describe it the way that it

• matches to the hardware implemented in QEMU good enough
• has a driver in AIX

The later was tricky, as AIX does support only a very limited amount of hardware. It checks exactly that your IDE controller is from Winbond (does anyone still remember them?) and checks the exact chip model. It doesn’t care if your chip is compatible, it wants the exact match.

As result we have a -M 40p model in QEMU which is not perfectly matching the physical IBM PPS 6015, and a firmware which describes it the way AIX 5.1 can see the onboard devices.

But anyways, it was fun 10 years ago and it's still fun.

AIX/PReP under QEMU How-To

AIX/PReP under QEMU How-To

Fetch the 40p-20190406-aix-boots branch and  compile qemu-system-ppc:

configure --target-list=ppc-softmmu

download the OFW image q40pofw-serial.rom configured  for the serial line.

create an empty hard disk image:

qemu-img create -f qcow2 aix-hdd.qcow2 8G

Concerning the VGA graphics: OFW can utilize the S3-Trio emulation done by Hervé, but AIX 5.1 can’t use it yet. For now, the serial line rules, but if you feel adventurous you can try using it omitting  the -vga none -nongraphic part.

qemu-system-ppc -M 40p -bios q40pofw-serial.rom -serial telnet::4441,server -hda aix-hdd.qcow2 -cdrom
/path/to/aix-5.1-cd1.iso  -vga none -nographic

Then in another terminal window:

telnet localhost 4441

The following text will appear:

QEMU PReP/40p, Serial #0, 128 MiB memory installed
Open Firmware, built  April 06, 2019 17:47:55
Copyright (c) 1995-2000, FirmWorks.
Copyright (c) 2014,2017,2019 Artyom Tarasenko.

Type any key to interrupt automatic startup
Boot device: /pci/ethernet  Arguments: 
The DHCP server did not specify a boot server

Boot load failed

ok

Once you see the “ok” prompt, type

ok boot cdrom:2

 

Then be patient, it takes some minutes till the first greeting appears and then some more before the installer starts.

Then answerer the installer questions. On my machine the copy process takes nearly one hour. At 93% it stalls after installing “mtools” for something like 10 Minutes, and then for another 10 minutes after “FAILURES” section, but don’t panic, eventually it will continue.

Once the install is done the emulated machine reboots to the “ok” prompt again. Type

ok boot disk

Supported AIX versions

I tested it with AIX 5.1 only. In theory it might work with 4.3.3 – 5.1 (a smoke test shows that at least the installer does start with AIX 4.3.3), let me know if you tested it. The 6015 support was officially discontinued in AIX 5.2, and probably the corresponding drivers were removed. I haven’t looked it up, as I don’t have a 5.2 media.

Networking in AIX 4.3.3 - 5.1 under QEMU

It looks like the PCNet driver (aka kent) is broken in AIX. I think the "busio" value used to look different in the previous versions. The networking can still be set up though. After performing the install, login as root and do the following (^D and ^C are Control-D and Control-C respectively):

# cat > lance-chg.asc
CuAt:
        name = "ent0"
        attribute = "busio"
        value = "0x01000000"
        type = "O"
        generic = "D"
        rep = "nr"
        nls_index = 3
^D
# odmchange -o CuAt -q "name=ent0 and attribute=busio" lance-chg.asc
# rmdev -l ent0
# mkdev -l ent0
# ifconfig en0 10.0.2.15
# ping 10.0.2.2
PING 10.0.2.2: (10.0.2.2): 56 data bytes
64 bytes from 10.0.2.2: icmp_seq=0 ttl=255 time=4 ms
64 bytes from 10.0.2.2: icmp_seq=1 ttl=255 time=3 ms
^C
#

If you try it with adifferent AIX version, before changing the busio, check first whether you have to modify it:

odmget -q "name=ent0 and attribute=busio" CuAt

In case  you get

value = "0x01000000"

you don't have to change it.

Your feedback is welcome!

Last updated on 2020.02.07

Cleaning up the PReP patches for AIX

I've got surprisingly many requests on booting AIX under the QEMU 40p target. I've looked at the changes which need to be done both to QEMU and to OpenFirmWare, and it turned out it there was more than I thought.

In 2017 I used some original work from the OFW done by Mitch Bradley. After a brief discussion he kindly published this file today. So now I'm good to publish my changes.

At the moment I'm cleaning the code, then I'll publish it on GitHub, and hopefully the patches will make it upstream. Except maybe for OFW, since it has been decided that the official firmware is going to be OpenBIOS. But for the users it should not matter, it's just one additional file to download.

/ Stay tuned ;-)

BLITing overlaping regions...

... may be tricky. The following screen shot illustrates why the memmove() system call was introduced as a safe replacement for the good old memcopy() back in the days.

Overlapping BLIT

The splash screen is done, next level

After some improvements to the cgsix emulation the boot splash screen is finally looking good:

cgsix under sun4m

On the screen above there is only one thing missing: the cursor. Unlike cgthree, the cgsix graphic adapter has hardware cursor, which I haven't implemented yet.

Well, the hardware cursor is not the only thing which is not yet implemented in general. The next screen is not as good:

The freedom statue is looking at Solaris install process

/stay tuned

Meanwhiile in sun4m

Debugging when a program does something unexpected is easy. You just have to find the place where it starts doing it and find out the reason.

In my case though, the problem is that Solaris doesn't change the color map. But where and when is it supposed to update it? Tricky.

And then I thought: why don't I try it under sun4m? And tell you what. I've got a good and a bad news. The good news is that the RAMDAC emulation does work ok:

cg6 under sun4m

The bad news is that the reason why it doesn't perform somewhere near it when running on a sun4u is still to be found. My current educated guess is that it has to do with the interrupt processing...

Don't know yet what I'm going to attack next: fix the interrupts under sun4u, or improve some missing graphic features under sun4m. The latter has an advantage of producing some nice or ugly screen shots, and everyone likes screen shots. :-)

The colors...

... are still not quite right:

Let's add some colors

The moment you see the endianess is wrong

Think I fixed one bug, but this way I loose the half tones. And the endianness is definitely wrong:

The endianness is wrong

Above I treat the bytes as pixels. The endianness is definitely wrong. Fixing the endianness the picture gets better:

The endianness is correct

Not sure if the bit order in the byte is correct. And no idea why it's so contrast and monochrome. Treating the bits as pixels with the proper endianness the picture looks more interesting:

As if a bit were a pixel

The result must be somewhere in between the two above... But I'm think I'm done for this weekend.