Hi Simon, Seems that there is an issue in dm test framework (if understood everything correctly),
I've noticed that dm_root is updated when dm tests are being invoked, and that's why the new tee udevice is allocated, consequently, the second invocation of probe in tee driver occurs. In dm_test_init() dm_root is re-inited with NULL (then it populates new dm tree for from scratch, probing all devices), and I can't find where it is done(or if it's done at all) a proper removal/cleanup of devices from the previous dm tree before this dm_test initialization is invoked (I've added a conditional breakpoint for removal of previously allocated tee device, and it's never being called): Hardware watchpoint 4: gd->dm_root Old value = (struct udevice *) 0x1593c230 New value = (struct udevice *) 0x0 dm_test_init (uts=0x7c5080 <global_dm_test_state>, of_live=false) at ../test/dm/test-main.c:30 30 memset(dm_testdrv_op_count, '\0', sizeof(dm_testdrv_op_count)); (gdb) bt #0 dm_test_init (uts=0x7c5080 <global_dm_test_state>, of_live=false) at ../test/dm/test-main.c:30 #1 dm_do_test (uts=0x7c5080 <global_dm_test_state>, of_live=false, test=0x77a208 <_u_boot_list_2_dm_test_2_dm_test_adc_bind>) at ../test/dm/test-main.c:86 #2 dm_test_main (test_name=0x1594ccf0 "adc_bind") at ../test/dm/test-main.c:180 #3 do_ut_dm (cmdtp=<optimized out>, flag=<optimized out>, argc=<optimized out>, argv=<optimized out>) at ../test/dm/test-main.c:206 #4 0x000000000042cc43 in cmd_call (repeatable=0x7fffffffd58c, argv=0x1594cd10, argc=3, flag=<optimized out>, cmdtp=0x779f90 <_u_boot_list_2_cmd_2_ut>) at ../common/command.c:565 #5 cmd_process (flag=<optimized out>, argc=3, argv=0x1594cd10, repeatable=repeatable@entry=0x78f394 <flag_repeat>, ticks=ticks@entry=0x0) at ../common/command.c:606 #6 0x000000000041bdcb in run_pipe_real (pi=0x1594cef0) at ../common/cli_hush.c:1677 #7 run_list_real (pi=<optimized out>) at ../common/cli_hush.c:1875 #8 0x000000000041c1dd in run_list (pi=0x1594cef0) at ../common/cli_hush.c:2024 #9 parse_stream_outer (inp=inp@entry=0x7fffffffd700, flag=flag@entry=2) at ../common/cli_hush.c:3216 #10 0x000000000041c54d in parse_file_outer () at ../common/cli_hush.c:3299 #11 0x000000000042c2ce in cli_loop () at ../common/cli.c:217 #12 0x0000000000419f74 in main_loop () at ../common/main.c:63 #13 0x000000000041ccec in run_main_loop () at ../common/board_r.c:631 #14 0x000000000041cf41 in initcall_run_list (init_sequence=0x787740 <init_sequence_r>) at ../include/initcall.h:35 #15 board_init_r (new_gd=<optimized out>, dest_addr=dest_addr@entry=0) at ../common/board_r.c:856 #16 0x00000000004025ee in main (argc=<optimized out>, argv=<optimized out>) at ../arch/sandbox/cpu/start.c:356 Have I missed something? On Tue, 12 Feb 2019 at 17:31, Simon Glass <[email protected]> wrote: > > Hi Igor, > > On Tue, 12 Feb 2019 at 14:54, Igor Opaniuk <[email protected]> wrote: > > > > Hi Tom, Simon, > > > > So I did a little investigation and found out that, the issue in that > > hcreate_r() invocation in the tee sandbox driver fails because the > > hashtable was allocated before. > > Debugging showed that the sandbox tee driver is probed twice every > > time (although remove() is never called, it's behaves like there are > > two "tee" nodes in DT), and still haven't found the root cause (I > > think Simon can help with the hint where to look). > > I was assuming that those returned udevice pointers are kept in some > > global state but seem that they are de-allocated at some point. > > Have you ever faced the same behavior? > > Not really. If the driver is probed before relocation then it may be > probed again after relocation. You should be able to tell that by > check gd->flags. > > Regards, > Simon -- Regards, Igor Opaniuk _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
