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

[Anton Staaf]

On Mon, Sep 26, 2011 at 12:22 PM, Simon Glass <sjg at chromium.org> wrote:
> 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...

Absolutely.  These sorts of details can be worked out later, and match what I
was thinking.  I just wanted to assert that I didn't think we were shooting
ourselves in the foot by exiting with a return code.

Thanks,
    Anton

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