Getting only rainbow square on boot — how to debug?

[JoeStrout]

I just discovered circle today and I'm quite excited about it.

Unfortunately, I'm not having much luck so far. I'm running a Raspberry Pi 400, so I configured like so:

PREFIX = arm-none-eabi-
AARCH = 32
RASPPI = 4

Everything builds cleanly. I did a make in the boot folder. I cd'd to the sample/02-screenpixel folder and did a make there too. I copied the kernel and the files from boot to my SD card, which now contains:

bcm2710-rpi-zero-2-w.dtb
bcm2711-rpi-4-b.dtb
bcm2711-rpi-400.dtb
bcm2711-rpi-cm4.dtb
bootcode.bin
config.txt
COPYING.linux
fixup_cd.dat
fixup.dat
fixup4.dat
fixup4cd.dat
kernel7l.img
LICENCE.broadcom
start.elf
start4.elf

But when I put this card in my Pi 400 and power it up, I see just this:

A friend suggested that this means that the GPU is spun up and talking to the HDMI port, but the kernel isn't loading. (I tried several other samples with the exact same result.)

Any idea how I can make it run the samples?

[JoeStrout]

I should add that I also tried building and adding the armstub7-rpi4.bin file, even though the docs make this sound optional; as well as the other start files (start4cd.elf and start_cd.elf). Still no dice.

Then I tried wiping the SD card, and using make install32 in the boot folder for a "quick install". Same result.

[rsta2]

The rainbow screen means, that the Raspberry Pi has booted something, but because you cannot see anything from the sample, it seems, it is not working.

I tried sample/02-screenpixel again on a Raspberry Pi 400 with Circle 45.3.1 from master branch, the GCC-12.2.1.-based toolchain, downloaded from the place noted in the main README.md file. I made make install32 with an empty SD card with FAT32 partition as first entry in the MBR.
After configure -r 4 I did ./makeall and make install in the sample's subdirectory. This replaced the kernel7l.img on the SD card.

Unfortunately I cannot reproduce the problem. On the HDMI display a cross is shown and the (power) LED on the RPi 400 blinks. This is all, what the sample is doing.

Which bootloader version is installed on your RPi 400? You can check this with rpi-eeprom-update on Raspberry Pi OS without giving an option. Which toolchain did you use?

[JoeStrout]

I cleared my SD card and restored the Raspberry Pi OS files (which I hadn't used in a while; this might be somewhat outdated). rpi-eeprom-update just prints "EEPROM updates directory /usr/bin/firmware/default not found."

Oh! But at one point in my experiments I had failed to copy start.elf and start4.elf, and I got this screen:

This shows the bootloader info at the top, and possibly other useful info?

I'm using the arm-gnu-toolchain-13.2.rel1-darwin-x86_64-arm-none, freshly downloaded yesterday from the recommended link. Circle was cloned from the master branch yesterday.

[JoeStrout]

Attempting it all again, fresh:

1. Cleared off my SD card again.
2. Looked at the makeall script, and manually cd'd to all the same subdirectories and did a make clean. (Feature suggestion: let makeall take a "clean" argument which does this for us!)
3. Did a ./makeall. Everything appeared to build cleanly.
4. Did cd boot and make install32. It downloaded and copied a bunch of stuff, no errors.
5. cd ../sample/l02-screenpixel, make, make install. Again no errors; I see it copied kernel7l.img to the SD card.
6. Booted the SD card on my RPi 400. IT WORKED!!! I see a white rectangle with a big X from corner to corner, and the power light is blinking!

OK, here's my theory: the first time I tried it, configure -r 4 did not work. I'm on a Mac, and apparently our version of getopt differs from the linux one, because the configure script completely ignores all command-line options. I did not at the time understand what it was doing, so it built everything with RASPPI = 1.

Then I realized what was going on, and changed the script to iterate over command-line options without using getopt; then changed my configuration to RASPPI = 4. I did a ./makeall, but (I'm guessing) this failed to rebuild everything. So my some of my binaries were still built for Pi 1.

If so, then the real fix for me was step 2 above. A ./makeall clean would give you an easier step to suggest to anybody else who shows up in such a fix. 😁 In any case, I am unstuck — thank you very much for your help!

[rsta2]

You are welcome. Two notes: * The recommended toolchain is still 12.2.Rel1. The newer version may or may not work with Circle. * You already can call "./makeall clean". This will clean all base Circle libraries. You can do this too in the sample/ directory again for the samples.

[JoeStrout]

Well I'll be dipped! I'd swear I tried that (.\makeall clean) this morning, but of course you're right, it works exactly as desired now.

Good note about the toolchain — so far the newer version appears to be working fine, so I'll stick with it for now, but if I run into problems I'll try dropping back to 12.2.Rel1.