rst
Posts: 386
Joined: Sat Apr 20, 2013 6:42 pm
Location: Germany

Re: BCM2711B0

Sat Jul 13, 2019 11:28 am

Some additional notes on Raspberry Pi 4 bare metal support from basically porting Circle:

Firmware

This has been tested with the firmware from Jul 9 2019 from here. Running bare metal code requires the following new firmware files:
  • fixup4.dat
  • start4.elf
  • bcm2711-rpi-4-b.dtb (did not work without)
bootcode.bin is not needed for the RPi 4. The 32-bit kernel image for the RPi 4 is named kernel7l.img, the 64-bit kernel image kernel8.img, but 64-bit mode is not activated automatically like on the RPi 3. A config.txt file with this entry is needed:

Code: Select all

arm_64bit=1
Mailbox property functions work as before.

I/O addresses

Beside the new I/O base address 0xFE000000 for the BCM2835 peripherals, there is a new I/O region for the BCM2836 local peripherals at 0xFF800000 (from the QA7 document). It is not known, how many of these local peripheral registers are implemented, but some are.

MMU and caches

The MMU is fully compatible to that of the Cortex-A53 in both 32- and 64-bit mode (as far as I am using it). Only the translation tables have to be updated to cover the new I/O regions and the Highmem (above 1 GB).

Cache configuration has changed. The L1 data cache (per core) is 2-way with 256 sets of 64 byte cache lines. The L2 data cache (unique) is 16-way with 1024 sets of 64 byte cache lines. The length of the cache lines did not change.

Memory layout and Highmem

The basic memory layout (below 1GB, ARM / GPU memory split) is unchanged. The additional RAM of the RPi 4 is implemented as Highmem above 1GB. The well-known property mailbox function 0x00010005 does only return the available memory size on ARM side below the memory split for the GPU. The available Highmem size can be detected from the board revision (mailbox function 0x00010002).

Interrupt controller

There is a new GIC-400 interrupt controller available, which implements the GICv2 architecture (not GICv3!). It is not known, if the BCM2835 interrupt controller is still available and can be used to generate interrupts. The Distibutor window of the GIC-400 is at 0xFF841000 (unique) and the CPU Interface window at 0xFF842000 (each core "sees its own CPU Interface window at this address). Interrupt numbers can be taken from the device tree sources from Linux. 32 has to be added to SPI interrupt numbers and 16 to PPI numbers from these files.

Unfortunately it is difficult to use the FIQ with the GIC-400 without "kernel_old=1", because the required register settings can only be done from Secure Mode. A Secure Monitor has to be implemented to support this, which is possible in AArch32, but probably not in AArch64. Maybe one has to move to the "kernel_old=1" setting in config.txt to use the FIQ.

Multi-core

Multi-core support works as before (spin mailboxes / table). Inter-Processor-Interrupts (IPI) can be generated using the GIC-400 as SGIs.

Timer and GPIO clocks

The oscillator is running at 54 MHz now. To generate timer interrupts the ARMv7 per core CPU timer can be used (via the GIC). The BCM2835 system timer peripheral still exists, but I don't know, if it can still generate interrupts.

GPIO clock source Oscillator runs at 54 MHz now and PLLD at 750 MHz.

DMA channels

At least DMA channels 0-7 work as before, while channel 1 and 3 is used by the firmware and channel 7 is a LITE engine. Channel 8 should also work and is also a LITE engine, but has the same interrupt number as channel 7. Channel 9 and 10 are used by the firmware. There are new 40-bit DMA engines 11-14, which are unknown.

Audio

PWM audio is working differently and is currently unknown. There is a new PWM peripheral device dedicated to the PWM audio via the headphone jack. It's I/O address is probably "base of PWM0" + 0x800. It is not known, which GPIO clock this PWM device uses and which DMA DREQ selector must be used to program PWM audio on the RPi 4.

Audio using the VCHIQ "AUDS" service does luckily still work (via headphone jack and HDMI).

EDIT: HDMI audio tested

User avatar
joan
Posts: 14097
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: BCM2711B0

Sat Jul 13, 2019 4:53 pm

@rst

Did you discover the 54 MHz Osc clock value in a document or by experiment? Similarly the DMA channel info.

rst
Posts: 386
Joined: Sat Apr 20, 2013 6:42 pm
Location: Germany

Re: BCM2711B0

Sat Jul 13, 2019 5:40 pm

joan wrote:
Sat Jul 13, 2019 4:53 pm
Did you discover the 54 MHz Osc clock value in a document or by experiment? Similarly the DMA channel info.
For the oscillator clock rate I generated a clock signal on GPIO4 with a defined divider and the oscillator source and measured the resulting clock rate. From that I calculated the oscillator frequency to be 54 MHz.

The DMA channel allocation info (free / used by firmware) can be requested via property mailbox call 0x00060001. The LITE engine info can be get from the DEBUG register. I tested DMA channels 0, 2, 4, 5, 6 and 7 with scrolling the frame buffer and a DMA-driven SPI driver.

Further info is from here (40-bit engines) and here (32-bit engines).

User avatar
joan
Posts: 14097
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: BCM2711B0

Sat Jul 13, 2019 5:47 pm

@rst Thanks for that. I knew something had changed about the DMA channels and by experiment the new 750 MHz PLLD. I didn't notice the 54 MHz oscillator change.

rst
Posts: 386
Joined: Sat Apr 20, 2013 6:42 pm
Location: Germany

Re: BCM2711B0

Sat Jul 13, 2019 6:02 pm

@joan You are welcome.

What I am missing at the moment is the PWM audio info for the new PWM device (assigned clock, DREQ and GPIO Alternate setting). If somebody would share info about this, it would be great. Perhaps we have to wait for the new "Peripherals document", but this may take time.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: BCM2711B0

Sat Jul 13, 2019 8:22 pm

Gavinmc42 wrote:
Sat Jul 13, 2019 9:30 am
That 512KB boot EEPROM is so calling to me :D
How much of an OS can fit in that?
That depends on how big the OS is, and how much is leftover after the firmware is in it.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Return to “Bare metal, Assembly language”