[U-Boot] Marketing Jurídico | Newsletter Inris e Consultoria | Edição 16 | Ano 03
Seu programa de e-mail não está configurado para acessar mensagens no formato HTML. Para visualizar este email copie e cole o seguinte link em seu navegador: www.inriseconsultoria.com.br/emailmkt/visualizar.php?key=19c5f446bbdb174&id=3641261 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Numonyx NOR support in u-boot
On Tue, Jun 29, 2010 at 2:28 PM, Todd Fischer wrote: > Hi, > > We are seeing NOR write failures on 6 of the 10 boards (DM6446 ARM SoC > with Numonyx JS28F256M29EWL NOR flash chip). Four of the boards seem to > work without error. All 10 boards were made on the same manufacturing > line at the same time. > > Initially, we couldn't properly read the QRY response from the chip. > We had to use this patch > > http://www.mail-archive.com/u-boot@lists.denx.de/msg26614.html > > We are getting 'flash not erased' error or timeout error. We have tried > monitoring D7 (busy) and monitoring D6 (activity toggle) to detect > erase / program command completion / timeout. We have tried changing > the timing of the control signals to the NOR chip, but need to use a > logic state analyzer to verify the timing is changed as expected. > > Example error output: > >> cp 0x8170 0x0200 0x40 > Copy to Flash... Flash not Erased > Timeout writing to Flash > >> cp 0x8170 0x0200 > 0x40 > Copy to Flash... Flash write timeout at address 200 data > 129f34 > > We have tried cp, cp.b, cp.w and get the same results. > > With 4 boards working correctly, the code must be close. > > Any suggestions (beyond looking at the signals with a Logic State > Analyzer)? > You didn't say what version of u-boot. A few years ago when doing a DM6446 design, we used a modified 1.2.x that TI was distributing with the DM6446 eval boards (customer insisted that we start from the TI distribution), and as I recall it had a bad implementation of the timer routines. If I remember right they were running the timer at something like 3.84 MHz. For a while now, the u-boot standard has been that CONFIG_HZ should be 1000. In the case where it's not, some of the timeouts in the common CFI flash code will be way too short and will occasionally fail. IIRC, TI had their own individual flash.c where the timeouts were done differently, and we only found it when we tried to use the CFI flash code. Another timer problem that will cause similar issues is if the timer ignores the base argument to get_timer(). ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] PXA: New MMC driver
The new driver is a complete rewrite. It uses the MMC framework and should
support both pxa2xx and pxa3xx.
This driver needs testing though.
Change since v1:
- Handle PXA27x CRC bug (erratum #42)
Signed-off-by: Marek Vasut
---
drivers/mmc/Makefile |1 +
drivers/mmc/pxa_mmc_gen.c | 352 +
2 files changed, 353 insertions(+), 0 deletions(-)
create mode 100644 drivers/mmc/pxa_mmc_gen.c
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 6fa04b8..01338a4 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -32,6 +32,7 @@ COBJS-$(CONFIG_OMAP3_MMC) += omap3_mmc.o
COBJS-$(CONFIG_FSL_ESDHC) += fsl_esdhc.o
COBJS-$(CONFIG_MXC_MMC) += mxcmmc.o
COBJS-$(CONFIG_PXA_MMC) += pxa_mmc.o
+COBJS-$(CONFIG_PXA_MMC_GENERIC) += pxa_mmc_gen.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/mmc/pxa_mmc_gen.c b/drivers/mmc/pxa_mmc_gen.c
new file mode 100644
index 000..a158000
--- /dev/null
+++ b/drivers/mmc/pxa_mmc_gen.c
@@ -0,0 +1,352 @@
+/*
+ * Copyright (C) 2010 Marek Vasut
+ *
+ * Loosely based on the old code and Linux's PXA MMC driver
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include "pxa_mmc.h"
+
+#definePXA_MMC_TIMEOUT 100
+
+static int pxa_mmc_stop_clock(void)
+{
+ int timeout = PXA_MMC_TIMEOUT;
+
+ /* If the clock aren't running, exit */
+ if (!(MMC_STAT & MMC_STAT_CLK_EN))
+ return 0;
+
+ /* Tell the controller to turn off the clock */
+ MMC_STRPCL = MMC_STRPCL_STOP_CLK;
+
+ /* Wait until the clock are off */
+ while ((MMC_STAT & MMC_STAT_CLK_EN) && --timeout)
+ udelay(10);
+
+ /* The clock refused to stop, scream and die a painful death */
+ if (!timeout)
+ return -ETIMEDOUT;
+
+ /* The clock stopped correctly */
+ return 0;
+}
+
+static int pxa_mmc_start_cmd(struct mmc_cmd *cmd, unsigned long cmdat)
+{
+ int timeout = PXA_MMC_TIMEOUT;
+
+ /* The card can send a "busy" response */
+ if (cmd->flags & MMC_RSP_BUSY)
+ cmdat |= MMC_CMDAT_BUSY;
+
+ /* Inform the controller about response type */
+ switch (cmd->resp_type) {
+ case MMC_RSP_R1:
+ case MMC_RSP_R1b:
+ cmdat |= MMC_CMDAT_R1;
+ break;
+ case MMC_RSP_R2:
+ cmdat |= MMC_CMDAT_R2;
+ break;
+ case MMC_RSP_R3:
+ cmdat |= MMC_CMDAT_R3;
+ break;
+ default:
+ break;
+ }
+
+ /* Load command and it's arguments into the controller */
+ MMC_CMD = cmd->cmdidx;
+ MMC_ARGH = cmd->cmdarg >> 16;
+ MMC_ARGL = cmd->cmdarg & 0x;
+ MMC_CMDAT = cmdat;
+
+ /* Start the controller clock and wait until they are started */
+ MMC_STRPCL = MMC_STRPCL_START_CLK;
+ while (!(MMC_STAT & MMC_STAT_CLK_EN) && --timeout)
+ udelay(10);
+
+ /* The clock didn't start, we have a problem */
+ if (!timeout)
+ return -ETIMEDOUT;
+
+ /* Correct and happy end */
+ return 0;
+}
+
+static int pxa_mmc_cmd_done(struct mmc_cmd *cmd)
+{
+ unsigned long a, b, c;
+ int i;
+ int stat;
+
+ /* Read the controller status */
+ stat = MMC_STAT;
+
+ /*
+* Linux says:
+* Did I mention this is Sick. We always need to
+* discard the upper 8 bits of the first 16-bit word.
+*/
+ a = MMC_RES & 0x;
+ for (i = 0; i < 4; i++) {
+ b = MMC_RES & 0x;
+ c = MMC_RES & 0x;
+ cmd->response[i] = (a << 24) | (b << 8) | (c >> 8);
+ a = c;
+ }
+
+ /* The command response didn't arrive */
+ if (stat & MMC_STAT_TIME_OUT_RESPONSE)
+ return -ETIMEDOUT;
+ else if (stat & MMC_STAT_RES_CRC_ERROR && cmd->flags & MMC_RSP_CRC) {
+#if defined(CONFIG_PXA27X)
+ if (cmd->flags & MMC_RSP_136 && cmd->response[0] & 0x8000)
+ printf("Ignoring CRC, this may be dangerous!\n");
+
Re: [U-Boot] [PATCH] MPC512x: workaround data corruption forunaligned local bus accesses
Wolfgang Denk wrote on 2010/06/29 21:24:03: > > Dear "Steve Deiters", > > In message <181804936abc2349be503168465576460f272...@exchserver.basler.com> > you wrote: > > > > I just posted a patch on the linuxppc-dev list that simply uses a > > slightly modified version of memcpy to always keep the source address > > aligned. I had conditionals in that one so it only used it for MPC512x > > or MPC52xx but you should be able to replace the regular memcpy with > > this version. This way you can avoid the wrappers and extra checks. It > > is a simple enough change in that case: > > Thanks. I'll keep this queued and try to run some tests with it on > different architectures - I don't know which side effects might be > caused by changing the alignment from target to source address, so I > will not introduce such a change at this point in the release cycle, > literally minutes before a release. Try the C memcpy I sent. It will/should compile into the same assembler(it did when I wrote it). It is far more generic and is easier to understand. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Make sure that argv[] argument pointers are not modified.
On Tuesday, June 29, 2010 17:08:51 Wolfgang Denk wrote: > Mike Frysinger wrote: > > > arch/blackfin/cpu/bootrom-asm-offsets.c.in|2 +- > > > > this file isnt linked into u-boot, so i dont think it needs to be > > changed. it is actually compiled, just preprocessed and assembly > > output. > > Is this just a comment, or a request to revert the changes to this > file? i dont see any warnings/errors even with the change, so doesnt matter to me. just commenting that it isnt required for the overall issue. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] powerpc/bootcount: Add bootcount support for MPC512x
Dear Detlev Zundel, In message <1274364575-9764-1-git-send-email-...@denx.de> you wrote: > From: Michael Weiss > > This also uses the breadcrumb register as on MPC5200. > > Signed-off-by: Michael Weiss > Signed-off-by: Detlev Zundel > --- > arch/powerpc/lib/bootcount.c |5 + > 1 files changed, 5 insertions(+), 0 deletions(-) Applied to "next" branch, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I have a theory that it's impossible to prove anything, but I can't prove it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Make sure that argv[] argument pointers are not modified.
Dear Mike Frysinger, In message <201006291559.55916.vap...@gentoo.org> you wrote: > > > arch/blackfin/cpu/bootrom-asm-offsets.c.in|2 +- > > this file isnt linked into u-boot, so i dont think it needs to be changed. > it > is actually compiled, just preprocessed and assembly output. Is this just a comment, or a request to revert the changes to this file? > > arch/blackfin/cpu/reset.c |2 +- > > arch/blackfin/lib/boot.c |2 +- > > arch/blackfin/lib/cmd_cache_dump.c|4 +- > > arch/blackfin/lib/kgdb.c |2 +- > > board/bf537-stamp/cmd_bf537led.c |2 +- > > board/cm-bf527/gpio.c |2 +- > > board/cm-bf537e/flash.c |2 +- > > board/cm-bf537u/flash.c |2 +- > > board/tcm-bf537/flash.c |2 +- > > common/cmd_bootldr.c |2 +- > > common/cmd_otp.c |2 +- > > these all look sane, so: > Acked-by: Mike Frysinger > -mike Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de 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] [PATCH 4/6 v2] exports.c: fix warning: 'dummy' defined but not used
Dear Mike Frysinger, In message <201006291600.44029.vap...@gentoo.org> you wrote: > > On Tuesday, June 29, 2010 05:52:32 Wolfgang Denk wrote: > > Signed-off-by: Wolfgang Denk > > --- > > v2: fix compile problem for some boards. > > an attribute should fix all compile errors since the func never gets hidden ;) Yes, I read your first message too, just too late. Thanks! Will respin that patch. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de When the tide of life turns against you And the current upsets your boat Don't waste tears on what might have been Just lie on your back and float. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] POST cleanup.
Dear Michael Zaidman,
In message
<630a18874b3365b814e6d28288770f2d9b437dfa.1273498052.git.michael.zaid...@gmail.com>
you wrote:
> Combine previously submitted POST cleanup patch series
> into single patch. Fix plain POST support introduced recently
> for mpc812x arch.
Please remove this part from the commit message (or replace it by a
better desccription).
> - Revives POST for blackfin arch;
> - Removes redundant code:
> arch/blackfin/lib/post.c
> board/ssv/common/post.c
> arch/powerpc/cpu/ppc4xx/commproc.c
> arch/powerpc/cpu/mpc512x/common.c
> - fixes up the post_word_{load|store} usage;
>
> Signed-off-by: Michael Zaidman
> Acked-by: Detlev Zundel
> Tested-by: Anatolij Gustschin
>
> List of the maintainers of the affected by patch boards:
> Cc: Stephan Linz
> Cc: Travis Sawyer
> Cc: Denis Peter
> Cc: Matthias Fuchs
> Cc: Peter Tyser
> Cc: Stefan Roese
> Cc: Mike Frysinger
> Cc: Niklaus Giger
> Cc: Larry Johnson
> Cc: Feng Kan
> ---
> arch/blackfin/lib/Makefile |2 +-
> arch/blackfin/lib/board.c |1 -
> arch/blackfin/lib/post.c| 421
> ---
> arch/powerpc/cpu/mpc512x/Makefile |1 -
> arch/powerpc/cpu/mpc512x/common.c | 25 --
> arch/powerpc/cpu/mpc8260/commproc.c | 20 --
> arch/powerpc/cpu/mpc85xx/commproc.c | 20 --
> arch/powerpc/cpu/mpc8xx/commproc.c | 20 --
> arch/powerpc/cpu/ppc4xx/Makefile|1 -
> arch/powerpc/cpu/ppc4xx/commproc.c | 53 -
> board/barco/barco.c |9 -
> board/bc3450/bc3450.c | 20 --
> board/bf537-stamp/Makefile |2 +-
> board/bf537-stamp/post.c| 14 --
> board/cm5200/cm5200.c | 16 --
> board/ssv/common/post.c | 44
> board/tqc/tqm5200/tqm5200.c | 19 --
> board/xes/xpedite1000/xpedite1000.c | 16 --
> include/common.h|5 +-
> include/configs/ADNPESC1.h |3 +-
> include/configs/KAREF.h |3 +-
> include/configs/METROBOX.h |3 +-
> include/configs/MIP405.h|4 -
> include/configs/PMC440.h|3 +-
> include/configs/TB5200.h|2 +-
> include/configs/XPEDITE1000.h |3 +-
> include/configs/alpr.h |3 +-
> include/configs/barco.h |2 +
> include/configs/bf537-stamp.h |1 +
> include/configs/bfin_adi_common.h |1 +
> include/configs/hcu4.h |3 +-
> include/configs/hcu5.h |5 +-
> include/configs/hmi1001.h |6 +-
> include/configs/icon.h |3 +-
> include/configs/inka4x0.h |6 +-
> include/configs/katmai.h|3 +-
> include/configs/kilauea.h |3 +-
> include/configs/korat.h |3 +-
> include/configs/lwmon5.h|2 +-
> include/configs/makalu.h|3 +-
> include/configs/mcu25.h |3 +-
> include/configs/mpc5121-common.h|3 +-
> include/configs/ocotea.h|3 +-
> include/configs/redwood.h |3 +-
> include/configs/sequoia.h |3 +-
> include/configs/taishan.h |3 +-
> include/configs/yucca.h |3 +-
> include/configs/zeus.h |7 +-
> include/post.h | 57 +-
> post/Makefile |3 +-
> 50 files changed, 103 insertions(+), 759 deletions(-)
> delete mode 100644 arch/blackfin/lib/post.c
> delete mode 100644 arch/powerpc/cpu/mpc512x/common.c
> delete mode 100644 arch/powerpc/cpu/ppc4xx/commproc.c
> delete mode 100644 board/ssv/common/post.c
This doesn't apply any more:
Applying: POST cleanup.
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
CONFLICT (rename/delete): Rename
board/ssv/common/post.c->tools/gen_eth_addr.c in HEAD and deleted in
POST cleanup.
Removing arch/blackfin/lib/post.c
Auto-merging arch/powerpc/cpu/mpc512x/Makefile
Removing arch/powerpc/cpu/mpc512x/common.c
Removing arch/powerpc/cpu/ppc4xx/commproc.c
CONFLICT (delete/modify): include/configs/ADNPESC1.h deleted in HEAD and
modified in POST cleanup.. Version POST cleanup. of
include/configs/ADNPESC1.h left in tree.
Auto-merging include/configs/icon.h
Failed to merge in the changes.
Patch failed at 0001 POST cleanup.
When you have resolved this problem run "git am -i -3 --resolved".
If you would prefer to skip this patch, instead run "git am -i -3 --skip".
To restore the original branch and stop patching run "git am -i -3 --abort".
Please rebase against "next" branch and resubmit. Sorry for the
inconvenience.
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
[Braddock
Re: [U-Boot] [PATCH] tsec: Fix eTSEC2 link problem on P2020RDB
Dear Peter Tyser, In message <1277838432.31352.197.ca...@petert> you wrote: > > > Applied, thanks. > > A little late, but: > Acked-by: Peter Tyser > Tested-by: Peter Tyser Not too late. Added, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense. - E. W. Dijkstra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] AT91SAM9 series - cleanup USART definitions
Reinhard Meyer wrote: > Hello Wolfgang, > > I just became aware that this patch will involve changes to ALL > include/configs/*.h files for AT91 AND AVR32 boards using > atmel_usart.c. If thats OK I will do that. > Reason: #if defined(CONFIG_USART0) # define USART_ID0 # define USART_BASEUSART0_BASE #elif defined(CONFIG_USART1) # define USART_ID1 # define USART_BASEUSART1_BASE #elif defined(CONFIG_USART2) # define USART_ID2 # define USART_BASEUSART2_BASE #elif defined(CONFIG_USART3) # define USART_ID3 # define USART_BASEUSART3_BASE #endif in atmel_usart.c would have to be blown up for each "new" USART incarnation Atmel invents on new SoCs. USART_ID is effectively not used and USART_BASE might as well defined directly in the include/configs/.h file either by: #define CONFIG_ATMEL_USART1 #define CONFIG_ATMEL_USART_BASE AT91_UARTDEB /* USART used is DBGU */ OR directly by: #define CONFIG_ATMEL_USART AT91_UARTDEB /* USART used is DBGU */ or is the 2nd solution bad because Makefiles might choke on it? Greetings, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] AT91SAM9 series - cleanup USART definitions
Wolfgang Denk wrote: > Dear Reinhard Meyer, > > In message <4c2a3c42.7050...@emk-elektronik.de> you wrote: > >> I propose to make the following changes: >> > > Please go on and submit a patch. > Hello Wolfgang, I just became aware that this patch will involve changes to ALL include/configs/*.h files for AT91 AND AVR32 boards using atmel_usart.c. If thats OK I will do that. Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3] Tools: set multiple variable with fw_setenv utility
Dear Stefano Babic, In message <1274695696-8606-1-git-send-email-sba...@denx.de> you wrote: > Add a sort of batch mode to fw_setenv, allowing to set > multiple variables in one shot, without updating the flash after > each set as now. It is added the possibility to pass > a config file with a list of pairs to be set, > separated by a TAB character. > > Signed-off-by: Stefano Babic > --- > tools/env/fw_env.c | 269 > +++ > tools/env/fw_env.h |4 + > tools/env/fw_env_main.c | 67 +++-- > 3 files changed, 288 insertions(+), 52 deletions(-) Applied to "next" branch. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "If a computer can't directly address all the RAM you can use, it's just a toy." - anonymous comp.sys.amiga posting, non-sequitir ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] smc911x_eeprom
Ok, ok, I get it. On 6/29/10, Mike Frysinger wrote: > On Tuesday, June 29, 2010 10:59:02 Sergey Alyoshin wrote: >> smc911x_eeprom: smc911x_detect_chip() function return 0 on success > > this should be the subject, not the changelog > >> >> diff --git a/examples/standalone/smc911x_eeprom.c > > you're missing a signed-off-by tag which means your patch cannot be accepted > > this ignores the fact that someone has already sent in a patch for this > issue > and that has been added ;) > -mike > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] avr32: add unaligned.h
Dear =?UTF-8?q?Andreas=20Bie=C3=9Fmann?=, In message <1276072140-29939-1-git-send-email-biessm...@corscience.de> you wrote: > This patch fixes following error: > > zlib.c:31:27: error: asm/unaligned.h: No such file or directory > > Suggested-by: Mike Frysinger > Signed-off-by: Andreas Bießmann > --- > arch/avr32/include/asm/unaligned.h |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > create mode 100644 arch/avr32/include/asm/unaligned.h Applied to "next", thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It is easier to change the specification to fit the program than vice versa. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] avr32: fix linking of atstk100x and favr32 boards
Dear =?UTF-8?q?Andreas=20Bie=C3=9Fmann?=, In message <1276072052-29831-1-git-send-email-biessm...@corscience.de> you wrote: > > When building some avr32 boards out of tree (e.g. O..) the linker script could > not be found. This patch references the linker script in source tree. > > Signed-off-by: Andreas Bießmann > --- > board/atmel/atstk1000/config.mk|2 +- > board/earthlcd/favr-32-ezkit/config.mk |2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) Applied to "next" branch. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There are three things I always forget. Names, faces - the third I can't remember. - Italo Svevo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] avr32: disable branch folding
Dear =?UTF-8?q?Andreas=20Bie=C3=9Fmann?=, In message <1276085625-7785-1-git-send-email-biessm...@corscience.de> you wrote: > > Due to a hardware bug mentioned in latest AP7000 datasheet errata > (revision M from 09.09) branch folding is unreliable. > This patch disables CPUCR.FE bitfield as stated in datasheet. > > Signed-off-by: Andreas Bießmann > --- > > Changes since v1: > - fix comment > > arch/avr32/cpu/start.S |7 --- > 1 files changed, 4 insertions(+), 3 deletions(-) Applied to "next" branch. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Humanity has the stars in its future, and that future is too important to be lost under the burden of juvenile folly and ignorant superstition. - Isaac Asimov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fixed #if chain and added AVR32 case in cmd_bdinfo.c
Dear Reinhard Meyer, In message <4c11e777.3060...@emk-elektronik.de> you wrote: > This is a multi-part message in MIME format. > --060008080708060407080307 > Content-Type: text/plain; charset=ISO-8859-15 > Content-Transfer-Encoding: 7bit > > From: Reinhard Meyer > Date: Sun, 6 Jun 2010 19:01:59 +0200 > Subject: [PATCH] fixed #if chain and added AVR32 case in cmd_bdinfo.c > > AVR32 case was missing in cmd_bdinfo, resulting in compiler warning > (bd->bi_baudrate declared unsigned int at AVR32, but printf used %d) > > At the same time slightly reordered #if #elif #endif to make ARM one > of the cases and not an extra case surrounding all others > > > Signed-off-by: Reinhard Meyer > --- > common/cmd_bdinfo.c | 44 +++- > 1 files changed, 35 insertions(+), 9 deletions(-) Applied to "next". 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 People are always a lot more complicated than you think. It's very important to remember that. - Terry Pratchett, _Truckers_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix (null) problem for AVR32 boards
Dear "Reinhard Meyer (-VC)", In message <4c1600e8.6070...@emk-elektronik.de> you wrote: > Currently the U-Boot address ranges for AVR32 boards are > printed like this: > "U-Boot code: (null) -> 0001183c data: 000188e8 -> 0004e9b0" > This patch fixes this to print: > "U-Boot code: -> 0001183c data: 000188f8 -> 0004e9c0" > > Signed-off-by: Reinhard Meyer > --- > arch/avr32/lib/board.c |5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) Applied to "next" branch. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I will also, for an appropriate fee, certify that your keyboard is object-oriented, and that the bits on your hard disk are template- compatible.- Jeffrey S. Haemer in <411akr$...@cygnus.com> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] examples/standalone: Remove relocation compile flags for PowerPC
In message <1276631305-30648-1-git-send-email...@denx.de> you wrote: > From: Peter Tyser > > Previously, standalone applications were compiled with gcc flags that > produced relocatable executables on the PowerPC architecture (eg with > the -mrelocatable and -fPIC flags). There's no reason for these > applications to be fully relocatable at this time since no relocation > fixups are performed on standalone applications. > > Additionally, removing the gcc relocation flags results in the entry > point of applications residing at the base of the image. When > a standalone application was relocatable, the entry point was generally > located at an offset into the image which was confusing and prone to > errors. > > This change moves the entry point of PowerPC standalone applications > from 0x40004 (usually) to 0x4. > > Signed-off-by: Peter Tyser > Signed-off-by: Wolfgang Denk > --- > > It seems we need to cleanup a few more make variables (+AFLAGS, CPPFLAGS) > > examples/standalone/Makefile | 10 ++ > 1 files changed, 10 insertions(+), 0 deletions(-) Applied to "next". 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 Totally illogical, there was no chance. -- Spock, "The Galileo Seven", stardate 2822.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: fix wrong comment at GOT definitions
Dear Heiko Schocher, In message <4c19ac34.3020...@denx.de> you wrote: > r12 is used for accessing the GOT not r14. Fix this in the > comment. > > Signed-off-by: Heiko Schocher > --- > include/ppc_asm.tmpl |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Any sufficiently advanced technology is indistinguishable from magic. - Arthur C. Clarke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V6 10/10] MAKEALL: Add missing powerpc 36-bit targets
Dear Becky Bruce, In message <1276792647-4563-11-git-send-email-bec...@kernel.crashing.org> you wrote: > We were missing 8641HPCN_36BIT and MPC8536DS_36BIT. > > Signed-off-by: Becky Bruce > --- > MAKEALL |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "Here's a fish hangs in the net like a poor man's right in the law. 'Twill hardly come out." - Shakespeare, Pericles, Act II, Scene 1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] hwconfig: Add some unit tests
Dear Anton Vorontsov, In message <20100618110827.gb26...@oksana.dev.rtsoft.ru> you wrote: > I use this for testing, and I think this might be useful in the > future. > > Signed-off-by: Anton Vorontsov > --- > common/hwconfig.c | 55 > + > 1 files changed, 55 insertions(+), 0 deletions(-) Applied to "next", thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Overflow on /dev/null, please empty the bit bucket. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] hwconfig: Fix stop characters parsing for subkeys
Dear Anton Vorontsov, In message <20100618110812.ga26...@oksana.dev.rtsoft.ru> you wrote: > For the following hwconfig string: > > key1:subkey1=value1,subkey2=value2;key2:value3 > > The subkey2 cannot be extracted correctly. The parsing code looks > for comma as a stopch, but there may be two kind of stop characters: > a comma and a semicolon. > > Currently the code would return "value2;key2:value3", while just > "value2" is the correct answer. > > This patch fixes the issue by making the code aware of multiple > stop characters. > > For old U-Boots, the issue can be workarounded by placing a comma > before a semicolon, i.e.: > > hwconfig=key1:subkey1=value1,subkey2=value2,;key2:value3 > > Reported-by: York Sun > Signed-off-by: Anton Vorontsov > --- > common/hwconfig.c | 19 ++- > 1 files changed, 10 insertions(+), 9 deletions(-) Applied to "next" branch. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A supercomputer is a machine that runs an endless loop in 2 seconds. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Drop support for GTH board
The board maintainer states: The GTH board is obsolete and has not been manufactured for several years. To my knowledge, no recent U-Boot build has been tested on that card. So drop support for this board. Signed-off-by: Wolfgang Denk Cc: Thomas Lange --- MAINTAINERS |4 - MAKEALL |1 - board/gth/Makefile| 44 board/gth/README | 18 -- board/gth/config.mk | 40 --- board/gth/ee_access.c | 335 - board/gth/ee_access.h | 16 -- board/gth/ee_dev.h| 85 --- board/gth/flash.c | 649 - board/gth/gth.c | 595 - board/gth/pcmcia.c| 93 --- board/gth/u-boot.lds | 127 -- boards.cfg|1 - 13 files changed, 0 insertions(+), 2008 deletions(-) delete mode 100644 board/gth/Makefile delete mode 100644 board/gth/README delete mode 100644 board/gth/config.mk delete mode 100644 board/gth/ee_access.c delete mode 100644 board/gth/ee_access.h delete mode 100644 board/gth/ee_dev.h delete mode 100644 board/gth/flash.c delete mode 100644 board/gth/gth.c delete mode 100644 board/gth/pcmcia.c delete mode 100644 board/gth/u-boot.lds diff --git a/MAINTAINERS b/MAINTAINERS index d7aec98..08027ae 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -262,10 +262,6 @@ Sangmoon Kim debris MPC8245 KVME080 MPC8245 -Thomas Lange - - GTH MPC860 - Robert Lazarski ATUM8548MPC8548 diff --git a/MAKEALL b/MAKEALL index d6d5f5b..e7c87e1 100755 --- a/MAKEALL +++ b/MAKEALL @@ -118,7 +118,6 @@ LIST_8xx=" \ GEN860T \ GEN860T_SC \ GENIETV \ - GTH \ hermes \ IAD210 \ ICU862_100MHz \ diff --git a/board/gth/Makefile b/board/gth/Makefile deleted file mode 100644 index 4b5c528..000 --- a/board/gth/Makefile +++ /dev/null @@ -1,44 +0,0 @@ -# -# (C) Copyright 2000-2006 -# Wolfgang Denk, DENX Software Engineering, w...@denx.de. -# -# See file CREDITS for list of people who contributed to this -# project. -# -# This program is free software; you can redistribute it and/or -# modify it under the terms of the GNU General Public License as -# published by the Free Software Foundation; either version 2 of -# the License, or (at your option) any later version. -# -# This program is distributed in the hope that it will be useful, -# but WITHOUT ANY WARRANTY; without even the implied warranty of -# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -# GNU General Public License for more details. -# -# You should have received a copy of the GNU General Public License -# along with this program; if not, write to the Free Software -# Foundation, Inc., 59 Temple Place, Suite 330, Boston, -# MA 02111-1307 USA -# - -include $(TOPDIR)/config.mk - -LIB= $(obj)lib$(BOARD).a - -COBJS = $(BOARD).o flash.o ee_access.o pcmcia.o - -SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) -OBJS := $(addprefix $(obj),$(COBJS)) -SOBJS := $(addprefix $(obj),$(SOBJS)) - -$(LIB):$(obj).depend $(OBJS) - $(AR) $(ARFLAGS) $@ $(OBJS) - -# - -# defines $(obj).depend target -include $(SRCTREE)/rules.mk - -sinclude $(obj).depend - -# diff --git a/board/gth/README b/board/gth/README deleted file mode 100644 index 241c70b..000 --- a/board/gth/README +++ /dev/null @@ -1,18 +0,0 @@ -Written by thomas.la...@corelatus.com 010805 - -To make a system for gth that actually works ;-) -the variable TBASE needs to be set to 0,1 or 2 -depending on location where image is supposed to -be started from. -E.g. make TBASE=1 - -0: Start from RAM, base 0 - -1: Start from flash_base + 0x10070 - -2: Start from flash_base + 0x30070 - -When using 1 or 2, the image is supposed to be launched -from miniboot that boots the first U-Boot image found in -flash. -For miniboot code, description, see www.opensource.se diff --git a/board/gth/config.mk b/board/gth/config.mk deleted file mode 100644 index 3c80156..000 --- a/board/gth/config.mk +++ /dev/null @@ -1,40 +0,0 @@ -# -# (C) Copyright 2000, 2001 -# 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
Re: [U-Boot] [PATCH 4/6 v2] exports.c: fix warning: 'dummy' defined but not used
On Tuesday, June 29, 2010 05:52:32 Wolfgang Denk wrote: > Signed-off-by: Wolfgang Denk > --- > v2: fix compile problem for some boards. an attribute should fix all compile errors since the func never gets hidden ;) -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Make sure that argv[] argument pointers are not modified.
On Tuesday, June 29, 2010 05:49:25 Wolfgang Denk wrote: > arch/blackfin/cpu/bootrom-asm-offsets.c.in|2 +- this file isnt linked into u-boot, so i dont think it needs to be changed. it is actually compiled, just preprocessed and assembly output. > arch/blackfin/cpu/reset.c |2 +- > arch/blackfin/lib/boot.c |2 +- > arch/blackfin/lib/cmd_cache_dump.c|4 +- > arch/blackfin/lib/kgdb.c |2 +- > board/bf537-stamp/cmd_bf537led.c |2 +- > board/cm-bf527/gpio.c |2 +- > board/cm-bf537e/flash.c |2 +- > board/cm-bf537u/flash.c |2 +- > board/tcm-bf537/flash.c |2 +- > common/cmd_bootldr.c |2 +- > common/cmd_otp.c |2 +- these all look sane, so: Acked-by: Mike Frysinger -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please Pull u-boot-ti/next
Dear s-paul...@ti.com, In message <1277220546-18148-1-git-send-email-s-paul...@ti.com> you wrote: > Wolfgang, > > Please pull u-boot-ti/next. > I ran MAKEALL and so no issues. > > Thanks, > Sandeep > > The following changes since commit 54e19a7ded6e9dbdc3392a57d82f4f77b34e85b8: > Wolfgang Denk (1): > Merge branch 'master' into next > > are available in the git repository at: > > git://git.denx.de/u-boot-ti.git next > > Nick Thompson (1): > Davinci: SPI performance enhancements > > Prakash PM (1): > DaVinci: EMAC: Get EMAC_MDIO_PHY_NUM from config files > > arch/arm/include/asm/arch-davinci/emac_defs.h |2 +- > drivers/spi/davinci_spi.c | 195 > - > include/configs/da830evm.h|1 + > include/configs/davinci_dm365evm.h|1 + > include/configs/davinci_dvevm.h |1 + > include/configs/davinci_schmoogie.h |1 + > include/configs/davinci_sffsdr.h |1 + > include/configs/davinci_sonata.h |1 + > 8 files changed, 135 insertions(+), 68 deletions(-) Applied to "next" branch. 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 Live long and prosper. -- Spock, "Amok Time", stardate 3372.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix compiler warnings for EVB64260, P3G4 and ZUMA
Dear Anatolij Gustschin, In message <1277505568-30524-1-git-send-email-ag...@denx.de> you wrote: > Fix following warnings: > > $ ./MAKEALL EVB64260 P3G4 ZUMA > Configuring for EVB64260 board... > mpsc.c: In function 'mpsc_putchar_early': > mpsc.c:121: warning: dereferencing type-punned pointer will break > strict-aliasing rules > mpsc.c:127: warning: dereferencing type-punned pointer will break > strict-aliasing rules > ... > > Signed-off-by: Anatolij Gustschin > --- > board/evb64260/mpsc.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) Applied, thanks a lot! 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 Of course there's no reason for it, it's just our policy. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] image.h: remove bogus '; ' after function declarations
In message <1277588800-8870-1-git-send-email...@denx.de> you wrote: > ISO C does not allow extra ';' outside of a function > > Signed-off-by: Wolfgang Denk > --- > include/image.h | 44 ++-- > 1 files changed, 22 insertions(+), 22 deletions(-) Applied to "next" branch. 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 Just because your doctor has a name for your condition doesn't mean he knows what it is. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] smc911x_eeprom
On Tuesday, June 29, 2010 10:59:02 Sergey Alyoshin wrote: > smc911x_eeprom: smc911x_detect_chip() function return 0 on success this should be the subject, not the changelog > > diff --git a/examples/standalone/smc911x_eeprom.c you're missing a signed-off-by tag which means your patch cannot be accepted this ignores the fact that someone has already sent in a patch for this issue and that has been added ;) -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3 v2] drivers/serial/serial.c: code maintainability improvments.
Dear Michael Zaidman, In message you wrote: > > Since no feedback was received for the > http://lists.denx.de/pipermail/u-boot/2010-May/071443.html proposal it > looks like no one is willing to discuss this subject anymore. Probably not in this verbal form. You will often notice that verbal descriptions of what could be done receive little or no echo, while a patch will. > Are there still any known obstructions do not accept the > http://lists.denx.de/pipermail/u-boot/2010-April/069391.html as is? > This will solve all undefined references to `BUILD_BUG_ON' problem. I suggest you roll your proposal into code and submit patches - then we have a much better base to discuss. 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 Earth -- mother of the most beautiful women in the universe. -- Apollo, "Who Mourns for Adonais?" stardate 3468.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Use memcpy in print_buffer to fix unaligned dumps
On Tuesday, June 29, 2010 08:53:06 Wolfgang Denk wrote: > Anatolij Gustschin wrote: > > Unaligned 32-/16-bit accesses to local bus on MPC5200 > > and MPC512x deliver corrupted data: > > Right, and the current version of print_buffer() shopws the real data, > i. e. you can see that such a corruption happens. i also prefer the current behavior. on Blackfin systems, you get unaligned exceptions when you try to do 'md.l 1' and it's a nice way to quickly exercise those code paths ;). -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Pull request: u-boot-sh
Dear Nobuhiro Iwamatsu, In message you wrote: > > Please pull: > The following changes since commit e5ed138a23923ebe61843244748d98d3dbc04777: > > Merge branch 'master' of ssh://gemini/home/wd/git/u-boot/master > (2010-06-23 20:55:27 +0200) > > are available in the git repository at: > > git://git.denx.de/u-boot-sh.git master > > Nobuhiro Iwamatsu (4): > sh: Fix build on the target > sh: Fix overflow problem in get_ticks > sh: Fix path of irqflags.h > sh: Add trigger_address_error and support cpu reset > > Makefile |3 ++- > arch/sh/cpu/sh2/watchdog.c |8 ++-- > arch/sh/cpu/sh3/watchdog.c |7 +++ > arch/sh/cpu/sh4/watchdog.c |4 > arch/sh/include/asm/system.h | 12 +++- > arch/sh/lib/time.c | 20 ++-- > 6 files changed, 48 insertions(+), 6 deletions(-) Sorry, this was way too late for the upcoming release, so I pulled this into the "next" branch. 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 Of all the things I've lost, I miss my mind the most. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] EHCI: zero out QH transfer overlay in ehci_submit_async()
Dear Sergei Shtylyov, In message <201006282244.49973.sshtyl...@ru.mvista.com> you wrote: > ehci_submit_async() doesn't really zero out the QH transfer overlay (as the > EHCI > specification suggests) which leads to the controller seeing the "token" field > as the previous call has left it, i.e.: > - if a timeout occured on the previous call (Active bit left as 1), controller > incorrectly tries to complete a previous transaction on a newly programmed > endpoint; > - if a halt occured on the previous call (Halted bit set to 1), controller > just > ignores the newly programmed TD(s) and the function then keeps returning > error > ad infinitum. > > This turned out to be caused by the wrong orger of the arguments to the > memset() > call in ehci_alloc(), so the allocated TDs weren't cleared either. > > While at it, stop needlessly initializing the alternate next TD pointer in the > QH transfer overlay... > > Signed-off-by: Sergei Shtylyov > > --- > Initialization of 'qh->qh_overlay.qt_next' turned out to be needed by the > error > cleanup code (seemingly useless, in its turn). > > This is quite serious bug, so would be good to have the patch in v2010.06... > > drivers/usb/host/ehci-hcd.c |3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Small is beautiful. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MPC512x: workaround data corruption for unaligned local bus accesses
In message <1277804892-453-1-git-send-email...@denx.de> you wrote:
> Commit 460c2ce3 "MPC5200: workaround data corruption for unaligned
> local bus accesses" fixed the problem for MPC5200 only, but MPC512x is
> affected as well, so apply the same fix here, too.
>
> Signed-off-by: Wolfgang Denk
> Cc: Detlev Zundel
> Cc: Anatolij Gustschin
> ---
> arch/powerpc/cpu/mpc5xxx/Makefile |5 -
> arch/powerpc/lib/Makefile | 16
> arch/powerpc/{cpu/mpc5xxx => lib}/memcpy_mpc5200.c |0
> 3 files changed, 12 insertions(+), 9 deletions(-)
> rename arch/powerpc/{cpu/mpc5xxx => lib}/memcpy_mpc5200.c (100%)
Applied
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 of peace usually are [brave].
-- Spock, "The Savage Curtain", stardate 5906.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Numonyx NOR support in u-boot
Hi, We are seeing NOR write failures on 6 of the 10 boards (DM6446 ARM SoC with Numonyx JS28F256M29EWL NOR flash chip). Four of the boards seem to work without error. All 10 boards were made on the same manufacturing line at the same time. Initially, we couldn't properly read the QRY response from the chip. We had to use this patch http://www.mail-archive.com/u-boot@lists.denx.de/msg26614.html We are getting 'flash not erased' error or timeout error. We have tried monitoring D7 (busy) and monitoring D6 (activity toggle) to detect erase / program command completion / timeout. We have tried changing the timing of the control signals to the NOR chip, but need to use a logic state analyzer to verify the timing is changed as expected. Example error output: > cp 0x8170 0x0200 0x40 Copy to Flash... Flash not Erased Timeout writing to Flash > cp 0x8170 0x0200 0x40 Copy to Flash... Flash write timeout at address 200 data 129f34 We have tried cp, cp.b, cp.w and get the same results. With 4 boards working correctly, the code must be close. Any suggestions (beyond looking at the signals with a Logic State Analyzer)? Todd ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MPC512x: workaround data corruption forunaligned local bus accesses
Dear "Steve Deiters", In message <181804936abc2349be503168465576460f272...@exchserver.basler.com> you wrote: > > I just posted a patch on the linuxppc-dev list that simply uses a > slightly modified version of memcpy to always keep the source address > aligned. I had conditionals in that one so it only used it for MPC512x > or MPC52xx but you should be able to replace the regular memcpy with > this version. This way you can avoid the wrappers and extra checks. It > is a simple enough change in that case: Thanks. I'll keep this queued and try to run some tests with it on different architectures - I don't know which side effects might be caused by changing the alignment from target to source address, so I will not introduce such a change at this point in the release cycle, literally minutes before a release. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If you hear an onion ring, answer it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] AT91SAM9 series - cleanup USART definitions
Dear Reinhard Meyer, In message <4c2a3c42.7050...@emk-elektronik.de> you wrote: > > I propose to make the following changes: Please go on and submit a patch. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Substitute "damn" every time you're inclined to write "very"; your editor will delete it and the writing will be just as it should be. - Mark Twain ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix console_buffer size conflict error.
Dear Remy Bohmer, In message <1276802228-22080-1-git-send-email-li...@bohmer.net> you wrote: > The console_buffer size is declared in common/main.c as >-- char console_buffer[CONFIG_SYS_CBSIZE + 1]; > so this extern definition is wrong. > > Signed-off-by: Remy Bohmer > --- > common/hush.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Nobody goes to that restaurant anymore. It's too crowded. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][v1] 85xx/p1_p2_rdb: Added RevD board version support
Dear Poonam Aggrwal, In message <1277191246-4245-1-git-send-email-poonam.aggr...@freescale.com> you wrote: > - Also modified the code to use io accessors. > > Signed-off-by: Poonam Aggrwal > Signed-off-by: Dipen Dudhat > --- > Incorporated Wolfgang's comments on earlier patch > board/freescale/p1_p2_rdb/p1_p2_rdb.c | 16 +--- > 1 files changed, 13 insertions(+), 3 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A Stanford research group advertised for participants in a study of obsessive-compulsive disorder. They were looking for therapy clients who had been diagnosed with this disorder. The response was grati- fying; they got 3,000 responses about three days after the ad came out. All from the same person. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tsec: Fix eTSEC2 link problem on P2020RDB
On Tue, 2010-06-29 at 21:02 +0200, Wolfgang Denk wrote: > Dear Felix Radensky, > > In message <1277679459-9453-1-git-send-email-fe...@embedded-sol.com> you > wrote: > > On P2020RDB eTSEC2 is connected to Vitesse VSC8221 PHY via SGMII. > > Current TBI PHY settings for SGMII mode cause link problems on > > this platform, link never comes up. > > > > Fix this by making TBI PHY settings configurable and add a working > > configuration for P2020RDB. > > > > Signed-off-by: Felix Radensky > > --- > > drivers/net/tsec.c |6 +- > > include/configs/P1_P2_RDB.h |9 + > > 2 files changed, 14 insertions(+), 1 deletions(-) > > Applied, thanks. A little late, but: Acked-by: Peter Tyser Tested-by: Peter Tyser Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tsec: Fix eTSEC2 link problem on P2020RDB
Dear Felix Radensky, In message <1277679459-9453-1-git-send-email-fe...@embedded-sol.com> you wrote: > On P2020RDB eTSEC2 is connected to Vitesse VSC8221 PHY via SGMII. > Current TBI PHY settings for SGMII mode cause link problems on > this platform, link never comes up. > > Fix this by making TBI PHY settings configurable and add a working > configuration for P2020RDB. > > Signed-off-by: Felix Radensky > --- > drivers/net/tsec.c |6 +- > include/configs/P1_P2_RDB.h |9 + > 2 files changed, 14 insertions(+), 1 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Man did not weave the web of life; he is merely a strand in it. Whatever he does to the web, he does to himself. - Seattle [1854] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 85xx/p1_p2_rdb: Modify the CLK_CTRL value for DDR at 667MHz
Dear Poonam Aggrwal, In message <1277301748-14249-1-git-send-email-poonam.aggr...@freescale.com> you wrote: > Use a slighly larger value of CLK_CTRL for DDR at 667MHz > which fixes random crashes while linux booting. > > Applicable for both NAND and NOR boot. > > Signed-off-by: Sandeep Gopalpet > Signed-off-by: Poonam Aggrwal > --- > board/freescale/p1_p2_rdb/ddr.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I have a theory that it's impossible to prove anything, but I can't prove it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tsec: Fix eTSEC2 link problem on P2020RDB
On Sun, Jun 27, 2010 at 5:57 PM, Felix Radensky wrote: > On P2020RDB eTSEC2 is connected to Vitesse VSC8221 PHY via SGMII. > Current TBI PHY settings for SGMII mode cause link problems on > this platform, link never comes up. > > Fix this by making TBI PHY settings configurable and add a working > configuration for P2020RDB. > > Signed-off-by: Felix Radensky Acked-by: Andy Fleming ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 85xx/p1_p2_rdb: Modify the CLK_CTRL value for DDR at 667MHz
On Wed, Jun 23, 2010 at 9:02 AM, Poonam Aggrwal wrote: > Use a slighly larger value of CLK_CTRL for DDR at 667MHz > which fixes random crashes while linux booting. > > Applicable for both NAND and NOR boot. > > Signed-off-by: Sandeep Gopalpet > Signed-off-by: Poonam Aggrwal Oops, forgot to reply all: Acked-by: Andy Fleming ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [Bugfix] 85xx/p1_p2_rdb: not able to modify "$bootfile" environment variable
Dear Poonam Aggrwal, In message <1277302327-14729-1-git-send-email-poonam.aggr...@freescale.com> you wrote: > Because the variable was getting defined twice. > Signed-off-by: Poonam Aggrwal > --- > include/configs/P1_P2_RDB.h |1 - > 1 files changed, 0 insertions(+), 1 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de To know how another being, another creature feels - that is impos- sible. - Terry Pratchett, _The Dark Side of the Sun_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] IRQ in realmode and sleep()
On Tue, Jun 29, 2010 at 10:03:53AM +0200, Reinhard Arlt wrote: > Hello, > > the data cache is disabled on the CPCI750 board for the SDRAM by the > DBAT entry for the SDRAM, but the data cache is enabled for most > 74xx_7xx boards in > > cpu/74xx_7xx/start.S together with the translation. > > The decrementer irq is executed in real mode with translation disabled. > > Now in the irq routine, the processor writes the data into the cache, > and the sleep() reads directly from RAM, and do not see the timer running. > > A good solution would be to have translation on for the irq's too, but a > simple solution is to put an '#if !(defined CPCI750)' around the > routine, that enables the l1 data cache. Sounds like the right solution is to change the DBAT to be cacheable. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 10/18] SPEAr : Configuring FSMC driver for NAND interface
On Tue, Jun 29, 2010 at 10:53:38AM +0530, Vipin KUMAR wrote: > From: Vipin KUMAR > > Since FSMC is a standard IP and it supports different memory interfaces, it > is supported independent of spear platform and spear is configured to use that > driver for interfacing with the NAND device > > Spear platform uses generic FSMC driver and spear specific files i.e > drivers/mtd/nand/spr_nand.c, arch/arm/include/asm/arch-spear/spr_nand.h are > removed > > Signed-off-by: Vipin Kumar > --- > arch/arm/include/asm/arch-spear/hardware.h |8 +- > arch/arm/include/asm/arch-spear/spr_nand.h | 57 - > board/spear/spear300/spear300.c|7 +- > board/spear/spear310/spear310.c|7 +- > board/spear/spear320/spear320.c|7 +- > board/spear/spear600/spear600.c|7 +- > drivers/mtd/nand/Makefile |1 - > drivers/mtd/nand/spr_nand.c| 124 > > include/configs/spear-common.h |2 +- > include/configs/spear3xx.h |4 + > include/configs/spear6xx.h |3 + > 11 files changed, 28 insertions(+), 199 deletions(-) > delete mode 100644 arch/arm/include/asm/arch-spear/spr_nand.h > delete mode 100644 drivers/mtd/nand/spr_nand.c Acked-by: Scott Wood -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 09/18] SPEAr : FSMC driver support added
On Tue, Jun 29, 2010 at 10:53:37AM +0530, Vipin KUMAR wrote: > From: Vipin KUMAR > > Flexible static memory controller is a peripheral provided by ST, > which controls the access to NAND chips along with many other > memory device chips eg NOR, SRAM. > > This patch adds the driver support for FSMC controller interfacing > with NAND memory. > > Signed-off-by: Vipin Kumar > --- > drivers/mtd/nand/Makefile |1 + > drivers/mtd/nand/fsmc_nand.c | 366 > + > include/linux/mtd/fsmc_nand.h | 104 > 3 files changed, 471 insertions(+), 0 deletions(-) > create mode 100644 drivers/mtd/nand/fsmc_nand.c > create mode 100644 include/linux/mtd/fsmc_nand.h Acked-by: Scott Wood -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] AT91SAM9 series - cleanup USART definitions
Hi, AT91SAM9 based boards have something like this in their include/configs file: #define CONFIG_ATMEL_USART1 #undef CONFIG_USART0 #undef CONFIG_USART1 #undef CONFIG_USART2 #define CONFIG_USART31/* USART 3 is DBGU */ these defines are used in drivers/serial/atmel_usart.c: #if defined(CONFIG_USART0) # define USART_ID0 # define USART_BASEUSART0_BASE #elif defined(CONFIG_USART1) # define USART_ID1 # define USART_BASEUSART1_BASE #elif defined(CONFIG_USART2) # define USART_ID2 # define USART_BASEUSART2_BASE #elif defined(CONFIG_USART3) # define USART_ID3 # define USART_BASEUSART3_BASE #endif USARTx_BASE is defined in arch/arm/include/asm/arch-at91/memory_map.h: #define USART0_BASE AT91_USART0 #define USART1_BASE AT91_USART1 #define USART2_BASE AT91_USART2 #define USART3_BASE (AT91_BASE_SYS + AT91_DBGU) #define SPI0_BASEAT91_BASE_SPI (note that nothing else is defined in that file!) AT91_USARTx finally comes from arch/arm/include/asm/arch-at91/at91sam*.h: #define AT91_USART0AT91SAM9260_BASE_US0 #define AT91_USART1AT91SAM9260_BASE_US1 #define AT91_USART2AT91SAM9260_BASE_US2 #define AT91_USART3AT91SAM9260_BASE_US3 #define AT91_USART4AT91SAM9260_BASE_US4 #define AT91_USART5AT91SAM9260_BASE_US5 1. memory_map.h is misleading, it just defines a few USARTs and one SPI 2. equalling CONFIG_USART3 with the debug UART is plain wrong, the 9260 for example has 6 'regular' USARTs (0..5) plus the debug UART I propose to make the following changes: 1. get rid of memory_map.h and the references to it, move the USART definitions to the respective at91sam*.h files 2. use DBU_BASE for the debug UART, leaving USART[0-5]_BASE to adress the 'regular' USARTs 3. use CONFIG_UARTDEBUG to indicate use of the debug UART for console output Note for those that don't want to dig the datasheets: the debug UART is software compatible to the 'regular' USARTs as long as only asynchronous features are used (true for the atmel_usart.c driver) Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [Bugfix] 85xx/p1_p2_rdb: not able to modify "$bootfile" environment variable
On Wed, Jun 23, 2010 at 9:12 AM, Poonam Aggrwal wrote: > Because the variable was getting defined twice. > Signed-off-by: Poonam Aggrwal Acked-by: Andy Fleming > --- > include/configs/P1_P2_RDB.h | 1 - > 1 files changed, 0 insertions(+), 1 deletions(-) > > diff --git a/include/configs/P1_P2_RDB.h b/include/configs/P1_P2_RDB.h > index 4f72f36..02e5281 100644 > --- a/include/configs/P1_P2_RDB.h > +++ b/include/configs/P1_P2_RDB.h > @@ -674,7 +674,6 @@ extern unsigned long get_board_sys_clk(unsigned long > dummy); > "netdev=eth0\0" \ > "uboot=" MK_STR(CONFIG_UBOOTPATH) "\0" \ > "loadaddr=100\0" \ > - "bootfile=uImage\0" \ > "tftpflash=tftpboot $loadaddr $uboot; " \ > "protect off " MK_STR(TEXT_BASE) " +$filesize; " \ > "erase " MK_STR(TEXT_BASE) " +$filesize; " \ > -- > 1.5.6.5 > > ___ > 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] Congratulations
You won £1,000,000 in the Microsoft lottery,send your Name,Add,Country to email address johna...@hotmail.com Servicio brindado por Velocom - http://www.velocom.com.ar/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] s3c44b0 serial driver questions
On Tue, Jun 22, 2010 at 10:11 AM, Andrea Scian
wrote:
>
> Dear Brian,
>
> yes it can be. IIRC I worked only with 75MHz version of S3C44B0, I've never
> used a 66MHz one.
It seems that no existing boards use this driver in the 66MHz mode.
So perhaps nobody has used it:)
> Unfortunately I do not have such a board here, neither the time ;-), to
> check your bug report..
> Did you already check the 66MHz BRD formula?
Yes. The existing dividers are correct for the 75MHz case, but are
all off by 5 or 10% for the 66MHz case.
> If it's correct in you testbed to me you can send the patch for commiting
I'm not testing on an ARM7/B2. I'm testing on an ARM9 called Pollux
that has similar serial hardware. My proposed change is meant to
groom the driver so it can work for S3C44B0 and Pollux targets (and
perhaps others). I'll submit the patch for review shortly.
Ciao,
Brian
>
> Best Regards,
>
> --
>
>
> Andrea Scian
>
> DAVE Srl - Electronics System House
> via Forniz 2/1
> 33080 Porcia (PN) - Italy
> Telephone: +39.0434.921215
> Telefax: +39.0434.1994030
> web: www.dave-tech.it
> e-mail address: andrea.sc...@dave-tech.it
> how to reach us: http://mail.map24.com/dave
>
>
> On 21/06/2010 14.45, Brian Cavagnolo wrote:
>>
>> Hello,
>>
>> I'm hoping to use the s3c44b0 serial driver for a CPU with very similar
>> serial
>> hardware. One change that I must make is to calculate the baud rate
>> divisor
>> with a macro because this operation is board-specific. I propose to clean
>> up
>> the large switch statement in the existing code with a macro that
>> calculates
>> the BRD using the formula in the datasheet ("S3C44B0X RISC MICROPROCESSOR"
>> pg. 10-7; See proposed patch below.) However, the BRD values in the
>> current
>> code for the 66MHz case do not match the formula in the data sheet. They
>> are
>> all skewed high. Is this a bug?
>>
>> Ciao,
>> Brian
>>
>> diff --git a/arch/arm/include/asm/arch-s3c44b0/hardware.h
>> b/arch/arm/include/asm/arch-s3c44b0/hardware.h
>> index 146e265..38ff32c 100644
>> --- a/arch/arm/include/asm/arch-s3c44b0/hardware.h
>> +++ b/arch/arm/include/asm/arch-s3c44b0/hardware.h
>> @@ -11,7 +11,8 @@
>> #define REGL(addr) (*(volatile unsigned int *)(REGBASE+addr))
>> #define REGW(addr) (*(volatile unsigned short *)(REGBASE+addr))
>> #define REGB(addr) (*(volatile unsigned char *)(REGBASE+addr))
>> -
>> +#define BRD(bps) (DIV_ROUND(CONFIG_S3C44B0_CLOCK_SPEED * 100, \
>> + (bps)*16) - 1)
>>
>> /*/
>> /* CPU Wrapper Registers */
>> diff --git a/drivers/serial/serial_s3c44b0.c
>> b/drivers/serial/serial_s3c44b0.c
>> index 95d0266..e6c535c 100644
>> --- a/drivers/serial/serial_s3c44b0.c
>> +++ b/drivers/serial/serial_s3c44b0.c
>> @@ -70,68 +70,7 @@ static int serial_flush_output(void)
>>
>> void serial_setbrg (void)
>> {
>> - u32 divisor = 0;
>> -
>> - /* get correct divisor */
>> - switch(gd->baudrate) {
>> -
>> - case 1200:
>> -#if CONFIG_S3C44B0_CLOCK_SPEED==66
>> - divisor = 3124;
>> -#elif CONFIG_S3C44B0_CLOCK_SPEED==75
>> - divisor = 3905;
>> -#else
>> -# error CONFIG_S3C44B0_CLOCK_SPEED undefined
>> -#endif
>> - break;
>> -
>> - case 9600:
>> -#if CONFIG_S3C44B0_CLOCK_SPEED==66
>> - divisor = 390;
>> -#elif CONFIG_S3C44B0_CLOCK_SPEED==75
>> - divisor = 487;
>> -#else
>> -# error CONFIG_S3C44B0_CLOCK_SPEED undefined
>> -#endif
>> - break;
>> -
>> - case 19200:
>> -#if CONFIG_S3C44B0_CLOCK_SPEED==66
>> - divisor = 194;
>> -#elif CONFIG_S3C44B0_CLOCK_SPEED==75
>> - divisor = 243;
>> -#else
>> -# error CONFIG_S3C44B0_CLOCK_SPEED undefined
>> -#endif
>> - break;
>> -
>> - case 38400:
>> -#if CONFIG_S3C44B0_CLOCK_SPEED==66
>> - divisor = 97;
>> -#elif CONFIG_S3C44B0_CLOCK_SPEED==75
>> - divisor = 121;
>> -#else
>> -# error CONFIG_S3C44B0_CLOCK_SPEED undefined
>> -#endif /* break; */
>> -
>> - case 57600:
>> -#if CONFIG_S3C44B0_CLOCK_SPEED==66
>> - divisor = 64;
>> -#elif CONFIG_S3C44B0_CLOCK_SPEED==75
>> - divisor = 80;
>> -#else
>> -# error CONFIG_S3C44B0_CLOCK_SPEED undefined
>> -#endif /* break; */
>> -
>> - case 115200:
>> -#if CONFIG_S3C44B0_CLOCK_SPEED==66
>> - divisor = 32;
>> -#elif CONFIG_S3C44B0_CLOCK_SPEED==75
>> - divisor = 40;
>> -#else
>> -# error CONFIG_S3C44B0_CLOCK_SPEED undefined
>> -#endif /* break; */
>> - }
>> + u32 divisor = BRD(gd->baudrate);
>>
>> serial_flush_output();
>> serial_flush_input();
>>
>>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] bug fix and cleanup for s3c44b0 serial driver
Specifically, don't dereference the URXH0 register twice; calculate the BRD
based on the formula in the databook instead of using a messy switch statement;
and migrate the BRD calculation to the hardware hardware header because it's
board specific.
Signed-off-by: Brian Cavagnolo
---
arch/arm/include/asm/arch-s3c44b0/hardware.h |3 +-
drivers/serial/serial_s3c44b0.c | 65 +-
2 files changed, 4 insertions(+), 64 deletions(-)
diff --git a/arch/arm/include/asm/arch-s3c44b0/hardware.h
b/arch/arm/include/asm/arch-s3c44b0/hardware.h
index 146e265..38ff32c 100644
--- a/arch/arm/include/asm/arch-s3c44b0/hardware.h
+++ b/arch/arm/include/asm/arch-s3c44b0/hardware.h
@@ -11,7 +11,8 @@
#define REGL(addr) (*(volatile unsigned int *)(REGBASE+addr))
#define REGW(addr) (*(volatile unsigned short *)(REGBASE+addr))
#define REGB(addr) (*(volatile unsigned char *)(REGBASE+addr))
-
+#define BRD(bps) (DIV_ROUND(CONFIG_S3C44B0_CLOCK_SPEED * 100, \
+ (bps)*16) - 1)
/*/
/* CPU Wrapper Registers */
diff --git a/drivers/serial/serial_s3c44b0.c b/drivers/serial/serial_s3c44b0.c
index 95d0266..e6c535c 100644
--- a/drivers/serial/serial_s3c44b0.c
+++ b/drivers/serial/serial_s3c44b0.c
@@ -48,7 +48,7 @@ static int serial_flush_input(void)
/* keep on reading as long as the receiver is not empty */
while(UTRSTAT0&0x01) {
- tmp = REGB(URXH0);
+ tmp = URXH0;
}
return 0;
@@ -70,68 +70,7 @@ static int serial_flush_output(void)
void serial_setbrg (void)
{
- u32 divisor = 0;
-
- /* get correct divisor */
- switch(gd->baudrate) {
-
- case 1200:
-#if CONFIG_S3C44B0_CLOCK_SPEED==66
- divisor = 3124;
-#elif CONFIG_S3C44B0_CLOCK_SPEED==75
- divisor = 3905;
-#else
-# error CONFIG_S3C44B0_CLOCK_SPEED undefined
-#endif
- break;
-
- case 9600:
-#if CONFIG_S3C44B0_CLOCK_SPEED==66
- divisor = 390;
-#elif CONFIG_S3C44B0_CLOCK_SPEED==75
- divisor = 487;
-#else
-# error CONFIG_S3C44B0_CLOCK_SPEED undefined
-#endif
- break;
-
- case 19200:
-#if CONFIG_S3C44B0_CLOCK_SPEED==66
- divisor = 194;
-#elif CONFIG_S3C44B0_CLOCK_SPEED==75
- divisor = 243;
-#else
-# error CONFIG_S3C44B0_CLOCK_SPEED undefined
-#endif
- break;
-
- case 38400:
-#if CONFIG_S3C44B0_CLOCK_SPEED==66
- divisor = 97;
-#elif CONFIG_S3C44B0_CLOCK_SPEED==75
- divisor = 121;
-#else
-# error CONFIG_S3C44B0_CLOCK_SPEED undefined
-#endif /* break; */
-
- case 57600:
-#if CONFIG_S3C44B0_CLOCK_SPEED==66
- divisor = 64;
-#elif CONFIG_S3C44B0_CLOCK_SPEED==75
- divisor = 80;
-#else
-# error CONFIG_S3C44B0_CLOCK_SPEED undefined
-#endif /* break; */
-
- case 115200:
-#if CONFIG_S3C44B0_CLOCK_SPEED==66
- divisor = 32;
-#elif CONFIG_S3C44B0_CLOCK_SPEED==75
- divisor = 40;
-#else
-# error CONFIG_S3C44B0_CLOCK_SPEED undefined
-#endif /* break; */
- }
+ u32 divisor = BRD(gd->baudrate);
serial_flush_output();
serial_flush_input();
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] smc911x_eeprom
Hi Sergey,
On 6/29/2010 7:59 AM, Sergey Alyoshin wrote:
smc911x_eeprom: smc911x_detect_chip() function return 0 on success
diff --git a/examples/standalone/smc911x_eeprom.c
b/examples/standalone/smc911x_eeprom.c
index 104047f..cb3c131 100644
--- a/examples/standalone/smc911x_eeprom.c
+++ b/examples/standalone/smc911x_eeprom.c
@@ -240,7 +240,7 @@ static void dump_eeprom(struct eth_device *dev)
static int smc911x_init(struct eth_device *dev)
{
/* See if there is anything there */
- if (!smc911x_detect_chip(dev))
+ if (smc911x_detect_chip(dev))
return 1;
smc911x_reset(dev);
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Somebody beat you to it. See commit
88fd3dbe7dac275bc2ae7727c7ebd293c53780c0 in net/next.
regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MPC512x: workaround data corruption forunaligned local bus accesses
> -Original Message- > From: u-boot-boun...@lists.denx.de > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wolfgang Denk > Sent: Tuesday, June 29, 2010 7:56 AM > To: Joakim Tjernlund > Cc: u-boot@lists.denx.de > Subject: Re: [U-Boot] [PATCH] MPC512x: workaround data > corruption forunaligned local bus accesses > > Dear Joakim Tjernlund, > > In message > nsmode.se> you wrote: > > > > > I could not come up with a better name... What is "align32wrap" > > > supposed to mean? > > > > mpc5200_memcpy_fromio() resp. mpc5200_memcpy_toio()? > > No. It's not only MPC5200, but also MPC521x. It's not I/O in > general, but only I/O from the Local Bus. And even then only > unaliged read access. > > But memcpy_for_unaligned_read_from_local_bus() was too long > for me, and memcpy_furflb() too cryptic ;-) > > Best regards, > > Wolfgang Denk I just posted a patch on the linuxppc-dev list that simply uses a slightly modified version of memcpy to always keep the source address aligned. I had conditionals in that one so it only used it for MPC512x or MPC52xx but you should be able to replace the regular memcpy with this version. This way you can avoid the wrappers and extra checks. It is a simple enough change in that case: diff --git a/arch/powerpc/lib/ppcstring.S b/arch/powerpc/lib/ppcstring.S index 97023a0..4e17265 100644 --- a/arch/powerpc/lib/ppcstring.S +++ b/arch/powerpc/lib/ppcstring.S @@ -114,7 +114,7 @@ memcpy: addir6,r3,-4 addir4,r4,-4 beq 2f /* if less than 8 bytes to do */ - andi. r0,r6,3 /* get dest word aligned */ + andi. r0,r4,3 /* get src word aligned */ mtctr r7 bne 5f 1: lwz r7,4(r4) @@ -125,6 +125,8 @@ memcpy: andi. r5,r5,7 2: cmplwi 0,r5,4 blt 3f + andi. r0,r4,3 + bne 3f lwzur0,4(r4) addir5,r5,-4 stwur0,4(r6) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Micrel Controller KSZ8841-16MBL
Hi Steve. Did you succeed on running the driver for KS8841? Did you have to change anything? We are debugging it and some modifications might be necessary for our platform. Hope to hear from you. Regards, Douglas On Tue, Jun 22, 2010 at 11:25 PM, Steve Sakoman wrote: > On Tue, Jun 22, 2010 at 5:26 PM, Ben Warren > wrote: > > > A few years ago I wrote a driver for KS8841 and got it working (16-bit > > memory-mapped on PowerPC). I started with the Micrel driver, but as you > > know it's pretty ugly. Last week I dusted off that old driver and got it > to > > compile with the latest U-boot, but wasn't able to test it because the > > company that I worked for is long gone. It's hopefully close to > functional, > > but still has too many style issues to post publicly. I sent the driver > to > > Douglas off-line, and am awaiting feedback. If you'd like, I can send it > to > > you too. It'd be nice to have a single driver that handles different > chips, > > but with configurable accessors. > > Yes, please send me a copy! I'll take a look and see if it looks like > it will work with the 8851. > > I agree it would be quite nice if we could have a single driver. > > Steve > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] How to support the embedded flash in AT91SAM9XE series ?
Hi, I want to add support for the embedded flash (128/256/512 kbytes) in those SoCs. In short this flash has the following unique features: 1. memory mapped and read accessible like any NOR flash 2. at reset it can also be mapped to adress 0x0 (by setting a NV bit) 3. it has a pagesize of 512 bytes, only full pages can be rewritten with 32 bit access 4. regions of 32 pages (hence 16 kbytes) can be locked (write protected) 5. the exact disposition (#pages, lock status etc) of the flash can be enquired at run time and hence should not be #defined at compile time Feature 3 prevents a simple "cp" like command like for NOR flash unless the copy command can be made to fail when it does not encompass full pages AND the copy command can be made such that the copying to flash itself is done by a specialised function. "protect on/off" could be made similiarly working, rounding up to full region sizes a command to set/reset that NV bit should be added Another possible solution would be to add a new command similiar to the "NAND" command for write purposes, lock and NV bit. Finally, u-boot itself, the environment and a possible backup should be able to be in that flash, too. Any comments/suggestions on this? Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] smc911x_eeprom
smc911x_eeprom: smc911x_detect_chip() function return 0 on success
diff --git a/examples/standalone/smc911x_eeprom.c
b/examples/standalone/smc911x_eeprom.c
index 104047f..cb3c131 100644
--- a/examples/standalone/smc911x_eeprom.c
+++ b/examples/standalone/smc911x_eeprom.c
@@ -240,7 +240,7 @@ static void dump_eeprom(struct eth_device *dev)
static int smc911x_init(struct eth_device *dev)
{
/* See if there is anything there */
- if (!smc911x_detect_chip(dev))
+ if (smc911x_detect_chip(dev))
return 1;
smc911x_reset(dev);
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MPC512x: workaround data corruption for unaligned local bus accesses
>
> Wolfgang Denk wrote on 2010/06/29 14:55:44:
> >
> > Dear Joakim Tjernlund,
> >
> > In message > 0045d...@transmode.se> you wrote:
> > >
> > > > I could not come up with a better name... What is "align32wrap"
> > > > supposed to mean?
> > >
> > > mpc5200_memcpy_fromio() resp. mpc5200_memcpy_toio()?
> >
> > No. It's not only MPC5200, but also MPC521x. It's not I/O in general,
> > but only I/O from the Local Bus. And even then only unaliged read
> > access.
> >
> > But memcpy_for_unaligned_read_from_local_bus() was too long for me,
> > and memcpy_furflb() too cryptic ;-)
>
> memcpy_align_src()?
>
>Jocke
BTW, perhaps this memcpy I wrote for uClibc long time ago
is useful? You can easily change dst or src alignment:
void *memcpy(void *to, const void *from, size_t len)
{
unsigned long rem, chunks, tmp1, tmp2;
unsigned char *tmp_to;
unsigned char *tmp_from = (unsigned char *)from;
chunks = len / 8;
tmp_from -= 4;
tmp_to = to - 4;
if (!chunks)
goto lessthan8;
rem = (unsigned long )tmp_to % 4;
if (rem)
goto align;
copy_chunks:
do {
/* make gcc to load all data, then store it */
tmp1 = *(unsigned long *)(tmp_from+4);
tmp_from += 8;
tmp2 = *(unsigned long *)tmp_from;
*(unsigned long *)(tmp_to+4) = tmp1;
tmp_to += 8;
*(unsigned long *)tmp_to = tmp2;
} while (--chunks);
lessthan8:
len = len % 8;
if (len >= 4) {
tmp_from += 4;
tmp_to += 4;
*(unsigned long *)(tmp_to) = *(unsigned long *)(tmp_from);
len -= 4;
}
if (!len)
return to;
tmp_from += 3;
tmp_to += 3;
do {
*++tmp_to = *++tmp_from;
} while (--len);
return to;
align:
/* ???: Do we really need to generate the carry flag here? If not, then:
rem -= 4; */
rem = 4 - rem;
len -= rem;
do {
*(tmp_to+4) = *(tmp_from+4);
++tmp_from;
++tmp_to;
} while (--rem);
chunks = len / 8;
if (chunks)
goto copy_chunks;
goto lessthan8;
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u boot error
Dear VOC, Please do not top post / full quote. Make sure to read http://www.netmeister.org/news/learn2quote.html In message <29023668.p...@talk.nabble.com> you wrote: > > I am using uboot and atmel patch from > http://://www.at91.com/linux4sam/bin/view/Linux4SAM/U-Boot > http://://www.at91.com/linux4sam/bin/view/Linux4SAM/U-Boot . I hope I' not > doing some mistakes. Well, as I told you, the code builds fine in mainline, which is what we support here. Please either use mainline code, or direct your complaints to the responsible developers at www.at91.com, but not here. Thanks. 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 project was large enough and management communication poor enough to prompt many members of the team to see themselves as contestants making brownie points, rather than as builders making programming products. Each suboptimized his piece to meet his targets; few stopped to think about the total effect on the customer. - Fred Brooks, "The Mythical Man Month" ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u boot error
Hi, I am using uboot and atmel patch from http://://www.at91.com/linux4sam/bin/view/Linux4SAM/U-Boot http://://www.at91.com/linux4sam/bin/view/Linux4SAM/U-Boot . I hope I' not doing some mistakes. wd wrote: > > Dear VOC, > > In message <29023152.p...@talk.nabble.com> you wrote: >> >> Hi, >> >> i am trying to build the uboot for at91sam9xeek board.But while building >> the >> uboot by using cross compiler it gives some error from start.s >> file.Please >> let me know how can I correct it. >> >> I tried the same for at91sam9260 board also.I gives the same error. >> >> arm-linux-as -o start.o start.s >> start.s: Assembler messages: >> start.s:387: Error: symbol `irq' is already defined >> start.s:393: Error: symbol `fiq' is already defined >> make[1]: *** [start.o] Error 1 >> make[1]: Leaving directory >> `/root/test/ubootAtmel/uBootNew/u-boot-1.3.4/u-boot-1.3.4/cpu/arm926ejs > > I cannot confirm this. Current code builds just fine: > > MAKEALL_LOGDIR=/work/wd/tmp-arm-LOG \ > BUILD_DIR=/work/wd/tmp-arm \ > ./MAKEALL at91sam9xeek > ... with environment variable in SPI DATAFLASH CS1 > Configuring for at91sam9xeek board... > cpu.c:26:2: warning: #warning Your board is using legacy SoC access. > Please update! >textdata bss dec hex filename > 1707187563 267520 445801 6cd69 /work/wd/tmp-arm/u-boot > > - SUMMARY > Boards compiled: 1 > Boards with warnings or errors: 1 ( at91sam9xeek ) > -- > > > 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 biggest difference between time and space is that you can't reuse > time. - Merrick Furst > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > > http://old.nabble.com/file/p29023668/UBOOTERROR UBOOTERROR -- View this message in context: http://old.nabble.com/u-boot-error-tp29023152p29023668.html Sent from the Uboot - Users mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MPC512x: workaround data corruption for unaligned local bus accesses
Dear Wolfgang, On Tue, 29 Jun 2010 14:47:14 +0200 Wolfgang Denk wrote: ... > > BTW, shouldn't we fix print_buffer() also? do_mem_md() doesn't use > > memcpy() and the issue with corrupted dumps still remains here. > > I'm testing a patch to fix it. Will submit it soon. > > I though about this, too. But then I decided against it. "md" is > intended to to exactly what the user requests - as is, we can easily > demonstrate the issue. I consider this an extremely useful debug > feature. If I command the memory to be read in units of 32 bits I > really mean that. A "fix" ins print_buffer() whould hush up the > symptoms, so the problem would be much harder to detect. Thanks for the explanation, I didn't thought about it. This is indeed a reasonable debug feature. Best regards, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MPC512x: workaround data corruption for unaligned local bus accesses
Wolfgang Denk wrote on 2010/06/29 14:55:44: > > Dear Joakim Tjernlund, > > In message 0045d...@transmode.se> you wrote: > > > > > I could not come up with a better name... What is "align32wrap" > > > supposed to mean? > > > > mpc5200_memcpy_fromio() resp. mpc5200_memcpy_toio()? > > No. It's not only MPC5200, but also MPC521x. It's not I/O in general, > but only I/O from the Local Bus. And even then only unaliged read > access. > > But memcpy_for_unaligned_read_from_local_bus() was too long for me, > and memcpy_furflb() too cryptic ;-) memcpy_align_src()? Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Use memcpy in print_buffer to fix unaligned dumps
Dear Anatolij,
I wrote:
> > Use memcpy in print_buffer() to fix the problem.
>
> NAK. This violates the design of the command.
>
> > for (i = 0; i < linelen; i++) {
> > if (width == 4) {
>
> The "width == 4" part means that we want to access the memory with 32
> bit accesses - nothing else.
Also note that the fix would be incomplete - the same issue happens
with unaligned 16 bit accesses:
=> md.w FC0C 10
fc0c: 7012 ab65 0161 6464 636f 6e73 3d73 6574p..e.addcons=set
fc0c0010: 656e 7620 626f 6f74 6172 6773 2024 7b62env bootargs ${b
=> md.w FC0C0001 10
fc0c0001: 007b 6501 6463 733d 7465.{e...dc..s=..te
fc0c0011: 2062 7461 7320 626f.. b..ta..s ..bo
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
Politics: A strife of interests masquerading as a contest of
principles. The conduct of public affairs for private advantage.
- Ambrose Bierce
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MPC512x: workaround data corruption for unaligned local bus accesses
Dear Joakim Tjernlund, In message you wrote: > > > I could not come up with a better name... What is "align32wrap" > > supposed to mean? > > mpc5200_memcpy_fromio() resp. mpc5200_memcpy_toio()? No. It's not only MPC5200, but also MPC521x. It's not I/O in general, but only I/O from the Local Bus. And even then only unaliged read access. But memcpy_for_unaligned_read_from_local_bus() was too long for me, and memcpy_furflb() too cryptic ;-) Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "There is nothing new under the sun, but there are lots of old things we don't know yet." - Ambrose Bierce ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MPC512x: workaround data corruption for unaligned local bus accesses
> > Dear Detlev Zundel, > > In message you wrote: > > > > Acked-by: Detlev Zundel > > thanks. > > > The only thing I wonder is the filename 'memcpy_mpc5200.c' as the code > > doesn't really have any 5200 specifics in it. What about > > As far as I understand this behaviour is specific to the MPC512x and > MPC5200 processors; I did not notice it on other cores yet. > Unfortunately we do not have a generic name that includes these > processors (5xxx is taken by something else). > > > 'memcpy_align32wrap' or something likew that to express the more general > > nature of the code? > > I could not come up with a better name... What is "align32wrap" > supposed to mean? mpc5200_memcpy_fromio() resp. mpc5200_memcpy_toio()? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Use memcpy in print_buffer to fix unaligned dumps
Dear Anatolij Gustschin,
In message <1277815514-32120-1-git-send-email-ag...@denx.de> you wrote:
> Unaligned 32-/16-bit accesses to local bus on MPC5200
> and MPC512x deliver corrupted data:
Right, and the current version of print_buffer() shopws the real data,
i. e. you can see that such a corruption happens.
> Use memcpy in print_buffer() to fix the problem.
NAK. This violates the design of the command.
> for (i = 0; i < linelen; i++) {
> if (width == 4) {
The "width == 4" part means that we want to access the memory with 32
bit accesses - nothing else.
> +#if defined(CONFIG_MPC5200) || defined(CONFIG_MPC512X)
> + /*
> + * workaround for issues on the MPC5200/MPC512X,
> + * where unaligned 32-/16-bit-accesses to the
> + * local bus will deliver corrupted data. Just
> + * use fixed memcpy here.
> + */
> + memcpy(&uip[i], data, 4);
> +#else
> uip[i] = *(volatile uint32_t *)data;
> +#endif
If we would go this route, we could drop the #ifdef and always
perform a memcpy(), but then we have absolutley no guarantee about
which kind of accesses would be used.
No, please leave as is - this part of U-Boot is working exactly as
intended.
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
Be kind to unkind people - they need it the most.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u boot error
Dear VOC, In message <29023152.p...@talk.nabble.com> you wrote: > > Hi, > > i am trying to build the uboot for at91sam9xeek board.But while building the > uboot by using cross compiler it gives some error from start.s file.Please > let me know how can I correct it. > > I tried the same for at91sam9260 board also.I gives the same error. > > arm-linux-as -o start.o start.s > start.s: Assembler messages: > start.s:387: Error: symbol `irq' is already defined > start.s:393: Error: symbol `fiq' is already defined > make[1]: *** [start.o] Error 1 > make[1]: Leaving directory > `/root/test/ubootAtmel/uBootNew/u-boot-1.3.4/u-boot-1.3.4/cpu/arm926ejs I cannot confirm this. Current code builds just fine: MAKEALL_LOGDIR=/work/wd/tmp-arm-LOG \ BUILD_DIR=/work/wd/tmp-arm \ ./MAKEALL at91sam9xeek ... with environment variable in SPI DATAFLASH CS1 Configuring for at91sam9xeek board... cpu.c:26:2: warning: #warning Your board is using legacy SoC access. Please update! textdata bss dec hex filename 1707187563 267520 445801 6cd69 /work/wd/tmp-arm/u-boot - SUMMARY Boards compiled: 1 Boards with warnings or errors: 1 ( at91sam9xeek ) -- 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 biggest difference between time and space is that you can't reuse time. - Merrick Furst ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MPC512x: workaround data corruption for unaligned local bus accesses
Dear Anatolij, In message <20100629142343.7ecad...@wker> you wrote: > > 'memcpy_align32wrap' isn't really good since the fixed memcpy > also fixes 16-bit accesses, too. we discussed this a bit more internally, and could not find a good name yet, either. Guess I'll stick with the current one until someone comes up with a really good idea. > BTW, shouldn't we fix print_buffer() also? do_mem_md() doesn't use > memcpy() and the issue with corrupted dumps still remains here. > I'm testing a patch to fix it. Will submit it soon. I though about this, too. But then I decided against it. "md" is intended to to exactly what the user requests - as is, we can easily demonstrate the issue. I consider this an extremely useful debug feature. If I command the memory to be read in units of 32 bits I really mean that. A "fix" ins print_buffer() whould hush up the symptoms, so the problem would be much harder to detect. Let's keep this as is, please: if you need a memory dump, you can either align your start address, or use "md.b". Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "How to make a million dollars: First, get a million dollars." - Steve Martin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Use memcpy in print_buffer to fix unaligned dumps
Unaligned 32-/16-bit accesses to local bus on MPC5200
and MPC512x deliver corrupted data:
=> md F000 10
f000: 27051956 552d426f 6f742032 3031302e'..VU-Boot 2010.
f010: 30362d72 63332d30 38303336 2d67666506-rc3-08036-gfe
f020: 38663238 362d6469 72747920 284a756e8f286-dirty (Jun
f030: 20323920 32303130 202d2031 343a3235 29 2010 - 14:25
=> md F001 10
f001: 5655 6f6f 3230 2e30..VU..oo..20...0
f011: 7263 3038 362d 6538..rc..08..6-..e8
f021: 3836 6972 2028 6e20..86..ir.. (..n
f031: 2032 3020 3134 353a.. 2..0 ..14..5:
=> md.w F001 20
f001: 5655 6f6f 3230 2e30..VU..oo..20...0
f011: 7263 3038 362d 6538..rc..08..6-..e8
f021: 3836 6972 2028 6e20..86..ir.. (..n
f031: 2032 3020 3134 353a.. 2..0 ..14..5:
Use memcpy in print_buffer() to fix the problem.
Signed-off-by: Anatolij Gustschin
Cc: Wolfgang Denk
Cc: Detlev Zundel
---
lib/display_options.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/lib/display_options.c b/lib/display_options.c
index a711425..c0b89b2 100644
--- a/lib/display_options.c
+++ b/lib/display_options.c
@@ -122,10 +122,24 @@ int print_buffer (ulong addr, void* data, uint width,
uint count, uint linelen)
/* Copy from memory into linebuf and print hex values */
for (i = 0; i < linelen; i++) {
if (width == 4) {
+#if defined(CONFIG_MPC5200) || defined(CONFIG_MPC512X)
+ /*
+* workaround for issues on the MPC5200/MPC512X,
+* where unaligned 32-/16-bit-accesses to the
+* local bus will deliver corrupted data. Just
+* use fixed memcpy here.
+*/
+ memcpy(&uip[i], data, 4);
+#else
uip[i] = *(volatile uint32_t *)data;
+#endif
printf(" %08x", uip[i]);
} else if (width == 2) {
+#if defined(CONFIG_MPC5200) || defined(CONFIG_MPC512X)
+ memcpy(&usp[i], data, 2);
+#else
usp[i] = *(volatile uint16_t *)data;
+#endif
printf(" %04x", usp[i]);
} else {
ucp[i] = *(volatile uint8_t *)data;
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MPC512x: workaround data corruption for unaligned local bus accesses
Hi Wolfgang,
>> The only thing I wonder is the filename 'memcpy_mpc5200.c' as the code
>> doesn't really have any 5200 specifics in it. What about
>
> As far as I understand this behaviour is specific to the MPC512x and
> MPC5200 processors; I did not notice it on other cores yet.
> Unfortunately we do not have a generic name that includes these
> processors (5xxx is taken by something else).
I believe that other architectures may also suffer from such unaligned
byte copies, but maybe in those cases 'memcpy' already takes car of
that, I don't know. The point I wanted to make is that the file in
question has no powerpc specific code in it at all.
>> 'memcpy_align32wrap' or something likew that to express the more general
>> nature of the code?
>
> I could not come up with a better name... What is "align32wrap"
> supposed to mean?
It was meant to mean somehow to express the fact that for some condition
the original memcpy was called and for some conditions not - hence
"wrap". The condition which was passed on to the original memcpy is
connected to correct 32 bit alignment, hence the proposal.
>> If one thinks further along this line, why not move the wrapper to lib/?
>
> Please re-check what my patch does - exactly that:
>
>> arch/powerpc/{cpu/mpc5xxx => lib}/memcpy_mpc5200.c |0
Actually I was aiming for "lib" outside of any architecure for the
reason noted above.
But as I said, this is only place for improvement, I surely will not nak
the patch ;)
Cheers
Detlev
--
System going down at 1:45 this afternoon for disk crashing.
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] u boot error
Hi, i am trying to build the uboot for at91sam9xeek board.But while building the uboot by using cross compiler it gives some error from start.s file.Please let me know how can I correct it. I tried the same for at91sam9260 board also.I gives the same error. arm-linux-as -o start.o start.s start.s: Assembler messages: start.s:387: Error: symbol `irq' is already defined start.s:393: Error: symbol `fiq' is already defined make[1]: *** [start.o] Error 1 make[1]: Leaving directory `/root/test/ubootAtmel/uBootNew/u-boot-1.3.4/u-boot-1.3.4/cpu/arm926ejs -- View this message in context: http://old.nabble.com/u-boot-error-tp29023152p29023152.html Sent from the Uboot - Users mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MPC512x: workaround data corruption for unaligned local bus accesses
Hi Detlev, Hi Wolfgang,
On Tue, 29 Jun 2010 13:49:11 +0200
Detlev Zundel wrote:
> > Commit 460c2ce3 "MPC5200: workaround data corruption for unaligned
> > local bus accesses" fixed the problem for MPC5200 only, but MPC512x is
> > affected as well, so apply the same fix here, too.
> >
> > Signed-off-by: Wolfgang Denk
> > Cc: Detlev Zundel
> > Cc: Anatolij Gustschin
> > ---
> > arch/powerpc/cpu/mpc5xxx/Makefile |5 -
> > arch/powerpc/lib/Makefile | 16
> > arch/powerpc/{cpu/mpc5xxx => lib}/memcpy_mpc5200.c |0
> > 3 files changed, 12 insertions(+), 9 deletions(-)
> > rename arch/powerpc/{cpu/mpc5xxx => lib}/memcpy_mpc5200.c (100%)
>
> Acked-by: Detlev Zundel
>
> The only thing I wonder is the filename 'memcpy_mpc5200.c' as the code
> doesn't really have any 5200 specifics in it. What about
> 'memcpy_align32wrap' or something likew that to express the more general
> nature of the code?
'memcpy_align32wrap' isn't really good since the fixed memcpy
also fixes 16-bit accesses, too.
BTW, shouldn't we fix print_buffer() also? do_mem_md() doesn't use
memcpy() and the issue with corrupted dumps still remains here.
I'm testing a patch to fix it. Will submit it soon.
Best regards,
Anatolij
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MPC512x: workaround data corruption for unaligned local bus accesses
Dear Detlev Zundel,
In message you wrote:
>
> Acked-by: Detlev Zundel
thanks.
> The only thing I wonder is the filename 'memcpy_mpc5200.c' as the code
> doesn't really have any 5200 specifics in it. What about
As far as I understand this behaviour is specific to the MPC512x and
MPC5200 processors; I did not notice it on other cores yet.
Unfortunately we do not have a generic name that includes these
processors (5xxx is taken by something else).
> 'memcpy_align32wrap' or something likew that to express the more general
> nature of the code?
I could not come up with a better name... What is "align32wrap"
supposed to mean?
> If one thinks further along this line, why not move the wrapper to lib/?
Please re-check what my patch does - exactly that:
> arch/powerpc/{cpu/mpc5xxx => lib}/memcpy_mpc5200.c |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
"The value of marriage is not that adults produce children, but that
children produce adults."- Peter De Vries
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MPC512x: workaround data corruption for unaligned local bus accesses
Hi Wolfgang,
> Commit 460c2ce3 "MPC5200: workaround data corruption for unaligned
> local bus accesses" fixed the problem for MPC5200 only, but MPC512x is
> affected as well, so apply the same fix here, too.
>
> Signed-off-by: Wolfgang Denk
> Cc: Detlev Zundel
> Cc: Anatolij Gustschin
> ---
> arch/powerpc/cpu/mpc5xxx/Makefile |5 -
> arch/powerpc/lib/Makefile | 16
> arch/powerpc/{cpu/mpc5xxx => lib}/memcpy_mpc5200.c |0
> 3 files changed, 12 insertions(+), 9 deletions(-)
> rename arch/powerpc/{cpu/mpc5xxx => lib}/memcpy_mpc5200.c (100%)
Acked-by: Detlev Zundel
The only thing I wonder is the filename 'memcpy_mpc5200.c' as the code
doesn't really have any 5200 specifics in it. What about
'memcpy_align32wrap' or something likew that to express the more general
nature of the code?
If one thinks further along this line, why not move the wrapper to lib/?
Cheers
Detlev
--
LISP is the most powerful programming language, and if you want an inter-
preter, LISP is the best. None of the other languages come anywhere near
LISP in their power. The most exciting things about LISP are read, eval,
and print. If you look at other languages, they have no equivalent for
any of those. -- Richard Stallman
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem in accessing Contex ram
On Tuesday 22 June 2010 07:29:33 Ronny D wrote: > I am using ppc440 based board. > While running the u-boot form DDR i am not able to access contex ram. > eg. > md 0xc000 > > u-boot generates machine check exception. > > Here my doubt is can we access contex ram from u-boot running from DDR? I've said this a few times already: We have very little information about your custom PPC440 SoC. So its hard to really comment on your problems. Perhaps if you would send some patches to push this SoC support into mainline it would be easier for us to help you with your problems. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] boards.cfg: add missing definitions for am3517_evm and s5p_goni
Signed-off-by: Wolfgang Denk --- boards.cfg |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/boards.cfg b/boards.cfg index f012d6c..912224b 100644 --- a/boards.cfg +++ b/boards.cfg @@ -261,7 +261,9 @@ omap3_zoom2 arm arm_cortexa8zoom2 logicpd omap3 omap3_beagle arm arm_cortexa8beagle ti omap3 omap3_evm arm arm_cortexa8evm ti omap3 omap3_sdp3430 arm arm_cortexa8sdp3430 ti omap3 +am3517_evm arm arm_cortexa8am3517evm logicpd omap3 devkit8000 arm arm_cortexa8devkit8000 timll omap3 +s5p_goni arm arm_cortexa8gonisamsung s5pc1xx smdkc100 arm arm_cortexa8smdkc100samsung s5pc1xx ixdpg425 arm ixp lpd7a400 arm lh7a40x lpd7a40x -- 1.7.0.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Make sure that argv[] argument pointers are not modified - Part 2
Fix compile problems cause by this commit. Signed-off-by: Wolfgang Denk --- Sorry, by accident these changes were not checked in yet when I submitted the patch. Given the size of the patch and the local impact of this fix I post this as an incremental patch. If nobody complains I will squash this into the first part when committing. board/trab/trab_fkt.c | 24 1 files changed, 12 insertions(+), 12 deletions(-) diff --git a/board/trab/trab_fkt.c b/board/trab/trab_fkt.c index 6faa9b1..268162e 100644 --- a/board/trab/trab_fkt.c +++ b/board/trab/trab_fkt.c @@ -115,21 +115,21 @@ int do_rotary_switch (void); int do_pressure (void); int do_v_bat (void); int do_vfd_id (void); -int do_buzzer (char **); -int do_led (char **); -int do_full_bridge (char **); -int do_dac (char **); +int do_buzzer (char * const *); +int do_led (char * const *); +int do_full_bridge (char * const *); +int do_dac (char * const *); int do_motor_contact (void); -int do_motor (char **); -int do_pwm (char **); -int do_thermo (char **); -int do_touch (char **); -int do_rs485 (char **); -int do_serial_number (char **); +int do_motor (char * const *); +int do_pwm (char * const *); +int do_thermo (char * const *); +int do_touch (char * const *); +int do_rs485 (char * const *); +int do_serial_number (char * const *); int do_crc16 (void); int do_power_switch (void); -int do_gain (char **); -int do_eeprom (char **); +int do_gain (char * const *); +int do_eeprom (char * const *); /* helper functions */ static void adc_init (void); -- 1.7.0.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Supporting two boards which are almost similar
Hi Sudhakar,
> On Fri, Jun 25, 2010 at 16:40:19, Sudhakar Rajashekhara wrote:
>> Hi,
>>
>> Spectrum digital has two versions of DM6467 EVM, DM6467 and DM6467T.
>> Though there are some video related differences between these two boards,
>> from U-Boot perspective the only difference the developer need to worry
>> is the different oscillator frequency. DM6467 has 27MHz crystal but
>> DM6467T has 33MHz crystal. Both these EVMs are registered as two different
>> boards in mach-types.h. Existing U-Boot has support DM6467 EVM which has
>> 27MHz crystal. How should I go about adding support for DM6467T EVM which
>> has 33MHz crystal? Do I need to add a new configuration file for this or
>> can I make use of the existing configuration file in any way?
>>
>> One method I was aware of was, using some scripting from the top level
>> Makefile but I believe this is not recommended.
>>
>
> Any other method of achieving this?
Actually I'm just in the process of answering your question.
My immediate response would have been "use -t for mkconfig" but this
does not (yet) work for boards.cfg versions. So I'm just in the process
of testing a mkconfig extension to allow for similar handling of
"BOARD_OPTION1_OPTION2" configurations which will be split into
'CONFIG_MK_{BOARD,OPTION1,OPTION2}' defines.
When we have this, we can use a common config file and use #ifdefs for
these CONFIG_MK defines.
Stay tuned
Detlev
--
A foolish consistency is the hobgoblin of little minds.
-- Ralph Waldo Emerson
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Supporting two boards which are almost similar
Hi, On Fri, Jun 25, 2010 at 16:40:19, Sudhakar Rajashekhara wrote: > Hi, > > Spectrum digital has two versions of DM6467 EVM, DM6467 and DM6467T. > Though there are some video related differences between these two boards, > from U-Boot perspective the only difference the developer need to worry > is the different oscillator frequency. DM6467 has 27MHz crystal but > DM6467T has 33MHz crystal. Both these EVMs are registered as two different > boards in mach-types.h. Existing U-Boot has support DM6467 EVM which has > 27MHz crystal. How should I go about adding support for DM6467T EVM which > has 33MHz crystal? Do I need to add a new configuration file for this or > can I make use of the existing configuration file in any way? > > One method I was aware of was, using some scripting from the top level > Makefile but I believe this is not recommended. > Any other method of achieving this? Regards, Sudhakar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/6 v2] exports.c: fix warning: 'dummy' defined but not used
Signed-off-by: Wolfgang Denk
---
v2: fix compile problem for some boards.
common/exports.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/common/exports.c b/common/exports.c
index 60bba75..36321e3 100644
--- a/common/exports.c
+++ b/common/exports.c
@@ -3,9 +3,14 @@
DECLARE_GLOBAL_DATA_PTR;
+#if (!defined(CONFIG_I386) && !defined(CONFIG_PPC)) || \
+!defined(CONFIG_CMD_I2C) || \
+!defined(CONFIG_HAS_UID) || \
+!defined(CONFIG_CMD_SPI)
static void dummy(void)
{
}
+#endif
unsigned long get_version(void)
{
--
1.7.0.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ppc4xx: Add T3COPR board support (PPC460GT based)
Hi Wolfgang,
On Tuesday 29 June 2010 09:52:00 Wolfgang Denk wrote:
> > This patch adds support for the T3CORP board, based on the
> > AppliedMicro (AMCC) PPC460GT.
>
> General question: should we rename "amcc" into "apm" ?
Personally, I don't like the idea to change all existing references from AMCC
to APM. But you are right. Its better to use AppliedMicro or APM from now on.
I'll switch to APM in the next patch version.
> ..
>
> > +int board_early_init_r(void)
> > +{
>
> ..
>
> > + /* Add TLB entry for 0xfn00. -> 0x4.cn00. */
> > + program_tlb(CONFIG_SYS_FLASH_BASE_PHYS, CONFIG_SYS_FLASH_BASE,
> > + CONFIG_SYS_FLASH_SIZE, TLB_WORD2_I_ENABLE);
> > +
> > + /*
> > +* Now accessing of the whole 64Mbytes of NOR FLASH at virtual address
> > +* 0xfc00. is possible
> > +*/
>
> What about the configuration with 128 MiB NOR flash?
Oops. This is a copy-n-paste error. There is no 128 MiB configuration for the
T3CORP board. I'll fix the comment and the code in the next patch version.
> Would it not be
> more flexible to use something like
>
> program_tlb(CONFIG_SYS_FLASH_END_PHYS-flash_info[0].size,
> -flash_info[0].size,
> flash_info[0].size, TLB_WORD2_I_ENABLE);
>
> with
> CONFIG_SYS_FLASH_END_PHYS_H = 0x4
> and CONFIG_SYS_FLASH_END_PHYS_L = 0xD000
>
> ?
Not necessary with a fixed 64MiB board.
> BTW: Please use "flash" (globally) instead of FLASH - "flash" is not
> an abbreviation.
OK.
> > +int board_pcie_last(void)
> > +{
> > + /*
> > +* Only PCIe0 for now, PCIe1 hangs on this boards
>
> "on this board" or "on these boards"
OK. Thanks for the review.
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MPC512x: workaround data corruption for unaligned local bus accesses
Commit 460c2ce3 "MPC5200: workaround data corruption for unaligned
local bus accesses" fixed the problem for MPC5200 only, but MPC512x is
affected as well, so apply the same fix here, too.
Signed-off-by: Wolfgang Denk
Cc: Detlev Zundel
Cc: Anatolij Gustschin
---
arch/powerpc/cpu/mpc5xxx/Makefile |5 -
arch/powerpc/lib/Makefile | 16
arch/powerpc/{cpu/mpc5xxx => lib}/memcpy_mpc5200.c |0
3 files changed, 12 insertions(+), 9 deletions(-)
rename arch/powerpc/{cpu/mpc5xxx => lib}/memcpy_mpc5200.c (100%)
diff --git a/arch/powerpc/cpu/mpc5xxx/Makefile
b/arch/powerpc/cpu/mpc5xxx/Makefile
index 4ab2b7b..0ee0611 100644
--- a/arch/powerpc/cpu/mpc5xxx/Makefile
+++ b/arch/powerpc/cpu/mpc5xxx/Makefile
@@ -30,11 +30,6 @@ SOBJS= io.o firmware_sc_task_bestcomm.impl.o
COBJS = i2c.o traps.o cpu.o cpu_init.o ide.o interrupts.o \
loadtask.o pci_mpc5200.o serial.o speed.o usb_ohci.o usb.o
-# Workaround for local bus unaligned access problem on MPC5200
-#ifdef CONFIG_MPC5200
-COBJS += memcpy_mpc5200.o
-#endif
-
SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS))
START := $(addprefix $(obj),$(START))
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index bf23790..2065b6d 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -40,14 +40,22 @@ COBJS-y += interrupts.o
COBJS-$(CONFIG_CMD_KGDB) += kgdb.o
COBJS-y+= time.o
-SRCS := $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
-OBJS := $(addprefix $(obj),$(SOBJS-y) $(COBJS-y))
-
-# Workaround for local bus unaligned access problem on MPC5200
+# Workaround for local bus unaligned access problems
+# on MPC512x and MPC5200
+ifdef CONFIG_MPC512X
+$(obj)ppcstring.o: AFLAGS += -Dmemcpy=__memcpy
+COBJS-y += memcpy_mpc5200.o
+endif
ifdef CONFIG_MPC5200
$(obj)ppcstring.o: AFLAGS += -Dmemcpy=__memcpy
+COBJS-y += memcpy_mpc5200.o
endif
+COBJS += $(sort $(COBJS-y))
+
+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 \
diff --git a/arch/powerpc/cpu/mpc5xxx/memcpy_mpc5200.c
b/arch/powerpc/lib/memcpy_mpc5200.c
similarity index 100%
rename from arch/powerpc/cpu/mpc5xxx/memcpy_mpc5200.c
rename to arch/powerpc/lib/memcpy_mpc5200.c
--
1.7.0.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] IRQ in realmode and sleep()
Hello, the data cache is disabled on the CPCI750 board for the SDRAM by the DBAT entry for the SDRAM, but the data cache is enabled for most 74xx_7xx boards in cpu/74xx_7xx/start.S together with the translation. The decrementer irq is executed in real mode with translation disabled. Now in the irq routine, the processor writes the data into the cache, and the sleep() reads directly from RAM, and do not see the timer running. A good solution would be to have translation on for the irq's too, but a simple solution is to put an '#if !(defined CPCI750)' around the routine, that enables the l1 data cache. I am not shure, if the problem with the sleep() (and the missing timeouts in the networks stack) hits other boards too. Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Link problem with eTSEC2 on P2020RDB
Hi Peter, On 6/26/2010 4:19 PM, Peter Tyser wrote: > Hi Felix, > > In any case, our testing and the Freescale FAE's input showed that > in-band auto-negotiation on the SGMII interface didn't work, thus I > submitted the change you referenced. If my memory is correct, > empirically it looked like the MPC8572 did support 1000 base-X > auto-negotiation, but not SGMII auto-negotiation. Can you validate > you're using SGMII and not 1000 base-X to connect the P2020 to the > VSC8211 PHY? A simple way to test this should be to connect the VSC8211 > to a 100 mpbs switch - this should work fine via SGMII but not 1000 > base-X (assuming you're using a copper interface). I'm definitely using SGMII with eTSEC2. This is documented in board user manual. Also, eTSEC2 works when connected to 100 mbps switch. >> I'm not familiar with how SGMII is configured on this controller, but >> it appears that Peter's patch turned of Autonegotiation. Why this >> would make a PHY work and a switch not work is curious... Maybe we >> should have a CONFIG option for SGMII parameters. Settings could >> default to the ones Peter set (since he submitted it in November and >> problems are surfacing now), but could be overriden. Does that sound >> reasonable? Something like: >> >> >> #ifndef CONFIG TSEC_TBICR_SETTINGS >> #define TBICR_SETTINGS ( \ >> TBICR_PHY_RESET \ >> | TBICR_FULL_DUPLEX \ >> | TBICR_SPEED1_SET \ >> ) >> #else >> #define TBICR_SETTINGS CONFIG_TSEC_TBICR_SETTINGS >> #endif >> Thanks. > This solution is fine by me. I'd be curious if anyone at Freescale has > a definitive answer about SGMII and auto-negotiation. I'm happy to try > any patch on Monday I've posted a patch, see http://lists.denx.de/pipermail/u-boot/2010-June/073208.html Can you please test it ? Thanks. Felix. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ppc4xx: Add T3COPR board support (PPC460GT based)
Dear Stefan Roese,
In message <1277796281-19728-1-git-send-email...@denx.de> you wrote:
> This patch adds support for the T3CORP board, based on the
> AppliedMicro (AMCC) PPC460GT.
General question: should we rename "amcc" into "apm" ?
...
> +int board_early_init_r(void)
> +{
...
> + /* Add TLB entry for 0xfn00. -> 0x4.cn00. */
> + program_tlb(CONFIG_SYS_FLASH_BASE_PHYS, CONFIG_SYS_FLASH_BASE,
> + CONFIG_SYS_FLASH_SIZE, TLB_WORD2_I_ENABLE);
> +
> + /*
> + * Now accessing of the whole 64Mbytes of NOR FLASH at virtual address
> + * 0xfc00. is possible
> + */
What about the configuration with 128 MiB NOR flash? Would it not be
more flexible to use something like
program_tlb(CONFIG_SYS_FLASH_END_PHYS-flash_info[0].size,
-flash_info[0].size,
flash_info[0].size, TLB_WORD2_I_ENABLE);
with
CONFIG_SYS_FLASH_END_PHYS_H = 0x4
and CONFIG_SYS_FLASH_END_PHYS_L = 0xD000
?
BTW: Please use "flash" (globally) instead of FLASH - "flash" is not
an abbreviation.
> +int board_pcie_last(void)
> +{
> + /*
> + * Only PCIe0 for now, PCIe1 hangs on this boards
"on this board" or "on these boards"
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Lots of people drink from the wrong bottle sometimes.
-- Edith Keeler, "The City on the Edge of Forever",
stardate unknown
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MXC: Performance issue/glitch with reading/writing files from SD card
alfred steele wrote: > Hi, > > Looks like there is a huge performance issue with the sdhc > hardware/software driver on the mx31 Actually I do not find any MX31 board in the mainline supporting MMC. However, drivers/mmmc/mxcmmc.c is suitable for both MX2 and MX3 processors. > Earlier on i had adapated the freescale mx "sdhc driver" and ported it > to the mx31 platform for U-boot v1.0. I have modified the driver to > put the host as well as the card in 4 bit mode in the initialization > sequence. This is your code and I am afraid we cannot help you. And u-boot 1.0 belongs to prehistory. I can only suggest you to update to the actual u-boot (2010.06-rc3) and sets your target to use the mxcmmc driver, and reports us if you find problems. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] ppc4xx: Add T3COPR board support (PPC460GT based)
This patch adds support for the T3CORP board, based on the
AppliedMicro (AMCC) PPC460GT.
Signed-off-by: Stefan Roese
---
v2: - Fixed spelling: fibre -> fiber
- Rebased on next, no changes to toplevel Makefile needed anymore
MAINTAINERS|1 +
MAKEALL|1 +
board/t3corp/Makefile | 53 +
board/t3corp/chip_config.c | 59 +
board/t3corp/config.mk | 39
board/t3corp/init.S| 99
board/t3corp/t3corp.c | 198
boards.cfg |1 +
include/configs/t3corp.h | 544
9 files changed, 995 insertions(+), 0 deletions(-)
create mode 100644 board/t3corp/Makefile
create mode 100644 board/t3corp/chip_config.c
create mode 100644 board/t3corp/config.mk
create mode 100644 board/t3corp/init.S
create mode 100644 board/t3corp/t3corp.c
create mode 100644 include/configs/t3corp.h
diff --git a/MAINTAINERS b/MAINTAINERS
index d7aec98..9485070 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -392,6 +392,7 @@ Stefan Roese
rainier PPC440GRx
sequoia PPC440EPx
sycamorePPC405GPr
+ t3corp PPC460GT
taishan PPC440GX
walnut PPC405GP
yellowstone PPC440GR
diff --git a/MAKEALL b/MAKEALL
index d6d5f5b..51de8fc 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -262,6 +262,7 @@ LIST_4xx=" \
sc3 \
sequoia \
sequoia_nand\
+ t3corp \
taihu \
taishan \
v5fx30teval \
diff --git a/board/t3corp/Makefile b/board/t3corp/Makefile
new file mode 100644
index 000..e2bb546
--- /dev/null
+++ b/board/t3corp/Makefile
@@ -0,0 +1,53 @@
+#
+# (C) Copyright 2010
+# Stefan Roese, DENX Software Engineering, s...@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-y:= $(BOARD).o
+COBJS-$(CONFIG_CMD_CHIP_CONFIG) += chip_config.o
+SOBJS := init.o
+
+COBJS := $(COBJS-y)
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(OBJS) $(SOBJS)
+ $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS)
+
+clean:
+ rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/t3corp/chip_config.c b/board/t3corp/chip_config.c
new file mode 100644
index 000..c00bf16
--- /dev/null
+++ b/board/t3corp/chip_config.c
@@ -0,0 +1,59 @@
+/*
+ * (C) Copyright 2010
+ * Stefan Roese, DENX Software Engineering, s...@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
+#include
+
+struct ppc4xx_config ppc4xx_config_val[] = {
+ {
+ "600", "CPU: 600 PLB: 200 OPB: 100 EBC: 100",
+ {
+ 0x86, 0x80, 0xce, 0x1f, 0x79, 0x80, 0x00, 0xa0,
+ 0x40, 0x08, 0x23, 0x50, 0x0d, 0x05, 0x00, 0x00
+ }
+ },
+ {
+ "800", "CPU: 800 PLB: 200 OPB: 100 EBC: 100",
+ {
+ 0x86, 0x80, 0xba, 0x14, 0x99, 0x80, 0x00,
[U-Boot] [PATCH v2] net: Add option to disable fiber on M88E1111 PHY for PPC4xx
By defining CONFIG_M88E_DISABLE_FIBER boards can configure the
M88E PYH to disable fiber. This is needed for an upcoming PPC460GT
based board, which has fiber/copper auto-selection enabled by default.
This doesn't seem to work. So we disable fiber in the PHY register.
Signed-off-by: Stefan Roese
Cc: Ben Warren
---
v2: - Fixed spelling: fibre -> fiber
drivers/net/4xx_enet.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/4xx_enet.c b/drivers/net/4xx_enet.c
index 2fac641..144b851 100644
--- a/drivers/net/4xx_enet.c
+++ b/drivers/net/4xx_enet.c
@@ -1095,6 +1095,11 @@ static int ppc_4xx_eth_init (struct eth_device *dev,
bd_t * bis)
miiphy_write (dev->name, reg, 0x18, 0x4101);
miiphy_write (dev->name, reg, 0x09, 0x0e00);
miiphy_write (dev->name, reg, 0x04, 0x01e1);
+#if defined(CONFIG_M88E_DISABLE_FIBER)
+ miiphy_read(dev->name, reg, 0x1b, ®_short);
+ reg_short |= 0x8000;
+ miiphy_write(dev->name, reg, 0x1b, reg_short);
+#endif
#endif
#if defined(CONFIG_M88E1112_PHY)
if (bis->bi_phymode[devnum] == BI_PHYMODE_SGMII) {
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
