Re: [U-Boot] AT91 Rework
Dear Wolfgang Denk, Umm... you are quite active for AT91 now - the position of the AT91 is still orphaned; did you ever think about volunteering? At the moment I'm work for different AT91 (AT91RM9200, AT91SAM9260 and AT91SAM9360) in timeslot mode. But I am fully costumer driven, so that it can be, i must switch to complette a other system like PIC and so on or back to windows. I recomment to make this u32 instead of ulong. I will replace this. again, please drop at least the parens and the casts. It will be removed Best regards, Jens Scharsig ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Save environment data to mmc.
Dear Terry Lv,
In message 12574070132761-git-send-email-r65...@freescale.com you wrote:
This patch is to save environment data to mmc card.
It uses interfaces defined in generic mmc.
...
+ if (!crc1_ok !crc2_ok)
+ gd-env_valid = 0;
+ else if (crc1_ok !crc2_ok)
+ gd-env_valid = 1;
+ else if (!crc1_ok crc2_ok)
+ gd-env_valid = 2;
+ else {
+ /* both ok - check serial */
+ if (tmp_env1-flags == 255 tmp_env2-flags == 0)
+ gd-env_valid = 2;
+ else if (tmp_env2-flags == 255 tmp_env1-flags == 0)
+ gd-env_valid = 1;
+ else if (tmp_env1-flags tmp_env2-flags)
+ gd-env_valid = 1;
+ else if (tmp_env2-flags tmp_env1-flags)
+ gd-env_valid = 2;
+ else /* flags are equal - almost impossible */
+ gd-env_valid = 1;
+ }
Please check if this logic is really working on MMC - do you really erase
(i. e. fill with 0xFF bytes) the data blocks when erasing?
...
+ if (!mmc) {
+ puts(No MMC card found\n);
+ return;
+ }
+
+ if (mmc_init(mmc)) {
+ puts(MMC init failed\n);
+ return 1;
+ }
This code repeats a number of times. Make it a (inline?) function?
+ tmp_env1 = (env_t *)malloc(CONFIG_ENV_SIZE);
+ if (!tmp_env1) {
+ puts(Not enough memory!\n);
+ goto use_default;
+ }
Please print where we are, and how many bytes you attempted to
allocate.
+ if (!tmp_env2) {
+ puts(Not enough memory!\n);
+ goto use_default;
+ }
Ditto . Again - repeated code!
--- a/include/environment.h
+++ b/include/environment.h
@@ -94,6 +94,24 @@
# endif
#endif /* CONFIG_ENV_IS_IN_MG_DISK */
+#if defined(CONFIG_ENV_IS_IN_MMC)
+# ifndef CONFIG_ENV_OFFSET
+# error Need to define CONFIG_ENV_OFFSET when using CONFIG_ENV_IS_IN_MMC
+# endif
+# ifndef CONFIG_ENV_ADDR
+# define CONFIG_ENV_ADDR(CONFIG_ENV_OFFSET)
+# endif
+# ifndef CONFIG_ENV_OFFSET
+# define CONFIG_ENV_OFFSET (CONFIG_ENV_ADDR)
+# endif
+# ifdef CONFIG_ENV_OFFSET_REDUND
+# define CONFIG_SYS_REDUNDAND_ENVIRONMENT
+# endif
+# ifdef CONFIG_ENV_IS_EMBEDDED
+# define ENV_IS_EMBEDDED1
+# endif
+#endif /* CONFIG_ENV_IS_IN_MMC */
Does this make sense on MMC?
Would it not be better to define block numbers instead?
+#ifdef CONFIG_GENERIC_MMC
+puts (MMC: );
+mmc_initialize (gd-bd);
+#endif
Indentation by TABs, please.
Are you sure movin the MMC initialization here has no negative impact
on any of the existing boards?
--- a/lib_ppc/board.c
+++ b/lib_ppc/board.c
@@ -776,6 +776,12 @@ void board_init_r (gd_t *id, ulong dest_addr)
nand_init();/* go init the NAND */
#endif
+#ifdef CONFIG_GENERIC_MMC
+WATCHDOG_RESET ();
+puts (MMC: );
+mmc_initialize (bd);
+#endif
Ditto, for both remarks.
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
The only way you could make a happy marriage is by cuttin' their
heads off as soon as they say `I do', yes? You can't make happi-
ness... - Terry Pratchett, _Witches Abroad_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] env: Group environment variables
Dear John, In message 1257352452-11748-1-git-send-email-jschmol...@xes-inc.com you wrote: This patch groups environment variables using a non-invasive protocol. Grouping is achieved by setting a grouping variable to a string of variables, and setting the master grouping variable, env_groups to the list of these grouping variables. For instance, setenv net ipaddr netmask gatewayip serverip setenv boot bootcmd bootdelay bootargs setenv env_groups net boot would print 4 variables grouped under net, 3 variables grouped under boot, and the rest of the variables grouped under other. If env_groups is not defined, print behaves normally. First of all: thanks for the patch. I'm interesetd in seeing peoples opinions of this implementation of grouping environment variables. My major concerns about this implementation are I have to admit that I did not actually test the code yet. I just read it a bit... 1) Using parse_line() requires placing several potentially large char array (CONFIG_SYS_CBSIZE in size) on the stack. Parse_line() does seem to be the right tool for the job, though. I am not sure about this. Keep in mind that parse_line() processes a maximum of CONFIG_SYS_MAXARGS arguments only, which on most boards is only 16 (and on some boards even less). 2) Trying to figure out which enviroment variables have already been printed in groups is less than elegant. Currently, it's a brute-force approach of looking through every entry until a variable is found in a group or not. Suggestions for cleaner algorithms here would be appreciated. The repeated scanning and comparing doesn't make much sense to me. Probably it makes more sense to use a more suitable data structure here. How about performing a linear scan of the environment only once and convert it into a more easily processable data structure, say a hash table or a binary tree or whatever, and then operate on this. Here you can easily add additional flags like a pointer which group the variable belongs to (if any). Also, this would make it easier for example to print a sorted list. Eventually we should _always_ do that, i. e. replace the standard copy operation as done in env_relocate*() by a function that not only copies the environment, but converts it into a new internal representation. This might be beneficial to accelerate access to variables, too. = print only a list of groups If env_groups is defined, none of the grouping variables will be printed. This seemed to clutter up the printenv output. I don't think this is a wise decision. Having magic variables which cannot be seen an idea I dislike. I think the standard printenv (without args) should print the grouping variables as first block. Also, it would be nice if prontenv now would allow to print a group, i. e. in your example something as printenv net pci should be supported. Grouping environment variables will almost certainly lead to a reqirement for bumping up CONFIG_SYS_MAXARGS. ...which raises the question why there is such a static limit in the first place. Yes, it was trivial to implement, but maybe this can be improved? Artificial limits on line lengths and numbers of arguments are a nice thing - to remove :-) 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 The question of whether a computer can think is no more interesting than the question of whether a submarine can swim - Edsgar W. Dijkstra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request - mpc85xx (for 200911 release) (updated)
Dear Kumar Gala, In message pine.lnx.4.64.0911041804320.16...@localhost.localdomain you wrote: Added two trivial patches in The following changes since commit b91b8f74fe9ded18344c3d03080a4abc07254502: Wolfgang Denk (1): Merge branch 'master' of /home/wd/git/u-boot/custodians are available in the git repository at: git://git.denx.de/u-boot-mpc85xx master Becky Bruce (1): 86xx: Remove redundant code in initdram Dave Liu (1): ppc/85xx: Fix misc L2 cache enabling bug Ed Swarthout (1): fsl_pci_init_port end-point initialization is broken Kumar Gala (2): Revert ppc/85xx/pci: fsl_pci_init: pcie agent mode support ppc/85xx: Fix inclusion of 83xx immap in 85xx builds board/freescale/mpc8572ds/mpc8572ds.c |6 ++-- board/freescale/mpc8610hpcd/mpc8610hpcd.c |5 board/freescale/mpc8641hpcn/mpc8641hpcn.c |5 board/freescale/p1_p2_rdb/pci.c |4 +- board/freescale/p2020ds/p2020ds.c |6 ++-- board/sbc8548/sbc8548.c |4 +- board/sbc8641d/sbc8641d.c |5 cpu/mpc85xx/release.S | 12 +++--- drivers/pci/fsl_pci_init.c| 32 +++- include/asm-ppc/fsl_pci.h |4 +- nand_spl/nand_boot_fsl_elbc.c |5 11 files changed, 42 insertions(+), 46 deletions(-) Applied, thanks. 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 A Puritan is someone who is deathly afraid that someone, somewhere, is having fun. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] use boot selecr jumper on NGW100 to select USART
Dear Thomas Sprinkmeier,
In message e355f1140911041955q1adf2c1fp75375e4b98cfd...@mail.gmail.com you
wrote:
Without the boot select jumper U-Boot will use the USART selected
using the CONFIG_USART1, CONFIG_USART2, directive.
Please fix the typo in the Subject:
If CONFIG_ALT_USART1 (or ..2, ..3, ..0) is defined then,
with the jumper in place, that USART is used instead.
Signed-off-by: Thomas Sprinkmeier thomas.sprinkme...@gmail.com
---
board/atmel/atngw100/atngw100.c | 40
drivers/serial/atmel_usart.c| 54
++-
drivers/serial/atmel_usart.h|9 +++---
include/configs/atngw100.h |1 +
4 files changed, 98 insertions(+), 6 deletions(-)
diff --git a/board/atmel/atngw100/atngw100.c b/board/atmel/atngw100/atngw100.c
index 004d8da..a2ffdb4 100644
--- a/board/atmel/atngw100/atngw100.c
+++ b/board/atmel/atngw100/atngw100.c
@@ -53,7 +53,47 @@ int board_early_init_f(void)
hmatrix_slave_write(EBI, SFR, HMATRIX_BIT(EBI_SDRAM_ENABLE));
portmux_enable_ebi(16, 23, 0, PORTMUX_DRIVE_HIGH);
+
+#if defined(CONFIG_ALT_USART0) || defined(CONFIG_ALT_USART1) || \
+defined(CONFIG_ALT_USART2) || defined(CONFIG_ALT_USART3)
+#define USART_USE_ALT (!gpio_get_value(GPIO_PIN_PB(30)))
Your patch is white space corrupted. All original indentation was by
TABs, but in your patch it's all spaces.
+ /* PB30, the 'boot' jumper with external pull-up resistor */
+ /* PORTMUX_DIR_INPUT == 0 as high-impedance input is the default
state.
+ In other words, I don't think this actually does anything... */
Incorrect multiline comment style. Please fix globally.
+ if (USART_USE_ALT) {
+#if defined(CONFIG_ALT_USART0)
+ portmux_enable_usart0(PORTMUX_DRIVE_MIN);
+#elif defined(CONFIG_ALT_USART1)
+ portmux_enable_usart1(PORTMUX_DRIVE_MIN);
+#elif defined(CONFIG_ALT_USART2)
+ portmux_enable_usart2(PORTMUX_DRIVE_MIN);
+#elif defined(CONFIG_ALT_USART3)
+ portmux_enable_usart3(PORTMUX_DRIVE_MIN);
+#endif
Incorrect indentation. Please fix globally.
+ } else {
+#endif
+#if defined(CONFIG_USART0)
+ portmux_enable_usart0(PORTMUX_DRIVE_MIN);
+#elif defined(CONFIG_USART1)
portmux_enable_usart1(PORTMUX_DRIVE_MIN);
+#elif defined(CONFIG_USART2)
+ portmux_enable_usart2(PORTMUX_DRIVE_MIN);
+#elif defined(CONFIG_USART3)
+ portmux_enable_usart3(PORTMUX_DRIVE_MIN);
+#else
If only one CONFIG_USARTx is allowed, you should think opf a way to
get rid of these long, repeated #if...#elif...#elif constructs.
-/* Register access macros */
-#define usart3_readl(reg) \
- readl((void *)USART_BASE + USART3_##reg)
-#define usart3_writel(reg,value) \
- writel((value), (void *)USART_BASE + USART3_##reg)
+int atmel_serial_read(int reg);
+void atmel_serial_write(int reg, int value);
+#define usart3_readl(reg) atmel_serial_read(USART3_##reg)
+#define usart3_writel(reg, value) atmel_serial_write(USART3_##reg, value)
Instead of making code more AT91 specific, we should try the opposite:
make it _less_ so.
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 really hate this damned machine It never does quite what I want
I wish that they would sell it. But only what I tell it.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AT91 Rework
Dear Jens Scharsig, In message 4af1d190.1010...@scharsoft.de you wrote: We discussed the AT91 defs replaced by C structures. I have checked the AT91 and the AT91RM9200 tree. I have planned the following procedure: 1. Add the CONFIG_AT_LEGACY to all affected boards (until the board is updated) 2. Put an warinig to all files that use old defs 3. enclose the old def's with #ifdef CONFIG_AT_LEGACY 4. Add new C stuctures to header files 5. update affected common and driver files 6. next steps t.b.d THis sounds good to me. An additional aim of the revision should be the union of the AT91 and AT91RM9200 tree. Some part like UART, SPI; PIO and so one are the same. Only a lot of devices like MAC are different. But I can't see, when this work will be done. I understand this. Let's focus on what you can do now. Evey bit of improvement is highly welcome. 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 Never face facts; if you do, you'll never get up in the morning. - Marlo Thomas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] v2 Linuxstamp II 9260 support
Dear Paul Thomas, In message c785bba30911042010w6ed4756ep3ee349dd79f0c...@mail.gmail.com you wrote: I have looked at about half of them. It looks like partition tables are identical. Right, and such duplication should be avoided. I am interested in a way to generalize this file and move it to the cpu layer so all the common or nearly common files can be reduced to 1 file Me too. This structure in partition.c is board specific not cpu specific. Even if all the current boards are exactly the same there would need to be a way someone could change this in the future without breaking other boards. In could be in the .c or .h file if that would make is Agreed. But as it is, most boards do use the same default settings. So please let us provide a common default, which can be used where it fits (which seems to be the majority of systems) and overwritten where it doesn't fit. 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 As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. -- Albert Einstein ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ARM: fix build error with gcc-4.4.2 about inline function declared weak
Dear Tom Rix, In message 1257292804-10612-3-git-send-email-tom@windriver.com you wrote: From: Abdoulaye Walsimou Gaye walsi...@walsimou.com This patch fix build error with gcc-4.4.2 about inline function declared weak, see below: board.c:96: error: inline function 'coloured_LED_init' cannot be declared weak board.c:98: error: inline function 'red_LED_on' cannot be declared weak board.c:100: error: inline function 'red_LED_off' cannot be declared weak board.c:102: error: inline function 'green_LED_on' cannot be declared weak board.c:104: error: inline function 'green_LED_off' cannot be declared weak board.c:106: error: inline function 'yellow_LED_on' cannot be declared weak board.c:108: error: inline function 'yellow_LED_off' cannot be declared weak board.c:110: error: inline function 'blue_LED_on' cannot be declared weak board.c:112: error: inline function 'blue_LED_off' cannot be declared weak make[1]: *** [board.o] Error 1 Signed-off-by: Abdoulaye Walsimou Gaye walsi...@walsimou.com What is this? Are you sure this patch is properly attributed? Was Abdoulaye Walsimou Gaye really the first to submit this patch? 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 Quote from a recent meeting: We are going to continue having these meetings everyday until I find out why no work is getting done. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ARM Conditionally compile board LED functions
Dear Tom Rix, In message 1257292804-10612-2-git-send-email-tom@windriver.com you wrote: The ARM board LED functions are defined as weak. They add a size overhead if they are not used. Now they are only defined if CONFIG_STATUS_LED is also defined. The arm920t and arm926ejs _start function calls these LED functions bl coloured_LED_init bl red_LED_on In general, what happens is they call into the weak stubs. Only if the cpu/board provides an overriding function do these calls cause anything meaningful to happen. Now this noop case is removed and these LED functions are excuted only when CONFIG_STATUS_LED is defined I don't get it. We use weak to avoid #ifdef's, and you insert new #ifdef's? That seems to be the wrong approach to me. 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 if is a trademark of Hewlett Packard, so stop using it in your sentences without permission, or risk being sued. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] env: Group environment variables
On Thu, 2009-11-05 at 20:57 +0100, Wolfgang Denk wrote: snip 2) Trying to figure out which enviroment variables have already been printed in groups is less than elegant. Currently, it's a brute-force approach of looking through every entry until a variable is found in a group or not. Suggestions for cleaner algorithms here would be appreciated. The repeated scanning and comparing doesn't make much sense to me. Probably it makes more sense to use a more suitable data structure here. How about performing a linear scan of the environment only once and convert it into a more easily processable data structure, say a hash table or a binary tree or whatever, and then operate on this. Here you can easily add additional flags like a pointer which group the variable belongs to (if any). Also, this would make it easier for example to print a sorted list. Eventually we should _always_ do that, i. e. replace the standard copy operation as done in env_relocate*() by a function that not only copies the environment, but converts it into a new internal representation. This might be beneficial to accelerate access to variables, too. This is an excellent suggestion. I'll see what I can whip up. = print only a list of groups If env_groups is defined, none of the grouping variables will be printed. This seemed to clutter up the printenv output. I don't think this is a wise decision. Having magic variables which cannot be seen an idea I dislike. I think the standard printenv (without args) should print the grouping variables as first block. Ok, I'll group the grouping variables into a group of their own. Also, it would be nice if prontenv now would allow to print a group, i. e. in your example something as printenv net pci should be supported. This is already (accidentally :) supported. a printenv $net would do just what you state. Grouping environment variables will almost certainly lead to a reqirement for bumping up CONFIG_SYS_MAXARGS. ...which raises the question why there is such a static limit in the first place. Yes, it was trivial to implement, but maybe this can be improved? Artificial limits on line lengths and numbers of arguments are a nice thing - to remove :-) Best regards, Wolfgang Denk John ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 3/5] CAN device driver for the SJA1000
Dear Wolfgang Grandegger, In message 4aef3f18.6000...@grandegger.com you wrote: Well, I think Wolfgang will tell me to use structs sooner than later. Why should I? You already know it! 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 There is no statute of limitations on stupidity. - Randomly produced by a computer program called Markov3. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ARM: fix build error with gcc-4.4.2 about inline function declared weak
Wolfgang Denk wrote: Dear Tom Rix, In message 1257292804-10612-3-git-send-email-tom@windriver.com you wrote: From: Abdoulaye Walsimou Gaye walsi...@walsimou.com This patch fix build error with gcc-4.4.2 about inline function declared weak, see below: board.c:96: error: inline function 'coloured_LED_init' cannot be declared weak board.c:98: error: inline function 'red_LED_on' cannot be declared weak board.c:100: error: inline function 'red_LED_off' cannot be declared weak board.c:102: error: inline function 'green_LED_on' cannot be declared weak board.c:104: error: inline function 'green_LED_off' cannot be declared weak board.c:106: error: inline function 'yellow_LED_on' cannot be declared weak board.c:108: error: inline function 'yellow_LED_off' cannot be declared weak board.c:110: error: inline function 'blue_LED_on' cannot be declared weak board.c:112: error: inline function 'blue_LED_off' cannot be declared weak make[1]: *** [board.o] Error 1 Signed-off-by: Abdoulaye Walsimou Gaye walsi...@walsimou.com What is this? Are you sure this patch is properly attributed? Was Abdoulaye Walsimou Gaye really the first to submit this patch? Best regards, Wolfgang Denk Would you like the older one ? As you said, they looked the same. Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ARM Conditionally compile board LED functions
Wolfgang Denk wrote: Dear Tom Rix, In message 1257292804-10612-2-git-send-email-tom@windriver.com you wrote: The ARM board LED functions are defined as weak. They add a size overhead if they are not used. Now they are only defined if CONFIG_STATUS_LED is also defined. The arm920t and arm926ejs _start function calls these LED functions bl coloured_LED_init bl red_LED_on In general, what happens is they call into the weak stubs. Only if the cpu/board provides an overriding function do these calls cause anything meaningful to happen. Now this noop case is removed and these LED functions are excuted only when CONFIG_STATUS_LED is defined I don't get it. We use weak to avoid #ifdef's, and you insert new #ifdef's? That seems to be the wrong approach to me. The arguments for using weak are getting weak :P Using weak is less relevant with the #ifdef's The benefit now is that boards that use the led functions do not have to define all of them. I am open to ideas on how to kill weak off completely. Has a general led driver layer ever been proposed ? Something to convert status led for a mixture of #defines and weak symbols to something that had a register function and some file_ops ? Tom Tom Best regards, Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/10] omap3evm: musb: add USB config
Hi Tom and Ajay, 2009/11/4 Tom Rix tom@windriver.com: From: Ajay Kumar Gupta ajay.gu...@ti.com Added USB host and device config for host (MSC, Keyboard) and device (ACM) functionalities. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com --- include/configs/omap3_evm.h | 39 +++ 1 files changed, 39 insertions(+), 0 deletions(-) Applied to the U-boot-usb next branch. Thanks. Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] NAND: Update to support 64 bit device size
On Fri, Oct 30, 2009 at 01:51:23PM -0400, s-paul...@ti.com wrote:
From: Sandeep Paulraj s-paul...@ti.com
This patch adds support for NANDs greater than 2 GB.
Patch is based on the MTD NAND driver in the kernel.
Signed-off-by: Sandeep Paulraj s-paul...@ti.com
Applied to u-boot-nand-flash/next, with a few whitespace changes that make
it more like the upstream code (though it's still not identical, as upstream
has some long lines that got wrapped in U-Boot). In particular, some things
were double-tabbed, and existing alignment broken.
Here's the diff from the posted patch to what was applied:
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 6848f28..30a3e9e 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2218,8 +2218,8 @@ int nand_erase_nand(struct mtd_info *mtd, struct
erase_info *instr,
loff_t len;
MTDDEBUG(MTD_DEBUG_LEVEL3, nand_erase: start = 0x%012llx,
- len = %llu\n, (unsigned long long) instr-addr,
- (unsigned long long) instr-len);
+len = %llu\n, (unsigned long long) instr-addr,
+(unsigned long long) instr-len);
/* Start address must align on block boundary */
if (instr-addr ((1 chip-phys_erase_shift) - 1)) {
@@ -2324,9 +2324,9 @@ int nand_erase_nand(struct mtd_info *mtd, struct
erase_info *instr,
* page being erased
*/
if (bbt_masked_page != 0x
- (page BBT_PAGE_MASK) == bbt_masked_page)
- rewrite_bbt[chipnr] = ((loff_t)page
- chip-page_shift);
+ (page BBT_PAGE_MASK) == bbt_masked_page)
+ rewrite_bbt[chipnr] =
+ ((loff_t)page chip-page_shift);
/* Increment page address and decrement length */
len -= (1 chip-phys_erase_shift);
@@ -2373,9 +2373,8 @@ int nand_erase_nand(struct mtd_info *mtd, struct
erase_info *instr,
continue;
/* update the BBT for chip */
MTDDEBUG (MTD_DEBUG_LEVEL0, nand_erase_nand: nand_update_bbt
- (%d:0x%0llx 0x%0x)\n, chipnr,
- rewrite_bbt[chipnr],
- chip-bbt_td-pages[chipnr]);
+ (%d:0x%0llx 0x%0x)\n, chipnr, rewrite_bbt[chipnr],
+ chip-bbt_td-pages[chipnr]);
nand_update_bbt(mtd, rewrite_bbt[chipnr]);
}
diff --git a/drivers/mtd/nand/nand_bbt.c b/drivers/mtd/nand/nand_bbt.c
index 1167c90..2fe68ab 100644
--- a/drivers/mtd/nand/nand_bbt.c
+++ b/drivers/mtd/nand/nand_bbt.c
@@ -443,8 +443,8 @@ static int create_bbt(struct mtd_info *mtd, uint8_t *buf,
if (ret) {
this-bbt[i 3] |= 0x03 (i 0x6);
MTDDEBUG (MTD_DEBUG_LEVEL0,
- Bad eraseblock %d at 0x%012llx\n,
- i 1, (unsigned long long)from);
+ Bad eraseblock %d at 0x%012llx\n,
+ i 1, (unsigned long long)from);
mtd-ecc_stats.badblocks++;
}
@@ -746,7 +746,7 @@ static int write_bbt(struct mtd_info *mtd, uint8_t *buf,
printk(KERN_DEBUG Bad block table written to 0x%012llx,
version 0x%02X\n, (unsigned long long)to,
- td-version[chip]);
+ td-version[chip]);
/* Mark it as used */
td-pages[chip] = page;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] env: Group environment variables
Dear John, In message 1257452739.8937.1166.ca...@johns you wrote: Also, it would be nice if prontenv now would allow to print a group, i. e. in your example something as printenv net pci should be supported. This is already (accidentally :) supported. a printenv $net would do just what you state. Um.. this is not what I mean. 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 Humanity has the stars in its future, and that future is too important to be lost under the burden of juvenile folly and ignorant superstition. - Isaac Asimov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ARM: fix build error with gcc-4.4.2 about inline function declared weak
Dear Tom, In message 4af33815.4030...@windriver.com you wrote: Signed-off-by: Abdoulaye Walsimou Gaye walsi...@walsimou.com What is this? Are you sure this patch is properly attributed? Was Abdoulaye Walsimou Gaye really the first to submit this patch? Best regards, Wolfgang Denk Would you like the older one ? As you said, they looked the same. It does not matter what I like. What matters is who is to be credited for this patch, and in my opinion this has to be the first to submit it. You don't get any credits any more today for inventing a light bulb, either. 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 Stupidity, like virtue, is its own reward. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] env: Group environment variables
On Thu, 2009-11-05 at 23:37 +0100, Wolfgang Denk wrote: Dear John, In message 1257452739.8937.1166.ca...@johns you wrote: Also, it would be nice if prontenv now would allow to print a group, i. e. in your example something as printenv net pci should be supported. This is already (accidentally :) supported. a printenv $net would do just what you state. Um.. this is not what I mean. So, a printenv net would print ipaddr netmask gatewayip serverip A printenv $net would print ipaddr=10.52.0.133 netmask=255.255.0.0 gatewayip=10.52.0.1 serverip=10.52.0.33 Do you mean something other than either of those? John ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ARM Conditionally compile board LED functions
Dear Tom, In message 4af339e1.9060...@windriver.com you wrote: The arguments for using weak are getting weak :P :-P Using weak is less relevant with the #ifdef's But it's the wrong direction your heading. We should get rid of #ifdef's, not add new ones. With #ifdef's, you have different versions of the code, which increases the multitude of configurations that actually need to be tested. With weak, you have one version of the code only. The benefit now is that boards that use the led functions do not have to define all of them. That's just an indication of a broken implementation. Normally you would provide the weak functions in a central place, where any board configuration which wants can overwrite them, or not. I am open to ideas on how to kill weak off completely. You got it wrong. We want to kill off the #ifdef's. Has a general led driver layer ever been proposed ? Something to convert status led for a mixture of #defines and weak symbols to something that had a register function and some file_ops ? We use status LEDs on many boards, without real issues. It's only AT91 which suffers from this mess. 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 There is nothing new under the sun, but there are lots of old things we don't know yet. - Ambrose Bierce ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] [OneNAND] Flex-OneNAND boundary settings
On Wed, Nov 04, 2009 at 10:39:41AM +0530, Amul Kumar Saha wrote:
while (blocks) {
+ blocksize = onenand_blocksize(ofs);
+
ret = mtd-block_isbad(mtd, ofs);
if (ret) {
printk(Bad blocks %d at 0x%x\n,
-(u32)(ofs this-erase_shift), (u32)ofs);
+(u32)onenand_block(this, ofs), (u32)ofs);
This isn't new, but %d doesn't match u32 (though I guess GCC doesn't
complain about signedness) -- and we shouldn't be chopping off the upper
bits of ofs.
+ blocks = (int) onenand_block(this, ofs + len)
+ - onenand_block(this, ofs);
Unnecessary cast.
@@ -493,9 +531,11 @@ U_BOOT_CMD(
onenand write[.oob] addr off size\n
read/write 'size' bytes starting at offset 'off'\n
to/from memory address 'addr', skipping bad blocks.\n
- onenand erase [force] [off size] - erase 'size' bytes from\n
+ onenand erase [force] [off size] - erase 'size' bytes from off\n
onenand test [off size] - test 'size' bytes from\n
offset 'off' (entire device if not specified)\n
onenand dump[.oob] off - dump page\n
onenand markbad off [...] - mark bad block(s) at offset (UNSAFE)
+ onenand setboundary DIE BOUNDARY [LOCK] - \n
+ Change SLC boundary of Flex-OneNAND\n
Description should be indented if you're going to put it on a new line.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] NAND: Update to support 64 bit device size
On Fri, Oct 30, 2009 at 01:51:23PM -0400, s-paul...@ti.com wrote: From: Sandeep Paulraj s-paul...@ti.com This patch adds support for NANDs greater than 2 GB. Patch is based on the MTD NAND driver in the kernel. Signed-off-by: Sandeep Paulraj s-paul...@ti.com Applied to u-boot-nand-flash/next, with a few whitespace changes that make it more like the upstream code (though it's still not identical, as upstream has some long lines that got wrapped in U-Boot). In particular, some things were double-tabbed, and existing alignment broken. Here's the diff from the posted patch to what was applied: Scott, Thanks for this. I have to update you and the list on some of my findings. I had a 4GB SAMSUNG NAND and a 4GB MICRON NAND which earlier would not even get correctly detected by U-Boot and the DaVinci NAND driver. After adding this support I solved 2 issues 1) The above 2 NAND devices got correctly detected. 2) I believe due to incomplete 64 bit support while doing a saveenv, the diagnostics were wrong. The env was getting saved but the address being displayed was obviously messed up. Adding this patch correctly displayed the address being saved to. But we have other issues. Some of them are 1) doing a nand bad resulted in a kind of a continuous spin. U-boot correctly detects bad blocks but because we use 32 bit variables in cmd_nand.c it keeps finding the same bad blocks infinite times. 2) I fixed the above but then I had issues with nand read and write. Basically to have fully functional NAND support we will need to completely update cmd_nand.c with 64 bit support I believe. Its on my TODO list but if anybody beats me to this I'll be more than happy. My intention is to work on this the moment I get some free time (I wish I do get some soon but I cannot promise anything). Also a quick look at the /common folder seems to suggest that we are not yet fully geared up for stuff more than 32 bit in general. In any case its time we all started updating U-Boot for this. Just though I'll update you and the list. Please do let me know if you have any issues as mentioned above. As always, I am always open to hear from anyone if any of my above observations are wrong. Its my personal opinion that there is nothing wrong with my patch itself. I've just picked up the kernel's version. But there's still stuff to be done. Thanks, Sandeep ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ARM Conditionally compile board LED functions
Wolfgang Denk wrote: Dear Tom, In message 4af339e1.9060...@windriver.com you wrote: The arguments for using weak are getting weak :P :-P Using weak is less relevant with the #ifdef's But it's the wrong direction your heading. We should get rid of #ifdef's, not add new ones. With #ifdef's, you have different versions of the code, which increases the multitude of configurations that actually need to be tested. With weak, you have one version of the code only. To use the status led api, you have to define CONFIG_STATUS_LED anyway. I did not think this added to the configuration space. The benefit now is that boards that use the led functions do not have to define all of them. That's just an indication of a broken implementation. Normally you would provide the weak functions in a central place, where any board configuration which wants can overwrite them, or not. I am open to ideas on how to kill weak off completely. You got it wrong. We want to kill off the #ifdef's. My vector is obviously pointing in the wrong direction.. Has a general led driver layer ever been proposed ? Something to convert status led for a mixture of #defines and weak symbols to something that had a register function and some file_ops ? We use status LEDs on many boards, without real issues. It's only AT91 which suffers from this mess. I withdraw this patch. I will rethink this and come up with something better. Tom Best regards, Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Save environment data to mmc.
Hi Mike, I will fix the two issues you pointed. Thanks a lot. Actually, env_mmc.c is written based on env_nand.c in u-boot 1.3.3. I have modified it according to the latest changes in environment code. But seems there's still a lot of issue. Sorry for that. It works well in our project. So I want to add it to u-boot mainline. Thanks~~ Yours Terry -Original Message- From: Mike Frysinger [mailto:vap...@gentoo.org] Sent: 2009年11月5日 20:10 To: u-boot@lists.denx.de Cc: Lv Terry-R65388 Subject: Re: [U-Boot] [PATCH] Save environment data to mmc. On Thursday 05 November 2009 02:43:33 Terry Lv wrote: --- a/common/Makefile +++ b/common/Makefile @@ -58,6 +58,7 @@ COBJS-$(CONFIG_ENV_IS_IN_NAND) += env_nand.o COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_nvram.o COBJS-$(CONFIG_ENV_IS_IN_ONENAND) += env_onenand.o COBJS-$(CONFIG_ENV_IS_IN_SPI_FLASH) += env_sf.o +COBJS-$(CONFIG_ENV_IS_IN_MMC) += env_mmc.o this list is attempting to stay in order according to the CONFIG name, so you should add this above the NAND ENV entry --- /dev/null +++ b/common/env_mmc.c @@ -0,0 +1,359 @@ +#if defined(CONFIG_ENV_IS_IN_MMC) /* Environment is in MMC Flash */ you dont need this line anymore as it's in the Makefile +#ifdef CONFIG_INFERNO +#error CONFIG_INFERNO not supported yet #endif is this really needed ? +extern int default_environment_size; this looks like another useless line copy pasted from whatever file you based this on -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] ARM Add New Board GEC2410 rev2
Signed-off-by: Hui.Tang zetal...@gmail.com --- checkpatch.pl shows total: 0 errors, 0 warnings, 1249 lines checked 0001-ARM-Add-New-Board-GEC2410.patch has no obvious style problems and is ready for submission. MAINTAINERS |4 + MAKEALL |1 + Makefile |7 + board/gec/gec2410/Makefile| 54 ++ board/gec/gec2410/README | 85 + board/gec/gec2410/config.mk | 34 board/gec/gec2410/gec2410.c | 313 + board/gec/gec2410/gec2410_mem.h | 118 + board/gec/gec2410/lowlevel_init.S | 93 ++ board/gec/gec2410/u-boot-nand.lds | 61 +++ cpu/arm920t/s3c24x0/timer.c |3 +- include/configs/gec2410.h | 249 ++ nand_spl/board/gec/gec2410/Makefile | 103 +++ nand_spl/board/gec/gec2410/config.mk | 40 + nand_spl/board/gec/gec2410/u-boot.lds | 60 +++ 15 files changed, 1224 insertions(+), 1 deletions(-) create mode 100644 board/gec/gec2410/Makefile create mode 100644 board/gec/gec2410/README create mode 100644 board/gec/gec2410/config.mk create mode 100644 board/gec/gec2410/gec2410.c create mode 100644 board/gec/gec2410/gec2410_mem.h create mode 100644 board/gec/gec2410/lowlevel_init.S create mode 100644 board/gec/gec2410/u-boot-nand.lds create mode 100644 include/configs/gec2410.h create mode 100644 nand_spl/board/gec/gec2410/Makefile create mode 100644 nand_spl/board/gec/gec2410/config.mk create mode 100644 nand_spl/board/gec/gec2410/u-boot.lds diff --git a/MAINTAINERS b/MAINTAINERS index d70a9d2..6ecba41 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -429,6 +429,10 @@ Timur Tabi ti...@freescale.com MPC8349E-mITX MPC8349 MPC8349E-mITX-GP MPC8349 +Hui Tang zetal...@gmail.com + + gec2410 ARM920T + Erik Theisen ethei...@mindspring.com W7OLMC PPC4xx diff --git a/MAKEALL b/MAKEALL index d63c5c2..fffa58a 100755 --- a/MAKEALL +++ b/MAKEALL @@ -548,6 +548,7 @@ LIST_ARM9= \ cp926ejs\ cp946es \ cp966 \ + gec2410 \ imx27lite \ lpd7a400\ mv88f6281gtw_ge \ diff --git a/Makefile b/Makefile index bcb3fe9..2de0b1d 100644 --- a/Makefile +++ b/Makefile @@ -2951,6 +2951,13 @@ davinci_dm365evm_config :unconfig davinci_dm6467evm_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm926ejs dm6467evm davinci davinci +gec2410_config : unconfig + @mkdir -p $(obj)include $(obj)board/gec/gec2410 + @mkdir -p $(obj)nand_spl/board/gec/gec2410 + @echo RAM_TEXT = 0x33e0 $(obj)board/gec/gec2410/config.tmp + @$(MKCONFIG) $(@:_config=) arm arm920t gec2410 gec s3c24x0 + @echo CONFIG_NAND_U_BOOT = y $(obj)include/config.mk + imx27lite_config: unconfig @$(MKCONFIG) $(@:_config=) arm arm926ejs imx27lite logicpd mx27 diff --git a/board/gec/gec2410/Makefile b/board/gec/gec2410/Makefile new file mode 100644 index 000..052f600 --- /dev/null +++ b/board/gec/gec2410/Makefile @@ -0,0 +1,54 @@ +# +# (C) Copyright 2000-2006 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# (C) Copyright 2009 +# Hui Tang zetal...@gmail.com +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS := gec2410.o +SOBJS := lowlevel_init.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/gec/gec2410/README
