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

[Igor Opaniuk]

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.opaniuk at 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 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



-- 
Regards,
Igor Opaniuk