[U-Boot] [RFC PATCH 1/3] sandbox: gpio: WIP add basic driver for simulating GPIOs

[U-Boot] [RFC PATCH 1/3] sandbox: gpio: WIP add basic driver for simulating GPIOs

[Simon Glass]

This provides a way of simulating GPIOs by setting values which are seen
by the normal gpio_get/set_value() calls.

Signed-off-by: Simon Glass <sjg@chromium.org>
---
 drivers/gpio/Makefile  |    1 +
 drivers/gpio/sandbox.c |  213 ++++++++++++++++++++++++++++++++++++++++++++++++
 include/sandbox_gpio.h |   50 +++++++++++
 3 files changed, 264 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpio/sandbox.c
 create mode 100644 include/sandbox_gpio.h

diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index f505813..f427127 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -33,6 +33,7 @@ COBJS-$(CONFIG_MXC_GPIO)	+= mxc_gpio.o
 COBJS-$(CONFIG_PCA953X)		+= pca953x.o
 COBJS-$(CONFIG_PCA9698)		+= pca9698.o
 COBJS-$(CONFIG_S5P)		+= s5p_gpio.o
+COBJS-$(CONFIG_SANDBOX_GPIO)	+= sandbox.o
 COBJS-$(CONFIG_TEGRA2_GPIO)	+= tegra2_gpio.o
 COBJS-$(CONFIG_DA8XX_GPIO)	+= da8xx_gpio.o
 
diff --git a/drivers/gpio/sandbox.c b/drivers/gpio/sandbox.c
new file mode 100644
index 0000000..81ba803
--- /dev/null
+++ b/drivers/gpio/sandbox.c
@@ -0,0 +1,213 @@
+/*
+ * Copyright (c) 2011 The Chromium OS Authors.
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <common.h>
+#include <asm/io.h>
+#include <asm/bitops.h>
+#include <asm/arch/gpio.h>
+
+enum {
+	CMD_INFO,
+	CMD_PORT,
+	CMD_OUTPUT,
+	CMD_INPUT,
+};
+
+/* Flags for each GPIO */
+enum {
+	GPIOF_OUTPUT	= 1 << 1,
+	GPIOF_HIGH	= 1 << 2,
+};
+
+/* TODO: Put this into sandbox state */
+static u8 state[GPIO_COUNT];	/* State of GPIOs */
+
+
+/* Access routines for GPIO state */
+static u8 *get_gpio(int gp)
+{
+	assert(gp >= 0 && gp < GPIO_COUNT);
+	return &state[gp];
+}
+
+static int get_gpio_flag(int gp, int flag)
+{
+	return *get_gpio(gp) & flag;
+}
+
+static void set_gpio_flag(int gp, int flag, int value)
+{
+	u8 *gpio = get_gpio(gp);
+
+	if (value)
+		*gpio |= flag;
+	else
+		*gpio &= ~flag;
+}
+
+int sandbox_gpio_get_value(int gp)
+{
+	if (get_gpio_flag(gp, GPIOF_OUTPUT))
+		printf("sandbox_gpio: get_value on output GPIO %d\n", gp);
+	return *get_gpio(gp) & GPIOF_HIGH;
+}
+
+int sandbox_gpio_set_value(int gp, int value)
+{
+	set_gpio_flag(gp, GPIOF_HIGH, value);
+	return 0;
+}
+
+int sandbox_gpio_get_direction(int gp)
+{
+	return get_gpio_flag(gp, GPIOF_OUTPUT);
+}
+
+int sandbox_gpio_set_direction(int gp, int output)
+{
+	set_gpio_flag(gp, GPIOF_OUTPUT, output);
+	return 0;
+}
+
+
+/* These functions make up what could be a public interface within U-Boot */
+
+/* set GPIO port 'gp' as an input */
+int gpio_direction_input(int gp)
+{
+	debug("gpio_direction_input: gp = %d\n", gp);
+	set_gpio_flag(gp, GPIOF_OUTPUT, 0);
+	return 0;
+}
+
+/* set GPIO port 'gp' as an output, with polarity 'value' */
+int gpio_direction_output(int gp, int value)
+{
+	debug("gpio_direction_output: gp = %d, value = %d\n",
+	      gp, value);
+	set_gpio_flag(gp, GPIOF_OUTPUT, 1);
+	return 0;
+}
+
+/* read GPIO IN value of port 'gp' */
+int gpio_get_value(int gp)
+{
+	debug("gpio_get_value: gp = %d\n", gp);
+	if (get_gpio_flag(gp, GPIOF_OUTPUT))
+		printf("sandbox_gpio: get_value on output GPIO %d\n", gp);
+	return *get_gpio(gp) & GPIOF_HIGH;
+}
+
+/* write GPIO OUT value to port 'gp' */
+void gpio_set_value(int gp, int value)
+{
+	debug("gpio_set_value: gp = %d, value = %d\n", gp, value);
+	if (get_gpio_flag(gp, GPIOF_OUTPUT))
+		set_gpio_flag(gp, GPIOF_HIGH, value);
+	else
+		printf("sandbox_gpio: set_value on input GPIO %d\n", gp);
+}
+
+/* Display GPIO information */
+static int gpio_info(int gp)
+{
+	printf("Sandbox GPIOs\n");
+	return 0;
+}
+
+cmd_tbl_t cmd_gpio[] = {
+	U_BOOT_CMD_MKENT(offset2port, 3, 0, (void *)CMD_PORT, "", ""),
+	U_BOOT_CMD_MKENT(output, 4, 0, (void *)CMD_OUTPUT, "", ""),
+	U_BOOT_CMD_MKENT(input, 3, 0, (void *)CMD_INPUT, "", ""),
+#ifdef CONFIG_CMD_GPIO_INFO
+	U_BOOT_CMD_MKENT(info, 3, 0, (void *)CMD_INFO, "", ""),
+#endif
+};
+
+int do_gpio(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+	static uint8_t offset;
+	int val __attribute__((unused));
+	ulong ul_arg2, ul_arg3, ul_arg4;
+	cmd_tbl_t *c;
+
+	ul_arg2 = ul_arg3 = ul_arg4 = 0;
+
+	c = find_cmd_tbl(argv[1], cmd_gpio, ARRAY_SIZE(cmd_gpio));
+
+	/* All commands but "port" require 'maxargs' arguments */
+	if (!c || !((argc == (c->maxargs)) ||
+		(((long)c->cmd == CMD_PORT) &&
+		 (argc == (c->maxargs - 1))))) {
+		cmd_usage(cmdtp);
+		return 1;
+	}
+
+	/* arg2 used as offset */
+	if (argc > 2)
+		ul_arg2 = simple_strtoul(argv[2], NULL, 10);
+
+	/* arg3 used as output value, 0 or 1 */
+	if (argc > 3)
+		ul_arg3 = simple_strtoul(argv[3], NULL, 10) & 0x1;
+
+	switch ((long)c->cmd) {
+	case CMD_INFO:
+		if (argc == 3)
+			offset = (uint8_t)ul_arg2;
+		return gpio_info(offset);
+
+	case CMD_PORT:
+		if (argc == 3)
+			offset = (uint8_t)ul_arg2;
+		return 0;
+
+	case CMD_INPUT:
+		/* arg2 = offset */
+		gpio_direction_input(ul_arg2);
+		val = gpio_get_value(ul_arg2);
+		return 0;
+
+	case CMD_OUTPUT:
+		/* args = offset, value */
+		gpio_direction_output(ul_arg2, ul_arg3);
+		return 0;
+
+	default:
+		/* We should never get here */
+		return 1;
+	}
+}
+
+U_BOOT_CMD(
+	gpio,	5,	1,	do_gpio,
+	"GPIO access",
+	"offset2port offset\n"
+	"	- show GPIO port:bit based on 'offset'\n"
+#ifdef CONFIG_CMD_GPIO_INFO
+	"     info offset\n"
+	"	- display info for all bits in port based on 'offset'\n"
+#endif
+	"     output offset 0|1\n"
+	"	- using 'offset', set port:bit as output and drive low or high\n"
+	"     input offset\n"
+	"	- using 'offset', set port:bit as input and read value"
+);
diff --git a/include/sandbox_gpio.h b/include/sandbox_gpio.h
new file mode 100644
index 0000000..db92f7b
--- /dev/null
+++ b/include/sandbox_gpio.h
@@ -0,0 +1,50 @@
+/*
+ * Copyright (c) 2011 The Chromium OS Authors.
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+/**
+ * Return the value of a GPIO
+ *
+ * @param gp	GPIO number
+ * @return -1 on error, 0 if GPIO is low, >0 if high
+ */
+int sandbox_gpio_get_value(int gp);
+
+/**
+ * @param gp	GPIO number
+ * @param value	value to set (0 for low, non-zero for high)
+ * @return -1 on error, 0 if ok
+ */
+int sandbox_gpio_set_value(int gp, int value);
+
+/**
+ * Return the direction of a GPIO
+ *
+ * @param gp	GPIO number
+ * @return -1 on error, 0 if GPIO is input, >0 if output
+ */
+int sandbox_gpio_get_direction(int gp);
+
+/**
+ * @param gp	GPIO number
+ * @param output 0 to set as input, 1 to set as output
+ * @return -1 on error, 0 if ok
+ */
+int sandbox_gpio_set_direction(int gp, int output);
-- 
1.7.3.1

[U-Boot] [RFC PATCH 2/3] sandbox: WIP add concept of sandbox state

[Simon Glass]

The state exists through the life of U-Boot. It can be adjusted by command
line options and perhaps later through a config file. It is available
to U-Boot through state_...() calls (within sandbox code).

Signed-off-by: Simon Glass <sjg@chromium.org>
---
 arch/sandbox/cpu/state.c                      |   54 ++++++++++++++++++++++
 arch/sandbox/include/asm/arch-sandbox/state.h |   59 +++++++++++++++++++++++++
 2 files changed, 113 insertions(+), 0 deletions(-)
 create mode 100644 arch/sandbox/cpu/state.c
 create mode 100644 arch/sandbox/include/asm/arch-sandbox/state.h

diff --git a/arch/sandbox/cpu/state.c b/arch/sandbox/cpu/state.c
new file mode 100644
index 0000000..a942174
--- /dev/null
+++ b/arch/sandbox/cpu/state.c
@@ -0,0 +1,54 @@
+/*
+ * Copyright (c) 2011 The Chromium OS Authors.
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <assert.h>
+#include <sandbox_gpio.h>
+#include <asm/arch/state.h>
+
+/* Main state record for the sandbox */
+struct sandbox_state main_state;
+struct sandbox_state *state;	/* Pointer to current state record */
+
+int state_is_processor_reset(void)
+{
+	return 1;
+}
+
+void state_record_exit(enum exit_type_id exit_type)
+{
+	state->exit_type = exit_type;
+}
+
+struct sandbox_state *state_get_current(void)
+{
+	assert(state);
+	return state;
+}
+
+int state_init(void)
+{
+	state = &main_state;
+
+	/* Example of how to use this... */
+	sandbox_gpio_set_direction(170, 0);
+	sandbox_gpio_set_value(170, 0);
+	return 0;
+}
diff --git a/arch/sandbox/include/asm/arch-sandbox/state.h b/arch/sandbox/include/asm/arch-sandbox/state.h
new file mode 100644
index 0000000..3023368
--- /dev/null
+++ b/arch/sandbox/include/asm/arch-sandbox/state.h
@@ -0,0 +1,59 @@
+/*
+ * Copyright (c) 2011 The Chromium OS Authors.
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+/* How we exited U-Boot */
+enum exit_type_id {
+	STATE_EXIT_NORMAL,
+	STATE_EXIT_COLD_REBOOT,
+	STATE_EXIT_POWER_OFF,
+};
+
+/* The complete state of the test system */
+struct sandbox_state {
+	const char *cmd;		/* Command to execute */
+	enum exit_type_id exit_type;	/* How we exited U-Boot */
+};
+
+/**
+ * Check the type of reset that caused U-Boot to run.
+ *
+ * @return 1 = processor reset (cold start), 0 = jump from previous U-Boot
+ */
+int state_is_processor_reset(void);
+
+/**
+ * Record the exit type to be reported by the test program.
+ *
+ * @param exit_type	Exit type to record
+ */
+void state_record_exit(enum exit_type_id exit_type);
+
+/**
+ * Gets a pointer to the current state.
+ *
+ * @return pointer to state
+ */
+struct sandbox_state *state_get_current(void);
+
+/**
+ * Initialize the test system state
+ */
+int state_init(void);
-- 
1.7.3.1

[U-Boot] [RFC PATCH 3/3] sandbox: WIP: add basic command line parsing

[Simon Glass]

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.

Signed-off-by: Simon Glass <sjg@chromium.org>
---
 arch/sandbox/cpu/Makefile |    2 +-
 arch/sandbox/cpu/parse.c  |   67 +++++++++++++++++++++++++++++++++++++++++++++
 arch/sandbox/cpu/parse.h  |   38 +++++++++++++++++++++++++
 arch/sandbox/cpu/start.c  |   33 ++++++++++++++++++++++
 4 files changed, 139 insertions(+), 1 deletions(-)
 create mode 100644 arch/sandbox/cpu/parse.c
 create mode 100644 arch/sandbox/cpu/parse.h

diff --git a/arch/sandbox/cpu/Makefile b/arch/sandbox/cpu/Makefile
index e5e860b..783a2c8 100644
--- a/arch/sandbox/cpu/Makefile
+++ b/arch/sandbox/cpu/Makefile
@@ -30,7 +30,7 @@ include $(TOPDIR)/config.mk
 
 LIB	= $(obj)lib$(CPU).o
 
-COBJS	:= cpu.o start.o os.o
+COBJS	:= cpu.o os.o parse.o start.o
 
 SRCS	:= $(COBJS:.o=.c)
 OBJS	:= $(addprefix $(obj),$(COBJS))
diff --git a/arch/sandbox/cpu/parse.c b/arch/sandbox/cpu/parse.c
new file mode 100644
index 0000000..38426fb
--- /dev/null
+++ b/arch/sandbox/cpu/parse.c
@@ -0,0 +1,67 @@
+/*
+ * Copyright (c) 2011 The Chromium OS Authors.
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <getopt.h>
+#include <stdio.h>
+#include <unistd.h>
+
+#include <asm/arch/state.h>
+
+#include "parse.h"
+
+static struct option long_options[] = {
+	{"command", required_argument, NULL, 'c'},
+	{"help", no_argument, NULL, 'h'},
+	{NULL, 0, NULL, 0}
+};
+
+void usage(void)
+{
+	fprintf(stderr, "u-boot, "
+		"a command line test interface to U-Boot\n\n"
+		"usage:\tu-boot [-ch]\n"
+		"Options:\n"
+		"\t-h\tDisplay help\n"
+		"\t-c <command>\tExecute U-Boot command\n"
+	);
+}
+
+int parse_args(struct sandbox_state *state, int argc, char *argv[])
+{
+	int c;
+
+	while ((c = getopt_long (argc, argv, "c:h",
+		long_options, NULL)) != EOF) {
+		switch (c) {
+		case 'c':
+			state->cmd = optarg;
+			break;
+		case 'h':
+			usage();
+			return 1;
+		default: /* '?' */
+			fprintf(stderr, "Try `--help' for more information."
+				"\n");
+			return -1;
+		}
+	}
+	return 0;
+}
diff --git a/arch/sandbox/cpu/parse.h b/arch/sandbox/cpu/parse.h
new file mode 100644
index 0000000..08e5ceb
--- /dev/null
+++ b/arch/sandbox/cpu/parse.h
@@ -0,0 +1,38 @@
+/*
+ * Copyright (c) 2011 The Chromium OS Authors.
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __SANDBOX_PARSE_H
+#define __SANDBOX_PARSE_H
+struct sandbox_state;
+
+/**
+ * Parse arguments and update sandbox state.
+ *
+ * @param state		Sandbox state to update
+ * @param argc		Argument count
+ * @param argv		Argument vector
+ * @return 0 if ok, and program should continue;
+ *	1 if ok, but program should stop;
+ *	-1 on error: program should terminate.
+ */
+int parse_args(struct sandbox_state *state, int argc, char *argv[]);
+
+#endif
diff --git a/arch/sandbox/cpu/start.c b/arch/sandbox/cpu/start.c
index 685793e..a13e9d0 100644
--- a/arch/sandbox/cpu/start.c
+++ b/arch/sandbox/cpu/start.c
@@ -20,14 +20,47 @@
  */
 
 #include <common.h>
+#include <asm/arch/state.h>
+
+#include "parse.h"
 
 int main(int argc, char *argv[])
 {
+	struct sandbox_state *state = NULL;
+	int err;
+
+	err = state_init();
+	if (!err) {
+		state = state_get_current();
+		err = parse_args(state, argc, argv);
+	}
+	if (err < 0)
+		return 1;
+	else if (err)	/* success return, but nothing to do */
+		return 0;
+	assert(state);
+
 	/*
 	 * Do pre- and post-relocation init, then start up U-Boot. This will
 	 * never return.
 	 */
 	board_init_f(0);
 
+	/* TODO: this code is not reached! */
+
+	/* Execute command if required */
+	if (state->cmd) {
+#ifdef CONFIG_SYS_HUSH_PARSER
+		run_command(state->cmd, 0);
+#else
+		parse_string_outer(state->cmd, FLAG_PARSE_SEMICOLON |
+				    FLAG_EXIT_FROM_LOOP);
+#endif
+	} else {
+		for (;;)
+			main_loop();
+	}
+	printf("U-Boot exited with state %d\n", state->exit_type);
+
 	return 0;
 }
-- 
1.7.3.1

[U-Boot] [RFC PATCH 1/3] sandbox: gpio: WIP add basic driver for simulating GPIOs

[Mike Frysinger]

On Wed, Oct 26, 2011 at 18:54, Simon Glass wrote:
> --- /dev/null
> +++ b/drivers/gpio/sandbox.c
>
> +#include <asm/io.h>
> +#include <asm/bitops.h>

not used

> +#include <asm/arch/gpio.h>

should be asm/gpio.h

> +/* These functions make up what could be a public interface within U-Boot */

these are the public interface in u-boot.  i wonder why you need the
sandbox_* names at all rather than just the public asm/gpio.h
interfaces.

> +U_BOOT_CMD(
> + ? ? ? gpio, ? 5, ? ? ?1, ? ? ?do_gpio,

if you implemented the asm/gpio.h interface only, you should be able
to re-use the existing cmd_gpio.c file rather than implementing your
own from scratch.
-mike

[U-Boot] [RFC PATCH 3/3] sandbox: WIP: add basic command line parsing

[Mike Frysinger]

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

> + ? ? ? ? ? ? ? "\t-c <command>\tExecute U-Boot command\n"

i don't think this is necessary.  i simply do:
    ./u-boot <<<$'bdinfo\nreset\n'
-mike

[U-Boot] [RFC PATCH 1/3] sandbox: gpio: WIP add basic driver for simulating GPIOs

[Simon Glass]

Hi Mike,

On Wed, Oct 26, 2011 at 11:14 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Wed, Oct 26, 2011 at 18:54, Simon Glass wrote:
>> --- /dev/null
>> +++ b/drivers/gpio/sandbox.c
>>
>> +#include <asm/io.h>
>> +#include <asm/bitops.h>
>
> not used
>
>> +#include <asm/arch/gpio.h>
>
> should be asm/gpio.h
>
>> +/* These functions make up what could be a public interface within U-Boot */
>
> these are the public interface in u-boot. ?i wonder why you need the
> sandbox_* names at all rather than just the public asm/gpio.h
> interfaces.
>
>> +U_BOOT_CMD(
>> + ? ? ? gpio, ? 5, ? ? ?1, ? ? ?do_gpio,
>
> if you implemented the asm/gpio.h interface only, you should be able
> to re-use the existing cmd_gpio.c file rather than implementing your
> own from scratch.
> -mike
>

Yes I'm afraid this patch is against a slightly older tree. I rebased
it but did not update it, but I will do so before sending it up for
real.

Thanks for the comments.

Regards,
Simon

[U-Boot] [RFC PATCH 1/3] sandbox: gpio: WIP add basic driver for simulating GPIOs

[Mike Frysinger]

ignoring the upgrade issues, i think this is useful.  only thing
"missing" is having the pin update state externally, but maybe i'm
crazy in thinking we need that.  it certainly could be done in a
follow up patch once your v2 of this patch gets updated, and once we
actually have a proposed interface that someone was able to make work
(vs us dreaming up something crazy like sockets/files/pipes/etc...).
-mike

[U-Boot] [RFC PATCH 3/3] sandbox: WIP: add basic command line parsing

[Simon Glass]

Hi Mike,

On Wed, Oct 26, 2011 at 11:16 PM, Mike Frysinger <vapier@gentoo.org> 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.

>
>> + ? ? ? ? ? ? ? "\t-c <command>\tExecute U-Boot command\n"
>
> i don't think this is necessary. ?i simply do:
> ? ?./u-boot <<<$'bdinfo\nreset\n'
> -mike
>

Well it's not possible ATM anyway since board_init_f() never returns.

Does your method use an expect script to check that the right result
is obtained?

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.

Regards,
Simon

[U-Boot] [RFC PATCH 3/3] sandbox: WIP: add basic command line parsing

[Mike Frysinger]

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.

> 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

[U-Boot] [RFC PATCH 1/3] sandbox: gpio: WIP add basic driver for simulating GPIOs

[Simon Glass]

Hi Mike,

On Fri, Oct 28, 2011 at 5:42 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> ignoring the upgrade issues, i think this is useful. ?only thing
> "missing" is having the pin update state externally, but maybe i'm
> crazy in thinking we need that. ?it certainly could be done in a
> follow up patch once your v2 of this patch gets updated, and once we
> actually have a proposed interface that someone was able to make work
> (vs us dreaming up something crazy like sockets/files/pipes/etc...).
> -mike
>

Yes. It depends on your definition of 'externally'. I am mostly
interested in self-contained tests, where we compile U-Boot against
its test code and run it very fast. However there is enormous scope
for going beyond that as has been discussed before - things like
making U-Boot talk on the host's Ethernet/ serial / USB ports, etc.

The tricky thing to get right here is the placement of the state. I
think we want to avoid test state in drivers where possible - on the
other hand we need drivers to be able to pretend to be broken, etc. If
we provide some sort of generic input/output config/log files for test
state, then I suppose converting to sockets/pipes is not a big step.
This is wrapped up in what the test harness looks like also. Are we
getting ahead of ourselves yet? ;-)

Regards,
Simon

[U-Boot] [RFC PATCH 3/3] sandbox: WIP: add basic command line parsing

[Simon Glass]

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

[U-Boot] [RFC PATCH 3/3] sandbox: WIP: add basic command line parsing

[Mike Frysinger]

On Sat, Oct 29, 2011 at 02:57, Simon Glass wrote:
> On Fri, Oct 28, 2011 at 5:50 PM, Mike Frysinger wrote:
>> On Sat, Oct 29, 2011 at 02:43, Simon Glass wrote:
>>> 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 ?
>
> 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.

does the spi flash patch you posted satisfy your first part here ?
after all, the back end shouldn't matter so long as "sf" is able to
read data out of a file into memory.
otherwise, i'll try and update the spi flash patch i posted sooner
rather than later.

as for sd/mmc, i think you might be on your own there.  i only have a
passing familiarity with the spec and would have to do quite a bit of
reading/learning first.  which i'm not terribly interested in doing at
this time i'm sorry to say.  the patents/licensing the sd peeps have
in place make that storage medium decidedly less interesting to me,
although i might suck it up (much further down the line) considering
it seems to (sadly) be the foreseeable future of storage in embedded.
-mike

[U-Boot] [RFC PATCH 3/3] sandbox: WIP: add basic command line parsing

[Simon Glass]

Hi Mike,

On Fri, Oct 28, 2011 at 6:05 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Sat, Oct 29, 2011 at 02:57, Simon Glass wrote:
>> On Fri, Oct 28, 2011 at 5:50 PM, Mike Frysinger wrote:
>>> On Sat, Oct 29, 2011 at 02:43, Simon Glass wrote:
>>>> 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 ?
>>
>> 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.
>
> does the spi flash patch you posted satisfy your first part here ?
> after all, the back end shouldn't matter so long as "sf" is able to
> read data out of a file into memory.
> otherwise, i'll try and update the spi flash patch i posted sooner
> rather than later.

Yes it does satisfy that - ATM I can boot through to where it wants to
load from MMC.

>
> as for sd/mmc, i think you might be on your own there. ?i only have a
> passing familiarity with the spec and would have to do quite a bit of
> reading/learning first. ?which i'm not terribly interested in doing at
> this time i'm sorry to say. ?the patents/licensing the sd peeps have
> in place make that storage medium decidedly less interesting to me,
> although i might suck it up (much further down the line) considering
> it seems to (sadly) be the foreseeable future of storage in embedded.
> -mike
>

Well that's OK. I had in mind a bit of a cheat (as I did with SPI)
anyway - i.e. this would be pretty trivial.

Regards,
Simon