* [U-Boot] [RFC PATCH 02/20] sandbox: Add architecture image support
2011-09-17 16:48 [U-Boot] [RFC PATCH 01/20] sandbox: Add architecture header files Simon Glass
@ 2011-09-17 16:48 ` Simon Glass
2011-09-17 19:29 ` Marek Vasut
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 03/20] sandbox: Add compiler defines to support a 64-bit x86_64 platform Simon Glass
` (18 subsequent siblings)
19 siblings, 1 reply; 57+ messages in thread
From: Simon Glass @ 2011-09-17 16:48 UTC (permalink / raw)
To: u-boot
We won't actually load an image with this architecture, but we still need to
define it.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
common/image.c | 5 +++--
include/image.h | 3 +++
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/common/image.c b/common/image.c
index d38ce4a..8283561 100644
--- a/common/image.c
+++ b/common/image.c
@@ -1581,7 +1581,7 @@ int boot_get_fdt (int flag, int argc, char * const argv[], bootm_headers_t *imag
goto error;
}
- printf (" Booting using the fdt blob at 0x%x\n", (int)fdt_blob);
+ printf(" Booting using the fdt blob at 0x%p\n", fdt_blob);
} else if (images->legacy_hdr_valid &&
image_check_type (&images->legacy_hdr_os_copy, IH_TYPE_MULTI)) {
@@ -1600,7 +1600,8 @@ int boot_get_fdt (int flag, int argc, char * const argv[], bootm_headers_t *imag
if (fdt_len) {
fdt_blob = (char *)fdt_data;
- printf (" Booting using the fdt at 0x%x\n", (int)fdt_blob);
+ printf(" Booting using the fdt at 0x%p\n",
+ fdt_blob);
if (fdt_check_header (fdt_blob) != 0) {
fdt_error ("image is not a fdt");
diff --git a/include/image.h b/include/image.h
index 352e4a0..c7fbb88 100644
--- a/include/image.h
+++ b/include/image.h
@@ -106,6 +106,7 @@
#define IH_ARCH_BLACKFIN 16 /* Blackfin */
#define IH_ARCH_AVR32 17 /* AVR32 */
#define IH_ARCH_ST200 18 /* STMicroelectronics ST200 */
+#define IH_ARCH_SANDBOX 19 /* Sandbox architecture (test only) */
/*
* Image Types
@@ -506,6 +507,8 @@ static inline int image_check_target_arch (const image_header_t *hdr)
if (!image_check_arch (hdr, IH_ARCH_SH))
#elif defined(__sparc__)
if (!image_check_arch (hdr, IH_ARCH_SPARC))
+#elif defined(CONFIG_SANDBOX_ARCH)
+ if (0)
#else
# error Unknown CPU type
#endif
--
1.7.3.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [RFC PATCH 02/20] sandbox: Add architecture image support
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 02/20] sandbox: Add architecture image support Simon Glass
@ 2011-09-17 19:29 ` Marek Vasut
2011-09-18 3:57 ` Simon Glass
0 siblings, 1 reply; 57+ messages in thread
From: Marek Vasut @ 2011-09-17 19:29 UTC (permalink / raw)
To: u-boot
On Saturday, September 17, 2011 06:48:41 PM Simon Glass wrote:
> We won't actually load an image with this architecture, but we still need
> to define it.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
> common/image.c | 5 +++--
> include/image.h | 3 +++
> 2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/common/image.c b/common/image.c
> index d38ce4a..8283561 100644
> --- a/common/image.c
> +++ b/common/image.c
> @@ -1581,7 +1581,7 @@ int boot_get_fdt (int flag, int argc, char * const
> argv[], bootm_headers_t *imag goto error;
> }
>
> - printf (" Booting using the fdt blob at 0x%x\n",
(int)fdt_blob);
> + printf(" Booting using the fdt blob at 0x%p\n", fdt_blob);
Well this is a fix and the patch description doesn't match it.
Can you split it or something?
Cheers
^ permalink raw reply [flat|nested] 57+ messages in thread* [U-Boot] [RFC PATCH 02/20] sandbox: Add architecture image support
2011-09-17 19:29 ` Marek Vasut
@ 2011-09-18 3:57 ` Simon Glass
0 siblings, 0 replies; 57+ messages in thread
From: Simon Glass @ 2011-09-18 3:57 UTC (permalink / raw)
To: u-boot
On Sat, Sep 17, 2011 at 12:29 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> On Saturday, September 17, 2011 06:48:41 PM Simon Glass wrote:
>> We won't actually load an image with this architecture, but we still need
>> to define it.
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>> ---
>> ?common/image.c ?| ? ?5 +++--
>> ?include/image.h | ? ?3 +++
>> ?2 files changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/common/image.c b/common/image.c
>> index d38ce4a..8283561 100644
>> --- a/common/image.c
>> +++ b/common/image.c
>> @@ -1581,7 +1581,7 @@ int boot_get_fdt (int flag, int argc, char * const
>> argv[], bootm_headers_t *imag goto error;
>> ? ? ? ? ? ? ? }
>>
>> - ? ? ? ? ? ? printf (" ? Booting using the fdt blob at 0x%x\n",
> (int)fdt_blob);
>> + ? ? ? ? ? ? printf(" ? Booting using the fdt blob at 0x%p\n", fdt_blob);
>
> Well this is a fix and the patch description doesn't match it.
>
> Can you split it or something?
Yes ok, there are a couple like this. When this becomes real patch I
will separate them out. This one should be split so that image.c and
image.h are separate patches.
Regards,
Simon
>
> Cheers
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [RFC PATCH 03/20] sandbox: Add compiler defines to support a 64-bit x86_64 platform
2011-09-17 16:48 [U-Boot] [RFC PATCH 01/20] sandbox: Add architecture header files Simon Glass
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 02/20] sandbox: Add architecture image support Simon Glass
@ 2011-09-17 16:48 ` Simon Glass
2011-09-17 23:56 ` Mike Frysinger
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 04/20] sandbox: Add cpu files Simon Glass
` (17 subsequent siblings)
19 siblings, 1 reply; 57+ messages in thread
From: Simon Glass @ 2011-09-17 16:48 UTC (permalink / raw)
To: u-boot
Temporary fix for 64-bit building.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
include/compiler.h | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/include/compiler.h b/include/compiler.h
index 4e047c7..78f8f0a 100644
--- a/include/compiler.h
+++ b/include/compiler.h
@@ -111,11 +111,21 @@ typedef unsigned int uint;
#include <linux/types.h>
#include <asm/byteorder.h>
+#if __SIZEOF_LONG__ == 8
+# define __WORDSIZE 64
+#elif __SIZEOF_LONG__ == 4
+# define __WORDSIZE 32
+#else
+#error "__SIZEOF_LONG__ has unexpected value"
+#endif
+
/* Types for `void *' pointers. */
#if __WORDSIZE == 64
typedef unsigned long int uintptr_t;
-#else
+#elif __WORDSIZE == 32
typedef unsigned int uintptr_t;
+#else
+#error "__WORDSIZE has unexpected value"
#endif
#endif
--
1.7.3.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [RFC PATCH 04/20] sandbox: Add cpu files
2011-09-17 16:48 [U-Boot] [RFC PATCH 01/20] sandbox: Add architecture header files Simon Glass
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 02/20] sandbox: Add architecture image support Simon Glass
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 03/20] sandbox: Add compiler defines to support a 64-bit x86_64 platform Simon Glass
@ 2011-09-17 16:48 ` Simon Glass
2011-09-17 23:58 ` Mike Frysinger
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 05/20] sandbox: Add architecture lib files Simon Glass
` (16 subsequent siblings)
19 siblings, 1 reply; 57+ messages in thread
From: Simon Glass @ 2011-09-17 16:48 UTC (permalink / raw)
To: u-boot
This is an initial implementation with all functions defined but not working.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
arch/sandbox/config.mk | 21 ++++++++++++
arch/sandbox/cpu/sandbox/Makefile | 47 +++++++++++++++++++++++++++
arch/sandbox/cpu/sandbox/cpu.c | 59 +++++++++++++++++++++++++++++++++++
arch/sandbox/cpu/sandbox/u-boot.lds | 34 ++++++++++++++++++++
4 files changed, 161 insertions(+), 0 deletions(-)
create mode 100644 arch/sandbox/config.mk
create mode 100644 arch/sandbox/cpu/sandbox/Makefile
create mode 100644 arch/sandbox/cpu/sandbox/cpu.c
create mode 100644 arch/sandbox/cpu/sandbox/u-boot.lds
diff --git a/arch/sandbox/config.mk b/arch/sandbox/config.mk
new file mode 100644
index 0000000..d9956ff
--- /dev/null
+++ b/arch/sandbox/config.mk
@@ -0,0 +1,21 @@
+# 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
+
+PLATFORM_CPPFLAGS += -DCONFIG_SANDBOX -D__SANDBOX__
+LDSCRIPT := $(SRCTREE)/$(CPUDIR)/u-boot.lds
diff --git a/arch/sandbox/cpu/sandbox/Makefile b/arch/sandbox/cpu/sandbox/Makefile
new file mode 100644
index 0000000..8dfa828
--- /dev/null
+++ b/arch/sandbox/cpu/sandbox/Makefile
@@ -0,0 +1,47 @@
+#
+# Copyright (c) 2011 The Chromium OS Authors.
+#
+# (C) Copyright 2000-2003
+# Wolfgang Denk, DENX Software Engineering, wd at denx.de.
+#
+# 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 $(TOPDIR)/config.mk
+
+LIB = $(obj)lib$(CPU).o
+
+COBJS := cpu.o
+
+SRCS := $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+
+all: $(obj).depend $(LIB)
+
+$(LIB): $(OBJS)
+ $(call cmd_link_o_target, $(OBJS))
+
+#########################################################################
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#########################################################################
diff --git a/arch/sandbox/cpu/sandbox/cpu.c b/arch/sandbox/cpu/sandbox/cpu.c
new file mode 100644
index 0000000..fd4ff1d
--- /dev/null
+++ b/arch/sandbox/cpu/sandbox/cpu.c
@@ -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
+ */
+
+#include <common.h>
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ return -1;
+}
+
+/* delay x useconds */
+void __udelay(unsigned long usec)
+{
+ /* Ignore this for now */
+}
+
+unsigned long timer_get_us(void)
+{
+ return 0;
+}
+
+int do_bootm_linux(int flag, int argc, char *argv[], bootm_headers_t *images)
+{
+ return -1;
+}
+
+int cleanup_before_linux(void)
+{
+ return 0;
+}
+
+void *map_physmem(phys_addr_t paddr, unsigned long len, unsigned long flags)
+{
+ return (void *)(gd->ram_buf + paddr);
+}
+
+void flush_dcache_range(unsigned long start, unsigned long stop)
+{
+}
diff --git a/arch/sandbox/cpu/sandbox/u-boot.lds b/arch/sandbox/cpu/sandbox/u-boot.lds
new file mode 100644
index 0000000..2d2e50f
--- /dev/null
+++ b/arch/sandbox/cpu/sandbox/u-boot.lds
@@ -0,0 +1,34 @@
+/*
+ * Copyright (c) 2011 The Chromium OS Authors.
+ * Use of this source code is governed by a BSD-style license that can be
+ * found in the LICENSE file.
+ *
+ * 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
+ */
+
+SECTIONS
+{
+ __u_boot_cmd_start = .;
+ .u_boot_cmd : { *(.u_boot_cmd) }
+ __u_boot_cmd_end = .;
+ __bss_start = .;
+
+}
+
+INSERT BEFORE .data;
--
1.7.3.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [RFC PATCH 04/20] sandbox: Add cpu files
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 04/20] sandbox: Add cpu files Simon Glass
@ 2011-09-17 23:58 ` Mike Frysinger
2011-09-23 15:54 ` Simon Glass
0 siblings, 1 reply; 57+ messages in thread
From: Mike Frysinger @ 2011-09-17 23:58 UTC (permalink / raw)
To: u-boot
On Saturday, September 17, 2011 12:48:43 Simon Glass wrote:
> --- /dev/null
> +++ b/arch/sandbox/config.mk
>
> +LDSCRIPT := $(SRCTREE)/$(CPUDIR)/u-boot.lds
the top level Makefile should take care of this for you so you can just delete
this line
> --- /dev/null
> +++ b/arch/sandbox/cpu/sandbox/cpu.c
>
> +int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> +{
> + return -1;
> +}
do_reset() is not supposed to return
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110917/ada43cd9/attachment.pgp
^ permalink raw reply [flat|nested] 57+ messages in thread* [U-Boot] [RFC PATCH 04/20] sandbox: Add cpu files
2011-09-17 23:58 ` Mike Frysinger
@ 2011-09-23 15:54 ` Simon Glass
2011-09-25 19:25 ` Wolfgang Denk
0 siblings, 1 reply; 57+ messages in thread
From: Simon Glass @ 2011-09-23 15:54 UTC (permalink / raw)
To: u-boot
Hi Mike,
On Sat, Sep 17, 2011 at 4:58 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Saturday, September 17, 2011 12:48:43 Simon Glass wrote:
>> --- /dev/null
>> +++ b/arch/sandbox/config.mk
>>
>> +LDSCRIPT := $(SRCTREE)/$(CPUDIR)/u-boot.lds
>
> the top level Makefile should take care of this for you so you can just delete
> this line
>
>> --- /dev/null
>> +++ b/arch/sandbox/cpu/sandbox/cpu.c
>>
>> +int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
>> +{
>> + ? ? return -1;
>> +}
>
> do_reset() is not supposed to return
I have adjusted the function meaning (which luckily for me was not
defined) so that it can return -1 on failure. This makes my code
correct :-)
I think it is reasonable to provide a reset function which might not
be able to do its job. That is the current state of sandbox.
Regards,
Simon
> -mike
>
^ permalink raw reply [flat|nested] 57+ messages in thread* [U-Boot] [RFC PATCH 04/20] sandbox: Add cpu files
2011-09-23 15:54 ` Simon Glass
@ 2011-09-25 19:25 ` Wolfgang Denk
2011-09-25 20:18 ` Simon Glass
0 siblings, 1 reply; 57+ messages in thread
From: Wolfgang Denk @ 2011-09-25 19:25 UTC (permalink / raw)
To: u-boot
Dear Simon Glass,
In message <CAPnjgZ1FfRPbU9gtxp9qVM24Ln2R-bWU1OjmrL3E+hijjLwiNQ@mail.gmail.com> you wrote:
>
> > do_reset() is not supposed to return
>
> I have adjusted the function meaning (which luckily for me was not
> defined) so that it can return -1 on failure. This makes my code
> correct :-)
>
> I think it is reasonable to provide a reset function which might not
> be able to do its job. That is the current state of sandbox.
No, I don't want to change the current definition of reset().
And "not able to do the job" is something different than
"unimplemented".
Why cannot we do a real reset here? Re-exec'in the running binary or
performing a longjmp() to the start might be ideas how to implement
this.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"The value of marriage is not that adults produce children, but that
children produce adults." - Peter De Vries
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [RFC PATCH 04/20] sandbox: Add cpu files
2011-09-25 19:25 ` Wolfgang Denk
@ 2011-09-25 20:18 ` Simon Glass
2011-09-26 4:48 ` Mike Frysinger
0 siblings, 1 reply; 57+ messages in thread
From: Simon Glass @ 2011-09-25 20:18 UTC (permalink / raw)
To: u-boot
Hi Wolfgang,
On Sun, Sep 25, 2011 at 12:25 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Simon Glass,
>
> In message <CAPnjgZ1FfRPbU9gtxp9qVM24Ln2R-bWU1OjmrL3E+hijjLwiNQ@mail.gmail.com> you wrote:
>>
>> > do_reset() is not supposed to return
>>
>> I have adjusted the function meaning (which luckily for me was not
>> defined) so that it can return -1 on failure. This makes my code
>> correct :-)
>>
>> I think it is reasonable to provide a reset function which might not
>> be able to do its job. That is the current state of sandbox.
>
> No, I don't want to change the current definition of reset().
OK.
>
>
> And "not able to do the job" is something different than
> "unimplemented".
>
> Why cannot we do a real reset here? Re-exec'in the running binary or
> performing a longjmp() to the start might be ideas how to implement
> this.
While this could be done I believe that it might be possible /
desirable to exit out of the main loop, rather than longjmp or
re-exec. I have not implemented it because I have not got to that bit
yet and don't want to put time into a solution I will throw away.
I'm happy to just put:
while (1) ;
in the reset code if you like?
Regards,
Simon
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> "The value of marriage is not that adults produce children, but ?that
> children produce adults." ? ? ? ? ? ? ? ? ? ? ? ? ? ?- Peter De Vries
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [RFC PATCH 04/20] sandbox: Add cpu files
2011-09-25 20:18 ` Simon Glass
@ 2011-09-26 4:48 ` Mike Frysinger
2011-09-26 16:49 ` Simon Glass
2011-09-26 18:12 ` Wolfgang Denk
0 siblings, 2 replies; 57+ messages in thread
From: Mike Frysinger @ 2011-09-26 4:48 UTC (permalink / raw)
To: u-boot
On Sunday, September 25, 2011 16:18:32 Simon Glass wrote:
> On Sun, Sep 25, 2011 at 12:25 PM, Wolfgang Denk wrote:
> > Simon Glass wrote:
> >> > do_reset() is not supposed to return
> >>
> >> I have adjusted the function meaning (which luckily for me was not
> >> defined) so that it can return -1 on failure. This makes my code
> >> correct :-)
> >>
> >> I think it is reasonable to provide a reset function which might not
> >> be able to do its job. That is the current state of sandbox.
> >
> > No, I don't want to change the current definition of reset().
>
> OK.
>
> > And "not able to do the job" is something different than
> > "unimplemented".
> >
> > Why cannot we do a real reset here? Re-exec'in the running binary or
> > performing a longjmp() to the start might be ideas how to implement
> > this.
>
> While this could be done I believe that it might be possible /
> desirable to exit out of the main loop, rather than longjmp or
> re-exec. I have not implemented it because I have not got to that bit
> yet and don't want to put time into a solution I will throw away.
>
> I'm happy to just put:
>
> while (1) ;
>
> in the reset code if you like?
i would expect "reset" in the sandbox to "exit(1)". how else would you exit ?
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110926/018b4d6e/attachment.pgp
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [RFC PATCH 04/20] sandbox: Add cpu files
2011-09-26 4:48 ` Mike Frysinger
@ 2011-09-26 16:49 ` Simon Glass
2011-09-26 17:10 ` Anton Staaf
2011-09-26 18:12 ` Wolfgang Denk
1 sibling, 1 reply; 57+ messages in thread
From: Simon Glass @ 2011-09-26 16:49 UTC (permalink / raw)
To: u-boot
Hi Mike,
On Sun, Sep 25, 2011 at 9:48 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Sunday, September 25, 2011 16:18:32 Simon Glass wrote:
>> On Sun, Sep 25, 2011 at 12:25 PM, Wolfgang Denk wrote:
>> > Simon Glass wrote:
>> >> > do_reset() is not supposed to return
>> >>
>> >> I have adjusted the function meaning (which luckily for me was not
>> >> defined) so that it can return -1 on failure. This makes my code
>> >> correct :-)
>> >>
>> >> I think it is reasonable to provide a reset function which might not
>> >> be able to do its job. That is the current state of sandbox.
>> >
>> > No, I don't want to change the current definition of reset().
>>
>> OK.
>>
>> > And "not able to do the job" is something different than
>> > "unimplemented".
>> >
>> > Why cannot we do a real reset here? Re-exec'in the running binary or
>> > performing a longjmp() to the start might be ideas how to implement
>> > this.
>>
>> While this could be done I believe that it might be possible /
>> desirable to exit out of the main loop, rather than longjmp or
>> re-exec. I have not implemented it because I have not got to that bit
>> yet and don't want to put time into a solution I will throw away.
>>
>> I'm happy to just put:
>>
>> while (1) ;
>>
>> in the reset code if you like?
>
> i would expect "reset" in the sandbox to "exit(1)". ?how else would you exit ?
> -mike
>
Right, I will do that then for now.
Regards,
Simon
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [RFC PATCH 04/20] sandbox: Add cpu files
2011-09-26 16:49 ` Simon Glass
@ 2011-09-26 17:10 ` Anton Staaf
2011-09-26 19:11 ` Simon Glass
0 siblings, 1 reply; 57+ messages in thread
From: Anton Staaf @ 2011-09-26 17:10 UTC (permalink / raw)
To: u-boot
On Mon, Sep 26, 2011 at 9:49 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Mike,
>
> On Sun, Sep 25, 2011 at 9:48 PM, Mike Frysinger <vapier@gentoo.org> wrote:
>> On Sunday, September 25, 2011 16:18:32 Simon Glass wrote:
>>> On Sun, Sep 25, 2011 at 12:25 PM, Wolfgang Denk wrote:
>>> > Simon Glass wrote:
>>> >> > do_reset() is not supposed to return
>>> >>
>>> >> I have adjusted the function meaning (which luckily for me was not
>>> >> defined) so that it can return -1 on failure. This makes my code
>>> >> correct :-)
>>> >>
>>> >> I think it is reasonable to provide a reset function which might not
>>> >> be able to do its job. That is the current state of sandbox.
>>> >
>>> > No, I don't want to change the current definition of reset().
>>>
>>> OK.
>>>
>>> > And "not able to do the job" is something different than
>>> > "unimplemented".
>>> >
>>> > Why cannot we do a real reset here? Re-exec'in the running binary or
>>> > performing a longjmp() to the start might be ideas how to implement
>>> > this.
>>>
>>> While this could be done I believe that it might be possible /
>>> desirable to exit out of the main loop, rather than longjmp or
>>> re-exec. I have not implemented it because I have not got to that bit
>>> yet and don't want to put time into a solution I will throw away.
>>>
>>> I'm happy to just put:
>>>
>>> while (1) ;
>>>
>>> in the reset code if you like?
>>
>> i would expect "reset" in the sandbox to "exit(1)". ?how else would you exit ?
>> -mike
>>
>
> Right, I will do that then for now.
Perhaps even nicer would be to define exit codes for the couple of cases where
we expect to "leave" U-Boot. So reset, and jump to linux kernel, and perhaps
power off. So a script calling the sandbox u-boot can check the reason and
possibly rerun it in the reset case.
Thanks,
Anton
> Regards,
> Simon
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
^ permalink raw reply [flat|nested] 57+ messages in thread* [U-Boot] [RFC PATCH 04/20] sandbox: Add cpu files
2011-09-26 17:10 ` Anton Staaf
@ 2011-09-26 19:11 ` Simon Glass
0 siblings, 0 replies; 57+ messages in thread
From: Simon Glass @ 2011-09-26 19:11 UTC (permalink / raw)
To: u-boot
Hi Anton,
On Mon, Sep 26, 2011 at 10:10 AM, Anton Staaf <robotboy@chromium.org> wrote:
> On Mon, Sep 26, 2011 at 9:49 AM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Mike,
>>
>> On Sun, Sep 25, 2011 at 9:48 PM, Mike Frysinger <vapier@gentoo.org> wrote:
>>> On Sunday, September 25, 2011 16:18:32 Simon Glass wrote:
>>>> On Sun, Sep 25, 2011 at 12:25 PM, Wolfgang Denk wrote:
>>>> > Simon Glass wrote:
>>>> >> > do_reset() is not supposed to return
>>>> >>
>>>> >> I have adjusted the function meaning (which luckily for me was not
>>>> >> defined) so that it can return -1 on failure. This makes my code
>>>> >> correct :-)
>>>> >>
>>>> >> I think it is reasonable to provide a reset function which might not
>>>> >> be able to do its job. That is the current state of sandbox.
>>>> >
>>>> > No, I don't want to change the current definition of reset().
>>>>
>>>> OK.
>>>>
>>>> > And "not able to do the job" is something different than
>>>> > "unimplemented".
>>>> >
>>>> > Why cannot we do a real reset here? Re-exec'in the running binary or
>>>> > performing a longjmp() to the start might be ideas how to implement
>>>> > this.
>>>>
>>>> While this could be done I believe that it might be possible /
>>>> desirable to exit out of the main loop, rather than longjmp or
>>>> re-exec. I have not implemented it because I have not got to that bit
>>>> yet and don't want to put time into a solution I will throw away.
>>>>
>>>> I'm happy to just put:
>>>>
>>>> while (1) ;
>>>>
>>>> in the reset code if you like?
>>>
>>> i would expect "reset" in the sandbox to "exit(1)". ?how else would you exit ?
>>> -mike
>>>
>>
>> Right, I will do that then for now.
>
> Perhaps even nicer would be to define exit codes for the couple of cases where
> we expect to "leave" U-Boot. ?So reset, and jump to linux kernel, and perhaps
> power off. ?So a script calling the sandbox u-boot can check the reason and
> possibly rerun it in the reset case.
Given the comments on this thread I will go with exit(EXIT_SUCCESS)
for now. But of course we will have to address this in test cases
later.
Regards,
Simon
>
> Thanks,
> ? ?Anton
>
>> Regards,
>> Simon
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>>
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [RFC PATCH 04/20] sandbox: Add cpu files
2011-09-26 4:48 ` Mike Frysinger
2011-09-26 16:49 ` Simon Glass
@ 2011-09-26 18:12 ` Wolfgang Denk
2011-09-26 18:16 ` Mike Frysinger
1 sibling, 1 reply; 57+ messages in thread
From: Wolfgang Denk @ 2011-09-26 18:12 UTC (permalink / raw)
To: u-boot
Dear Mike Frysinger,
In message <201109260048.41976.vapier@gentoo.org> you wrote:
>
> i would expect "reset" in the sandbox to "exit(1)". how else would you exit ?
"reset" should then use "exit(EXIT_SUCCESS)" as thisis a normal
termination of the program, not an error condition.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A Vulcan can no sooner be disloyal than he can exist without
breathing.
-- Kirk, "The Menagerie", stardate 3012.4
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [RFC PATCH 05/20] sandbox: Add architecture lib files
2011-09-17 16:48 [U-Boot] [RFC PATCH 01/20] sandbox: Add architecture header files Simon Glass
` (2 preceding siblings ...)
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 04/20] sandbox: Add cpu files Simon Glass
@ 2011-09-17 16:48 ` Simon Glass
2011-09-18 0:02 ` Mike Frysinger
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 06/20] sandbox: Allow board_init_f() and board_init_r() to return Simon Glass
` (15 subsequent siblings)
19 siblings, 1 reply; 57+ messages in thread
From: Simon Glass @ 2011-09-17 16:48 UTC (permalink / raw)
To: u-boot
These files are taken from the ARM board implementation and then reduced
to remove unneeded cr!uft.
Ideally we would work towards unifying arch/xxx/lib files, particularly
board.c.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
arch/sandbox/lib/Makefile | 62 +++++++++
arch/sandbox/lib/board.c | 294 +++++++++++++++++++++++++++++++++++++++++
arch/sandbox/lib/interrupts.c | 39 ++++++
3 files changed, 395 insertions(+), 0 deletions(-)
create mode 100644 arch/sandbox/lib/Makefile
create mode 100644 arch/sandbox/lib/board.c
create mode 100644 arch/sandbox/lib/interrupts.c
diff --git a/arch/sandbox/lib/Makefile b/arch/sandbox/lib/Makefile
new file mode 100644
index 0000000..a724406
--- /dev/null
+++ b/arch/sandbox/lib/Makefile
@@ -0,0 +1,62 @@
+#
+# Copyright (c) 2011 The Chromium OS Authors.
+#
+# (C) Copyright 2002-2006
+# Wolfgang Denk, DENX Software Engineering, wd at denx.de.
+#
+# 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 $(TOPDIR)/config.mk
+
+LIB = $(obj)lib$(ARCH).o
+LIBGCC = $(obj)libgcc.o
+
+COBJS-y += board.o
+COBJS-y += interrupts.o
+
+SRCS := $(COBJS-y:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS-y))
+LGOBJS := $(addprefix $(obj),$(GLSOBJS)) \
+ $(addprefix $(obj),$(GLCOBJS))
+
+# Always build libsandbox.o
+TARGETS := $(LIB)
+
+# Build private libgcc only when asked for
+ifdef USE_PRIVATE_LIBGCC
+TARGETS += $(LIBGCC)
+endif
+
+all: $(TARGETS)
+
+$(LIB): $(obj).depend $(OBJS)
+ $(call cmd_link_o_target, $(OBJS))
+
+$(LIBGCC): $(obj).depend $(LGOBJS)
+ $(call cmd_link_o_target, $(LGOBJS))
+
+#########################################################################
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#########################################################################
diff --git a/arch/sandbox/lib/board.c b/arch/sandbox/lib/board.c
new file mode 100644
index 0000000..24e8414
--- /dev/null
+++ b/arch/sandbox/lib/board.c
@@ -0,0 +1,294 @@
+/*
+ * Copyright (c) 2011 The Chromium OS Authors.
+ *
+ * (C) Copyright 2002-2006
+ * Wolfgang Denk, DENX Software Engineering, wd at denx.de.
+ *
+ * (C) Copyright 2002
+ * Sysgo Real-Time Solutions, GmbH <www.elinos.com>
+ * Marius Groeger <mgroeger@sysgo.de>
+ *
+ * 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
+ */
+
+/*
+ * This file was taken from ARM and changed to remove things we don't
+ * need. This is most of it, so have tried to avoid being over-zealous!
+ * For example, we want to have an emulation of the 'DRAM' used by
+ * U-Boot.
+ *
+ * has been talk upstream of unifying the architectures w.r.t board.c,
+ * so the less change here the better.
+ */
+
+#include <common.h>
+#include <command.h>
+#include <malloc.h>
+#include <stdio_dev.h>
+#include <timestamp.h>
+#include <version.h>
+#include <serial.h>
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#ifndef CONFIG_IDENT_STRING
+#define CONFIG_IDENT_STRING ""
+#endif
+
+const char version_string[] =
+ U_BOOT_VERSION" (" U_BOOT_DATE " - " U_BOOT_TIME ")"CONFIG_IDENT_STRING;
+
+
+/************************************************************************
+ * Init Utilities *
+ ************************************************************************
+ * Some of this code should be moved into the core functions,
+ * or dropped completely,
+ * but let's get it working (again) first...
+ */
+
+static int display_banner(void)
+{
+ printf("\n\n%s\n\n", version_string);
+ debug("U-Boot code: %08lX -> %08lX BSS: -> %08lX\n",
+ _TEXT_BASE,
+ _bss_start_ofs+_TEXT_BASE, _bss_end_ofs+_TEXT_BASE);
+
+ return 0;
+}
+
+/*
+ * WARNING: this code looks "cleaner" than the PowerPC version, but
+ * has the disadvantage that you either get nothing, or everything.
+ * On PowerPC, you might see "DRAM: " before the system hangs - which
+ * gives a simple yet clear indication which part of the
+ * initialization if failing.
+ */
+static int display_dram_config(void)
+{
+ int i;
+
+#ifdef DEBUG
+ puts("RAM Configuration:\n");
+
+ for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
+ printf("Bank #%d: %08lx ", i, gd->bd->bi_dram[i].start);
+ print_size(gd->bd->bi_dram[i].size, "\n");
+ }
+#else
+ ulong size = 0;
+
+ for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++)
+ size += gd->bd->bi_dram[i].size;
+ puts("DRAM: ");
+ print_size(size, "\n");
+#endif
+
+ return 0;
+}
+
+/*
+ * Breathe some life into the board...
+ *
+ * Initialize a serial port as console, and carry out some hardware
+ * tests.
+ *
+ * The first part of initialization is running from Flash memory;
+ * its main purpose is to initialize the RAM so that we
+ * can relocate the monitor code to RAM.
+ */
+
+/*
+ * All attempts to come up with a "common" initialization sequence
+ * that works for all boards and architectures failed: some of the
+ * requirements are just _too_ different. To get rid of the resulting
+ * mess of board dependent #ifdef'ed code we now make the whole
+ * initialization sequence configurable to the user.
+ *
+ * The requirements for any new initalization function is simple: it
+ * receives a pointer to the "global data" structure as it's only
+ * argument, and returns an integer return code, where 0 means
+ * "continue" and != 0 means "fatal error, hang the system".
+ */
+typedef int (init_fnc_t) (void);
+
+void __dram_init_banksize(void)
+{
+ gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
+ gd->bd->bi_dram[0].size = gd->ram_size;
+}
+
+void dram_init_banksize(void)
+ __attribute__((weak, alias("__dram_init_banksize")));
+
+init_fnc_t *init_sequence[] = {
+#if defined(CONFIG_ARCH_CPU_INIT)
+ arch_cpu_init, /* basic arch cpu dependent setup */
+#endif
+#if defined(CONFIG_BOARD_EARLY_INIT_F)
+ board_early_init_f,
+#endif
+ timer_init, /* initialize timer */
+ env_init, /* initialize environment */
+ serial_init, /* serial communications setup */
+ console_init_f, /* stage 1 init of console */
+ display_banner, /* say that we are here */
+#if defined(CONFIG_DISPLAY_CPUINFO)
+ print_cpuinfo, /* display cpu info (and speed) */
+#endif
+#if defined(CONFIG_DISPLAY_BOARDINFO)
+ checkboard, /* display board info */
+#endif
+ dram_init, /* configure available RAM banks */
+ NULL,
+};
+
+void board_init_f(ulong bootflag)
+{
+ init_fnc_t **init_fnc_ptr;
+ uchar *mem;
+ unsigned long addr_sp, addr, size;
+
+ gd = malloc(sizeof(gd_t));
+ assert(gd);
+
+ memset((void *)gd, 0, sizeof(gd_t));
+
+ gd->mon_len = 0; /* _bss_end_ofs;*/
+
+ for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
+ if ((*init_fnc_ptr)() != 0)
+ hang();
+ }
+
+ size = 128 * 1024 * 1024;
+ mem = malloc(size);
+ assert(mem);
+ gd->ram_buf = mem;
+ addr = (ulong)(mem + size);
+
+ /*
+ * reserve memory for malloc() arena
+ */
+ addr_sp = addr - TOTAL_MALLOC_LEN;
+ debug("Reserving %dk for malloc() at: %08lx\n",
+ TOTAL_MALLOC_LEN >> 10, addr_sp);
+ /*
+ * (permanently) allocate a Board Info struct
+ * and a permanent copy of the "global" data
+ */
+ addr_sp -= sizeof(bd_t);
+ gd->bd = (bd_t *) addr_sp;
+ debug("Reserving %zu Bytes for Board Info at: %08lx\n",
+ sizeof(bd_t), addr_sp);
+
+#ifdef CONFIG_POST
+ post_bootmode_init();
+ post_run(NULL, POST_ROM | post_bootmode_get(0));
+#endif
+
+ /* Ram ist board specific, so move it to board code ... */
+ dram_init_banksize();
+ display_dram_config(); /* and display it */
+}
+
+#if !defined(CONFIG_SYS_NO_FLASH)
+static char *failed = "*** failed ***\n";
+#endif
+
+/************************************************************************
+ *
+ * This is the next part if the initialization sequence: we are now
+ * running from RAM and have a "normal" C environment, i. e. global
+ * data can be written, BSS has been cleared, the stack size in not
+ * that critical any more, etc.
+ *
+ ************************************************************************
+ */
+
+void board_init_r(gd_t *id, ulong dest_addr)
+{
+
+ if (id)
+ gd = id;
+
+ gd->flags |= GD_FLG_RELOC; /* tell others: relocation done */
+
+ board_init(); /* Setup chipselects */
+
+#ifdef CONFIG_SERIAL_MULTI
+ serial_initialize();
+#endif
+
+#ifdef CONFIG_POST
+ post_output_backlog();
+#endif
+
+#if 0 /* Sandbox uses system malloc for now */
+ /* The Malloc area is immediately below the monitor copy in DRAM */
+ malloc_start = dest_addr - TOTAL_MALLOC_LEN;
+ mem_malloc_init(malloc_start, TOTAL_MALLOC_LEN);
+#endif
+
+ /* initialize environment */
+ env_relocate();
+
+ /* IP Address */
+ gd->bd->bi_ip_addr = getenv_IPaddr("ipaddr");
+
+ stdio_init(); /* get the devices list going. */
+
+ jumptable_init();
+
+ console_init_r(); /* fully init console as a device */
+
+#if defined(CONFIG_DISPLAY_BOARDINFO_LATE)
+ checkboard();
+#endif
+
+#if defined(CONFIG_ARCH_MISC_INIT)
+ /* miscellaneous arch dependent initialisations */
+ arch_misc_init();
+#endif
+#if defined(CONFIG_MISC_INIT_R)
+ /* miscellaneous platform dependent initialisations */
+ misc_init_r();
+#endif
+
+ /* set up exceptions */
+ interrupt_init();
+ /* enable exceptions */
+ enable_interrupts();
+
+#ifdef BOARD_LATE_INIT
+ board_late_init();
+#endif
+
+#ifdef CONFIG_POST
+ post_run(NULL, POST_RAM | post_bootmode_get(0));
+#endif
+
+}
+
+void hang(void)
+{
+ puts("### ERROR ### Please RESET the board ###\n");
+ for (;;)
+ ;
+}
diff --git a/arch/sandbox/lib/interrupts.c b/arch/sandbox/lib/interrupts.c
new file mode 100644
index 0000000..d350108
--- /dev/null
+++ b/arch/sandbox/lib/interrupts.c
@@ -0,0 +1,39 @@
+/*
+ * Copyright (c) 2011 The Chromium OS Authors.
+ * Use of this source code is governed by a BSD-style license that can be
+ * found in the LICENSE file.
+ *
+ * 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>
+
+int interrupt_init(void)
+{
+ return 0;
+}
+
+void enable_interrupts(void)
+{
+ return;
+}
+int disable_interrupts(void)
+{
+ return 0;
+}
--
1.7.3.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [RFC PATCH 05/20] sandbox: Add architecture lib files
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 05/20] sandbox: Add architecture lib files Simon Glass
@ 2011-09-18 0:02 ` Mike Frysinger
0 siblings, 0 replies; 57+ messages in thread
From: Mike Frysinger @ 2011-09-18 0:02 UTC (permalink / raw)
To: u-boot
On Saturday, September 17, 2011 12:48:44 Simon Glass wrote:
> These files are taken from the ARM board implementation and then reduced
> to remove unneeded cr!uft.
"cr!uft" -> "cruft"
> --- /dev/null
> +++ b/arch/sandbox/lib/Makefile
>
> +LIBGCC = $(obj)libgcc.o
>
> +LGOBJS := $(addprefix $(obj),$(GLSOBJS)) \
> + $(addprefix $(obj),$(GLCOBJS))
>
> +# Build private libgcc only when asked for
> +ifdef USE_PRIVATE_LIBGCC
> +TARGETS += $(LIBGCC)
> +endif
>
> +$(LIBGCC): $(obj).depend $(LGOBJS)
> + $(call cmd_link_o_target, $(LGOBJS))
i think this is arm cruft that should get scrubbed here
> --- /dev/null
> +++ b/arch/sandbox/lib/board.c
>
> +#ifndef CONFIG_IDENT_STRING
> +#define CONFIG_IDENT_STRING ""
> +#endif
> +
> +const char version_string[] =
> + U_BOOT_VERSION" (" U_BOOT_DATE " - " U_BOOT_TIME ")"CONFIG_IDENT_STRING;
common code takes care of this for you already, so just delete it
> +static int display_banner(void)
> +{
> + printf("\n\n%s\n\n", version_string);
call display_options() instead of writing version_string yourself
> +static int display_dram_config(void)
is any of this dram logic needed ? looks like an ARM wart that should get
removed from all the sandbox code.
> +#if !defined(CONFIG_SYS_NO_FLASH)
> +static char *failed = "*** failed ***\n";
> +#endif
i dont see this getting used anywhere, so punt it
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110917/4c636a31/attachment.pgp
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [RFC PATCH 06/20] sandbox: Allow board_init_f() and board_init_r() to return
2011-09-17 16:48 [U-Boot] [RFC PATCH 01/20] sandbox: Add architecture header files Simon Glass
` (3 preceding siblings ...)
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 05/20] sandbox: Add architecture lib files Simon Glass
@ 2011-09-17 16:48 ` Simon Glass
2011-09-18 0:05 ` Mike Frysinger
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 07/20] sandbox: Add sandbox board Simon Glass
` (14 subsequent siblings)
19 siblings, 1 reply; 57+ messages in thread
From: Simon Glass @ 2011-09-17 16:48 UTC (permalink / raw)
To: u-boot
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.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
include/common.h | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/common.h b/include/common.h
index 2a39df3..7ae9bcf 100644
--- a/include/common.h
+++ b/include/common.h
@@ -262,8 +262,13 @@ void init_cmd_timeout(void);
void reset_cmd_timeout(void);
/* arch/$(ARCH)/lib/board.c */
-void board_init_f (ulong) __attribute__ ((noreturn));
-void board_init_r (gd_t *, ulong) __attribute__ ((noreturn));
+#ifdef CONFIG_SANDBOX
+void board_init_f(ulong);
+void board_init_r(gd_t *, ulong);
+#else
+void board_init_f(ulong) __attribute__ ((noreturn));
+void board_init_r(gd_t *, ulong) __attribute__ ((noreturn));
+#endif
int checkboard (void);
int checkflash (void);
int checkdram (void);
--
1.7.3.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [RFC PATCH 06/20] sandbox: Allow board_init_f() and board_init_r() to return
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 06/20] sandbox: Allow board_init_f() and board_init_r() to return Simon Glass
@ 2011-09-18 0:05 ` Mike Frysinger
2011-09-23 15:55 ` Simon Glass
0 siblings, 1 reply; 57+ messages in thread
From: Mike Frysinger @ 2011-09-18 0:05 UTC (permalink / raw)
To: u-boot
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()
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110917/b3972e85/attachment.pgp
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [RFC PATCH 06/20] sandbox: Allow board_init_f() and board_init_r() to return
2011-09-18 0:05 ` Mike Frysinger
@ 2011-09-23 15:55 ` Simon Glass
2011-09-25 19:55 ` Wolfgang Denk
2011-09-26 4:47 ` Mike Frysinger
0 siblings, 2 replies; 57+ messages in thread
From: Simon Glass @ 2011-09-23 15:55 UTC (permalink / raw)
To: u-boot
Hi Mike,
On Sat, Sep 17, 2011 at 5:05 PM, Mike Frysinger <vapier@gentoo.org> 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.
Regards,
Simon
> -mike
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [RFC PATCH 06/20] sandbox: Allow board_init_f() and board_init_r() to return
2011-09-23 15:55 ` Simon Glass
@ 2011-09-25 19:55 ` Wolfgang Denk
2011-09-25 20:20 ` Simon Glass
2011-09-26 4:47 ` Mike Frysinger
1 sibling, 1 reply; 57+ messages in thread
From: Wolfgang Denk @ 2011-09-25 19:55 UTC (permalink / raw)
To: u-boot
Dear Simon Glass,
In message <CAPnjgZ1DfWHum=WuzRh75eU7raf_QbCWorc6YpkhhuBzOP1B0Q@mail.gmail.com> you wrote:
>
> On Sat, Sep 17, 2011 at 5:05 PM, Mike Frysinger <vapier@gentoo.org> wrote:
...
> > NAK; i dont see how sandbox is special. just do what i do in Blackfin's
...
> 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 think the argument that the sandbox should be implemented and
behave like the real implementations is a very important one. Please
let's stick to that.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A mouse is an elephant built by the Japanese.
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [RFC PATCH 06/20] sandbox: Allow board_init_f() and board_init_r() to return
2011-09-25 19:55 ` Wolfgang Denk
@ 2011-09-25 20:20 ` Simon Glass
0 siblings, 0 replies; 57+ messages in thread
From: Simon Glass @ 2011-09-25 20:20 UTC (permalink / raw)
To: u-boot
Hi Wolfgang,
On Sun, Sep 25, 2011 at 12:55 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Simon Glass,
>
> In message <CAPnjgZ1DfWHum=WuzRh75eU7raf_QbCWorc6YpkhhuBzOP1B0Q@mail.gmail.com> you wrote:
>>
>> On Sat, Sep 17, 2011 at 5:05 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> ...
>> > NAK; i dont see how sandbox is special. ?just do what i do in Blackfin's
> ...
>> 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 think the argument that the sandbox should be implemented and
> behave like the real implementations is a very important one. ?Please
> let's stick to that.
OK, with RFV patch set v2 I have made the code match existing
architectures in this area.
Regards,
Simon
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> A mouse is an elephant built by the Japanese.
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [RFC PATCH 06/20] sandbox: Allow board_init_f() and board_init_r() to return
2011-09-23 15:55 ` Simon Glass
2011-09-25 19:55 ` Wolfgang Denk
@ 2011-09-26 4:47 ` Mike Frysinger
2011-09-26 16:48 ` Simon Glass
1 sibling, 1 reply; 57+ messages in thread
From: Mike Frysinger @ 2011-09-26 4:47 UTC (permalink / raw)
To: u-boot
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110926/b7996b97/attachment.pgp
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [RFC PATCH 06/20] sandbox: Allow board_init_f() and board_init_r() to return
2011-09-26 4:47 ` Mike Frysinger
@ 2011-09-26 16:48 ` Simon Glass
2011-09-26 17:49 ` Anton Staaf
0 siblings, 1 reply; 57+ messages in thread
From: Simon Glass @ 2011-09-26 16:48 UTC (permalink / raw)
To: u-boot
Hi Mike,
On Sun, Sep 25, 2011 at 9:47 PM, Mike Frysinger <vapier@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.
Regards,
Simon
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [RFC PATCH 06/20] sandbox: Allow board_init_f() and board_init_r() to return
2011-09-26 16:48 ` Simon Glass
@ 2011-09-26 17:49 ` Anton Staaf
2011-09-26 19:22 ` Simon Glass
0 siblings, 1 reply; 57+ messages in thread
From: Anton Staaf @ 2011-09-26 17:49 UTC (permalink / raw)
To: u-boot
On Mon, Sep 26, 2011 at 9:48 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Mike,
>
> On Sun, Sep 25, 2011 at 9:47 PM, Mike Frysinger <vapier@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.
Thanks,
Anton
> Regards,
> Simon
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
^ permalink raw reply [flat|nested] 57+ messages in thread* [U-Boot] [RFC PATCH 06/20] sandbox: Allow board_init_f() and board_init_r() to return
2011-09-26 17:49 ` Anton Staaf
@ 2011-09-26 19:22 ` Simon Glass
2011-09-26 19:25 ` Anton Staaf
0 siblings, 1 reply; 57+ messages in thread
From: Simon Glass @ 2011-09-26 19:22 UTC (permalink / raw)
To: u-boot
Hi Anton,
On Mon, Sep 26, 2011 at 10:49 AM, Anton Staaf <robotboy@chromium.org> wrote:
> On Mon, Sep 26, 2011 at 9:48 AM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Mike,
>>
>> On Sun, Sep 25, 2011 at 9:47 PM, Mike Frysinger <vapier@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
>>
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [RFC PATCH 06/20] sandbox: Allow board_init_f() and board_init_r() to return
2011-09-26 19:22 ` Simon Glass
@ 2011-09-26 19:25 ` Anton Staaf
0 siblings, 0 replies; 57+ messages in thread
From: Anton Staaf @ 2011-09-26 19:25 UTC (permalink / raw)
To: u-boot
On Mon, Sep 26, 2011 at 12:22 PM, Simon Glass <sjg@chromium.org> wrote:
> Hi Anton,
>
> On Mon, Sep 26, 2011 at 10:49 AM, Anton Staaf <robotboy@chromium.org> wrote:
>> On Mon, Sep 26, 2011 at 9:48 AM, Simon Glass <sjg@chromium.org> wrote:
>>> Hi Mike,
>>>
>>> On Sun, Sep 25, 2011 at 9:47 PM, Mike Frysinger <vapier@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
>>>
>>
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [RFC PATCH 07/20] sandbox: Add sandbox board
2011-09-17 16:48 [U-Boot] [RFC PATCH 01/20] sandbox: Add architecture header files Simon Glass
` (4 preceding siblings ...)
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 06/20] sandbox: Allow board_init_f() and board_init_r() to return Simon Glass
@ 2011-09-17 16:48 ` Simon Glass
2011-09-18 0:17 ` Mike Frysinger
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 08/20] sandbox: Add board info for architecture Simon Glass
` (13 subsequent siblings)
19 siblings, 1 reply; 57+ messages in thread
From: Simon Glass @ 2011-09-17 16:48 UTC (permalink / raw)
To: u-boot
This adds basic files for the sandbox board. The lds file is very simple
since we can rely mostly on the linker defaults.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
board/sandbox/sandbox/Makefile | 50 ++++++++++++++++++++++++++++++++++++
board/sandbox/sandbox/sandbox.c | 54 +++++++++++++++++++++++++++++++++++++++
boards.cfg | 1 +
3 files changed, 105 insertions(+), 0 deletions(-)
create mode 100644 board/sandbox/sandbox/Makefile
create mode 100644 board/sandbox/sandbox/sandbox.c
diff --git a/board/sandbox/sandbox/Makefile b/board/sandbox/sandbox/Makefile
new file mode 100644
index 0000000..ce1c01c
--- /dev/null
+++ b/board/sandbox/sandbox/Makefile
@@ -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 Foundatio; 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 $(TOPDIR)/config.mk
+
+$(shell mkdir -p $(obj)../common)
+
+LIB = $(obj)lib$(BOARD).o
+
+COBJS := $(BOARD).o
+
+SRCS := $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+
+$(LIB): $(obj).depend $(OBJS)
+ $(AR) $(ARFLAGS) $@ $(OBJS)
+
+clean:
+ rm -f $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak $(obj).depend
+
+#########################################################################
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#########################################################################
diff --git a/board/sandbox/sandbox/sandbox.c b/board/sandbox/sandbox/sandbox.c
new file mode 100644
index 0000000..c12c231
--- /dev/null
+++ b/board/sandbox/sandbox/sandbox.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 <common.h>
+
+/*
+ * Pointer to initial global data area
+ *
+ * Here we initialize it.
+ */
+#undef XTRN_DECLARE_GLOBAL_DATA_PTR
+#define XTRN_DECLARE_GLOBAL_DATA_PTR /* empty = allocate here */
+DECLARE_GLOBAL_DATA_PTR;
+
+gd_t *gd;
+
+
+void flush_cache(unsigned long start, unsigned long size)
+{
+}
+
+ulong get_timer(ulong base)
+{
+ return 0;
+}
+
+int timer_init(void)
+{
+ return 0;
+}
+
+int dram_init(void)
+{
+ gd->ram_size = CONFIG_DRAM_SIZE;
+ return 0;
+}
diff --git a/boards.cfg b/boards.cfg
index 8a5bfc1..2af8473 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -259,6 +259,7 @@ tcm-bf518 blackfin blackfin
tcm-bf537 blackfin blackfin
eNET x86 x86 eNET - sc520 eNET:SYS_TEXT_BASE=0x38040000
eNET_SRAM x86 x86 eNET - sc520 eNET:SYS_TEXT_BASE=0x19000000
+sandbox sandbox sandbox sandbox sandbox -
idmr m68k mcf52x2
TASREG m68k mcf52x2 tasreg esd
M5208EVBE m68k mcf52x2 m5208evbe freescale
--
1.7.3.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [RFC PATCH 08/20] sandbox: Add board info for architecture
2011-09-17 16:48 [U-Boot] [RFC PATCH 01/20] sandbox: Add architecture header files Simon Glass
` (5 preceding siblings ...)
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 07/20] sandbox: Add sandbox board Simon Glass
@ 2011-09-17 16:48 ` Simon Glass
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 09/20] sandbox: Add bootm support Simon Glass
` (12 subsequent siblings)
19 siblings, 0 replies; 57+ messages in thread
From: Simon Glass @ 2011-09-17 16:48 UTC (permalink / raw)
To: u-boot
This is required for the bdinfo command to work.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
common/cmd_bdinfo.c | 34 ++++++++++++++++++++++++++++++----
1 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/common/cmd_bdinfo.c b/common/cmd_bdinfo.c
index 6051120..0faca6f 100644
--- a/common/cmd_bdinfo.c
+++ b/common/cmd_bdinfo.c
@@ -31,11 +31,14 @@ DECLARE_GLOBAL_DATA_PTR;
static void print_num(const char *, ulong);
-#if !(defined(CONFIG_ARM) || defined(CONFIG_M68K)) || defined(CONFIG_CMD_NET)
+#if !(defined(CONFIG_ARM) || defined(CONFIG_M68K) || defined(CONFIG_SANDBOX))
+ || defined(CONFIG_CMD_NET)
+#define HAVE_PRINT_ETH
static void print_eth(int idx);
#endif
-#if (!defined(CONFIG_ARM) && !defined(CONFIG_X86))
+#if (!defined(CONFIG_ARM) && !defined(CONFIG_X86) && !defined(CONFIG_SANDBOX))
+#define HAVE_PRINT_LNUM
static void print_lnum(const char *, u64);
#endif
@@ -413,6 +416,29 @@ int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
return 0;
}
+#elif defined(CONFIG_SANDBOX)
+
+int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ int i;
+ bd_t *bd = gd->bd;
+
+ print_num("boot_params", (ulong)bd->bi_boot_params);
+
+ for (i = 0; i < CONFIG_NR_DRAM_BANKS; ++i) {
+ print_num("DRAM bank", i);
+ print_num("-> start", bd->bi_dram[i].start);
+ print_num("-> size", bd->bi_dram[i].size);
+ }
+
+#if defined(CONFIG_CMD_NET)
+ print_eth(0);
+ printf("ip_addr = %pI4\n", &bd->bi_ip_addr);
+#endif
+ print_num("FB base ", gd->fb_base);
+ return 0;
+}
+
#else
#error "a case for this architecture does not exist!"
#endif
@@ -422,7 +448,7 @@ static void print_num(const char *name, ulong value)
printf("%-12s= 0x%08lX\n", name, value);
}
-#if !(defined(CONFIG_ARM) || defined(CONFIG_M68K)) || defined(CONFIG_CMD_NET)
+#ifdef HAVE_PRINT_ETH
static void print_eth(int idx)
{
char name[10], *val;
@@ -437,7 +463,7 @@ static void print_eth(int idx)
}
#endif
-#if (!defined(CONFIG_ARM) && !defined(CONFIG_X86))
+#ifdef HAVE_PRINT_LNUM
static void print_lnum(const char *name, u64 value)
{
printf("%-12s= 0x%.8llX\n", name, value);
--
1.7.3.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [RFC PATCH 09/20] sandbox: Add bootm support
2011-09-17 16:48 [U-Boot] [RFC PATCH 01/20] sandbox: Add architecture header files Simon Glass
` (6 preceding siblings ...)
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 08/20] sandbox: Add board info for architecture Simon Glass
@ 2011-09-17 16:48 ` Simon Glass
2011-09-18 0:16 ` Mike Frysinger
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 10/20] sandbox: Disable built-in malloc Simon Glass
` (11 subsequent siblings)
19 siblings, 1 reply; 57+ messages in thread
From: Simon Glass @ 2011-09-17 16:48 UTC (permalink / raw)
To: u-boot
This adds sandbox architecture support to bootm, although it is probably
not useful to load sandbox code into the address space and execute it.
These changes at least make the file build correctly on 64-bit machines.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
common/cmd_bootm.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 8909ee7..b16e242 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -187,6 +187,8 @@ void arch_preboot_os(void) __attribute__((weak, alias("__arch_preboot_os")));
#define IH_INITRD_ARCH IH_ARCH_SH
#elif defined(__sparc__)
#define IH_INITRD_ARCH IH_ARCH_SPARC
+#elif defined(CONFIG_SANDBOX_ARCH)
+ #define IH_INITRD_ARCH IH_ARCH_SANDBOX
#else
# error Unknown CPU type
#endif
@@ -453,7 +455,9 @@ static int bootm_load_os(image_info_t os, ulong *load_end, int boot_progress)
static int bootm_start_standalone(ulong iflag, int argc, char * const argv[])
{
char *s;
+#if BITS_PER_LONG == 32
int (*appl)(int, char * const []);
+#endif
/* Don't start if "autostart" is set to "no" */
if (((s = getenv("autostart")) != NULL) && (strcmp(s, "no") == 0)) {
@@ -462,9 +466,10 @@ static int bootm_start_standalone(ulong iflag, int argc, char * const argv[])
setenv("filesize", buf);
return 0;
}
+#if BITS_PER_LONG == 32
appl = (int (*)(int, char * const []))ntohl(images.ep);
(*appl)(argc-1, &argv[1]);
-
+#endif
return 0;
}
@@ -488,14 +493,14 @@ static cmd_tbl_t cmd_bootm_sub[] = {
int do_bootm_subcommand (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
int ret = 0;
- int state;
+ long state;
cmd_tbl_t *c;
boot_os_fn *boot_fn;
c = find_cmd_tbl(argv[1], &cmd_bootm_sub[0], ARRAY_SIZE(cmd_bootm_sub));
if (c) {
- state = (int)c->cmd;
+ state = (long)c->cmd;
/* treat start special since it resets the state machine */
if (state == BOOTM_STATE_START) {
--
1.7.3.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [RFC PATCH 09/20] sandbox: Add bootm support
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 09/20] sandbox: Add bootm support Simon Glass
@ 2011-09-18 0:16 ` Mike Frysinger
2011-09-23 15:55 ` Simon Glass
0 siblings, 1 reply; 57+ messages in thread
From: Mike Frysinger @ 2011-09-18 0:16 UTC (permalink / raw)
To: u-boot
On Saturday, September 17, 2011 12:48:48 Simon Glass wrote:
> --- a/common/cmd_bootm.c
> +++ b/common/cmd_bootm.c
>
> +#if BITS_PER_LONG == 32
> int (*appl)(int, char * const []);
> +#endif
>
> +#if BITS_PER_LONG == 32
> appl = (int (*)(int, char * const []))ntohl(images.ep);
> (*appl)(argc-1, &argv[1]);
> -
> +#endif
why do you need this ? if it's because you're converting from a 32bit int to
a pointer, then you could address this by putting an (unsigned long) cast
between the pointer and the ntohl() call.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110917/9b8c67d8/attachment.pgp
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [RFC PATCH 09/20] sandbox: Add bootm support
2011-09-18 0:16 ` Mike Frysinger
@ 2011-09-23 15:55 ` Simon Glass
0 siblings, 0 replies; 57+ messages in thread
From: Simon Glass @ 2011-09-23 15:55 UTC (permalink / raw)
To: u-boot
On Sat, Sep 17, 2011 at 5:16 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Saturday, September 17, 2011 12:48:48 Simon Glass wrote:
>> --- a/common/cmd_bootm.c
>> +++ b/common/cmd_bootm.c
>>
>> +#if BITS_PER_LONG == 32
>> ? ? ? int ? (*appl)(int, char * const []);
>> +#endif
>>
>> +#if BITS_PER_LONG == 32
>> ? ? ? appl = (int (*)(int, char * const []))ntohl(images.ep);
>> ? ? ? (*appl)(argc-1, &argv[1]);
>> -
>> +#endif
>
> why do you need this ? ?if it's because you're converting from a 32bit int to
> a pointer, then you could address this by putting an (unsigned long) cast
> between the pointer and the ntohl() call.
OK have done this.
> -mike
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [RFC PATCH 10/20] sandbox: Disable built-in malloc
2011-09-17 16:48 [U-Boot] [RFC PATCH 01/20] sandbox: Add architecture header files Simon Glass
` (7 preceding siblings ...)
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 09/20] sandbox: Add bootm support Simon Glass
@ 2011-09-17 16:48 ` Simon Glass
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 11/20] sandbox: Disable standalone/API support Simon Glass
` (10 subsequent siblings)
19 siblings, 0 replies; 57+ messages in thread
From: Simon Glass @ 2011-09-17 16:48 UTC (permalink / raw)
To: u-boot
We prefer to U-Boot's malloc but for now it is easier to use the C library's
version.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
common/Makefile | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/common/Makefile b/common/Makefile
index 2edbd71..8d17a54 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -29,7 +29,9 @@ LIB = $(obj)libcommon.o
ifndef CONFIG_SPL_BUILD
COBJS-y += main.o
COBJS-y += command.o
+ifndef CONFIG_SANDBOX
COBJS-y += dlmalloc.o
+endif
COBJS-y += exports.o
COBJS-$(CONFIG_SYS_HUSH_PARSER) += hush.o
COBJS-y += image.o
--
1.7.3.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [RFC PATCH 11/20] sandbox: Disable standalone/API support
2011-09-17 16:48 [U-Boot] [RFC PATCH 01/20] sandbox: Add architecture header files Simon Glass
` (8 preceding siblings ...)
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 10/20] sandbox: Disable built-in malloc Simon Glass
@ 2011-09-17 16:48 ` Simon Glass
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 12/20] sandbox: Force command sections to be 4-byte aligned Simon Glass
` (9 subsequent siblings)
19 siblings, 0 replies; 57+ messages in thread
From: Simon Glass @ 2011-09-17 16:48 UTC (permalink / raw)
To: u-boot
This is not useful on the sandbox architecture since we can simply link all
our code with U-Boot.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Makefile | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index e9ba6a4..672b5cd 100644
--- a/Makefile
+++ b/Makefile
@@ -137,9 +137,7 @@ unexport CDPATH
# The "tools" are needed early, so put this first
# Don't include stuff already done in $(LIBS)
-SUBDIRS = tools \
- examples/standalone \
- examples/api
+SUBDIRS = tools
.PHONY : $(SUBDIRS) $(VERSION_FILE)
@@ -156,6 +154,11 @@ sinclude $(obj)include/autoconf.mk
include $(obj)include/config.mk
export ARCH CPU BOARD VENDOR SOC
+ifndef CONFIG_SANDBOX
+SUBDIRS += examples/standalone \
+ examples/api
+endif
+
# set default to nothing for native builds
ifeq ($(HOSTARCH),$(ARCH))
CROSS_COMPILE ?=
--
1.7.3.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [RFC PATCH 12/20] sandbox: Force command sections to be 4-byte aligned
2011-09-17 16:48 [U-Boot] [RFC PATCH 01/20] sandbox: Add architecture header files Simon Glass
` (9 preceding siblings ...)
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 11/20] sandbox: Disable standalone/API support Simon Glass
@ 2011-09-17 16:48 ` Simon Glass
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 13/20] sandbox: Add OS dependent layer Simon Glass
` (8 subsequent siblings)
19 siblings, 0 replies; 57+ messages in thread
From: Simon Glass @ 2011-09-17 16:48 UTC (permalink / raw)
To: u-boot
By default sections are 16-byte aligned on some architectures, but the
command name structure (struct cmd_tbl_s) does not have padding to
16 bytes. This reduces the alignment to 4-bytes so that the command
table can be accessed correctly on any architecture.
(Note: this needs doing properly)
Signed-off-by: Simon Glass <sjg@chromium.org>
---
include/command.h | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/include/command.h b/include/command.h
index f1accd0..c270110 100644
--- a/include/command.h
+++ b/include/command.h
@@ -117,7 +117,8 @@ extern int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]);
#define CMD_FLAG_REPEAT 0x0001 /* repeat last command */
#define CMD_FLAG_BOOTD 0x0002 /* command is from bootd */
-#define Struct_Section __attribute__ ((unused,section (".u_boot_cmd")))
+#define Struct_Section __attribute__((unused, section(".u_boot_cmd"), \
+ aligned(4)))
#ifdef CONFIG_AUTO_COMPLETE
# define _CMD_COMPLETE(x) x,
--
1.7.3.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [RFC PATCH 13/20] sandbox: Add OS dependent layer
2011-09-17 16:48 [U-Boot] [RFC PATCH 01/20] sandbox: Add architecture header files Simon Glass
` (10 preceding siblings ...)
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 12/20] sandbox: Force command sections to be 4-byte aligned Simon Glass
@ 2011-09-17 16:48 ` Simon Glass
2011-09-18 0:20 ` Mike Frysinger
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 14/20] sandbox: Add board_init() Simon Glass
` (7 subsequent siblings)
19 siblings, 1 reply; 57+ messages in thread
From: Simon Glass @ 2011-09-17 16:48 UTC (permalink / raw)
To: u-boot
We want to keep all OS-dependent code in once place, with a simple interface
to U-Boot. For now, this is that place.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
arch/sandbox/config.mk | 2 +-
board/sandbox/common/Makefile | 47 +++++++++++++++++++++++++++++++++++++++
board/sandbox/common/os.c | 49 +++++++++++++++++++++++++++++++++++++++++
include/os.h | 27 ++++++++++++++++++++++
4 files changed, 124 insertions(+), 1 deletions(-)
create mode 100644 board/sandbox/common/Makefile
create mode 100644 board/sandbox/common/os.c
create mode 100644 include/os.h
diff --git a/arch/sandbox/config.mk b/arch/sandbox/config.mk
index d9956ff..f0f1472 100644
--- a/arch/sandbox/config.mk
+++ b/arch/sandbox/config.mk
@@ -17,5 +17,5 @@
# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
# MA 02111-1307 USA
-PLATFORM_CPPFLAGS += -DCONFIG_SANDBOX -D__SANDBOX__
+PLATFORM_CPPFLAGS += -DCONFIG_SANDBOX -D__SANDBOX__ -I/usr/include
LDSCRIPT := $(SRCTREE)/$(CPUDIR)/u-boot.lds
diff --git a/board/sandbox/common/Makefile b/board/sandbox/common/Makefile
new file mode 100644
index 0000000..3289368
--- /dev/null
+++ b/board/sandbox/common/Makefile
@@ -0,0 +1,47 @@
+# 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 $(TOPDIR)/config.mk
+
+LIB = $(obj)lib$(VENDOR).o
+
+COBJS-y += os.o
+
+COBJS := $(COBJS-y)
+SRCS := $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+
+all: $(LIB)
+
+$(LIB): $(obj).depend $(OBJS)
+ $(call cmd_link_o_target, $(OBJS))
+
+clean:
+ rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak $(obj).depend
+
+#########################################################################
+# This is for $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#########################################################################
diff --git a/board/sandbox/common/os.c b/board/sandbox/common/os.c
new file mode 100644
index 0000000..8df7b7e
--- /dev/null
+++ b/board/sandbox/common/os.c
@@ -0,0 +1,49 @@
+/*
+ * 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 <fcntl.h>
+#include <unistd.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+
+#include <os.h>
+
+/* Operating System Interface */
+
+ssize_t os_read(int fd, void *buf, size_t count)
+{
+ return read(fd, buf, count);
+}
+
+ssize_t os_write(int fd, const void *buf, size_t count)
+{
+ return write(fd, buf, count);
+}
+
+int os_open(const char *pathname, int flags)
+{
+ return open(pathname, flags);
+}
+
+int os_close(int fd)
+{
+ return close(fd);
+}
diff --git a/include/os.h b/include/os.h
new file mode 100644
index 0000000..3010920
--- /dev/null
+++ b/include/os.h
@@ -0,0 +1,27 @@
+/*
+ * 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
+ */
+
+/* Operating System Interface */
+
+ssize_t os_read(int fd, void *buf, size_t count);
+ssize_t os_write(int fd, const void *buf, size_t count);
+int os_open(const char *pathname, int flags);
+int os_close(int fd);
--
1.7.3.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [RFC PATCH 13/20] sandbox: Add OS dependent layer
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 13/20] sandbox: Add OS dependent layer Simon Glass
@ 2011-09-18 0:20 ` Mike Frysinger
2011-09-23 15:59 ` Simon Glass
0 siblings, 1 reply; 57+ messages in thread
From: Mike Frysinger @ 2011-09-18 0:20 UTC (permalink / raw)
To: u-boot
On Saturday, September 17, 2011 12:48:52 Simon Glass wrote:
> --- a/arch/sandbox/config.mk
> +++ b/arch/sandbox/config.mk
>
> -PLATFORM_CPPFLAGS += -DCONFIG_SANDBOX -D__SANDBOX__
> +PLATFORM_CPPFLAGS += -DCONFIG_SANDBOX -D__SANDBOX__ -I/usr/include
since this gets used by all u-boot files, shouldnt the /usr/include path get
added only for specific files/dirs ? the ones that glue the u-boot world to
the host C library ?
> --- /dev/null
> +++ b/board/sandbox/common/Makefile
>
> +clean:
> + rm -f $(SOBJS) $(OBJS)
> +
> +distclean: clean
> + rm -f $(LIB) core *.bak $(obj).depend
these dont get used, so punt them
> --- /dev/null
> +++ b/board/sandbox/common/os.c
isnt this an "arch" issue and not "board" ?
> --- /dev/null
> +++ b/include/os.h
seems like this glue should be in the sandbox arch subdir
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110917/b8cd60e2/attachment.pgp
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [RFC PATCH 13/20] sandbox: Add OS dependent layer
2011-09-18 0:20 ` Mike Frysinger
@ 2011-09-23 15:59 ` Simon Glass
0 siblings, 0 replies; 57+ messages in thread
From: Simon Glass @ 2011-09-23 15:59 UTC (permalink / raw)
To: u-boot
Hi Mike,
On Sat, Sep 17, 2011 at 5:20 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Saturday, September 17, 2011 12:48:52 Simon Glass wrote:
>> --- a/arch/sandbox/config.mk
>> +++ b/arch/sandbox/config.mk
>>
>> -PLATFORM_CPPFLAGS += -DCONFIG_SANDBOX -D__SANDBOX__
>> +PLATFORM_CPPFLAGS += -DCONFIG_SANDBOX -D__SANDBOX__ -I/usr/include
>
> since this gets used by all u-boot files, shouldnt the /usr/include path get
> added only for specific files/dirs ? ?the ones that glue the u-boot world to
> the host C library ?
Yes I tried to do that, but it didn't seem to work. I have put my
original attempt - what I would like to do - in the v2 patch series. I
will come back to this later but hopefully someone can just point out
what is wrong.
>
>> --- /dev/null
>> +++ b/board/sandbox/common/Makefile
>>
>> +clean:
>> + ? ? rm -f $(SOBJS) $(OBJS)
>> +
>> +distclean: ? clean
>> + ? ? rm -f $(LIB) core *.bak $(obj).depend
>
> these dont get used, so punt them
>
>> --- /dev/null
>> +++ b/board/sandbox/common/os.c
>
> isnt this an "arch" issue and not "board" ?
>
>> --- /dev/null
>> +++ b/include/os.h
>
> seems like this glue should be in the sandbox arch subdir
> -mike
I originally had it there, and then decided to move it since I was
concerned that we might want to define an os layer which doesn't do OS
calls, but perhaps communicates over a network link to a remote test
controller, or uses expect scripts to run tests. However, this is pie
in the sky at this stage so I am changing back to arch, as you
suggest.
Regards,
Simon
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [RFC PATCH 14/20] sandbox: Add board_init()
2011-09-17 16:48 [U-Boot] [RFC PATCH 01/20] sandbox: Add architecture header files Simon Glass
` (11 preceding siblings ...)
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 13/20] sandbox: Add OS dependent layer Simon Glass
@ 2011-09-17 16:48 ` Simon Glass
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 15/20] sandbox: Add main program Simon Glass
` (6 subsequent siblings)
19 siblings, 0 replies; 57+ messages in thread
From: Simon Glass @ 2011-09-17 16:48 UTC (permalink / raw)
To: u-boot
Create a basic empty board_init() to get us running.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
board/sandbox/common/Makefile | 2 +-
board/sandbox/common/board.c | 25 +++++++++++++++++++++++++
2 files changed, 26 insertions(+), 1 deletions(-)
create mode 100644 board/sandbox/common/board.c
diff --git a/board/sandbox/common/Makefile b/board/sandbox/common/Makefile
index 3289368..eb5062c 100644
--- a/board/sandbox/common/Makefile
+++ b/board/sandbox/common/Makefile
@@ -21,7 +21,7 @@ include $(TOPDIR)/config.mk
LIB = $(obj)lib$(VENDOR).o
-COBJS-y += os.o
+COBJS-y += board.o os.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/board/sandbox/common/board.c b/board/sandbox/common/board.c
new file mode 100644
index 0000000..de3cf06
--- /dev/null
+++ b/board/sandbox/common/board.c
@@ -0,0 +1,25 @@
+/*
+ * 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
+ */
+
+void board_init(void)
+{
+ /* Nothing to do here for the moment */
+}
--
1.7.3.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [RFC PATCH 15/20] sandbox: Add main program
2011-09-17 16:48 [U-Boot] [RFC PATCH 01/20] sandbox: Add architecture header files Simon Glass
` (12 preceding siblings ...)
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 14/20] sandbox: Add board_init() Simon Glass
@ 2011-09-17 16:48 ` Simon Glass
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 16/20] sandbox: Add serial uart Simon Glass
` (5 subsequent siblings)
19 siblings, 0 replies; 57+ messages in thread
From: Simon Glass @ 2011-09-17 16:48 UTC (permalink / raw)
To: u-boot
Add a main program so that we can run U-Boot.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
board/sandbox/common/Makefile | 2 +-
board/sandbox/common/main.c | 34 ++++++++++++++++++++++++++++++++++
2 files changed, 35 insertions(+), 1 deletions(-)
create mode 100644 board/sandbox/common/main.c
diff --git a/board/sandbox/common/Makefile b/board/sandbox/common/Makefile
index eb5062c..909962d 100644
--- a/board/sandbox/common/Makefile
+++ b/board/sandbox/common/Makefile
@@ -21,7 +21,7 @@ include $(TOPDIR)/config.mk
LIB = $(obj)lib$(VENDOR).o
-COBJS-y += board.o os.o
+COBJS-y += board.o main.o os.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/board/sandbox/common/main.c b/board/sandbox/common/main.c
new file mode 100644
index 0000000..3753c5c
--- /dev/null
+++ b/board/sandbox/common/main.c
@@ -0,0 +1,34 @@
+/*
+ * 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>
+
+int main(int argc, char *argv[])
+{
+ /* Do pre- and post-relocation init, then start up U-Boot */
+ board_init_f(0);
+ board_init_r(0, 0);
+
+ for (;;)
+ main_loop();
+
+ return 0;
+}
--
1.7.3.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [RFC PATCH 16/20] sandbox: Add serial uart
2011-09-17 16:48 [U-Boot] [RFC PATCH 01/20] sandbox: Add architecture header files Simon Glass
` (13 preceding siblings ...)
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 15/20] sandbox: Add main program Simon Glass
@ 2011-09-17 16:48 ` Simon Glass
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 17/20] sandbox: Add basic config file Simon Glass
` (4 subsequent siblings)
19 siblings, 0 replies; 57+ messages in thread
From: Simon Glass @ 2011-09-17 16:48 UTC (permalink / raw)
To: u-boot
This uart simply writes to stdout and reads from stdin. We might imagine
instead buffering the data so that a test interface can check output and
inject input.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
drivers/serial/Makefile | 1 +
drivers/serial/sandbox.c | 67 ++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 68 insertions(+), 0 deletions(-)
create mode 100644 drivers/serial/sandbox.c
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index 1dcc1c7..6309549 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -53,6 +53,7 @@ COBJS-$(CONFIG_SA1100_SERIAL) += serial_sa1100.o
COBJS-$(CONFIG_S3C24X0_SERIAL) += serial_s3c24x0.o
COBJS-$(CONFIG_S3C44B0_SERIAL) += serial_s3c44b0.o
COBJS-$(CONFIG_XILINX_UARTLITE) += serial_xuartlite.o
+COBJS-$(CONFIG_SANDBOX_SERIAL) += sandbox.o
COBJS-$(CONFIG_SCIF_CONSOLE) += serial_sh.o
COBJS-$(CONFIG_TEGRA2) += serial_tegra2.o
diff --git a/drivers/serial/sandbox.c b/drivers/serial/sandbox.c
new file mode 100644
index 0000000..7c4b11b
--- /dev/null
+++ b/drivers/serial/sandbox.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
+ */
+
+/*
+ * This provide a test serial port. It provides an emulated serial port where
+ * a test program and read out the serial output and inject serial input for
+ * U-Boot.
+ */
+
+#include <common.h>
+#include <os.h>
+
+int serial_init(void)
+{
+ return 0;
+}
+
+void serial_exit(void)
+{
+}
+
+void serial_setbrg(void)
+{
+}
+
+void serial_putc(const char ch)
+{
+ os_write(1, &ch, 1);
+}
+
+void serial_puts(const char *str)
+{
+ while (*str)
+ serial_putc(*str++);
+}
+
+int serial_getc(void)
+{
+ char buf;
+ int count;
+
+ count = os_read(0, &buf, 1);
+ return count == 1 ? buf : 0;
+}
+
+int serial_tstc(void)
+{
+ return 0;
+}
--
1.7.3.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [RFC PATCH 17/20] sandbox: Add basic config file
2011-09-17 16:48 [U-Boot] [RFC PATCH 01/20] sandbox: Add architecture header files Simon Glass
` (14 preceding siblings ...)
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 16/20] sandbox: Add serial uart Simon Glass
@ 2011-09-17 16:48 ` Simon Glass
2011-09-18 0:22 ` Mike Frysinger
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 18/20] sandbox: Remove unused variable warnings Simon Glass
` (3 subsequent siblings)
19 siblings, 1 reply; 57+ messages in thread
From: Simon Glass @ 2011-09-17 16:48 UTC (permalink / raw)
To: u-boot
This includes just a few basic features to illustrate the concept.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
include/configs/sandbox.h | 80 +++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 80 insertions(+), 0 deletions(-)
create mode 100644 include/configs/sandbox.h
diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h
new file mode 100644
index 0000000..43c7172
--- /dev/null
+++ b/include/configs/sandbox.h
@@ -0,0 +1,80 @@
+/*
+ * 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
+ */
+
+#define CONFIG_NR_DRAM_BANKS 1
+#define CONFIG_SYS_SDRAM_BASE 0
+#define CONFIG_DRAM_SIZE (128 << 20)
+
+/* Number of bits in a C 'long' on this architecture */
+#define CONFIG_SANDBOX_BITS_PER_LONG 64
+
+/*
+ * Size of malloc() pool, although we don't actually use this yet.
+ */
+#define CONFIG_SYS_MALLOC_LEN (4 << 20) /* 4MB */
+
+#define CONFIG_SYS_PROMPT "=>" /* Command Prompt */
+#define CONFIG_SYS_HUSH_PARSER
+#define CONFIG_SYS_PROMPT_HUSH_PS2 "> "
+#define CONFIG_SYS_LONGHELP /* #undef to save memory */
+#define CONFIG_SYS_CBSIZE 1024 /* Console I/O Buffer Size */
+
+/* Print Buffer Size */
+#define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) + 16)
+#define CONFIG_SYS_MAXARGS 16
+
+/* turn on command-line edit/c/auto */
+#define CONFIG_CMDLINE_EDITING
+#define CONFIG_COMMAND_HISTORY
+#define CONFIG_AUTOCOMPLETE
+
+#define CONFIG_ENV_SIZE 8192
+#define CONFIG_ENV_IS_NOWHERE
+
+#define CONFIG_SYS_HZ 1000
+
+/* Memory things - we don't really want a memory test */
+#define CONFIG_SYS_LOAD_ADDR 0x10000000
+#define CONFIG_SYS_MEMTEST_START 0x10000000
+#define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_MEMTEST_START + 0x1000)
+#define CONFIG_PHYS_64BIT
+
+#define CONFIG_BAUDRATE 115200
+#define CONFIG_SYS_BAUDRATE_TABLE {4800, 9600, 19200, 38400, 57600,\
+ 115200}
+#define CONFIG_SANDBOX_SERIAL
+
+#define CONFIG_SYS_NO_FLASH
+
+#define CONFIG_LMB
+
+/* include default commands */
+#include <config_cmd_default.h>
+
+/* We don't have networking support yet */
+#undef CONFIG_CMD_NET
+#undef CONFIG_CMD_NFS
+
+#define CONFIG_BOOTARGS ""
+
+#define CONFIG_EXTRA_ENV_SETTINGS "stdin=serial\0" \
+ "stdout=serial,lcd\0" \
+ "stderr=serial,lcd\0"
--
1.7.3.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [RFC PATCH 17/20] sandbox: Add basic config file
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 17/20] sandbox: Add basic config file Simon Glass
@ 2011-09-18 0:22 ` Mike Frysinger
2011-09-23 16:00 ` Simon Glass
0 siblings, 1 reply; 57+ messages in thread
From: Mike Frysinger @ 2011-09-18 0:22 UTC (permalink / raw)
To: u-boot
On Saturday, September 17, 2011 12:48:56 Simon Glass wrote:
> --- /dev/null
> +++ b/include/configs/sandbox.h
missing #ifdef multiple include protection
> +#define CONFIG_NR_DRAM_BANKS 1
> +#define CONFIG_SYS_SDRAM_BASE 0
> +#define CONFIG_DRAM_SIZE (128 << 20)
do you need any of this ?
> +#define CONFIG_SYS_PROMPT "=>" /* Command Prompt */
this file has a bunch of "#define<tab>" where it should be "#define<space>"
> +#define CONFIG_LMB
i dont think you need this either ?
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110917/08ee311e/attachment.pgp
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [RFC PATCH 17/20] sandbox: Add basic config file
2011-09-18 0:22 ` Mike Frysinger
@ 2011-09-23 16:00 ` Simon Glass
2011-09-26 4:52 ` Mike Frysinger
0 siblings, 1 reply; 57+ messages in thread
From: Simon Glass @ 2011-09-23 16:00 UTC (permalink / raw)
To: u-boot
Hi Mike,
On Sat, Sep 17, 2011 at 5:22 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Saturday, September 17, 2011 12:48:56 Simon Glass wrote:
>> --- /dev/null
>> +++ b/include/configs/sandbox.h
>
> missing #ifdef multiple include protection
>
>> +#define CONFIG_NR_DRAM_BANKS 1
>> +#define CONFIG_SYS_SDRAM_BASE ? ? ? ?0
I don't need this ^^
>> +#define CONFIG_DRAM_SIZE ? ? (128 << 20)
>
> do you need any of this ?
I want to have simulated DRAM, so yes. But I will make it start always
at 0 which removes one item.
>
>> +#define ? ? ?CONFIG_SYS_PROMPT ? ? ? ? ? ? ? "=>" ? ?/* Command Prompt */
>
> this file has a bunch of "#define<tab>" where it should be "#define<space>"
OK, fixed.
>
>> +#define CONFIG_LMB
>
> i dont think you need this either ?
No, removed.
Regards,
Simon
> -mike
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [RFC PATCH 17/20] sandbox: Add basic config file
2011-09-23 16:00 ` Simon Glass
@ 2011-09-26 4:52 ` Mike Frysinger
2011-09-26 18:18 ` Simon Glass
0 siblings, 1 reply; 57+ messages in thread
From: Mike Frysinger @ 2011-09-26 4:52 UTC (permalink / raw)
To: u-boot
On Friday, September 23, 2011 12:00:15 Simon Glass wrote:
> On Sat, Sep 17, 2011 at 5:22 PM, Mike Frysinger wrote:
> > On Saturday, September 17, 2011 12:48:56 Simon Glass wrote:
> >> +#define CONFIG_DRAM_SIZE (128 << 20)
> >
> > do you need any of this ?
>
> I want to have simulated DRAM, so yes. But I will make it start always
> at 0 which removes one item.
which is fine, but i guess the notion of "how much ram do i have" is not
standardized anywhere. you're copying the arm tree as the basis of the
sandbox arch, so it's including the DRAM conventions that arm uses.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110926/bf598958/attachment.pgp
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [RFC PATCH 17/20] sandbox: Add basic config file
2011-09-26 4:52 ` Mike Frysinger
@ 2011-09-26 18:18 ` Simon Glass
0 siblings, 0 replies; 57+ messages in thread
From: Simon Glass @ 2011-09-26 18:18 UTC (permalink / raw)
To: u-boot
Hi Mike,
On Sun, Sep 25, 2011 at 9:52 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Friday, September 23, 2011 12:00:15 Simon Glass wrote:
>> On Sat, Sep 17, 2011 at 5:22 PM, Mike Frysinger wrote:
>> > On Saturday, September 17, 2011 12:48:56 Simon Glass wrote:
>> >> +#define CONFIG_DRAM_SIZE ? ? (128 << 20)
>> >
>> > do you need any of this ?
>>
>> I want to have simulated DRAM, so yes. But I will make it start always
>> at 0 which removes one item.
>
> which is fine, but i guess the notion of "how much ram do i have" is not
> standardized anywhere. ?you're copying the arm tree as the basis of the
> sandbox arch, so it's including the DRAM conventions that arm uses.
> -mike
>
No, not yet. I suppose it will be in a config file somewhere and
defined by the test controller. TBD.
Regards,
Simon
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [RFC PATCH 18/20] sandbox: Remove unused variable warnings
2011-09-17 16:48 [U-Boot] [RFC PATCH 01/20] sandbox: Add architecture header files Simon Glass
` (15 preceding siblings ...)
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 17/20] sandbox: Add basic config file Simon Glass
@ 2011-09-17 16:48 ` Simon Glass
2011-09-18 0:25 ` Mike Frysinger
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 19/20] sandbox: Use uintptr_t for 32/64-bit compatibility Simon Glass
` (2 subsequent siblings)
19 siblings, 1 reply; 57+ messages in thread
From: Simon Glass @ 2011-09-17 16:48 UTC (permalink / raw)
To: u-boot
There are a few variables set but not used - this marks these as unused
for the compiler.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
common/cmd_mem.c | 2 +-
common/cmd_nvedit.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/cmd_mem.c b/common/cmd_mem.c
index 4daa1b3..1168766 100644
--- a/common/cmd_mem.c
+++ b/common/cmd_mem.c
@@ -471,7 +471,7 @@ int do_mem_base (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
int do_mem_loop (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
- ulong addr, length, i, junk;
+ ulong addr, length, i, junk __attribute__((unused));
int size;
volatile uint *longp;
volatile ushort *shortp;
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index e8b116d..cf6601d 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -460,7 +460,7 @@ int do_env_edit(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
char buffer[CONFIG_SYS_CBSIZE];
char *init_val;
- int len;
+ int len __attribute((unused));
if (argc < 2)
return cmd_usage(cmdtp);
--
1.7.3.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [RFC PATCH 18/20] sandbox: Remove unused variable warnings
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 18/20] sandbox: Remove unused variable warnings Simon Glass
@ 2011-09-18 0:25 ` Mike Frysinger
2011-09-23 16:01 ` Simon Glass
0 siblings, 1 reply; 57+ messages in thread
From: Mike Frysinger @ 2011-09-18 0:25 UTC (permalink / raw)
To: u-boot
On Saturday, September 17, 2011 12:48:57 Simon Glass wrote:
> There are a few variables set but not used - this marks these as unused
> for the compiler.
summary says "sandbox:" but i dont think this has anything to do with sandbox.
you're just using a newer compiler.
> --- a/common/cmd_mem.c
> +++ b/common/cmd_mem.c
>
> - ulong addr, length, i, junk;
> + ulong addr, length, i, junk __attribute__((unused));
this one is tricky as we just want to read the value from the volatile
pointer. i'm guessing do "*longp++;" just adds a different warning ?
> --- a/common/cmd_nvedit.c
> +++ b/common/cmd_nvedit.c
>
> - int len;
> + int len __attribute((unused));
this file though looks like we should just delete "len"
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110917/df29ac81/attachment.pgp
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [RFC PATCH 18/20] sandbox: Remove unused variable warnings
2011-09-18 0:25 ` Mike Frysinger
@ 2011-09-23 16:01 ` Simon Glass
2011-09-26 4:49 ` Mike Frysinger
0 siblings, 1 reply; 57+ messages in thread
From: Simon Glass @ 2011-09-23 16:01 UTC (permalink / raw)
To: u-boot
Hi Mike,
On Sat, Sep 17, 2011 at 5:25 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Saturday, September 17, 2011 12:48:57 Simon Glass wrote:
>> There are a few variables set but not used - this marks these as unused
>> for the compiler.
>
> summary says "sandbox:" but i dont think this has anything to do with sandbox.
> you're just using a newer compiler.
>
>> --- a/common/cmd_mem.c
>> +++ b/common/cmd_mem.c
>>
>> - ? ? ulong ? addr, length, i, junk;
>> + ? ? ulong ? addr, length, i, junk __attribute__((unused));
>
> this one is tricky as we just want to read the value from the volatile
> pointer. ?i'm guessing do "*longp++;" just adds a different warning ?
Isn't that a nop?
Well I can just assign it to a different variable - I will use 'size'
in my new patch set.
>
>> --- a/common/cmd_nvedit.c
>> +++ b/common/cmd_nvedit.c
>>
>> - ? ? int len;
>> + ? ? int len __attribute((unused));
>
> this file though looks like we should just delete "len"
Yes, done. I don't use lint anyway.
Regards,
Simon
> -mike
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [RFC PATCH 18/20] sandbox: Remove unused variable warnings
2011-09-23 16:01 ` Simon Glass
@ 2011-09-26 4:49 ` Mike Frysinger
2011-09-26 18:07 ` Simon Glass
0 siblings, 1 reply; 57+ messages in thread
From: Mike Frysinger @ 2011-09-26 4:49 UTC (permalink / raw)
To: u-boot
On Friday, September 23, 2011 12:01:46 Simon Glass wrote:
> On Sat, Sep 17, 2011 at 5:25 PM, Mike Frysinger wrote:
> > On Saturday, September 17, 2011 12:48:57 Simon Glass wrote:
> >> There are a few variables set but not used - this marks these as unused
> >> for the compiler.
> >
> > summary says "sandbox:" but i dont think this has anything to do with
> > sandbox. you're just using a newer compiler.
> >
> >> --- a/common/cmd_mem.c
> >> +++ b/common/cmd_mem.c
> >>
> >> - ulong addr, length, i, junk;
> >> + ulong addr, length, i, junk __attribute__((unused));
> >
> > this one is tricky as we just want to read the value from the volatile
> > pointer. i'm guessing do "*longp++;" just adds a different warning ?
>
> Isn't that a nop?
if it's volatile, it shouldn't be
> Well I can just assign it to a different variable - I will use 'size'
> in my new patch set.
Marek Vasut posted a patch which dropped the assignment and it seems to not
add any warnings
> >> --- a/common/cmd_nvedit.c
> >> +++ b/common/cmd_nvedit.c
> >>
> >> - int len;
> >> + int len __attribute((unused));
> >
> > this file though looks like we should just delete "len"
>
> Yes, done. I don't use lint anyway.
he also posted a fix for this :)
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110926/624ffbd9/attachment.pgp
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [RFC PATCH 18/20] sandbox: Remove unused variable warnings
2011-09-26 4:49 ` Mike Frysinger
@ 2011-09-26 18:07 ` Simon Glass
0 siblings, 0 replies; 57+ messages in thread
From: Simon Glass @ 2011-09-26 18:07 UTC (permalink / raw)
To: u-boot
Hi Mike,
On Sun, Sep 25, 2011 at 9:49 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Friday, September 23, 2011 12:01:46 Simon Glass wrote:
>> On Sat, Sep 17, 2011 at 5:25 PM, Mike Frysinger wrote:
>> > On Saturday, September 17, 2011 12:48:57 Simon Glass wrote:
>> >> There are a few variables set but not used - this marks these as unused
>> >> for the compiler.
>> >
>> > summary says "sandbox:" but i dont think this has anything to do with
>> > sandbox. you're just using a newer compiler.
>> >
>> >> --- a/common/cmd_mem.c
>> >> +++ b/common/cmd_mem.c
>> >>
>> >> - ? ? ulong ? addr, length, i, junk;
>> >> + ? ? ulong ? addr, length, i, junk __attribute__((unused));
>> >
>> > this one is tricky as we just want to read the value from the volatile
>> > pointer. ?i'm guessing do "*longp++;" just adds a different warning ?
>>
>> Isn't that a nop?
>
> if it's volatile, it shouldn't be
I missed that. checkpatch warns me so badly on volatile that I assumed
we didn't use it :-)
>
>> Well I can just assign it to a different variable - I will use 'size'
>> in my new patch set.
>
> Marek Vasut posted a patch which dropped the assignment and it seems to not
> add any warnings
Yes, just tried it and it works fine.
Regards,
Simon
>
>> >> --- a/common/cmd_nvedit.c
>> >> +++ b/common/cmd_nvedit.c
>> >>
>> >> - ? ? int len;
>> >> + ? ? int len __attribute((unused));
>> >
>> > this file though looks like we should just delete "len"
>>
>> Yes, done. I don't use lint anyway.
>
> he also posted a fix for this :)
> -mike
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [U-Boot] [RFC PATCH 19/20] sandbox: Use uintptr_t for 32/64-bit compatibility
2011-09-17 16:48 [U-Boot] [RFC PATCH 01/20] sandbox: Add architecture header files Simon Glass
` (16 preceding siblings ...)
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 18/20] sandbox: Remove unused variable warnings Simon Glass
@ 2011-09-17 16:48 ` Simon Glass
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 20/20] sandbox: Makefile changes to build sandbox architecture Simon Glass
2011-09-17 23:54 ` [U-Boot] [RFC PATCH 01/20] sandbox: Add architecture header files Mike Frysinger
19 siblings, 0 replies; 57+ messages in thread
From: Simon Glass @ 2011-09-17 16:48 UTC (permalink / raw)
To: u-boot
This fixes a problems when building on some 64-bit machines.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
common/cmd_mem.c | 2 +-
common/fdt_support.c | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/common/cmd_mem.c b/common/cmd_mem.c
index 1168766..94d3926 100644
--- a/common/cmd_mem.c
+++ b/common/cmd_mem.c
@@ -937,7 +937,7 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
if (readback != val) {
printf ("\nMem error @ 0x%08X: "
"found %08lX, expected %08lX\n",
- (uint)addr, readback, val);
+ (uint)(uintptr_t)addr, readback, val);
errs++;
if (ctrlc()) {
putc ('\n');
diff --git a/common/fdt_support.c b/common/fdt_support.c
index 19b2ef6..9bed3ce 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -495,7 +495,7 @@ int fdt_resize(void *blob)
total = fdt_num_mem_rsv(blob);
for (i = 0; i < total; i++) {
fdt_get_mem_rsv(blob, i, &addr, &size);
- if (addr == (uint64_t)(u32)blob) {
+ if (addr == (uintptr_t)blob) {
fdt_del_mem_rsv(blob, i);
break;
}
@@ -511,14 +511,14 @@ int fdt_resize(void *blob)
fdt_size_dt_strings(blob) + 5 * sizeof(struct fdt_reserve_entry);
/* Make it so the fdt ends on a page boundary */
- actualsize = ALIGN(actualsize + ((uint)blob & 0xfff), 0x1000);
- actualsize = actualsize - ((uint)blob & 0xfff);
+ actualsize = ALIGN(actualsize + ((uintptr_t)blob & 0xfff), 0x1000);
+ actualsize = actualsize - ((uintptr_t)blob & 0xfff);
/* Change the fdt header to reflect the correct size */
fdt_set_totalsize(blob, actualsize);
/* Add the new reservation */
- ret = fdt_add_mem_rsv(blob, (uint)blob, actualsize);
+ ret = fdt_add_mem_rsv(blob, (uintptr_t)blob, actualsize);
if (ret < 0)
return ret;
--
1.7.3.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [RFC PATCH 20/20] sandbox: Makefile changes to build sandbox architecture
2011-09-17 16:48 [U-Boot] [RFC PATCH 01/20] sandbox: Add architecture header files Simon Glass
` (17 preceding siblings ...)
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 19/20] sandbox: Use uintptr_t for 32/64-bit compatibility Simon Glass
@ 2011-09-17 16:48 ` Simon Glass
2011-09-17 23:54 ` [U-Boot] [RFC PATCH 01/20] sandbox: Add architecture header files Mike Frysinger
19 siblings, 0 replies; 57+ messages in thread
From: Simon Glass @ 2011-09-17 16:48 UTC (permalink / raw)
To: u-boot
At this point U-Boot will build and run on x86 under Linux.
The idea is to define a new architecture called 'sandbox', alongside ARM
and x86. This runs natively on Linux to suit the host machine. All
hardware access is either omitted or emulated.
The purpose of this system is to test the bulk of the non-hardware-specific
U-Boot code. We can mock the SPI flash, GPIOs, UART and keyboard, then test
that U-Boot behaves as we wish.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Makefile | 14 ++++++++++++--
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 672b5cd..136bd75 100644
--- a/Makefile
+++ b/Makefile
@@ -200,7 +200,9 @@ endif
#########################################################################
# U-Boot objects....order is important (i.e. start must be first)
+ifneq ($(CPU),sandbox)
OBJS = $(CPUDIR)/start.o
+endif
ifeq ($(CPU),x86)
OBJS += $(CPUDIR)/start16.o
OBJS += $(CPUDIR)/resetvec.o
@@ -401,12 +403,20 @@ $(obj)u-boot.ubl: $(obj)u-boot-nand.bin
$(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \
-e $(CONFIG_SYS_TEXT_BASE) -d $< $@
+ifeq ($(CONFIG_SANDBOX),y)
+GEN_UBOOT = \
+ cd $(LNDIR) && $(CC) -o u-boot $(SYMS) \
+ -Wl,-Map -Wl,u-boot.map -T $(obj)u-boot.lds \
+ -Wl,--start-group $(__LIBS) -Wl,--end-group \
+ $(PLATFORM_LIBS)
+else
GEN_UBOOT = \
- UNDEF_SYM=`$(OBJDUMP) -x $(LIBBOARD) $(LIBS) | \
- sed -n -e 's/.*\($(SYM_PREFIX)__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`;\
+ UNDEF_SYM=`$(UNDEF)`; \
cd $(LNDIR) && $(LD) $(LDFLAGS) $(LDFLAGS_$(@F)) $$UNDEF_SYM $(__OBJS) \
--start-group $(__LIBS) --end-group $(PLATFORM_LIBS) \
-Map u-boot.map -o u-boot
+endif
+
$(obj)u-boot: depend \
$(SUBDIRS) $(OBJS) $(LIBBOARD) $(LIBS) $(LDSCRIPT) $(obj)u-boot.lds
$(GEN_UBOOT)
--
1.7.3.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* [U-Boot] [RFC PATCH 01/20] sandbox: Add architecture header files
2011-09-17 16:48 [U-Boot] [RFC PATCH 01/20] sandbox: Add architecture header files Simon Glass
` (18 preceding siblings ...)
2011-09-17 16:48 ` [U-Boot] [RFC PATCH 20/20] sandbox: Makefile changes to build sandbox architecture Simon Glass
@ 2011-09-17 23:54 ` Mike Frysinger
19 siblings, 0 replies; 57+ messages in thread
From: Mike Frysinger @ 2011-09-17 23:54 UTC (permalink / raw)
To: u-boot
On Saturday, September 17, 2011 12:48:40 Simon Glass wrote:
> --- /dev/null
> +++ b/arch/sandbox/include/asm/arch-sandbox/clock.h
>
> +enum periph_id {
> + PERIPH_COUNT
> +};
is this needed by anything ?
> --- /dev/null
> +++ b/arch/sandbox/include/asm/arch-sandbox/gpio.h
>
> +enum {
> + GPIO_COUNT = 255, /* Number of GPIOs */
> +};
are these needed for anything ?
> +int gpio_direction_input(int gp);
> +int gpio_direction_output(int gp, int value);
> +int gpio_get_value(int gp);
> +void gpio_set_value(int gp, int value);
let's use this new sandbox arch as an excuse to populate asm-generic/ further
> --- /dev/null
> +++ b/arch/sandbox/include/asm/posix_types.h
>
> +typedef struct {
> +#if defined(__KERNEL__) || defined(__USE_ALL)
> + int val[2];
> +#else /* !defined(__KERNEL__) && !defined(__USE_ALL) */
> + int __val[2];
> +#endif /* !defined(__KERNEL__) && !defined(__USE_ALL) */
> +} __kernel_fsid_t;
> +
> +#if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2)
> +
> +#undef __FD_SET
> +#define __FD_SET(fd, fdsetp) \
> + (((fd_set *)fdsetp)->fds_bits[fd >> 5] |= (1<<(fd & 31)))
> +
> +#undef __FD_CLR
> +#define __FD_CLR(fd, fdsetp) \
> + (((fd_set *)fdsetp)->fds_bits[fd >> 5] &= ~(1<<(fd & 31)))
> +
> +#undef __FD_ISSET
> +#define __FD_ISSET(fd, fdsetp) \
> + ((((fd_set *)fdsetp)->fds_bits[fd >> 5] & (1<<(fd & 31))) != 0)
> +
> +#undef __FD_ZERO
> +#define __FD_ZERO(fdsetp) \
> + (memset(fdsetp, 0, sizeof(*(fd_set *)fdsetp)))
pretty sure u-boot doesnt use this, so just drop it
> --- /dev/null
> +++ b/arch/sandbox/include/asm/ptrace.h
>
> +/* This is not used in the sandbox architecture, but required by U-Boot */
> +struct pt_regs {
> + long dummy;
> +};
does it actually need to have "dummy" ?
> --- /dev/null
> +++ b/arch/sandbox/include/asm/string.h
this file looks like it should simply include linux/string.h
> --- /dev/null
> +++ b/arch/sandbox/include/asm/u-boot-sandbox.h
>
> +/* cpu/.../cpu.c */
> +int cpu_init(void);
> +int cleanup_before_linux(void);
> +
> +/* cpu/.../arch/cpu.c */
> +int arch_cpu_init(void);
> +int arch_misc_init(void);
> +
> +/* board/.../... */
> +int board_init(void);
> +int dram_init(void);
> +void dram_init_banksize(void);
> +
> +/* cpu/.../interrupt.c */
> +int arch_interrupt_init(void);
> +void reset_timer_masked(void);
> +ulong get_timer_masked(void);
> +void udelay_masked(unsigned long usec);
are these actually needed ? or should these get punted ?
> +/* common/cmd_nvedit.c */
> +int setenv(const char *, const char *);
this arch header shouldnt contain prototypes for non-arch stuff
> +/* cpu/.../timer.c */
> +int timer_init(void);
already in common.h
> --- /dev/null
> +++ b/arch/sandbox/include/asm/unaligned.h
include asm-generic/unaligned.h rather than writing your own
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110917/e78c09fb/attachment.pgp
^ permalink raw reply [flat|nested] 57+ messages in thread