headers
Wolfgang Denk | 1 Jan 2012 02:54
Picon
Picon
Favicon

Re: [RFC PATCH 0/19] Create generic board init and move ARM and x86 to it

Dear Simon Glass,

In message <CAPnjgZ1Zim6=u3rLcnAKE-0Bw3sO_hRY+U67jkpkNoNi8g7ctw <at> mail.gmail.com> you wrote:
> 
> Also it does depend on expectations. I would hope that moving an
> architecture over would be a fairly small task:
> 
> - getting generic relocation working

I don;t see why this would be a direct prerequisite here.  We want to
have that, no boubt about that.  But it appears to be an unrelated
change to me.

> - adding functions for anything that is missing from board init code

"anything that is missing from board init code" ?

> - removing things which don't work on the architecture?

That would probably reander systems broken that need these things?

> - worrying about differences in ordering between functions

This is indeed the biggest issue.

Keep in mind that my original ida of providing a function call table
was to allow to define this table in a board specific way (i. e. in
the board config file).

[Not that this idea found many friends...]
(Continue reading)

Permalink | Reply | 2 comments |
headers
Marek Vasut | 1 Jan 2012 05:28
Picon

[PATCH] M28EVK: Fix build if CONFIG_CMD_NAND not selected

Signed-off-by: Marek Vasut <marek.vasut <at> gmail.com>
Cc: Wolfgang Denk <wd <at> denx.de>
Cc: Stefano Babic <sbabic <at> denx.de>
---
 include/configs/m28evk.h |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/include/configs/m28evk.h b/include/configs/m28evk.h
index 39c841f..dcea878 100644
--- a/include/configs/m28evk.h
+++ b/include/configs/m28evk.h
 <at>  <at>  -140,6 +140,7  <at>  <at> 
 /*
  * NAND
  */
+#define	CONFIG_ENV_SIZE			(16 * 1024)
 #ifdef	CONFIG_CMD_NAND
 #define	CONFIG_NAND_MXS
 #define CONFIG_APBH_DMA
 <at>  <at>  -150,7 +151,6  <at>  <at> 

 /* Environment is in NAND */
 #define	CONFIG_ENV_IS_IN_NAND
-#define	CONFIG_ENV_SIZE			(16 * 1024)
 #define	CONFIG_ENV_SIZE_REDUND		CONFIG_ENV_SIZE
 #define	CONFIG_ENV_SECT_SIZE		(128 * 1024)
 #define	CONFIG_ENV_RANGE		(512 * 1024)
 <at>  <at>  -173,6 +173,8  <at>  <at> 
 		"512k(redundant-environment),"	\
 		"4m(kernel),"			\
(Continue reading)

Permalink | Reply | 4 comments |
headers
Xiangfu Liu | 1 Jan 2012 12:31
Favicon
Gravatar

add nand spl boot for qi_lb60 board

Hi Scott Wood

this is the patch I try to add nand spl boot for qi_lb60 board

this patch works fine under qi_lb60(ben nanonote) but there are three
'extern' lines under: nand_spl/board/qi/qi_lb60/nand_spl.c

those 'extern' lines already in jz4740.h, my question is when I remove
those three lines under nand_spl/board/qi/qi_lb60/nand_spl.c, it will
make u-boot-nand.bin break. can't boot the device anymore.

Please give me some advice how to debug the error.

thanks
xiangfu

Signed-off-by: Xiangfu Liu <xiangfu <at> openmobilefree.net>
---
 arch/mips/cpu/xburst/cpu.c           |    4 +
 arch/mips/cpu/xburst/start_spl.S     |   65 ++++++++++++++++++++
 drivers/mtd/nand/jz4740_nand.c       |   40 +++++++++++-
 include/configs/qi_lb60.h            |    1 +
 nand_spl/board/qi/qi_lb60/Makefile   |  112 ++++++++++++++++++++++++++++++++++
 nand_spl/board/qi/qi_lb60/nand_spl.c |   41 ++++++++++++
 nand_spl/board/qi/qi_lb60/u-boot.lds |   63 +++++++++++++++++++
 7 files changed, 323 insertions(+), 3 deletions(-)
 create mode 100644 arch/mips/cpu/xburst/start_spl.S
 create mode 100644 nand_spl/board/qi/qi_lb60/Makefile
 create mode 100644 nand_spl/board/qi/qi_lb60/nand_spl.c
 create mode 100644 nand_spl/board/qi/qi_lb60/u-boot.lds
(Continue reading)

Permalink | Reply | 7 comments |
headers
Simon Glass | 2 Jan 2012 00:47

Re: [RFC PATCH 0/19] Create generic board init and move ARM and x86 to it

Hi Wolfgang,

On Sat, Dec 31, 2011 at 5:54 PM, Wolfgang Denk <wd <at> denx.de> wrote:
> Dear Simon Glass,
>
> In message <CAPnjgZ1Zim6=u3rLcnAKE-0Bw3sO_hRY+U67jkpkNoNi8g7ctw <at> mail.gmail.com> you wrote:
>>
>> Also it does depend on expectations. I would hope that moving an
>> architecture over would be a fairly small task:
>>
>> - getting generic relocation working
>
> I don;t see why this would be a direct prerequisite here.  We want to
> have that, no boubt about that.  But it appears to be an unrelated
> change to me.

I don't think it's essential, but it is desirable, which I why it is
on the list.

>
>> - adding functions for anything that is missing from board init code
>
> "anything that is missing from board init code" ?

By that I mean that if the architecture has its own little things
which aren't supported by generic board init, then these would need to
be worked into the generic board init somehow, perhaps initially with
a new function in the initcall list.

>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Simon Glass | 2 Jan 2012 00:48

Re: [RFC PATCH 0/19] Create generic board init and move ARM and x86 to it

Hi Graeme,

On Sat, Dec 31, 2011 at 3:52 AM, Graeme Russ <graeme.russ <at> gmail.com> wrote:
> Hi Simon,
>
> On 31/12/11 13:02, Simon Glass wrote:
>> Hi Graeme,
>>
>> On Fri, Dec 30, 2011 at 7:49 AM, Graeme Russ <graeme.russ <at> gmail.com> wrote:
>>> Hi Simon,
>>>
>
> [snip]
>
>>> However, I think this approach is not the right one - and I think the CFI
>>> driver backs me up. Your plan is to create generic code which you want ALL
>>> arches to cross over to, but you only look to migrate two initially and
>>> migrate the rest 'later'. This is similar to what happened with the CFI
>>> driver, and there are still boards with custom flash.c files which are
>>> completely redundant.
>>>
>>> But, creating a single patch-set to migrate everyone in one go is going to
>>> be too massive a job to do in one go, and too prone to introducing breakage.
>>
>> Yes to some extent. However, my patch basically splits the two
>> board_init_x() functions into parts, and puts them in a function
>> table.
>
> Ah yes, looking a bit closer I see this now in patches 5 & 6. However, I
> think if you look at my patches 9, 10, 12 and 13 I'm doing essentially the
(Continue reading)

Permalink | Reply | 9 comments |
headers
Graeme Russ | 2 Jan 2012 05:09
Picon

[PATCH 00/17] x86: Rework of board init code (plus support patches)

Happy New Year!

I was thinking I would do another RFC, but instead I pulled an all-nighter
to get this series cleaned up ready for mainline

There a two major architectural changes introduced by this series:

 - The global data pointer is converted to a psuedo register implementation
   which allows global data to be access pre and post relocations like all
   other aches
 - The init sequences in board.c are reduced to be purely to loops which
   execute arrays of init functions

All patches are checkpatch clean

Series is rebased to commit bfcc40bb09b05c90cc3b1496abb270eb8aa72134
(Merge branch 'next' of ../next)

Regards,

Graeme

Graeme Russ (17):
  x86: Import glibc memcpy implementation
  x86: Speed up copy-to-RAM and clear BSS operations
  x86: Remove GDR related magic numbers
  x86: Rework Global Descriptor Table loading
  x86: Simplify Flash-to-RAM code execution transition
  x86: Rework relocation calcuations
  x86: Use fs for global data
(Continue reading)

Permalink | Reply | 86 comments |
headers
Graeme Russ | 2 Jan 2012 05:09
Picon

[PATCH 01/17] x86: Import glibc memcpy implementation

Taken from glibc version 2.14.90

Signed-off-by: Graeme Russ <graeme.russ <at> gmail.com>
---
 arch/x86/include/asm/string.h |    2 +-
 arch/x86/lib/string.c         |   61 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 62 insertions(+), 1 deletions(-)

diff --git a/arch/x86/include/asm/string.h b/arch/x86/include/asm/string.h
index 3aa6c11..0ad612f 100644
--- a/arch/x86/include/asm/string.h
+++ b/arch/x86/include/asm/string.h
 <at>  <at>  -14,7 +14,7  <at>  <at>  extern char * strrchr(const char * s, int c);
 #undef __HAVE_ARCH_STRCHR
 extern char * strchr(const char * s, int c);

-#undef __HAVE_ARCH_MEMCPY
+#define __HAVE_ARCH_MEMCPY
 extern void * memcpy(void *, const void *, __kernel_size_t);

 #undef __HAVE_ARCH_MEMMOVE
diff --git a/arch/x86/lib/string.c b/arch/x86/lib/string.c
index f2ea7e4..1fde81b 100644
--- a/arch/x86/lib/string.c
+++ b/arch/x86/lib/string.c
 <at>  <at>  -85,3 +85,64  <at>  <at>  void *memset(void *dstpp, int c, size_t len)

 	return dstpp;
 }
+
(Continue reading)

Permalink | Reply | 43 comments |
headers
Graeme Russ | 2 Jan 2012 05:09
Picon

[PATCH 02/17] x86: Speed up copy-to-RAM and clear BSS operations

The implementations of memcpy and memset are now the optimised versions
from glibc, so use them instead of simple copy loops

Signed-off-by: Graeme Russ <graeme.russ <at> gmail.com>
---
 arch/x86/lib/board.c |   17 +++++------------
 1 files changed, 5 insertions(+), 12 deletions(-)

diff --git a/arch/x86/lib/board.c b/arch/x86/lib/board.c
index d742fec..ba6b59f 100644
--- a/arch/x86/lib/board.c
+++ b/arch/x86/lib/board.c
 <at>  <at>  -188,26 +188,19  <at>  <at>  static int calculate_relocation_address(void)

 static int copy_uboot_to_ram(void)
 {
-	ulong *dst_addr = (ulong *)gd->relocaddr;
-	ulong *src_addr = (ulong *)&__text_start;
-	ulong *end_addr = (ulong *)&__data_end;
+	size_t len = (size_t)(&__data_end) - (size_t)(&__text_start);

-	while (src_addr < end_addr)
-		*dst_addr++ = *src_addr++;
+	memcpy((void *)gd->relocaddr, (void *)&__text_start, len);

 	return 0;
 }

 static int clear_bss(void)
 {
(Continue reading)

Permalink | Reply | 2 comments |
headers
Graeme Russ | 2 Jan 2012 05:09
Picon

[PATCH 03/17] x86: Remove GDR related magic numbers


Signed-off-by: Graeme Russ <graeme.russ <at> gmail.com>
---
 arch/x86/cpu/start.S             |    3 ++-
 arch/x86/include/asm/processor.h |    6 +++++-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/x86/cpu/start.S b/arch/x86/cpu/start.S
index f87633b..7f9b6a7 100644
--- a/arch/x86/cpu/start.S
+++ b/arch/x86/cpu/start.S
 <at>  <at>  -29,6 +29,7  <at>  <at> 
 #include <config.h>
 #include <version.h>
 #include <asm/global_data.h>
+#include <asm/processor.h>
 #include <asm/processor-flags.h>
 #include <generated/asm-offsets.h>

 <at>  <at>  -58,7 +59,7  <at>  <at>  _start:
 	/* This is the 32-bit cold-reset entry point */

 	/* Load the segement registes to match the gdt loaded in start16.S */
-	movl	$0x18, %eax
+	movl	$(GDT_ENTRY_32BIT_DS * 8), %eax
 	movw	%ax, %fs
 	movw	%ax, %ds
 	movw	%ax, %gs
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 1e5dccd..203c63a 100644
(Continue reading)

Permalink | Reply | 2 comments |
headers
Graeme Russ | 2 Jan 2012 05:09
Picon

[PATCH 04/17] x86: Rework Global Descriptor Table loading


Signed-off-by: Graeme Russ <graeme.russ <at> gmail.com>
---
 arch/x86/cpu/cpu.c |   82 +++++++++++++++++++++++++++++++++------------------
 1 files changed, 53 insertions(+), 29 deletions(-)

diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index 61d0b69..bf55c26 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
 <at>  <at>  -55,35 +55,39  <at>  <at>  struct gdt_ptr {
 	u32 ptr;
 } __packed;

-static void reload_gdt(void)
+static void load_ds(u32 segment)
 {
-	/*
-	 * There are machines which are known to not boot with the GDT
-	 * being 8-byte unaligned.  Intel recommends 16 byte alignment
-	 */
-	static const u64 boot_gdt[] __attribute__((aligned(16))) = {
-		/* CS: code, read/execute, 4 GB, base 0 */
-		[GDT_ENTRY_32BIT_CS] = GDT_ENTRY(0xc09b, 0, 0xfffff),
-		/* DS: data, read/write, 4 GB, base 0 */
-		[GDT_ENTRY_32BIT_DS] = GDT_ENTRY(0xc093, 0, 0xfffff),
-		/* 16-bit CS: code, read/execute, 64 kB, base 0 */
-		[GDT_ENTRY_16BIT_CS] = GDT_ENTRY(0x109b, 0, 0x0ffff),
-		/* 16-bit DS: data, read/write, 64 kB, base 0 */
-		[GDT_ENTRY_16BIT_DS] = GDT_ENTRY(0x1093, 0, 0x0ffff),
(Continue reading)

Permalink | Reply | 2 comments |

Gmane