Re: [U-Boot] subcmd handling
Hi Frans,
It was hinted (iirc by Detlev) that I'd have a stab at subcmd handling
(at least for i2c).
Yep.
As example bootm was suggested.
This was only one example, there are more usages of this. Good old grep
will be your friend.
I've peeked at the bootm code and the code in command.c.
It seems bootm has some internal state engine, that is somewhat less
applicable for other commands.
This doesn't really matter. If you want an easier example, check
board/inka4x0/inkadiag.c and do_inkadiag in particular.
My proposal for i2c:
have an array
static cmd_tbl_t cmd_i2c_sub[] = { };
whiich is populated/initialized by U_BOOT_CMD_MKENT macro invocations
for the various subcommands.
The function do_i2c which now handles the subcmd parsing changes into:
int do_i2c(cmd_tbl_t * cmdtp, int flag, int argc, char *argv[])
{
cmd_tbl_t *c;
/* Strip off leading 'i2c' command argument */
argc--;
argv++;
c = find_cmd_tbl(argv[0], cmd_i2c_sub[0], ARRAY_SIZE(cmd_i2c_sub));
if (c) {
return c-cmd(cmdtp, flag, argc, argv);
}
else
{
cmd_usage(cmdtp);
return 0;
}
}
Yep, looks roughly comparable to the example I pointed out above.
(and sorry for the messy layout)
A few questions before I actually implement and test this:
any comments on this proposal ?
What should be the return value in case the usage is printed? do_i2c
returns 0 in that case
however do_bootm_subcommand returns 1 in that case.
As the command failed, 1 should be returned. I would consider the 0
return of do_i2c to be a (minor) bug.
We might also consider putting the help texts in U_BOOT_CMD_MKENT.
Then U_BOOT_CMD should probably be aware of the child commands and
should use the help of the child commands to print its help.
Hm? This is one of the reasons for using this infrastructure. Somehow
I feel I do not understand your question.
The first entry in U_BOOT_CMD_MKENT is the name. This is stringified
by using a # in the macro.
Personally I would like to change it and have string quotes in the
macro invocation so that it is immediately visible when reading the
code that it is a string, not e.g. a variable.
E.g. we would get
U_BOOT_CMD_MKENT(start, ...
instead of
U_BOOT_CMD_MKENT(start, ...
what we have now where for the casual reader not up to date on the
definition of the macro it might look as if a var is passed.
(btw passing a string could also allow for passing an empty string,
which could be used to add non-command assoicated help texts).
As I have no plans to implement this more than once, I would
appreciate feedback before starting to actually code it.
Do you feel that thi slight difference is worth the effort? I guess it
is not clear to me what you want to change. You could try to show us
only a protoitype of your proposed change and then we can comment more
sensibly.
Thanks
Detlev
--
If you think the Y2K crisis is bad - then wait for the year
-- Donald Knuth
--
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] sdhc: use reset value instead of a hardcoded value to set wml
From: Roy Zang tie-fei.z...@freescale.com
Use reset value instead of a hardcoded value to set wml.
Signed-off-by: Roy Zang tie-fei.z...@freescale.com
---
drivers/mmc/fsl_esdhc.c |8 +---
include/fsl_esdhc.h |4 +++-
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 34a2585..dc37bf8 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2007, Freescale Semiconductor, Inc
+ * Copyright 2007, 2010 Freescale Semiconductor, Inc
* Andy Fleming
*
* Based vaguely on the pxa mmc code:
@@ -110,7 +110,8 @@ static int esdhc_setup_data(struct mmc *mmc, struct
mmc_data *data)
if (wml_value 0x10)
wml_value = 0x10;
- wml_value = 0x10 | wml_value;
+ wml_value = in_be32(regs-wml) (~WML_RD_WML_MASK) |
+ wml_value;
out_be32(regs-dsaddr, (u32)data-dest);
} else {
@@ -120,7 +121,8 @@ static int esdhc_setup_data(struct mmc *mmc, struct
mmc_data *data)
printf(\nThe SD card is locked. Can not write to a
locked card.\n\n);
return TIMEOUT;
}
- wml_value = wml_value 16 | 0x10;
+ wml_value = in_be32(regs-wml) (~WML_WR_WML_MASK) |
+ (wml_value 16);
out_be32(regs-dsaddr, (u32)data-src);
}
diff --git a/include/fsl_esdhc.h b/include/fsl_esdhc.h
index adb43d7..3b5665d 100644
--- a/include/fsl_esdhc.h
+++ b/include/fsl_esdhc.h
@@ -2,7 +2,7 @@
* FSL SD/MMC Defines
*---
*
- * Copyright 2007-2008, Freescale Semiconductor, Inc
+ * Copyright 2007-2008, 2010 Freescale Semiconductor, Inc
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
@@ -130,6 +130,8 @@
#define WML0x2e044
#define WML_WRITE 0x0001
+#define WML_RD_WML_MASK0xff
+#define WML_WR_WML_MASK0xff
#define BLKATTR0x2e004
#define BLKATTR_CNT(x) ((x 0x) 16)
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] EMAC failure and SPI support for TI DaVinci DM365
On 23/02/10 20:14, Paulraj, Sandeep wrote: Ian Jeffray wrote: I do notice that the Net: line above has no further detail, wheras the TI PSP binary version says Ethernet PHY: GENERIC @ 0x00 (I've not managed to get a 2009.03 build of my own to run on DM365 to compare yet... that's the version TI supplied as binary somehow) The other issue might be the updates tot eh EMAC driver. The version that finally was accepted by Ben was submitted by Nick Thompson. It worked fine for me but I'm not sure if something small was missed. I tested on da830evm, but only in my private tree. The changes needed by da830 are still filtering up to main (currently in the arm tree). Once it hits main, I will be retesting. In the mean time, I will be following this thread in case there is an issue. Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM change name of defines for AT91 arm926ejs
Configuration defines should be preceeded with CONFIG_SYS_. Renamed some at91 specific defines to conform to this naming convention: AT91_CPU_NAME to CONFIG_SYS_AT91_CPU_NAME AT91_MAIN_CLOCK to CONFIG_SYS_AT91_MAIN_CLOCK Signed-off-by: Achim Ehrlich aehrl...@taskit.de --- board/atmel/at91cap9adk/at91cap9adk.c |2 +- board/atmel/at91sam9261ek/at91sam9261ek.c |2 +- board/atmel/at91sam9263ek/at91sam9263ek.c |2 +- board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c |2 +- board/atmel/at91sam9rlek/at91sam9rlek.c |2 +- board/esd/otc570/otc570.c |2 +- board/ronetix/pm9261/pm9261.c |2 +- board/ronetix/pm9263/pm9263.c |2 +- cpu/arm926ejs/at91/clock.c |2 +- cpu/arm926ejs/at91/cpu.c|8 include/asm-arm/arch-at91/at91cap9.h|2 +- include/asm-arm/arch-at91/at91rm9200.h |2 +- include/asm-arm/arch-at91/at91sam9260.h |4 ++-- include/asm-arm/arch-at91/at91sam9261.h |2 +- include/asm-arm/arch-at91/at91sam9263.h |2 +- include/asm-arm/arch-at91/at91sam9g45.h |2 +- include/asm-arm/arch-at91/at91sam9rl.h |2 +- include/configs/afeb9260.h |2 +- include/configs/at91cap9adk.h |2 +- include/configs/at91sam9260ek.h |2 +- include/configs/at91sam9261ek.h |2 +- include/configs/at91sam9263ek.h |2 +- include/configs/at91sam9m10g45ek.h |2 +- include/configs/at91sam9rlek.h |2 +- include/configs/cpu9260.h |2 +- include/configs/pm9261.h|4 ++-- include/configs/pm9263.h|2 +- include/configs/sbc35_a9g20.h |2 +- include/configs/tny_a9260.h |2 +- 29 files changed, 34 insertions(+), 34 deletions(-) diff --git a/board/atmel/at91cap9adk/at91cap9adk.c b/board/atmel/at91cap9adk/at91cap9adk.c index 9f73df6..258d1ea 100644 --- a/board/atmel/at91cap9adk/at91cap9adk.c +++ b/board/atmel/at91cap9adk/at91cap9adk.c @@ -282,7 +282,7 @@ void lcd_show_board_info(void) lcd_printf ((C) 2008 ATMEL Corp\n); lcd_printf (at91supp...@atmel.com\n); lcd_printf (%s CPU at %s MHz\n, - AT91_CPU_NAME, + CONFIG_SYS_AT91_CPU_NAME, strmhz(temp, get_cpu_clk_rate())); dram_size = 0; diff --git a/board/atmel/at91sam9261ek/at91sam9261ek.c b/board/atmel/at91sam9261ek/at91sam9261ek.c index 7ead2b8..de5cfae 100644 --- a/board/atmel/at91sam9261ek/at91sam9261ek.c +++ b/board/atmel/at91sam9261ek/at91sam9261ek.c @@ -217,7 +217,7 @@ void lcd_show_board_info(void) lcd_printf ((C) 2008 ATMEL Corp\n); lcd_printf (at91supp...@atmel.com\n); lcd_printf (%s CPU at %s MHz\n, - AT91_CPU_NAME, + CONFIG_SYS_AT91_CPU_NAME, strmhz(temp, get_cpu_clk_rate())); dram_size = 0; diff --git a/board/atmel/at91sam9263ek/at91sam9263ek.c b/board/atmel/at91sam9263ek/at91sam9263ek.c index 8ab45af..5cd7aa7 100644 --- a/board/atmel/at91sam9263ek/at91sam9263ek.c +++ b/board/atmel/at91sam9263ek/at91sam9263ek.c @@ -218,7 +218,7 @@ void lcd_show_board_info(void) lcd_printf ((C) 2008 ATMEL Corp\n); lcd_printf (at91supp...@atmel.com\n); lcd_printf (%s CPU at %s MHz\n, - AT91_CPU_NAME, + CONFIG_SYS_AT91_CPU_NAME, strmhz(temp, get_cpu_clk_rate())); dram_size = 0; diff --git a/board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c b/board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c index 45a14a9..edfb627 100644 --- a/board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c +++ b/board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c @@ -217,7 +217,7 @@ void lcd_show_board_info(void) lcd_printf ((C) 2008 ATMEL Corp\n); lcd_printf (at91supp...@atmel.com\n); lcd_printf (%s CPU at %s MHz\n, - AT91_CPU_NAME, + CONFIG_SYS_AT91_CPU_NAME, strmhz(temp, get_cpu_clk_rate())); dram_size = 0; diff --git a/board/atmel/at91sam9rlek/at91sam9rlek.c b/board/atmel/at91sam9rlek/at91sam9rlek.c index 7013ba2..e374917 100644 --- a/board/atmel/at91sam9rlek/at91sam9rlek.c +++ b/board/atmel/at91sam9rlek/at91sam9rlek.c @@ -157,7 +157,7 @@ void lcd_show_board_info(void) lcd_printf ((C) 2008 ATMEL Corp\n); lcd_printf (at91supp...@atmel.com\n); lcd_printf (%s CPU at %s MHz\n, - AT91_CPU_NAME, + CONFIG_SYS_AT91_CPU_NAME, strmhz(temp, get_cpu_clk_rate())); dram_size = 0; diff --git a/board/esd/otc570/otc570.c b/board/esd/otc570/otc570.c index 056df37..3fe28cb 100644 --- a/board/esd/otc570/otc570.c +++ b/board/esd/otc570/otc570.c @@
Re: [U-Boot] [PATCH 4/6] fsl_diu_fb.c: add support for RLE8 bitmaps
Hello Wolfgang, Wolfgang Denk w...@denx.de wrote: Dear Anatolij Gustschin, In message 1266964630-7754-5-git-send-email-ag...@denx.de you wrote: Allow displaying run length encoded bitmaps. Signed-off-by: Anatolij Gustschin ag...@denx.de --- board/freescale/common/fsl_diu_fb.c | 78 +++ 1 files changed, 78 insertions(+), 0 deletions(-) Isn't there a way to implement this feature in common code, so all boards with bitmap support can benefit from this? There is a way to do it, sure. The problem is, diu driver doesn't use this common code. I'll rework the diu driver to do so. Best regards, Anatolij -- 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] [PATCH 6/6] mpc5121: add support for PDM360NG board
Hi Detlev,
Detlev Zundel d...@denx.de wrote:
Signed-off-by: Michael Weiss michael.we...@ifm.com
Please fix the e-mail format.
Ok.
@@ -820,6 +820,9 @@ aria_config:unconfig
mecp5123_config: unconfig
@$(MKCONFIG) -a mecp5123 ppc mpc512x mecp5123 esd
+pdm360ng_config: unconfig
+ @$(MKCONFIG) -a pdm360ng ppc mpc512x pdm360ng
+
mpc5121ads_config \
mpc5121ads_rev2_config \
: unconfig
Keep the list of targets sorted in the Makefile please.
Ok!
+/*
+ * Co-Processor communication POST
+ */
+#if defined(CONFIG_POST) defined(CONFIG_SERIAL_MULTI)
Why is this depending on SERIAL_MULTI? The POST system as such is
orthogonal, no?
Currently there is only Coprocessor POST only which depends
on SERIAL_MULTI. I think I should better do something like:
#if defined(CONFIG_POST)
#if defined(CONFIG_SERIAL_MULTI)
/* Co-Processor POST code */
...
#endif
#endif
Even better would be to move POST code to separate file, it seems.
+
+#if defined(CONFIG_SYS_POST_WORD_ADDR)
+# define _POST_ADDR(CONFIG_SYS_POST_WORD_ADDR)
+#else
+#error echo No POST word address defined
+#endif
+
+void post_word_store(ulong a)
+{
+ volatile void *save_addr = (volatile void *)(_POST_ADDR);
+
+ out_be32(save_addr, a);
+}
+
+ulong post_word_load(void)
+{
+ volatile void *save_addr = (volatile void *)(_POST_ADDR);
+
+ return in_be32(save_addr);
+}
Can't we put this into 512x shared code? I really dislike putting this
into board code. I know that 5200 set a precedent here, but they all
have identical code. One should rather fix 5200 also.
I'll move it to cpu/mpc512x/commproc.c.
...
+ ret = read_port(cop_port, buf, sizeof(buf));
+ close_port(1);
+ if (ret = 0) {
+ post_log(Error: Can't read WD Coprocessor port.\n);
+ return -1;
+ }
+
+ if (strcmp(buf, alive)) {
+ post_log(Error: WD-Cop. resp.: %s\n, buf);
+ return -1;
+ }
+
+ return 0;
+}
+#endif /* CONFIG_POST */
Wouldn't it be a good idea to split the POST stuff into a separate file?
I'll move it to a separate file.
+/* Use SRAM for initial stack */
+#define CONFIG_SYS_INIT_RAM_ADDR CONFIG_SYS_SRAM_BASE/* Initial RAM
address */
+#define CONFIG_SYS_INIT_RAM_ENDCONFIG_SYS_SRAM_SIZE/* End
of used area in RAM */
+
+#define CONFIG_SYS_GBL_DATA_SIZE 0x100 /* num bytes
initial data */
+#define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_INIT_RAM_END -
CONFIG_SYS_GBL_DATA_SIZE)
+#define CONFIG_SYS_POST_WORD_ADDR (CONFIG_SYS_GBL_DATA_OFFSET - 0x4)
+#define CONFIG_SYS_INIT_SP_OFFSET CONFIG_SYS_POST_WORD_ADDR
Isn't this shared among the 512x implementations so we can put it in a
common file?
Yes, we should put it in a common file.
Thanks,
Anatolij
--
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
[U-Boot] mcf 5307
Hello all, is ColdFire mcf5307 cpu supported ? in 1.1.6 i found mcf52x2 cpu only. Regards, Angelo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] The abortboot routine misses key hits issued via netconsole.
Hello, The Hit any key to stop autoboot: of abortboot routine misses the key hits issued via netconsole. It happens due to delays of 10ms used to count passed seconds in the abortboot routine of main.c file. All key events arrived asynchronously during these delays are lost. I solved it localy on my mpc8349 @ 514MHz based board by expanding netloop receive window for netconsole case by 10 in nc_tstc routine and eliminating 10ms delays from wait loop of abortboot routine when compiled with CONFIG_NETCONSOLE and stdin configured to nc. This solution has following drawback - the Console multiplexing (CONFIG_CONSOLE_MUX) will not work because it relates on tstc immediate return. The mitigation factors are: 1) The console mutiplexing could not work anyway when is used with netconsole due to the same limitation as in case with abortboot explained above. 2) See CAVEATS in README.iomux; 3) Currently, AFAIK, console multiplexing is not used by any board. Definitely, not resetting of the eth interface as discussed in http://lists.denx.de/pipermail/u-boot/2010-January/067260.html would be better solution but I am afraid its proper realization may require significant effort under current IP stack architectural limitations. Any thoughts/opinions/comments will be highly appreciated. Regards, Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Release on hold, wait for i.MX custodian
Dear Jason, In message 3d9b2d7685e0734592024dd0f3028ae6ae4...@zch01exm23.fsl.freescale.net you wrote: I'm Jason Liu from freecale MAD SW team. I will act as uboot custodian for FSL I.MX platforms. Thanks for volunteering. Please send me your SSH public key(s) so I can enable accees to the custodian repository for you. I'm hope that the patches owner can feedback me the status of each patch with the following classfication a. brand new pathes, no review comments. b. patches reviewed by not provide new version according to the review comments, c. updated patches, no further review comments. As far as I can tell no further action from the submitters should be needed. All patches have been posted sufficiently long ago so others had a chance to review, and I am not aware of open requests for changes. I think you just have to re-review these patches, and if you have no concerns yourself they can go upstream. 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 How many hardware guys does it take to change a light bulb? Well the diagnostics say it's fine buddy, so it's a software problem. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mcf 5307
Hi Angelo, On Wed, Feb 24, 2010 at 11:32:33AM +0100, angelo wrote: Hello all, is ColdFire mcf5307 cpu supported ? in 1.1.6 i found mcf52x2 cpu only. no. Why are you using a stone-age version? In the current git tree a lot of MCF53xx (and MCF54xx) are supported, too. There is no direct support for MCF5307, but considering they use the same processor core adding support for it starting from one of the more modern MCF53xx parts should be possible. Regards, Wolfgang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] setexpr and memory access
I feel sometimes it could be convenient to use setexpr to use a memory location as argument. The code for that is pretty trivial but the question (and reason for mailing this instead of just submitting the patch) is the syntax of the command. setexpr uses A op B and one of the possibilities for op is a *. If we also allow a * to dereference things (like done in itest) we could get something like setexpr result *3 * *4 Not sure if that is a desirable syntax. Your opinion on this extension and syntax is appreciated. Frans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM change name of defines for AT91 arm926ejs
Achim Ehrlich wrote: Configuration defines should be preceeded with CONFIG_SYS_. Renamed some at91 specific defines to conform to this naming convention: AT91_CPU_NAME to CONFIG_SYS_AT91_CPU_NAME AT91_MAIN_CLOCK to CONFIG_SYS_AT91_MAIN_CLOCK Signed-off-by: Achim Ehrlich aehrl...@taskit.de Thank you. I have pushed this to arm/master Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add bootcount to AT91
Hi Tom, Any news on this? Best regards, Anders On Mon, Feb 8, 2010 at 14:32, Tom tom@windriver.com wrote: Anders Darander wrote: Hi Tom, On Sun, Feb 7, 2010 at 15:35, Tom tom@windriver.com wrote: From: Anders Darander a...@datarespons.se Use AT91_GPBR 3 as a bootcount register. Please send me a link to the original patch. I will take a look Tom Here is the link from Werners patch-status mail: http://article.gmane.org/gmane.comp.boot-loaders.u-boot/73640 (Sorry for bumping this thread that many times... I'm pretty sure that you're quite busy...) No problem. Its quite all right to ping me. I have added your patch to what will be reviewed this week. Tom Best regards, Anders Darander -- Anders Darander EPO guidelines 1978: If the contribution to the known art resides solely in a computer program then the subject matter is not patentable in whatever manner it may be presented in the claims. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mcf 5307
Hi Wolfgang, i didn't know it is stone-age, anyway, it is still well-sold in the Freescale site, quite cheap and suit perfectly my needs. Core V4 also is Harvard architecture, and i don't like it. many thanks Wolfgang Wegner wrote: Hi Angelo, On Wed, Feb 24, 2010 at 11:32:33AM +0100, angelo wrote: Hello all, is ColdFire mcf5307 cpu supported ? in 1.1.6 i found mcf52x2 cpu only. no. Why are you using a stone-age version? In the current git tree a lot of MCF53xx (and MCF54xx) are supported, too. There is no direct support for MCF5307, but considering they use the same processor core adding support for it starting from one of the more modern MCF53xx parts should be possible. Regards, Wolfgang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: Corrected EBC register bit definitions
Hello Stefan, In addition to Wolfgangs comment (patch is line wrapped): I just checked the 440EP and the 440EPx users manual, and it seems that the original bit masks are correct. Which PPC4xx variant are you using? Please double check again if you your patch is correct. I am working on another platform based on the PPC405GPr. You are correct in your observation and my patch is incorrect. The original bit masks are correct for the PPC440EP and PPC440EPx but **not** for the PPC405GPr so a correction is required. According to the AMCC documentation, the EMPL, EMPH bit positions are as you defined them for the PPC440 processors and they are as I define them for the PPC405 processors (in the group of processors defined as CONFIG_EBC_PPC4xx_IBM_VER1). The PPC405EP is an exception since it does not seem to allow external bus mastering and these bits are reserved. Therefore a proper patch needs to set the bit position of the EMPL and EMPH fields differently with the CONFIG_EBC_PPC4xx_IBM_VER1 group accordingly. I can attempt a patch for that if you like. My apologies for the line wrapping mistake (I believe my email client is not line wrapping but it got line wrapped somewhere else... possibly in the Microsoft exchange server). Regards, Eugene ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: Corrected EBC register bit definitions
Hi Eugene, On Wednesday 24 February 2010 16:12:48 Eugene O'Brien wrote: I am working on another platform based on the PPC405GPr. You are correct in your observation and my patch is incorrect. The original bit masks are correct for the PPC440EP and PPC440EPx but **not** for the PPC405GPr so a correction is required. I see. According to the AMCC documentation, the EMPL, EMPH bit positions are as you defined them for the PPC440 processors and they are as I define them for the PPC405 processors (in the group of processors defined as CONFIG_EBC_PPC4xx_IBM_VER1). The PPC405EP is an exception since it does not seem to allow external bus mastering and these bits are reserved. Therefore a proper patch needs to set the bit position of the EMPL and EMPH fields differently with the CONFIG_EBC_PPC4xx_IBM_VER1 group accordingly. I can attempt a patch for that if you like. Yes, please do so. Thanks. 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
[U-Boot] [PATCH v2] edb93xx: Fix SDRAM initialization
edb93xx: Fix SDRAM initialization by issuing a precharge all command before
forcing the precharge and select mode register update mode before programming
the mode registers. Write to the SDRAM banks in order to force a precharge,
reading causes the edb93xx boards to hang
Signed-off-by: Matthias Kaehlcke matth...@kaehlcke.net
---
Changes with with regard to v1:
* Fixed order of years in copyright notice
board/edb93xx/sdram_cfg.c | 39 +++
1 files changed, 31 insertions(+), 8 deletions(-)
diff --git a/board/edb93xx/sdram_cfg.c b/board/edb93xx/sdram_cfg.c
index 6155f0e..440ad11 100644
--- a/board/edb93xx/sdram_cfg.c
+++ b/board/edb93xx/sdram_cfg.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2009 Matthias Kaehlcke matth...@kaehlcke.net
+ * Copyright (C) 2009, 2010 Matthias Kaehlcke matth...@kaehlcke.net
*
* Copyright (C) 2006 Dominic Rath dominic.r...@gmx.de
*
@@ -30,9 +30,9 @@
(SDRAM_BASE_ADDR | SDRAM_BANK_SEL_##bank | SDRAM_MODE_REG_VAL))
#define PRECHARGE_BANK(bank) (*(volatile uint32_t *) \
- (SDRAM_BASE_ADDR | SDRAM_BANK_SEL_##bank))
+ (SDRAM_BASE_ADDR | SDRAM_BANK_SEL_##bank)) = 0
-static void force_precharge(void);
+static void precharge_all_banks(void);
static void setup_refresh_timer(void);
static void program_mode_registers(void);
@@ -47,7 +47,7 @@ void sdram_cfg(void)
early_udelay(200);
- force_precharge();
+ precharge_all_banks();
setup_refresh_timer();
@@ -57,19 +57,37 @@ void sdram_cfg(void)
writel(GLCONFIG_CKE, sdram-glconfig);
}
-static void force_precharge(void)
+static void precharge_all_banks(void)
{
+ struct sdram_regs *sdram = (struct sdram_regs *)SDRAM_BASE;
+
+ /* Issue PRECHARGE ALL commands */
+ writel(GLCONFIG_INIT | GLCONFIG_CKE, sdram-glconfig);
+
/*
-* Errata most EP93xx revisions say that PRECHARGE ALL isn't always
-* issued.
+* Errata of most EP93xx revisions say that PRECHARGE ALL isn't always
+* issued
*
-* Do a read from each bank to make sure they're precharged
+* Cirrus proposes a workaround which consists in performing a read from
+* each bank to force the precharge. This causes some boards to hang.
+* Writing to the SDRAM banks instead of reading has the same
+* side-effect (the SDRAM controller issues the necessary precharges),
+* but is known to work on all supported boards
*/
PRECHARGE_BANK(0);
+
+#if (CONFIG_NR_DRAM_BANKS = 2)
PRECHARGE_BANK(1);
+#endif
+
+#if (CONFIG_NR_DRAM_BANKS = 3)
PRECHARGE_BANK(2);
+#endif
+
+#if (CONFIG_NR_DRAM_BANKS == 4)
PRECHARGE_BANK(3);
+#endif
}
static void setup_refresh_timer(void)
@@ -101,6 +119,11 @@ static void setup_refresh_timer(void)
static void program_mode_registers(void)
{
+ struct sdram_regs *sdram = (struct sdram_regs *)SDRAM_BASE;
+
+ /* Select mode register update mode */
+ writel(GLCONFIG_MRS | GLCONFIG_CKE, sdram-glconfig);
+
/*
* The mode registers are programmed by performing a read from each
* SDRAM bank. The value of the address that is read defines the value
--
1.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cmd_i2c.c: reworked subcommand handling
Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com
---
common/cmd_i2c.c | 77 +++--
1 files changed, 45 insertions(+), 32 deletions(-)
diff --git a/common/cmd_i2c.c b/common/cmd_i2c.c
index 7531702..e54fc20 100644
--- a/common/cmd_i2c.c
+++ b/common/cmd_i2c.c
@@ -1242,46 +1242,59 @@ int do_i2c_bus_speed(cmd_tbl_t * cmdtp, int flag, int
argc, char *argv[])
return ret;
}
-int do_i2c(cmd_tbl_t * cmdtp, int flag, int argc, char *argv[])
+int do_i2c_mm(cmd_tbl_t * cmdtp, int flag, int argc, char *argv[])
{
- /* Strip off leading 'i2c' command argument */
- argc--;
- argv++;
+ return mod_i2c_mem (cmdtp, 1, flag, argc, argv);
+}
+
+int do_i2c_nm(cmd_tbl_t * cmdtp, int flag, int argc, char *argv[])
+{
+ return mod_i2c_mem (cmdtp, 0, flag, argc, argv);
+}
+int do_i2c_reset(cmd_tbl_t * cmdtp, int flag, int argc, char *argv[])
+{
+ i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
+ return 0;
+}
+
+static cmd_tbl_t cmd_i2c_sub[] = {
#if defined(CONFIG_I2C_MUX)
- if (!strncmp(argv[0], bu, 2))
- return do_i2c_add_bus(cmdtp, flag, argc, argv);
+ U_BOOT_CMD_MKENT(bus, 1, 1, do_i2c_add_bus, , ),
#endif /* CONFIG_I2C_MUX */
- if (!strncmp(argv[0], sp, 2))
- return do_i2c_bus_speed(cmdtp, flag, argc, argv);
+ U_BOOT_CMD_MKENT(crc32, 3, 1, do_i2c_crc, , ),
#if defined(CONFIG_I2C_MULTI_BUS)
- if (!strncmp(argv[0], de, 2))
- return do_i2c_bus_num(cmdtp, flag, argc, argv);
+ U_BOOT_CMD_MKENT(dev, 1, 1, do_i2c_bus_num, , ),
#endif /* CONFIG_I2C_MULTI_BUS */
- if (!strncmp(argv[0], md, 2))
- return do_i2c_md(cmdtp, flag, argc, argv);
- if (!strncmp(argv[0], mm, 2))
- return mod_i2c_mem (cmdtp, 1, flag, argc, argv);
- if (!strncmp(argv[0], mw, 2))
- return do_i2c_mw(cmdtp, flag, argc, argv);
- if (!strncmp(argv[0], nm, 2))
- return mod_i2c_mem (cmdtp, 0, flag, argc, argv);
- if (!strncmp(argv[0], cr, 2))
- return do_i2c_crc(cmdtp, flag, argc, argv);
- if (!strncmp(argv[0], pr, 2))
- return do_i2c_probe(cmdtp, flag, argc, argv);
- if (!strncmp(argv[0], re, 2)) {
- i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
- return 0;
- }
- if (!strncmp(argv[0], lo, 2))
- return do_i2c_loop(cmdtp, flag, argc, argv);
+ U_BOOT_CMD_MKENT(loop, 3, 1, do_i2c_loop, , ),
+ U_BOOT_CMD_MKENT(md, 3, 1, do_i2c_md, , ),
+ U_BOOT_CMD_MKENT(mm, 2, 1, do_i2c_mm, , ),
+ U_BOOT_CMD_MKENT(mw, 3, 1, do_i2c_mw, , ),
+ U_BOOT_CMD_MKENT(nm, 2, 1, do_i2c_nm, , ),
+ U_BOOT_CMD_MKENT(probe, 0, 1, do_i2c_probe, , ),
+ U_BOOT_CMD_MKENT(reset, 0, 1, do_i2c_reset, , ),
#if defined(CONFIG_CMD_SDRAM)
- if (!strncmp(argv[0], sd, 2))
- return do_sdram(cmdtp, flag, argc, argv);
+ U_BOOT_CMD_MKENT(sdram, 1, 1, do_i2c_sdram, , ),
#endif
- cmd_usage(cmdtp);
- return 0;
+ U_BOOT_CMD_MKENT(speed, 1, 1, do_i2c_bus_speed, , ),
+};
+
+int do_i2c(cmd_tbl_t * cmdtp, int flag, int argc, char *argv[])
+{
+ cmd_tbl_t *c;
+
+ /* Strip off leading 'i2c' command argument */
+ argc--;
+ argv++;
+
+ c = find_cmd_tbl(argv[0], cmd_i2c_sub[0], ARRAY_SIZE(cmd_i2c_sub));
+
+ if (c) {
+ return c-cmd(cmdtp, flag, argc, argv);
+ } else {
+ cmd_usage(cmdtp);
+ return 1;
+ }
}
/***/
--
1.5.4.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mcf 5307
angelo wrote: Hi Wolfgang, i didn't know it is stone-age, anyway, it is still well-sold in the Freescale site, quite cheap and suit perfectly my needs. Core V4 also is Harvard architecture, and i don't like it. I think he's referring to the u-boot version (1.1.6 is several years old), not the hardware. -Scott Wolfgang Wegner wrote: Hi Angelo, On Wed, Feb 24, 2010 at 11:32:33AM +0100, angelo wrote: Hello all, is ColdFire mcf5307 cpu supported ? in 1.1.6 i found mcf52x2 cpu only. no. Why are you using a stone-age version? In the current git tree a lot of MCF53xx (and MCF54xx) are supported, too. There is no direct support for MCF5307, but considering they use the same processor core adding support for it starting from one of the more modern MCF53xx parts should be possible. Regards, Wolfgang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cmd_i2c.c: added i2c read to memory function
Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com
---
common/cmd_i2c.c | 60 ++
1 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/common/cmd_i2c.c b/common/cmd_i2c.c
index 1dd4df3..552b4e5 100644
--- a/common/cmd_i2c.c
+++ b/common/cmd_i2c.c
@@ -154,6 +154,64 @@ int i2c_set_bus_speed(unsigned int)
*/
#define DISP_LINE_LEN 16
+/*
+ * Syntax:
+ * i2c read {i2c_chip} {devaddr}{.0, .1, .2} {len} {memaddr}
+ */
+
+int do_i2c_read ( cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+ u_char chip;
+ uintdevaddr, alen, length;
+ u_char *memaddr;
+ int j;
+
+ if (argc != 5) {
+ cmd_usage(cmdtp);
+ return 1;
+ }
+
+ /*
+* I2C chip address
+*/
+ chip = simple_strtoul(argv[1], NULL, 16);
+
+ /*
+* I2C data address within the chip. This can be 1 or
+* 2 bytes long. Some day it might be 3 bytes long :-).
+*/
+ devaddr = simple_strtoul(argv[2], NULL, 16);
+ alen = 1;
+ for (j = 0; j 8; j++) {
+ if (argv[2][j] == '.') {
+ alen = argv[2][j+1] - '0';
+ if (alen 3) {
+ cmd_usage(cmdtp);
+ return 1;
+ }
+ break;
+ } else if (argv[2][j] == '\0')
+ break;
+ }
+
+ /*
+* Length is the number of objects, not number of bytes.
+*/
+ length = simple_strtoul(argv[3], NULL, 16);
+
+ /*
+* memaddr is the address where to store things in memory
+*/
+ memaddr = (u_char *)simple_strtoul(argv[4], NULL, 16);
+
+ if (i2c_read(chip, devaddr, alen, memaddr, length) != 0)
+ {
+ puts (Error reading the chip.\n);
+ return 1;
+ }
+ return 0;
+}
+
int do_i2c_md ( cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
{
u_char chip;
@@ -1272,6 +1330,7 @@ static cmd_tbl_t cmd_i2c_sub[] = {
U_BOOT_CMD_MKENT(mw, 3, 1, do_i2c_mw, , ),
U_BOOT_CMD_MKENT(nm, 2, 1, do_i2c_nm, , ),
U_BOOT_CMD_MKENT(probe, 0, 1, do_i2c_probe, , ),
+ U_BOOT_CMD_MKENT(read, 5, 1, do_i2c_read, , ),
U_BOOT_CMD_MKENT(reset, 0, 1, do_i2c_reset, , ),
#if defined(CONFIG_CMD_SDRAM)
U_BOOT_CMD_MKENT(sdram, 1, 1, do_i2c_sdram, , ),
@@ -1316,6 +1375,7 @@ U_BOOT_CMD(
i2c nm chip address[.0, .1, .2] - write to I2C device (constant
address)\n
i2c crc32 chip address[.0, .1, .2] count - compute CRC32 checksum\n
i2c probe - show devices on the I2C bus\n
+ i2c read chip address[.0, .1, .2] length memaddress - read to memory
\n
i2c reset - re-init the I2C Controller\n
#if defined(CONFIG_CMD_SDRAM)
i2c sdram chip - print SDRAM configuration information\n
--
1.5.4.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cmd_i2c.c: reduced subaddress length to 3 bytes
according to some of the comments the subaddress length is 1 or 2, but we are
being
prepared for the case it becomes 3. However the code also accepted 4.
This repairs this by changing the constand 4 to 3.
Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com
---
common/cmd_i2c.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/common/cmd_i2c.c b/common/cmd_i2c.c
index 62cbd33..7531702 100644
--- a/common/cmd_i2c.c
+++ b/common/cmd_i2c.c
@@ -193,7 +193,7 @@ int do_i2c_md ( cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[])
for (j = 0; j 8; j++) {
if (argv[2][j] == '.') {
alen = argv[2][j+1] - '0';
- if (alen 4) {
+ if (alen 3) {
cmd_usage(cmdtp);
return 1;
}
@@ -287,7 +287,7 @@ int do_i2c_mw ( cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[])
for (j = 0; j 8; j++) {
if (argv[2][j] == '.') {
alen = argv[2][j+1] - '0';
- if (alen 4) {
+ if (alen 3) {
cmd_usage(cmdtp);
return 1;
}
@@ -361,7 +361,7 @@ int do_i2c_crc (cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[])
for (j = 0; j 8; j++) {
if (argv[2][j] == '.') {
alen = argv[2][j+1] - '0';
- if (alen 4) {
+ if (alen 3) {
cmd_usage(cmdtp);
return 1;
}
@@ -451,7 +451,7 @@ mod_i2c_mem(cmd_tbl_t *cmdtp, int incrflag, int flag, int
argc, char *argv[])
for (j = 0; j 8; j++) {
if (argv[2][j] == '.') {
alen = argv[2][j+1] - '0';
- if (alen 4) {
+ if (alen 3) {
cmd_usage(cmdtp);
return 1;
}
@@ -607,7 +607,7 @@ int do_i2c_loop(cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[])
for (j = 0; j 8; j++) {
if (argv[2][j] == '.') {
alen = argv[2][j+1] - '0';
- if (alen 4) {
+ if (alen 3) {
cmd_usage(cmdtp);
return 1;
}
--
1.5.4.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cmd_bootm.c: made subcommand array static
Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com
---
common/cmd_bootm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 23ab0c4..827d542 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -462,7 +462,7 @@ static int bootm_start_standalone(ulong iflag, int argc,
char *argv[])
/* we overload the cmd field with our state machine info instead of a
* function pointer */
-cmd_tbl_t cmd_bootm_sub[] = {
+static cmd_tbl_t cmd_bootm_sub[] = {
U_BOOT_CMD_MKENT(start, 0, 1, (void *)BOOTM_STATE_START, , ),
U_BOOT_CMD_MKENT(loados, 0, 1, (void *)BOOTM_STATE_LOADOS, , ),
#if defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_SPARC)
--
1.5.4.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cmd_i2c.c: sorted commands alphabetically
Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com --- common/cmd_i2c.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/common/cmd_i2c.c b/common/cmd_i2c.c index e54fc20..1dd4df3 100644 --- a/common/cmd_i2c.c +++ b/common/cmd_i2c.c @@ -1302,13 +1302,14 @@ int do_i2c(cmd_tbl_t * cmdtp, int flag, int argc, char *argv[]) U_BOOT_CMD( i2c, 6, 1, do_i2c, I2C sub-system, - speed [speed] - show or set I2C bus speed\n #if defined(CONFIG_I2C_MUX) - i2c bus [muxtype:muxaddr:muxchannel] - add a new bus reached over muxes\n + bus [muxtype:muxaddr:muxchannel] - add a new bus reached over muxes\ni2c #endif /* CONFIG_I2C_MUX */ + crc32 chip address[.0, .1, .2] count - compute CRC32 checksum\n #if defined(CONFIG_I2C_MULTI_BUS) i2c dev [dev] - show or set current I2C bus\n #endif /* CONFIG_I2C_MULTI_BUS */ + i2c loop chip address[.0, .1, .2] [# of objects] - looping read of device\n i2c md chip address[.0, .1, .2] [# of objects] - read from I2C device\n i2c mm chip address[.0, .1, .2] - write to I2C device (auto-incrementing)\n i2c mw chip address[.0, .1, .2] value [count] - write to I2C device (fill)\n @@ -1316,11 +1317,10 @@ U_BOOT_CMD( i2c crc32 chip address[.0, .1, .2] count - compute CRC32 checksum\n i2c probe - show devices on the I2C bus\n i2c reset - re-init the I2C Controller\n - i2c loop chip address[.0, .1, .2] [# of objects] - looping read of device #if defined(CONFIG_CMD_SDRAM) - \n - i2c sdram chip - print SDRAM configuration information + i2c sdram chip - print SDRAM configuration information\n #endif + i2c speed [speed] - show or set I2C bus speed ); #if defined(CONFIG_I2C_MUX) -- 1.5.4.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: Corrected EBC register bit definitions
Corrected the bit field positions of the external master priority low and the external master priority high values in the EBC configuration register. These bit field positions differ between PPC405 and PPC440 processors Signed-off-by: Eugene O'Brien eugene.obr...@advantechamt.com --- include/asm-ppc/ppc4xx-ebc.h | 24 ++-- 1 files changed, 18 insertions(+), 6 deletions(-) diff --git a/include/asm-ppc/ppc4xx-ebc.h b/include/asm-ppc/ppc4xx-ebc.h index 9680f70..9c17e46 100644 --- a/include/asm-ppc/ppc4xx-ebc.h +++ b/include/asm-ppc/ppc4xx-ebc.h @@ -25,14 +25,24 @@ #define _PPC4xx_EBC_H_ /* - * Currently there are two register layout versions for the - * IBM EBC core used on 4xx PPC's: + * Currently there are two register layout versions for the IBM EBC core + * used on 4xx PPC's. The following grouping lists the first layout. + * Within this group there is a slight variation concerning the bit field + * position of the EMPL and EMPH fields: */ #if defined(CONFIG_405CR) || defined(CONFIG_405GP) || \ defined(CONFIG_405EP) || \ defined(CONFIG_440EP) || defined(CONFIG_440GR) || \ defined(CONFIG_440EPX) || defined(CONFIG_440GRX) #define CONFIG_EBC_PPC4xx_IBM_VER1 +#if defined(CONFIG_405CR) || defined(CONFIG_405GP) || \ +defined(CONFIG_405EP) +#define EBC_CFG_EMPH_POS 8 +#define EBC_CFG_EMPL_POS 6 +#else +#define EBC_CFG_EMPH_POS 6 +#define EBC_CFG_EMPL_POS 8 +#endif #endif /* @@ -143,10 +153,12 @@ #define EBC_CFG_EBTC_MASK PPC_REG_VAL(0, 0x1) #define EBC_CFG_EBTC_HIPPC_REG_VAL(0, 0x0) #define EBC_CFG_EBTC_DRIVENPPC_REG_VAL(0, 0x1) -#define EBC_CFG_EMPH_MASK PPC_REG_VAL(6, 0x3) -#define EBC_CFG_EMPH_ENCODE(n) PPC_REG_VAL(6, (static_cast(u32, n)) 0x3) -#define EBC_CFG_EMPL_MASK PPC_REG_VAL(8, 0x3) -#define EBC_CFG_EMPL_ENCODE(n) PPC_REG_VAL(8, (static_cast(u32, n)) 0x3) +#define EBC_CFG_EMPH_MASK PPC_REG_VAL(EBC_CFG_EMPH_POS, 0x3) +#define EBC_CFG_EMPH_ENCODE(n) PPC_REG_VAL(EBC_CFG_EMPH_POS, \ + (static_cast(u32, n)) 0x3) +#define EBC_CFG_EMPL_MASK PPC_REG_VAL(EBC_CFG_EMPL_POS, 0x3) +#define EBC_CFG_EMPL_ENCODE(n) PPC_REG_VAL(EBC_CFG_EMPH_POS, \ + (static_cast(u32, n)) 0x3) #define EBC_CFG_CSTC_MASK PPC_REG_VAL(9, 0x1) #define EBC_CFG_CSTC_HIPPC_REG_VAL(9, 0x0) #define EBC_CFG_CSTC_DRIVENPPC_REG_VAL(9, 0x1) -- 1.7.0.rc1.10.gb8bb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] my recent i2c patches
Hi Frans, Le 24/02/2010 20:32, Frans Meulenbroeks a écrit : If anyone can educate me how to get the patches numbered, please (I have sent this by git send-email 0001... 0002 etc in one command git format-patch -n -n, --numbered Name output in [PATCH n/m] format, even with a single patch. Frans. PS: I once read somewhere that it is also possible to add additional text in a patch only for the mailing list, so not part of the commit message. However, I could not find that info any more. If someone by any chance knows that please drop me a mail. maybe this option to git format-patch can help you even if that's not exactly what you ask here : --cover-letter In addition to the patches, generate a cover letter file containing the shortlog and the overall diffstat. You can fill in a description in the file before sending it out. Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] my recent i2c patches
Dear Frans Meulenbroeks, In message ac9c93b11002241132j50c1c4a2p5e4407da7f096...@mail.gmail.com you wrote: One word wrt the i2c patches I just mailed. It was my impression that git send-email would include the number in the patch but as can be seen that was not the case. Git-send-email does not insert anything, it just sends the emails. If you want numbered patches, you have to add the numbers when formatting the patches - i. e. use git-format-patch -n The patches are to be applied in the following order: 0001-cmd_i2c.c-reduced-subaddress-length-to-3-bytes.patch 0002-cmd_bootm.c-made-subcommand-array-static.patch 0003-cmd_i2c.c-reworked-subcommand-handling.patch 0004-cmd_i2c.c-sorted-commands-alphabetically.patch 0005-cmd_i2c.c-added-i2c-read-to-memory-function.patch Thanks. PS: I once read somewhere that it is also possible to add additional text in a patch only for the mailing list, so not part of the commit message. Indeed. Text below the --- line is comment. 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 Good manners are the settled medium of social, as specie is of commercial, life; returns are equally expected for both. - Lord Chesterfield _Letters to his Son_, 25 December 1753 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] setexpr and memory access
Dear Frans, In message ac9c93b11002240514w75d010ao8b3a52ca8ef01...@mail.gmail.com you wrote: setexpr uses A op B and one of the possibilities for op is a *. If we also allow a * to dereference things (like done in itest) we could get something like setexpr result *3 * *4 Not sure if that is a desirable syntax. Agreed it looks ugly, but it's the logical consequence of what we are using so far. Any other solution would probably require changes in some other areas. Considering that, your suggestion looks fine 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 Don't tell me how hard you work. Tell me how much you get done. - James J. Ling ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] coldfire support
Thirumalai, These ColdFire processors (MCF52277, MCF5235, MCF5249, MCF5253, MCF5271, MCF5272, MCF5275, MCF5282, MCF5329, MCF5373, MCF5445x, and MCF547x_8x) are supported by u-boot. Like Wolfgang Wegner mentioned, you can download the ToolChain at http://www.codesourcery.com/sgpp/lite/coldfire. As for the Linux, we use different repository site. http://www.bitshrine.org/gpp/ Regards, TsiChung On Mon, Feb 22, 2010 at 5:00 AM, Thirumalai thirumala...@datapatterns.co.in wrote: Hi denx, I just want to know whether the coldfire processor is supported by u-boot and what toolchains need to be used for compilation. Whether ELDK will support or not ? Thank you Thirumalai ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot coldfire linux and fdt
Hi Philippe, ColdFire Linux does use the MAC address, the issue is that the kernel does not pass the MAC address properly to the FEC driver. I will pass up this issue to the Linux team to have it fix soon. The bd_info struct is still there and has not removed from u-boot source. There is a plan of implementing fdt. Regards, TsiChung On Sun, Feb 21, 2010 at 6:31 AM, Philippe De Muyter p...@macqel.be wrote: Hello Tsi Chung Liew, I have installed u-boot and linux on a in-house-made coldfire mcf5484 based board. As u-boot currently supports mcf5484-based development boards, I used that as a starting point for the u-boot port for our in-house board. For linux unfortunately I needed to stick with the ltib-based version of linux-2.6.25 for mcf5484-based development boards distributed by freescale. I have discovered the hard way that that version of linux does not use the mac addresses for the ethernet ports as known by u-boot under the names ethaddr and eth1addr, but uses the same wrong mac-address for all the boards. Now it seems that the old way to communicate the mac addresses from u-boot to linux using the struct bd_info has been deprecated and removed from u-boot sources. I see some fdt-related functions in the u-boot sources, but I am not sure that the fdt blob is given to linux, or that linux for coldfire expects to get and use a fdt blob. Can you enlighten me regarding that point, especially for mcf5484 boards ? Thanks in advance Philippe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
