From mboxrd@z Thu Jan  1 00:00:00 1970
From: Simon Glass <sjg@chromium.org>
Date: Fri, 28 Oct 2011 17:57:32 -0700
Subject: [U-Boot] [RFC PATCH 3/3] sandbox: WIP: add basic command line
	parsing
In-Reply-To: <CAJaTeToSZj=86C86bgLzUrUj2JgZhhWYPRfDeXJ9bk-Ku+vLpg@mail.gmail.com>
References: <1319648079-12622-1-git-send-email-sjg@chromium.org>
	<1319648079-12622-3-git-send-email-sjg@chromium.org>
	<CAJaTeTrc_J+4Tz8sYGkD=h7nWyW02k_ax2g=1u6OzQS6+8q8NA@mail.gmail.com>
	<CAPnjgZ1czn153=pAbt4ZSK5pptwkFoQ5LTHx6=gGDZW8GO-uRA@mail.gmail.com>
	<CAJaTeToSZj=86C86bgLzUrUj2JgZhhWYPRfDeXJ9bk-Ku+vLpg@mail.gmail.com>
Message-ID: <CAPnjgZ0--YYdonKmzJKTBBT+DvPGg1oV4U3ZMCgvSgb7PLwNpQ@mail.gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi Mike,

On Fri, Oct 28, 2011 at 5:50 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Sat, Oct 29, 2011 at 02:43, Simon Glass wrote:
>> On Wed, Oct 26, 2011 at 11:16 PM, Mike Frysinger wrote:
>>> On Wed, Oct 26, 2011 at 18:54, Simon Glass wrote:
>>>> This adds simple command-line parssing to sandbox. The idea is that it
>>>> sets up the state with options provided, and this state can then be
>>>> queried as needed later.
>>>
>>> i'm not seeing the usefulness of the "state" code
>>
>> Not yet - for now it just holds the command line flags and anything
>> parsed from the command line. Ultimately it will hold test state, but
>> it is early days on that yet.
>
> i think we should split command line parsing from state. ?the former
> is clearly desirable $now.
>
>>>> + ? ? ? ? ? ? ? "\t-c <command>\tExecute U-Boot command\n"
>>>
>>> i don't think this is necessary. ?i simply do:
>>> ? ?./u-boot <<<$'bdinfo\nreset\n'
>>
>> Well it's not possible ATM anyway since board_init_f() never returns.
>
> right. ?i was speaking in general.
>
>> Does your method use an expect script to check that the right result
>> is obtained?
>
> yes & no. ?i wrote up a tiny test quite that does `./u-boot ... >&
> test.out`, and then compares test.out to a test.in file to make sure
> things worked. ?it could be made to use expect instead.
>
> however, Marek (or maybe Jean) pointed out DUTS to me, so i stopped
> working on that and switched to trying to learn that framework so we
> could use what already existed rather than writing something from
> scratch which i imagine Wolfgang (rightly so) would barf all over.

Yes, looking forward to finding out more about that. Whatever we do
for test harness needs to avoid the re-invention of wheels.

>
>> I am not going to get back to sandbox for a few weeks now - my next
>> task is to get it booting from simulated SPI/MMC and see what tests
>> can be written against that. It will become clearer then I think.
>
> this is a bit ambiguous ... you want to test booting from SPI flash
> and from a card in a MMC slot ? ?or you want to test booting from a
> card in a MMC slot connected via SPI ?
> -mike
>

I mean boot by loading some data, etc. from SPI-attached SPI flash and
then loading a kernel from an SDMMC-attached MMC card and jumping to
it.

Regards,
Simon