Why does initr_env fail to initialize when uboot starts

[riverjeep]

MPC8640 uboot boot print information is as follows：

-------------------------------------------------------------------------------------------------------------

initcall: eff45d50

U-Boot 2017.11 (Mar 05 2020 - 22:42:06 +0800)

initcall: eff12c4c
U-Boot code: EFF00000 -> EFF6AB00 BSS: -> EFF91968
initcall: eff05268
CPU: 8641, Version: 3.0, (0x80900030)
Core: e600 Core 0 (MSSCR0=8000, PORDEVSR=aa58700), Version: 2.2, (0x80040202)
Clock Configuration:
CPU:1000 MHz, MPX:500 MHz
DDR:250 MHz (500 MT/s data rate), LBC:500 MHz
L1: D-cache 32 KiB enabled
I-cache 32 KiB enabled
L2: 512 KiB enabled
initcall: eff13644
initcall: eff12e18
I2C: Requested speed:400000, i2c_clk:250000000
FDR:0x28, div:640, ga:0x4, gb:0x2, a:10, b:64, speed:390625
Tr <= 112 ns
divider:625, est_div:640, DFSR:12
FDR:0x28, speed:390625
ready
initcall: eff12de4
DRAM: initcall: eff07464
DDR: initcall: eff13014
Monitor len: 00091968
Ram size: 40000000
Ram top: 40000000
Reserving MP boot page to 3ff00000
initcall: eff129b4
initcall: eff129d8
initcall: eff12f04
initcall: eff12be8
Reserving 582k for U-Boot at: 3fe6e000
initcall: eff12b9c
Reserving 1032k for malloc() at: 3fd6c000
initcall: eff12d70
Reserving 84 Bytes for Board Info at: 3fd6bfac
initcall: eff12f1c
initcall: eff12b4c
Reserving 172 Bytes for Global Data at: 3fd6bf00
initcall: eff12acc
initcall: eff12f34
initcall: eff12f94
initcall: eff130c4
initcall: eff12960
initcall: eff12fac
1 GiB (DDR2, 64-bit, CL=4, ECC off)
initcall: eff129f0
initcall: eff12a24
initcall: eff12a94
New Stack Pointer is: 3fd6bef0
initcall: eff12d0c
initcall: eff12f4c
initcall: eff12c8c
Relocation Offset is: 4ff6e000
Relocating to 3fe6e000, new gd at 3fd6bf00, sp at 3fd6bef0
initcall: eff12a50
initcall: 3fe81158
initcall: 3fe81170
initcall: eff135bc (relocated to 3fe815bc)
initcall: eff13194 (relocated to 3fe81194)
initcall: eff13454 (relocated to 3fe81454)
using memory 0x3fd6c000-0x3fe6e000 for malloc()
initcall: eff13420 (relocated to 3fe81420)
initcall: eff134b0 (relocated to 3fe814b0)
initcall: eff13140 (relocated to 3fe81140)
initcall: eff1cdb4 (relocated to 3fe8adb4)
initcall: eff133f0 (relocated to 3fe813f0)
initcall: eff13354 (relocated to 3fe81354)
Now running in RAM - U-Boot at: 3fe6e000
initcall: eff133bc (relocated to 3fe813bc)
initcall: eff1338c (relocated to 3fe8138c)
initcall: eff134c8 (relocated to 3fe814c8)
initcall: eff134f8 (relocated to 3fe814f8)
Flash: flash detect cfi
fwc addr ec000000 cmd f0 f0 8bit x 8 bit
fwc addr ec000000 cmd ff ff 8bit x 8 bit
fwc addr ec000055 cmd 98 98 8bit x 8 bit
is= cmd 51(Q) addr ec000010 is= ff 51
fwc addr ec000555 cmd 98 98 8bit x 8 bit
is= cmd 51(Q) addr ec000010 is= ff 51
fwc addr ec000000 cmd f0 f0f0 16bit x 8 bit
fwc addr ec000000 cmd ff ffff 16bit x 8 bit
fwc addr ec0000aa cmd 98 9898 16bit x 8 bit
is= cmd 51(Q) addr ec000020 is= ffff 5151
fwc addr ec000aaa cmd 98 9898 16bit x 8 bit
is= cmd 51(Q) addr ec000020 is= ffff 5151
fwc addr ec000000 cmd f0 00f0 16bit x 16 bit
fwc addr ec000000 cmd ff 00ff 16bit x 16 bit
fwc addr ec0000aa cmd 98 0098 16bit x 16 bit
is= cmd 51(Q) addr ec000020 is= ffff 0051
fwc addr ec000aaa cmd 98 0098 16bit x 16 bit
is= cmd 51(Q) addr ec000020 is= ffff 0051
fwc addr ec000000 cmd f0 f0f0f0f0 32bit x 8 bit
fwc addr ec000000 cmd ff ffffffff 32bit x 8 bit
fwc addr ec000154 cmd 98 98989898 32bit x 8 bit
is= cmd 51(Q) addr ec000040 is= 00510051 51515151
fwc addr ec001554 cmd 98 98989898 32bit x 8 bit
is= cmd 51(Q) addr ec000040 is= 00510051 51515151
fwc addr ec000000 cmd f0 00f000f0 32bit x 16 bit
fwc addr ec000000 cmd ff 00ff00ff 32bit x 16 bit
fwc addr ec000154 cmd 98 00980098 32bit x 16 bit
is= cmd 51(Q) addr ec000040 is= 00510051 00510051
is= cmd 52(R) addr ec000044 is= 00520052 00520052
is= cmd 59(Y) addr ec000048 is= 00590059 00590059
device interface is 1
found port 4 chip 2 port 32 bits chip 16 bits
00 : 51 52 59 02 00 40 00 00 00 00 00 27 36 00 00 08 QRY..@.....'6...
10 : 09 08 13 01 02 03 03 1c 01 00 09 00 01 ff 07 00 ................
20 : 02 00 00 00 00 00 00 00 00 00 00 00 00 ff cd cf ................
fwc addr ec000000 cmd f0 00f000f0 32bit x 16 bit
fwc addr ec001554 cmd aa 00aa00aa 32bit x 16 bit
fwc addr ec000aa8 cmd 55 00550055 32bit x 16 bit
fwc addr ec001554 cmd 90 00900090 32bit x 16 bit
fwc addr ec000000 cmd f0 00f000f0 32bit x 16 bit
fwc addr ec000154 cmd 98 00980098 32bit x 16 bit
manufacturer is 2
manufacturer id is 0x1
device id is 0x227e
device id2 is 0x4801
cfi version is 0x3135
size_ratio 2 port 32 bits chip 16 bits
found 1 erase regions
erase region 0: 0x020007ff
erase_region_count = 2048 erase_region_size = 131072
ERROR: too many flash sectors
fwc addr ec000000 cmd f0 00f000f0 32bit x 16 bit
512 MiB
initcall: eff055dc (relocated to 3fe735dc)
PORDEVSR[IO_SEL_SRDS] = 5
SRIO1: enabled
initcall: eff13498 (relocated to 3fe81498)
initcall: eff1330c (relocated to 3fe8130c)
*** Warning - bad CRC, using default environment

Destroy Hash Table: 3fed8270 table = 00000000
Create Hash Table: N=240

------------------------------------------------------------------------------------------------------------

uboot starts and stops at the above location。

I traced the uboot code and found that the stop location was initr_env-> env_relocate-> set_default_env ("! Bad CRC")-> himport_r-> hsearch_r. As soon as the function hsearch_r was executed, it stopped.

I don't know why this kind of problem occurs, does anyone know how this is caused?

Thanks！

[yipingwang]

Hello river jeep,

Would you please provide the memory map of u-boot and u-boot environment?

Please check whether u-boot environment is override by u-boot binary.

Thanks,

Yiping

[riverjeep]

Hi,

The configuration of DDR in uboot is as follows：

[riverjeep]

I have solved the problem.
The method is: in the himport_r () function, where hsearch_r () is called, replace hsearch_r () with my_hsearch_r (). my_hsearch_r () function prototype is
int my_hsearch_r (char * name, char * value, ACTION action, ENTRY ** retval, struct hsearch_data * htab, int flag), replace the "ENTRY item" with "char * name, char * value" parameters. The internal implementation of my_hsearch_r () refers exactly to hsearch_r (). I suspect it is a stack overflow problem. As for why the stack overflow occurs, I don't know the exact reason. I wonder if it will be related to the configuration in MPC8641HPCN.h