Re: [U-Boot] some question
Hello, Booting using the fdt blob at 0xc0 Uncompressing Kernel Image ... out of func inflateInit2 I backtraced the contents dumped and I found it died in function "inflate" which is defined in the file of lib/zlib.c and called in the file of lib/gunzip.c.But after that I don't know what I should to do. can any one give me some advice? Second,my flash size is 32MB, so I think the base address of my flash is 0xFE00, and the number of sector is 256,but if I use the configuration of this, it also enter the machine check, if I set the base address as 0xFF00 and the number of sector as 128, it can work, but if I type the flinfo ,the output is as follows: Hit any key to stop autoboot: 0 Did you check if the kernel is compressed using the correct algorithm ? ___ 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] [PATCH] cfi_flash: use AMD fixups for AMIC (e.g. A29L160A series) too
Am 11.02.2011 15:30, schrieb Steffen Sledz:
> Signed-off-by: Mario Schuknecht
> Signed-off-by: Steffen Sledz
> ---
> drivers/mtd/cfi_flash.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
> index dd394a8..527a3a5 100644
> --- a/drivers/mtd/cfi_flash.c
> +++ b/drivers/mtd/cfi_flash.c
> @@ -1924,7 +1924,8 @@ ulong flash_get_size (phys_addr_t base, int banknum)
>
> /* Do manufacturer-specific fixups */
> switch (info->manufacturer_id) {
> - case 0x0001:
> + case 0x0001: /* AMD */
> + case 0x0037: /* AMIC */
> flash_fixup_amd(info, &qry);
> break;
> case 0x001f:
Ping!
--
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sl...@dresearch.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot for x86 Core2Duo target
Zvi wrote... > On my next project, the target is Core2Duo (AMPRO's COM840). > > Is it a wise decision to use u-boot on this target ? Probably not! Ampro will already have invested a lot of time and effort in porting the BIOS to that board and are giving you a device that works out of the box. If there is a specific issue that you have with their board then talk to Ampro and they may look into it for you. > Is it a huge project to port it to another x86 target that has a different > ethernet controller ? In the first instance it will rely on you being able to get all of the information that you need in order to initialise all of the respective hardware and some of the x86 CPU and chipset vendors limit who they make it available to. There are other questions you will need to ask, for instance. Are you using the VGA display? If so, will your operating system device driver work without the video BIOS having done the initialisation or some of the other services provided by it? > The u-boot image is loader by the BIOS from compact flash via SATA. As Graeme Russ said, U-Boot would replace the BIOS. I haven't looked at the board but I would assume the BIOS can be in-situ updated. In the first instance you could try the flash update utility that goes along with the BIOS to see if it will reprogram it with an arbitrary binary. It may not do as it may have a write protected boot block that you can't replace. Andy. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 18/18] Make the at91sam9263ek compile again.
This version has been tested on an
armputer-vmax board, which is similar to the at91sam9263ek
but not on the at91sam9263ek board itself.
A new configuration "armputer-vmax_config" has been added. This configuration
has been tested on the hardware and is known to work. Further hardware tests
for individual options are needed. The LCD screen was not tested.
---
Makefile |1 -
arch/arm/cpu/arm926ejs/at91/at91sam9263_devices.c |3 +-
arch/arm/cpu/arm926ejs/at91/clock.c |2 +-
arch/arm/cpu/arm926ejs/at91/cpu.c |2 +-
arch/arm/cpu/arm926ejs/at91/reset.c |2 +-
arch/arm/cpu/arm926ejs/at91/timer.c | 10 +-
arch/arm/include/asm/arch-at91/at91_pio.h |6 +-
arch/arm/include/asm/arch-at91/at91sam9263.h | 170 +++--
arch/arm/lib/board.c |1 +
board/atmel/at91sam9263ek/at91sam9263ek.c | 13 +-
board/atmel/at91sam9263ek/led.c | 19 +--
boards.cfg|2 +
drivers/gpio/at91_gpio.c | 44 +++---
drivers/serial/atmel_usart.c | 12 +-
drivers/spi/atmel_dataflash_spi.c | 78 --
drivers/usb/host/ohci-at91.c |6 +-
include/configs/at91sam9263ek.h | 122 ---
17 files changed, 251 insertions(+), 242 deletions(-)
diff --git a/Makefile b/Makefile
index 6133160..0c653fa 100644
--- a/Makefile
+++ b/Makefile
@@ -827,7 +827,6 @@ at91sam9263ek_norflash_config \
at91sam9263ek_norflash_boot_config \
at91sam9263ek_nandflash_config \
at91sam9263ek_dataflash_config \
-at91sam9263ek_dataflash_cs0_config \
at91sam9263ek_config : unconfig
@mkdir -p $(obj)include
@if [ "$(findstring _nandflash,$@)" ] ; then \
diff --git a/arch/arm/cpu/arm926ejs/at91/at91sam9263_devices.c
b/arch/arm/cpu/arm926ejs/at91/at91sam9263_devices.c
index deda3e5..d58f8e4 100644
--- a/arch/arm/cpu/arm926ejs/at91/at91sam9263_devices.c
+++ b/arch/arm/cpu/arm926ejs/at91/at91sam9263_devices.c
@@ -26,9 +26,10 @@
* MA 02111-1307 USA
*/
+#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/arch/arm/cpu/arm926ejs/at91/clock.c
b/arch/arm/cpu/arm926ejs/at91/clock.c
index 608af2c..37b0335 100644
--- a/arch/arm/cpu/arm926ejs/at91/clock.c
+++ b/arch/arm/cpu/arm926ejs/at91/clock.c
@@ -145,7 +145,7 @@ static u32 at91_pll_rate(u32 freq, u32 reg)
int at91_clock_init(unsigned long main_clock)
{
unsigned freq, mckr;
- at91_pmc_t *pmc = (at91_pmc_t *) ATMEL_BASE_PMC;
+ at91_pmc_t *pmc = (at91_pmc_t *) AT91_PMC_BASE;
#ifndef CONFIG_SYS_AT91_MAIN_CLOCK
unsigned tmp;
/*
diff --git a/arch/arm/cpu/arm926ejs/at91/cpu.c
b/arch/arm/cpu/arm926ejs/at91/cpu.c
index c47fb31..df77097 100644
--- a/arch/arm/cpu/arm926ejs/at91/cpu.c
+++ b/arch/arm/cpu/arm926ejs/at91/cpu.c
@@ -43,7 +43,7 @@ int arch_cpu_init(void)
void arch_preboot_os(void)
{
ulong cpiv;
- at91_pit_t *pit = (at91_pit_t *) ATMEL_BASE_PIT;
+ at91_pit_t *pit = (at91_pit_t *) AT91_PIT_BASE;
cpiv = AT91_PIT_MR_PIV_MASK(readl(&pit->piir));
diff --git a/arch/arm/cpu/arm926ejs/at91/reset.c
b/arch/arm/cpu/arm926ejs/at91/reset.c
index 023719a..22a8cb3 100644
--- a/arch/arm/cpu/arm926ejs/at91/reset.c
+++ b/arch/arm/cpu/arm926ejs/at91/reset.c
@@ -30,7 +30,7 @@
/* Reset the cpu by telling the reset controller to do so */
void reset_cpu(ulong ignored)
{
- at91_rstc_t *rstc = (at91_rstc_t *) ATMEL_BASE_RSTC;
+ at91_rstc_t *rstc = (at91_rstc_t *) AT91_RSTC_BASE;
writel(AT91_RSTC_KEY
| AT91_RSTC_CR_PROCRST /* Processor Reset */
diff --git a/arch/arm/cpu/arm926ejs/at91/timer.c
b/arch/arm/cpu/arm926ejs/at91/timer.c
index a087687..38be95a 100644
--- a/arch/arm/cpu/arm926ejs/at91/timer.c
+++ b/arch/arm/cpu/arm926ejs/at91/timer.c
@@ -70,11 +70,11 @@ static inline unsigned long long usec_to_tick(unsigned long
long usec)
*/
int timer_init(void)
{
- at91_pmc_t *pmc = (at91_pmc_t *) ATMEL_BASE_PMC;
- at91_pit_t *pit = (at91_pit_t *) ATMEL_BASE_PIT;
+at91_pmc_t *pmc = (at91_pmc_t *) AT91_PMC_BASE;
+ at91_pit_t *pit = (at91_pit_t *) AT91_PIT_BASE;
/* Enable PITC Clock */
- writel(1 << ATMEL_ID_SYS, &pmc->pcer);
+ writel(1 << AT91_ID_SYS, &pmc->pcer);
/* Enable PITC */
writel(TIMER_LOAD_VAL | AT91_PIT_MR_EN , &pit->mr);
@@ -90,7 +90,7 @@ int timer_init(void)
*/
unsigned long long get_ticks(void)
{
- at91_pit_t *pit = (at91_pit_t *) ATMEL_BASE_PIT;
+ at91_pit_t *pit = (at91_pit_t *) AT91_PIT_BASE;
ulong now = readl(&pit->piir);
@@ -109,7 +109,7 @@ void __udelay(unsigned long usec)
start = get_ticks();/* get current timestamp */
tmo = usec_to_tick(usec); /* co
Re: [U-Boot] [PATCH] cfi_flash: use AMD fixups for AMIC (e.g. A29L160A series) too
Hi Steffen,
On Monday 21 February 2011 09:30:35 Steffen Sledz wrote:
> Am 11.02.2011 15:30, schrieb Steffen Sledz:
> > Signed-off-by: Mario Schuknecht
> > Signed-off-by: Steffen Sledz
> > ---
> >
> > drivers/mtd/cfi_flash.c |3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
> > index dd394a8..527a3a5 100644
> > --- a/drivers/mtd/cfi_flash.c
> > +++ b/drivers/mtd/cfi_flash.c
> > @@ -1924,7 +1924,8 @@ ulong flash_get_size (phys_addr_t base, int
> > banknum)
> >
> > /* Do manufacturer-specific fixups */
> > switch (info->manufacturer_id) {
> >
> > - case 0x0001:
> > + case 0x0001: /* AMD */
> > + case 0x0037: /* AMIC */
> >
> > flash_fixup_amd(info, &qry);
> > break;
> >
> > case 0x001f:
> Ping!
This patch is not really a bug-fix. So I have it queued for the upcoming
"next" branch (will open with -rc2).
But I do have a small question about the patch: Who is the author of this
patch? You (Steffen) or Mario? If its Mario, then you should add a "From:
Mario Schuknecht " line at the beginning of the
mail body. If its yourself, then you should switch the Signed-off-by lines
(author should be the first here).
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
On Sunday 20 February 2011 01:25 AM, Wolfgang Denk wrote: > Dear Raghuveer Murthy, > > In message<1298042212-12260-1-git-send-email-raghuveer.mur...@ti.com> you > wrote: >> U-boot built for MeeGo on PandaBoard, with compiler option >> -mfloat-abi=hard, caused a build break. Please refer to the bug id: >> >> http://bugs.meego.com/show_bug.cgi?id=13140 >> >> Removing the -msoft-float options in the config.mk files, allowed it >> to be built for both armv7hl and armv7el compilers on MeeGo >> >> Please refer to the below link for more details: >> http://wiki.meego.com/SDK/Toolchains/ToolchainChangeProposal >> >> Signed-off-by: Raghuveer Murthy >> --- >> arch/arm/cpu/armv7/config.mk |2 +- >> arch/arm/cpu/armv7/omap-common/config.mk |2 +- >> 2 files changed, 2 insertions(+), 2 deletions(-) > > After we had just another round of these discussions I thing we have > again found an agreement that there are good reasons for using > -msoft-float. > > I hereby reject your patch. > > If you have problems with your tool chain, please feel free to use > the U-Boot provided libgcc functions instead (by providing > USE_PRIVATE_LIBGCC=yes on the command line) or even your private > libgcc code (by providing USE_PRIVATE_LIBGCC=directory_with_your_lib > on the command line). > > Or fix your tool chain so it provides a soft-float version of the > needed library routines, too. > > Best regards, > > Wolfgang Denk > Acknowledge the comments. Thanks for you time. Regards, Raghuveer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] MX5:MX53: support for freescale MX53LOCO board
This patch add initial support for freescale MX53LOCO board. Network(FEC),SD/MMC, UART have been supported by this patch. Signed-off-by: Jason Liu --- MAINTAINERS |1 + board/freescale/mx53loco/Makefile | 46 + board/freescale/mx53loco/config.mk| 24 +++ board/freescale/mx53loco/imximage.cfg | 99 ++ board/freescale/mx53loco/mx53loco.c | 316 + boards.cfg|1 + include/configs/mx53loco.h| 196 7 files changed, 683 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 07541bd..b635a8a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -567,6 +567,7 @@ Stefano Babic Jason Liu mx53evk i.MX53 + mx53locoi.MX53 Enric Balletbo i Serra diff --git a/board/freescale/mx53loco/Makefile b/board/freescale/mx53loco/Makefile new file mode 100644 index 000..92ba09a --- /dev/null +++ b/board/freescale/mx53loco/Makefile @@ -0,0 +1,46 @@ +# +# (C) Copyright 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 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 := mx53loco.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +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 .depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/freescale/mx53loco/config.mk b/board/freescale/mx53loco/config.mk new file mode 100644 index 000..ec0c66c --- /dev/null +++ b/board/freescale/mx53loco/config.mk @@ -0,0 +1,24 @@ +# +# Copyright 2011 Freescale Semiconductor, Inc. All Rights Reserved. +# +# 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 +# + +IMX_CONFIG = $(SRCTREE)/board/$(BOARDDIR)/imximage.cfg +ALL += $(obj)u-boot.imx diff --git a/board/freescale/mx53loco/imximage.cfg b/board/freescale/mx53loco/imximage.cfg new file mode 100755 index 000..07dae26 --- /dev/null +++ b/board/freescale/mx53loco/imximage.cfg @@ -0,0 +1,99 @@ +# +# (C Copyright 2009 +# Stefano Babic DENX Software Engineering sba...@denx.de. +# (C Copyright 2011 +# Jason Liu Freescale Software Engineering r64...@freescale.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. 51 Franklin Street Fifth Floor Boston, +# MA 02110-1301 USA +# +# Refer docs/README.imxmage for more details about how-to configure +# and create imximage boot image +# +# The syntax is taken as close as possible with the kwbimage + +# image ver
[U-Boot] [PATCH 1/1] MX5: Enable flat-device-tree support on mx51/53 evk board
device tree for uboot arm support has already been enabled in the master branch. This patch enable device tree support for mx51/53 evk board for DT test. Signed-off-by: Jason Liu --- include/configs/mx51evk.h |3 +++ include/configs/mx53evk.h |3 +++ 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/include/configs/mx51evk.h b/include/configs/mx51evk.h index 591d6e1..57186aa 100644 --- a/include/configs/mx51evk.h +++ b/include/configs/mx51evk.h @@ -222,4 +222,7 @@ #define CONFIG_ENV_IS_IN_MMC #define CONFIG_SYS_MMC_ENV_DEV 0 +#define CONFIG_OF_LIBFDT +#define CONFIG_SYS_BOOTMAPSZ 0x80 + #endif diff --git a/include/configs/mx53evk.h b/include/configs/mx53evk.h index f2a5752..6ac910b 100644 --- a/include/configs/mx53evk.h +++ b/include/configs/mx53evk.h @@ -190,4 +190,7 @@ #define CONFIG_ENV_IS_IN_MMC #define CONFIG_SYS_MMC_ENV_DEV 0 +#define CONFIG_OF_LIBFDT +#define CONFIG_SYS_BOOTMAPSZ 0x80 + #endif /* __CONFIG_H */ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] ARM: Update mach types
This commit updates the mach-types to sync with ARM Linux based on the following commit by Russell King commit 4a683a2c5e7cabe91218db28e56dc25e1b134ce3 Signed-off-by: Jason Liu --- arch/arm/include/asm/mach-types.h | 1293 - 1 files changed, 1277 insertions(+), 16 deletions(-) diff --git a/arch/arm/include/asm/mach-types.h b/arch/arm/include/asm/mach-types.h index d95e6d6..26fb866 100644 --- a/arch/arm/include/asm/mach-types.h +++ b/arch/arm/include/asm/mach-types.h @@ -1,5 +1,5 @@ /* - * This was automagically generated from arch/arm/tools/mach-types! + * This was automagically generated from /home/r64343/work_space/linux-2.6/arch/arm/tools/mach-types! * Do NOT edit */ @@ -2236,7 +2236,7 @@ extern unsigned int __machine_arch_type; #define MACH_TYPE_VS_V210 2252 #define MACH_TYPE_VS_V212 2253 #define MACH_TYPE_HMT 2254 -#define MACH_TYPE_SUEN32255 +#define MACH_TYPE_KM_KIRKWOOD 2255 #define MACH_TYPE_VESPER 2256 #define MACH_TYPE_STR9 2257 #define MACH_TYPE_OMAP3_WL_FF 2258 @@ -2983,7 +2983,7 @@ extern unsigned int __machine_arch_type; #define MACH_TYPE_EA20 3002 #define MACH_TYPE_AWM2 3003 #define MACH_TYPE_TI8148EVM3004 -#define MACH_TYPE_TEGRA_SEABOARD 3005 +#define MACH_TYPE_SEABOARD 3005 #define MACH_TYPE_LINKSTATION_CHLV23006 #define MACH_TYPE_TERA_PRO2_RACK 3007 #define MACH_TYPE_RUBYS3008 @@ -3186,7 +3186,7 @@ extern unsigned int __machine_arch_type; #define MACH_TYPE_ICS_IF_VOIP 3206 #define MACH_TYPE_WLF_CRAGG_6410 3207 #define MACH_TYPE_PUNICA 3208 -#define MACH_TYPE_SBC_NT2503209 +#define MACH_TYPE_TRIMSLICE3209 #define MACH_TYPE_MX27_WMULTRA 3210 #define MACH_TYPE_MACKEREL 3211 #define MACH_TYPE_FA9X27 3213 @@ -3215,6 +3215,103 @@ extern unsigned int __machine_arch_type; #define MACH_TYPE_PCM048 3236 #define MACH_TYPE_DDS 3237 #define MACH_TYPE_CHALTEN_XA1 3238 +#define MACH_TYPE_TS48XX 3239 +#define MACH_TYPE_TONGA2_TFTTIMER 3240 +#define MACH_TYPE_WHISTLER 3241 +#define MACH_TYPE_ASL_PHOENIX 3242 +#define MACH_TYPE_AT91SAM9263OTLITE3243 +#define MACH_TYPE_DDPLUG 3244 +#define MACH_TYPE_D2PLUG 3245 +#define MACH_TYPE_KZM9D3246 +#define MACH_TYPE_VERDI_LTE3247 +#define MACH_TYPE_NANOZOOM 3248 +#define MACH_TYPE_DM3730_SOM_LV3249 +#define MACH_TYPE_DM3730_TORPEDO 3250 +#define MACH_TYPE_ANCHOVY 3251 +#define MACH_TYPE_RE2REV20 3253 +#define MACH_TYPE_RE2REV21 3254 +#define MACH_TYPE_CNS21XX 3255 +#define MACH_TYPE_RIDER3257 +#define MACH_TYPE_NSK330 3258 +#define MACH_TYPE_CNS2133EVB 3259 +#define MACH_TYPE_Z3_816X_MOD 3260 +#define MACH_TYPE_Z3_814X_MOD 3261 +#define MACH_TYPE_BEECT3262 +#define MACH_TYPE_DMA_THUNDERBUG 3263 +#define MACH_TYPE_OMN_AT91SAM9G20 3264 +#define MACH_TYPE_MX25_E2S_UC 3265 +#define MACH_TYPE_MIONE3266 +#define MACH_TYPE_TOP9000_TCU 3267 +#define MACH_TYPE_TOP9000_BSL 3268 +#define MACH_TYPE_KINGDOM 3269 +#define MACH_TYPE_ARMADILLO460 3270 +#define MACH_TYPE_LQ2 3271 +#define MACH_TYPE_SWEDA_TMS2 3272 +#define MACH_TYPE_MX53_LOCO3273 +#define MACH_TYPE_ACER_A8 3275 +#define MACH_TYPE_ACER_GAUGUIN 3276 +#define MACH_TYPE_GUPPY3277 +#define MACH_TYPE_MX61_ARD 3278 +#define MACH_TYPE_TX53 3279 +#define MACH_TYPE_OMAPL138_CASE_A3 3280 +#define MACH_TYPE_UEMD 3281 +#define MACH_TYPE_CCWMX51MUT 3282 +#define MACH_TYPE_ROCKHOPPER 3283 +#define MACH_TYPE_NOOKCOLOR3284 +#define MACH_TYPE_HKDKC100 3285 +#define MACH_TYPE_TS42XX 3286 +#define MACH_TYPE_AEBL 3287 +#define MACH_TYPE_WARIO3288 +#define MACH_TYPE_GFS_SPM 3289 +#define MACH_TYPE_CM_T3730 3290 +#define MACH_TYPE_ISC3 3291 +#define MACH_TYPE_RASCAL 3292 +#define MACH_TYPE_HREFV60 3293 +#define MACH_TYPE_TPT_2_0 3294 +#define MACH_TYPE_PYRAMID_TD 3295 +#define MACH_TYPE_SPLENDOR 3296 +#define MACH_TYPE_GUF_PLANET 3297 +#define MACH_TYPE_MSM8X60_QT 3298 +#define MACH_TYPE_HTC_HD_MINI 3299 +#define MACH_TYPE_ATHENE 3300 +#define MACH_TYPE_DEEP_R_EK_1 3301 +#define MACH_TYPE_VIVOW_CT 3302 +#define MACH_TYPE_NERY_10003303 +#define MAC
Re: [U-Boot] [PATCH 18/18] Make the at91sam9263ek compile again.
Dear Uli Raich, > This version has been tested on an > armputer-vmax board, which is similar to the at91sam9263ek > but not on the at91sam9263ek board itself. > A new configuration "armputer-vmax_config" has been added. This configuration > has been tested on the hardware and is known to work. Further hardware tests > for individual options are needed. The LCD screen was not tested. Sorry, this has to get a full NAK. 1. Please never hijack someone's thread! Your patch has nothing to do with someone's PATCH 18/18. 2. You are undoing all rework efforts with this patch! The rework was, amongst others, to get rid of all AT91_*, AT91_*, AVR* macros and unify them into ATMEL_* macros. And by that also remove the twofold re-wrapping of those defines. > diff --git a/Makefile b/Makefile > index 6133160..0c653fa 100644 > --- a/Makefile > +++ b/Makefile > @@ -827,7 +827,6 @@ at91sam9263ek_norflash_config \ > at91sam9263ek_norflash_boot_config \ > at91sam9263ek_nandflash_config \ > at91sam9263ek_dataflash_config \ > -at91sam9263ek_dataflash_cs0_config \ > at91sam9263ek_config: unconfig If, all entries have to be moved to boards.cfg > - at91_pmc_t *pmc = (at91_pmc_t *) ATMEL_BASE_PMC; > + at91_pmc_t *pmc = (at91_pmc_t *) AT91_PMC_BASE; ATMEL_BASE_*, ATMEL_ID_* are the new names that are the same names for all ATMEL SoCs, although they might hold different numerical values. > - at91_pit_t *pit = (at91_pit_t *) ATMEL_BASE_PIT; > + at91_pit_t *pit = (at91_pit_t *) AT91_PIT_BASE; and so on... > - at91_pmc_t *pmc = (at91_pmc_t *) ATMEL_BASE_PMC; > - at91_pit_t *pit = (at91_pit_t *) ATMEL_BASE_PIT; > +at91_pmc_t *pmc = (at91_pmc_t *) AT91_PMC_BASE; > + at91_pit_t *pit = (at91_pit_t *) AT91_PIT_BASE; You even re-add white-space errors.. ... > - atmel_usart3_t *usart = (atmel_usart3_t *)CONFIG_USART_BASE; > + atmel_usart3_t *usart = (atmel_usart3_t*)AT91_DBGU_BASE; It seems you have not understood the concept of "CONFIG_" macros. They are to allow the designer to use different USARTs, not explicitly only the one in the debug unit... 3. And, please, run your patches through checkpatch.pl Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 18/18] Make the at91sam9263ek compile again.
Dear Uli Raich,
In message <0f3ef05ca2a70e43b140ef090b9f97183efe0...@cernxchg22.cern.ch> you
wrote:
> This version has been tested on an
> armputer-vmax board, which is similar to the at91sam9263ek
> but not on the at91sam9263ek board itself.
> A new configuration "armputer-vmax_config" has been added. This configuration
> has been tested on the hardware and is known to work. Further hardware tests
> for individual options are needed. The LCD screen was not tested.
>
>
> ---
SoB line missing, as I already remaked twice before.
Also, please run your patch through checkpatch and fix the errors:
total: 57 errors, 26 warnings, 961 lines checked
ERROR: "(foo*)" should be "(foo *)"
ERROR: Macros with complex values should be enclosed in parenthesis
ERROR: Missing Signed-off-by: line(s)
ERROR: code indent should use tabs where possible
ERROR: do not use C99 // comments
ERROR: space required after that ',' (ctx:VxV)
ERROR: trailing statements should be on next line
ERROR: trailing whitespace
WARNING: line over 80 characters
WARNING: please, no space before tabs
WARNING: please, no spaces at the start of a line
WARNING: space prohibited between function name and open parenthesis '('
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
Overdrawn? But I still have checks left!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 18/18] Make the at91sam9263ek compile again.
Hi,
2011/2/21 Uli Raich :
> This version has been tested on an
> armputer-vmax board, which is similar to the at91sam9263ek
> but not on the at91sam9263ek board itself.
> A new configuration "armputer-vmax_config" has been added. This configuration
> has been tested on the hardware and is known to work. Further hardware tests
> for individual options are needed. The LCD screen was not tested.
>
> ---
> Makefile | 1 -
> arch/arm/cpu/arm926ejs/at91/at91sam9263_devices.c | 3 +-
> arch/arm/cpu/arm926ejs/at91/clock.c | 2 +-
> arch/arm/cpu/arm926ejs/at91/cpu.c | 2 +-
> arch/arm/cpu/arm926ejs/at91/reset.c | 2 +-
> arch/arm/cpu/arm926ejs/at91/timer.c | 10 +-
> arch/arm/include/asm/arch-at91/at91_pio.h | 6 +-
> arch/arm/include/asm/arch-at91/at91sam9263.h | 170
> +++--
> arch/arm/lib/board.c | 1 +
> board/atmel/at91sam9263ek/at91sam9263ek.c | 13 +-
> board/atmel/at91sam9263ek/led.c | 19 +--
> boards.cfg | 2 +
> drivers/gpio/at91_gpio.c | 44 +++---
> drivers/serial/atmel_usart.c | 12 +-
> drivers/spi/atmel_dataflash_spi.c | 78 --
> drivers/usb/host/ohci-at91.c | 6 +-
> include/configs/at91sam9263ek.h | 122 ---
> 17 files changed, 251 insertions(+), 242 deletions(-)
I already make some remarks that Reinhard is also likely going to make...
Patch 18/18? Where are the first 17 patches?
You should not revert changes that where made within the rework110218
branch of the atmel tree.
I noticed that you replaced some ATMEL_ defines by the older AT91_
style defines.
You should use the 9260ek board as example, which is in the
rework110202 branch of Reinhards tree.
This patch touches too many files and can be done which much less
changes on less files.
> diff --git a/Makefile b/Makefile
> index 6133160..0c653fa 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -827,7 +827,6 @@ at91sam9263ek_norflash_config \
> at91sam9263ek_norflash_boot_config \
> at91sam9263ek_nandflash_config \
> at91sam9263ek_dataflash_config \
> -at91sam9263ek_dataflash_cs0_config \
> at91sam9263ek_config : unconfig
I would expect you would remove all sam9263ek stuff from the Makefile.
> --- a/arch/arm/cpu/arm926ejs/at91/clock.c
> +++ b/arch/arm/cpu/arm926ejs/at91/clock.c
> @@ -145,7 +145,7 @@ static u32 at91_pll_rate(u32 freq, u32 reg)
> int at91_clock_init(unsigned long main_clock)
> {
> unsigned freq, mckr;
> - at91_pmc_t *pmc = (at91_pmc_t *) ATMEL_BASE_PMC;
> + at91_pmc_t *pmc = (at91_pmc_t *) AT91_PMC_BASE;
ATMEL_BASE type defines are right, AT91_ type defines are wrong.
Please fix globally
> --- a/arch/arm/include/asm/arch-at91/at91sam9263.h
> +++ b/arch/arm/include/asm/arch-at91/at91sam9263.h
> @@ -20,118 +20,124 @@
> /*
> * defines to be used in other places
> */
> -#define CONFIG_ARM926EJS /* ARM926EJS Core */
> +//#define CONFIG_ARM926EJS /* ARM926EJS Core */
No C++ style comments and no dead code please.
> diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
> index c620d2c..ea81378 100644
> --- a/arch/arm/lib/board.c
> +++ b/arch/arm/lib/board.c
> @@ -232,6 +232,7 @@ void __dram_init_banksize(void)
> {
> gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
> gd->bd->bi_dram[0].size = gd->ram_size;
> +
Why adding an empty line here?
> }
> void dram_init_banksize(void)
> __attribute__((weak, alias("__dram_init_banksize")));
> diff --git a/board/atmel/at91sam9263ek/at91sam9263ek.c
> b/board/atmel/at91sam9263ek/at91sam9263ek.c
> index 91efc07..7216022 100644
> --- a/board/atmel/at91sam9263ek/at91sam9263ek.c
> +++ b/board/atmel/at91sam9263ek/at91sam9263ek.c
> @@ -276,8 +280,9 @@ int board_init(void)
>
> int dram_init(void)
> {
> - gd->bd->bi_dram[0].start = PHYS_SDRAM;
> - gd->bd->bi_dram[0].size = PHYS_SDRAM_SIZE;
> + gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
> + gd->bd->bi_dram[0].size = CONFIG_SYS_SDRAM_SIZE;
> + gd->ram_size = CONFIG_SYS_SDRAM_SIZE; // U.R is this the way to do
> it?
Filling gd->bd->bi_dram[0].start and size are not required here.
It is likely enough to make dram_init() like this (Including
auto-detection of available RAM size)
int dram_init(void)
{
/* dram_init must store complete ramsize in gd->ram_size */
gd->ram_size = get_ram_size((volatile long *)CONFIG_SYS_SDRAM_BASE,
CONFIG_SYS_SDRAM_SIZE);
return 0;
}
> diff --git a/board/atmel/at91sam9263ek/led.c b/board/atmel/at91sam9263ek/led.c
> index fa1f05b..b3adc51 100644
> --- a/board/atmel/at91sam9263ek/led.c
> +++ b/board/atmel/at91sam9263ek/led.c
> @@ -23,25 +23,22 @@
> */
>
> #include
> -#include
Re: [U-Boot] [PATCH] cfi_flash: use AMD fixups for AMIC (e.g. A29L160A series) too
Am 21.02.2011 11:14, schrieb Stefan Roese: > Hi Steffen, > > On Monday 21 February 2011 09:30:35 Steffen Sledz wrote: >> Am 11.02.2011 15:30, schrieb Steffen Sledz: >>> Signed-off-by: Mario Schuknecht >>> Signed-off-by: Steffen Sledz >>> ... >> Ping! > > This patch is not really a bug-fix. So I have it queued for the upcoming > "next" branch (will open with -rc2). OK, no problem. > But I do have a small question about the patch: Who is the author of this > patch? You (Steffen) or Mario? If its Mario, then you should add a "From: > Mario Schuknecht " line at the beginning of the > mail body. If its yourself, then you should switch the Signed-off-by lines > (author should be the first here). Mario is the main author. I'll send an update to the patch. Steffen -- DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany Tel: +49 30 515932-237 mailto:sl...@dresearch.de Fax: +49 30 515932-299 Geschäftsführer: Dr. Michael Weber, Werner Mögle; Amtsgericht Berlin Charlottenburg; HRB 130120 B; Ust.-IDNr. DE273952058 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] cfi_flash: use AMD fixups for AMIC (e.g. A29L160A series) too
Signed-off-by: Mario Schuknecht
Signed-off-by: Steffen Sledz
---
drivers/mtd/cfi_flash.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index dd394a8..527a3a5 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -1924,7 +1924,8 @@ ulong flash_get_size (phys_addr_t base, int banknum)
/* Do manufacturer-specific fixups */
switch (info->manufacturer_id) {
- case 0x0001:
+ case 0x0001: /* AMD */
+ case 0x0037: /* AMIC */
flash_fixup_amd(info, &qry);
break;
case 0x001f:
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] MX5:MX53: support for freescale MX53LOCO board
On 02/21/2011 11:15 AM, Jason Liu wrote: Hi Jason, > +# > diff --git a/board/freescale/mx53loco/config.mk > b/board/freescale/mx53loco/config.mk > new file mode 100644 > index 000..ec0c66c As I discovered myself, usage of config.mk is discouraged and it should be removed and it is not accepted anymore for new boards. Instead of that, it is possible to add CONFIG_ options in boards.cfg. I have already sent changes for imx51evk, as example for the imx5 boards. However, I sent them when window was already closed, and I merged them on the next branch of u-boot-imx. You will find these patches in archive also as: [PATCH 1/2] Makefile: change rule to build IMX image [PATCH 2/2] MX51: drop config.mk from mx51evk You can take a look at them to see how to drop the config.mk file. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SoC specific driver changes through other custodian's trees?
Dear Reinhard Meyer, In message <4d624a5e.30...@emk-elektronik.de> you wrote: > > > Please, provide a separate patch for changes in the OHCI drivers. > > They need to go to the u-boot-usb tree. > Apart from the fact that no change is required here.. > > I don't think it would make sense to let ATMEL specific driver patches > (serial, net, usb, spi, etc.) go through different trees as long as they do > not change common files there (Makefile, general header files etc.). We split responsibilities (and repositories) by topics. Indeed USB stuff should go through the USB repository. Similar, network stuff should go through the network tree. I2C stuff goes through the I2C repo, etc. > For the rework effort, it would separate changes to files that inherently > must be > applied together, like changing header files in arch-at91/avr32 and the > required > adaptions to the atmel drivers. Then your patches need to split in an orthogonal way. > It is natural, of course, that each custodian should have a look at the patch > involving > their architecture or field and possibly add an "Acked-By:" to it. Just "having a look" is cartainly not sufficient. 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 Marriage is the triumph of imagination over intelligence. Second marriage is the triumph of hope over experience. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 18/18] Make the at91sam9263ek compile again.
Dear Remy Bohmer,
Am 21.02.2011 12:00, schrieb Remy Bohmer:
>> diff --git a/board/atmel/at91sam9263ek/led.c
>> b/board/atmel/at91sam9263ek/led.c
>> index fa1f05b..b3adc51 100644
>> --- a/board/atmel/at91sam9263ek/led.c
>> +++ b/board/atmel/at91sam9263ek/led.c
>> @@ -23,25 +23,22 @@
>> */
>>
>> #include
>> -#include
>> -#include
>> -#include
>> #include
>> -#include
>> +#include
>>
>> void coloured_LED_init(void)
>> {
>>/* Enable clock */
>>at91_pmc_t *pmc= (at91_pmc_t *) AT91_PMC_BASE;
>>
>> - writel(1 << AT91SAM9263_ID_PIOB | 1 << AT91SAM9263_ID_PIOCDE,
>> + writel(1 << AT91_ID_PIOB | 1 << AT91_ID_PIOCDE,
>>&pmc->pcer);
>
> Enable all the GPIO peripheral clocks in a board_early_init_f() routine.
> Not here.
No, that is wrong! board_early_init_f() is too late! coloured_LED stuff
is used (currently) in early init stage for debugging. Therefore we need
to initialize the clocks here. Nevertheless it should preserve old
settings in PCER!
If we need these coloured_LED stuff beside the other LED
implementation's is another question.
regards
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SoC specific driver changes through other custodian's trees?
Dear Wolfgang Denk, > Dear Reinhard Meyer, > > In message<4d624a5e.30...@emk-elektronik.de> you wrote: >> >>> Please, provide a separate patch for changes in the OHCI drivers. >>> They need to go to the u-boot-usb tree. >> Apart from the fact that no change is required here.. >> >> I don't think it would make sense to let ATMEL specific driver patches >> (serial, net, usb, spi, etc.) go through different trees as long as they do >> not change common files there (Makefile, general header files etc.). > > We split responsibilities (and repositories) by topics. Indeed USB > stuff should go through the USB repository. Similar, network stuff > should go through the network tree. I2C stuff goes through the I2C > repo, etc. > >> For the rework effort, it would separate changes to files that inherently >> must be >> applied together, like changing header files in arch-at91/avr32 and the >> required >> adaptions to the atmel drivers. > > Then your patches need to split in an orthogonal way. I'm not sure what that means, but the rework effort won't work when not all required changes are in one tree. And how would, for example, the NET custodian verify a patch when it would not even build when the rework changes to ATMEL header files are not in his tree? On another note: If I am supposed to be responsible fot ATMEL stuff, that includes IMHO also the drivers that are purely ATMEL specific. > >> It is natural, of course, that each custodian should have a look at the >> patch involving >> their architecture or field and possibly add an "Acked-By:" to it. > > Just "having a look" is cartainly not sufficient. > Best regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 18/18] Make the at91sam9263ek compile again.
Dear Remy Bohmer, Am 21.02.2011 14:09, schrieb Andreas Bießmann: >> >> Enable all the GPIO peripheral clocks in a board_early_init_f() routine. >> Not here. > > No, that is wrong! board_early_init_f() is too late! coloured_LED stuff > is used (currently) in early init stage for debugging. Therefore we need > to initialize the clocks here. Nevertheless it should preserve old > settings in PCER! That was wrong ... I know we do not 'disable' other peripherial clocks here. regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SoC specific driver changes through other custodian's trees?
Dear Reinhard Meyer, In message <4d626a18.7030...@emk-elektronik.de> you wrote: > > I'm not sure what that means, but the rework effort won't work when not all > required changes are in one tree. And how would, for example, the NET > custodian verify a patch when it would not even build when the rework changes > to ATMEL header files are not in his tree? Normally you do the core first, so it builds, then add the network and USB and ... On a patch series you can try Cc: each patch of a seris to a different list of people. You are supposed to include the respective custodian. > On another note: If I am supposed to be responsible fot ATMEL stuff, that > includes > IMHO also the drivers that are purely ATMEL specific. Stuff that affects other areas as well need at least the ACK from the respective custodian. You can ask him for his ACK to take it through your tree, but this requires his explicit agreement and must not taken for granted. 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 Mistakes are often the stepping stones to utter failure. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] ARM: Update mach types
>This commit updates the mach-types to sync with ARM >Linux based on the following commit by Russell King >commit 4a683a2c5e7cabe91218db28e56dc25e1b134ce3 > >Signed-off-by: Jason Liu >--- already done http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commitdiff;h=c7977858dcf1f656cbe91ea0dc3cb9139c6a8cc8 --Sandeep ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [HELP] Where can i get uboot patch for freescale P4080
thanks very much ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] ARM: Update mach types
Hi Jason, --- On Mon, 2/21/11, Jason Liu wrote: > From: Jason Liu > Subject: [U-Boot] [PATCH 1/1] ARM: Update mach types > To: u-boot@lists.denx.de > Date: Monday, February 21, 2011, 8:14 AM > This commit updates the mach-types to > sync with ARM > Linux based on the following commit by Russell King > commit 4a683a2c5e7cabe91218db28e56dc25e1b134ce3 > > Signed-off-by: Jason Liu > --- > arch/arm/include/asm/mach-types.h | 1293 > - > 1 files changed, 1277 insertions(+), 16 deletions(-) The machine update patch is already in U-boot ARM tree: http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commitdiff;h=c7977858dcf1f656cbe91ea0dc3cb9139c6a8cc8 Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MAINTAINERS: fix email address case
Signed-off-by: Fabio Estevam --- MAINTAINERS |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 07541bd..7e987b3 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -624,7 +624,7 @@ Kristoffer Ericson jornada SA1110 -Fabio Estevam +Fabio Estevam mx31pdk i.MX31 -- 1.6.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/7] mpc85xx: Support a board-specific processor reset routines
Some board models (such as the submitted P2020-based HWW-1U-1A hardware)
need specialized code to run when a reset is requested to ensure proper
synchronization with other hardware.
In order to facilitate such board ports, we add a board_reset_r()
routine which is called from the do_reset() command function instead of
directly poking at the MPC85xx "RSTCR" (reset control) register.
Signed-off-by: Kyle Moffett
---
arch/powerpc/cpu/mpc85xx/cpu.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c b/arch/powerpc/cpu/mpc85xx/cpu.c
index 1aad2ba..dbc662f 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu.c
@@ -204,8 +204,10 @@ int checkcpu (void)
int do_reset (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
-/* Everything after the first generation of PQ3 parts has RSTCR */
-#if defined(CONFIG_MPC8540) || defined(CONFIG_MPC8541) || \
+#if defined(CONFIG_BOARD_RESET_R)
+ extern void board_reset_r(void);
+ board_reset_r();
+#elif defined(CONFIG_MPC8540) || defined(CONFIG_MPC8541) || \
defined(CONFIG_MPC8555) || defined(CONFIG_MPC8560)
unsigned long val, msr;
@@ -221,6 +223,7 @@ int do_reset (cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
val |= 0x7000;
mtspr(DBCR0,val);
#else
+ /* Everything after the first generation of PQ3 parts has RSTCR */
volatile ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
out_be32(&gur->rstcr, 0x2); /* HRESET_REQ */
udelay(100);
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Support patches for the eXMeritus HWW-1U-1A system (v3)
Hello again everyone! After a relatively long hiatus working on other projects, I'm resubmitting updated versions of our board-support patches for review and inclusion. This patch series is based off the latest master branch as of Feb 11th, specifically, commit d1a79b71f7c5fd9e277e0feb35f049289df1ed0e. This patch series includes several generic cleanups, enhancements, and bugfixes, but the vast majority of the code is board-specific. See the specific patches for further details. Overall diffstat below: MAINTAINERS |4 + arch/powerpc/cpu/mpc85xx/cpu.c |7 +- arch/powerpc/cpu/mpc8xxx/ddr/ddr2_dimm_params.c | 34 +- arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c | 37 +- arch/powerpc/cpu/mpc8xxx/ddr/util.c | 58 ++- arch/powerpc/include/asm/mpc85xx_gpio.h | 124 + arch/powerpc/lib/Makefile | 28 +- arch/powerpc/lib/_ashldi3.S | 45 ++ arch/powerpc/lib/_ashrdi3.S | 47 ++ arch/powerpc/lib/_lshrdi3.S | 45 ++ board/exmeritus/hww1u1a/Makefile| 54 ++ board/exmeritus/hww1u1a/ddr.c | 51 ++ board/exmeritus/hww1u1a/gpios.h | 81 +++ board/exmeritus/hww1u1a/hww1u1a.c | 629 +++ board/exmeritus/hww1u1a/law.c | 34 ++ board/exmeritus/hww1u1a/tlb.c | 106 boards.cfg |2 + common/ddr_spd.c|2 +- common/fdt_support.c|2 +- include/configs/HWW1U1A.h | 470 + include/ddr_spd.h | 28 +- 21 files changed, 1826 insertions(+), 62 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/7] mpc8xxx: DDR2/3: Use human-readable SPD DIMM-type constants
Use #define constants to enhance readability of DDR2/3 SPD parsing code.
Also add the DDR2 type for an SO-RDIMM module to the switch statement.
Signed-off-by: Kyle Moffett
---
arch/powerpc/cpu/mpc8xxx/ddr/ddr2_dimm_params.c | 34 +++--
arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c | 37 ++-
common/ddr_spd.c|2 +-
include/ddr_spd.h | 28 -
4 files changed, 60 insertions(+), 41 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/ddr2_dimm_params.c
b/arch/powerpc/cpu/mpc8xxx/ddr/ddr2_dimm_params.c
index dcb37ce..d1f0f2b 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/ddr2_dimm_params.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/ddr2_dimm_params.c
@@ -250,24 +250,27 @@ ddr_compute_dimm_parameters(const ddr2_spd_eeprom_t *spd,
pdimm->primary_sdram_width = spd->primw;
pdimm->ec_sdram_width = spd->ecw;
- /* FIXME: what about registered SO-DIMM? */
+ /* These are all the types defined by the JEDEC DDR2 SPD 1.3 spec */
switch (spd->dimm_type) {
- case 0x01: /* RDIMM */
- case 0x10: /* Mini-RDIMM */
- pdimm->registered_dimm = 1; /* register buffered */
+ case DDR2_SPD_DIMMTYPE_RDIMM:
+ case DDR2_SPD_DIMMTYPE_72B_SO_RDIMM:
+ case DDR2_SPD_DIMMTYPE_MINI_RDIMM:
+ /* Registered/buffered DIMMs */
+ pdimm->registered_dimm = 1;
break;
- case 0x02: /* UDIMM */
- case 0x04: /* SO-DIMM */
- case 0x08: /* Micro-DIMM */
- case 0x20: /* Mini-UDIMM */
- pdimm->registered_dimm = 0; /* unbuffered */
+ case DDR2_SPD_DIMMTYPE_UDIMM:
+ case DDR2_SPD_DIMMTYPE_SO_DIMM:
+ case DDR2_SPD_DIMMTYPE_MICRO_DIMM:
+ case DDR2_SPD_DIMMTYPE_MINI_UDIMM:
+ /* Unbuffered DIMMs */
+ pdimm->registered_dimm = 0;
break;
+ case DDR2_SPD_DIMMTYPE_72B_SO_CDIMM:
default:
printf("unknown dimm_type 0x%02X\n", spd->dimm_type);
return 1;
- break;
}
/* SDRAM device parameters */
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c
b/arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c
index 29cea53..e31f201 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c
@@ -128,24 +128,30 @@ ddr_compute_dimm_parameters(const ddr3_spd_eeprom_t *spd,
pdimm->data_width = pdimm->primary_sdram_width
+ pdimm->ec_sdram_width;
- switch (spd->module_type & 0xf) {
- case 0x01: /* RDIMM */
- case 0x05: /* Mini-RDIMM */
- pdimm->registered_dimm = 1; /* register buffered */
+ /* These are the types defined by the JEDEC DDR3 SPD spec */
+ switch (spd->module_type & DDR3_SPD_MODULETYPE_MASK) {
+ case DDR3_SPD_MODULETYPE_RDIMM:
+ case DDR3_SPD_MODULETYPE_MINI_RDIMM:
+ /* Registered/buffered DIMMs */
+ pdimm->registered_dimm = 1;
+ pdimm->mirrored_dimm = 0;
for (i = 0; i < 16; i += 2) {
pdimm->rcw[i] = spd->mod_section.registered.rcw[i/2] &
0x0F;
pdimm->rcw[i+1] = (spd->mod_section.registered.rcw[i/2]
>> 4) & 0x0F;
}
break;
- case 0x02: /* UDIMM */
- case 0x03: /* SO-DIMM */
- case 0x04: /* Micro-DIMM */
- case 0x06: /* Mini-UDIMM */
- pdimm->registered_dimm = 0; /* unbuffered */
+
+ case DDR3_SPD_MODULETYPE_UDIMM:
+ case DDR3_SPD_MODULETYPE_SO_DIMM:
+ case DDR3_SPD_MODULETYPE_MICRO_DIMM:
+ case DDR3_SPD_MODULETYPE_MINI_UDIMM:
+ /* Unbuffered DIMMs */
+ pdimm->registered_dimm = 0;
+ pdimm->mirrored_dimm = spd->mod_section.unbuffered.addr_mapping
& 0x1;
break;
default:
- printf("unknown dimm_type 0x%02X\n", spd->module_type);
+ printf("unknown module_type 0x%02X\n", spd->module_type);
return 1;
}
@@ -303,16 +309,5 @@ ddr_compute_dimm_parameters(const ddr3_spd_eeprom_t *spd,
pdimm->tFAW_ps = (((spd->tFAW_msb & 0xf) << 8) | spd->tFAW_min)
* mtb_ps;
- /*
-* We need check the address mirror for unbuffered DIMM
-* If SPD indicate the address map mirror, The DDR controller
-* need care it.
-*/
- if ((spd->module_type == SPD_MODULETYPE_UDIMM) ||
- (spd->module_type == SPD_MODULETYPE_SODIMM) ||
- (spd->module_type == SPD_MODULETYPE_MICRODIMM) ||
- (spd->module_type == SPD_MODULETYPE_MINIUDIMM))
- pdimm->mirrored_dimm = spd->mod_section.unbuffered.addr_mapping
& 0x1;
-
return 0;
}
diff --git a/common/ddr_
[U-Boot] [PATCH 4/7] fsl_ddr: Don't use full 64-bit divides on 32-bit PowerPC
The current FreeScale MPC-8xxx DDR SPD interpreter is using full 64-bit
integer divide operations to convert between nanoseconds and DDR clock
cycles given arbitrary DDR clock frequencies.
Since all of the inputs to this are 32-bit (nanoseconds, clock cycles,
and DDR frequencies), we can easily restructure the computation to use
the "do_div()" function to perform 64-bit/32-bit divide operations.
This decreases compute time rather significantly for each conversion and
avoids bringing in a very complicated function from libgcc.
It should be noted that nothing else in U-Boot or the Linux kernel seems
to require a full 64-bit divide on any 32-bit PowerPC.
Build-and-boot-tested on the HWW-1U-1A board using DDR2 SPD detection.
Signed-off-by: Kyle Moffett
---
Author's note: This patch really needs a bunch more review and testing, but
I only have access to a very limited selection of hardware. Please let me
know about any questions or concerns.
arch/powerpc/cpu/mpc8xxx/ddr/util.c | 58 --
1 files changed, 41 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/util.c
b/arch/powerpc/cpu/mpc8xxx/ddr/util.c
index 1e2d921..c545d59 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/util.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/util.c
@@ -8,11 +8,19 @@
#include
#include
+#include
#include "ddr.h"
unsigned int fsl_ddr_get_mem_data_rate(void);
+/* To avoid 64-bit full-divides, we factor this here */
+#define ULL_2e12 2ULL
+#define UL_5pow12 244140625UL
+#define UL_2pow13 (1UL << 13)
+
+#define ULL_8Fs 0xULL
+
/*
* Round mclk_ps to nearest 10 ps in memory controller code.
*
@@ -22,36 +30,52 @@ unsigned int fsl_ddr_get_mem_data_rate(void);
*/
unsigned int get_memory_clk_period_ps(void)
{
- unsigned int mclk_ps;
+ unsigned int data_rate = fsl_ddr_get_mem_data_rate();
+ unsigned int result;
+
+ /* Round to nearest 10ps, being careful about 64-bit multiply/divide */
+ unsigned long long mclk_ps = ULL_2e12;
- mclk_ps = 2ULL / fsl_ddr_get_mem_data_rate();
- /* round to nearest 10 ps */
- return 10 * ((mclk_ps + 5) / 10);
+ /* Add 5*data_rate, for rounding */
+ mclk_ps += 5*(unsigned long long)data_rate;
+
+ /* Now perform the big divide, the result fits in 32-bits */
+ do_div(mclk_ps, data_rate);
+ result = mclk_ps;
+
+ /* We still need to round to 10ps */
+ return 10 * (result/10);
}
/* Convert picoseconds into DRAM clock cycles (rounding up if needed). */
unsigned int picos_to_mclk(unsigned int picos)
{
- const unsigned long long ULL_2e12 = 2ULL;
- const unsigned long long ULL_8Fs = 0xULL;
- unsigned long long clks;
- unsigned long long clks_temp;
+ unsigned long long clks, clks_rem;
+ /* Short circuit for zero picos */
if (!picos)
return 0;
- clks = fsl_ddr_get_mem_data_rate() * (unsigned long long) picos;
- clks_temp = clks;
- clks = clks / ULL_2e12;
- if (clks_temp % ULL_2e12) {
+ /* First multiply the time by the data rate (32x32 => 64) */
+ clks = picos * (unsigned long long)fsl_ddr_get_mem_data_rate();
+
+ /*
+* Now divide by 5^12 and track the 32-bit remainder, then divide
+* by 2*(2^12) using shifts (and updating the remainder).
+*/
+ clks_rem = do_div(clks, UL_5pow12);
+ clks_rem <<= 13;
+ clks_rem |= clks & (UL_2pow13-1);
+ clks >>= 13;
+
+ /* If we had a remainder, then round up */
+ if (clks_rem)
clks++;
- }
- if (clks > ULL_8Fs) {
+ /* Clamp to the maximum representable value */
+ if (clks > ULL_8Fs)
clks = ULL_8Fs;
- }
-
- return (unsigned int) clks;
+ return (unsigned int)clks;
}
unsigned int mclk_to_picos(unsigned int mclk)
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/7] powerpc: Minimal private libgcc to build on Debian
Standard Debian powerpc and powerpcspe systems only include hard-float libgcc in their native compilers, which causes scary build warnings when building U-Boot. The easiest way to resolve this is to borrow the routines that U-Boot needs from the Linux kernel (GPLv2-licensed), which has the same issue. Specifically, the routines are: _ashldi3(), _ashrdi3(), and _lshrdi3(). The Makefile framework was copied from the U-Boot ARM port. Signed-off-by: Kyle Moffett --- arch/powerpc/lib/Makefile | 28 - arch/powerpc/lib/_ashldi3.S | 45 + arch/powerpc/lib/_ashrdi3.S | 47 +++ arch/powerpc/lib/_lshrdi3.S | 45 + 4 files changed, 164 insertions(+), 1 deletions(-) create mode 100644 arch/powerpc/lib/_ashldi3.S create mode 100644 arch/powerpc/lib/_ashrdi3.S create mode 100644 arch/powerpc/lib/_lshrdi3.S diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile index 724d8ee..5733e59 100644 --- a/arch/powerpc/lib/Makefile +++ b/arch/powerpc/lib/Makefile @@ -23,6 +23,19 @@ include $(TOPDIR)/config.mk +## Build a couple of necessary functions into a private libgcc +LIBGCC = $(obj)libgcc.o +GLSOBJS+= _ashldi3.o +GLSOBJS+= _ashrdi3.o +GLSOBJS+= _lshrdi3.o +LGOBJS := $(addprefix $(obj),$(GLSOBJS)) \ + $(addprefix $(obj),$(GLCOBJS)) + +## But only build it if the user asked for it +ifdef USE_PRIVATE_LIBGCC +TARGETS+= $(LIBGCC) +endif + LIB= $(obj)lib$(ARCH).o SOBJS-y+= ppccache.o @@ -53,9 +66,14 @@ endif COBJS += $(sort $(COBJS-y)) -SRCS := $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c) +SRCS := $(GLSOBJS:.o=.S) $(GLCOBJS:.o=.c) \ + $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c) OBJS := $(addprefix $(obj),$(SOBJS-y) $(COBJS-y)) +TARGETS += $(LIB) + +all: $(TARGETS) + $(LIB):$(obj).depend $(OBJS) @if ! $(CROSS_COMPILE)readelf -S $(OBJS) | grep -q '\.fixup.*PROGBITS';\ then \ @@ -65,6 +83,9 @@ $(LIB): $(obj).depend $(OBJS) fi; $(call cmd_link_o_target, $(OBJS)) +$(LIBGCC): $(obj).depend $(LGOBJS) + $(call cmd_link_o_target, $(LGOBJS)) + # # defines $(obj).depend target diff --git a/arch/powerpc/lib/_ashldi3.S b/arch/powerpc/lib/_ashldi3.S new file mode 100644 index 000..1835904 --- /dev/null +++ b/arch/powerpc/lib/_ashldi3.S @@ -0,0 +1,45 @@ +/* + * This code was copied from arch/powerpc/kernel/misc_32.S in the Linux + * kernel sources. The file it was copied from is licensed as follows: + * + * (C) Copyright 1995-1996 Gary Thomas (g...@linuxppc.org) + * + * Largely rewritten by Cort Dougan (c...@cs.nmt.edu) + * and Paul Mackerras. + * + * 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. + * + */ + +#include +#include +#include + +/* + * Extended precision shifts. + * + * Updated to be valid for shift counts from 0 to 63 inclusive. + * -- Gabriel + * + * R3/R4 has 64 bit value + * R5has shift count + * result in R3/R4 + * + * ashrdi3: arithmetic right shift (sign propagation) + * lshrdi3: logical right shift + * ashldi3: left shift + */ + .globl __ashldi3 +__ashldi3: + subfic r6,r5,32 + slw r3,r3,r5# MSW = count > 31 ? 0 : MSW << count + addir7,r5,32# could be xori, or addi with -32 + srw r6,r4,r6# t1 = count > 31 ? 0 : LSW >> (32-count) + slw r7,r4,r7# t2 = count < 32 ? 0 : LSW << (count-32) + or r3,r3,r6# MSW |= t1 + slw r4,r4,r5# LSW = LSW << count + or r3,r3,r7# MSW |= t2 + blr diff --git a/arch/powerpc/lib/_ashrdi3.S b/arch/powerpc/lib/_ashrdi3.S new file mode 100644 index 000..ff00197 --- /dev/null +++ b/arch/powerpc/lib/_ashrdi3.S @@ -0,0 +1,47 @@ +/* + * This code was copied from arch/powerpc/kernel/misc_32.S in the Linux + * kernel sources. The file it was copied from is licensed as follows: + * + * (C) Copyright 1995-1996 Gary Thomas (g...@linuxppc.org) + * + * Largely rewritten by Cort Dougan (c...@cs.nmt.edu) + * and Paul Mackerras. + * + * 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. + * + */ + +#include +#include +#include + +/* + * Extended precision shifts. + * + * Updated to be valid for shift counts from 0 to 63 inclusive. + * -- Gabriel + * + * R3/R4 has 64 bit value + * R5has shift count + * result in R3/R4 + * + * ashrdi3: arithmetic right shift (sign propagation) + * lshr
[U-Boot] [PATCH 6/7] fdt_support: Fix buffer overflow in fdt_fixup_memory_banks
When fdt_fixup_memory_banks is called with 2-cell address and size
fields in the device-tree (IE: 64-bit address and size), then it will
overflow its on-stack "tmp" buffer.
This fixes the buffer size and adds a comment explaining how many bytes
need to be allocated per record.
Signed-off-by: Kyle Moffett
---
common/fdt_support.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index 6c98e5b..edcf04a 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -394,7 +394,7 @@ int fdt_fixup_memory_banks(void *blob, u64 start[], u64
size[], int banks)
{
int err, nodeoffset;
int addr_cell_len, size_cell_len, len;
- u8 tmp[banks * 8];
+ u8 tmp[banks * 16]; /* Up to 64-bit address + 64-bit size */
int bank;
err = fdt_check_header(blob);
--
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/7] mpc85xx: Add inline GPIO acessor functions
To ease the implementation of other MPC85xx board ports, several common
GPIO helpers are added to .
Since each of these compiles to no more than 4-5 instructions it would
be very inefficient to call them out of line, therefore we put them
entirely in the header file.
The HWW-1U-1A board port which these were written for strongly prefers
to set multiple GPIOs as a single batch operation, so the API is
designed around that basis.
To assist other board ports, a small set of wrappers are used which
provides a standard gpio_request() interface around the MPC85xx-specific
functions. This can be enabled with CONFIG_MPC85XX_GENERIC_GPIO
Signed-off-by: Kyle Moffett
---
arch/powerpc/include/asm/mpc85xx_gpio.h | 124 +++
1 files changed, 124 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/include/asm/mpc85xx_gpio.h
diff --git a/arch/powerpc/include/asm/mpc85xx_gpio.h
b/arch/powerpc/include/asm/mpc85xx_gpio.h
new file mode 100644
index 000..d02d933
--- /dev/null
+++ b/arch/powerpc/include/asm/mpc85xx_gpio.h
@@ -0,0 +1,124 @@
+/*
+ * Copyright 2010 eXMeritus, A Boeing Company
+ *
+ * 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
+
+/*
+ * The following internal functions are an MPC85XX-specific GPIO API which
+ * allows setting and querying multiple GPIOs in a single operation.
+ *
+ * All of these look relatively large, but the arguments are almost always
+ * constants, so they compile down to just a few instructions and a
+ * memory-mapped IO operation or two.
+ */
+static inline void mpc85xx_gpio_set(unsigned int mask,
+ unsigned int dir, unsigned int val)
+{
+ volatile ccsr_gpio_t *gpio;
+
+ /* First mask off the unwanted parts of "dir" and "val" */
+ dir &= mask;
+ val &= mask;
+
+ /* Now read in the values we're supposed to preserve */
+ gpio = (void *)(CONFIG_SYS_MPC85xx_GPIO_ADDR + 0xc00);
+ dir |= (in_be32(&gpio->gpdir) & ~mask);
+ val |= (in_be32(&gpio->gpdat) & ~mask);
+
+ /* Now write out the new values, writing the direction first */
+ out_be32(&gpio->gpdir, dir);
+ asm("sync; isync":::"memory");
+ out_be32(&gpio->gpdat, val);
+}
+
+static inline void mpc85xx_gpio_set_in(unsigned int gpios)
+{
+ mpc85xx_gpio_set(gpios, 0x, 0x);
+}
+
+static inline void mpc85xx_gpio_set_low(unsigned int gpios)
+{
+ mpc85xx_gpio_set(gpios, 0x, 0x);
+}
+
+static inline void mpc85xx_gpio_set_high(unsigned int gpios)
+{
+ mpc85xx_gpio_set(gpios, 0x, 0x);
+}
+
+static inline unsigned int mpc85xx_gpio_get(unsigned int mask)
+{
+ volatile ccsr_gpio_t *gpio;
+ unsigned int ret;
+
+ /* Read the requested values */
+ gpio = (void *)(CONFIG_SYS_MPC85xx_GPIO_ADDR + 0xc00);
+ ret = mask & in_be32(&gpio->gpdat);
+
+ return ret;
+}
+
+/*
+ * These implement the standard generic GPIO API on top of the
+ * MPC85xx-specific header.
+ */
+#ifdef CONFIG_MPC85XX_GENERIC_GPIO
+static inline int gpio_request(unsigned gpio, const char *label)
+{
+ /* Do nothing */
+ (void)gpio;
+ (void)label;
+}
+
+static inline void gpio_free(unsigned gpio)
+{
+ /* Do nothing */
+ (void)gpio;
+}
+
+static inline int gpio_direction_input(unsigned gpio)
+{
+ mpc85xx_gpio_set_in(1U << gpio);
+ return 0;
+}
+
+static inline int gpio_direction_output(unsigned gpio, int value)
+{
+ mpc85xx_gpio_set_low(1U << gpio);
+ return 0;
+}
+
+static inline int gpio_get_value(unsigned gpio)
+{
+ return !!mpc85xx_gpio_get(1U << gpio)
+}
+
+static inline void gpio_set_value(unsigned gpio, int value)
+{
+ if (value)
+ mpc85xx_gpio_set_high(1U << gpio);
+ else
+ mpc85xx_gpio_set_low(1U << gpio);
+}
+
+static inline int gpio_is_valid(int gpio)
+{
+ return (gpio >= 0) && (gpio < 32);
+}
+#endif /* CONFIG_MPC85XX_GENERIC_GPIO */
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/7] mpc85xx: Add board support for the eXMeritus HWW-1U-1A devices
The eXMeritus HWW-1U-1A unit is a DO-160-certified 13lb 1U chassis with 3 independent TEMPEST zones. Two independent P2020 computers may be found inside each zone. Complete hardware support is included. High-level hardware overview: * DO-160 certified for passenger aircraft (noncritical) * TEMPEST ceritified for RED/BLACK separation * 3 zones per chassis, 2 computers per zone (total of 6) * Dual-core 1.066GHz P2020 per computer * One 2GB DDR2 SO-RDIMM module per computer (upgradable to 4GB) * Removable 80GB or 160GB Intel X18-M SSD per computer * Front-accessible dual-port E1000E per computer * Front-accessible serial console per computer * Front-accessible USB port per computer * Internal Gigabit crossover within each TEMPEST zone * Internal unidirectional fiber links across TEMPEST zones * Battery-backed DS1339 I2C RTC on each CPU. Combined, each 13lb 1U chassis contains 12GB RAM, 12 cores @ 1.066GHz, 12 front-accessible Gigabit Ethernet ports and 960GB of solid-state storage with a total power consumption of ~200W. Additional notes: * SPD detection is only known to work with the DO-160-certified DIMMs * A U-Boot built with 36-bit address-space seems to work, but I don't yet have a usable 36-bit kernel or DTB, so it's mostly untested. * CPU reset is a little quirky due to hardware misfeature, see the extensive comments in the board_reset_r() function in hww-1u-1a.c Signed-off-by: Kyle Moffett --- MAINTAINERS |4 + board/exmeritus/hww1u1a/Makefile | 54 board/exmeritus/hww1u1a/ddr.c | 51 +++ board/exmeritus/hww1u1a/gpios.h | 81 + board/exmeritus/hww1u1a/hww1u1a.c | 629 + board/exmeritus/hww1u1a/law.c | 34 ++ board/exmeritus/hww1u1a/tlb.c | 106 +++ boards.cfg|2 + include/configs/HWW1U1A.h | 470 +++ 9 files changed, 1431 insertions(+), 0 deletions(-) create mode 100644 board/exmeritus/hww1u1a/Makefile create mode 100644 board/exmeritus/hww1u1a/ddr.c create mode 100644 board/exmeritus/hww1u1a/gpios.h create mode 100644 board/exmeritus/hww1u1a/hww1u1a.c create mode 100644 board/exmeritus/hww1u1a/law.c create mode 100644 board/exmeritus/hww1u1a/tlb.c create mode 100644 include/configs/HWW1U1A.h diff --git a/MAINTAINERS b/MAINTAINERS index 07541bd..5da7c1f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -320,6 +320,10 @@ Reinhard Meyer TOP5200 MPC5200 TOP9000 ARM926EJS (AT91SAM9xxx SoC) +Kyle Moffett + + HWW1U1A P2020 + Tolunay Orkun csb272 PPC405GP diff --git a/board/exmeritus/hww1u1a/Makefile b/board/exmeritus/hww1u1a/Makefile new file mode 100644 index 000..b927f59 --- /dev/null +++ b/board/exmeritus/hww1u1a/Makefile @@ -0,0 +1,54 @@ +# +# Copyright 2007-2009 Freescale Semiconductor, Inc. +# (C) Copyright 2001-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-y+= $(BOARD).o +COBJS-y+= law.o +COBJS-y+= tlb.o +COBJS-$(CONFIG_DDR_SPD) += ddr.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)) + +clean: + rm -f $(OBJS) $(SOBJS) + +distclean: clean + rm -f $(LIB) core *.bak .depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/exmeritus/hww1u1a/ddr.c b/board/exmeritus/hww1u1a/ddr.c new file mode 100644 index 000..dbdcc86 --- /dev/null +++ b/board/exmeritus/hww1u1a/ddr.c @@ -0,0 +1,51 @@ +/* + * Copyright 2009-2010 eXMeritus, A Boeing Company + * Copyright 2008-2009 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 + * Vers
Re: [U-Boot] Reading from NAND
> Is there any reason for not using itest.b directly?
If I do a test on a non-word aligned location the processor gets an exception.
Also does the shell support adding values like "itest *(${base} +
${offset}) == 0x01"?
Or any other integer addition or subtraction so that a loop can walk an array?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] ARM: Update mach types
> > This commit updates the mach-types to sync with ARM > Linux based on the following commit by Russell King > commit 4a683a2c5e7cabe91218db28e56dc25e1b134ce3 > > Signed-off-by: Jason Liu Already submitted and accepted http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commitdiff;h=c7977858dcf1f656cbe91ea0dc3cb9139c6a8cc8 --Sandeep ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Reading from NAND
Dear D Kesselring,
In message you
wrote:
> > Is there any reason for not using itest.b directly?
> If I do a test on a non-word aligned location the processor gets an exception.
You cannot do a byte access on a random address?? Than something is
seriously broken in your system.
> Also does the shell support adding values like "itest *(${base} +
> ${offset}) == 0x01"?
Why would that be needed?
> Or any other integer addition or subtraction so that a loop can walk an array?
You can use setexpr in a loop to increment or decrement an address or
perform any other kind of arithmetics.
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
Marriage is the sole cause of divorce.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] mpc85xx: Support a board-specific processor reset routines
Dear Kyle Moffett,
In message <1298311199-18775-2-git-send-email-kyle.d.moff...@boeing.com> you
wrote:
> Some board models (such as the submitted P2020-based HWW-1U-1A hardware)
> need specialized code to run when a reset is requested to ensure proper
> synchronization with other hardware.
>
> In order to facilitate such board ports, we add a board_reset_r()
> routine which is called from the do_reset() command function instead of
> directly poking at the MPC85xx "RSTCR" (reset control) register.
>
> Signed-off-by: Kyle Moffett
> ---
> arch/powerpc/cpu/mpc85xx/cpu.c |7 +--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c b/arch/powerpc/cpu/mpc85xx/cpu.c
> index 1aad2ba..dbc662f 100644
> --- a/arch/powerpc/cpu/mpc85xx/cpu.c
> +++ b/arch/powerpc/cpu/mpc85xx/cpu.c
> @@ -204,8 +204,10 @@ int checkcpu (void)
>
> int do_reset (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> {
> -/* Everything after the first generation of PQ3 parts has RSTCR */
> -#if defined(CONFIG_MPC8540) || defined(CONFIG_MPC8541) || \
> +#if defined(CONFIG_BOARD_RESET_R)
> + extern void board_reset_r(void);
> + board_reset_r();
> +#elif defined(CONFIG_MPC8540) || defined(CONFIG_MPC8541) || \
> defined(CONFIG_MPC8555) || defined(CONFIG_MPC8560)
> unsigned long val, msr;
Please implement without #ifdef's using a weak function - see
arch/powerpc/cpu/mpc86xx/cpu.c for an example. Actually you might
want to facto this out into common code.
Side note: don't use ever "extern" function declarations in the code;
use proper prototype declarations in some header file instead.
> @@ -221,6 +223,7 @@ int do_reset (cmd_tbl_t *cmdtp, int flag, int argc, char
> * const argv[])
> val |= 0x7000;
> mtspr(DBCR0,val);
> #else
> + /* Everything after the first generation of PQ3 parts has RSTCR */
> volatile ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
Note that this declaration is now basicy in the middle of code, which
is ugly at best.
What is the "volatile" needed for?
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
An Elephant is a mouse with an Operating System. - Knuth
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/7] mpc8xxx: DDR2/3: Use human-readable SPD DIMM-type constants
Dear Kyle Moffett, In message <1298311199-18775-3-git-send-email-kyle.d.moff...@boeing.com> you wrote: > Use #define constants to enhance readability of DDR2/3 SPD parsing code. > Also add the DDR2 type for an SO-RDIMM module to the switch statement. > > Signed-off-by: Kyle Moffett > --- > arch/powerpc/cpu/mpc8xxx/ddr/ddr2_dimm_params.c | 34 +++-- > arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c | 37 > ++- > common/ddr_spd.c|2 +- > include/ddr_spd.h | 28 - > 4 files changed, 60 insertions(+), 41 deletions(-) ... > + case DDR3_SPD_MODULETYPE_UDIMM: > + case DDR3_SPD_MODULETYPE_SO_DIMM: > + case DDR3_SPD_MODULETYPE_MICRO_DIMM: > + case DDR3_SPD_MODULETYPE_MINI_UDIMM: > + /* Unbuffered DIMMs */ > + pdimm->registered_dimm = 0; > + pdimm->mirrored_dimm = spd->mod_section.unbuffered.addr_mapping > & 0x1; > break; Line too long. 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 The thing is, as you progress in the Craft, you'll learn there is another rule... When you break rules, break 'em good and hard. - Terry Pratchett, _Wyrd Sisters_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] mpc85xx: Add inline GPIO acessor functions
Dear Kyle Moffett,
In message <1298311199-18775-4-git-send-email-kyle.d.moff...@boeing.com> you
wrote:
> To ease the implementation of other MPC85xx board ports, several common
> GPIO helpers are added to .
In which way is this specific to 85xx? Why not make available on a
wider base?
> To assist other board ports, a small set of wrappers are used which
> provides a standard gpio_request() interface around the MPC85xx-specific
> functions. This can be enabled with CONFIG_MPC85XX_GENERIC_GPIO
How similar is this interface with other "generic" GPIO interfaces we
have here in U-Boot (and in Linux) ?
> +static inline void mpc85xx_gpio_set(unsigned int mask,
> + unsigned int dir, unsigned int val)
> +{
> + volatile ccsr_gpio_t *gpio;
> +
> + /* First mask off the unwanted parts of "dir" and "val" */
> + dir &= mask;
> + val &= mask;
> +
> + /* Now read in the values we're supposed to preserve */
> + gpio = (void *)(CONFIG_SYS_MPC85xx_GPIO_ADDR + 0xc00);
> + dir |= (in_be32(&gpio->gpdir) & ~mask);
> + val |= (in_be32(&gpio->gpdat) & ~mask);
> +
> + /* Now write out the new values, writing the direction first */
> + out_be32(&gpio->gpdir, dir);
This way work, but quite often is wrong. If you set the direction
first for an output, you start driving the old value, before you set
the correct one. This results in a short pulse that may cause
negative side effects.
Don't!
> + asm("sync; isync":::"memory");
Why would that be needed? out_be32() is supposed to provide sufficient
memory barriers.
> +static inline unsigned int mpc85xx_gpio_get(unsigned int mask)
> +{
> + volatile ccsr_gpio_t *gpio;
Why would this volatile be needed here? [Please fix globally.]
> +#ifdef CONFIG_MPC85XX_GENERIC_GPIO
> +static inline int gpio_request(unsigned gpio, const char *label)
> +{
> + /* Do nothing */
> + (void)gpio;
> + (void)label;
NAK. Please don't do that. Fix globally.
> +static inline int gpio_direction_input(unsigned gpio)
> +{
> + mpc85xx_gpio_set_in(1U << gpio);
> + return 0;
> +}
Why is this function not void when it cannot return any usefult return
code anyway?
> +static inline int gpio_direction_output(unsigned gpio, int value)
> +{
> + mpc85xx_gpio_set_low(1U << gpio);
> + return 0;
> +}
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
Cleverness and Style have no place in getting a project completed.
-- Tom Christiansen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/7] fsl_ddr: Don't use full 64-bit divides on 32-bit PowerPC
Dear Kyle Moffett, In message <1298311199-18775-5-git-send-email-kyle.d.moff...@boeing.com> you wrote: > The current FreeScale MPC-8xxx DDR SPD interpreter is using full 64-bit > integer divide operations to convert between nanoseconds and DDR clock > cycles given arbitrary DDR clock frequencies. > > Since all of the inputs to this are 32-bit (nanoseconds, clock cycles, > and DDR frequencies), we can easily restructure the computation to use > the "do_div()" function to perform 64-bit/32-bit divide operations. > > This decreases compute time rather significantly for each conversion and > avoids bringing in a very complicated function from libgcc. > > It should be noted that nothing else in U-Boot or the Linux kernel seems > to require a full 64-bit divide on any 32-bit PowerPC. > > Build-and-boot-tested on the HWW-1U-1A board using DDR2 SPD detection. > > Signed-off-by: Kyle Moffett > --- > > Author's note: This patch really needs a bunch more review and testing, but > I only have access to a very limited selection of hardware. Please let me > know about any questions or concerns. This patch should be split off the patch series and submitted separately. 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 witty saying proves nothing." - Voltaire ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/7] powerpc: Minimal private libgcc to build on Debian
Dear Kyle Moffett, In message <1298311199-18775-6-git-send-email-kyle.d.moff...@boeing.com> you wrote: > Standard Debian powerpc and powerpcspe systems only include hard-float > libgcc in their native compilers, which causes scary build warnings when > building U-Boot. > > The easiest way to resolve this is to borrow the routines that U-Boot > needs from the Linux kernel (GPLv2-licensed), which has the same issue. Actually the code says "either version 2 of the License, or (at your option) any later version", as far as I can tell ? > Specifically, the routines are: _ashldi3(), _ashrdi3(), and _lshrdi3(). We have been building for years on such systems, and I don;t remember that such issues have been reprted before for Power Architecture systems (I remember only ARM to have such issues). How comes this is suddenly popping up now? Please also follow the rules when copying code from Linux - provide exact reference; see bullet # 4 at 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 "...one of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs." - Robert Firth ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/7] powerpc: Minimal private libgcc to build on Debian
Dear Kyle Moffett, In message <1298311199-18775-6-git-send-email-kyle.d.moff...@boeing.com> you wrote: > Standard Debian powerpc and powerpcspe systems only include hard-float > libgcc in their native compilers, which causes scary build warnings when > building U-Boot. > > The easiest way to resolve this is to borrow the routines that U-Boot > needs from the Linux kernel (GPLv2-licensed), which has the same issue. > > Specifically, the routines are: _ashldi3(), _ashrdi3(), and _lshrdi3(). > > The Makefile framework was copied from the U-Boot ARM port. > > Signed-off-by: Kyle Moffett There are also whitespace problems with this patch - there is trailing whitespace in the assembler code. 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 Uncertain fortune is thoroughly mastered by the equity of the calcu- lation. - Blaise Pascal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/7] fdt_support: Fix buffer overflow in fdt_fixup_memory_banks
Dear Kyle Moffett, In message <1298311199-18775-7-git-send-email-kyle.d.moff...@boeing.com> you wrote: > When fdt_fixup_memory_banks is called with 2-cell address and size > fields in the device-tree (IE: 64-bit address and size), then it will > overflow its on-stack "tmp" buffer. > > This fixes the buffer size and adds a comment explaining how many bytes > need to be allocated per record. > > Signed-off-by: Kyle Moffett > --- This should also submitted as separate patch (as bug fix, actually). 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 Der Irrtum wiederholt sich immerfort in der Tat. Deshalb muß man das Wahre unermüdlich in Worten wiederholen. - Goethe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] mpc85xx: Add board support for the eXMeritus HWW-1U-1A devices
Dear Kyle Moffett,
In message <1298311199-18775-8-git-send-email-kyle.d.moff...@boeing.com> you
wrote:
> The eXMeritus HWW-1U-1A unit is a DO-160-certified 13lb 1U chassis
> with 3 independent TEMPEST zones. Two independent P2020 computers may
> be found inside each zone. Complete hardware support is included.
...
There are a number of formal issues - please run checkpatch:
total: 12 errors, 12 warnings, 1443 lines checked
ERROR: do not initialise statics to 0 or NULL
ERROR: space prohibited after that open parenthesis '('
ERROR: space prohibited before that close parenthesis ')'
WARNING: Use of volatile is usually wrong: see
Documentation/volatile-considered-harmful.txt
WARNING: externs should be avoided in .c files
WARNING: please, no spaces at the start of a line
Please fix.
...
> + puts("Waiting 1 sec for reset...");
> + for (i = 0; i < 10; i++) {
> + udelay(10);
> + puts(".");
> + }
Do you really need a full second here?
...
> +U_BOOT_CMD(
> + hww1u1a_is_cpu_a, 1, 0, do_hww1u1a_is_cpu_a,
> + "Test if this is CPU A (versus B) on the eXMeritus HWW-1U-1A board",
> + /* */" && echo This is CPU A\n"
> + "if hww1u1a_is_cpu_a; then\n"
> + "## Do stuff\n"
> + "else\n"
> + "## Do other stuff\n"
> + "fi"
Please don't misuse the help messages like that. Use external
documentation instead.
> +
> +/* Create a prompt-like string: "uboot@HOSTNAME% " */
> +#define PROMPT_PREFIX "uboot@exm"
> +#define PROMPT_SUFFIX "% "
> +
> +/* This function returns a PS1 prompt based on the serial number */
> +static char *hww1u1a_prompt = NULL;
> +const char *hww1u1a_get_ps1(void)
> +{
> + unsigned long len, i, j;
> + const char *serialnr;
> +
> + /* If our prompt was already set, just use that */
> + if (hww1u1a_prompt)
> + return hww1u1a_prompt;
> +
> + /* Use our serial number if present, otherwise "UNPROGRAMMED-[AB]" */
> + serialnr = getenv("serial#");
> + if (!serialnr || !serialnr[0]) {
> + if (hww1u1a_is_cpu_a())
> + serialnr = "99-XA";
> + else
> + serialnr = "99-XB";
> + }
> +
> + /*
> + * We will turn the serial number into a hostname by:
> + * (A) Delete all non-alphanumerics.
> + * (B) Lowercase all letters
> + * (C) Prefix "exm"
> + */
> + for (i = 0, len = 0; serialnr[i]; i++)
> + if (isalnum(serialnr[i]))
> + len++;
> +
> + len += sizeof(PROMPT_PREFIX PROMPT_SUFFIX); /* Includes NUL */
> + hww1u1a_prompt = malloc(len);
> + if (!hww1u1a_prompt)
> + return PROMPT_PREFIX "UNKNOWN(ENOMEM)" PROMPT_SUFFIX;
> +
> + /* Now actually fill it in */
> + i = 0;
> +
> + /* Handle the prefix */
> + for (j = 0; j < sizeof(PROMPT_PREFIX) - 1; j++)
> + hww1u1a_prompt[i++] = PROMPT_PREFIX[j];
> +
> + /* Now the serial# part of the hostname */
> + for (j = 0; serialnr[j]; j++)
> + if (isalnum(serialnr[j]))
> + hww1u1a_prompt[i++] = tolower(serialnr[j]);
> +
> + /* Finally the suffix */
> + for (j = 0; j < sizeof(PROMPT_SUFFIX); j++)
> + hww1u1a_prompt[i++] = PROMPT_SUFFIX[j];
> +
> + /* This should all have added up, but just in case */
> + hww1u1a_prompt[len - 1] = '\0';
> +
> + /* Now we're done */
> + return hww1u1a_prompt;
> +}
> +
> +#ifndef CONFIG_DDR_SPD
> +phys_size_t fixed_sdram(void)
> +{
> + /* This is manual (non-SPD) DDR2 SDRAM configuration (2GB ECC) */
> + volatile ccsr_ddr_t *ddr = (ccsr_ddr_t *)CONFIG_SYS_MPC85xx_DDR_ADDR;
> + phys_size_t dram_size = (2048ULL) << 20;
> +
> + /*
> + * First program the DDR registers, then allow time for the SDRAM
> + * configuration and clocks to settle before enabling everything.
> + */
> + out_be32(&ddr->cs0_bnds,0x003F);
> + out_be32(&ddr->cs1_bnds,0x0040007F);
> + out_be32(&ddr->cs0_config, 0x80014202);
> + out_be32(&ddr->cs1_config, 0x80014202);
> + out_be32(&ddr->timing_cfg_0,0x00330804);
> + out_be32(&ddr->timing_cfg_1,0x6f69f643);
> + out_be32(&ddr->timing_cfg_2,0x022068cd);
> + out_be32(&ddr->timing_cfg_3,0x0003);
> + out_be32(&ddr->sdram_cfg_2, 0x04400010);
> + out_be32(&ddr->sdram_mode, 0x00440452);
> + out_be32(&ddr->sdram_mode_2,0x);
> + out_be32(&ddr->sdram_md_cntl, 0x);
> + out_be32(&ddr->sdram_interval, 0x0a280110);
> + out_be32(&ddr->sdram_data_init, 0xDEADBEEF);
> + out_be32(&ddr->sdram_clk_cntl, 0x0200);
> + out_be32(&ddr->timing_cfg_4,0x);
> + out_be32(&ddr->timing_cfg_5,0x);
> + out_be32(&ddr->ddr_zq_cntl, 0x);
> + out_be32(&ddr->ddr_wrlvl_cntl, 0x);
> + out_be32(&ddr->ip_rev1,
Re: [U-Boot] [PATCH 3/7] mpc85xx: Add inline GPIO acessor functions
Dear "Moffett, Kyle D",
In message you wrote:
>
> >> +static inline int gpio_direction_input(unsigned gpio)
> >> +{
> >> + mpc85xx_gpio_set_in(1U << gpio);
> >> + return 0;
> >> +}
> >
> > Why is this function not void when it cannot return any usefult return
> > code anyway?
> >
> >> +static inline int gpio_direction_output(unsigned gpio, int value)
> >> +{
> >> + mpc85xx_gpio_set_low(1U << gpio);
> >> + return 0;
> >> +}
> >
> > Ditto.
>
> This is the "Linux-compatible" gpio layer that Peter Tyser was asking
> for. I sort-of-copied most of these functions from
> arch/nios2/include/asm/gpio.h, which just does the "return 0;" in
> several functions.
> Those 2 later functions are expected to be able to return an error (for
> I2C chips and such). As I said above, if these wrappers are
> unacceptable then I will just delete them; the only thing I use are the
> mpc85xx_gpio_*() functions.
It's not unacceptable, but maybe you add a comment to explain why
these return int.
> --Apple-Mail-2-42328377
> Content-Disposition: attachment; filename"smime.p7s"
> Content-Type: application/pkcs7-signature; name"smime.p7s"
> Content-Transfer-Encoding: base64
Do you really have to append a 120 line binary encoded signature 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
I read part of it all the way through.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/7] mpc8xxx: DDR2/3: Use human-readable SPD DIMM-type constants
Dear "Moffett, Kyle D", In message <325e6be9-3fcd-4798-813a-26cd3ccc5...@boeing.com> you wrote: > > > Line too long. Please fix globally. > > Ok, will fix. Although, this one is only 87 characters and some of the = > other lines already in that file are 93 characters long. It would be nice if you could provide a separate patch (to go completely separate, or earlier in the series) to fix the other lines as well. 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 I am not now, nor have I ever been, a member of the demigodic party. -- Dennis Ritchie ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/7] powerpc: Minimal private libgcc to build on Debian
On Feb 21, 2011, at 16:23, Wolfgang Denk wrote: > In message <1298311199-18775-6-git-send-email-kyle.d.moff...@boeing.com> you > wrote: >> Standard Debian powerpc and powerpcspe systems only include hard-float >> libgcc in their native compilers, which causes scary build warnings when >> building U-Boot. >> >> The easiest way to resolve this is to borrow the routines that U-Boot >> needs from the Linux kernel (GPLv2-licensed), which has the same issue. > > Actually the code says "either version 2 of the License, or (at your > option) any later version", as far as I can tell ? Ah, sorry, I dropped the "+" in there somehow. Will fix. >> Specifically, the routines are: _ashldi3(), _ashrdi3(), and _lshrdi3(). > > We have been building for years on such systems, and I don;t remember > that such issues have been reprted before for Power Architecture > systems (I remember only ARM to have such issues). Debian/RedHat used to build "nof" libraries, but they were almost completely unused and several major bugs went unnoticed for a while. Furthermore, they took a lot of time to build and they basically did not get used. Eventually it was decided to just remove the "nof" (soft-float) libgcc, etc. It's not actually fatal right now, because the 3 routines that it pulls from hard-float libgcc don't use floating point (you just get a nasty warning). The problem is that if somebody were to accidentally use one of the hard-float-based routines in U-Boot I would unexpectedly get indeterminate results instead of compile errors. > Please also follow the rules when copying code from Linux - provide > exact reference; see bullet # 4 at > http://www.denx.de/wiki/view/U-Boot/Patches#Attributing_Code_Copyrights_Sign Will fix, thanks! Cheers, Kyle Moffett smime.p7s Description: S/MIME cryptographic signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] mpc85xx: Add board support for the eXMeritus HWW-1U-1A devices
On Feb 21, 2011, at 16:47, Wolfgang Denk wrote:
> In message <1298311199-18775-8-git-send-email-kyle.d.moff...@boeing.com> you
> wrote:
>> The eXMeritus HWW-1U-1A unit is a DO-160-certified 13lb 1U chassis
>> with 3 independent TEMPEST zones. Two independent P2020 computers may
>> be found inside each zone. Complete hardware support is included.
> ...
>
> There are a number of formal issues - please run checkpatch:
> total: 12 errors, 12 warnings, 1443 lines checked
>
> ERROR: do not initialise statics to 0 or NULL
> ERROR: space prohibited after that open parenthesis '('
> ERROR: space prohibited before that close parenthesis ')'
> WARNING: Use of volatile is usually wrong: see
> Documentation/volatile-considered-harmful.txt
> WARNING: externs should be avoided in .c files
> WARNING: please, no spaces at the start of a line
>
> Please fix.
Ok, will fix. Most of the "volatile" problems were copied from the P2020DS
board and other MPC85xx boards, those are definitely wrong there too.
> ...
>> +puts("Waiting 1 sec for reset...");
>> +for (i = 0; i < 10; i++) {
>> +udelay(10);
>> +puts(".");
>> +}
>
> Do you really need a full second here?
Probably not, but this code only ever executes when a JTAG debugger has been
poking around already (the pins are always low after CPU reset), so I'd prefer
not to risk breaking it unless absolutely necessary.
> ...
>> +U_BOOT_CMD(
>> +hww1u1a_is_cpu_a, 1, 0, do_hww1u1a_is_cpu_a,
>> +"Test if this is CPU A (versus B) on the eXMeritus HWW-1U-1A board",
>> +/* */" && echo This is CPU A\n"
>> +"if hww1u1a_is_cpu_a; then\n"
>> +"## Do stuff\n"
>> +"else\n"
>> +"## Do other stuff\n"
>> +"fi"
>
> Please don't misuse the help messages like that. Use external
> documentation instead.
Ok, is just " && echo This is CPU A\n" OK? I'm trying to show possible usage
of the command and it has no actual arguments or output on its own.
>> +#ifndef CONFIG_DDR_SPD
>> +phys_size_t fixed_sdram(void)
>> +{
>> +/* This is manual (non-SPD) DDR2 SDRAM configuration (2GB ECC) */
>> +volatile ccsr_ddr_t *ddr = (ccsr_ddr_t *)CONFIG_SYS_MPC85xx_DDR_ADDR;
>> +phys_size_t dram_size = (2048ULL) << 20;
>> +
>> +/*
>> + * First program the DDR registers, then allow time for the SDRAM
>> + * configuration and clocks to settle before enabling everything.
>> + */
>> +out_be32(&ddr->cs0_bnds,0x003F);
>> +out_be32(&ddr->cs1_bnds,0x0040007F);
>> +out_be32(&ddr->cs0_config, 0x80014202);
>> +out_be32(&ddr->cs1_config, 0x80014202);
>> +out_be32(&ddr->timing_cfg_0,0x00330804);
>> +out_be32(&ddr->timing_cfg_1,0x6f69f643);
>> +out_be32(&ddr->timing_cfg_2,0x022068cd);
>> +out_be32(&ddr->timing_cfg_3,0x0003);
>> +out_be32(&ddr->sdram_cfg_2, 0x04400010);
>> +out_be32(&ddr->sdram_mode, 0x00440452);
>> +out_be32(&ddr->sdram_mode_2,0x);
>> +out_be32(&ddr->sdram_md_cntl, 0x);
>> +out_be32(&ddr->sdram_interval, 0x0a280110);
>> +out_be32(&ddr->sdram_data_init, 0xDEADBEEF);
>> +out_be32(&ddr->sdram_clk_cntl, 0x0200);
>> +out_be32(&ddr->timing_cfg_4,0x);
>> +out_be32(&ddr->timing_cfg_5,0x);
>> +out_be32(&ddr->ddr_zq_cntl, 0x);
>> +out_be32(&ddr->ddr_wrlvl_cntl, 0x);
>> +out_be32(&ddr->ip_rev1, 0x00020403);
>> +out_be32(&ddr->ip_rev2, 0x0100);
>> +out_be32(&ddr->err_int_en, 0x000D);
>> +out_be32(&ddr->err_disable, 0x);
>> +out_be32(&ddr->err_sbe, 0x0001);
>> +out_be32(&ddr->ddr_cdr1,0x0004);
>> +out_be32(&ddr->ddr_cdr2,0x);
>> +out_be32(&ddr->sdram_cfg, 0x7300);
>> +udelay(500);
>> +out_be32(&ddr->sdram_cfg, 0xF300);
>> +
>> +/* Now wait until memory is initialized */
>> +while (in_be32(&ddr->sdram_cfg_2) & 0x0010)
>> +udelay(1000);
>
> Please avoid all these magic constants and use symbolic names instead
> like other boards are doing.
Hum.
The only difference between this code and P2020DS is that the P2020DS
development board has:
include/configs/P2020DS.h:
#define CONFIG_SYS_DDR_CS0_BNDS 0x003F
#define CONFIG_SYS_DDR_CS1_BNDS 0x
[...]
board/freescale/p2020ds/p2020ds.c:
volatile ccsr_ddr_t *ddr = (ccsr_ddr_t *)CONFIG_SYS_MPC85xx_DDR_ADDR;
ddr->cs0_config = CONFIG_SYS_DDR_CS0_CONFIG;
ddr->cs1_config = CONFIG_SYS_DDR_CS1_CONFIG;
[...]
I don't see how using a bunch of #defines with the exact same names as the CCSR
DDR registers makes the code any more readable.
I only use this code for debugging so if the numeric constants are completely
unacceptable I will just delete it rather than try to rewrite it to make
everybody happy.
> ...
>> diff --git a/include/
Re: [U-Boot] [PATCH 3/7] mpc85xx: Add inline GPIO acessor functions
On Feb 21, 2011, at 16:56, Wolfgang Denk wrote:
> In message you wrote:
>>
+static inline int gpio_direction_input(unsigned gpio)
+{
+ mpc85xx_gpio_set_in(1U << gpio);
+ return 0;
+}
>>>
>>> Why is this function not void when it cannot return any usefult return
>>> code anyway?
>>>
+static inline int gpio_direction_output(unsigned gpio, int value)
+{
+ mpc85xx_gpio_set_low(1U << gpio);
+ return 0;
+}
>>>
>>> Ditto.
>>
>> This is the "Linux-compatible" gpio layer that Peter Tyser was asking
>> for. I sort-of-copied most of these functions from
>> arch/nios2/include/asm/gpio.h, which just does the "return 0;" in
>> several functions.
>> Those 2 later functions are expected to be able to return an error (for
>> I2C chips and such). As I said above, if these wrappers are
>> unacceptable then I will just delete them; the only thing I use are the
>> mpc85xx_gpio_*() functions.
>
> It's not unacceptable, but maybe you add a comment to explain why
> these return int.
Ok, will fix, thanks.
>> --Apple-Mail-2-42328377
>> Content-Disposition: attachment; filename"smime.p7s"
>> Content-Type: application/pkcs7-signature; name"smime.p7s"
>> Content-Transfer-Encoding: base64
>
> Do you really have to append a 120 line binary encoded signature here?
Ah, crap, somehow S/MIME signatures got turned on. It's a tiny checkbox in the
corner of the GUI. Sorry!
Cheers,
Kyle Moffett
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-arm
Dear Albert ARIBAUD, In message <4d621552.7090...@free.fr> you wrote: > Hi Wolfgang, > > Please pull the following from u-boot-arm/master. > > Amicalement, > Albert. > > The following changes since commit c650e1be41536a453d115e6b73898fa5dabdadc2: > >Fix compile warning in net/eth.c (2011-02-19 20:32:38 +0100) > > are available in the git repository at: >git://www.denx.de/git/u-boot-arm.git master > > Alexander Stein (1): >arm relocation: Fix calculation of board_init_r > > Fabio Estevam (4): >mx31pdk: Use the new relocation scheme >mx31pdk: Make the full boot log visible >arm1136: Fix NAND boot >arm1136 relocation: Fix calculation of board_init_r > > Lei Wen (5): >mv: seperate kirkwood and armada from common setting >ARM: Add Support for Marvell Pantheon Familiy SoCs >serial: add pantheon soc support >mvmfp: add MFP configuration support for PANTHEON >Pantheon: Add Board Support for Marvell dkb board > > Loïc Minier (1): >EfikaMX: switch to MACH_TYPE_MX51_EFIKAMX > > Po-Yu Chuang (1): >arm: get_sp() should always be compiled > > Sandeep Paulraj (1): >ARM: Update mach-types > > Tom Warren (4): >arm: Tegra2: Add basic NVIDIA Tegra2 SoC support >serial: Add Tegra2 serial port support >arm: Tegra2: Add support for NVIDIA Harmony board >arm: Tegra2: Add support for NVIDIA Seaboard board > > Wolfgang Denk (1): >ARM: fix write*() I/O accessors > > MAINTAINERS |9 + > README|5 + > arch/arm/cpu/arm1136/start.S | 18 +- > arch/arm/cpu/arm926ejs/pantheon/Makefile | 46 + > arch/arm/cpu/arm926ejs/pantheon/cpu.c | 78 ++ > arch/arm/cpu/arm926ejs/pantheon/dram.c| 132 +++ > arch/arm/cpu/arm926ejs/pantheon/timer.c | 214 > arch/arm/cpu/arm926ejs/start.S|2 +- > arch/arm/cpu/armv7/tegra2/Makefile| 48 + > arch/arm/cpu/armv7/tegra2/board.c | 88 ++ > arch/arm/cpu/armv7/tegra2/config.mk | 28 + > arch/arm/cpu/armv7/tegra2/lowlevel_init.S | 65 ++ > arch/arm/cpu/armv7/tegra2/sys_info.c | 35 + > arch/arm/cpu/armv7/tegra2/timer.c | 122 +++ > arch/arm/include/asm/arch-armada100/config.h | 44 + > arch/arm/include/asm/arch-kirkwood/config.h | 145 +++ > arch/arm/include/asm/arch-pantheon/config.h | 38 + > arch/arm/include/asm/arch-pantheon/cpu.h | 79 ++ > arch/arm/include/asm/arch-pantheon/mfp.h | 41 + > arch/arm/include/asm/arch-pantheon/pantheon.h | 54 + > arch/arm/include/asm/arch-tegra2/clk_rst.h| 165 > arch/arm/include/asm/arch-tegra2/pinmux.h | 55 ++ > arch/arm/include/asm/arch-tegra2/pmc.h| 124 +++ > arch/arm/include/asm/arch-tegra2/sys_proto.h | 35 + > arch/arm/include/asm/arch-tegra2/tegra2.h | 49 + > arch/arm/include/asm/arch-tegra2/uart.h | 47 + > arch/arm/include/asm/io.h |6 +- > arch/arm/include/asm/mach-types.h | 1291 > - > arch/arm/lib/bootm.c |4 +- > board/Marvell/dkb/Makefile| 51 + > board/Marvell/dkb/dkb.c | 54 + > board/efikamx/efikamx.c |2 +- > board/freescale/mx31pdk/mx31pdk.c | 17 +- > board/nvidia/common/board.c | 193 > board/nvidia/harmony/Makefile | 50 + > board/nvidia/seaboard/Makefile| 50 + > boards.cfg|3 + > common/serial.c |3 +- > drivers/gpio/mvmfp.c |2 + > drivers/serial/Makefile |1 + > drivers/serial/serial.c |2 + > drivers/serial/serial_tegra2.c| 77 ++ > drivers/serial/serial_tegra2.h| 29 + > include/configs/aspenite.h|8 + > include/configs/dkb.h | 65 ++ > include/configs/harmony.h | 49 + > include/configs/mv-common.h | 147 +--- > include/configs/mx31pdk.h |7 + > include/configs/seaboard.h| 43 + > include/configs/tegra2-common.h | 160 +++ > include/serial.h |3 +- > nand_spl/board/freescale/mx31pdk/u-boot.lds | 59 +- > 52 files changed, 3968 insertions(+), 174 deletions(-) > create mode 100644 arch/arm/cpu/arm926ejs/pantheon/Makefile > create mode 100644 arch/arm/cpu/arm926ejs/pantheon/cpu.c > create mode 100644 arch/arm/cpu/arm926ejs/pantheon/dram.c > create mode 100644 arch/arm/cpu/arm926ejs/pantheon/timer.c > create mode 100644 arch/a
Re: [U-Boot] [PATCH 1/7] mpc85xx: Support a board-specific processor reset routines
On Feb 21, 2011, at 15:59, Wolfgang Denk wrote:
> In message <1298311199-18775-2-git-send-email-kyle.d.moff...@boeing.com> you
> wrote:
>> Some board models (such as the submitted P2020-based HWW-1U-1A hardware)
>> need specialized code to run when a reset is requested to ensure proper
>> synchronization with other hardware.
>>
>> In order to facilitate such board ports, we add a board_reset_r()
>> routine which is called from the do_reset() command function instead of
>> directly poking at the MPC85xx "RSTCR" (reset control) register.
>>
>> Signed-off-by: Kyle Moffett
>> ---
>> arch/powerpc/cpu/mpc85xx/cpu.c |7 +--
>> 1 files changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c b/arch/powerpc/cpu/mpc85xx/cpu.c
>> index 1aad2ba..dbc662f 100644
>> --- a/arch/powerpc/cpu/mpc85xx/cpu.c
>> +++ b/arch/powerpc/cpu/mpc85xx/cpu.c
>> @@ -204,8 +204,10 @@ int checkcpu (void)
>>
>> int do_reset (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
>> {
>> -/* Everything after the first generation of PQ3 parts has RSTCR */
>> -#if defined(CONFIG_MPC8540) || defined(CONFIG_MPC8541) || \
>> +#if defined(CONFIG_BOARD_RESET_R)
>> +extern void board_reset_r(void);
>> +board_reset_r();
>> +#elif defined(CONFIG_MPC8540) || defined(CONFIG_MPC8541) || \
>> defined(CONFIG_MPC8555) || defined(CONFIG_MPC8560)
>> unsigned long val, msr;
>
> Please implement without #ifdef's using a weak function - see
> arch/powerpc/cpu/mpc86xx/cpu.c for an example. Actually you might
> want to facto this out into common code.
>
> Side note: don't use ever "extern" function declarations in the code;
> use proper prototype declarations in some header file instead.
Hmm, ok. I thought that looked kind of funny but I copied it from somewhere
else in U-Boot so I figured it was fine.
I'll see if I can't come up with something a little more generic, otherwise
I'll use the weak function approach.
>> @@ -221,6 +223,7 @@ int do_reset (cmd_tbl_t *cmdtp, int flag, int argc, char
>> * const argv[])
>> val |= 0x7000;
>> mtspr(DBCR0,val);
>> #else
>> +/* Everything after the first generation of PQ3 parts has RSTCR */
>> volatile ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
>
> Note that this declaration is now basicy in the middle of code, which
> is ugly at best.
>
> What is the "volatile" needed for?
It was always in the middle of code, I just moved the comment. I also didn't
add the volatile, and I have no idea why anybody thought it was needed in the
first place.
I'll fix it in v4. Thanks!
Cheers,
Kyle Moffett
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/7] mpc8xxx: DDR2/3: Use human-readable SPD DIMM-type constants
On Feb 21, 2011, at 16:03, Wolfgang Denk wrote: > In message <1298311199-18775-3-git-send-email-kyle.d.moff...@boeing.com> you > wrote: >> Use #define constants to enhance readability of DDR2/3 SPD parsing code. >> Also add the DDR2 type for an SO-RDIMM module to the switch statement. >> >> Signed-off-by: Kyle Moffett >> --- >> arch/powerpc/cpu/mpc8xxx/ddr/ddr2_dimm_params.c | 34 +++-- >> arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c | 37 >> ++- >> common/ddr_spd.c|2 +- >> include/ddr_spd.h | 28 - >> 4 files changed, 60 insertions(+), 41 deletions(-) > ... >> +case DDR3_SPD_MODULETYPE_UDIMM: >> +case DDR3_SPD_MODULETYPE_SO_DIMM: >> +case DDR3_SPD_MODULETYPE_MICRO_DIMM: >> +case DDR3_SPD_MODULETYPE_MINI_UDIMM: >> +/* Unbuffered DIMMs */ >> +pdimm->registered_dimm = 0; >> +pdimm->mirrored_dimm = spd->mod_section.unbuffered.addr_mapping >> & 0x1; >> break; > > Line too long. Please fix globally. Ok, will fix. Although, this one is only 87 characters and some of the other lines already in that file are 93 characters long. Cheers, Kyle Moffett smime.p7s Description: S/MIME cryptographic signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] MX5:MX53: support for freescale MX53LOCO board
Hi Jason, --- On Mon, 2/21/11, Liu Hui-R64343 wrote: ... > >> +# (C Copyright 2009 > >> +# Stefano Babic DENX Software Engineering sba...@denx.de. > >> +# (C Copyright 2011 > >> +# Jason Liu Freescale Software Engineering r64...@freescale.com > > > >Why don´t you use the standard Freescale copyright > header here instead? > > Do you think it's a must to do it here? I think we never use the term ´Freescale Software Engineering´, so I was suggesting you to keep consistency with what is more commonly used as Freescale copyright header. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] mpc85xx: Add inline GPIO acessor functions
On Feb 21, 2011, at 16:14, Wolfgang Denk wrote:
> In message <1298311199-18775-4-git-send-email-kyle.d.moff...@boeing.com> you
> wrote:
>> To ease the implementation of other MPC85xx board ports, several common
>> GPIO helpers are added to .
>
> In which way is this specific to 85xx? Why not make available on a
> wider base?
This particular set of registers is a particular part of the MPC85xx-series SOC.
The other boards based on mpc85xx seem to just do stuff like this:
volatile ccsr_gpio_t *pgpio = (void *)(CONFIG_SYS_MPC85xx_GPIO_ADDR);
[...]
in_be32(&pgpio->gpdat);
[...]
out_be32(&pgpio->gpdat, newdat);
[...]
I thought that was kind of ugly and abstracted it out into static inline
functions in my board-specific header. Last time this was posted for review it
was pointed out that they are generally applicable to all MPC85xx chips ans so
I moved them to a more-generic header for other MPC85xx boards to use.
>> To assist other board ports, a small set of wrappers are used which
>> provides a standard gpio_request() interface around the MPC85xx-specific
>> functions. This can be enabled with CONFIG_MPC85XX_GENERIC_GPIO
>
> How similar is this interface with other "generic" GPIO interfaces we
> have here in U-Boot (and in Linux) ?
The interface emulates the "generic" GPIO API in Linux because Peter Tyser
indicated he would use that generic interface for his other MPC85xx board ports
if it was available. I don't actually use that particular API though; it isn't
really suitable to my board-support code and I'd rather delete it than try to
extend it further.
>> +static inline void mpc85xx_gpio_set(unsigned int mask,
>> +unsigned int dir, unsigned int val)
>> +{
>> +volatile ccsr_gpio_t *gpio;
>> +
>> +/* First mask off the unwanted parts of "dir" and "val" */
>> +dir &= mask;
>> +val &= mask;
>> +
>> +/* Now read in the values we're supposed to preserve */
>> +gpio = (void *)(CONFIG_SYS_MPC85xx_GPIO_ADDR + 0xc00);
>> +dir |= (in_be32(&gpio->gpdir) & ~mask);
>> +val |= (in_be32(&gpio->gpdat) & ~mask);
>> +
>> +/* Now write out the new values, writing the direction first */
>> +out_be32(&gpio->gpdir, dir);
>
> This way work, but quite often is wrong. If you set the direction
> first for an output, you start driving the old value, before you set
> the correct one. This results in a short pulse that may cause
> negative side effects.
>
> Don't!
Whoops, I did get that completely backwards! I was very carefully trying to
ensure a clean transition and managed to swap it :-(.
Will fix, thanks for noticing!
>> +asm("sync; isync":::"memory");
>
> Why would that be needed? out_be32() is supposed to provide sufficient
> memory barriers.
Again, I was just cribbing from some of the other board ports. If in_be32()
and out_be32() are defined to provide enough barriers then I'll remove it.
>> +static inline unsigned int mpc85xx_gpio_get(unsigned int mask)
>> +{
>> +volatile ccsr_gpio_t *gpio;
>
> Why would this volatile be needed here? [Please fix globally.]
As above this was copied from other MPC85xx boards, will fix.
>> +#ifdef CONFIG_MPC85XX_GENERIC_GPIO
>> +static inline int gpio_request(unsigned gpio, const char *label)
>> +{
>> +/* Do nothing */
>> +(void)gpio;
>> +(void)label;
>
> NAK. Please don't do that. Fix globally.
>
>> +static inline int gpio_direction_input(unsigned gpio)
>> +{
>> +mpc85xx_gpio_set_in(1U << gpio);
>> +return 0;
>> +}
>
> Why is this function not void when it cannot return any usefult return
> code anyway?
>
>> +static inline int gpio_direction_output(unsigned gpio, int value)
>> +{
>> +mpc85xx_gpio_set_low(1U << gpio);
>> +return 0;
>> +}
>
> Ditto.
This is the "Linux-compatible" gpio layer that Peter Tyser was asking for. I
sort-of-copied most of these functions from arch/nios2/include/asm/gpio.h,
which just does the "return 0;" in several functions.
Those 2 later functions are expected to be able to return an error (for I2C
chips and such). As I said above, if these wrappers are unacceptable then I
will just delete them; the only thing I use are the mpc85xx_gpio_*() functions.
Thanks for the review!
Cheers,
Kyle Moffett
smime.p7s
Description: S/MIME cryptographic signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] mpc85xx: Add board support for the eXMeritus HWW-1U-1A devices
Dear "Moffett, Kyle D", In message <475ab4e4-f287-44e3-8a16-213506955...@boeing.com> you wrote: > ... > >> +U_BOOT_CMD( > >> + hww1u1a_is_cpu_a, 1, 0, do_hww1u1a_is_cpu_a, > >> + "Test if this is CPU A (versus B) on the eXMeritus HWW-1U-1A board", > >> + /* */" && echo This is CPU A\n" > >> + "if hww1u1a_is_cpu_a; then\n" > >> + "## Do stuff\n" > >> + "else\n" > >> + "## Do other stuff\n" > >> + "fi" > > > > Please don't misuse the help messages like that. Use external > > documentation instead. > > Ok, is just " && echo This is CPU A\n" OK? I'm trying to show possible > usage of the command and it has no actual arguments or output on its own. No, usage documentation is not supposed to be found here. We just provide the synopsis. > >> + out_be32(&ddr->cs0_bnds,0x003F); > >> + out_be32(&ddr->cs1_bnds,0x0040007F); > >> + out_be32(&ddr->cs0_config, 0x80014202); > >> + out_be32(&ddr->cs1_config, 0x80014202); > >> + out_be32(&ddr->timing_cfg_0,0x00330804); > >> + out_be32(&ddr->timing_cfg_1,0x6f69f643); > >> + out_be32(&ddr->timing_cfg_2,0x022068cd); > >> + out_be32(&ddr->timing_cfg_3,0x0003); > >> + out_be32(&ddr->sdram_cfg_2, 0x04400010); > >> + out_be32(&ddr->sdram_mode, 0x00440452); > >> + out_be32(&ddr->sdram_mode_2,0x); > >> + out_be32(&ddr->sdram_md_cntl, 0x); > >> + out_be32(&ddr->sdram_interval, 0x0a280110); > >> + out_be32(&ddr->sdram_data_init, 0xDEADBEEF); > >> + out_be32(&ddr->sdram_clk_cntl, 0x0200); > >> + out_be32(&ddr->timing_cfg_4,0x); > >> + out_be32(&ddr->timing_cfg_5,0x); > >> + out_be32(&ddr->ddr_zq_cntl, 0x); > >> + out_be32(&ddr->ddr_wrlvl_cntl, 0x); > >> + out_be32(&ddr->ip_rev1, 0x00020403); > >> + out_be32(&ddr->ip_rev2, 0x0100); > >> + out_be32(&ddr->err_int_en, 0x000D); > >> + out_be32(&ddr->err_disable, 0x); > >> + out_be32(&ddr->err_sbe, 0x0001); > >> + out_be32(&ddr->ddr_cdr1,0x0004); > >> + out_be32(&ddr->ddr_cdr2,0x); > >> + out_be32(&ddr->sdram_cfg, 0x7300); > >> + udelay(500); > >> + out_be32(&ddr->sdram_cfg, 0xF300); > >> + > >> + /* Now wait until memory is initialized */ > >> + while (in_be32(&ddr->sdram_cfg_2) & 0x0010) > >> + udelay(1000); > > > > Please avoid all these magic constants and use symbolic names instead > > like other boards are doing. ... > I only use this code for debugging so if the numeric constants are > completely unacceptable I will just delete it rather than try to rewrite > it to make everybody happy. If you prefer so... > >> > +/> > >> + * High-level system configuration options > >> > * > >> + > > >> / > > > > Incorrect multiline comment style. Please fix globally. > > Hmm, the intent was to group config options into "sections" of a sort > (such as I2C, PCI, networking, etc). > > Is there a better syntax for me to use or am I not allowed to do that? Use two blank lines as block separator? > > Please remove the "1" for all macros that are actually used with > > "#ifdef"s. Please fix globally. > > I added all of the "1"s after I experienced random build breakage from a > couple config variables being "#ifdef" in one place and "#if" in > another. Is there a convenient list somewhere of which should be which? Such code should be fixed. Do you remember where this was? Sorry, I don;t have such a list, but in generall all "features" are only "ifdef"; only where a numeric value is really needed (like UART index or similar) a "#define name number" makes sense. > > If you write such constants as "(128 << 10)", "(512 << 20)" resp. > > "(64 << 10)" they may become better readable. > > > >> + > > >> / > >> +#define CONFIG_ENV_SIZE 0x02000 /* 8kB */ > >> +#define CONFIG_ENV_SIZE_REDUND0x02000 /* 8kB */ > > > > Ditto. > > This was also copied from P2020DS. > These are address-space sizes next to the actual base addresses, so I > would rather leave them in this form to make them easier to correlate > against the base addresses. I cannot really follow this argument, but I don't have to maintain that code so I don't insist. > Also, the environment sector size (with comment about flash sector) > makes it much more obvious that 0xefff6000 specified later on is exactly > one sector prior to the 0xefff8000 base address of the U-Boot image. As it is not really obvious that the difference of a sector sice is not just a coincidence you could improve readability by using #define CONFIG_ENV_ADDR (CONFIG_SYS_TEXT_BASE - CONFIG_ENV_SECT_SIZE) #define CONFIG_ENV_ADDR_REDUND (CONFIG_ENV_ADDR - CONFIG_ENV
Re: [U-Boot] [PATCH 1/1] MX5:MX53: support for freescale MX53LOCO board
Hi Jason, --- On Mon, 2/21/11, Jason Liu wrote: ... > --- /dev/null > +++ b/board/freescale/mx53loco/imximage.cfg > @@ -0,0 +1,99 @@ > +# > +# (C Copyright 2009 > +# Stefano Babic DENX Software Engineering sba...@denx.de. > +# (C Copyright 2011 > +# Jason Liu Freescale Software Engineering r64...@freescale.com Why don´t you use the standard Freescale copyright header here instead? Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] MX5:MX53: support for freescale MX53LOCO board
Hi, Stefano, >-Original Message- >From: Stefano Babic [mailto:sba...@denx.de] >Sent: Monday, February 21, 2011 8:46 PM >To: Liu Hui-R64343 >Cc: u-boot@lists.denx.de; sba...@denx.de >Subject: Re: [U-Boot][PATCH 1/1] MX5:MX53: support for freescale MX53LOCO >board > >On 02/21/2011 11:15 AM, Jason Liu wrote: > >Hi Jason, > > >> >+ ># >> + >> diff --git a/board/freescale/mx53loco/config.mk >> b/board/freescale/mx53loco/config.mk >> new file mode 100644 >> index 000..ec0c66c > >As I discovered myself, usage of config.mk is discouraged and it should be >removed and it is not accepted anymore for new boards. Instead of that, it is >possible to add CONFIG_ options in boards.cfg. OK, do you know why config.mk is discouraged? > >I have already sent changes for imx51evk, as example for the imx5 boards. >However, I sent them when window was already closed, and I merged them >on the next branch of u-boot-imx. You will find these patches in archive also >as: Can I based on next of u-boot-imx to submit new patches since master branch Of uboot does not have it? > >[PATCH 1/2] Makefile: change rule to build IMX image [PATCH 2/2] MX51: >drop config.mk from mx51evk > >You can take a look at them to see how to drop the config.mk file. OK, thanks for the information. I will look at it and check my new version patch. > >Best regards, >Stefano Babic > >-- >= > >DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel >HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany >Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de >= > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] MX5:MX53: support for freescale MX53LOCO board
Hi, Fabio, >-Original Message- >From: Fabio Estevam [mailto:fabioeste...@yahoo.com] >Sent: Tuesday, February 22, 2011 7:38 AM >To: u-boot@lists.denx.de; Liu Hui-R64343 >Subject: Re: [U-Boot] [PATCH 1/1] MX5:MX53: support for freescale >MX53LOCO board > >Hi Jason, > >--- On Mon, 2/21/11, Jason Liu wrote: >... >> --- /dev/null >> +++ b/board/freescale/mx53loco/imximage.cfg >> @@ -0,0 +1,99 @@ >> +# >> +# (C Copyright 2009 >> +# Stefano Babic DENX Software Engineering sba...@denx.de. >> +# (C Copyright 2011 >> +# Jason Liu Freescale Software Engineering r64...@freescale.com > >Why don´t you use the standard Freescale copyright header here instead? Do you think it's a must to do it here? > >Regards, > >Fabio Estevam > > > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] ARM: Update mach types
Hi, Fabio, Best Regards, Jason Liu >-Original Message- >From: Fabio Estevam [mailto:fabioeste...@yahoo.com] >Sent: Tuesday, February 22, 2011 1:36 AM >To: u-boot@lists.denx.de; Liu Hui-R64343 >Subject: Re: [U-Boot] [PATCH 1/1] ARM: Update mach types > >Hi Jason, > >--- On Mon, 2/21/11, Jason Liu wrote: > >> From: Jason Liu >> Subject: [U-Boot] [PATCH 1/1] ARM: Update mach types >> To: u-boot@lists.denx.de >> Date: Monday, February 21, 2011, 8:14 AM This commit updates the >> mach-types to sync with ARM Linux based on the following commit by >> Russell King commit 4a683a2c5e7cabe91218db28e56dc25e1b134ce3 >> >> Signed-off-by: Jason Liu >> --- >> arch/arm/include/asm/mach-types.h | 1293 >> - >> 1 files changed, 1277 insertions(+), 16 deletions(-) > >The machine update patch is already in U-boot ARM tree: >http://git.denx.de/?p=u-boot/u-boot- >arm.git;a=commitdiff;h=c7977858dcf1f656cbe91ea0dc3cb9139c6a8cc8 Yes, I just see it now but not when I submit patches. > >Regards, > >Fabio Estevam > > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] OMAP3 Beagle Pin Mux initialization issue
The BeagleBoard beagle.c file contains: 242 /* Configure GPIOs to output */ 243 writel(~(GPIO23 | GPIO10 | GPIO8 | GPIO2 | GPIO1), &gpio6_base->oe); 244 writel(~(GPIO31 | GPIO30 | GPIO29 | GPIO28 | GPIO22 | GPIO21 | 245 GPIO15 | GPIO14 | GPIO13 | GPIO12), &gpio5_base->oe); 246 247 /* Set GPIOs */ 248 writel(GPIO23 | GPIO10 | GPIO8 | GPIO2 | GPIO1, 249 &gpio6_base->setdataout); 250 writel(GPIO31 | GPIO30 | GPIO29 | GPIO28 | GPIO22 | GPIO21 | 251 GPIO15 | GPIO14 | GPIO13 | GPIO12, &gpio5_base->setdataout); It first sets some pins as outputs and then initializes their values. This can cause narrow glitches on the output pins. To prevent the glitches the order should be reversed. First Set the GPIOs, then Configure them as outputs. Also, I have observed the discussion regarding moving Pin Mux control to the kernel. This is fine except for pins that need to be configured ASAP after power-on. (The system could sit at the u-boot command prompt indefinitely, so the kernel pin mux configuration can be significantly delayed.). Please leave the hook so that u-boot customizers can configure their critical pins muxes. Regards, Bob Feretich ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] MX5:MX53: support for freescale MX53LOCO board
Dear Liu Hui-R64343, In message <2cf7613b9822a943bef13ef7acec5bd114a...@039-sn1mpn1-003.039d.mgd.msft.net> you wrote: > > >As I discovered myself, usage of config.mk is discouraged and it should be > >removed and it is not accepted anymore for new boards. Instead of that, it is > >possible to add CONFIG_ options in boards.cfg. > > OK, do you know why config.mk is discouraged? There are seeral reasons, the most prominent being 1) because it's simply not needed in 95% of all cases 2) because it's bad to distribute vital configuration information into several independent files and 3) because we're preparing the grounds for a Kconfig based setup so we want to have all config options controlled by a single mechanism (board config file). 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 1/1] MX5:MX53: support for freescale MX53LOCO board
Dear Liu Hui-R64343, In message <2cf7613b9822a943bef13ef7acec5bd114a...@039-sn1mpn1-003.039d.mgd.msft.net> you wrote: > > >> +# (C Copyright 2011 > >> +# Jason Liu Freescale Software Engineering r64...@freescale.com > > > >Why don´t you use the standard Freescale copyright header here instead? > > Do you think it's a must to do it here? Your manager at Freescale probably wants it. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The IQ of the group is the lowest IQ of a member of the group divided by the number of people in the group. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Fix variable flavor in examples/standalone/Makefile
GNU Makefile have two flavors of variables, recursively expanded that is defined by using '=', and simply expanded that is defined by using ':='. The bug is caused by using recursively expanded flavor for BIN and SREC. As you can see below, they are prepended by $(obj) twice. We can reproduce this bug with a simplified version of this Makefile: $ cat > Makefile < --- examples/standalone/Makefile |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/examples/standalone/Makefile b/examples/standalone/Makefile index c1dfdce..6fd9f5d 100644 --- a/examples/standalone/Makefile +++ b/examples/standalone/Makefile @@ -45,8 +45,8 @@ ELF-oxc += eepro100_eeprom # ELF := $(strip $(ELF-y) $(ELF-$(ARCH)) $(ELF-$(BOARD)) $(ELF-$(CPU))) -SREC = $(addsuffix .srec,$(ELF)) -BIN = $(addsuffix .bin,$(ELF)) +SREC := $(addsuffix .srec,$(ELF)) +BIN := $(addsuffix .bin,$(ELF)) COBJS := $(ELF:=.o) -- 1.7.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP3 Beagle Pin Mux initialization issue
Dear Bob Feretich, In message <4d6316a8.4090...@prodigy.net> you wrote: > The BeagleBoard beagle.c file contains: > 242 /* Configure GPIOs to output */ > 243 writel(~(GPIO23 | GPIO10 | GPIO8 | GPIO2 | GPIO1), > &gpio6_base->oe); > 244 writel(~(GPIO31 | GPIO30 | GPIO29 | GPIO28 | GPIO22 | GPIO21 | > 245 GPIO15 | GPIO14 | GPIO13 | GPIO12), &gpio5_base->oe); > 246 > 247 /* Set GPIOs */ > 248 writel(GPIO23 | GPIO10 | GPIO8 | GPIO2 | GPIO1, > 249 &gpio6_base->setdataout); > 250 writel(GPIO31 | GPIO30 | GPIO29 | GPIO28 | GPIO22 | GPIO21 | > 251 GPIO15 | GPIO14 | GPIO13 | GPIO12, > &gpio5_base->setdataout); > > It first sets some pins as outputs and then initializes their values. > This can cause narrow glitches on the output pins. > > To prevent the glitches the order should be reversed. First Set the > GPIOs, then Configure them as outputs. You are right. Can you please submit a patch? For instructions please see http://www.denx.de/wiki/U-Boot/Patches > Also, I have observed the discussion regarding moving Pin Mux control to > the kernel. This is fine except for pins that need to be configured ASAP > after power-on. (The system could sit at the u-boot command prompt > indefinitely, so the kernel pin mux configuration can be significantly > delayed.). Please leave the hook so that u-boot customizers can > configure their critical pins muxes. Which pins would that be, for example? 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 But the only way of discovering the limits of the possible is to venture a little way past them into the impossible. - _Profiles of the Future_ (1962; rev. 1973) ``Hazards of Prophecy: The Failure of Imagination'' ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix variable flavor in examples/standalone/Makefile
Dear Che-liang Chiou, In message you wrote: > GNU Makefile have two flavors of variables, recursively expanded that is > defined by using '=', and simply expanded that is defined by using ':='. > > The bug is caused by using recursively expanded flavor for BIN and SREC. You wrote "The bug". How does this bug manifest in U-Boot? For which configuration do you see issues? 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 "Anyone attempting to generate random numbers by deterministic means is, of course, living in a state of sin." - John Von Neumann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
