[U-Boot] Pull request u-boot-blackfin.git (post branch)
All of thse patches have been posted previously, and no one has given feedback, so here they are in a handy branch for you to pull.
The following changes since commit b1af6f532e0d348b153d5c148369229d24af361a:
Prepare v2011.06 (2011-06-27 22:22:42 +0200)
are available in the git repository at: git://www.denx.de/git/u-boot-blackfin.git post
Mike Frysinger (5): post: fix up I/O helper usage post: add gpio hotkey support post: use ARRAY_SIZE post: new nor flash test serial: implement common uart post test
common/serial.c | 90 +++++++++++++++++++++ include/post.h | 5 +- include/serial.h | 5 + post/board/lwmon/sysmon.c | 2 +- post/cpu/mpc8xx/ether.c | 4 +- post/cpu/mpc8xx/spr.c | 3 +- post/cpu/mpc8xx/uart.c | 4 +- post/cpu/ppc4xx/spr.c | 3 +- post/drivers/Makefile | 2 +- post/drivers/flash.c | 107 +++++++++++++++++++++++++ post/drivers/memory.c | 2 +- post/lib_powerpc/andi.c | 3 +- post/lib_powerpc/cmp.c | 3 +- post/lib_powerpc/cmpi.c | 3 +- post/lib_powerpc/cr.c | 12 +-- post/lib_powerpc/fpu/mul-subnormal-single-1.c | 2 +- post/lib_powerpc/load.c | 3 +- post/lib_powerpc/multi.c | 2 +- post/lib_powerpc/rlwimi.c | 3 +- post/lib_powerpc/rlwinm.c | 3 +- post/lib_powerpc/rlwnm.c | 3 +- post/lib_powerpc/srawi.c | 3 +- post/lib_powerpc/store.c | 3 +- post/lib_powerpc/three.c | 3 +- post/lib_powerpc/threei.c | 3 +- post/lib_powerpc/threex.c | 3 +- post/lib_powerpc/two.c | 3 +- post/lib_powerpc/twox.c | 3 +- post/post.c | 23 +++++- post/tests.c | 17 ++++- 30 files changed, 269 insertions(+), 56 deletions(-) create mode 100644 post/drivers/flash.c
The I/O API from Linux defaults to little endian accesses. In order to do big endian accesses, there are a "be" variants. The "le32" variants are arch-specific and not terribly common, so change it to the normal Linux API funcs.
Signed-off-by: Mike Frysinger vapier@gentoo.org --- include/post.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/post.h b/include/post.h index 519cef1..c9ec2f4 100644 --- a/include/post.h +++ b/include/post.h @@ -78,12 +78,12 @@
static inline ulong post_word_load (void) { - return in_le32((volatile void *)(_POST_WORD_ADDR)); + return inl((volatile void *)(_POST_WORD_ADDR)); }
static inline void post_word_store (ulong value) { - out_le32((volatile void *)(_POST_WORD_ADDR), value); + outl(value, (volatile void *)(_POST_WORD_ADDR)); } #endif /* defined (CONFIG_POST) || defined(CONFIG_LOGBUFFER) */ #endif /* __ASSEMBLY__ */
Now that we have the generic GPIO layer, we can easily provide a common implementation for the post_hotkeys_pressed() function based on it.
Signed-off-by: Mike Frysinger vapier@gentoo.org --- post/post.c | 21 +++++++++++++++++++++ 1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/post/post.c b/post/post.c index 1b7f2aa..ecea1e1 100644 --- a/post/post.c +++ b/post/post.c @@ -26,6 +26,10 @@ #include <watchdog.h> #include <post.h>
+#ifdef CONFIG_SYS_POST_HOTKEYS_GPIO +#include <asm/gpio.h> +#endif + #ifdef CONFIG_LOGBUFFER #include <logbuff.h> #endif @@ -68,6 +72,23 @@ int post_init_f (void) */ int __post_hotkeys_pressed(void) { +#ifdef CONFIG_SYS_POST_HOTKEYS_GPIO + int ret; + unsigned gpio = CONFIG_SYS_POST_HOTKEYS_GPIO; + + ret = gpio_request(gpio, "hotkeys"); + if (ret) { + printf("POST: gpio hotkey request failed\n"); + return 0; + } + + gpio_direction_input(gpio); + ret = gpio_get_value(gpio); + gpio_free(gpio); + + return ret; +#endif + return 0; /* No hotkeys supported */ } int post_hotkeys_pressed(void)
We've got a handy dandy macro already for calculating the number of elements in an array, so use it.
Signed-off-by: Mike Frysinger vapier@gentoo.org --- post/board/lwmon/sysmon.c | 2 +- post/cpu/mpc8xx/ether.c | 4 +--- post/cpu/mpc8xx/spr.c | 3 +-- post/cpu/mpc8xx/uart.c | 4 +--- post/cpu/ppc4xx/spr.c | 3 +-- post/drivers/memory.c | 2 +- post/lib_powerpc/andi.c | 3 +-- post/lib_powerpc/cmp.c | 3 +-- post/lib_powerpc/cmpi.c | 3 +-- post/lib_powerpc/cr.c | 12 ++++-------- post/lib_powerpc/fpu/mul-subnormal-single-1.c | 2 +- post/lib_powerpc/load.c | 3 +-- post/lib_powerpc/multi.c | 2 +- post/lib_powerpc/rlwimi.c | 3 +-- post/lib_powerpc/rlwinm.c | 3 +-- post/lib_powerpc/rlwnm.c | 3 +-- post/lib_powerpc/srawi.c | 3 +-- post/lib_powerpc/store.c | 3 +-- post/lib_powerpc/three.c | 3 +-- post/lib_powerpc/threei.c | 3 +-- post/lib_powerpc/threex.c | 3 +-- post/lib_powerpc/two.c | 3 +-- post/lib_powerpc/twox.c | 3 +-- post/post.c | 2 +- post/tests.c | 2 +- 25 files changed, 28 insertions(+), 52 deletions(-)
diff --git a/post/board/lwmon/sysmon.c b/post/board/lwmon/sysmon.c index fc828b2..72224c6 100644 --- a/post/board/lwmon/sysmon.c +++ b/post/board/lwmon/sysmon.c @@ -133,7 +133,7 @@ static sysmon_table_t sysmon_table[] = {"+ 5 V standby", "V", &sysmon_pic, NULL, NULL, 100, 1000, 0, 6040, 0xFF, 0xC8, 0xDE, 0, 0xC8, 0xDE, 0, 0x7C}, }; -static int sysmon_table_size = sizeof(sysmon_table) / sizeof(sysmon_table[0]); +static int sysmon_table_size = ARRAY_SIZE(sysmon_table);
static int conversion_done = 0;
diff --git a/post/cpu/mpc8xx/ether.c b/post/cpu/mpc8xx/ether.c index 43ea817..fcbb300 100644 --- a/post/cpu/mpc8xx/ether.c +++ b/post/cpu/mpc8xx/ether.c @@ -67,8 +67,6 @@ static int ctlr_list[][2] = { {CTLR_SCC, 1} }; static int ctlr_list[][2] = { }; #endif
-#define CTRL_LIST_SIZE (sizeof(ctlr_list) / sizeof(ctlr_list[0])) - static struct { void (*init) (int index); void (*halt) (int index); @@ -618,7 +616,7 @@ int ether_post_test (int flags) ctlr_proc[CTLR_SCC].send = scc_send; ctlr_proc[CTLR_SCC].recv = scc_recv;
- for (i = 0; i < CTRL_LIST_SIZE; i++) { + for (i = 0; i < ARRAY_SIZE(ctlr_list); i++) { if (test_ctlr (ctlr_list[i][0], ctlr_list[i][1]) != 0) { res = -1; } diff --git a/post/cpu/mpc8xx/spr.c b/post/cpu/mpc8xx/spr.c index db84dbe..4c1e2af 100644 --- a/post/cpu/mpc8xx/spr.c +++ b/post/cpu/mpc8xx/spr.c @@ -108,8 +108,7 @@ static struct {826, "MD_DBRAM1", 0x00000000, 0x00000000}, };
-static int spr_test_list_size = - sizeof (spr_test_list) / sizeof (spr_test_list[0]); +static int spr_test_list_size = ARRAY_SIZE(spr_test_list);
int spr_post_test (int flags) { diff --git a/post/cpu/mpc8xx/uart.c b/post/cpu/mpc8xx/uart.c index f351ac0..7a7a62a 100644 --- a/post/cpu/mpc8xx/uart.c +++ b/post/cpu/mpc8xx/uart.c @@ -61,8 +61,6 @@ static int ctlr_list[][2] = static int ctlr_list[][2] = { }; #endif
-#define CTRL_LIST_SIZE (sizeof(ctlr_list) / sizeof(ctlr_list[0])) - static struct { void (*init) (int index); void (*halt) (int index); @@ -540,7 +538,7 @@ int uart_post_test (int flags) ctlr_proc[CTLR_SCC].putc = scc_putc; ctlr_proc[CTLR_SCC].getc = scc_getc;
- for (i = 0; i < CTRL_LIST_SIZE; i++) { + for (i = 0; i < ARRAY_SIZE(ctlr_list); i++) { if (test_ctlr (ctlr_list[i][0], ctlr_list[i][1]) != 0) { res = -1; } diff --git a/post/cpu/ppc4xx/spr.c b/post/cpu/ppc4xx/spr.c index cb18b64..3f5e965 100644 --- a/post/cpu/ppc4xx/spr.c +++ b/post/cpu/ppc4xx/spr.c @@ -156,8 +156,7 @@ static struct { {0x3f3, "DBDR", 0x00000000, 0x00000000}, };
-static int spr_test_list_size = - sizeof (spr_test_list) / sizeof (spr_test_list[0]); +static int spr_test_list_size = ARRAY_SIZE(spr_test_list);
int spr_post_test (int flags) { diff --git a/post/drivers/memory.c b/post/drivers/memory.c index 3f47449..4cca035 100644 --- a/post/drivers/memory.c +++ b/post/drivers/memory.c @@ -225,7 +225,7 @@ const unsigned long long otherpattern = 0x0123456789abcdefULL; static int memory_post_dataline(unsigned long long * pmem) { unsigned long long temp64 = 0; - int num_patterns = sizeof(pattern)/ sizeof(pattern[0]); + int num_patterns = ARRAY_SIZE(pattern); int i; unsigned int hi, lo, pathi, patlo; int ret = 0; diff --git a/post/lib_powerpc/andi.c b/post/lib_powerpc/andi.c index 52ec7c4..2791cd7 100644 --- a/post/lib_powerpc/andi.c +++ b/post/lib_powerpc/andi.c @@ -61,8 +61,7 @@ static struct cpu_post_andi_s 0x80000000 }, }; -static unsigned int cpu_post_andi_size = - sizeof (cpu_post_andi_table) / sizeof (struct cpu_post_andi_s); +static unsigned int cpu_post_andi_size = ARRAY_SIZE(cpu_post_andi_table);
int cpu_post_test_andi (void) { diff --git a/post/lib_powerpc/cmp.c b/post/lib_powerpc/cmp.c index 5f6a3b9..ae5b72b 100644 --- a/post/lib_powerpc/cmp.c +++ b/post/lib_powerpc/cmp.c @@ -95,8 +95,7 @@ static struct cpu_post_cmp_s 0x04 }, }; -static unsigned int cpu_post_cmp_size = - sizeof (cpu_post_cmp_table) / sizeof (struct cpu_post_cmp_s); +static unsigned int cpu_post_cmp_size = ARRAY_SIZE(cpu_post_cmp_table);
int cpu_post_test_cmp (void) { diff --git a/post/lib_powerpc/cmpi.c b/post/lib_powerpc/cmpi.c index 1a2fc3d..4160a2a 100644 --- a/post/lib_powerpc/cmpi.c +++ b/post/lib_powerpc/cmpi.c @@ -95,8 +95,7 @@ static struct cpu_post_cmpi_s 0x04 }, }; -static unsigned int cpu_post_cmpi_size = - sizeof (cpu_post_cmpi_table) / sizeof (struct cpu_post_cmpi_s); +static unsigned int cpu_post_cmpi_size = ARRAY_SIZE(cpu_post_cmpi_table);
int cpu_post_test_cmpi (void) { diff --git a/post/lib_powerpc/cr.c b/post/lib_powerpc/cr.c index fbee6d5..ada7c7a 100644 --- a/post/lib_powerpc/cr.c +++ b/post/lib_powerpc/cr.c @@ -59,8 +59,7 @@ static ulong cpu_post_cr_table1[] = 0xaaaaaaaa, 0x55555555, }; -static unsigned int cpu_post_cr_size1 = - sizeof (cpu_post_cr_table1) / sizeof (ulong); +static unsigned int cpu_post_cr_size1 = ARRAY_SIZE(cpu_post_cr_table1);
static struct cpu_post_cr_s2 { ulong xer; @@ -76,8 +75,7 @@ static struct cpu_post_cr_s2 { 5 }, }; -static unsigned int cpu_post_cr_size2 = - sizeof (cpu_post_cr_table2) / sizeof (struct cpu_post_cr_s2); +static unsigned int cpu_post_cr_size2 = ARRAY_SIZE(cpu_post_cr_table2);
static struct cpu_post_cr_s3 { ulong cr; @@ -99,8 +97,7 @@ static struct cpu_post_cr_s3 { 0x71234567 }, }; -static unsigned int cpu_post_cr_size3 = - sizeof (cpu_post_cr_table3) / sizeof (struct cpu_post_cr_s3); +static unsigned int cpu_post_cr_size3 = ARRAY_SIZE(cpu_post_cr_table3);
static struct cpu_post_cr_s4 { ulong cmd; @@ -240,8 +237,7 @@ static struct cpu_post_cr_s4 { 0x0000ffff }, }; -static unsigned int cpu_post_cr_size4 = - sizeof (cpu_post_cr_table4) / sizeof (struct cpu_post_cr_s4); +static unsigned int cpu_post_cr_size4 = ARRAY_SIZE(cpu_post_cr_table4);
int cpu_post_test_cr (void) { diff --git a/post/lib_powerpc/fpu/mul-subnormal-single-1.c b/post/lib_powerpc/fpu/mul-subnormal-single-1.c index 23a3f30..b3f8deb 100644 --- a/post/lib_powerpc/fpu/mul-subnormal-single-1.c +++ b/post/lib_powerpc/fpu/mul-subnormal-single-1.c @@ -86,7 +86,7 @@ int fpu_post_test_math7 (void) { unsigned int i;
- for (i = 0; i < sizeof (expected) / sizeof (expected[0]); i++) + for (i = 0; i < ARRAY_SIZE(expected); i++) { tstmul (expected[i].p1, expected[i].p2, expected[i].res); tstmul (expected[i].p2, expected[i].p1, expected[i].res); diff --git a/post/lib_powerpc/load.c b/post/lib_powerpc/load.c index 98d4373..49924f2 100644 --- a/post/lib_powerpc/load.c +++ b/post/lib_powerpc/load.c @@ -171,8 +171,7 @@ static struct cpu_post_load_s 1 }, }; -static unsigned int cpu_post_load_size = - sizeof (cpu_post_load_table) / sizeof (struct cpu_post_load_s); +static unsigned int cpu_post_load_size = ARRAY_SIZE(cpu_post_load_table);
int cpu_post_test_load (void) { diff --git a/post/lib_powerpc/multi.c b/post/lib_powerpc/multi.c index e42a7c0..5845616 100644 --- a/post/lib_powerpc/multi.c +++ b/post/lib_powerpc/multi.c @@ -57,7 +57,7 @@ int cpu_post_test_multi (void) ASM_BLR, };
- for (i = 0; i < sizeof(src) / sizeof(src[0]); i ++) + for (i = 0; i < ARRAY_SIZE(src); ++i) { src[i] = i; dst[i] = 0; diff --git a/post/lib_powerpc/rlwimi.c b/post/lib_powerpc/rlwimi.c index fd628b3..15d96ac 100644 --- a/post/lib_powerpc/rlwimi.c +++ b/post/lib_powerpc/rlwimi.c @@ -62,8 +62,7 @@ static struct cpu_post_rlwimi_s 0xffaaffff }, }; -static unsigned int cpu_post_rlwimi_size = - sizeof (cpu_post_rlwimi_table) / sizeof (struct cpu_post_rlwimi_s); +static unsigned int cpu_post_rlwimi_size = ARRAY_SIZE(cpu_post_rlwimi_table);
int cpu_post_test_rlwimi (void) { diff --git a/post/lib_powerpc/rlwinm.c b/post/lib_powerpc/rlwinm.c index 88a28c6..a04ec52 100644 --- a/post/lib_powerpc/rlwinm.c +++ b/post/lib_powerpc/rlwinm.c @@ -59,8 +59,7 @@ static struct cpu_post_rlwinm_s 0x0000ff00 }, }; -static unsigned int cpu_post_rlwinm_size = - sizeof (cpu_post_rlwinm_table) / sizeof (struct cpu_post_rlwinm_s); +static unsigned int cpu_post_rlwinm_size = ARRAY_SIZE(cpu_post_rlwinm_table);
int cpu_post_test_rlwinm (void) { diff --git a/post/lib_powerpc/rlwnm.c b/post/lib_powerpc/rlwnm.c index 60bcb6d..764fe0c 100644 --- a/post/lib_powerpc/rlwnm.c +++ b/post/lib_powerpc/rlwnm.c @@ -60,8 +60,7 @@ static struct cpu_post_rlwnm_s 0x0000ff00 }, }; -static unsigned int cpu_post_rlwnm_size = - sizeof (cpu_post_rlwnm_table) / sizeof (struct cpu_post_rlwnm_s); +static unsigned int cpu_post_rlwnm_size = ARRAY_SIZE(cpu_post_rlwnm_table);
int cpu_post_test_rlwnm (void) { diff --git a/post/lib_powerpc/srawi.c b/post/lib_powerpc/srawi.c index be153ad..90a1e4d 100644 --- a/post/lib_powerpc/srawi.c +++ b/post/lib_powerpc/srawi.c @@ -61,8 +61,7 @@ static struct cpu_post_srawi_s 0xf0000000 }, }; -static unsigned int cpu_post_srawi_size = - sizeof (cpu_post_srawi_table) / sizeof (struct cpu_post_srawi_s); +static unsigned int cpu_post_srawi_size = ARRAY_SIZE(cpu_post_srawi_table);
int cpu_post_test_srawi (void) { diff --git a/post/lib_powerpc/store.c b/post/lib_powerpc/store.c index 1956f6b..441389c 100644 --- a/post/lib_powerpc/store.c +++ b/post/lib_powerpc/store.c @@ -156,8 +156,7 @@ static struct cpu_post_store_s 0xff }, }; -static unsigned int cpu_post_store_size = - sizeof (cpu_post_store_table) / sizeof (struct cpu_post_store_s); +static unsigned int cpu_post_store_size = ARRAY_SIZE(cpu_post_store_table);
int cpu_post_test_store (void) { diff --git a/post/lib_powerpc/three.c b/post/lib_powerpc/three.c index 7f8c1e2..4391386 100644 --- a/post/lib_powerpc/three.c +++ b/post/lib_powerpc/three.c @@ -155,8 +155,7 @@ static struct cpu_post_three_s 0x40 }, }; -static unsigned int cpu_post_three_size = - sizeof (cpu_post_three_table) / sizeof (struct cpu_post_three_s); +static unsigned int cpu_post_three_size = ARRAY_SIZE(cpu_post_three_table);
int cpu_post_test_three (void) { diff --git a/post/lib_powerpc/threei.c b/post/lib_powerpc/threei.c index 31953f9..95b6322 100644 --- a/post/lib_powerpc/threei.c +++ b/post/lib_powerpc/threei.c @@ -75,8 +75,7 @@ static struct cpu_post_threei_s 0xffff8000 }, }; -static unsigned int cpu_post_threei_size = - sizeof (cpu_post_threei_table) / sizeof (struct cpu_post_threei_s); +static unsigned int cpu_post_threei_size = ARRAY_SIZE(cpu_post_threei_table);
int cpu_post_test_threei (void) { diff --git a/post/lib_powerpc/threex.c b/post/lib_powerpc/threex.c index 350a12a..7769218 100644 --- a/post/lib_powerpc/threex.c +++ b/post/lib_powerpc/threex.c @@ -125,8 +125,7 @@ static struct cpu_post_threex_s 0x1000 }, }; -static unsigned int cpu_post_threex_size = - sizeof (cpu_post_threex_table) / sizeof (struct cpu_post_threex_s); +static unsigned int cpu_post_threex_size = ARRAY_SIZE(cpu_post_threex_table);
int cpu_post_test_threex (void) { diff --git a/post/lib_powerpc/two.c b/post/lib_powerpc/two.c index 2b11147..7f08880 100644 --- a/post/lib_powerpc/two.c +++ b/post/lib_powerpc/two.c @@ -81,8 +81,7 @@ static struct cpu_post_two_s ~5 }, }; -static unsigned int cpu_post_two_size = - sizeof (cpu_post_two_table) / sizeof (struct cpu_post_two_s); +static unsigned int cpu_post_two_size = ARRAY_SIZE(cpu_post_two_table);
int cpu_post_test_two (void) { diff --git a/post/lib_powerpc/twox.c b/post/lib_powerpc/twox.c index d6714f9..88140bf 100644 --- a/post/lib_powerpc/twox.c +++ b/post/lib_powerpc/twox.c @@ -81,8 +81,7 @@ static struct cpu_post_twox_s 12 }, }; -static unsigned int cpu_post_twox_size = - sizeof (cpu_post_twox_table) / sizeof (struct cpu_post_twox_s); +static unsigned int cpu_post_twox_size = ARRAY_SIZE(cpu_post_twox_table);
int cpu_post_test_twox (void) { diff --git a/post/post.c b/post/post.c index ecea1e1..7660224 100644 --- a/post/post.c +++ b/post/post.c @@ -196,7 +196,7 @@ static void post_get_flags (int *test_flags) POST_CRITICAL }; char *var[] = { "post_poweron", "post_normal", "post_slowtest", "post_critical" }; - int varnum = sizeof (var) / sizeof (var[0]); + int varnum = ARRAY_SIZE(var); char list[128]; /* long enough for POST list */ char *name; char *s; diff --git a/post/tests.c b/post/tests.c index 5f59fbb..71437b6 100644 --- a/post/tests.c +++ b/post/tests.c @@ -305,4 +305,4 @@ struct post_test post_list[] = #endif };
-unsigned int post_list_size = sizeof (post_list) / sizeof (struct post_test); +unsigned int post_list_size = ARRAY_SIZE(post_list);
This adds a simple flash test to automatically verify erasing, writing, and reading of sectors. The code is based on existing Blackfin tests but generalized for everyone to use.
Signed-off-by: Mike Frysinger vapier@gentoo.org --- include/post.h | 1 + post/drivers/Makefile | 2 +- post/drivers/flash.c | 107 +++++++++++++++++++++++++++++++++++++++++++++++++ post/tests.c | 15 ++++++- 4 files changed, 123 insertions(+), 2 deletions(-) create mode 100644 post/drivers/flash.c
diff --git a/include/post.h b/include/post.h index c9ec2f4..19991de 100644 --- a/include/post.h +++ b/include/post.h @@ -186,6 +186,7 @@ extern int post_hotkeys_pressed(void); #define CONFIG_SYS_POST_BSPEC5 0x00100000 #define CONFIG_SYS_POST_CODEC 0x00200000 #define CONFIG_SYS_POST_COPROC 0x00400000 +#define CONFIG_SYS_POST_FLASH 0x00800000
#endif /* CONFIG_POST */
diff --git a/post/drivers/Makefile b/post/drivers/Makefile index 0d87ae0..85d6c03 100644 --- a/post/drivers/Makefile +++ b/post/drivers/Makefile @@ -24,6 +24,6 @@ include $(TOPDIR)/config.mk
LIB = libpostdrivers.o
-COBJS-$(CONFIG_HAS_POST) += i2c.o memory.o rtc.o +COBJS-$(CONFIG_HAS_POST) += flash.o i2c.o memory.o rtc.o
include $(TOPDIR)/post/rules.mk diff --git a/post/drivers/flash.c b/post/drivers/flash.c new file mode 100644 index 0000000..07eab33 --- /dev/null +++ b/post/drivers/flash.c @@ -0,0 +1,107 @@ +/* + * Parallel NOR Flash tests + * + * Copyright (c) 2005-2011 Analog Devices Inc. + * + * Licensed under the GPL-2 or later. + */ + +#include <common.h> +#include <malloc.h> +#include <post.h> +#include <flash.h> + +#if CONFIG_POST & CONFIG_SYS_POST_FLASH + +/* + * This code will walk over the declared sectors erasing them, + * then programming them, then verifying the written contents. + * Possible future work: + * - verify sectors before/after are not erased/written + * - verify partial writes (e.g. programming only middle of sector) + * - verify the contents of the erased sector + * - better seed pattern than 0x00..0xff + */ + +#ifndef CONFIG_SYS_POST_FLASH_NUM +# define CONFIG_SYS_POST_FLASH_NUM 0 +#endif +#if CONFIG_SYS_POST_FLASH_START >= CONFIG_SYS_POST_FLASH_END +# error "invalid flash block start/end" +#endif + +extern flash_info_t flash_info[]; + +static void *seed_src_data(void *ptr, ulong *old_len, ulong new_len) +{ + unsigned char *p; + ulong i; + + p = ptr = realloc(ptr, new_len); + if (!ptr) + return ptr; + + for (i = *old_len; i < new_len; ++i) + p[i] = i; + + *old_len = new_len; + + return ptr; +} + +int flash_post_test(int flags) +{ + ulong len; + void *src; + int ret, n, n_start, n_end; + flash_info_t *info; + + /* the output from the common flash layers needs help */ + puts("\n"); + + len = 0; + src = NULL; + info = &flash_info[CONFIG_SYS_POST_FLASH_NUM]; + n_start = CONFIG_SYS_POST_FLASH_START; + n_end = CONFIG_SYS_POST_FLASH_END; + + for (n = n_start; n < n_end; ++n) { + ulong s_start, s_len, s_off; + + s_start = info->start[n]; + s_len = flash_sector_size(info, n); + s_off = s_start - info->start[0]; + + src = seed_src_data(src, &len, s_len); + if (!src) { + printf("malloc(%#lx) failed\n", s_len); + return 1; + } + + printf("\tsector %i: %#lx +%#lx", n, s_start, s_len); + + ret = flash_erase(info, n, n + 1); + if (ret) { + flash_perror(ret); + break; + } + + ret = write_buff(info, src, s_start, s_len); + if (ret) { + flash_perror(ret); + break; + } + + ret = memcmp(src, (void *)s_start, s_len); + if (ret) { + printf(" verify failed with %i\n", ret); + break; + } + } + + free(src); + + return ret; +} + +#endif diff --git a/post/tests.c b/post/tests.c index 71437b6..bfb9cb5 100644 --- a/post/tests.c +++ b/post/tests.c @@ -46,6 +46,7 @@ extern int sysmon_post_test (int flags); extern int dsp_post_test (int flags); extern int codec_post_test (int flags); extern int ecc_post_test (int flags); +extern int flash_post_test(int flags);
extern int dspic_init_post_test (int flags); extern int dspic_post_test (int flags); @@ -301,7 +302,19 @@ struct post_test post_list[] = NULL, NULL, CONFIG_SYS_POST_COPROC - } + }, +#endif +#if CONFIG_POST & CONFIG_SYS_POST_FLASH + { + "Parallel NOR flash test", + "flash", + "This test verifies parallel flash operations.", + POST_RAM | POST_SLOWTEST | POST_MANUAL, + &flash_post_test, + NULL, + NULL, + CONFIG_SYS_POST_FLASH + }, #endif };
The current arch/driver specific UART posts basically boil down to setting the UART to loop back mode, then reading and writing data. If we ignore the loop back part, the rest can be built upon the existing common serial API. So let's do just that.
First add a call back for serial drivers to implement loop back control. Then write a post test that walks all of the serial drivers, puts them into loop back mode, and verifies that reading/writing at all the diff baud rates is OK.
If a serial driver doesn't support loop back mode (either it can't or it hasn't done so yet), then skip it. This should allow for people to easily migrate to the new post test with existing serial drivers.
I haven't touched the few already existing uart post tests as I don't the hardware or knowledge of converting them over. So I've marked the new test as weak which will allow the existing tests to override the default until they are converted.
Signed-off-by: Mike Frysinger vapier@gentoo.org --- common/serial.c | 90 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ include/serial.h | 5 +++ 2 files changed, 95 insertions(+), 0 deletions(-)
diff --git a/common/serial.c b/common/serial.c index 8ebf9a5..27c9b69 100644 --- a/common/serial.c +++ b/common/serial.c @@ -24,6 +24,8 @@ #include <common.h> #include <serial.h> #include <stdio_dev.h> +#include <post.h> +#include <linux/compiler.h>
DECLARE_GLOBAL_DATA_PTR;
@@ -291,3 +293,91 @@ void serial_puts (const char *s)
serial_current->puts (s); } + +#if CONFIG_POST & CONFIG_SYS_POST_UART +static const int bauds[] = CONFIG_SYS_BAUDRATE_TABLE; + +/* Mark weak until post/cpu/.../uart.c migrate over */ +__weak +int uart_post_test(int flags) +{ + unsigned char c; + int ret, saved_baud, b; + struct serial_device *saved_dev, *s; + bd_t *bd = gd->bd; + + /* Save current serial state */ + ret = 0; + saved_dev = serial_current; + saved_baud = bd->bi_baudrate; + + for (s = serial_devices; s; s = s->next) { + /* If this driver doesn't support loop back, skip it */ + if (!s->loop) + continue; + + /* Test the next device */ + serial_current = s; + + ret = serial_init(); + if (ret) + goto done; + + /* Consume anything that happens to be queued */ + while (serial_tstc()) + serial_getc(); + + /* Enable loop back */ + s->loop(1); + + /* Test every available baud rate */ + for (b = 0; b < ARRAY_SIZE(bauds); ++b) { + bd->bi_baudrate = bauds[b]; + serial_setbrg(); + + /* + * Stick to printable chars to avoid issues: + * - terminal corruption + * - serial program reacting to sequences and sending + * back random extra data + * - most serial drivers add in extra chars (like \r\n) + */ + for (c = 0x20; c < 0x7f; ++c) { + /* Send it out */ + serial_putc(c); + + /* Make sure it's the same one */ + ret = (c != serial_getc()); + if (ret) { + s->loop(0); + goto done; + } + + /* Clean up the output in case it was sent */ + serial_putc('\b'); + ret = ('\b' != serial_getc()); + if (ret) { + s->loop(0); + goto done; + } + } + } + + /* Disable loop back */ + s->loop(0); + + /* XXX: There is no serial_uninit() !? */ + if (s->uninit) + s->uninit(); + } + + done: + /* Restore previous serial state */ + serial_current = saved_dev; + bd->bi_baudrate = saved_baud; + serial_reinit_all(); + serial_setbrg(); + + return ret; +} +#endif diff --git a/include/serial.h b/include/serial.h index f21d961..2230ed0 100644 --- a/include/serial.h +++ b/include/serial.h @@ -1,6 +1,8 @@ #ifndef __SERIAL_H__ #define __SERIAL_H__
+#include <post.h> + #define NAMESIZE 16 #define CTLRSIZE 8
@@ -15,6 +17,9 @@ struct serial_device { int (*tstc) (void); void (*putc) (const char c); void (*puts) (const char *s); +#if CONFIG_POST & CONFIG_SYS_POST_UART + void (*loop) (int); +#endif
struct serial_device *next; };
Dear Mike Frysinger,
In message 1309289196-5718-1-git-send-email-vapier@gentoo.org you wrote:
All of thse patches have been posted previously, and no one has given feedback, so here they are in a handy branch for you to pull.
The following changes since commit b1af6f532e0d348b153d5c148369229d24af361a:
Prepare v2011.06 (2011-06-27 22:22:42 +0200)
are available in the git repository at: git://www.denx.de/git/u-boot-blackfin.git post
Please stop reposting patches without reference or patch version or change logs.
Please consider all these postings to be NAKed.
Please stick to the rules. These apply to everbody, including you. Even more so to you, as you have the experience and knowledge so that you actually should be aware of how these things get done.
Also, after posting a patch series you MUST allow for review time.
Um... you are reposting old patches unchanged? Now this is a really stupid thing to do - please stop doing that.
Best regards,
Wolfgang Denk
On Wednesday, June 29, 2011 17:21:46 Wolfgang Denk wrote:
Please stick to the rules. These apply to everbody, including you. Even more so to you, as you have the experience and knowledge so that you actually should be aware of how these things get done.
you'll need to revise the wiki then as this really isnt how the linux workflow works. i dont know which patches exactly have been posted, which had feedback and were revised, etc... so i just posted the entire set that havent been merged fresh in case people missed things the first time around -- as is done on lkml.
since most likely nothing is going to get changed (again) in the next two weeks, i'll simply rebase the branches and send another pull request. -mike
Dear Mike Frysinger,
In message 201106291930.48377.vapier@gentoo.org you wrote:
On Wednesday, June 29, 2011 17:21:46 Wolfgang Denk wrote:
Please stick to the rules. These apply to everbody, including you. Even more so to you, as you have the experience and knowledge so that you actually should be aware of how these things get done.
you'll need to revise the wiki then as this really isnt how the linux workflow works. ...
I see no need to change anything, as the wiki represents how OUR workflow works.
Please don't start applying random rules.
... i dont know which patches exactly have been posted, which had feedback and were revised, etc...
Then please get a clue. If you don't maintain your own copies of such mails, then you can always refer to any of the mailing list archives. And of course there is patchwork, which nicely collects all messages that are related to a patch.
All you have to is looking there.
... so i just posted the entire set that havent beenmerged fresh in case people missed things the first time around -- as is done on lkml.
I don't care if this is done like this on lkml. I consider it a stupid thing to do, as there is no indication in this repost 1) that this has been posted before, 2) to which mail thread a patch might refer to, 3) if this is just an unchanged repost and 4) if you made any changes, what these changes might be.
I will definitely not invest any time in trying to find this out.
We have clear rules how to post patches and updated versions of patches, and I ask you again to stick to these rules.
Reposting patches - changed or unchanged - without any additional commend will receive immediate NAKs.
since most likely nothing is going to get changed (again) in the next two weeks, i'll simply rebase the branches and send another pull request.
I will not pull any patches that have been NAKed, and these are. And any similar repostings will be NAKed as well.
If you want to do something useful, then apply the original patches, and make sure to reference these properly.
Thanks.
Wolfgang Denk
On Thu, Jun 30, 2011 at 06:29, Wolfgang Denk wrote:
Mike Frysinger wrote:
On Wednesday, June 29, 2011 17:21:46 Wolfgang Denk wrote:
Please stick to the rules. These apply to everbody, including you. Even more so to you, as you have the experience and knowledge so that you actually should be aware of how these things get done.
you'll need to revise the wiki then as this really isnt how the linux workflow works. ...
I see no need to change anything, as the wiki represents how OUR workflow works.
Please don't start applying random rules.
i'm not applying "random" rules. the workflow is generally modeled after the linux workflow, and the wiki explicitly has a section called "Differences to Linux Development Process". this common linux workflow was not mentioned in the differences section.
If you want to do something useful, then apply the original patches, and make sure to reference these properly.
except that they already are the original ones -mike
Dear Mike Frysinger,
In message BANLkTi=PoSnG11pLWC11Xv=HVO_pYQOR0A@mail.gmail.com you wrote:
If you want to do something useful, then apply the original patches, and make sure to reference these properly.
except that they already are the original ones
Then why did you repost them? This is completely stupid, and I never want to see this again.
And why do you think the rules for posting patches don't apply to you?
Wolfgang Denk
On Thu, Jun 30, 2011 at 11:38, Wolfgang Denk wrote:
Mike Frysinger wrote:
If you want to do something useful, then apply the original patches, and make sure to reference these properly.
except that they already are the original ones
Then why did you repost them?
i already explained why in the thread.
i just went through patchwork and d/l-ed the ones posted there and compared to my local tree to come to the conclusion that everything has already been posted (which is something i was not sure of when i sent things out a few days ago). it was a pita, but a requirement you stipulated.
And why do you think the rules for posting patches don't apply to you?
i never said that, and i already explained why i did what i did -mike
Dear Mike Frysinger,
In message BANLkTimMPtK0gyhRGammL0igYKsB0O2HCA@mail.gmail.com you wrote:
i just went through patchwork and d/l-ed the ones posted there and compared to my local tree to come to the conclusion that everything has already been posted (which is something i was not sure of when i sent things out a few days ago). it was a pita, but a requirement you stipulated.
As a result of this action you could have come up with a branch that includes all the stuff that "has already been posted". There was no need nor any benefit from reposting the stuff again. On contrary, it is just wasting time and resources.
And why do you think the rules for posting patches don't apply to you?
i never said that, and i already explained why i did what i did
Then please follow the rules. Don't repost other people's patches unchanged; and if you change them, provide proper indication in the Subject and a patch's change log.
Best regards,
Wolfgang Denk
On Thu, Jun 30, 2011 at 11:49, Wolfgang Denk wrote:
Mike Frysinger wrote:
i just went through patchwork and d/l-ed the ones posted there and compared to my local tree to come to the conclusion that everything has already been posted (which is something i was not sure of when i sent things out a few days ago). it was a pita, but a requirement you stipulated.
As a result of this action you could have come up with a branch that includes all the stuff that "has already been posted". There was no need nor any benefit from reposting the stuff again. On contrary, it is just wasting time and resources.
i often post misc patches all over which frequently get forgotten, and so i roll them up into a dedicated branch for you to pull. and in the past, you said you liked that.
so now you're saying that my only option is to ping multiple patches over time until you notice. that sounds like more of a waste. -mike
Dear Mike Frysinger,
In message BANLkTinWfOUUBM8oJRuTZpX2N6ADTZTZ+A@mail.gmail.com you wrote:
i just went through patchwork and d/l-ed the ones posted there and compared to my local tree to come to the conclusion that everything has already been posted (which is something i was not sure of when i sent things out a few days ago). =A0it was a pita, but a requirement you stipulated.
As a result of this action you could have come up with a branch that includes all the stuff that "has already been posted". =A0There was no need nor any benefit from reposting the stuff again. =A0On contrary, it is just wasting time and resources.
i often post misc patches all over which frequently get forgotten, and so i roll them up into a dedicated branch for you to pull. and in the past, you said you liked that.
Indeed, such a branch can be helpful. Also a pull request for it. But we're talking about the _original_ patches.
so now you're saying that my only option is to ping multiple patches over time until you notice. that sounds like more of a waste.
You misunderstand.
Best regards,
Wolfgang Denk
On Thu, Jun 30, 2011 at 17:10, Wolfgang Denk wrote:
Indeed, such a branch can be helpful. Also a pull request for it. But we're talking about the _original_ patches.
and that's what my serial/post/sf patches ended up being. should i change the status for them in patchwork from "rejected" to "new" ? -mike
Dear Mike Frysinger,
In message BANLkTimNnd7SS3K4ovEKNFV3TytGz6JzgQ@mail.gmail.com you wrote:
On Thu, Jun 30, 2011 at 17:10, Wolfgang Denk wrote:
Indeed, such a branch can be helpful. Also a pull request for it. =A0But we're talking about the _original_ patches.
and that's what my serial/post/sf patches ended up being. should i
You don't want to understand, right? You posted _new_ patches. There is a chance that these might actually be identical to any previously posted ones, but my time is way too precious that I would spend a single second on checking this, especially when you ignore all rules (version marker in the Subject, change log in the comment section).
change the status for them in patchwork from "rejected" to "new" ?
Try it, if you really want to see how I react when someone really p*sses me off.
I have already wasted way too much time on this stupid issue. I do not intend to continue this discussion.
Wolfgang Denk
On Thu, Jun 30, 2011 at 18:57, Wolfgang Denk wrote:
Mike Frysinger wrote:
On Thu, Jun 30, 2011 at 17:10, Wolfgang Denk wrote:
Indeed, such a branch can be helpful. Also a pull request for it. =A0But we're talking about the _original_ patches.
and that's what my serial/post/sf patches ended up being. should i
You don't want to understand, right? You posted _new_ patches. There is a chance that these might actually be identical to any previously posted ones, but my time is way too precious that I would spend a single second on checking this, especially when you ignore all rules (version marker in the Subject, change log in the comment section).
and like i *already* said, i verified that the patches just posted match the ones already posted in the past by downloading them from patchwork and doing a diff on them.
I have already wasted way too much time on this stupid issue. I do not intend to continue this discussion.
so basically you're permanently NAK-ing all my patches even though i'm trying to find a way forward. awesome. -mike
Dear Mike Frysinger,
In message BANLkTim2vo8vrSZWWxGnLf8N2_gqBHUVSQ@mail.gmail.com you wrote:
so basically you're permanently NAK-ing all my patches even though i'm trying to find a way forward. awesome.
It's awsome how you manage to continue to ignore the documented rules, even after I explained them ten times to you.
You are wasting my time.
Wolfgang Denk
On Friday, July 01, 2011 00:36:59 Wolfgang Denk wrote:
Mike Frysinger wrote:
so basically you're permanently NAK-ing all my patches even though i'm trying to find a way forward. awesome.
It's awsome how you manage to continue to ignore the documented rules, even after I explained them ten times to you.
i'm not ignoring any rules. you said you dont want dumps of patches that havent been changed and lack pointing back to previous sets. fine.
you also said you only want pull requests of patches that match the patches previously posted to the list, and based on that you NAK-ed my pulls. i then researched and clarified that all the pulls match exactly the patches that were in patchwork before the fresh dumps on June 28th. pretend the patch dumps for these branches didnt happen on June 28th, and the pull requests would still be exactly the same.
yet you still refuse to take the pull requests and provide no reason as to why. you only say that i'm "wasting your time" with no backing logic and no indication as to how to move forward. i cant go back in time and unsend the patches that have already hit the list. -mike
Dear Mike Frysinger,
In message 201107011927.38666.vapier@gentoo.org you wrote:
i'm not ignoring any rules. you said you dont want dumps of patches that havent been changed and lack pointing back to previous sets. fine.
http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions
yet you still refuse to take the pull requests and provide no reason as to why. you only say that i'm "wasting your time" with no backing logic and no indication as to how to move forward. i cant go back in time and unsend the patches that have already hit the list.
Unsend patches? I suggest you take a time-out of a few days, and then re-read this thread. If you still don't understand, then please ask somebody else to explain it to you.
I give up here.
Wolfgang Denk
On Sunday, July 03, 2011 18:30:05 Wolfgang Denk wrote:
Mike Frysinger wrote:
i'm not ignoring any rules. you said you dont want dumps of patches that havent been changed and lack pointing back to previous sets. fine.
http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions
which is irrelevant like i already said multiple times -- these patches arent updated
yet you still refuse to take the pull requests and provide no reason as to why. you only say that i'm "wasting your time" with no backing logic and no indication as to how to move forward. i cant go back in time and unsend the patches that have already hit the list.
Unsend patches? I suggest you take a time-out of a few days, and then re-read this thread. If you still don't understand, then please ask somebody else to explain it to you.
you seem to be ignoring the points i'm making -mike
Dear Mike Frysinger,
In message 201107042125.54555.vapier@gentoo.org you wrote:
http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions
which is irrelevant like i already said multiple times -- these patches arent updated
So there is zero reason for resending.
you seem to be ignoring the points i'm making
Wrong, twice. First, you are not making any points. You are just repeating the same rogation. Second, I'm on the verge of ignoring you.
Wolfgang Denk
On Tuesday, July 05, 2011 00:42:13 Wolfgang Denk wrote:
Mike Frysinger wrote:
http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versi ons
which is irrelevant like i already said multiple times -- these patches arent updated
So there is zero reason for resending.
you already said that's what you want, and i already said "OK", which gets us back to what i already asked: if the pull requests reflect the old patches posted to the list before the resend on June 28th, then why cant they be changed from "rejected" to "new" ? -mike
Dear Mike Frysinger,
In message 201107050214.11960.vapier@gentoo.org you wrote:
you already said that's what you want, and i already said "OK", which gets us back to what i already asked: if the pull requests reflect the old patches posted to the list before the resend on June 28th, then why cant they be changed from "rejected" to "new" ?
Your bogus repostings are rejected, not the original patches.
Wolfgang Denk
On Tuesday, July 05, 2011 05:59:56 Wolfgang Denk wrote:
Mike Frysinger wrote:
you already said that's what you want, and i already said "OK", which gets us back to what i already asked: if the pull requests reflect the old patches posted to the list before the resend on June 28th, then why cant they be changed from "rejected" to "new" ?
Your bogus repostings are rejected, not the original patches.
so since my pull requests are actually the original patches, i can go ahead and change them from "rejected" to "new" ? or should i just send new pull requests ? -mike
Dear Mike Frysinger,
In message 201107051332.55970.vapier@gentoo.org you wrote:
Your bogus repostings are rejected, not the original patches.
so since my pull requests are actually the original patches, i can go ahead and change them from "rejected" to "new" ? or should i just send new pull requests ?
This has already been answered. You are wasting my time. Stop it, now.
This is my last message in this thread. Try to get help elsewhere. I got better things to do.
Wolfgang Denk
On Tuesday, July 05, 2011 17:54:32 Wolfgang Denk wrote:
Mike Frysinger wrote:
Your bogus repostings are rejected, not the original patches.
so since my pull requests are actually the original patches, i can go ahead and change them from "rejected" to "new" ? or should i just send new pull requests ?
This has already been answered. You are wasting my time. Stop it, now.
your logic makes no sense. you say you are fine with the original patches, but i cant send pull requests of the original patches. i guess i'll have to wait for you to pick the individual patches out of patchwork then. -mike
participants (2)
-
Mike Frysinger -
Wolfgang Denk