December 13, 2025

Initialization and the GICv3 driver

I have taken a bottom up look at this, starting with calls in the driver and investigating how and from where they are called.

Now I want to start fresh from what I think is the earliest call to initialize the GIC, this is found in bl31/bl31_main.c where we see:

unsigned int core_pos = plat_my_core_pos();

#if USE_GIC_DRIVER
    /*
     * Initialize the GIC driver as well as per-cpu and global interfaces.
     * Platform has had an opportunity to initialise specifics.
     */
    gic_init(core_pos);
    gic_pcpu_init(core_pos);
    gic_cpuif_enable(core_pos);
#endif /* USE_GIC_DRIVER */
We have ctags to help us working top down like this, making it easy to investigate these 3 calls. We find:
/* in gicv3_base.c */
void __init gic_init(unsigned int cpu_idx)
{
    gicv3_driver_init(&gic_data);
    gicv3_distif_init();
}
We find gic_pcpu_init() also in gicv3_base.c.
It loops calling gicv3_rdistif_probe() to discover frames, then calls gicv3_rdistif_init();

Finally, the call to gic_cpuif_enable() just bounces the call to a driver routine like so:

void gic_cpuif_enable(unsigned int cpu_idx)
{
    gicv3_cpuif_enable(cpu_idx);
}

Add gicv3_main.c to the file list

This involves the usual rinse/lather/repeat sequence of typing make then chasing missing include files. This source file pulls in a lot of include files! When the smoke clears (and it doesn't entirely, but I stop getting errors) I find that there are two places that perform initialization of the gic driver! They are different in a way that has already gotten my attention.

One uses fixed addresses for the redistributor base, the other uses this probing scheme I discovered to build a list of redistributor addresses. All of this merits a closer look.

What is up with these frames?

The routine gicv3_rdistif_probe() in gicv3_main.c finds "frames". These are apparently redistributor addresses, but I am not yet clear on all of this. Several routines in gicv3_helpers.c probe and discover frames.
Have any comments? Questions? Drop me a line!

Tom's electronics pages / tom@mmto.org