Re: [U-Boot] [PATCH V5 2/4] serial: Add Tegra2 serial port support
On 01/22/11 01:06, Tom Warren wrote: > Signed-off-by: Tom Warren > --- [ snip ] > +/* > + * Routine: pin_mux_uart > + * Description: setup the pin muxes/tristate values for a UART > + */ > +static void pin_mux_uart(void) > +{ > + pinmux_tri_ctlr *const pmt = (pinmux_tri_ctlr *)NV_PA_APB_MISC_BASE; > + u32 reg; > + > +#if CONFIG_TEGRA2_ENABLE_UARTA > + reg = readl(&pmt->pmt_ctl_c); > + reg &= 0xFFF0; /* IRRX_/IRTX_SEL [19:16] = 00 UARTA */ > + writel(reg, &pmt->pmt_ctl_c); > + > + reg = readl(&pmt->pmt_tri_a); > + reg &= ~Z_IRRX; /* Z_IRRX = normal (0) */ > + reg &= ~Z_IRTX; /* Z_IRTX = normal (0) */ > + writel(reg, &pmt->pmt_tri_a); > +#endif /* CONFIG_TEGRA2_ENABLE_UARTA */ > +#if CONFIG_TEGRA2_ENABLE_UARTD > + reg = readl(&pmt->pmt_ctl_b); > + reg &= 0xFFF3; /* GMC_SEL [3:2] = 00, UARTD */ > + writel(reg, &pmt->pmt_ctl_b); > + > + reg = readl(&pmt->pmt_tri_a); > + reg &= ~Z_GMC; /* Z_GMC = normal (0) */ > + writel(reg, &pmt->pmt_tri_a); > +#endif /* CONFIG_TEGRA2_ENABLE_UARTD */ As I've already pointed out (1) this covers only one possibility of UART pin muxing options. I agree that it makes sense when this is a part of the board-specific code. However, forcing specific pins configuration in the generic driver seems problematic to me, even if most Tegra2 boards use the same configuration. As a side note, I'd prefer to have all the pin multiplexing defined in one place in board file rather than scattered among different drivers. (1) http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/92887/focus=93233 -- Sincerely yours, Mike. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot v2010.12 released - Merge Window OPEN
Hello, Am 22.12.2010 21:15, schrieb Wolfgang Denk: > * > * Currently,>100 ARM boards are *broken* and *do not compile*. * > * > > Board maintainers or othe rinterested parties are requested to > adapt their boards to the new code in the timeframe of the > upcoming release v2010.03; all boards that have not been converted > by then, i. e. that are still broken then, are considered > unmaintained and without interest to the community and will be > removed. Maybe just a #error Code for this board doesn't compile since at least #date# or a similiar message in foo_config.h would be a way to inform people early that the code needs some work. This way the source for the board could be visible for some more time in the repository. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Default base for numbers
Hello, I've stumbled over the fact that the length parameter for sha1sum uses 16 as default base, which I found a bit confusing. E.g. - U-Boot>> tftp $loadaddr uImage ... done Bytes transferred = 1976384 (1e2840 hex) U-Boot>> sha1sum $loadaddr 1976384 SHA1 for 0080 ... 02176383 ==> 8d9cc7b167b6d1471d73d46cfc3b374091de88a6 U-Boot>> sha1sum $loadaddr 0x1e2840 SHA1 for 0080 ... 009e283f ==> fde54f7409c785b7929d36624f77f71abd30282a - (The second one is correct) Is the base 16 as default for numbers common for commands in u-boot or is that just a problem of md5sum and sha1sum? Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Switch from archive libraries to partial linking
On Jan 25, 2011, at 12:36 AM, Wolfgang Denk wrote: > Dear Kumar Gala, > > In message <356989c7-fa92-46d5-9fb6-5f9332ecb...@kernel.crashing.org> you > wrote: >> >> The issue is that the code under post/lib_powerpc/fpu/* is compiled with: >> >> CFLAGS := $(shell echo $(CFLAGS) | sed s/-msoft-float//) >> CFLAGS += -mhard-float -fkeep-inline-functions >> >> We need to see if we can avoid building the whole post/lib_powerpc/fpu/* dir >> if CONFIG_POST_FPU isn't set in CONFIG_POST. > > This might solve the warning in most cases - but what abut these where > CONFIG_POST_FPU is defined? I mean, it is inherent that these tests > need to execute FP instructions. > > Best regards, > > Wolfgang Denk Actually we've dealt with this already: commit ce82ff05388b5ddafdf6082ef0776cce72c40b1c Author: Yuri Tikhonov Date: Sat Dec 20 14:54:21 2008 +0300 FPU POST: fix warnings when building with 2.18 binutils When compile u-boot with the 2.18 binutils the following warning messages for each object file in post/lib_ppc/fpu/ is produced at the linking stage: post/libpost.a(acc1.o) uses hard float, u-boot uses soft-float ... ... However I think we just need to move the code a bit. Will post a patch - k - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm, keymile: remove unneeded code
On first HW versions the BOCO FPGA was behind a MUX device. These HW versions are not supported anymore. And therefore this code can be removed, it is already unused. Signed-off-by: Holger Brunck --- board/keymile/km_arm/km_arm.c |7 --- 1 files changed, 0 insertions(+), 7 deletions(-) diff --git a/board/keymile/km_arm/km_arm.c b/board/keymile/km_arm/km_arm.c index 2e20644..dcf0f42 100644 --- a/board/keymile/km_arm/km_arm.c +++ b/board/keymile/km_arm/km_arm.c @@ -41,9 +41,6 @@ DECLARE_GLOBAL_DATA_PTR; -static int io_dev; -extern I2C_MUX_DEVICE *i2c_mux_ident_muxstring (uchar *buf); - /* Multi-Purpose Pins Functionality configuration */ u32 kwmpp_config[] = { MPP0_NF_IO2, @@ -122,13 +119,9 @@ int ethernet_present(void) int misc_init_r(void) { - I2C_MUX_DEVICE *i2cdev; char *str; int mach_type; - /* add I2C Bus for I/O Expander */ - i2cdev = i2c_mux_ident_muxstring((uchar *)"pca9554a:70:a"); - io_dev = i2cdev->busid; puts("Piggy:"); if (ethernet_present() == 0) puts (" not"); -- 1.7.0.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc: Fix FPU post related link warnings
If we built POST on PPC's that didn't enable CONFIG_SYS_POST_FPU we'd get the following warning with newer toolchains: powerpc-linux-gnu-ld: Warning: lib_powerpc/fpu/libpostpowerpcfpu.o uses hard float, libpost.o uses soft float We actually worked around this sometime ago with the following commit: commit ce82ff05388b5ddafdf6082ef0776cce72c40b1c Author: Yuri Tikhonov Date: Sat Dec 20 14:54:21 2008 +0300 FPU POST: fix warnings when building with 2.18 binutils However, this only took into effect if CONFIG_SYS_POST_FPU was enabled. We can simply move the GNU_FPOST_ATTR out of the CONFIG_SYS_POST_FPU ifdef block to address the issue. Signed-off-by: Kumar Gala --- Wolfgang, I request we think about include this patch in v2011.03 tree so we can all stop getting these build warnings :) - k post/lib_powerpc/fpu/20001122-1.c |4 ++-- post/lib_powerpc/fpu/20010114-2.c |4 ++-- post/lib_powerpc/fpu/20010226-1.c |4 ++-- post/lib_powerpc/fpu/980619-1.c |4 ++-- post/lib_powerpc/fpu/acc1.c |4 ++-- post/lib_powerpc/fpu/compare-fp-1.c |4 ++-- post/lib_powerpc/fpu/fpu.c|4 ++-- post/lib_powerpc/fpu/mul-subnormal-single-1.c |4 ++-- 8 files changed, 16 insertions(+), 16 deletions(-) diff --git a/post/lib_powerpc/fpu/20001122-1.c b/post/lib_powerpc/fpu/20001122-1.c index bef80c5..4af300d 100644 --- a/post/lib_powerpc/fpu/20001122-1.c +++ b/post/lib_powerpc/fpu/20001122-1.c @@ -28,10 +28,10 @@ #include -#if CONFIG_POST & CONFIG_SYS_POST_FPU - GNU_FPOST_ATTR +#if CONFIG_POST & CONFIG_SYS_POST_FPU + int fpu_post_test_math1 (void) { volatile double a, *p; diff --git a/post/lib_powerpc/fpu/20010114-2.c b/post/lib_powerpc/fpu/20010114-2.c index ee564e8..dab4d7e 100644 --- a/post/lib_powerpc/fpu/20010114-2.c +++ b/post/lib_powerpc/fpu/20010114-2.c @@ -28,10 +28,10 @@ #include -#if CONFIG_POST & CONFIG_SYS_POST_FPU - GNU_FPOST_ATTR +#if CONFIG_POST & CONFIG_SYS_POST_FPU + static float rintf (float x) { volatile float TWO23 = 8388608.0; diff --git a/post/lib_powerpc/fpu/20010226-1.c b/post/lib_powerpc/fpu/20010226-1.c index 099ca4a..c644bc9 100644 --- a/post/lib_powerpc/fpu/20010226-1.c +++ b/post/lib_powerpc/fpu/20010226-1.c @@ -28,10 +28,10 @@ #include -#if CONFIG_POST & CONFIG_SYS_POST_FPU - GNU_FPOST_ATTR +#if CONFIG_POST & CONFIG_SYS_POST_FPU + int fpu_post_test_math3 (void) { volatile long double dfrom = 1.1; diff --git a/post/lib_powerpc/fpu/980619-1.c b/post/lib_powerpc/fpu/980619-1.c index 46a31ae..0c195c1 100644 --- a/post/lib_powerpc/fpu/980619-1.c +++ b/post/lib_powerpc/fpu/980619-1.c @@ -28,10 +28,10 @@ #include -#if CONFIG_POST & CONFIG_SYS_POST_FPU - GNU_FPOST_ATTR +#if CONFIG_POST & CONFIG_SYS_POST_FPU + int fpu_post_test_math4 (void) { volatile float reale = 1.0f; diff --git a/post/lib_powerpc/fpu/acc1.c b/post/lib_powerpc/fpu/acc1.c index 9fca9b3..4dc1362 100644 --- a/post/lib_powerpc/fpu/acc1.c +++ b/post/lib_powerpc/fpu/acc1.c @@ -28,10 +28,10 @@ #include -#if CONFIG_POST & CONFIG_SYS_POST_FPU - GNU_FPOST_ATTR +#if CONFIG_POST & CONFIG_SYS_POST_FPU + static double func (const double *array) { double d = *array; diff --git a/post/lib_powerpc/fpu/compare-fp-1.c b/post/lib_powerpc/fpu/compare-fp-1.c index f836b29..a0859f8 100644 --- a/post/lib_powerpc/fpu/compare-fp-1.c +++ b/post/lib_powerpc/fpu/compare-fp-1.c @@ -30,10 +30,10 @@ #include -#if CONFIG_POST & CONFIG_SYS_POST_FPU - GNU_FPOST_ATTR +#if CONFIG_POST & CONFIG_SYS_POST_FPU + static int failed; #define TEST(c) if ((c) != ok) failed++ diff --git a/post/lib_powerpc/fpu/fpu.c b/post/lib_powerpc/fpu/fpu.c index 3f3adea..a4369f1 100644 --- a/post/lib_powerpc/fpu/fpu.c +++ b/post/lib_powerpc/fpu/fpu.c @@ -36,12 +36,12 @@ #include +GNU_FPOST_ATTR + #if CONFIG_POST & CONFIG_SYS_POST_FPU #include -GNU_FPOST_ATTR - extern int fpu_status (void); extern void fpu_enable (void); extern void fpu_disable (void); diff --git a/post/lib_powerpc/fpu/mul-subnormal-single-1.c b/post/lib_powerpc/fpu/mul-subnormal-single-1.c index 1f3732d..23a3f30 100644 --- a/post/lib_powerpc/fpu/mul-subnormal-single-1.c +++ b/post/lib_powerpc/fpu/mul-subnormal-single-1.c @@ -30,10 +30,10 @@ #include -#if CONFIG_POST & CONFIG_SYS_POST_FPU - GNU_FPOST_ATTR +#if CONFIG_POST & CONFIG_SYS_POST_FPU + union uf { unsigned int u; -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Default base for numbers
Dear Alexander Holler, In message <4d3e8f9d.7040...@ahsoftware.de> you wrote: > > I've stumbled over the fact that the length parameter for sha1sum uses > 16 as default base, which I found a bit confusing. Read the documentation. > Is the base 16 as default for numbers common for commands in u-boot or > is that just a problem of md5sum and sha1sum? With very few exceptions all commands use base 16 input. I recommend you start reading the manual. 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 panic: can't find / ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/85xx: Extend ethernet device tree stashing parameters for "fsl, etsec2"
From: Pankaj Chauhan In a manner similar to passing ethernet stashing parameters into device tree for "gianfar", extend the support to the "fsl,etsec2" as well. Signed-off-by: Pankaj Chauhan Signed-off-by: Sandeep Gopalpet Signed-off-by: Kumar Gala --- arch/powerpc/cpu/mpc85xx/fdt.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/cpu/mpc85xx/fdt.c b/arch/powerpc/cpu/mpc85xx/fdt.c index 00fa752..6ed0284 100644 --- a/arch/powerpc/cpu/mpc85xx/fdt.c +++ b/arch/powerpc/cpu/mpc85xx/fdt.c @@ -338,6 +338,9 @@ void fdt_add_enet_stashing(void *fdt) do_fixup_by_compat_u32(fdt, "gianfar", "rx-stash-len", 96, 1); do_fixup_by_compat_u32(fdt, "gianfar", "rx-stash-idx", 0, 1); + do_fixup_by_compat(fdt, "fsl,etsec2", "bd-stash", NULL, 0, 1); + do_fixup_by_compat_u32(fdt, "fsl,etsec2", "rx-stash-len", 96, 1); + do_fixup_by_compat_u32(fdt, "fsl,etsec2", "rx-stash-idx", 0, 1); } #if defined(CONFIG_SYS_DPAA_FMAN) || defined(CONFIG_SYS_DPAA_PME) -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Default base for numbers
Am 25.01.2011 10:16, schrieb Wolfgang Denk: > Dear Alexander Holler, > > In message<4d3e8f9d.7040...@ahsoftware.de> you wrote: >> >> I've stumbled over the fact that the length parameter for sha1sum uses >> 16 as default base, which I found a bit confusing. > > Read the documentation. > >> Is the base 16 as default for numbers common for commands in u-boot or >> is that just a problem of md5sum and sha1sum? > > With very few exceptions all commands use base 16 input. I recommend > you start reading the manual. Thanks for the pointer, if someone else is interested, it is described in chapter 5.9. U-Boot Command Line Interface. Easy to find. ;) Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Change the visible output for transfers to display hex numbers
When files were transfered the output is currently - Bytes transferred = 1976384 (1e2840 hex) - Using the decimal length as input for other commands conflicts with the the default base of 16 needed. Change the output to - Bytes transferred = 0x1e2840 (1976384 bytes) - to reflect what should be used as input for other commands. Signed-off-by: Alexander Holler --- net/net.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/net.c b/net/net.c index a609632..a454411 100644 --- a/net/net.c +++ b/net/net.c @@ -528,7 +528,7 @@ restart: case NETLOOP_SUCCESS: if (NetBootFileXferSize > 0) { char buf[20]; - printf("Bytes transferred = %ld (%lx hex)\n", + printf("Bytes transferred = 0x%lx (%ld bytes)\n", NetBootFileXferSize, NetBootFileXferSize); sprintf(buf, "%lX", NetBootFileXferSize); -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Uboot can't start kernel after change from version 2009.01 to 2010.09
Hi, I change my uboot version and after it the uboot don't starts the same linux kernel: ## Booting kernel from Legacy Image at 1006 ... Image Name: Linux Kernel Image Type: ARM Linux Kernel Image (gzip compressed) Data Size:1178673 Bytes = 1.1 MiB Load Address: 20008000 Entry Point: 20008000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Starting kernel ... *LOG END* It's a board simular to the at91rm9200dk. I start the kernel with bootcmd2=setenv bootargs root=/dev/mtdblock9 rootfstype=squashfs ETHADDR=$(ethaddr) RUNNING=$(runningimage) CFGFS=mtdblock10;bootm 0x3006 run bootcmd2 Can anybody give me a hint where I had to search for the error? Mit freundlichen Grüßen Maik Hänig ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc, mgcoge: add DIP switch detection
From: Andreas Huber This reads the DIP switch on mgcoge. The DIP switch is connected to the BFTICU (0x4089) FPGA. If the DIP switch is set the environment variable 'actual_bank' is set to 0 and starts the SW in bank0. Signed-off-by: Andreas Huber Signed-off-by: Holger Brunck --- board/keymile/mgcoge/mgcoge.c | 18 ++ include/configs/mgcoge.h |5 + 2 files changed, 23 insertions(+), 0 deletions(-) diff --git a/board/keymile/mgcoge/mgcoge.c b/board/keymile/mgcoge/mgcoge.c index 5c9496c..5dcdf37 100644 --- a/board/keymile/mgcoge/mgcoge.c +++ b/board/keymile/mgcoge/mgcoge.c @@ -293,6 +293,24 @@ int checkboard(void) return 0; } +#define DIPSWITCH_OFFSET 0x89 +#define DIPSWITCH_MASK 0x0f + +int last_stage_init(void) +{ + u8 dip_switch; + /* Dip switch */ + dip_switch = readb(CONFIG_SYS_BFTICU_BASE + DIPSWITCH_OFFSET); + dip_switch &= DIPSWITCH_MASK; + /* dip switch 'full reset' or 'db erase' */ + if (dip_switch & 0x1 || dip_switch & 0x2) { + /* start bootloader */ + puts("DIP: Enabled\n"); + setenv("actual_bank", "0"); + } + return 0; +} + /* * Early board initalization. */ diff --git a/include/configs/mgcoge.h b/include/configs/mgcoge.h index 6dec0ee..f1bd32a 100644 --- a/include/configs/mgcoge.h +++ b/include/configs/mgcoge.h @@ -348,4 +348,9 @@ #define OF_TBCLK (bd->bi_busfreq / 4) #define OF_STDOUT_PATH "/soc/cpm/serial@11a90" +/* enable last_stage_init */ +#define CONFIG_LAST_STAGE_INIT 1 +/* bfticu address */ +#define CONFIG_SYS_BFTICU_BASE 0x4000 + #endif /* __CONFIG_H */ -- 1.7.0.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Change the visible output for transfers to display hex numbers
Dear Alexander Holler, In message <1295950537-12363-1-git-send-email-hol...@ahsoftware.de> you wrote: > When files were transfered the output is currently > - > Bytes transferred = 1976384 (1e2840 hex) > - > Using the decimal length as input for other commands conflicts with the > the default base of 16 needed. > > Change the output to > - > Bytes transferred = 0x1e2840 (1976384 bytes) > - > to reflect what should be used as input for other commands. In which way does this reflect what "should be used as input for other commands"? I don't even understand why you use this manually with copy & paste. Why don't you simply refer to the ${filesize} variable? In any case, if you want to change this format, you must change _all_ occurrences of it, i. e. include all the commands that load from external storage (ide, usb, scsi, sata, nand, dataflash, SPI-Flash, ...). 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 Lots of folks confuse bad management with destiny. -- Frank Hubbard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Uboot can't start kernel after change from version 2009.01 to 2010.09
Hi, I change my uboot version and after it the uboot don't starts the same linux kernel: ## Booting kernel from Legacy Image at 1006 ... Image Name: Linux Kernel Image Type: ARM Linux Kernel Image (gzip compressed) Data Size:1178673 Bytes = 1.1 MiB Load Address: 20008000 Entry Point: 20008000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Starting kernel ... *LOG END* It's a board simular to the at91rm9200dk. I start the kernel with bootcmd2=setenv bootargs root=/dev/mtdblock9 rootfstype=squashfs ETHADDR=$(ethaddr) RUNNING=$(runningimage) CFGFS=mtdblock10;bootm 0x3006 run bootcmd2 Can anybody give me a hint where I had to search for the error? Mit freundlichen Grüßen Maik Hänig ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Change the visible output for transfers to display hex numbers
Hello, Am 25.01.2011 11:27, schrieb Wolfgang Denk: > Dear Alexander Holler, > > In message<1295950537-12363-1-git-send-email-hol...@ahsoftware.de> you wrote: >> When files were transfered the output is currently >> - >> Bytes transferred = 1976384 (1e2840 hex) >> - >> Using the decimal length as input for other commands conflicts with the >> the default base of 16 needed. >> >> Change the output to >> - >> Bytes transferred = 0x1e2840 (1976384 bytes) >> - >> to reflect what should be used as input for other commands. > > In which way does this reflect what "should be used as input for other > commands"? > > I don't even understand why you use this manually with copy& paste. > > Why don't you simply refer to the ${filesize} variable? TIMTOWTDI > In any case, if you want to change this format, you must change _all_ > occurrences of it, i. e. include all the commands that load from > external storage (ide, usb, scsi, sata, nand, dataflash, SPI-Flash, > ...). Than I prefer not to change something and live with that unorthogonality. Besides several READMEs, net/net.c is the only source where git grep "Bytes transferred" shows that such an output is used. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Uboot can't start kernel after change from version 2009.01 to 2010.09
Dear Maik Hänig, > Hi, > > > I change my uboot version and after it the uboot don't starts the same > linux kernel: > > ## Booting kernel from Legacy Image at 1006 ... _ > Image Name: Linux Kernel > Image Type: ARM Linux Kernel Image (gzip compressed) > Data Size:1178673 Bytes = 1.1 MiB > Load Address: 20008000 > Entry Point: 20008000 > Verifying Checksum ... OK > Uncompressing Kernel Image ... OK > > Starting kernel ... > > *LOG END* > > > It's a board simular to the at91rm9200dk. I start the kernel with > > bootcmd2=setenv bootargs root=/dev/mtdblock9 rootfstype=squashfs > ETHADDR=$(ethaddr) RUNNING=$(runningimage) CFGFS=mtdblock10;bootm 0x3006 __ > > run bootcmd2 First, I don't understand why those two addresses are not the same. Then, are you sure your "bootcmd2" ist really what you think it is? Try a "printenv" and see whats really there. Should you not have a "console=xxx" in your kernel parameters? Besides once "Starting kernel ..." shows, u-boot is about to give control to the kernel, all future output would be from the kernel itself, probably needing a sane "console=xxx" parameter. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Use optimized memcpy and memset from linux
Am 24.01.2011 21:07, schrieb Wolfgang Denk: > OK - so which results do you see in reallife use, say when loading and > booting an OS? How much boot time can be saved? All tests are done with jadecpu | HEAD(1)| HEAD(1)| HEAD(2)| HEAD(2)| || +patch || +patch | ---+++++ Reset to prompt| 438ms | 330ms | 228ms | 120ms | ||||| TFTP a 3MB img | 4782ms | 3428ms | 3245ms | 2820ms | ||||| FATLOAD USB a 3MB img* | 8515ms | 8510ms | -- | -- | ||||| BOOTM LZO img in RAM | 3473ms | 3168ms | 592ms | 592ms | where CRC is | 615ms | 615ms | 54ms | 54ms | uncompress| 2460ms | 2462ms | 450ms | 451ms | final boot_elf| 376ms | 68ms | 65ms | 65ms | ||||| BOOTM LZO img in FLASH | 3207ms | 2902ms | 1050ms | 1050ms | where CRC is | 600ms | 600ms | 135ms | 135ms | uncompress| 2209ms | 2211ms | 828ms | 828ms | final boot_elf| 376ms | 68ms | 65ms | 65ms | (1) No dcache (2) dcache enabled in board_init *Does not work when dcache is on I think we can see that there seems to be no negativ impact of theses patches when only execution speed is taken into consideration. The gain is noticable when caching is not used or not activated. For pure RAM to RAM copy when caching is activated the patch didn't change anything. Here are some additional numbers for copying a 1.4MB image from NOR to RAM: HEAD : 134ms HEAD + patch : 72ms HEAD + dcache : 120ms HEAD + dcache + patch : 70ms So, for copy actions from flash to RAM there is also an improvement. As boot times are a bit critical or us every improvement > 10ms is interesting for us. > I guess the speed improvemnt you see for a few large copy operations > is just one side - probably there will be slower excution (due to the > effort to set up the operations) for the (many more frequent) small > operations. In addition, there is an increase of the memory footprint > of nearly 1 kB. > > I think additional measuremnts need to be done - for example, we > should check how the execution times change for typical operations > like TFTP download, reading from NAND flash and MMC/SDcard, booting a > Linux kernel etc. As the test above show there is no negative performance impact with the test cases I have done. As we don't use Linux here I can't test this. Maybe someone other can jump in here. > Also, it should be possible to enable this feature consditionally, so > users can decide wether speed or size is more important in their > configurations. Would it be an option to use the CONFIG entries CONFIG_USE_ARCH_MEMCPY and CONFIG_USE_ARCH_MEMSET to enable that feature? If that is OK I can send a new version of the patch. The only problem I see with this approach is that there are architectures which already have their own implementations which are then not affected by these config options. Regards Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Uboot can't start kernel after change from version 2009.01 to 2010.09
Dear Reinhard, sorry I copied the wrong log: U-Boot 2010.09 (Jan 24 2011 - 17:45:54) I2C: ready DRAM: 64 MiB Flash: 32 MiB In:serial Out: serial Err: serial Hit any key to stop autoboot: 0 ## Booting kernel from Legacy Image at 3006 ... Image Name: Linux Kernel Image Type: ARM Linux Kernel Image (gzip compressed) Data Size:1084127 Bytes = 1 MiB Load Address: 20008000 Entry Point: 20008000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Starting kernel ... I have to kernel Images in flash. The bootcmd is copied from printenv. With the uboot version 2009.01 it works well. Is it nessesary to set a console parameter in the bootcmd in uboot version 2010.09? Mit freundlichen Grüßen Maik Hänig Am 25.01.2011 11:54, schrieb Reinhard Meyer: > Dear Maik Hänig, >> Hi, >> >> >> I change my uboot version and after it the uboot don't starts the same >> linux kernel: >> >> ## Booting kernel from Legacy Image at 1006 ... > _ >> Image Name: Linux Kernel >> Image Type: ARM Linux Kernel Image (gzip compressed) >> Data Size:1178673 Bytes = 1.1 MiB >> Load Address: 20008000 >> Entry Point: 20008000 >> Verifying Checksum ... OK >> Uncompressing Kernel Image ... OK >> >> Starting kernel ... >> >> *LOG END* >> >> >> It's a board simular to the at91rm9200dk. I start the kernel with >> >> bootcmd2=setenv bootargs root=/dev/mtdblock9 rootfstype=squashfs >> ETHADDR=$(ethaddr) RUNNING=$(runningimage) CFGFS=mtdblock10;bootm 0x3006 > __ >> >> run bootcmd2 > > First, I don't understand why those two addresses are not the same. > > Then, are you sure your "bootcmd2" ist really what you think it is? > Try a "printenv" and see whats really there. > > Should you not have a "console=xxx" in your kernel parameters? > > Besides once "Starting kernel ..." shows, u-boot is about to give control > to the kernel, all future output would be from the kernel itself, probably > needing a sane "console=xxx" parameter. > > Best Regards, > Reinhard > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Uboot can't start kernel after change from version 2009.01 to 2010.09
Dear Reinhard Meyer, I tried it with: setenv bootargs root=/dev/mtdblock9 rootfstype=jffs2 console=ttyS4 ETHADDR=$(ethaddr) RUNNING=$(runningimage) CFGFS=mtdblock10;bootm 0x3006 but nothing the error is still there. The console is set in the board init of the linux kernel. I changed only the uboot verion. The linux kernel and the rootfilesystem are the same. Mit freundlichen Grüßen Maik Hänig Am 25.01.2011 12:03, schrieb Maik Hänig: > Dear Reinhard, > > sorry I copied the wrong log: > > U-Boot 2010.09 (Jan 24 2011 - 17:45:54) > > I2C: ready > DRAM: 64 MiB > Flash: 32 MiB > In:serial > Out: serial > Err: serial > Hit any key to stop autoboot: 0 > ## Booting kernel from Legacy Image at 3006 ... > Image Name: Linux Kernel > Image Type: ARM Linux Kernel Image (gzip compressed) > Data Size:1084127 Bytes = 1 MiB > Load Address: 20008000 > Entry Point: 20008000 > Verifying Checksum ... OK > Uncompressing Kernel Image ... OK > > Starting kernel ... > > I have to kernel Images in flash. The bootcmd is copied from printenv. > With the uboot version 2009.01 it works well. Is it nessesary to set a > console parameter in the bootcmd in uboot version 2010.09? > > > Mit freundlichen Grüßen > > Maik Hänig > > Am 25.01.2011 11:54, schrieb Reinhard Meyer: >> Dear Maik Hänig, >>> Hi, >>> >>> >>> I change my uboot version and after it the uboot don't starts the same >>> linux kernel: >>> >>> ## Booting kernel from Legacy Image at 1006 ... >> _ >>> Image Name: Linux Kernel >>> Image Type: ARM Linux Kernel Image (gzip compressed) >>> Data Size:1178673 Bytes = 1.1 MiB >>> Load Address: 20008000 >>> Entry Point: 20008000 >>> Verifying Checksum ... OK >>> Uncompressing Kernel Image ... OK >>> >>> Starting kernel ... >>> >>> *LOG END* >>> >>> >>> It's a board simular to the at91rm9200dk. I start the kernel with >>> >>> bootcmd2=setenv bootargs root=/dev/mtdblock9 rootfstype=squashfs >>> ETHADDR=$(ethaddr) RUNNING=$(runningimage) CFGFS=mtdblock10;bootm 0x3006 >> __ >>> >>> run bootcmd2 >> >> First, I don't understand why those two addresses are not the same. >> >> Then, are you sure your "bootcmd2" ist really what you think it is? >> Try a "printenv" and see whats really there. >> >> Should you not have a "console=xxx" in your kernel parameters? >> >> Besides once "Starting kernel ..." shows, u-boot is about to give control >> to the kernel, all future output would be from the kernel itself, probably >> needing a sane "console=xxx" parameter. >> >> Best Regards, >> Reinhard >> >> > ___ > 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] Uboot can't start kernel after change from version 2009.01 to 2010.09
Dear Maik Hänig, please do not hijack a thread! Am 25.01.2011 12:03, schrieb Maik Hänig: > Dear Reinhard, > > sorry I copied the wrong log: > > U-Boot 2010.09 (Jan 24 2011 - 17:45:54) Ok, you use 2010.09. This was last release before relocate changes. Therefore it has no connection with the relocation stuff. > I2C: ready > DRAM: 64 MiB > Flash: 32 MiB > In:serial > Out: serial > Err: serial > Hit any key to stop autoboot: 0 > ## Booting kernel from Legacy Image at 3006 ... > Image Name: Linux Kernel > Image Type: ARM Linux Kernel Image (gzip compressed) > Data Size:1084127 Bytes = 1 MiB > Load Address: 20008000 > Entry Point: 20008000 > Verifying Checksum ... OK > Uncompressing Kernel Image ... OK > > Starting kernel ... > > I have to kernel Images in flash. The bootcmd is copied from printenv. > With the uboot version 2009.01 it works well. > Is it nessesary to set a > console parameter in the bootcmd in uboot version 2010.09? We don't know your configuration. What tells your working setup in kernel log messages about 'Command line'? -> /proc/cmdline > > > Mit freundlichen Grüßen > > Maik Hänig > > Am 25.01.2011 11:54, schrieb Reinhard Meyer: >> Dear Maik Hänig, >>> Hi, >>> >>> >>> I change my uboot version and after it the uboot don't starts the same >>> linux kernel: >>> >>> ## Booting kernel from Legacy Image at 1006 ... >> _ >>> Image Name: Linux Kernel >>> Image Type: ARM Linux Kernel Image (gzip compressed) >>> Data Size:1178673 Bytes = 1.1 MiB >>> Load Address: 20008000 >>> Entry Point: 20008000 >>> Verifying Checksum ... OK >>> Uncompressing Kernel Image ... OK >>> >>> Starting kernel ... >>> >>> *LOG END* >>> >>> >>> It's a board simular to the at91rm9200dk. I start the kernel with What is your board exactly? Is it currently in official u-boot or do you have another tree? at91rm9200dk is most likely broken with current u-boot (2010.12) and will be removed for 2011.03. So if you have a at91rm9200dk at hand please try to get the current u-boot working with that board and provide patches. You may see my patches for at91rm9200ek which at least make at91rm9200ek boot from SDRAM when setup correctly with an jtag (-> booting with at91bootstrab should also work but is untested). regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Uboot can't start kernel after change from version 2009.01 to 2010.09
Dear Maik Hänig, Am 25.01.2011 12:18, schrieb Maik Hänig: > Dear Reinhard Meyer, > > I tried it with: > > setenv bootargs root=/dev/mtdblock9 rootfstype=jffs2 console=ttyS4 > ETHADDR=$(ethaddr) RUNNING=$(runningimage) CFGFS=mtdblock10;bootm 0x3006 > > but nothing the error is still there. The console is set in the board > init of the linux kernel. > > I changed only the uboot verion. The linux kernel and the rootfilesystem > are the same. > I guess you have a board with specific kernel and specific u-boot. So maybe the machtype does not match? regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Uboot can't start kernel after change from version 2009.01 to 2010.09
Andreas Bießmann, > I guess you have a board with specific kernel and specific u-boot. So > maybe the machtype does not match? Yes. Where can I found the mach type in uboot source? Best regards / Mit freundlichen Grüßen Maik Hänig ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Uboot can't start kernel after change from version 2009.01 to 2010.09
Dear Andreas Bießmann, please do not hijack a thread! sorry I didn't want do this. I wanted to give some more information. Ok, you use 2010.09. This was last release before relocate changes. Therefore it has no connection with the relocation stuff. yes I. I tried to make a patch for 2010.12 but the uboot don't starts so I tried in the first step the version before. It is a similar board to the at91rm9200dk. It hangs in the low level_init file. But I have only a keil jtag debugger and couldn't debug it. or is there any possibility to use it with the gdb? I found the problem in the board.c of the arm architecture. But can't see why. Line 303 is reached but line 312 not. Also line 306 is not reached. I don't know why, maybe you can give me a hint? I think if the problem is found the problem with the at91rm9200dk is also found. Is it nessesary to set a console parameter in the bootcmd in uboot version 2010.09? We don't know your configuration. What tells your working setup in kernel log messages about 'Command line'? -> /proc/cmdline I only give the MAC and the running image in the cmdline. I think the problem must be in the uboot. What is your board exactly? Is it currently in official u-boot or do you have another tree? at91rm9200dk is most likely broken with current u-boot (2010.12) and will be removed for 2011.03. So if you have a at91rm9200dk at hand please try to get the current u-boot working with that board and provide patches. You may see my patches for at91rm9200ek which at least make at91rm9200ek boot from SDRAM when setup correctly with an jtag (-> booting with at91bootstrab should also work but is untested). It isn't in official u-boot tree. You can have a look in the patch. Best regards / Mit freundlichen Grüßen Maik Hänig diff -Naur u-boot-2010.12_org/arch/arm/cpu/arm920t/at91/lowlevel_init.S u-boot-2010.12_patch/arch/arm/cpu/arm920t/at91/lowlevel_init.S --- u-boot-2010.12_org/arch/arm/cpu/arm920t/at91/lowlevel_init.S 2010-12-22 20:22:14.0 +0100 +++ u-boot-2010.12_patch/arch/arm/cpu/arm920t/at91/lowlevel_init.S 2011-01-20 11:44:21.384576087 +0100 @@ -65,7 +65,7 @@ ldr r0, =SMRDATA ldr r1, _MTEXT_BASE sub r0, r0, r1 - add r2, r0, #80 + add r2, r0, #(SMRDATA1-SMRDATA) pllloop: /* the address */ ldr r1, [r0], #4 @@ -83,7 +83,7 @@ ldr r0, =SMRDATA1 ldr r1, _MTEXT_BASE sub r0, r0, r1 - add r2, r0, #176 + add r2, r0, #(SMRDATA2-SMRDATA1) sdinit: /* the address */ ldr r1, [r0], #4 @@ -108,6 +108,10 @@ .word CONFIG_SYS_EBI_CFGR_VAL .word AT91_ASM_MC_SMC_CSR0 .word CONFIG_SYS_SMC_CSR0_VAL +#ifdef CONFIG_SYS_SMC_CSR2_VAL + .word AT91_ASM_MC_SMC_CSR2 + .word CONFIG_SYS_SMC_CSR2_VAL +#endif .word AT91_ASM_PMC_PLLAR .word CONFIG_SYS_PLLAR_VAL .word AT91_ASM_PMC_PLLBR @@ -161,4 +165,5 @@ .word CONFIG_SYS_SDRAM .word CONFIG_SYS_SDRAM_VAL /* SMRDATA1 is 176 bytes long */ +SMRDATA2: #endif /* CONFIG_SKIP_LOWLEVEL_INIT */ diff -Naur u-boot-2010.12_org/arch/arm/cpu/arm920t/start.S u-boot-2010.12_patch/arch/arm/cpu/arm920t/start.S --- u-boot-2010.12_org/arch/arm/cpu/arm920t/start.S 2010-12-22 20:22:14.0 +0100 +++ u-boot-2010.12_patch/arch/arm/cpu/arm920t/start.S 2011-01-20 12:22:11.732575245 +0100 @@ -122,7 +122,7 @@ bl coloured_LED_init bl red_LED_on -#ifdefined(CONFIG_AT91RM9200DK) || defined(CONFIG_AT91RM9200EK) +#ifdefined(CONFIG_AT91RM9200DK) || defined(CONFIG_AT91RM9200EK) || defined(CONFIG_KACOM) /* * relocate exception table */ @@ -190,6 +190,14 @@ /*--*/ +/* ldr r0, =0x0001 + ldr r1, =0xfA00 + str r0, [r1] + ldr r1, =0xfA10 + str r0, [r1] + ldr r1, =0xfA34 + str r0, [r1]*/ + /* * void relocate_code (addr_sp, gd, addr_moni) * diff -Naur u-boot-2010.12_org/arch/arm/include/asm/arch-at91/at91_mc.h u-boot-2010.12_patch/arch/arm/include/asm/arch-at91/at91_mc.h --- u-boot-2010.12_org/arch/arm/include/asm/arch-at91/at91_mc.h 2010-12-22 20:22:14.0 +0100 +++ u-boot-2010.12_patch/arch/arm/include/asm/arch-at91/at91_mc.h 2011-01-20 08:39:22.604076221 +0100 @@ -26,6 +26,7 @@ #define AT91_ASM_MC_EBI_CSA(AT91_MC_BASE + 0x60) #define AT91_ASM_MC_EBI_CFG(AT91_MC_BASE + 0x64) #define AT91_ASM_MC_SMC_CSR0 (AT91_MC_BASE + 0x70) +#define AT91_ASM_MC_SMC_CSR2 (AT91_MC_BASE + 0x78) #define AT91_ASM_MC_SDRAMC_MR (AT91_MC_BASE + 0x90) #define AT91_ASM_MC_SDRAMC_TR (AT91_MC_BASE + 0x94) #define AT91_ASM_MC_SDRAMC_CR (AT91_MC_BASE + 0x98) diff -Naur u-boot-2010.12_org/arch/arm/lib/board.c u-boot-2010.12_patch/arch/arm/lib/board.
[U-Boot] Pull from ARM mavell and samsung repos?
(cc: ARM Marvell and Samsung custodians) Hi, Looking up ARM repos, I see that currently u-boot-arm/master is lagging behind u-boot-marvell/master and u-boot-samsung/master. All patches in these two repos are prior to jan 17. However I haven't found pull requests for these. Should I pull them in before sending out my pull request to u-boot ? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull from ARM mavell and samsung repos?
Dear Albert ARIBAUD, On 25 January 2011 21:18, Albert ARIBAUD wrote: > (cc: ARM Marvell and Samsung custodians) > > Hi, > > Looking up ARM repos, I see that currently u-boot-arm/master is lagging > behind u-boot-marvell/master and u-boot-samsung/master. All patches in these > two repos are prior to jan 17. > > However I haven't found pull requests for these. Should I pull them in > before sending out my pull request to u-boot ? > I'm going to send the pull request at this Thursday . Because of I'm waiting the review of my patches. (about s5pc2xx SoC) When will you send the pull request to u-boot? Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Uboot can't start kernel after change from version 2009.01 to 2010.09
Dear Andreas Bießmann, > I guess you have a board with specific kernel and specific u-boot. So > maybe the machtype does not match? thanks, you was right it was a mach-type problem. I had set the wrong mach-type in my board init. The problem with the uboot version 2010.12 hasn't changed. Best regards / Mit freundlichen Grüßen Maik Hänig ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] How to give RESET_VECTOR_ADDRESS
Hi As the config.mk file is doomed I tried to set my reset vector in another way. I first tried it in the board's config header. But that didn't seem to have an effect. I then tried a config option in the boards.cfg file but that also didn't work. The only way I could get it to work so far was with the config.mk file. What's the new way to give a (CONFIG_)RESET_VECTOR_ADDRESS? Thanks bye Fabi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to give RESET_VECTOR_ADDRESS
On Jan 25, 2011, at 7:25 AM, Fabian Cenedese wrote: > Hi > > As the config.mk file is doomed I tried to set my reset vector > in another way. I first tried it in the board's config header. But > that didn't seem to have an effect. I then tried a config option > in the boards.cfg file but that also didn't work. The only way I > could get it to work so far was with the config.mk file. > > What's the new way to give a (CONFIG_)RESET_VECTOR_ADDRESS? Specify it in the board's config.h - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Switch from archive libraries to partial linking
Kumar Gala wrote: > Actually we've dealt with this already: > > commit ce82ff05388b5ddafdf6082ef0776cce72c40b1c > Author: Yuri Tikhonov > Date: Sat Dec 20 14:54:21 2008 +0300 > > FPU POST: fix warnings when building with 2.18 binutils Why don't we compile all of U-Boot with hard float by default? What's wrong with using floating point instructions in U-Boot? -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 2/4] serial: Add Tegra2 serial port support
Mike, On Tue, Jan 25, 2011 at 1:11 AM, Mike Rapoport wrote: > On 01/22/11 01:06, Tom Warren wrote: >> Signed-off-by: Tom Warren >> --- > > [ snip ] > >> +/* >> + * Routine: pin_mux_uart >> + * Description: setup the pin muxes/tristate values for a UART >> + */ >> +static void pin_mux_uart(void) >> +{ >> + pinmux_tri_ctlr *const pmt = (pinmux_tri_ctlr *)NV_PA_APB_MISC_BASE; >> + u32 reg; >> + >> +#if CONFIG_TEGRA2_ENABLE_UARTA >> + reg = readl(&pmt->pmt_ctl_c); >> + reg &= 0xFFF0; /* IRRX_/IRTX_SEL [19:16] = 00 UARTA */ >> + writel(reg, &pmt->pmt_ctl_c); >> + >> + reg = readl(&pmt->pmt_tri_a); >> + reg &= ~Z_IRRX; /* Z_IRRX = normal (0) */ >> + reg &= ~Z_IRTX; /* Z_IRTX = normal (0) */ >> + writel(reg, &pmt->pmt_tri_a); >> +#endif /* CONFIG_TEGRA2_ENABLE_UARTA */ >> +#if CONFIG_TEGRA2_ENABLE_UARTD >> + reg = readl(&pmt->pmt_ctl_b); >> + reg &= 0xFFF3; /* GMC_SEL [3:2] = 00, UARTD */ >> + writel(reg, &pmt->pmt_ctl_b); >> + >> + reg = readl(&pmt->pmt_tri_a); >> + reg &= ~Z_GMC; /* Z_GMC = normal (0) */ >> + writel(reg, &pmt->pmt_tri_a); >> +#endif /* CONFIG_TEGRA2_ENABLE_UARTD */ > > As I've already pointed out (1) this covers only one possibility of UART pin > muxing options. I agree that it makes sense when this is a part of the > board-specific code. However, forcing specific pins configuration in the > generic > driver seems problematic to me, even if most Tegra2 boards use the same > configuration. > As a side note, I'd prefer to have all the pin multiplexing defined in one > place > in board file rather than scattered among different drivers. > Alright. I'd like to get this wrapped up and accepted before the merge window closes so I can get on with the important bits (drivers, etc.). What would you like here? A generic function like 'pinmux_set_config(reg, val, bit)' that lives in the board files and gets called from the driver code with specifics of that board's/drivers pinmux config? Or do you see the pinmux code living entirely in the board files, and being done as part of board init? That's where it was before, BTW. If there are examples that you approve of in any extant U-Boot code (omap, ti91, davinci, etc.), please point them out. I'd really like to finalize this patch series. > (1) http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/92887/focus=93233 > > > -- > Sincerely yours, > Mike. Thanks, Tom > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Switch from archive libraries to partial linking
On Jan 25, 2011, at 10:40 AM, Timur Tabi wrote: > Kumar Gala wrote: >> Actually we've dealt with this already: >> >> commit ce82ff05388b5ddafdf6082ef0776cce72c40b1c >> Author: Yuri Tikhonov >> Date: Sat Dec 20 14:54:21 2008 +0300 >> >>FPU POST: fix warnings when building with 2.18 binutils > > Why don't we compile all of U-Boot with hard float by default? What's wrong > with using floating point instructions in U-Boot? * still have to deal with cores that dont have FP - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull from ARM mavell and samsung repos?
Le 25/01/2011 13:51, Minkyu Kang a écrit : > Dear Albert ARIBAUD, > > On 25 January 2011 21:18, Albert ARIBAUD wrote: >> (cc: ARM Marvell and Samsung custodians) >> >> Hi, >> >> Looking up ARM repos, I see that currently u-boot-arm/master is lagging >> behind u-boot-marvell/master and u-boot-samsung/master. All patches in these >> two repos are prior to jan 17. >> >> However I haven't found pull requests for these. Should I pull them in >> before sending out my pull request to u-boot ? >> > > I'm going to send the pull request at this Thursday . > Because of I'm waiting the review of my patches. (about s5pc2xx SoC) > > When will you send the pull request to u-boot? If that's fine with Wolfgang, I'll wait for your own pull request. > Thanks > Minkyu Kang Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot support for board(s) meesc, otc570
Le 24/01/2011 12:39, Daniel Gorsulowski a écrit : > Hello Reinhard, > > ... >>> >>> Check that your AT91Bootstrap loads u-boot to a sane address not at the >>> very end >>> of DRAM, and that CONFIG_SYS_TEXT_BASE is exactly the address where >>> AT91Bootstrap >>> loads u-boot. (I changed AT91Bootstrap to load u-boot to the very begin >>> of DRAM >>> for our boards.) >>> >> >> I neither change the AT91Bootstrap nor the CONFIG_SYS_TEXT_BASE address, >> so the problem must be located elsewhere. >> >> Today I found out by GPIO debugging, that U-Boot seems to boot but prints >> its startup messages to wrong USART with proper baudrate. I'll try to >> find out, why there is no output on DBGU. >> > > I have to correct myself. > My board_init() and checkboard() fanctions are executed. But the board > crashes, before misc_init_r() functions executes. > (I guess, it crashes somwhere in board_init_f()) > I'll try to find out more infos. But without an appropriate opportunity > to debug, it will be verry difficult. Make sure nothing executes under board_init_f() that tries to write to BSS (uninitialized) variables: BSS does not actually exist until after relocation, and writing to the would-be BSS area will cause corruption of the U-boot code. Not sure this is what happens with you but better safe than sorry. > Best regards > Daniel Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Switch from archive libraries to partial linking
Dear Timur Tabi, In message <4d3efcf2.4060...@freescale.com> you wrote: > > Why don't we compile all of U-Boot with hard float by default? What's wrong > with using floating point instructions in U-Boot? We don't need it. Why doesn't the Linux kernel use floating point instructions? 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 ultimate barrier is one's viewpoint. - 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] Pull from ARM mavell and samsung repos?
Dear Albert ARIBAUD, In message <4d3f1125.5070...@free.fr> you wrote: > > > I'm going to send the pull request at this Thursday . > > Because of I'm waiting the review of my patches. (about s5pc2xx SoC) > > > > When will you send the pull request to u-boot? > > If that's fine with Wolfgang, I'll wait for your own pull request. I have little choice but wait until you all are ready. [And my own todo list is not empty yet 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 The evolution of the human race will not be accomplished in the ten thousand years of tame animals, but in the million years of wild animals, because man is and will always be a wild animal. - Charles Galton Darwin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Switch from archive libraries to partial linking
Wolfgang Denk wrote: > Why doesn't the Linux kernel use floating point instructions? Because dealing with FP in a multi-tasking OS is messy. U-Boot doesn't have that problem. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Switch from archive libraries to partial linking
Kumar Gala wrote: > * still have to deal with cores that dont have FP But when will gcc generate FP instructions? If we compile with soft-float, will it link in an FP library and use it? My point is that compiling with soft-float doesn't make much more sense than compiling with hard-float, since there won't be any floating point instructions in either case. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] SteppingStone
Hello. I have a custom board with a Samsung s3c2410 (arm920t) processor. I have been unable to get the main branch of u-boot to work with this board. However, I have been successful with the old OpenMoko fork. (I believe it is because of the "SteppingStone" microcode. See http://wiki.openmoko.org/wiki/S3C2410_Steppingstone if you're unfamiliar.) I'd prefer to use the main branch, because the OpenMoko fork is old and unmaintained. The OpenMoko project abandoned u-boot some time ago, in favor of their "Qi" bootloader. Has anyone looked at merging the SteppingStone code back in to the main branch? Is there some other workaround that is unclear to me? Are there other bootloaders that support SteppingStone that I could try? I'm looking for something as full-featured as u-boot, but actively maintained. The only other that I've found is Vivi - which is super ancient. Any advice is appreciated. Thanks, Matt ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/85xx: Add some defines for P2040, P3041, P5010, P5020
Specify the number of DDR controllers, number of frame managers, number of 1g and 10g ports. Signed-off-by: Kumar Gala --- arch/powerpc/include/asm/config_mpc85xx.h | 15 +++ 1 files changed, 15 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/include/asm/config_mpc85xx.h b/arch/powerpc/include/asm/config_mpc85xx.h index a78086b..0f83d15 100644 --- a/arch/powerpc/include/asm/config_mpc85xx.h +++ b/arch/powerpc/include/asm/config_mpc85xx.h @@ -140,11 +140,18 @@ #define CONFIG_MAX_CPUS4 #define CONFIG_SYS_FSL_NUM_LAWS32 #define CONFIG_SYS_FSL_SEC_COMPAT 4 +#define CONFIG_SYS_NUM_FMAN1 +#define CONFIG_SYS_NUM_FM1_DTSEC 5 +#define CONFIG_NUM_DDR_CONTROLLERS 1 #elif defined(CONFIG_PPC_P3041) #define CONFIG_MAX_CPUS4 #define CONFIG_SYS_FSL_NUM_LAWS32 #define CONFIG_SYS_FSL_SEC_COMPAT 4 +#define CONFIG_SYS_NUM_FMAN1 +#define CONFIG_SYS_NUM_FM1_DTSEC 5 +#define CONFIG_SYS_NUM_FM1_10GEC 1 +#define CONFIG_NUM_DDR_CONTROLLERS 1 #elif defined(CONFIG_PPC_P4040) #define CONFIG_MAX_CPUS4 @@ -176,11 +183,19 @@ #define CONFIG_MAX_CPUS1 #define CONFIG_SYS_FSL_NUM_LAWS32 #define CONFIG_SYS_FSL_SEC_COMPAT 4 +#define CONFIG_SYS_NUM_FMAN1 +#define CONFIG_SYS_NUM_FM1_DTSEC 5 +#define CONFIG_SYS_NUM_FM1_10GEC 1 +#define CONFIG_NUM_DDR_CONTROLLERS 1 #elif defined(CONFIG_PPC_P5020) #define CONFIG_MAX_CPUS2 #define CONFIG_SYS_FSL_NUM_LAWS32 #define CONFIG_SYS_FSL_SEC_COMPAT 4 +#define CONFIG_SYS_NUM_FMAN1 +#define CONFIG_SYS_NUM_FM1_DTSEC 5 +#define CONFIG_SYS_NUM_FM1_10GEC 1 +#define CONFIG_NUM_DDR_CONTROLLERS 2 #else #error Processor type not defined for this platform -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull from ARM mavell and samsung repos?
> -Original Message- > From: Minkyu Kang [mailto:proms...@gmail.com] > Sent: Tuesday, January 25, 2011 4:52 AM > To: Albert ARIBAUD > Cc: u-boot@lists.denx.de; Prafulla Wadaskar > Subject: Re: Pull from ARM mavell and samsung repos? > > Dear Albert ARIBAUD, > > On 25 January 2011 21:18, Albert ARIBAUD wrote: > > (cc: ARM Marvell and Samsung custodians) > > > > Hi, > > > > Looking up ARM repos, I see that currently u-boot-arm/master is > lagging > > behind u-boot-marvell/master and u-boot-samsung/master. All patches in > these > > two repos are prior to jan 17. > > > > However I haven't found pull requests for these. Should I pull them in > > before sending out my pull request to u-boot ? > > > > I'm going to send the pull request at this Thursday . > Because of I'm waiting the review of my patches. (about s5pc2xx SoC) Even I too Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Switch from archive libraries to partial linking
Dear Timur Tabi, In message <4d3f1674.10...@freescale.com> you wrote: > > Because dealing with FP in a multi-tasking OS is messy. U-Boot doesn't have > that problem. But we also do not have any need for FP operations either. It would just add to the complexity (and to the memory foot print, especially on systems without FPU where we would have to provide soft-float libraries, plus eventually variantes for SPEv1 and SPEvv2 and whatever - not to mention that tghis will be needed for all the non-PPC architectures as well). 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 combination of a number of things to make existence worthwhile." "Yes, the philosophy of 'none,' meaning 'all.'" -- Spock and Lincoln, "The Savage Curtain", stardate 5906.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Switch from archive libraries to partial linking
Dear Timur Tabi, In message <4d3f16c7.7040...@freescale.com> you wrote: > > But when will gcc generate FP instructions? If we compile with soft-float, > will > it link in an FP library and use it? GCC will (in addition to the obvious case of operations of FP data types) generate FP instructions for a number of "small data copy" operations, like assignment of structs etc. > My point is that compiling with soft-float doesn't make much more sense than > compiling with hard-float, since there won't be any floating point > instructions > in either case. You are wrong. 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 One difference between a man and a machine is that a machine is quiet when well oiled. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Switch from archive libraries to partial linking
Dear Timur Tabi, In message <4d3f1d25.4070...@freescale.com> you wrote: > > I think you misunderstand. I'm not saying that we should use FP instructions > in > U-Boot. I'm saying that since we *don't* use FP instructions in U-Boot, we > can > just turn on hard-float and avoid any incompatibility with CONFIG_POST_FPU, > because all of U-Boot will then be compiled with hard-float. If we let him, GCC would generate FP instructions in a number of places where you don't expect them, even whithout any FP variables or explicit FP operations in the whole code C or assembler input. 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 "'Tis true, 'tis pity, and pity 'tis 'tis true." - Poloniouius, in Willie the Shake's _Hamlet, Prince of Darkness_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Switch from archive libraries to partial linking
Wolfgang Denk wrote: > But we also do not have any need for FP operations either. It would > just add to the complexity (and to the memory foot print, especially > on systems without FPU where we would have to provide soft-float > libraries, plus eventually variantes for SPEv1 and SPEvv2 and > whatever - not to mention that tghis will be needed for all the > non-PPC architectures as well). I think you misunderstand. I'm not saying that we should use FP instructions in U-Boot. I'm saying that since we *don't* use FP instructions in U-Boot, we can just turn on hard-float and avoid any incompatibility with CONFIG_POST_FPU, because all of U-Boot will then be compiled with hard-float. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Use optimized memcpy and memset from linux
Dear =?ISO-8859-1?Q?Matthias_Wei=DFer?=, In message <4d3eac1a.5030...@arcor.de> you wrote: > > | HEAD(1)| HEAD(1)| HEAD(2)| HEAD(2)| > || +patch || +patch | > ---+++++ > Reset to prompt| 438ms | 330ms | 228ms | 120ms | > ||||| > TFTP a 3MB img | 4782ms | 3428ms | 3245ms | 2820ms | > ||||| > FATLOAD USB a 3MB img* | 8515ms | 8510ms | -- | -- | > ||||| > BOOTM LZO img in RAM | 3473ms | 3168ms | 592ms | 592ms | > where CRC is | 615ms | 615ms | 54ms | 54ms | > uncompress| 2460ms | 2462ms | 450ms | 451ms | > final boot_elf| 376ms | 68ms | 65ms | 65ms | > ||||| > BOOTM LZO img in FLASH | 3207ms | 2902ms | 1050ms | 1050ms | > where CRC is | 600ms | 600ms | 135ms | 135ms | > uncompress| 2209ms | 2211ms | 828ms | 828ms | > final boot_elf| 376ms | 68ms | 65ms | 65ms | > > (1) No dcache > (2) dcache enabled in board_init > *Does not work when dcache is on > > I think we can see that there seems to be no negativ impact of theses > patches when only execution speed is taken into consideration. The gain > is noticable when caching is not used or not activated. For pure RAM to > RAM copy when caching is activated the patch didn't change anything. > > Here are some additional numbers for copying a 1.4MB image from NOR to RAM: > > HEAD : 134ms > HEAD + patch : 72ms > HEAD + dcache : 120ms > HEAD + dcache + patch : 70ms This is pretty much interesting information for developers who have to decide if they want to accept the increased memory footprint. Can you please add this to the commit message? > Would it be an option to use the CONFIG entries CONFIG_USE_ARCH_MEMCPY > and CONFIG_USE_ARCH_MEMSET to enable that feature? If that is OK I can Makes sense to me. > send a new version of the patch. The only problem I see with this > approach is that there are architectures which already have their own > implementations which are then not affected by these config options. If you are aware of any, it might make sense to put the respective maintainers on Cc: to trigger them to adapt / clean up their code. 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 Its always easier short term to pee in the pond than install a toilet - it's just not a good long term plan. - Alan Cox in <20100101145701.6432e...@lxorguk.ukuu.org.uk> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Switch from archive libraries to partial linking
On Tue, 25 Jan 2011 11:49:53 -0600 Kumar Gala wrote: > > On Jan 25, 2011, at 10:40 AM, Timur Tabi wrote: > > > Kumar Gala wrote: > >> Actually we've dealt with this already: > >> > >> commit ce82ff05388b5ddafdf6082ef0776cce72c40b1c > >> Author: Yuri Tikhonov > >> Date: Sat Dec 20 14:54:21 2008 +0300 > >> > >>FPU POST: fix warnings when building with 2.18 binutils > > > > Why don't we compile all of U-Boot with hard float by default? What's wrong > > with using floating point instructions in U-Boot? > > * still have to deal with cores that dont have FP On cores that have FP (at least those that support the FPU POST, and which are currently having problems), use hard float, enable MSR[FP] or equivalent, and let GCC use FP for various tasks if it wants. This shouldn't involve much more complexity than adding a small amount of init, which you'd need for the POST anyway. On cores that don't have FP, use soft float, and don't include the FPU POST code. This should not be any different than today, except for adding another compiler flag that depends on the build target. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Please pull u-boot-mpc85xx.git
Dear Kumar Gala, In message you wrote: > The following changes since commit e1ccf97c5d7651664d37c0c5aa243874b8851b2d: > > Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx (2011-01-17 > 20:31:46 +0100) > > are available in the git repository at: > > git://git.denx.de/u-boot-mpc85xx master > > Dipen Dudhat (1): > powerpc/85xx: Protect all LBC code with CONFIG_FSL_LBC > > Haiying Wang (1): > 8xxx/ddr: add support to only compute the ddr sdram size > > Kumar Gala (6): > powerpc/85xx: Move RESET_VECTOR_ADDRESS into config.h > powerpc/p3041: Add various p3041 specific information > powerpc/p5020: Add various p5020 specific information > powerpc/p2040: Add various p2040 specific information > powerpc/8xxx: Add hwconfig APIs to address early parsing used by DDR > init > powerpc/8xxx: Introduce 85xx, 86xx, QorIQ config headers > > Poonam Aggrwal (2): > powerpc/85xx: Add Support for Freescale P1010 Processor > powerpc/85xx: Add Support for Freescale P1014 Processor > > Prabhakar (1): > Fix wrong CONFIG_SYS_MPC85xx_SERDES1_ADDR > > Prabhakar Kushwaha (1): > ppc/85xx: Fix compile err when PCI disabled on P1_P2_RDB > > York Sun (8): > mpc8xxx: Display RDIMM if detected > mpc8xxx: Enable ECC on/off control in hwconfig > corenet_ds: Enable ECC for corenet_ds > mpc85xx: Adding more registers and options > mpc85xx: Enable unique mode registers and dynamic ODT for DDR3 > mpc85xx: Implement workaround for erratum DDR-A003 > corenet_ds: Extend board specific parameters > powerpc/p4080: Fix warning in serdes code from early use of hwconfig > > arch/powerpc/cpu/mpc85xx/Makefile |6 + > arch/powerpc/cpu/mpc85xx/cmd_errata.c |3 + > arch/powerpc/cpu/mpc85xx/cpu.c |9 +- > arch/powerpc/cpu/mpc85xx/ddr-gen3.c| 99 +- > arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c | 17 +- > arch/powerpc/cpu/mpc85xx/p2040_serdes.c| 66 > arch/powerpc/cpu/mpc85xx/p3041_ids.c | 105 ++ > arch/powerpc/cpu/mpc85xx/p3041_serdes.c| 151 > arch/powerpc/cpu/mpc85xx/p5020_ids.c | 105 ++ > arch/powerpc/cpu/mpc85xx/p5020_serdes.c| 151 > arch/powerpc/cpu/mpc85xx/speed.c |6 +- > arch/powerpc/cpu/mpc85xx/u-boot.lds|8 +- > arch/powerpc/cpu/mpc8xxx/cpu.c |8 +- > arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c | 262 +++--- > arch/powerpc/cpu/mpc8xxx/ddr/ddr.h |8 +- > .../cpu/mpc8xxx/ddr/lc_common_dimm_params.c| 20 +- > arch/powerpc/cpu/mpc8xxx/ddr/main.c| 31 ++- > arch/powerpc/cpu/mpc8xxx/ddr/options.c | 395 > ++-- > arch/powerpc/include/asm/config.h | 39 +-- > arch/powerpc/include/asm/config_mpc85xx.h | 188 ++ > arch/powerpc/include/asm/config_mpc86xx.h | 38 ++ > arch/powerpc/include/asm/fsl_ddr_sdram.h | 52 +++ > arch/powerpc/include/asm/immap_85xx.h | 23 +- > arch/powerpc/include/asm/processor.h |6 + > board/freescale/corenet_ds/config.mk | 27 -- > board/freescale/corenet_ds/ddr.c | 159 > board/freescale/mpc8536ds/config.mk| 14 +- > board/freescale/mpc8572ds/config.mk|4 +- > board/freescale/p1022ds/config.mk | 10 - > board/freescale/p1_p2_rdb/config.mk| 14 +- > board/freescale/p1_p2_rdb/p1_p2_rdb.c |4 +- > board/freescale/p1_p2_rdb/tlb.c|4 +- > board/freescale/p2020ds/config.mk | 26 -- > board/tqc/tqm85xx/sdram.c |8 +- > common/hwconfig.c | 86 +++-- > doc/README.fsl-ddr | 74 - > drivers/misc/fsl_law.c | 23 +- > include/configs/MPC8536DS.h|6 + > include/configs/MPC8572DS.h|4 + > include/configs/P1022DS.h |4 + > include/configs/P1_P2_RDB.h| 19 +- > include/configs/P2020DS.h |4 + > include/configs/P4080DS.h | 16 - > include/configs/corenet_ds.h |8 +- > include/hwconfig.h | 68 +++- > 45 files changed, 1940 insertions(+), 438 deletions(-) > create mode 100644 arch/powerpc/cpu/mpc85xx/p2040_serdes.c > create mode 100644 arch/powerpc/cpu/mpc85xx/p3041_ids.c > create mode 100644 arch/powerpc/cpu/mpc85xx/p3041_serdes.c > create mode 100644 arch/powerpc/cpu/mpc85xx/p5020_ids.c > create mode 100644 arch/powerpc/cpu/mpc85xx/p5
Re: [U-Boot] [PATCH] UEC: Fix compiler warnings introduced by linux/mii.h change
Dear Kumar Gala, In message <1295429800-26074-1-git-send-email-ga...@kernel.crashing.org> you wrote: > Patch 8ef583a0 [miiphy: convert to linux/mii.h] introduced the following > compiler warnings in the uec ethernet driver: > > In file included from /local/home/galak/git/u-boot-85xx/include/miiphy.h:37:0, > from uec.c:32: > /local/home/galak/git/u-boot-85xx/include/linux/mii.h:133:0: warning: > "LPA_1000FULL" redefined > uec_phy.h:34:0: note: this is the location of the previous definition > /local/home/galak/git/u-boot-85xx/include/linux/mii.h:134:0: warning: > "LPA_1000HALF" redefined > uec_phy.h:35:0: note: this is the location of the previous definition > In file included from /local/home/galak/git/u-boot-85xx/include/miiphy.h:37:0, > from uec_phy.c:27: > /local/home/galak/git/u-boot-85xx/include/linux/mii.h:133:0: warning: > "LPA_1000FULL" redefined > uec_phy.h:34:0: note: this is the location of the previous definition > /local/home/galak/git/u-boot-85xx/include/linux/mii.h:134:0: warning: > "LPA_1000HALF" redefined > uec_phy.h:35:0: note: this is the location of the previous definition > > Fix them be removing the duplication in the uec code and utlizing the > linux/mii.h version instead. > > Signed-off-by: Kumar Gala > --- > drivers/qe/uec_phy.c | 16 > drivers/qe/uec_phy.h | 12 +--- > 2 files changed, 9 insertions(+), 19 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 Old programmers never die, they just become managers. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: Fix FPU post related link warnings
Dear Kumar Gala, In message <1295946008-11905-1-git-send-email-ga...@kernel.crashing.org> you wrote: > If we built POST on PPC's that didn't enable CONFIG_SYS_POST_FPU we'd > get the following warning with newer toolchains: > > powerpc-linux-gnu-ld: Warning: lib_powerpc/fpu/libpostpowerpcfpu.o > uses hard float, libpost.o uses soft float > > We actually worked around this sometime ago with the following commit: > > commit ce82ff05388b5ddafdf6082ef0776cce72c40b1c > Author: Yuri Tikhonov > Date: Sat Dec 20 14:54:21 2008 +0300 > >FPU POST: fix warnings when building with 2.18 binutils > > However, this only took into effect if CONFIG_SYS_POST_FPU was enabled. > We can simply move the GNU_FPOST_ATTR out of the CONFIG_SYS_POST_FPU > ifdef block to address the issue. > > Signed-off-by: Kumar Gala > --- > > Wolfgang, I request we think about include this patch in v2011.03 tree so we > can all stop getting these build warnings :) > > - k > > post/lib_powerpc/fpu/20001122-1.c |4 ++-- > post/lib_powerpc/fpu/20010114-2.c |4 ++-- > post/lib_powerpc/fpu/20010226-1.c |4 ++-- > post/lib_powerpc/fpu/980619-1.c |4 ++-- > post/lib_powerpc/fpu/acc1.c |4 ++-- > post/lib_powerpc/fpu/compare-fp-1.c |4 ++-- > post/lib_powerpc/fpu/fpu.c|4 ++-- > post/lib_powerpc/fpu/mul-subnormal-single-1.c |4 ++-- > 8 files changed, 16 insertions(+), 16 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 No more blah, blah, blah! -- Kirk, "Miri", stardate 2713.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot v2010.12 released - Merge Window OPEN
Dear Alexander Holler, In message <4d3e8855.4070...@ahsoftware.de> you wrote: > > > * > > * Currently,>100 ARM boards are *broken* and *do not compile*. * > > * > > > > Board maintainers or othe rinterested parties are requested to > > adapt their boards to the new code in the timeframe of the > > upcoming release v2010.03; all boards that have not been converted > > by then, i. e. that are still broken then, are considered > > unmaintained and without interest to the community and will be > > removed. > > Maybe just a > > #error Code for this board doesn't compile since at least #date# > > or a similiar message in foo_config.h would be a way to inform people > early that the code needs some work. > > This way the source for the board could be visible for some more time in > the repository. Patches 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 The world is coming to an end -- save your buffers! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Switch from archive libraries to partial linking
Dear Scott Wood, In message <20110125140547.2825f...@udp111988uds.am.freescale.net> you wrote: > > On cores that have FP (at least those that support the FPU POST, and > which are currently having problems), use hard float, enable > MSR[FP] or equivalent, and let GCC use FP for various tasks if it > wants. This shouldn't involve much more complexity than adding a > small amount of init, which you'd need for the POST anyway. > > On cores that don't have FP, use soft float, and don't include > the FPU POST code. This should not be any different than today, except > for adding another compiler flag that depends on the build target. And why exactly should we do all this, given the fact that there are no intentions to work with floating point data in U-Boot? 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 e-credibility: the non-guaranteeable likelihood that the electronic data you're seeing is genuine rather than somebody's made-up crap. - Karl Lehenbauer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH 12/36] sc520 - Sort Makefile
Dear Graeme Russ, In message <1294084016-2674-13-git-send-email-graeme.r...@gmail.com> you wrote: > --- > arch/i386/cpu/sc520/Makefile |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/i386/cpu/sc520/Makefile b/arch/i386/cpu/sc520/Makefile > index fb47c20..b962b02 100644 > --- a/arch/i386/cpu/sc520/Makefile > +++ b/arch/i386/cpu/sc520/Makefile > @@ -32,9 +32,9 @@ include $(TOPDIR)/config.mk > LIB := $(obj)lib$(SOC).o > > COBJS-$(CONFIG_SYS_SC520) += sc520.o > +COBJS-$(CONFIG_PCI) += sc520_pci.o > COBJS-$(CONFIG_SYS_SC520_SSI) += sc520_ssi.o > COBJS-$(CONFIG_SYS_SC520_TIMER) += sc520_timer.o > -COBJS-$(CONFIG_PCI) += sc520_pci.o Please sort list. 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 If a group of N persons implements a COBOL compiler, there will be N-1 passes. Someone in the group has to be the manager. - T. Cheatham ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/36] Massive x86 Update - Bring x86 in line with ARM and PPC
Dear Graeme Russ, In message <1294084016-2674-1-git-send-email-graeme.r...@gmail.com> you wrote: > It's been a while since I've posted a patch (missed the last release cycle > entirely). I've been working on bringing x86 into line with ARM and PowerPC > with the init sequence running in flash. Currently, the SDRAM gets > initialised in asm before jumping into C and the first thing the C code did > was copy U-Boot to RAM. > > The breakthrough came when I discovered that the sc520 CPU can be configured > to enable the 16kB cache to be used as Cache-As-RAM (Thanks to Juergen > Beisert). The 'big' changes in this series are: > > - Memory initialisation is done in C (26) > - The initial global data is placed in CAR (Patches 24 & 36) - These are >interesting and could be used to get rid of the fixed register for >global data, but that would break the standalone API which uses it > - Board initialisation moved into RAM (patches 27 - 34) Except for the small nitpicking (sort list): Acked-by: Wolfgang Denk for the whole set. Please feel free to merge and send a pull req. 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 human race is a race of cowards; and I am not only marching in that procession but carrying a banner. - Mark Twain ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/13] add dvlhost (dLAN 200 AV Wireless G) board
Dear Michael Schwingen, In message <1294062338-21084-14-git-send-email-mich...@schwingen.org> you wrote: > > Signed-off-by: Michael Schwingen ... > diff --git a/board/dvlhost/config.mk b/board/dvlhost/config.mk > new file mode 100644 > index 000..a370337 > --- /dev/null > +++ b/board/dvlhost/config.mk > @@ -0,0 +1,3 @@ > +LDSCRIPT := $(SRCTREE)/board/$(BOARDDIR)/u-boot.lds > +PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections > +PLATFORM_LDFLAGS += --gc-sections Please drop that file, it should not be needed. ... > +int board_init (void) > +{ > + gd->bd->bi_arch_number = MACH_TYPE_DVLHOST; > + > + /* adress of boot parameters */ > + gd->bd->bi_boot_params = 0x0100; > + > + /* Setup GPIOs used as output */ > + GPIO_OUTPUT_CLEAR(CONFIG_SYS_GPIO_WDGTRIGGER); > + GPIO_OUTPUT_SET(CONFIG_SYS_GPIO_DLAN_PAIRING); > + GPIO_OUTPUT_CLEAR(CONFIG_SYS_GPIO_PCIRST); > + > + /* LED latch enable and watchdog enable are tied to the same GPIO, > +so we need to trigger the watchdog if we want to enable the LEDs. */ Incorrect multiline comment style, please fix globally. > +int dram_init (void) > +{ > + gd->ram_size = PHYS_SDRAM_1_SIZE; > + return (0); You should use get_ram_size() here. > diff --git a/board/dvlhost/u-boot.lds b/board/dvlhost/u-boot.lds > new file mode 100644 > index 000..606a46f > --- /dev/null > +++ b/board/dvlhost/u-boot.lds Do you really need a board specific linker script? It looks pretty much generic to me. > +void hw_watchdog_reset(void) > +{ > + *IXP425_GPIO_GPOUTR ^= (1 << (CONFIG_SYS_GPIO_WDGTRIGGER)); Please always use I/O accessors. Please fix globally. ... > + > +#undef CONFIG_HW_WATCHDOG/* HW Watchdog, board specific */ Please do not undef what is not defined anyway. Please fix globally. 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 By the way, ALL software projects are done by iterative prototyping. Some companies call their prototypes "releases", that's all. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Switch from archive libraries to partial linking
On Tue, 25 Jan 2011 21:19:19 +0100 Wolfgang Denk wrote: > Dear Scott Wood, > > In message <20110125140547.2825f...@udp111988uds.am.freescale.net> you wrote: > > > > On cores that have FP (at least those that support the FPU POST, and > > which are currently having problems), use hard float, enable > > MSR[FP] or equivalent, and let GCC use FP for various tasks if it > > wants. This shouldn't involve much more complexity than adding a > > small amount of init, which you'd need for the POST anyway. > > > > On cores that don't have FP, use soft float, and don't include > > the FPU POST code. This should not be any different than today, except > > for adding another compiler flag that depends on the build target. > > And why exactly should we do all this, To fix the FPU POST build errors. Do you have a simpler way to do this? Note that for any board that doesn't currently have a problem, "all this" means no change at all. And for those that do have a problem, the change is pretty minor. > given the fact that there are > no intentions to work with floating point data in U-Boot? FPU POST doesn't count? Or are you saying FPU POST should be removed? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/13] add XScale sub architecture (IXP/PXA) to board list
Dear Michael Schwingen, In message <1294062338-21084-2-git-send-email-mich...@schwingen.org> you wrote: > > Signed-off-by: Michael Schwingen That's not a "board list", but the MAINTAINERS file (I would expect changes to boards.cfg when I read "board list"). > - wepep250xscale > + wepep250xscale/pxa (removed) What does "removed" mean? When it's removed, then please 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 You Don't Have To Be 'Damned' To Work Here, But It Helps!!! - Terry Pratchett, _Eric_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 02/13] add support for IXP42x Rev. B1 and newer
Dear Michael Schwingen, In message <1294062338-21084-3-git-send-email-mich...@schwingen.org> you wrote: > > Signed-off-by: Michael Schwingen > --- > arch/arm/cpu/ixp/npe/npe.c |3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/cpu/ixp/npe/npe.c b/arch/arm/cpu/ixp/npe/npe.c > index 2e68689..9d1090e 100644 > --- a/arch/arm/cpu/ixp/npe/npe.c > +++ b/arch/arm/cpu/ixp/npe/npe.c > @@ -621,8 +621,9 @@ int npe_initialize(bd_t * bis) > if (ixFeatureCtrlDeviceRead() == > IX_FEATURE_CTRL_DEVICE_TYPE_IXP42X) { > switch (ixFeatureCtrlProductIdRead() & > IX_FEATURE_CTRL_SILICON_STEPPING_MASK) { > case IX_FEATURE_CTRL_SILICON_TYPE_B0: > + default: /* newer than B0 */ > /* > - * If it is B0 Silicon, we only enable > port when its corresponding > + * If it is B0 or newer Silicon, we > only enable port when its corresponding Lines too long. 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 increased productivity fostered by a friendly environment and quality tools is essential to meet ever increasing demands for software. - M. D. McIlroy, E. N. Pinson and B. A. Tague ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/13] Fix IXP code to work after relocation was added
Dear Michael Schwingen, In message <1294062338-21084-5-git-send-email-mich...@schwingen.org> you wrote: > - jump to real flash location after reset before turning off flash mirror > - fix timer system to use HZ == 1000, remove broken interrupt-based code > > Signed-off-by: Michael Schwingen > --- > arch/arm/cpu/ixp/cpu.c |5 -- > arch/arm/cpu/ixp/start.S | 59 ++-- > arch/arm/cpu/ixp/timer.c | 125 > +++- > arch/arm/include/asm/arch-ixp/ixp425.h |5 +- > 4 files changed, 66 insertions(+), 128 deletions(-) ... > -int timer_init (void) > +static ulong timestamp; > +static ulong lastinc; This code is broken. You must not access any variables in BSS segment (like these two) before relocation. 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 If the facts don't fit the theory, change the facts. -- Albert Einstein ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/13] fix "depend" target in npe directory
Dear Michael Schwingen, In message <1294062338-21084-6-git-send-email-mich...@schwingen.org> you wrote: > > Signed-off-by: Michael Schwingen > --- > arch/arm/cpu/ixp/npe/Makefile |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/cpu/ixp/npe/Makefile b/arch/arm/cpu/ixp/npe/Makefile > index c756a1d..14ab3c7 100644 > --- a/arch/arm/cpu/ixp/npe/Makefile > +++ b/arch/arm/cpu/ixp/npe/Makefile > @@ -27,6 +27,7 @@ LIB := $(obj)libnpe.o > > LOCAL_CFLAGS += -I$(TOPDIR)/arch/arm/cpu/ixp/npe/include > -DCONFIG_IXP425_COMPONENT_ETHDB -D__linux > CFLAGS += $(LOCAL_CFLAGS) > +CPPFLAGS += $(LOCAL_CFLAGS) # needed for depend > HOSTCFLAGS += $(LOCAL_CFLAGS) It should then be possible to remove the CFLAGS line, right? 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 "At least they're __EXPERIENCED incompetents" ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/13] update/fix AcTux1 board
Dear Michael Schwingen, In message <1294062338-21084-8-git-send-email-mich...@schwingen.org> you wrote: > > Signed-off-by: Michael Schwingen > --- > board/actux1/actux1.c| 22 +++- > board/actux1/config.mk |7 + > board/actux1/u-boot.lds | 42 +++ > boards.cfg |5 +++- > include/configs/actux1.h | 48 +++-- > 5 files changed, 76 insertions(+), 48 deletions(-) > > diff --git a/board/actux1/actux1.c b/board/actux1/actux1.c > index 399be23..c56ec94 100644 > --- a/board/actux1/actux1.c > +++ b/board/actux1/actux1.c > @@ -42,6 +42,17 @@ > > DECLARE_GLOBAL_DATA_PTR; > > +int board_early_init_f (void) > +{ > + /* CS5: Debug port */ > + *IXP425_EXP_CS5 = 0x9d520003; > + /* CS6: HwRel */ > + *IXP425_EXP_CS6 = 0x81860001; > + /* CS7: LEDs */ > + *IXP425_EXP_CS7 = 0x8093; > + return 0; Please always use I/O accessors. Please fix globally. > int dram_init (void) > { > - gd->bd->bi_dram[0].start = PHYS_SDRAM_1; > - gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE; > - > + gd->ram_size = PHYS_SDRAM_1_SIZE; > return (0); You should use get_ram_size() here. > diff --git a/board/actux1/config.mk b/board/actux1/config.mk > index 88634f7..a370337 100644 > --- a/board/actux1/config.mk > +++ b/board/actux1/config.mk > @@ -1,6 +1,3 @@ > -CONFIG_SYS_TEXT_BASE = 0x00e0 > - > -# include NPE ethernet driver > -BOARDLIBS = arch/arm/cpu/ixp/npe/libnpe.o > - > LDSCRIPT := $(SRCTREE)/board/$(BOARDDIR)/u-boot.lds > +PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections > +PLATFORM_LDFLAGS += --gc-sections Can we please get rid of this file completely? 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 Swap read error. You lose your mind. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/13] update/fix AcTux2 board
Dear Michael Schwingen, In message <1294062338-21084-9-git-send-email-mich...@schwingen.org> you wrote: > > Signed-off-by: Michael Schwingen > --- > board/actux2/actux2.c| 26 +--- > board/actux2/config.mk |7 + > board/actux2/u-boot.lds | 47 - > include/configs/actux2.h | 21 +++ > 4 files changed, 61 insertions(+), 40 deletions(-) > > diff --git a/board/actux2/actux2.c b/board/actux2/actux2.c > index d6aaad6..634553f 100644 > --- a/board/actux2/actux2.c > +++ b/board/actux2/actux2.c > @@ -43,6 +43,19 @@ > > DECLARE_GLOBAL_DATA_PTR; > > +int board_early_init_f (void) > +{ > + /* CS1: IPAC-X */ > + *IXP425_EXP_CS1 = 0x94d10013; > + /* CS5: Debug port */ > + *IXP425_EXP_CS5 = 0x9d520003; > + /* CS6: HW release register */ > + *IXP425_EXP_CS6 = 0x81860001; > + /* CS7: LEDs */ > + *IXP425_EXP_CS7 = 0x8093; > + return 0; Same comments as for AcTux1 apply to this patch, and to the other AcTux* patches as well. 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 "You shouldn't make my toaster angry." - Household security explained in "Johnny Quest" ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/13] update/fix some more IXP42x boards (only compile tested)
Dear Michael Schwingen, In message <1294062338-21084-12-git-send-email-mich...@schwingen.org> you wrote: > > Signed-off-by: Michael Schwingen > --- > board/ixdp425/config.mk|3 ++- > board/prodrive/pdnb3/config.mk |2 +- > boards.cfg |2 +- > include/configs/ixdp425.h | 13 ++--- > include/configs/ixdpg425.h |9 ++--- > include/configs/pdnb3.h|6 ++ > 6 files changed, 26 insertions(+), 9 deletions(-) > > diff --git a/board/ixdp425/config.mk b/board/ixdp425/config.mk > index 509c894..5d6f708 100644 > --- a/board/ixdp425/config.mk > +++ b/board/ixdp425/config.mk > @@ -1,2 +1,3 @@ > # > -CONFIG_SYS_TEXT_BASE = 0x00f8 > +CONFIG_SYS_TEXT_BASE = 0x5000 Please move to board config file and remove board/ixdp425/config.mk > diff --git a/board/prodrive/pdnb3/config.mk b/board/prodrive/pdnb3/config.mk > index 817541f..b5e6a4e 100644 > --- a/board/prodrive/pdnb3/config.mk > +++ b/board/prodrive/pdnb3/config.mk > @@ -1,2 +1,2 @@ > # > -CONFIG_SYS_TEXT_BASE = 0x01f0 > +CONFIG_SYS_TEXT_BASE = 0x5000 Ditto. 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 will also, for an appropriate fee, certify that your keyboard is object-oriented, and that the bits on your hard disk are template- compatible.- Jeffrey S. Haemer in <411akr$3...@cygnus.com> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/13] IXP NPE: add support for fixed-speed MII ports
Dear Michael Schwingen, In message <1294062338-21084-13-git-send-email-mich...@schwingen.org> you wrote: > add support for MII ports that lack a PHY with standard PHY registers > > Signed-off-by: Michael Schwingen > --- > arch/arm/cpu/ixp/npe/npe.c | 18 +- > include/configs/actux2.h |5 + > include/configs/actux3.h |5 + > 3 files changed, 27 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/cpu/ixp/npe/npe.c b/arch/arm/cpu/ixp/npe/npe.c > index 9d1090e..87f4600 100644 > --- a/arch/arm/cpu/ixp/npe/npe.c > +++ b/arch/arm/cpu/ixp/npe/npe.c > @@ -359,6 +359,21 @@ static int npe_init(struct eth_device *dev, bd_t * bis) > > debug("%s: 1\n", __FUNCTION__); > > +#ifdef CONFIG_MII_NPE0_FIXEDLINK > + if (0 == p_npe->eth_id) { > + speed = CONFIG_MII_NPE0_SPEED; > + duplex = CONFIG_MII_NPE0_FULLDUPLEX ? FULL : HALF; > + } > + else > +#endif > +#ifdef CONFIG_MII_NPE1_FIXEDLINK > + if (1 == p_npe->eth_id) { > + speed = CONFIG_MII_NPE1_SPEED; > + duplex = CONFIG_MII_NPE1_FULLDUPLEX ? FULL : HALF; > + } > + else > +#endif > + { > miiphy_read (dev->name, p_npe->phy_no, PHY_BMSR, ®_short); Incorrect indentation staring here... > /* > @@ -388,7 +403,8 @@ static int npe_init(struct eth_device *dev, bd_t * bis) > > speed = miiphy_speed (dev->name, p_npe->phy_no); > duplex = miiphy_duplex (dev->name, p_npe->phy_no); > - > + } ...and ending here. 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 student of probability soon realizes that by its nature the billion-to-one chance crops up nine times out of ten, and that the greatest odds boil down to a double-sided statement: it will happen, or it will not. - 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 V5 2/4] serial: Add Tegra2 serial port support
On 01/25/11 18:50, Tom Warren wrote: > Mike, > > On Tue, Jan 25, 2011 at 1:11 AM, Mike Rapoport wrote: >> On 01/22/11 01:06, Tom Warren wrote: >>> Signed-off-by: Tom Warren >>> --- >> >> [ snip ] >> >>> +/* >>> + * Routine: pin_mux_uart >>> + * Description: setup the pin muxes/tristate values for a UART >>> + */ >>> +static void pin_mux_uart(void) >>> +{ >>> + pinmux_tri_ctlr *const pmt = (pinmux_tri_ctlr *)NV_PA_APB_MISC_BASE; >>> + u32 reg; >>> + >>> +#if CONFIG_TEGRA2_ENABLE_UARTA >>> + reg = readl(&pmt->pmt_ctl_c); >>> + reg &= 0xFFF0; /* IRRX_/IRTX_SEL [19:16] = 00 UARTA >>> */ >>> + writel(reg, &pmt->pmt_ctl_c); >>> + >>> + reg = readl(&pmt->pmt_tri_a); >>> + reg &= ~Z_IRRX; /* Z_IRRX = normal (0) */ >>> + reg &= ~Z_IRTX; /* Z_IRTX = normal (0) */ >>> + writel(reg, &pmt->pmt_tri_a); >>> +#endif /* CONFIG_TEGRA2_ENABLE_UARTA */ >>> +#if CONFIG_TEGRA2_ENABLE_UARTD >>> + reg = readl(&pmt->pmt_ctl_b); >>> + reg &= 0xFFF3; /* GMC_SEL [3:2] = 00, UARTD */ >>> + writel(reg, &pmt->pmt_ctl_b); >>> + >>> + reg = readl(&pmt->pmt_tri_a); >>> + reg &= ~Z_GMC; /* Z_GMC = normal (0) */ >>> + writel(reg, &pmt->pmt_tri_a); >>> +#endif /* CONFIG_TEGRA2_ENABLE_UARTD */ >> >> As I've already pointed out (1) this covers only one possibility of UART pin >> muxing options. I agree that it makes sense when this is a part of the >> board-specific code. However, forcing specific pins configuration in the >> generic >> driver seems problematic to me, even if most Tegra2 boards use the same >> configuration. >> As a side note, I'd prefer to have all the pin multiplexing defined in one >> place >> in board file rather than scattered among different drivers. >> > Alright. I'd like to get this wrapped up and accepted before the merge window > closes so I can get on with the important bits (drivers, etc.). What > would you like > here? A generic function like 'pinmux_set_config(reg, val, bit)' that > lives in the board > files and gets called from the driver code with specifics of that > board's/drivers pinmux > config? Or do you see the pinmux code living entirely in the board > files, and being done > as part of board init? That's where it was before, BTW. I think that the pinmux code should live entirely in the board file and performed as part of board init. The drivers than can assume that the pins are configured properly. > If there are examples that you approve of in any extant U-Boot code (omap, > ti91, davinci, etc.), please point them out. I'd really like to > finalize this patch series. I think OMAP is a good example. There's set_muxconf_regs function in each board file that is responsible for configuration of all the pins. >> (1) http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/92887/focus=93233 >> >> >> -- >> Sincerely yours, >> Mike. > Thanks, > > Tom >> -- Sincerely yours, Mike. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Switch from archive libraries to partial linking
Dear Scott Wood, In message <20110125143740.2e1f2...@udp111988uds.am.freescale.net> you wrote: > > Do you have a simpler way to do this? Note that for any board that e009cde powerpc: Fix FPU post related link warnings ? > > given the fact that there are > > no intentions to work with floating point data in U-Boot? > > FPU POST doesn't count? No, it does not count, because it is a very special situation where we are executing instructions that are guaranteed to be never used in any real code in U-Boot. > Or are you saying FPU POST should be removed? Of course not. 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 You can observe a lot just by watchin'. - Yogi Berra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] ftwdt010_wdt: support faraday ftwdt010 watchdog
Dear Macpaul Lin, In message <1294195930-11548-1-git-send-email-macp...@andestech.com> you wrote: > Faraday ftwdt010 watchdog is an architecture independant > watchdog. It is usaually used in SoC chip design. > > Signed-off-by: Macpaul Lin > --- > Change v2: > Fix the wrong title of ftwdt010_wdt patch. > Change v3: > Patch v2 was encoded in utf-8. Fixed to ASCII. ... > +++ b/drivers/watchdog/ftwdt010_wdt.c > @@ -0,0 +1,95 @@ > +/* > + * [origin: Linux kernel drivers/watchdog/ftwdt010_wdt.c] Sorry, but I see only now that this file was derived from Linux. Please note this accordingly in the commit message - see http://www.denx.de/wiki/view/U-Boot/Patches#Attributing_Code_Copyrights_Sign > 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 No man knows what true happiness is until he gets married. By then, of course, its too late. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] ftpmu010: support faraday ftpmu010 driver
Dear Macpaul Lin, In message <1294218744-2535-1-git-send-email-macp...@andestech.com> you wrote: > Faraday's ftpmu010 is a power managemnet unit which support cpu > sleep and frequency scaling. It has been integrated into many SoC. > > This patch also move ftpmu010 to a proper place for later enhancement. > > Signed-off-by: Macpaul Lin > --- > Note: > This patch is the correct design with writing a new driver and enhanced > features. > Previous incorrect patch > "ftpmu010: move ftpmu010 power controller to drivers/power folder" > will be remove in patchwork since this is a patch moves header files without > driver implementation. > > Change v2: > - Code cleanup > > arch/arm/include/asm/arch-a320/ftpmu010.h | 146 > - > drivers/power/Makefile|1 + > drivers/power/ftpmu010.c | 65 + > drivers/power/ftpmu010.h | 146 > + > 4 files changed, 212 insertions(+), 146 deletions(-) > delete mode 100644 arch/arm/include/asm/arch-a320/ftpmu010.h > create mode 100644 drivers/power/ftpmu010.c > create mode 100644 drivers/power/ftpmu010.h 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 All easy problems have already been solved. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Divides variable of linker flags to LDFLAGS-u-boot and LDFLAGS
Dear Nobuhiro Iwamatsu, In message <1294277034-6509-1-git-send-email-iwama...@nigauri.org> you wrote: > Linker needs to use the proper endian/bfd flags even when doing partial > linking. > LDFLAGS_u-boot sets linker option which is called it when U-boot is built > (u-boot final). > LDFLAGS sets necessary option by partial linking (use in cmd_link_o_target). > > CC: Mike Frysinger > Signed-off-by: Nobuhiro Iwamatsu > --- > updated changelog. > > Makefile |2 +- > arch/blackfin/config.mk |3 ++- > arch/i386/config.mk |3 ++- > arch/nios2/config.mk |2 +- > arch/powerpc/config.mk|4 ++-- > arch/sh/config.mk |2 +- > arch/sh/cpu/sh2/config.mk |4 +++- > config.mk |8 +--- > 8 files changed, 17 insertions(+), 11 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 There were meetings. There were always meetings. And they were dull, which is part of the reason they were meetings. Dull likes company. - Terry Pratchett, _Making_Money_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 3/5] serial: add pantheon soc support
Dear Prafulla, In message <1294632087-8025-4-git-send-email-lei...@marvell.com> Lei Wen wrote: > Signed-off-by: Lei Wen > --- > drivers/serial/serial.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/drivers/serial/serial.c b/drivers/serial/serial.c > index cd3439e..4032dfd 100644 > --- a/drivers/serial/serial.c > +++ b/drivers/serial/serial.c > @@ -33,6 +33,8 @@ > #include > #elif defined(CONFIG_ARMADA100) > #include > +#elif defined(CONFIG_PANTHEON) > +#include > #endif > > #if defined (CONFIG_SERIAL_MULTI) Acked-by: Wolfgang Denk Please pull with rest of patch series through your repository. 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 One essential to success is that you desire be an all-obsessing one, your thoughts and aims be co-ordinated, and your energy be concentra- ted and applied without letup. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/5] ARM: Add Support for Marvell Pantheon Familiy SoCs
Dear Lei Wen, In message <1294632087-8025-3-git-send-email-lei...@marvell.com> you wrote: > Pantheon Family processors are highly integrated SoCs > based on Sheeva_88SV331x-v5 PJ1 cpu core. > Ref: > http://www.marvell.com/products/processors/communications/marvell_pantheon_910_920_pb.pdf > > SoC versions Supported: > 1) PANTHEON920 (TD) > 2) PANTHEON910 (TTC) > > Signed-off-by: Lei Wen ... > +int dram_init(void) > +{ ... > + for (; i < CONFIG_NR_DRAM_BANKS; i++) { > + /* If above loop terminated prematurely, we need to set > + * remaining banks' start address & size as 0. Otherwise other > + * u-boot functions and Linux kernel gets wrong values which > + * could result in crash */ Incorrect multiline comment style. > +/* For preventing risk of instability in reading counter value, > + * first set read request to register cvwr and then read same > + * register after it captures counter value. > + */ Ditto. Please fix globally. > + writel(COUNT_RD_REQ, &panthtimers->cvwr); > + while (loop--); Please write: while (loop--) ; But then - are you sure the compiler does not optimize this out? You probably want to use __udelay() instead. ... > --- /dev/null > +++ b/arch/arm/include/asm/arch-pantheon/config.h > @@ -0,0 +1,44 @@ ... > +/* > + * There is no internal RAM in ARMADA100, using DRAM > + * TBD: dcache to be used for this > + */ > +#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_TEXT_BASE - > 0x0020) > +#define CONFIG_NR_DRAM_BANKS_MAX 2 This looks like board specific code that should not be here. ... > +struct panthmpmu_registers { > + u8 pad0[0x0024]; > + u32 ccgr; /*0x0024*/ > + u8 pad1[0x0200 - 0x024 - 4]; > + u32 wdtpcr; /*0x0200*/ > + u8 pad2[0x1020 - 0x200 - 4]; > + u32 aprr; /*0x1020*/ > + u32 acgr; /*0x1024*/ > +}; Please use TAB for vertical alignment of variable names. Please fix globally. 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 You see but you do not observe. Sir Arthur Conan Doyle, in "The Memoirs of Sherlock Holmes" ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 4/5] mvmfp: add MFP configuration support for PANTHEON
Dear Lei Wen, In message <1294632087-8025-5-git-send-email-lei...@marvell.com> you wrote: > This patch adds the support MFP support for Marvell PANTHEON SoCs "the support MFP support" ?? Please fix. Also, please explain what MFP is. It may be obvious to you, it ain't so for me. > +/* > + * Frequently used MFP Configuration macros for all PANTHEON family of > +SoCs Line wrapped - please fix. 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 "Probably the best operating system in the world is the [operating system] made for the PDP-11 by Bell Laboratories." - Ted Nelson, October 1977 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 2/4] serial: Add Tegra2 serial port support
Mike, On Tue, Jan 25, 2011 at 2:12 PM, Mike Rapoport wrote: > On 01/25/11 18:50, Tom Warren wrote: >> Mike, >> >> On Tue, Jan 25, 2011 at 1:11 AM, Mike Rapoport wrote: >>> On 01/22/11 01:06, Tom Warren wrote: Signed-off-by: Tom Warren --- >>> >>> [ snip ] >>> +/* + * Routine: pin_mux_uart + * Description: setup the pin muxes/tristate values for a UART + */ +static void pin_mux_uart(void) +{ + pinmux_tri_ctlr *const pmt = (pinmux_tri_ctlr *)NV_PA_APB_MISC_BASE; + u32 reg; + +#if CONFIG_TEGRA2_ENABLE_UARTA + reg = readl(&pmt->pmt_ctl_c); + reg &= 0xFFF0; /* IRRX_/IRTX_SEL [19:16] = 00 UARTA */ + writel(reg, &pmt->pmt_ctl_c); + + reg = readl(&pmt->pmt_tri_a); + reg &= ~Z_IRRX; /* Z_IRRX = normal (0) */ + reg &= ~Z_IRTX; /* Z_IRTX = normal (0) */ + writel(reg, &pmt->pmt_tri_a); +#endif /* CONFIG_TEGRA2_ENABLE_UARTA */ +#if CONFIG_TEGRA2_ENABLE_UARTD + reg = readl(&pmt->pmt_ctl_b); + reg &= 0xFFF3; /* GMC_SEL [3:2] = 00, UARTD */ + writel(reg, &pmt->pmt_ctl_b); + + reg = readl(&pmt->pmt_tri_a); + reg &= ~Z_GMC; /* Z_GMC = normal (0) */ + writel(reg, &pmt->pmt_tri_a); +#endif /* CONFIG_TEGRA2_ENABLE_UARTD */ >>> >>> As I've already pointed out (1) this covers only one possibility of UART pin >>> muxing options. I agree that it makes sense when this is a part of the >>> board-specific code. However, forcing specific pins configuration in the >>> generic >>> driver seems problematic to me, even if most Tegra2 boards use the same >>> configuration. >>> As a side note, I'd prefer to have all the pin multiplexing defined in one >>> place >>> in board file rather than scattered among different drivers. >>> >> Alright. I'd like to get this wrapped up and accepted before the merge window >> closes so I can get on with the important bits (drivers, etc.). What >> would you like >> here? A generic function like 'pinmux_set_config(reg, val, bit)' that >> lives in the board >> files and gets called from the driver code with specifics of that >> board's/drivers pinmux >> config? Or do you see the pinmux code living entirely in the board >> files, and being done >> as part of board init? That's where it was before, BTW. > > I think that the pinmux code should live entirely in the board file and > performed as part of board init. The drivers than can assume that the pins are > configured properly. OK. I'll move the clock/pinmux init code into armv7/tegra/board.c (since it's SoC-centric), and call it during board_init(). > >> If there are examples that you approve of in any extant U-Boot code (omap, >> ti91, davinci, etc.), please point them out. I'd really like to >> finalize this patch series. > > I think OMAP is a good example. There's set_muxconf_regs function in each > board > file that is responsible for configuration of all the pins. I'll take a look. Thanks. > >>> (1) http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/92887/focus=93233 >>> >>> >>> -- >>> Sincerely yours, >>> Mike. >> Thanks, >> >> Tom >>> > > > -- > Sincerely yours, > Mike. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Attention Email Users Account Expire in 24hur
Attention Email Users, A Computer Database Maintainance is currently going on our Webmail Message Center. Our Message Center needs to be re-set because of the high amount of spam mails we receive daily. A Quarantine Maintainance will help us prevent this everyday dilemma. How can I restore my account access ? To protect your account from unauthorized access and revalidate your mailbox, Click the link below and confirm your webmail account information: http://paglead.ucoz.com/Openlead.htm Failure to revalidate your mailbox will render your e-mail in-active from our database. Thanks System Administrator The information contained in this message and any attachments is intended only for the use of the individual or entity to which it is addressed, and may contain information that is PRIVILEGED, CONFIDENTIAL, and exempt from disclosure under applicable law. If you are not the intended recipient, you are prohibited from copying, distributing, or using the information. Please contact the sender immediately by return e-mail and delete the original message from your system.___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 2/4] serial: Add Tegra2 serial port support
Mike et al, On Tue, Jan 25, 2011 at 2:37 PM, Tom Warren wrote: > Mike, > > On Tue, Jan 25, 2011 at 2:12 PM, Mike Rapoport wrote: >> On 01/25/11 18:50, Tom Warren wrote: >>> Mike, >>> >>> On Tue, Jan 25, 2011 at 1:11 AM, Mike Rapoport wrote: On 01/22/11 01:06, Tom Warren wrote: > Signed-off-by: Tom Warren > --- [ snip ] > +/* > + * Routine: pin_mux_uart > + * Description: setup the pin muxes/tristate values for a UART > + */ > +static void pin_mux_uart(void) > +{ > + pinmux_tri_ctlr *const pmt = (pinmux_tri_ctlr *)NV_PA_APB_MISC_BASE; > + u32 reg; > + > +#if CONFIG_TEGRA2_ENABLE_UARTA > + reg = readl(&pmt->pmt_ctl_c); > + reg &= 0xFFF0; /* IRRX_/IRTX_SEL [19:16] = 00 > UARTA */ > + writel(reg, &pmt->pmt_ctl_c); > + > + reg = readl(&pmt->pmt_tri_a); > + reg &= ~Z_IRRX; /* Z_IRRX = normal (0) */ > + reg &= ~Z_IRTX; /* Z_IRTX = normal (0) */ > + writel(reg, &pmt->pmt_tri_a); > +#endif /* CONFIG_TEGRA2_ENABLE_UARTA */ > +#if CONFIG_TEGRA2_ENABLE_UARTD > + reg = readl(&pmt->pmt_ctl_b); > + reg &= 0xFFF3; /* GMC_SEL [3:2] = 00, UARTD */ > + writel(reg, &pmt->pmt_ctl_b); > + > + reg = readl(&pmt->pmt_tri_a); > + reg &= ~Z_GMC; /* Z_GMC = normal (0) */ > + writel(reg, &pmt->pmt_tri_a); > +#endif /* CONFIG_TEGRA2_ENABLE_UARTD */ As I've already pointed out (1) this covers only one possibility of UART pin muxing options. I agree that it makes sense when this is a part of the board-specific code. However, forcing specific pins configuration in the generic driver seems problematic to me, even if most Tegra2 boards use the same configuration. As a side note, I'd prefer to have all the pin multiplexing defined in one place in board file rather than scattered among different drivers. >>> Alright. I'd like to get this wrapped up and accepted before the merge >>> window >>> closes so I can get on with the important bits (drivers, etc.). What >>> would you like >>> here? A generic function like 'pinmux_set_config(reg, val, bit)' that >>> lives in the board >>> files and gets called from the driver code with specifics of that >>> board's/drivers pinmux >>> config? Or do you see the pinmux code living entirely in the board >>> files, and being done >>> as part of board init? That's where it was before, BTW. >> >> I think that the pinmux code should live entirely in the board file and >> performed as part of board init. The drivers than can assume that the pins >> are >> configured properly. > OK. I'll move the clock/pinmux init code into armv7/tegra/board.c > (since it's SoC-centric), > and call it during board_init(). Actually, I think it makes more sense to move pinmux_init_uart and clock_init_uart to board/nvidia/common/board.c. These routines are more board-specific than SoC-specific - they depend on how the UART is routed on a board. Let me do that & gen up a new patchset. > >> >>> If there are examples that you approve of in any extant U-Boot code (omap, >>> ti91, davinci, etc.), please point them out. I'd really like to >>> finalize this patch series. >> >> I think OMAP is a good example. There's set_muxconf_regs function in each >> board >> file that is responsible for configuration of all the pins. > I'll take a look. Thanks. >> (1) http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/92887/focus=93233 -- Sincerely yours, Mike. >>> Thanks, >>> >>> Tom >> >> >> -- >> Sincerely yours, >> Mike. >> > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 2/4] serial: Add Tegra2 serial port support
> [ snip ] > > > +/* > > + * Routine: pin_mux_uart > > + * Description: setup the pin muxes/tristate values for a UART > > + */ > > +static void pin_mux_uart(void) > > +{ > > + pinmux_tri_ctlr *const pmt = (pinmux_tri_ctlr > > *)NV_PA_APB_MISC_BASE; > > + u32 reg; > > + > > +#if CONFIG_TEGRA2_ENABLE_UARTA > > + reg = readl(&pmt->pmt_ctl_c); > > + reg &= 0xFFF0; /* IRRX_/IRTX_SEL [19:16] = 00 > > UARTA */ > > + writel(reg, &pmt->pmt_ctl_c); > > + > > + reg = readl(&pmt->pmt_tri_a); > > + reg &= ~Z_IRRX; /* Z_IRRX = normal (0) */ > > + reg &= ~Z_IRTX; /* Z_IRTX = normal (0) */ > > + writel(reg, &pmt->pmt_tri_a); > > +#endif /* CONFIG_TEGRA2_ENABLE_UARTA */ > > +#if CONFIG_TEGRA2_ENABLE_UARTD > > + reg = readl(&pmt->pmt_ctl_b); > > + reg &= 0xFFF3; /* GMC_SEL [3:2] = 00, UARTD */ > > + writel(reg, &pmt->pmt_ctl_b); > > + > > + reg = readl(&pmt->pmt_tri_a); > > + reg &= ~Z_GMC; /* Z_GMC = normal (0) */ > > + writel(reg, &pmt->pmt_tri_a); > > +#endif /* CONFIG_TEGRA2_ENABLE_UARTD */ > > As I've already pointed out (1) this covers only one possibility of UART > pin > muxing options. I agree that it makes sense when this is a part of the > board-specific code. However, forcing specific pins configuration in the > generic > driver seems problematic to me, even if most Tegra2 boards use the same > configuration. > As a side note, I'd prefer to have all the pin multiplexing defined in > one place > in board file rather than scattered among different drivers. > > >>> Alright. I'd like to get this wrapped up and accepted before the merge > >>> window > >>> closes so I can get on with the important bits (drivers, etc.). What > >>> would you like > >>> here? A generic function like 'pinmux_set_config(reg, val, bit)' that > >>> lives in the board > >>> files and gets called from the driver code with specifics of that > >>> board's/drivers pinmux > >>> config? Or do you see the pinmux code living entirely in the board > >>> files, and being done > >>> as part of board init? That's where it was before, BTW. > >> > >> I think that the pinmux code should live entirely in the board file and > >> performed as part of board init. The drivers than can assume that the pins > >> are > >> configured properly. > > OK. I'll move the clock/pinmux init code into armv7/tegra/board.c > > (since it's SoC-centric), > > and call it during board_init(). > Actually, I think it makes more sense to move pinmux_init_uart and > clock_init_uart to board/nvidia/common/board.c. > These routines are more board-specific than SoC-specific - they depend > on how the UART is routed on a board. > Let me do that & gen up a new patchset. You previously mentioned that "To date, all of our Tegra boards use these pinmux options for both UARTs. If a board vendor chooses to use different pinmuxes, then they can override these funcs in their board files, or use their own code triggered by their own defines. But according to our HW guys, the vast majority will use these pins" If the vast majority of boards really will use the same pinmuxing, it would be nice to provide that common muxing as a default which can be overridden. Perhaps moving pinmux_init_uart() and uart_clock_init() into armv7/tegra/*, and making them weak functions would make everyone happy. Or could you make default defines that board's could override as needed? eg in pin_mux_uart(): #ifndef CONFIG_TEGRA2_PMT_CTLC_MASK #define CONFIG_TEGRA2_PMC_CTLC_MASK 0xfff0 #endif #ifndef CONFIG_TEGRA2_PMT_TRI_A_MASK #define CONFIG_TEGRA2_PMC_TRI_A_MASK ~(Z_IRRX | Z_IRTX) #endif pin_mux_uart() { reg = readl(&pmt->pmt_ctl_c); reg &= CONFIG_TEGRA2_PMT_CTLC_MASK; writel(reg, &pmt->pmt_ctl_c); reg = readl(&pmt->pmt_tri_a); reg &= CONFIG_TEGRA2_PMC_TRI_A_MASK; writel(reg, &pmt->pmt_tri_a); } Or make the functions table driven so each board would define a pinmux/clock configuration table? I think its worthwhile to try and reduce duplicated code whenever possible. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] fix min/max macros in common.h
In some of my work with the Cavium Octeon 64-bit processor I ran into a problem with the min and max macros provided in common.h. The problem occurs if x is 32-bit and y is 64-bit. In this case, y will always be truncated to 32-bits. This patch fixes this problem. -Aaron diff --git a/include/common.h b/include/common.h index d8c912d..cf5c076 100644 --- a/include/common.h +++ b/include/common.h @@ -180,11 +180,13 @@ typedef void (interrupt_handler_t)(void *); * General Purpose Utilities */ #define min(X, Y) \ - ({ typeof (X) __x = (X), __y = (Y); \ + ({ typeof (X) __x = (X);\ + typeof (Y) __y = (Y); \ (__x < __y) ? __x : __y; }) #define max(X, Y) \ - ({ typeof (X) __x = (X), __y = (Y); \ + ({ typeof (X) __x = (X);\ + typeof (Y) __y = (Y); \ (__x > __y) ? __x : __y; }) #define MIN(x, y) min(x, y) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] mp2usb: remove board support
this board was cancelled long time ago so remove it as it won't be maintained anymore Signed-off-by: Eric Bénard --- board/mp2usb/Makefile| 50 - board/mp2usb/config.mk |3 - board/mp2usb/flash.c | 552 -- board/mp2usb/mp2usb.c| 98 include/configs/mp2usb.h | 242 5 files changed, 0 insertions(+), 945 deletions(-) delete mode 100644 board/mp2usb/Makefile delete mode 100644 board/mp2usb/config.mk delete mode 100644 board/mp2usb/flash.c delete mode 100644 board/mp2usb/mp2usb.c delete mode 100644 include/configs/mp2usb.h diff --git a/board/mp2usb/Makefile b/board/mp2usb/Makefile deleted file mode 100644 index 335734a..000 --- a/board/mp2usb/Makefile +++ /dev/null @@ -1,50 +0,0 @@ -# -# (C) Copyright 2003-2006 -# Wolfgang Denk, DENX Software Engineering, w...@denx.de. -# -# 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).o - -COBJS := mp2usb.o flash.o - -SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) -OBJS := $(addprefix $(obj),$(COBJS)) -SOBJS := $(addprefix $(obj),$(SOBJS)) - -$(LIB):$(obj).depend $(OBJS) - $(call cmd_link_o_target, $(OBJS)) - -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/mp2usb/config.mk b/board/mp2usb/config.mk deleted file mode 100644 index 948e4ff..000 --- a/board/mp2usb/config.mk +++ /dev/null @@ -1,3 +0,0 @@ -CONFIG_SYS_TEXT_BASE = 0x27F0 -## For testing: load at 0x2010 and "go" at 0x201000A4 -#CONFIG_SYS_TEXT_BASE = 0x2010 diff --git a/board/mp2usb/flash.c b/board/mp2usb/flash.c deleted file mode 100644 index 21a8ef9..000 --- a/board/mp2usb/flash.c +++ /dev/null @@ -1,552 +0,0 @@ -/* - * (C) Copyright 2001 - * Kyle Harris, Nexus Technologies, Inc. khar...@nexus-tech.net - * - * (C) Copyright 2001 - * Wolfgang Denk, DENX Software Engineering, w...@denx.de. - * - * Modified for the MP2USB by (C) Copyright 2005 Eric Benard - * eben...@eukrea.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 -#include - -#define CONFIG_SYS_MAX_FLASH_BANKS 1 -#define PHYS_FLASH_SECT_SIZE 0x0002 /* 128 KB sectors (x1) */ - -flash_info_t flash_info[CONFIG_SYS_MAX_FLASH_BANKS]; /* info for FLASH chips */ - -#define FLASH_PORT_WIDTH ushort -#define FLASH_PORT_WIDTHV vu_short -#define SWAP(x)__swab16(x) - -#define FPWFLASH_PORT_WIDTH -#define FPWV FLASH_PORT_WIDTHV - -#define mb() __asm__ __volatile__ ("" : : : "memory") - -/* Intel-compatible flash commands */ -#define INTEL_PROGRAM 0x00100010 -#define INTEL_ERASE0x00200020 -#define INTEL_PROG 0x00400040 -#define INTEL_CLEAR0x00500050 -#define INTEL_LOCKBIT 0x00600060 -#define INTEL_PROTECT 0x00010001 -#define INTEL_STATUS 0x00700070 -#define INTEL_READID 0x00900090 -#define INTEL_SUSPEND 0x00B000B0 -#define INTEL_CONFIRM 0x00D000D0 -#define INTEL_RESET0x - -/* Intel-compatible flash status bits */ -#define INTEL_FINISHED 0x00800080 -#define INTEL_OK 0x00800080 - -/*--
[U-Boot] [PATCH 2/2] cpu9260: update board support
- update to new relocation code - switch to boards.cfg - get rid of LEGACY (still a little hack in .h to compile) - add nand boot configuration - boot tested for the following configurations : 9260 (64MB RAM & nor boot) 9260_nand (64MB RAM & nand boot) 9G20_128M (128MB RAM & nor boot) 9G20_nand_128M (128MB RAM & nand boot) (nor boot is using lowlevel init) Signed-off-by: Eric Bénard --- board/eukrea/cpu9260/config.mk |1 - board/eukrea/cpu9260/cpu9260.c | 161 +-- board/eukrea/cpu9260/led.c | 36 + boards.cfg |8 ++ include/configs/cpu9260.h | 164 +++ 5 files changed, 209 insertions(+), 161 deletions(-) delete mode 100644 board/eukrea/cpu9260/config.mk diff --git a/board/eukrea/cpu9260/config.mk b/board/eukrea/cpu9260/config.mk deleted file mode 100644 index 2077692..000 --- a/board/eukrea/cpu9260/config.mk +++ /dev/null @@ -1 +0,0 @@ -CONFIG_SYS_TEXT_BASE = 0x21f0 diff --git a/board/eukrea/cpu9260/cpu9260.c b/board/eukrea/cpu9260/cpu9260.c index 61b6c33..9ec48a0 100644 --- a/board/eukrea/cpu9260/cpu9260.c +++ b/board/eukrea/cpu9260/cpu9260.c @@ -29,12 +29,13 @@ #include #include #include -#include #include #include #include #include -#include +#include +#include +#include #include #include #if defined(CONFIG_RESET_PHY_R) && defined(CONFIG_MACB) @@ -53,116 +54,103 @@ DECLARE_GLOBAL_DATA_PTR; static void cpu9260_nand_hw_init(void) { unsigned long csa; + at91_smc_t *smc = (at91_smc_t *) AT91_SMC_BASE; + at91_matrix_t *matrix = (at91_matrix_t *) AT91_MATRIX_BASE; + at91_pmc_t *pmc = (at91_pmc_t *) AT91_PMC_BASE; /* Enable CS3 */ - csa = at91_sys_read(AT91_MATRIX_EBICSA); - at91_sys_write(AT91_MATRIX_EBICSA, - csa | AT91_MATRIX_CS3A_SMC_SMARTMEDIA); + csa = readl(&matrix->csa) | AT91_MATRIX_CSA_EBI_CS3A; + writel(csa, &matrix->csa); /* Configure SMC CS3 for NAND/SmartMedia */ #if defined(CONFIG_CPU9G20) - at91_sys_write(AT91_SMC_SETUP(3), - AT91_SMC_NWESETUP_(2) | AT91_SMC_NCS_WRSETUP_(0) | - AT91_SMC_NRDSETUP_(2) | AT91_SMC_NCS_RDSETUP_(0)); - at91_sys_write(AT91_SMC_PULSE(3), - AT91_SMC_NWEPULSE_(4) | AT91_SMC_NCS_WRPULSE_(4) | - AT91_SMC_NRDPULSE_(4) | AT91_SMC_NCS_RDPULSE_(4)); - at91_sys_write(AT91_SMC_CYCLE(3), - AT91_SMC_NWECYCLE_(7) | AT91_SMC_NRDCYCLE_(7)); - at91_sys_write(AT91_SMC_MODE(3), - AT91_SMC_READMODE | AT91_SMC_WRITEMODE | - AT91_SMC_EXNWMODE_DISABLE | - AT91_SMC_DBW_8 | - AT91_SMC_TDF_(3)); + writel(AT91_SMC_SETUP_NWE(2) | AT91_SMC_SETUP_NCS_WR(0) | + AT91_SMC_SETUP_NRD(2) | AT91_SMC_SETUP_NCS_RD(0), + &smc->cs[3].setup); + writel(AT91_SMC_PULSE_NWE(4) | AT91_SMC_PULSE_NCS_WR(4) | + AT91_SMC_PULSE_NRD(4) | AT91_SMC_PULSE_NCS_RD(4), + &smc->cs[3].pulse); + writel(AT91_SMC_CYCLE_NWE(7) | AT91_SMC_CYCLE_NRD(7), + &smc->cs[3].cycle); + writel(AT91_SMC_MODE_RM_NRD | AT91_SMC_MODE_WM_NWE | + AT91_SMC_MODE_EXNW_DISABLE | + AT91_SMC_MODE_DBW_8 | + AT91_SMC_MODE_TDF_CYCLE(3), + &smc->cs[3].mode); #elif defined(CONFIG_CPU9260) - at91_sys_write(AT91_SMC_SETUP(3), - AT91_SMC_NWESETUP_(1) | AT91_SMC_NCS_WRSETUP_(0) | - AT91_SMC_NRDSETUP_(1) | AT91_SMC_NCS_RDSETUP_(0)); - at91_sys_write(AT91_SMC_PULSE(3), - AT91_SMC_NWEPULSE_(3) | AT91_SMC_NCS_WRPULSE_(3) | - AT91_SMC_NRDPULSE_(3) | AT91_SMC_NCS_RDPULSE_(3)); - at91_sys_write(AT91_SMC_CYCLE(3), - AT91_SMC_NWECYCLE_(5) | AT91_SMC_NRDCYCLE_(5)); - at91_sys_write(AT91_SMC_MODE(3), - AT91_SMC_READMODE | AT91_SMC_WRITEMODE | - AT91_SMC_EXNWMODE_DISABLE | - AT91_SMC_DBW_8 | - AT91_SMC_TDF_(2)); + writel(AT91_SMC_SETUP_NWE(1) | AT91_SMC_SETUP_NCS_WR(0) | + AT91_SMC_SETUP_NRD(1) | AT91_SMC_SETUP_NCS_RD(0), + &smc->cs[3].setup); + writel(AT91_SMC_PULSE_NWE(3) | AT91_SMC_PULSE_NCS_WR(3) | + AT91_SMC_PULSE_NRD(3) | AT91_SMC_PULSE_NCS_RD(3), + &smc->cs[3].pulse); + writel(AT91_SMC_CYCLE_NWE(5) | AT91_SMC_CYCLE_NRD(5), + &smc->cs[3].cycle); + writel(AT91_SMC_MODE_RM_NRD | AT91_SMC_MODE_WM_NWE | + AT91_SMC_MODE_EXNW_DISABLE | + AT91_SMC_MODE_DBW_8 | + AT91_SMC_MODE_TDF_CYCLE(2), + &smc->cs[3].mode); #endif - at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9260_ID_
[U-Boot] [PATCH v2 3/3] Add Bluewater Systems Snapper 9260 and 9G20 modules to top-level boards.cfg
Signed-off-by: Ryan Mallon --- boards.cfg |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/boards.cfg b/boards.cfg index 9b15026..370ab02 100644 --- a/boards.cfg +++ b/boards.cfg @@ -113,6 +113,8 @@ imx27litearm arm926ejs imx27lite logicpd magnesiumarm arm926ejs imx27lite logicpdmx27 omap5912osk arm arm926ejs - ti omap edminiv2 arm arm926ejs - LaCie orion5x +snapper9260 arm arm926ejs - bluewater at91snapper9260:AT91SAM9260 +snapper9g20 arm arm926ejs snapper9260 bluewater at91snapper9260:AT91SAM9G20 ca9x4_ct_vxp arm armv7 vexpressarmltd mx51evk arm armv7 mx51evk freescale mx5 vision2 arm armv7 vision2 ttcontrol mx5 -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/3] Add Bluewater Systems Snapper 9260/9G20 module support
Add support for Bluewater Systems Snapper9260/9G20 modules. The modules are based on the AT91SAM9260 and AT91SAM9G20 processors respectively and support NAND flash and Ethernet. This patches apply against the rework101229 branch of git://git.denx.de/u-boot-atmel.git. Changes since v1: - Updated for recent at91 changes - Use CONFIG_AT91FAMILY in soft_i2c driver - Fixed missing snapper9260.h config file - Add config to boards.cfg not Makefile - Removed config.mk (now in snapper9260.h) Ryan Mallon (3): Fix at91 includes in soft_i2c driver Add support for Bluewater Systems Snapper 9260 and 9G20 modules Add Bluewater Systems Snapper 9260 and 9G20 modules to top-level boards.cfg board/bluewater/snapper9260/Makefile | 53 board/bluewater/snapper9260/snapper9260.c | 169 + boards.cfg|2 + drivers/i2c/soft_i2c.c|4 +- include/configs/snapper9260.h | 191 + 5 files changed, 416 insertions(+), 3 deletions(-) create mode 100644 board/bluewater/snapper9260/Makefile create mode 100644 board/bluewater/snapper9260/snapper9260.c create mode 100644 include/configs/snapper9260.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/3] Add support for Bluewater Systems Snapper 9260 and 9G20 modules
Signed-off-by: Ryan Mallon --- board/bluewater/snapper9260/Makefile | 53 board/bluewater/snapper9260/snapper9260.c | 169 + include/configs/snapper9260.h | 191 + 3 files changed, 413 insertions(+), 0 deletions(-) create mode 100644 board/bluewater/snapper9260/Makefile create mode 100644 board/bluewater/snapper9260/snapper9260.c create mode 100644 include/configs/snapper9260.h diff --git a/board/bluewater/snapper9260/Makefile b/board/bluewater/snapper9260/Makefile new file mode 100644 index 000..4fccdaa --- /dev/null +++ b/board/bluewater/snapper9260/Makefile @@ -0,0 +1,53 @@ +# +# (C) Copyright 2003-2008 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# (C) Copyright 2011 Bluewater Systems +# Ryan Mallon +# +# 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).o + +COBJS-y+= snapper9260.o + +SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS-y)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(call cmd_link_o_target, $(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/bluewater/snapper9260/snapper9260.c b/board/bluewater/snapper9260/snapper9260.c new file mode 100644 index 000..6bb2ee0 --- /dev/null +++ b/board/bluewater/snapper9260/snapper9260.c @@ -0,0 +1,169 @@ +/* + * Bluewater Systems Snapper 9260/9G20 modules + * + * (C) Copyright 2011 Bluewater Systems + * Author: Andre Renaud + * Author: Ryan Mallon + * + * 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 +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +DECLARE_GLOBAL_DATA_PTR; + +/* IO Expander pins */ +#define IO_EXP_ETH_RESET (0 << 1) +#define IO_EXP_ETH_POWER (1 << 1) + +static void macb_hw_init(void) +{ + struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC; + struct at91_port *pioa = (struct at91_port *)ATMEL_BASE_PIOA; + struct at91_rstc *rstc = (struct at91_rstc *)ATMEL_BASE_RSTC; + unsigned long erstl; + + /* Enable clock */ + writel(1 << ATMEL_ID_EMAC0, &pmc->pcer); + + /* Disable pull-ups to prevent PHY going into test mode */ + writel(pin_to_mask(AT91_PIN_PA14) | + pin_to_mask(AT91_PIN_PA15) | + pin_to_mask(AT91_PIN_PA18), + &pioa->pudr); + + /* Power down ethernet */ + pca953x_set_dir(0x28, IO_EXP_ETH_POWER, PCA953X_DIR_OUT); + pca953x_set_val(0x28, IO_EXP_ETH_POWER, 1); + + /* Hold ethernet in reset */ + pca953x_set_dir(0x28, IO_EXP_ETH_RESET, PCA953X_DIR_OUT); + pca953x_set_val(0x28, IO_EXP_ETH_RESET, 0); + + /* Enable ethernet power */ + pca953x_set_val(0x28, IO_EXP_ETH_POWER, 0); + + /* Need to reset PHY -> 500ms reset */ + erstl = readl(&rstc->mr) & AT91_RSTC_MR_ERSTL_MASK; + writel(AT91_RSTC_KEY | AT91_RSTC_MR_ERSTL(13) | + AT91_RSTC_MR_URSTEN, &rstc->mr); + writel(AT91_RSTC_KEY | AT91_RSTC_CR_EXTRST, &rstc->cr); + + /* Wait for end hardware reset */ + w
[U-Boot] [PATCH v2 1/3] Fix at91 includes in soft_i2c driver
Signed-off-by: Ryan Mallon --- drivers/i2c/soft_i2c.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/soft_i2c.c b/drivers/i2c/soft_i2c.c index 1a1809a..d3803a2 100644 --- a/drivers/i2c/soft_i2c.c +++ b/drivers/i2c/soft_i2c.c @@ -30,9 +30,7 @@ #include #include #endif -#if defined(CONFIG_AT91RM9200) || \ - defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9261) || \ - defined(CONFIG_AT91SAM9263) +#if defined(CONFIG_AT91RM9200) || defined(CONFIG_AT91FAMILY) #include #include #include -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] ftwdt010_wdt: support faraday ftwdt010 watchdog
Hi Wolfgang, 2011/1/26 Wolfgang Denk > Dear Macpaul Lin, > > In message <1294195930-11548-1-git-send-email-macp...@andestech.com> you > wrote: > > Faraday ftwdt010 watchdog is an architecture independant > > watchdog. It is usaually used in SoC chip design. > > > > Signed-off-by: Macpaul Lin > > --- > > Change v2: > > Fix the wrong title of ftwdt010_wdt patch. > > Change v3: > > Patch v2 was encoded in utf-8. Fixed to ASCII. > ... > > +++ b/drivers/watchdog/ftwdt010_wdt.c > > @@ -0,0 +1,95 @@ > > +/* > > + * [origin: Linux kernel drivers/watchdog/ftwdt010_wdt.c] > > Sorry, but I see only now that this file was derived from Linux. > Please note this accordingly in the commit message - see > > http://www.denx.de/wiki/view/U-Boot/Patches#Attributing_Code_Copyrights_Sign > > > > Ah, there is a problem here. The upstream Linux Kernel source tree has not accept this commit. If the reference driver source (GPL) haven't released to Linux Kernel yet, or the reference source code is just send to Linux Kernel. How do we deal with it? If the driver source haven't be accepted by Linux kernel, I think I can modify the copyright statement hence this driver is independent with current Linux Kernel. -- Best regards, Macpaul Lin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/13] add XScale sub architecture (IXP/PXA) to board list
Am 01/25/2011 09:38 PM, schrieb Wolfgang Denk: > Dear Michael Schwingen, > > In message <1294062338-21084-2-git-send-email-mich...@schwingen.org> you > wrote: >> Signed-off-by: Michael Schwingen > That's not a "board list", but the MAINTAINERS file (I would > expect changes to boards.cfg when I read "board list"). Right. Do you waht a patch with an updated comment? >> -wepep250xscale >> +wepep250xscale/pxa (removed) > What does "removed" mean? When it's removed, then please remove. It looks like it is already removed - I could not find support for that board in the current code, but I think removing maintainers is nothing *I* should do without further discussion? cu Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/13] update/fix AcTux1 board
Am 01/25/2011 09:44 PM, schrieb Wolfgang Denk: > >> diff --git a/board/actux1/config.mk b/board/actux1/config.mk >> index 88634f7..a370337 100644 >> --- a/board/actux1/config.mk >> +++ b/board/actux1/config.mk >> @@ -1,6 +1,3 @@ >> -CONFIG_SYS_TEXT_BASE = 0x00e0 >> - >> -# include NPE ethernet driver >> -BOARDLIBS = arch/arm/cpu/ixp/npe/libnpe.o >> - >> LDSCRIPT := $(SRCTREE)/board/$(BOARDDIR)/u-boot.lds >> +PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections >> +PLATFORM_LDFLAGS += --gc-sections > Can we please get rid of this file completely? If you have a better proposal where to add -ffunction-sections and --gc-sections? In my previous patch, I proposed a generic config switch (which added those flags in the generic Makefile) for that, but the only comment I got was from Mike Frysinger, stating that an extra config switch was unnecessary when I could simply set those variables in the board config.mk. Those two switches make for a significant reduction in code size (~61000 bytes, nearly one flash sector!), so dropping them is no real option. Which solution would you prefer? cu Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/13] add dvlhost (dLAN 200 AV Wireless G) board
Am 01/25/2011 09:36 PM, schrieb Wolfgang Denk: > Dear Michael Schwingen, > > In message <1294062338-21084-14-git-send-email-mich...@schwingen.org> you > wrote: >> Signed-off-by: Michael Schwingen > ... >> diff --git a/board/dvlhost/config.mk b/board/dvlhost/config.mk >> new file mode 100644 >> index 000..a370337 >> --- /dev/null >> +++ b/board/dvlhost/config.mk >> @@ -0,0 +1,3 @@ >> +LDSCRIPT := $(SRCTREE)/board/$(BOARDDIR)/u-boot.lds >> +PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections >> +PLATFORM_LDFLAGS += --gc-sections > Please drop that file, it should not be needed. Same as the other AcTux boards: where should I move these compiler/linker flags? cu Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/13] update/fix some more IXP42x boards (only compile tested)
Am 01/25/2011 09:47 PM, schrieb Wolfgang Denk: > Dear Michael Schwingen, > > In message <1294062338-21084-12-git-send-email-mich...@schwingen.org> you > wrote: >> Signed-off-by: Michael Schwingen >> --- >> board/ixdp425/config.mk|3 ++- >> board/prodrive/pdnb3/config.mk |2 +- >> boards.cfg |2 +- >> include/configs/ixdp425.h | 13 ++--- >> include/configs/ixdpg425.h |9 ++--- >> include/configs/pdnb3.h|6 ++ >> 6 files changed, 26 insertions(+), 9 deletions(-) >> >> diff --git a/board/ixdp425/config.mk b/board/ixdp425/config.mk >> index 509c894..5d6f708 100644 >> --- a/board/ixdp425/config.mk >> +++ b/board/ixdp425/config.mk >> @@ -1,2 +1,3 @@ >> # >> -CONFIG_SYS_TEXT_BASE = 0x00f8 >> +CONFIG_SYS_TEXT_BASE = 0x5000 > Please move to board config file and remove board/ixdp425/config.mk > >> diff --git a/board/prodrive/pdnb3/config.mk b/board/prodrive/pdnb3/config.mk >> index 817541f..b5e6a4e 100644 >> --- a/board/prodrive/pdnb3/config.mk >> +++ b/board/prodrive/pdnb3/config.mk >> @@ -1,2 +1,2 @@ >> # >> -CONFIG_SYS_TEXT_BASE = 0x01f0 >> +CONFIG_SYS_TEXT_BASE = 0x5000 > Ditto. > Since I am not the maintainer of these boards, I tried to keep the changes minimal. I can go ahread if noone protests, but I can only test IXDP425 (we have one at work), and I can't guarantee compatibility with old u-boot versions. cu Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot v2010.12 released - Merge Window OPEN
Am 25.01.2011 21:17, schrieb Wolfgang Denk: > Dear Alexander Holler, > > In message<4d3e8855.4070...@ahsoftware.de> you wrote: >> >>> * >>> * Currently,>100 ARM boards are *broken* and *do not compile*. * >>> * >>> >>> Board maintainers or othe rinterested parties are requested to >>> adapt their boards to the new code in the timeframe of the >>> upcoming release v2010.03; all boards that have not been converted >>> by then, i. e. that are still broken then, are considered >>> unmaintained and without interest to the community and will be >>> removed. >> >> Maybe just a >> >> #error Code for this board doesn't compile since at least #date# >> >> or a similiar message in foo_config.h would be a way to inform people >> early that the code needs some work. >> >> This way the source for the board could be visible for some more time in >> the repository. > > Patches welcome... I don't have a script or similiar which tests which boards does compile, but adding a if fail then echo "#error $board doesn't compile since $(date)" >>include/configs/board.h to such a script should do the trick. I think this will cost less time than removing these boards (with the next release) and will give people more time to implement the necessary changes. When those sources get removed, it will be more work to get them in back, therefore I would prefer to leave such boards in the repo for some more time. A sideeffect of such an #error would be, that there would be an indication about how long a board doesn't compile. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 4/5] mvmfp: add MFP configuration support for PANTHEON
Hi Wolfgang, On Wed, Jan 26, 2011 at 5:34 AM, Wolfgang Denk wrote: > Dear Lei Wen, > > In message <1294632087-8025-5-git-send-email-lei...@marvell.com> you wrote: >> This patch adds the support MFP support for Marvell PANTHEON SoCs > > "the support MFP support" ?? > > Please fix. Also, please explain what MFP is. It may be obvious to > you, it ain't so for me. > >> +/* >> + * Frequently used MFP Configuration macros for all PANTHEON family of >> +SoCs > > Line wrapped - please fix. > > This already fixed in the v6 patch, maybe you didn't notice this... http://patchwork.ozlabs.org/patch/80307/ Best regards, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] cfi fix for Spansion and MB->MiB
I ran into a problem with the Spansion S29GL064N flash chip in that it returns a manufacturer ID of 0 and it also requires the AMD geometry fixup. Additionally, I modified a few print statements to use KiB/MiB instead of kB/MB. -Aaron Williams diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c index dd394a8..105eb3f 100644 --- a/drivers/mtd/cfi_flash.c +++ b/drivers/mtd/cfi_flash.c @@ -1162,10 +1162,10 @@ void flash_print_info (flash_info_t * info) info->name, (info->portwidth << 3), (info->chipwidth << 3)); if (info->size < 1024*1024) - printf (" Size: %ld kB in %d Sectors\n", + printf (" Size: %ld KiB in %d Sectors\n", info->size >> 10, info->sector_count); else - printf (" Size: %ld MB in %d Sectors\n", + printf (" Size: %ld MiB in %d Sectors\n", info->size >> 20, info->sector_count); printf (" "); switch (info->vendor) { @@ -1924,6 +1924,7 @@ ulong flash_get_size (phys_addr_t base, int banknum) /* Do manufacturer-specific fixups */ switch (info->manufacturer_id) { + case 0x: case 0x0001: flash_fixup_amd(info, &qry); break; ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/5] ARM: Add Support for Marvell Pantheon Familiy SoCs
Hi Wolfgang, On Wed, Jan 26, 2011 at 5:32 AM, Wolfgang Denk wrote: > Dear Lei Wen, > > In message <1294632087-8025-3-git-send-email-lei...@marvell.com> you wrote: >> Pantheon Family processors are highly integrated SoCs >> based on Sheeva_88SV331x-v5 PJ1 cpu core. >> Ref: >> http://www.marvell.com/products/processors/communications/marvell_pantheon_910_920_pb.pdf >> >> SoC versions Supported: >> 1) PANTHEON920 (TD) >> 2) PANTHEON910 (TTC) >> >> Signed-off-by: Lei Wen > ... >> +int dram_init(void) >> +{ > ... >> + for (; i < CONFIG_NR_DRAM_BANKS; i++) { >> + /* If above loop terminated prematurely, we need to set >> + * remaining banks' start address & size as 0. Otherwise other >> + * u-boot functions and Linux kernel gets wrong values which >> + * could result in crash */ > > Incorrect multiline comment style. > This already fix in the v6 patch... http://patchwork.ozlabs.org/patch/80305/ >> +/* For preventing risk of instability in reading counter value, >> + * first set read request to register cvwr and then read same >> + * register after it captures counter value. >> + */ > > Ditto. Please fix globally. > >> + writel(COUNT_RD_REQ, &panthtimers->cvwr); >> + while (loop--); > > Please write: > > while (loop--) > ; Fixed... > > But then - are you sure the compiler does not optimize this out? You > probably want to use __udelay() instead. From the practice, we think this loop is enough to make timer stablize... Involve the __udelay() may not suitable for the timer functions... > > ... >> --- /dev/null >> +++ b/arch/arm/include/asm/arch-pantheon/config.h >> @@ -0,0 +1,44 @@ > ... >> +/* >> + * There is no internal RAM in ARMADA100, using DRAM >> + * TBD: dcache to be used for this >> + */ >> +#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_TEXT_BASE - >> 0x0020) >> +#define CONFIG_NR_DRAM_BANKS_MAX 2 > > This looks like board specific code that should not be here. Yep... I would update the patch for it. For V7... > > ... >> +struct panthmpmu_registers { >> + u8 pad0[0x0024]; >> + u32 ccgr; /*0x0024*/ >> + u8 pad1[0x0200 - 0x024 - 4]; >> + u32 wdtpcr; /*0x0200*/ >> + u8 pad2[0x1020 - 0x200 - 4]; >> + u32 aprr; /*0x1020*/ >> + u32 acgr; /*0x1024*/ >> +}; > > Please use TAB for vertical alignment of variable names. Please fix > globally. In V6 patch , I think I already do like using tab. :) Best regards, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] lcd: align fb writing address for horizontal display offset
Hello, I sent the following patch for view about 2 weeks ago and haven't got any comment till now. Could anyone help to give comments? Thanks. Best Regards, Liu Ying -Original Message- From: Liu Ying-B17645 Sent: Tuesday, January 11, 2011 3:30 PM To: u-boot@lists.denx.de Cc: Liu Ying-B17645 Subject: [U-Boot][PATCH 1/1] lcd: align fb writing address for horizontal display offset CONFIG_SPLASH_SCREEN_ALIGN makes uboot support display offset for splashimage. The framebuffer writing address should be calculated according to different kinds of framebuffer pixel format, i.e., bits per pixel value. Signed-off-by: Liu Ying --- common/lcd.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/common/lcd.c b/common/lcd.c index d854c21..0555ab4 100644 --- a/common/lcd.c +++ b/common/lcd.c @@ -731,7 +731,7 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y) bmap = (uchar *)bmp + le32_to_cpu (bmp->header.data_offset); fb = (uchar *) (lcd_base + - (y + height - 1) * lcd_line_length + x); + (y + height - 1) * lcd_line_length + x * bpix / 8); switch (bmp_bpix) { case 1: /* pass through */ -- 1.6.3.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SteppingStone
2011/1/26 Matt Johnson > Hello. > > I have a custom board with a Samsung s3c2410 (arm920t) processor. I have > been unable to get the main branch of u-boot to work with this board. > However, I have been successful with the old OpenMoko fork. (I believe it > is because of the "SteppingStone" microcode. See > http://wiki.openmoko.org/wiki/S3C2410_Steppingstone if you're unfamiliar.) > I'd prefer to use the main branch, because the OpenMoko fork is old and > unmaintained. The OpenMoko project abandoned u-boot some time ago, in > favor > of their "Qi" bootloader. > > Has anyone looked at merging the SteppingStone code back in to the main > branch? Is there some other workaround that is unclear to me? > > Are there other bootloaders that support SteppingStone that I could try? > I'm looking for something as full-featured as u-boot, but actively > maintained. The only other that I've found is Vivi - which is super > ancient. > Any advice is appreciated. > Thanks, > Matt > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > Steppingstone is just a 4KBytes buffer which works together with some kinda HW mechanism to copy the first 4KBytes of NAND to it. IMH, you can just treat it as a feature provided by S3C2410 to support NAND boot. If you have NOR flash in th board, you can simply boot from NOR flash and ignore this feature. I'm not sure whether there is some patches to support this feature or not, if not, may be you could provide one. The following is my advice to implement NAND boot for S3C2410: 1. write your NAND device driver, simply read operation is OK; 2. in the relocation part in Start.S, read code from NAND to RAM use your NAND device driver, and make sure the relocation part is in the very beginning 4KBytes range of NAND (by Loader script). In this way, the first 4KBytes in NAND will be read into Steppingstone buffer and executed, after execution of relocation code, your bootloader code will be read into RAM, and then the code can be executed in RAM, the full bootup procedure is over. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] cfi fix for Spansion and MB->MiB
On Tue, Jan 25, 2011 at 19:56, Aaron Williams wrote: > I ran into a problem with the Spansion S29GL064N flash chip in that it returns > a manufacturer ID of 0 and it also requires the AMD geometry fixup. > > Additionally, I modified a few print statements to use KiB/MiB instead of > kB/MB. > > -Aaron Williams > > diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c > index dd394a8..105eb3f 100644 > --- a/drivers/mtd/cfi_flash.c > +++ b/drivers/mtd/cfi_flash.c > @@ -1162,10 +1162,10 @@ void flash_print_info (flash_info_t * info) > info->name, > (info->portwidth << 3), (info->chipwidth << 3)); > if (info->size < 1024*1024) > - printf (" Size: %ld kB in %d Sectors\n", > + printf (" Size: %ld KiB in %d Sectors\n", > info->size >> 10, info->sector_count); > else > - printf (" Size: %ld MB in %d Sectors\n", > + printf (" Size: %ld MiB in %d Sectors\n", > info->size >> 20, info->sector_count); > printf (" "); > switch (info->vendor) { > @@ -1924,6 +1924,7 @@ ulong flash_get_size (phys_addr_t base, int banknum) > > /* Do manufacturer-specific fixups */ > switch (info->manufacturer_id) { > + case 0x: > case 0x0001: > flash_fixup_amd(info, &qry); > break; I think something is wrong here. You shouldn't get a manufacturer ID of from a Spansion part. cmdset_amd_read_jedec_ids() should be where it's coming from, reading the datasheet is pretty clear that these parts return an 0001 or 01 depending on the BYTE# pin. I've used other parts in the series GL128N, GL256N, GL256P that have the same command set and not seen this. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Switch from archive libraries to partial linking
On Jan 25, 2011, at 3:13 PM, Wolfgang Denk wrote: > Dear Scott Wood, > > In message <20110125143740.2e1f2...@udp111988uds.am.freescale.net> you wrote: >> >> Do you have a simpler way to do this? Note that for any board that > > e009cde powerpc: Fix FPU post related link warnings > > ? > >>> given the fact that there are >>> no intentions to work with floating point data in U-Boot? >> >> FPU POST doesn't count? > > No, it does not count, because it is a very special situation where > we are executing instructions that are guaranteed to be never used in > any real code in U-Boot. > >> Or are you saying FPU POST should be removed? > > Of course not. I thank you all, as I've enjoyed this thread for something we've just fixed :) - k - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] powerpc/85xx: Remove DATARATE_*_MHZ defines in static ddr init
Rather than having #defines DATARATE_*_MHZ, lets just match what we do on the SPD code and convert the DDR frequency into MHZ and just compare with a constant. Based on patch from Poonam Aggrwal. Signed-off-by: Kumar Gala --- board/freescale/corenet_ds/ddr.c | 14 -- board/freescale/corenet_ds/p4080ds_ddr.c | 24 +--- board/freescale/p1_p2_rdb/ddr.c | 25 +++-- 3 files changed, 28 insertions(+), 35 deletions(-) diff --git a/board/freescale/corenet_ds/ddr.c b/board/freescale/corenet_ds/ddr.c index 6660b01..4c30657 100644 --- a/board/freescale/corenet_ds/ddr.c +++ b/board/freescale/corenet_ds/ddr.c @@ -31,19 +31,21 @@ extern fixed_ddr_parm_t fixed_ddr_parm_1[]; phys_size_t fixed_sdram(void) { int i; - sys_info_t sysinfo; char buf[32]; fsl_ddr_cfg_regs_t ddr_cfg_regs; phys_size_t ddr_size; unsigned int lawbar1_target_id; + ulong ddr_freq, ddr_freq_mhz; + + ddr_freq = get_ddr_freq(0); + ddr_freq_mhz = ddr_freq / 100; - get_sys_info(&sysinfo); printf("Configuring DDR for %s MT/s data rate\n", - strmhz(buf, sysinfo.freqDDRBus)); + strmhz(buf, ddr_freq)); for (i = 0; fixed_ddr_parm_0[i].max_freq > 0; i++) { - if ((sysinfo.freqDDRBus > fixed_ddr_parm_0[i].min_freq) && - (sysinfo.freqDDRBus <= fixed_ddr_parm_0[i].max_freq)) { + if ((ddr_freq_mhz > fixed_ddr_parm_0[i].min_freq) && + (ddr_freq_mhz <= fixed_ddr_parm_0[i].max_freq)) { memcpy(&ddr_cfg_regs, fixed_ddr_parm_0[i].ddr_settings, sizeof(ddr_cfg_regs)); @@ -53,7 +55,7 @@ phys_size_t fixed_sdram(void) if (fixed_ddr_parm_0[i].max_freq == 0) panic("Unsupported DDR data rate %s MT/s data rate\n", - strmhz(buf, sysinfo.freqDDRBus)); + strmhz(buf, ddr_freq)); ddr_size = (phys_size_t) CONFIG_SYS_SDRAM_SIZE * 1024 * 1024; ddr_cfg_regs.ddr_cdr1 = DDR_CDR1_DHC_EN; diff --git a/board/freescale/corenet_ds/p4080ds_ddr.c b/board/freescale/corenet_ds/p4080ds_ddr.c index 4ad89ff..ccb9da8 100644 --- a/board/freescale/corenet_ds/p4080ds_ddr.c +++ b/board/freescale/corenet_ds/p4080ds_ddr.c @@ -1,5 +1,5 @@ /* - * Copyright 2009-2010 Freescale Semiconductor, Inc. + * Copyright 2009-2011 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 @@ -9,12 +9,6 @@ #include #include -#define DATARATE_800MHZ8 -#define DATARATE_900MHZ9 -#define DATARATE_1000MHZ 10 -#define DATARATE_1200MHZ 12 -#define DATARATE_1300MHZ 13 - #define CONFIG_SYS_DDR_TIMING_3_1200 0x0103 #define CONFIG_SYS_DDR_TIMING_0_1200 0xCC550104 #define CONFIG_SYS_DDR_TIMING_1_1200 0x868FAA45 @@ -340,17 +334,17 @@ fsl_ddr_cfg_regs_t ddr_cfg_regs_1200_2nd = { }; fixed_ddr_parm_t fixed_ddr_parm_0[] = { - {DATARATE_800MHZ, DATARATE_900MHZ, &ddr_cfg_regs_800}, - {DATARATE_900MHZ, DATARATE_1000MHZ, &ddr_cfg_regs_900}, - {DATARATE_1000MHZ, DATARATE_1200MHZ, &ddr_cfg_regs_1000}, - {DATARATE_1200MHZ, DATARATE_1300MHZ, &ddr_cfg_regs_1200}, + {800, 900, &ddr_cfg_regs_800}, + {900, 1000, &ddr_cfg_regs_900}, + {1000, 1200, &ddr_cfg_regs_1000}, + {1200, 1300, &ddr_cfg_regs_1200}, {0, 0, NULL} }; fixed_ddr_parm_t fixed_ddr_parm_1[] = { - {DATARATE_800MHZ, DATARATE_900MHZ, &ddr_cfg_regs_800_2nd}, - {DATARATE_900MHZ, DATARATE_1000MHZ, &ddr_cfg_regs_900_2nd}, - {DATARATE_1000MHZ, DATARATE_1200MHZ, &ddr_cfg_regs_1000_2nd}, - {DATARATE_1200MHZ, DATARATE_1300MHZ, &ddr_cfg_regs_1200_2nd}, + {800, 900, &ddr_cfg_regs_800_2nd}, + {900, 1000, &ddr_cfg_regs_900_2nd}, + {1000, 1200, &ddr_cfg_regs_1000_2nd}, + {1200, 1300, &ddr_cfg_regs_1200_2nd}, {0, 0, NULL} }; diff --git a/board/freescale/p1_p2_rdb/ddr.c b/board/freescale/p1_p2_rdb/ddr.c index e54fde2..fbc46b1 100644 --- a/board/freescale/p1_p2_rdb/ddr.c +++ b/board/freescale/p1_p2_rdb/ddr.c @@ -1,5 +1,5 @@ /* - * Copyright 2009 Freescale Semiconductor, Inc. + * Copyright 2009, 2011 Freescale Semiconductor, Inc. * * See file CREDITS for list of people who contributed to this * project. @@ -33,11 +33,6 @@ DECLARE_GLOBAL_DATA_PTR; extern void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs, unsigned int ctrl_num); -#define DATARATE_400MHZ 4 -#define DATARATE_533MHZ 5 -#define DATARATE_667MHZ 6 -#define DATARATE_800MHZ 8 - #define CONFIG_SYS_DDR_CS0_BNDS0x003
[U-Boot] [PATCH 2/2] powerpc/85xx: Declare fsl_ddr_set_memctl_regs in
Remove declerations of fsl_ddr_set_memctl_regs in board files with and place it into a common header. Based on patch from Poonam Aggrwal. Signed-off-by: Kumar Gala --- arch/powerpc/include/asm/fsl_ddr_sdram.h |2 ++ board/freescale/corenet_ds/ddr.c |3 --- board/freescale/p1_p2_rdb/ddr.c |3 --- 3 files changed, 2 insertions(+), 6 deletions(-) diff --git a/arch/powerpc/include/asm/fsl_ddr_sdram.h b/arch/powerpc/include/asm/fsl_ddr_sdram.h index 852e5c3..73bc023 100644 --- a/arch/powerpc/include/asm/fsl_ddr_sdram.h +++ b/arch/powerpc/include/asm/fsl_ddr_sdram.h @@ -266,6 +266,8 @@ typedef struct memctl_options_s { extern phys_size_t fsl_ddr_sdram(void); extern int fsl_use_spd(void); +extern void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs, + unsigned int ctrl_num); /* * The 85xx boards have a common prototype for fixed_sdram so put the diff --git a/board/freescale/corenet_ds/ddr.c b/board/freescale/corenet_ds/ddr.c index 4c30657..fb53946 100644 --- a/board/freescale/corenet_ds/ddr.c +++ b/board/freescale/corenet_ds/ddr.c @@ -16,9 +16,6 @@ DECLARE_GLOBAL_DATA_PTR; -extern void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs, - unsigned int ctrl_num); - /* * Fixed sdram init -- doesn't use serial presence detect. diff --git a/board/freescale/p1_p2_rdb/ddr.c b/board/freescale/p1_p2_rdb/ddr.c index fbc46b1..44faec3 100644 --- a/board/freescale/p1_p2_rdb/ddr.c +++ b/board/freescale/p1_p2_rdb/ddr.c @@ -30,9 +30,6 @@ DECLARE_GLOBAL_DATA_PTR; -extern void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs, - unsigned int ctrl_num); - #define CONFIG_SYS_DDR_CS0_BNDS0x003F #define CONFIG_SYS_DDR_CS0_CONFIG 0x80014202 #define CONFIG_SYS_DDR_CS0_CONFIG_20x -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] powerpc/85xx: Enable Errata command on MPC8572DS
From: York Sun Also removed duplicate CONFIG_CMD_IRQ define. Signed-off-by: York Sun Signed-off-by: Kumar Gala --- include/configs/MPC8572DS.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/MPC8572DS.h b/include/configs/MPC8572DS.h index e6b60cf..8f333a6 100644 --- a/include/configs/MPC8572DS.h +++ b/include/configs/MPC8572DS.h @@ -654,12 +654,12 @@ */ #include +#define CONFIG_CMD_ERRATA #define CONFIG_CMD_IRQ #define CONFIG_CMD_PING #define CONFIG_CMD_I2C #define CONFIG_CMD_MII #define CONFIG_CMD_ELF -#define CONFIG_CMD_IRQ #define CONFIG_CMD_SETEXPR #define CONFIG_CMD_REGINFO -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] powerpc/85xx: Remove unnecessary polling loop from DDR init
From: York Sun This polling loop is not required normally, unless specifically stated in workaround. Signed-off-by: York Sun Signed-off-by: Kumar Gala --- arch/powerpc/cpu/mpc85xx/ddr-gen3.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/cpu/mpc85xx/ddr-gen3.c b/arch/powerpc/cpu/mpc85xx/ddr-gen3.c index fa7e09f..b9502f7 100644 --- a/arch/powerpc/cpu/mpc85xx/ddr-gen3.c +++ b/arch/powerpc/cpu/mpc85xx/ddr-gen3.c @@ -199,8 +199,6 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs, temp_sdram_cfg = in_be32(&ddr->sdram_cfg) & ~SDRAM_CFG_BI; out_be32(&ddr->sdram_cfg, temp_sdram_cfg | SDRAM_CFG_MEM_EN); asm volatile("sync;isync"); - while (!(in_be32(&ddr->debug[1]) & 0x2)) - ; /* Poll DDR_SDRAM_CFG_2[D_INIT] bit until auto-data init is done. */ while (in_be32(&ddr->sdram_cfg_2) & 0x10) { -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] powerpc/85xx: Rename MPC8572 DDR erratum to DDR115
From: York Sun Use unique erratum number instead of platform number. Enable command that reports errata on MPC8572DS. Signed-off-by: York Sun Signed-off-by: Kumar Gala --- arch/powerpc/cpu/mpc85xx/cmd_errata.c |4 +++- arch/powerpc/cpu/mpc85xx/ddr-gen3.c |2 +- arch/powerpc/include/asm/config_mpc85xx.h |1 + 3 files changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/cpu/mpc85xx/cmd_errata.c b/arch/powerpc/cpu/mpc85xx/cmd_errata.c index 0cc8b1e..94a5876 100644 --- a/arch/powerpc/cpu/mpc85xx/cmd_errata.c +++ b/arch/powerpc/cpu/mpc85xx/cmd_errata.c @@ -71,7 +71,9 @@ static int do_errata(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) #ifdef CONFIG_SYS_FSL_ERRATUM_DDR_A003 puts("Work-around for Erratum DDR-A003 enabled\n"); #endif - +#ifdef CONFIG_SYS_FSL_ERRATUM_DDR_115 + puts("Work-around for Erratum DDR115 enabled\n"); +#endif return 0; } diff --git a/arch/powerpc/cpu/mpc85xx/ddr-gen3.c b/arch/powerpc/cpu/mpc85xx/ddr-gen3.c index b9502f7..35997f2 100644 --- a/arch/powerpc/cpu/mpc85xx/ddr-gen3.c +++ b/arch/powerpc/cpu/mpc85xx/ddr-gen3.c @@ -178,7 +178,7 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs, * when operatiing in 32-bit bus mode with 4-beat bursts, * This erratum does not affect DDR3 mode, only for DDR2 mode. */ -#ifdef CONFIG_MPC8572 +#ifdef CONFIG_SYS_FSL_ERRATUM_DDR_115 if in_be32(&ddr->sdram_cfg) >> 24) & 0x7) == SDRAM_TYPE_DDR2) && in_be32(&ddr->sdram_cfg) & 0x8) { /* set DEBUG_1[31] */ diff --git a/arch/powerpc/include/asm/config_mpc85xx.h b/arch/powerpc/include/asm/config_mpc85xx.h index 7a0af37..8ef9743 100644 --- a/arch/powerpc/include/asm/config_mpc85xx.h +++ b/arch/powerpc/include/asm/config_mpc85xx.h @@ -77,6 +77,7 @@ #define CONFIG_MAX_CPUS2 #define CONFIG_SYS_FSL_NUM_LAWS12 #define CONFIG_SYS_FSL_SEC_COMPAT 2 +#define CONFIG_SYS_FSL_ERRATUM_DDR_115 #elif defined(CONFIG_P1010) #define CONFIG_MAX_CPUS1 -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot