Avoiding the thread hijacking on HoneyComb LX2 no console or GPU output. I have created this new topic
From the looks of it the BL2 image is 0x30000 bytes (LSDK-21.08 with debug disabled - it’s even worse when debug is enabled!) when compared to 0x29000 bytes (LSDK-20.12). This means that the OCRAM required overlaps the SD block buffer which is located in the last 32KiB of OCRAM causing a boot assertion failure.
LSDK-21.08
Program Header:
LOAD off 0x0000000000000000 vaddr 0x0000000018000000 paddr 0x0000000018000000 align 2**16
filesz 0x0000000000026511 memsz 0x0000000000030000 flags rwx
STACK off 0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**4
filesz 0x0000000000000000 memsz 0x0000000000000000 flags rw-
private flags = 0:
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00012000 000000001800d000 000000001800d000 0000d000 2**11
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .rodata 00007000 000000001801f000 000000001801f000 0001f000 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
LSDK-20.12
Program Header:
LOAD off 0x0000000000000000 vaddr 0x0000000018000000 paddr 0x0000000018000000 align 2**16
filesz 0x000000000001f301 memsz 0x0000000000029000 flags rwx
STACK off 0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**4
filesz 0x0000000000000000 memsz 0x0000000000000000 flags rw-
private flags = 0:
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 0000e000 000000001800d000 000000001800d000 0000d000 2**11
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .rodata 00004000 000000001801b000 000000001801b000 0001b000 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
The SD block buffer is located at 0x18038000 … 0x1803FFFF.
The problem seems to be due to a bloating of .rodata for some reason.
Thanks for the update. I will investigate this on our end. For the UEFI builds I am using a newer TF-A could you test this image an on sd-card and see if it is functioning properly on your hardware? https://solid-run-images.sos-de-fra-1.exo.io/LX2k/lx2160a_uefi/lx2160acex7_2000_700_2400_8_5_2_sd_ee5c233.img.xz
Hi Jon,
With that image I am able to see the CEX7 boot which I can interrupt
UEFI Interactive Shell v2.2
EDK II
UEFI v2.70 (EDK II, 0x00000000)
Mapping table
BLK2: Alias(s):
SD(0xCA)
BLK0: Alias(s):
eMMC(0xCA)
BLK1: Alias(s):
eMMC(0xCA)/HD(1,MBR,0x30303030,0x20000,0x7650000)
Press ESC in 5 seconds to skip startup.nsh or any other key to continue.
Shell>
okay good to know. I will get some _build patches together to get this sorted out for u-boot. Thanks for testing.
Hi Jon,
Glad I’m not going totally crazy.
Do you happen to support a solidrun yocto layer which includes a lx2160acex7 machine target? We prefer yocto over buildroot as it’s already used internally by ourselves on other projects.
I will take a look at NXP’s meta-qoriq layer and get an idea how much work integration for our platforms will be.
I just did a fresh clone and test build and was unable to replicate the BL2 image bloat you were seeing. However on my test machine I found that this patch was causing my machine to not boot from the usdhc card. Can you try and revert this commit from your build/rcw and test the image again?
lx2160acex7: mode 8: use external PLLs
If you are still having the bloat issue I can also share my patch that switches to gcc-10
No problem. Build is running now. The only change I have is as follows to remove the PLL patch. I’ll post back once I’ve tested it
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
deleted: patches/rcw-LSDK-21.08/0017-lx2160acex7-mode-8-use-external-PLLs.patch
Untracked files:
(use "git add <file>..." to include in what will be committed)
patches/rcw-LSDK-21.08/0017-lx2160acex7-mode-8-use-external-PLLs.patchX
Woohoo
NOTICE: BL2: v2.4(release):LSDK-21.08-4-gc2c7e05c5
NOTICE: BL2: Built : 13:46:29, May 11 2022
NOTICE: UDIMM 4ATF1G64HZ-3G2E2
NOTICE: DDR PMU Hardware version-0x1210
NOTICE: DDR PMU Firmware vision-0x1001 (vA-2019.04)
NOTICE: DDR4 UDIMM with 1-rank 64-bit bus (x16)
NOTICE: 16 GB DDR4, 64-bit, CL=22, ECC off, 256B
NOTICE: BL2: Booting BL31
NOTICE: BL31: v2.4(release):LSDK-21.08-4-gc2c7e05c5
NOTICE: BL31: Built : 13:46:29, May 11 2022
NOTICE: Welcome to lx2160acex7 BL31 Phase
U-Boot 2021.04-00031-g3600707cf4 (May 11 2022 - 13:46:21 +0000)
SoC: LX2160ACE Rev2.0 (0x87360020)
Clock Configuration:
CPU0(A72):2000 MHz CPU1(A72):2000 MHz CPU2(A72):2000 MHz
CPU3(A72):2000 MHz CPU4(A72):2000 MHz CPU5(A72):2000 MHz
CPU6(A72):2000 MHz CPU7(A72):2000 MHz CPU8(A72):2000 MHz
CPU9(A72):2000 MHz CPU10(A72):2000 MHz CPU11(A72):2000 MHz
CPU12(A72):2000 MHz CPU13(A72):2000 MHz CPU14(A72):2000 MHz
CPU15(A72):2000 MHz
Bus: 700 MHz DDR: 3200 MT/s
Reset Configuration Word (RCW):
00000000: 50838338 24500050 00000000 00000000
00000010: 00000000 0e010000 00000000 00000000
00000020: 10c001a0 00002580 00000000 08000086
00000030: 09240000 00000001 00000000 00000000
00000040: 00000000 00000000 00000000 00000000
00000050: 00000000 00000000 00000000 00000000
00000060: 00000000 00000000 00027000 00000000
00000070: 08a80001 00151020
Model: SolidRun LX2160ACEX7 COM express type 7 based board
Board: LX2160ACE Rev2.0-CEX7, SD
SERDES1 Reference: Clock1 = 161.13MHz Clock2 = 100MHz
SERDES2 Reference: Clock1 = 100MHz Clock2 = 100MHz
SERDES3 Reference: Clock1 = 100MHz Clock2 = 100Hz
DRAM: 15.9 GiB
DDR 15.9 GiB (DDR4, 64-bit, CL=22, ECC off)
DDR Controller Interleaving Mode: 256B
dev_get_priv: null device
dev_get_priv: null device
Using SERDES1 Protocol: 8 (0x8)
Using SERDES2 Protocol: 5 (0x5)
Using SERDES3 Protocol: 2 (0x2)
PCIe1: pcie@3400000 disabled
PCIe2: pcie@3500000 disabled
PCIe3: pcie@3600000 Root Complex: no link
PCIe4: pcie@3700000 disabled
PCIe5: pcie@3800000 Root Complex: no link
PCIe6: pcie@3900000 disabled
WDT: Started with servicing (30s timeout)
MMC: FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... *** Warning - bad CRC, using default environment
EEPROM: TlvInfo v1 len=116
In: serial_pl01x
Out: serial_pl01x
Err: serial_pl01x
SEC0: RNG instantiated
fsl_board_late_init
Setting up retimer channels 1..4 as 10Gbps
Net: eth0: DPMAC3@xgmii, eth1: DPMAC4@xgmii, eth2: DPMAC5@xgmii, eth3: DPMAC6@xgmii, eth4: DPMAC7@xgmii, eth5: DPMAC8@xgmii, eth6: DPMAC9@xgmii, eth7: DPMAC10@xgmii, eth8: DPMAC17@rgmii-id [PRIME]
MMC read: dev # 0, block # 20480, count 4608 ... 4608 blocks read: OK
MMC read: dev # 0, block # 28672, count 2048 ... 2048 blocks read: OK
crc32+
fsl-mc: Booting Management Complex ... SUCCESS
fsl-mc: Management Complex booted (version: 10.28.1, boot status: 0x1)
Hit any key to stop autoboot: 0
=>
1 Like
The latest images here SolidRun Images have the offending commit reverted.