The cores do not disable (LS1043a)

[notshure]

Hello everyone.

I have been trying to perform this task for several days.
Here is what I am doing:

Target:

My goal is to get my LS1043a board to boot by SD and starting the system by shutting down CPU 1, CPU 2 and CPU 3. Once the system is up and running, i would like to see from U-boot that such cores are disabled.

What have I done:

I performed a custom boot (with Flex-Builder) in which I entered the PBI command (write to the registry DCFG_CCSR_COREDISR to disable the cores). The procedure I followed is well described and can be found in the following link:Procedure to disable CPU.
The procedure seems apparently correct, since I can start U-Boot from SD.

Problem:

Once U-Boot starts, the log reported by U-Boot informs me that the cores have not been disabled.

U-Boot LOG:

NOTICE: Fixed DDR on board

NOTICE: 2 GB DDR4, 32-bit, CL=11, ECC off
NOTICE: BL2: v2.4(release):LSDK-21.08-0-g340b20bcb
NOTICE: BL2: Built : 11:04:47, Oct 14 2021
NOTICE: BL2: Booting BL31
NOTICE: BL31: v2.4(release):LSDK-21.08-0-g340b20bcb
NOTICE: BL31: Built : 11:04:37, Oct 14 2021
NOTICE: Welcome to ls1043ardb BL31 Phase

U-Boot 2021.04 (Oct 14 2021 - 09:49:48 +0200)

SoC: LS1043AE Rev1.1 (0x87920011)
Clock Configuration:
CPU0(A53):1600 MHz CPU1(A53):1600 MHz CPU2(A53):1600 MHz
CPU3(A53):1600 MHz
Bus: 400 MHz DDR: 1600 MT/s FMAN: 500 MHz
Reset Configuration Word (RCW):
00000000: 08100010 0a000000 00000000 00000000
00000010: 14550002 80004012 60040000 c1002000
00000020: 00000000 00000000 00000000 00038800
00000030: 00000000 00001100 00000096 00000001
Model: LS1043A RDB Board
Board: LS1043ARDB, boot from SD
CPLD: V2.0
PCBA: V6.0
SERDES Reference Clocks:
SD1_CLK1 = 156.25MHZ, SD1_CLK2 = 100.00MHZ
DRAM: 1.9 GiB (DDR4, 32-bit, CL=11, ECC off)
Using SERDES1 Protocol: 5205 (0x1455)
FSL_SDHC: 0

MMC read: dev # 0, block # 18944, count 128 ...
Firmware 'Microcode version 0.0.1 for LS1021a r1.0' for 1021 V1.0
QE: uploading microcode 'Microcode for LS1021a r1.0' version 0.0.1
Flash: 128 MiB
NAND: 512 MiB
MMC: Loading Environment from MMC... *** Warning - bad CRC, using default environment

EEPROM: NXID v1
In: serial
Out: serial
Err: serial
SEC0: RNG instantiated
Net:
MMC read: dev # 0, block # 18432, count 128 ...
Fman1: Uploading microcode version 106.4.18
eth0: fm1-mac1, eth1: fm1-mac2, eth2: fm1-mac3, eth3: fm1-mac4, eth4: fm1-mac5, eth5: fm1-mac6, eth6: fm1-mac9
Hit any key to stop autoboot: 0

This can be seen above all in the initial part (highlighted in pink) in which it is reported that the different CPUs are all working at a frequency of 1600MHz. I shouldn't just read the writing with CPU0 and that's it?

Furthermore this seems to me a bit of a contradiction given that the contents of the register DCFG_CCSR_COREDISR is the following:

=> md.b 1ee0094 4
01ee0094: 00 00 00 0e

Which would seem fair, given what the datasheet said QorIQ LS1043A Reference Manual, Rev. 6, 07/2020 (Pag. 498).

That is, it would seem that I was able to write to DCFG_CCSR_COREDISR register before U-Boot even started, but that the cores in the end were not disabled.

Question:

I just don't understand.
I performed the procedure as mentioned in the datasheet which mentions that to disable the cores you need to enable some bits of the register DCFG_CCSR_COREDISR under certain circumstances, i.e. during boot, via a PBI command.
I succeeded, in fact I read that log from U-Boot and saw that the log was written even before U-Boot started, but then why does U-boot in its log inform me that all cores are actually working?

I don't understand where the mistake is.

Thank you very much for your availability.

[ufedor]

Please note that in the U-Boot log it is printed:

Clock Configuration:
CPU0(A53):1600 MHz CPU1(A53):1600 MHz CPU2(A53):1600 MHz
CPU3(A53):1600 MHz

I.e. these lines just show clocks applied to the cores.

[notshure]

Hi, thanks for your reply.

So are you telling me that even though the cores are clocked at 1600MHz, the cores are actually disabled?
When the cores are disabled shouldn't they do the "gating" of the clock, that is precisely to remove the clock from the unnecessary cores?

Then it is very contradictory to what a colleague of you told me about a previous question of mine: Previous Quesion 

Also since I am working with QorlQ LS1043A board, according to what is said in the document LS1043ARDBGSG QorlQ LS1043A Reference Design Board Getting Started Guide it is possible to disable two cores out of four via switch 5 [3]

in fact when I work with two cores disabled in hardware, U-Boot shows me only the writing CPU0(A53):1600 MHz CPU1(A53):1600 MHz.

I'm sure the cores are disabled, as it's done via hardware somehow.

So the question is: Following my procedure, have I been able to disable the cores that I am not interested in?

[ufedor]

You wrote:

> When the cores are disabled shouldn't they do the "gating" of the clock,

> that is precisely to remove the clock from the unnecessary cores?

Correct.

> it is very contradictory to what a colleague of you told me about a previous question of mine

There is no contradiction.

U-Boot shows core clock frequencies as they are configured by the RCW - there is no indication whether core clocks are gated or not.

> it is possible to disable two cores out of four via switch 5 [3]

This switch changes the processor personality between LS1043A and LS1023A.

U-Boot knows these personalities, thus clock frequencies for only two cores are shown for LS1023A.

[notshure]

So was I able to disable the cores?

I leave you attached my boot from SD.

firmware_ls1043ardb_sdboot.img 

[ufedor]

When DCFG_CCSR_COREDISR = 0x0000000e cores 1, 2, 3 are disabled.

[notshure]

is it a yes or no?

If I start the system with my boot through the .img file linked, does the system start with the cores disabled?

Also is there another test you can perform to understand that the cores are disabled?

I need different tests besides that of going to read on the DCFG_CCSR_COREDISR register, to understand that the cores are disabled.

[ufedor]

Yes.

> Also is there another test you can perform to understand that the cores are disabled?

No such test.