PiDP-8 software on Raspberry Pi 4 not loading OS/8

[MogensB]

I am trying to install the PiDP-8 software on a fresh SD install of the Raspbian OS "Bullseye" on a Raspberry Pi 4 (with 4 Gb).

I have chosen to clone the fossil repository, and do as the doc describes, using

configure, tools/mmake and sudo make install.

The software builds and installs fine, but when I try to start the OS/8 image it fails to complete. On the Pi 4 console I get the following output:

PiDP-8/I trunk:id[ef142cdc8e] [pi4b] [ils] [stdpcb] [gpio] [rt]
PDP-8 simulator V4.0-0 Current git commit id: 030a47bd 

And then no further response at all. If I press Ctrl-C a little more happens, but then it stops and blocks again, and I quit to simh by pressing Ctrl-E:

^CLoading OS/8 from the RK05 cartridge disk...
PiDP-8/I initial throttle = 333000 IPS

Simulation stopped, PC: 00024 (DLCA)
sim>

I tried both the release branch and the trunk branch from the fossil repo.

I have just tried to perform the identical procedures on a blank SD card installation on a Raspberry Pi 2, and everything works perfectly.

So am I missing out on some differences with the Raspberry Pi 4? IS it supposed to work "out of the box" with debian bullseye?

I read another thread in this group suggesting a bad os8 RK05 file, so I have also tried to make a new copy of the file, but that didn't help either.

I guess that since the bullseye Raspberry Pi 2 installation works every time, I believe some differences between Pi 2 and Pi 4 must be causing issues?

Best regards,

Mogens

[Heinz-Bernd Eggenstein]

Just to be 100% sure and to help in reproducing this ... are you using a 32 bit or 64 bit version of Raspberry Pi OS on the Pi4 ? (it has to be 32 bit one the Raspi 2 because the CPU on that one is only 32 bit, but for the Pi4 you have both options theoretically). Running uname -a will tell you.

A discussion on why you would want or not want to use the 64 bit version  is in here https://www.raspberrypi.com/news/raspberry-pi-os-debian-bullseye/

(I suppose you are also running 32 bit on the Pi4 but let's exclude some possible complications right at the start. )

Cheers

HBE

[MogensB]

I get the following on my Pi4 - with respect to the output from uname -a I am not sure how to see if this is 32 or 64 bit?

~ $ uname -a
Linux rp4002 5.10.92-v7l+ #1514 SMP Mon Jan 17 17:38:03 GMT 2022 armv7l GNU/Linux

~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

[Heinz-Bernd Eggenstein]

That is a 32 bit installation. On a 64 bit Raspi OS, the output of uname -a would end in "aarch64 GNU/Linux" .

HB

[Enrique Haro]

I think another indicator of this being a 32 bit machine is the 'armv71' in the uname output....    armv7 is 32 bits.    armv8 can be 32/64 bits and armv9 is the first family that is 64 bits only.

More info here: https://en.wikipedia.org/wiki/ARM_architecture_family

.... e

[Sam Cappello]

Hi - was there any resolution to this?  i am facing the same issue.

sam

[Ian Schofield]

Dear All,

 I can confirm this error using Raspbian Buster:

pi@pi64:~ $ uname -a
Linux pi64 5.15.32-v8+ #1538 SMP PREEMPT Thu Mar 31 19:40:39 BST 2022 aarch64 GNU/Linux

1. The app locks in sim_timer_precalibrate_execution_rate because no instructions can be executed. scp.c:2924

2. Excluding this call allows the app to continue and the CPU immediately halts after a CAF instruction at 23 following an RK05 boot.

3. To workaround this, I commented out line  691 in src/Pidp8i which relates to the single step logic etc. and the cpu will then run.

4. I think Warren may need to fix this as the logic here is quite complex.

Regards, Ian.

[Warren Young]

On Sunday, July 17, 2022 at 2:35:46 PM UTC-6 Ian wrote:

1. The app locks in sim_timer_precalibrate_execution_rate because no instructions can be executed. scp.c:2924

Thanks for diagnosing this. However…

 

4. I think Warren may need to fix this as the logic here is quite complex.

…I don't have a Pi 4, I have zero interest in buying one at today's wildly inflated prices, and even if I did somehow acquire one, I'd have little interest in converted my existing unit over to use it, since the Pi 3B has power far in excess to requirements for this application. I wouldn't waste a Pi 4 here.

(Yes, yes, I realize one does get faster builds, and you can run more background programs on the PiDP-8/I this way. Thing is, I have other servers for that. There's no practical value for me here.)

I'm willing to consider patches, even offer a commit bit to one motivated to take up Pi 4 maintenance matters, but I'm not going to be pursuing this myself.

[Ian Schofield]

Dear All,

 I have tracked down the error. The GPIO interface is different for the PI4 in relation to the way active pull up/down are set on a per pin basis.

 This due to the fact that for the PI4, the BCM2835 has been replaced with a BCM2711 although proc/cpuinfo says BCM2835. Quite a bit of noise about this.

 NB: For those interested, this has wrecked WiringPi as well.

As the BCM2711 needs to be configured differently, this results in a misread of the switches and the simulator will not run.

I have attached 2 files to fix this which will still require further verification.

Replace these files in the build directory structure in /src/pidp8i/, make and reinstall.

Hope this helps, regards, Ian.

NNB: My Pi4 gets rather hot in the case even with a heatsink. I do wonder if a fan is required.

[Heinz-Bernd Eggenstein]

Nice catch!

> NNB: My Pi4 gets rather hot in the case even with a heatsink. I do wonder if a fan is required.

I'm totally convinced it is not "necessary" as in "necessary to prevent malfunction", but for my PiDP-11 I ended up installing a small fan nevertheless, just to prevent the thing from throttling the CPU up and down, which for me caused fluctuating benchmark results when I tried to throttle the thing to near-realistic benchmark performance. And I guess a little noise just adds a bit of realism :-)

HBE

[Warren Young]

On Monday, July 18, 2022 at 2:44:03 PM UTC-6 isy...@gmail.com wrote:

 I have tracked down the error. The GPIO interface is different for the PI4 in relation to the way active pull up/down are set on a per pin basis.

 This due to the fact that for the PI4, the BCM2835 has been replaced with a BCM2711 although proc/cpuinfo says BCM2835. Quite a bit of noise about this.

I assumed you were running into something different than is already covered by the two branches we have for this:

   https://tangentsoft.com/pidp8i/info/bd10d4dde2f485a5

   https://tangentsoft.com/pidp8i/vdiff?from=d10da9f38617cb2b&to=1eee47198175cfc1

I don't want yet a third implementation. I want those two branches to be resolved by someone who has the hardware to test with. My understanding is that Oscar's patch is functional but ugly, whereas mine is clean and non-functional, owing to being done blindly, without reference to the hardware.

I want both, please, functional and clean. :)

It must continue to function on older Pi models as well, autodetecting the proper method.

[Warren Young]

Oh, and while I'm wishing: surely someone has come out with an abstraction library to paper over this difference in the Pi GPIO versions since the Pi 4 initially came out. I don't mind adding it as a build prereq, provided it's in the official repos.

[Ian Schofield]

Thanks Warren,

 I wasn't aware that this problem had been sorted out. The source I used for testing is the version from the software home page.

 So, where is the patched version for the Pi4? I assume this is branch Pi4-gpio-clean.

 Also, the tiny changes I added should make no difference to the Pi3 and older versions as the BCM2835 does not have any registers at offset 0xe4/0xe8.

 The existing Pi3 and below code has no effect on the Pi4.

 Having said this, this does required verification...... But, a single codebase would be an option or, use Oscars code to identify the BCM device:

    // Configure GPIO pin pull-ups
    if (gpio.addr_p == 0xfe200000) {
        init_bcm2711_gpio();
    }
    else {
        init_bcm2835_gpio();
    }

Which looks fine to me......

Regards, Ian.