Re: [U-Boot] [PATCH] zlib: allow 0 as destination pointer
Very good!!! So is it time to re-apply zlib patch to u-boot main tree, together Alessandro's patch? Wolfgang, what's your position? Best Regards, Giuseppe -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Stefan Roese Sent: Tuesday, July 28, 2009 8:31 AM To: Alessandro Rubini Cc: u-boot@lists.denx.de; rhabarber1...@web.de Subject: Re: [U-Boot] [PATCH] zlib: allow 0 as destination pointer On Monday 27 July 2009 18:40:31 Alessandro Rubini wrote: The entry point of an image can be 0 (like on PowerPC), so allow next_out to be NULL in inflate() Signed-off-by: Alessandro Rubini rub...@unipv.it --- Stefan Roese: I'll try to uncompress to something != 0 tomorrow on PPC. You are right. I naively thought my arm has RAM at 0 like PPC, but entry point of image is not really 0. Yes, this works: Tested-by: Stefan Roese s...@denx.de 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dlmalloc: Ignore gcc4.4 compiler warnings
On Jul 29, 2009, at 12:47 AM, Wolfgang Denk wrote: Dear Scott, In message 20090728225244.ga8...@b07421-ec1.am.freescale.net you wrote: The patch title is bad -- it's not disabling warnings, it's disabling an aspect of C99 that the code is incompatible with (and which is pretty questionable in the first place with such low level code). Note that in Linux, this is disabled for the entire kernel. I know. But Linux is bigger than U-Boot, and I think we should be able to fix the few isolated places that throw such warnings. As things stand, GCC may do bad things with that code. With this patch, it may not (at least not this particular sort of bad thing). Those bad things are not limited to the places where it warns -- those are just the violations it detected. Agreed, and that's why I want to see this fixed. Do you have an alternative malloc implementation in mind that is designed to work with strict aliasing, or a suggested fix to the current one? I did not look into this yet - there was some discussion about a malloc replacement, but it faded away without visible result. I cannot do everything myself, but I can oppose changes that are IMO to the worse. Do we have any ideas what type of performance we're looking for from malloc? - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] zlib: allow 0 as destination pointer
Dear Giuseppe CONDORELLI, In message 001601ca1012$e0f72730$c0818...@st.com you wrote: Very good!!! So is it time to re-apply zlib patch to u-boot main tree, together Alessandro's patch? Wolfgang, what's your position? Actually I'm waiting for a new patch that integrates that fix. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Just about every computer on the market today runs Unix, except the Mac (and nobody cares about it). - Bill Joy 6/21/85 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] zlib: allow 0 as destination pointer
Dear Wolfgang, Actually I'm waiting for a new patch that integrates that fix. Maybe I've not understood. Do you mean you are waiting a new zlib patch [v4] that includes Alessandro's patch, to apply only one patch containing all? Best Regards, Giuseppe -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Wednesday, July 29, 2009 8:24 AM To: Giuseppe CONDORELLI Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] zlib: allow 0 as destination pointer Dear Giuseppe CONDORELLI, In message 001601ca1012$e0f72730$c0818...@st.com you wrote: Very good!!! So is it time to re-apply zlib patch to u-boot main tree, together Alessandro's patch? Wolfgang, what's your position? Actually I'm waiting for a new patch that integrates that fix. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Just about every computer on the market today runs Unix, except the Mac (and nobody cares about it). - Bill Joy 6/21/85 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Is it an error in function ehci_submit_root() in ehci-hcd.c
Hi All,
I'm trying to enable ehci usb in our board and I found that there
maybe two issues in funcion ehci_submit_root() in ehci-hcd.c.
1)
In ehci_submit_root(), the function will do the following operation.
From line 553 in ehci-hcd.c:
typeReq = req-request 8 | req-requesttype;
switch (le16_to_cpu(typeReq)) {
case DeviceRequest | USB_REQ_GET_DESCRIPTOR:
...
...
case USB_REQ_GET_DESCRIPTOR | ((USB_DIR_IN | USB_RT_HUB) 8):
...
...
}
As in function usb_get_descriptor() in usb.c,
res = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
(type 8) + index, 0,
buf, size, USB_CNTL_TIMEOUT);
req-request will be assigned USB_REQ_GET_DESCRIPTOR,
req-requesttype will be assigned USB_DIR_IN.
The value of typeReq will be 0x680 which can't match any value in
switch (le16_to_cpu(typeReq)) .
Do I miss any config here?
2)
In funcion usb_get_descriptor() in usb.c, it will pass index 0 to
usb_control_msg. setup_packet.index will be assigned 0.
res = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
(type 8) + index, 0,
buf, size, USB_CNTL_TIMEOUT); /* The sixty parameter
is index */
Then in funcion ehci_submit_root() in ehci-hcd.c,
status_reg = (uint32_t *)hcor-or_portsc[le16_to_cpu(req-index) -
1];
(le16_to_cpu(req-index) - 1) will be -1 here.
Is it correct?
Pls correct me.
Thanks a lot in advance.
Yours
Terry
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] zlib: allow 0 as destination pointer
Dear Giuseppe CONDORELLI, In message 001701ca1015$dbf7fae0$c0818...@st.com you wrote: Actually I'm waiting for a new patch that integrates that fix. Maybe I've not understood. Do you mean you are waiting a new zlib patch [v4] that includes Alessandro's patch, to apply only one patch containing all? Yes. It makes no sense to add a known to be broken patch and fix it in a second commit, as this leaves only a state in the tree where attempts to bisect any issues run into problems. So please submit a new, fixed patch, that really works. 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 Applying computer technology is simply finding the right wrench to pound in the correct screw. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] zlib: allow 0 as destination pointer
Dear rhabarber1848, In message h4orm0$l1...@ger.gmane.org you wrote: Actually I'm waiting for a new patch that integrates that fix. please do not commit the zlib-1.2.3 patch in its current state, although Alessandro's patch fixes on bug there is still the problem that the WATCHDOG_RESET() calls from gunzip.c #if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG) s.outcb = (cb_func)WATCHDOG_RESET; #else s.outcb = Z_NULL; #endif/* CONFIG_HW_WATCHDOG */ are silently ignored in the new zlib code. My C knowledge is insufficient to solve this problem. In its current state it will break zlib decompression on the machines I am taking care of. Agreed - that should be working, too, before we pull that patch into 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 Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. - Antoine de Saint-Exupery ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mpc83xx
Dear Kim Phillips, In message 20090727185329.874ef2ae.kim.phill...@freescale.com you wrote: Hi Wolfgang, please pull (mostly) support for the VME8349 board (it's initial patch was posted well in advance of the window) and a couple of fixes: The following changes since commit 94978e19f31d225b4f7d97c4acbac1ecfaeb8f69: Wolfgang Denk (1): Prepare 2009.08-rc1 (again, after fixing last minute issues). are available in the git repository at: git://git.denx.de/u-boot-mpc83xx.git master Kim Phillips (1): mpc83xx: CONFIG_83XX_GENERIC_PCI is now synonymous with CONFIG_PCI; remove the former Paul Gortmaker (1): sbc8349: combine HRCW flash and u-boot image flash Reinhard Arlt (1): mpc83xx: Add esd VME8349 board support MAINTAINERS |2 + MAKEALL |1 + Makefile |2 + board/esd/vme8349/Makefile| 54 board/esd/vme8349/caddy.c | 194 + board/esd/vme8349/caddy.h | 77 ++ board/esd/vme8349/config.mk | 28 ++ board/esd/vme8349/pci.c | 119 board/esd/vme8349/vme8349.c | 140 ++ board/sbc8349/config.mk |2 +- cpu/mpc83xx/Makefile |4 +- doc/README.sbc8349| 30 ++- drivers/pci/pci_auto.c|2 +- include/configs/MPC8313ERDB.h |1 - include/configs/MPC8315ERDB.h |3 +- include/configs/MPC8323ERDB.h |1 - include/configs/MPC832XEMDS.h |1 - include/configs/MPC8349EMDS.h |4 - include/configs/MPC8349ITX.h |1 - include/configs/MPC8360EMDS.h |1 - include/configs/MPC8360ERDK.h |1 - include/configs/MPC837XEMDS.h |3 +- include/configs/MPC837XERDB.h |3 +- include/configs/MVBLM7.h |1 - include/configs/SIMPC8313.h |1 - include/configs/TQM834x.h |1 - include/configs/sbc8349.h |5 +- include/configs/vme8349.h | 608 + 28 files changed, 1254 insertions(+), 36 deletions(-) create mode 100644 board/esd/vme8349/Makefile create mode 100644 board/esd/vme8349/caddy.c create mode 100644 board/esd/vme8349/caddy.h create mode 100644 board/esd/vme8349/config.mk create mode 100644 board/esd/vme8349/pci.c create mode 100644 board/esd/vme8349/vme8349.c create mode 100644 include/configs/vme8349.h Applied, thanks. But please do not reqrite the Subject of committed patches, at least not without specifically mentioning it here. My patch tracking is based on the Subject: lines, and it causes additional work (and eventually introduces errors) when you rename the original (poor,agreed)Subjectmpc83xx:because CONFIG_83XX_GENERIC_PCI is now synonymous with CONFIG_PCI, we remove the former into mpc83xx: CONFIG_83XX_GENERIC_PCI is now synonymous with CONFIG_PCI; remove the former - which is still _way_too_long_, btw. Rather reject the patch and ask for a resubmit. Even from yourself :-) 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 Of course there's no reason for it, it's just our policy. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ppc4xx/master
Dear Stefan Roese, In message 200907280729.23996...@denx.de you wrote: The following changes since commit 10c7604d021949464b1e4ba903df95e6b2f0d2ff: Wolfgang Denk (1): Prepare 2009.08-rc1 are available in the git repository at: git://www.denx.de/git/u-boot-ppc4xx.git master Dirk Eibach (1): ppc4xx: Add GDsys CompactCenter board support. Stefan Roese (4): ppc4xx: Fix Arches DDR2 initialization ppc4xx: Kilauea: Fix SDRAM init in NAND booting version ppc4xx: Add some NAND-booting bootstrap entries to Kilauea chip_config cmd ppc4xx: Fix problem with NOR range assignment in Canyonlands ft_board_setup MAINTAINERS |2 + MAKEALL |2 + Makefile |8 + board/amcc/canyonlands/canyonlands.c | 45 ++-- board/amcc/kilauea/chip_config.c | 24 ++- board/gdsys/compactcenter/Makefile| 53 board/gdsys/compactcenter/chip_config.c | 87 ++ board/gdsys/compactcenter/compactcenter.c | 297 board/gdsys/compactcenter/config.mk | 41 +++ board/gdsys/compactcenter/init.S | 97 +++ board/gdsys/compactcenter/u-boot.lds | 144 ++ include/configs/compactcenter.h | 437 + include/configs/kilauea.h |2 + 13 files changed, 1208 insertions(+), 31 deletions(-) create mode 100644 board/gdsys/compactcenter/Makefile create mode 100644 board/gdsys/compactcenter/chip_config.c create mode 100644 board/gdsys/compactcenter/compactcenter.c create mode 100644 board/gdsys/compactcenter/config.mk create mode 100644 board/gdsys/compactcenter/init.S create mode 100644 board/gdsys/compactcenter/u-boot.lds create mode 100644 include/configs/compactcenter.h Applied, thanks. Ummm.. Stefan, please try to come up with shorter Subject: lines for your patches, please. Especially ppc4xx: Add some NAND-booting bootstrap entries to Kilauea chip_config cmd and ppc4xx: Fix problem with NOR range assignment in Canyonlands ft_board_setup are _way_too_long_! 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 Diplomacy is the art of saying nice doggy until you can find a rock. ___ 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 updated
Dear Heiko Schocher, In message 4a6ed511.6010...@denx.de you wrote: Hello Wolfgang, The following changes since commit 94978e19f31d225b4f7d97c4acbac1ecfaeb8f69: Wolfgang Denk (1): Prepare 2009.08-rc1 (again, after fixing last minute issues). are available in the git repository at: git://git.denx.de/u-boot-i2c.git master Alessandro Rubini (2): arm nomadik: add gpio support arm nomadik: add i2c Heiko Schocher (2): arm, i2c: added support for the TWSI I2C Interface Because twl4030 now has its own device files, move exiting Not pulled again because of this obscure commit. 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 No problem is insoluble. -- Dr. Janet Wallace, The Deadly Years, stardate 3479.4 ___ 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 updated
Hello Wolfgang, Wolfgang Denk wrote: In message 4a6ed511.6010...@denx.de you wrote: Hello Wolfgang, The following changes since commit 94978e19f31d225b4f7d97c4acbac1ecfaeb8f69: Wolfgang Denk (1): Prepare 2009.08-rc1 (again, after fixing last minute issues). are available in the git repository at: git://git.denx.de/u-boot-i2c.git master Alessandro Rubini (2): arm nomadik: add gpio support arm nomadik: add i2c Heiko Schocher (2): arm, i2c: added support for the TWSI I2C Interface Because twl4030 now has its own device files, move exiting Not pulled again because of this obscure commit. Hups ... Sorry ... I look for this issue ... bye Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Update Freescale copyrights to remove All Rights Reserved
Dear Kumar Gala, In message 1248835792-1882-1-git-send-email-kumar.g...@freescale.com you wrote: All Rights Reserved conflicts with the GPL. Signed-off-by: Kumar Gala kumar.g...@freescale.com --- Wolfgang, I would ask that you apply this now rather than later as it just addresses the All Rights Reserved issue and doesn't change any functional code.. Agreed - applied. And thanks a lot! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de SW engineering is a race between programmers trying to make better idiot-proof programs and the universe producing greater idiots. ___ 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 updated v2
Hello Wolfgang,
Heiko Schocher wrote:
Wolfgang Denk wrote:
In message 4a6ed511.6010...@denx.de you wrote:
Hello Wolfgang,
The following changes since commit 94978e19f31d225b4f7d97c4acbac1ecfaeb8f69:
Wolfgang Denk (1):
Prepare 2009.08-rc1 (again, after fixing last minute issues).
are available in the git repository at:
git://git.denx.de/u-boot-i2c.git master
Alessandro Rubini (2):
arm nomadik: add gpio support
arm nomadik: add i2c
Heiko Schocher (2):
arm, i2c: added support for the TWSI I2C Interface
Because twl4030 now has its own device files, move exiting
Not pulled again because of this obscure commit.
Hups ... Sorry ... I look for this issue ...
Here comes the right version ... sorry for the confusion.
The following changes since commit 94978e19f31d225b4f7d97c4acbac1ecfaeb8f69:
Wolfgang Denk (1):
Prepare 2009.08-rc1 (again, after fixing last minute issues).
are available in the git repository at:
git://git.denx.de/u-boot-i2c.git master
Alessandro Rubini (2):
arm nomadik: add gpio support
arm nomadik: add i2c
Heiko Schocher (1):
arm, i2c: added support for the TWSI I2C Interface
Tom Rix (6):
OMAP I2C Fix the sampling clock.
TWL4030 Add initial support
TWL4030 Add power reset button
OMAP3 Move twl4030 power and led functions
OMAP3 Move twl4030 mmc function
OMAP3 Remove twl4030 defines
Makefile |1 +
board/omap3/beagle/beagle.c|4 +-
board/omap3/common/power.c | 74
board/omap3/overo/overo.c |4 +-
board/omap3/pandora/pandora.c |4 +-
board/omap3/zoom1/zoom1.c | 12 +-
board/omap3/zoom2/zoom2.c | 17 +-
board/st/nhk8815/nhk8815.c | 16 +-
cpu/arm926ejs/nomadik/Makefile |2 +-
cpu/arm926ejs/nomadik/gpio.c | 99 +
drivers/i2c/Makefile |1 +
drivers/i2c/kirkwood_i2c.c | 484
drivers/i2c/omap24xx_i2c.c | 74 -
drivers/misc/Makefile |1 +
drivers/misc/twl4030_led.c | 52 +++
drivers/mmc/omap3_mmc.c| 13 +-
{board/omap3/common = drivers/power}/Makefile | 25 +-
drivers/power/twl4030.c| 115 ++
include/asm-arm/arch-nomadik/gpio.h| 42 ++
include/asm-arm/arch-omap24xx/i2c.h| 44 +++
include/asm-arm/arch-omap3/i2c.h | 70 +++-
include/asm-arm/arch-omap3/omap3.h | 35 --
include/configs/nhk8815.h | 18 +-
include/configs/omap3_beagle.h |6 +
include/configs/omap3_evm.h|5 +
include/configs/omap3_overo.h |6 +
include/configs/omap3_pandora.h|6 +
include/configs/omap3_zoom1.h |6 +
include/configs/omap3_zoom2.h |6 +
include/twl4030.h | 401
30 files changed, 1484 insertions(+), 159 deletions(-)
delete mode 100644 board/omap3/common/power.c
create mode 100644 cpu/arm926ejs/nomadik/gpio.c
create mode 100644 drivers/i2c/kirkwood_i2c.c
create mode 100644 drivers/misc/twl4030_led.c
rename {board/omap3/common = drivers/power}/Makefile (67%)
create mode 100644 drivers/power/twl4030.c
create mode 100644 include/asm-arm/arch-nomadik/gpio.h
create mode 100644 include/twl4030.h
bye
heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 2/2] zlib: add watchdog reset call
This patch adds watchdog reset call to allow its invokation during decompression
phase. This control was present on old zlib version and here it is
backported for those relevant routines. This patch is sent as a zlib separate
one beacuse it was not tested due to specific board lack.
zlib patches will be unified just in one when this will be validated through
tests.
Signed-off-by: Giuseppe Condorelli giuseppe.condore...@st.com
---
lib_generic/zlib.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/lib_generic/zlib.c b/lib_generic/zlib.c
index 49fb145..6a78dc9 100644
--- a/lib_generic/zlib.c
+++ b/lib_generic/zlib.c
@@ -1040,6 +1040,8 @@ z_streamp strm;
state-hold = 0;
state-bits = 0;
state-lencode = state-distcode = state-next = state-codes;
+if (strm-outcb != Z_NULL)
+ (*strm-outcb)(Z_NULL, 0);
Tracev((stderr, inflate: reset\n));
return Z_OK;
}
@@ -1950,7 +1952,11 @@ z_streamp strm;
if (strm == Z_NULL || strm-state == Z_NULL || strm-zfree == (free_func)0)
return Z_STREAM_ERROR;
state = (struct inflate_state FAR *)strm-state;
-if (state-window != Z_NULL) ZFREE(strm, state-window);
+if (state-window != Z_NULL) {
+ if (strm-outcb != Z_NULL)
+ (*strm-outcb)(Z_NULL, 0);
+ ZFREE(strm, state-window);
+}
ZFREE(strm, strm-state);
strm-state = Z_NULL;
Tracev((stderr, inflate: end\n));
--
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] zlib: allow 0 as destination pointer
Hi rhabarber1848, please could you test latest two zlib patches I have sent few minutes ago? NOTE: the first one is waiting for approval due to its big size. Thanks, I hope these patches will solve your issue. G. -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wolfgang Denk Sent: Wednesday, July 29, 2009 9:12 AM To: rhabarber1...@web.de Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] zlib: allow 0 as destination pointer Dear rhabarber1848, In message h4orm0$l1...@ger.gmane.org you wrote: Actually I'm waiting for a new patch that integrates that fix. please do not commit the zlib-1.2.3 patch in its current state, although Alessandro's patch fixes on bug there is still the problem that the WATCHDOG_RESET() calls from gunzip.c #if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG) s.outcb = (cb_func)WATCHDOG_RESET; #else s.outcb = Z_NULL; #endif/* CONFIG_HW_WATCHDOG */ are silently ignored in the new zlib code. My C knowledge is insufficient to solve this problem. In its current state it will break zlib decompression on the machines I am taking care of. Agreed - that should be working, too, before we pull that patch into 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 Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. - Antoine de Saint-Exupery ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] zlib: allow 0 as destination pointer
Hi rhabarber1848,
please could you test latest two zlib patches I have sent few minutes ago?
Unfortunately you add outcb() only in inflatestart and inflateend. IT should
also go in the main loop.
Being an out-callback with arguments, it should be called during copy to
output, with proper arguments (and in that form it would be a fix to
the official zlib).
I tried this one, which is a quick hack (no arguments passed, so not
suitable for upstream zlib in any case). Moreover, one of those two
should be sufficient, but I don't know which one exactly. I'm lazy so I
won't trace program flow in detail.
I think rhabarber should test with this addition too and select which one
is the good one.
(formatted for git-am for quick testing, even thought he talk is irrelevant
as a commit message).
ps: please note that your addition of outcb() has white-space inconsistency with
zlib.c (which is not u-boot style while those lines are).
/alessandro
---
lib_generic/zlib.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/lib_generic/zlib.c b/lib_generic/zlib.c
index 6a78dc9..66b18eb 100644
--- a/lib_generic/zlib.c
+++ b/lib_generic/zlib.c
@@ -1129,6 +1129,10 @@ unsigned out;
state = (struct inflate_state FAR *)strm-state;
+/* call watchdog_reset if needed (addition for U-Boot) */
+if (strm-outcb != Z_NULL)
+(*strm-outcb)(Z_NULL, 0);
+
/* if it hasn't been done already, allocate space for the window */
if (state-window == Z_NULL) {
state-window = (unsigned char FAR *)
@@ -1741,6 +1745,8 @@ int flush;
Tracev((stderr, inflate: codes ok\n));
state-mode = LEN;
case LEN:
+if (strm-outcb != Z_NULL) /* for watchdog (U-Boot) */
+(*strm-outcb)(Z_NULL, 0);
if (have = 6 left = 258) {
RESTORE();
inflate_fast(strm, out);
--
1.6.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] zlib: allow 0 as destination pointer
Hi,
Alessandro Rubini wrote:
Giuseppe Condorelli wrote:
Hi rhabarber1848,
please could you test latest two zlib patches I have sent few minutes
ago?
Unfortunately you add outcb() only in inflatestart and inflateend. IT
should also go in the main loop.
you are right. The two patches sent by Giuseppe do not solve the problem.
I think rhabarber should test with this addition too and select which one
is the good one.
Let's see:
--- a/lib_generic/zlib.c
+++ b/lib_generic/zlib.c
@@ -1129,6 +1129,10 @@ unsigned out;
state = (struct inflate_state FAR *)strm-state;
+/* call watchdog_reset if needed (addition for U-Boot) */
+if (strm-outcb != Z_NULL)
+(*strm-outcb)(Z_NULL, 0);
+
/* if it hasn't been done already, allocate space for the window */
if (state-window == Z_NULL) {
state-window = (unsigned char FAR *)
This patch does not fix the problem.
@@ -1741,6 +1745,8 @@ int flush;
Tracev((stderr, inflate: codes ok\n));
state-mode = LEN;
case LEN:
+if (strm-outcb != Z_NULL) /* for watchdog (U-Boot) */
+(*strm-outcb)(Z_NULL, 0);
if (have = 6 left = 258) {
RESTORE();
inflate_fast(strm, out);
This patch alone seems to solve the problem, only with it U-Boot could
decompress a Linux image, proven with 10 successful boot attempts. All the
other patches regarding WATCHDOG_RESET() can be ignored.
Tested with U-Boot 2008.09-rc1, the original zlib123-patch from Giuseppe +
your allow 0 as destination pointer-patch and the last patch from the
mail quoted above.
Cheers, rhabarber1848
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] zlib: allow 0 as destination pointer
Hi rhbarber1848,
I've merged patches into one only and resent it to list (v5).
Please verify once more the issue is solved, to close it definitively.
Cheers and thanks,
Giuseppe
-Original Message-
From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On
Behalf Of rhabarber1848
Sent: Wednesday, July 29, 2009 12:33 PM
To: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] zlib: allow 0 as destination pointer
Hi,
Alessandro Rubini wrote:
Giuseppe Condorelli wrote:
Hi rhabarber1848,
please could you test latest two zlib patches I have sent few minutes
ago?
Unfortunately you add outcb() only in inflatestart and inflateend. IT
should also go in the main loop.
you are right. The two patches sent by Giuseppe do not solve the problem.
I think rhabarber should test with this addition too and select which one
is the good one.
Let's see:
--- a/lib_generic/zlib.c
+++ b/lib_generic/zlib.c
@@ -1129,6 +1129,10 @@ unsigned out;
state = (struct inflate_state FAR *)strm-state;
+/* call watchdog_reset if needed (addition for U-Boot) */
+if (strm-outcb != Z_NULL)
+(*strm-outcb)(Z_NULL, 0);
+
/* if it hasn't been done already, allocate space for the window */
if (state-window == Z_NULL) {
state-window = (unsigned char FAR *)
This patch does not fix the problem.
@@ -1741,6 +1745,8 @@ int flush;
Tracev((stderr, inflate: codes ok\n));
state-mode = LEN;
case LEN:
+if (strm-outcb != Z_NULL) /* for watchdog (U-Boot) */
+(*strm-outcb)(Z_NULL, 0);
if (have = 6 left = 258) {
RESTORE();
inflate_fast(strm, out);
This patch alone seems to solve the problem, only with it U-Boot could
decompress a Linux image, proven with 10 successful boot attempts. All the
other patches regarding WATCHDOG_RESET() can be ignored.
Tested with U-Boot 2008.09-rc1, the original zlib123-patch from Giuseppe +
your allow 0 as destination pointer-patch and the last patch from the
mail quoted above.
Cheers, rhabarber1848
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dlmalloc: Ignore gcc4.4 compiler warnings
On Wed, 2009-07-29 at 07:47 +0200, Wolfgang Denk wrote: Dear Scott, In message 20090728225244.ga8...@b07421-ec1.am.freescale.net you wrote: The patch title is bad -- it's not disabling warnings, it's disabling an aspect of C99 that the code is incompatible with (and which is pretty questionable in the first place with such low level code). Note that in Linux, this is disabled for the entire kernel. I know. But Linux is bigger than U-Boot, and I think we should be able to fix the few isolated places that throw such warnings. As things stand, GCC may do bad things with that code. With this patch, it may not (at least not this particular sort of bad thing). Those bad things are not limited to the places where it warns -- those are just the violations it detected. Agreed, and that's why I want to see this fixed. Personally I feel this optimization to be in the luxury category. I'm not sure it's worth the trouble in a project like u-boot. Maybe it should be default off and only turned on for specific modules. like checksum and compression stuff. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mpc83xx
On Wed, Jul 29, 2009 at 2:21 AM, Wolfgang Denkw...@denx.de wrote: My patch tracking is based on the Subject: lines, and it causes additional work (and eventually introduces errors) when you rename Do you use Patchworks? I don't know if it handles renamed patches, but a public patchworks web page would allow other people to tag their patches for you. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: amcc: Set CONFIG_SYS_BOOTMAPSZ to 16MB to enable booting of big kernels
This patch changes CONFIG_SYS_BOOTMAPSZ from 8MB to 16MB which is the initial TLB on 40x PPC's in the Linux kernel. With this change even bigger Linux kernels ( 8MB) can be booted. Signed-off-by: Stefan Roese s...@denx.de --- include/configs/amcc-common.h |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/include/configs/amcc-common.h b/include/configs/amcc-common.h index 3b733c0..e82b5ed 100644 --- a/include/configs/amcc-common.h +++ b/include/configs/amcc-common.h @@ -137,10 +137,10 @@ /* * For booting Linux, the board info and command line data - * have to be in the first 8 MB of memory, since this is - * the maximum mapped by the Linux kernel during initialization. + * have to be in the first 16 MB of memory, since this is + * the maximum mapped by the 40x Linux kernel during initialization. */ -#define CONFIG_SYS_BOOTMAPSZ (8 20) /* Initial Memory map for Linux */ +#define CONFIG_SYS_BOOTMAPSZ (16 20) /* Initial Memory map for Linux */ /* * Internal Definitions -- 1.6.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: amcc: Move kernel_addr_r etc to higher locations ( 16MB)
This patch moves the load addresses for kernel, fdt and ramdisk to higher
addresses (= 16MB). This enables booting of bigger kernel images (e.g.
lockdep enabled).
Signed-off-by: Stefan Roese s...@denx.de
---
include/configs/amcc-common.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/configs/amcc-common.h b/include/configs/amcc-common.h
index e82b5ed..70b2d3d 100644
--- a/include/configs/amcc-common.h
+++ b/include/configs/amcc-common.h
@@ -214,9 +214,9 @@
console= xstr(CONFIG_USE_TTY) ,${baudrate}\0 \
CONFIG_ADDMISC \
initrd_high=3000\0\
- kernel_addr_r=40\0\
- fdt_addr_r=80\0 \
- ramdisk_addr_r=C0\0 \
+ kernel_addr_r=100\0 \
+ fdt_addr_r=180\0 \
+ ramdisk_addr_r=190\0 \
hostname= xstr(CONFIG_HOSTNAME) \0 \
bootfile= xstr(CONFIG_HOSTNAME) /uImage\0 \
ramdisk_file= xstr(CONFIG_HOSTNAME) /uRamdisk\0 \
--
1.6.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: Canyonlands-NAND-boot: Support 2 Crucial 512MByte SODIMM's
Some Canyonlands boards are equipped with different SODIMM's. This is no
problem with the normal NOR booting Canyonlands U-Boot, since it
automatically detects the SODIMM's via SPD data and correctly configures
them. But the NAND booting version is different. Here we only have 4k
of image size to completely setup the hardware, including DDR2 setup.
So we need to use a fixed DDR2 setup here. This doesn't work for different
SODIMM's right now.
Currently only this Crucial SODIMM is support:
CT6464AC667.8FB (dual ranked)
Now some boards are shipped with this SODIMM:
CT6464AC667.4FE (single ranked)
This patch now supports both SODIMM's by configuring first for the dual
ranked DIMM. A quick shows, if this module is really installed. If this test
fails, the DDR2 controller is re-configured for the single
ranked SODIMM.
Tested with those SODIMM's:
CT6464AC667.8FB (dual ranked)
CT6464AC667.4FE (single ranked)
Signed-off-by: Stefan Roese s...@denx.de
---
nand_spl/board/amcc/canyonlands/ddr2_fixed.c | 79 +-
1 files changed, 65 insertions(+), 14 deletions(-)
diff --git a/nand_spl/board/amcc/canyonlands/ddr2_fixed.c
b/nand_spl/board/amcc/canyonlands/ddr2_fixed.c
index 371bbb3..ed1888c 100644
--- a/nand_spl/board/amcc/canyonlands/ddr2_fixed.c
+++ b/nand_spl/board/amcc/canyonlands/ddr2_fixed.c
@@ -1,5 +1,5 @@
/*
- * (C) Copyright 2008
+ * (C) Copyright 2008-2009
* Stefan Roese, DENX Software Engineering, s...@denx.de.
*
* See file CREDITS for list of people who contributed to this
@@ -26,6 +26,17 @@
#include asm/io.h
#include asm/processor.h
+/*
+ * This code can configure those two Crucial SODIMM's:
+ *
+ * Crucial CT6464AC667.4FE - 512MB SO-DIMM (single rank)
+ * Crucial CT6464AC667.8FB - 512MB SO-DIMM (dual rank)
+ *
+ */
+
+#define TEST_ADDR 0x1000
+#define TEST_MAGIC 0x11223344
+
static void wait_init_complete(void)
{
u32 val;
@@ -35,7 +46,13 @@ static void wait_init_complete(void)
} while (!(val 0x8000));
}
-phys_size_t initdram(int board_type)
+static void ddr_start(void)
+{
+ mtsdram(SDRAM_MCOPT2, 0x2800);
+ wait_init_complete();
+}
+
+static void ddr_init_common(void)
{
/*
* Reset the DDR-SDRAM controller.
@@ -49,17 +66,12 @@ phys_size_t initdram(int board_type)
* enabled. This will only work for the same memory
* configuration as used here:
*
-* Crucial CT6464AC667.8FB - 512MB SO-DIMM
-*
*/
mtsdram(SDRAM_MCOPT2, 0x);
- mtsdram(SDRAM_MCOPT1, 0x05122000);
mtsdram(SDRAM_MODT0, 0x0100);
- mtsdram(SDRAM_CODT, 0x02800021);
mtsdram(SDRAM_WRDTR, 0x82000823);
mtsdram(SDRAM_CLKTR, 0x4000);
mtsdram(SDRAM_MB0CF, 0x0201);
- mtsdram(SDRAM_MB1CF, 0x0201);
mtsdram(SDRAM_RTR, 0x0618);
mtsdram(SDRAM_SDTR1, 0x80201000);
mtsdram(SDRAM_SDTR2, 0x42103243);
@@ -82,17 +94,56 @@ phys_size_t initdram(int board_type)
mtsdram(SDRAM_INITPLR13, 0x80810040);
mtsdram(SDRAM_INITPLR14, 0x);
mtsdram(SDRAM_INITPLR15, 0x);
-
- mtsdram(SDRAM_MCOPT2, 0x2800);
-
- wait_init_complete();
+ mtsdram(SDRAM_RDCC, 0x4000);
+ mtsdram(SDRAM_RQDC, 0x8038);
+ mtsdram(SDRAM_RFDC, 0x0257);
mtdcr(SDRAM_R0BAS, 0xF800); /* MQ0_B0BAS */
mtdcr(SDRAM_R1BAS, 0x0400F800); /* MQ0_B1BAS */
+}
- mtsdram(SDRAM_RDCC, 0x4000);
- mtsdram(SDRAM_RQDC, 0x8038);
- mtsdram(SDRAM_RFDC, 0x0257);
+phys_size_t initdram(int board_type)
+{
+ /*
+* First try init for this module:
+*
+* Crucial CT6464AC667.8FB - 512MB SO-DIMM (dual rank)
+*/
+
+ ddr_init_common();
+
+ /*
+* Crucial CT6464AC667.8FB - 512MB SO-DIMM
+*/
+ mtdcr(SDRAM_R0BAS, 0xF800);
+ mtdcr(SDRAM_R1BAS, 0x0400F800);
+ mtsdram(SDRAM_MCOPT1, 0x05122000);
+ mtsdram(SDRAM_CODT, 0x02800021);
+ mtsdram(SDRAM_MB1CF, 0x0201);
+
+ ddr_start();
+
+ /*
+* Now test if the dual-ranked module is really installed
+* by checking an address in the upper 256MByte region
+*/
+ out_be32((void *)TEST_ADDR, TEST_MAGIC);
+ if (in_be32((void *)TEST_ADDR) != TEST_MAGIC) {
+ /*
+* The test failed, so we assume that the single
+* ranked module is installed:
+*
+* Crucial CT6464AC667.4FE - 512MB SO-DIMM (single rank)
+*/
+
+ ddr_init_common();
+
+ mtdcr(SDRAM_R0BAS, 0xF000);
+ mtsdram(SDRAM_MCOPT1, 0x05322000);
+ mtsdram(SDRAM_CODT, 0x00800021);
+
+ ddr_start();
+ }
return CONFIG_SYS_MBYTES_SDRAM 20;
}
--
1.6.3.4
___
U-Boot mailing list
[U-Boot] [PATCH] ppc4xx: Add basic support for AMCC PPC460EX/460GT rev B chips
This patch is based on a diff created by Phong Vo from AMCC. Signed-off-by: Phong Vo p...@amcc.com Signed-off-by: Stefan Roese s...@denx.de --- cpu/ppc4xx/cpu.c| 23 +++ include/asm-ppc/processor.h |2 ++ include/ppc440.h|5 + 3 files changed, 30 insertions(+), 0 deletions(-) diff --git a/cpu/ppc4xx/cpu.c b/cpu/ppc4xx/cpu.c index e12a784..e9861ab 100644 --- a/cpu/ppc4xx/cpu.c +++ b/cpu/ppc4xx/cpu.c @@ -285,6 +285,9 @@ int checkcpu (void) uint pvr = get_pvr(); ulong clock = gd-cpu_clk; char buf[32]; +#if defined(CONFIG_460EX) || defined(CONFIG_460GT) + u32 reg; +#endif #if !defined(CONFIG_IOP480) char addstr[64] = ; @@ -526,6 +529,7 @@ int checkcpu (void) strcpy(addstr, No RAID 6 support); break; +#if defined(CONFIG_460EX) || defined(CONFIG_460GT) case PVR_460EX_RA: puts(EX Rev. A); strcpy(addstr, No Security/Kasumi support); @@ -536,6 +540,15 @@ int checkcpu (void) strcpy(addstr, Security/Kasumi support); break; + case PVR_460EX_RB: + puts(EX Rev. B); + mfsdr(SDR0_ECID3, reg); + if (reg 0x0010) + strcpy(addstr, No Security/Kasumi support); + else + strcpy(addstr, Security/Kasumi support); + break; + case PVR_460GT_RA: puts(GT Rev. A); strcpy(addstr, No Security/Kasumi support); @@ -546,6 +559,16 @@ int checkcpu (void) strcpy(addstr, Security/Kasumi support); break; + case PVR_460GT_RB: + puts(GT Rev. B); + mfsdr(SDR0_ECID3, reg); + if (reg 0x0010) + strcpy(addstr, No Security/Kasumi support); + else + strcpy(addstr, Security/Kasumi support); + break; +#endif + case PVR_460SX_RA: puts(SX Rev. A); strcpy(addstr, Security support); diff --git a/include/asm-ppc/processor.h b/include/asm-ppc/processor.h index 2c0c0ce..2841104 100644 --- a/include/asm-ppc/processor.h +++ b/include/asm-ppc/processor.h @@ -883,8 +883,10 @@ #define PVR_440SPe_RB 0x53521891 /* 440SPe rev B without RAID 6 support */ #define PVR_460EX_SE_RA0x130218A2 /* 460EX rev A with Security Engine */ #define PVR_460EX_RA 0x130218A3 /* 460EX rev A without Security Engine */ +#define PVR_460EX_RB 0x130218A4 /* 460EX rev B with and without Sec Eng*/ #define PVR_460GT_SE_RA0x130218A0 /* 460GT rev A with Security Engine */ #define PVR_460GT_RA 0x130218A1 /* 460GT rev A without Security Engine */ +#define PVR_460GT_RB 0x130218A5 /* 460GT rev B with and without Sec Eng*/ #define PVR_460SX_RA0x13541800 /* 460SX rev A */ #define PVR_460SX_RA_V1 0x13541801 /* 460SX rev A Variant 1 Security disabled */ #define PVR_460GX_RA0x13541802 /* 460GX rev A */ diff --git a/include/ppc440.h b/include/ppc440.h index 6ce53a6..e6dc740 100644 --- a/include/ppc440.h +++ b/include/ppc440.h @@ -1156,6 +1156,11 @@ #define SDR0_PFC1_SIS_SCP_SEL 0x /* SCP Selected */ #define SDR0_PFC1_SIS_IIC1_SEL 0x0002 /* IIC1 Selected */ +#define SDR0_ECID0 0x0080 +#define SDR0_ECID1 0x0081 +#define SDR0_ECID2 0x0082 +#define SDR0_ECID3 0x0083 + /* Ethernet PLL Configuration Register (SDR0_ETH_PLL) */ #define SDR0_ETH_PLL 0x4102 #define SDR0_ETH_PLL_PLLLOCK0x8000 /*Ethernet PLL lock indication*/ -- 1.6.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: Add support for PPC460EX/460GT rev B chip to AMCC Canyonlands
This patch is based on a diff created by Phong Vo from AMCC.
Signed-off-by: Phong Vo p...@amcc.com
Signed-off-by: Stefan Roese s...@denx.de
---
board/amcc/canyonlands/canyonlands.c | 26 +-
1 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/board/amcc/canyonlands/canyonlands.c
b/board/amcc/canyonlands/canyonlands.c
index 5071c8d..710a0af 100644
--- a/board/amcc/canyonlands/canyonlands.c
+++ b/board/amcc/canyonlands/canyonlands.c
@@ -94,13 +94,23 @@ static inline void board_cpld_write(int offset, int data)
out_8((void *)(CONFIG_SYS_CPLD_ADDR), offset);
out_8((void *)(CONFIG_SYS_CPLD_DATA), data);
}
+#else
+static int pvr_460ex(void)
+{
+ u32 pvr = get_pvr();
+
+ if ((pvr == PVR_460EX_RA) || (pvr == PVR_460EX_SE_RA) ||
+ (pvr == PVR_460EX_RB))
+ return 1;
+
+ return 0;
+}
#endif /* defined(CONFIG_ARCHES) */
int board_early_init_f(void)
{
#if !defined(CONFIG_ARCHES)
u32 sdr0_cust0;
- u32 pvr = get_pvr();
#endif
/*
@@ -175,7 +185,7 @@ int board_early_init_f(void)
mtdcr(AHB_TOP, 0x804B);
mtdcr(AHB_BOT, 0x804B);
- if ((pvr == PVR_460EX_RA) || (pvr == PVR_460EX_SE_RA)) {
+ if (pvr_460ex()) {
/*
* Configure USB-STP pins as alternate and not GPIO
* It seems to be neccessary to configure the STP pins as GPIO
@@ -234,17 +244,16 @@ int get_cpu_num(void)
int checkboard(void)
{
char *s = getenv(serial#);
- u32 pvr = get_pvr();
- if ((pvr == PVR_460GT_RA) || (pvr == PVR_460GT_SE_RA)) {
- printf(Board: Glacier - AMCC PPC460GT Evaluation Board);
- gd-board_type = BOARD_GLACIER;
- } else {
+ if (pvr_460ex()) {
printf(Board: Canyonlands - AMCC PPC460EX Evaluation Board);
if (in_8((void *)(CONFIG_SYS_BCSR_BASE + 3))
CONFIG_SYS_BCSR3_PCIE)
gd-board_type = BOARD_CANYONLANDS_PCIE;
else
gd-board_type = BOARD_CANYONLANDS_SATA;
+ } else {
+ printf(Board: Glacier - AMCC PPC460GT Evaluation Board);
+ gd-board_type = BOARD_GLACIER;
}
switch (gd-board_type) {
@@ -498,7 +507,6 @@ int misc_init_r(void)
{
u32 sdr0_srst1 = 0;
u32 eth_cfg;
- u32 pvr = get_pvr();
u8 val;
/*
@@ -513,7 +521,7 @@ int misc_init_r(void)
/* Set the for 2 RGMII mode */
/* GMC0 EMAC4_0, GMC0 EMAC4_1, RGMII Bridge 0 */
eth_cfg = ~SDR0_ETH_CFG_GMC0_BRIDGE_SEL;
- if ((pvr == PVR_460EX_RA) || (pvr == PVR_460EX_SE_RA))
+ if (pvr_460ex())
eth_cfg |= SDR0_ETH_CFG_GMC1_BRIDGE_SEL;
else
eth_cfg = ~SDR0_ETH_CFG_GMC1_BRIDGE_SEL;
--
1.6.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mpc83xx
Dear Timur Tabi, In message ed82fe3e0907290717p2584db95l5fdf5cfa60cb6...@mail.gmail.com you wrote: On Wed, Jul 29, 2009 at 2:21 AM, Wolfgang Denkw...@denx.de wrote: My patch tracking is based on the Subject: =A0lines, =A0and =A0it =A0ca= uses additional =A0work =A0(and =A0eventually introduces errors) when you rena= me Do you use Patchworks? I don't know if it handles renamed patches, but a public patchworks web page would allow other people to tag their patches for you. No, I use the mark message unseen feature of my mail reader (exmh). 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 On a clear disk you can seek forever. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: amcc: Set CONFIG_SYS_BOOTMAPSZ to 16MB to enable booting of big kernels
Hi Stefan, On Wed, 2009-07-29 at 16:25 +0200, Stefan Roese wrote: This patch changes CONFIG_SYS_BOOTMAPSZ from 8MB to 16MB which is the initial TLB on 40x PPC's in the Linux kernel. With this change even bigger Linux kernels ( 8MB) can be booted. Might be nice to increase CONFIG_SYS_BOOTM_LEN at the same time. Or maybe something along the lines of changing CONFIG_SYS_BOOTM_LEN to be based on CONFIG_SYS_BOOTMAPSZ in general as (at a glance) it looks like they should generally be the same value. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 0/3] uboot-doc User's Manual Generation Tool
On Tue, 2009-07-28 at 23:27 +0200, Wolfgang Denk wrote: Dear John, in message 1248813631.3915.102.ca...@johns you wrote: It seems to me that DUTS is designed to test U-Boot and also automates the running of commands whose output can be put online in the DULG. I Correct. And the DULG itself is a wiki (TWiki at the moment, to be converted to Foswiki ASAP) based framework which holds the static parts of the documentation. didn't notice any documented procedure on how to turn the DULG into XML, extensible PDFs, etc. It also seems as if the DULG is a combination of hand-edited wiki pages as well as the DUTS output? I was hoping to You probably can export the DULG into XML, too - but what would that be good for? At the moment we export it into PDF, PostScript, HTML and plain text. Exporting to XML (and specifically DocBook XML, which is widely supported and accepted as a standard (at least that's what the tech writer next to me says :) ) is, I feel, a key to this whole process. Since XML doesn't specify a style, but rather what the content *means*, style sheets can be designed to turn the DocBook XML into anything, in any format, rearranged in any way, and with any style (fonts, colors, graphics). Again, I'm not familiar with the process you use to export HTML to PFD, PS, etc. but I'm guessing that the formatting and style end up being very similar. develop a system that's completely automated. I also noticed in a quick Hm... completely automated is a nice buzzword, but you still have to write the documentation in the first place. You're in luck, I've already volunteered to write it in the first place :) and much of it is already done. Take a look at the manual posted on the X-ES website and see for yourself. http://www.xes-inc.com/sources/u-boot/xpedite5370.pdf This manual was completely generated with my tool. The nice thing of the wiki based approach is that you can have a (even random) collection of pages which can be linearized and brought into arbitrary sets of linear doucumentation - this is what the WebOrder pages are good for - see http://www.denx.de/wiki/DULG/WebOrder So you can use the same set of wiki pages an genreate for example the full fledged manual, a short version including only the most significant topics and an extended version including other stuff that is normally not part of the manual - all from the same envrionment. This is definitely possible with DocBook XML. For those who care, I'm thinking the @role attribute available in standard DocBook, though there may be a better way. I'll talk this through with our tech writers. probe around that a few items in the DULG seem to be out of sync (imd vs. i2c md, source vs. autoscr, etc.) and DHCP seems to be out of date as well. Is the process for updating the DULG automatic? If so, how is it done? Soemone still has to write the documentation - and this is not always done in sync with the code. Your approach of including the documentation with the source code makes it more likely that one remebers to update the docs as well, but just remember how many places there are where code and comments don't agree - it's no guarantee either. I would guess someone is several dozen times more likely to update a documentation snippet in the source over modifying a Wiki page. If you find such areas in the DULG that are out of sync or missing please feel free to add them - everybody can contribute and modify the pages or add new content. And everyboidy can modify and extend the DUTS test cases, too. As I mentioned, I borrowed this idea from the kernel-doc script in Linux, which does do API documentation. But my hope for the uboot-doc tool would be to create user documentation, or a manual we'd provide to a customer when they purchased a product that would describe available commands, environment variables, common operations, etc. That's what the DULG does, so you are truely duplicating efforts. As I mentioned earlier, it seems to me that most vendors are creating their own manuals. That either means knowledge of the existence of DULG is limited, or the tool isn't meeting people's needs. In order to use it, you need to download a completely separate package (DUTS), learn to use it, then hand edit the output into a Wiki page. The advantage with a documentation engine distributed with the sources is that there is no learning curve. make pdf creates a perfectly suitable PDF manual, and with a little work (first time only) they can make it look like anything and chug out manuals for all their boards in minutes. Your approach may be suitable for standard documents, but in many years of working with U-Boot (and Linux) we found that it does not work so well with the specific needs we have for a User's Manual. One issue is that you have to support many different boards (well, maybe not you as a user, but we as a
Re: [U-Boot] [PATCH] ppc4xx: amcc: Set CONFIG_SYS_BOOTMAPSZ to 16MB to enable booting of big kernels
Hi Peter, On Wednesday 29 July 2009 16:36:17 Peter Tyser wrote: This patch changes CONFIG_SYS_BOOTMAPSZ from 8MB to 16MB which is the initial TLB on 40x PPC's in the Linux kernel. With this change even bigger Linux kernels ( 8MB) can be booted. Might be nice to increase CONFIG_SYS_BOOTM_LEN at the same time. Or maybe something along the lines of changing CONFIG_SYS_BOOTM_LEN to be based on CONFIG_SYS_BOOTMAPSZ in general as (at a glance) it looks like they should generally be the same value. I never tuned CONFIG_SYS_BOOTM_LEN before. But you are right, this should be changed as well. I'll wait a short while for further comments on this and send an updated patch version then. 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] Is it an error in function ehci_submit_root() in ehci-hcd.c
Hi,
2009/7/29 Lv Terry-R65388 rui...@freescale.com:
Hi All,
I'm trying to enable ehci usb in our board and I found that there
maybe two issues in funcion ehci_submit_root() in ehci-hcd.c.
1)
In ehci_submit_root(), the function will do the following operation.
From line 553 in ehci-hcd.c:
typeReq = req-request 8 | req-requesttype;
switch (le16_to_cpu(typeReq)) {
case DeviceRequest | USB_REQ_GET_DESCRIPTOR:
...
...
case USB_REQ_GET_DESCRIPTOR | ((USB_DIR_IN | USB_RT_HUB) 8):
...
...
}
As in function usb_get_descriptor() in usb.c,
res = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
(type 8) + index, 0,
buf, size, USB_CNTL_TIMEOUT);
req-request will be assigned USB_REQ_GET_DESCRIPTOR,
req-requesttype will be assigned USB_DIR_IN.
The value of typeReq will be 0x680 which can't match any value in
switch (le16_to_cpu(typeReq)) .
In current mainline this le16_to_cpu() macro has been removed.
Does that change anything?
Do I miss any config here?
I guess not.
2)
In funcion usb_get_descriptor() in usb.c, it will pass index 0 to
usb_control_msg. setup_packet.index will be assigned 0.
res = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
(type 8) + index, 0,
buf, size, USB_CNTL_TIMEOUT); /* The sixty parameter
is index */
Then in funcion ehci_submit_root() in ehci-hcd.c,
status_reg = (uint32_t *)hcor-or_portsc[le16_to_cpu(req-index) -
1];
(le16_to_cpu(req-index) - 1) will be -1 here.
Is it correct?
Nice catch!
Prafulla/Michael, what do you think?
Kind Regards,
Remy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Is it an error in function ehci_submit_root() in ehci-hcd.c
Remy Bohmer wrote:
Hi,
2009/7/29 Lv Terry-R65388 rui...@freescale.com:
Hi All,
I'm trying to enable ehci usb in our board and I found that there
maybe two issues in funcion ehci_submit_root() in ehci-hcd.c.
1)
In ehci_submit_root(), the function will do the following operation.
From line 553 in ehci-hcd.c:
typeReq = req-request 8 | req-requesttype;
switch (le16_to_cpu(typeReq)) {
case DeviceRequest | USB_REQ_GET_DESCRIPTOR:
...
...
case USB_REQ_GET_DESCRIPTOR | ((USB_DIR_IN | USB_RT_HUB) 8):
...
...
}
As in function usb_get_descriptor() in usb.c,
res = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
(type 8) + index, 0,
buf, size, USB_CNTL_TIMEOUT);
req-request will be assigned USB_REQ_GET_DESCRIPTOR,
req-requesttype will be assigned USB_DIR_IN.
The value of typeReq will be 0x680 which can't match any value in
switch (le16_to_cpu(typeReq)) .
In current mainline this le16_to_cpu() macro has been removed.
Does that change anything?
Do I miss any config here?
I guess not.
2)
In funcion usb_get_descriptor() in usb.c, it will pass index 0 to
usb_control_msg. setup_packet.index will be assigned 0.
res = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
(type 8) + index, 0,
buf, size, USB_CNTL_TIMEOUT); /* The sixty parameter
is index */
Then in funcion ehci_submit_root() in ehci-hcd.c,
status_reg = (uint32_t *)hcor-or_portsc[le16_to_cpu(req-index) -
1];
(le16_to_cpu(req-index) - 1) will be -1 here.
Is it correct?
Nice catch!
Prafulla/Michael, what do you think?
That we need a patch here urgent :).
Terry, Can you provide the proper fix?
Michael
Kind Regards,
Remy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] zlib: updated to v.1.2.3
Giuseppe CONDORELLI wrote: This patch updates zlib to the latest stable version. Hi, this patch finally works for me, thank you. Reviewed-by: rhabarber1848 rhabarber1...@web.de Cheers, rhabarber1848 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Is it an error in function ehci_submit_root() in ehci-hcd.c
-Original Message-
From: Michael Trimarchi [mailto:trimar...@gandalf.sssup.it]
Sent: Wednesday, July 29, 2009 8:41 PM
To: Remy Bohmer
Cc: Lv Terry-R65388; Prafulla Wadaskar; u-boot@lists.denx.de
Subject: Re: [U-Boot] Is it an error in function
ehci_submit_root() in ehci-hcd.c
Remy Bohmer wrote:
Hi,
2009/7/29 Lv Terry-R65388 rui...@freescale.com:
Hi All,
I'm trying to enable ehci usb in our board and I found
that there
maybe two issues in funcion ehci_submit_root() in ehci-hcd.c.
1)
In ehci_submit_root(), the function will do the
following operation.
From line 553 in ehci-hcd.c:
typeReq = req-request 8 | req-requesttype;
switch (le16_to_cpu(typeReq)) {
case DeviceRequest | USB_REQ_GET_DESCRIPTOR:
...
...
case USB_REQ_GET_DESCRIPTOR | ((USB_DIR_IN | USB_RT_HUB) 8):
...
...
}
As in function usb_get_descriptor() in usb.c,
res = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
(type 8) + index, 0,
buf, size, USB_CNTL_TIMEOUT);
req-request will be assigned USB_REQ_GET_DESCRIPTOR,
req-requesttype will be assigned USB_DIR_IN.
The value of typeReq will be 0x680 which can't match
any value in
switch (le16_to_cpu(typeReq)) .
In current mainline this le16_to_cpu() macro has been removed.
Does that change anything?
Do I miss any config here?
I guess not.
2)
In funcion usb_get_descriptor() in usb.c, it will pass
index 0 to
usb_control_msg. setup_packet.index will be assigned 0.
res = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
(type 8) + index, 0,
buf, size, USB_CNTL_TIMEOUT); /* The sixty
parameter is index */
Then in funcion ehci_submit_root() in ehci-hcd.c,
status_reg = (uint32_t
*)hcor-or_portsc[le16_to_cpu(req-index)
- 1];
(le16_to_cpu(req-index) - 1) will be -1 here.
Is it correct?
Nice catch!
Prafulla/Michael, what do you think?
Hi Terry
BTW: Which is your board?
Is it big endian machine? I am curious about it :)
Regards..
Prafulla . . .
That we need a patch here urgent :).
Terry, Can you provide the proper fix?
Michael
Kind Regards,
Remy
___
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 10:49 PM To: Jean-Christophe PLAGNIOL-VILLARD Cc: U-Boot; Ben Warren Subject: Re: [U-Boot] ARM Pull Request Dear Jean-Christophe PLAGNIOL-VILLARD, In message 20090722234335.gi19...@game.jcrosoft.org you wrote: Or do you have mnore stuff queued? If so, when will it be ready for pulling? Ilya Yanok patch which need ack from Scoot and Ben a at91rm9200 cleanup which cant wait a after rc1 as I want to test it on rm9200ek this WE and maybe few other fix patch we can be handle later Um... nothing else? What about all the pending OMAP3 patches? but I would like we include Alessandro patch and Prafulla kwimage for this release not necessarely before rc1 Please leave the kwimage patch for me; this is not ARM related, but affects pretty much global code only. Dear Wolfgang Hopefully you might have received my new patch series (posted 30 hours back) I know it's very busy time for you. But that's my wish to see this stuff in. Please let me know your valued feedback so that I can help to get this stuff IN this release. FYI: I tried to fulfill all points raised by you in earlier feedback. Also some code reused from image.c/h for kwbimage in clean way Though the entire resulting code will look different since there are lot changes, I tired to maintain smaller patches for easy understanding and acceptance Regards.. Prafulla . . 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 conservative is a man who believes that nothing should be done for the first time. - Alfred E. Wiggam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND booting of MPC8313 based Custom board
On Wed, Jul 29, 2009 at 10:05:45PM +0530, Rupesh Kumar wrote: I am using u-boot version 1.3.0 included in freescale LTIB released for MPC8313ERDB custom board. I tried NAND booting of MPC8313ERDB board using this u-boot and it worked fine. Using similar procedure i tried NAND boot on my custom board but it dint work :( My board has large page NAND where as MPC8313ERDB has small page NAND. I have modified all the parameters required for Large page NAND. It prints initail debug message as shown below and then while copying u-boot code from NAND to DDR it detects NAND blocks as bad block and continuously prints 'B' on Console. NAND SPL - U-Boot 1.3.0 (Jul 30 2009 - 06:33:05) MPC83XX Loading from NAND : B Can any one please tell what could be going wrong? Am i missing something in large page NAND initialization? Please try the current upstream u-boot rather than the BSP version. Large page support in the mpc8313erdb BSP is likely broken. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND booting of MPC8313 based Custom board
Dear Rupesh Kumar, In message of532b0371.e31eb889-on65257602.0059777c-65257602.005a0...@lntemsys.com you wrote: I am using u-boot version 1.3.0 included in freescale LTIB released for MPC8313ERDB custom board. I tried NAND booting of MPC8313ERDB board using this u-boot and it worked fine. U-Boot 1.3.0 is very old. Please try top of tree (v2009.08-rc1). 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 Philosophy: A route of many roads leading from nowhere to nothing. - Ambrose Bierce ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM Pull Request
Dear Prafulla Wadaskar, In message 73173d32e9439e4abb5151606c3e19e202de13c...@sc-vexch1.marvell.com you wrote: Hopefully you might have received my new patch series (posted 30 hours back) I know it's very busy time for you. I received it, but did not have time for a thorough review yet. Sorry. But that's my wish to see this stuff in. Please let me know your valued feedback so that I can help to get this stuff IN this release. That hould work out well. We still have sufficient time. FYI: I tried to fulfill all points raised by you in earlier feedback. Also some code reused from image.c/h for kwbimage in clean way Though the entire resulting code will look different since there are lot changes, I tired to maintain smaller patches for easy understanding and acceptance 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 ...and the fully armed nuclear warheads, are, of course, merely a courtesy detail. ___ 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 updated v2
Dear Heiko Schocher,
In message 4a7003a4.2050...@denx.de you wrote:
Hello Wolfgang,
Heiko Schocher wrote:
Wolfgang Denk wrote:
In message 4a6ed511.6010...@denx.de you wrote:
Hello Wolfgang,
The following changes since commit
94978e19f31d225b4f7d97c4acbac1ecfaeb8f69:
Wolfgang Denk (1):
Prepare 2009.08-rc1 (again, after fixing last minute issues).
are available in the git repository at:
git://git.denx.de/u-boot-i2c.git master
Alessandro Rubini (2):
arm nomadik: add gpio support
arm nomadik: add i2c
Heiko Schocher (2):
arm, i2c: added support for the TWSI I2C Interface
Because twl4030 now has its own device files, move exiting
Not pulled again because of this obscure commit.
Hups ... Sorry ... I look for this issue ...
Here comes the right version ... sorry for the confusion.
The following changes since commit 94978e19f31d225b4f7d97c4acbac1ecfaeb8f69:
Wolfgang Denk (1):
Prepare 2009.08-rc1 (again, after fixing last minute issues).
are available in the git repository at:
git://git.denx.de/u-boot-i2c.git master
Alessandro Rubini (2):
arm nomadik: add gpio support
arm nomadik: add i2c
Heiko Schocher (1):
arm, i2c: added support for the TWSI I2C Interface
Tom Rix (6):
OMAP I2C Fix the sampling clock.
TWL4030 Add initial support
TWL4030 Add power reset button
OMAP3 Move twl4030 power and led functions
OMAP3 Move twl4030 mmc function
OMAP3 Remove twl4030 defines
Makefile |1 +
board/omap3/beagle/beagle.c|4 +-
board/omap3/common/power.c | 74
board/omap3/overo/overo.c |4 +-
board/omap3/pandora/pandora.c |4 +-
board/omap3/zoom1/zoom1.c | 12 +-
board/omap3/zoom2/zoom2.c | 17 +-
board/st/nhk8815/nhk8815.c | 16 +-
cpu/arm926ejs/nomadik/Makefile |2 +-
cpu/arm926ejs/nomadik/gpio.c | 99 +
drivers/i2c/Makefile |1 +
drivers/i2c/kirkwood_i2c.c | 484
drivers/i2c/omap24xx_i2c.c | 74 -
drivers/misc/Makefile |1 +
drivers/misc/twl4030_led.c | 52 +++
drivers/mmc/omap3_mmc.c| 13 +-
{board/omap3/common = drivers/power}/Makefile | 25 +-
drivers/power/twl4030.c| 115 ++
include/asm-arm/arch-nomadik/gpio.h| 42 ++
include/asm-arm/arch-omap24xx/i2c.h| 44 +++
include/asm-arm/arch-omap3/i2c.h | 70 +++-
include/asm-arm/arch-omap3/omap3.h | 35 --
include/configs/nhk8815.h | 18 +-
include/configs/omap3_beagle.h |6 +
include/configs/omap3_evm.h|5 +
include/configs/omap3_overo.h |6 +
include/configs/omap3_pandora.h|6 +
include/configs/omap3_zoom1.h |6 +
include/configs/omap3_zoom2.h |6 +
include/twl4030.h | 401
30 files changed, 1484 insertions(+), 159 deletions(-)
delete mode 100644 board/omap3/common/power.c
create mode 100644 cpu/arm926ejs/nomadik/gpio.c
create mode 100644 drivers/i2c/kirkwood_i2c.c
create mode 100644 drivers/misc/twl4030_led.c
rename {board/omap3/common = drivers/power}/Makefile (67%)
create mode 100644 drivers/power/twl4030.c
create mode 100644 include/asm-arm/arch-nomadik/gpio.h
create mode 100644 include/twl4030.h
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
KLB is an acronym for `Known Lazy Bastard', aka non-FAQ reader, aka
person who would rather make someone take their time to explain
something basic than look it up in a FAQ.
-- Tom Christiansen in 6aq547$mn...@csnews.cs.colorado.edu
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 83xx, kmeter1, fix: update in the DTS the correct size for the first flash
On Tue, 28 Jul 2009 14:53:44 +0200 Heiko Schocher h...@denx.de wrote: When updating the reg in the /localbus/fl...@f000,0 node size was wrong updated for the first flash, because the total size was filled in, instead of the right size for it. Signed-off-by: Heiko Schocher h...@denx.de applied. Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Is it an error in function ehci_submit_root() in ehci-hcd.c
Hi Prafulla,
I'm using a little-endian machine.
My board is freescale i.mx51, the core is arm12.
I will try to correct these two places and test it in my board.
Hope it can work.
Thanks~~
Yours
Terry
-Original Message-
From: Prafulla Wadaskar [mailto:prafu...@marvell.com]
Sent: 2009年7月30日 1:30
To: Michael Trimarchi; Remy Bohmer
Cc: Lv Terry-R65388; u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik
Subject: RE: [U-Boot] Is it an error in function ehci_submit_root() in
ehci-hcd.c
-Original Message-
From: Michael Trimarchi [mailto:trimar...@gandalf.sssup.it]
Sent: Wednesday, July 29, 2009 8:41 PM
To: Remy Bohmer
Cc: Lv Terry-R65388; Prafulla Wadaskar; u-boot@lists.denx.de
Subject: Re: [U-Boot] Is it an error in function
ehci_submit_root() in ehci-hcd.c
Remy Bohmer wrote:
Hi,
2009/7/29 Lv Terry-R65388 rui...@freescale.com:
Hi All,
I'm trying to enable ehci usb in our board and I found
that there
maybe two issues in funcion ehci_submit_root() in ehci-hcd.c.
1)
In ehci_submit_root(), the function will do the
following operation.
From line 553 in ehci-hcd.c:
typeReq = req-request 8 | req-requesttype;
switch (le16_to_cpu(typeReq)) {
case DeviceRequest | USB_REQ_GET_DESCRIPTOR:
...
...
case USB_REQ_GET_DESCRIPTOR | ((USB_DIR_IN | USB_RT_HUB) 8):
...
...
}
As in function usb_get_descriptor() in usb.c,
res = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
(type 8) + index, 0,
buf, size, USB_CNTL_TIMEOUT);
req-request will be assigned USB_REQ_GET_DESCRIPTOR,
req-requesttype will be assigned USB_DIR_IN.
The value of typeReq will be 0x680 which can't match
any value in
switch (le16_to_cpu(typeReq)) .
In current mainline this le16_to_cpu() macro has been removed.
Does that change anything?
Do I miss any config here?
I guess not.
2)
In funcion usb_get_descriptor() in usb.c, it will pass
index 0 to
usb_control_msg. setup_packet.index will be assigned 0.
res = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
(type 8) + index, 0,
buf, size, USB_CNTL_TIMEOUT); /* The sixty
parameter is index */
Then in funcion ehci_submit_root() in ehci-hcd.c,
status_reg = (uint32_t
*)hcor-or_portsc[le16_to_cpu(req-index)
- 1];
(le16_to_cpu(req-index) - 1) will be -1 here.
Is it correct?
Nice catch!
Prafulla/Michael, what do you think?
Hi Terry
BTW: Which is your board?
Is it big endian machine? I am curious about it :)
Regards..
Prafulla . . .
That we need a patch here urgent :).
Terry, Can you provide the proper fix?
Michael
Kind Regards,
Remy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] how to add mmc/sd support in 6410 u-boot?
hello, everyone. Has somebody ported U-boot to s3c6410? I want add mmc/sd reading and writing in 6410 u-boot. Can somebody give me some hints? Thanks in advance. -- Michael L. Jul 30, 2009 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] ppc4xx: amcc: Set CONFIG_SYS_BOOTMAPSZ to 16MB for big kernels
This patch changes CONFIG_SYS_BOOTMAPSZ from 8MB to 16MB which is the initial TLB on 40x PPC's in the Linux kernel. With this change even bigger Linux kernels ( 8MB) can be booted. This patch also sets CONFIG_SYS_BOOTM_LEN to 16MB (default 8MB) to enable decompression of bigger images. Signed-off-by: Stefan Roese s...@denx.de --- This patch replaces the orinal patch [PATCH v2] ppc4xx: amcc: Set CONFIG_SYS_BOOTMAPSZ to 16MB to enable booting of big kernels. v2: - Patch subject line now a bit shorter - Increase CONFIG_SYS_BOOTM_LEN to 16MB too include/configs/amcc-common.h |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/include/configs/amcc-common.h b/include/configs/amcc-common.h index 3b733c0..275adcc 100644 --- a/include/configs/amcc-common.h +++ b/include/configs/amcc-common.h @@ -137,10 +137,11 @@ /* * For booting Linux, the board info and command line data - * have to be in the first 8 MB of memory, since this is - * the maximum mapped by the Linux kernel during initialization. + * have to be in the first 16 MB of memory, since this is + * the maximum mapped by the 40x Linux kernel during initialization. */ -#define CONFIG_SYS_BOOTMAPSZ (8 20) /* Initial Memory map for Linux */ +#define CONFIG_SYS_BOOTMAPSZ (16 20) /* Initial Memory map for Linux */ +#define CONFIG_SYS_BOOTM_LEN (16 20) /* Increase max gunzip size */ /* * Internal Definitions -- 1.6.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
