Re: [U-Boot] [PATCH] Refresh LZMA-lib to v4.65
thanks Dear Luigi 'Comio' Mantellini, In message 1248165949-5845-2-git-send-email-luigi.mantellini...@gmail.com you wrote: --===0963718385== From: Luigi 'Comio' Mantellini luigi.mantell...@idf-hit.com Signed-off-by: Luigi 'Comio' Mantellini luigi.mantell...@idf-hit.com --- common/cmd_bootm.c |5 +- include/configs/qemu-mips.h|2 + include/lzma/LzmaDec.h | 31 + include/lzma/LzmaDecode.h | 31 - include/lzma/LzmaTools.h |2 +- include/lzma/LzmaTypes.h | 15 +- lib_generic/lzma/LGPL.txt | 502 -- lib_generic/lzma/LzmaDec.c | 1007 + lib_generic/lzma/LzmaDec.h | 223 +++ lib_generic/lzma/LzmaDecode.c | 584 - lib_generic/lzma/LzmaDecode.h | 113 lib_generic/lzma/LzmaTools.c | 165 +++--- lib_generic/lzma/LzmaTools.h |4 +- lib_generic/lzma/LzmaTypes.h | 45 -- lib_generic/lzma/Makefile |4 +- lib_generic/lzma/README.txt|8 +- lib_generic/lzma/Types.h | 208 ++ lib_generic/lzma/history.txt | 434 +++-- lib_generic/lzma/import_lzmasdk.sh |8 +- lib_generic/lzma/license.txt |3 + lib_generic/lzma/lzma.txt | 1257 +--- 21 files changed, 2404 insertions(+), 2247 deletions(-) create mode 100644 include/lzma/LzmaDec.h delete mode 100644 include/lzma/LzmaDecode.h delete mode 100644 lib_generic/lzma/LGPL.txt create mode 100644 lib_generic/lzma/LzmaDec.c create mode 100644 lib_generic/lzma/LzmaDec.h delete mode 100644 lib_generic/lzma/LzmaDecode.c delete mode 100644 lib_generic/lzma/LzmaDecode.h delete mode 100644 lib_generic/lzma/LzmaTypes.h create mode 100644 lib_generic/lzma/Types.h create mode 100644 lib_generic/lzma/license.txt Applying: Refresh LZMA-lib to v4.65 /home/wd/git/u-boot/work/.git/rebase-apply/patch:854: trailing whitespace. /home/wd/git/u-boot/work/.git/rebase-apply/patch:1038: trailing whitespace. /home/wd/git/u-boot/work/.git/rebase-apply/patch:1437: trailing whitespace. /home/wd/git/u-boot/work/.git/rebase-apply/patch:1483: trailing whitespace. /home/wd/git/u-boot/work/.git/rebase-apply/patch:1614: trailing whitespace. warning: squelched 100 whitespace errors warning: 105 lines applied after fixing whitespace errors. Applied. 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 miracle: an extremely outstanding or unusual event, thing, or accomplishment.- Webster's Dictionary ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5] ppc4xx: Add 405EP based PMC405DE board
Dear Stefan Roese, In message 200907221147.25539...@denx.de you wrote: Indentation is not done by TABs, but by TABs + spaces, and this is wrong. Why should this be wrong? This alignment looks better IMHO. Please allow the developers a little bit of freedom. Documentation/CodingStyle: Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3. 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 wish Captain Vimes were here. He wouldn't have known what to do either, but he's got a much better vocabulary to be baffled in. - Terry Pratchett, _Guards! Guards!_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] tools: mkimage: kwbimage list command support
Dear Prafulla Wadaskar,
In message 73173d32e9439e4abb5151606c3e19e202ddf27...@sc-vexch1.marvell.com
you wrote:
When exporting this function, then please add prototype to
header file.
I have followed function crc32, I will do it.
Ah, I see.
Shall I do it for crc32 and other functions too? I should not disturb them?
If you would be so kind and clean up these other function declarations
as well, that would be much appreciated. Thanks in advance.
...
+ if (!(kwbimage_check_header ((struct kwb_header
*)ptr))) {
+ kwbimage_print_contents ((struct
kwb_header *)ptr);
+ exit (EXIT_SUCCESS);
I think you should add error checking here. For example, when
the code detects a corruption of the image (checksum error or
the like), it should return an error code here, so you can
use mkimage -l to actually verify the consistency of an
image (in automated scripts).
Currently mkimage checks first kwbimage header followed by ftd/fit header c
hecks
In that case returning an error code will not be useful
I don't understand what you mean here. Any corruption of an image
should be detected and signalled to the caller by a non-zero return
code of the mkimage command.
On the other hand,
we should detect filename extension (img/kwb) from input file and then only
do relevant image checks.
NO!! Never do anything like that. File names don't matter at all.
We're not Windows, where just naming your virus code as document.txt
will make it look harmless. Only the content matters - if the file is
called image.foo or just foo or sjjsdhashd does not matter at
all.
Filenames can be altered so I think current implementation is okay.
What do you think?
Filenames must not play any role.
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
Sometimes a feeling is all we humans have to go on.
-- Kirk, A Taste of Armageddon, stardate 3193.9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] P2020RDB Platform Support Added
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wolfgang Denk
Sent: Tuesday, July 21, 2009 6:56 PM
To: Aggrwal Poonam-B10812
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH 2/2] P2020RDB Platform Support Added
Dear Poonam Aggrwal,
In message
1248173285-30560-1-git-send-email-poonam.aggr...@freescale.co
m you wrote:
The code base is generic to add more P1_P2 RDB platforms
support as and when required.
The folder and file names are such that they can cater to
future SOCs of P1/P2 family.
Tested the following on P2020RDB:
1. eTSECs(1/2/3)
2. DDR, NAND, NOR, I2C etc
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
---
MAINTAINERS |4 +
MAKEALL |1 +
Makefile |8 +
board/freescale/p1_p2_rdb/Makefile| 53 +++
board/freescale/p1_p2_rdb/config.mk | 32 ++
board/freescale/p1_p2_rdb/ddr.c | 188 ++
board/freescale/p1_p2_rdb/law.c | 37 ++
board/freescale/p1_p2_rdb/p1_p2_rdb.c | 234
board/freescale/p1_p2_rdb/pci.c | 174 +
board/freescale/p1_p2_rdb/tlb.c | 79 +
board/freescale/p1_p2_rdb/u-boot.lds | 143
doc/README.p2020rdb | 143
include/configs/P1_P2_RDB.h | 625
+
13 files changed, 1721 insertions(+), 0 deletions(-) create mode
100644 board/freescale/p1_p2_rdb/Makefile
create mode 100644 board/freescale/p1_p2_rdb/config.mk
create mode 100644 board/freescale/p1_p2_rdb/ddr.c create mode
100644 board/freescale/p1_p2_rdb/law.c create mode 100644
board/freescale/p1_p2_rdb/p1_p2_rdb.c
create mode 100644 board/freescale/p1_p2_rdb/pci.c create mode
100644 board/freescale/p1_p2_rdb/tlb.c create mode 100644
board/freescale/p1_p2_rdb/u-boot.lds
create mode 100644 doc/README.p2020rdb create mode 100644
include/configs/P1_P2_RDB.h
diff --git a/MAINTAINERS b/MAINTAINERS index 705bac5..814912c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -436,6 +436,10 @@ Peter Tyser pty...@xes-inc.com
XPEDITE5200 MPC8548
XPEDITE5370 MPC8572
+Poonam Aggrwal poonam.aggr...@freescale.com
+
+ P2020RDBP2020
+
David Updegraff d...@cray.com
Please keep list sorted by names.
diff --git a/Makefile b/Makefile
index 2a06440..dc3e987 100644
--- a/Makefile
+++ b/Makefile
@@ -1,4 +1,5 @@
#
+# Copyright (C) 2009 Freescale Semiconductor, Inc. All
rights reserved.
Please note that
1) I don't think that you have any real right to add a (C) note to
this file for just adding anothe rboard entry.
2) Your copyright note, especially the phrase All rights reserved.
is incompatible with the GPL.
We cannot accept any such code. Plase make sure never to
use that in
any submissions to this project, as we can then only relect your
code.
I will rework the copyright stuff.
diff --git a/board/freescale/p1_p2_rdb/ddr.c
b/board/freescale/p1_p2_rdb/ddr.c new file mode 100644 index
000..2b880ab
--- /dev/null
+++ b/board/freescale/p1_p2_rdb/ddr.c
@@ -0,0 +1,188 @@
+/*
+ * Copyright (C) 2009 Freescale Semiconductor, Inc. All
rights reserved.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General
Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include asm/mmu.h
+#include asm/immap_85xx.h
+#include asm/fsl_ddr_sdram.h
+#include asm/io.h
+#include asm/fsl_law.h
+
+
+#if defined(CONFIG_DDR_ECC)
+!defined(CONFIG_ECC_INIT_VIA_DDRCONTROLLER)
+extern void ddr_enable_ecc(unsigned int dram_size); #endif
+
+phys_size_t fixed_sdram(void);
+
+unsigned long get_board_ddr_size(ulong dummy) {
+ return 1024;
+}
Please use auto-detection of the memory size (using get_ram_size()).
Thanks for the suggestion, I was not aware of this function.
+ u32 val, temp;
+ volatile ccsr_gpio_t *pgpio = (void
*)(CONFIG_SYS_MPC85xx_GPIO_ADDR);
+ char board_rev = 0;
+ struct cpu_type *cpu;
+
+ val =
Re: [U-Boot] Rejected: PATCH Nios2 kernel bootstrap error due to missing processor data cache flush: fix
Dear Scott, Wolfgang, On Tue, Jul 21, 2009 at 02:02:43PM -0400, Scott McNutt wrote: ... for a two line bug fix? This is hardly a valid reason to claim copyright on the module. This practice will only discourage the contribution of original work to the project. Nobody wants to have their work hijacked in such a manner. So you really think your practice will encourage anybody to submit a clean patch for a bug he spent days (or weeks) to find? I found it very difficult to supply a clean patch for some of the fixes or improvements I did for my private coldfire tree. For few of them, I sent bug reports with the part to fix - but I am not even sure if they finally got picked up by the maintainer. On the one hand, you want patches to be tested (which is a good thing, of course), on the other hand I can not test a patch without other things changed for my board (which is not really useful for inclusion in the official tree, I think). Keeping several trees up-to-date to test the patches out of the vanilla tree and then rolling them back into the vanilly tree is at least beyond my time scale (and, to be honest, sometimes my knowledge of git, which is not self-explanatory at all). I can understand the maintainers have not that much time, I can also understand that the original work has to get its due credit - but then those sending patches should get their credit, too, or else the maintainer has to do the work of integrating the fix himself. Just my 2C, of course... Regards, Wolfgang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] P2020RDB Platform Support Added
Dear Aggrwal Poonam-B10812, In message 1bd5cfc378ed0946b688e0c9ba2ef095129...@zin33exm24.fsl.freescale.net you wrote: ... + val = pgpio-gpdat; + temp = val BOARDREV_MASK; + if (temp == BOARDREV_C) + board_rev = 'C'; + else if (temp == BOARDREV_B) + board_rev = 'B'; What happens if it's neither BOARDREV_B nore BOARDREV_C ? It has to be rev b or revC , may be we can spin here. Famous last words :-) Please at least print an error message. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The IQ of the group is the lowest IQ of a member of the group divided by the number of people in the group. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Rejected: PATCH Nios2 kernel bootstrap error due to missing processor data cache flush: fix
Dear Wolfgang Wegner, In message 20090722094127.gv20...@leila.ping.de you wrote: So you really think your practice will encourage anybody to submit a clean patch for a bug he spent days (or weeks) to find? That's how the public review process works: You submit a patch, and it either gets accepted or rejected. If it gets rejected, you gotta rework it again (and again, if necessary) until it gets accepted. This is not different for you or for me or for anybody else. If you submit a patch that gets accepted you at least 1) know that the problem is fixed in mainline, i. e. once and for ever, and 2) you receive the full credit for it because you show up as the author of the commit. If you don't do that, then either somebody else will clean up your patch and commit it and earn the credits for your work, or nobody will care and the problem remains, which means your work was basicly wasted. Your choice. On the one hand, you want patches to be tested (which is a good thing, of course), on the other hand I can not test a patch without other things changed for my board (which is not really useful for inclusion in the official tree, I think). Keeping several trees up-to-date to test the patches out of the vanilla tree and then rolling them back into the vanilly tree is at least beyond my time scale (and, to be honest, sometimes my knowledge of git, which is not self-explanatory at all). Well, we cannot save you the effort of learning git. We all had to go through this ourself. But I can promise that it is very well invested effort which will pay back very quickly. Um... and instead of maintaining several private source trees you should consider poushing your code upstream, so that others do the maintenance for you. I can understand the maintainers have not that much time, I can also understand that the original work has to get its due credit - but then those sending patches should get their credit, too, or else the maintainer has to do the work of integrating the fix himself. You get the credit by being the author of the commit, and by your Signed-off-by: line in it. git log will show it, git blame will show it, and you will find your place in the U-Boot statistics page, too. You do not have any entitlement on a (C) Copyright entry in a bigger source file if you change just a few lines in it. That's not reasonable. 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 some good people in it, but the orchestra as a whole is equivalent to a gang bent on destruction. - John Cage, composer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5] ppc4xx: Add 405EP based PMC405DE board
On Wednesday 22 July 2009 12:34:44 Wolfgang Denk wrote: Indentation is not done by TABs, but by TABs + spaces, and this is wrong. Why should this be wrong? This alignment looks better IMHO. Please allow the developers a little bit of freedom. Documentation/CodingStyle: Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3. Fuck Ack. But: This has nothing to do with the problem we are discussing here. I was talking about alignment and not indentation. Do you want to forbid people use alignment at all? Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Support for the Calao TNY-A9260 board
Hi Wolfgang, On Wed, Jul 22, 2009 at 11:47:36AM +0200, Wolfgang Denk wrote : Just rebase your tree against current mainline. Ah, it's in git now, thanks. include/configs/tny_a9260.h makes the compile fail. Am I overlooking something here ? You should not have to include common.h; it's already included virtually everywhere. cpu/arm926ejs/start.S includes directly config.h, which in turns includes the config file, but nowhere is common.h included, leading to start.S:168: Error: garbage following instruction -- `sub r0,r0,#ROUND(3*0x1000+128*1024,0x1000)' What's the best way to fix this ? Cheers, -- Albin Tonnerre, Free Electrons Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5] ppc4xx: Add 405EP based PMC405DE board
Dear Matthias Fuchs,
In message 200907221214.25935.matthias.fu...@esd.eu you wrote:
The braces should be indented by TABs.
Can you please post a suggestion you you would like to this these
lines indented. When I try to replace the spaces by TABs, the code
looks very ugly and unreadable and I don't like that.
So you want me to do the editing for you? May I send my invoice to
esd's address?
So perhaps I missed what you mean and I have to reconfigure my emacs
autoindent mode to wd'mode.
I don't understand what's so difficult about it; just indent by TABs:
struct ppc4xx_config ppc4xx_config_val[] = {
{
133,
CPU: 133 PLB: 133 OPB: 66 EBC: 44 PCI: 44/66,
{
0x19, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x40, 0x12, 0x12, 0x42, 0x3e, 0x00, 0x00,
}
},
{
266,
CPU: 266 PLB: 133 OPB: 66 EBC: 44 PCI: 44/66,
{
0x19, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x50, 0x22, 0x2d, 0x42, 0x3e, 0x00, 0x00,
}
},
{
333,
CPU: 333 PLB: 111 OPB: 55 EBC: 55 PCI: 55/111,
{
0x19, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x60, 0x29, 0x2d, 0x42, 0xbe, 0x00, 0x00,
}
},
};
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
Half of the people in the world are below average.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5] ppc4xx: Add 405EP based PMC405DE board
Dear Stefan Roese, In message 200907221257.30824...@denx.de you wrote: Fuck Ack. But: This has nothing to do with the problem we are discussing here. I was talking about alignment and not indentation. Do you want to forbid people use alignment at all? Please do me (and yourself, and us all) a favour and just read the rules, and then follow them, instead of wasting our all time. See http://www.denx.de/wiki/U-Boot/CodingStyle: Use TAB characters for indentation and vertical alignment, not spaces. Anything else? 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 As of 1992, they're called European Economic Community fries. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5] ppc4xx: Add 405EP based PMC405DE board
On Wednesday 22 July 2009 13:05:56 Wolfgang Denk wrote:
I don't understand what's so difficult about it; just indent by TABs:
struct ppc4xx_config ppc4xx_config_val[] = {
{
133,
CPU: 133 PLB: 133 OPB: 66 EBC: 44 PCI: 44/66,
{
0x19, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x40, 0x12, 0x12, 0x42, 0x3e, 0x00, 0x00,
}
},
OK, now let's compare your version with ours:
+ { 133, CPU: 133 PLB: 133 OPB: 66 EBC: 44 PCI: 44/66,
+ { 0x19, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x40, 0x12, 0x12, 0x42, 0x3e, 0x00, 0x00 } },
Your version is 10 lines long, ours is 5. That twice as long. I still prefer
our version and think this kind of personal freedom should be allowed.
Best regards,
Stefan
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Support for the Calao TNY-A9260 board
Dear Albin Tonnerre, In message 20090722110303.gc13...@pc-ras4041.res.insa you wrote: You should not have to include common.h; it's already included virtually everywhere. cpu/arm926ejs/start.S includes directly config.h, which in turns includes the config file, but nowhere is common.h included, leading to start.S:168: Error: garbage following instruction -- `sub r0,r0,#ROUND(3*0x 1000+128*1024,0x1000)' Arghh.. Seems the mising feedback for the patch was caused by nobody actually testing it, not by nobody having any problems with it. Sorry for that. What's the best way to fix this ? Hm... give me a few minutes to think about this. 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 much net work could a network work, if a network could net work? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5] ppc4xx: Add 405EP based PMC405DE board
Dear Stefan Roese, In message 200907221312.17644...@denx.de you wrote: Your version is 10 lines long, ours is 5. That twice as long. I still prefer our version and think this kind of personal freedom should be allowed. Nobody attempts to restrict yoru thoughts or preferences. But you want to have the patch accepted, and I want you to stick with the CodingStyle. That's all. Full stop. 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 In the beginning, there was nothing, which exploded. - Terry Pratchett, _Lords and Ladies_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5] ppc4xx: Add 405EP based PMC405DE board
On Wednesday 22 July 2009 13:08:30 Wolfgang Denk wrote: Please do me (and yourself, and us all) a favour and just read the rules, and then follow them, instead of wasting our all time. I'm pretty sure that I'm doing at least some developers a favour, in discussing this issue. It's annoying not being able to use a coding style that's accepted for example in the Linux kernel all the time. But ok, I'm stopping here as well. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Removed CONFIG_NUM_CPUS for 85xx and86xxFreescale processors.
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Aggrwal
Poonam-B10812
Sent: Wednesday, July 22, 2009 3:45 PM
To: Wolfgang Denk; Gala Kumar-B11780
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH 1/2] Removed CONFIG_NUM_CPUS for
85xx and86xxFreescale processors.
...
+#ifndef CONFIG_MP
+ if (cpu_numcores() 1)
+ puts(#\n
+ The system is detected to be MULTICORE,\n
+ but u-boot is built with UNI-CORE\n
+ To enable mutlticore Build set CONFIG_MP\n
+
#\n\n);
#endif
Please use terse error messages. We don't print prose here.
- cpu = identify_cpu(ver);
- if (cpu) {
+ if (cpu_numcores() 1) {
+ volatile ccsr_pic_t *pic = (void
*)(CONFIG_SYS_MPC85xx_PIC_ADDR);
+ printf(CPU%d: , pic-whoami);
+ }
+ else
Incorrect brace style.
--- a/cpu/mpc85xx/speed.c
+++ b/cpu/mpc85xx/speed.c
...
@@ -51,7 +51,7 @@ void get_sys_info (sys_info_t * sysInfo)
/* Divide before multiply to avoid integer
* overflow for processor speeds above 2GHz */
half_freqSystemBus = sysInfo-freqSystemBus/2;
- for (i = 0; i CONFIG_NUM_CPUS; i++) {
+ for (i = 0; i cpu_numcores(); i++) {
Only one space before the '', please.
...
--- a/cpu/mpc86xx/cpu.c
+++ b/cpu/mpc86xx/cpu.c
...
+int probecpu (void)
+{
+ uint svr;
+ uint ver;
+
+ svr = get_svr();
+ ver = SVR_SOC_VER(svr);
+
+ gd-cpu = identify_cpu(ver);
+
+ return 0;
+}
+
+int cpu_numcores() {
+ struct cpu_type *cpu;
+ cpu = gd-cpu;
+ return cpu-num_cores;
+}
+
This seems to be identically repeated code. Please factor out into
common code.
Actually the files cpu/mpc86xx/cpu.c cpu/mpc85xx/cpu.c are
quite identical.
Kumar, Please suggest how should this be taken care.
Probably a single file to take care of 85xx and 86xx don't know?
Just a request , I would like to close this as we need to push P2020RDB
support quickly.
Otherwise should I just go ahead with 85xx for now? Please suggest.
Regards
Poonam
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk
Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194
Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
w...@denx.de You can only live once, but if you do it right, once is
enough.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Support up to 7 banks for ids as specified in JEDEC JEP106Z. see http://www.jedec.org/download/search/jep106Z.pdf Add some second source legacy flash chips 256x8.
Signed-off-by: Niklaus Giger niklaus.gi...@member.fsf.org
---
drivers/mtd/cfi_flash.c | 15 +-
drivers/mtd/jedec_flash.c | 67 +
include/flash.h | 10 ++-
3 files changed, 89 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index 81ac5d3..4a4b697 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -106,6 +106,8 @@
#define ATM_CMD_SOFTLOCK_START 0x80
#define ATM_CMD_LOCK_SECT 0x40
+#define FLASH_CONTINUATION_CODE 0x7F
+
#define FLASH_OFFSET_MANUFACTURER_ID 0x00
#define FLASH_OFFSET_DEVICE_ID 0x01
#define FLASH_OFFSET_DEVICE_ID20x0E
@@ -1541,13 +1543,22 @@ static int cmdset_intel_init(flash_info_t *info, struct
cfi_qry *qry)
static void cmdset_amd_read_jedec_ids(flash_info_t *info)
{
+ ushort bankId = 0;
+ uchar manuId;
+
flash_write_cmd(info, 0, 0, AMD_CMD_RESET);
flash_unlock_seq(info, 0);
flash_write_cmd(info, 0, info-addr_unlock1, FLASH_CMD_READ_ID);
udelay(1000); /* some flash are slow to respond */
- info-manufacturer_id = flash_read_uchar (info,
- FLASH_OFFSET_MANUFACTURER_ID);
+ manuId = flash_read_uchar (info, FLASH_OFFSET_MANUFACTURER_ID);
+ /* JEDEC JEP106Z specifies ID codes up to bank 7 */
+ while (manuId == FLASH_CONTINUATION_CODE bankId 0x800) {
+ bankId += 0x100;
+ manuId = flash_read_uchar (info,
+ bankId | FLASH_OFFSET_MANUFACTURER_ID);
+ }
+ info-manufacturer_id = manuId;
switch (info-chipwidth){
case FLASH_CFI_8BIT:
diff --git a/drivers/mtd/jedec_flash.c b/drivers/mtd/jedec_flash.c
index e48acec..376a323 100644
--- a/drivers/mtd/jedec_flash.c
+++ b/drivers/mtd/jedec_flash.c
@@ -68,6 +68,17 @@
#define SST39SF010A0x00B5
#define SST39SF020A0x00B6
+/* MXIC */
+#define MX29LV040 0x004F
+
+/* WINBOND */
+#define W39L040A0x00D6
+
+/* AMIC */
+#define A29L040 0x0092
+
+/* EON */
+#define EN29LV040A 0x004F
/*
* Unlock address sets for AMD command sets.
@@ -225,6 +236,62 @@ static const struct amd_flash_info jedec_table[] = {
ERASEINFO(0x1,8),
}
},
+ {
+ .mfr_id = (u16)MX_MANUFACT,
+ .dev_id = MX29LV040,
+ .name = MXIC MX29LV040,
+ .uaddr = {
+ [0] = MTD_UADDR_0x0555_0x02AA /* x8 */
+ },
+ .DevSize= SIZE_512KiB,
+ .CmdSet = P_ID_AMD_STD,
+ .NumEraseRegions= 1,
+ .regions= {
+ ERASEINFO(0x1, 8),
+ }
+ },
+ {
+ .mfr_id = (u16)WINB_MANUFACT,
+ .dev_id = W39L040A,
+ .name = WINBOND W39L040A,
+ .uaddr = {
+ [0] = MTD_UADDR_0x_0x2AAA /* x8 */
+ },
+ .DevSize= SIZE_512KiB,
+ .CmdSet = P_ID_AMD_STD,
+ .NumEraseRegions= 1,
+ .regions= {
+ ERASEINFO(0x1, 8),
+ }
+ },
+ {
+ .mfr_id = (u16)AMIC_MANUFACT,
+ .dev_id = A29L040,
+ .name = AMIC A29L040,
+ .uaddr = {
+ [0] = MTD_UADDR_0x0555_0x02AA /* x8 */
+ },
+ .DevSize= SIZE_512KiB,
+ .CmdSet = P_ID_AMD_STD,
+ .NumEraseRegions= 1,
+ .regions= {
+ ERASEINFO(0x1, 8),
+ }
+ },
+ {
+ .mfr_id = (u16)EON_MANUFACT,
+ .dev_id = EN29LV040A,
+ .name = EON EN29LV040A,
+ .uaddr = {
+ [0] = MTD_UADDR_0x0555_0x02AA /* x8 */
+ },
+ .DevSize= SIZE_512KiB,
+ .CmdSet = P_ID_AMD_STD,
+ .NumEraseRegions= 1,
+ .regions= {
+ ERASEINFO(0x1, 8),
+ }
+ },
#endif
#ifdef CONFIG_SYS_FLASH_LEGACY_512Kx16
{
diff --git a/include/flash.h b/include/flash.h
index b016162..8feca1b 100644
--- a/include/flash.h
+++ b/include/flash.h
@@ -46,7 +46,7 @@ typedef struct {
ushort cmd_reset; /* vendor specific reset command
*/
ushort interface; /* used for x8/x16 adjustments
*/
ushort legacy_unlock; /* support Intel legacy (un)locking
*/
- uchar manufacturer_id;/* manufacturer id
Re: [U-Boot] Rejected: PATCH Nios2 kernel bootstrap error due to missing processor data cache flush: fix
Dear Wolfgang, On Wed, Jul 22, 2009 at 12:56:52PM +0200, Wolfgang Denk wrote: [...] If you don't do that, then either somebody else will clean up your patch and commit it and earn the credits for your work, or nobody will care and the problem remains, which means your work was basicly wasted. that was why I wrote now, because it seemed to me that the latter might happen in the current case. But maybe I misunderstood Renatos intention here. [...] Um... and instead of maintaining several private source trees you should consider poushing your code upstream, so that others do the maintenance for you. The intention is to do so with my next project at work - but again it depends on how much time is left after sorting out all the low-level hard- and software bugs. You get the credit by being the author of the commit, and by your Signed-off-by: line in it. git log will show it, git blame will show it, and you will find your place in the U-Boot statistics page, too. You do not have any entitlement on a (C) Copyright entry in a bigger source file if you change just a few lines in it. That's not reasonable. Thanks for clearing this up. Best regards, Wolfgang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Support up to 7 banks for ids as specified in JEDEC JEP106Z. see http://www.jedec.org/download/search/jep106Z.pdf Add some second source legacy flash chips 256x8.
Hi Niklaus, now you've got a very looong subject. Please split this into a shorter subject and put the rest in the commit text. Thanks. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] tools: mkimage: kwbimage list command support
-Original Message-
From: Wolfgang Denk [mailto:w...@denx.de]
Sent: Wednesday, July 22, 2009 4:11 PM
To: Prafulla Wadaskar
Cc: u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik
Subject: Re: [U-Boot] [PATCH v2 3/4] tools: mkimage: kwbimage
list command support
+ if (!(kwbimage_check_header ((struct kwb_header
*)ptr))) {
+ kwbimage_print_contents ((struct
kwb_header *)ptr);
+ exit (EXIT_SUCCESS);
I think you should add error checking here. For example, when the
code detects a corruption of the image (checksum error or
the like),
it should return an error code here, so you can use
mkimage -l to
actually verify the consistency of an image (in automated
scripts).
Currently mkimage checks first kwbimage header followed by ftd/fit
header c hecks In that case returning an error code will
not be useful
I don't understand what you mean here. Any corruption of an
image should be detected and signalled to the caller by a
non-zero return code of the mkimage command.
My answer was only related to kwbimage point of view
your comment is more towards existing code cleanup, yes it returns success even
though header check fails
I will do it as a part of mkimage code cleanup.
Thanks and regards..
Prafulla . .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V6] ppc4xx: Add 405EP based PMC405DE board
Signed-off-by: Matthias Fuchs matthias.fu...@esd.eu --- patch v2: - coding style cleanup - added CONFIG_PHY1_ADDR patch v3: - refactor PLL reconfiguration code - beautify some one-line-functions patch v4: - remove 'sbe' command - add CONFIG_CMD_CHIP_CONFIG support - use ppc4xx_gpio struct for GPIO access - use set/clrbits_be32 to modify GPIO registers - add CPLD register struct patch v5: - add patch history to commit message patch v6: - update identation of chip_config struct MAINTAINERS |1 + MAKEALL |1 + Makefile |3 + board/esd/pmc405de/Makefile | 53 board/esd/pmc405de/chip_config.c | 61 + board/esd/pmc405de/config.mk | 23 ++ board/esd/pmc405de/pmc405de.c| 521 ++ board/esd/pmc405de/u-boot.lds| 133 ++ include/configs/PMC405DE.h | 378 +++ 9 files changed, 1174 insertions(+), 0 deletions(-) create mode 100644 board/esd/pmc405de/Makefile create mode 100644 board/esd/pmc405de/chip_config.c create mode 100644 board/esd/pmc405de/config.mk create mode 100644 board/esd/pmc405de/pmc405de.c create mode 100644 board/esd/pmc405de/u-boot.lds create mode 100644 include/configs/PMC405DE.h diff --git a/MAINTAINERS b/MAINTAINERS index 575a7ec..484040c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -171,6 +171,7 @@ Matthias Fuchs matthias.fu...@esd-electronics.com PCI405 PPC405GP PLU405 PPC405EP PMC405 PPC405GP + PMC405DEPPC405EP PMC440 PPC440EPx VOH405 PPC405EP VOM405 PPC405EP diff --git a/MAKEALL b/MAKEALL index 020ff73..f36a5fd 100755 --- a/MAKEALL +++ b/MAKEALL @@ -237,6 +237,7 @@ LIST_4xx= \ PIP405 \ PLU405 \ PMC405 \ + PMC405DE\ PMC440 \ PPChameleonEVB \ quad100hd \ diff --git a/Makefile b/Makefile index 090e645..a5d397b 100644 --- a/Makefile +++ b/Makefile @@ -1492,6 +1492,9 @@ PLU405_config:unconfig PMC405_config: unconfig @$(MKCONFIG) $(@:_config=) ppc ppc4xx pmc405 esd +PMC405DE_config: unconfig + @$(MKCONFIG) $(@:_config=) ppc ppc4xx pmc405de esd + PMC440_config: unconfig @$(MKCONFIG) $(@:_config=) ppc ppc4xx pmc440 esd diff --git a/board/esd/pmc405de/Makefile b/board/esd/pmc405de/Makefile new file mode 100644 index 000..a080649 --- /dev/null +++ b/board/esd/pmc405de/Makefile @@ -0,0 +1,53 @@ +# +# (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-y= $(BOARD).o +COBJS-y+= ../common/cmd_loadpci.o +COBJS-$(CONFIG_CMD_CHIP_CONFIG) += chip_config.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) + +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/esd/pmc405de/chip_config.c b/board/esd/pmc405de/chip_config.c new file mode 100644 index 000..e93a32c --- /dev/null +++ b/board/esd/pmc405de/chip_config.c @@ -0,0 +1,61 @@ +/* + * (C) Copyright 2008-2009 + * 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
[U-Boot] [PATCH:v2] Support up to 7 banks for ids as specified in JEDEC JEP106Z
see http://www.jedec.org/download/search/jep106Z.pdf
Add some second source legacy flash chips 256x8.
Signed-off-by: Niklaus Giger niklaus.gi...@member.fsf.org
---
drivers/mtd/cfi_flash.c | 15 +-
drivers/mtd/jedec_flash.c | 67 +
include/flash.h | 10 ++-
3 files changed, 89 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index 81ac5d3..4a4b697 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -106,6 +106,8 @@
#define ATM_CMD_SOFTLOCK_START 0x80
#define ATM_CMD_LOCK_SECT 0x40
+#define FLASH_CONTINUATION_CODE 0x7F
+
#define FLASH_OFFSET_MANUFACTURER_ID 0x00
#define FLASH_OFFSET_DEVICE_ID 0x01
#define FLASH_OFFSET_DEVICE_ID20x0E
@@ -1541,13 +1543,22 @@ static int cmdset_intel_init(flash_info_t *info, struct
cfi_qry *qry)
static void cmdset_amd_read_jedec_ids(flash_info_t *info)
{
+ ushort bankId = 0;
+ uchar manuId;
+
flash_write_cmd(info, 0, 0, AMD_CMD_RESET);
flash_unlock_seq(info, 0);
flash_write_cmd(info, 0, info-addr_unlock1, FLASH_CMD_READ_ID);
udelay(1000); /* some flash are slow to respond */
- info-manufacturer_id = flash_read_uchar (info,
- FLASH_OFFSET_MANUFACTURER_ID);
+ manuId = flash_read_uchar (info, FLASH_OFFSET_MANUFACTURER_ID);
+ /* JEDEC JEP106Z specifies ID codes up to bank 7 */
+ while (manuId == FLASH_CONTINUATION_CODE bankId 0x800) {
+ bankId += 0x100;
+ manuId = flash_read_uchar (info,
+ bankId | FLASH_OFFSET_MANUFACTURER_ID);
+ }
+ info-manufacturer_id = manuId;
switch (info-chipwidth){
case FLASH_CFI_8BIT:
diff --git a/drivers/mtd/jedec_flash.c b/drivers/mtd/jedec_flash.c
index e48acec..376a323 100644
--- a/drivers/mtd/jedec_flash.c
+++ b/drivers/mtd/jedec_flash.c
@@ -68,6 +68,17 @@
#define SST39SF010A0x00B5
#define SST39SF020A0x00B6
+/* MXIC */
+#define MX29LV040 0x004F
+
+/* WINBOND */
+#define W39L040A0x00D6
+
+/* AMIC */
+#define A29L040 0x0092
+
+/* EON */
+#define EN29LV040A 0x004F
/*
* Unlock address sets for AMD command sets.
@@ -225,6 +236,62 @@ static const struct amd_flash_info jedec_table[] = {
ERASEINFO(0x1,8),
}
},
+ {
+ .mfr_id = (u16)MX_MANUFACT,
+ .dev_id = MX29LV040,
+ .name = MXIC MX29LV040,
+ .uaddr = {
+ [0] = MTD_UADDR_0x0555_0x02AA /* x8 */
+ },
+ .DevSize= SIZE_512KiB,
+ .CmdSet = P_ID_AMD_STD,
+ .NumEraseRegions= 1,
+ .regions= {
+ ERASEINFO(0x1, 8),
+ }
+ },
+ {
+ .mfr_id = (u16)WINB_MANUFACT,
+ .dev_id = W39L040A,
+ .name = WINBOND W39L040A,
+ .uaddr = {
+ [0] = MTD_UADDR_0x_0x2AAA /* x8 */
+ },
+ .DevSize= SIZE_512KiB,
+ .CmdSet = P_ID_AMD_STD,
+ .NumEraseRegions= 1,
+ .regions= {
+ ERASEINFO(0x1, 8),
+ }
+ },
+ {
+ .mfr_id = (u16)AMIC_MANUFACT,
+ .dev_id = A29L040,
+ .name = AMIC A29L040,
+ .uaddr = {
+ [0] = MTD_UADDR_0x0555_0x02AA /* x8 */
+ },
+ .DevSize= SIZE_512KiB,
+ .CmdSet = P_ID_AMD_STD,
+ .NumEraseRegions= 1,
+ .regions= {
+ ERASEINFO(0x1, 8),
+ }
+ },
+ {
+ .mfr_id = (u16)EON_MANUFACT,
+ .dev_id = EN29LV040A,
+ .name = EON EN29LV040A,
+ .uaddr = {
+ [0] = MTD_UADDR_0x0555_0x02AA /* x8 */
+ },
+ .DevSize= SIZE_512KiB,
+ .CmdSet = P_ID_AMD_STD,
+ .NumEraseRegions= 1,
+ .regions= {
+ ERASEINFO(0x1, 8),
+ }
+ },
#endif
#ifdef CONFIG_SYS_FLASH_LEGACY_512Kx16
{
diff --git a/include/flash.h b/include/flash.h
index b016162..8feca1b 100644
--- a/include/flash.h
+++ b/include/flash.h
@@ -46,7 +46,7 @@ typedef struct {
ushort cmd_reset; /* vendor specific reset command
*/
ushort interface; /* used for x8/x16 adjustments
*/
ushort legacy_unlock; /* support
Re: [U-Boot] Kernel RSA signature ?
Tivoize : no. My interest is the security part, I want a secure boot for remotely upgrade my firmware. Thanks Cyrille ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH:v2] Support up to 7 banks for ids as specified in JEDEC JEP106Z
On Wednesday 22 July 2009 14:03:04 Niklaus Giger wrote:
see http://www.jedec.org/download/search/jep106Z.pdf
Add some second source legacy flash chips 256x8.
Please add an empty line here.
Signed-off-by: Niklaus Giger niklaus.gi...@member.fsf.org
And still some more white space cleanup comments below (sorry, I didn't catch
them before).
---
drivers/mtd/cfi_flash.c | 15 +-
drivers/mtd/jedec_flash.c | 67
+ include/flash.h |
10 ++-
3 files changed, 89 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index 81ac5d3..4a4b697 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -106,6 +106,8 @@
#define ATM_CMD_SOFTLOCK_START 0x80
#define ATM_CMD_LOCK_SECT0x40
+#define FLASH_CONTINUATION_CODE 0x7F
Indentation by tab's please.
+
#define FLASH_OFFSET_MANUFACTURER_ID 0x00
#define FLASH_OFFSET_DEVICE_ID 0x01
#define FLASH_OFFSET_DEVICE_ID2 0x0E
@@ -1541,13 +1543,22 @@ static int cmdset_intel_init(flash_info_t *info,
struct cfi_qry *qry)
static void cmdset_amd_read_jedec_ids(flash_info_t *info)
{
+ ushort bankId = 0;
+ uchar manuId;
+
flash_write_cmd(info, 0, 0, AMD_CMD_RESET);
flash_unlock_seq(info, 0);
flash_write_cmd(info, 0, info-addr_unlock1, FLASH_CMD_READ_ID);
udelay(1000); /* some flash are slow to respond */
- info-manufacturer_id = flash_read_uchar (info,
- FLASH_OFFSET_MANUFACTURER_ID);
+ manuId = flash_read_uchar (info, FLASH_OFFSET_MANUFACTURER_ID);
+ /* JEDEC JEP106Z specifies ID codes up to bank 7 */
+ while (manuId == FLASH_CONTINUATION_CODE bankId 0x800) {
+ bankId += 0x100;
+ manuId = flash_read_uchar (info,
+ bankId | FLASH_OFFSET_MANUFACTURER_ID);
+ }
+ info-manufacturer_id = manuId;
switch (info-chipwidth){
case FLASH_CFI_8BIT:
diff --git a/drivers/mtd/jedec_flash.c b/drivers/mtd/jedec_flash.c
index e48acec..376a323 100644
--- a/drivers/mtd/jedec_flash.c
+++ b/drivers/mtd/jedec_flash.c
@@ -68,6 +68,17 @@
#define SST39SF010A 0x00B5
#define SST39SF020A 0x00B6
+/* MXIC */
+#define MX29LV0400x004F
+
+/* WINBOND */
+#define W39L040A0x00D6
tabs again.
+
+/* AMIC */
+#define A29L040 0x0092
and here.
+
+/* EON */
+#define EN29LV040A 0x004F
and here.
Thanks.
Best regards,
Stefan
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm: pRAM support?
Dear Wolfgang Denk, Dear Heiko Schocher, In message 4a66a86d.7070...@denx.de you wrote: Andreas Huber wrote: We are using the pRAM feature (CONFIG_PRAM) on the PPC architecture. As we are switching to an ARM architecture (Kirkwood) I am wondering if there is an equivalent U-Boot feature for this (CONFIG_PRAM did not work). As this functionality uses RAM at the end of RAM, it should be possible to add this also to ARM plattforms. Jean-Christophe, Prafulla, are there any objections on it? Well, if you want to do it Right (TM) that means we would take this chance and fix the ARM memory map, which implies to implement relocation to a dynamicalle detemined relocation address. can you explain this a little bit more in detail? Sounds like, that this is a larger chunk of work? Best regards Holger Brunck ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] 86xx: Report which bank of NOR flash we are booting from on MPC8641HPCN
The MPC8641HPCN board is capable of swizzling the upper address bit of
the NOR flash we boot out of which creates the concept of virtual
banks. This is useful in that we can flash a test of image of u-boot
and reset to one of the virtual banks while still maintaining a
working image in bank 0.
The PIXIS FPGA exposes registers on LBC which we can use to determine
which bank we are booting out of (as well as setting which bank to
boot out of).
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
* Added #defines for the VBOOT fields we use
board/freescale/mpc8641hpcn/mpc8641hpcn.c | 18 ++
include/configs/MPC8641HPCN.h |2 ++
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/board/freescale/mpc8641hpcn/mpc8641hpcn.c
b/board/freescale/mpc8641hpcn/mpc8641hpcn.c
index 7422e6b..441127b 100644
--- a/board/freescale/mpc8641hpcn/mpc8641hpcn.c
+++ b/board/freescale/mpc8641hpcn/mpc8641hpcn.c
@@ -42,10 +42,20 @@ int board_early_init_f(void)
int checkboard(void)
{
- printf (Board: MPC8641HPCN, System ID: 0x%02x,
- System Version: 0x%02x, FPGA Version: 0x%02x\n,
- in8(PIXIS_BASE + PIXIS_ID), in8(PIXIS_BASE + PIXIS_VER),
- in8(PIXIS_BASE + PIXIS_PVER));
+ u8 vboot;
+ u8 *pixis_base = (u8 *)PIXIS_BASE;
+
+ printf (Board: MPC8641HPCN, Sys ID: 0x%02x,
+ Sys Ver: 0x%02x, FPGA Ver: 0x%02x, ,
+ in_8(pixis_base + PIXIS_ID), in_8(pixis_base + PIXIS_VER),
+ in_8(pixis_base + PIXIS_PVER));
+
+ vboot = in_8(pixis_base + PIXIS_VBOOT);
+ if (vboot PIXIS_VBOOT_FMAP)
+ printf (vBank: %d\n, ((vboot PIXIS_VBOOT_FBANK) 6));
+ else
+ puts (Promjet\n);
+
#ifdef CONFIG_PHYS_64BIT
printf ( 36-bit physical address map\n);
#endif
diff --git a/include/configs/MPC8641HPCN.h b/include/configs/MPC8641HPCN.h
index 955ac3d..bf2e359 100644
--- a/include/configs/MPC8641HPCN.h
+++ b/include/configs/MPC8641HPCN.h
@@ -224,6 +224,8 @@ extern unsigned long get_board_sys_clk(unsigned long dummy);
#define PIXIS_VCFGEN0 0x12/* VELA Config Enable 0 */
#define PIXIS_VCFGEN1 0x13/* VELA Config Enable 1 */
#define PIXIS_VBOOT0x16/* VELA VBOOT Register */
+#define PIXIS_VBOOT_FMAP 0x80/* VBOOT - CFG_FLASHMAP */
+#define PIXIS_VBOOT_FBANK 0x40/* VBOOT - CFG_FLASHBANK */
#define PIXIS_VSPEED0 0x17/* VELA VSpeed 0 */
#define PIXIS_VSPEED1 0x18/* VELA VSpeed 1 */
#define PIXIS_VCLKH0x19/* VELA VCLKH register */
--
1.6.0.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
We are looking for an http client now as well. Our major issue revolves around the download times for tftp. Can Volkmar Uhlig kindly provide the patches? Our units automically update themselves inside of uboot giving us the most control over our firmware. The issue is that it takes 20 minutes via a DSL line in Africa to update our units. An http test showed that the same firmware downloads in 30 seconds. We have also added things like the blksize parameter to the uboot tftp client to get it down to 20 minutes, our original download times were ~50 minutes. We would like to work to integrate or add the necessary http client functions to achieve this. If there are no patches obtainable, is anyone interested in working on this with us? Jeffery Palmer Project Development 954.709.7232 _ From: Mark T [mailto:m...@astfin.org] Sent: Wednesday, July 22, 2009 8:47 AM To: Jeff Palmer Subject: Fwd: [U-Boot] http client? fyi Begin forwarded message: From: Robin Getz rg...@blackfin.uclinux.org Date: July 22, 2009 8:26:58 AM GMT-04:00 To: u-boot@lists.denx.de Cc: Ben Warren biggerbadder...@gmail.com, Volkmar Uhlig vuh...@us.ibm.com Subject: Re: [U-Boot] http client? On Tue 21 Jul 2009 17:09, Wolfgang Denk pondered: Dear Robin Getz, In message 200907211400.21275.rg...@blackfin.uclinux.org you wrote: I know there have been discussions about adding wget to U-Boot, which I agree is not something that is worthwhile to do. I am not so sure about that, but that's just my opinion. http://lists.denx.de/pipermail/u-boot/2006-March/013697.html but a simple client would be helpful in many situations. There is such in IBM's port of U-Boot for the Blue Gene super- computer, and Volkmar Uhlig promised to submit patches. But so far he didn't. Hmm.. That sounds interesting. Do you know if there is a public repository? or Do I need to buy a Blue Gene to get access to the source :) According to: http://domino.research.ibm.com/comm/research_projects.nsf/pages/kittyhawkindex.html/$FILE/Kittyhawk%20OSR%2008.pdf We added a simple HTTP server to U-Boot so that individual nodes can be booted via a PUT command that pushes the desired boot images and kernel command line. The command line is evaluated via the scripting environment before it gets passed on to the OS kernel thereby allowing per node customizations. With this simple extension to U-Boot we are able to construct powerful scripted environments and bootstrap large numbers of nodes in a controlled, flexible, and secure way. What is in RedBoot is a HTTP GET. So -- while it shouldn't be hard to extend from there... If a port of the redboot functionality is done - any thoughts on if it would be accepted? Well, you are aware that such a thing would need a TCP/IP stack, which is far beyond what we currently have in U-Boot support? Yes - I'm aware. My thoughts were to do something like what IBM and other suggestions were - use lwip. -Robin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot __ NOD32 4266 (20090722) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] 85xx: Report which bank of NOR flash we are booting from on FSL boards
The p2020DS, MPC8536DS, MPC8572DS, MPC8544DS boards are capable of
swizzling the upper address bits of the NOR flash we boot out of which
creates the concept of virtual banks. This is useful in that we can
flash a test of image of u-boot and reset to one of the virtual banks
while still maintaining a working image in bank 0.
The PIXIS FPGA exposes registers on LBC which we can use to determine
which bank we are booting out of (as well as setting which bank to
boot out of).
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
* Added #defines for the VBOOT/SW7 register fields we use
* Moved from in8 - in_8
* simplified if() test
board/freescale/mpc8536ds/mpc8536ds.c | 39 +---
board/freescale/mpc8544ds/mpc8544ds.c | 16 ++---
board/freescale/mpc8572ds/mpc8572ds.c | 26 +++--
board/freescale/p2020ds/p2020ds.c | 23 +--
include/configs/MPC8536DS.h |7 ++
include/configs/MPC8544DS.h |2 +
include/configs/MPC8572DS.h |5
include/configs/P2020DS.h |5
8 files changed, 109 insertions(+), 14 deletions(-)
diff --git a/board/freescale/mpc8536ds/mpc8536ds.c
b/board/freescale/mpc8536ds/mpc8536ds.c
index 28b27ee..66f095f 100644
--- a/board/freescale/mpc8536ds/mpc8536ds.c
+++ b/board/freescale/mpc8536ds/mpc8536ds.c
@@ -60,10 +60,41 @@ int board_early_init_f (void)
int checkboard (void)
{
- printf (Board: MPC8536DS, System ID: 0x%02x,
- System Version: 0x%02x, FPGA Version: 0x%02x\n,
- in8(PIXIS_BASE + PIXIS_ID), in8(PIXIS_BASE + PIXIS_VER),
- in8(PIXIS_BASE + PIXIS_PVER));
+ u8 vboot;
+ u8 *pixis_base = (u8 *)PIXIS_BASE;
+
+ puts(Board: MPC8536DS );
+#ifdef CONFIG_PHYS_64BIT
+ puts((36-bit addrmap) );
+#endif
+
+ printf (Sys ID: 0x%02x,
+ Sys Ver: 0x%02x, FPGA Ver: 0x%02x, ,
+ in_8(pixis_base + PIXIS_ID), in_8(pixis_base + PIXIS_VER),
+ in_8(pixis_base + PIXIS_PVER));
+
+ vboot = in_8(pixis_base + PIXIS_VBOOT);
+ switch ((vboot PIXIS_VBOOT_LBMAP) 5) {
+ case PIXIS_VBOOT_LBMAP_NOR0:
+ puts (vBank: 0\n);
+ break;
+ case PIXIS_VBOOT_LBMAP_NOR1:
+ puts (vBank: 1\n);
+ break;
+ case PIXIS_VBOOT_LBMAP_NOR2:
+ puts (vBank: 2\n);
+ break;
+ case PIXIS_VBOOT_LBMAP_NOR3:
+ puts (vBank: 3\n);
+ break;
+ case PIXIS_VBOOT_LBMAP_PJET:
+ puts (Promjet\n);
+ break;
+ case PIXIS_VBOOT_LBMAP_NAND:
+ puts (NAND\n);
+ break;
+ }
+
return 0;
}
diff --git a/board/freescale/mpc8544ds/mpc8544ds.c
b/board/freescale/mpc8544ds/mpc8544ds.c
index 34bdbad..b251e2e 100644
--- a/board/freescale/mpc8544ds/mpc8544ds.c
+++ b/board/freescale/mpc8544ds/mpc8544ds.c
@@ -43,14 +43,22 @@ int checkboard (void)
volatile ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
volatile ccsr_lbc_t *lbc = (void *)(CONFIG_SYS_MPC85xx_LBC_ADDR);
volatile ccsr_local_ecm_t *ecm = (void *)(CONFIG_SYS_MPC85xx_ECM_ADDR);
+ u8 vboot;
+ u8 *pixis_base = (u8 *)PIXIS_BASE;
if ((uint)gur-porpllsr != 0xe00e) {
printf(immap size error %lx\n,(ulong)gur-porpllsr);
}
- printf (Board: MPC8544DS, System ID: 0x%02x,
- System Version: 0x%02x, FPGA Version: 0x%02x\n,
- in8(PIXIS_BASE + PIXIS_ID), in8(PIXIS_BASE + PIXIS_VER),
- in8(PIXIS_BASE + PIXIS_PVER));
+ printf (Board: MPC8544DS, Sys ID: 0x%02x,
+ Sys Ver: 0x%02x, FPGA Ver: 0x%02x, ,
+ in_8(pixis_base + PIXIS_ID), in_8(pixis_base + PIXIS_VER),
+ in_8(pixis_base + PIXIS_PVER));
+
+ vboot = in_8(pixis_base + PIXIS_VBOOT);
+ if (vboot PIXIS_VBOOT_FMAP)
+ printf (vBank: %d\n, ((vboot PIXIS_VBOOT_FBANK) 6));
+ else
+ puts (Promjet\n);
lbc-ltesr = 0x;/* Clear LBC error interrupts */
lbc-lteir = 0x;/* Enable LBC error interrupts */
diff --git a/board/freescale/mpc8572ds/mpc8572ds.c
b/board/freescale/mpc8572ds/mpc8572ds.c
index 4b95617..51231d7 100644
--- a/board/freescale/mpc8572ds/mpc8572ds.c
+++ b/board/freescale/mpc8572ds/mpc8572ds.c
@@ -42,14 +42,34 @@ long int fixed_sdram(void);
int checkboard (void)
{
+ u8 vboot;
+ u8 *pixis_base = (u8 *)PIXIS_BASE;
+
puts (Board: MPC8572DS );
#ifdef CONFIG_PHYS_64BIT
puts ((36-bit addrmap) );
#endif
printf (Sys ID: 0x%02x,
- Sys Ver: 0x%02x, FPGA Ver: 0x%02x\n,
- in8(PIXIS_BASE + PIXIS_ID),
Re: [U-Boot] Rejected: PATCH Nios2 kernel bootstrap error due to missing processor data cache flush: fix
Dear Wolfgang Wegner, In message 20090722103358.gw20...@leila.ping.de you wrote: Um... and instead of maintaining several private source trees you should consider poushing your code upstream, so that others do the maintenance for you. The intention is to do so with my next project at work - but again it depends on how much time is left after sorting out all the low-level hard- and software bugs. I strongly recommend to include the time for the upstream-pushing into your next project schedule, right from the beginning. Consider it an important quality-assurance measure - where else do you get a large number of highly qualified experts reviewing your code _for_ _free_ ? Otherwise you might find yourself in a situation (again) where you will have to realize that we never get assigned enough time to do things right - but always to do them twice. 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 Use the Force, Luke. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kernel RSA signature ?
Dear Cyrille Francois, In message 61acdef60907220506s6d203bbfvea7bfc0420003...@mail.gmail.com you wrote: Tivoize : no. My interest is the security part, I want a secure boot for remotely upgrade my firmware. Verifying the SHA1 checksum of the loaded image should be sufficient, no? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Madness takes its toll. Please have exact change. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
Dear Robin Getz, In message 200907220826.58333.rg...@blackfin.uclinux.org you wrote: Well, you are aware that such a thing would need a TCP/IP stack, which is far beyond what we currently have in U-Boot support? Yes - I'm aware. My thoughts were to do something like what IBM and other suggestions were - use lwip. Well, yes. Use it. And have fun debugging funny network behaviour in real life networks. I must admit that I'm not really interested in this - I will not oppose any such patches as long as they are cleanly done and can be disabled without negative impact on exitsting code and systems, but whenever I will need TCP/IP, I will boot an OS instead. Much, much less effort - much faster, and much mor reliable. 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 Humans do claim a great deal for that particular emotion (love). -- Spock, The Lights of Zetar, stardate 5725.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Ask: How speed up read nand flash on lpc3250
CPU:LPC3250. Nand:K9F2G8U0A 256M the u-boot boot time now about 8s. the step to read linux kernel less 2M cost more or less 4s!! I want to make it faster~,but don't know how to. I try to change the memcpy function.but it's works not very well. so i want to via the maillist to find some help. thank you~~. --wizard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm: pRAM support?
Dear Holger, In message 4a671863.9040...@keymile.com you wrote: Well, if you want to do it Right (TM) that means we would take this chance and fix the ARM memory map, which implies to implement relocation to a dynamicalle detemined relocation address. can you explain this a little bit more in detail? Sounds like, that this is a larger chunk of work? The ARM port of U-Boot is seriously broken in several respects. When the ARMBoot project was forked off the PPCBoot (as it was caled by then), the implementors did not care for compatibility, and decided in fevour for minimal porting effort by giving up some features that we considered essential when designing PPCBoot / U-Boot on PowerPC. Just to give one example: on PowerPC, we normally use code to automatically determine the memory sizes on a board. One binary image of U-Boot can run unchanged on boards with for example different sizes of flash and RAM. U-Boot will always relocate itself to the end of the available RAM, thus leavin the maximum possible amount of RAM available for the user, for example to load Linux kernel and root file system. If we need to reserve memory, like for protected RAM, or for a frame buffer we can shared between U-Boot and Linux (so you can have a splash screen right after power-on which does not even flicker when Linux boots), or for a shared log buffer (so you can for example process U-Boots Power-On Self Test messages in Linux using standard syslog tools, or you can use U-Boot to dump the Linux kernel's crash messages post mortem in U-Boot or in Linux after rebooting the system), we just shift the relocation address for U-Boot down by the required amount. If you need a different amount of pRAM, just setenv the pram environment variable, and U-Boot will auto-adjust at the next reboot. On ARM, we don't do any such relocation, we link the image for a fixed address in RAM. So assum you have a board that can come with 32 MB or with 64 MB of RAM. You will have to link U-Boot close to the end of the 32 MB border - say to run at 31 MB. On a 64 MB board this means it sits right in the middle of availabel RAM - you have some 63+ MB of RAm free, but you cannot find more than 32 MB contiguous space. If you need pRAM or framebuffer or log buffer, you will have to configure sizes at compile time, and then you cannot change it at run time. Systems with variable RAM sizes will always suffer from the same restrictions like on the board with the smallest RAM configuration. And so on and on... That's why I think that the ARM memory map needs to be put from top on it's feet where we can make use of many of the nice features we have in U-Boot. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de One difference between a man and a machine is that a machine is quiet when well oiled. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] 85xx/86xx: Replace in8/out8 with in_8/out_8 on FSL boards
The pixis code used in8/out8 all over the place. Replace it with
in_8/out_8 macros.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
board/freescale/common/pixis.c| 78 ++---
board/freescale/mpc8536ds/mpc8536ds.c | 22 +---
board/freescale/mpc8544ds/mpc8544ds.c | 11 ++--
board/freescale/mpc8572ds/mpc8572ds.c | 22 +---
board/freescale/mpc8610hpcd/mpc8610hpcd.c | 25 +
board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c | 13 ++--
board/freescale/mpc8641hpcn/mpc8641hpcn.c | 15 +++--
board/freescale/p2020ds/p2020ds.c | 22 +---
8 files changed, 122 insertions(+), 86 deletions(-)
diff --git a/board/freescale/common/pixis.c b/board/freescale/common/pixis.c
index 4851f06..7210512 100644
--- a/board/freescale/common/pixis.c
+++ b/board/freescale/common/pixis.c
@@ -39,7 +39,8 @@ static ulong strfractoint(uchar *strptr);
*/
void pixis_reset(void)
{
-out8(PIXIS_BASE + PIXIS_RST, 0);
+ u8 *pixis_base = (u8 *)PIXIS_BASE;
+ out_8(pixis_base + PIXIS_RST, 0);
}
@@ -49,6 +50,7 @@ void pixis_reset(void)
int set_px_sysclk(ulong sysclk)
{
u8 sysclk_s, sysclk_r, sysclk_v, vclkh, vclkl, sysclk_aux;
+ u8 *pixis_base = (u8 *)PIXIS_BASE;
switch (sysclk) {
case 33:
@@ -107,10 +109,10 @@ int set_px_sysclk(ulong sysclk)
vclkh = (sysclk_s 5) | sysclk_r;
vclkl = sysclk_v;
- out8(PIXIS_BASE + PIXIS_VCLKH, vclkh);
- out8(PIXIS_BASE + PIXIS_VCLKL, vclkl);
+ out_8(pixis_base + PIXIS_VCLKH, vclkh);
+ out_8(pixis_base + PIXIS_VCLKL, vclkl);
- out8(PIXIS_BASE + PIXIS_AUX, sysclk_aux);
+ out_8(pixis_base + PIXIS_AUX, sysclk_aux);
return 1;
}
@@ -120,6 +122,7 @@ int set_px_mpxpll(ulong mpxpll)
{
u8 tmp;
u8 val;
+ u8 *pixis_base = (u8 *)PIXIS_BASE;
switch (mpxpll) {
case 2:
@@ -137,9 +140,9 @@ int set_px_mpxpll(ulong mpxpll)
return 0;
}
- tmp = in8(PIXIS_BASE + PIXIS_VSPEED1);
+ tmp = in_8(pixis_base + PIXIS_VSPEED1);
tmp = (tmp 0xF0) | (val 0x0F);
- out8(PIXIS_BASE + PIXIS_VSPEED1, tmp);
+ out_8(pixis_base + PIXIS_VSPEED1, tmp);
return 1;
}
@@ -149,6 +152,7 @@ int set_px_corepll(ulong corepll)
{
u8 tmp;
u8 val;
+ u8 *pixis_base = (u8 *)PIXIS_BASE;
switch ((int)corepll) {
case 20:
@@ -174,9 +178,9 @@ int set_px_corepll(ulong corepll)
return 0;
}
- tmp = in8(PIXIS_BASE + PIXIS_VSPEED0);
+ tmp = in_8(pixis_base + PIXIS_VSPEED0);
tmp = (tmp 0xE0) | (val 0x1F);
- out8(PIXIS_BASE + PIXIS_VSPEED0, tmp);
+ out_8(pixis_base + PIXIS_VSPEED0, tmp);
return 1;
}
@@ -184,27 +188,29 @@ int set_px_corepll(ulong corepll)
void read_from_px_regs(int set)
{
+ u8 *pixis_base = (u8 *)PIXIS_BASE;
u8 mask = 0x1C; /* COREPLL, MPXPLL, SYSCLK controlled by PIXIS */
- u8 tmp = in8(PIXIS_BASE + PIXIS_VCFGEN0);
+ u8 tmp = in_8(pixis_base + PIXIS_VCFGEN0);
if (set)
tmp = tmp | mask;
else
tmp = tmp ~mask;
- out8(PIXIS_BASE + PIXIS_VCFGEN0, tmp);
+ out_8(pixis_base + PIXIS_VCFGEN0, tmp);
}
void read_from_px_regs_altbank(int set)
{
+ u8 *pixis_base = (u8 *)PIXIS_BASE;
u8 mask = 0x04; /* FLASHBANK and FLASHMAP controlled by PIXIS */
- u8 tmp = in8(PIXIS_BASE + PIXIS_VCFGEN1);
+ u8 tmp = in_8(pixis_base + PIXIS_VCFGEN1);
if (set)
tmp = tmp | mask;
else
tmp = tmp ~mask;
- out8(PIXIS_BASE + PIXIS_VCFGEN1, tmp);
+ out_8(pixis_base + PIXIS_VCFGEN1, tmp);
}
#ifndef CONFIG_SYS_PIXIS_VBOOT_MASK
@@ -214,50 +220,54 @@ void read_from_px_regs_altbank(int set)
void clear_altbank(void)
{
u8 tmp;
+ u8 *pixis_base = (u8 *)PIXIS_BASE;
- tmp = in8(PIXIS_BASE + PIXIS_VBOOT);
+ tmp = in_8(pixis_base + PIXIS_VBOOT);
tmp = ~CONFIG_SYS_PIXIS_VBOOT_MASK;
- out8(PIXIS_BASE + PIXIS_VBOOT, tmp);
+ out_8(pixis_base + PIXIS_VBOOT, tmp);
}
void set_altbank(void)
{
u8 tmp;
+ u8 *pixis_base = (u8 *)PIXIS_BASE;
- tmp = in8(PIXIS_BASE + PIXIS_VBOOT);
+ tmp = in_8(pixis_base + PIXIS_VBOOT);
tmp |= CONFIG_SYS_PIXIS_VBOOT_MASK;
- out8(PIXIS_BASE + PIXIS_VBOOT, tmp);
+ out_8(pixis_base + PIXIS_VBOOT, tmp);
}
void set_px_go(void)
{
u8 tmp;
+ u8 *pixis_base = (u8 *)PIXIS_BASE;
- tmp = in8(PIXIS_BASE + PIXIS_VCTL);
+ tmp = in_8(pixis_base + PIXIS_VCTL);
tmp = tmp 0x1E; /* clear GO bit */
- out8(PIXIS_BASE + PIXIS_VCTL, tmp);
+ out_8(pixis_base + PIXIS_VCTL, tmp);
- tmp = in8(PIXIS_BASE + PIXIS_VCTL);
+ tmp = in_8(pixis_base + PIXIS_VCTL);
tmp = tmp | 0x01;
Re: [U-Boot] http client?
Dear jeffery palmer, In message blu127-dav686e79b5bf3a89693a9...@phx.gbl you wrote: We are looking for an http client now as well. Our major issue revolves around the download times for tftp. HTTP will probably not be much faster. Did you try using NFS? Our units automically update themselves inside of uboot giving us the most control over our firmware. The issue is that it takes 20 minutes via a DSL line in Africa to update our units. An http test showed that the same firmware downloads in 30 seconds. We have also added things like the blksize parameter to the uboot tftp client to get it down to 20 minutes, our original download times were ~50 minutes. Hm... but 20 minutes versus 30 seconds cannot be explained by TFTP versus HTTP alone. There must be other effects impacting your network traffic. Did you run any deeper analysis? 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 Never ascribe to malice that which can adequately be explained by stupidity. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] include/asm-ppc/immap_86xx.h
Hi.
I think there is a small offset bug in here.. unless there is an errata
that I have missed there should be no pad between srds1cr0,1. Anyone
know for sure?
--- a/include/asm-ppc/immap_86xx.h
+++ b/include/asm-ppc/immap_86xx.h
@@ -1240,7 +1240,7 @@ typedef struct ccsr_gur {
uintlbcdllcr; /* 0xe0e20 - LBC DLL control register */
charres13a[224];
uintsrds1cr0; /* 0xe0f04 - SerDes1 control register 0 */
- charres13b[4];
+ //char res13b[4];
uintsrds1cr1; /* 0xe0f08 - SerDes1 control register 1 */
charres14[24];
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
Hm... but 20 minutes versus 30 seconds cannot be explained by TFTP versus HTTP alone. There must be other effects impacting your network traffic. Did you run any deeper analysis? I'm sure it depends on network delays. TCP has the sliding window mechanism, so several packets can be in flight before you get a single ack. TFTP requires one ack for each data packet, doesn't it? If you have high delays, TCP is usually a win, even with relatively low bandwidth. Otherwise, we need a an UDP protocol that doesn't require individual ack. /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] include/asm-ppc/immap_86xx.h
On Jul 22, 2009, at 10:16 AM, David Updegraff wrote:
Hi.
I think there is a small offset bug in here.. unless there is an
errata
that I have missed there should be no pad between srds1cr0,1. Anyone
know for sure?
--- a/include/asm-ppc/immap_86xx.h
+++ b/include/asm-ppc/immap_86xx.h
@@ -1240,7 +1240,7 @@ typedef struct ccsr_gur {
uintlbcdllcr; /* 0xe0e20 - LBC DLL control
register */
charres13a[224];
uintsrds1cr0; /* 0xe0f04 - SerDes1 control
register 0 */
- charres13b[4];
+ //char res13b[4];
uintsrds1cr1; /* 0xe0f08 - SerDes1 control
register 1 */
charres14[24];
I'm guessing this is a bug in the manual, but will look into it.
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: Replace 4xx lowercase SPR references
Signed-off-by: Matthias Fuchs matthias.fu...@esd.eu
---
This patch replaces my patch from yesterday titled
[PATCH V2] ppc4xx: use SPRN_TCR macro instead of tcr
board/esd/pmc440/pmc440.c |2 +-
board/mpl/mip405/mip405.c |2 +-
board/mpl/pip405/pip405.c |2 +-
board/netstal/hcu5/hcu5.c |8 +-
board/netstal/hcu5/sdram.c |4 +-
board/netstal/mcu25/mcu25.c |2 +-
cpu/ppc4xx/cpu.c|8 +-
cpu/ppc4xx/cpu_init.c |2 +-
cpu/ppc4xx/interrupts.c | 18 ++--
cpu/ppc4xx/speed.c |3 +-
cpu/ppc4xx/start.S | 206 +-
include/asm-ppc/processor.h | 46 ++
include/ppc405.h| 55
include/ppc440.h| 93 ---
post/cpu/ppc4xx/fpu.c |6 +-
15 files changed, 178 insertions(+), 279 deletions(-)
diff --git a/board/esd/pmc440/pmc440.c b/board/esd/pmc440/pmc440.c
index 2ab944d..f22a1c2 100644
--- a/board/esd/pmc440/pmc440.c
+++ b/board/esd/pmc440/pmc440.c
@@ -142,7 +142,7 @@ int board_early_init_f(void)
reg |= CPR0_ICFG_RLI_MASK;
mtcpr(clk_icfg, reg);
- mtspr(dbcr0, 0x2000); /* do chip reset */
+ mtspr(SPRN_DBCR0, 0x2000); /* do chip reset */
}
/*
diff --git a/board/mpl/mip405/mip405.c b/board/mpl/mip405/mip405.c
index 24caa46..1738f54 100644
--- a/board/mpl/mip405/mip405.c
+++ b/board/mpl/mip405/mip405.c
@@ -688,7 +688,7 @@ int misc_init_r (void)
start=get_timer(0);
/* if MIP405 has booted from PCI, reset CCR0[24] as described in errata
PCI_18 */
if (mfdcr(strap) PSR_ROM_LOC)
- mtspr(ccr0, (mfspr(ccr0) ~0x80));
+ mtspr(SPRN_CCR0, (mfspr(SPRN_CCR0) ~0x80));
return (0);
}
diff --git a/board/mpl/pip405/pip405.c b/board/mpl/pip405/pip405.c
index f31a5e8..677437d 100644
--- a/board/mpl/pip405/pip405.c
+++ b/board/mpl/pip405/pip405.c
@@ -669,7 +669,7 @@ int misc_init_r (void)
/* if PIP405 has booted from PCI, reset CCR0[24] as described in errata
PCI_18 */
if (mfdcr(strap) PSR_ROM_LOC)
- mtspr(ccr0, (mfspr(ccr0) ~0x80));
+ mtspr(SPRN_CCR0, (mfspr(SPRN_CCR0) ~0x80));
return (0);
}
diff --git a/board/netstal/hcu5/hcu5.c b/board/netstal/hcu5/hcu5.c
index 6f4ec29..5eb33d3 100644
--- a/board/netstal/hcu5/hcu5.c
+++ b/board/netstal/hcu5/hcu5.c
@@ -89,8 +89,8 @@ int board_early_init_f(void)
/*
* Initiate system reset in debug control register DBCR
*/
- dbcr = mfspr(dbcr0);
- mtspr(dbcr0, dbcr | CHIP_RESET);
+ dbcr = mfspr(SPRN_DBCR0);
+ mtspr(SPRN_DBCR0, dbcr | CHIP_RESET);
}
mtsdr(SDR0_CP440, 0x0EAAEA02); /* [Nto1] = 1*/
#endif
@@ -307,14 +307,14 @@ int misc_init_r(void)
/* We cannot easily enable trace before, as there are other
* routines messing around with sdr0_pfc1. And I do not need it.
*/
- if (mfspr(dbcr0) 0x8000) {
+ if (mfspr(SPRN_DBCR0) 0x8000) {
/* External debugger alive
* enable trace facilty for Lauterbach
* CCR0[DTB]=0 Enable broadcast of trace information
* SDR0_PFC0[TRE] Trace signals are enabled instead of
* GPIO49-63
*/
- mtspr(ccr0, mfspr(ccr0) ~ (CCR0_DTB));
+ mtspr(SPRN_CCR0, mfspr(SPRN_CCR0) ~ (CCR0_DTB));
mtsdr(SDR0_PFC0, sdr0_pfc1 | SDR0_PFC0_TRE_ENABLE);
}
return 0;
diff --git a/board/netstal/hcu5/sdram.c b/board/netstal/hcu5/sdram.c
index f59bd7d..5c2ec35 100644
--- a/board/netstal/hcu5/sdram.c
+++ b/board/netstal/hcu5/sdram.c
@@ -144,7 +144,7 @@ static void program_ecc(unsigned long start_address,
unsigned long num_bytes)
u32 *magicPtr;
u32 magic;
- if ((mfspr(dbcr0) 0x8000) == 0) {
+ if ((mfspr(SPRN_DBCR0) 0x8000) == 0) {
/* only if no external debugger is alive!
* Check whether vxWorks is using EDR logging, if yes zero
* also PostMortem and user reserved memory
@@ -182,7 +182,7 @@ static void program_ecc(unsigned long start_address,
unsigned long num_bytes)
* If not done, then we could get an interrupt later on when
* exceptions are enabled.
*/
- mtspr(mcsr, mfspr(mcsr));
+ mtspr(SPRN_MCSR, mfspr(SPRN_MCSR));
/* Set 'int_mask' parameter to functionnal value */
mfsdram(DDR0_01, val);
diff --git a/board/netstal/mcu25/mcu25.c b/board/netstal/mcu25/mcu25.c
index 66ed95f..67c1b0b 100644
--- a/board/netstal/mcu25/mcu25.c
+++ b/board/netstal/mcu25/mcu25.c
@@ -77,7 +77,7 @@ int board_early_init_f (void)
out32(GPIO0_OR, CONFIG_SYS_GPIO0_OR );
out32(GPIO0_TCR,
Re: [U-Boot] Support for Calao USB A9263 board based on AT91SAM9263 CPU
The Calao USB A9263 board is a board manufactured and sold by Calao Systems http://www.calao-systems.com. Its components are very similar to the AT91SAM9263EK board, so its configuration is based on the configuration of this board. There are however some differences: different clocks, no LCD, etc. Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com --- This new version includes the following changes : * Copyright header on config.mk, by suggestion of Peter Tyser * Updated copyright informations in all new files * Use get_ram_size(), as suggested by Wolfgang Denk * Do some cleanup of useless comments, re-indent definitions to avoid long lines, etc. * Add entry to MAINTAINERS I'm still including the definition of ROUND() in the board configuration file, since Wolfgang's patch has yet been merged to the Git tree (and I don't think sending a patch that doesn't compile against the current Git tree is useful). MAINTAINERS |4 MAKEALL |1 Makefile |3 board/calao/usb-a9263/Makefile| 58 +++ board/calao/usb-a9263/config.mk | 24 board/calao/usb-a9263/partition.c | 38 +++ board/calao/usb-a9263/usb-a9263.c | 194 ++ include/configs/usb-a9263.h | 185 8 files changed, 507 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 575a7ec..5c37647 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -624,6 +624,10 @@ Peter Pearse peter.pea...@arm.com versatile ARM926EJ-S versatile ARM926EJ-S +Thomas Petazzoni thomas.petazz...@free-electrons.com + + usb-a9263 ARM926EJS (AT91SAM9263 SoC) + Dave Peverley dpever...@mpc-data.co.uk omap730p2 ARM926EJS diff --git a/MAKEALL b/MAKEALL index 020ff73..452d09a 100755 --- a/MAKEALL +++ b/MAKEALL @@ -599,6 +599,7 @@ LIST_at91= \ m501sk \ pm9261 \ pm9263 \ + usb9263 \ # diff --git a/Makefile b/Makefile index 4fe3232..e484204 100644 --- a/Makefile +++ b/Makefile @@ -2807,6 +2807,9 @@ at91sam9g45ekes_config: unconfig pm9263_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm926ejs pm9263 ronetix at91 +usb_a9263_config : unconfig + $(MKCONFIG) -a usb-a9263 arm arm926ejs usb-a9263 calao at91 + ## ARM Integrator boards - see doc/README-integrator for more info. integratorap_config\ diff --git a/board/calao/usb-a9263/Makefile b/board/calao/usb-a9263/Makefile new file mode 100644 index 000..ec79872 --- /dev/null +++ b/board/calao/usb-a9263/Makefile @@ -0,0 +1,58 @@ +# +# (C) Copyright 2003-2008 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# (C) Copyright 2008 +# Stelian Pop stelian@leadtechdesign.com +# Lead Tech Design www.leadtechdesign.com +# +# (C) Copyright 2009 +# Thomas Petazzoni, Free Electrons, thomas.petazz...@free-electrons.com +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS-y += usb-a9263.o +COBJS-$(CONFIG_HAS_DATAFLASH) += partition.o + +SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS-y)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/calao/usb-a9263/config.mk b/board/calao/usb-a9263/config.mk new file mode 100644 index 000..2724a7d --- /dev/null +++ b/board/calao/usb-a9263/config.mk @@ -0,0 +1,24 @@ +# +# (C) Copyright 2009 +# Thomas Petazzoni, Free Electrons,
Re: [U-Boot] [PATCH 1/2] xes: Increase CONFIG_SYS_BOOTM_LEN to 16MB
On Jul 21, 2009, at 1:51 PM, Peter Tyser wrote: Increasing CONFIG_SYS_BOOTM_LEN from 8 MB to 16 MB is necessary to support uncompressing images larger than 8 MB when using the bootm command. Note that recent Linux kernels for the 85xx and 86xx map greater than 16MB of memory on bootup, but we use 16MB to maintain compatibility with older Linux kernels for now. Signed-off-by: Nate Case nc...@xes-inc.com Signed-off-by: Peter Tyser pty...@xes-inc.com --- Hi Kumar, I just realized I never submitted these 2 patches during the merge window. They aren't super critical so feel free to skip them for the upcoming release if you'd prefer and I'll resubmit them later. Thanks, Peter applied - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] xpedite5370: Enable NAND command support
On Jul 21, 2009, at 1:51 PM, Peter Tyser wrote: Use the MPC8572's eLBC to access 1 GB (or greater) onboard NAND flash via the 'nand' command. Previously, the XPedite5370's NAND chip selects were properly configured, but NAND support was not enabled. Signed-off-by: Peter Tyser pty...@xes-inc.com --- include/configs/XPEDITE5370.h |9 - 1 files changed, 8 insertions(+), 1 deletions(-) applied - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: Replace 4xx lowercase SPR references
Dear Matthias Fuchs, In message 200907221727.56402.matthias.fu...@esd.eu you wrote: Signed-off-by: Matthias Fuchs matthias.fu...@esd.eu ... board/esd/pmc440/pmc440.c |2 +- board/mpl/mip405/mip405.c |2 +- board/mpl/pip405/pip405.c |2 +- board/netstal/hcu5/hcu5.c |8 +- board/netstal/hcu5/sdram.c |4 +- board/netstal/mcu25/mcu25.c |2 +- cpu/ppc4xx/cpu.c|8 +- cpu/ppc4xx/cpu_init.c |2 +- cpu/ppc4xx/interrupts.c | 18 ++-- cpu/ppc4xx/speed.c |3 +- cpu/ppc4xx/start.S | 206 +- include/asm-ppc/processor.h | 46 ++ include/ppc405.h| 55 include/ppc440.h| 93 --- post/cpu/ppc4xx/fpu.c |6 +- 15 files changed, 178 insertions(+), 279 deletions(-) I understand the include/asm-ppc/processor.h changes are in sync with the Linux version of this file? If so: Acked-by: Wolfgang Denk w...@denx.de 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 Death, when unnecessary, is a tragic thing. -- Flint, Requiem for Methuselah, stardate 5843.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 85xx: Fix mapping of 0xfffffxxx when CONFIG_MP
Hi Kumar, I understand what the patch does. It just removes the capability of soft-resetting a core back into the boot translation code. I understand your problem I'm just not keen on solving it by completely disabling boot translation. We had a similar memory map and I moved away from it because of the reset vector issues. Additionally, things like 4G of memory also start creeping up. I'm not super familiar with how the MP support in U-Boot is used. Would you be resetting a secondary core for debug purposes? Or is there an example of when you'd reset one in normal operation? I thought normal operation was to use the cpu release command, or to let the OS manually take the secondary cores out of their wait loops. What if I spruced up cpu_reset() to temporarily re-enable boot page translation, then disabled it again? (And maybe re-initialized the cpus MP table so that it could properly ack the primary core similar to in pq3_mp_up(). It seems somewhat dirty to me to constantly keep boot page translation enabled, even when its not needed. Especially since it would require us to change our memory map, environment variable scripts, documentation, etc on all our boards:) I'd be happy to look into an alternate workaround if you have an idea for a cleaner implementation. The idea is after u-boot if you soft-reset a core that it would go back into the spin table code. U-boot is long gone at this point. Are there common scenarios where a core would be reset after its already booted an OS? If an OS did need to soft-reset a secondary core, shouldn't the OS be responsible for ensuring boot page translation is enabled, its translating to the proper location, etc? For example, I imagine non-Linux OSes bring up secondary cores in different manners and some wouldn't re-utilize U-Boot's boot page code located in SDRAM at all, thus they wouldn't want the boot page translation always enabled. It just seems less than ideal to have a chunk of memory space that somewhat magically accesses a completely different, unintuitive address space. Someone else ran into the same issue already: http://www.mail-archive.com/u-boot@lists.denx.de/msg08361.html I realize there's a tradeoff between keeping the translation enabled vs disabled, I'm just not familiar with how OSes utilize the secondary cores to know what the downsides of disabling translation are... Any feedback on my last email above, or is disabling boot page translation just a no-go? Or is there an more ideal alternative? I really don't want to change up the memory map on all our Freescale boards, documentation, dts files, etc because of an optional 4KB chunk of memory space:) I'm more than willing to implement a different workaround if it means we can keep our current memory map... Thanks, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Use do_div from div64.h for vsprintf
Use do_div from div64.h for vsprintf in case of 64bit division.
For 32bit division, do_div from div64.h can't be used as it
needs a 64bit parameter.
Signed-off-by: Dirk Behme dirk.be...@googlemail.com
CC: Simon Kagstrom simon.kagst...@netinsight.net
---
This patch replaces first version
http://lists.denx.de/pipermail/u-boot/2009-July/055599.html
due to compiler warnings
http://lists.denx.de/pipermail/u-boot/2009-July/056994.html
lib_generic/vsprintf.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
Index: u-boot-main/lib_generic/vsprintf.c
===
--- u-boot-main.orig/lib_generic/vsprintf.c
+++ u-boot-main/lib_generic/vsprintf.c
@@ -22,18 +22,19 @@ extern int do_reset (cmd_tbl_t *cmdtp, i
#endif
#ifdef CONFIG_SYS_64BIT_VSPRINTF
+#include div64.h
# define NUM_TYPE long long
#else
# define NUM_TYPE long
-#endif
-#define noinline __attribute__((noinline))
-
#define do_div(n, base) ({ \
unsigned int __res; \
__res = ((unsigned NUM_TYPE) n) % base; \
n = ((unsigned NUM_TYPE) n) / base; \
__res; \
})
+#endif
+#define noinline __attribute__((noinline))
+
const char hex_asc[] = 0123456789abcdef;
#define hex_asc_lo(x) hex_asc[((x) 0x0f)]
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Support for Calao USB A9263 board based on AT91SAM9263 CPU
Hi Thomas, Just a note, but its nice when you resend patches to include the string [PATCH vX] where X=2, 3, etc. That way whoever applies your patch can tell which email contains the latest iteration of it. This new version includes the following changes : * Copyright header on config.mk, by suggestion of Peter Tyser * Updated copyright informations in all new files * Use get_ram_size(), as suggested by Wolfgang Denk * Do some cleanup of useless comments, re-indent definitions to avoid long lines, etc. * Add entry to MAINTAINERS I'm still including the definition of ROUND() in the board configuration file, since Wolfgang's patch has yet been merged to the Git tree (and I don't think sending a patch that doesn't compile against the current Git tree is useful). That's just plain bad luck, Wolfgang just merged the ROUND() commit a few hours ago:) http://git.denx.de/?p=u-boot.git;a=commit;h=70ebf31633f372a24505e47846b2628e8435ea37 Its up to the ARM maintainer to determine if having the ROUND() defined locally is a show stopper. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
The ACK delays are exactly what cause the extremely long download times. There are approx 16,000 ACK cycles for my 8MB image on a 512K blksize. I upped this to 1432 to stay under the MTU which cut the ACK cycles by three, but still, on a 180ms round trip time the math is simple. 8MB/1432bytes=5580 ACK's * 180 ms = 17 minutes. There are good reasons to use TCP/IP for doing the updates. Some of our reasons are: - Firewall/NAT/filter transversals - Passing arguments and status information to our update server, such as serial numbers, status's, etc. - Receiving uboot specific commands via update server - Error checking in TCP streams vs UDP (Alreading using checksums, but another layer of reliability wouldn't hurt) NFS is still be stuck to the same rules as TFTP so it's not a very good option. We already have equipment using UIP (UDP + TCP) which works great and is extremely small at ~30K of compiled code. I am not yet familiar with the underlying network code in uboot, but is it entirely written from the ground up or based off of another project? There are quite a few additions you can achieve with a TCP stack but of course it needs to be very clean and well tested. Jeffery Palmer Project Development -Original Message- From: rubini-l...@gnudd.com [mailto:rubini-l...@gnudd.com] Sent: Wednesday, July 22, 2009 11:23 AM To: w...@denx.de Cc: jefferypal...@hotmail.com; u-boot@lists.denx.de Subject: Re: [U-Boot] http client? Hm... but 20 minutes versus 30 seconds cannot be explained by TFTP versus HTTP alone. There must be other effects impacting your network traffic. Did you run any deeper analysis? I'm sure it depends on network delays. TCP has the sliding window mechanism, so several packets can be in flight before you get a single ack. TFTP requires one ack for each data packet, doesn't it? If you have high delays, TCP is usually a win, even with relatively low bandwidth. Otherwise, we need a an UDP protocol that doesn't require individual ack. /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Support for Calao USB A9263 board based on AT91SAM9263 CPU
Hi, Le Wed, 22 Jul 2009 10:57:09 -0500, Peter Tyser pty...@xes-inc.com a écrit : Hi Thomas, Just a note, but its nice when you resend patches to include the string [PATCH vX] where X=2, 3, etc. That way whoever applies your patch can tell which email contains the latest iteration of it. Ok. That's just plain bad luck, Wolfgang just merged the ROUND() commit a few hours ago:) http://git.denx.de/?p=u-boot.git;a=commit;h=70ebf31633f372a24505e47846b2628e8435ea37 Yes, but it also doesn't seem to work (yet): http://lists.denx.de/pipermail/u-boot/2009-July/057230.html Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Support for Calao USB A9263 board based on AT91SAM9263 CPU
On Wed, Jul 22, 2009 at 10:57:09AM -0500, Peter Tyser wrote : Hi Thomas, Just a note, but its nice when you resend patches to include the string [PATCH vX] where X=2, 3, etc. That way whoever applies your patch can tell which email contains the latest iteration of it. This new version includes the following changes : * Copyright header on config.mk, by suggestion of Peter Tyser * Updated copyright informations in all new files * Use get_ram_size(), as suggested by Wolfgang Denk * Do some cleanup of useless comments, re-indent definitions to avoid long lines, etc. * Add entry to MAINTAINERS I'm still including the definition of ROUND() in the board configuration file, since Wolfgang's patch has yet been merged to the Git tree (and I don't think sending a patch that doesn't compile against the current Git tree is useful). That's just plain bad luck, Wolfgang just merged the ROUND() commit a few hours ago:) http://git.denx.de/?p=u-boot.git;a=commit;h=70ebf31633f372a24505e47846b2628e8435ea37 Which consequently made all those boards fail to compile. See http://lists.denx.de/pipermail/u-boot/2009-July/057230.html for further details Cheers, -- Albin Tonnerre, Free Electrons Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Support for Calao USB A9263 board based on AT91SAM9263 CPU
On Wed, 2009-07-22 at 18:04 +0200, Thomas Petazzoni wrote: Hi, Le Wed, 22 Jul 2009 10:57:09 -0500, Peter Tyser pty...@xes-inc.com a écrit : Hi Thomas, Just a note, but its nice when you resend patches to include the string [PATCH vX] where X=2, 3, etc. That way whoever applies your patch can tell which email contains the latest iteration of it. Ok. That's just plain bad luck, Wolfgang just merged the ROUND() commit a few hours ago:) http://git.denx.de/?p=u-boot.git;a=commit;h=70ebf31633f372a24505e47846b2628e8435ea37 Yes, but it also doesn't seem to work (yet): http://lists.denx.de/pipermail/u-boot/2009-July/057230.html I see, well I'll gracefully bow out of this conversation now:) Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-mpc85xx (updated)
(This has the updated versions of the 'bank' patches based on comments from the list) - k The following changes since commit d4abc757c26c531293f5bbc4262ade44a317eec9: Peter Tyser (1): Move api_examples to examples/api are available in the git repository at: git://git.denx.de/u-boot-mpc85xx.git master Kumar Gala (4): 85xx: Bump up the BOOTMAP to 16M on FSL 85xx boards 86xx: Report which bank of NOR flash we are booting from on MPC8641HPCN 85xx: Report which bank of NOR flash we are booting from on FSL boards 85xx/86xx: Replace in8/out8 with in_8/out_8 on FSL boards Peter Tyser (8): 86xx: Rename ccsr_ddr's sdram_mode_1, sdram_cfg_1 fields xes: Remove 8xxx board_add_ram_info() function tqm85xx: Remove board_add_ram_info() 85xx, 86xx: Add common board_add_ram_info() xpedite5200,5370: Use buffered NOR flash writes xpedite5370: Fix I2C GPIO initialization typo xes: Increase CONFIG_SYS_BOOTM_LEN to 16MB xpedite5370: Enable NAND command support Roy Zang (1): 85xx: Add pci/pcie E1000 ethernet support for MPC8544DS and MPC8536 boards board/freescale/common/pixis.c| 78 +++- board/freescale/mpc8536ds/mpc8536ds.c | 61 +--- board/freescale/mpc8544ds/mpc8544ds.c | 27 +--- board/freescale/mpc8572ds/mpc8572ds.c | 48 ++--- board/freescale/mpc8610hpcd/mpc8610hpcd.c | 29 board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c | 13 ++-- board/freescale/mpc8641hpcn/mpc8641hpcn.c | 39 +++ board/freescale/p2020ds/p2020ds.c | 45 +--- board/sbc8641d/sbc8641d.c | 12 ++-- board/tqc/tqm85xx/sdram.c | 33 + board/xes/common/fsl_8xxx_ddr.c | 53 -- board/xes/xpedite5370/xpedite5370.c |4 +- cpu/mpc86xx/ddr-8641.c|4 +- cpu/mpc8xxx/ddr/main.c| 43 +--- cpu/mpc8xxx/ddr/util.c| 96 + include/asm-ppc/immap_86xx.h |4 +- include/configs/MPC8536DS.h | 12 +++- include/configs/MPC8540ADS.h |4 +- include/configs/MPC8541CDS.h |4 +- include/configs/MPC8544DS.h |7 ++- include/configs/MPC8548CDS.h |4 +- include/configs/MPC8555CDS.h |4 +- include/configs/MPC8560ADS.h |4 +- include/configs/MPC8568MDS.h |4 +- include/configs/MPC8569MDS.h |4 +- include/configs/MPC8572DS.h |9 ++- include/configs/MPC8641HPCN.h |2 + include/configs/P2020DS.h |9 ++- include/configs/XPEDITE5170.h |1 + include/configs/XPEDITE5200.h |2 + include/configs/XPEDITE5370.h | 11 +++- 31 files changed, 402 insertions(+), 268 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Update the mtd driver name in bootargs for at91-based boards
The name of the atmel nand driver in the kernel changed from at91_nand to atmel_nand back in June 2008, but the at91-based boards config files still refer to at91_nand. This patch updates them with the new name Signed-off-by: Albin Tonnerre albin.tonne...@free-electrons.com --- include/configs/at91cap9adk.h |4 ++-- include/configs/at91sam9260ek.h|6 +++--- include/configs/at91sam9261ek.h|6 +++--- include/configs/at91sam9263ek.h|4 ++-- include/configs/at91sam9m10g45ek.h |4 ++-- include/configs/at91sam9rlek.h |4 ++-- include/configs/pm9261.h |4 ++-- include/configs/pm9263.h |4 ++-- 8 files changed, 18 insertions(+), 18 deletions(-) diff --git a/include/configs/at91cap9adk.h b/include/configs/at91cap9adk.h index 0ef3554..cc194d8 100644 --- a/include/configs/at91cap9adk.h +++ b/include/configs/at91cap9adk.h @@ -172,7 +172,7 @@ #define CONFIG_BOOTARGSconsole=ttyS0,115200 \ root=/dev/mtdblock1 \ mtdparts=physmap-flash.0:-(nor); \ - at91_nand:-(root) \ + atmel_nand:-(root)\ rw rootfstype=jffs2 #else @@ -188,7 +188,7 @@ root=/dev/mtdblock4 \ mtdparts=physmap-flash.0:16k(bootstrap)ro,\ 16k(env),224k(uboot)ro,-(linux); \ - at91_nand:-(root) \ + atmel_nand:-(root)\ rw rootfstype=jffs2 #endif diff --git a/include/configs/at91sam9260ek.h b/include/configs/at91sam9260ek.h index 6cee593..3507de2 100644 --- a/include/configs/at91sam9260ek.h +++ b/include/configs/at91sam9260ek.h @@ -163,7 +163,7 @@ #define CONFIG_BOOTCOMMAND cp.b 0xC0042000 0x2200 0x21; bootm #define CONFIG_BOOTARGSconsole=ttyS0,115200 \ root=/dev/mtdblock0 \ - mtdparts=at91_nand:-(root)\ + mtdparts=atmel_nand:-(root) \ rw rootfstype=jffs2 #elif CONFIG_SYS_USE_DATAFLASH_CS1 @@ -177,7 +177,7 @@ #define CONFIG_BOOTCOMMAND cp.b 0xD0042000 0x2200 0x21; bootm #define CONFIG_BOOTARGSconsole=ttyS0,115200 \ root=/dev/mtdblock0 \ - mtdparts=at91_nand:-(root)\ + mtdparts=atmel_nand:-(root) \ rw rootfstype=jffs2 #else /* CONFIG_SYS_USE_NANDFLASH */ @@ -190,7 +190,7 @@ #define CONFIG_BOOTCOMMAND nand read 0x2200 0xA 0x20; bootm #define CONFIG_BOOTARGSconsole=ttyS0,115200 \ root=/dev/mtdblock5 \ - mtdparts=at91_nand:128k(bootstrap)ro, \ + mtdparts=atmel_nand:128k(bootstrap)ro, \ 256k(uboot)ro,128k(env1)ro, \ 128k(env2)ro,2M(linux),-(root)\ rw rootfstype=jffs2 diff --git a/include/configs/at91sam9261ek.h b/include/configs/at91sam9261ek.h index 3d108ab..f86698f 100644 --- a/include/configs/at91sam9261ek.h +++ b/include/configs/at91sam9261ek.h @@ -181,7 +181,7 @@ #define CONFIG_BOOTCOMMAND cp.b 0xC0042000 0x2200 0x21; bootm #define CONFIG_BOOTARGSconsole=ttyS0,115200 \ root=/dev/mtdblock0 \ - mtdparts=at91_nand:-(root)\ + mtdparts=atmel_nand:-(root) \ rw rootfstype=jffs2 #elif CONFIG_SYS_USE_DATAFLASH_CS3 @@ -195,7 +195,7 @@ #define CONFIG_BOOTCOMMAND cp.b 0xD0042000 0x2200 0x21; bootm #define CONFIG_BOOTARGSconsole=ttyS0,115200 \ root=/dev/mtdblock0 \ - mtdparts=at91_nand:-(root)\ + mtdparts=atmel_nand:-(root) \ rw rootfstype=jffs2 #else /* CONFIG_SYS_USE_NANDFLASH */ @@ -208,7 +208,7 @@ #define CONFIG_BOOTCOMMAND nand read 0x2200 0xA 0x20; bootm #define CONFIG_BOOTARGSconsole=ttyS0,115200 \ root=/dev/mtdblock5 \ -
[U-Boot] [RFC] arm/board.c: avoid ifdef using weak default functions
From: Alessandro Rubini rub...@gnudd.com
While it's a matter of personal taste, I prefer to avoid ifdef when
possible. For example, I don't like to add BOARD_LATE_INIT in the
config file just to have my board_late_init() function called.
This patch (not meant to be applied mainstram, jsut for discussion)
tries to simplify and make more readable the code in lib_arm/board.c.
If this is considered useful it can be done more seriously to all
platforms, and allow over time to remove defines in the class of
BOARD_LATE_INIT.
A serious reordering will definitely need more time, and this is just
a quick hack to show the idea; some things are suboptimal like the
arm_pci_init() thing which has to remain an ifdef and should be fixed
in a different way (I think all init function should return int
and print their own messages, to simplify this factoring out, but again
it's a matter of personal taste).
About the use of weak, I first converted .a to .o, but then found it
works nonetheless, and led functions are already weak ones in this file.
Is the idea worth pursuing? Or does it conflich with other work in
progress?
---
lib_arm/board.c | 62 ++
1 files changed, 30 insertions(+), 32 deletions(-)
diff --git a/lib_arm/board.c b/lib_arm/board.c
index a44d308..50fe74b 100644
--- a/lib_arm/board.c
+++ b/lib_arm/board.c
@@ -61,10 +61,26 @@ DECLARE_GLOBAL_DATA_PTR;
ulong monitor_flash_len;
-#ifdef CONFIG_HAS_DATAFLASH
-extern int AT91F_DataflashInit(void);
-extern void dataflash_print_info(void);
-#endif
+/* Some functions may be there or not. Use a weak placeholder to avoid ifdef */
+int __normal_nop(void) { return 0; }
+void __void_nop(void) {}
+
+/* parts of init_sequence that may not be present */
+int arch_cpu_init(void) __attribute__((weak, alias(__normal_nop)));
+int interrupt_init(void) __attribute__((weak, alias(__normal_nop)));
+int print_cpuinfo(void) __attribute__((weak, alias(__normal_nop)));
+int checkboard(void) __attribute__((weak, alias(__normal_nop)));
+
+/* other functions that appear later and depend on config items */
+int AT91F_DataflashInit(void) __attribute__((weak, alias(__normal_nop)));
+void dataflash_print_info(void) __attribute__((weak, alias(__void_nop)));
+void serial_initialize(void) __attribute__((weak, alias(__void_nop)));
+void onenand_init(void) __attribute__((weak, alias(__void_nop)));
+int drv_vfd_init(void) __attribute__((weak, alias(__normal_nop)));
+void api_init(void) __attribute__((weak, alias(__void_nop)));
+int arch_misc_init(void) __attribute__((weak, alias(__normal_nop)));
+int misc_init_r(void) __attribute__((weak, alias(__normal_nop)));
+int board_late_init(void) __attribute__((weak, alias(__normal_nop)));
#ifndef CONFIG_IDENT_STRING
#define CONFIG_IDENT_STRING
@@ -227,6 +243,11 @@ static int init_func_i2c (void)
puts (ready\n);
return (0);
}
+#else
+static int init_func_i2c (void)
+{
+ return 0;
+}
#endif
#if defined(CONFIG_CMD_PCI) || defined (CONFIG_PCI)
@@ -236,6 +257,11 @@ static int arm_pci_init(void)
pci_init();
return 0;
}
+#else
+static int arm_pci_init(void)
+{
+ return 0;
+}
#endif /* CONFIG_CMD_PCI || CONFIG_PCI */
/*
@@ -266,32 +292,20 @@ typedef int (init_fnc_t) (void);
int print_cpuinfo (void);
init_fnc_t *init_sequence[] = {
-#if defined(CONFIG_ARCH_CPU_INIT)
arch_cpu_init, /* basic arch cpu dependent setup */
-#endif
board_init, /* basic board dependent setup */
-#if defined(CONFIG_USE_IRQ)
interrupt_init, /* set up exceptions */
-#endif
timer_init, /* initialize timer */
env_init, /* initialize environment */
init_baudrate, /* initialze baudrate settings */
serial_init,/* serial communications setup */
console_init_f, /* stage 1 init of console */
display_banner, /* say that we are here */
-#if defined(CONFIG_DISPLAY_CPUINFO)
print_cpuinfo, /* display cpu info (and speed) */
-#endif
-#if defined(CONFIG_DISPLAY_BOARDINFO)
checkboard, /* display board info */
-#endif
-#if defined(CONFIG_HARD_I2C) || defined(CONFIG_SOFT_I2C)
init_func_i2c,
-#endif
dram_init, /* configure available RAM banks */
-#if defined(CONFIG_CMD_PCI) || defined (CONFIG_PCI)
arm_pci_init,
-#endif
display_dram_config,
NULL,
};
@@ -365,26 +379,18 @@ void start_armboot (void)
nand_init();/* go init the NAND */
#endif
-#if defined(CONFIG_CMD_ONENAND)
onenand_init();
-#endif
-#ifdef CONFIG_HAS_DATAFLASH
AT91F_DataflashInit();
dataflash_print_info();
-#endif
/* initialize environment */
env_relocate ();
-#ifdef CONFIG_VFD
/* must do this after the framebuffer is allocated */
drv_vfd_init();
-#endif /* CONFIG_VFD */
-#ifdef
Re: [U-Boot] http client?
On Wed, 2009-07-22 at 12:00 -0400, jeffery palmer wrote: There are quite a few additions you can achieve with a TCP stack but of course it needs to be very clean and well tested. http://www.sics.se/~adam/uip/uip-1.0-refman/ I used it before on a small arm platform (small =16k ram) and used it for a tftp server and http server. Have no idea about performance I was only interested in it working at all so never tried to measure anything or tune any parameters. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Less verbose output when loading vxworks 6.x images
Loading vxWorks 5.x images resulted just into 3 or 4 lines of output.
With vxWorks 6.x and the new GCC it emits about 30 lines, which is
far too noisy in my opinion.
Signed-off-by: Niklaus Giger niklaus.gi...@member.fsf.org
---
common/cmd_elf.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/common/cmd_elf.c b/common/cmd_elf.c
index abec7dd..0842ce9 100644
--- a/common/cmd_elf.c
+++ b/common/cmd_elf.c
@@ -286,6 +286,7 @@ unsigned long load_elf_image (unsigned long addr)
continue;
}
+#ifdef DEBUG
if (strtab) {
printf (%sing %s @ 0x%08lx (%ld bytes)\n,
(shdr-sh_type == SHT_NOBITS) ?
@@ -294,6 +295,7 @@ unsigned long load_elf_image (unsigned long addr)
(unsigned long) shdr-sh_addr,
(long) shdr-sh_size);
}
+#endif
if (shdr-sh_type == SHT_NOBITS) {
memset ((void *)shdr-sh_addr, 0, shdr-sh_size);
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
On Wed 22 Jul 2009 10:04, jeffery palmer pondered: We are looking for an http client now as well. Our major issue revolves around the download times for tftp. Can Volkmar Uhlig kindly provide the patches? Our units automically update themselves inside of uboot giving us the most control over our firmware. The issue is that it takes 20 minutes via a DSL line in Africa to update our units. An http test showed that the same firmware downloads in 30 seconds. We have also added things like the blksize parameter to the uboot tftp client to get it down to 20 minutes, our original download times were ~50 minutes. Hmm -- I'm assuming that is http://www.faqs.org/rfcs/rfc1783.html ? Do you have a patch to send - or that I can clean up and submit? We would like to work to integrate or add the necessary http client functions to achieve this. If there are no patches obtainable, is anyone interested in working on this with us? Yes - Although it sounds like your schedule is more immediate than mine... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Less verbose output when loading vxworks 6.x images
On Wed 22 Jul 2009 15:32, Niklaus Giger pondered:
Loading vxWorks 5.x images resulted just into 3 or 4 lines of output.
With vxWorks 6.x and the new GCC it emits about 30 lines, which is
far too noisy in my opinion.
Signed-off-by: Niklaus Giger niklaus.gi...@member.fsf.org
---
common/cmd_elf.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/common/cmd_elf.c b/common/cmd_elf.c
index abec7dd..0842ce9 100644
--- a/common/cmd_elf.c
+++ b/common/cmd_elf.c
@@ -286,6 +286,7 @@ unsigned long load_elf_image (unsigned long addr)
continue;
}
+#ifdef DEBUG
if (strtab) {
printf (%sing %s @ 0x%08lx (%ld bytes)\n,
(shdr-sh_type == SHT_NOBITS) ?
@@ -294,6 +295,7 @@ unsigned long load_elf_image (unsigned long addr)
(unsigned long) shdr-sh_addr,
(long) shdr-sh_size);
}
+#endif
if (shdr-sh_type == SHT_NOBITS) {
memset ((void *)shdr-sh_addr, 0,
shdr-sh_size);
its better to remove the ifdef, and replace the printf() with debug() (IMHO).
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
Robin Getz wrote: On Wed 22 Jul 2009 10:04, jeffery palmer pondered: We are looking for an http client now as well. Our major issue revolves around the download times for tftp. Can Volkmar Uhlig kindly provide the patches? Our units automically update themselves inside of uboot giving us the most control over our firmware. The issue is that it takes 20 minutes via a DSL line in Africa to update our units. An http test showed that the same firmware downloads in 30 seconds. We have also added things like the blksize parameter to the uboot tftp client to get it down to 20 minutes, our original download times were ~50 minutes. Hmm -- I'm assuming that is http://www.faqs.org/rfcs/rfc1783.html ? Do you have a patch to send - or that I can clean up and submit? Requesting a bigger blocksize is already implemented and should work if the server supports it. It's been a while since I used this, but it was added along with support for multicast TFTP, probably about a year ago. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
On Wed 22 Jul 2009 16:32, Ben Warren pondered: Robin Getz wrote: On Wed 22 Jul 2009 10:04, jeffery palmer pondered: We are looking for an http client now as well. Our major issue revolves around the download times for tftp. Can Volkmar Uhlig kindly provide the patches? Our units automically update themselves inside of uboot giving us the most control over our firmware. The issue is that it takes 20 minutes via a DSL line in Africa to update our units. An http test showed that the same firmware downloads in 30 seconds. We have also added things like the blksize parameter to the uboot tftp client to get it down to 20 minutes, our original download times were ~50 minutes. Hmm -- I'm assuming that is http://www.faqs.org/rfcs/rfc1783.html ? Do you have a patch to send - or that I can clean up and submit? Requesting a bigger blocksize is already implemented and should work if the server supports it. It's been a while since I used this, but it was added along with support for multicast TFTP, probably about a year ago. I see: #define TFTP_MTU_BLOCKSIZE 1468blksize static unsigned short TftpBlkSizeOption=TFTP_MTU_BLOCKSIZE; /* try for more effic. blk size */ pkt += sprintf((char *)pkt,blksize%c%d%c, 0,TftpBlkSizeOption,0); but that is it... No CONFIG_ options for anything else? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
Robin Getz wrote: On Wed 22 Jul 2009 16:32, Ben Warren pondered: Robin Getz wrote: On Wed 22 Jul 2009 10:04, jeffery palmer pondered: We are looking for an http client now as well. Our major issue revolves around the download times for tftp. Can Volkmar Uhlig kindly provide the patches? Our units automically update themselves inside of uboot giving us the most control over our firmware. The issue is that it takes 20 minutes via a DSL line in Africa to update our units. An http test showed that the same firmware downloads in 30 seconds. We have also added things like the blksize parameter to the uboot tftp client to get it down to 20 minutes, our original download times were ~50 minutes. Hmm -- I'm assuming that is http://www.faqs.org/rfcs/rfc1783.html ? Do you have a patch to send - or that I can clean up and submit? Requesting a bigger blocksize is already implemented and should work if the server supports it. It's been a while since I used this, but it was added along with support for multicast TFTP, probably about a year ago. I see: #define TFTP_MTU_BLOCKSIZE 1468blksize static unsigned short TftpBlkSizeOption=TFTP_MTU_BLOCKSIZE; /* try for more effic. blk size */ pkt += sprintf((char *)pkt,blksize%c%d%c, 0,TftpBlkSizeOption,0); but that is it... No CONFIG_ options for anything else? Right, it's hard-coded to 1468 (maximum TFTP frame that will fit in a 1500-byte Ethernet frame, due to UDP overhead). By default, TFTP requests a blocksize that will fill the frame. If not, it uses the default TFTP block size (512, I think). Is this not good enough? Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
On Wed 22 Jul 2009 16:53, Ben Warren pondered: Robin Getz wrote: I see: #define TFTP_MTU_BLOCKSIZE 1468blksize static unsigned short TftpBlkSizeOption=TFTP_MTU_BLOCKSIZE; /* try for more effic. blk size */ pkt += sprintf((char *)pkt,blksize%c%d%c, 0,TftpBlkSizeOption,0); but that is it... No CONFIG_ options for anything else? Right, it's hard-coded to 1468 (maximum TFTP frame that will fit in a 1500-byte Ethernet frame, due to UDP overhead). By default, TFTP requests a blocksize that will fill the frame. If not, it uses the default TFTP block size (512, I think). Is this not good enough? When I looked at the RFC data blocksize no gateway with gateway - -- 51223.85 37.05 102416.15 25.65 143213.70 23.10 204810.90 16.90 4096 6.85 9.65 8192 4.90 6.15 it appears that the overhead of IP fragmentation and reassembly (which does add overhead as the number of gateways increases) may be worth the time... -Robin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mxc_nand: add nand driver for MX2/MX3
On 14:53 Fri 17 Jul , Ilya Yanok wrote: Driver for NFC NAND controller found on Freescale's MX2 and MX3 processors. Ported from Linux. Tested only with i.MX27 but should works with other MX2 and MX3 processors too. Signed-off-by: Ilya Yanok ya...@emcraft.com --- drivers/mtd/nand/Makefile |1 + drivers/mtd/nand/mxc_nand.c | 902 +++ 2 files changed, 903 insertions(+), 0 deletions(-) create mode 100644 drivers/mtd/nand/mxc_nand.c Scott for you is it fine? Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] imx27lite: add support for imx27lite board from LogicPD
+ */
+
+#include common.h
+#include asm/io.h
+#include asm/arch/imx-regs.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static int imx27lite_devices_init(void)
+{
+ struct gpio_regs *regs = (struct gpio_regs *)IMX_GPIO_BASE;
+ int i;
+ unsigned int mode[] = {
+ PD0_AIN_FEC_TXD0,
+ PD1_AIN_FEC_TXD1,
+ PD2_AIN_FEC_TXD2,
+ PD3_AIN_FEC_TXD3,
+ PD4_AOUT_FEC_RX_ER,
+ PD5_AOUT_FEC_RXD1,
+ PD6_AOUT_FEC_RXD2,
+ PD7_AOUT_FEC_RXD3,
+ PD8_AF_FEC_MDIO,
+ PD9_AIN_FEC_MDC | GPIO_PUEN,
+ PD10_AOUT_FEC_CRS,
+ PD11_AOUT_FEC_TX_CLK,
+ PD12_AOUT_FEC_RXD0,
+ PD13_AOUT_FEC_RX_DV,
+ PD14_AOUT_FEC_CLR,
+ PD15_AOUT_FEC_COL,
+ PD16_AIN_FEC_TX_ER,
+ PF23_AIN_FEC_TX_EN,
+ PE12_PF_UART1_TXD,
+ PE13_PF_UART1_RXD,
+ PB4_PF_SD2_D0,
+ PB5_PF_SD2_D1,
+ PB6_PF_SD2_D2,
+ PB7_PF_SD2_D3,
+ PB8_PF_SD2_CMD,
+ PB9_PF_SD2_CLK,
+ (GPIO_PORTC | GPIO_OUT | GPIO_PUEN | GPIO_GPIO | 31),
+ };
+
+ for (i = 0; i ARRAY_SIZE(mode); i++)
+ imx_gpio_mode(mode[i]);
you do not answer about my api comment?
do you plan to create one for device init?
otherwise ok
Best Regards,
J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM Cortex A8: Move OMAP3 specific reset handler
On 11:40 Mon 20 Jul , Minkyu Kang wrote: Because of the reset_cpu is soc specific, should be move to soc Cc: Dirk Behme dirk.be...@googlemail.com Signed-off-by: Minkyu Kang mk7.k...@samsung.com --- cpu/arm_cortexa8/omap3/Makefile |1 + cpu/arm_cortexa8/omap3/reset.S | 36 cpu/arm_cortexa8/start.S| 14 -- 3 files changed, 37 insertions(+), 14 deletions(-) create mode 100644 cpu/arm_cortexa8/omap3/reset.S applied to u-boot-arm Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] I2C Add initial support for TWL4030
On 11:12 Mon 20 Jul , Heiko Schocher wrote: Hello Tom, Tom wrote: Omap2 is still pending. I was hoping to help Richard out with this last week but he was on travel. There is not much more I think I can do wrt omap2. All my targets are omap3. The nearest I can find online is the nokia n8xx which uses a another bootloader. The options as I see them are. 1. Get a pass on omap2 testing 2. Rewrite i2c init to have a omap3 specific init 3. Hack n8xx and try to convience you the results are reasonable 4. Wait for omap2 testing. I vote for #1. Hmm.. because I think this patches go through Jean-Christophe he has to decide if this is acceptable. we will not get a pass on the omap2 but we will do this in a second step as agree with Nishanth Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] arm, i2c: added support for the TWSI I2C Interface
On 09:59 Mon 20 Jul , Heiko Schocher wrote: Signed-off-by: Heiko Schocher h...@denx.de --- - changes since v1: added comments from Prafulla Wadaskar - changes since v2 added comments from Jean-Christophe - added speed setting drivers/i2c/Makefile |1 + drivers/i2c/kirkwood_i2c.c | 484 2 files changed, 485 insertions(+), 0 deletions(-) create mode 100644 drivers/i2c/kirkwood_i2c.c ok for me Prafulla I guess it's ok for you too Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] Add support for Eukrea CPUAT91 SBC
-SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) -OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS)) +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) $(COBJS-y:.o=.c) +OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS) $(COBJS-y)) all: $(obj).depend $(LIB) diff --git a/cpu/arm920t/at91rm9200/ks8721.c b/cpu/arm920t/at91rm9200/ks8721.c new file mode 100644 index 000..703e58c --- /dev/null +++ b/cpu/arm920t/at91rm9200/ks8721.c @@ -0,0 +1,244 @@ +/* + * (C) Copyright 2006 + * Author : Eric Benard (Eukrea Electromatique) + * based on dm9161.c which is : + * (C) Copyright 2003 + * Author : Hamid Ikdoumi (Atmel) I'm not a fan of this implementation at all but as I've not yet finish the rm9200 cleanup I'll ack this ben what do you think? ben please note that the rm9200 cleanup will introduce a phylib support Ben ping Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Fix ld: cannot find -lstubs build error
Commit 1bc15386 moved the examples/ to examples/standalone but failed to adapt the Makefiles that need to link against libstubs.a Signed-off-by: Wolfgang Denk w...@denx.de Cc: Signed-off-by: Peter Tyser pty...@xes-inc.com --- board/netstar/Makefile |2 +- board/trab/Makefile |2 +- board/voiceblue/Makefile |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/board/netstar/Makefile b/board/netstar/Makefile index 91bac38..cb3f7c9 100644 --- a/board/netstar/Makefile +++ b/board/netstar/Makefile @@ -53,7 +53,7 @@ $(LIB): $(OBJS) $(SOBJS) $(obj)eeprom.srec: $(obj)eeprom.o $(obj)eeprom_start.o cd $(lnk) $(LD) -T $(LDSCRIPT) -g -Ttext $(LOAD_ADDR) \ -o $(:.o=) -e eeprom eeprom.o eeprom_start.o \ - -L$(obj)../../examples -lstubs \ + -L$(obj)../../examples/standalone -lstubs \ -L$(obj)../../lib_generic -lgeneric \ -L$(gcclibdir) -lgcc $(OBJCOPY) -O srec $(:.o=) $@ diff --git a/board/trab/Makefile b/board/trab/Makefile index 30e5fbb..3a92c0d 100644 --- a/board/trab/Makefile +++ b/board/trab/Makefile @@ -49,7 +49,7 @@ $(LIB): $(obj).depend $(OBJS) $(SOBJS) $(obj)trab_fkt.srec: $(OBJS_FKT) $(LIB) $(LD) -g -Ttext $(LOAD_ADDR) -o $(:.o=) -e trab_fkt $^ $(LIB) \ - -L$(obj)../../examples -lstubs \ + -L$(obj)../../examples/standalone -lstubs \ -L$(obj)../../lib_generic -lgeneric \ $(obj)../../lib_arm/div0.o \ $(obj)../../lib_arm/_*.o diff --git a/board/voiceblue/Makefile b/board/voiceblue/Makefile index e7c1cbb..7bb92a6 100644 --- a/board/voiceblue/Makefile +++ b/board/voiceblue/Makefile @@ -47,7 +47,7 @@ $(LIB): $(OBJS) $(SOBJS) $(obj)eeprom.srec: $(obj)eeprom.o $(obj)eeprom_start.o cd $(lnk) $(LD) -T $(LDSCRIPT) -g -Ttext $(LOAD_ADDR) \ -o $(:.o=) -e eeprom eeprom.o eeprom_start.o \ - -L$(obj)../../examples -lstubs \ + -L$(obj)../../examples/standalone -lstubs \ -L$(obj)../../lib_generic -lgeneric \ -L$(gcclibdir) -lgcc $(OBJCOPY) -O srec $(:.o=) $@ -- 1.6.0.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OneNAND IPL: Move u-boot-onenand linker script to common use
On 09:08 Fri 17 Jul , Shinya Kuribayashi wrote: Scott Wood wrote: On Mon, Jul 13, 2009 at 09:48:30AM +0900, Kyungmin Park wrote: Basically I agree your opinion, however do see the other arch OneNAND usage? I mean I can't see the other arch patches. There was nothing but powerpc in nand_spl at first, but I don't think ARM developers would have appreciated finding hardcoded powerpc assumptions when they tried to add their boards. Heh, we're already using onenand_ipl on our MIPS machines ;-) maybe mainline soon. ;-) Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] at91cap9adk: fix #ifdef/#endif pairing
On 20:47 Sat 18 Jul , Wolfgang Denk wrote: The #ifdef/#endif pairing in this file was obviously messed up. Signed-off-by: Wolfgang Denk w...@denx.de --- include/configs/at91cap9adk.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) applied to u-boot-arm Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
When I looked at the RFC data
it appears that the overhead of IP fragmentation and reassembly (which does
add overhead as the number of gateways increases) may be worth the time...
Just tried it: U-Boot doesn't support reassembly, it seems.
net.c confirms it:
/* Can't deal with fragments */
if (ip-ip_off htons(IP_OFFS | IP_FLAGS_MFRAG)) {
return;
}
I don't think it's worth adding.
/alessandro
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] AT91: factor out ROUND() macro
On 23:35 Fri 17 Jul , Wolfgang Denk wrote: A large number of boards (all AT91 based) duplicated the ROUND() macro in their board specific config files. Add the definition to include/common.h and clean up the board config files. Signed-off-by: Wolfgang Denk w...@denx.de build failled as we do not include common.h but config.h it in the cpu/arm926ejs/start.S Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] api: Fix broken build on ARM.
On 16:35 Fri 17 Jul , Piotr Ziecik wrote: This patch fixes broken build introduced by commit 84bf7ca522e94ec402a1264b01971b924b7e268f (api: remove un-needed ifdef CONFIG_API already handle by the Makefile). Signed-off-by: Piotr Ziecik ko...@semihalf.com --- api/api_platform-arm.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) applied to u-boot-arm Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] imx27lite: add support for imx27lite board from LogicPD
Hi Jean-Christophe,
Jean-Christophe PLAGNIOL-VILLARD wrote:
+static int imx27lite_devices_init(void)
+{
+struct gpio_regs *regs = (struct gpio_regs *)IMX_GPIO_BASE;
+int i;
+unsigned int mode[] = {
+PD0_AIN_FEC_TXD0,
+PD1_AIN_FEC_TXD1,
+PD2_AIN_FEC_TXD2,
+PD3_AIN_FEC_TXD3,
+PD4_AOUT_FEC_RX_ER,
+PD5_AOUT_FEC_RXD1,
+PD6_AOUT_FEC_RXD2,
+PD7_AOUT_FEC_RXD3,
+PD8_AF_FEC_MDIO,
+PD9_AIN_FEC_MDC | GPIO_PUEN,
+PD10_AOUT_FEC_CRS,
+PD11_AOUT_FEC_TX_CLK,
+PD12_AOUT_FEC_RXD0,
+PD13_AOUT_FEC_RX_DV,
+PD14_AOUT_FEC_CLR,
+PD15_AOUT_FEC_COL,
+PD16_AIN_FEC_TX_ER,
+PF23_AIN_FEC_TX_EN,
+PE12_PF_UART1_TXD,
+PE13_PF_UART1_RXD,
+PB4_PF_SD2_D0,
+PB5_PF_SD2_D1,
+PB6_PF_SD2_D2,
+PB7_PF_SD2_D3,
+PB8_PF_SD2_CMD,
+PB9_PF_SD2_CLK,
+(GPIO_PORTC | GPIO_OUT | GPIO_PUEN | GPIO_GPIO | 31),
+};
+
+for (i = 0; i ARRAY_SIZE(mode); i++)
+imx_gpio_mode(mode[i]);
you do not answer about my api comment?
Sorry, I forgot to write a separate mail to ask you.
do you plan to create one for device init?
What kind of API you expect me to create here? It's just IO pins
initialization...
Regards, Ilya.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6][repost] Marvell RD6281A Board support
On 21:02 Thu 16 Jul , Prafulla Wadaskar wrote: This is Marvell's 88F6281_A0 based reference design board This patch is tested for- 1. Boot from DRAM/NAND flash/NFS 2. File transfer using tftp and loadb 3. NAND flash read/write/erase Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- Change log: Sorry.. One commit was missing... applied to u-boot-arm Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm, kirkwood: added KW_TWSI_BASE in kirkwood.h
On 09:59 Thu 16 Jul , Heiko Schocher wrote: Signed-off-by: Heiko Schocher h...@denx.de --- include/asm-arm/arch-kirkwood/kirkwood.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) applied to u-boot-arm Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH1/2] Kirkwood: add Marvell Kirkwood gpio driver
From fcdea0c7bba3c25a1fb183bbcaf6d1a4ec32a157 Mon Sep 17 00:00:00 2001 From: Dieter Kiermaier dk-arm-li...@gmx.de Date: Mon, 29 Jun 2009 14:22:13 +0200 Subject: [PATCH] Kirkwood: add Marvell Kirkwood gpio driver Signed-off-by: Dieter Kiermaier dk-arm-li...@gmx.de --- drivers/gpio/Makefile|1 + drivers/gpio/kw_gpio.c | 151 ++ include/asm-arm/arch-kirkwood/gpio.h | 51 3 files changed, 203 insertions(+), 0 deletions(-) create mode 100644 drivers/gpio/kw_gpio.c create mode 100644 include/asm-arm/arch-kirkwood/gpio.h applied to u-boot-arm Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OneNAND IPL: Move u-boot-onenand linker script to common use
On 15:11 Mon 20 Jul , Kyungmin Park wrote: Hi, On Sun, Jul 12, 2009 at 9:58 PM, Jean-Christophe PLAGNIOL-VILLARDplagn...@jcrosoft.com wrote: On 17:10 Sat 11 Jul , Kyungmin Park wrote: Use the common OneNAND linker script. Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- diff --git a/onenand_ipl/board/apollon/u-boot.onenand.lds b/onenand_ipl/u-boot-onenand.lds similarity index 100% rename from onenand_ipl/board/apollon/u-boot.onenand.lds rename to onenand_ipl/u-boot-onenand.lds this is arch specific please move it to lib_arm/ I want to make a conclusion. Don't you change your mind? Please give your opinion. as point out by Shinya-san Scott too other can use it and use it today so please make it generic Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm, kirkwood: added kw_gpio_set_valid() in gpio.h
On 09:58 Thu 16 Jul , Heiko Schocher wrote: Signed-off-by: Heiko Schocher h...@denx.de --- This patch needs the patch from: http://lists.denx.de/pipermail/u-boot/2009-July/055854.html first applied. include/asm-arm/arch-kirkwood/gpio.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) applied to u-boot-arm Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fec_mxc: driver for FEC ethernet controller on i.MX27
On 19:32 Tue 21 Jul , Ilya Yanok wrote: Signed-off-by: Ilya Yanok ya...@emcraft.com --- cpu/arm926ejs/mx27/generic.c | 10 + drivers/net/Makefile |1 + drivers/net/fec_mxc.c| 742 ++ drivers/net/fec_mxc.h| 304 + include/netdev.h |1 + 5 files changed, 1058 insertions(+), 0 deletions(-) create mode 100644 drivers/net/fec_mxc.c create mode 100644 drivers/net/fec_mxc.h Ben ping Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ARM Pull Request
Hi Wolfgang, this pull request need that ben send it's pull request for net first as multiple patch depend on it Ben do you plan to send it soon? Please pull The following changes since commit 462b1038738dd86f8dd70595f250ce792e90d244: Wolfgang Denk (1): Merge branch 'master' of /home/wd/git/u-boot/custodians are available in the git repository at: git://git.denx.de/u-boot-arm.git master Dieter Kiermaier (1): Kirkwood: add Marvell Kirkwood gpio driver Heiko Schocher (2): arm, kirkwood: added KW_TWSI_BASE in kirkwood.h arm, kirkwood: added kw_gpio_set_valid() in gpio.h Minkyu Kang (1): ARM Cortex A8: Move OMAP3 specific reset handler Piotr Ziecik (1): api: Fix broken build on ARM. Prafulla Wadaskar (3): Marvell Sheevaplug Board support Marvell MV88F6281GTW_GE Board support Marvell RD6281A Board support Simon Kagstrom (1): Add unaligned.h for arm Wolfgang Denk (1): at91cap9adk: fix #ifdef/#endif pairing MAINTAINERS |6 + MAKEALL |3 + Makefile| 10 +- api/api_platform-arm.c |2 - board/Marvell/mv88f6281gtw_ge/Makefile | 51 ++ board/Marvell/mv88f6281gtw_ge/config.mk | 25 +++ board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c | 141 board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.h | 36 board/Marvell/rd6281a/Makefile | 51 ++ board/Marvell/rd6281a/config.mk | 25 +++ board/Marvell/rd6281a/rd6281a.c | 179 board/Marvell/rd6281a/rd6281a.h | 41 + board/Marvell/sheevaplug/Makefile | 51 ++ board/Marvell/sheevaplug/config.mk | 25 +++ board/Marvell/sheevaplug/sheevaplug.c | 155 ++ board/Marvell/sheevaplug/sheevaplug.h | 41 + cpu/arm_cortexa8/omap3/Makefile |1 + cpu/arm_cortexa8/omap3/reset.S | 36 cpu/arm_cortexa8/start.S| 14 -- drivers/gpio/Makefile |1 + drivers/gpio/kw_gpio.c | 151 + include/asm-arm/arch-kirkwood/gpio.h| 53 ++ include/asm-arm/arch-kirkwood/kirkwood.h|1 + include/asm-arm/unaligned.h | 18 ++ include/configs/at91cap9adk.h |2 +- include/configs/mv88f6281gtw_ge.h | 200 +++ include/configs/rd6281a.h | 198 ++ include/configs/sheevaplug.h| 195 ++ 28 files changed, 1694 insertions(+), 18 deletions(-) create mode 100644 board/Marvell/mv88f6281gtw_ge/Makefile create mode 100644 board/Marvell/mv88f6281gtw_ge/config.mk create mode 100644 board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c create mode 100644 board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.h create mode 100644 board/Marvell/rd6281a/Makefile create mode 100644 board/Marvell/rd6281a/config.mk create mode 100644 board/Marvell/rd6281a/rd6281a.c create mode 100644 board/Marvell/rd6281a/rd6281a.h create mode 100644 board/Marvell/sheevaplug/Makefile create mode 100644 board/Marvell/sheevaplug/config.mk create mode 100644 board/Marvell/sheevaplug/sheevaplug.c create mode 100644 board/Marvell/sheevaplug/sheevaplug.h create mode 100644 cpu/arm_cortexa8/omap3/reset.S create mode 100644 drivers/gpio/kw_gpio.c create mode 100644 include/asm-arm/arch-kirkwood/gpio.h create mode 100644 include/asm-arm/unaligned.h create mode 100644 include/configs/mv88f6281gtw_ge.h create mode 100644 include/configs/rd6281a.h create mode 100644 include/configs/sheevaplug.h Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] http client?
On Wed 22 Jul 2009 18:00, Alessandro Rubini pondered:
When I looked at the RFC data
it appears that the overhead of IP fragmentation and reassembly (which
does add overhead as the number of gateways increases) may be worth
the time...
Just tried it: U-Boot doesn't support reassembly, it seems.
I don't think anyone said it did.
net.c confirms it:
/* Can't deal with fragments */
if (ip-ip_off htons(IP_OFFS | IP_FLAGS_MFRAG)) {
return;
}
I don't think it's worth adding.
This is based on ... ?
If it reduces download time by 1/2 (1432 byte block size == 13.70 seconds,
4096 byte block size == 6.85 seconds) it might be worth the complexity...
At least worth it enough to give it a try, gather some results, and then make
a decision.
-Robin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] at91cap9adk: fix #ifdef/#endif pairing
Dear Jean-Christophe PLAGNIOL-VILLARD, In message 20090722215459.gb26...@game.jcrosoft.org you wrote: On 20:47 Sat 18 Jul , Wolfgang Denk wrote: The #ifdef/#endif pairing in this file was obviously messed up. Signed-off-by: Wolfgang Denk w...@denx.de --- include/configs/at91cap9adk.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) applied to u-boot-arm Why? I have added this to mainline long ago. Please make sure your ARM repo is up to date, i. e. in sync with mainline. 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 great many people think they are thinking when they are merely re- arranging their prejudices. - William James ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] AT91: factor out ROUND() macro
Dear Jean-Christophe PLAGNIOL-VILLARD, In message 2009070950.gc26...@game.jcrosoft.org you wrote: On 23:35 Fri 17 Jul , Wolfgang Denk wrote: A large number of boards (all AT91 based) duplicated the ROUND() macro in their board specific config files. Add the definition to include/common.h and clean up the board config files. Signed-off-by: Wolfgang Denk w...@denx.de build failled as we do not include common.h but config.h it in the cpu/arm926ejs/start.S Yeah, this escaped my testing. But it's already in mainline, so we need a fix for it. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de All these theories, diverse as they are, have two things in common: they explain the observed facts, and they are completeley and utterly wrong. - Terry Pratchett, _The Light Fantastic_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] minor debug cleanups in ./net
From: Robin Getz rg...@blackfin.uclinux.org
Minor ./net cleanups - no functional changes
- change #ifdef DEBUG printf(); #endif to just debug()
- changed __FUNCTION__ to __func__
- got rid of extra whitespace between function and opening brace
- removed unnecessary braces on if statements
gcc dead code elimination should make this functionally/size equivalent
when DEBUG is not defined. (confirmed on Blackfin, with gcc 4.3.3).
Signed-off-by: Robin Getz rg...@blackfin.uclinux.org
---
Most changes are:
-#ifdef DEBUG
- printf(packet received\n);
-#endif
+ debug(packet received\n);
which is just plain nicer to read...
Makefile |2 -
bootp.c | 81 ++---
eth.c|8 ++---
net.c| 78 ---
nfs.c| 42 ++-
rarp.c |4 --
sntp.c |6 +--
tftp.c | 21 +++--
8 files changed, 78 insertions(+), 164 deletions(-)
---
diff --git a/net/Makefile b/net/Makefile
index 835a04a..ff87d87 100644
--- a/net/Makefile
+++ b/net/Makefile
@@ -23,7 +23,7 @@
include $(TOPDIR)/config.mk
-# CFLAGS += -DET_DEBUG -DDEBUG
+# CFLAGS += -DDEBUG
LIB= $(obj)libnet.a
diff --git a/net/bootp.c b/net/bootp.c
index d5f9c4b..0799ae2 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -8,17 +8,6 @@
* Copyright 2000-2004 Wolfgang Denk, w...@denx.de
*/
-#if 0
-#define DEBUG 1 /* general debug */
-#define DEBUG_BOOTP_EXT 1 /* Debug received vendor fields */
-#endif
-
-#ifdef DEBUG_BOOTP_EXT
-#define debug_ext(fmt,args...) printf (fmt ,##args)
-#else
-#define debug_ext(fmt,args...)
-#endif
-
#include common.h
#include command.h
#include net.h
@@ -107,7 +96,7 @@ static int BootpCheckPkt(uchar *pkt, unsigned dest, unsigned
src, unsigned len)
retval = -6;
}
- debug (Filtering pkt = %d\n, retval);
+ debug(Filtering pkt = %d\n, retval);
return retval;
}
@@ -129,7 +118,7 @@ static void BootpCopyNetParams(Bootp_t *bp)
if (strlen(bp-bp_file) 0)
copy_filename (BootFile, bp-bp_file, sizeof(BootFile));
- debug (Bootfile: %s\n, BootFile);
+ debug(Bootfile: %s\n, BootFile);
/* Propagate to environment:
* don't delete exising entry when BOOTP / DHCP reply does
@@ -156,7 +145,7 @@ static void BootpVendorFieldProcess (u8 * ext)
{
int size = *(ext + 1);
- debug_ext ([BOOTP] Processing extension %d... (%d bytes)\n, *ext,
+ debug([BOOTP] Processing extension %d... (%d bytes)\n, *ext,
*(ext + 1));
NetBootFileSize = 0;
@@ -255,7 +244,7 @@ static void BootpVendorProcess (u8 * ext, int size)
{
u8 *end = ext + size;
- debug_ext ([BOOTP] Checking extension (%d bytes)...\n, size);
+ debug([BOOTP] Checking extension (%d bytes)...\n, size);
while ((ext end) (*ext != 0xff)) {
if (*ext == 0) {
@@ -269,34 +258,27 @@ static void BootpVendorProcess (u8 * ext, int size)
}
}
-#ifdef DEBUG_BOOTP_EXT
- puts ([BOOTP] Received fields: \n);
+ debug([BOOTP] Received fields: \n);
if (NetOurSubnetMask)
- printf (NetOurSubnetMask : %pI4\n, NetOurSubnetMask);
+ debug(NetOurSubnetMask : %pI4\n, NetOurSubnetMask);
if (NetOurGatewayIP)
- printf (NetOurGatewayIP: %pI4, NetOurGatewayIP);
+ debug(NetOurGatewayIP : %pI4, NetOurGatewayIP);
- if (NetBootFileSize) {
- printf (NetBootFileSize : %d\n, NetBootFileSize);
- }
+ if (NetBootFileSize)
+ debug(NetBootFileSize : %d\n, NetBootFileSize);
- if (NetOurHostName[0]) {
- printf (NetOurHostName : %s\n, NetOurHostName);
- }
+ if (NetOurHostName[0])
+ debug(NetOurHostName : %s\n, NetOurHostName);
- if (NetOurRootPath[0]) {
- printf (NetOurRootPath : %s\n, NetOurRootPath);
- }
+ if (NetOurRootPath[0])
+ debug(NetOurRootPath : %s\n, NetOurRootPath);
- if (NetOurNISDomain[0]) {
- printf (NetOurNISDomain : %s\n, NetOurNISDomain);
- }
+ if (NetOurNISDomain[0])
+ debug(NetOurNISDomain : %s\n, NetOurNISDomain);
- if (NetBootFileSize) {
- printf (NetBootFileSize: %d\n, NetBootFileSize);
- }
-#endif /* DEBUG_BOOTP_EXT */
+ if (NetBootFileSize)
+ debug(NetBootFileSize: %d\n, NetBootFileSize);
}
/*
* Handle a BOOTP received packet.
@@ -307,7 +289,7 @@ BootpHandler(uchar * pkt, unsigned dest, unsigned src,
unsigned len)
Bootp_t *bp;
char*s;
- debug (got BOOTP packet (src=%d, dst=%d, len=%d want_len=%zu)\n,
+ debug(got BOOTP packet (src=%d, dst=%d, len=%d want_len=%zu)\n,
src, dest, len, sizeof (Bootp_t));
bp =
Re: [U-Boot] Please pull u-boot-mpc85xx
Dear Kumar Gala, In message pine.lnx.4.64.0907210935500.5...@localhost.localdomain you wrote: The following changes since commit d4abc757c26c531293f5bbc4262ade44a317eec9: Peter Tyser (1): Move api_examples to examples/api are available in the git repository at: git://git.denx.de/u-boot-mpc85xx.git master Kumar Gala (3): 85xx: Bump up the BOOTMAP to 16M on FSL 85xx boards 85xx: Report which bank of NOR flash we are booting from on FSL boards 86xx: Report which bank of NOR flash we are booting from on MPC8641HPCN Peter Tyser (6): 86xx: Rename ccsr_ddr's sdram_mode_1, sdram_cfg_1 fields xes: Remove 8xxx board_add_ram_info() function tqm85xx: Remove board_add_ram_info() 85xx, 86xx: Add common board_add_ram_info() xpedite5200,5370: Use buffered NOR flash writes xpedite5370: Fix I2C GPIO initialization typo Roy Zang (1): 85xx: Add pci/pcie E1000 ethernet support for MPC8544DS and MPC8536 boards board/freescale/mpc8536ds/mpc8536ds.c | 18 +- board/freescale/mpc8544ds/mpc8544ds.c | 11 +++- board/freescale/mpc8572ds/mpc8572ds.c | 21 ++- board/freescale/mpc8610hpcd/mpc8610hpcd.c |4 +- board/freescale/mpc8641hpcn/mpc8641hpcn.c | 19 -- board/freescale/p2020ds/p2020ds.c | 12 +++- board/sbc8641d/sbc8641d.c | 12 ++-- board/tqc/tqm85xx/sdram.c | 33 +- board/xes/common/fsl_8xxx_ddr.c | 53 board/xes/xpedite5370/xpedite5370.c |4 +- cpu/mpc86xx/ddr-8641.c|4 +- cpu/mpc8xxx/ddr/main.c| 43 + cpu/mpc8xxx/ddr/util.c| 96 + include/asm-ppc/immap_86xx.h |4 +- include/configs/MPC8536DS.h |5 +- include/configs/MPC8540ADS.h |4 +- include/configs/MPC8541CDS.h |4 +- include/configs/MPC8544DS.h |5 +- include/configs/MPC8548CDS.h |4 +- include/configs/MPC8555CDS.h |4 +- include/configs/MPC8560ADS.h |4 +- include/configs/MPC8568MDS.h |4 +- include/configs/MPC8569MDS.h |4 +- include/configs/MPC8572DS.h |4 +- include/configs/P2020DS.h |4 +- include/configs/XPEDITE5200.h |1 + include/configs/XPEDITE5370.h |1 + 27 files changed, 211 insertions(+), 171 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 Hiring experienced unix people is like a built-in filter against idiots. Hiring experienced NT people provides no such guarantee. -- Miguel Cruz in wgl96.349$cc.122...@typhoon2.ba-dsg.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-i2c.git
Dear Heiko Schocher, In message 4a65dae6.40...@denx.de you wrote: Hello Wolfgang, The following changes since commit 1bc1538613d66cef3cbce680fc8d7c3561a0fbd0: Peter Tyser (1): Move examples/ to examples/standalone are available in the git repository at: git://git.denx.de/u-boot-i2c.git master Heiko Schocher (1): i2c, mpc83xx: add CONFIG_SYS_I2C_INIT_BOARD for fsl_i2c board/keymile/common/common.c | 20 drivers/i2c/fsl_i2c.c |6 ++ include/configs/kmeter1.h |1 - 3 files changed, 26 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 Far back in the mists of ancient time, in the great and glorious days of the former Galactic Empire, life was wild, rich and largely tax free. - Douglas Adams, _The Hitchhiker's Guide to the Galaxy_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mpc85xx (updated)
Dear Kumar Gala, In message pine.lnx.4.64.0907221042010.25...@localhost.localdomain you wrote: (This has the updated versions of the 'bank' patches based on comments from the list) - k The following changes since commit d4abc757c26c531293f5bbc4262ade44a317eec9: Peter Tyser (1): Move api_examples to examples/api are available in the git repository at: git://git.denx.de/u-boot-mpc85xx.git master Kumar Gala (4): 85xx: Bump up the BOOTMAP to 16M on FSL 85xx boards 86xx: Report which bank of NOR flash we are booting from on MPC8641HPCN 85xx: Report which bank of NOR flash we are booting from on FSL boards 85xx/86xx: Replace in8/out8 with in_8/out_8 on FSL boards Peter Tyser (8): 86xx: Rename ccsr_ddr's sdram_mode_1, sdram_cfg_1 fields xes: Remove 8xxx board_add_ram_info() function tqm85xx: Remove board_add_ram_info() 85xx, 86xx: Add common board_add_ram_info() xpedite5200,5370: Use buffered NOR flash writes xpedite5370: Fix I2C GPIO initialization typo xes: Increase CONFIG_SYS_BOOTM_LEN to 16MB xpedite5370: Enable NAND command support Roy Zang (1): 85xx: Add pci/pcie E1000 ethernet support for MPC8544DS and MPC8536 boards board/freescale/common/pixis.c| 78 +++- board/freescale/mpc8536ds/mpc8536ds.c | 61 +--- board/freescale/mpc8544ds/mpc8544ds.c | 27 +--- board/freescale/mpc8572ds/mpc8572ds.c | 48 ++--- board/freescale/mpc8610hpcd/mpc8610hpcd.c | 29 board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c | 13 ++-- board/freescale/mpc8641hpcn/mpc8641hpcn.c | 39 +++ board/freescale/p2020ds/p2020ds.c | 45 +--- board/sbc8641d/sbc8641d.c | 12 ++-- board/tqc/tqm85xx/sdram.c | 33 + board/xes/common/fsl_8xxx_ddr.c | 53 -- board/xes/xpedite5370/xpedite5370.c |4 +- cpu/mpc86xx/ddr-8641.c|4 +- cpu/mpc8xxx/ddr/main.c| 43 +--- cpu/mpc8xxx/ddr/util.c| 96 + include/asm-ppc/immap_86xx.h |4 +- include/configs/MPC8536DS.h | 12 +++- include/configs/MPC8540ADS.h |4 +- include/configs/MPC8541CDS.h |4 +- include/configs/MPC8544DS.h |7 ++- include/configs/MPC8548CDS.h |4 +- include/configs/MPC8555CDS.h |4 +- include/configs/MPC8560ADS.h |4 +- include/configs/MPC8568MDS.h |4 +- include/configs/MPC8569MDS.h |4 +- include/configs/MPC8572DS.h |9 ++- include/configs/MPC8641HPCN.h |2 + include/configs/P2020DS.h |9 ++- include/configs/XPEDITE5170.h |1 + include/configs/XPEDITE5200.h |2 + include/configs/XPEDITE5370.h | 11 +++- 31 files changed, 402 insertions(+), 268 deletions(-) Done, too. 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's only one kind of woman ... Or man, for that matter. You either believe in yourself or you don't. -- Kirk and Harry Mudd, Mudd's Women, stardate 1330.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] document network driver framework
On Sat, Jul 18, 2009 at 8:04 PM, Mike Frysinger vap...@gentoo.org wrote: Signed-off-by: Mike Frysinger vap...@gentoo.org --- Ben: some things to note: - i adopted Jean's proposed naming scheme in the CONFIG section - i deprecated calling the driver-specific entry point xxx_initialization() in favor of xxx_register() because the former is way too confusing with everyone also having xxx_init() doc/README.drivers.eth | 199 1 files changed, 199 insertions(+), 0 deletions(-) create mode 100644 doc/README.drivers.eth diff --git a/doc/README.drivers.eth b/doc/README.drivers.eth new file mode 100644 index 000..00b4eb1 --- /dev/null +++ b/doc/README.drivers.eth @@ -0,0 +1,199 @@ +--- + Ethernet Driver Guide +--- + +The networking stack in Das U-Boot is designed for multiple network devices +to be easily added and controlled at runtime. This guide is meant for people +who wish to review the net driver stack with an eye towards implementing your +own ethernet device driver. Here we will describe a new pseudo 'APE' driver. + + + CONFIG Options + + +The common config defines your device should respect (if applicable): + CONFIG_MII - configure in MII mode + CONFIG_RMII - configure in RMII mode That's awfully global, and inflexible. I don't think there's any convention here that should be encouraged. The data bus configuration is a per-device attribute. If some system architects choose to allow this into their config files, far be it from me to protest, but I'm against it. Also, CONFIG_MII doesn't mean what you think it means. It stems from the obnoxious overlap in terms set forth by IEEE 802.3. The MII in this case refers to the MII Management bus. Defining CONFIG_MII will cause miiphyutil.c to be built, which is a bit-bang MII Management bus driver. It will also enable some MII Management features. CONFIG_MII is therefore a relevant CONFIG option for most drivers. Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fec_mxc: driver for FEC ethernet controller on i.MX27
Jean-Christophe PLAGNIOL-VILLARD wrote: On 19:32 Tue 21 Jul , Ilya Yanok wrote: Signed-off-by: Ilya Yanok ya...@emcraft.com --- cpu/arm926ejs/mx27/generic.c | 10 + drivers/net/Makefile |1 + drivers/net/fec_mxc.c| 742 ++ drivers/net/fec_mxc.h| 304 + include/netdev.h |1 + 5 files changed, 1058 insertions(+), 0 deletions(-) create mode 100644 drivers/net/fec_mxc.c create mode 100644 drivers/net/fec_mxc.h Ben ping Best Regards, J. Planning on getting to it tonight. Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM Pull Request
Dear Jean-Christophe PLAGNIOL-VILLARD, In message 2009073039.gg19...@game.jcrosoft.org you wrote: Hi Wolfgang, this pull request need that ben send it's pull request for net first as multiple patch depend on it Ben do you plan to send it soon? Please pull The following changes since commit 462b1038738dd86f8dd70595f250ce792e90d244: Wolfgang Denk (1): Merge branch 'master' of /home/wd/git/u-boot/custodians are available in the git repository at: git://git.denx.de/u-boot-arm.git master Dieter Kiermaier (1): Kirkwood: add Marvell Kirkwood gpio driver Heiko Schocher (2): arm, kirkwood: added KW_TWSI_BASE in kirkwood.h arm, kirkwood: added kw_gpio_set_valid() in gpio.h Minkyu Kang (1): ARM Cortex A8: Move OMAP3 specific reset handler Piotr Ziecik (1): api: Fix broken build on ARM. Prafulla Wadaskar (3): Marvell Sheevaplug Board support Marvell MV88F6281GTW_GE Board support Marvell RD6281A Board support Simon Kagstrom (1): Add unaligned.h for arm Wolfgang Denk (1): at91cap9adk: fix #ifdef/#endif pairing MAINTAINERS |6 + MAKEALL |3 + Makefile| 10 +- api/api_platform-arm.c |2 - board/Marvell/mv88f6281gtw_ge/Makefile | 51 ++ board/Marvell/mv88f6281gtw_ge/config.mk | 25 +++ board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c | 141 board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.h | 36 board/Marvell/rd6281a/Makefile | 51 ++ board/Marvell/rd6281a/config.mk | 25 +++ board/Marvell/rd6281a/rd6281a.c | 179 board/Marvell/rd6281a/rd6281a.h | 41 + board/Marvell/sheevaplug/Makefile | 51 ++ board/Marvell/sheevaplug/config.mk | 25 +++ board/Marvell/sheevaplug/sheevaplug.c | 155 ++ board/Marvell/sheevaplug/sheevaplug.h | 41 + cpu/arm_cortexa8/omap3/Makefile |1 + cpu/arm_cortexa8/omap3/reset.S | 36 cpu/arm_cortexa8/start.S| 14 -- drivers/gpio/Makefile |1 + drivers/gpio/kw_gpio.c | 151 + include/asm-arm/arch-kirkwood/gpio.h| 53 ++ include/asm-arm/arch-kirkwood/kirkwood.h|1 + include/asm-arm/unaligned.h | 18 ++ include/configs/at91cap9adk.h |2 +- include/configs/mv88f6281gtw_ge.h | 200 +++ include/configs/rd6281a.h | 198 ++ include/configs/sheevaplug.h| 195 ++ 28 files changed, 1694 insertions(+), 18 deletions(-) create mode 100644 board/Marvell/mv88f6281gtw_ge/Makefile create mode 100644 board/Marvell/mv88f6281gtw_ge/config.mk create mode 100644 board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c create mode 100644 board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.h create mode 100644 board/Marvell/rd6281a/Makefile create mode 100644 board/Marvell/rd6281a/config.mk create mode 100644 board/Marvell/rd6281a/rd6281a.c create mode 100644 board/Marvell/rd6281a/rd6281a.h create mode 100644 board/Marvell/sheevaplug/Makefile create mode 100644 board/Marvell/sheevaplug/config.mk create mode 100644 board/Marvell/sheevaplug/sheevaplug.c create mode 100644 board/Marvell/sheevaplug/sheevaplug.h create mode 100644 cpu/arm_cortexa8/omap3/reset.S create mode 100644 drivers/gpio/kw_gpio.c create mode 100644 include/asm-arm/arch-kirkwood/gpio.h create mode 100644 include/asm-arm/unaligned.h create mode 100644 include/configs/mv88f6281gtw_ge.h create mode 100644 include/configs/rd6281a.h create mode 100644 include/configs/sheevaplug.h Applied, thanks. Umm... is this all for ARM for this merge window? I mean, could we release -rc1 from ARM's point of view now? Or do you have mnore stuff queued? If so, when will it be ready for pulling? 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 f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Rejected: PATCH Nios2 kernel bootstrap error due to missing processor data cache flush: fix
Wolfgang Wegner wrote: Dear Scott, Wolfgang, On Tue, Jul 21, 2009 at 02:02:43PM -0400, Scott McNutt wrote: ... for a two line bug fix? This is hardly a valid reason to claim copyright on the module. This practice will only discourage the contribution of original work to the project. Nobody wants to have their work hijacked in such a manner. So you really think your practice will encourage anybody to submit a clean patch for a bug he spent days (or weeks) to find? Many contributors have done so, many times, for many years, across many different architectures, myself included. The amount of time I have spent doing so is insignificant when compared to the benefits I have enjoyed from the generous contributions of _others_. It's one of the small ways I can express my gratitude for the privilege of using such contributions. But this is all irrelevant and off point, no? I am very happy to hear that someone can benefit from the code I spent many, many weeks to develop in my spare time ... code that I have offered freely. So don't enjoy the benefit, then claim co-ownership after adding two lines. At the very best, that's presumptuous. And yes, if that was considered accepted practice, I doubt I'd make any significant original contributions again. Best Regards, --Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] gcc4.4 warning fix patches
Any comments (or acceptance of): http://article.gmane.org/gmane.comp.boot-loaders.u-boot/63614 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/63615 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/63616 - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] arm, i2c: added support for the TWSI I2C Interface
-Original Message- From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com] Sent: Thursday, July 23, 2009 3:17 AM To: Heiko Schocher Cc: Prafulla Wadaskar; U-Boot user list; Wolfgang Denk Subject: Re: [PATCH v3] arm, i2c: added support for the TWSI I2C Interface On 09:59 Mon 20 Jul , Heiko Schocher wrote: Signed-off-by: Heiko Schocher h...@denx.de --- - changes since v1: added comments from Prafulla Wadaskar - changes since v2 added comments from Jean-Christophe - added speed setting drivers/i2c/Makefile |1 + drivers/i2c/kirkwood_i2c.c | 484 2 files changed, 485 insertions(+), 0 deletions(-) create mode 100644 drivers/i2c/kirkwood_i2c.c ok for me Prafulla I guess it's ok for you too Dear Jean, Yes, it's okay for me too. Regards.. Prafulla . . Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] Add support for Eukrea CPUAT91 SBC
Jean-Christophe PLAGNIOL-VILLARD wrote: -SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) -OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS)) +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) $(COBJS-y:.o=.c) +OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS) $(COBJS-y)) all: $(obj).depend $(LIB) diff --git a/cpu/arm920t/at91rm9200/ks8721.c b/cpu/arm920t/at91rm9200/ks8721.c new file mode 100644 index 000..703e58c --- /dev/null +++ b/cpu/arm920t/at91rm9200/ks8721.c @@ -0,0 +1,244 @@ +/* + * (C) Copyright 2006 + * Author : Eric Benard (Eukrea Electromatique) + * based on dm9161.c which is : + * (C) Copyright 2003 + * Author : Hamid Ikdoumi (Atmel) I'm not a fan of this implementation at all but as I've not yet finish the rm9200 cleanup I'll ack this ben what do you think? ben please note that the rm9200 cleanup will introduce a phylib support Ben ping Best Regards, J. This patch has many coding style violations that haven't been addressed, so it can't go in. Im not a fan of the piece-meal PHY implementation either, but realize that a real PHY lib isn't imminent, unless your rm2000 implementation is useful across architectures. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM Pull Request
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wolfgang Denk Sent: Thursday, July 23, 2009 4:35 AM To: Jean-Christophe PLAGNIOL-VILLARD Cc: U-Boot; Ben Warren Subject: Re: [U-Boot] ARM Pull Request Dear Jean-Christophe PLAGNIOL-VILLARD, In message 2009073039.gg19...@game.jcrosoft.org you wrote: Hi Wolfgang, this pull request need that ben send it's pull request for net first as multiple patch depend on it Ben do you plan to send it soon? Please pull The following changes since commit 462b1038738dd86f8dd70595f250ce792e90d244: Wolfgang Denk (1): Merge branch 'master' of /home/wd/git/u-boot/custodians are available in the git repository at: git://git.denx.de/u-boot-arm.git master Dieter Kiermaier (1): Kirkwood: add Marvell Kirkwood gpio driver Heiko Schocher (2): arm, kirkwood: added KW_TWSI_BASE in kirkwood.h arm, kirkwood: added kw_gpio_set_valid() in gpio.h Minkyu Kang (1): ARM Cortex A8: Move OMAP3 specific reset handler Piotr Ziecik (1): api: Fix broken build on ARM. Prafulla Wadaskar (3): Marvell Sheevaplug Board support Marvell MV88F6281GTW_GE Board support Marvell RD6281A Board support Simon Kagstrom (1): Add unaligned.h for arm Wolfgang Denk (1): at91cap9adk: fix #ifdef/#endif pairing MAINTAINERS |6 + MAKEALL |3 + Makefile| 10 +- api/api_platform-arm.c |2 - board/Marvell/mv88f6281gtw_ge/Makefile | 51 ++ board/Marvell/mv88f6281gtw_ge/config.mk | 25 +++ board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c | 141 board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.h | 36 board/Marvell/rd6281a/Makefile | 51 ++ board/Marvell/rd6281a/config.mk | 25 +++ board/Marvell/rd6281a/rd6281a.c | 179 board/Marvell/rd6281a/rd6281a.h | 41 + board/Marvell/sheevaplug/Makefile | 51 ++ board/Marvell/sheevaplug/config.mk | 25 +++ board/Marvell/sheevaplug/sheevaplug.c | 155 ++ board/Marvell/sheevaplug/sheevaplug.h | 41 + cpu/arm_cortexa8/omap3/Makefile |1 + cpu/arm_cortexa8/omap3/reset.S | 36 cpu/arm_cortexa8/start.S| 14 -- drivers/gpio/Makefile |1 + drivers/gpio/kw_gpio.c | 151 + include/asm-arm/arch-kirkwood/gpio.h| 53 ++ include/asm-arm/arch-kirkwood/kirkwood.h|1 + include/asm-arm/unaligned.h | 18 ++ include/configs/at91cap9adk.h |2 +- include/configs/mv88f6281gtw_ge.h | 200 +++ include/configs/rd6281a.h | 198 ++ include/configs/sheevaplug.h| 195 ++ 28 files changed, 1694 insertions(+), 18 deletions(-) create mode 100644 board/Marvell/mv88f6281gtw_ge/Makefile create mode 100644 board/Marvell/mv88f6281gtw_ge/config.mk create mode 100644 board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c create mode 100644 board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.h create mode 100644 board/Marvell/rd6281a/Makefile create mode 100644 board/Marvell/rd6281a/config.mk create mode 100644 board/Marvell/rd6281a/rd6281a.c create mode 100644 board/Marvell/rd6281a/rd6281a.h create mode 100644 board/Marvell/sheevaplug/Makefile create mode 100644 board/Marvell/sheevaplug/config.mk create mode 100644 board/Marvell/sheevaplug/sheevaplug.c create mode 100644 board/Marvell/sheevaplug/sheevaplug.h create mode 100644 cpu/arm_cortexa8/omap3/reset.S create mode 100644 drivers/gpio/kw_gpio.c create mode 100644 include/asm-arm/arch-kirkwood/gpio.h create mode 100644 include/asm-arm/unaligned.h create mode 100644 include/configs/mv88f6281gtw_ge.h create mode 100644 include/configs/rd6281a.h create mode 100644 include/configs/sheevaplug.h Applied, thanks. Umm... is this all for ARM for this merge window? I mean, could we release -rc1 from ARM's point of view now? Or do you have mnore stuff queued? If so, when will it be ready for pulling? Dear Wolfgang The arm build is broken at this moment on u-boot.git/master I have tested for kirkwood boards using nand (i.e. Sheevaplug and RD6281A) same should be the case for other ARM boards using NAND flash. The following patches from jean needed for successful build. But those cannot be
[U-Boot] FW: ARM Pull Request
Prafulla Wadaskar (3): Marvell Sheevaplug Board support Marvell MV88F6281GTW_GE Board support Marvell RD6281A Board support Hi Ben, I think Pull request net not yet applied. This breaks build for RD6281A board. Some discussion was going for net: Kirkwood_egiga: forced interface speed config support patch inclusion. Jean has voted to keep this patch. Ref http://lists.denx.de/pipermail/u-boot/2009-July/057139.html even if wolfgang decides to skip this patch, rest other should be applied. Thanks and Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] Add support for Eukrea CPUAT91 SBC
Ben Warren wrote : This patch has many coding style violations that haven't been addressed, so it can't go in. Im not a fan of the piece-meal PHY implementation coding style violations should be fixed in v3 / http://www.mail-archive.com/u-boot@lists.denx.de/msg18068.html Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] uec: Fix compile warning
Kumar Gala wrote: cpu.c: In function 'cpu_eth_init': cpu.c:371: warning: implicit declaration of function 'uec_standard_init' Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- include/netdev.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/netdev.h b/include/netdev.h index aed5c4c..92eceb1 100644 --- a/include/netdev.h +++ b/include/netdev.h @@ -50,6 +50,7 @@ int e1000_initialize(bd_t *bis); int eepro100_initialize(bd_t *bis); int eth_3com_initialize (bd_t * bis); int fec_initialize (bd_t *bis); +int uec_standard_init(bd_t *bis); int greth_initialize(bd_t *bis); void gt6426x_eth_initialize(bd_t *bis); int inca_switch_initialize(bd_t *bis); I'm not sure why I applied this - the prototype is already there and this is not sorted alphabetically. Anyway, reverted and you shouldn't get the warning. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Ping is not working with uboot 1.3.4 on at91sam9263 custom board
Hi i have been using custom board with at91sam9263 and U boot 1.3.4, It showing that link is up and down whenever i pluging and plugout the Ethernet cable. But when I try to ping, it showing : host device not active. Whether its a problem with Uboot or something with board?? Your suggestions would be great help for me. -- View this message in context: http://www.nabble.com/Ping-is-not-working-with-uboot-1.3.4-on-at91sam9263-custom-board-tp24600587p24600587.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
