[U-Boot] U-Boot and CONFIG_SYS_DAVINCI_BROKEN_ECC
I was looking at the DaVinci NAND support in current U-Boot code (i.e. 2009.03 plus patches merged since that release), and am puzzled by the above-named config option. Before I submit a patch to remove it from U-Boot GIT (nothing there enables it, and it will nastify 4-bit support), I thought I'd see if anyone knows exactly what software it was trying to emulate. Differences from the current NAND driver in GIT: - Matches MVL 4.0 (2.6.10) and 5.0 (2.6.18) drivers in handling NANDx1ECC registers: 0PQR0stu maps to PsQRtu, while the NAND driver in mainline maps it to ~PQRstu. - Custom ECC layouts, not compatible with Linux or RBL/UBL. - Does some very broken stuff for large page support. The first of those I can understand; someone wrote some odd and overly-complex ECC code way back, it worked and then got shipped. (Although TI's U-Boot 1.2.0 uses soft ECC, instead...) The other two look like they were experimental code that should probably not have been merged anywhere... - Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] lib_arm/board.c: remove misleading test-only comment.
For a long time, the print_cpuinfo() declaration in lib_arm/board.c
had been marked as test-only, which is plain wrong considering
current usage. Delete this misleading comment.
Signed-off-by: Wolfgang Denk w...@denx.de
---
lib_arm/board.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib_arm/board.c b/lib_arm/board.c
index 6847ea8..5d05d9b 100644
--- a/lib_arm/board.c
+++ b/lib_arm/board.c
@@ -258,7 +258,7 @@ static int arm_pci_init(void)
*/
typedef int (init_fnc_t) (void);
-int print_cpuinfo (void); /* test-only */
+int print_cpuinfo (void);
init_fnc_t *init_sequence[] = {
cpu_init, /* basic cpu dependent setup */
--
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] lib_arm/board.c: remove misleading test-only comment.
In message 1240771284-20054-1-git-send-email...@denx.de you wrote: For a long time, the print_cpuinfo() declaration in lib_arm/board.c had been marked as test-only, which is plain wrong considering current usage. Delete this misleading comment. Signed-off-by: Wolfgang Denk w...@denx.de --- lib_arm/board.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) 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 Quotation, n. The act of repeating erroneously the words of another. The words erroneously repeated. - Ambrose Bierce _The Devil's Dictionary_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] OMAP3: Remove unused board-types
Dear Dirk Behme, In message 49f3e966@googlemail.com you wrote: I would not dare to use such a function in my code given the test-only comment. sorry I've no time to clean every part of the arm as noone else are interrested in old code so yes it will be cleanup but later asI work on other part of the arm actually which I will finish first Uups :( And this is what I really have a problem with. Problem solved. I removed this comment. The patch has been checked into mainline, Then we find that the changes we are asked to do rely on code that is marked with 'test only' and needs documentation. Actualy I removed only the comment. I left the documentation for those who know better than me what's going on. And now? What are we supposed to do? Change our patch based on 'test only' undocumented code? The test-only has been removed, and the documentation will be added ASAP. Please base your patch on this code as is now (even though the documentation is still missing). Or will a trivial 'remove dead code only' patch delayed until e.g. the Kconfig framework or e.g. the new clock framework or e.g. add what you want will be ready? And when will this be? No, it will not be delayed. I will take personal care that it goes into this release. If needed I will apply it myself. 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 committee is a group that keeps the minutes and loses hours. -- Milton Berle ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Medical Doctor Listing
Essential tool for marketing to heathcare professionals Current Doctors in the USA 788,748 in total * 17,500 emails Featuring the most accurate contact information in many different areas of medicine you can sort by many different fields like city, state or zip Pharmaceutical Companies in the United States Personal email addresses (47,000 in total) and names for top level executives Complete Directory of Hospitals in the US Full data for all the major positions in more than 7k facilities Dentists in the United States 597,000 dentists and dental services ( a $350 value!) Chiropractors in the USA Complete data for all chiropractors in the US (a $250 value) This week only you pay only: $390 for everything Email us at: mast...@medexecdata.com only during this week to adjust your subscription status email to del...@medexecdata.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] OMAP3: Fix timer handling to 1ms and CONFIG_SYS_HZ to 1000
On 17:29 Tue 21 Apr , Dirk Behme wrote: From: Manikandan Pillai mani.pil...@ti.com Signed-off-by: Dirk Behme dirk.be...@googlemail.com Signed-off-by: Manikandan Pillai mani.pil...@ti.com --- as Request precedently switch to 12Mhz source clock or please specify the timer resolution precision of your implementation and put in the commit message code and please specify on which board you test it in the commit message Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/10] LED Add documentation describing the status_led and colour led API.
On 09:40 Tue 14 Apr , Tom Rix wrote: This document describes the u-boot status LED API. This allows common u-boot commands to use a board's leds to provide status for activities like booting and downloading files. Signed-off-by: Tom Rix tom@windriver.com --- Applied to arm/next Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/10] ARM Add blue colour LED to status_led.
On 09:41 Tue 14 Apr , Tom Rix wrote: There is exiting support for red,yellow,green but no blue. The main LED on the zoom2 is a blue LED. Signed-off-by: Tom Rix tom@windriver.com --- Applied to arm/next Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] OMAP3: Remove legacy NAND defines
Dear Jean-Christophe PLAGNIOL-VILLARD, In message 20090426214652.gd32...@game.jcrosoft.org you wrote: On 20:15 Tue 14 Apr , Dirk Behme wrote: Remove remaining legacy NAND defines for Beagle, EVM, Overo and Pandora. Signed-off-by: Dirk Behme dirk.be...@googlemail.com --- applied to arm/next Could you please move this to master so we hanlde all boards consistently? Zoom1 has the same change, and this went into master, if I remember correctly. And we can be generous and consider this cleanup to be a fix - and we are pretty sure that it does not hurt anybody else. Thanks in advance. 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 We are Microsoft. Unix is irrelevant. Openness is futile. Prepare to be assimilated. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3: Fix changed mmc init command
On 17:30 Tue 21 Apr , Dirk Behme wrote: In recent U-Boot mmcinit changed to mmc init. Signed-off-by: Steve Sakoman st...@sakoman.com Signed-off-by: Dirk Behme dirk.be...@googlemail.com --- Applied Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] OMAP3: Remove legacy NAND defines
On 20:15 Tue 14 Apr , Dirk Behme wrote: Remove remaining legacy NAND defines for Beagle, EVM, Overo and Pandora. Signed-off-by: Dirk Behme dirk.be...@googlemail.com --- applied to arm/next Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy
Dear David, In message 200904251153.51380.davi...@pacbell.net you wrote: Just type u-boot merge window at google and click on the very first link. Several other key infrastructure projects make it easy to find that info even without using a search engine. Come on and be reasonable. Yes, the current release state is not on the front page. But it is just one click away. And my reference to google was just because of the argument difficult to find. As a developer, I'd be more likely to look at the GIT summary for status of the GIT tree; its normally the first place to look for such things. I agree fully with this statement. But at the same time I have to point out that this is exactly where our opinions differ: - You expect that the U-Boot git repository mirrors the current state in the release process, ideally in the same way as Linux handles this. - For me, the current phase of the release process is not necessarily reflected by a specific tag on the git tree. This is a (as I think unavoidable) consequence of the existing differences in the prcedures: * In Linux, top-level maintainers will collect patches in their trees and send pull requests to Linus as soon as the merge window opens. So far, most U-Boot custodians do not work like that; they send pull requests only at (or even after) the end of the merge window. * In Linux, the closing of the merge window is maked by the release of the next =-rc1 In U-Boot, -rc1 will only be released after all (or at least most of the) patches that were submitted during the merge window have been applied. Well, yes, I know. The tiome when I get the pull requests from the custodians is another one - being a major contribution to the former. And Linux has had years to develop -- and motivate! -- its merge procedures ... it's a different team and process. Processes need constant tweaking though. And your process page strongly suggests you're using the Linux processes. Hence surprise and confusion when you aren't quite doing so, from folk who use those processes daily. Well, it's exactly my intention to do things differnetly or to cause confusion :-( But the thing is, that we (the custodians and me) are not working (yet?) as the Linux maintainers do. I hope we can improve. I am really thankful for this discussion - IIRC this is the first time ever that suchtopics have been discussed here. Easily addressed though ... that web page can point out some differences. Make a few small things *obviously* different, and people will assume that other things may also differ. I tried to make things a bit clearer. Please have a look at http://www.denx.de/wiki/U-Boot/ReleaseCycle and http://www.denx.de/wiki/U-Boot/DevelopmentProcess and let me know what's unclear or missing or needs improvement (or, even better, edit it yourself -it's a wiki after all, where everybody can contribute). When the RC label just means we only integrate bugfixes now, that communicates such status with very little work. If folk miss some webpage, or mailing list post, they'll still know. Please allow me to stick with RC = release candidate, i. e. something that is at least reasonably compile tested and has at least the majority of patches included. I couldn't stop you, of course. All I'm doing is pointing out what others have also pointed out: that the current process is a bit opaque about some key points. And I'm trying to help with some small suggestions. I've tried to explain the reasons for the differences on the web page. Since you don't want to use an rc tag -- even rc0? -- maybe some other git tag could be used to flag merge window ended. Please see above - I feel it would be wrong, as the merge window closed state is nothing that has a direct representation in our git tree. A -pre, maybe. If there's some obvious indicator there, you wouldn't need to update the wiki except maybe to summarize key points of the process you want to publicize. And contributors wouldn't be scratching their heads, or starting long discussions on the list. ;) But this discussion is/was a good thing to have! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Open the pod bay doors, HAL.- Dave Bowman, 2001 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/10] ZOOM2 Add initial support for Zoom2
On 00:10 Sat 25 Apr , Wolfgang Denk wrote:
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090424213824.gd32...@game.jcrosoft.org you wrote:
...
[FULL QUOTE DELETED]
It makes no sense to quote the complete patch when you just want to
add one line of comment at the end!
+ . = ALIGN(4);
+ .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
+
+ .ARM.extab : { *(.ARM.extab* .gnu.linkonce.armextab.*) }
+ __exidx_start = .;
+ .ARM.exidx : { *(.ARM.exidx* .gnu.linkonce.armexidx.*) }
+ __exidx_end = .;
as said precedently .ARM.extab .ARM.exidx is not needed please remove
I've seen you fix it in the 10th patch
So what does this mean now? Will this patch 01/10 be accepted?
As ask on the [PATCH 05/10] ZOOM2: rename timer divisor
this patch and the 5th need to be joined otherwise 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 v3] Marvell MV88F6281GTW_GE Board support
On 07:19 Thu 23 Apr , Prafulla Wadaskar wrote:
This is Marvell's 88F6281_A0 based custom board developed
for wireless access point product
This patch is tested for-
1. Boot from DRAM/SPI flash/NFS
2. File transfer using tftp and loadb
3. SPI flash read/write/erase
4. Booting Linux kernel and RFS from SPI flash
Reviewed-by: Ronen Shitrit rshit...@marvell.com
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
Change log
v2: updated as per first review comments
debug_prints updated to debug
v3: updated as per review comments for v2
added mv88f6281gtw_ge.h file
removed BITxx macros
first a general comment
I do not known if it's your mailer but all tab are converted in whitespace
please fix it
MAKEALL |1 +
Makefile|3 +
board/Marvell/mv88f6281gtw_ge/Makefile | 51 +++
board/Marvell/mv88f6281gtw_ge/config.mk | 25
board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c | 102 +
board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.h | 46 ++
board/Marvell/mv88f6281gtw_ge/u-boot.lds| 53 +++
include/configs/mv88f6281gtw_ge.h | 175
+++
8 files changed, 456 insertions(+), 0 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/mv88f6281gtw_ge/u-boot.lds
create mode 100644 include/configs/mv88f6281gtw_ge.h
diff --git a/MAKEALL b/MAKEALL
index e4eb42b..1caf81d 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -504,6 +504,7 @@ LIST_ARM9= \
cp946es \
cp966 \
lpd7a400\
+ mv88f6281gtw_ge \
mx1ads \
mx1fs2 \
netstar \
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include common.h
+#include ../drivers/net/phy/mv88e61xx.h
+#include netdev.h
+#include mv88f6281gtw_ge.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int board_init(void)
+{
+ /* Board Parameters initializations */
could explain what you do a few more?
+ kw_window_ctrl_reg_init();
+ kw_gpio_init(MV88F6281GTW_GE_OE_VAL_LOW,
+MV88F6281GTW_GE_OE_VAL_HIGH,
+MV88F6281GTW_GE_OE_LOW, MV88F6281GTW_GE_OE_HIGH);
+
+ kw_mpp_control_init(MV88F6281GTW_GE_MPP0_7,
+ MV88F6281GTW_GE_MPP8_15,
+ MV88F6281GTW_GE_MPP16_23,
+ MV88F6281GTW_GE_MPP24_31,
+ MV88F6281GTW_GE_MPP32_39,
+ MV88F6281GTW_GE_MPP40_47,
MV88F6281GTW_GE_MPP48_55);
+
from
+ /* serial config */
+ gd-baudrate = CONFIG_BAUDRATE;
+ gd-have_console = 1;
no need please remove
+ /*
+* arch number of USED SOC
+*/
+ gd-bd-bi_arch_number = MACH_TYPE_MV88F6281GTW_GE;
+
+ /* adress of boot parameters */
+ gd-bd-bi_boot_params = 0x0100;
please be more consistant with the other arm boards
RAM_BASE + 0x100
+
+ return 0;
+}
+
+int dram_init(void)
+{
+ int i;
+
+ for (i = 0; i CONFIG_NR_DRAM_BANKS; i++) {
+ gd-bd-bi_dram[i].start = kw_sdram_bar(i);
+ gd-bd-bi_dram[i].size = kw_sdram_bs(i);
+ }
+ return 0;
+}
+
+int last_stage_init(void)
+{
+ return 0;
+}
no need please remove
+
+#if defined(CONFIG_MISC_INIT_R)
+/* miscellaneous platform dependent init */
+int misc_init_r(void)
+{
+ return kw_misc_init_r();
+}
if it's really arch late init please create a generic function like
arch_late_init or arch_misc_init
and call it from lib_arm/board.c
+
+void reset_phy(void)
+{
+#ifdef CONFIG_MV88E61XX_SWITCH
+ /* configure and initialize switch */
+ struct mv88e61xx_config swcfg = {
+ .name = egiga0,
+ .vlancfg = MV88E61XX_VLANCFG_ROUTER,
+ .rgmii_delay =
Re: [U-Boot] U-Boot and CONFIG_SYS_DAVINCI_BROKEN_ECC
On 11:11 Sun 26 Apr , David Brownell wrote: I was looking at the DaVinci NAND support in current U-Boot code (i.e. 2009.03 plus patches merged since that release), and am puzzled by the above-named config option. Before I submit a patch to remove it from U-Boot GIT (nothing there enables it, and it will nastify 4-bit support), I thought I'd see if anyone knows exactly what software it was trying to emulate. Differences from the current NAND driver in GIT: maybe add it in the feature-removal-schedule.txt will let people time to explain why they need it After my only request will be to use the same ECC as the mainline kernel or if someone explain why he need it add on other ECC algo 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] OMAP3: Beagle: Set pinmux conditionally for Rev C boards
On 20:27 Fri 17 Apr , Dirk Behme wrote: The Beagle Rev C boards pull UART2 from an alternate set of balls. Signed-off-by: Steve Sakoman st...@sakoman.com Signed-off-by: Dirk Behme dirk.be...@googlemail.com --- Applied to arm/next Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot and CONFIG_SYS_DAVINCI_BROKEN_ECC
Dear Jean-Christophe PLAGNIOL-VILLARD, In message 20090426224036.gl32...@game.jcrosoft.org you wrote: On 11:11 Sun 26 Apr , David Brownell wrote: I was looking at the DaVinci NAND support in current U-Boot code (i.e. 2009.03 plus patches merged since that release), and am puzzled by the above-named config option. Before I submit a patch to remove it from U-Boot GIT (nothing there enables it, and it will nastify 4-bit support), I thought I'd see if anyone knows exactly what software it was trying to emulate. Differences from the current NAND driver in GIT: maybe add it in the feature-removal-schedule.txt will let people time to explain why they need it Hm... I don't think this is needed. Since there are no users of this code in U-Boot, we can as well remove it without warning. 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 Heavier than air flying machines are impossible. -- Lord Kelvin, President, Royal Society, c. 1895 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot and CONFIG_SYS_DAVINCI_BROKEN_ECC
On 00:51 Mon 27 Apr , Wolfgang Denk wrote: Dear Jean-Christophe PLAGNIOL-VILLARD, In message 20090426224036.gl32...@game.jcrosoft.org you wrote: On 11:11 Sun 26 Apr , David Brownell wrote: I was looking at the DaVinci NAND support in current U-Boot code (i.e. 2009.03 plus patches merged since that release), and am puzzled by the above-named config option. Before I submit a patch to remove it from U-Boot GIT (nothing there enables it, and it will nastify 4-bit support), I thought I'd see if anyone knows exactly what software it was trying to emulate. Differences from the current NAND driver in GIT: maybe add it in the feature-removal-schedule.txt will let people time to explain why they need it Hm... I don't think this is needed. Since there are no users of this code in U-Boot, we can as well remove it without warning. no necessarelly the boards Maintainer choose to use the other ECC but part of the U-Boot user may need it. So add it in the removal schedule make sense. We can evenif plan it for the next Release. Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot and CONFIG_SYS_DAVINCI_BROKEN_ECC
On Sunday 26 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote: Before I submit a patch to remove it from U-Boot GIT (nothing there enables it, and it will nastify 4-bit support), I thought I'd see if anyone knows exactly what software it was trying to emulate. ... maybe add it in the feature-removal-schedule.txt will let people time to explain why they need it Hm... I don't think this is needed. Since there are no users of this code in U-Boot, we can as well remove it without warning. That was my thought. If it were important enough to keep in *this* source base, someone would have submitted some board that uses it. It's badly enough broken that I don't know who would bother using it, though; anyone trying to use it has some kind of (non-Linux?) support nightmare already. no necessarelly the boards Maintainer choose to use the other ECC but part of the U-Boot user may need it. So add it in the removal schedule make sense. We can evenif plan it for the next Release. I wouldn't mind doing that. After my only request will be to use the same ECC as the mainline kernel or if someone explain why he need it add on other ECC algo Right, mainline does not use that broken ECC. I can't figure out who *does* use it, either... - Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot and CONFIG_SYS_DAVINCI_BROKEN_ECC
On Sun, 26 Apr 2009 16:56:40 -0700 David Brownell davi...@pacbell.net wrote: On Sunday 26 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote: Before I submit a patch to remove it from U-Boot GIT (nothing there enables it, and it will nastify 4-bit support), I thought I'd see if anyone knows exactly what software it was trying to emulate. ... maybe add it in the feature-removal-schedule.txt will let people time to explain why they need it Hm... I don't think this is needed. Since there are no users of this code in U-Boot, we can as well remove it without warning. That was my thought. If it were important enough to keep in *this* source base, someone would have submitted some board that uses it. It's badly enough broken that I don't know who would bother using it, though; anyone trying to use it has some kind of (non-Linux?) support nightmare already. no necessarelly the boards Maintainer choose to use the other ECC but part of the U-Boot user may need it. So add it in the removal schedule make sense. We can evenif plan it for the next Release. I wouldn't mind doing that. After my only request will be to use the same ECC as the mainline kernel or if someone explain why he need it add on other ECC algo Right, mainline does not use that broken ECC. I can't figure out who *does* use it, either... We certainly don't use it for the SFFSDR board. Hugo V. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] smc911x: do net reset the chip if no EEPROM is connected
On Tuesday 21 April 2009 07:13:10 Daniel Mack wrote: On Wed, Apr 08, 2009 at 11:57:37PM -0400, Mike Frysinger wrote: Not if the MAC is stored in the volatile smc911x registers. Issuing a soft reset flushes these values - if U-Boot does that, the OS has no change getting them. then either your u-boot or your OS is misconfigured and you need to fix that. as clearly stated in docs/README.enetaddr, the environment is the place where mac addresses live when there is no dedicated storage (like an eeprom). ignoring that, the mac address doesnt magically get programmed. if no network operation was initiated, then the part wouldnt have been programmed anyways, so you're still left with an OS that cant get itself functional. Ok, true. Thanks for pointing this out. usually what i suggest to people are things like: - pass $(ethaddr) via kernel command line and parse /proc/cmdline - use the u-boot tools to read the u-boot env directly - set the hw address with `ifconfig` or similar tool -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Uboot mtest hang on mx31
Hi All. When i do a memtest without any args, it crashes after printing the first line. I know the output may vary depending on the processor and the memmap. I just wanted to knoe is this tha appropiate behaviour for mtest. CPU: Freescale i.MX31 at 531 MHz Board: MX31 3Stack DRAM: 128 MB NAND: Bad block table found at page 65472, version 0x01 Bad block table found at page 65408, version 0x01 nand_read_bbt: Bad block at 0x01b0 nand_read_bbt: Bad block at 0x02ae nand_read_bbt: Bad block at 0x02c6 nand_read_bbt: Bad block at 0x052a nand_read_bbt: Bad block at 0x052c 128 MiB In:serial Out: serial Err: serial Hit any key to stop autoboot: 0 = = mtest Pattern Writing... The serial console just freezes here, meaning an evident crash After reboot, when i do and md for the base address 0x0, i get the following, which proabbly is the uboot image itself in RAM. So i am guessing, the memtest tries modifying the U-boot in memory and hence the crash. i am not sure though Please correct me if i am wrong. Here's the message log. CPU: Freescale i.MX31 at 531 MHz Board: MX31 3Stack DRAM: 128 MB NAND: Bad block table found at page 65472, version 0x01 Bad block table found at page 65408, version 0x01 nand_read_bbt: Bad block at 0x01b0 nand_read_bbt: Bad block at 0x02ae nand_read_bbt: Bad block at 0x02c6 nand_read_bbt: Bad block at 0x052a nand_read_bbt: Bad block at 0x052c 128 MiB In:serial Out: serial Err: serial Hit any key to stop autoboot: 0 =md 0 : e59ff00c e59ff018 e59ff018 e59ff018 0010: e59ff018 b800 e59ff014 e59ff014 0020: 0090 1fd0 1fd4 1fd8 0030: 1fdc 1fe0 1fe4 0040: 79706f43 68676972 63282074 30322029Copyright (c) 20 0050: 4d203430 726f746f 20616c6f 2e636e4904 Motorola Inc. 0060: 6c6c4120 67697220 20737468 65736572 All rights rese 0070: 64657672 002e rved 0080: 02b4 04e0 0524 $... 0090: e321f0d3 e59fd008 e59f0008 e12fff10..!.../. 00a0: ea01 1fd0 00e0 e321f0d3..!. 00b0: e59fd014 e59f0014 e3a0106c e5c01000l... 00c0: e59f000c e12fff10 eaf7 1fd0../. 00d0: 1fffc800 02b4 00e0: e59f2064 e59f005c e59f1054 e3c22003d ..\...T .. 00f0: e0823000 e153 34912004 34802004.0P.. .4. .4 Thanks, Alfred. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot -printk kernel crash dump using md on PDK
Hi Fabio, Are the load address and other params same for PDK and the ADS board. I intend to do the same as what you intended to aith sucess. I saw your post her : http://www.nabble.com/Loading-a-kernel-on-MX31ADS-using-U-boot-td16642427.html Please let me know how were able to sucessfully load the kernel. My bootup sequence too hangs after Uncompressing kernel...done booting the kernel. Thanks. On Fri, Apr 24, 2009 at 1:23 PM, Fabio Estevam fabioeste...@yahoo.com wrote: Hi Alfred, --- On Thu, 4/23/09, alfred steele alfred.jaq...@gmail.com wrote: I have attached the printk circular buffer log. smc911x: initializing smc911x: detected NULL controller smc911x: phy initialized smc911x: MAC 92:92:92:bb:bb:bb TFTP from server 206.44.18.25; our IP address is 206.44.18.31 Filename 'zImage_spin2_23march'. Is this really an uImage? The name of the file starts with zImage, so it looks confusing. Can you confirm? How are you generating the uImage? Assuming you are using MX31PDK Freescale BSP, you can do as follows: cd rpm/BUILD/linux make ARCH=arm uImage (You need to have mkimage installed) Which U-boot version are you using? Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot -printk kernel crash dump using md on PDK
Dear alfred steele, A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? (see http://www.netmeister.org/news/learn2quote.html) In message 528f13590904262208s66b17bdekac218fba7994d...@mail.gmail.com you wrote: Hi Fabio, Are the load address and other params same for PDK and the ADS board. I intend to do the same as what you intended to aith sucess. I saw your post her : http://www.nabble.com/Loading-a-kernel-on-MX31ADS-using-U-boot-td16642427.html Please let me know how were able to sucessfully load the kernel. My bootup sequence too hangs after Uncompressing kernel...done booting the kernel. ... [Full quote deleted.] You top post. You full quote. And you post off topic stuff (Linux questions are off topic on the U-Boot list). Note that you cannot win any price for the maximum number of netiquette violations in a single posting. Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It is common sense to take a method and try it. If it fails, admit it frankly and try another. But above all, try something. - Franklin D. Roosevelt ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot -printk kernel crash dump using md on PDK
Dear Wolfgang, You top post. You full quote. Sincere Apologies. I better watch out before i hit the send button. Best Regards. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
