On 2019/8/24 下午12:19, Simon Glass wrote:
Hi Kever,
On Mon, 19 Aug 2019 at 19:53, Kever Yang kever.yang@rock-chips.com wrote:
Hi Stephen,
On 2019/8/20 上午1:34, Stephen Warren wrote:
On 8/18/19 7:01 PM, Kever Yang wrote:
Hi Simon, Stephen,
Could you help to comment on my other mail, which patch causethis failure.
If you run "git bisect", you should be able to track down which patch introduced the problem.
I already locate the patch, and it seems some but in sandbox_spl or test, but not the driver,
see below:
Here's what I found:
$ gdb --args /tmp/b/sandbox_spl/u-boot -D GNU gdb (Debian 8.1-4+build1) 8.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /tmp/b/sandbox_spl/u-boot...done. (gdb) r Starting program: /tmp/b/sandbox_spl/u-boot -D [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". bloblist_init() Existing bloblist not found: creating new bloblist
Program received signal SIGSEGV, Segmentation fault. 0x0000555555617db5 in strcmp (cs=cs@entry=0x5555556602cf "root_driver", ct=0x1 <error: Cannot access memory at address 0x1>) at /home/sjg/c/src/third_party/u-boot/files/lib/string.c:190 190 if ((__res = *cs - *ct++) != 0 || !*cs++) (gdb) up #1 0x00005555555a9f91 in lists_driver_lookup_name (name=0x5555556602cf "root_driver") at /home/sjg/c/src/third_party/u-boot/files/drivers/core/lists.c:28 28 if (!strcmp(name, entry->name)) (gdb) print entry->name $1 = 0x0 (gdb) print *entry $2 = {name = 0x0, id = UCLASS_ROOT, of_match = 0x0, bind = 0x55555569b660, probe = 0x3e, remove = 0x5555556fd1e0 <rk8xx_ids>, unbind = 0x5555555d0ad6 <rk8xx_bind>, ofdata_to_platdata = 0x5555555d0a77 <rk8xx_probe>, child_post_bind = 0x0, child_pre_probe = 0x0, child_post_remove = 0x0, priv_auto_alloc_size = 0, platdata_auto_alloc_size = 0, per_child_auto_alloc_size = 0, per_child_platdata_auto_alloc_size = 0, ops = 0x0, flags = 4}
Here you have a rockchip driver in UCLASS_ROOT with no name.
The symbol is _u_boot_list_2_driver_2_pmic_rk8xx so perhaps it is getting corrupted?
But I don't understand how this corrupt happen, does this area should be RO data? When I compare the good case and error case, I got below difference, the 'fill' data only present at error case, does it suppose to be there?
.u_boot_list_2_driver_2_pmic_pm8916 0x00000000003b14f0 0x78 drivers/power/pmic/built-in.o 0x00000000003b14f0 _u_boot_list_2_driver_2_pmic_pm8916 *fill* 0x00000000003b1568 0x18 .u_boot_list_2_driver_2_pmic_rk8xx 0x00000000003b1580 0x78 drivers/power/pmic/built-in.o 0x00000000003b1580 _u_boot_list_2_driver_2_pmic_rk8xx
Thanks, - Kever
(gdb) where #0 0x0000555555617db5 in strcmp (cs=cs@entry=0x5555556602cf "root_driver", ct=0x1 <error: Cannot access memory at address 0x1>) at /home/sjg/c/src/third_party/u-boot/files/lib/string.c:190 #1 0x00005555555a9f91 in lists_driver_lookup_name (name=0x5555556602cf "root_driver") at /home/sjg/c/src/third_party/u-boot/files/drivers/core/lists.c:28 #2 0x00005555555a9561 in device_bind_by_name (parent=parent@entry=0x0, pre_reloc_only=pre_reloc_only@entry=false, info=info@entry=0x5555556fa560 <root_info>, devp=0x7fffffffdd08) at /home/sjg/c/src/third_party/u-boot/files/drivers/core/device.c:250 #3 0x00005555555aa423 in dm_init (of_live=<optimized out>) at /home/sjg/c/src/third_party/u-boot/files/drivers/core/root.c:148 #4 0x00005555555aa558 in dm_init_and_scan (pre_reloc_only=pre_reloc_only@entry=true) at /home/sjg/c/src/third_party/u-boot/files/drivers/core/root.c:373 #5 0x000055555559381a in initf_dm () at /home/sjg/c/src/third_party/u-boot/files/common/board_f.c:807 #6 0x000055555559395a in initcall_run_list (init_sequence=0x5555556fe840 <init_sequence_f>) at /home/sjg/c/src/third_party/u-boot/files/include/initcall.h:38 #7 board_init_f (boot_flags=<optimized out>) at /home/sjg/c/src/third_party/u-boot/files/common/board_f.c:986 #8 0x00005555555774d6 in main (argc=2, argv=0x7fffffffdf58) at /home/sjg/c/src/third_party/u-boot/files/arch/sandbox/cpu/start.c:360 (gdb) q
Regards, Simon