Hi Simon, I've fixed failing test on sandbox_flattree by keeping all defined global variables in a driver-private data struct(as you suggested), which permits to probe multiple tee sandbox devices (sent v5, kept you R-b tag, please let me know if there are any objections from your side).
But the way how dm test framework is invoked and why dm_root is simply re-allocated (and what happens with the previous one) is still an open question to me. If you can confirm that this a bug, I'll try to think about how this can be fixed. Thanks! On Wed, 13 Feb 2019 at 17:38, Igor Opaniuk <igor.opan...@linaro.org> wrote: > > 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 <s...@chromium.org> wrote: > > > > Hi Igor, > > > > On Tue, 12 Feb 2019 at 14:54, Igor Opaniuk <igor.opan...@linaro.org> 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 -- Regards, Igor Opaniuk _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot