U-Boot currently selects "N/A" to clock the A55 cores and the cores appear to operate at a small fraction of the target 1.2 GHz.
analogdevicesinc/u-boot#158 configures the A55 to use CCLK0_1, which runs the core at 450 MHz and boots Linux successfully.
Ideally, the A55 should instead run at around 1.2 GHz, but this causes Linux to hang during very early boot and it seems the only clock we can select is CCLK0_1, anything else hangs the kernel
Testing shows:
- Clocking ARM to CCLK0_1 at 450 MHz boots Linux successfully.
- Clocking ARM to CCLK0_0 in U-Boot causes Linux to hang shortly after
Starting kernel ....
- Clocking ARM CCLK2_0 in U-Boot causes Linux to hang shortly after
Starting kernel ....
- Configurations running the A55 at 1 GHz or 1.2 GHz also hang during kernel boot.
If Linux is first booted successfully at 450 MHz (CCLK0_1 is already running at 450), switching the A55 clock afterward to CCLK0_0 works without an immediate issue, so this seems like a early booting issue.
I also ran another test: I noticed that clocking the ARM via the "N/A" field in the CDU causes it to act as if it was clocked by CCLK0_1 (Im not sure if its actually clocked by that but im highly suspicious of it), I ran an experiment where I ensured ARM was clocked by "N/A" (which it currently is) and then I disabled CCLK0_1 in both U-Boot and Linux and the system crashes/freezes on both.
I then ran a second experiment where I reparented the ARM to a non-N/A field and then I tried to disable CCLK0_1 again and this time nothing happened. SO it seems N/A might be connected to CCLK0_1 or is itself CCLK0_1 or something (this is why DGM set CCLK0_1 to CRITICAL). We really shouldn't be using N/A clocks anyways.
This suggests there are two separate problems: 1) the invalid N/A selection, which is fixed by analogdevicesinc/u-boot#158, and a remaining early boot issue when the A55 is configured for higher clock rates before Linux starts.
For now, 450 MHz is used as a temporary workaround while the 1.2 GHz boot issue is investigated.
U-Boot currently selects "N/A" to clock the A55 cores and the cores appear to operate at a small fraction of the target 1.2 GHz.
analogdevicesinc/u-boot#158 configures the A55 to use CCLK0_1, which runs the core at 450 MHz and boots Linux successfully.
Ideally, the A55 should instead run at around 1.2 GHz, but this causes Linux to hang during very early boot and it seems the only clock we can select is CCLK0_1, anything else hangs the kernel
Testing shows:
Starting kernel ....Starting kernel ....If Linux is first booted successfully at 450 MHz (CCLK0_1 is already running at 450), switching the A55 clock afterward to CCLK0_0 works without an immediate issue, so this seems like a early booting issue.
I also ran another test: I noticed that clocking the ARM via the "N/A" field in the CDU causes it to act as if it was clocked by CCLK0_1 (Im not sure if its actually clocked by that but im highly suspicious of it), I ran an experiment where I ensured ARM was clocked by "N/A" (which it currently is) and then I disabled CCLK0_1 in both U-Boot and Linux and the system crashes/freezes on both.
I then ran a second experiment where I reparented the ARM to a non-N/A field and then I tried to disable CCLK0_1 again and this time nothing happened. SO it seems N/A might be connected to CCLK0_1 or is itself CCLK0_1 or something (this is why DGM set CCLK0_1 to CRITICAL). We really shouldn't be using N/A clocks anyways.
This suggests there are two separate problems: 1) the invalid N/A selection, which is fixed by analogdevicesinc/u-boot#158, and a remaining early boot issue when the A55 is configured for higher clock rates before Linux starts.
For now, 450 MHz is used as a temporary workaround while the 1.2 GHz boot issue is investigated.