[U-Boot] Bad Data CRC ERROR: can't get kernel image!
I am using u-boot version 2009-08 for customized PPC 440 based board. Board is having 16MB Nor flash. I am flashing the kernel image at 0xffdc, ramdisk at 0xff8c and dtb at 0xff20 When I pass bootm command through u-boot prompt i.e “bootm 0xffdc 0xff8c 0xff20” Kernel booting stops with following error message. ## Booting kernel from Legacy Image at ffdc ... Image Name: Linux-2.6.31-LE Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 936145 Bytes = 914.2 kB Load Address: Entry Point: Bad Data CRC ERROR: can't get kernel image! When I print the data that we calculated in image_check_dcrc() I found foloowing difference: Calculated DCRC Data : 0xffdc0040 Len: 0xe48d1 dcrc: 0x5fe26d1e From image_get_dcrc function DCRC: 0x72e08293 And hence return (dcrc == image_get_dcrc (hdr)) this condition become false. Please let me know your input on this. -Ronny Send free SMS to your Friends on Mobile from your Yahoo! Messenger. Download Now! http://messenger.yahoo.com/download.php___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V6 1/3] Initial support for Marvell Orion5x SoC
Prafulla Wadaskar a écrit : -Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Tuesday, April 13, 2010 9:10 PM To: Prafulla Wadaskar Cc: Wolfgang Denk; U-Boot@lists.denx.de Subject: Re: [U-Boot] [PATCH V6 1/3] Initial support for Marvell Orion5x SoC Prafulla Wadaskar a écrit : You are right, the code is SoC specific, but the values to be programmed are board specific. if you are interested, Look at cpu/arm926ejs/at91/lowlevel_init.s how it programs SMRDATA. Follow similar arch here too. -Define similar data segment for holding soc_reg_addr and data array -Define macros for SOC register addresses in soc specific header file -Define macros for SOC register values in board specific header file This way we can retain lowlevel_init.S in soc specific folder, whereas you can pass data through board specific macros. Ok. DRAM init should go in lowlevel_init i.e. asm code, that's need of Orion5X Either its location or its architecture need to change to address board specific issues. Agreed. Now, what about that overall cpu/arch hierarchy change that's been started? Is there a branch with the new file hierarchi that I should rebase on, or do I keep the current organization in my patch? I am waiting for u-boot-arm.git to get rebased so that I can rebase u-boot-mravell.git Meanwhile this happens, you can post your patches w.r.to u-boot.git. Regards.. Prafulla . . Prafulla, FYI, I will unfortunately be unable to work further on this patch until next wednesday. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM/PXA maintainership
-Original Message- From: Marek Vasut [mailto:marek.va...@gmail.com] Sent: Thursday, April 15, 2010 12:13 AM To: Wolfgang Denk Cc: Tom; Prafulla Wadaskar; u-boot@lists.denx.de Subject: Re: [U-Boot] U-Boot ARM/PXA maintainership Dne St 14. dubna 2010 20:26:04 Wolfgang Denk napsal(a): Dear Tom, In message 4bc5a674.9070...@windriver.com you wrote: Tom, if you (and everybody else) aggree(s) I would like to hand over the u-boot-pxa repository to Marek. What do you think? That would be fine with me. Thanks. Hi, Marek - the u-boot-pxa repository is ready for your use now. Thanks! Hm... I would like to keep hierarchy flat, and my impression is that the PXA activities are pretty much different from Marvell's other U-Boot related work, so I suggest you send your pull requests directly to Tom. You mean Kirkwood, Orion or Armada (did any patches for this actually hit the tree yet)? Yes, those SoCs are different. Yes, Kirkwood is already mainlined, Orion in progress will be mainlined available soon. Armada under development. Prafulla, is this OK with you? Yes, This is okay with me, I wish good luck for Marek for this activity. Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] improve printf behavior on arm/pxa after enabling 64bit support in printf by default.
Dne Čt 15. dubna 2010 01:12:30 Mikhail Kshevetskiy napsal(a): Yes, you was right. This is definitely an alignment issue. Here is a patch to fix this issue. Thanks, actually, I pushed a different patch that fixed the stack alignment issue, but forgot to reserve the space for abort stack in my patch. Therefore I pushed a patch on top of mine based on your patch. The patch is attached below. Ah also please, keep track of the u-boot-pxa.git repo, that should contain most recent fixes for xscale. http://git.denx.de/?p=u-boot/u-boot-pxa.git;a=summary Sorry for attaching file. I am in a trip and use web browser for sending mail Fine by me. But please, stop top posting (post below the mail or into the body). It's some rule that improves readability. Thanks! 2010/4/10 Wolfgang Denk w...@denx.de: Dear Mikhail Kshevetskiy, In message 20100329162346.017a4...@laska.campus-ws.pu.ru you wrote: commit 4b142febff71eabdb7ddbb125c7b583b24ddc434 (common: delete CONFIG_SYS_64BIT_VSPRINTF and CONFIG_SYS_64BIT_STRTOUL) breaks printf on my arm/pxa270 board. For example, the code int a = 128; printf(a= %d\n, a); will print zero on the console. The problem reproduced on gcc 4.1.1, 4.3.3, 4.4.1 and 4.4.2. This patch fix printf unless you'll need printing 64-bit values. I doubt that your patch addresses the real cause of the problem. Did you check if the stack alignment problem discussed here earlier has been fixed for your architecture? From: Marek Vasut marek.va...@gmail.com Date: Thu, 15 Apr 2010 09:35:04 +0200 Subject: [PATCH] PXA: Fix abort stack The stack alignment patch didn't reserve space for abort stack anymore. This patch fixes the problem. Original patch that pointed this issue out was by Mikhail Kshevetskiy. Signed-off-by: Marek Vasut marek.va...@gmail.com --- arch/arm/cpu/pxa/start.S |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/pxa/start.S b/arch/arm/cpu/pxa/start.S index f7236bf..3989fa6 100644 --- a/arch/arm/cpu/pxa/start.S +++ b/arch/arm/cpu/pxa/start.S @@ -140,8 +140,8 @@ stack_setup: #ifdef CONFIG_USE_IRQ sub r0, r0, #(CONFIG_STACKSIZE_IRQ+CONFIG_STACKSIZE_FIQ) #endif /* CONFIG_USE_IRQ */ - bic sp, r0, #7 /* leave 4 words for abort-stack*/ - /* NOTE: stack MUST be aligned to */ + sub r0, r0, #12 /* leave 3 words for abort-stack*/ + bic sp, r0, #7 /* NOTE: stack MUST be aligned to */ /* 8 bytes in case we want to use */ /* 64bit datatypes (eg. VSPRINTF64) */ -- 1.7.0 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: w...@denx.de Die Scheu vor Verantwortung ist die Krankheit unserer Zeit. -- Otto von Bismarck ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Heads-up: Reorganize directory structure
Wolfgang Denk wrote: Hello Custodians, please note that I have applied Peter Tyser's Reorganize directory structure patch series. This results in a massive change of the directory structure. Please make sure to sync your repsitories ASAP. Do you have any plan to move board dirs to arch folder too? Regards, Michal Thanks. Best regards, Wolfgang Denk -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Heads-up: Reorganize directory structure
[cc: list trimmed as this is not that urgent any more] Dear Michal Simek, In message 4bc6bad2.8040...@monstr.eu you wrote: please note that I have applied Peter Tyser's Reorganize directory structure patch series. This results in a massive change of the directory structure. Please make sure to sync your repsitories ASAP. Do you have any plan to move board dirs to arch folder too? Speaking for myself: I have no such plans. 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: w...@denx.de What's the sound a name makes when it's dropped? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] OpenRD: Bring PCIe endpoint out of reset
There exists PCIe endpoints(not all) that remains in reset state till PERST# line (A11 on the PCIe connector) is hold low. They come out of reset only when this line is high. In case of OpenRD, this line was in tri-state. So, some of the PCIe devices would never appear on the PCIe bus. This patch makes PERST# line high while booting to bring such PCIe devices out of reset. XGI Vollari Z11 GPU and Intel WiFi 4965 are the ones who doesn't care about this line. Where as Broadcom's BCM970012 won't appear on the PCIe bus until PERST# is high. With this patch both kinds of device would appear on the PCIe bus. Signed-off-by: Tanmay Upadhyay tanmay.upadh...@einfochips.com Signed-off-by: Dhaval Vasa dhaval.v...@einfochips.com --- board/Marvell/openrd_base/openrd_base.h |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/board/Marvell/openrd_base/openrd_base.h b/board/Marvell/openrd_base/openrd_base.h index f3daf17..965bd50 100644 --- a/board/Marvell/openrd_base/openrd_base.h +++ b/board/Marvell/openrd_base/openrd_base.h @@ -30,10 +30,10 @@ #ifndef __OPENRD_BASE_H #define __OPENRD_BASE_H -#define OPENRD_OE_LOW (~(128))/* RS232 / RS485 */ -#define OPENRD_OE_HIGH (~(12)) /* SD / UART1 */ -#define OPENRD_OE_VAL_LOW (0) /* Sel RS232 */ -#define OPENRD_OE_VAL_HIGH (1 2) /* Sel SD */ +#define OPENRD_OE_LOW (~((128) | (17))) /* RS232 / RS485 */ +#define OPENRD_OE_HIGH (~(12)) /* SD / UART1 */ +#define OPENRD_OE_VAL_LOW (17) /* Sel RS232 */ +#define OPENRD_OE_VAL_HIGH (1 2) /* Sel SD */ /* PHY related */ #define MV88E1116_LED_FCTRL_REG10 -- 1.6.6.1 -- _ Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. _ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] mpc5121: pdm360ng: add coprocessor POST
Hi Wolfgang,
Dear Anatolij Gustschin,
In message 1271254909-20398-4-git-send-email-ag...@denx.de you wrote:
Adds coprocessor communication POST code.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
board/pdm360ng/Makefile|1 +
board/pdm360ng/post.c | 75
include/configs/pdm360ng.h |5 +++
include/post.h |1 +
post/tests.c | 13 +++
5 files changed, 95 insertions(+), 0 deletions(-)
create mode 100644 board/pdm360ng/post.c
...
--- a/post/tests.c
+++ b/post/tests.c
@@ -53,6 +53,7 @@ extern int gdc_post_test (int flags);
extern int fpga_post_test (int flags);
extern int lwmon5_watchdog_post_test(int flags);
extern int sysmon1_post_test(int flags);
+extern int pdm360ng_coprocessor_post_test(int flags);
extern int sysmon_init_f (void);
@@ -286,6 +287,18 @@ struct post_test post_list[] =
#if CONFIG_POST CONFIG_SYS_POST_BSPEC5
CONFIG_POST_BSPEC5,
#endif
+#if CONFIG_POST CONFIG_SYS_POST_COPROC
+{
+Coprocessors communication test,
+coproc_com,
+This test checks communication with coprocessors.,
+POST_RAM | POST_ALWAYS | POST_CRITICAL,
+pdm360ng_coprocessor_post_test,
+NULL,
+NULL,
+CONFIG_SYS_POST_COPROC
+}
+#endif
};
I don't want to see board specific code (pdm360ng_*) in such a global
file. Please use a more generic approach.
Do you mean like for example CONFIG_POST_BSPEC1 used for lwmon5?
Anatolij, this should be straight forward.
Cheers
Detlev
--
C hasn't changed much since the 1970s. And let's face it it's ugly.
Can't we do better? C++? (Sorry, never mind.)
-- Rob Pike
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] mpc5121: pdm360ng: add coprocessor POST
Hi Detlev,
On Thu, 15 Apr 2010 11:18:13 +0200
Detlev Zundel d...@denx.de wrote:
...
@@ -286,6 +287,18 @@ struct post_test post_list[] =
#if CONFIG_POST CONFIG_SYS_POST_BSPEC5
CONFIG_POST_BSPEC5,
#endif
+#if CONFIG_POST CONFIG_SYS_POST_COPROC
+{
+ Coprocessors communication test,
+ coproc_com,
+ This test checks communication with coprocessors.,
+ POST_RAM | POST_ALWAYS | POST_CRITICAL,
+ pdm360ng_coprocessor_post_test,
+ NULL,
+ NULL,
+ CONFIG_SYS_POST_COPROC
+}
+#endif
};
I don't want to see board specific code (pdm360ng_*) in such a global
file. Please use a more generic approach.
Do you mean like for example CONFIG_POST_BSPEC1 used for lwmon5?
Anatolij, this should be straight forward.
Similar was in the first patch version. But according to Wolfgang
this doesn't belong in the board config file.
Anatolij
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bad Data CRC ERROR: can't get kernel image!
Hi Ronny, Bad Data CRC ERROR: can't get kernel image! [...] Please let me know your input on this. Well your data seems to be corrupt - what more can we say? What does imi 0xffdc say? Maybe you did not flash the whole image correctly? E.g. did you see error message about non-erased flash? Cheers Detlev -- Test applications with a variety of tools. Don't assume everything works if you've tested with only one client. Also, assume the low end of technology for clients and don't create applications which can only be used by Graphical User Interfaces. -- RFC 1855 -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] mpc5121: pdm360ng: add coprocessor POST
Hello Wolfgang,
On Wed, 14 Apr 2010 17:40:16 +0200
Wolfgang Denk w...@denx.de wrote:
...
--- a/post/tests.c
+++ b/post/tests.c
@@ -53,6 +53,7 @@ extern int gdc_post_test (int flags);
extern int fpga_post_test (int flags);
extern int lwmon5_watchdog_post_test(int flags);
extern int sysmon1_post_test(int flags);
+extern int pdm360ng_coprocessor_post_test(int flags);
extern int sysmon_init_f (void);
@@ -286,6 +287,18 @@ struct post_test post_list[] =
#if CONFIG_POST CONFIG_SYS_POST_BSPEC5
CONFIG_POST_BSPEC5,
#endif
+#if CONFIG_POST CONFIG_SYS_POST_COPROC
+{
+ Coprocessors communication test,
+ coproc_com,
+ This test checks communication with coprocessors.,
+ POST_RAM | POST_ALWAYS | POST_CRITICAL,
+ pdm360ng_coprocessor_post_test,
+ NULL,
+ NULL,
+ CONFIG_SYS_POST_COPROC
+}
+#endif
};
I don't want to see board specific code (pdm360ng_*) in such a global
file. Please use a more generic approach.
What would be a preferred way to realize this? Defining a weak
function in post/post.c or post/tests.c which could be over-ridden
by board specific one? Like:
int __post_coprocessor_post_test(int flags)
{
return 0;
}
int coprocessor_post_test(int flags)
__attribute__((weak, alias(__post_coprocessor_post_test)));
Then I have to put board specific post code in board/pdm360ng/post.c
to the pdm360ng.c file back. Otherwise the board's
coprocessor_post_test() function is not linked if there is no other
code in this post.c file which is strongly-linked.
Anatolij
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] microblaze: Add FDT support
This patch adds FDT (flattened device tree) support to microblaze arch.
Tested with Linux arch/microblaze kernels with and without compiled in
FDT on Xilinx ML506 board.
Signed-off-by: Arun Bhanu a...@bhanu.net
---
arch/microblaze/lib/bootm.c | 39 ++-
1 files changed, 34 insertions(+), 5 deletions(-)
diff --git a/arch/microblaze/lib/bootm.c b/arch/microblaze/lib/bootm.c
index bce4774..0c2c5e8 100644
--- a/arch/microblaze/lib/bootm.c
+++ b/arch/microblaze/lib/bootm.c
@@ -35,22 +35,51 @@ DECLARE_GLOBAL_DATA_PTR;
int do_bootm_linux(int flag, int argc, char *argv[], bootm_headers_t *images)
{
/* First parameter is mapped to $r5 for kernel boot args */
- void(*theKernel) (char *);
+ void(*theKernel) (char *, ulong, ulong);
char*commandline = getenv (bootargs);
+ ulong rd_data_start, rd_data_end;
if ((flag != 0) (flag != BOOTM_STATE_OS_GO))
return 1;
- theKernel = (void (*)(char *))images-ep;
+ int ret;
+
+ char*of_flat_tree = NULL;
+#if defined(CONFIG_OF_LIBFDT)
+ ulong of_size = 0;
+
+ /* find flattened device tree */
+ ret = boot_get_fdt (flag, argc, argv, images, of_flat_tree, of_size);
+ if (ret)
+ return 1;
+#endif
+
+ theKernel = (void (*)(char *, ulong, ulong))images-ep;
+
+ /* find ramdisk */
+ ret = boot_get_ramdisk (argc, argv, images, IH_ARCH_MICROBLAZE,
+ rd_data_start, rd_data_end);
+ if (ret)
+ return 1;
show_boot_progress (15);
+ if (!(ulong) of_flat_tree)
+ of_flat_tree = simple_strtoul (argv[3], NULL, 16);
+
#ifdef DEBUG
- printf (## Transferring control to Linux (at address %08lx) ...\n,
- (ulong) theKernel);
+ printf (## Transferring control to Linux (at address 0x%08lx) \
+ ramdisk 0x%08lx, FDT 0x%08lx...\n,
+ (ulong) theKernel, rd_data_start, (ulong) of_flat_tree);
#endif
- theKernel (commandline);
+ /*
+* Linux Kernel Parameters (passing device tree):
+* r5: pointer to command line
+* r6: pointer to ramdisk
+* r7: pointer to the fdt, followed by the board info data
+*/
+ theKernel (commandline, rd_data_start, (ulong) of_flat_tree);
/* does not return */
return 1;
--
1.6.2.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/7] Nomadik: lcd and other stuff
From: Alessandro Rubini rub...@unipv.it This patch set is the one from December, with one addition in documentation (last patch in the series). It is rebased to current master, although there was no dependency on the massive renames besides the fix timer patch which meanwhile got upstream. Alessandro Rubini (7): nhk8815: change the order of initialization drivers/misc: add stmpe2401 port extender and keypad controller nhk8815.h: define we need stmpe nhk8815: added keypad nhk8815: start lower in RAM, so the 800x480 frame buffer fits nhk8815: added lcd support nhk8815: documented how to replace u-boot on flash board/st/nhk8815/Makefile |6 +- board/st/nhk8815/config.mk |8 +- board/st/nhk8815/keypad.c | 99 +++ board/st/nhk8815/lcd.c | 88 + board/st/nhk8815/nhk8815-devices.h |8 ++ board/st/nhk8815/nhk8815.c | 38 +-- doc/README.nhk8815 | 20 drivers/misc/Makefile |1 + drivers/misc/stmpe2401.c | 191 include/configs/nhk8815.h | 20 - include/stmpe2401.h| 66 11 files changed, 528 insertions(+), 17 deletions(-) create mode 100644 board/st/nhk8815/keypad.c create mode 100644 board/st/nhk8815/lcd.c create mode 100644 board/st/nhk8815/nhk8815-devices.h create mode 100644 drivers/misc/stmpe2401.c create mode 100644 include/stmpe2401.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/7] nhk8815: change the order of initialization
From: Alessandro Rubini rub...@unipv.it
Some inizialization was in board_late_init(), but to satisfy drivers
added in the next patches must be performed in normal board_init.
This patch leaves board_late_init() empty, but later patches fill it.
Signed-off-by: Alessandro Rubini rub...@unipv.it
Acked-by: Andrea Gallo andrea.ga...@stericsson.com
---
board/st/nhk8815/nhk8815.c | 31 +--
1 files changed, 21 insertions(+), 10 deletions(-)
diff --git a/board/st/nhk8815/nhk8815.c b/board/st/nhk8815/nhk8815.c
index faef810..eadce40 100644
--- a/board/st/nhk8815/nhk8815.c
+++ b/board/st/nhk8815/nhk8815.c
@@ -60,22 +60,26 @@ int board_init(void)
writel(0x02100551, NOMADIK_FSMC_BASE + 0x04); /* FSMC_BTR0 */
icache_enable();
- return 0;
-}
-int board_late_init(void)
-{
+ /*
+* Configure I2C pins, as we will use I2C in a later commit
+*/
+
/* Set the two I2C gpio lines to be gpio high */
nmk_gpio_set(__SCL, 1); nmk_gpio_set(__SDA, 1);
nmk_gpio_dir(__SCL, 1); nmk_gpio_dir(__SDA, 1);
nmk_gpio_af(__SCL, GPIO_GPIO); nmk_gpio_af(__SDA, GPIO_GPIO);
- /* Reset the I2C port expander, on GPIO77 */
- nmk_gpio_af(77, GPIO_GPIO);
- nmk_gpio_dir(77, 1);
- nmk_gpio_set(77, 0);
- udelay(10);
- nmk_gpio_set(77, 1);
+ /* Put the two I2C port expanders out of reset, on GPIO77 and 79 */
+ {
+ int n[2]={77, 79};
+ int i;
+ for (i = 0; i ARRAY_SIZE(n); i++) {
+ nmk_gpio_af(n[i], GPIO_GPIO);
+ nmk_gpio_dir(n[i], 1);
+ nmk_gpio_set(n[i], 1);
+ }
+ }
return 0;
}
@@ -101,3 +105,10 @@ int board_eth_init(bd_t *bis)
return rc;
}
#endif
+
+/* Initialization callback, from lib_arm/board.c */
+int board_late_init(void)
+{
+ return 0;
+}
+
--
1.6.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/7] drivers/misc: add stmpe2401 port extender and keypad controller
From: Alessandro Rubini rub...@unipv.it
This driver is an i2c device acting as a port extender. Since
the keypad can be configured to act on specific row and column lines,
the specific setup is passed by the board file. This is used by
the Nomadik nhk8815, through a later patch in this series.
Signed-off-by: Alessandro Rubini rub...@unipv.it
Acked-by: Andrea Gallo andrea.ga...@stericsson.com
---
drivers/misc/Makefile|1 +
drivers/misc/stmpe2401.c | 191 ++
include/stmpe2401.h | 66
3 files changed, 258 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/stmpe2401.c
create mode 100644 include/stmpe2401.h
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index f6df60f..76c009a 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -30,6 +30,7 @@ COBJS-$(CONFIG_DS4510) += ds4510.o
COBJS-$(CONFIG_FSL_LAW) += fsl_law.o
COBJS-$(CONFIG_NS87308) += ns87308.o
COBJS-$(CONFIG_STATUS_LED) += status_led.o
+COBJS-$(CONFIG_STMPE2401) += stmpe2401.o
COBJS-$(CONFIG_TWL4030_LED) += twl4030_led.o
COBJS := $(COBJS-y)
diff --git a/drivers/misc/stmpe2401.c b/drivers/misc/stmpe2401.c
new file mode 100644
index 000..f347d07
--- /dev/null
+++ b/drivers/misc/stmpe2401.c
@@ -0,0 +1,191 @@
+/*
+ * board/st/nhk8815/egpio.c: extended gpio as found on nhk8815 board
+ *
+ * Copyright 2009 Alessandro Rubini rub...@unipv.it
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+#include common.h
+#include i2c.h
+#include stmpe2401.h
+
+/*
+ * First, an interface to set and read registers, used in this file as well
+ */
+int pe_getreg(int addr, int reg)
+{
+ unsigned char val8 = reg;
+ int ret;
+
+ ret = i2c_read(addr, reg, 1 /* len */, val8, 1);
+ if (ret 0)
+ return ret;
+ return val8;
+}
+
+int pe_setreg(int addr, int reg, int val)
+{
+ unsigned char val8 = val;
+
+ return i2c_write(addr, reg, 1, val8, 1);
+}
+
+/*
+ * Generic higher-level GPIO interface
+ */
+int pe_gpio_af(int addr, int pin, int af)
+{
+ int regval;
+
+ regval = pe_getreg(addr, PE_GPIO_AFR(pin));
+ if (regval 0)
+ return regval;
+ regval = ~PE_GPIO_AF_MASK(pin);
+ regval |= af PE_GPIO_AF_SHIFT(pin);
+ return pe_setreg(addr, PE_GPIO_AFR(pin), regval);
+}
+
+int pe_gpio_dir(int addr, int pin, int dir)
+{
+ int regval;
+
+ /* 0 == input, 1 == output */
+ regval = pe_getreg(addr, PE_GPIO_GPDR(pin));
+ if (regval 0)
+ return regval;
+ regval = ~PE_GPIO_MASK(pin);
+ if (dir)
+ regval |= PE_GPIO_MASK(pin);
+ return pe_setreg(addr, PE_GPIO_GPDR(pin), regval);
+}
+
+int pe_gpio_pud(int addr, int pin, int pu, int pd)
+{
+ int regval, mask = PE_GPIO_MASK(pin);
+
+ /* change pullup */
+ regval = pe_getreg(addr, PE_GPIO_GPPUR(pin));
+ if (regval 0)
+ return regval;
+ if (pu)
+ regval |= mask;
+ else
+ regval = ~mask;
+ regval = pe_setreg(addr, PE_GPIO_GPPUR(pin), regval);
+ if (regval 0)
+ return regval;
+
+ /* change pulldown */
+ regval = pe_getreg(addr, PE_GPIO_GPPDR(pin));
+ if (regval 0)
+ return regval;
+ if (pu)
+ regval |= mask;
+ else
+ regval = ~mask;
+ regval = pe_setreg(addr, PE_GPIO_GPPDR(pin), regval);
+ if (regval 0)
+ return regval;
+
+ return 0;
+}
+
+int pe_gpio_set(int addr, int pin, int val)
+{
+ int reg;
+
+ if (val)
+ reg = PE_GPIO_GPSR(pin);
+ else
+ reg = PE_GPIO_GPCR(pin);
+
+ return pe_setreg(addr, reg, PE_GPIO_MASK(pin));
+}
+
+int pe_gpio_get(int addr, int pin)
+{
+ int regval;
+
+ regval = pe_getreg(addr, PE_GPIO_GPMR(pin));
+ if (regval 0)
+ return regval;
+ return (regval PE_GPIO_MASK(pin)) ? 1 : 0;
+}
+
+/*
+ * Generic higher-level keypad interface: we have 12 rows out, 8 columns in
+ */
+int pe_kpc_init(int addr, int rowmask, int colmask, int debounce_ms)
+{
+ int i;
+ /* note that gpio15
[U-Boot] [PATCH 3/7] nhk8815.h: define we need stmpe
From: Alessandro Rubini rub...@unipv.it
Signed-off-by: Alessandro Rubini rub...@unipv.it
Acked-by: Andrea Gallo andrea.ga...@stericsson.com
---
include/configs/nhk8815.h |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/include/configs/nhk8815.h b/include/configs/nhk8815.h
index 2b640dc..fcb1b20 100644
--- a/include/configs/nhk8815.h
+++ b/include/configs/nhk8815.h
@@ -109,7 +109,7 @@
#define CONFIG_PL01x_PORTS { (void *)CFG_SERIAL0, (void *)CFG_SERIAL1 }
#define CONFIG_PL011_CLOCK 4800
-/* i2c, for the port extenders (uses gpio.c in board directory) */
+/* i2c, for the stmpe2401 port extenders (uses gpio.c in board directory) */
#ifndef __ASSEMBLY__
#include asm/arch/gpio.h
#define CONFIG_CMD_I2C
@@ -125,6 +125,11 @@
#define I2C_DELAY (udelay(2))
#endif /* __ASSEMBLY__ */
+/* Activate port extenders and define their i2c address */
+#define CONFIG_STMPE2401
+#define STMPE0 0x43
+#define STMPE1 0x44
+
/* Ethernet */
#define PCI_MEMORY_VADDR 0xe800
#define PCI_IO_VADDR 0xee00
--
1.6.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/7] nhk8815: added keypad
From: Alessandro Rubini rub...@unipv.it
This patch adds keypad support for the nhk8815 board, based on the
stmpe2401 driver. The keypad hosts 16 keys, so each of them sends a
string instead of a single key. The provided keymap is only an
example and must be customized according to the use case.
Signed-off-by: Alessandro Rubini rub...@unipv.it
Acked-by: Andrea Gallo andrea.ga...@stericsson.com
---
board/st/nhk8815/Makefile |5 ++-
board/st/nhk8815/keypad.c | 99
board/st/nhk8815/nhk8815-devices.h |7 +++
board/st/nhk8815/nhk8815.c |4 ++
include/configs/nhk8815.h |3 +
5 files changed, 117 insertions(+), 1 deletions(-)
create mode 100644 board/st/nhk8815/keypad.c
create mode 100644 board/st/nhk8815/nhk8815-devices.h
diff --git a/board/st/nhk8815/Makefile b/board/st/nhk8815/Makefile
index b37fe53..1bb1d2c 100644
--- a/board/st/nhk8815/Makefile
+++ b/board/st/nhk8815/Makefile
@@ -29,7 +29,10 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).a
-COBJS := nhk8815.o
+COBJS-y:= nhk8815.o
+COBJS-$(CONFIG_NHK8815_KEYPAD) += keypad.o
+
+COBJS := $(COBJS-y)
SOBJS := platform.o
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
diff --git a/board/st/nhk8815/keypad.c b/board/st/nhk8815/keypad.c
new file mode 100644
index 000..4bbcce6
--- /dev/null
+++ b/board/st/nhk8815/keypad.c
@@ -0,0 +1,99 @@
+/*
+ * board/st/nhk8815/keypad.c: keypad on nhk8815 board, based on STMPE2401
+ *
+ * Copyright 2009 Alessandro Rubini rub...@unipv.it
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+#include common.h
+#include stdio_dev.h
+#include i2c.h
+#include stmpe2401.h
+
+/*
+ * Keymap for our 4x4 matrix: since we have just
+ * a few keys, use a string for each of the keys.
+ */
+static char *keymap[4][4] = {
+ {, back, ffw, left},
+ {, tvout, playpause, right},
+ {vol-, lock, rew, up},
+ {vol+, start, ok, down}
+};
+
+/* this keeps track of the string being returned */
+static char *nextchar = ;
+
+/* This getc can return failure, not permitted in the caller */
+static int __nhk8815_getc(void)
+{
+ int row, col, res;
+
+ res = pe_kpc_getkey(STMPE0, row, col);
+ if (res 0)
+ return res; /* invalid */
+ nextchar = keymap[row][col];
+ return 0;
+}
+
+/* This is low level: may not report a valid key (a release, for example) */
+static int __nhk8815_tstc(void)
+{
+ /* the interrupt is active low */
+ int gpio = nmk_gpio_get(76);
+ return !gpio;
+}
+
+/* This is the one that is being called, it reads the pending string */
+static int nhk8815_tstc(void)
+{
+ if (*nextchar) /* there's already data */
+ return 1;
+ if (!__nhk8815_tstc()) /* no new data? */
+ return 0;
+ __nhk8815_getc(); /* get (or not) new data */
+ return (nextchar[0] != '\0');
+}
+
+/* So this is only called when there is data in the currenct string */
+static int nhk8815_getc(void)
+{
+ return *(nextchar++);
+}
+
+/* called from late init */
+int nhk8815_keypad_init(void)
+{
+ struct stdio_dev dev;
+
+ /* The keypad is on EXP0, columns 0..3, rows 0..3 */
+ pe_kpc_init(STMPE0, 0x0f, 0x0f, 30 /* ms */);
+
+ /* Keypad interrupt: GPIO76 */
+ nmk_gpio_af(76, GPIO_GPIO);
+ nmk_gpio_dir(76, 0);
+
+ memset (dev, 0, sizeof (dev));
+ dev.flags = DEV_FLAGS_INPUT;
+ dev.getc = nhk8815_getc;
+ dev.tstc = nhk8815_tstc;
+ strcpy(dev.name, keypad);
+ stdio_register(dev);
+ return 0;
+}
diff --git a/board/st/nhk8815/nhk8815-devices.h
b/board/st/nhk8815/nhk8815-devices.h
new file mode 100644
index 000..78252ed
--- /dev/null
+++ b/board/st/nhk8815/nhk8815-devices.h
@@ -0,0 +1,7 @@
+#ifndef __NHK8815_DEVICES__
+#define __NHK8815_DEVICES__
+
+/* Prototypes for functions exported by device files in this directory */
+extern int nhk8815_keypad_init(void); /* ./keypad.c */
+
+#endif /* __NHK8815_DEVICES__ */
diff --git a/board/st/nhk8815/nhk8815.c b/board/st/nhk8815/nhk8815.c
index eadce40..fbabd15 100644
--- a/board/st/nhk8815/nhk8815.c
+++ b/board/st/nhk8815/nhk8815.c
@@ -29,6 +29,7 @@
[U-Boot] [PATCH 5/7] nhk8815: start lower in RAM, so the 800x480 frame buffer fits
From: Alessandro Rubini rub...@unipv.it This simply moves u-boot to a lower address, as the frame buffer is allocated after u-boot itself in memory. Signed-off-by: Alessandro Rubini rub...@unipv.it Acked-by: Andrea Gallo andrea.ga...@stericsson.com --- board/st/nhk8815/config.mk |8 +++- 1 files changed, 3 insertions(+), 5 deletions(-) diff --git a/board/st/nhk8815/config.mk b/board/st/nhk8815/config.mk index 590393b..6e5e358 100644 --- a/board/st/nhk8815/config.mk +++ b/board/st/nhk8815/config.mk @@ -18,9 +18,7 @@ # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, # MA 02111-1307 USA -# -# -# image should be loaded at 0x0100 -# -TEXT_BASE = 0x03F8 +# Start 4MB before the end, as the frame buffer is allocate after +# u-boot. 800x480 @ 32bpp takes 1.5MB alone, so let's play safe. +TEXT_BASE = 0x03c0 -- 1.6.0.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/7] nhk8815: added lcd support
From: Alessandro Rubini rub...@unipv.it
This adds lcd support for the board. It includes defines for 32-bit
parameter as well, although support for LCD_COLOR32 is not yet in
u-boot. This uses the stmpe2401 to turn on display backlight.
Signed-off-by: Alessandro Rubini rub...@unipv.it
Acked-by: Andrea Gallo andrea.ga...@stericsson.com
---
board/st/nhk8815/Makefile |1 +
board/st/nhk8815/lcd.c | 88
board/st/nhk8815/nhk8815-devices.h |1 +
board/st/nhk8815/nhk8815.c |3 +
include/configs/nhk8815.h | 10
5 files changed, 103 insertions(+), 0 deletions(-)
create mode 100644 board/st/nhk8815/lcd.c
diff --git a/board/st/nhk8815/Makefile b/board/st/nhk8815/Makefile
index 1bb1d2c..7155f12 100644
--- a/board/st/nhk8815/Makefile
+++ b/board/st/nhk8815/Makefile
@@ -31,6 +31,7 @@ LIB = $(obj)lib$(BOARD).a
COBJS-y:= nhk8815.o
COBJS-$(CONFIG_NHK8815_KEYPAD) += keypad.o
+COBJS-$(CONFIG_LCD) += lcd.o
COBJS := $(COBJS-y)
SOBJS := platform.o
diff --git a/board/st/nhk8815/lcd.c b/board/st/nhk8815/lcd.c
new file mode 100644
index 000..d3acb48
--- /dev/null
+++ b/board/st/nhk8815/lcd.c
@@ -0,0 +1,88 @@
+/*
+ * board/st/nhk8815/lcd.c: use amba clcd and STMPE2401 for backlight/reset
+ *
+ * Copyright 2009 Alessandro Rubini rub...@unipv.it
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+#include common.h
+#include lcd.h
+#include amba_clcd.h
+#include stmpe2401.h
+
+/* Two configurations are supported: 32bpp and 16bpp */
+#if LCD_BPP == LCD_COLOR32
+# define CLCD_CNTL_VAL 0x0019182b
+# define CLCD_BPIX_VAL 5 /* 15 = 32 */
+#elif LCD_BPP == LCD_COLOR16
+# define CLCD_CNTL_VAL 0x001d1829
+# define CLCD_BPIX_VAL 4 /* 14 = 16 */
+#else
+# error Invalid LCD_BPP in config file
+#endif
+
+/* Horribly, these are precomputed registers */
+struct clcd_config nhk8815_clcd_config = {
+ .address = (struct clcd_registers *)NOMADIK_CLCDC_BASE,
+ .tim0 = 0xd52600c4, /* horizontal timings */
+ .tim1 = 0x220a01df, /* vertical timings */
+ .tim2 = 0x031f1821, /* clock and signal polarity */
+ .tim3 = 0, /* not used */
+ .cntl = CLCD_CNTL_VAL, /* control, pixel size etc */
+ .pixclock = 18*1000*1000, /* 18 MHz */
+};
+
+/* This is the panel_info for generic boards. Too little info, actually */
+vidinfo_t panel_info = {
+ .vl_col = 800,
+ .vl_row = 480,
+ .vl_bpix = CLCD_BPIX_VAL,
+ .priv = nhk8815_clcd_config,
+};
+
+/* Don't turn on (too early), but configure data lines and remove reset */
+void lcd_enable(void)
+{
+ int i;
+
+ /* Turn the alternate functions as needed */
+ for (i = 32; i = 39; i++)
+ nmk_gpio_af(i, GPIO_ALT_B);
+
+ /* EXP1_GPIO_5 = output high -- remove reset from display */
+ pe_gpio_af(STMPE1, 5, PE_GPIO_AF_GPIO);
+ pe_gpio_dir(STMPE1, 5, 1);
+ pe_gpio_set(STMPE1, 5, 1);
+}
+
+/* Called from late_init: we turn on the backlight through port expander */
+int nhk8815_backlight_on(void)
+{
+ int i;
+
+ /* Turn the alternate functions as needed */
+ for (i = 32; i = 39; i++)
+ nmk_gpio_af(i, GPIO_ALT_B);
+
+ /* EXP0_GPIO_21 = output high -- backlight */
+ pe_gpio_af(STMPE0, 21, PE_GPIO_AF_GPIO);
+ pe_gpio_dir(STMPE0, 21, 1);
+ pe_gpio_set(STMPE0, 21, 1);
+ return 0;
+}
diff --git a/board/st/nhk8815/nhk8815-devices.h
b/board/st/nhk8815/nhk8815-devices.h
index 78252ed..aec5825 100644
--- a/board/st/nhk8815/nhk8815-devices.h
+++ b/board/st/nhk8815/nhk8815-devices.h
@@ -3,5 +3,6 @@
/* Prototypes for functions exported by device files in this directory */
extern int nhk8815_keypad_init(void); /* ./keypad.c */
+extern int nhk8815_backlight_on(void); /* in ./lcd.c */
#endif /* __NHK8815_DEVICES__ */
diff --git a/board/st/nhk8815/nhk8815.c b/board/st/nhk8815/nhk8815.c
index fbabd15..fedb3c0 100644
--- a/board/st/nhk8815/nhk8815.c
[U-Boot] [PATCH 7/7] nhk8815: documented how to replace u-boot on flash
From: Alessandro Rubini rub...@unipv.it Signed-off-by: Alessandro Rubini rub...@unipv.it Acked-by: Andrea Gallo andrea.ga...@stericsson.com --- doc/README.nhk8815 | 20 1 files changed, 20 insertions(+), 0 deletions(-) diff --git a/doc/README.nhk8815 b/doc/README.nhk8815 index 9008e39..365d7e1 100644 --- a/doc/README.nhk8815 +++ b/doc/README.nhk8815 @@ -26,6 +26,26 @@ where it was loaded from, the configurations differ in where the filesystem is looked for by default. +** How to replace U-Boot with your own + +Due to the secure boot described above, The U-Boot binary isn't +expected to live at the beginning of the NAND flash but rather at +0x80800 (offset 2kB within /dev/mtd). + +To replace it with your own binary you should either use the serial +flasher the vendor distributes (there is a version running on +GNU/Linux too) or with the following commands from U-Boot. +These commands read 256kB from the are that will be /dev/mtd2 and +overwrite U-Boot at offset 2kB: + +nand read 10 8 4 +bootp 100800 u-boot-nhl8815.bin +nand erase 8 4 +nand write 10 8 4 + + +** Further documentation + On www.st.com/nomadik and on www.stnwireless.com there are documents, summary data and white papers on Nomadik. The full datasheet for STn8815 is not currently available on line but under specific request -- 1.6.0.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] mpc5121: pdm360ng: add coprocessor POST
Dear Detlev Zundel,
In message m2bpdlf50q@ohwell.denx.de you wrote:
@@ -286,6 +287,18 @@ struct post_test post_list[] =
#if CONFIG_POST CONFIG_SYS_POST_BSPEC5
CONFIG_POST_BSPEC5,
#endif
+#if CONFIG_POST CONFIG_SYS_POST_COPROC
+{
+ Coprocessors communication test,
+ coproc_com,
+ This test checks communication with coprocessors.,
+ POST_RAM | POST_ALWAYS | POST_CRITICAL,
+ pdm360ng_coprocessor_post_test,
+ NULL,
+ NULL,
+ CONFIG_SYS_POST_COPROC
+}
+#endif
};
I don't want to see board specific code (pdm360ng_*) in such a global
file. Please use a more generic approach.
Do you mean like for example CONFIG_POST_BSPEC1 used for lwmon5?
That would be possible, too. But actually the ...POST_COPROC stuff
itself looks OK to me. It's just the pdm360ng_coprocessor_post_test
part that needs to be replaced by a more generic name.
I mean, the implementations for lwmon5 and sysmon1 are not exactly
elegant either, but at least they are a bit more generic.
Anatolij, this should be straight forward.
That's what I thought, too.
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: w...@denx.de
Men will always be men -- no matter where they are.
-- Harry Mudd, Mudd's Women, stardate 1329.8
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] mpc5121: pdm360ng: add coprocessor POST
Dear Anatolij Gustschin, In message 20100415112520.3b6c3...@wker you wrote: Similar was in the first patch version. But according to Wolfgang this doesn't belong in the board config file. Eventually I did not understand the whole scope of the problem, then. In any case we should keep such common files clear of board specific stuff, and use feature specfic names instead. 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: w...@denx.de I express preference for a chronological sequence of events which precludes a violence. - Terry Pratchett, _The Dark Side of the Sun_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] mpc5121: pdm360ng: add coprocessor POST
Dear Anatolij Gustschin, In message 20100415122416.050f3...@wker you wrote: What would be a preferred way to realize this? Defining a weak function in post/post.c or post/tests.c which could be over-ridden by board specific one? Like: This would eventually indeed allow for cleaner code, but then we should also clean up the existing lwmon5 and sysmon1 code in the same way. I don't want to urge you doing that, though. For now I would also accept the code as is, just with a more generic function name. Then I have to put board specific post code in board/pdm360ng/post.c to the pdm360ng.c file back. Otherwise the board's coprocessor_post_test() function is not linked if there is no other code in this post.c file which is strongly-linked. Actually board specific POST code should go to post/board/pdm360ng/ 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: w...@denx.de Backed up the system lately? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/3] mpc5121: determine RAM size using get_ram_size()
Hello Wolfgang, On Wed, 14 Apr 2010 17:31:47 +0200 Wolfgang Denk w...@denx.de wrote: In message 1271254909-20398-2-git-send-email-ag...@denx.de you wrote: Configure 1GiB address range in DDR LAW and determine the RAM size. Fix DDR LAW afterwards. Why 1 GiB? Where is this linit coming from? It seems pretty artificial to me? It is the base address for NAND which is 0x4000 (1GiB) for all mpc512x boards in the U-Boot tree. But now I see that it is also wrong as some boards use 0x3000 for SRAM base. The upper limit is 2GiB. - u32 msize = CONFIG_SYS_DDR_SIZE * 1024 * 1024; + u32 msize = 1024 * 1024 * 1024; I'd rather see a (#define'd) constant used here, espeaically as the vlue is used again furhter doewn in the code... Will fix. u32 i; @@ -148,5 +148,10 @@ long int fixed_sdram(ddr512x_config_t *mddrc_config, out_be32(im-mddrc.ddr_time_config0, mddrc_config-ddr_time_config0); out_be32(im-mddrc.ddr_sys_config, mddrc_config-ddr_sys_config); + msize = get_ram_size(CONFIG_SYS_DDR_BASE, 0x4000); ... i. e. here. Using two different notations for the same number makes the code even hearder to read and understand. I suggest we use CONFIG_SYS_MAX_RAM_SIZE like we do in so many other boards, and leave it to the board maintainer to set a usefule default value. Ok, I will submit next patch version with this fix. Thanks! Best regards, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/3] mpc5121: add support for PDM360NG board
Hello Wolfgang, On Wed, 14 Apr 2010 17:48:40 +0200 Wolfgang Denk w...@denx.de wrote: In message 1271254909-20398-3-git-send-email-ag...@denx.de you wrote: PDM360NG is a MPC5121E based board by ifm ecomatic gmbh. ... - don't use DDR RAM size config macro, get_ram_size() is used now in fixed_sdram() to determine RAM size (see previous patch 1/3) With this change, can we then not also get rid of manually defining CONFIG_PDM360NG_BIG ? We should be able to auto-detect the configuration from the actual RAM size now, right? But another configuration for 128 MB uses different values for DDR System Configuration Register and DDR Time Config[0-2] Registers. We still need this config option. Best regards, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/3] mpc5121: add support for PDM360NG board
Hi Anatolij,
On Thursday 15 April 2010 14:32:14 Anatolij Gustschin wrote:
With this change, can we then not also get rid of manually defining
CONFIG_PDM360NG_BIG ? We should be able to auto-detect the
configuration from the actual RAM size now, right?
But another configuration for 128 MB uses different values
for DDR System Configuration Register and DDR Time Config[0-2]
Registers. We still need this config option.
On some 4xx boards, we have a similar SDRAM size auto-detection, using
different SDRAM controller setup's. It's done by first configuring the
max. size config option and testing its memory size (get_ram_size()).
If this size doesn't match the configured one (mirroring), then the next
smaller config option is used. And so on. This way we can have one binary
image supporting multiple SDRAM configurations.
I suggest you take a look at arch/ppc/cpu/ppc4xx/sdram.c:
sdram_conf_t mb0cf[] = {
{(128 20), 13, 0x000A4001}, /* (0-128MB) Address Mode 3,
13x10(4) */
{(64 20), 13, 0x00084001}, /* (0-64MB) Address Mode 3, 13x9(4)
*/
{(32 20), 12, 0x00062001}, /* (0-32MB) Address Mode 2, 12x9(4)
*/
{(16 20), 12, 0x00046001}, /* (0-16MB) Address Mode 4, 12x8(4)
*/
{(4 20), 11, 0x8001}, /* (0-4MB) Address Mode 5, 11x8(2)
*/
};
and initdram() where these struct is used.
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bad Data CRC ERROR: can't get kernel image!
Hi Detlev, I used iminfo 0xffdc and got following log Image Name: Linux-2.6.31-LE Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 936145 Bytes = 914.2 kB Load Address: Entry Point: Bad Data CRC Here i am confused that if i comment the verification of kernel header then kernel commend prompts come. so not sure about image is corrupt or not. Is there any dependency of mkimage? There was an endian problem with the CRC routine a while ago. Try updating your u-boot tree and rebuild the mkimage tool. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] net: add opencore 10/100 ethernet mac driver
This patch ports the opencore 10/100 ethernet mac driver ethoc.c from linux kernel to u-boot. Signed-off-by: Thomas Chou tho...@wytron.com.tw --- use iobase of struct eth_device. add dev_num to ethoc_initialize. drivers/net/Makefile |1 + drivers/net/ethoc.c | 511 ++ include/netdev.h |1 + 3 files changed, 513 insertions(+), 0 deletions(-) create mode 100644 drivers/net/ethoc.c diff --git a/drivers/net/Makefile b/drivers/net/Makefile index 1ec0ba1..0e68e52 100644 --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -39,6 +39,7 @@ COBJS-$(CONFIG_E1000) += e1000.o COBJS-$(CONFIG_EEPRO100) += eepro100.o COBJS-$(CONFIG_ENC28J60) += enc28j60.o COBJS-$(CONFIG_EP93XX) += ep93xx_eth.o +COBJS-$(CONFIG_ETHOC) += ethoc.o COBJS-$(CONFIG_FEC_MXC) += fec_mxc.o COBJS-$(CONFIG_FSLDMAFEC) += fsl_mcdmafec.o mcfmii.o COBJS-$(CONFIG_FTMAC100) += ftmac100.o diff --git a/drivers/net/ethoc.c b/drivers/net/ethoc.c new file mode 100644 index 000..b912e44 --- /dev/null +++ b/drivers/net/ethoc.c @@ -0,0 +1,511 @@ +/* + * Opencore 10/100 ethernet mac driver + * + * Copyright (C) 2007-2008 Avionic Design Development GmbH + * Copyright (C) 2008-2009 Avionic Design GmbH + * Thierry Reding thierry.red...@avionic-design.de + * Copyright (C) 2010 Thomas Chou tho...@wytron.com.tw + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include common.h +#include command.h +#include malloc.h +#include net.h +#include miiphy.h +#include asm/io.h +#include asm/cache.h + +/* register offsets */ +#defineMODER 0x00 +#defineINT_SOURCE 0x04 +#defineINT_MASK0x08 +#defineIPGT0x0c +#defineIPGR1 0x10 +#defineIPGR2 0x14 +#definePACKETLEN 0x18 +#defineCOLLCONF0x1c +#defineTX_BD_NUM 0x20 +#defineCTRLMODER 0x24 +#defineMIIMODER0x28 +#defineMIICOMMAND 0x2c +#defineMIIADDRESS 0x30 +#defineMIITX_DATA 0x34 +#defineMIIRX_DATA 0x38 +#defineMIISTATUS 0x3c +#defineMAC_ADDR0 0x40 +#defineMAC_ADDR1 0x44 +#defineETH_HASH0 0x48 +#defineETH_HASH1 0x4c +#defineETH_TXCTRL 0x50 + +/* mode register */ +#defineMODER_RXEN (1 0) /* receive enable */ +#defineMODER_TXEN (1 1) /* transmit enable */ +#defineMODER_NOPRE (1 2) /* no preamble */ +#defineMODER_BRO (1 3) /* broadcast address */ +#defineMODER_IAM (1 4) /* individual address mode */ +#defineMODER_PRO (1 5) /* promiscuous mode */ +#defineMODER_IFG (1 6) /* interframe gap for incoming frames */ +#defineMODER_LOOP (1 7) /* loopback */ +#defineMODER_NBO (1 8) /* no back-off */ +#defineMODER_EDE (1 9) /* excess defer enable */ +#defineMODER_FULLD (1 10) /* full duplex */ +#defineMODER_RESET (1 11) /* FIXME: reset (undocumented) */ +#defineMODER_DCRC (1 12) /* delayed CRC enable */ +#defineMODER_CRC (1 13) /* CRC enable */ +#defineMODER_HUGE (1 14) /* huge packets enable */ +#defineMODER_PAD (1 15) /* padding enabled */ +#defineMODER_RSM (1 16) /* receive small packets */ + +/* interrupt source and mask registers */ +#defineINT_MASK_TXF(1 0)/* transmit frame */ +#defineINT_MASK_TXE(1 1)/* transmit error */ +#defineINT_MASK_RXF(1 2)/* receive frame */ +#defineINT_MASK_RXE(1 3)/* receive error */ +#defineINT_MASK_BUSY (1 4) +#defineINT_MASK_TXC(1 5)/* transmit control frame */ +#defineINT_MASK_RXC(1 6)/* receive control frame */ + +#defineINT_MASK_TX (INT_MASK_TXF | INT_MASK_TXE) +#defineINT_MASK_RX (INT_MASK_RXF | INT_MASK_RXE) + +#defineINT_MASK_ALL ( \ + INT_MASK_TXF | INT_MASK_TXE | \ + INT_MASK_RXF | INT_MASK_RXE | \ + INT_MASK_TXC | INT_MASK_RXC | \ + INT_MASK_BUSY \ + ) + +/* packet length register */ +#definePACKETLEN_MIN(min) (((min) 0x) 16) +#definePACKETLEN_MAX(max) (((max) 0x) 0) +#definePACKETLEN_MIN_MAX(min, max) (PACKETLEN_MIN(min) | \ + PACKETLEN_MAX(max)) + +/* transmit buffer number register */ +#defineTX_BD_NUM_VAL(x)(((x) = 0x80) ? (x) : 0x80) + +/* control module mode register
Re: [U-Boot] [PATCH 3/5 v3] nios2: add Altera EP3C120 board
On 04/02/2010 09:33 AM, Thomas Chou wrote: This patch supports the Altera CycloneIII Nios dev board using the example FPGA design at http://nioswiki.com/Linux. This board servers as a configuration template for nios2-generic approach. Since each fpga board can have different designs, we will refer them as designs rather than boards. All designs can share the same nios2-generic board directory. To support a new design, 1. add a configuration file based on EP3C120.h. 2. include the fpga header file 3. add an entry to the NIOS2_GENERIC list in the top Makefile Signed-off-by: Thomas Choutho...@wytron.com.tw --- Please drop this patch. A nios2-generic board is fold into patch 1/5. - Thomas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] nios2: add nios2-generic board
This is a generic approach to port u-boot for nios2 boards. You may find the usage of this approach on the nioswiki, http://nioswiki.com/DasUBoot A fpga parameter file, which contains base address information and drivers declaration, is generated from Altera's hardware system description sopc file using tools. The example fpga parameter file is compatible with EP1C20, EP1S10 and EP1S40 boards. So these boards can be removed after this commit. Though epcs controller is not included to cut the dependency of altera_spi driver. Signed-off-by: Thomas Chou tho...@wytron.com.tw --- fix board_eth_init() return. add nios2-generic board template. The fpga parameter file is generated with a script at http://sopc.et.ntust.edu.tw/?p=toolchain-build.git; a=blob_plain;f=tools/sopc-create-config-files;hb=HEAD MAINTAINERS|1 + MAKEALL|1 + Makefile |6 + board/altera/nios2-generic/Makefile| 60 +++ board/altera/nios2-generic/config.mk | 32 ++ board/altera/nios2-generic/custom_fpga.h | 66 board/altera/nios2-generic/nios2-generic.c | 68 board/altera/nios2-generic/text_base.S | 21 board/altera/nios2-generic/u-boot.lds | 136 include/configs/nios2-generic.h| 153 10 files changed, 544 insertions(+), 0 deletions(-) create mode 100644 board/altera/nios2-generic/Makefile create mode 100644 board/altera/nios2-generic/config.mk create mode 100644 board/altera/nios2-generic/custom_fpga.h create mode 100644 board/altera/nios2-generic/nios2-generic.c create mode 100644 board/altera/nios2-generic/text_base.S create mode 100644 board/altera/nios2-generic/u-boot.lds create mode 100644 include/configs/nios2-generic.h diff --git a/MAINTAINERS b/MAINTAINERS index 04c8730..46e051b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -858,6 +858,7 @@ Scott McNutt smcn...@psyent.com EP1C20 Nios-II EP1S10 Nios-II EP1S40 Nios-II + nios2-generic Nios-II # # MicroBlaze Systems: # diff --git a/MAKEALL b/MAKEALL index fb1f7a3..216b89b 100755 --- a/MAKEALL +++ b/MAKEALL @@ -824,6 +824,7 @@ LIST_nios2=\ EP1S40 \ PCI5441 \ PK1C20 \ + nios2-generic \ # diff --git a/Makefile b/Makefile index 5d314c6..752f529 100644 --- a/Makefile +++ b/Makefile @@ -3538,6 +3538,12 @@ PK1C20_config : unconfig PCI5441_config : unconfig @$(MKCONFIG) PCI5441 nios2 nios2 pci5441 psyent +# nios2 generic boards +NIOS2_GENERIC = nios2-generic + +$(NIOS2_GENERIC:%=%_config) : unconfig + @$(MKCONFIG) $(@:_config=) nios2 nios2 nios2-generic altera + # ## Microblaze # diff --git a/board/altera/nios2-generic/Makefile b/board/altera/nios2-generic/Makefile new file mode 100644 index 000..2a6f69b --- /dev/null +++ b/board/altera/nios2-generic/Makefile @@ -0,0 +1,60 @@ +# +# (C) Copyright 2001-2006 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# (C) Copyright 2010, Thomas Chou tho...@wytron.com.tw +# +# 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 +ifneq ($(OBJTREE),$(SRCTREE)) +$(shell mkdir -p $(obj)../common) +endif + +LIB= $(obj)lib$(BOARD).a + +COBJS-y:= $(BOARD).o +COBJS-$(CONFIG_CMD_IDE) += ../common/cfide.o +COBJS-$(CONFIG_EPLED) += ../common/epled.o +COBJS-$(CONFIG_GPIOLED) += ../common/gpioled.o +COBJS-$(CONFIG_SEVENSEG) += ../common/sevenseg.o + +SOBJS-y:= text_base.o + +SRCS := $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS-y)) +SOBJS := $(addprefix $(obj),$(SOBJS-y)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f
Re: [U-Boot] [STATUS] Heads-up: Reorganize directory structure
please note that I have applied Peter Tyser's Reorganize directory structure patch series. This results in a massive change of the directory structure. Please make sure to sync your repsitories ASAP. Do you have any plan to move board dirs to arch folder too? Speaking for myself: I have no such plans. A closely related topic was discussed here: www.mail-archive.com/u-boot@lists.denx.de/msg20367.html The conclusion was that grouping boards by vendor as opposed to CPU type made sense so that the vendor's boards could share code and provide a common feel across their supported platforms. I can see how it'd be nice to split up boards into CPU directories, but we'd have to discuss some of the warts, like where vendor-specific code would be located if we went down that path. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/3] mpc5121: add support for PDM360NG board
Dear Anatolij Gustschin, In message 20100415143214.3e108...@wker you wrote: With this change, can we then not also get rid of manually defining CONFIG_PDM360NG_BIG ? We should be able to auto-detect the configuration from the actual RAM size now, right? But another configuration for 128 MB uses different values for DDR System Configuration Register and DDR Time Config[0-2] Registers. We still need this config option. Isn't there a way to auto-adjust these settings? On PowerPC, we routinely use get_ram_size() to test different sets of memory controller settings to auto-select the correct ones, allowing to use one single binary image for all memory configurations. 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: w...@denx.de I have never understood the female capacity to avoid a direct answer to any question. -- Spock, This Side of Paradise, stardate 3417.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Heads-up: Reorganize directory structure
I can see how it'd be nice to split up boards into CPU directories, but we'd have to discuss some of the warts, like where vendor-specific code would be located if we went down that path. Right. I can see arguments pro and con each of the approaches, and I must admit that I have no telling argument for either. My gut feeling is that I like the existing board/ approach better, but I'm open to arguments. Here a pair of arguments... Most boards are very similar to the original evaluation kit. For example, within Nomadik, code for the Calao USB-S8815 is not much different from code for the NHK8815 evaluation board. But Wolfgang refused my patch as the files are very similar; I asked how to proceed, with no reply so far. Note that both board/calao and board/st exist (board/st only has 1 board, though). Similarly, I'm working on a dave-tech.eu board series based on ep9302-ep9315. board/edb93xx exists but edb is the evaluation board; mine should be board/dave/zefeer (board/dave already exists), though very similar to edb93xx code. Hope these are arguments WD would consider. Moreover, vendors switch names often, cpu families do it rarely. /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bad Data CRC ERROR: can't get kernel image!
Hi Ronny, I used iminfo 0xffdc and got following log Image Name: Linux-2.6.31-LE Just out of curiosity - does the -LE mean that you do have a little-endian linux running on this platform? Cheers Detlev -- Those who do not understand Unix are condemned to reinvent it, poorly. - Henry Spencer, University of Toronto Unix hack -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH RFC] possible typo in atmel_lcdfb.c
This may be a typo inside the driver, but HFP is subtracted by 2 instead of 1 like the other variables in the register. This is stated in AT91SAM9263 Summary 6249HâATARMâ27-Jul-09 p. 940 HFP: Horizontal Front Porch in LCDTIM2 So the driver should also subtract 2 to achieve the correct and exptected behavior. Of cource, in this case all sources which use already this variable must be adjusted to reflect this. Kind regards, Alexander --- drivers/video/atmel_lcdfb.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c index c02ffd8..b2b7b8c 100644 --- a/drivers/video/atmel_lcdfb.c +++ b/drivers/video/atmel_lcdfb.c @@ -121,7 +121,7 @@ void lcd_ctrl_init(void *lcdbase) lcdc_writel(panel_info.mmio, ATMEL_LCDC_TIM1, value); /* Horizontal timing */ - value = (panel_info.vl_right_margin - 1) ATMEL_LCDC_HFP_OFFSET; + value = (panel_info.vl_right_margin - 2) ATMEL_LCDC_HFP_OFFSET; value |= (panel_info.vl_hsync_len - 1) ATMEL_LCDC_HPW_OFFSET; value |= (panel_info.vl_left_margin - 1); lcdc_writel(panel_info.mmio, ATMEL_LCDC_TIM2, value); -- 1.6.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Heads-up: Reorganize directory structure
Hi Alessandro, On Thu, 2010-04-15 at 17:31 +0200, Alessandro Rubini wrote: I can see how it'd be nice to split up boards into CPU directories, but we'd have to discuss some of the warts, like where vendor-specific code would be located if we went down that path. Right. I can see arguments pro and con each of the approaches, and I must admit that I have no telling argument for either. My gut feeling is that I like the existing board/ approach better, but I'm open to arguments. Here a pair of arguments... Most boards are very similar to the original evaluation kit. For example, within Nomadik, code for the Calao USB-S8815 is not much different from code for the NHK8815 evaluation board. But Wolfgang refused my patch as the files are very similar; I asked how to proceed, with no reply so far. Note that both board/calao and board/st exist (board/st only has 1 board, though). Similarly, I'm working on a dave-tech.eu board series based on ep9302-ep9315. board/edb93xx exists but edb is the evaluation board; mine should be board/dave/zefeer (board/dave already exists), though very similar to edb93xx code. Hope these are arguments WD would consider. Moreover, vendors switch names often, cpu families do it rarely. I don't follow either argument, or the name-switching argument... How does putting boards in their appropriate CPU directory make your coding any easier? And why does vendors switching names make a difference? My understanding is that currently we have: board/ $VENDOR/ $BOARDA $BOARDB Putting boards in CPU directories would result in something like: arch/ $ARCH/ cpu/ $CPU/ board/ $BOARDA $BOARDB So the contents of $BOARDA directory are nearly identical whether its located in board/... or arch/..., right? I thought we were only talking about organizational changes. Are you talking about combining multiple vendor's code into 1 file, as well as restructuring directories? Maybe an explanation of what you're envisioning would help. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Heads-up: Reorganize directory structure
Most boards are very similar to the original evaluation kit. For example, [...] Similarly, I'm working on a dave-tech.eu board series based on ep9302-ep9315. [...] I don't follow either argument, or the name-switching argument... Well, the name-switching is half a joke (but the philips 21xx is now nxp, motorola went freescale and so on). How does putting boards in their appropriate CPU directory make your coding any easier? Because if all boars with the same SoC are in the same directory they can share source files. In my example, st/nhk8815 and calao/usb-s8815 had several files replicated -- so Wolfgang rejected the patch. But in a vendor-based structure I won't merge in a single board dir boards from two different vendors. Same will happen for dave/zefeer where a lot is in commong with edb93xx. That's what the kernel is doing, actually. In arch-pxa, arch-at91 and other directories at the same level I have board file and some files that are used by several boards. Some are SoC wide, so would fit in cpu/ within u-boot, but some not (although, my fault, I'm not digging for filenames to show). I think there already is some replication in u-boot currently, but I haven't stats right now. On the other hand, having boards as subdirs of the same parent doesn't automatically make replication go away, but at least may avoid new replication in future boards thanks for your patience /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] fec_mx.c: Fix MX27 FEC logic to check validity of the MAC address in fuse
Fix MX27 FEC logic to check validity of the MAC address in fuse. Only null (empty fuse) or invalid MAC address was retrieved from mx27 fuses before this change. Signed-off-by: Eric Jarrige jora...@armadeus.org --- diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c index 8c4ade5..d7706b5 100644 --- a/drivers/net/fec_mxc.c +++ b/drivers/net/fec_mxc.c @@ -325,7 +325,7 @@ static int fec_get_hwaddr(struct eth_device *dev, unsigned char *mac) for (i = 0; i 6; i++) mac[6-1-i] = readl(iim-iim_bank_area0[IIM0_MAC + i]); - return is_valid_ether_addr(mac); + return !is_valid_ether_addr(mac); #endif } ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] POST: Added ECC memory test for mpc83xx.
On Thu, 8 Apr 2010 10:37:08 +0200
Joakim Tjernlund joakim.tjernl...@transmode.se wrote:
Kim Phillips kim.phill...@freescale.com wrote on 2010-04-08 10:27:03:
The documentation is confusing: the e300c2 has its FPU chopped off -
the FP registers are simply not there.
this is a good catch by Jocke - it would be best if generic 83xx code
didn't depend on the ppcDW* accessors.
That or one could impl. ppcDW* using normal load/store insns for 832x.
Either way the ppcDW* should be inlined as the overhead for doing
function calls isn't something you want when looking for speed.
another good point, but it seems they were added primarily for code
density benefits. I think we can do something like this in the
meantime:
From 686d3bb7a732ec36beec169c4eaf4882382d3aa2 Mon Sep 17 00:00:00 2001
From: Kim Phillips kim.phill...@freescale.com
Date: Thu, 8 Apr 2010 18:22:13 -0500
Subject: [PATCH] mpc83xx: implement ppcDW{load,store} accessors for e300c2
e300c2 core based processors (MPC832x) don't have an FPU: provide
alternative, gpr based accessor functions for code compatibility.
Suggested-by: Joakim Tjernlund joakim.tjernl...@transmode.se
Signed-off-by: Kim Phillips kim.phill...@freescale.com
---
arch/ppc/cpu/mpc83xx/start.S | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/ppc/cpu/mpc83xx/start.S b/arch/ppc/cpu/mpc83xx/start.S
index 68bb620..6bfce57 100644
--- a/arch/ppc/cpu/mpc83xx/start.S
+++ b/arch/ppc/cpu/mpc83xx/start.S
@@ -139,14 +139,28 @@ get_pvr:
.globl ppcDWstore
ppcDWstore:
+#if !defined(CONFIG_MPC832x)
lfd 1, 0(r4)
stfd1, 0(r3)
+#else
+ lwz r5, 0(r4)
+ stw r5, 0(r3)
+ lwz r5, 4(r4)
+ stw r5, 4(r3)
+#endif
blr
.globl ppcDWload
ppcDWload:
+#if !defined(CONFIG_MPC832x)
lfd 1, 0(r3)
stfd1, 0(r4)
+#else
+ lwz r5, 0(r3)
+ stw r5, 0(r4)
+ lwz r5, 4(r3)
+ stw r5, 4(r4)
+#endif
blr
#ifndef CONFIG_DEFAULT_IMMR
--
1.7.0.5
but 83xx is still missing (at least) the post_word_{load,store} functions:
post/libpost.a(post.o): In function `post_bootmode_get':
/home/kim/git/u-boot/post/post.c:107: undefined reference to `post_word_load'
post/libpost.a(post.o): In function `post_bootmode_test_on':
/home/kim/git/u-boot/post/post.c:154: undefined reference to `post_word_load'
/home/kim/git/u-boot/post/post.c:160: undefined reference to `post_word_store'
post/libpost.a(post.o): In function `post_bootmode_test_off':
/home/kim/git/u-boot/post/post.c:165: undefined reference to `post_word_load'
/home/kim/git/u-boot/post/post.c:169: undefined reference to `post_word_store'
post/libpost.a(post.o): In function `post_bootmode_init':
/home/kim/git/u-boot/post/post.c:90: undefined reference to `post_word_load'
/home/kim/git/u-boot/post/post.c:99: undefined reference to `post_word_store'
Michael, can you resubmit something more comprehensive, something that
builds for 83xx with CONFIG_POST turned on?
Kim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Fix comments for map_flash_by_law1
On Tue, 13 Apr 2010 20:59:04 -0500 Kim Phillips kim.phill...@freescale.com wrote: On Fri, 9 Apr 2010 19:06:49 +0800 Gao Ya'nan abutter@gmail.com wrote: --- cpu/mpc83xx/start.S |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) I need a signoff on both these patches. Gao, I can't commit these patches without a signoff. please read section 11 of http://lwn.net/Articles/139918/ and if you can certify the Developer's Certificate of Origin for these two patches, simply reply to this email with your Signed-off-by:, and I'll take care of the rest. Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] keymile: rework headerfiles for keymile boards
On Mon, 12 Apr 2010 09:33:14 +0200 Heiko Schocher h...@denx.de wrote: - This patch reworks all headerfiles for keymile boards (coge, supx4, eter1, suen3). Furthermore, a refactoring on the whole environment variables has been acomplished. - Environment variables: - grouped into logical blocks (#defines) based on the functionality/purpose - short description for most of the variables - as much as possible is moved into the common headerfile - Keep the kernel command line clean from KM 'specialities'. The boardId and hwKey is no longer needed as kernel arguments. They are stored in the U-Boot environment and read out from userspace later with the help of fw_printenv or equivalent tools. - km8xx: default environment partitioning corrected - Check the board id and the HW key stored in the environment with the values stored in IVM. Board id and hardware key are patched into the environment when building a keymile bootpackage. - introduces the variable initial_boot_bank to the default environment. The actual_bank is set to this value on first startup. It is normally set to 0. So the behaviour is as before. If set to != 0, the first actual_bank is set to this value as well. Thus a bootpackage can define a boot bank other than 0. Signed-off-by: Andreas Huber andreas.hu...@keymile.com Signed-off-by: Holger Brunck holger.bru...@keymile.com Signed-off-by: Heiko Schocher h...@denx.de --- since 3 of these 4 patches are in the mpc83xx domain, I went ahead and applied 1-4/4 and pushed to u-boot-mpc83xx.git. Thanks everyone, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] mpc83xx: Use CONFIG_FSL_ESDHC to enable sdhc clk
On Thu, 15 Apr 2010 16:03:05 +0200 Rini van Zetten r...@arvoo.nl wrote: Enable eSDHC Clock based on generic CONFIG_FSL_ESDHC define instead of a platform define. This will enable all the 83xx platforms to use sdhc_clk based on CONFIG_FSL_ESDHC. It's the same patch as commit 6b9ea08c5010eab5ad1056bc9bf033afb672d9cc for the ppc/85x Signed-off-by: Rini r...@arvoo.nl --- v3 : changed to new arch/ file location and mail agent issues fixed v2 : added some missed cases in the file arch/ppc/cpu/mpc83xx/speed.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/ppc/cpu/mpc83xx/speed.c b/arch/ppc/cpu/mpc83xx/speed.c index bde7e92..d9bc1ca 100644 --- a/arch/ppc/cpu/mpc83xx/speed.c +++ b/arch/ppc/cpu/mpc83xx/speed.c @@ -116,7 +116,7 @@ int get_clocks(void) #if defined(CONFIG_MPC8315) u32 tdm_clk; #endif -#if defined(CONFIG_MPC837x) +#if defined(ONFIG_FSL_ESDHC) applied and pushed to u-boot-mpc83xx after fixing up s/(ONFIG/(CONFIG/g. Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] mpc83xx: use A nomenclature only on mpc834x and mpc836x families
marketing didn't extend their postpend-with-an-A naming strategy on rev.2's and higher beyond the first two 83xx families. This patch stops us from misreporting we're running e.g., on an MPC8313EA, when such a name doesn't exist. Signed-off-by: Kim Phillips kim.phill...@freescale.com --- arch/ppc/cpu/mpc83xx/cpu.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/ppc/cpu/mpc83xx/cpu.c b/arch/ppc/cpu/mpc83xx/cpu.c index 5ca6f83..01129d3 100644 --- a/arch/ppc/cpu/mpc83xx/cpu.c +++ b/arch/ppc/cpu/mpc83xx/cpu.c @@ -106,7 +106,9 @@ int checkcpu(void) puts(cpu_type_list[i].name); if (IS_E_PROCESSOR(spridr)) puts(E); - if (REVID_MAJOR(spridr) = 2) + if ((SPR_FAMILY(spridr) == SPR_834X_FAMILY || +SPR_FAMILY(spridr) == SPR_836X_FAMILY) + REVID_MAJOR(spridr) = 2) puts(A); printf(, Rev: %d.%d, REVID_MAJOR(spridr), REVID_MINOR(spridr)); -- 1.7.0.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] mpc83xx: enable command line autocompletion
because it's convenient. Signed-off-by: Kim Phillips kim.phill...@freescale.com --- include/configs/MPC8313ERDB.h |2 +- include/configs/MPC8315ERDB.h |1 + include/configs/MPC8323ERDB.h |1 + include/configs/MPC832XEMDS.h |1 + include/configs/MPC8349EMDS.h |1 + include/configs/MPC8349ITX.h |3 ++- include/configs/MPC8360EMDS.h |1 + include/configs/MPC8360ERDK.h |1 + include/configs/MPC837XEMDS.h |1 + include/configs/MPC837XERDB.h |1 + include/configs/MVBLM7.h |1 + include/configs/SIMPC8313.h |2 +- include/configs/TQM834x.h |2 ++ include/configs/sbc8349.h |1 + include/configs/vme8349.h |1 + 15 files changed, 17 insertions(+), 3 deletions(-) diff --git a/include/configs/MPC8313ERDB.h b/include/configs/MPC8313ERDB.h index 1478ec8..a2e4cd4 100644 --- a/include/configs/MPC8313ERDB.h +++ b/include/configs/MPC8313ERDB.h @@ -435,7 +435,7 @@ #endif #define CONFIG_CMDLINE_EDITING 1 - +#define CONFIG_AUTO_COMPLETE /* add autocompletion support */ /* * Miscellaneous configurable options diff --git a/include/configs/MPC8315ERDB.h b/include/configs/MPC8315ERDB.h index a8570ce..b106aa9 100644 --- a/include/configs/MPC8315ERDB.h +++ b/include/configs/MPC8315ERDB.h @@ -504,6 +504,7 @@ #endif #define CONFIG_CMDLINE_EDITING 1 /* add command line history */ +#define CONFIG_AUTO_COMPLETE /* add autocompletion support */ #undef CONFIG_WATCHDOG /* watchdog disabled */ diff --git a/include/configs/MPC8323ERDB.h b/include/configs/MPC8323ERDB.h index 4046f80..50aea79 100644 --- a/include/configs/MPC8323ERDB.h +++ b/include/configs/MPC8323ERDB.h @@ -275,6 +275,7 @@ #define CONFIG_SYS_NS16550_COM2(CONFIG_SYS_IMMR+0x4600) #define CONFIG_CMDLINE_EDITING 1 /* add command line history */ +#define CONFIG_AUTO_COMPLETE /* add autocompletion support */ /* Use the HUSH parser */ #define CONFIG_SYS_HUSH_PARSER #ifdef CONFIG_SYS_HUSH_PARSER diff --git a/include/configs/MPC832XEMDS.h b/include/configs/MPC832XEMDS.h index 2ad5f60..f7632e0 100644 --- a/include/configs/MPC832XEMDS.h +++ b/include/configs/MPC832XEMDS.h @@ -286,6 +286,7 @@ #define CONFIG_SYS_NS16550_COM2(CONFIG_SYS_IMMR+0x4600) #define CONFIG_CMDLINE_EDITING 1 /* add command line history */ +#define CONFIG_AUTO_COMPLETE /* add autocompletion support */ /* Use the HUSH parser */ #define CONFIG_SYS_HUSH_PARSER #ifdef CONFIG_SYS_HUSH_PARSER diff --git a/include/configs/MPC8349EMDS.h b/include/configs/MPC8349EMDS.h index bf28d9e..5c410c9 100644 --- a/include/configs/MPC8349EMDS.h +++ b/include/configs/MPC8349EMDS.h @@ -296,6 +296,7 @@ #define CONFIG_SYS_NS16550_COM2(CONFIG_SYS_IMMR+0x4600) #define CONFIG_CMDLINE_EDITING 1 /* add command line history */ +#define CONFIG_AUTO_COMPLETE /* add autocompletion support */ /* Use the HUSH parser */ #define CONFIG_SYS_HUSH_PARSER #ifdef CONFIG_SYS_HUSH_PARSER diff --git a/include/configs/MPC8349ITX.h b/include/configs/MPC8349ITX.h index 52e2851..09f9e38 100644 --- a/include/configs/MPC8349ITX.h +++ b/include/configs/MPC8349ITX.h @@ -511,7 +511,8 @@ boards, we say we have two, but don't display a message if we find only one. */ * Miscellaneous configurable options */ #define CONFIG_SYS_LONGHELP/* undef to save memory */ -#define CONFIG_CMDLINE_EDITING /* Command-line editing */ +#define CONFIG_CMDLINE_EDITING /* Command-line editing */ +#define CONFIG_AUTO_COMPLETE /* add autocompletion support */ #define CONFIG_SYS_HUSH_PARSER /* Use the HUSH parser */ #define CONFIG_SYS_PROMPT_HUSH_PS2 diff --git a/include/configs/MPC8360EMDS.h b/include/configs/MPC8360EMDS.h index b9b5eab..620e32c 100644 --- a/include/configs/MPC8360EMDS.h +++ b/include/configs/MPC8360EMDS.h @@ -320,6 +320,7 @@ #define CONFIG_SYS_NS16550_COM2(CONFIG_SYS_IMMR+0x4600) #define CONFIG_CMDLINE_EDITING 1 /* add command line history */ +#define CONFIG_AUTO_COMPLETE /* add autocompletion support */ /* Use the HUSH parser */ #define CONFIG_SYS_HUSH_PARSER #ifdef CONFIG_SYS_HUSH_PARSER diff --git a/include/configs/MPC8360ERDK.h b/include/configs/MPC8360ERDK.h index c7bc9cd..a43e465 100644 --- a/include/configs/MPC8360ERDK.h +++ b/include/configs/MPC8360ERDK.h @@ -250,6 +250,7 @@ #define CONFIG_SYS_NS16550_COM2(CONFIG_SYS_IMMR+0x4600) #define CONFIG_CMDLINE_EDITING 1 /* add command line history */ +#define CONFIG_AUTO_COMPLETE /* add autocompletion support */ /* Use the HUSH parser */ #define CONFIG_SYS_HUSH_PARSER #ifdef CONFIG_SYS_HUSH_PARSER diff --git a/include/configs/MPC837XEMDS.h b/include/configs/MPC837XEMDS.h index 65d49ec..1565ff9 100644 --- a/include/configs/MPC837XEMDS.h +++ b/include/configs/MPC837XEMDS.h @@ -500,6 +500,7 @@ extern int board_pci_host_broken(void); #endif
[U-Boot] [PATCH 3/3] mpc83xx: turn on icache in core initialization to improve u-boot boot time
before, MPC8349ITX boots u-boot in 4.3sec: column1 is elapsed time since first message column2 is elapsed time since previous message column3 is the message 0.000 0.000: U-Boot 2010.03-00126-gfd4e49c (Apr 11 2010 - 17:25:29) MPC83XX 0.000 0.000: 0.000 0.000: Reset Status: 0.000 0.000: 0.032 0.032: CPU: e300c1, MPC8349E, Rev: 1.1 at 533.333 MHz, CSB: 266.667 MHz 0.032 0.000: Board: Freescale MPC8349E-mITX 0.032 0.000: UPMA: Configured for compact flash 0.032 0.000: I2C: ready 0.061 0.028: DRAM: 256 MB (DDR1, 64-bit, ECC off, 266.667 MHz) 1.516 1.456: FLASH: 16 MB 2.641 1.125: PCI: Bus Dev VenId DevId Class Int 2.652 0.011: 00 10 1095 3114 0180 00 2.652 0.000: PCI: Bus Dev VenId DevId Class Int 2.652 0.000: In:serial 2.652 0.000: Out: serial 2.652 0.000: Err: serial 2.682 0.030: Board revision: 1.0 (PCF8475A) 3.080 0.398: Net: TSEC1: No support for PHY id ; assuming generic 3.080 0.000: TSEC0, TSEC1 4.300 1.219: IDE: Bus 0: .** Timeout ** after, MPC8349ITX boots u-boot in 3.0sec: 0.010 0.010: U-Boot 2010.03-00127-g4b468cc-dirty (Apr 11 2010 - 17:47:29) MPC83XX 0.010 0.000: 0.010 0.000: Reset Status: 0.010 0.000: 0.017 0.007: CPU: e300c1, MPC8349E, Rev: 1.1 at 533.333 MHz, CSB: 266.667 MHz 0.017 0.000: Board: Freescale MPC8349E-mITX 0.038 0.020: UPMA: Configured for compact flash 0.038 0.000: I2C: ready 0.038 0.000: DRAM: 256 MB (DDR1, 64-bit, ECC off, 266.667 MHz) 0.260 0.222: FLASH: 16 MB 1.390 1.130: PCI: Bus Dev VenId DevId Class Int 1.390 0.000: 00 10 1095 3114 0180 00 1.390 0.000: PCI: Bus Dev VenId DevId Class Int 1.400 0.010: In:serial 1.400 0.000: Out: serial 1.400 0.000: Err: serial 1.400 0.000: Board revision: 1.0 (PCF8475A) 1.832 0.432: Net: TSEC1: No support for PHY id ; assuming generic 1.832 0.000: TSEC0, TSEC1 3.038 1.205: IDE: Bus 0: .** Timeout ** also tested on these boards (albeit with a less accurate boottime measurement method): seconds: before after 8349MDS ~2.6~2.2 8360MDS ~2.8~2.6 8313RDB ~2.5~2.3 #nand boot 837xRDB ~3.1~2.3 also tested on an 8323ERDB. Signed-off-by: Kim Phillips kim.phill...@freescale.com --- please test! include/configs/MPC8313ERDB.h |3 ++- include/configs/MPC8315ERDB.h |5 +++-- include/configs/MPC8323ERDB.h |5 +++-- include/configs/MPC832XEMDS.h |5 +++-- include/configs/MPC8349EMDS.h |3 ++- include/configs/MPC8360EMDS.h |5 +++-- include/configs/MPC8360ERDK.h |5 +++-- include/configs/MPC837XEMDS.h |5 +++-- include/configs/MPC837XERDB.h |5 +++-- include/configs/MVBLM7.h|3 ++- include/configs/SIMPC8313.h |5 +++-- include/configs/TQM834x.h |3 ++- include/configs/km83xx-common.h |3 ++- include/configs/sbc8349.h |3 ++- include/configs/vme8349.h |3 ++- 15 files changed, 38 insertions(+), 23 deletions(-) diff --git a/include/configs/MPC8313ERDB.h b/include/configs/MPC8313ERDB.h index a2e4cd4..94695fc 100644 --- a/include/configs/MPC8313ERDB.h +++ b/include/configs/MPC8313ERDB.h @@ -517,7 +517,8 @@ #define CONFIG_SYS_HID0_INIT 0x0 #define CONFIG_SYS_HID0_FINAL (HID0_ENABLE_MACHINE_CHECK | \ -HID0_ENABLE_DYNAMIC_POWER_MANAGMENT) +HID0_ENABLE_INSTRUCTION_CACHE | \ +HID0_ENABLE_DYNAMIC_POWER_MANAGMENT) #define CONFIG_SYS_HID2 HID2_HBE diff --git a/include/configs/MPC8315ERDB.h b/include/configs/MPC8315ERDB.h index b106aa9..6972fe8 100644 --- a/include/configs/MPC8315ERDB.h +++ b/include/configs/MPC8315ERDB.h @@ -536,8 +536,9 @@ /* * Core HID Setup */ -#define CONFIG_SYS_HID0_INIT 0x0 -#define CONFIG_SYS_HID0_FINAL (HID0_ENABLE_MACHINE_CHECK | \ +#define CONFIG_SYS_HID0_INIT 0x0 +#define CONFIG_SYS_HID0_FINAL (HID0_ENABLE_MACHINE_CHECK | \ +HID0_ENABLE_INSTRUCTION_CACHE | \ HID0_ENABLE_DYNAMIC_POWER_MANAGMENT) #define CONFIG_SYS_HID2HID2_HBE diff --git a/include/configs/MPC8323ERDB.h b/include/configs/MPC8323ERDB.h index 50aea79..7c84393 100644 --- a/include/configs/MPC8323ERDB.h +++ b/include/configs/MPC8323ERDB.h @@ -438,8 +438,9 @@ /* * Core HID Setup */ -#define CONFIG_SYS_HID0_INIT 0x0 -#define CONFIG_SYS_HID0_FINAL HID0_ENABLE_MACHINE_CHECK +#define CONFIG_SYS_HID0_INIT 0x0 +#define CONFIG_SYS_HID0_FINAL (HID0_ENABLE_MACHINE_CHECK | \ +HID0_ENABLE_INSTRUCTION_CACHE) #define CONFIG_SYS_HID2HID2_HBE /* diff --git a/include/configs/MPC832XEMDS.h b/include/configs/MPC832XEMDS.h index f7632e0..7bd2793 100644 --- a/include/configs/MPC832XEMDS.h +++ b/include/configs/MPC832XEMDS.h @@ -455,8 +455,9 @@ /* * Core HID Setup */ -#define CONFIG_SYS_HID0_INIT 0x0 -#define
Re: [U-Boot] [STATUS] Heads-up: Reorganize directory structure
Hi Alessandro, snip How does putting boards in their appropriate CPU directory make your coding any easier? Because if all boars with the same SoC are in the same directory they can share source files. But boards don't need to be in the same directory to share the same source files. You could pull out common code to arch/arm/cpu/* or arch/arm/lib right now if you wanted, but that is the case whether the board directories were in board/... or arch/ In my example, st/nhk8815 and calao/usb-s8815 had several files replicated -- so Wolfgang rejected the patch. But in a vendor-based structure I won't merge in a single board dir boards from two different vendors. Same will happen for dave/zefeer where a lot is in commong with edb93xx. Could you give a specific example of how you'd like to final directory/file structure to look like? eg where would the code common to the nhk8815 and usb-s8815 be located? What would the file(s) be named? And how would the issue of vendors like Freescale which support multiple architectures and share code between them be supported? snip thanks for your patience Likewise:) Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Heads-up: Reorganize directory structure
Dear Alessandro, In message 20100415153127.ga...@morgana.gnudd.com you wrote: My gut feeling is that I like the existing board/ approach better, but I'm open to arguments. Here a pair of arguments... Most boards are very similar to the original evaluation kit. For Some boards are different, others arent. I would not dare to say which group is bigger. In most cases the eval kit is something you don't really want to replicate in your own design if you know what you are doing. example, within Nomadik, code for the Calao USB-S8815 is not much different from code for the NHK8815 evaluation board. But Wolfgang refused my patch as the files are very similar; I asked how to proceed, with no reply so far. Note that both board/calao and board/st exist (board/st only has 1 board, though). Sorry if you are waiting for a reply guess I missed that. But what could I say in such a situation? That it makes sense to factor out common code, of course. Similarly, I'm working on a dave-tech.eu board series based on ep9302-ep9315. board/edb93xx exists but edb is the evaluation board; mine should be board/dave/zefeer (board/dave already exists), though very similar to edb93xx code. I'm afraid I don't understand what you want to tell me, what the problem actually is, or why it would be solved by moving to beoards into arch/cpu/ ? Hope these are arguments WD would consider. Moreover, vendors switch names often, cpu families do it rarely. Once a name was chosen, it is permanent. I haven't seen any significant number of name changes in the whole history of PPCBoot and U-Boot. And I don't see how this is relevant to the location in board/ or arch/cpu/ ? 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: w...@denx.de Question: How does one get fresh air into a Russian church? Answer: One clicks on an icon, and a window opens! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Heads-up: Reorganize directory structure
On Fri, Apr 16, 2010 at 1:58 AM, Peter Tyser pty...@xes-inc.com wrote: Hi Alessandro, On Thu, 2010-04-15 at 17:31 +0200, Alessandro Rubini wrote: I can see how it'd be nice to split up boards into CPU directories, but we'd have to discuss some of the warts, like where vendor-specific code would be located if we went down that path. Right. I can see arguments pro and con each of the approaches, and I must admit that I have no telling argument for either. My gut feeling is that I like the existing board/ approach better, but I'm open to arguments. My understanding is that currently we have: board/ $VENDOR/ $BOARDA $BOARDB Almost - it is more like board/ $VENDOR/ include/ common/ lib(?)/ etc../ $BOARDA/ $BOARDB/ I really like this structure, particularly if the code under $VENDOR/[common, include, lib] is arch independent. If a vendor develops a new board using a different CPU or SOC they can easily re-use all their pre-existing platform independent code for the new board. Maybe we should look at moving CPU SOC specific code from board/$VENDOR into arch/ which will probably consolidate a lot of common code loitering around in the various board directories. And then there is also board/ $BOARDC $BOARDD I've never liked code existing on multiple depths like this. Maybe we move towards: board/ $VENDOR include/ lib/ $BOARDA/ $BOARDB/ $cpu_generic/ $BOARDC/ $BOARDD/ Any code that would otherwise live under $cpu_generic/[include, lib] should (by definition) be moved to arch/$cpu/[include, lib] Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bad Data CRC ERROR: can't get kernel image!
Yes i am running little endian kernel, but this error comes in both little as well as big endian kernel. --- On Thu, 15/4/10, Detlev Zundel d...@denx.de wrote: From: Detlev Zundel d...@denx.de Subject: Re: [U-Boot] Bad Data CRC ERROR: can't get kernel image! To: Ronny D ronny_...@yahoo.com Cc: U-boot u-boot@lists.denx.de Date: Thursday, 15 April, 2010, 3:37 PM Hi Ronny, I used iminfo 0xffdc and got following log Image Name: Linux-2.6.31-LE Just out of curiosity - does the -LE mean that you do have a little-endian linux running on this platform? Cheers Detlev -- Those who do not understand Unix are condemned to reinvent it, poorly. - Henry Spencer, University of Toronto Unix hack -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de Send free SMS to your Friends on Mobile from your Yahoo! Messenger. Download Now! http://messenger.yahoo.com/download.php___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
