[U-Boot] [RFC PATCH 06/20] sandbox: Allow board_init_f() and board_init_r() to return

[Simon Glass]

Hi Anton,

On Mon, Sep 26, 2011 at 10:49 AM, Anton Staaf <robotboy at chromium.org> wrote:
> On Mon, Sep 26, 2011 at 9:48 AM, Simon Glass <sjg at chromium.org> wrote:
>> Hi Mike,
>>
>> On Sun, Sep 25, 2011 at 9:47 PM, Mike Frysinger <vapier at gentoo.org> wrote:
>>> On Friday, September 23, 2011 11:55:11 Simon Glass wrote:
>>>> On Sat, Sep 17, 2011 at 5:05 PM, Mike Frysinger wrote:
>>>> > On Saturday, September 17, 2011 12:48:45 Simon Glass wrote:
>>>> >> Since the sandbox architecture doesn't do relocation, we prefer to call
>>>> >> board_init_r() explicitly when board_init_f() returns. Similarly we
>>>> >> prefer to call main_loop() when board_init_r returns.
>>>> >
>>>> > NAK; i dont see how sandbox is special.  just do what i do in Blackfin's
>>>> > board.c:
>>>> >        board_init_f calls board_init_r
>>>> >        board_init_r does while (1) main_loop()
>>>>
>>>> I have done as you say for now, but this isn't great. It means that
>>>> the only way back to the top level (say to run another test) is to use
>>>> setjmp/longjmp. But I will deal with this issue when it actually comes
>>>> up.
>>>
>>> i dont understand what you mean.  the main loop allows you to process commands
>>> forever and thus test as many commands as you want.
>>>
>>> if you're testing something before the main_loop, then i think it is correct
>>> that you'd "boot" from scratch, get to the main_loop (and thus pass your
>>> test), and then call "reset" to exit.  if you want to test something else
>>> before main_loop, start all over from scratch.
>>> -mike
>>>
>>
>> In short: at this stage I really don't mind what this particular patch
>> looks like - it will become clear later.
>>
>> Long version: I think there might be a basic confusion here as to how
>> this test idea is supposed to work. I think I mentioned at some point
>> that the question of the test controller will be resolved later.
>>
>> The test controller is the thing that kicks off tests. Many of these
>> tests will be for a complete run of U-Boot from start to
>> bootm/reset/whatever.
>>
>> If the test controller is separate from U-boot and runs U-Boot once
>> for each test then yes: reset and bootm can exit, the main loop never
>> needs to quit, etc.
>>
>> If the test controller is linked with U-Boot, and is basically just a
>> high-level control function for the rest of the code, then we want
>> reset and bootm to exit back to this test controller code.
>>
>> I haven't written any tests yes so it isn't yet clear what the
>> trade-offs are, but I suspect that linking at least part of the test
>> controller with U-Boot is going to be attractive so that it can spread
>> its tentacles and see what is going on during the test run.
>
> I would actually vote for the exact opposite.  The test controller should be
> able to get this information from the mocks of the devices that are used and
> the input and output it provides and consumes from stdio.
>
> I think it would be better to factor this into two problems.  Plus, I'm always a
> fan of smaller single purpose tools that are composed at the process boundary.

Yes it seems that we need some sort of config input and results output
'file' which device mocks can consume and produce. For the runtime I
am thinking of some device state which is specific to testing. For
example, a SPI flash driver might be able to emulate failure to erase
a block. This feature would be enabled by config, and perhaps the
results output would include the pages read/written, etc.

But I do want to keep this simple...

Regards,
Simon

>
> Thanks,
>    Anton
>
>> Regards,
>> Simon
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>>
>