Re: [U-Boot] [PATCH v3 1/3] NAND boot: MPC8536DS support
-Original Message-
From: Kumar Gala [mailto:ga...@kernel.crashing.org]
Sent: Saturday, September 19, 2009 2:42 AM
To: Hu Mingkai-B21284
Cc: u-boot@lists.denx.de; Wood Scott-B07421
Subject: Re: [PATCH v3 1/3] NAND boot: MPC8536DS support
+
+#include common.h
+#include asm/io.h
+
+void cpu_init_f(void)
+{
+ ccsr_lbc_t *lbc = (void *)(CONFIG_SYS_MPC85xx_LBC_ADDR);
+
+ /*
+* LCRR - Clock Ratio Register - set up local bus timing
+* when needed
+*/
+ out_be32(lbc-lcrr, LCRR_DBYP | LCRR_CLKDIV_8);
+
+#if defined(CONFIG_NAND_BR_PRELIM) \
+defined(CONFIG_NAND_OR_PRELIM)
+ out_be32(lbc-br0, CONFIG_NAND_BR_PRELIM);
+ out_be32(lbc-or0, CONFIG_NAND_OR_PRELIM);
+ /* for FPGA */
+ out_be32(lbc-br3, CONFIG_SYS_BR3_PRELIM);
+ out_be32(lbc-or3, CONFIG_SYS_OR3_PRELIM); #else #error
+CONFIG_NAND_BR_PRELIM, CONFIG_NAND_OR_PRELIM must be defined #endif
+
Should we not have br/or1, br/or2, etc?
In order to boot from NAND, it should be connected on br/or0, so we
don't care br/or1, br/or2.
The br/or3 shoud be moved to board specific file nand_boot.c, as dave
pointed, owing to different
connection between the different borads.
Thanks,
Mingkai
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/3] NAND boot: MPC8536DS support
-Original Message-
From: Wood Scott-B07421
Sent: Saturday, September 19, 2009 12:37 AM
To: Hu Mingkai-B21284
Cc: u-boot@lists.denx.de; ga...@kernel.crashing.org
Subject: Re: [PATCH v3 1/3] NAND boot: MPC8536DS support
On Fri, Sep 18, 2009 at 11:35:33AM +0800, Mingkai Hu wrote:
diff --git a/Makefile b/Makefile
index 99837a3..4d18a9f 100644
--- a/Makefile
+++ b/Makefile
@@ -2446,6 +2446,7 @@ vme8349_config: unconfig
ATUM8548_config: unconfig
@$(MKCONFIG) $(@:_config=) ppc mpc85xx atum8548
+MPC8536DS_NAND_config \
MPC8536DS_36BIT_config \
MPC8536DS_config: unconfig
NAND and 36BIT are orthogonal.
How about changing it to:
# Options: NAND, 36BIT
MPC8536DS_%_config MPC8536DS_config: unconfig
I don't get it. what's the '%'? or how to use it?
+#if defined(CONFIG_NAND_BR_PRELIM) \
+defined(CONFIG_NAND_OR_PRELIM)
+ out_be32(lbc-br0, CONFIG_NAND_BR_PRELIM);
+ out_be32(lbc-or0, CONFIG_NAND_OR_PRELIM);
+ /* for FPGA */
+ out_be32(lbc-br3, CONFIG_SYS_BR3_PRELIM);
+ out_be32(lbc-or3, CONFIG_SYS_OR3_PRELIM);
Those last two lines should probably be #ifdef CONFIG_SYS_BR3_PRELIM.
Ok.
+#if defined(CONFIG_SYS_RAMBOOT) defined(CONFIG_SYS_INIT_L2_ADDR)
+ ccsr_l2cache_t *l2cache = (void *)CONFIG_SYS_MPC85xx_L2_ADDR;
+ uint l2srbar;
+ int i;
+
+ l2srbar = CONFIG_SYS_INIT_L2_ADDR;
+ out_be32(l2cache-l2srbar0, l2srbar);
+
+ /* set MBECCDIS=1, SBECCDIS=1 */
+ out_be32(l2cache-l2errdis,
+ (MPC85xx_L2ERRDIS_MBECC |
+MPC85xx_L2ERRDIS_SBECC));
+
+ /* set L2E=1 L2SRAM=001 */
+ out_be32(l2cache-l2ctl,
+ (MPC85xx_L2CTL_L2E |
+MPC85xx_L2CTL_L2SRAM_ENTIRE));
+
+ /* Initialize L2 SRAM to zero */
+ for (i = 0; i CONFIG_SYS_L2_SIZE; i++)
+ ((char *)l2srbar)[i] = 0;
uint is not a valid type for either virtual or physical addresses.
Use a pointer (or uintptr_t if you must) for the former, and
phys_addr_t for the latter.
You're using it as char *, so why not just declare it that way?
Ok, change to char *.
+void board_init_f(ulong bootflag)
+{
+ u8 sysclk_ratio;
You're not saving any space over plain int/uint...
+ uint plat_ratio, bus_clk, sys_clk;
+ volatile ccsr_gur_t *gur = (void
*)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
+
+ /* initialize selected port with appropriate baud rate */
+ sysclk_ratio = *((volatile unsigned char *)(PIXIS_BASE
+ PIXIS_SPD));
+ sysclk_ratio = 0x7;
+ switch (sysclk_ratio) {
+ case 0:
+ sys_clk = 3000;
+ break;
+ case 1:
+ sys_clk = 3600;
+ break;
+ case 2:
+ sys_clk = 4500;
+ break;
+ case 3:
+ sys_clk = 6000;
+ break;
+ case 4:
+ sys_clk = 83332500;
+ break;
+ case 5:
+ sys_clk = 9000;
+ break;
+ case 6:
+ sys_clk = 12000;
+ break;
+ case 7:
+ sys_clk = 15000;
+ break;
+ default:
+ sys_clk = 0;
This default: case is impossible to reach.
+ break;
+ }
We could save some space by putting this in a table.
+ plat_ratio = (gur-porpllsr) 0x003e;
Unnecessary parens.
+ plat_ratio = 1;
plat_ratio /= 2 is more readable and should generate identical code.
Reshaped this function(board_init_f) by table-driven method.
Thanks,
Mingkai
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Warning Bad CRC
Hi All, I am getting a warning message when i run fw_printenv on board. Warning : Bad CRC!! Using Default Environment. And it showed Few environment variables. The values of those environment variables are not that is set on my board. What might me the issue? Thanks Rahanesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand_scan() in ARM9 S3C2410
Dear J.Hwan.Kim 2009/9/20 J.Hwan.Kim frog1...@gmail.com: Hi, everyone I'm using u-boot for ARM9 S3C2410. My tool chain is ELDK4.2. I defined configuration CONFIG_NAND_CMD, CONFIG_SYS_MAX_NAND_DEVICE 1, and CONFIG_SYS_NAND_BASE 0x4E0C for nand_init(). It works well until the routine reaches nand_scan() which is in nand_base.c When nand_scan() is called, the system hangs. For test, When I written dummy function is nand_base.c and called the dummy function from nand.c, the system is down. My u-boot is using relocation to SDRAM from NAND. The address of nand_scan() is 0x31F85894. (TEXT_BASE is 0x31F8 and SDRAM start from 0x3000) I'm sured that the binary data of u-boot.bin (address 0x5894) is same with SDRAM data in 0x31F85894. I think the relocation is OK. When I attached the routines of nand_base.c to nand.c, the nand_scan() function passed. Is there any hint for this problem? Thanks in advnace. Regards, J.Hwan Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Did you check the kevin's mail? He said u-boot for s3c2410 doesn't support. http://lists.denx.de/pipermail/u-boot/2009-September/060855.html And I think.. you can trace nand_scan() step by step. please try it and do more detailed question. Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand_scan() in ARM9 S3C2410
Minkyu Kang wrote: Dear J.Hwan.Kim 2009/9/20 J.Hwan.Kim frog1...@gmail.com: Hi, everyone I'm using u-boot for ARM9 S3C2410. My tool chain is ELDK4.2. I defined configuration CONFIG_NAND_CMD, CONFIG_SYS_MAX_NAND_DEVICE1, and CONFIG_SYS_NAND_BASE 0x4E0C for nand_init(). It works well until the routine reaches nand_scan() which is in nand_base.c When nand_scan() is called, the system hangs. For test, When I written dummy function is nand_base.c and called the dummy function from nand.c, the system is down. My u-boot is using relocation to SDRAM from NAND. The address of nand_scan() is 0x31F85894. (TEXT_BASE is 0x31F8 and SDRAM start from 0x3000) I'm sured that the binary data of u-boot.bin (address 0x5894) is same with SDRAM data in 0x31F85894. I think the relocation is OK. When I attached the routines of nand_base.c to nand.c, the nand_scan() function passed. Is there any hint for this problem? Thanks in advnace. Regards, J.Hwan Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Did you check the kevin's mail? He said u-boot for s3c2410 doesn't support. http://lists.denx.de/pipermail/u-boot/2009-September/060855.html u-boot for s3c2410 doesn't support booting from NAND flash, but assuming you boot from NOR flash and have NAND enabled properly in the board config file it does support the use of NAND flash. In the NAND config you show in your email, it's probably a typo but it should be CONFIG_CMD_NAND not CONFIG_NAND_CMD. If that's not the problem - I'm not sure what board you're using. If you're using an existing config file post the name of it, or if you're using one you've created post the board config file itself. Regards Kevin Morfitt And I think.. you can trace nand_scan() step by step. please try it and do more detailed question. Thanks Minkyu Kang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] MAKEALL: Add summary information
Dear Peter Tyser, In message 1253489072.27060.51.ca...@ptyser-laptop you wrote: - JOBS=-j`expr $BUILD_NCPUS + 1` + JOBS=-j $(($BUILD_NCPUS + 1)) ... This is an unrelated change. I would not include it with this patch. Mike mentioned using POSIX math in the new arithmetic functions I added, which makes sense. I reasoned it was better to convert the 1 other reference to 'expr + 1' to the same POSIX style for consistency's sake. Changing 1 'expr + 1' reference to $((+ 1)) doesn't seem worth its own commit, so I rolled it into this patch. How about I just add a sentence to the commit message stating that I also converted math operations to be POSIX compliant? It's still an unrelated change. Please do this in a separate patch (probably before adding your other changes). 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 More software projects have gone awry for lack of calendar time than for all other causes combined. - Fred Brooks, Jr., _The Mythical Man Month_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] MAKEALL: Add summary information
Dear Peter Tyser, In message 1253489996.27060.60.ca...@ptyser-laptop you wrote: +# Print statistics when ctrl-c is pressed +trap print_stats; exit 2 Why only on signal 2? Usually we use 1 2 3 15 in such cases. 2's the only case I've ever used for MAKEALL, I'll add the other cases as you suggest. Thanks. I didn't trap 0 because I wasn't aware of a quick way to only call print_stats once when ctrl-c was pressed (eg trapping 0 and 2 would result in 2 print_stats calls with the current code). Let me know if there's a standard way to workaround this. I would probably use something like this: trap exit 1 2 3 15 trap print_stats 0 Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Quotation, n. The act of repeating erroneously the words of another. The words erroneously repeated. - Ambrose Bierce _The Devil's Dictionary_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Warning Bad CRC
Dear Rahanesh, In message 4ab72177.7090...@tataelxsi.co.in you wrote: I am getting a warning message when i run fw_printenv on board. Warning : Bad CRC!! Using Default Environment. And it showed Few environment variables. The values of those environment variables are not that is set on my board. What might me the issue? I thiunk this has been explained to you before: your fw_env.config file is incorrect and does not match your actual hardware configuration. 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 Madness has no purpose. Or reason. But it may have a goal. -- Spock, The Alternative Factor, stardate 3088.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] sbc8548: use I/O accessors
Dear Graeme Russ, In message d66caabb0909201837g28da0ed5k6069e96775cfb...@mail.gmail.com you wrote: - ecm-eedr = 0x; /* clear ecm errors */ - ecm-eeer = 0x; /* enable ecm errors */ + out_be32(ecm-eedr, 0x); /* clear ecm errors */ + out_be32(ecm-eeer, 0x); /* enable ecm errors */ return 0; Correct me if I'm wrong, but I thought the general rule was the other way (i.e. the way it alreay was). See for example: You are wrong. We must use I/O accessors. http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commit;h=ed7a1b681de1e31d18d5b92e2767ae8df3241687 Ouch. This patch is clearly bloken. Sorry it escaped my attention. Using a C structure to describe the hardware is a good thing, but we still must use I/O accessors to access the registers. This needs to be fixed in your code. This prevents, for example, accidentally writing words and longs to byte sized registers. Right. The I/O accessors still allow for strict type checking. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de What is wanted is not the will to believe, but the will to find out, which is the exact opposite. - Bertrand Russell, _Sceptical_Essays_, 1928 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] sbc8548: use I/O accessors
On Mon, Sep 21, 2009 at 6:48 PM, Wolfgang Denk w...@denx.de wrote: Dear Graeme Russ, In message d66caabb0909201837g28da0ed5k6069e96775cfb...@mail.gmail.com you wrote: - ecm-eedr = 0x; /* clear ecm errors */ - ecm-eeer = 0x; /* enable ecm errors */ + out_be32(ecm-eedr, 0x); /* clear ecm errors */ + out_be32(ecm-eeer, 0x); /* enable ecm errors */ return 0; Correct me if I'm wrong, but I thought the general rule was the other way (i.e. the way it alreay was). See for example: You are wrong. We must use I/O accessors. Thanks for the correction :) http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commit;h=ed7a1b681de1e31d18d5b92e2767ae8df3241687 Ouch. This patch is clearly bloken. Sorry it escaped my attention. Hence my incorrect assumption ;) Using a C structure to describe the hardware is a good thing, but we still must use I/O accessors to access the registers. This needs to be fixed in your code. Will do This prevents, for example, accidentally writing words and longs to byte sized registers. Right. The I/O accessors still allow for strict type checking. Right, which still makes my patch better than the completely unchecked previous version of the SC520 MMCR accessors Regards, G ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net: phy: mv88e61xx.c : fixed build warning
following build warning was observed
mv88e61xx.c: In function ‘mv88e61xx_busychk’:
mv88e61xx.c:208: warning: dereferencing type-punned pointer will break
strict-aliasing rules
This patch fixes the same
Patch tested for rd6281a board build
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
drivers/net/phy/mv88e61xx.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/mv88e61xx.c b/drivers/net/phy/mv88e61xx.c
index 3754e8b..2d1de02 100644
--- a/drivers/net/phy/mv88e61xx.c
+++ b/drivers/net/phy/mv88e61xx.c
@@ -201,11 +201,11 @@ static void mv88e61xx_port_vlan_config(struct
mv88e61xx_config *swconfig,
*/
static int mv88e61xx_busychk(char *name)
{
- u32 reg = 0;
+ u16 reg = 0;
u32 timeout = MV88E61XX_PHY_TIMEOUT;
do {
RD_PHY(name, MV88E61XX_GLB2REG_DEVADR,
- MV88E61XX_PHY_CMD, (u16 *) reg);
+ MV88E61XX_PHY_CMD, reg);
if (timeout-- == 0) {
printf(SMI busy timeout\n);
return -1;
--
1.5.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Kirkwood: rd6281a: Add kwbimage build support
This patch adds kwbimage configuration file (used by mkimage utility) to support u-boot.kwb target on rd6281a platform. To create Kirkwood boot image to be flashed on NAND, additional parameter u-boot.kwb need to be passed during make. Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- board/Marvell/rd6281a/config.mk|3 + board/Marvell/rd6281a/kwbimage.cfg | 167 2 files changed, 170 insertions(+), 0 deletions(-) create mode 100644 board/Marvell/rd6281a/kwbimage.cfg diff --git a/board/Marvell/rd6281a/config.mk b/board/Marvell/rd6281a/config.mk index a4ea769..2bd9f79 100644 --- a/board/Marvell/rd6281a/config.mk +++ b/board/Marvell/rd6281a/config.mk @@ -23,3 +23,6 @@ # TEXT_BASE = 0x0060 + +# Kirkwood Boot Image configuration file +KWD_CONFIG = $(SRCTREE)/board/$(BOARDDIR)/kwbimage.cfg diff --git a/board/Marvell/rd6281a/kwbimage.cfg b/board/Marvell/rd6281a/kwbimage.cfg new file mode 100644 index 000..0d12dd9 --- /dev/null +++ b/board/Marvell/rd6281a/kwbimage.cfg @@ -0,0 +1,167 @@ +# +# (C) Copyright 2009 +# Marvell Semiconductor www.marvell.com +# Written-by: Prafulla Wadaskar prafu...@marvell.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.kwimage for more details about how-to configure +# and create kirkwood boot image +# + +# Boot Media configurations +BOOT_FROM nand +NAND_ECC_MODE default +NAND_PAGE_SIZE 0x0800 + +# SOC registers configuration using bootrom header extension +# Maximum KWBIMAGE_MAX_CONFIG configurations allowed + +# Configure RGMII-0 interface pad voltage to 1.8V +DATA 0xFFD100e0 0x1b1b1b9b + +#Dram initalization for SINGLE x16 CL=5 @ 400MHz +DATA 0xFFD01400 0x43000c30 # DDR Configuration register +# bit13-0: 0xc30 (3120 DDR2 clks refresh rate) +# bit23-14: zero +# bit24: 1= enable exit self refresh mode on DDR access +# bit25: 1 required +# bit29-26: zero +# bit31-30: 01 + +DATA 0xFFD01404 0x37543000 # DDR Controller Control Low +# bit 4:0=addr/cmd in smame cycle +# bit 5:0=clk is driven during self refresh, we don't care for APX +# bit 6:0=use recommended falling edge of clk for addr/cmd +# bit14:0=input buffer always powered up +# bit18:1=cpu lock transaction enabled +# bit23-20: 5=recommended value for CL=5 and STARTBURST_DEL disabled bit31=0 +# bit27-24: 7= CL+2, STARTBURST sample stages, for freqs 400MHz, unbuffered DIMM +# bit30-28: 3 required +# bit31:0=no additional STARTBURST delay + +DATA 0xFFD01408 0x22125451 # DDR Timing (Low) (active cycles value +1) +# bit3-0: TRAS lsbs +# bit7-4: TRCD +# bit11- 8: TRP +# bit15-12: TWR +# bit19-16: TWTR +# bit20:TRAS msb +# bit23-21: 0x0 +# bit27-24: TRRD +# bit31-28: TRTP + +DATA 0xFFD0140C 0x0a33 # DDR Timing (High) +# bit6-0: TRFC +# bit8-7: TR2R +# bit10-9: TR2W +# bit12-11: TW2W +# bit31-13: zero required + +DATA 0xFFD01410 0x0099 # DDR Address Control +# bit1-0: 00, Cs0width=x8 +# bit3-2: 11, Cs0size=1Gb +# bit5-4: 00, Cs1width=x8 +# bit7-6: 11, Cs1size=1Gb +# bit9-8: 00, Cs2width=nonexistent +# bit11-10: 00, Cs2size =nonexistent +# bit13-12: 00, Cs3width=nonexistent +# bit15-14: 00, Cs3size =nonexistent +# bit16:0, Cs0AddrSel +# bit17:0, Cs1AddrSel +# bit18:0, Cs2AddrSel +# bit19:0, Cs3AddrSel +# bit31-20: 0 required + +DATA 0xFFD01414 0x # DDR Open Pages Control +# bit0:0, OpenPage enabled +# bit31-1: 0 required + +DATA 0xFFD01418 0x # DDR Operation +# bit3-0: 0x0, DDR cmd +# bit31-4: 0 required + +DATA 0xFFD0141C 0x0C52 # DDR Mode +# bit2-0: 2, BurstLen=2 required +# bit3: 0, BurstType=0 required +# bit6-4: 4, CL=5 +# bit7: 0, TestMode=0 normal +# bit8: 0, DLL reset=0 normal +# bit11-9: 6, auto-precharge write recovery +# bit12:0, PD must be zero +# bit31-13: 0 required + +DATA 0xFFD01420 0x0004 # DDR Extended Mode +# bit0:0, DDR DLL enabled +# bit1:0, DDR drive strenght normal +# bit2:1, DDR ODT control lsd (disabled) +# bit5-3: 000, required +# bit6:0, DDR ODT control msb, (disabled) +# bit9-7: 000, required +# bit10: 0, differential DQS enabled +# bit11: 0, required +# bit12: 0,
[U-Boot] [PATCH] Kirkwood: mv88f6281gtw_ge: Add kwbimage build support
This patch adds kwbimage configuration file (used by mkimage utility) to support u-boot.kwb target on mv88f6281gtw_ge board. To create Kirkwood boot image to be flashed on SPI Flash, additional parameter u-boot.kwb need to be passed during make. Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- board/Marvell/mv88f6281gtw_ge/config.mk|3 + board/Marvell/mv88f6281gtw_ge/kwbimage.cfg | 165 2 files changed, 168 insertions(+), 0 deletions(-) create mode 100644 board/Marvell/mv88f6281gtw_ge/kwbimage.cfg diff --git a/board/Marvell/mv88f6281gtw_ge/config.mk b/board/Marvell/mv88f6281gtw_ge/config.mk index a4ea769..2bd9f79 100644 --- a/board/Marvell/mv88f6281gtw_ge/config.mk +++ b/board/Marvell/mv88f6281gtw_ge/config.mk @@ -23,3 +23,6 @@ # TEXT_BASE = 0x0060 + +# Kirkwood Boot Image configuration file +KWD_CONFIG = $(SRCTREE)/board/$(BOARDDIR)/kwbimage.cfg diff --git a/board/Marvell/mv88f6281gtw_ge/kwbimage.cfg b/board/Marvell/mv88f6281gtw_ge/kwbimage.cfg new file mode 100644 index 000..ec2513f --- /dev/null +++ b/board/Marvell/mv88f6281gtw_ge/kwbimage.cfg @@ -0,0 +1,165 @@ +# +# (C) Copyright 2009 +# Marvell Semiconductor www.marvell.com +# Written-by: Prafulla Wadaskar prafu...@marvell.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.kwimage for more details about how-to configure +# and create kirkwood boot image +# + +# Boot Media configurations +BOOT_FROM spi # Boot from SPI flash + +# SOC registers configuration using bootrom header extension +# Maximum KWBIMAGE_MAX_CONFIG configurations allowed + +# Configure RGMII-0 interface pad voltage to 1.8V +DATA 0xFFD100e0 0x1b1b1b9b + +#Dram initalization for SINGLE x16 CL=5 @ 400MHz +DATA 0xFFD01400 0x43000a00 # DDR Configuration register +# bit13-0: 0xa00 (2560 DDR2 clks refresh rate) +# bit23-14: zero +# bit24: 1= enable exit self refresh mode on DDR access +# bit25: 1 required +# bit29-26: zero +# bit31-30: 01 + +DATA 0xFFD01404 0x38543000 # DDR Controller Control Low +# bit 4:0=addr/cmd in smame cycle +# bit 5:0=clk is driven during self refresh, we don't care for APX +# bit 6:0=use recommended falling edge of clk for addr/cmd +# bit14:0=input buffer always powered up +# bit18:1=cpu lock transaction enabled +# bit23-20: 5=recommended value for CL=5 and STARTBURST_DEL disabled bit31=0 +# bit27-24: 8= CL+3, STARTBURST sample stages, for freqs 400MHz, unbuffered DIMM +# bit30-28: 3 required +# bit31:0=no additional STARTBURST delay + +DATA 0xFFD01408 0x2202433D # DDR Timing (Low) (active cycles value +1) +# bit3-0: TRAS lsbs +# bit7-4: TRCD +# bit11- 8: TRP +# bit15-12: TWR +# bit19-16: TWTR +# bit20:TRAS msb +# bit23-21: 0x0 +# bit27-24: TRRD +# bit31-28: TRTP + +DATA 0xFFD0140C 0x002A # DDR Timing (High) +# bit6-0: TRFC +# bit8-7: TR2R +# bit10-9: TR2W +# bit12-11: TW2W +# bit31-13: zero required + +DATA 0xFFD01410 0x000D # DDR Address Control +# bit1-0: 01, Cs0width=x16 +# bit3-2: 11, Cs0size=1Gb +# bit5-4: 00, Cs2width=nonexistent +# bit7-6: 00, Cs1size =nonexistent +# bit9-8: 00, Cs2width=nonexistent +# bit11-10: 00, Cs2size =nonexistent +# bit13-12: 00, Cs3width=nonexistent +# bit15-14: 00, Cs3size =nonexistent +# bit16:0, Cs0AddrSel +# bit17:0, Cs1AddrSel +# bit18:0, Cs2AddrSel +# bit19:0, Cs3AddrSel +# bit31-20: 0 required + +DATA 0xFFD01414 0x # DDR Open Pages Control +# bit0:0, OpenPage enabled +# bit31-1: 0 required + +DATA 0xFFD01418 0x # DDR Operation +# bit3-0: 0x0, DDR cmd +# bit31-4: 0 required + +DATA 0xFFD0141C 0x0C52 # DDR Mode +# bit2-0: 2, BurstLen=2 required +# bit3: 0, BurstType=0 required +# bit6-4: 4, CL=5 +# bit7: 0, TestMode=0 normal +# bit8: 0, DLL reset=0 normal +# bit11-9: 6, auto-precharge write recovery +# bit12:0, PD must be zero +# bit31-13: 0 required + +DATA 0xFFD01420 0x0046 # DDR Extended Mode +# bit0:0, DDR DLL enabled +# bit1:1, DDR drive strenght reduced +# bit2:1, DDR ODT control lsd enabled +# bit5-3: 000, required +# bit6:1, DDR ODT control msb, enabled +# bit9-7: 000, required +#
Re: [U-Boot] [PATCH v3] Support for the OpenRD base board
-Original Message- From: Simon Kagstrom [mailto:simon.kagst...@netinsight.net] Sent: Monday, September 14, 2009 1:17 PM To: U-Boot ML Cc: Prafulla Wadaskar; Dhaval Vasa; Prabhanjan Sarnaik; Ashish Karkare Subject: [PATCH v3] Support for the OpenRD base board Support for the OpenRD base board Hi Simon Two small things- Can you pls remove this line, git log shows two lines since subject is also the same The implementation is borrowed from the sheevaplug board and the Marvell 1.1.4 code and likely to be a bit incomplete. Though you have specified below ---, it is better if you can specify what's incomplete here since it will appear in git log. If that is UBIFS only, then I don't think it is incomplete :-) Rest is okay Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Warning Bad CRC
Wolfgang Denk wrote: I thiunk this has been explained to you before: your fw_env.config file is incorrect and does not match your actual hardware configuration. But i cannot find out the issue with config file. This is the information i get from include/configs/my_board.h /* Address and size of Primary Environment Sector */ /* I put the env in the last sector since the board has */ /* top type boot sectors... */ #define CFG_ENV_ADDR0xAD03F000 #define CFG_ENV_SIZE0x1000 #define CFG_ENV_SECT_SIZE 0x1 and my config file is as below MTD device name Device offset Env. size Flash sector size Number of sectors /dev/mtd0 0x3F000 0x1000 0x1 Thanks Rahanesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] fsl_i2c: Impl. AN2919, rev 5 to calculate FDR/DFSR
Hi Joakim,
Joakim Tjernlund wrote:
The latest AN2919 has changed the way FDR/DFSR should be calculated.
Update the driver according to spec. However, Condition 2
is not accounted for as it is not clear how to do so.
I compared rev. 5 of AN2919 with rev. 3 and, as you pointed out, it puts
additional constraints on how to select dfsr and fdr. Especially dfsr
should not exceed a certain, frequency dependent value: dfsr = 50 /
period-in-ns. Therefore, I expected problems with divider values from
the table which high dfsr values. I did your = date;date;date;date
test on a MPC8548 board using dfsr=43 and fdr=7 but it did not fail.
According to the rev. 5, dfsr is not allowed to be greater than 8.
Your patch works fine on this board as well. I have no time for a more
thorough testing with different CPUs and frequencies. Anyhow...
Signed-off-by: Joakim Tjernlund joakim.tjernl...@transmode.se
Acked-by: Wolfgang Grandegger w...@grandegger.com
I realized some minor coding style issues, though. See below.
---
drivers/i2c/fsl_i2c.c | 90
++---
1 files changed, 55 insertions(+), 35 deletions(-)
diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c
index 0c5f6be..78f21c7 100644
--- a/drivers/i2c/fsl_i2c.c
+++ b/drivers/i2c/fsl_i2c.c
@@ -100,29 +100,9 @@ static const struct fsl_i2c *i2c_dev[2] = {
*/
static const struct {
unsigned short divider;
-#ifdef __PPC__
- u8 dfsr;
-#endif
u8 fdr;
} fsl_i2c_speed_map[] = {
-#ifdef __PPC__
- {160, 1, 32}, {192, 1, 33}, {224, 1, 34}, {256, 1, 35},
- {288, 1, 0}, {320, 1, 1}, {352, 6, 1}, {384, 1, 2}, {416, 6, 2},
- {448, 1, 38}, {480, 1, 3}, {512, 1, 39}, {544, 11, 3}, {576, 1, 4},
- {608, 22, 3}, {640, 1, 5}, {672, 32, 3}, {704, 11, 5}, {736, 43, 3},
- {768, 1, 6}, {800, 54, 3}, {832, 11, 6}, {896, 1, 42}, {960, 1, 7},
- {1024, 1, 43}, {1088, 22, 7}, {1152, 1, 8}, {1216, 43, 7}, {1280, 1, 9},
- {1408, 22, 9}, {1536, 1, 10}, {1664, 22, 10}, {1792, 1, 46},
- {1920, 1, 11}, {2048, 1, 47}, {2176, 43, 11}, {2304, 1, 12},
- {2560, 1, 13}, {2816, 43, 13}, {3072, 1, 14}, {3328, 43, 14},
- {3584, 1, 50}, {3840, 1, 15}, {4096, 1, 51}, {4608, 1, 16},
- {5120, 1, 17}, {6144, 1, 18}, {7168, 1, 54}, {7680, 1, 19},
- {8192, 1, 55}, {9216, 1, 20}, {10240, 1, 21}, {12288, 1, 22},
- {14336, 1, 58}, {15360, 1, 23}, {16384, 1, 59}, {18432, 1, 24},
- {20480, 1, 25}, {24576, 1, 26}, {28672, 1, 62}, {30720, 1, 27},
- {32768, 1, 63}, {36864, 1, 28}, {40960, 1, 29}, {49152, 1, 30},
- {61440, 1, 31}, {-1, 1, 31}
-#elif defined(__M68K__)
+#ifdef __M68K__
{20, 32}, {22, 33}, {24, 34}, {26, 35},
{28, 0}, {28, 36}, {30, 1}, {32, 37},
{34, 2}, {36, 38}, {40, 3}, {40, 39},
@@ -158,7 +138,6 @@ static unsigned int set_i2c_bus_speed(const struct
fsl_i2c *dev,
unsigned int i2c_clk, unsigned int speed)
{
unsigned short divider = min(i2c_clk / speed, (unsigned short) -1);
- unsigned int i;
/*
* We want to choose an FDR/DFSR that generates an I2C bus speed that
@@ -166,31 +145,72 @@ static unsigned int set_i2c_bus_speed(const struct
fsl_i2c *dev,
* want the first divider that is equal to or greater than the
* calculated divider.
*/
-
- for (i = 0; i ARRAY_SIZE(fsl_i2c_speed_map); i++)
- if (fsl_i2c_speed_map[i].divider = divider) {
- u8 fdr;
#ifdef __PPC__
- u8 dfsr;
+ u8 dfsr, fdr = 0x31; /* Default if no FDR found */
+ /* a, b and dfsr matches identifiers A,B and C respectively in AN2919 */
+ unsigned short a, b, ga, gb;
+ unsigned long c_div, est_div;
+
#ifdef CONFIG_FSL_I2C_CUSTOM_DFSR
- dfsr = CONFIG_FSL_I2C_CUSTOM_DFSR;
+ dfsr = CONFIG_FSL_I2C_CUSTOM_DFSR;
#else
- dfsr = fsl_i2c_speed_map[i].dfsr;
-#endif
- writeb(dfsr, dev-dfsrr); /* set default filter */
+ /* Condition 1: dfsr = 50/T */
+ dfsr = (5 * (i2c_clk / 1000)) / 10;
#endif
#ifdef CONFIG_FSL_I2C_CUSTOM_FDR
- fdr = CONFIG_FSL_I2C_CUSTOM_FDR;
- speed = i2c_clk / divider; /* Fake something */
+ fdr = CONFIG_FSL_I2C_CUSTOM_FDR;
+ speed = i2c_clk / divider; /* Fake something */
#else
+ debug(Requested speed:%d, i2c_clk:%d\n, speed, i2c_clk);
+ if (!dfsr)
+ dfsr = 1;
+
+ est_div = ~0;
+ for (ga = 0x4, a = 10; a = 30; ga++, a += 2) {
+ for (gb = 0; gb 8; gb++) {
+ b = 16 gb;
+ c_div = b * (a + ((3*dfsr)/b)*2);
Please use spaces around / and *.
+ if ((c_div divider) (c_div est_div)) {
+ unsigned short bin_gb, bin_ga;
+
+ est_div = c_div;
+ bin_gb = gb 2;
+
Re: [U-Boot] [PATCH v4] Support for the OpenRD base board
The implementation is borrowed from the sheevaplug board and the Marvell 1.1.4 code. Unsupported (or untested) is the SD card, PCIe and SATA. Signed-off-by: Simon Kagstrom simon.kagst...@netinsight.net --- I get run-time problems when building for armv5te for OpenRD base (apparently the same problem occurs for other Kirkwood boards). ChangeLog: v2: kwbimage.cfg, which is needed to produce an image to install on the NAND flash, has been added v3: Updated after Prafullas review: * Correct typo in comment section :-) * Update copyright references * Correct bit meaning in kwbimage.cfg according to new specification * Add empty line after MPP configuration * Use short name for board identity string in config * Use CONFIG_SHEEVA_88SV131 instead of Feroceon * Add CONFIG_KIRKWOOD_PCIE_INIT to config * Use config_cmd_default.h and remove options which are not needed anymore * Move config address to 0x6 (384KB). I'd like it at this address since adding UBI/UBIFS support to U-boot makes the binary a bit more than 300KB and would thus overlap a config address at 0x4. Not updated in v3: * The default MTD options are kept (useful for UBIFS) * eth init is not done, this needs to be done in a generic way v4: Updated after Prafullas second review: * Remove the double title line * Change the description to note what's not tested * Re-enable UBIFS since the bitops patch was merged Thanks for the reviews, Prafulla! MAINTAINERS |4 + MAKEALL |1 + Makefile|3 + board/Marvell/openrd_base/Makefile | 56 board/Marvell/openrd_base/config.mk | 33 + board/Marvell/openrd_base/kwbimage.cfg | 168 +++ board/Marvell/openrd_base/openrd_base.c | 160 ++ board/Marvell/openrd_base/openrd_base.h | 46 +++ include/configs/openrd_base.h | 220 +++ 9 files changed, 691 insertions(+), 0 deletions(-) create mode 100644 board/Marvell/openrd_base/Makefile create mode 100644 board/Marvell/openrd_base/config.mk create mode 100644 board/Marvell/openrd_base/kwbimage.cfg create mode 100644 board/Marvell/openrd_base/openrd_base.c create mode 100644 board/Marvell/openrd_base/openrd_base.h create mode 100644 include/configs/openrd_base.h diff --git a/MAINTAINERS b/MAINTAINERS index f42c8f0..50f9260 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -588,6 +588,10 @@ Gary Jennejohn ga...@denx.de Konstantin Kletschke kletsc...@synertronixx.de scb9328 ARM920T +Simon Kagstrom simon.kagst...@netinsight.net + + openrd_base ARM926EJS (Kirkwood SoC) + Nishant Kamat nska...@ti.com omap1610h2 ARM926EJS diff --git a/MAKEALL b/MAKEALL index 1d50c34..a0a3006 100755 --- a/MAKEALL +++ b/MAKEALL @@ -533,6 +533,7 @@ LIST_ARM9= \ omap1610inn \ omap5912osk \ omap730p2 \ + openrd_base \ rd6281a \ sbc2410x\ scb9328 \ diff --git a/Makefile b/Makefile index 0b61d05..8541b36 100644 --- a/Makefile +++ b/Makefile @@ -3022,6 +3022,9 @@ omap1610h2_cs_autoboot_config:unconfig omap5912osk_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm926ejs omap5912osk ti omap +openrd_base_config: unconfig + @$(MKCONFIG) $(@:_config=) arm arm926ejs $(@:_config=) Marvell kirkwood + xtract_omap730p2 = $(subst _cs0boot,,$(subst _cs3boot,, $(subst _config,,$1))) omap730p2_config \ diff --git a/board/Marvell/openrd_base/Makefile b/board/Marvell/openrd_base/Makefile new file mode 100644 index 000..3ef0b9b --- /dev/null +++ b/board/Marvell/openrd_base/Makefile @@ -0,0 +1,56 @@ +# +# (C) Copyright 2009 +# Net Insight www.netinsight.net +# Written-by: Simon Kagstrom simon.kagst...@netinsight.net +# +# Based on sheevaplug: +# (C) Copyright 2009 +# Marvell Semiconductor www.marvell.com +# Written-by: Prafulla Wadaskar prafu...@marvell.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 +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a +
Re: [U-Boot] [PATCH v3] at91: Update MEESC board support
Dear Wolfgang Denk and Jean-Christophe PLAGNIOL-VILLARD, Daniel Gorsulowski wrote: This patch implements several updates: -disable CONFIG_ENV_OVERWRITE -add new hardware style variants and set the arch numbers appropriate (autodet.) -pass the serial# and hardware revision to the kernel -removed unused macros from include/configs/meesc.h Signed-off-by: Daniel Gorsulowski daniel.gorsulow...@esd.eu --- v2: - don't write the ethernet address to the EMAC module anymore v3: - removed function meesc_set_arch_number and moved code to checkboard() - reworked function get_board_serial() - removed unused macros from include/configs/meesc.h board/esd/meesc/meesc.c | 62 +++ include/configs/meesc.h | 25 ++- 2 files changed, 65 insertions(+), 22 deletions(-) snip what about this patch? No more comments, no NACK, no applied to...? Best regards, Daniel Gorsulowski ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: Make DDR2 timing for intip more robust
DDR2 timing for intip was on the edge for some of the available chips for this board. Now it is verfied to work with all of them. Signed-off-by: Dirk Eibach eib...@gdsys.de --- include/configs/intip.h | 20 ++-- 1 files changed, 10 insertions(+), 10 deletions(-) diff --git a/include/configs/intip.h b/include/configs/intip.h index 4f7bc7e..19f12fa 100644 --- a/include/configs/intip.h +++ b/include/configs/intip.h @@ -172,7 +172,7 @@ #define CONFIG_SYS_SDRAM_R3BAS 0x #define CONFIG_SYS_SDRAM_PLBADDULL 0x #define CONFIG_SYS_SDRAM_PLBADDUHB 0x0008 -#define CONFIG_SYS_SDRAM_CONF1LL 0x80001C80 +#define CONFIG_SYS_SDRAM_CONF1LL 0x80001C00 #define CONFIG_SYS_SDRAM_CONF1HB 0x80001C80 #define CONFIG_SYS_SDRAM_CONFPATHB 0x10a68000 @@ -181,7 +181,7 @@ #define CONFIG_SYS_SDRAM0_MB1CF0x #define CONFIG_SYS_SDRAM0_MB2CF0x #define CONFIG_SYS_SDRAM0_MB3CF0x -#define CONFIG_SYS_SDRAM0_MCOPT1 0x05122000 +#define CONFIG_SYS_SDRAM0_MCOPT1 0x0512 #define CONFIG_SYS_SDRAM0_MCOPT2 0x #define CONFIG_SYS_SDRAM0_MODT00x #define CONFIG_SYS_SDRAM0_MODT10x @@ -193,7 +193,7 @@ #define CONFIG_SYS_SDRAM0_INITPLR1 0x81900400 #define CONFIG_SYS_SDRAM0_INITPLR2 0x8102 #define CONFIG_SYS_SDRAM0_INITPLR3 0x8103 -#define CONFIG_SYS_SDRAM0_INITPLR4 0x8101 +#define CONFIG_SYS_SDRAM0_INITPLR4 0x81010002 #define CONFIG_SYS_SDRAM0_INITPLR5 0xE4000542 #define CONFIG_SYS_SDRAM0_INITPLR6 0x81900400 #define CONFIG_SYS_SDRAM0_INITPLR7 0x8A88 @@ -201,21 +201,21 @@ #define CONFIG_SYS_SDRAM0_INITPLR9 0x8A88 #define CONFIG_SYS_SDRAM0_INITPLR100x8A88 #define CONFIG_SYS_SDRAM0_INITPLR110x81000442 -#define CONFIG_SYS_SDRAM0_INITPLR120x81010380 -#define CONFIG_SYS_SDRAM0_INITPLR130x8101 +#define CONFIG_SYS_SDRAM0_INITPLR120x81010382 +#define CONFIG_SYS_SDRAM0_INITPLR130x81010002 #define CONFIG_SYS_SDRAM0_INITPLR140x #define CONFIG_SYS_SDRAM0_INITPLR150x #define CONFIG_SYS_SDRAM0_RQDC 0x8038 -#define CONFIG_SYS_SDRAM0_RFDC 0x003F -#define CONFIG_SYS_SDRAM0_RDCC 0x8000 +#define CONFIG_SYS_SDRAM0_RFDC 0x0257 +#define CONFIG_SYS_SDRAM0_RDCC 0x4000 #define CONFIG_SYS_SDRAM0_DLCR 0x #define CONFIG_SYS_SDRAM0_CLKTR0x4000 -#define CONFIG_SYS_SDRAM0_WRDTR0x84000800 +#define CONFIG_SYS_SDRAM0_WRDTR0x84000823 #define CONFIG_SYS_SDRAM0_SDTR10x80201000 #define CONFIG_SYS_SDRAM0_SDTR20x32204232 -#define CONFIG_SYS_SDRAM0_SDTR30x090B0D15 +#define CONFIG_SYS_SDRAM0_SDTR30x090C0D15 #define CONFIG_SYS_SDRAM0_MMODE0x0442 -#define CONFIG_SYS_SDRAM0_MEMODE 0x +#define CONFIG_SYS_SDRAM0_MEMODE 0x0002 #define CONFIG_SYS_MBYTES_SDRAM256 /* 256MB */ -- 1.5.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] fsl_i2c: Impl. AN2919, rev 5 to calculate FDR/DFSR
Wolfgang Grandegger w...@denx.de wrote on 21/09/2009 12:53:36: Hi Joakim, Joakim Tjernlund wrote: The latest AN2919 has changed the way FDR/DFSR should be calculated. Update the driver according to spec. However, Condition 2 is not accounted for as it is not clear how to do so. I compared rev. 5 of AN2919 with rev. 3 and, as you pointed out, it puts additional constraints on how to select dfsr and fdr. Especially dfsr should not exceed a certain, frequency dependent value: dfsr = 50 / period-in-ns. Therefore, I expected problems with divider values from the table which high dfsr values. I did your = date;date;date;date test on a MPC8548 board using dfsr=43 and fdr=7 but it did not fail. According to the rev. 5, dfsr is not allowed to be greater than 8. Your patch works fine on this board as well. I have no time for a more thorough testing with different CPUs and frequencies. Anyhow... Yes, I too notice that higher dfsr values than the spec says works, in fact my board needs at least dfsr 8 to be 100% stable but the spec says no more that 6 for my board. I suspect that we should enforce a minimum value of 8 to be on the safe side, especially as the HW default is 0x10. Anyhow it is better now than before. Signed-off-by: Joakim Tjernlund joakim.tjernl...@transmode.se Acked-by: Wolfgang Grandegger w...@grandegger.com Thanks. I realized some minor coding style issues, though. See below. Noted. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: split ARM repo and distribute workload
On 23:57 Fri 04 Sep , Wolfgang Denk wrote: Hello everybody, ARM has always been one of the architectures that generated a big number of different processors and SoCs, but recently the activitiy in this area is literally exploding. This is partially due to the fact that ARM is currently used in many designs, so many new ARM based processors and SoCs and even more new ARM boards show up, but another and at least as important change is that some silicon and board vendors have started to actively pushing their products into the U-Boot (and Linux) mainline source trees (and *welcome* they all are!). It has become evident that this growing complexity has become way too massive to be shouldered by a single custodian, even a very active one like Jean-Christophe. I think we have no other choice but to add more manpower to this task, i. e. split the ARM respository and distribute the workload across a few more custodians. Unline with the Power architecture, where the split can be easily defined by processor lines, with ARM it seems more logical to me to differentiate by silicon vendors. After much thinking I therefor suggest to implement the following change for the ARM architecture: master ARM repository:Tom Rix Atmel (AT91): Jean-Christophe Plagniol-Villard Marvell (PXA + IXP): Jean-Christophe Plagniol-Villard I decline it Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] fsl_i2c: Impl. AN2919, rev 5 to calculate FDR/DFSR
Joakim Tjernlund wrote: Wolfgang Grandegger w...@denx.de wrote on 21/09/2009 12:53:36: Hi Joakim, Joakim Tjernlund wrote: The latest AN2919 has changed the way FDR/DFSR should be calculated. Update the driver according to spec. However, Condition 2 is not accounted for as it is not clear how to do so. I compared rev. 5 of AN2919 with rev. 3 and, as you pointed out, it puts additional constraints on how to select dfsr and fdr. Especially dfsr should not exceed a certain, frequency dependent value: dfsr = 50 / period-in-ns. Therefore, I expected problems with divider values from the table which high dfsr values. I did your = date;date;date;date test on a MPC8548 board using dfsr=43 and fdr=7 but it did not fail. According to the rev. 5, dfsr is not allowed to be greater than 8. Your patch works fine on this board as well. I have no time for a more thorough testing with different CPUs and frequencies. Anyhow... Yes, I too notice that higher dfsr values than the spec says works, in fact my board needs at least dfsr 8 to be 100% stable but the spec says no more that 6 for my board. I suspect that we should enforce a minimum value of 8 to be on the safe side, especially as the HW default is 0x10. You say that the new constraints introduced by rev. 5 are not even correct!? Well, these modifications are obscure anyhow. Anyhow it is better now than before. At least for your board. Let's keep an eye on people reporting I2C problems for these processors on the U-Boot and linuxppc-dev ML. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Warning Bad CRC
Dear Rahanesh, In message 4ab75481.6060...@tataelxsi.co.in you wrote: But i cannot find out the issue with config file. We cannot find this out either. We don't know your hardware, and your code is not in mainline either. This is the information i get from include/configs/my_board.h /* Address and size of Primary Environment Sector */ /* I put the env in the last sector since the board has */ /* top type boot sectors... */ #define CFG_ENV_ADDR0xAD03F000 #define CFG_ENV_SIZE0x1000 #define CFG_ENV_SECT_SIZE 0x1 It has already meen explained before that this looks broken. I would expect that the environment address is a multiple of the block size, which it is not in your case. and my config file is as below MTD device name Device offset Env. size Flash sector size =20 Number of sectors /dev/mtd0 0x3F000 0x1000 0x1 Is 0x3F00 really the correct offset? I doubt so. What are your full U-Boot boot messages, and what does flinfo print? 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 Nearly everyone is in favor of going to heaven but too many are hoping they'll live long enough to see an easing of the entrance requirements. Never appeal to a man's better nature. he might not have one. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] fsl_i2c: Impl. AN2919, rev 5 to calculate FDR/DFSR
Wolfgang Grandegger w...@denx.de wrote on 21/09/2009 13:59:04: Joakim Tjernlund wrote: Wolfgang Grandegger w...@denx.de wrote on 21/09/2009 12:53:36: Hi Joakim, Joakim Tjernlund wrote: The latest AN2919 has changed the way FDR/DFSR should be calculated. Update the driver according to spec. However, Condition 2 is not accounted for as it is not clear how to do so. I compared rev. 5 of AN2919 with rev. 3 and, as you pointed out, it puts additional constraints on how to select dfsr and fdr. Especially dfsr should not exceed a certain, frequency dependent value: dfsr = 50 / period-in-ns. Therefore, I expected problems with divider values from the table which high dfsr values. I did your = date;date;date;date test on a MPC8548 board using dfsr=43 and fdr=7 but it did not fail. According to the rev. 5, dfsr is not allowed to be greater than 8. Your patch works fine on this board as well. I have no time for a more thorough testing with different CPUs and frequencies. Anyhow... Yes, I too notice that higher dfsr values than the spec says works, in fact my board needs at least dfsr 8 to be 100% stable but the spec says no more that 6 for my board. I suspect that we should enforce a minimum value of 8 to be on the safe side, especially as the HW default is 0x10. You say that the new constraints introduced by rev. 5 are not even correct!? Well, these modifications are obscure anyhow. My board has a higher rise time than the I2C spec(1 us) so it may be the reason for me. It *looks* like a higher dfsr makes the controller tolerate more noise. Where does the dfsr=1 come from in the first place? It seems random and is very far from HW default. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: split ARM repo and distribute workload
Dear Jean-Christophe, in message 20090921113701.gp29...@game.jcrosoft.org you wrote: Atmel (AT91): Jean-Christophe Plagniol-Villard Marvell (PXA + IXP):Jean-Christophe Plagniol-Villard I decline it Thank you for the clear statement. Thanks again for the work you did in the past. May I inquire what your plans are for other development tasks which you said in the past you were working on (generic cache support for ARM, Kconfig, etc.)? Will you continue this work and submit any patches for these? If so, when might this happen? Tom, I suggest we proceed as follows: - IXP and PXA are really low traffic these days (EOL products); I think we can give up these repositories and just ran this through the generic ARM repo. - AT91 needs a new custodian. Let's see if someone volunteers. Until then, please try to pick up related patches directly. 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 inappropriate cannot be beautiful. - Frank Lloyd Wright _The Future of Architecture_ (1953) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] digsy_mtc: Add TCR register value for RTC (DS1339)
From: Werner Pfister werner.pfis...@intercontrol.de Signed-off-by: Werner Pfister werner.pfis...@intercontrol.de Signed-off-by: Detlev Zundel d...@denx.de --- include/configs/digsy_mtc.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/configs/digsy_mtc.h b/include/configs/digsy_mtc.h index 2bdaaac..7a1a7c3 100644 --- a/include/configs/digsy_mtc.h +++ b/include/configs/digsy_mtc.h @@ -244,6 +244,7 @@ */ #define CONFIG_RTC_DS1337 #define CONFIG_SYS_I2C_RTC_ADDR0x68 +#define CONFIG_SYS_DS1339_TCR_VAL 0xAB/* diode + 4k resistor */ /* * Flash configuration -- 1.6.0.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Subject: [PATCH v3] mx27ads: add support for iMX27ADS board from Freescale
Dear Alan Carvalho de Assis, 2009/9/16 Alan Carvalho de Assis acas...@gmail.com This patch adds support to iMX27ADS development board. This board has 128MB RAM, 32MB NOR Flash and 128MB NAND Flash. Currently only booting from NOR is supported. Signed-off-by: Alan Carvalho de Assis acas...@gmail.com --- MAINTAINERS |3 + MAKEALL |1 + Makefile|3 + board/freescale/mx27ads/Makefile| 51 board/freescale/mx27ads/config.mk |1 + board/freescale/mx27ads/lowlevel_init.S | 127 +++ board/freescale/mx27ads/mx27ads.c | 93 ++ board/freescale/mx27ads/u-boot.lds | 56 + include/configs/mx27ads.h | 202 +++ 9 files changed, 537 insertions(+), 0 deletions(-) create mode 100644 board/freescale/mx27ads/Makefile create mode 100644 board/freescale/mx27ads/config.mk create mode 100644 board/freescale/mx27ads/lowlevel_init.S create mode 100644 board/freescale/mx27ads/mx27ads.c create mode 100644 board/freescale/mx27ads/u-boot.lds create mode 100644 include/configs/mx27ads.h diff --git a/MAINTAINERS b/MAINTAINERS index e9db278..7ff3160 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -512,6 +512,9 @@ Unknown / orphaned boards: # Board CPU # # +Alan Carvalho de Assis acas...@gmail.com + mx27ads i.MX27 + Rowel Atienza ro...@diwalabs.com armadillo ARM720T diff --git a/MAKEALL b/MAKEALL index f0ed8ea..56b4446 100755 --- a/MAKEALL +++ b/MAKEALL @@ -525,6 +525,7 @@ LIST_ARM9= \ mv88f6281gtw_ge \ mx1ads \ mx1fs2 \ + mx27ads \ netstar \ nhk8815 \ nhk8815_onenand \ diff --git a/Makefile b/Makefile index 9764cea..4f2dcef 100644 --- a/Makefile +++ b/Makefile @@ -2965,6 +2965,9 @@ davinci_dm365evm_config : unconfig imx27lite_config: unconfig @$(MKCONFIG) $(@:_config=) arm arm926ejs imx27lite logicpd mx27 +mx27ads_config : unconfig + @$(MKCONFIG) $(@:_config=) arm arm926ejs mx27ads freescale mx27 + lpd7a400_config \ lpd7a404_config: unconfig @$(MKCONFIG) $(@:_config=) arm lh7a40x lpd7a40x diff --git a/board/freescale/mx27ads/Makefile b/board/freescale/mx27ads/Makefile new file mode 100644 index 000..d142a9e --- /dev/null +++ b/board/freescale/mx27ads/Makefile @@ -0,0 +1,51 @@ +# +# (C) Copyright 2000-2004 +# 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).a + +COBJS := mx27ads.o +SOBJS := lowlevel_init.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# + diff --git a/board/freescale/mx27ads/config.mk b/board/freescale/mx27ads/config.mk new file mode 100644 index 000..a2e7768 --- /dev/null +++ b/board/freescale/mx27ads/config.mk @@ -0,0 +1 @@ +TEXT_BASE = 0xA7F0 diff --git a/board/freescale/mx27ads/lowlevel_init.S b/board/freescale/mx27ads/lowlevel_init.S new file mode 100644 index 000..dc62a93 --- /dev/null +++ b/board/freescale/mx27ads/lowlevel_init.S @@ -0,0 +1,127 @@ +/* + * Copyright (C) 2008, Guennadi Liakhovetski l...@denx.de + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as
Re: [U-Boot] network bootp/tftp hang with tsec on MPC8343
Siva,
Myself Siva, working on a custom board using MCF5485. We had a typical
problem with tftp. We are using u-boot(1.3.3) from Freescale on our
first of all I'd try to use latest code.
board and trying to do tftp of filesize 12MB. Sometime file is
getting downloaded into external DDR SDRAM correctly. Sometime u-boot
get’s hanged. This problem is observed during cold bootup. When we
switch off the board and powered it up, we are facing this problem. If
we wait for 1 or 2 minutes after the board get’s powered up, try to do
tftp it goes well. After going through your post on internet
(http://www.mail-archive.com/u-boot@lists.denx.de/msg00719.html) , I
am suspecting this could be problem with our DDR SDRAM controller
initialization.
Using memory with single read/write access is very relaxed compared to
burst mode access during DMA ops. I've had a plain simple timing
violation ... there are lots of dynamic parameters that have to be met.
There's no general advice - sorry.
Are you sure that it is a memory problem ? Any obscure crashes running
linux or other apps ? If not it's more likely to be a networking issue.
R/S-GMII also has strict timing requirements. What about signal
integrity issues - are you sure the interface is working fine from an
electrical point of view ?
U-boot Ethernet driver uses DMA to transfer the frames. But the serail
console log shows some timeouts (T) when the U-boot hangs during
transfer.
ok - could be anything.
If we wait for 1 or 2 minutes before doing tftp to get the image into
RAM , it is getting downloaded properly. Could you please suggest what
exactly you did in your SRAM configuration to fix the problem?
looks like a thermal issue, i.e. electrical problem.
Again, this might be either local memory or MII. What kind of network
are you using ? I'm not familiar with MCF54xx ...
Get you memory device datasheet and match the dynamic parameters with
that of your CPU's memory controller.
Maybe there are others having similar problems with your particular CPU.
Regards,
André
Please find the attached log:
U-Boot 1.3.3 (Sep 18 2009 - 10:24:03)
CPU: Freescale MCF5485
CPU CLK 200 Mhz BUS CLK 100 Mhz
Board: Freescale FireEngine 5485 EVB
DRAM: 128 MB
POST: Checking Ram...PASSED.
FLASH: 16 MB
In:serial
Out: serial
Err: serial
Net: rxbd f0012000 txbd f0012100
rxbd f0012870 txbd f0012970
FEC0, FEC1
Hit any key to stop autoboot: 5
- printenv
bootdelay=5
baudrate=115200
netmask=255.255.255.0
hostname=M548xEVB
netdev=eth0
loadaddr=1000
u-boot=u-boot.bin
load=tftp ${loadaddr) ${u-boot}
kernel=u-boot.bin
load=tftp ${loadaddr) ${kernel}
upd=run load; run prog
progboot=prot off 1:0-2;era e000 e005;cp.b ${loadaddr}
e000 ${filesize};
progkern=prot off 1:4-51;era e008 e067;cp.b ${loadaddr}
e008 ${filesize};save
bootargs=console=/dev/console,115200 root=/dev/ram0 rootfstype=romfs
ro
bootcmd=cp.b e008 ${loadaddr} ${filesize};go 2000
ethact=FEC0
ethaddr=00:25:F7:10:00:1F
eth1addr=00:25:F7:10:00:20
stdin=serial
stdout=serial
stderr=serial
mem=130560k
gatewayip=169.254.0.102
ipaddr=169.254.0.101
serverip=169.254.0.253
filesize=C7
Environment size: 720/131068 bytes
- tftp 1 image.bin;prot off 1:4-103;era E008 E0CF;cp.b
1000 E008 BEEC0F;reset;
Using FEC0 device
TFTP from server 169.254.0.253; our IP address is 169.254.0.101
Filename 'image.bin'.
Load address: 0x1
Loading:
*#
#
#
T #
#
#
Thanks,
Siva
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner,
Hans-Joachim Reich
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand_scan() in ARM9 S3C2410
kevin.morf...@fearnside-systems.co.uk wrote: Minkyu Kang wrote: Dear J.Hwan.Kim 2009/9/20 J.Hwan.Kim frog1...@gmail.com: Hi, everyone I'm using u-boot for ARM9 S3C2410. My tool chain is ELDK4.2. I defined configuration CONFIG_NAND_CMD, CONFIG_SYS_MAX_NAND_DEVICE1, and CONFIG_SYS_NAND_BASE 0x4E0C for nand_init(). It works well until the routine reaches nand_scan() which is in nand_base.c When nand_scan() is called, the system hangs. For test, When I written dummy function is nand_base.c and called the dummy function from nand.c, the system is down. My u-boot is using relocation to SDRAM from NAND. The address of nand_scan() is 0x31F85894. (TEXT_BASE is 0x31F8 and SDRAM start from 0x3000) I'm sured that the binary data of u-boot.bin (address 0x5894) is same with SDRAM data in 0x31F85894. I think the relocation is OK. When I attached the routines of nand_base.c to nand.c, the nand_scan() function passed. Is there any hint for this problem? Thanks in advnace. Regards, J.Hwan Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Did you check the kevin's mail? He said u-boot for s3c2410 doesn't support. http://lists.denx.de/pipermail/u-boot/2009-September/060855.html u-boot for s3c2410 doesn't support booting from NAND flash, but assuming you boot from NOR flash and have NAND enabled properly in the board config file it does support the use of NAND flash. In the NAND config you show in your email, it's probably a typo but it should be CONFIG_CMD_NAND not CONFIG_NAND_CMD. First of all, thank you for replies. I solved the problem, which was not nand_scan routine() problem. My board is DEP-2410 which is not included in an official U-boot. I modifies smdk2410_config for my board. However, I received an unofficial code from the company making DEP-2410 board, which enables NAND booting. The code includes routines for nand initialization before relocation to SDRAM and the routines copying pages from NAND to SDRAM. My mistake was that I did not increased the relocation size after including nand related code by defining CONFIG_CMD_NAND and others. The relocation size was defined in the code received from the DEP-2410 board company. By defining CONFIG_CMD_NAND, the code size increased over 128Kbytes. The size of original code ,which did not include NAND related code, was about 93Kbytes and my relocation code size was defined as 128KBytes. So, when code branches to over 128Kbytes, strange code is executed and system hangs. It was my mistake. Regards, J.Hwan Kim If that's not the problem - I'm not sure what board you're using. If you're using an existing config file post the name of it, or if you're using one you've created post the board config file itself. Regards Kevin Morfitt And I think.. you can trace nand_scan() step by step. please try it and do more detailed question. Thanks Minkyu Kang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] at91: Update MEESC board support
Dear Daniel Gorsulowski, In message 4ab76125.5010...@esd.eu you wrote: Dear Wolfgang Denk and Jean-Christophe PLAGNIOL-VILLARD, ... what about this patch? No more comments, no NACK, no applied to...? As you might have noticed, Jean-Christophe just throw in the towel as AT91 (and PXA and IXP) custodian. Until we find a new one (volunteers welcome!) Tom will have to handles this - additionally to his other work. Please be a bit patient with him. You can usually just relax as long as there is no NAK :-) Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There are three principal ways to lose money: wine, women, and engi- neers. While the first two are more pleasant, the third is by far the more certain. - Baron Rothschild, ca. 1800 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Warning Bad CRC
Dear Wolfgang, Is 0x3F00 really the correct offset? I doubt so. What are your full U-Boot boot messages, and what does flinfo print? * This is the print message of flinfo* U-BOOT # flinfo DataFlash:Nb pages: 32768 Page Size:256 Size= 8388608 bytes Logical address: 0xAD00 Nb Erase Blocks:128 Erase Block Size: 65536 Area 0: AD00 to AD003FFF Area 1: AD004000 to AD03 Area 2: AD04 to AD30BFFF Area 3: AD30C000 to AD7F *U-Boot boot messages follow* U-Boot 1.1.2 (Sep 19 2009 - 10:26:28) Board: IAD CPU Speed 200 MHz DRAM: 32 MB sflash.c:266:DF_F_DataflashProbe: Entered sflash.c:269:DF_F_DataflashProbe: flash type is 0x1 sflash.c:270:DF_F_DataflashProbe: num pages 32768 DataFlash:Nb pages: 32768 Page Size:256 Size= 8388608 bytes Logical address: 0xAD00 Nb Erase Blocks:128 Erase Block Size: 65536 Area 0: AD00 to AD003FFF Area 1: AD004000 to AD03 Area 2: AD04 to AD30BFFF Area 3: AD30C000 to AD7F got bad crc. got:0x603b0489, expected:0x0 *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Net:Eth. Type run flash_nfs to mount root filesystem over NFS Hit any key to stop autoboot: 0 *Print message after execution of saveenv command from uboot : *Saving Environment to dataflash... copy 0xad03-0xad04 to saveenv-buf 0x8010. erasing 0xad03 - 0xad03 Erasing sectors 0x3 to 0x3 sflash.c:69:DF_F_PageErase: erasing page: 0x3 done erasingsflash.c:164:DF_F_DataFlashWrite: write: src 0x8010, dst 0x3, size 0x1 ... .sflash.c:225:DF_F_DataFlashWrite: final partial page Hope this helps Thanks Rahanesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/3] NAND boot: MPC8536DS support
On Sun, Sep 20, 2009 at 11:40:33PM -0700, Hu Mingkai-B21284 wrote: How about changing it to: # Options: NAND, 36BIT MPC8536DS_%_config MPC8536DS_config: unconfig I don't get it. what's the '%'? or how to use it? It is a wildcard (or more specifically, a pattern rule). It will match anything that begins with MPC8536DS_ and ends with _config. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Add version variable to the galaxy5200 board.
Add version environment variable to the galaxy5200 board header file. Signed-off-by: Eric Millbrandt emillbra...@dekaresearch.com --- include/configs/galaxy5200.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/configs/galaxy5200.h b/include/configs/galaxy5200.h index f4b520d..3b67ea9 100644 --- a/include/configs/galaxy5200.h +++ b/include/configs/galaxy5200.h @@ -367,6 +367,8 @@ CONFIG_BOOTP_DNS2 | \ CONFIG_BOOTP_SEND_HOSTNAME ) +#define CONFIG_VERSION_VARIABLE 1 + /* * Various low-level settings */ -- 1.6.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 00/13] ppc: Fix relocation
This series attempts to fix relocation to RAM for ppc boards. I split the patches up pretty liberally, let me know if you'd like them organized differently. I tried to be thorough during the changes (especially #1), let me know if I missed anything, there's lots of linker scripts for ppc boards:) Peter Tyser (13): ppc: Enable full relocation to RAM ppc: Check for compilers that don't support relocation ppc: Remove board.c relocation fixups ppc: Remove pci config table pointer relocation fixups ppc: Remove extable relocation fixups ppc: Remove board-specific command table relocation fixups tsec: Remove PHY command relocation fixups fpga: Remove relocation fixups mpl: Remove memory test relocation fixups lwmon, lwmon5: Remove sysmon POST relocation fixups p3mx: Remove serial relocation fixups Conditionally perform common relocation fixups ppc: Remove reloc_off field from global_data structure board/LEOX/elpt860/u-boot.lds |1 - board/LEOX/elpt860/u-boot.lds.debug|1 - board/MAI/AmigaOneG3SE/u-boot.lds |1 - board/Marvell/db64360/u-boot.lds |1 - board/Marvell/db64460/u-boot.lds |1 - board/RPXClassic/u-boot.lds|1 - board/RPXClassic/u-boot.lds.debug |1 - board/RPXlite/u-boot.lds |1 - board/RPXlite/u-boot.lds.debug |1 - board/RPXlite_dw/u-boot.lds|1 - board/RPXlite_dw/u-boot.lds.debug |1 - board/RRvision/u-boot.lds |1 - board/adder/u-boot.lds |1 - board/amcc/acadia/u-boot-nand.lds |1 - board/amcc/acadia/u-boot.lds |1 - board/amcc/bamboo/u-boot-nand.lds |1 - board/amcc/bamboo/u-boot.lds |1 - board/amcc/bubinga/u-boot.lds |1 - board/amcc/canyonlands/u-boot-nand.lds |1 - board/amcc/canyonlands/u-boot.lds |1 - board/amcc/ebony/u-boot.lds|1 - board/amcc/katmai/u-boot.lds |1 - board/amcc/kilauea/u-boot-nand.lds |1 - board/amcc/kilauea/u-boot.lds |1 - board/amcc/luan/u-boot.lds |1 - board/amcc/makalu/u-boot.lds |1 - board/amcc/ocotea/u-boot.lds |1 - board/amcc/redwood/u-boot.lds |1 - board/amcc/sequoia/u-boot-nand.lds |1 - board/amcc/sequoia/u-boot-ram.lds |1 - board/amcc/sequoia/u-boot.lds |1 - board/amcc/taihu/u-boot.lds|1 - board/amcc/taishan/u-boot.lds |1 - board/amcc/walnut/u-boot.lds |1 - board/amcc/yosemite/u-boot.lds |1 - board/amcc/yucca/u-boot.lds|1 - board/amirix/ap1000/u-boot.lds |1 - board/c2mon/u-boot.lds |1 - board/c2mon/u-boot.lds.debug |1 - board/cm5200/u-boot.lds|1 - board/cogent/u-boot.lds|1 - board/cogent/u-boot.lds.debug |1 - board/cray/L1/u-boot.lds |1 - board/cray/L1/u-boot.lds.debug |1 - board/csb272/u-boot.lds|1 - board/csb472/u-boot.lds|1 - board/dave/PPChameleonEVB/u-boot.lds |1 - board/digsy_mtc/cmd_mtc.c | 30 - board/digsy_mtc/digsy_mtc.c|2 - board/eltec/bab7xx/u-boot.lds |1 - board/eltec/elppc/u-boot.lds |1 - board/eltec/mhpc/u-boot.lds|1 - board/eltec/mhpc/u-boot.lds.debug |1 - board/emk/top860/u-boot.lds|1 - board/emk/top860/u-boot.lds.debug |1 - board/ep88x/u-boot.lds |1 - board/eric/u-boot.lds |1 - board/esd/adciop/u-boot.lds|1 - board/esd/apc405/u-boot.lds|1 - board/esd/ar405/u-boot.lds |1 - board/esd/ash405/u-boot.lds|1 - board/esd/canbt/u-boot.lds |1 - board/esd/cms700/u-boot.lds|1 - board/esd/cpci2dp/u-boot.lds |1 - board/esd/cpci405/u-boot.lds |1 - board/esd/cpci750/u-boot.lds |1 - board/esd/cpciiser4/u-boot.lds |1 - board/esd/dasa_sim/u-boot.lds |1 - board/esd/dp405/u-boot.lds |1 - board/esd/du405/u-boot.lds |1 - board/esd/du440/u-boot.lds |1 - board/esd/hh405/u-boot.lds |1 - board/esd/hub405/u-boot.lds|1 - board/esd/ocrtc/u-boot.lds |1 - board/esd/pci405/u-boot.lds|1 - board/esd/plu405/u-boot.lds|1 - board/esd/pmc405/u-boot.lds
[U-Boot] [PATCH 03/13] ppc: Remove board.c relocation fixups
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
lib_ppc/board.c | 50 --
1 files changed, 0 insertions(+), 50 deletions(-)
diff --git a/lib_ppc/board.c b/lib_ppc/board.c
index e8509ee..4123e73 100644
--- a/lib_ppc/board.c
+++ b/lib_ppc/board.c
@@ -627,13 +627,8 @@ void board_init_f (ulong bootflag)
*/
void board_init_r (gd_t *id, ulong dest_addr)
{
- cmd_tbl_t *cmdtp;
char *s;
bd_t *bd;
- extern void malloc_bin_reloc (void);
-#ifndef CONFIG_ENV_IS_NOWHERE
- extern char * env_name_spec;
-#endif
ulong malloc_start;
#ifndef CONFIG_SYS_NO_FLASH
@@ -646,18 +641,7 @@ void board_init_r (gd_t *id, ulong dest_addr)
gd-flags |= GD_FLG_RELOC; /* tell others: relocation done */
/* The Malloc area is immediately below the monitor copy in DRAM */
-#if defined(CONFIG_RELOC_FIXUP_WORKS)
- gd-reloc_off = 0;
malloc_start = dest_addr - TOTAL_MALLOC_LEN;
-#else
- gd-reloc_off = dest_addr - CONFIG_SYS_MONITOR_BASE;
- malloc_start = CONFIG_SYS_MONITOR_BASE + gd-reloc_off -
- TOTAL_MALLOC_LEN;
-#endif
-
-#if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx)
- gd-cpu += gd-reloc_off;
-#endif
#ifdef CONFIG_SERIAL_MULTI
serial_initialize();
@@ -682,38 +666,6 @@ void board_init_r (gd_t *id, ulong dest_addr)
monitor_flash_len = (ulong)__init_end - dest_addr;
- /*
-* We have to relocate the command table manually
-*/
- for (cmdtp = __u_boot_cmd_start; cmdtp != __u_boot_cmd_end; cmdtp++)
{
- ulong addr;
- addr = (ulong) (cmdtp-cmd) + gd-reloc_off;
-#if 0
- printf (Command \%s\: 0x%08lx = 0x%08lx\n,
- cmdtp-name, (ulong) (cmdtp-cmd), addr);
-#endif
- cmdtp-cmd =
- (int (*)(struct cmd_tbl_s *, int, int, char *[]))addr;
-
- addr = (ulong)(cmdtp-name) + gd-reloc_off;
- cmdtp-name = (char *)addr;
-
- if (cmdtp-usage) {
- addr = (ulong)(cmdtp-usage) + gd-reloc_off;
- cmdtp-usage = (char *)addr;
- }
-#ifdef CONFIG_SYS_LONGHELP
- if (cmdtp-help) {
- addr = (ulong)(cmdtp-help) + gd-reloc_off;
- cmdtp-help = (char *)addr;
- }
-#endif
- }
- /* there are some other pointer constants we must deal with */
-#ifndef CONFIG_ENV_IS_NOWHERE
- env_name_spec += gd-reloc_off;
-#endif
-
WATCHDOG_RESET ();
#ifdef CONFIG_LOGBUFFER
@@ -721,7 +673,6 @@ void board_init_r (gd_t *id, ulong dest_addr)
#endif
#ifdef CONFIG_POST
post_output_backlog ();
- post_reloc ();
#endif
WATCHDOG_RESET();
@@ -752,7 +703,6 @@ void board_init_r (gd_t *id, ulong dest_addr)
asm (sync ; isync);
mem_malloc_init (malloc_start, TOTAL_MALLOC_LEN);
- malloc_bin_reloc ();
#if !defined(CONFIG_SYS_NO_FLASH)
puts (FLASH: );
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 02/13] ppc: Check for compilers that don't support relocation
Certain ppc compilers are known not to generate the .fixup section properly. The .fixup section is necessary to create a relocatable U-Boot image. A basic check for the existence of the .fixup section should hopefully catch the majority of broken compilers which don't support relocation. Signed-off-by: Peter Tyser pty...@xes-inc.com --- lib_ppc/Makefile |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/lib_ppc/Makefile b/lib_ppc/Makefile index 60ea0c9..399b41e 100644 --- a/lib_ppc/Makefile +++ b/lib_ppc/Makefile @@ -42,6 +42,12 @@ SRCS := $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c) OBJS := $(addprefix $(obj),$(SOBJS-y) $(COBJS-y)) $(LIB):$(obj).depend $(OBJS) + @if ! $(CROSS_COMPILE)readelf -S $(OBJS) | grep -q '\.fixup.*PROGBITS';\ + then \ + echo ERROR: Your compiler doesn't generate .fixup sections!;\ + echoUpgrade to a recent toolchain.; \ + exit 1; \ + fi; $(AR) $(ARFLAGS) $@ $(OBJS) # -- 1.6.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 05/13] ppc: Remove extable relocation fixups
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
lib_ppc/extable.c | 26 ++
1 files changed, 6 insertions(+), 20 deletions(-)
diff --git a/lib_ppc/extable.c b/lib_ppc/extable.c
index 91e2b3d..7408d5c 100644
--- a/lib_ppc/extable.c
+++ b/lib_ppc/extable.c
@@ -53,27 +53,13 @@ search_one_table(const struct exception_table_entry *first,
unsigned long value)
{
long diff;
- if ((ulong) first CONFIG_SYS_MONITOR_BASE) {
- /* exception occurs in FLASH, before u-boot relocation.
-* No relocation offset is needed.
-*/
- while (first = last) {
- diff = first-insn - value;
- if (diff == 0)
- return first-fixup;
- first++;
- }
- } else {
- /* exception occurs in RAM, after u-boot relocation.
-* A relocation offset should be added.
-*/
- while (first = last) {
- diff = (first-insn + gd-reloc_off) - value;
- if (diff == 0)
- return (first-fixup + gd-reloc_off);
- first++;
- }
+ while (first = last) {
+ diff = first-insn - value;
+ if (diff == 0)
+ return first-fixup;
+ first++;
}
+
return 0;
}
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 06/13] ppc: Remove board-specific command table relocation fixups
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
board/digsy_mtc/cmd_mtc.c | 30 --
board/digsy_mtc/digsy_mtc.c |2 --
board/inka4x0/inka4x0.c | 10 --
board/inka4x0/inkadiag.c| 28
include/configs/inka4x0.h |1 -
5 files changed, 0 insertions(+), 71 deletions(-)
diff --git a/board/digsy_mtc/cmd_mtc.c b/board/digsy_mtc/cmd_mtc.c
index aa39611..ecea5b3 100644
--- a/board/digsy_mtc/cmd_mtc.c
+++ b/board/digsy_mtc/cmd_mtc.c
@@ -320,36 +320,6 @@ static int do_mtc_help(cmd_tbl_t *cmdtp, int flag, int
argc, char *argv[])
ARRAY_SIZE(cmd_mtc_sub), cmdtp, flag, argc, argv);
}
-/* Relocate the command table function pointers when running in RAM */
-int mtc_cmd_init_r(void)
-{
- cmd_tbl_t *cmdtp;
-
- for (cmdtp = cmd_mtc_sub[0]; cmdtp !=
-cmd_mtc_sub[ARRAY_SIZE(cmd_mtc_sub)]; cmdtp++) {
- ulong addr;
-
- addr = (ulong)(cmdtp-cmd) + gd-reloc_off;
- cmdtp-cmd =
- (int (*)(struct cmd_tbl_s *, int, int, char *[]))addr;
-
- addr = (ulong)(cmdtp-name) + gd-reloc_off;
- cmdtp-name = (char *)addr;
-
- if (cmdtp-usage) {
- addr = (ulong)(cmdtp-usage) + gd-reloc_off;
- cmdtp-usage = (char *)addr;
- }
-#ifdef CONFIG_SYS_LONGHELP
- if (cmdtp-help) {
- addr = (ulong)(cmdtp-help) + gd-reloc_off;
- cmdtp-help = (char *)addr;
- }
-#endif
- }
- return 0;
-}
-
int cmd_mtc(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
{
cmd_tbl_t *c;
diff --git a/board/digsy_mtc/digsy_mtc.c b/board/digsy_mtc/digsy_mtc.c
index 9d77e54..cc6087b 100644
--- a/board/digsy_mtc/digsy_mtc.c
+++ b/board/digsy_mtc/digsy_mtc.c
@@ -240,7 +240,6 @@ void board_get_enetaddr (uchar * enet)
int misc_init_r(void)
{
- extern int mtc_cmd_init_r (void);
uchar enetaddr[6];
if (!eth_getenv_enetaddr(ethaddr, enetaddr)) {
@@ -248,7 +247,6 @@ int misc_init_r(void)
eth_setenv_enetaddr(ethaddr, enetaddr);
}
- mtc_cmd_init_r();
return 0;
}
diff --git a/board/inka4x0/inka4x0.c b/board/inka4x0/inka4x0.c
index c645b05..27b79ec 100644
--- a/board/inka4x0/inka4x0.c
+++ b/board/inka4x0/inka4x0.c
@@ -177,16 +177,6 @@ void flash_preinit(void)
clrbits_be32(lpb-cs0_cfg, 0x1); /* clear RO */
}
-int misc_init_r (void) {
- extern int inkadiag_init_r (void);
-
- /*
-* The command table used for the subcommands of inkadiag
-* needs to be relocated manually.
-*/
- return inkadiag_init_r();
-}
-
int misc_init_f (void)
{
volatile struct mpc5xxx_gpio*gpio=
diff --git a/board/inka4x0/inkadiag.c b/board/inka4x0/inkadiag.c
index 3761ef6..0a75abd 100644
--- a/board/inka4x0/inkadiag.c
+++ b/board/inka4x0/inkadiag.c
@@ -484,31 +484,3 @@ U_BOOT_CMD(inkadiag, 6, 1, do_inkadiag,
[inkadiag what ...]\n
- perform a diagnosis on inka hardware\n
'inkadiag' performs hardware tests.);
-
-/* Relocate the command table function pointers when running in RAM */
-int inkadiag_init_r (void) {
- cmd_tbl_t *cmdtp;
-
- for (cmdtp = cmd_inkadiag_sub[0]; cmdtp !=
-cmd_inkadiag_sub[ARRAY_SIZE(cmd_inkadiag_sub)]; cmdtp++) {
- ulong addr;
-
- addr = (ulong) (cmdtp-cmd) + gd-reloc_off;
- cmdtp-cmd = (int (*)(struct cmd_tbl_s *, int, int, char
*[]))addr;
-
- addr = (ulong)(cmdtp-name) + gd-reloc_off;
- cmdtp-name = (char *)addr;
-
- if (cmdtp-usage) {
- addr = (ulong)(cmdtp-usage) + gd-reloc_off;
- cmdtp-usage = (char *)addr;
- }
-#ifdef CONFIG_SYS_LONGHELP
- if (cmdtp-help) {
- addr = (ulong)(cmdtp-help) + gd-reloc_off;
- cmdtp-help = (char *)addr;
- }
-#endif
- }
- return 0;
-}
diff --git a/include/configs/inka4x0.h b/include/configs/inka4x0.h
index 46606ca..14f7826 100644
--- a/include/configs/inka4x0.h
+++ b/include/configs/inka4x0.h
@@ -42,7 +42,6 @@
#define BOOTFLAG_WARM 0x02/* Software reboot
*/
#define CONFIG_MISC_INIT_F 1 /* Use misc_init_f()
*/
-#define CONFIG_MISC_INIT_R 1 /* Use misc_init_r()
*/
#define CONFIG_HIGH_BATS 1 /* High BATs supported
*/
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/13] ppc: Remove pci config table pointer relocation fixups
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
board/freescale/mpc8548cds/mpc8548cds.c |7 ---
board/mpl/common/pci.c | 18 --
board/sbc8548/sbc8548.c |6 --
3 files changed, 0 insertions(+), 31 deletions(-)
diff --git a/board/freescale/mpc8548cds/mpc8548cds.c
b/board/freescale/mpc8548cds/mpc8548cds.c
index 80de6f8..73e7c21 100644
--- a/board/freescale/mpc8548cds/mpc8548cds.c
+++ b/board/freescale/mpc8548cds/mpc8548cds.c
@@ -276,7 +276,6 @@ pci_init_board(void)
{
volatile ccsr_fsl_pci_t *pci = (ccsr_fsl_pci_t *) CONFIG_SYS_PCI1_ADDR;
struct pci_controller *hose = pci1_hose;
- struct pci_config_table *table;
struct pci_region *r = hose-regions;
uint pci_32 = gur-pordevsr MPC85xx_PORDEVSR_PCI1_PCI32; /*
PORDEVSR[15] */
@@ -312,12 +311,6 @@ pci_init_board(void)
PCI_REGION_IO);
hose-region_count = r - hose-regions;
- /* relocate config table pointers */
- hose-config_table = \
- (struct pci_config_table *)((uint)hose-config_table +
gd-reloc_off);
- for (table = hose-config_table; table table-vendor;
table++)
- table-config_device += gd-reloc_off;
-
hose-first_busno=first_free_busno;
fsl_pci_init(hose, (u32)pci-cfg_addr, (u32)pci-cfg_data);
diff --git a/board/mpl/common/pci.c b/board/mpl/common/pci.c
index e0ba620..f9bb6ab 100644
--- a/board/mpl/common/pci.c
+++ b/board/mpl/common/pci.c
@@ -94,29 +94,11 @@ static struct pci_controller hose = {
};
-static void reloc_pci_cfg_table(struct pci_config_table *table)
-{
- unsigned long addr;
-
- for (; table table-vendor; table++) {
- addr = (ulong) (table-config_device) + gd-reloc_off;
-#ifdef DEBUG
- printf (device \%d\: 0x%08lx = 0x%08lx\n,
- table-device, (ulong) (table-config_device),
addr);
-#endif
- table-config_device =
- (void (*)(struct pci_controller* hose, pci_dev_t dev,
- struct pci_config_table *))addr;
- table-priv[0]+=gd-reloc_off;
- }
-}
-
void pci_init_board(void)
{
/*we want the ptrs to RAM not flash (ie don't use init list)*/
hose.fixup_irq= pci_pip405_fixup_irq;
hose.config_table = pci_pip405_config_table;
- reloc_pci_cfg_table(hose.config_table);
#ifdef DEBUG
printf(Init PCI: fixup_irq=%p config_table=%p
hose=%p\n,pci_pip405_fixup_irq,pci_pip405_config_table,hose);
#endif
diff --git a/board/sbc8548/sbc8548.c b/board/sbc8548/sbc8548.c
index e5b21b5..5cdfef4 100644
--- a/board/sbc8548/sbc8548.c
+++ b/board/sbc8548/sbc8548.c
@@ -392,12 +392,6 @@ pci_init_board(void)
PCI_REGION_IO);
hose-region_count = r - hose-regions;
- /* relocate config table pointers */
- hose-config_table = \
- (struct pci_config_table *)((uint)hose-config_table +
gd-reloc_off);
- for (table = hose-config_table; table table-vendor;
table++)
- table-config_device += gd-reloc_off;
-
hose-first_busno=first_free_busno;
fsl_pci_init(hose, (u32)pci-cfg_addr, (u32)pci-cfg_data);
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 07/13] tsec: Remove PHY command relocation fixups
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
drivers/net/tsec.c | 49 -
1 files changed, 0 insertions(+), 49 deletions(-)
diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
index 5c3d261..3f74118 100644
--- a/drivers/net/tsec.c
+++ b/drivers/net/tsec.c
@@ -35,8 +35,6 @@ typedef volatile struct rtxbd {
#define MAXCONTROLLERS (8)
-static int relocated = 0;
-
static struct tsec_private *privlist[MAXCONTROLLERS];
static int num_tsecs = 0;
@@ -59,7 +57,6 @@ uint read_phy_reg(struct tsec_private *priv, uint regnum);
struct phy_info *get_phy_info(struct eth_device *dev);
void phy_run_commands(struct tsec_private *priv, struct phy_cmd *cmd);
static void adjust_link(struct eth_device *dev);
-static void relocate_cmds(void);
#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII) \
!defined(BITBANGMII)
static int tsec_miiphy_write(char *devname, unsigned char addr,
@@ -321,9 +318,6 @@ static int init_phy(struct eth_device *dev)
asm(sync);
while (priv-phyregs-miimind MIIMIND_BUSY) ;
- if (0 == relocated)
- relocate_cmds();
-
/* Get the cmd structure corresponding to the attached
* PHY */
curphy = get_phy_info(dev);
@@ -1800,49 +1794,6 @@ void phy_run_commands(struct tsec_private *priv, struct
phy_cmd *cmd)
}
}
-/* Relocate the function pointers in the phy cmd lists */
-static void relocate_cmds(void)
-{
- struct phy_cmd **cmdlistptr;
- struct phy_cmd *cmd;
- int i, j, k;
-
- for (i = 0; phy_info[i]; i++) {
- /* First thing's first: relocate the pointers to the
-* PHY command structures (the structs were done) */
- phy_info[i] = (struct phy_info *)((uint) phy_info[i]
- + gd-reloc_off);
- phy_info[i]-name += gd-reloc_off;
- phy_info[i]-config =
- (struct phy_cmd *)((uint) phy_info[i]-config
- + gd-reloc_off);
- phy_info[i]-startup =
- (struct phy_cmd *)((uint) phy_info[i]-startup
- + gd-reloc_off);
- phy_info[i]-shutdown =
- (struct phy_cmd *)((uint) phy_info[i]-shutdown
- + gd-reloc_off);
-
- cmdlistptr = phy_info[i]-config;
- j = 0;
- for (; cmdlistptr = phy_info[i]-shutdown; cmdlistptr++) {
- k = 0;
- for (cmd = *cmdlistptr;
-cmd-mii_reg != miim_end;
-cmd++) {
- /* Only relocate non-NULL pointers */
- if (cmd-funct)
- cmd-funct += gd-reloc_off;
-
- k++;
- }
- j++;
- }
- }
-
- relocated = 1;
-}
-
#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII) \
!defined(BITBANGMII)
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 10/13] lwmon, lwmon5: Remove sysmon POST relocation fixups
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
post/board/lwmon/sysmon.c | 17 +
post/board/lwmon5/sysmon.c | 17 +
2 files changed, 2 insertions(+), 32 deletions(-)
diff --git a/post/board/lwmon/sysmon.c b/post/board/lwmon/sysmon.c
index 79a5151..fc828b2 100644
--- a/post/board/lwmon/sysmon.c
+++ b/post/board/lwmon/sysmon.c
@@ -56,8 +56,6 @@ static int sysmon_temp_invalid = 0;
/* #define DEBUG */
-#defineRELOC(x) if (x != NULL) x = (void *) ((ulong) (x) +
gd-reloc_off)
-
typedef struct sysmon_s sysmon_t;
typedef struct sysmon_table_s sysmon_table_t;
@@ -159,20 +157,7 @@ int sysmon_init_f (void)
void sysmon_reloc (void)
{
- sysmon_t ** l;
- sysmon_table_t * t;
-
- for (l = sysmon_list; *l; l++) {
- RELOC(*l);
- RELOC((*l)-init);
- RELOC((*l)-read);
- }
-
- for (t = sysmon_table; t sysmon_table + sysmon_table_size; t ++) {
- RELOC(t-exec_before);
- RELOC(t-exec_after);
- RELOC(t-sysmon);
- }
+ /* Do nothing for now, sysmon_reloc() is required by the sysmon post */
}
static char *sysmon_unit_value (sysmon_table_t *s, uint val)
diff --git a/post/board/lwmon5/sysmon.c b/post/board/lwmon5/sysmon.c
index aef5bd0..9c49d0e 100644
--- a/post/board/lwmon5/sysmon.c
+++ b/post/board/lwmon5/sysmon.c
@@ -58,8 +58,6 @@ DECLARE_GLOBAL_DATA_PTR;
/* from dspic.c */
extern int dspic_read(ushort reg);
-#defineRELOC(x) if (x != NULL) x = (void *) ((ulong) (x) +
gd-reloc_off)
-
#define REG_TEMPERATURE0x12BC
#define REG_VOLTAGE_5V 0x12CA
#define REG_VOLTAGE_5V_STANDBY 0x12C6
@@ -160,20 +158,7 @@ int sysmon_init_f (void)
void sysmon_reloc (void)
{
- sysmon_t ** l;
- sysmon_table_t * t;
-
- for (l = sysmon_list; *l; l++) {
- RELOC(*l);
- RELOC((*l)-init);
- RELOC((*l)-read);
- }
-
- for (t = sysmon_table; t sysmon_table + sysmon_table_size; t ++) {
- RELOC(t-exec_before);
- RELOC(t-exec_after);
- RELOC(t-sysmon);
- }
+ /* Do nothing for now, sysmon_reloc() is required by the sysmon post */
}
static char *sysmon_unit_value (sysmon_table_t *s, uint val)
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 08/13] fpga: Remove relocation fixups
PPC boards are the only users of the current FPGA code which is littered
with manual relocation fixups. Now that proper relocation is supported
for PPC boards, remove FPGA manual relocation.
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
board/esd/pmc440/fpga.c |6 +-
board/gen860t/fpga.c |5 +-
board/matrix_vision/mvbc_p/fpga.c |7 +-
board/matrix_vision/mvblm7/fpga.c |6 +-
board/prodrive/alpr/fpga.c|4 +-
drivers/fpga/ACEX1K.c | 96 ---
drivers/fpga/altera.c | 39
drivers/fpga/cyclon2.c| 91 --
drivers/fpga/fpga.c | 53 +--
drivers/fpga/spartan2.c | 187 -
drivers/fpga/spartan3.c | 185
drivers/fpga/stratixII.c | 24 -
drivers/fpga/virtex2.c| 118 ---
drivers/fpga/xilinx.c | 42
include/ACEX1K.h |4 -
include/altera.h |1 -
include/fpga.h|2 +-
include/spartan2.h|3 -
include/spartan3.h|3 -
include/stratixII.h |1 -
include/virtex2.h |3 -
include/xilinx.h |1 -
22 files changed, 18 insertions(+), 863 deletions(-)
diff --git a/board/esd/pmc440/fpga.c b/board/esd/pmc440/fpga.c
index a2eda32..f92bbff 100644
--- a/board/esd/pmc440/fpga.c
+++ b/board/esd/pmc440/fpga.c
@@ -442,9 +442,9 @@ int pmc440_init_fpga(void)
{
char *s;
- debug(%s:%d: Initialize FPGA interface (relocation offset =
0x%.8lx)\n,
- __FUNCTION__, __LINE__, gd-reloc_off);
- fpga_init(gd-reloc_off);
+ debug(%s:%d: Initialize FPGA interface\n,
+ __FUNCTION__, __LINE__);
+ fpga_init();
fpga_serialslave_init ();
debug(%s:%d: Adding fpga 0\n, __FUNCTION__, __LINE__);
diff --git a/board/gen860t/fpga.c b/board/gen860t/fpga.c
index 29cad2e..d42c500 100644
--- a/board/gen860t/fpga.c
+++ b/board/gen860t/fpga.c
@@ -193,8 +193,9 @@ int gen860t_init_fpga (void)
{
int i;
- PRINTF (%s:%d: Initialize FPGA interface (relocation offset =
0x%.8lx)\n, __FUNCTION__, __LINE__, gd-reloc_off);
- fpga_init (gd-reloc_off);
+ PRINTF (%s:%d: Initialize FPGA interface\n,
+ __FUNCTION__, __LINE__);
+ fpga_init ();
fpga_selectmap_init ();
for (i = 0; i CONFIG_FPGA_COUNT; i++) {
diff --git a/board/matrix_vision/mvbc_p/fpga.c
b/board/matrix_vision/mvbc_p/fpga.c
index 356af1a..3ed46fe 100644
--- a/board/matrix_vision/mvbc_p/fpga.c
+++ b/board/matrix_vision/mvbc_p/fpga.c
@@ -46,7 +46,6 @@ Altera_CYC2_Passive_Serial_fns altera_fns = {
fpga_wr_fn,
fpga_null_fn,
fpga_null_fn,
- 0
};
Altera_desc cyclone2 = {
@@ -55,16 +54,14 @@ Altera_desc cyclone2 = {
Altera_EP2C8_SIZE,
(void *) altera_fns,
NULL,
- 0
};
DECLARE_GLOBAL_DATA_PTR;
int mvbc_p_init_fpga(void)
{
- fpga_debug(Initialize FPGA interface (reloc 0x%.8lx)\n,
- gd-reloc_off);
- fpga_init(gd-reloc_off);
+ fpga_debug(Initialize FPGA interface\n);
+ fpga_init();
fpga_add(fpga_altera, cyclone2);
fpga_config_fn(0, 1, 0);
udelay(60);
diff --git a/board/matrix_vision/mvblm7/fpga.c
b/board/matrix_vision/mvblm7/fpga.c
index 7527d16..7b03d6f 100644
--- a/board/matrix_vision/mvblm7/fpga.c
+++ b/board/matrix_vision/mvblm7/fpga.c
@@ -46,7 +46,6 @@ Altera_CYC2_Passive_Serial_fns altera_fns = {
fpga_wr_fn,
fpga_null_fn,
fpga_null_fn,
- 0
};
Altera_desc cyclone2 = {
@@ -62,9 +61,8 @@ DECLARE_GLOBAL_DATA_PTR;
int mvblm7_init_fpga(void)
{
- fpga_debug(Initialize FPGA interface (reloc 0x%.8lx)\n,
- gd-reloc_off);
- fpga_init(gd-reloc_off);
+ fpga_debug(Initialize FPGA interface\n);
+ fpga_init();
fpga_add(fpga_altera, cyclone2);
fpga_config_fn(0, 1, 0);
udelay(60);
diff --git a/board/prodrive/alpr/fpga.c b/board/prodrive/alpr/fpga.c
index 0ecebc9..7571cd9 100644
--- a/board/prodrive/alpr/fpga.c
+++ b/board/prodrive/alpr/fpga.c
@@ -244,8 +244,8 @@ int alpr_fpga_init (void)
{
int i;
- PRINTF (%s:%d: Initialize FPGA interface (relocation offset =
0x%.8lx)\n, __FUNCTION__, __LINE__, gd-reloc_off);
- fpga_init (gd-reloc_off);
+ PRINTF (%s:%d: Initialize FPGA interface\n, __FUNCTION__, __LINE__);
+ fpga_init ();
for (i = 0; i CONFIG_FPGA_COUNT; i++) {
PRINTF (%s:%d: Adding fpga %d\n, __FUNCTION__, __LINE__, i);
diff --git a/drivers/fpga/ACEX1K.c b/drivers/fpga/ACEX1K.c
index 3f79677..06b4247 100644
--- a/drivers/fpga/ACEX1K.c
+++ b/drivers/fpga/ACEX1K.c
@@ -51,7 +51,6 @@
static int ACEX1K_ps_load( Altera_desc *desc, void
[U-Boot] [PATCH 09/13] mpl: Remove memory test relocation fixups
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
board/mpl/common/memtst.c | 26 --
board/mpl/mip405/mip405.c |3 +--
board/mpl/pati/pati.c |2 --
board/mpl/vcma9/vcma9.c |3 ---
4 files changed, 1 insertions(+), 33 deletions(-)
diff --git a/board/mpl/common/memtst.c b/board/mpl/common/memtst.c
index 1393ea1..92c33ba 100644
--- a/board/mpl/common/memtst.c
+++ b/board/mpl/common/memtst.c
@@ -468,32 +468,6 @@ static RAM_MEMTEST_FUNC test_stage[TEST_STAGES] = {
RAM_MemTest_CheckRandomPattern, NULL}
};
-void mem_test_reloc(void)
-{
- unsigned long addr;
- int i;
- for (i=0; i TEST_STAGES; i++) {
- addr = (ulong) (test_stage[i].test_write) + gd-reloc_off;
- test_stage[i].test_write=
- (void (*) (unsigned long startaddr, unsigned long size,
- unsigned long *pat))addr;
- addr = (ulong) (test_stage[i].test_write_desc) + gd-reloc_off;
- test_stage[i].test_write_desc=(char *)addr;
- if(test_stage[i].test_check1) {
- addr = (ulong) (test_stage[i].test_check1) +
gd-reloc_off;
- test_stage[i].test_check1=
- (void *(*) (int mode, unsigned long startaddr,
-unsigned long size, unsigned long *pat))addr;
- }
- if(test_stage[i].test_check2) {
- addr = (ulong) (test_stage[i].test_check2) +
gd-reloc_off;
- test_stage[i].test_check2=
- (void *(*) (int mode, unsigned long startaddr,
-unsigned long size, unsigned long *pat))addr;
- }
- }
-}
-
int mem_test (unsigned long start, unsigned long ramsize, int quiet)
{
diff --git a/board/mpl/mip405/mip405.c b/board/mpl/mip405/mip405.c
index d8279e8..fdfa897 100644
--- a/board/mpl/mip405/mip405.c
+++ b/board/mpl/mip405/mip405.c
@@ -717,7 +717,6 @@ int post_hotkeys_pressed(void)
}
#endif
-extern void mem_test_reloc(void);
extern int mk_date (char *, struct rtc_time *);
int last_stage_init (void)
@@ -725,7 +724,7 @@ int last_stage_init (void)
unsigned long stop;
struct rtc_time newtm;
char *s;
- mem_test_reloc();
+
/* write correct LED configuration */
if (miiphy_write(ppc_4xx_eth0, 0x1, 0x14, 0x2402) != 0) {
printf (Error writing to the PHY\n);
diff --git a/board/mpl/pati/pati.c b/board/mpl/pati/pati.c
index 1b3b698..e12bc42 100644
--- a/board/mpl/pati/pati.c
+++ b/board/mpl/pati/pati.c
@@ -144,7 +144,6 @@ const sdram_t sdram_table[] = {
extern int mem_test (unsigned long start, unsigned long ramsize, int quiet);
-extern void mem_test_reloc(void);
/*
* Get RAM size.
@@ -334,7 +333,6 @@ void user_led1(int led_on)
/
int last_stage_init (void)
{
- mem_test_reloc();
init_ios();
return 0;
}
diff --git a/board/mpl/vcma9/vcma9.c b/board/mpl/vcma9/vcma9.c
index 3216d63..2b64f44 100644
--- a/board/mpl/vcma9/vcma9.c
+++ b/board/mpl/vcma9/vcma9.c
@@ -312,11 +312,8 @@ int checkboard(void)
}
-extern void mem_test_reloc(void);
-
int last_stage_init(void)
{
- mem_test_reloc();
checkboard();
stdio_print_current_devices();
check_env();
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 11/13] p3mx: Remove serial relocation fixups
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
board/prodrive/p3mx/p3mx.c | 10 --
include/configs/p3mx.h |1 -
2 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/board/prodrive/p3mx/p3mx.c b/board/prodrive/p3mx/p3mx.c
index 0247bb8..05eca52 100644
--- a/board/prodrive/p3mx/p3mx.c
+++ b/board/prodrive/p3mx/p3mx.c
@@ -316,16 +316,6 @@ int misc_init_r ()
return 0;
}
-int board_early_init_r(void)
-{
- /* now relocate the debug serial driver */
- mpsc_putchar += gd-reloc_off;
- mpsc_getchar += gd-reloc_off;
- mpsc_test_char += gd-reloc_off;
-
- return 0;
-}
-
void after_reloc (ulong dest_addr, gd_t * gd)
{
memoryMapDeviceSpace (BOOT_DEVICE, CONFIG_SYS_BOOT_SPACE,
CONFIG_SYS_BOOT_SIZE);
diff --git a/include/configs/p3mx.h b/include/configs/p3mx.h
index 5e4d30b..0749037 100644
--- a/include/configs/p3mx.h
+++ b/include/configs/p3mx.h
@@ -59,7 +59,6 @@
/* which initialization functions to call for this board */
#define CONFIG_SYS_BOARD_ASM_INIT 1
#define CONFIG_BOARD_EARLY_INIT_F 1 /* Call board_early_init_f */
-#define CONFIG_BOARD_EARLY_INIT_R 1 /* Call board_early_init_f */
#define CONFIG_MISC_INIT_R 1 /* Call misc_init_r() */
/*---
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 13/13] ppc: Remove reloc_off field from global_data structure
Now that proper relocation is supported, the reloc_off field is no longer
necessary.
Note that the location of the standalone application jump table pointer
in the global data structure is affected by this change, breaking
execution of standalone applications compiled for previous versions of
U-Boot.
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
Would others prefer an empty ulong take reloc_off's place so old
standalone apps don't break? Or perhaps we should move the jump
table pointer to the first item in global_data to prevent breakage
every time global_data is modified in the future?
include/asm-ppc/global_data.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/asm-ppc/global_data.h b/include/asm-ppc/global_data.h
index db4b1ea..55e7e20 100644
--- a/include/asm-ppc/global_data.h
+++ b/include/asm-ppc/global_data.h
@@ -24,6 +24,7 @@
#ifndef__ASM_GBL_DATA_H
#define __ASM_GBL_DATA_H
+#include config.h
#include asm/types.h
/*
@@ -124,7 +125,6 @@ typedef struct global_data {
unsigned long flb_clk;
#endif
phys_size_t ram_size; /* RAM size */
- unsigned long reloc_off; /* Relocation Offset */
unsigned long reset_status; /* reset status register at boot
*/
#if defined(CONFIG_MPC83xx)
unsigned long arbiter_event_attributes;
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 12/13] Conditionally perform common relocation fixups
Add #ifdefs where necessary to not perform relocation fixups. This
allows boards/architectures which support relocation to trim a decent
chunk of code.
Note that this patch doesn't add #ifdefs to architecture-specific code
which does not support relocation.
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
common/cmd_bootm.c |4 +++-
common/cmd_date.c |4
common/dlmalloc.c |2 ++
common/env_common.c |4
common/hush.c |4
common/image.c |6 +-
common/serial.c |2 ++
common/stdio.c |5 +++--
disk/part.c |5 -
drivers/mtd/nand/nand.c |2 ++
fs/ubifs/ubifs.c|4
include/post.h |2 ++
post/post.c |2 ++
13 files changed, 41 insertions(+), 5 deletions(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 365ceeb..8f83598 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -561,7 +561,6 @@ int do_bootm_subcommand (cmd_tbl_t *cmdtp, int flag, int
argc, char *argv[])
/***/
/* bootm - boot application image from image in memory */
/***/
-static int relocated = 0;
int do_bootm (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
{
@@ -569,6 +568,8 @@ int do_bootm (cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[])
ulong load_end = 0;
int ret;
boot_os_fn *boot_fn;
+#ifndef CONFIG_RELOC_FIXUP_WORKS
+ static int relocated = 0;
/* relocate boot function table */
if (!relocated) {
@@ -578,6 +579,7 @@ int do_bootm (cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[])
boot_os[i] += gd-reloc_off;
relocated = 1;
}
+#endif
/* determine if we have a sub command */
if (argc 1) {
diff --git a/common/cmd_date.c b/common/cmd_date.c
index b69e935..9f50f89 100644
--- a/common/cmd_date.c
+++ b/common/cmd_date.c
@@ -35,7 +35,11 @@ const char *weekdays[] = {
Sun, Mon, Tues, Wednes, Thurs, Fri, Satur,
};
+#ifdef CONFIG_RELOC_FIXUP_WORKS
+#define RELOC(a) a
+#else
#define RELOC(a) ((typeof(a))((unsigned long)(a) + gd-reloc_off))
+#endif
int mk_date (char *, struct rtc_time *);
diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index 241db8c..ca088a1 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -1494,6 +1494,7 @@ static mbinptr av_[NAV * 2 + 2] = {
IAV(120), IAV(121), IAV(122), IAV(123), IAV(124), IAV(125), IAV(126), IAV(127)
};
+#ifndef CONFIG_RELOC_FIXUP_WORKS
void malloc_bin_reloc (void)
{
unsigned long *p = (unsigned long *)(av_[2]);
@@ -1502,6 +1503,7 @@ void malloc_bin_reloc (void)
*p++ += gd-reloc_off;
}
}
+#endif
ulong mem_malloc_start = 0;
ulong mem_malloc_end = 0;
diff --git a/common/env_common.c b/common/env_common.c
index be64d13..439a4a9 100644
--- a/common/env_common.c
+++ b/common/env_common.c
@@ -224,8 +224,10 @@ void set_default_env(void)
void env_relocate (void)
{
+#ifndef CONFIG_RELOC_FIXUP_WORKS
DEBUGF (%s[%d] offset = 0x%lx\n, __FUNCTION__,__LINE__,
gd-reloc_off);
+#endif
#ifdef CONFIG_AMIGAONEG3SE
enable_nvram();
@@ -236,7 +238,9 @@ void env_relocate (void)
* The environment buffer is embedded with the text segment,
* just relocate the environment pointer
*/
+#ifndef CONFIG_RELOC_FIXUP_WORKS
env_ptr = (env_t *)((ulong)env_ptr + gd-reloc_off);
+#endif
DEBUGF (%s[%d] embedded ENV at %p\n, __FUNCTION__,__LINE__,env_ptr);
#else
/*
diff --git a/common/hush.c b/common/hush.c
index 528dd25..06c5ff8 100644
--- a/common/hush.c
+++ b/common/hush.c
@@ -3270,6 +3270,7 @@ int parse_file_outer(void)
}
#ifdef __U_BOOT__
+#ifndef CONFIG_RELOC_FIXUP_WORKS
static void u_boot_hush_reloc(void)
{
unsigned long addr;
@@ -3280,6 +3281,7 @@ static void u_boot_hush_reloc(void)
r-literal = (char *)addr;
}
}
+#endif
int u_boot_hush_start(void)
{
@@ -3290,7 +3292,9 @@ int u_boot_hush_start(void)
top_vars-next = 0;
top_vars-flg_export = 0;
top_vars-flg_read_only = 1;
+#ifndef CONFIG_RELOC_FIXUP_WORKS
u_boot_hush_reloc();
+#endif
}
return 0;
}
diff --git a/common/image.c b/common/image.c
index d0f169d..6eaf41e 100644
--- a/common/image.c
+++ b/common/image.c
@@ -513,7 +513,7 @@ char *get_table_entry_name (table_entry_t *table, char
*msg, int id)
{
for (; table-id = 0; ++table) {
if (table-id == id)
-#ifdef USE_HOSTCC
+#if defined(USE_HOSTCC) || defined(CONFIG_RELOC_FIXUP_WORKS)
return table-lname;
#else
return table-lname + gd-reloc_off;
@@ -578,7 +578,11 @@ int get_table_entry_id (table_entry_t
[U-Boot] Executing uboot from FLASH
Hello all, I am working with the AMCC PPC 405Ex. I will have very limited RAM on my production board, thus I would like u-boot to execute from FLASH rather than RAM. Has anyone else done this? I played with this a couple of days without much success. Is it do-able, without too much effort? Thanks, Mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4] ppc/85xx: Clean up mpc8572DS PCI setup code
Use new fsl_pci_init_port() that reduces amount of duplicated code in the
board ports, use IO accessors and clean up printing of status info.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
* Fix MPC85xx_DEVDISR_PCIE2/3 use of setbits_be32
board/freescale/mpc8572ds/mpc8572ds.c | 230 +++--
1 files changed, 73 insertions(+), 157 deletions(-)
diff --git a/board/freescale/mpc8572ds/mpc8572ds.c
b/board/freescale/mpc8572ds/mpc8572ds.c
index c69934c..933dd12 100644
--- a/board/freescale/mpc8572ds/mpc8572ds.c
+++ b/board/freescale/mpc8572ds/mpc8572ds.c
@@ -160,189 +160,105 @@ static struct pci_controller pcie2_hose;
static struct pci_controller pcie3_hose;
#endif
-int first_free_busno=0;
#ifdef CONFIG_PCI
void pci_init_board(void)
{
volatile ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
- uint devdisr = gur-devdisr;
- uint io_sel = (gur-pordevsr MPC85xx_PORDEVSR_IO_SEL) 19;
- uint host_agent = (gur-porbmsr MPC85xx_PORBMSR_HA) 16;
+ struct fsl_pci_info pci_info[3];
+ u32 devdisr, pordevsr, io_sel, host_agent, temp32;
+ int first_free_busno = 0;
+ int num = 0;
+
+ int pcie_ep, pcie_configured;
+
+ devdisr = in_be32(gur-devdisr);
+ pordevsr = in_be32(gur-pordevsr);
+ io_sel = (pordevsr MPC85xx_PORDEVSR_IO_SEL) 19;
+ host_agent = (in_be32(gur-porbmsr) MPC85xx_PORBMSR_HA) 16;
debug ( pci_init_board: devdisr=%x, io_sel=%x, host_agent=%x\n,
devdisr, io_sel, host_agent);
- if (!(gur-pordevsr MPC85xx_PORDEVSR_SGMII1_DIS))
+ if (!(pordevsr MPC85xx_PORDEVSR_SGMII1_DIS))
printf (eTSEC1 is in sgmii mode.\n);
- if (!(gur-pordevsr MPC85xx_PORDEVSR_SGMII2_DIS))
+ if (!(pordevsr MPC85xx_PORDEVSR_SGMII2_DIS))
printf (eTSEC2 is in sgmii mode.\n);
- if (!(gur-pordevsr MPC85xx_PORDEVSR_SGMII3_DIS))
+ if (!(pordevsr MPC85xx_PORDEVSR_SGMII3_DIS))
printf (eTSEC3 is in sgmii mode.\n);
- if (!(gur-pordevsr MPC85xx_PORDEVSR_SGMII4_DIS))
+ if (!(pordevsr MPC85xx_PORDEVSR_SGMII4_DIS))
printf (eTSEC4 is in sgmii mode.\n);
-
+ puts(\n);
#ifdef CONFIG_PCIE3
- {
- volatile ccsr_fsl_pci_t *pci = (ccsr_fsl_pci_t *)
CONFIG_SYS_PCIE3_ADDR;
- struct pci_controller *hose = pcie3_hose;
- int pcie_ep = is_fsl_pci_agent(LAW_TRGT_IF_PCIE_3, host_agent);
- int pcie_configured = is_fsl_pci_cfg(LAW_TRGT_IF_PCIE_3,
io_sel);
- struct pci_region *r = hose-regions;
- u32 temp32;
-
- if (pcie_configured !(devdisr MPC85xx_DEVDISR_PCIE3)){
- printf (\nPCIE3 connected to ULI as %s (base
address %x),
- pcie_ep ? End Point : Root Complex,
- (uint)pci);
- if (pci-pme_msg_det) {
- pci-pme_msg_det = 0x;
- debug ( with errors. Clearing. Now
0x%08x,pci-pme_msg_det);
- }
- printf (\n);
-
- /* outbound memory */
- pci_set_region(r++,
- CONFIG_SYS_PCIE3_MEM_BUS,
- CONFIG_SYS_PCIE3_MEM_PHYS,
- CONFIG_SYS_PCIE3_MEM_SIZE,
- PCI_REGION_MEM);
-
- /* outbound io */
- pci_set_region(r++,
- CONFIG_SYS_PCIE3_IO_BUS,
- CONFIG_SYS_PCIE3_IO_PHYS,
- CONFIG_SYS_PCIE3_IO_SIZE,
- PCI_REGION_IO);
-
- hose-region_count = r - hose-regions;
- hose-first_busno=first_free_busno;
-
- fsl_pci_init(hose, (u32)pci-cfg_addr,
(u32)pci-cfg_data);
-
- first_free_busno=hose-last_busno+1;
- printf (PCIE3 on bus %02x - %02x\n,
- hose-first_busno,hose-last_busno);
-
- /*
-* Activate ULI1575 legacy chip by performing a fake
-* memory access. Needed to make ULI RTC work.
-* Device 1d has the first on-board memory BAR.
-*/
-
- pci_hose_read_config_dword(hose, PCI_BDF(2, 0x1d, 0 ),
- PCI_BASE_ADDRESS_1, temp32);
- if (temp32 = CONFIG_SYS_PCIE3_MEM_BUS) {
- void *p = pci_mem_to_virt(PCI_BDF(2, 0x1d, 0),
- temp32, 4, 0);
-
Re: [U-Boot] RFC: split ARM repo and distribute workload
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wolfgang Denk Sent: Monday, September 21, 2009 6:14 PM To: Jean-Christophe PLAGNIOL-VILLARD Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] RFC: split ARM repo and distribute workload Dear Jean-Christophe, in message 20090921113701.gp29...@game.jcrosoft.org you wrote: Atmel (AT91): Jean-Christophe Plagniol-Villard Marvell (PXA + IXP): Jean-Christophe Plagniol-Villard I decline it Thank you for the clear statement. Thanks again for the work you did in the past. May I inquire what your plans are for other development tasks which you said in the past you were working on (generic cache support for ARM, Kconfig, etc.)? Will you continue this work and submit any patches for these? If so, when might this happen? Tom, I suggest we proceed as follows: - IXP and PXA are really low traffic these days (EOL products); I think we can give up these repositories and just ran this through the generic ARM repo. I would love to own this one too. But I will check if somebody more capable in Marvell can help to own this activity. Regards.. Prafulla . . - AT91 needs a new custodian. Let's see if someone volunteers. Until then, please try to pick up related patches directly. 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 inappropriate cannot be beautiful. - Frank Lloyd Wright _The Future of Architecture_ (1953) ___ 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 v4] Support for the OpenRD base board
-Original Message- From: Simon Kagstrom [mailto:simon.kagst...@netinsight.net] Sent: Monday, September 21, 2009 4:24 PM To: U-Boot ML Cc: Prafulla Wadaskar; Dhaval Vasa; Prabhanjan Sarnaik; Ashish Karkare Subject: Re: [U-Boot] [PATCH v4] Support for the OpenRD base board The implementation is borrowed from the sheevaplug board and the Marvell 1.1.4 code. Unsupported (or untested) is the SD card, PCIe and SATA. Signed-off-by: Simon Kagstrom simon.kagst...@netinsight.net --- I get run-time problems when building for armv5te for OpenRD base (apparently the same problem occurs for other Kirkwood boards). ChangeLog: v2: kwbimage.cfg, which is needed to produce an image to install on the NAND flash, has been added v3: Updated after Prafullas review: * Correct typo in comment section :-) * Update copyright references * Correct bit meaning in kwbimage.cfg according to new specification * Add empty line after MPP configuration * Use short name for board identity string in config * Use CONFIG_SHEEVA_88SV131 instead of Feroceon * Add CONFIG_KIRKWOOD_PCIE_INIT to config * Use config_cmd_default.h and remove options which are not needed anymore * Move config address to 0x6 (384KB). I'd like it at this address since adding UBI/UBIFS support to U-boot makes the binary a bit more than 300KB and would thus overlap a config address at 0x4. Not updated in v3: * The default MTD options are kept (useful for UBIFS) * eth init is not done, this needs to be done in a generic way v4: Updated after Prafullas second review: * Remove the double title line * Change the description to note what's not tested * Re-enable UBIFS since the bitops patch was merged Oh that's great, so it's perfect now. Thanks for the reviews, Prafulla! That's my pleasure too :-) Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/13] ppc: Remove pci config table pointer relocation fixups
On Mon, Sep 21, 2009 at 12:20 PM, Peter Tyser pty...@xes-inc.com wrote:
Signed-off-by: Peter Tyser pty...@xes-inc.com
It looks like something happened during the send of your patches;
it seems the long log of what you are trying to fix and how the patch
fixes it is missing here and from several of the other patches
as well.
---
board/freescale/mpc8548cds/mpc8548cds.c | 7 ---
board/mpl/common/pci.c | 18 --
board/sbc8548/sbc8548.c | 6 --
3 files changed, 0 insertions(+), 31 deletions(-)
diff --git a/board/freescale/mpc8548cds/mpc8548cds.c
b/board/freescale/mpc8548cds/mpc8548cds.c
index 80de6f8..73e7c21 100644
--- a/board/freescale/mpc8548cds/mpc8548cds.c
+++ b/board/freescale/mpc8548cds/mpc8548cds.c
@@ -276,7 +276,6 @@ pci_init_board(void)
{
volatile ccsr_fsl_pci_t *pci = (ccsr_fsl_pci_t *) CONFIG_SYS_PCI1_ADDR;
struct pci_controller *hose = pci1_hose;
- struct pci_config_table *table;
struct pci_region *r = hose-regions;
uint pci_32 = gur-pordevsr MPC85xx_PORDEVSR_PCI1_PCI32; /*
PORDEVSR[15] */
@@ -312,12 +311,6 @@ pci_init_board(void)
PCI_REGION_IO);
hose-region_count = r - hose-regions;
- /* relocate config table pointers */
- hose-config_table = \
- (struct pci_config_table *)((uint)hose-config_table
+ gd-reloc_off);
- for (table = hose-config_table; table table-vendor;
table++)
- table-config_device += gd-reloc_off;
For the mpc8548cds, if this removal was somehow the right thing to do,
it would still be incomplete; I am sure that there is a dummy function
related to a PCI bridge quirk associated with the above change that
would now be orphaned in the code.
-
hose-first_busno=first_free_busno;
fsl_pci_init(hose, (u32)pci-cfg_addr, (u32)pci-cfg_data);
[...]
diff --git a/board/sbc8548/sbc8548.c b/board/sbc8548/sbc8548.c
index e5b21b5..5cdfef4 100644
--- a/board/sbc8548/sbc8548.c
+++ b/board/sbc8548/sbc8548.c
@@ -392,12 +392,6 @@ pci_init_board(void)
PCI_REGION_IO);
hose-region_count = r - hose-regions;
- /* relocate config table pointers */
- hose-config_table = \
- (struct pci_config_table *)((uint)hose-config_table
+ gd-reloc_off);
- for (table = hose-config_table; table table-vendor;
table++)
- table-config_device += gd-reloc_off;
This code is already gone from the sbc8548 in the 85xx branch;
the sbc8548 didn't need the bridge quirk fixup.
Paul.
-
hose-first_busno=first_free_busno;
fsl_pci_init(hose, (u32)pci-cfg_addr, (u32)pci-cfg_data);
--
1.6.2.1
___
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 04/13] ppc: Remove pci config table pointer relocation fixups
On Mon, 2009-09-21 at 12:49 -0400, Paul Gortmaker wrote:
On Mon, Sep 21, 2009 at 12:20 PM, Peter Tyser pty...@xes-inc.com wrote:
Signed-off-by: Peter Tyser pty...@xes-inc.com
It looks like something happened during the send of your patches;
it seems the long log of what you are trying to fix and how the patch
fixes it is missing here and from several of the other patches
as well.
I didn't put long log messages in patches which I thought would be clear
what was changing. All the Remove XYZ relocation fixups are intended
to only remove no longer needed fixups. They shouldn't (hopefully) have
any functional change. I can add log messages, but they will all be the
same don't fixup xyz as relocation now works.
---
board/freescale/mpc8548cds/mpc8548cds.c |7 ---
board/mpl/common/pci.c | 18 --
board/sbc8548/sbc8548.c |6 --
3 files changed, 0 insertions(+), 31 deletions(-)
diff --git a/board/freescale/mpc8548cds/mpc8548cds.c
b/board/freescale/mpc8548cds/mpc8548cds.c
index 80de6f8..73e7c21 100644
--- a/board/freescale/mpc8548cds/mpc8548cds.c
+++ b/board/freescale/mpc8548cds/mpc8548cds.c
@@ -276,7 +276,6 @@ pci_init_board(void)
{
volatile ccsr_fsl_pci_t *pci = (ccsr_fsl_pci_t *)
CONFIG_SYS_PCI1_ADDR;
struct pci_controller *hose = pci1_hose;
- struct pci_config_table *table;
struct pci_region *r = hose-regions;
uint pci_32 = gur-pordevsr MPC85xx_PORDEVSR_PCI1_PCI32; /*
PORDEVSR[15] */
@@ -312,12 +311,6 @@ pci_init_board(void)
PCI_REGION_IO);
hose-region_count = r - hose-regions;
- /* relocate config table pointers */
- hose-config_table = \
- (struct pci_config_table
*)((uint)hose-config_table + gd-reloc_off);
- for (table = hose-config_table; table table-vendor;
table++)
- table-config_device += gd-reloc_off;
For the mpc8548cds, if this removal was somehow the right thing to do,
it would still be incomplete; I am sure that there is a dummy function
related to a PCI bridge quirk associated with the above change that
would now be orphaned in the code.
I didn't intend to make any functional change as I know nothing about
this board:) I only intended to remove the references to gd-reloc_off.
I looked over this code quickly and came to the conclusion I wasn't
changing any functionality, let me know if I'm missing something.
-
hose-first_busno=first_free_busno;
fsl_pci_init(hose, (u32)pci-cfg_addr, (u32)pci-cfg_data);
[...]
diff --git a/board/sbc8548/sbc8548.c b/board/sbc8548/sbc8548.c
index e5b21b5..5cdfef4 100644
--- a/board/sbc8548/sbc8548.c
+++ b/board/sbc8548/sbc8548.c
@@ -392,12 +392,6 @@ pci_init_board(void)
PCI_REGION_IO);
hose-region_count = r - hose-regions;
- /* relocate config table pointers */
- hose-config_table = \
- (struct pci_config_table
*)((uint)hose-config_table + gd-reloc_off);
- for (table = hose-config_table; table table-vendor;
table++)
- table-config_device += gd-reloc_off;
This code is already gone from the sbc8548 in the 85xx branch;
the sbc8548 didn't need the bridge quirk fixup.
Thanks for the heads up. Maybe git will gracefully handle this change?
If not, I'd prefer to wait till Wolfgang attempts to merge this patch as
other things may be merged between now and then and I'd rather just send
1 cleanup patch series.
Best,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] sbc8548: remove eTSEC3/4 voltage hack
On Sep 20, 2009, at 7:36 PM, Paul Gortmaker wrote: With only eTSEC1 and 2 being brought out to RJ-45 connectors, we aren't interested in the eTSEC3/4 voltage hack on this board Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com --- board/sbc8548/sbc8548.c |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) applied to 85xx. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] sbc8548: use I/O accessors
On Sep 20, 2009, at 7:36 PM, Paul Gortmaker wrote: Sweep throught the board specific file and replace the various register proddings with the equivalent I/O accessors. Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com --- board/sbc8548/sbc8548.c | 91 ++ + 1 files changed, 45 insertions(+), 46 deletions(-) applied to 85xx. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] sbc8548: correct local bus SDRAM size from 64M to 128M
On Sep 20, 2009, at 7:36 PM, Paul Gortmaker wrote: The size of the LB SDRAM on this board is 128MB, spanning CS3 and CS4. It was previously only being configured for 64MB on CS3, since that was what the original codebase of the MPC8548CDS had. In addition to setting up BR4/OR4, this also adds the TLB entry for the second half of the SDRAM. Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com --- board/sbc8548/sbc8548.c |8 +++- board/sbc8548/tlb.c | 22 +++--- include/configs/sbc8548.h | 42 ++ 3 files changed, 60 insertions(+), 12 deletions(-) applied to 85xx. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] fsl_pci: create a SET_STD_PCI_INFO() helper wrapper
On Sep 20, 2009, at 7:36 PM, Paul Gortmaker wrote: Recycle the recently added PCI-e wrapper used to reduce board duplication of code by creating a similar version for plain PCI. Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com --- include/asm-ppc/fsl_pci.h | 12 1 files changed, 12 insertions(+), 0 deletions(-) applied to 85xx. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] sbc8548: update PCI/PCI-e support code
On Sep 20, 2009, at 7:36 PM, Paul Gortmaker wrote: The PCI/PCI-e support for the sbc8548 was based on an earlier version of what the MPC8548CDS board was using, and in its current state it won't even compile. This re-syncs it to match the latest codebase and makes use of the new shared PCI functions to reduce board duplication. It borrows from the MPC8568MDS, in that it pulls the PCI-e I/O back to 0xe280_ (where PCI2 would be on MPC8548CDS), and similarly it coalesces the PCI and PCI-e mem into one single TLB. Both PCI-x and PCI-e have been tested with intel e1000 cards under linux (with an accompanying dts change in place) Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com --- board/sbc8548/law.c | 12 - board/sbc8548/sbc8548.c | 129 + +--- board/sbc8548/tlb.c | 48 +++- include/configs/sbc8548.h | 45 --- 4 files changed, 94 insertions(+), 140 deletions(-) applied to 85xx. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2 v5] MAKEALL: Add summary information
This change adds some basic summary information to the MAKEALL script.
The summary information includes how many boards were compiled, how many
boards had compile warnings or errors, and which specific boards had
compile warnings or errors.
This information is useful when doing compile testing to quickly
determine which boards are broken.
As a side benefit, no empty $BOARD.ERR files are generated by MAKEALL.
Previously, each board had a corresponding $BOARD.ERR file, even if the
board compiled cleanly.
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
Changes since v1:
- Fix issue where summary was printed multiple times when a list
was composed of sublists
Changes since v2:
- Update script to only use POSIX arithmetic
Changes since v3:
- Remove unnecessary expansion of variables inside of $(( ... ))
Changes since v4:
- Catch additional termination signals
- Use signal 0 to trigger printing of stats
- Break POSIX math change into a separate patch
MAKEALL | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/MAKEALL b/MAKEALL
index 1d50c34..fd06d8d 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -1,5 +1,9 @@
#!/bin/sh
+# Print statistics when we exit
+trap exit 1 2 3 15
+trap print_stats 0
+
# Determine number of CPU cores if no default was set
: ${BUILD_NCPUS:=`getconf _NPROCESSORS_ONLN`}
@@ -31,6 +35,11 @@ fi
LIST=
+# Keep track of the number of builds and errors
+ERR_CNT=0
+ERR_LIST=
+TOTAL_CNT=0
+
#
## MPC5xx Systems
#
@@ -900,6 +909,14 @@ build_target() {
${MAKE} ${JOBS} all 21 ${LOG_DIR}/$target.MAKELOG \
| tee ${LOG_DIR}/$target.ERR
+ if [ -s ${LOG_DIR}/$target.ERR ] ; then
+ ERR_CNT=$((ERR_CNT + 1))
+ ERR_LIST=${ERR_LIST} $target
+ else
+ rm ${LOG_DIR}/$target.ERR
+ fi
+
+ TOTAL_CNT=$((TOTAL_CNT + 1))
${CROSS_COMPILE}size ${BUILD_DIR}/u-boot \
| tee -a ${LOG_DIR}/$target.MAKELOG
@@ -907,7 +924,17 @@ build_target() {
#---
+print_stats() {
+ echo
+ echo - SUMMARY
+ echo Boards compiled: ${TOTAL_CNT}
+ if [ ${ERR_CNT} -gt 0 ] ; then
+ echo Boards with warnings or errors: ${ERR_CNT} (${ERR_LIST} )
+ fi
+ echo --
+}
+#---
for arg in $@
do
case $arg in
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2 v5] MAKEALL: Use POSIX math
Signed-off-by: Peter Tyser pty...@xes-inc.com --- MAKEALL |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/MAKEALL b/MAKEALL index fd06d8d..1e7ec20 100755 --- a/MAKEALL +++ b/MAKEALL @@ -9,7 +9,7 @@ trap print_stats 0 if [ $BUILD_NCPUS -gt 1 ] then - JOBS=-j`expr $BUILD_NCPUS + 1` + JOBS=-j $((BUILD_NCPUS + 1)) else JOBS= fi -- 1.6.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] Marvell Pull Request
Hi Wolfgang Please pull The following changes since commit 3b6a9267f0de7b85d387fa4123d0b58379363447: Wolfgang Denk (1): board/flagadm/flash.c: fix compile warning are available in the git repository at: git://git.denx.de/u-boot-marvell.git master Prafulla Wadaskar (2): Kirkwood: rd6281a: Add kwbimage build support Kirkwood: mv88f6281gtw_ge: Add kwbimage build support Simon Kagstrom (1): Support for the OpenRD base board MAINTAINERS|4 + MAKEALL|1 + Makefile |3 + board/Marvell/mv88f6281gtw_ge/config.mk|3 + board/Marvell/mv88f6281gtw_ge/kwbimage.cfg | 165 + board/Marvell/openrd_base/Makefile | 56 +++ board/Marvell/openrd_base/config.mk| 33 board/Marvell/openrd_base/kwbimage.cfg | 168 + board/Marvell/openrd_base/openrd_base.c| 160 board/Marvell/openrd_base/openrd_base.h| 46 ++ board/Marvell/rd6281a/config.mk|3 + board/Marvell/rd6281a/kwbimage.cfg | 167 + include/configs/openrd_base.h | 220 13 files changed, 1029 insertions(+), 0 deletions(-) create mode 100644 board/Marvell/mv88f6281gtw_ge/kwbimage.cfg create mode 100644 board/Marvell/openrd_base/Makefile create mode 100644 board/Marvell/openrd_base/config.mk create mode 100644 board/Marvell/openrd_base/kwbimage.cfg create mode 100644 board/Marvell/openrd_base/openrd_base.c create mode 100644 board/Marvell/openrd_base/openrd_base.h create mode 100644 board/Marvell/rd6281a/kwbimage.cfg create mode 100644 include/configs/openrd_base.h Regards.. Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/13] ppc: Remove pci config table pointer relocation fixups
Peter Tyser wrote:
On Mon, 2009-09-21 at 12:49 -0400, Paul Gortmaker wrote:
On Mon, Sep 21, 2009 at 12:20 PM, Peter Tyser pty...@xes-inc.com wrote:
Signed-off-by: Peter Tyser pty...@xes-inc.com
It looks like something happened during the send of your patches;
it seems the long log of what you are trying to fix and how the patch
fixes it is missing here and from several of the other patches
as well.
I didn't put long log messages in patches which I thought would be clear
what was changing. All the Remove XYZ relocation fixups are intended
to only remove no longer needed fixups. They shouldn't (hopefully) have
any functional change. I can add log messages, but they will all be the
same don't fixup xyz as relocation now works.
I guess even something as basic as that would be better than
nothing in my opinion. Folks rummaging through history won't
have the benefit of your [0/13] description when they are
looking through the change history with git.
---
board/freescale/mpc8548cds/mpc8548cds.c |7 ---
board/mpl/common/pci.c | 18 --
board/sbc8548/sbc8548.c |6 --
3 files changed, 0 insertions(+), 31 deletions(-)
diff --git a/board/freescale/mpc8548cds/mpc8548cds.c
b/board/freescale/mpc8548cds/mpc8548cds.c
index 80de6f8..73e7c21 100644
--- a/board/freescale/mpc8548cds/mpc8548cds.c
+++ b/board/freescale/mpc8548cds/mpc8548cds.c
@@ -276,7 +276,6 @@ pci_init_board(void)
{
volatile ccsr_fsl_pci_t *pci = (ccsr_fsl_pci_t *)
CONFIG_SYS_PCI1_ADDR;
struct pci_controller *hose = pci1_hose;
- struct pci_config_table *table;
struct pci_region *r = hose-regions;
uint pci_32 = gur-pordevsr MPC85xx_PORDEVSR_PCI1_PCI32; /*
PORDEVSR[15] */
@@ -312,12 +311,6 @@ pci_init_board(void)
PCI_REGION_IO);
hose-region_count = r - hose-regions;
- /* relocate config table pointers */
- hose-config_table = \
- (struct pci_config_table
*)((uint)hose-config_table + gd-reloc_off);
- for (table = hose-config_table; table table-vendor;
table++)
- table-config_device += gd-reloc_off;
For the mpc8548cds, if this removal was somehow the right thing to do,
it would still be incomplete; I am sure that there is a dummy function
related to a PCI bridge quirk associated with the above change that
would now be orphaned in the code.
I didn't intend to make any functional change as I know nothing about
this board:) I only intended to remove the references to gd-reloc_off.
I looked over this code quickly and came to the conclusion I wasn't
changing any functionality, let me know if I'm missing something.
OK, I just went and looked, and I think that you are correct.
The config_table with the dummy function is still hooked in via
the static pci1_hose initialization; sorry for the noise.
-
hose-first_busno=first_free_busno;
fsl_pci_init(hose, (u32)pci-cfg_addr, (u32)pci-cfg_data);
[...]
diff --git a/board/sbc8548/sbc8548.c b/board/sbc8548/sbc8548.c
index e5b21b5..5cdfef4 100644
--- a/board/sbc8548/sbc8548.c
+++ b/board/sbc8548/sbc8548.c
@@ -392,12 +392,6 @@ pci_init_board(void)
PCI_REGION_IO);
hose-region_count = r - hose-regions;
- /* relocate config table pointers */
- hose-config_table = \
- (struct pci_config_table
*)((uint)hose-config_table + gd-reloc_off);
- for (table = hose-config_table; table table-vendor;
table++)
- table-config_device += gd-reloc_off;
This code is already gone from the sbc8548 in the 85xx branch;
the sbc8548 didn't need the bridge quirk fixup.
Thanks for the heads up. Maybe git will gracefully handle this change?
Depends on your definition of gracefully, I guess. :-)
If not, I'd prefer to wait till Wolfgang attempts to merge this patch as
other things may be merged between now and then and I'd rather just send
1 cleanup patch series.
Makes sense.
Paul.
Best,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] Support for the OpenRD base board
-Original Message- From: Simon Kagstrom [mailto:simon.kagst...@netinsight.net] Sent: Monday, September 21, 2009 4:24 PM To: U-Boot ML Cc: Prafulla Wadaskar; Dhaval Vasa; Prabhanjan Sarnaik; Ashish Karkare Subject: Re: [U-Boot] [PATCH v4] Support for the OpenRD base board The implementation is borrowed from the sheevaplug board and the Marvell 1.1.4 code. Unsupported (or untested) is the SD card, PCIe and SATA. Signed-off-by: Simon Kagstrom simon.kagst...@netinsight.net --- I get run-time problems when building for armv5te for OpenRD base (apparently the same problem occurs for other Kirkwood boards). ChangeLog: v2: kwbimage.cfg, which is needed to produce an image to install on the NAND flash, has been added v3: Updated after Prafullas review: * Correct typo in comment section :-) * Update copyright references * Correct bit meaning in kwbimage.cfg according to new specification * Add empty line after MPP configuration * Use short name for board identity string in config * Use CONFIG_SHEEVA_88SV131 instead of Feroceon * Add CONFIG_KIRKWOOD_PCIE_INIT to config * Use config_cmd_default.h and remove options which are not needed anymore * Move config address to 0x6 (384KB). I'd like it at this address since adding UBI/UBIFS support to U-boot makes the binary a bit more than 300KB and would thus overlap a config address at 0x4. Not updated in v3: * The default MTD options are kept (useful for UBIFS) * eth init is not done, this needs to be done in a generic way v4: Updated after Prafullas second review: * Remove the double title line * Change the description to note what's not tested * Re-enable UBIFS since the bitops patch was merged Thanks for the reviews, Prafulla! MAINTAINERS |4 + MAKEALL |1 + Makefile|3 + board/Marvell/openrd_base/Makefile | 56 board/Marvell/openrd_base/config.mk | 33 + board/Marvell/openrd_base/kwbimage.cfg | 168 +++ board/Marvell/openrd_base/openrd_base.c | 160 ++ board/Marvell/openrd_base/openrd_base.h | 46 +++ include/configs/openrd_base.h | 220 +++ 9 files changed, 691 insertions(+), 0 deletions(-) create mode 100644 board/Marvell/openrd_base/Makefile create mode 100644 board/Marvell/openrd_base/config.mk create mode 100644 board/Marvell/openrd_base/kwbimage.cfg create mode 100644 board/Marvell/openrd_base/openrd_base.c create mode 100644 board/Marvell/openrd_base/openrd_base.h create mode 100644 include/configs/openrd_base.h Applied to u-boot-marvell master branch Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Kirkwood: mv88f6281gtw_ge: Add kwbimage build support
-Original Message- From: Prafulla Wadaskar [mailto:prafu...@marvell.com] Sent: Monday, September 21, 2009 8:28 PM To: u-boot@lists.denx.de Cc: Prabhanjan Sarnaik; Ashish Karkare; Prafulla Wadaskar Subject: [PATCH] Kirkwood: mv88f6281gtw_ge: Add kwbimage build support This patch adds kwbimage configuration file (used by mkimage utility) to support u-boot.kwb target on mv88f6281gtw_ge board. To create Kirkwood boot image to be flashed on SPI Flash, additional parameter u-boot.kwb need to be passed during make. Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- board/Marvell/mv88f6281gtw_ge/config.mk|3 + board/Marvell/mv88f6281gtw_ge/kwbimage.cfg | 165 2 files changed, 168 insertions(+), 0 deletions(-) create mode 100644 board/Marvell/mv88f6281gtw_ge/kwbimage.cfg Applied to u-boot-marvell master branch Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Kirkwood: rd6281a: Add kwbimage build support
-Original Message- From: Prafulla Wadaskar [mailto:prafu...@marvell.com] Sent: Monday, September 21, 2009 8:28 PM To: u-boot@lists.denx.de Cc: Prabhanjan Sarnaik; Ashish Karkare; Prafulla Wadaskar Subject: [PATCH] Kirkwood: rd6281a: Add kwbimage build support This patch adds kwbimage configuration file (used by mkimage utility) to support u-boot.kwb target on rd6281a platform. To create Kirkwood boot image to be flashed on NAND, additional parameter u-boot.kwb need to be passed during make. Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- board/Marvell/rd6281a/config.mk|3 + board/Marvell/rd6281a/kwbimage.cfg | 167 2 files changed, 170 insertions(+), 0 deletions(-) create mode 100644 board/Marvell/rd6281a/kwbimage.cfg Applied to u-boot-marvell master branch Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add MII bus implementation for FCC ports (using bitbanging)
On Sat, Sep 19, 2009 at 05:39:37PM +0200, Luigi 'Comio' Mantellini wrote:
+/*
+ *
+ * Utility to send the preamble, address, and register (common to read
+ * and write).
+ */
+static void mpc85xx_miiphy_pre (struct ether_fcc_info_s *info, char read,
unsigned char addr, unsigned char reg)
+{
+ int j; /* counter */
+
+ int mdio = info-mdiopin;
+ int mdc = info-mdcpin;
+
+ /*
+ * Send a 32 bit preamble ('1's) with an extra '1' bit for good measure.
+ * The IEEE spec says this is a PHY optional requirement. The AMD
+ * 79C874 requires one after power up and one after a MII communications
+ * error. This means that we are doing more preambles than we need,
+ * but it is safer and will be much more robust.
+ */
+
+ mpc85xx_mdio_active(mdio);
+ mpc85xx_mdc_active(mdc);
+ mpc85xx_mdio_set(mdio, 1);
+
+ for (j = 0; j 32; j++) {
+ mpc85xx_mdc_set(mdc, 0);
+ mpc85xx_udelay(1);
+ mpc85xx_mdc_set(mdc, 1);
+ mpc85xx_udelay(1);
+ }
+
+ /* send the start bit (01) and the read opcode (10) or write (10) */
+ mpc85xx_mdc_set(mdc, 0);
+ mpc85xx_mdio_set(mdio, 0);
+ mpc85xx_udelay(1);
+ mpc85xx_mdc_set(mdc, 1);
+ mpc85xx_udelay(1);
+ mpc85xx_mdc_set(mdc, 0);
+ mpc85xx_mdio_set(mdio, 1);
+ mpc85xx_udelay(1);
Please do not duplicate this. Use the existing code in
drivers/net/phy/miiphybb.c, refactoring it if necessary.
Also, please attribute and preserve copyrights when you copy large chunks
of code.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] sbc8548: allow enabling PCI via a make config option
On Sep 20, 2009, at 7:36 PM, Paul Gortmaker wrote: Prior to this commit, to enable PCI, you had to go manually edit the board config header, and if you had 33MHz PCI, you had to manually change CONFIG_SYS_NS16550_CLK too, which was not real user friendly, This adds the typical PCI and clock speed make targets to the toplevel Makefile in accordance with what is being done with other boards (i.e. using the -t to mkconfig). Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com --- MAKEALL |4 Makefile |8 ++-- include/configs/sbc8548.h | 43 +-- 3 files changed, 43 insertions(+), 12 deletions(-) applied to 85xx. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Warning Bad CRC
Dear Rahanesh, In message 4ab786b9.4080...@tataelxsi.co.in you wrote: U-Boot 1.1.2 (Sep 19 2009 - 10:26:28) Board: IAD CPU Speed 200 MHz DRAM: 32 MB sflash.c:266:DF_F_DataflashProbe: Entered sflash.c:269:DF_F_DataflashProbe: flash type is 0x1 sflash.c:270:DF_F_DataflashProbe: num pages 32768 DataFlash:Nb pages: 32768 Page Size:256 Size=3D 8388608 bytes Logical address: 0xAD00 Nb Erase Blocks:128 Erase Block Size: 65536 Area 0: AD00 to AD003FFF Area 1: AD004000 to AD03 Area 2: AD04 to AD30BFFF Area 3: AD30C000 to AD7F got bad crc. got:0x603b0489, expected:0x0 *** Warning - bad CRC, using default environment Ah! Here you can see that the CRC is incorrect in U-Boot already, so why do you expect to see a different result when using fw_printenv? WHen the CRC _is_ incorrect, both U-Boot and fw_printenv will report this fact in the same way. *Print message after execution of saveenv command from uboot : *Saving Environment to dataflash... copy 0xad03-0xad04 to saveenv-buf 0x8010. erasing 0xad03 - 0xad03 Erasing sectors 0x3 to 0x3 sflash.c:69:DF_F_PageErase: erasing page: 0x3 done erasingsflash.c:164:DF_F_DataFlashWrite: write: src 0x8010, dst=20 0x3, size 0x1 I have no idea what sort of code you might be using there, there is no such file as 'sflash.c' in the mainline U-Boot code. And U-Boot 1.1.2 is old. I mean: OLD. Really, really OLD. Nearly 5 years old. Please consider it completely unsupported at this time. Please update and use recent code instead. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. - Doug Gwyn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: split ARM repo and distribute workload
Wolfgang Denk wrote: Dear Jean-Christophe, in message 20090921113701.gp29...@game.jcrosoft.org you wrote: Atmel (AT91): Jean-Christophe Plagniol-Villard Marvell (PXA + IXP):Jean-Christophe Plagniol-Villard I decline it Thank you for the clear statement. Thanks again for the work you did in the past. May I inquire what your plans are for other development tasks which you said in the past you were working on (generic cache support for ARM, Kconfig, etc.)? Will you continue this work and submit any patches for these? If so, when might this happen? Tom, I suggest we proceed as follows: - IXP and PXA are really low traffic these days (EOL products); I think we can give up these repositories and just ran this through the generic ARM repo. OK. - AT91 needs a new custodian. Let's see if someone volunteers. Until then, please try to pick up related patches directly. OK Best regards, Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Executing uboot from FLASH
Dear Mike Breneman, In message b0a7af226b49a14897036e9b3a68cffecb1ab0f...@hq-exch-7.corp.brocade.com you wrote: I am working with the AMCC PPC 405Ex. I will have very limited RAM on my production board, thus I would like u-boot to execute from How much is very limited ? If you want to use that board for any reasonable pourposes, which justify the use of a boot loader like U-Boot, then you probably have more than enough RAM to run U-Boot. FLASH rather than RAM. Has anyone else done this? I played with this a couple of days with out much success. Is it do-able, without too much effort? It would be significant effort. And it makes not much sense, as you would lose a lot of basic functionality, resp. have to work around the resulting restrictions. It doesn't make sense to me. Rather think how to make it fit into avilable RAM. How much RAM do you have? 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 light at the end of the tunnel is usually a No Exit sign. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: split ARM repo and distribute workload
Dear Prafulla, in message 73173d32e9439e4abb5151606c3e19e202ed512...@sc-vexch1.marvell.com you wrote: - IXP and PXA are really low traffic these days (EOL products); I think we can give up these repositories and just ran this through the generic ARM repo. I would love to own this one too. But I will check if somebody more capable in Marvell can help to own this activity. Given the low traffic for these processors I think we can stop having a separate repository. If you want to care about this, we can run this through the existing u-boot-marvell repository, which is only logical. Thanks for your help. 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 who knows history, particularly the history of Europe, will, I think, recognize that the domination of education or of government by any one particular religious faith is never a happy arrangement for the people. - Eleanor Roosevelt ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: split ARM repo and distribute workload
Prafulla Wadaskar wrote: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wolfgang Denk Sent: Monday, September 21, 2009 6:14 PM To: Jean-Christophe PLAGNIOL-VILLARD Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] RFC: split ARM repo and distribute workload Dear Jean-Christophe, in message 20090921113701.gp29...@game.jcrosoft.org you wrote: Atmel (AT91): Jean-Christophe Plagniol-Villard Marvell (PXA + IXP): Jean-Christophe Plagniol-Villard I decline it Thank you for the clear statement. Thanks again for the work you did in the past. May I inquire what your plans are for other development tasks which you said in the past you were working on (generic cache support for ARM, Kconfig, etc.)? Will you continue this work and submit any patches for these? If so, when might this happen? Tom, I suggest we proceed as follows: - IXP and PXA are really low traffic these days (EOL products); I think we can give up these repositories and just ran this through the generic ARM repo. I would love to own this one too. But I will check if somebody more capable in Marvell can help to own this activity. If the traffic was low, I would just as well kill off the pxa and ixp repo's. Tom Regards.. Prafulla . . - AT91 needs a new custodian. Let's see if someone volunteers. Until then, please try to pick up related patches directly. 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 inappropriate cannot be beautiful. - Frank Lloyd Wright _The Future of Architecture_ (1953) ___ 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Executing uboot from FLASH
Thanks for the response. Currently the processor will have 128KB of RAM. It will be running a small footprint RTOS. This processor is sort of a co-processor which offloads the main CPU for certain tasks. It is basically replacing an FPGA as it is a cheaper solution. I will check if I can bump the RAM to 256 or 512KB. I began to suspect it would be a sizeable effort to modify u-boot to execute from FLASH, thanks for confirming. Regards, Mike -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wolfgang Denk Sent: Monday, September 21, 2009 10:46 AM To: Mike Breneman Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Executing uboot from FLASH Dear Mike Breneman, In message b0a7af226b49a14897036e9b3a68cffecb1ab0f...@hq-exch-7.corp.brocade.com you wrote: I am working with the AMCC PPC 405Ex. I will have very limited RAM on my production board, thus I would like u-boot to execute from How much is very limited ? If you want to use that board for any reasonable pourposes, which justify the use of a boot loader like U-Boot, then you probably have more than enough RAM to run U-Boot. FLASH rather than RAM. Has anyone else done this? I played with this a couple of days with out much success. Is it do-able, without too much effort? It would be significant effort. And it makes not much sense, as you would lose a lot of basic functionality, resp. have to work around the resulting restrictions. It doesn't make sense to me. Rather think how to make it fit into avilable RAM. How much RAM do you have? 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 light at the end of the tunnel is usually a No Exit sign. ___ 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
[U-Boot] [PATCH] Add Elpida Memory Configuration to mpc5121ads Boards
Signed-off-by: Martha M Stan mm...@silicontkx.com
---
board/freescale/mpc5121ads/mpc5121ads.c | 98 ++-
include/configs/mpc5121ads.h| 35 ++-
2 files changed, 129 insertions(+), 4 deletions(-)
diff --git a/board/freescale/mpc5121ads/mpc5121ads.c
b/board/freescale/mpc5121ads/mpc5121ads.c
index 8defb00..4315734 100644
--- a/board/freescale/mpc5121ads/mpc5121ads.c
+++ b/board/freescale/mpc5121ads/mpc5121ads.c
@@ -31,6 +31,7 @@
#ifdef CONFIG_MISC_INIT_R
#include i2c.h
#endif
+#include net.h
#include linux/mtd/mtd.h
#include linux/mtd/nand.h
@@ -133,11 +134,104 @@ int board_early_init_f(void)
return 0;
}
+int is_micron(void){
+
+ ushort brd_rev = *(vu_short *)(CONFIG_SYS_CPLD_BASE + 0x00);
+ uchar macaddr[6];
+ u32 brddate, macchk, ismicron;
+
+ /*
+* MAC address has serial number with date of manufacture
+* Boards made before Nov-08 #1180 use Micron memory;
+* 001e59 is the STx vendor #
+* Default is Elpida since it works for both but is slightly slower
+*/
+ ismicron = 0;
+ if (brd_rev = 0x0400 eth_getenv_enetaddr(ethaddr, macaddr)) {
+ brddate = (macaddr[3] 16) + (macaddr[4] 8) + macaddr[5];
+ macchk = (macaddr[0] 16) + (macaddr[1] 8) + macaddr[2];
+ debug(brddate = %d\n\t, brddate);
+
+ if (macchk == 0x001e59 brddate = 880)
+ ismicron = 1;
+ } else if (brd_rev 0x400) {
+ ismicron = 1;
+ }
+ debug(Using %s Memory settings\n\t,
+ ismicron ? Micron : Elpida);
+ return(ismicron);
+}
+
phys_size_t initdram(int board_type)
{
- u32 msize = 0;
+ /* Elpida MDDRC and initialization settings are an alternative
+* to the Default Micron ones for all but the earliest Rev 4 boards
+*/
+ u32 elpida_mddrc_config[4] = {
+ CONFIG_SYS_MDDRC_SYS_CFG_ELPIDA,
+ CONFIG_SYS_MDDRC_TIME_CFG0,
+ CONFIG_SYS_MDDRC_TIME_CFG1_ELPIDA,
+ CONFIG_SYS_MDDRC_TIME_CFG2_ELPIDA
+ };
+
+ u32 elpida_init_sequence[] = {
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_PCHG_ALL,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_RFSH,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_RFSH,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_EM2,
+ CONFIG_SYS_DDRCMD_EM3,
+ CONFIG_SYS_DDRCMD_EN_DLL,
+ CONFIG_SYS_ELPIDA_RES_DLL,
+ CONFIG_SYS_DDRCMD_PCHG_ALL,
+ CONFIG_SYS_DDRCMD_RFSH,
+ CONFIG_SYS_DDRCMD_RFSH,
+ CONFIG_SYS_DDRCMD_RFSH,
+ CONFIG_SYS_ELPIDA_INIT_DEV_OP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_OCD_DEFAULT,
+ CONFIG_SYS_ELPIDA_OCD_EXIT,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP
+ };
- msize = fixed_sdram(NULL, NULL, 0);
+ u32 msize = 0;
+ if (is_micron()) {
+ msize = fixed_sdram(NULL, NULL, 0);
+ } else {
+ msize = fixed_sdram(elpida_mddrc_config,
+ elpida_init_sequence,
+ sizeof(elpida_init_sequence)/sizeof(u32));
+ }
return msize;
}
diff --git a/include/configs/mpc5121ads.h b/include/configs/mpc5121ads.h
index 0c871c9..ebc518c 100644
--- a/include/configs/mpc5121ads.h
+++ b/include/configs/mpc5121ads.h
@@ -141,14 +141,45 @@
#endif
#define CONFIG_SYS_MDDRC_TIME_CFG0 0x06183D2E
+#define CONFIG_SYS_MDDRC_SYS_CFG_ELPIDA0xEA802B00
+#define CONFIG_SYS_MDDRC_TIME_CFG1_ELPIDA 0x690e1189
+#define CONFIG_SYS_MDDRC_TIME_CFG2_ELPIDA 0x35310864
+
#define CONFIG_SYS_DDRCMD_NOP 0x0138
#define
[U-Boot] [PATCH] Streamlined mpc512x fixed_sdram init sequence.
Signed-off-by: Martha M Stan mm...@silicontkx.com
---
board/davedenx/aria/aria.c |2 +-
board/esd/mecp5123/mecp5123.c |2 +-
board/freescale/mpc5121ads/mpc5121ads.c |2 +-
cpu/mpc512x/fixed_sdram.c | 104 --
include/asm-ppc/immap_512x.h|4 +
include/asm-ppc/mpc512x.h |2 +-
include/configs/aria.h | 22 +++
include/configs/mecp5123.h | 23 +++
include/configs/mpc5121ads.h| 30 -
9 files changed, 109 insertions(+), 82 deletions(-)
diff --git a/board/davedenx/aria/aria.c b/board/davedenx/aria/aria.c
index 2064aa2..cc69c9d 100644
--- a/board/davedenx/aria/aria.c
+++ b/board/davedenx/aria/aria.c
@@ -101,7 +101,7 @@ int board_early_init_f(void)
phys_size_t initdram (int board_type)
{
- return fixed_sdram();
+ return fixed_sdram(NULL, NULL, 0);
}
int misc_init_r(void)
diff --git a/board/esd/mecp5123/mecp5123.c b/board/esd/mecp5123/mecp5123.c
index f591e32..5139358 100644
--- a/board/esd/mecp5123/mecp5123.c
+++ b/board/esd/mecp5123/mecp5123.c
@@ -135,7 +135,7 @@ int board_early_init_f(void)
phys_size_t initdram(int board_type)
{
- return get_ram_size(0, fixed_sdram());
+ return get_ram_size(0, fixed_sdram(NULL, NULL, 0));
}
int misc_init_r(void)
diff --git a/board/freescale/mpc5121ads/mpc5121ads.c
b/board/freescale/mpc5121ads/mpc5121ads.c
index a0d7a82..8defb00 100644
--- a/board/freescale/mpc5121ads/mpc5121ads.c
+++ b/board/freescale/mpc5121ads/mpc5121ads.c
@@ -137,7 +137,7 @@ phys_size_t initdram(int board_type)
{
u32 msize = 0;
- msize = fixed_sdram();
+ msize = fixed_sdram(NULL, NULL, 0);
return msize;
}
diff --git a/cpu/mpc512x/fixed_sdram.c b/cpu/mpc512x/fixed_sdram.c
index d906903..63a3035 100644
--- a/cpu/mpc512x/fixed_sdram.c
+++ b/cpu/mpc512x/fixed_sdram.c
@@ -25,18 +25,70 @@
#include asm/io.h
#include asm/mpc512x.h
+/*
+ * MDDRC Config Runtime Settings in order of the 4 MDDRC cfg registers
+ */
+u32 default_mddrc_config[4] = {
+ CONFIG_SYS_MDDRC_SYS_CFG,
+ CONFIG_SYS_MDDRC_TIME_CFG0,
+ CONFIG_SYS_MDDRC_TIME_CFG1,
+ CONFIG_SYS_MDDRC_TIME_CFG2
+};
+
+u32 default_init_seq[] = {
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_PCHG_ALL,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_RFSH,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_RFSH,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_MICRON_INIT_DEV_OP,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_EM2,
+ CONFIG_SYS_DDRCMD_NOP,
+ CONFIG_SYS_DDRCMD_PCHG_ALL,
+ CONFIG_SYS_DDRCMD_EM2,
+ CONFIG_SYS_DDRCMD_EM3,
+ CONFIG_SYS_DDRCMD_EN_DLL,
+ CONFIG_SYS_MICRON_INIT_DEV_OP,
+ CONFIG_SYS_DDRCMD_PCHG_ALL,
+ CONFIG_SYS_DDRCMD_RFSH,
+ CONFIG_SYS_MICRON_INIT_DEV_OP,
+ CONFIG_SYS_DDRCMD_OCD_DEFAULT,
+ CONFIG_SYS_DDRCMD_PCHG_ALL,
+ CONFIG_SYS_DDRCMD_NOP
+};
+
/*
* fixed sdram init:
* The board doesn't use memory modules that have serial presence
* detect or similar mechanism for discovery of the DRAM settings
*/
-long int fixed_sdram(void)
+long int fixed_sdram(u32 *mddrc_config, u32 *dram_init_seq, int seq_sz)
{
volatile immap_t *im = (immap_t *)CONFIG_SYS_IMMR;
u32 msize = CONFIG_SYS_DDR_SIZE * 1024 * 1024;
u32 msize_log2 = __ilog2(msize);
u32 i;
+ /* take default settings and init sequence if necessary */
+ if (mddrc_config == 0)
+ mddrc_config = default_mddrc_config;
+ if (dram_init_seq == 0) {
+ dram_init_seq = default_init_seq;
+ seq_sz = sizeof(default_init_seq)/sizeof(u32);
+ }
+
/* Initialize IO Control */
out_be32(im-io_ctrl.io_control_mem, IOCTRL_MUX_DDR);
@@ -45,8 +97,8 @@ long int fixed_sdram(void)
out_be32(im-sysconf.ddrlaw.ar, msize_log2 - 1);
sync_law(im-sysconf.ddrlaw.ar);
- /* Enable DDR */
- out_be32(im-mddrc.ddr_sys_config, CONFIG_SYS_MDDRC_SYS_CFG_EN);
+ /* DDR Enable */
+ out_be32(im-mddrc.ddr_sys_config, MDDRC_SYS_CFG_EN);
/* Initialize DDR Priority Manager */
out_be32(im-mddrc.prioman_config1, CONFIG_SYS_MDDRCGRP_PM_CFG1);
@@ -73,41 +125,23 @@ long int fixed_sdram(void)
out_be32(im-mddrc.lut_table4_alternate_upper,
CONFIG_SYS_MDDRCGRP_LUT4_AU);
out_be32(im-mddrc.lut_table4_alternate_lower,
CONFIG_SYS_MDDRCGRP_LUT4_AL);
- /* Initialize MDDRC */
- out_be32(im-mddrc.ddr_sys_config, CONFIG_SYS_MDDRC_SYS_CFG);
- out_be32(im-mddrc.ddr_time_config0,
[U-Boot] [PATCH] ppc4xx: Fix PCIE PLL lock on 440SPe Yucca board
u-boot reports a PCIE PLL lock error at boot time on Yucca board, and
left PCIe nonfunctional. This is fixed by making u-boot function
ppc4xx_init_pcie() to wait 300 uS after negating reset before the
first check of the PLL lock.
Signed-off-by: Rupjyoti Sarmah rsar...@amcc.com
---
diff --git a/cpu/ppc4xx/4xx_pcie.c b/cpu/ppc4xx/4xx_pcie.c
index 07fbb0e..78fdb4e 100644
--- a/cpu/ppc4xx/4xx_pcie.c
+++ b/cpu/ppc4xx/4xx_pcie.c
@@ -374,28 +374,35 @@ int ppc4xx_init_pcie(void)
/* Set PLL clock receiver to LVPECL */
SDR_WRITE(PESDR0_PLLLCT1, SDR_READ(PESDR0_PLLLCT1) | 1 28);
- if (check_error())
+ if (check_error()) {
+ printf(ERROR: failed to set PCIe reference clock receiver --
+ PESDR0_PLLLCT1 = 0x%08x\n, SDR_READ(PESDR0_PLLLCT1));
+
return -1;
+ }
+
+ /* Did resistance calibration work? */
+ if (!(SDR_READ(PESDR0_PLLLCT2) 0x1)) {
+ printf(ERROR: PCIe resistance calibration failed --
+ PESDR0_PLLLCT2 = 0x%08x\n, SDR_READ(PESDR0_PLLLCT2));
- if (!(SDR_READ(PESDR0_PLLLCT2) 0x1))
- {
- printf(PCIE: PESDR_PLLCT2 resistance calibration failed
(0x%08x)\n,
- SDR_READ(PESDR0_PLLLCT2));
return -1;
}
/* De-assert reset of PCIe PLL, wait for lock */
SDR_WRITE(PESDR0_PLLLCT1, SDR_READ(PESDR0_PLLLCT1) ~(1 24));
- udelay(3);
+ udelay(300);/* 300 uS is maximum time lock should take */
while (time_out) {
if (!(SDR_READ(PESDR0_PLLLCT3) 0x1000)) {
time_out--;
- udelay(1);
+ udelay(20); /* Wait 20 uS more if needed */
} else
break;
}
if (!time_out) {
- printf(PCIE: VCO output not locked\n);
+ printf(ERROR: PCIe PLL VCO output not locked to ref clock --
+ PESDR0_PLLLCTS=0x%08x\n, SDR_READ(PESDR0_PLLLCT3));
+
return -1;
}
return 0;
--
1.5.6.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TI: DaVinci: DM646x: Update flag used to represent DM646x SOC's
s-paul...@ti.com wrote:
From: Sandeep Paulraj s-paul...@ti.com
In the DaVinci specific code, we use both CONFIG_SOC_DM646X and
CONFIG_SOC_DM646x to represent DM646x specific code.
This patch changes occurrences of CONFIG_SOC_DM646x to
CONFIG_SOC_DM646X. This is because for DM644x series of SOCs we use
the flag CONFIG_SOC_DM644X. We want some uniformity.
Signed-off-by: Sandeep Paulraj s-paul...@ti.com
Which board defines CONFIG_SOC_DM646X?
I could not find it in a simple grep.
Otherwise..
Ack-ed
Tom
---
include/asm-arm/arch-davinci/emac_defs.h |4 ++--
include/asm-arm/arch-davinci/nand_defs.h |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/asm-arm/arch-davinci/emac_defs.h
b/include/asm-arm/arch-davinci/emac_defs.h
index ae75f84..96bc80e 100644
--- a/include/asm-arm/arch-davinci/emac_defs.h
+++ b/include/asm-arm/arch-davinci/emac_defs.h
@@ -50,7 +50,7 @@
#define EMAC_MDIO_BASE_ADDR (0x01c84000)
#endif
-#ifdef CONFIG_SOC_DM646x
+#ifdef CONFIG_SOC_DM646X
/* MDIO module input frequency */
#define EMAC_MDIO_BUS_FREQ 7650
/* MDIO clock output frequency */
@@ -283,7 +283,7 @@ typedef struct {
/* EMAC Wrapper Registers Structure */
typedef struct {
-#if defined(CONFIG_SOC_DM646x) || defined(CONFIG_SOC_DM365)
+#if defined(CONFIG_SOC_DM646X) || defined(CONFIG_SOC_DM365)
dv_reg IDVER;
dv_reg SOFTRST;
dv_reg EMCTRL;
diff --git a/include/asm-arm/arch-davinci/nand_defs.h
b/include/asm-arm/arch-davinci/nand_defs.h
index 386540e..10f3a39 100644
--- a/include/asm-arm/arch-davinci/nand_defs.h
+++ b/include/asm-arm/arch-davinci/nand_defs.h
@@ -28,7 +28,7 @@
#include asm/arch/hardware.h
-#ifdef CONFIG_SOC_DM646x
+#ifdef CONFIG_SOC_DM646X
#define MASK_CLE0x8
#define MASK_ALE0x4
#else
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-boot] Marvell Pull Request
Prafulla Wadaskar wrote: Hi Wolfgang Please pull Shouldn't this rather get pulled to u-boot-arm? Tom The following changes since commit 3b6a9267f0de7b85d387fa4123d0b58379363447: Wolfgang Denk (1): board/flagadm/flash.c: fix compile warning are available in the git repository at: git://git.denx.de/u-boot-marvell.git master Prafulla Wadaskar (2): Kirkwood: rd6281a: Add kwbimage build support Kirkwood: mv88f6281gtw_ge: Add kwbimage build support Simon Kagstrom (1): Support for the OpenRD base board MAINTAINERS|4 + MAKEALL|1 + Makefile |3 + board/Marvell/mv88f6281gtw_ge/config.mk|3 + board/Marvell/mv88f6281gtw_ge/kwbimage.cfg | 165 + board/Marvell/openrd_base/Makefile | 56 +++ board/Marvell/openrd_base/config.mk| 33 board/Marvell/openrd_base/kwbimage.cfg | 168 + board/Marvell/openrd_base/openrd_base.c| 160 board/Marvell/openrd_base/openrd_base.h| 46 ++ board/Marvell/rd6281a/config.mk|3 + board/Marvell/rd6281a/kwbimage.cfg | 167 + include/configs/openrd_base.h | 220 13 files changed, 1029 insertions(+), 0 deletions(-) create mode 100644 board/Marvell/mv88f6281gtw_ge/kwbimage.cfg create mode 100644 board/Marvell/openrd_base/Makefile create mode 100644 board/Marvell/openrd_base/config.mk create mode 100644 board/Marvell/openrd_base/kwbimage.cfg create mode 100644 board/Marvell/openrd_base/openrd_base.c create mode 100644 board/Marvell/openrd_base/openrd_base.h create mode 100644 board/Marvell/rd6281a/kwbimage.cfg create mode 100644 include/configs/openrd_base.h Regards.. Prafulla . . . ___ 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 v3] at91: Update MEESC board support
Daniel Gorsulowski wrote: Dear Wolfgang Denk and Jean-Christophe PLAGNIOL-VILLARD, Daniel Gorsulowski wrote: This patch implements several updates: -disable CONFIG_ENV_OVERWRITE -add new hardware style variants and set the arch numbers appropriate (autodet.) -pass the serial# and hardware revision to the kernel -removed unused macros from include/configs/meesc.h Signed-off-by: Daniel Gorsulowski daniel.gorsulow...@esd.eu --- v2: - don't write the ethernet address to the EMAC module anymore v3: - removed function meesc_set_arch_number and moved code to checkboard() - reworked function get_board_serial() - removed unused macros from include/configs/meesc.h board/esd/meesc/meesc.c | 62 +++ include/configs/meesc.h | 25 ++- 2 files changed, 65 insertions(+), 22 deletions(-) snip what about this patch? No more comments, no NACK, no applied to...? Daniel, Please resend or point me to the latest version of this patch. We will resolve this shortly. Thanks, Tom Best regards, Daniel Gorsulowski ___ 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] TI: DaVinci: DM646x: Update flag used to represent DM646x SOC's
s-paul...@ti.com wrote: From: Sandeep Paulraj s-paul...@ti.com In the DaVinci specific code, we use both CONFIG_SOC_DM646X and CONFIG_SOC_DM646x to represent DM646x specific code. This patch changes occurrences of CONFIG_SOC_DM646x to CONFIG_SOC_DM646X. This is because for DM644x series of SOCs we use the flag CONFIG_SOC_DM644X. We want some uniformity. Signed-off-by: Sandeep Paulraj s-paul...@ti.com Which board defines CONFIG_SOC_DM646X? I could not find it in a simple grep. Otherwise.. Ack-ed Tom No board uses it as of now. But there is some support for DM646x(DaVinci-HD) based chips in the present source in the form of some entries in the hardware.h file and 1 DM646x SOC specific file. IIRC patches were sent some months ago for DM646x but got lost in the list. Thanks, Sandeep ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] AT91 pending patches
Hi Tom, may you please comment on the following patches : http://article.gmane.org/gmane.comp.boot-loaders.u-boot/67400 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/65674 Many thanks Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH MAKEALL coldfire] : Fix start.S:Error: Conversion of PC relative displacement to absolute
Hi all, This fixes the following errors when running MAKEALL for coldfire : start.S: Assembler messages: start.S:320: Error: Conversion of PC relative displacement to absolute Signed-off-by: Philippe De Muyter p...@macqel.be diff -ru a/cpu/mcf523x/start.S b/cpu/mcf523x/start.S --- a/cpu/mcf523x/start.S 2009-09-17 23:28:31.0 +0200 +++ b/cpu/mcf523x/start.S 2009-09-21 19:58:34.0 +0200 @@ -246,7 +246,7 @@ /* exception code */ .globl _fault _fault: - jmp _fault + bra _fault .globl _exc_handler _exc_handler: diff -ru a/cpu/mcf52x2/start.S b/cpu/mcf52x2/start.S --- a/cpu/mcf52x2/start.S 2009-09-17 23:28:31.0 +0200 +++ b/cpu/mcf52x2/start.S 2009-09-21 19:47:40.0 +0200 @@ -317,7 +317,7 @@ /* exception code */ .globl _fault _fault: - jmp _fault + bra _fault .globl _exc_handler _exc_handler: diff -ru a/cpu/mcf532x/start.S b/cpu/mcf532x/start.S --- a/cpu/mcf532x/start.S 2009-09-17 23:28:31.0 +0200 +++ b/cpu/mcf532x/start.S 2009-09-21 19:50:36.0 +0200 @@ -256,7 +256,7 @@ /* exception code */ .globl _fault _fault: - jmp _fault + bra _fault .globl _exc_handler _exc_handler: ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH MAKEALL coldfire] fix tools/kwbimage.c format warning
Hi all,
This fixes the following warnings when running MAKEALL for coldfire :
tools/kwbimage.c: In function #kwbimage_checksum32#:
tools/kwbimage.c:135: warning: format #%ld# expects type #long int#, but
argument 4 has type #unsigned int#
Signed-off-by: Philippe De Muyter p...@macqel.be
diff -ru a/tools/kwbimage.c b/tools/kwbimage.c
--- a/tools/kwbimage.c 2009-09-17 23:28:31.0 +0200
+++ b/tools/kwbimage.c 2009-09-21 19:40:19.0 +0200
@@ -131,7 +131,7 @@
return 0;
if (len % sizeof(uint32_t)) {
- printf (Error:%s[%d] - lenght is not in multiple of %ld\n,
+ printf (Error:%s[%d] - length is not in multiple of %u\n,
__FUNCTION__, len, sizeof(uint32_t));
return 0;
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH MAKEALL coldfire] fix tools/kwbimage.c format warning
Dear Philippe De Muyter,
In message 20090921200644.ga6...@frolo.macqel you wrote:
Hi all,
This fixes the following warnings when running MAKEALL for coldfire :
tools/kwbimage.c: In function #kwbimage_checksum32#:
tools/kwbimage.c:135: warning: format #%ld# expects type #long int#, but
argument 4 has type #unsigned int#
Signed-off-by: Philippe De Muyter p...@macqel.be
diff -ru a/tools/kwbimage.c b/tools/kwbimage.c
--- a/tools/kwbimage.c2009-09-17 23:28:31.0 +0200
+++ b/tools/kwbimage.c2009-09-21 19:40:19.0 +0200
@@ -131,7 +131,7 @@
return 0;
if (len % sizeof(uint32_t)) {
- printf (Error:%s[%d] - lenght is not in multiple of %ld\n,
+ printf (Error:%s[%d] - length is not in multiple of %u\n,
__FUNCTION__, len, sizeof(uint32_t));
Seems you are using old code. This has long been fixed (using a %zu
format).
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Men don't talk peace unless they're ready to back it up with war.
-- Col. Green, The Savage Curtain, stardate 5906.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH MAKEALL coldfire] fix cmd_bdinfo.c:354: warning: 'print_eth' defined but not used
Hi all,
This fixes the following warnings when running MAKEALL for coldfire :
cmd_bdinfo.c:354: warning: 'print_eth' defined but not used
Signed-off-by: Philippe De Muyter p...@macqel.be
diff -ru a/common/cmd_bdinfo.c b/common/cmd_bdinfo.c
--- a/common/cmd_bdinfo.c 2009-09-17 23:28:31.0 +0200
+++ b/common/cmd_bdinfo.c 2009-09-21 20:10:45.0 +0200
@@ -31,7 +31,7 @@
static void print_num(const char *, ulong);
-#if !defined(CONFIG_ARM) || defined(CONFIG_CMD_NET)
+#if !(defined(CONFIG_ARM) || defined(CONFIG_M68K)) || defined(CONFIG_CMD_NET)
static void print_eth(int idx);
#endif
@@ -349,7 +349,7 @@
printf (%-12s= 0x%08lX\n, name, value);
}
-#if !defined(CONFIG_ARM) || defined(CONFIG_CMD_NET)
+#if !(defined(CONFIG_ARM) || defined(CONFIG_M68K)) || defined(CONFIG_CMD_NET)
static void print_eth(int idx)
{
char name[10], *val;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH MAKEALL coldfire] fix tools/kwbimage.c format warning
Dear Philippe De Muyter,
In message 20090921202802.gb12...@frolo.macqel you wrote:
if (len % sizeof(uint32_t)) {
- printf (Error:%s[%d] - lenght is not in multiple of %ld\n,
+ printf (Error:%s[%d] - length is not in multiple of %u\n,
__FUNCTION__, len, sizeof(uint32_t));
Seems you are using old code. This has long been fixed (using a %zu
format).
That's surprising. I got a tarball last friday (3 days ago) using the
snapshot button on the gitweb interface :
u-boot-3dc5e00454a58499d4f4c790b38036b0e873747e.tar.gz
You need this commit:
commit ceb2d57c2205db5bbd868577f756c74a2568160c
Author: Wolfgang Denk w...@denx.de
Date: Tue Sep 15 21:13:27 2009 +0200
kwbimage.c: Fix compile warning when building on 64 bit systems (again)
Commit 51003b89 attempted to fix a build problem on 64 bit systems,
but just turned it into a build problem on 32 bit systems (silly me).
Now do the Right Thing (TM) and use a %zu printf format.
Also fix spelling error.
Signed-off-by: Wolfgang Denk w...@denx.de
It was merged into the master branch on 2009-09-18 23:20:12.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
What is mind? No matter. What is matter? Never mind.
-- Thomas Hewitt Key, 1799-1875
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] imx51:Add support basic boot code of freescale imx51 bbg board
Hi Fred, --- On Mon, 9/21/09, Magnus Lilja lilja.mag...@gmail.com wrote: From: Magnus Lilja lilja.mag...@gmail.com Subject: Re: [U-Boot] [PATCH] imx51:Add support basic boot code of freescale imx51 bbg board To: gareat...@gmail.com Cc: u-boot@lists.denx.de Date: Monday, September 21, 2009, 2:55 PM Hi I've scanned the patch briefly and have some comments below. gareat...@gmail.com wrote: From: Fred Fan fanyef...@gmail.com This patch just supports boot into u-boot from mmc or spi-nor flash. It just implements console, iomux and clock. There are no ethernet, nor-flash, mmc or other peripheral drivers. Sign-of-by: Fred.Fan fanyef...@gmail.com Sign-of-by: Fred.Fan r01...@freescale.com Should be 'Signed-off-by: FredFan fanyef...@gmail.com'. diff --git a/MAINTAINERS b/MAINTAINERS index 620604c..5fb1221 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -549,6 +549,10 @@ Fabio Estevam fabio.este...@freescale.com mx31pdk i.MX31 +Fred Fan fanyef...@gmail.com + + imx51 i.MX51 + Is imx51 really the name of this board? Later on it looks like the name is MX51_BABBAGE. I agree with Magnus. You should use the board name here, not the processor name. Peter Figuli pep...@etc.sk wepep250 xscale diff --git a/MAKEALL b/MAKEALL index edebaea..ed8c437 100755 --- a/MAKEALL +++ b/MAKEALL snip diff --git a/board/freescale/imx51/Makefile b/board/freescale/imx51/Makefile new file mode 100644 index 000..fbd40f2 --- /dev/null +++ b/board/freescale/imx51/Makefile As Magnus pointed out you should use /board/freescale/mx51babbage/... diff --git a/board/freescale/imx51/board-imx51.h Ditto b/board/freescale/imx51/board-imx51.h new file mode 100644 index 000..7a2cae0 --- /dev/null +++ b/board/freescale/imx51/board-imx51.h @@ -0,0 +1,64 @@ +/* + * Copyright 2009 Freescale Semiconductor, Inc. All Rights Reserved. + */ + +/* + * The code contained herein is licensed under the GNU General Public + * License. You may obtain a copy of the GNU General Public License + * Version 2 or later at the following locations: + * + * http://www.opensource.org/licenses/gpl-license.html + * http://www.gnu.org/copyleft/gpl.html + */ + +#ifndef __BOARD_FREESCALE_BOARD_IMX51_H__ +#define __BOARD_FREESCALE_BOARD_IMX51_H__ + +/*! + * @defgroup BRDCFG_MX51 Board Configuration Options + * @ingroup MSL_MX51 + */ + +/*! + * @file mx51_3stack/board-imx51.h + * + * @brief This file contains all the board level configuration options. + * + * It currently hold the options defined for MX51 3Stack Platform. I think you should remove MX51 3stack references as it can cause confusion. + * + * @ingroup BRDCFG_IMX51 + */ + +/* CPLD offsets */ +#define PBC_LED_CTRL (0x2) +#define PBC_SB_STAT (0x20008) +#define PBC_ID_ (0x20040) +#define PBC_ID_ (0x20048) +#define PBC_VERSION (0x20050) +#define PBC_ID_CAFE (0x20058) +#define PBC_INT_STAT (0x20010) +#define PBC_INT_MASK (0x20038) +#define PBC_INT_REST (0x20020) +#define PBC_SW_RESET (0x20060) + +/* LED switchs */ +#define LED_SWITCH_REG 0x00 +/* buttons */ +#define SWITCH_BUTTONS_REG 0x08 +/* status, interrupt */ +#define INTR_STATUS_REG 0x10 +#define INTR_MASK_REG 0x38 +#define INTR_RESET_REG 0x20 +/* magic word for debug CPLD */ +#define MAGIC_NUMBER1_REG 0x40 +#define MAGIC_NUMBER2_REG 0x48 +/* CPLD code version */ +#define CPLD_CODE_VER_REG 0x50 +/* magic word for debug CPLD */ +#define MAGIC_NUMBER3_REG 0x58 +/* module reset register*/ +#define MODULE_RESET_REG 0x60 +/* CPU ID and Personality ID */ +#define MCU_BOARD_ID_REG 0x68 + +#endif /* __BOARD_FREESCALE_BOARD_IMX51_H__ */ diff --git a/board/freescale/imx51/config.mk b/board/freescale/imx51/config.mk new file mode 100644 index 000..d8b0f10 --- /dev/null +++ b/board/freescale/imx51/config.mk @@ -0,0 +1,2 @@ +LDSCRIPT = board/$(VENDOR)/$(BOARD)/u-boot.lds +TEXT_BASE = 0x9780 diff --git a/board/freescale/imx51/flash_header.S b/board/freescale/imx51/flash_header.S new file mode 100644 index 000..6790679 --- /dev/null +++ b/board/freescale/imx51/flash_header.S @@ -0,0 +1,113 @@ +/* + * Copyright 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 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
Re: [U-Boot] [PATCH MAKEALL coldfire] fix tools/kwbimage.c format warning
Dear Wolfgang, On Mon, Sep 21, 2009 at 10:53:13PM +0200, Wolfgang Denk wrote: Seems you are using old code. This has long been fixed (using a %zu format). That's surprising. I got a tarball last friday (3 days ago) using the snapshot button on the gitweb interface : u-boot-3dc5e00454a58499d4f4c790b38036b0e873747e.tar.gz You need this commit: ... Date: Tue Sep 15 21:13:27 2009 +0200 ... It was merged into the master branch on 2009-09-18 23:20:12. OK, that's the explanation : I downloaded the snapshot on 2009-09-18 18:59 thanks and good night Philippe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add mpc5125ads board and processor to the mpc512x family
Hi Martha, --- On Mon, 9/21/09, Martha M Stan mm...@silicontkx.com wrote: From: Martha M Stan mm...@silicontkx.com Subject: [U-Boot] [PATCH] Add mpc5125ads board and processor to the mpc512x family To: u-boot@lists.denx.de Cc: Martha M Stan mm...@silicontkx.com Date: Monday, September 21, 2009, 5:27 PM Signed-off-by: Martha M Stan mm...@silicontkx.com You missed MAKEALL and MAINTAINERS entries. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] sbc85x0: tidy up Makefile to use new configuration script.
Commit 804d83a5 allows us to move all the configuration variation tweaks out of the top level Makefile and down into the boards config header. This takes advantage of that for the sbc8540/sbc8560 boards. There were a couple of cheezy comments pointing at incorrect files, or files that don't exist, so I've cleaned those up too. Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com --- For 85xx tree; since it contains sbc8548 commits which this diff has context of one of those commit changes to Makefile Makefile | 18 ++ include/configs/SBC8540.h | 19 +++ include/configs/sbc8560.h | 17 - 3 files changed, 25 insertions(+), 29 deletions(-) diff --git a/Makefile b/Makefile index 55ee25d..9c5b2a5 100644 --- a/Makefile +++ b/Makefile @@ -2535,14 +2535,7 @@ PM856_config:unconfig sbc8540_config \ sbc8540_33_config \ sbc8540_66_config: unconfig - @mkdir -p $(obj)include - @if [ $(findstring _66_,$@) ] ; then \ - echo #define CONFIG_PCI_66$(obj)include/config.h ; \ - $(XECHO) ... 66 MHz PCI ; \ - else \ - $(XECHO) ... 33 MHz PCI ; \ - fi - @$(MKCONFIG) -a SBC8540 ppc mpc85xx sbc8560 + @$(MKCONFIG) -t $(@:_config=) SBC8540 ppc mpc85xx sbc8560 sbc8548_config \ sbc8548_PCI_33_config \ @@ -2554,14 +2547,7 @@ sbc8548_PCI_66_PCIE_config: unconfig sbc8560_config \ sbc8560_33_config \ sbc8560_66_config: unconfig - @mkdir -p $(obj)include - @if [ $(findstring _66_,$@) ] ; then \ - echo #define CONFIG_PCI_66$(obj)include/config.h ; \ - $(XECHO) ... 66 MHz PCI ; \ - else \ - $(XECHO) ... 33 MHz PCI ; \ - fi - @$(MKCONFIG) -a sbc8560 ppc mpc85xx sbc8560 + @$(MKCONFIG) -t $(@:_config=) sbc8560 ppc mpc85xx sbc8560 socrates_config: unconfig @$(MKCONFIG) $(@:_config=) ppc mpc85xx socrates diff --git a/include/configs/SBC8540.h b/include/configs/SBC8540.h index 7239f84..198dece 100644 --- a/include/configs/SBC8540.h +++ b/include/configs/SBC8540.h @@ -24,22 +24,25 @@ * MA 02111-1307 USA */ -/* mpc8560ads board configuration file */ -/* please refer to doc/README.mpc85xx for more info */ -/* make sure you change the MAC address and other network params first, - * search for CONFIG_ETHADDR,CONFIG_SERVERIP,etc in this file +/* + * sbc8540 board configuration file. */ #ifndef __CONFIG_H #define __CONFIG_H -#if XXX -#define DEBUG/* General debug */ -#define ET_DEBUG +/* + * Top level Makefile configuration choices + */ +#ifdef CONFIG_MK_66 +#define CONFIG_PCI_66 #endif + #define TSEC_DEBUG -/* High Level Configuration Options */ +/* + * High Level Configuration Options + */ #define CONFIG_BOOKE 1 /* BOOKE*/ #define CONFIG_E5001 /* BOOKE e500 family*/ #define CONFIG_MPC85xx 1 /* MPC8540/MPC8560 */ diff --git a/include/configs/sbc8560.h b/include/configs/sbc8560.h index 4fa501d..7c1d7a6 100644 --- a/include/configs/sbc8560.h +++ b/include/configs/sbc8560.h @@ -24,16 +24,23 @@ * MA 02111-1307 USA */ -/* sbc8560 board configuration file */ -/* please refer to doc/README.sbc8560 for more info */ -/* make sure you change the MAC address and other network params first, - * search for CONFIG_ETHADDR,CONFIG_SERVERIP,etc in this file +/* + * sbc8560 board configuration file. */ #ifndef __CONFIG_H #define __CONFIG_H -/* High Level Configuration Options */ +/* + * Top level Makefile configuration choices + */ +#ifdef CONFIG_MK_66 +#define CONFIG_PCI_66 +#endif + +/* + * High Level Configuration Options + */ #define CONFIG_BOOKE 1 /* BOOKE*/ #define CONFIG_E5001 /* BOOKE e500 family*/ #define CONFIG_MPC85xx 1 /* MPC8540/MPC8560 */ -- 1.6.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] sbc8349: tidy up Makefile to use new configuration script.
Commit 804d83a5 allows us to move all the configuration variation tweaks out of the top level Makefile and down into the board config header. This takes advantage of that for the sbc8349 board. Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com --- Makefile | 15 +-- include/configs/sbc8349.h | 15 +++ 2 files changed, 16 insertions(+), 14 deletions(-) diff --git a/Makefile b/Makefile index 0b61d05..b90be69 100644 --- a/Makefile +++ b/Makefile @@ -2403,20 +2403,7 @@ MVBLM7_config: unconfig sbc8349_config \ sbc8349_PCI_33_config \ sbc8349_PCI_66_config: unconfig - @mkdir -p $(obj)include - @if [ $(findstring _PCI_,$@) ] ; then \ - $(XECHO) -n ... PCI HOST at ; \ - echo #define CONFIG_PCI $(obj)include/config.h ; \ - fi ; \ - if [ $(findstring _33_,$@) ] ; then \ - $(XECHO) -n 33MHz... ; \ - echo #define PCI_33M $(obj)include/config.h ; \ - fi ; \ - if [ $(findstring _66_,$@) ] ; then \ - $(XECHO) -n 66MHz... ; \ - echo #define PCI_66M $(obj)include/config.h ; \ - fi ; - @$(MKCONFIG) -a sbc8349 ppc mpc83xx sbc8349 + @$(MKCONFIG) -t $(@:_config=) sbc8349 ppc mpc83xx sbc8349 SIMPC8313_LP_config \ SIMPC8313_SP_config: unconfig diff --git a/include/configs/sbc8349.h b/include/configs/sbc8349.h index e961bb3..6f574ca 100644 --- a/include/configs/sbc8349.h +++ b/include/configs/sbc8349.h @@ -32,6 +32,21 @@ #define __CONFIG_H /* + * Top level Makefile configuration choices + */ +#ifdef CONFIG_MK_PCI +#define CONFIG_PCI +#endif + +#ifdef CONFIG_MK_66 +#define PCI_66M +#endif + +#ifdef CONFIG_MK_33 +#define PCI_33M +#endif + +/* * High Level Configuration Options */ #define CONFIG_E3001 /* E300 Family */ -- 1.6.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] TFTP Server in U-Boot / Pushing files to U-Boot
Hi All, This is related to the post here: http://www.mail-archive.com/u-boot@lists.denx.de/msg06428.html My use case is similar... updating the kernel remotely to a deployed, physically inaccessible system. I am considering the same thing (TFTP server in U-Boot), but I believe I have a good reason for wanting it. At the same time, I don't want to waste effort if others have a better idea for how to accomplish what I need. The main sticking point for me with using TFTP client from U-Boot is firewalls. My system will be accessed by machines inside a firewall and if I use TFTP client from U-Boot, then I must poke a hole in the firewall... however, I have no control over the firewall so that isn't possible. If the host machine connects to the U-Boot running TFTP server, then all is well. I intend to control U-Boot remotely using netconsole. Is there a better way to push files to U-Boot over netconsole than implementing TFTP server? It seems like this would be a common concern, so it seems likely that it has been solved (in some other way, since there is no TFTP server support in U-Boot). Thanks, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP Server in U-Boot / Pushing files to U-Boot
Dear Joe Hershberger, In message 4b538920909211414o3a7e9c84se0df6e1622f49...@mail.gmail.com you wrote: This is related to the post here: http://www.mail-archive.com/u-boot@lists.denx.de/msg06428.html My use case is similar... updating the kernel remotely to a deployed, physically inaccessible system. I am considering the same thing (TFTP server in U-Boot), but I believe I have a good reason for wanting it. At the same time, I don't want to waste effort if others have a better idea for how to accomplish what I need. The big question is: why do you want to do this in U-Boot? The main sticking point for me with using TFTP client from U-Boot is firewalls. My system will be accessed by machines inside a firewall and if I use TFTP client from U-Boot, then I must poke a hole in the firewall... however, I have no control over the firewall so that isn't possible. If the host machine connects to the U-Boot running TFTP server, then all is well. If you really have no control over the firewall, then I seriously doubt that you will be able to use TFTP at all - no matter if it's incoming or outgoing traffic. I intend to control U-Boot remotely using netconsole. Is there a better way to push files to U-Boot over netconsole than implementing TFTP server? It Are you sure you get the netconsole traffic through your (uncon- trollable, as you wrote) firewall? seems like this would be a common concern, so it seems likely that it has been solved (in some other way, since there is no TFTP server support in U-Boot). Well, most people use an operating system to perform such complex tasks. 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 Is there a way to determine Yesterday's date using Unix utilities? echo what is yesterday's date? | /bin/mail root -- Randal L. Schwartz in ukbuh2y982@julie.teleport.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AT91 pending patches
Eric Bénard wrote:
Hi Tom,
may you please comment on the following patches :
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/67400
[U-Boot] [PATCH] Add support for Eukrea CPU9260/CPU9G20 SBC
these boards are built around Atmel's AT91SAM9260/9G20 and have
up to 64MB of NOR flash, up to 128MB of SDRAM, up to 2GB of NAND
and include a 10/100 Ethernet PHY in RMII mode.
This looks like the first revision.
Only comments from Jean.
He liked it so that's an ack .
Some minor ws issues
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/65674
CPUAT91 is built around Atmel's AT91RM9200 and has up to 16MB of NOR
flash, up to 128MB of SDRAM, and includes a Micrel KS8721 PHY in RMII
mode.
Lots of ws cleanup from v5 to v6.
checkpatch complaining about
checkpatch.pl cpuat91-v6.patch
WARNING: braces {} are not necessary for single statement blocks
#480: FILE: cpu/arm920t/at91rm9200/ks8721.c:222:
+ if (!(value KS8721_AUTONEG_COMP)) {
+ return 0;
+ }
I will take care of this.
From history, lots of comments
I will do the merge and push these patches this weekend after running
the compiling the configurations. There will be some obvious
conflicts like your maintainer list of boards that I will just handle.
Tom
Many thanks
Eric
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP Server in U-Boot / Pushing files to U-Boot
On Mon, Sep 21, 2009 at 4:56 PM, Wolfgang Denk w...@denx.de wrote: In message 4b538920909211414o3a7e9c84se0df6e1622f49...@mail.gmail.com you wrote: I am considering the same thing (TFTP server in U-Boot), but I believe I have a good reason for wanting it. At the same time, I don't want to waste effort if others have a better idea for how to accomplish what I need. The big question is: why do you want to do this in U-Boot? The primary reason was to maintain a fail-safe update procedure without requiring much more flash memory. The main sticking point for me with using TFTP client from U-Boot is firewalls. My system will be accessed by machines inside a firewall and if I use TFTP client from U-Boot, then I must poke a hole in the firewall... however, I have no control over the firewall so that isn't possible. If the host machine connects to the U-Boot running TFTP server, then all is well. If you really have no control over the firewall, then I seriously doubt that you will be able to use TFTP at all - no matter if it's incoming or outgoing traffic. I intend to control U-Boot remotely using netconsole. Is there a better way to push files to U-Boot over netconsole than implementing TFTP server? It Are you sure you get the netconsole traffic through your (uncon- trollable, as you wrote) firewall? I see your point here. Since UDP traffic is just datagrams and there is no concept of connections, the reply messages for both TFTP and netconsole may be blocked by the firewall. Some firewalls will open a return port for UDP traffic, but it does seem that there's no guarantee. So no... I'm not sure. By the way, the firewall I'm referring to is generic. The device will be installed into foreign networks where the only requirement is that outbound (toward the device) TCP traffic on port 80 is allowed. This is very common and can be assumed for my purposes. One of my goals is to not increase the requirements on the network / firewall configuration to facilitate updating the kernel (or to minimally increase... i.e. within the bounds of a typical configuration). seems like this would be a common concern, so it seems likely that it has been solved (in some other way, since there is no TFTP server support in U-Boot). Well, most people use an operating system to perform such complex tasks. Several of the design alternatives do include the operating system. To more completely address your original big question, I am considering the following design alternatives. For the OS based designs, the updated files are all simply sent using a post to a webservice running in the OS. 1. Define redundant partitions in the flash to store the kernel, ramdisk, and device tree, overwrite the inactive partitions in the OS, and once complete, update a flag in the U-Boot env to switch the active partitions, then reboot. This requires the most flash, but there are no special images, therefore there is less development effort and less maintenance. 2. Define a set of safe-mode image partitions that can be used in the event that U-Boot detects a corrupt main image. The safe-mode image can be stripped down to support the bare minimum needed to update and therefore be smaller than the main image. It would use less flash than option 1, but require more effort to develop and maintain the special image. 3. Simply overwrite the main partitions in flash of the currently running live image and hope for the best. The only recourse in the case of failure being to go to the device (or at least somewhere on the device side of the firewall) to repair the failed update using U-Boot. This requires no additional flash partitions, but includes a non-ideal user experience (in the failure case) and it requires implementing the host side of the updating twice in two different ways, which means increased development effort, complexity, and maintenance. 4. Utilize U-Boot directly to perform all updates so that every update is essentially in recovery mode. U-Boot is never updated so it will always be valid and able to replace firmware, regardless of the state of the device otherwise. This, like option 3, requires no additional flash partitions, but reduces complexity by having a single update / recovery procedure. This option, however, has the awful user experience that the user must always go to the device (or to the device side of the firewall) to update it. Naturally, if the user happens to have control of the firewall (or is not using one), then they can avoid going anywhere with option 4 (and option 3, should disaster strike) and the user experience is great. For the purpose of the design, however, I assume the typical firewall configuration stated above. My goal is to attempt to salvage the benefits of option 4 while addressing the primary shortcoming. Are there other designs that you have in mind that may more completely or elegantly address the problem? Thanks, -Joe
Re: [U-Boot] [PATCH] [OneNAND IPL] OneNAND board init support
On Tue, Sep 22, 2009 at 1:15 AM, Scott Wood scottw...@freescale.com wrote:
On Sat, Sep 19, 2009 at 10:32:30AM +0900, Kyungmin Park wrote:
On Sat, Sep 19, 2009 at 4:26 AM, Scott Wood scottw...@freescale.com wrote:
On Sat, Aug 29, 2009 at 01:00:59PM +0900, Kyungmin Park wrote:
#define READ_INTERRUPT() \
- onenand_readw(THIS_ONENAND(ONENAND_REG_INTERRUPT))
+ onenand_readw(ONENAND_REG_INTERRUPT)
You could get rid of the newline now...
It exceeds the 80 columns.
No it doesn't, anymore. You'll note that the start of onenand_readw() in to
the right of the end of READ_INTERRUPT, so you're not saving any horizontal
space with the newline.
Right, change it.
+enum {
+ ONENAND_USE_DEFAULT,
+ ONENAND_USE_GENERIC,
+};
What is this? Add a comment, and possibly more specific names.
I see redefine the specific names and comments.
At this time no need to it. remove it.
+extern int (*onenand_read_page)(ulong block, ulong page,
+ u_char *buf, int pagesize);
Maybe use a weak function instead? Or an #ifdef
CONFIG_SYS_ONENAND_BOARD_READ_PAGE that will keep the code for the
generic version from being in the image (it'd be nice if we could
optimize out replaced weak functions). It seems especially odd that you
use one method for init and another for read page.
I tried to use weak function but it produces more than expected.
More than compiling both functions and choosing with a function pointer?
Weak function itself. when using the weak function. it create more
than function pointer.
as you know it got size limitation. When use the weak function. the
apollon board will be broken.
Broken how? Size?
Yes, I'm under pressure of size limitation.
and I don't want to use #ifdef. since Now we support two different CPUs,
s5pc100, s5pc110. these accesses different way. s5pc100 use own OneNAND
controller. but s5pc110 use generic OneNAND method. That's reason to
define the function pointer.
Function pointers make sense if you want to override on a per-device basis
(i.e. multiple controller types in the same system) or dynamically
(different hardware handled by the same binary). Are you trying to generate
one image that works on both s5pc100 and s5pc110? That sounds pretty
luxurious for a space-constrained NAND bootstrap. :-)
Now I used the two different CPUs. s5pc100 and s5pc110. also these
cpus have different interface. Own controller and generic,
respectively. Of course Now it supports both at one image.
That's reason to introduce the onenand_board_init at onenand IPL.
Right. it's some luxurious but need to maintain several boards. It requires it.
/* read a page with ECC */
-static inline int onenand_read_page(ulong block, ulong page,
+static int generic_onenand_read_page(ulong block, ulong page,
u_char * buf, int pagesize)
Is the generic code really generic, or is it just one specific
controller?
The 'generic' means the original OneNAND access method. Use NOR
interface and use OneNAND registers.
Most and Most generic method.
OK, good; it was never clear to me just which hardware the existing onenand
code has been targeting; I had gotten the impression that it was for one of
the chips with a custom controller.
Better, though, would be to still have good separation between that
implementation and the infrastructure that is truly generic even when you
have a special controller. This is something I don't like about the current
NAND code.
+ onenand_board_init(page_is_4KiB, page);
+#else
+ onenand_generic_init(page_is_4KiB, page);
+#endif
- if (onenand_readw(ONENAND_REG_TECHNOLOGY)) {
- pagesize = 4096; /* MLC OneNAND has 4KiB pagesize */
+ if (page_is_4KiB) {
+ pagesize = 4096; /* OneNAND has 4KiB pagesize */
erase_shift = 18;
- } else {
- pagesize = 2048;
- erase_shift = 17;
}
I don't understand why you move the pagesize/erase_shift init before
onenand_board_init, suggesting that the init code change it if it needs
changing -- but then leave the page_is_4KiB stuff in the generic code.
This should probably just be filled in by the init code without anything
here.
No different. basically I assume OneNAND has 2KiB pagesize and
In special case, MLC, and 4KiB pagesize OneNAND set the 4KiB pagesize.
If you want to leave as before. no problem.
Please consider the code size
It seems to me that just having the replaceable init function fill in the
page size would be smaller than having non-replaceable code that passes a
pointer in and then decides on the basis what was written there.
and don't want to break exsiting board support.
I don't see how this additional bit of refactoring would put other boards at
higher risk of breaking that what
[U-Boot] [PATCH] [OneNAND IPL] Refactor OneNAND IPL code
Refactoring the OneNAND IPL code
and some minor fixed:
- Remove unnecessary header file
- Fix wrong access at read interrupt
- The recent OneNAND has 4KiB pagesize
Also Board can override OneNAND IPL image
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
diff --git a/Makefile b/Makefile
index 0b61d05..961c007 100644
--- a/Makefile
+++ b/Makefile
@@ -285,6 +285,7 @@ endif
ifeq ($(CONFIG_ONENAND_U_BOOT),y)
ONENAND_IPL = onenand_ipl
U_BOOT_ONENAND = $(obj)u-boot-onenand.bin
+ONENAND_BIN ?= $(obj)onenand_ipl/onenand-ipl-2k.bin
endif
__OBJS := $(subst $(obj),,$(OBJS))
@@ -378,8 +379,7 @@ $(ONENAND_IPL): $(TIMESTAMP_FILE) $(VERSION_FILE)
$(obj)include/autoconf.mk
$(MAKE) -C onenand_ipl/board/$(BOARDDIR) all
$(U_BOOT_ONENAND): $(ONENAND_IPL) $(obj)u-boot.bin
- cat $(obj)onenand_ipl/onenand-ipl-2k.bin $(obj)u-boot.bin
$(obj)u-boot-onenand.bin
- cat $(obj)onenand_ipl/onenand-ipl-4k.bin $(obj)u-boot.bin
$(obj)u-boot-flexonenand.bin
+ cat $(ONENAND_BIN) $(obj)u-boot.bin $(obj)u-boot-onenand.bin
$(VERSION_FILE):
@( printf '#define U_BOOT_VERSION U-Boot %s%s\n'
$(U_BOOT_VERSION) \
@@ -3259,8 +3259,6 @@ zylonite_config :
#
apollon_config : unconfig
- @mkdir -p $(obj)include
- @mkdir -p $(obj)onenand_ipl/board/apollon
@echo #define CONFIG_ONENAND_U_BOOT $(obj)include/config.h
@$(MKCONFIG) $(@:_config=) arm arm1136 apollon NULL omap24xx
@echo CONFIG_ONENAND_U_BOOT = y $(obj)include/config.mk
@@ -3742,7 +3740,8 @@ clean:
$(obj)cpu/blackfin/bootrom-asm-offsets.[chs]
@rm -f $(obj)include/bmp_logo.h
@rm -f $(obj)nand_spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,System.map}
- @rm -f
$(obj)onenand_ipl/onenand-{ipl,ipl.bin,ipl-2k.bin,ipl-4k.bin,ipl.map}
+ @rm -f $(obj)onenand_ipl/onenand-{ipl,ipl.bin,ipl.map}
+ @rm -f $(ONENAND_BIN)
@rm -f $(obj)onenand_ipl/u-boot.lds
@rm -f $(TIMESTAMP_FILE) $(VERSION_FILE)
@find $(OBJTREE) -type f \
diff --git a/onenand_ipl/onenand_boot.c b/onenand_ipl/onenand_boot.c
index 63995ce..22baebb 100644
--- a/onenand_ipl/onenand_boot.c
+++ b/onenand_ipl/onenand_boot.c
@@ -24,7 +24,6 @@
*/
#include common.h
-#include version.h
#include onenand_ipl.h
diff --git a/onenand_ipl/onenand_ipl.h b/onenand_ipl/onenand_ipl.h
index 412572a..7ebb3e3 100644
--- a/onenand_ipl/onenand_ipl.h
+++ b/onenand_ipl/onenand_ipl.h
@@ -28,8 +28,9 @@
#define THIS_ONENAND(a) (CONFIG_SYS_ONENAND_BASE + (a))
-#define READ_INTERRUPT()\
- onenand_readw(THIS_ONENAND(ONENAND_REG_INTERRUPT))
+#define READ_INTERRUPT() onenand_readw(ONENAND_REG_INTERRUPT)
+extern int (*onenand_read_page)(ulong block, ulong page,
+ u_char *buf, int pagesize);
extern int onenand_read_block(unsigned char *buf);
#endif
diff --git a/onenand_ipl/onenand_read.c b/onenand_ipl/onenand_read.c
index d1a842d..8d0df81 100644
--- a/onenand_ipl/onenand_read.c
+++ b/onenand_ipl/onenand_read.c
@@ -1,5 +1,5 @@
/*
- * (C) Copyright 2005-2008 Samsung Electronis
+ * (C) Copyright 2005-2009 Samsung Electronics
* Kyungmin Park kyungmin.p...@samsung.com
*
* See file CREDITS for list of people who contributed to this
@@ -37,8 +37,10 @@
extern void *memcpy32(void *dest, void *src, int size);
#endif
+int (*onenand_read_page)(ulong block, ulong page, u_char *buf, int pagesize);
+
/* read a page with ECC */
-static inline int onenand_read_page(ulong block, ulong page,
+static int generic_onenand_read_page(ulong block, ulong page,
u_char * buf, int pagesize)
{
unsigned long *base;
@@ -89,9 +91,25 @@ static inline int onenand_read_page(ulong block, ulong page,
return 0;
}
-#define ONENAND_START_PAGE 1
+#ifndef CONFIG_ONENAND_START_PAGE
+#define CONFIG_ONENAND_START_PAGE 1
+#endif
#define ONENAND_PAGES_PER_BLOCK64
+static void onenand_generic_init(int *page_is_4KiB, int *page)
+{
+ int dev_id, density;
+
+ if (onenand_readw(ONENAND_REG_TECHNOLOGY))
+ *page_is_4KiB = 1;
+ dev_id = onenand_readw(ONENAND_REG_DEVICE_ID);
+ density = dev_id ONENAND_DEVICE_DENSITY_SHIFT;
+ density = ONENAND_DEVICE_DENSITY_MASK;
+ if (density = ONENAND_DEVICE_DENSITY_4Gb
+ !(dev_id ONENAND_DEVICE_IS_DDP))
+ *page_is_4KiB = 1;
+}
+
/**
* onenand_read_block - Read CONFIG_SYS_MONITOR_LEN from begining
* of OneNAND, skipping bad blocks
@@ -99,24 +117,28 @@ static inline int onenand_read_page(ulong block, ulong
page,
*/
int onenand_read_block(unsigned char *buf)
{
- int block;
- int page = ONENAND_START_PAGE, offset = 0;
- int pagesize = 0, erase_shift = 0;
- int
[U-Boot] [PATCH] mpc8610hpcd: Use common 86xx fdt fixup code
Using the common 86xx fdt fixups removes some board-specific code and
should make the mpc8610hpcd easier to maintain in the long run.
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
board/freescale/mpc8610hpcd/mpc8610hpcd.c | 14 +-
2 files changed, 1 insertions(+), 14 deletions(-)
diff --git a/board/freescale/mpc8610hpcd/mpc8610hpcd.c
b/board/freescale/mpc8610hpcd/mpc8610hpcd.c
index 98111eb..358148f 100644
--- a/board/freescale/mpc8610hpcd/mpc8610hpcd.c
+++ b/board/freescale/mpc8610hpcd/mpc8610hpcd.c
@@ -387,19 +387,7 @@ void pci_init_board(void)
void
ft_board_setup(void *blob, bd_t *bd)
{
- do_fixup_by_prop_u32(blob, device_type, cpu, 4,
-timebase-frequency, bd-bi_busfreq / 4, 1);
- do_fixup_by_prop_u32(blob, device_type, cpu, 4,
-bus-frequency, bd-bi_busfreq, 1);
- do_fixup_by_prop_u32(blob, device_type, cpu, 4,
-clock-frequency, bd-bi_intfreq, 1);
- do_fixup_by_prop_u32(blob, device_type, soc, 4,
-bus-frequency, bd-bi_busfreq, 1);
-
- do_fixup_by_compat_u32(blob, ns16550,
- clock-frequency, bd-bi_busfreq, 1);
-
- fdt_fixup_memory(blob, bd-bi_memstart, bd-bi_memsize);
+ ft_cpu_setup(blob, bd);
#ifdef CONFIG_PCI1
ft_fsl_pci_setup(blob, pci0, pci1_hose);
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/13] ppc: Fix relocation
Hi Peter, On Monday 21 September 2009 18:20:24 Peter Tyser wrote: This series attempts to fix relocation to RAM for ppc boards. I split the patches up pretty liberally, let me know if you'd like them organized differently. I tried to be thorough during the changes (especially #1), let me know if I missed anything, there's lots of linker scripts for ppc boards:) Peter Tyser (13): ppc: Enable full relocation to RAM ppc: Check for compilers that don't support relocation ppc: Remove board.c relocation fixups ppc: Remove pci config table pointer relocation fixups ppc: Remove extable relocation fixups ppc: Remove board-specific command table relocation fixups tsec: Remove PHY command relocation fixups fpga: Remove relocation fixups mpl: Remove memory test relocation fixups lwmon, lwmon5: Remove sysmon POST relocation fixups p3mx: Remove serial relocation fixups Conditionally perform common relocation fixups ppc: Remove reloc_off field from global_data structure Thanks. I think it would be a good idea to push all your relocation patches into a special git branch for testing. Wolfgang, what do you think? Could you pull those patches into such a branch for general testing/updates etc? Thanks. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Warning Bad CRC
Wolfgang Denk wrote: Dear Rahanesh, In message 4ab786b9.4080...@tataelxsi.co.in you wrote: U-Boot 1.1.2 (Sep 19 2009 - 10:26:28) Board: IAD CPU Speed 200 MHz DRAM: 32 MB sflash.c:266:DF_F_DataflashProbe: Entered sflash.c:269:DF_F_DataflashProbe: flash type is 0x1 sflash.c:270:DF_F_DataflashProbe: num pages 32768 DataFlash:Nb pages: 32768 Page Size:256 Size=3D 8388608 bytes Logical address: 0xAD00 Nb Erase Blocks:128 Erase Block Size: 65536 Area 0: AD00 to AD003FFF Area 1: AD004000 to AD03 Area 2: AD04 to AD30BFFF Area 3: AD30C000 to AD7F got bad crc. got:0x603b0489, expected:0x0 *** Warning - bad CRC, using default environment Ah! Here you can see that the CRC is incorrect in U-Boot already, so why do you expect to see a different result when using fw_printenv? WHen the CRC _is_ incorrect, both U-Boot and fw_printenv will report this fact in the same way. The message is printed because the flash sector or ERPROM containing the environment variables has never been initialized yet. The message will go away as soon as you save the envrionment variables using the |*saveenv*| command. *Print message after execution of saveenv command from uboot : *Saving Environment to dataflash... copy 0xad03-0xad04 to saveenv-buf 0x8010. erasing 0xad03 - 0xad03 Erasing sectors 0x3 to 0x3 sflash.c:69:DF_F_PageErase: erasing page: 0x3 done erasingsflash.c:164:DF_F_DataFlashWrite: write: src 0x8010, dst=20 0x3, size 0x1 I have no idea what sort of code you might be using there, there is no such file as 'sflash.c' in the mainline U-Boot code. sflash.c is flash driver code . I showed you the print message of savenev to note that it is erasing 0xad03 - 0xad03. That means environment variables are placed in the mentioned sector(0xad03 - 0xad03). Actual address of environment variables is 0xad03f000, which is last 4Kb of 64KB sector. If this is the case what should be the DEVICE_OFFSET? ENV_SIZE? Using the latest u-boot will be quite time consuming. Please help!!! Thanks Rahanesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
