[U-Boot] [U-Boot, v4, 1/1] avb: add support for named persistent values

[Igor Opaniuk]

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 at entry=0x78f394 <flag_repeat>,
ticks=ticks at 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 at entry=0x7fffffffd700,
flag=flag at 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 at 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 <sjg at chromium.org> wrote:
>
> Hi Igor,
>
> On Tue, 12 Feb 2019 at 14:54, Igor Opaniuk <igor.opaniuk at 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