Re: [U-Boot] u-boot master on a pandaboard won't boot
Hi Christopher, On Wednesday 02 November 2011 06:33 PM, Lalancette, Christopher wrote: Hello, I've recently been playing around with u-boot on a pandaboard Rev A1. The rest of my environment is an MLO built from x-loader git hash c4289f1bee035dea41536c5ba5e1bc36c7d493c4, and booting an ubuntu 11.04 kernel 2.6.38-1208-omap4. Up until tag v2011.06, u-boot works flawlessly (as far as I've tested) on this combination. However, if I take any u-boot release after that, including v2011.09 and u-boot git head, u-boot hangs very early on: Texas Instruments X-Loader 1.5.1 (Nov 2 2011 - 08:55:25) Reading boot sector Loading u-boot.bin from mmc And the status LEDs blink rapidly. I bisected the problem down to commit bcae72116257201d7288cb8c525a29aea4875b95; prior to that commit, I can successfully[1] boot u-boot on the pandaboard, but after that I cannot. This commit changes the load address of u-boot and according to the new relocation scheme u-boot should be loaded at where it is built for. x-loader is assuming the load address of TI Internal u-boot. You have two options: 1. Use SPL - when you build mainline u-boot you get an MLO as by-product. Use it instead of x-loader. 2. Change the u-boot load address in x-loader to 0x8010 (CFG_LOADADDR in include/configs/omap4430panda.h) BTW, I am considering unifying the two load addresses. br, Aneesh I'm going to poke at it a bit more, but does anyone have any ideas of what is going on here? --- Chris Lalancette [1] Well, I can at least get beyond Loading u-boot.bin from mmc and boot the kernel and userland. For some reason with this setup I can't get ethernet to work, but one problem at a time. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] malloc issue while migrating from 2010.03 to 2011.06 U-boot
Let me try with 2011.09. However, to understand this malloc issue further, do you have any comments on what could be wrong and any tests for me to try out to debug further? |It's an out of tree port, isn't it? So how could I comment on it? |I don't know what you did... Yes, its a custom port. However, the common code is same. Only board specific directories and config files are different. Anyway, it seems that I am on my own. Let me try using 2011.09 U-Boot and in parallel debug this issue on 2011.06 ;-( Thanks, Vinay___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ulpi: add generic ULPI support header file
Great work, Jana! On 11/02/11 20:42, Jana Rapava wrote: Add ULPI header file needed by Efika USB support patchset and generic ULPI support patch, which is to be posted soon. Signed-off-by: Jana Rapava ferma...@gmail.com Cc: Marek Vasut marek.va...@gmail.com Cc: Remy Bohmer li...@bohmer.net Cc: Stefano Babic sba...@denx.de Cc: Igor Grinberg grinb...@compulab.co.il Acked-by: Igor Grinberg grinb...@compulab.co.il -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-mmc.git
The following changes since commit ce5207e191c59b3135303fd03b98dd2ac3701ba2: e1000: Allow direct access to the E1000 SPI EEPROM device (2011-10-28 00:37:01 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-mmc.git master Ajay Bhargav (1): mmc: CMD7:MMC_CMD_SELECT_CARD response fix Lei Wen (9): mmc: retry the cmd8 to meet 74 clocks requirement in the spec mmc: mv_sdhci: fix 8bus width access for 88SV331xV5 mmc: change magic number to macro define mmc: test mmc bus width on startup mmc: sdhci: fix cache flush mmc: sdhci: fix build warning mmc: sdhci: add mmc structure for host mmc: sdhci: add timeout for data transfer mmc: sdhci: fix sdma bug for large file transfer Marek Vasut (1): PXA: Add MMC driver using the generic MMC framework Stephen Warren (1): tegra2: Move MMC clock initialization into MMC driver arch/arm/include/asm/arch-pxa/regs-mmc.h | 154 +++ board/nvidia/common/board.c | 13 +- drivers/mmc/Makefile |1 + drivers/mmc/mmc.c| 83 -- drivers/mmc/mv_sdhci.c | 33 +++ drivers/mmc/pxa_mmc_gen.c| 442 ++ drivers/mmc/sdhci.c | 14 +- drivers/mmc/tegra2_mmc.c | 12 +- include/mmc.h| 16 +- include/sdhci.h |6 + 10 files changed, 719 insertions(+), 55 deletions(-) create mode 100644 arch/arm/include/asm/arch-pxa/regs-mmc.h create mode 100644 drivers/mmc/pxa_mmc_gen.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] MPC8360EMDS: 512MB DDR and 33.33MHz oscillator support
Thanks and Best Regards Jerry Huang -Original Message- From: Phillips Kim-R1AAHA Sent: Thursday, November 03, 2011 4:37 AM To: McClintock Matthew-B29882 Cc: Huang Changming-R66093; Tabi Timur-B04825; u-boot@lists.denx.de; Phillips Kim-R1AAHA Subject: Re: [U-Boot] [PATCH v5] MPC8360EMDS: 512MB DDR and 33.33MHz oscillator support On Wed, 2 Nov 2011 09:52:17 -0500 McClintock Matthew-B29882 b29...@freescale.com wrote: On Wed, Nov 2, 2011 at 2:34 AM, Huang Changming-R66093 r66...@freescale.com wrote: How can I deal with the new board and old board? Check the board revision at runtime. Board Specification says, there is one EEPROM to contain all board history, and I found it: On I2C2 bus, there is one EEPROM BRD(0x50) from the schematics, but the content of this EEPROM is 0xff. That's to say, we can't check the board information from this EEPROM. From the code of mpc8360emds platform, there is not the interface to check the board information. So, there is no way to check the board revision at runtime. Board revision information should be in BCSR12. I'm curious whether yours contains a higher board revision level than mine: = md.b f800 e f800: 04 04 00 c6 94 60 00 00 ac 2e 00 b8 10 3f.`...? BCSR12-^^ My board BCSR info: = md.b f800 e f800: 0a 04 00 8f 94 60 00 00 ac 2e 00 b8 22 3f.`..? because the sticker on the FPGA says BCSR 2.1 vs. the 1.0 encoding above. Best case explanation would be the h/w encoding is 0- based and they don't bother to update the minor revision number... Is your board special? Maybe the ones customers get go through the proper process to have EEPROM updated? Otherwise, you will probably need to create a new board type: $ make mpc8360emds_newmodifier wrt setting CONFIG_83XX_CLKIN, it's a little harder to do at runtime, so we should do as Matt says instead of checking the board revision at runtime - see e.g., the MPC8313ERDB_33 vs. MPC8313ERDB_66 targets. The HRCW_LOW change should also be #ifdeffed. Some other comments on this patch, now that I've taken a closer look: 1. it should be two patches - one for the CLKIN change, the other for the dynamic remapping change. 2. update doc/README.mpc8360emds for 33 vs. 66 a la doc/README.mpc8313erdb, and also for the remapping change, each update in its corresponding patch. Might want to mention any dip switch setting changes and the physical location of the oscillator so the user is sure which one to use - CLKIN is the one closest to the JTAG connector, right? Yes, it is U41. 3. no need to sync after write_bat(); write_bat() does this already. 4. no need to clear BATs before writing them either. 5. I can't comprehend the comment re-setup PCI MEM space used BAT5 after relocated to DDR - do you mean something like reuse BAT5 for PCI MEM space after relocation to RAM? Yes, I will change the comment. 6. re-post patches to this thread - see the 3rd bullet in: http://www.denx.de/wiki/view/U- Boot/Patches#Sending_updated_patch_versions Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Allow for parallel builds and saved output
The MAKEALL script cleverly runs make with the appropriate options
to use all of the cores on the system, but your average U-Boot build
can't make much use of more than a few cores. If you happen to have
a many-core server, your builds will leave most of the system idle.
In order to make full use of such a system, we need to build multiple
targets in parallel, and this requires directing make output into
multiple directories. We add a BUILD_NBUILDS variable, which allows
users to specify how many builds to run in parallel. I've found that
16 is too many on my system (fork starts to fail). When BUILD_NBUILDS
is set greater than 1, we redefine BUILD_DIR for each build to be
${BUILD_DIR}/${target}. Also, we make ./build the default BUILD_DIR
when BUILD_NBUILDS is greater than 1.
Once each build finishes, we run make clean on its directory, to reduce
the footprint, and also remove all .depend files.
As a result, we are left with a build directory with all of the built
targets still there for use, which means anyone who wanted to use
MAKEALL as part of a test harness can now do so.
Signed-off-by: Andy Fleming aflem...@freescale.com
---
Inspired by all the MAKEALL improvements, I decided to clean up my old
one for parallel builds. I think this version addresses the concerns
raised last time...
MAKEALL | 74 ++
1 files changed, 64 insertions(+), 10 deletions(-)
diff --git a/MAKEALL b/MAKEALL
index 95b7cd3..4583ddb 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -31,6 +31,7 @@ usage()
CROSS_COMPILEcross-compiler toolchain prefix (default: )
MAKEALL_LOGDIR output all logs to here (default: ./LOG/)
BUILD_DIRoutput build directory (default: ./)
+ BUILD_NBUILDSnumber of parallel targets (default: 1)
Examples:
- build all Power Architecture boards:
@@ -160,10 +161,23 @@ else
LOG_DIR=LOG
fi
+if [ ! ${BUILD_NBUILDS} ] ; then
+ BUILD_NBUILDS=1
+fi
+
+if [ $BUILD_NBUILDS -gt 1 ] ; then
+ if [ ! ${BUILD_DIR} ] ; then
+ BUILD_DIR=./build
+ fi
+ mkdir -p ${BUILD_DIR}/ERR
+fi
+
if [ ! ${BUILD_DIR} ] ; then
BUILD_DIR=.
fi
+OUTPUT_PREFIX=${BUILD_DIR}
+
[ -d ${LOG_DIR} ] || mkdir ${LOG_DIR} || exit 1
LIST=
@@ -483,32 +497,52 @@ LIST_sparc=$(boards_by_arch sparc)
LIST_nds32=$(boards_by_arch nds32)
+CURRENT_COUNT=0
+
#---
build_target() {
target=$1
+ if [ $BUILD_NBUILDS -gt 1 ] ; then
+ output_dir=${OUTPUT_PREFIX}/${target}
+ mkdir -p ${output_dir}
+ else
+ output_dir=${OUTPUT_PREFIX}
+ fi
+
+ export BUILD_DIR=${output_dir}
+
${MAKE} distclean /dev/null
${MAKE} -s ${target}_config
- ${MAKE} ${JOBS} all 21 ${LOG_DIR}/$target.MAKELOG \
- | tee ${LOG_DIR}/$target.ERR
+ ${MAKE} ${JOBS} all \
+ 21 ${LOG_DIR}/$target.MAKELOG | tee ${LOG_DIR}/$target.ERR
# Check for 'make' errors
if [ ${PIPESTATUS[0]} -ne 0 ] ; then
RC=1
fi
- if [ -s ${LOG_DIR}/$target.ERR ] ; then
- ERR_CNT=$((ERR_CNT + 1))
- ERR_LIST=${ERR_LIST} $target
+ if [ $BUILD_NBUILDS -gt 1 ] ; then
+ ${MAKE} clean
+ find ${output_dir} -type f -name '*.depend' | xargs rm
+
+ if [ -s ${LOG_DIR}/${target}.ERR ] ; then
+ touch ${OUTPUT_PREFIX}/ERR/${target}
+ else
+ rm ${LOG_DIR}/${target}.ERR
+ fi
else
- rm ${LOG_DIR}/$target.ERR
+ if [ -s ${LOG_DIR}/${target}.ERR ] ; then
+ ERR_CNT=$((ERR_CNT + 1))
+ ERR_LIST=${ERR_LIST} $target
+ else
+ rm ${LOG_DIR}/${target}.ERR
+ fi
fi
- TOTAL_CNT=$((TOTAL_CNT + 1))
-
- ${CROSS_COMPILE}size ${BUILD_DIR}/u-boot \
+ ${CROSS_COMPILE}size ${output_dir}/u-boot \
| tee -a ${LOG_DIR}/$target.MAKELOG
}
build_targets() {
@@ -523,7 +557,20 @@ build_targets() {
if [ -n ${list} ] ; then
build_targets ${list}
else
- build_target ${t}
+ if [ $BUILD_NBUILDS -gt 1 ] ; then
+ build_target ${t}
+ else
+ build_target ${t}
+ fi
+
+ TOTAL_CNT=$((TOTAL_CNT + 1))
+ CURRENT_COUNT=$((CURRENT_COUNT + 1))
+ fi
+
+ # Limit number of parallel builds
+ if [ ${CURRENT_COUNT} -gt ${BUILD_NBUILDS} ] ; then
+ CURRENT_COUNT=0;
+ wait;
Re: [U-Boot] [PATCH] mmc: mv_sdhci: Fix host version read for Armada100
-Original Message- From: Marek Vasut [mailto:marek.va...@gmail.com] Sent: Wednesday, November 02, 2011 7:59 PM To: Prafulla Wadaskar Cc: Ajay Bhargav; u-boot@lists.denx.de; aflem...@gmail.com; Lei Wen; Chris Ball Subject: Re: [U-Boot] [PATCH] mmc: mv_sdhci: Fix host version read for Armada100 -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot- boun...@lists.denx.de] On Behalf Of Marek Vasut Sent: Wednesday, November 02, 2011 3:55 PM To: Ajay Bhargav Cc: u-boot@lists.denx.de; aflem...@gmail.com Subject: Re: [U-Boot] [PATCH] mmc: mv_sdhci: Fix host version read for Armada100 - Marek Vasut marek.va...@gmail.com wrote: - Marek Vasut marek.va...@gmail.com wrote: sdhci_readw does not work for host version read in Armada100 [...] Well such crippled hardware might appear somewhere else too, so yes. But still, it's surprising it's only one register, really. Can you point me to a datasheet/errata stating it? Thanks! I agree, adding a quirk for this is best option this way driver will still be generic for marvell series. Marek, I am really sorry but I am not allowed to share errata here :) I will ask my senior if i can atleast send you a screenshot regarding this issue. Stupid Marvell crap again :-( Hi Marek I understand your concern. Please understand there are company policies we need to follow. Which are ... see above :-) Meanwhile have a look at documentation (software manual) at below pointer, if it helps you (I hope you already had it :-D ) http://www.marvell.com/application-processors/armada-100/ Good, thank you. Do you plan to release armada610 TRM too (used in OLPC 1.75) ? I will query on this and let you know. Regards.. Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] QorIQ: fix network frame manager TBI PHY address settings
-Original Message- From: Zang Roy-R61911 Sent: Friday, October 28, 2011 13:16 PM To: u-boot@lists.denx.de Cc: Zang Roy-R61911; Fleming Andy-AFLEMING; Kumar Gala Subject: [PATCH v2] QorIQ: fix network frame manager TBI PHY address settings TBI PHY address (TBIPA) register has been set in general frame manager phy init funciton dtsec_init_phy() in drivers/net/fm/eth.c So remove the duplicate code on QorIQ frame manager Ethernet related platforms, which include Hydra board, P4080DS board and P2041rdb board. Signed-off-by: Roy Zang tie-fei.z...@freescale.com Cc: Andy Fleming aflem...@freescale.com Cc: Kumar Gala ga...@kernel.crashing.org --- v2: refine the subject and description according to feedback Hi, Wolfgang Any feedback for the update patch? Thanks. Roy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] QorIQ: fix network frame manager TBI PHY address settings
On Nov 3, 2011, at 2:47 AM, Zang Roy-R61911 wrote: -Original Message- From: Zang Roy-R61911 Sent: Friday, October 28, 2011 13:16 PM To: u-boot@lists.denx.de Cc: Zang Roy-R61911; Fleming Andy-AFLEMING; Kumar Gala Subject: [PATCH v2] QorIQ: fix network frame manager TBI PHY address settings TBI PHY address (TBIPA) register has been set in general frame manager phy init funciton dtsec_init_phy() in drivers/net/fm/eth.c So remove the duplicate code on QorIQ frame manager Ethernet related platforms, which include Hydra board, P4080DS board and P2041rdb board. Signed-off-by: Roy Zang tie-fei.z...@freescale.com Cc: Andy Fleming aflem...@freescale.com Cc: Kumar Gala ga...@kernel.crashing.org --- v2: refine the subject and description according to feedback Hi, Wolfgang Any feedback for the update patch? Thanks. Roy Roy, the patch is fine. I'll pick it on today or tomorrow. I try to let things at least get a week before getting pulled into a tree and sending a pull request to Wolfgang. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Phy/Marvell: Rewrite the MV88E1111 phy config function based on kernel code
-Original Message- From: Zang Roy-R61911 Sent: Friday, October 28, 2011 12:52 PM To: u-boot@lists.denx.de Cc: Zang Roy-R61911; Kumar Gala Subject: [PATCH v2] Phy/Marvell: Rewrite the MV88E phy config function based on kernel code The original m88es_config() does not do the SGMII mode initialization and is buggy. Rewrite the function according to 3.0.6 kernel function m88e_config_init() in drivers/net/phy/marvell.c Signed-off-by: Roy Zang tie-fei.z...@freescale.com Acked-by: Andy Fleming aflem...@freescale.com Cc: Kumar Gala ga...@kernel.crashing.org --- v2: Use timeout instead of infinite loop How about this patch? Any feedback? Thanks. Roy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2 v6] powerpc/mpc83xx: Add 33.33MHz support for mpc8360emds
From: Jerry Huang chang-ming.hu...@freescale.com The new MPC8360EMDS board changes the oscillator to 33.33MHz in order to support QE 500MHz since 2008. Signed-off-by: Jerry Huang chang-ming.hu...@freescale.com CC: Kim Phillips kim.phill...@freescale.com --- cahnges for v2: - fix multiline comment wrong changes for v3: - change the oscillator to , not 3330 changes for v4: - add the mandatory history of changes changes for v5: - move the code to platform file from lib/board.c - add 2011 copyright changes for v6: - split into two patch - add the CLKIN33 option for 33.33MHz oscillator - add the readme for CLKIN33 option - add CC boards.cfg|5 + doc/README.mpc8360emds| 14 ++ include/configs/MPC8360EMDS.h | 25 + 3 files changed, 44 insertions(+), 0 deletions(-) diff --git a/boards.cfg b/boards.cfg index 90dab8b..273615d 100644 --- a/boards.cfg +++ b/boards.cfg @@ -424,6 +424,11 @@ MPC8360EMDS_ATM powerpc mpc83xx mpc8360emds freesca MPC8360EMDS_HOST_33 powerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:PCI,PCI_33M,PQ_MDS_PIB=1 MPC8360EMDS_HOST_66 powerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:PCI,PCI_66M,PQ_MDS_PIB=1 MPC8360EMDS_SLAVEpowerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:PCI,PCISLAVE +MPC8360EMDS_CLKIN33 powerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:CLKIN_33MHZ +MPC8360EMDS_CLKIN33_ATM powerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:CLKIN_33MHZ,PQ_MDS_PIB=1,PQ_MDS_PIB_ATM=1 +MPC8360EMDS_CLKIN33_HOST_33 powerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:CLKIN_33MHZ,PCI,PCI_33M,PQ_MDS_PIB=1 +MPC8360EMDS_CLKIN33_HOST_66 powerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:CLKIN_33MHZ,PCI,PCI_66M,PQ_MDS_PIB=1 +MPC8360EMDS_CLKIN33_SLAVEpowerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:CLKIN_33MHZ,PCI,PCISLAVE MPC8360ERDK powerpc mpc83xx mpc8360erdk freescale - MPC8360ERDK MPC8360ERDK_33 powerpc mpc83xx mpc8360erdk freescale - MPC8360ERDK:CLKIN_33MHZ MPC8360ERDK_66 powerpc mpc83xx mpc8360erdk freescale - MPC8360ERDK diff --git a/doc/README.mpc8360emds b/doc/README.mpc8360emds index d65a2a4..6506193 100644 --- a/doc/README.mpc8360emds +++ b/doc/README.mpc8360emds @@ -109,6 +109,20 @@ Freescale MPC8360EMDS Board 1) DIP SW setting is similar as Section 1.1, except for SW9[3] is 1 2) Make MPC8360EMDS_SLAVE_config + MPC8360EMDS shipped with 33.33MHz oscillator(U41 is 33.33MHZ): + + To make u-boot as the defualt with 33.33MHz oscillator: + 1) make distclean + 2) make MPC8360EMDS_CLKIN33_config + + To make u-boot support the other feature with 33.33MHz oscillator: + 1) make distclean + 2) make MPC8360EMDS_CLKIN33_XXX_config + (where XXX is: + ATM - ATM support with 33.33MHz oscillator + HOST_33 - PCI host 33M support with 33.33MHz oscillator + HOST_66 - PCI host 66M support with 33.33MHz oscillator + SLAVE - PCI slave support with 33.33MHz oscillator) 5. Downloading and Flashing Images diff --git a/include/configs/MPC8360EMDS.h b/include/configs/MPC8360EMDS.h index cfba894..9aa3973 100644 --- a/include/configs/MPC8360EMDS.h +++ b/include/configs/MPC8360EMDS.h @@ -39,6 +39,18 @@ /* * System Clock Setup */ +#ifdef CONFIG_CLKIN_33MHZ +#ifdef CONFIG_PCISLAVE +#define CONFIG_83XX_PCICLK /* in HZ */ +#else +#define CONFIG_83XX_CLKIN /* in Hz */ +#endif + +#ifndef CONFIG_SYS_CLK_FREQ +#define CONFIG_SYS_CLK_FREQ +#endif + +#else #ifdef CONFIG_PCISLAVE #define CONFIG_83XX_PCICLK 6600 /* in HZ */ #else @@ -48,10 +60,22 @@ #ifndef CONFIG_SYS_CLK_FREQ #define CONFIG_SYS_CLK_FREQ6600 #endif +#endif /* * Hardware Reset Configuration Word */ +#ifdef CONFIG_CLKIN_33MHZ +#define CONFIG_SYS_HRCW_LOW (\ + HRCWL_LCL_BUS_TO_SCB_CLK_1X1 |\ + HRCWL_DDR_TO_SCB_CLK_1X1 |\ + HRCWL_CSB_TO_CLKIN_8X1 |\ + HRCWL_VCO_1X2 |\ + HRCWL_CE_PLL_VCO_DIV_4 |\ + HRCWL_CE_PLL_DIV_1X1 |\ + HRCWL_CE_TO_PLL_1X15 |\ + HRCWL_CORE_TO_CSB_2X1) +#else #define CONFIG_SYS_HRCW_LOW (\ HRCWL_LCL_BUS_TO_SCB_CLK_1X1 |\ HRCWL_DDR_TO_SCB_CLK_1X1 |\ @@ -61,6 +85,7 @@ HRCWL_CE_PLL_DIV_1X1 |\ HRCWL_CE_TO_PLL_1X6 |\ HRCWL_CORE_TO_CSB_2X1) +#endif #ifdef CONFIG_PCISLAVE #define CONFIG_SYS_HRCW_HIGH (\ -- 1.6.4
[U-Boot] [PATCH 1/2 v6] powerpc/mpc83xx: Add 512MB DDR support for mpc8360emds
From: Jerry Huang chang-ming.hu...@freescale.com
The new MPC8360EMDS board supports 512MB DDR since 2008.
For 512MB DDR:
BAT0 is used for the first 256MB memory, BAT4 is used for the second
256MB memory and the address space of SDRAM follows the DDR, so if the
size of DDR is 256MB, the BAT4 will be used for SDRAM and if the size of
DDR is 512MB, the BAT4 will be used for the second 256MB memory and
there is no BAT for SDRAM.
Therefore, if the size of DDR is 512MB, this patch will use BAT6 for
SDRAM and BAT5 will be used for PCI MEM to replace the BAT6 after the
codes relocates to the DDR.
Signed-off-by: Jerry Huang chang-ming.hu...@freescale.com
CC: Kim Phillips kim.phill...@freescale.com
---
cahnges for v2:
- fix multiline comment wrong
changes for v3:
- change the oscillator to , not 3330
changes for v4:
- add the mandatory history of changes
changes for v5:
- move the code to platform file from lib/board.c
- add 2011 copyright
changes for v6:
- split into two patch
- clean the code
- add CC
board/freescale/mpc8360emds/mpc8360emds.c | 27 ++-
include/configs/MPC8360EMDS.h |3 ++-
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/board/freescale/mpc8360emds/mpc8360emds.c
b/board/freescale/mpc8360emds/mpc8360emds.c
index 0babd26..f150a09 100644
--- a/board/freescale/mpc8360emds/mpc8360emds.c
+++ b/board/freescale/mpc8360emds/mpc8360emds.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2006,2010 Freescale Semiconductor, Inc.
+ * Copyright (C) 2006,2010-2011 Freescale Semiconductor, Inc.
* Dave Liu dave...@freescale.com
*
* See file CREDITS for list of people who contributed to this
@@ -23,6 +23,7 @@
#include asm/mmu.h
#include asm/io.h
#include asm/fsl_enet.h
+#include asm/mmu.h
#if defined(CONFIG_OF_LIBFDT)
#include libfdt.h
#endif
@@ -138,9 +139,20 @@ int board_early_init_f(void)
int board_early_init_r(void)
{
+ gd_t *gd;
#ifdef CONFIG_PQ_MDS_PIB
pib_init();
#endif
+ /*
+* BAT6 is used for SDRAM when DDR size is 512MB or larger than 256MB
+* So re-setup PCI MEM space used BAT5 after relocated to DDR
+*/
+ gd = (gd_t *)(CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_GBL_DATA_OFFSET);
+ if (gd-ram_size CONFIG_MAX_MEM_MAPPED) {
+ write_bat(DBAT5, CONFIG_SYS_DBAT6U, CONFIG_SYS_DBAT6L);
+ write_bat(IBAT5, CONFIG_SYS_IBAT6U, CONFIG_SYS_IBAT6L);
+ }
+
return 0;
}
@@ -290,6 +302,19 @@ static int sdram_init(unsigned int base)
if (rem)
base = base - rem + sdram_size;
+ /*
+* Setup BAT6 for SDRAM when DDR size is 512MB or larger than 256MB
+* After relocated to DDR, reuse BAT5 for PCI MEM space
+*/
+ if (base CONFIG_MAX_MEM_MAPPED) {
+ unsigned long batl = base | BATL_PP_10 | BATL_MEMCOHERENCE;
+ unsigned long batu = base | BATU_BL_64M | BATU_VS | BATU_VP;
+
+ /* Setup the BAT6 for SDRAM */
+ write_bat(DBAT6, batu, batl);
+ write_bat(IBAT6, batu, batl);
+ }
+
sdram_addr = (uint *)base;
/*
* Setup SDRAM Base and Option Registers
diff --git a/include/configs/MPC8360EMDS.h b/include/configs/MPC8360EMDS.h
index a959940..cfba894 100644
--- a/include/configs/MPC8360EMDS.h
+++ b/include/configs/MPC8360EMDS.h
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2006 Freescale Semiconductor, Inc.
+ * Copyright (C) 2006,2011 Freescale Semiconductor, Inc.
*
* Dave Liu dave...@freescale.com
*
@@ -506,6 +506,7 @@
*/
#define CONFIG_HIGH_BATS 1 /* High BATs supported */
+#define CONFIG_BAT_RW
/* DDR/LBC SDRAM: cacheable */
#define CONFIG_SYS_IBAT0L (CONFIG_SYS_SDRAM_BASE | BATL_PP_10 |
BATL_MEMCOHERENCE)
--
1.6.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx31pdk: Enable D and I caches
Fabio, 2011/11/3 Fabio Estevam feste...@gmail.com: Hi Stefano, On Wed, Nov 2, 2011 at 6:41 AM, Stefano Babic sba...@denx.de wrote: Good. To be sure, do you have also tested NAND in u-boot ? I do not expect problems, but... Yes, I confirmed that NAND works with the caches enabled by doing the following tests: 1. Save environment variables in NAND 2. Reprogram U-boot in NAND using run prg_uboot script. I would like to investigate the FEC issue when caches are enabled when I have a chance. Would you have any pointers as to where to start investigating why the FEC driver is buggy when caches are enabled? you can search the tread: [U-Boot] i.MX51: FEC: Cache coherency problem? Jason Liu Thanks, Fabio Estevam ___ 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] dfu: initial implementation
Hello Stefan, On Wednesday, November 02, 2011 3:29 PM Stefan Shmidt wrote: Have you fully implemented 1.1? With the detahc logic inside the device implementation? As you noticed in another post, the state machine is reused. Just curious. What version of dfu-util your are using for your tests? I released 0.5 earlier today. I used what was available in my desktop's Ubuntu 10.04 LTS, and it happens to be version 0.1+svn :O It works, though. Hmm, that sounds like you only implemented the DFU mode but not the run-time mode yet? This conclusion is not correct. After issuing the dfu command my implementation begins in runtime mode. Only after using dfu-util from the host is the mode changed to DFU mode. Actually, as far as usage of dfu-util is concerned, I find it inconvenient when the device is in runtime mode, because there (at least with my version of dfu-util) is no way for the user to guess what altsettings are actually available. I personally do dfu-util -U file -a 0 or a similar command to kick the device into DFU mode, then dfu-util -l to discover what altsettings there are. So, it could be tempting to omit the runtime mode at all and start in DFU mode, but, to be standard compliant, I start in runtime mode. How do you discover with dfu-util what altsettings there are in the device? While the original purpose of DFU was to make updating USB device easy enough for end-users as well. True, that's what the standard says about the very purpose of DFU. However, pressing keys to bring the device into a specific mode is probably very much device-specific. It would be nice if we are able to come up with a generic solution which only delegates the necessary details to board-specific files. In the end I would like to see different options available: 1) Entering DFU mode directly when a button is pressed on startup. An update mode if you want to call it like this. Please see my comment above. 2) Normal startup, but with DFU descripton to allow dfu-util detaching and entering the DFU mode for flashing. 3) Starting dfu mode form the command line as you did implement it. I think 2 and 3 don't differ too much - it seems that enriching a setup without DFU with additional USB descriptors will do the job. But 2 and 3 probably should not be merged, though. The implementation is split into two parts: the dfu gadget implementation and a flashing backend, the interface between the two being the struct flash_entity. The flashing backend's implementation is board-specific and is implemented on the Goni target. What is your reasoning behind this split? I have it working here with the normal nand_flashing routines taking care of bad blocks, etc. The reason is to factor out board-specific stuff from the dfu gadget implementation. However, in what I factored out probably there are parts which are generic enough not to be board-specific. Since there seems to be considerable interest in DFU implementation for u-boot, this could be reworked. To make it clear, I'm happy to see somebody else working on this Whap! --- Oh, man, we are not alone! ;) I am happy to hear from someone else who works on this, too. Regards, Andrzej ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dfu: initial implementation
Hello Mike, Thank you for your review. Please see my comments inline. On Wednesday, November 02, 2011 4:16 PM Mike Frysinger wrote: Dear All, This is Device Firmware Upgrade (DFU) implementation which supports data upload and download function to devices which are equipped with a UDC. this information belongs in the changelog (above the --- marker) I generally agree to remarks related to coding style and implementation's distribution into respective patches. are you working with the elinux.org guys ? http://elinux.org/Merge_DFU_support_into_mainline_U-Boot That's not me. this should be split up into at least the dfu core and board-specific changes. although i'd wonder how much of the board/samsung/ stuff is really board specific and couldn't be generalized ... You are right, probably the flashing backend part contains some code which can be generalized. Regards, Andrzej ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Coca Cola Company @ West Africa End of Year Promo.Email: frankmorri...@ymail.com
Win $500,000 in Coca Cola Company @ West Africa end of year promo.To qualify, Email the correct answer to the question given below to Mr. Frank Morris via (frankmorri...@ymail.com) Question: Who won the 2010 FIFA World Cup in South Africa? (A)England (B)Spain (C)Germany (D)Brazi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dfu: initial implementation
Hello Stefan, On Wednesday, November 02, 2011 8:30 PM Stefan Schmidt writes: Agreed. The eMMC flashing with files on FAT is nothing goni specific. Others should be able to use this as well. I see three different parts here that can be separated: I agree. Since there is interest in DFU implementation this can and should be generalized. 1) The DFU protocol implementation which lives in usb gadget with an interface for flashing backends 2) The flashing backends (no idea where to put them best). At the moment that would be the implementation here with eMMC and files on FAT, mine with raw NAND devices and in the future maybe others. Each flashing backend should be generic enough to allow different boards using it. 3) Board specific information like partitions or hints for the flashing backend. The information itself should be in the board file here and only used by the flashing backends. How does this sound to you? Andrzej? Sounds good to me. In my implementation the interface between dfu gadget and flashing backend is around the struct flash_entity. It contains a character string intended to provide a human-readable name, a void * context which is not interpreted by the gadget code, but is passed to the flashing backend and understood by it. The struct flash_entity also contains prepare-finish methods to be called before and after read/write operations, and the read_block- write_block pair. What do you think? As far as generalization is concerned, in my flashing backend implementation I see these parts as candidates for generalization: 1) mbr/ebr reading 2) reading/writing mmc 3) read/write fat 4) generic prepare/finish; not sure if fat-specific prepare can be generalized 5) read/write_block 6) some more work should be put to create an interface between the board initialization routine, the flashing backend and the DFU gadget implementation. In my implementation the board initialization routine calls board-specific register_flash_areas, which, in turn, calls DFU gadget's register_flash_entities. What's your opinion? Thanks, Andrzej ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] powerpc/mpc85xx: Set SYSCLK to the required frequency
From: Jerry Huang chang-ming.hu...@freescale.com
For ICS307-02, there is one general expression to generate SYSCLK:
CLK1Frequency = InputFrequency * 2 * (VDW + 8) / ((RDW + 2) * OD)
If we want the required frequency for SYSCLK, we must find one solution
to generate this frequency, this solution includes VDW, RDW and OD.
For OD, there are only eight option value: 10, 2, 8, 4, 5, 7, 3, 6.
For RDW, the range is 1 to 127.
For VDW, the range is 4 to 511.
First, we use one OD, RDW and required SYSCLK to calculate the VDW,
if VDW is in it's range, we will calculate the CLK1Frequency with
the OD, RDW and VDW calculated, and we will check this percent
(CLK1Frequency / required SYSCLK), and the precision is 1/1000.
if the percent is less than 1/1000, we think the CLK1Frequency is we want.
Otherwise, We will continue to calculate it with the next OD and RDW.
Signed-off-by: Jerry Huang chang-ming.hu...@freescale.com
CC: Kumar Gala kumar.g...@freescale.com
---
changes for v2:
- move these macro to .c file
- change the subject to powerpc/mpc85xx
- add CC
board/freescale/common/ics307_clk.c | 69 +++
board/freescale/common/ics307_clk.h |4 ++-
board/freescale/common/ngpixis.c| 27 ++
3 files changed, 99 insertions(+), 1 deletions(-)
diff --git a/board/freescale/common/ics307_clk.c
b/board/freescale/common/ics307_clk.c
index 89d8810..6804a32 100644
--- a/board/freescale/common/ics307_clk.c
+++ b/board/freescale/common/ics307_clk.c
@@ -31,12 +31,81 @@
#include pixis.h
#endif
+/* define for SYS CLK or CLK1Frequency */
+#define TTL1
+#define CLK2 0
+#define CRYSTAL0
+#define MAX_VDW(511 + 8)
+#define MAX_RDW(127 + 2)
+#define MIN_VDW(4 + 8)
+#define MIN_RDW(1 + 2)
+#define NUM_OD_SETTING 8
+/*
+ * These defines cover the industrial temperature range part,
+ * for commercial, change below to 40 and 55000, respectively
+ */
+#define MAX_VCO36
+#define MIN_VCO6
+
/* decode S[0-2] to Output Divider (OD) */
static u8 ics307_s_to_od[] = {
10, 2, 8, 4, 5, 7, 3, 6
};
/*
+ * Find one solution to generate required frequency for SYSCLK
+ * out_freq: KHz, required frequency to the SYSCLK
+ * the result will be retuned with component RDW, VDW, OD, TTL,
+ * CLK2 and crystal
+ */
+unsigned long ics307_sysclk_calculator(unsigned long out_freq)
+{
+ const unsigned long input_freq = CONFIG_ICS307_REFCLK_HZ;
+ unsigned long vdw, rdw, odp, s_vdw, s_rdw, s_odp, od;
+ unsigned long tmp_out, diff, result = 0;
+ int found = 0;
+
+ for (odp = 0; odp NUM_OD_SETTING; odp++) {
+ od = ics307_s_to_od[odp];
+ if (od * out_freq MIN_VCO || od * out_freq MAX_VCO)
+ continue;
+ for (rdw = MIN_RDW; rdw = MAX_RDW; rdw++) {
+ /* Calculate the VDW */
+ vdw = out_freq * 1000 * od * rdw / (input_freq * 2);
+ if (vdw MAX_VDW)
+ vdw = MAX_VDW;
+ if (vdw MIN_VDW)
+ continue;
+ /* Calculate the temp out frequency */
+ tmp_out = input_freq * 2 * vdw / (rdw * od * 1000);
+ diff = MAX(out_freq, tmp_out) - MIN(out_freq, tmp_out);
+ /*
+* calculate the percent, the precision is 1/1000
+* If greater than 1/1000, continue
+* otherwise, we think the solution is we required
+*/
+ if (diff * 1000 / out_freq 1)
+ continue;
+ else {
+ s_vdw = vdw;
+ s_rdw = rdw;
+ s_odp = odp;
+ found = 1;
+ break;
+ }
+ }
+ }
+
+ if (found)
+ result = (s_rdw - 2) | (s_vdw - 8) 7 | s_odp 16 |
+ CLK2 19 | TTL 21 | CRYSTAL 22;
+
+ debug(ICS307-02: RDW: %d, VDW: %d, OD: %d\n, s_rdw - 2, s_vdw - 8,
+ ics307_s_to_od[s_odp]);
+ return result;
+}
+
+/*
* Calculate frequency being generated by ICS307-02 clock chip based upon
* the control bytes being programmed into it.
*/
diff --git a/board/freescale/common/ics307_clk.h
b/board/freescale/common/ics307_clk.h
index db3dbc4..3757912 100644
--- a/board/freescale/common/ics307_clk.h
+++ b/board/freescale/common/ics307_clk.h
@@ -1,5 +1,5 @@
/*
- * Copyright 2010 Freescale Semiconductor, Inc.
+ * Copyright 2010-2011 Freescale Semiconductor, Inc.
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -23,8 +23,10
[U-Boot] [PATCH] ftsdc010: improve performance and capability
This patch improve the performance by spliting flag examination code
in ftsdc010_send_cmd() into 3 functions.
This patch also reordered the function which made better capability to
some high performance cards against to the next version of ftsdc010
hardware.
Signed-off-by: Macpaul Lin macp...@andestech.com
---
drivers/mmc/ftsdc010_esdhc.c | 172 +++---
1 files changed, 93 insertions(+), 79 deletions(-)
diff --git a/drivers/mmc/ftsdc010_esdhc.c b/drivers/mmc/ftsdc010_esdhc.c
index e38dd87..538800b 100644
--- a/drivers/mmc/ftsdc010_esdhc.c
+++ b/drivers/mmc/ftsdc010_esdhc.c
@@ -90,8 +90,13 @@ static void ftsdc010_pio_read(struct mmc_host *host, char
*buf, unsigned int siz
while (size) {
status = readl(host-reg-status);
+ debug(%s: size: %08x\n, __func__, size);
if (status FTSDC010_STATUS_FIFO_ORUN) {
+
+ debug(%s: FIFO OVERRUN: sta: %08x\n,
+ __func__, status);
+
fifo = host-fifo_len size ?
size : host-fifo_len;
@@ -146,7 +151,7 @@ static void ftsdc010_pio_write(struct mmc_host *host, const
char *buf,
while (size) {
status = readl(host-reg-status);
- if (status FTSDC010_STATUS_FIFO_ORUN) {
+ if (status FTSDC010_STATUS_FIFO_URUN) {
fifo = host-fifo_len size ?
size : host-fifo_len;
@@ -158,7 +163,6 @@ static void ftsdc010_pio_write(struct mmc_host *host, const
char *buf,
writel(*ptr, host-reg-dwr);
ptr++;
}
-
} else {
udelay(1);
if (++retry = FTSDC010_PIO_RETRY) {
@@ -169,56 +173,19 @@ static void ftsdc010_pio_write(struct mmc_host *host,
const char *buf,
}
}
-static int ftsdc010_pio_check_status(struct mmc *mmc, struct mmc_cmd *cmd,
+static int ftsdc010_check_rsp(struct mmc *mmc, struct mmc_cmd *cmd,
struct mmc_data *data)
{
struct mmc_host *host = mmc-priv;
-
unsigned int sta, clear;
- unsigned int i;
-
- /* check response and hardware status */
- clear = 0;
-
- /* chech CMD_SEND */
- for (i = 0; i FTSDC010_CMD_RETRY; i++) {
- sta = readl(host-reg-status);
- /* Command Complete */
- if (sta FTSDC010_STATUS_CMD_SEND) {
- if (!data)
- clear |= FTSDC010_CLR_CMD_SEND;
- break;
- }
- }
-
- if (i FTSDC010_CMD_RETRY) {
- printf(%s: send command timeout\n, __func__);
- return TIMEOUT;
- }
- /* debug: print status register and command index*/
- debug(sta: %08x cmd %d\n, sta, cmd-cmdidx);
-
- /* handle data FIFO */
- if ((sta FTSDC010_STATUS_FIFO_ORUN) ||
- (sta FTSDC010_STATUS_FIFO_URUN)) {
-
- /* Wrong DATA FIFO Flag */
- if (data == NULL)
- printf(%s, data fifo wrong: sta: %08x cmd %d\n,
- __func__, sta, cmd-cmdidx);
-
- if (sta FTSDC010_STATUS_FIFO_ORUN)
- clear |= FTSDC010_STATUS_FIFO_ORUN;
- if (sta FTSDC010_STATUS_FIFO_URUN)
- clear |= FTSDC010_STATUS_FIFO_URUN;
- }
+ sta = readl(host-reg-status);
+ debug(%s: sta: %08x cmd %d\n, __func__, sta, cmd-cmdidx);
/* check RSP TIMEOUT or FAIL */
if (sta FTSDC010_STATUS_RSP_TIMEOUT) {
/* RSP TIMEOUT */
- debug(%s: RSP timeout: sta: %08x cmd %d\n,
- __func__, sta, cmd-cmdidx);
+ debug(%s: RSP timeout: sta: %08x\n, __func__, sta);
clear |= FTSDC010_CLR_RSP_TIMEOUT;
writel(clear, host-reg-clr);
@@ -226,47 +193,62 @@ static int ftsdc010_pio_check_status(struct mmc *mmc,
struct mmc_cmd *cmd,
return TIMEOUT;
} else if (sta FTSDC010_STATUS_RSP_CRC_FAIL) {
/* clear response fail bit */
- debug(%s: RSP CRC FAIL: sta: %08x cmd %d\n,
- __func__, sta, cmd-cmdidx);
+ debug(%s: RSP CRC FAIL: sta: %08x\n, __func__, sta);
clear |= FTSDC010_CLR_RSP_CRC_FAIL;
writel(clear, host-reg-clr);
- return 0;
+ return COMM_ERR;
} else if (sta FTSDC010_STATUS_RSP_CRC_OK) {
/* clear response CRC OK bit */
clear |= FTSDC010_CLR_RSP_CRC_OK;
}
+ writel(clear, host-reg-clr);
+ return 0;
+}
+
+static int ftsdc010_check_data(struct mmc *mmc, struct mmc_cmd *cmd,
+ struct mmc_data *data)
Re: [U-Boot] [PATCH] dfu: initial implementation
Hello Stefan,
Thank you for your review. Please see comments inline.
On Wednesday, November 02, 2011 9:07 PM Stefan Schmidt wrote:
First, and only high level, review for the DFU part.
Against which u-boot tree/branch/version is this patch? I tried to
apply it against HEAD and it failed for me. Anything I miss?
Sorry about that. I forgot to mention the reference. It is
http://patchwork.ozlabs.org/patch/122080
On Wed, 2011-11-02 at 11:00, Andrzej Pietrasiewicz wrote:
The implementation is split into two parts: the dfu gadget
implementation
and a flashing backend, the interface between the two being the
struct flash_entity. The flashing backend's implementation is
board-specific and is implemented on the Goni target.
I replied to Mike's mail with my ideas on this. Split between dfu and
flashing backends is good and missng in my approach currently. I would
not put it into the board file though but make it generic for other
boards as well and only define the needed informations in the board
file. Please see my other mail for details. Comments appreciated!
Comments sent in other mails;) I agree that since there is interest
in implementing DFU in u-boot the code which in fact is not board
specific can and should be generalized. We need to think of an
appropriate place in the tree to store it, though.
diff --git a/common/Makefile b/common/Makefile
index ae795e0..de926d9 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -162,6 +162,7 @@ COBJS-y += cmd_usb.o
COBJS-y += usb.o
COBJS-$(CONFIG_USB_STORAGE) += usb_storage.o
endif
+COBJS-$(CONFIG_CMD_DEVICE_FIRMWARE_UPGRADE) += cmd_dfu.o
CONFIG_CMD_DFU instead? Looks a bit long to me.
ACK. No problem with changing that.
I already wrote a bit about my approach here. At OpenMoko we used a
button to enter u-boot during startup when pressed. This offered a
usbtty interface as usb gadget as well as the runtime descripto for
DFU. With dfu-util it was possible to iniate the DFU download or
upload procedure while being in the mode. Another option would be to
directly jump into DFU mode when a button is pressed.
Please see my comment in the other mail. A generic way to handle
a button pressed seems necessary. Actually in my opinion just
providing the dfu command is enough. If, in some hardware,
initiating the runtime mode is desired by pressing some keys, then
the board initialization code should check for such an event and
if it happens then just programmatically run the dfu command.
What do you think?
+/* #include usbstring.c */
Not needed, can be removed.
I agree to coding style/reduntant code comments; will not
specifically comment on them unless I disagree.
+static const struct dfu_function_descriptor dfu_func = {
+ .bLength = sizeof dfu_func,
+ .bDescriptorType = DFU_DT_FUNC,
+ .bmAttributes = DFU_BIT_WILL_DETACH |
Here are you setting the WILL_DETACH bit. Is the device really
detaching itself? Its not obvious to me from the code that it does.
It seems it does not. The dfu-util session says Resetting USB, so I
assume that resetting is initiated by the host, not by the device.
To be removed.
+static char manufacturer[50];
+static const char longname[] = DFU Gadget;
+/* default serial number takes at least two packets */
+static const char serial[] = 0123456789.0123456789.012345678;
+static const char dfu_name[] = Device Firmware Upgrade;
+static const char shortname[] = dfu;
This surely should be come from the board configuration?
Yes and no - depends on whether we want to version the gadget itself
or the flashing backend, or both. As probably the last option
is best, the answer is probably yes. We need some interface then.
+static bool is_runtime(struct dfu_dev *dev)
+{
+ return dev-dfu_state == DFU_STATE_appIDLE ||
+ dev-dfu_state == DFU_STATE_appDETACH;
+}
Hmm, here you are checking if you are in run-time mode. In the
introduction you wrote that it is in DFU mode when the dfu command is
executed. When does it enter the run-time mode? After the first
flashing?
I think this is over-interpretation of what I wrote in introduction.
I gave an example dfu-util session when the device is already in DFU
mode. I didn't say that it only has DFU mode. It has both.
+ /* send status response */
+ dstat-bStatus = dev-dfu_status;
+ /* FIXME: set dstat-bwPollTimeout */
This really needs to be set. It was a nightmare with dfu-util not
having it set with the initial u-boot implementation. setting the
correct values here is not that easy though. It depends on the flash
layer and if can get the information about the maximal time a flash
write can take.
Not sure what to do at this moment, either.
+ case USB_REQ_DFU_DETACH:
+ /* Proprietary extension: 'detach' from idle mode
and
+* get back to runtime mode in case of USB Reset.
As
+
[U-Boot] Coca Cola Company @ West Africa End of Year Promo.Email: frankmorri...@ymail.com
Win $500,000 in Coca Cola Company @ West Africa end of year promo.To qualify, Email the correct answer to the question given below to Mr. Frank Morris via (frankmorri...@ymail.com) Question: Who won the 2010 FIFA World Cup in South Africa? (A)England (B)Spain (C)Germany (D)Brazi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] net: introduce per device index
Am Do, 27.10.2011, 22:31 schrieb Michael Walle:
Instead of counting the device index everytime a functions needs it, store
it in the eth_device struct. eth_register() keeps track of the indices and
updates the device's index number. This simplifies some functions in
net/eth.c.
Additionally, a network driver can now query its index, eg. to get the
correct environment ethaddr name.
Ping, anyone?
Signed-off-by: Michael Walle mich...@walle.cc
Cc: Prafulla Wadaskar prafu...@marvell.com
Cc: Mike Frysinger vap...@gentoo.com
Cc: Wolfgang Denk w...@denx.de
---
include/net.h |1 +
net/eth.c | 41 -
2 files changed, 13 insertions(+), 29 deletions(-)
diff --git a/include/net.h b/include/net.h
index b408dea..7f9b1d1 100644
--- a/include/net.h
+++ b/include/net.h
@@ -89,6 +89,7 @@ struct eth_device {
#endif
int (*write_hwaddr) (struct eth_device*);
struct eth_device *next;
+ int index;
void *priv;
};
diff --git a/net/eth.c b/net/eth.c
index 4280d6d..b4b9b43 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -127,7 +127,6 @@ struct eth_device *eth_get_dev_by_name(const char
*devname)
struct eth_device *eth_get_dev_by_index(int index)
{
struct eth_device *dev, *target_dev;
- int idx = 0;
if (!eth_devices)
return NULL;
@@ -135,12 +134,11 @@ struct eth_device *eth_get_dev_by_index(int index)
dev = eth_devices;
target_dev = NULL;
do {
- if (idx == index) {
+ if (dev-index == index) {
target_dev = dev;
break;
}
dev = dev-next;
- idx++;
} while (dev != eth_devices);
return target_dev;
@@ -148,24 +146,11 @@ struct eth_device *eth_get_dev_by_index(int index)
int eth_get_dev_index (void)
{
- struct eth_device *dev;
- int num = 0;
-
- if (!eth_devices) {
- return (-1);
- }
-
- for (dev = eth_devices; dev; dev = dev-next) {
- if (dev == eth_current)
- break;
- ++num;
- }
-
- if (dev) {
- return (num);
+ if (!eth_current) {
+ return -1;
}
- return (0);
+ return eth_current-index;
}
static void eth_current_changed(void)
@@ -219,6 +204,7 @@ int eth_write_hwaddr(struct eth_device *dev, const
char *base_name,
int eth_register(struct eth_device *dev)
{
struct eth_device *d;
+ static int index = 0;
assert(strlen(dev-name) NAMESIZE);
@@ -233,14 +219,14 @@ int eth_register(struct eth_device *dev)
dev-state = ETH_STATE_INIT;
dev-next = eth_devices;
+ dev-index = index++;
return 0;
}
int eth_initialize(bd_t *bis)
{
- int eth_number = 0;
-
+ int num_devices = 0;
eth_devices = NULL;
eth_current = NULL;
@@ -281,7 +267,7 @@ int eth_initialize(bd_t *bis)
show_boot_progress (65);
do {
- if (eth_number)
+ if (dev-index)
puts (, );
printf(%s, dev-name);
@@ -294,18 +280,18 @@ int eth_initialize(bd_t *bis)
if (strchr(dev-name, ' '))
puts(\nWarning: eth device name has a
space!\n);
- if (eth_write_hwaddr(dev, eth, eth_number))
+ if (eth_write_hwaddr(dev, eth, dev-index))
puts(\nWarning: failed to set MAC address\n);
- eth_number++;
dev = dev-next;
+ num_devices++;
} while(dev != eth_devices);
eth_current_changed();
putc ('\n');
}
- return eth_number;
+ return num_devices;
}
#ifdef CONFIG_MCAST_TFTP
@@ -356,7 +342,6 @@ u32 ether_crc (size_t len, unsigned char const *p)
int eth_init(bd_t *bis)
{
- int eth_number;
struct eth_device *old_current, *dev;
if (!eth_current) {
@@ -365,16 +350,14 @@ int eth_init(bd_t *bis)
}
/* Sync environment with network devices */
- eth_number = 0;
dev = eth_devices;
do {
uchar env_enetaddr[6];
- if (eth_getenv_enetaddr_by_index(eth, eth_number,
+ if (eth_getenv_enetaddr_by_index(eth, dev-index,
env_enetaddr))
memcpy(dev-enetaddr, env_enetaddr, 6);
- ++eth_number;
dev = dev-next;
} while (dev != eth_devices);
--
1.7.2.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] net: introduce per device index
-Original Message- From: Michael Walle [mailto:mich...@walle.cc] Sent: Thursday, November 03, 2011 4:54 PM To: Michael Walle Cc: u-boot@lists.denx.de; Prafulla Wadaskar; Mike Frysinger; Wolfgang Denk; Michael Walle Subject: Re: [PATCH 1/2] net: introduce per device index Am Do, 27.10.2011, 22:31 schrieb Michael Walle: Instead of counting the device index everytime a functions needs it, store it in the eth_device struct. eth_register() keeps track of the indices and updates the device's index number. This simplifies some functions in net/eth.c. Additionally, a network driver can now query its index, eg. to get the correct environment ethaddr name. Ping, anyone? Signed-off-by: Michael Walle mich...@walle.cc Cc: Prafulla Wadaskar prafu...@marvell.com Cc: Mike Frysinger vap...@gentoo.com Cc: Wolfgang Denk w...@denx.de --- include/net.h |1 + net/eth.c | 41 --- These patches are for u-boot-net.git. Copying Ben on this. Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] reg: did u boot contains display driver
Hi all I need to know if u boot on i.mx 51 board contains display driver If yes how to test a display program in it. Regards Babu Shanmuga sundaram ::DISCLAIMER:: --- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. --- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] [MMC] Is the HIGH_SPEED_SUPPORT bit checked wrong in mmc.c?
Hi all, I have a problem on reading low speed card on my platform. While high speed card were all correct. However I have only SD 1.0 specification in hand, I'll try to get 3.0 version tomorrow. But, I've found that in include/mmc.h /* SCR definitions in different words */ #define SD_HIGHSPEED_BUSY 0x0002 #define SD_HIGHSPEED_SUPPORTED 0x0002 The both of these 2 defined the same value. Then I've force the driver/mmc/mmc.c return 0 before checking SD_HIGHSPEED_SUPPORTED bit. (workaround) All operations on low speed card get correct now. The mmcinfo, fatls and fatload works normally like high speed cards. --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -784,6 +784,7 @@ retry_scr: } /* If high-speed isn't supported, we return */ + return 0; if (!(__be32_to_cpu(switch_status[3]) SD_HIGHSPEED_SUPPORTED)) return 0; Because I have no specification in hand, I cannot check the bit fields and send correct patch if there is a problem until next week. Could someone help to check it before this weekend ? Thanks. -- Best regards, Macpaul Lin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dfu: initial implementation
On Thursday, November 03, 2011 11:33 AM Andrzej Pietrasiewicz wrote: Sorry about that. I forgot to mention the reference. It is http://patchwork.ozlabs.org/patch/122080 Sorry again. I meant http://patchwork.ozlabs.org/patch/122079 Andrzej ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dfu: initial implementation
Hello. On Thu, 2011-11-03 at 13:47, Andrzej Pietrasiewicz wrote: On Thursday, November 03, 2011 11:33 AM Andrzej Pietrasiewicz wrote: Sorry about that. I forgot to mention the reference. It is http://patchwork.ozlabs.org/patch/122080 Sorry again. I meant http://patchwork.ozlabs.org/patch/122079 Hmm, applied this one but the DFU patch stills fails to apply in goni.c and goni.h. Seems there is something else applied that is not in mainline yet. I can't test the goni part anyway as I don't have the hardware so I will split it out of the patch and test the dfu command and its implementation. regards Stefan Schmidt ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dfu: initial implementation
Hello. On Thu, 2011-11-03 at 09:12, Andrzej Pietrasiewicz wrote: On Wednesday, November 02, 2011 3:29 PM Stefan Shmidt wrote: Have you fully implemented 1.1? With the detahc logic inside the device implementation? As you noticed in another post, the state machine is reused. Yes, sorry about this. I was fouled into thinking you did not as it was splitted out and no mentioning of Harald copyright. Having the same state machine is a good base for further cooperation on this. :) Just curious. What version of dfu-util your are using for your tests? I released 0.5 earlier today. I used what was available in my desktop's Ubuntu 10.04 LTS, and it happens to be version 0.1+svn :O It works, though. Ah, latest Ubuntu has 0.3 and hopefully they will update as well. Already pinged the maintainer. Hmm, that sounds like you only implemented the DFU mode but not the run-time mode yet? This conclusion is not correct. Indeed. I stand corrected. After issuing the dfu command my implementation begins in runtime mode. Only after using dfu-util from the host is the mode changed to DFU mode. Actually, as far as usage of dfu-util is concerned, I find it inconvenient when the device is in runtime mode, because there (at least with my version of dfu-util) is no way for the user to guess what altsettings are actually available. Correct. Sadly this is due to the standard only allowing the functional descriptor in runtime mode. On the other hand the exposed alt settings in run-time mode would clutter the USB device settings. I personally do dfu-util -U file -a 0 or a similar command to kick the device into DFU mode, then dfu-util -l to discover what altsettings there are. I did run exactly in the same problem. :) I added a detach command to dfu-util to switch between the different modes. From run-time to dfu and from dfu to run-time. I wanted to get the release out before bringing it in. Pushed it to the master branch of dfu-util now. Feel free to test and let me know if it works for you. So, it could be tempting to omit the runtime mode at all and start in DFU mode, but, to be standard compliant, I start in runtime mode. How do you discover with dfu-util what altsettings there are in the device? See above. Not available in run-time mode. :/ While the original purpose of DFU was to make updating USB device easy enough for end-users as well. True, that's what the standard says about the very purpose of DFU. However, pressing keys to bring the device into a specific mode is probably very much device-specific. It would be nice if we are able to come up with a generic solution which only delegates the necessary details to board-specific files. Agreed. This should not be handled in the dfu implementation at all. Your split between dfu and flashing backend is a good step in the right direction here. Invoking the dfu mode through a command is also a nice addition. The implementation is split into two parts: the dfu gadget implementation and a flashing backend, the interface between the two being the struct flash_entity. The flashing backend's implementation is board-specific and is implemented on the Goni target. What is your reasoning behind this split? I have it working here with the normal nand_flashing routines taking care of bad blocks, etc. The reason is to factor out board-specific stuff from the dfu gadget implementation. However, in what I factored out probably there are parts which are generic enough not to be board-specific. Since there seems to be considerable interest in DFU implementation for u-boot, this could be reworked. After thinking more about it I agree with you here. The split makes sense and it will allow for more flexibility when adding more flashing backend to the implementation. To make it clear, I'm happy to see somebody else working on this Whap! --- Oh, man, we are not alone! ;) I am happy to hear from someone else who works on this, too. Good to know. :) Brainstorming about a way going forward. Please comment if with your view on this. o I will send out my not ready for mainline patch to give you and others an impression how it is tackled in my patch. o I like your split between dfu and flashing and also the addition of the dfu command. Could you split this part from the rest and send it as self conatining patch without other dependencies? o And then one patch with the mmc/fat flashing backend in moved out of the board file (no idea what the best place is, maybe just another file for now) and a last patch with all the board specific changes? o I will then rebase my code on yours and prepare patches against the dfu implementations as needed and also flashing backend for NAND. o After this we need to review was is missing and bring it over. Not all details covered in the plan but a start. Comments? regards Stefan Schmidt ___ U-Boot mailing
Re: [U-Boot] [PATCH] dfu: initial implementation
Hello. On Thu, 2011-11-03 at 09:44, Andrzej Pietrasiewicz wrote: On Wednesday, November 02, 2011 8:30 PM Stefan Schmidt writes: Agreed. The eMMC flashing with files on FAT is nothing goni specific. Others should be able to use this as well. I see three different parts here that can be separated: I agree. Since there is interest in DFU implementation this can and should be generalized. Great! 1) The DFU protocol implementation which lives in usb gadget with an interface for flashing backends 2) The flashing backends (no idea where to put them best). At the moment that would be the implementation here with eMMC and files on FAT, mine with raw NAND devices and in the future maybe others. Each flashing backend should be generic enough to allow different boards using it. 3) Board specific information like partitions or hints for the flashing backend. The information itself should be in the board file here and only used by the flashing backends. How does this sound to you? Andrzej? Sounds good to me. In my implementation the interface between dfu gadget and flashing backend is around the struct flash_entity. It contains a character string intended to provide a human-readable name, a void * context which is not interpreted by the gadget code, but is passed to the flashing backend and understood by it. The struct flash_entity also contains prepare-finish methods to be called before and after read/write operations, and the read_block- write_block pair. What do you think? I would need to use it for my NAND backend before I really can comment on it. I can only tell if I'm happy with and interface if I actually used it. :) Will do this when you send it a separate patch with only the DFU implementation with the flash entity as interface. See my roadmap proposal in the other mail. As far as generalization is concerned, in my flashing backend implementation I see these parts as candidates for generalization: 1) mbr/ebr reading 2) reading/writing mmc 3) read/write fat Agreed. That can be used by all kind of devices. 4) generic prepare/finish; not sure if fat-specific prepare can be generalized Would be good to get soem comments on the fs custodians around here. 5) read/write_block Agreed. 6) some more work should be put to create an interface between the board initialization routine, the flashing backend and the DFU gadget implementation. In my implementation the board initialization routine calls board-specific register_flash_areas, which, in turn, calls DFU gadget's register_flash_entities. What's your opinion? The interface between the configuration in the board file and the actual flashing backend is something I haven't wraped my mind around yet. Need to think about it. regards Stefan Schmidt ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dfu: initial implementation
Hello Stefan, On Thursday, November 03, 2011 2:32 PM Stefan Schmidt wrote: Sorry about that. I forgot to mention the reference. It is http://patchwork.ozlabs.org/patch/122080 Sorry again. I meant http://patchwork.ozlabs.org/patch/11122079 Hmm, applied this one but the DFU patch stills fails to apply in goni.c and goni.h. Seems there is something else applied that is not in mainline yet. Ok, here is the full story: this http://patchwork.ozlabs.org/patch/11122079 is the second patch in a series, the first being http://patchwork.ozlabs.org/patch/122080 and you actually need both. I pulled the latest git.denx.de tree and had to also apply a patch which Defines CONFIG_SYS_CACHELINE_SIZE for Goni target. It can be found here: http://article.gmane.org/gmane.comp.boot-loaders.u-boot/112755/match= I know this is confusing. Sorry about that. Andrzej ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dfu: initial implementation
Hello.
On Thu, 2011-11-03 at 11:33, Andrzej Pietrasiewicz wrote:
On Wednesday, November 02, 2011 9:07 PM Stefan Schmidt wrote:
On Wed, 2011-11-02 at 11:00, Andrzej Pietrasiewicz wrote:
diff --git a/common/Makefile b/common/Makefile
index ae795e0..de926d9 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -162,6 +162,7 @@ COBJS-y += cmd_usb.o
COBJS-y += usb.o
COBJS-$(CONFIG_USB_STORAGE) += usb_storage.o
endif
+COBJS-$(CONFIG_CMD_DEVICE_FIRMWARE_UPGRADE) += cmd_dfu.o
CONFIG_CMD_DFU instead? Looks a bit long to me.
ACK. No problem with changing that.
OK
I already wrote a bit about my approach here. At OpenMoko we used a
button to enter u-boot during startup when pressed. This offered a
usbtty interface as usb gadget as well as the runtime descripto for
DFU. With dfu-util it was possible to iniate the DFU download or
upload procedure while being in the mode. Another option would be to
directly jump into DFU mode when a button is pressed.
Please see my comment in the other mail. A generic way to handle
a button pressed seems necessary. Actually in my opinion just
providing the dfu command is enough. If, in some hardware,
initiating the runtime mode is desired by pressing some keys, then
the board initialization code should check for such an event and
if it happens then just programmatically run the dfu command.
What do you think?
Lets go with your dfu implementation and the dfu command. I will
prepare patches against is if I see something missing from my patch.
+/* #include usbstring.c */
Not needed, can be removed.
I agree to coding style/reduntant code comments; will not
specifically comment on them unless I disagree.
Thanks.
+static const struct dfu_function_descriptor dfu_func = {
+ .bLength = sizeof dfu_func,
+ .bDescriptorType = DFU_DT_FUNC,
+ .bmAttributes = DFU_BIT_WILL_DETACH |
Here are you setting the WILL_DETACH bit. Is the device really
detaching itself? Its not obvious to me from the code that it does.
It seems it does not. The dfu-util session says Resetting USB, so I
assume that resetting is initiated by the host, not by the device.
To be removed.
So far I also put this aside. Its only a 1.1 feature which can be
added with another patch when the basic stuff is working and merged.
+static char manufacturer[50];
+static const char longname[] = DFU Gadget;
+/* default serial number takes at least two packets */
+static const char serial[] = 0123456789.0123456789.012345678;
+static const char dfu_name[] = Device Firmware Upgrade;
+static const char shortname[] = dfu;
This surely should be come from the board configuration?
Yes and no - depends on whether we want to version the gadget itself
or the flashing backend, or both. As probably the last option
is best, the answer is probably yes. We need some interface then.
As I already stated this part is not worked out in my head yet. Feel
free to propose something or we will fix it while working on it.
+static bool is_runtime(struct dfu_dev *dev)
+{
+ return dev-dfu_state == DFU_STATE_appIDLE ||
+ dev-dfu_state == DFU_STATE_appDETACH;
+}
Hmm, here you are checking if you are in run-time mode. In the
introduction you wrote that it is in DFU mode when the dfu command is
executed. When does it enter the run-time mode? After the first
flashing?
I think this is over-interpretation of what I wrote in introduction.
I gave an example dfu-util session when the device is already in DFU
mode. I didn't say that it only has DFU mode. It has both.
Yeah, sorry for that. I indeed misread this part of your
implementation.
+ /* send status response */
+ dstat-bStatus = dev-dfu_status;
+ /* FIXME: set dstat-bwPollTimeout */
This really needs to be set. It was a nightmare with dfu-util not
having it set with the initial u-boot implementation. setting the
correct values here is not that easy though. It depends on the flash
layer and if can get the information about the maximal time a flash
write can take.
Not sure what to do at this moment, either.
If we don't have a back channel from the actual flashing subsystem we
need to oriantate the values on the hardware spec on own measurements
I fear. Soemthing that need to be set in the board file then.
+ case USB_REQ_DFU_DETACH:
+ /* Proprietary extension: 'detach' from idle mode
and
+ * get back to runtime mode in case of USB Reset.
As
+ * much as I dislike this, we just can't use every
USB
+ * bus reset to switch back to runtime mode, since
at
+ * least the Linux USB stack likes to send a number
of
+ * resets in a row :(
+ */
OK, this makes it clear that you took the DFU state machine from
Haralds implementation I'm also using. :)
[U-Boot] Business propossal.
I Seek for your Partnership from Intl Bank of Taipei Taiwan. Contact (mr.wen...@yahoo.com.tw)if interested. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] tegra2: Enable second SD port (J5) on Harmony
Andy Fleming wrote at Wednesday, November 02, 2011 6:17 PM: I'm currently assuming this patch has been superseded by the patches you submitted on the 31st? That looks correct, yes. This whole v2 series was replaced by v7 IIRC. On Tue, Oct 4, 2011 at 12:32 PM, Stephen Warren swar...@nvidia.com wrote: Seaboard uses SDMMC4, SDMMC3. Harmony uses SDMMC4, SDMMC2. Move board_init_mmc and gpio_config_mmc into board-specific files, so boards can choose which ports to set up. Split clock_init_mmc and pin_mux_mmc into per-port functions, and export them for use by boards. Signed-off-by: Stephen Warren swar...@nvidia.com -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Reduce build times
Hi Wolfgang, On Wed, Nov 2, 2011 at 11:48 PM, Wolfgang Denk w...@denx.de wrote: Dear Daniel Schwierzeck, In message cacuy__ujmnrykmwimb9pqr0_ds6cgiyo-msovy4esh2zt6z...@mail.gmail.com you wrote: On Wed, Nov 2, 2011 at 7:54 AM, Wolfgang Denk w...@denx.de wrote: U-Boot Makefiles contain a number of tests for compiler features etc. which so far are executed again and again. =C2=A0On some architectures (especially ARM) this results in a large number of calls to gcc. This patch makes sure to run such tests only once, thus largely reducing the number of execve system calls. maybe you want to try this experimental patch. http://patchwork.ozlabs.org/patch/123313/ It significantly reduces the count of gcc calls by caching the results. This also improves compilation times. Do you suggest this in addition or instead of the patch I posted? Can you provide some measurements of build times and/or execve system calls? I ran some additonal tests with interesting results. Board: ARM, Tegra2, seaboard Toolchain: Sourcery G++ Lite 2011.03-41 for ARM GNU/Linux Workstation: Core 2 Duo E6600 @2,4 Ghz, 4 GB, x86_64 I patched the cc-option macro to count all calls like this: cc-option = $(shell if $(CC) $(CFLAGS) $(1) -S -o /dev/null -xc /dev/null \ -/dev/null 21; then echo $(1); else echo $(2); fi ;) +/dev/null 21; then echo $(1); echo $1 $(OBJTREE)/cc-option; else echo $(2); fi ;) I ran the steps below for following source trees: - unmodified HEAD - only your patch - only my patch - both patches combined Steps: Complete build: - git clean -xdf - CROSS_COMPILE=/opt/codesourcery/arm-2011.03/bin/arm-none-linux-gnueabi- make seaboard_config - time CROSS_COMPILE=/opt/codesourcery/arm-2011.03/bin/arm-none-linux-gnueabi- CACHE_CC_OPTIONS=y make -s - cat cc-option | wc -l Incremental rebuild: - time CROSS_COMPILE=/opt/codesourcery/arm-2011.03/bin/arm-none-linux-gnueabi- CACHE_CC_OPTIONS=y make -s Complete build with strace: - git clean -xdf - CROSS_COMPILE=/opt/codesourcery/arm-2011.03/bin/arm-none-linux-gnueabi- make seaboard_config - CROSS_COMPILE=/opt/codesourcery/arm-2011.03/bin/arm-none-linux-gnueabi- CACHE_CC_OPTIONS=y strace -f -e trace=execve -o strace.out make -s - grep execve strace.out | wc -l Results: unmodified HEAD: real1m11.540s user2m7.170s sys 0m19.840s cc-option calls 3024 real0m20.176s user0m39.260s sys 0m6.480s execve calls 16502 only your patch: real0m32.371s user0m47.440s sys 0m7.900s cc-option calls 864 real0m9.606s user0m16.890s sys 0m2.940s execve calls 5906 only my patch: real0m28.187s user0m56.030s sys 0m7.820s cc-option calls 20 real0m5.013s user0m13.300s sys 0m2.200s execve calls 7415 both patches combined: real0m19.777s user0m28.010s sys 0m4.100s cc-option calls 8 real0m2.902s user0m6.400s sys 0m1.070s execve calls 3329 Conclusion: - complete build time reduced from 1m11s to 20s - incremental rebuild time reduced from 20s to 3s - cc-option calls reduced from 3024 to 8 - execve calls reduced from 16502 to 3329 Best regards, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] Another DFU implementation
Hello. This patch is not meant for merging yet. I'm sending it here to allow Andrzej and other having a look at this implementation. The end goal would be to merge both DFU implementations with a split between DFU implementation and different flashing backends. Architectural comments are really welcome here. Coding style and implementation details are likely to change. regards Stefan Schmidt Stefan Schmidt (1): usb/gadget: Add Device Firmware Upgrade (DFU) support. drivers/serial/usbtty.c | 22 +- drivers/serial/usbtty.h |6 + drivers/usb/gadget/Makefile |1 + drivers/usb/gadget/core.c | 19 + drivers/usb/gadget/dfu.c | 1007 + drivers/usb/gadget/ep0.c | 50 ++- include/usb_dfu.h | 95 include/usb_dfu_descriptors.h | 94 include/usbdevice.h | 13 + 9 files changed, 1303 insertions(+), 4 deletions(-) create mode 100644 drivers/usb/gadget/dfu.c create mode 100644 include/usb_dfu.h create mode 100644 include/usb_dfu_descriptors.h -- 1.7.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] usb/gadget: Add Device Firmware Upgrade (DFU) support.
A vendor independent standard from the USB forum to upgrade firmware on
devices over USB. U-Boot is seen as the device to be upgraded here and
exposes the functionality over the USB gadget framework.
Signed-off-by: Stefan Schmidt ste...@datenfreihafen.org
---
drivers/serial/usbtty.c | 22 +-
drivers/serial/usbtty.h |6 +
drivers/usb/gadget/Makefile |1 +
drivers/usb/gadget/core.c | 19 +
drivers/usb/gadget/dfu.c | 1007 +
drivers/usb/gadget/ep0.c | 50 ++-
include/usb_dfu.h | 95
include/usb_dfu_descriptors.h | 94
include/usbdevice.h | 13 +
9 files changed, 1303 insertions(+), 4 deletions(-)
create mode 100644 drivers/usb/gadget/dfu.c
create mode 100644 include/usb_dfu.h
create mode 100644 include/usb_dfu_descriptors.h
diff --git a/drivers/serial/usbtty.c b/drivers/serial/usbtty.c
index cffd5a2..b13b497 100644
--- a/drivers/serial/usbtty.c
+++ b/drivers/serial/usbtty.c
@@ -22,6 +22,8 @@
*/
#include common.h
+#include usb_dfu_descriptors.h
+#include usb_dfu.h
#include config.h
#include circbuf.h
#include stdio_dev.h
@@ -101,7 +103,7 @@ extern struct usb_string_descriptor **usb_strings;
static unsigned short rx_endpoint = 0;
static unsigned short tx_endpoint = 0;
static unsigned short interface_count = 0;
-static struct usb_string_descriptor *usbtty_string_table[STR_COUNT];
+static struct usb_string_descriptor *usbtty_string_table[NUM_STRINGS];
/* USB Descriptor Strings */
static u8 wstrLang[4] = {4,USB_DT_STRING,0x9,0x4};
@@ -151,6 +153,10 @@ struct acm_config_desc {
/* Slave Interface */
struct usb_interface_descriptor data_class_interface;
struct usb_endpoint_descriptor data_endpoints[NUM_ENDPOINTS-1];
+#ifdef CONFIG_USBD_DFU
+ struct usb_interface_descriptor uif_dfu;
+ struct usb_dfu_func_descriptor func_dfu;
+#endif
} __attribute__((packed));
static struct acm_config_desc acm_configuration_descriptors[NUM_CONFIGS] = {
@@ -161,7 +167,11 @@ static struct acm_config_desc
acm_configuration_descriptors[NUM_CONFIGS] = {
.bDescriptorType = USB_DT_CONFIG,
.wTotalLength =
cpu_to_le16(sizeof(struct acm_config_desc)),
+#ifdef CONFIG_USBD_DFU
+ .bNumInterfaces = NUM_ACM_INTERFACES + 1,
+#else
.bNumInterfaces = NUM_ACM_INTERFACES,
+#endif
.bConfigurationValue = 1,
.iConfiguration = STR_CONFIG,
.bmAttributes =
@@ -260,6 +270,11 @@ static struct acm_config_desc
acm_configuration_descriptors[NUM_CONFIGS] = {
.bInterval = 0xFF,
},
},
+#ifdef CONFIG_USBD_DFU
+ /* Interface 3 */
+ .uif_dfu = DFU_RT_IF_DESC,
+ .func_dfu = DFU_FUNC_DESC,
+#endif
},
};
@@ -370,7 +385,7 @@ static int fill_buffer (circbuf_t * buf);
void usbtty_poll (void);
/* utility function for converting char* to wide string used by USB */
-static void str2wide (char *str, u16 * wide)
+void str2wide (char *str, u16 * wide)
{
int i;
for (i = 0; i strlen (str) str[i]; i++){
@@ -639,6 +654,9 @@ static void usbtty_init_instances (void)
device_instance-bus = bus_instance;
device_instance-configurations = NUM_CONFIGS;
device_instance-configuration_instance_array = config_instance;
+#ifdef CONFIG_USBD_DFU
+ dfu_init_instance(device_instance);
+#endif
/* initialize bus instance */
memset (bus_instance, 0, sizeof (struct usb_bus_instance));
diff --git a/drivers/serial/usbtty.h b/drivers/serial/usbtty.h
index a23169a..bb45025 100644
--- a/drivers/serial/usbtty.h
+++ b/drivers/serial/usbtty.h
@@ -84,4 +84,10 @@
#define STR_CTRL_INTERFACE 0x06
#define STR_COUNT 0x07
+#ifdef CONFIG_USBD_DFU
+#define NUM_STRINGSDFU_STR_COUNT
+#else
+#define NUM_STRINGSSTR_COUNT
+#endif
+
#endif
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index 7d5b504..570470d 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -34,6 +34,7 @@ else
ifdef CONFIG_USB_DEVICE
COBJS-y += core.o
COBJS-y += ep0.o
+COBJS-y += dfu.o
COBJS-$(CONFIG_OMAP1510) += omap1510_udc.o
COBJS-$(CONFIG_OMAP1610) += omap1510_udc.o
COBJS-$(CONFIG_MPC885_FAMILY) += mpc8xx_udc.o
diff --git a/drivers/usb/gadget/core.c b/drivers/usb/gadget/core.c
index 67b6681..e5ee9f6 100644
--- a/drivers/usb/gadget/core.c
+++ b/drivers/usb/gadget/core.c
@@ -31,6 +31,7 @@
#include malloc.h
#include usbdevice.h
+#include usb_dfu.h
#define MAX_INTERFACES 2
@@ -209,6 +210,10 @@ struct usb_alternate_instance
*usbd_device_alternate_instance (struct usb_device
*/
struct usb_device_descriptor *usbd_device_device_descriptor (struct
usb_device_instance
Re: [U-Boot] [PATCH 3/4 V2] OneNAND: Add simple OneNAND SPL
On 11/02/2011 07:15 PM, Marek Vasut wrote:
On 11/01/2011 05:54 PM, Marek Vasut wrote:
+static void spl_onenand_get_geometry(struct spl_onenand_data *data)
+{
[...]
+ /* The page can be either 2k or 4k, avoid using DIV_ROUND_UP. */
+ if (data.pagesize == 2048) {
+ total_pages = len / 2048;
+ page = offset / 2048;
+ total_pages += !!(len 2047);
+ } else if (data.pagesize == 4096) {
+ total_pages = len / 4096;
+ page = offset / 4096;
+ total_pages += !!(len 4095);
+ }
What's wrong with DIV_ROUND_UP? It should produce smaller code than
what you've done here...
It pulls in aeabi_*div* functions, which won't fit into block 0 of Onenand.
It shouldn't do that if the divisor is a constant power of 2. The
compiler will turn it into a shift, just like with the other divides in
the above code fragment.
You can't use DIV_ROUND_UP directly on data.pagesize, but you can use it
in each branch of the if statement instead of that awkward and slightly
more expensive !!(len 4095) construct.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Allow for parallel builds and saved output
Hi Andy,
On Thu, Nov 3, 2011 at 12:28 AM, Andy Fleming aflem...@freescale.com wrote:
The MAKEALL script cleverly runs make with the appropriate options
to use all of the cores on the system, but your average U-Boot build
can't make much use of more than a few cores. If you happen to have
a many-core server, your builds will leave most of the system idle.
In order to make full use of such a system, we need to build multiple
targets in parallel, and this requires directing make output into
multiple directories. We add a BUILD_NBUILDS variable, which allows
users to specify how many builds to run in parallel. I've found that
16 is too many on my system (fork starts to fail). When BUILD_NBUILDS
is set greater than 1, we redefine BUILD_DIR for each build to be
${BUILD_DIR}/${target}. Also, we make ./build the default BUILD_DIR
when BUILD_NBUILDS is greater than 1.
Once each build finishes, we run make clean on its directory, to reduce
the footprint, and also remove all .depend files.
As a result, we are left with a build directory with all of the built
targets still there for use, which means anyone who wanted to use
MAKEALL as part of a test harness can now do so.
Signed-off-by: Andy Fleming aflem...@freescale.com
---
Inspired by all the MAKEALL improvements, I decided to clean up my old
one for parallel builds. I think this version addresses the concerns
raised last time...
Thanks very much for posting this. The low CPU utilization is
something that has bugged me - I get maybe 20% at best. I was
thinking about writing a little script which fires off one job as soon
as the first complete, and keeps maybe 20 jobs running at once. This
patch does most of that, with the limitation that jobs that finish
early can leave idle CPU time.
With your patch I get at least 70% CPU averaged over the whole
MAKEALL, and all the ARM boards build in 5 minutes (with Wolfgang and
Daniel Schwierzeck's patches also). The only proviso is that you need
to set BUILD_NCPUS to 1 I think - maybe your patch should do that also
? Otherwise I got a load average of 220...
If you get back to this sometime the other little wish is that it
could perhaps display the output of the build together, perhaps
buffering it in a log file first. So instead of:
Configuring for imx31_phycore_eet - Board: imx31_phycore, Options:
IMX31_PHYCORE_EET
Configuring for imx31_phycore_eet - Board: imx31_phycore, Options:
IMX31_PHYCORE_EET
Configuring for imx31_phycore board...
board.c:389: error: 'MACH_TYPE_TIAM335EVM' undeclared (first use in
this function)
board.c:389: error: (Each undeclared identifier is reported only once
board.c:389: error: for each function it appears in.)
make[1]: *** [/c/cosarm/buildall/u-boot/build/am335x_evm/arch/arm/lib/board.o]
Error 1
make: *** [/c/cosarm/buildall/u-boot/build/am335x_evm/arch/arm/lib/libarm.o]
Error 2
arm-none-linux-gnueabi-size: './build/am335x_evm/u-boot': No such file
cmd_version.c:29: error: expected ',' or ';' before 'U_BOOT_DATE'
textdata bss dec hex filename
1767923144 223300 403236 62724 ./build/ca9x4_ct_vxp/u-boot
textdata bss dec hex filename
1562362788 10776 169800 29748 ./build/highbank/u-boot
it could do:
Configuring for board1
warnings/errors for board1
size info for board1
Configuring for board2
warnings/errors for board2
size info for board2
...
Tested-by: Simon Glass s...@chromium.org
Regards,
Simon
MAKEALL | 74 ++
1 files changed, 64 insertions(+), 10 deletions(-)
diff --git a/MAKEALL b/MAKEALL
index 95b7cd3..4583ddb 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -31,6 +31,7 @@ usage()
CROSS_COMPILE cross-compiler toolchain prefix (default: )
MAKEALL_LOGDIR output all logs to here (default: ./LOG/)
BUILD_DIR output build directory (default: ./)
+ BUILD_NBUILDS number of parallel targets (default: 1)
Examples:
- build all Power Architecture boards:
@@ -160,10 +161,23 @@ else
LOG_DIR=LOG
fi
+if [ ! ${BUILD_NBUILDS} ] ; then
+ BUILD_NBUILDS=1
+fi
+
+if [ $BUILD_NBUILDS -gt 1 ] ; then
+ if [ ! ${BUILD_DIR} ] ; then
+ BUILD_DIR=./build
+ fi
+ mkdir -p ${BUILD_DIR}/ERR
+fi
+
if [ ! ${BUILD_DIR} ] ; then
BUILD_DIR=.
fi
+OUTPUT_PREFIX=${BUILD_DIR}
+
[ -d ${LOG_DIR} ] || mkdir ${LOG_DIR} || exit 1
LIST=
@@ -483,32 +497,52 @@ LIST_sparc=$(boards_by_arch sparc)
LIST_nds32=$(boards_by_arch nds32)
+CURRENT_COUNT=0
+
#---
build_target() {
target=$1
+ if [ $BUILD_NBUILDS -gt 1 ] ; then
+ output_dir=${OUTPUT_PREFIX}/${target}
+ mkdir -p ${output_dir}
+ else
+ output_dir=${OUTPUT_PREFIX}
+ fi
+
+ export BUILD_DIR=${output_dir}
+
${MAKE}
[U-Boot] Please pull u-boot-ti/master
Albert, Please pull u-boot-ti/master Regards, Sandeep The following changes since commit ce5207e191c59b3135303fd03b98dd2ac3701ba2: Kyle Moffett (1): e1000: Allow direct access to the E1000 SPI EEPROM device are available in the git repository at: git://git.denx.de/u-boot-ti.git master Bastian Ruppert (4): Davinci: ea20: set console on UART0 Davinci: ea20: set GPIOs to hold MII-Phy in reset and set UART0-Switch for console Davinci: ea20: add gpio for keeping power on in board_late_init Davinci: ea20: add gpios for LCD backlight control Christian Riesch (1): arm, davinci: Add function lpsc_syncreset() Heiko Schocher (13): arm, davinci: replace CONFIG_PRELOADER with CONFIG_SPL_BUILD arm, arm926: fix missing symbols in NAND_SPL mode usb, davinci: add enable_vbus() weak function arm, usb, davinci: make USBPHY_CTL register configurable net, davinci_emac: make clock divider in MDIO control register configurable spl: add option for adding post memory test to the SPL framework arm, davinci: add support for new spl framework spl, nand: add 4bit HW ecc oob first nand_read_page function arm, davinci: add header files for dm365 arm, davinci: add lowlevel function for dm365 soc arm926ejs, davinci: add cpuinfo for dm365 arm926ejs, davinci: add missing spi defines for dm365 arm, davinci: add cam_enc_4xx support Ilya Yanok (2): davinci_emac: compilation fix, phy is array now omap/spl: actually enable the console Sanjeev Premi (7): omap3evm: Set environment variable 'ethaddr' omap3evm: Reorder related config options omap3evm: Prepare to split configuration omap3evm: move common config options to new file omap3evm: Add (quick) configuration for MMC/SD only omap3evm: Add (quick) configuration for NAND only omap3evm: fix errors caused by multiple definitions Stefano Babic (8): Davinci: ea20: Add NAND support Davinci: ea20: Add early init to get early output from console Davinci: ea20: Add default U-Boot environment ARM: Davinci: added missing registers to hardware.h VIDEO: davinci: add framebuffer to da8xx Davinci: ea20: added video support Davinci: ea20: added I2C support Davinci: ea20: added PREBOOT to configuration MAINTAINERS|1 + Makefile |8 +- README |5 + arch/arm/cpu/arm926ejs/davinci/Makefile|5 + arch/arm/cpu/arm926ejs/davinci/cpu.c | 27 +- arch/arm/cpu/arm926ejs/davinci/dm365_lowlevel.c| 439 ++ arch/arm/cpu/arm926ejs/davinci/psc.c | 20 +- arch/arm/cpu/arm926ejs/davinci/spl.c | 63 ++ arch/arm/cpu/arm926ejs/start.S | 31 +- arch/arm/cpu/armv7/omap-common/spl.c |2 + arch/arm/include/asm/arch-davinci/aintc_defs.h | 50 ++ arch/arm/include/asm/arch-davinci/da8xx-fb.h | 126 +++ arch/arm/include/asm/arch-davinci/dm365_lowlevel.h | 41 + arch/arm/include/asm/arch-davinci/hardware.h | 27 +- arch/arm/include/asm/arch-davinci/pll_defs.h | 84 ++ arch/arm/include/asm/arch-davinci/psc_defs.h | 86 ++ arch/arm/include/asm/arch-davinci/syscfg_defs.h| 66 ++ board/ait/cam_enc_4xx/Makefile | 46 ++ board/ait/cam_enc_4xx/cam_enc_4xx.c| 446 +++ board/ait/cam_enc_4xx/config.mk| 15 + board/ait/cam_enc_4xx/u-boot-spl.lds | 73 ++ board/ait/cam_enc_4xx/ublimage.cfg | 48 ++ board/davinci/common/misc.c|2 +- board/davinci/ea20/ea20.c | 205 - board/ti/evm/evm.c | 15 + boards.cfg |3 + doc/README.SPL |2 + doc/README.davinci.nand_spl| 141 drivers/mtd/nand/Makefile |3 + drivers/mtd/nand/nand_spl_load.c | 56 ++ drivers/mtd/nand/nand_spl_simple.c | 43 +- drivers/net/davinci_emac.c | 11 +- drivers/usb/musb/davinci.c | 20 +- drivers/video/Makefile |1 + drivers/video/da8xx-fb.c | 846 include/configs/cam_enc_4xx.h | 453 +++ include/configs/ea20.h | 126 +++- include/configs/omap3_evm.h| 331 ++--- include/configs/omap3_evm_common.h | 292 +++ include/configs/omap3_evm_quick_mmc.h | 91 +++ include/configs/omap3_evm_quick_nand.h | 79 ++ spl/Makefile
Re: [U-Boot] [PATCH 3/4 V2] OneNAND: Add simple OneNAND SPL
On 11/02/2011 07:15 PM, Marek Vasut wrote:
On 11/01/2011 05:54 PM, Marek Vasut wrote:
+static void spl_onenand_get_geometry(struct spl_onenand_data *data)
+{
[...]
+ /* The page can be either 2k or 4k, avoid using DIV_ROUND_UP. */
+ if (data.pagesize == 2048) {
+ total_pages = len / 2048;
+ page = offset / 2048;
+ total_pages += !!(len 2047);
+ } else if (data.pagesize == 4096) {
+ total_pages = len / 4096;
+ page = offset / 4096;
+ total_pages += !!(len 4095);
+ }
What's wrong with DIV_ROUND_UP? It should produce smaller code than
what you've done here...
It pulls in aeabi_*div* functions, which won't fit into block 0 of
Onenand.
It shouldn't do that if the divisor is a constant power of 2. The
compiler will turn it into a shift, just like with the other divides in
the above code fragment.
You can't use DIV_ROUND_UP directly on data.pagesize, but you can use it
in each branch of the if statement instead of that awkward and slightly
more expensive !!(len 4095) construct.
Expensive in what way? Either way, I don't think this matters that much.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4 V2] OneNAND: Add simple OneNAND SPL
On 11/03/2011 11:56 AM, Marek Vasut wrote:
On 11/02/2011 07:15 PM, Marek Vasut wrote:
On 11/01/2011 05:54 PM, Marek Vasut wrote:
+static void spl_onenand_get_geometry(struct spl_onenand_data *data)
+{
[...]
+ /* The page can be either 2k or 4k, avoid using DIV_ROUND_UP. */
+ if (data.pagesize == 2048) {
+ total_pages = len / 2048;
+ page = offset / 2048;
+ total_pages += !!(len 2047);
+ } else if (data.pagesize == 4096) {
+ total_pages = len / 4096;
+ page = offset / 4096;
+ total_pages += !!(len 4095);
+ }
What's wrong with DIV_ROUND_UP? It should produce smaller code than
what you've done here...
It pulls in aeabi_*div* functions, which won't fit into block 0 of
Onenand.
It shouldn't do that if the divisor is a constant power of 2. The
compiler will turn it into a shift, just like with the other divides in
the above code fragment.
You can't use DIV_ROUND_UP directly on data.pagesize, but you can use it
in each branch of the if statement instead of that awkward and slightly
more expensive !!(len 4095) construct.
Expensive in what way?
Compare the resulting asm code. You're replacing this:
a = (b + 4095) 12;
with this:
a = b 12;
if (b 4095)
a++;
Either way, I don't think this matters that much.
This is code that has to fit in 1K -- why waste instructions by writing
code in a way that is *less* readable?
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Financial Help
-- Hi Mr/Mrs, rex capital investment is best positioned within London to help you in finding the most optimal solution and support you throughout the whole process of company establishment,account opening and funding operations. Our goal is to share our experience and connectivity with companies/individuals who wish to establish large or small businesses or simply want financial instruments for their transactions. All you need to do is to provide the necessary paper works and pay the charges involved.Our firm will arrange for the lender and the provider .We also provide instrument for trading program and arrange for platform. Contact us below for more details. Email: rexcapita...@yahoo.com Regards Mr.Kezman Asst President rex capital investment Inc Flat #2 first floor,Tavistock House North, Tavistock Square, LONDON, WC1H 9HR United Kingdom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
s-paul...@ti.com wrote: Albert, Please pull u-boot-ti/master Regards, Sandeep The following changes since commit ce5207e191c59b3135303fd03b98dd2ac3701ba2: Kyle Moffett (1): e1000: Allow direct access to the E1000 SPI EEPROM device are available in the git repository at: git://git.denx.de/u-boot-ti.git master Hi Sandeep, yesterday I sent two patches to make the dig297 board compile again after the mach-types sync. Did you receive them? http://lists.denx.de/pipermail/u-boot/2011-November/108000.html http://lists.denx.de/pipermail/u-boot/2011-November/108001.html Thanks, Luca ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4 V2] OneNAND: Add simple OneNAND SPL
On 11/03/2011 11:56 AM, Marek Vasut wrote:
On 11/02/2011 07:15 PM, Marek Vasut wrote:
On 11/01/2011 05:54 PM, Marek Vasut wrote:
+static void spl_onenand_get_geometry(struct spl_onenand_data *data)
+{
[...]
+ /* The page can be either 2k or 4k, avoid using DIV_ROUND_UP. */
+ if (data.pagesize == 2048) {
+ total_pages = len / 2048;
+ page = offset / 2048;
+ total_pages += !!(len 2047);
+ } else if (data.pagesize == 4096) {
+ total_pages = len / 4096;
+ page = offset / 4096;
+ total_pages += !!(len 4095);
+ }
What's wrong with DIV_ROUND_UP? It should produce smaller code than
what you've done here...
It pulls in aeabi_*div* functions, which won't fit into block 0 of
Onenand.
It shouldn't do that if the divisor is a constant power of 2. The
compiler will turn it into a shift, just like with the other divides in
the above code fragment.
You can't use DIV_ROUND_UP directly on data.pagesize, but you can use it
in each branch of the if statement instead of that awkward and slightly
more expensive !!(len 4095) construct.
Expensive in what way?
Compare the resulting asm code. You're replacing this:
a = (b + 4095) 12;
with this:
a = b 12;
if (b 4095)
a++;
Either way, I don't think this matters that much.
This is code that has to fit in 1K -- why waste instructions by writing
code in a way that is *less* readable?
The size is the same (tested). I'll submit a patch with DIV_ROUND_UP, whatever.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
Subject: Re: [U-Boot] Please pull u-boot-ti/master s-paul...@ti.com wrote: Albert, Please pull u-boot-ti/master Regards, Sandeep The following changes since commit ce5207e191c59b3135303fd03b98dd2ac3701ba2: Kyle Moffett (1): e1000: Allow direct access to the E1000 SPI EEPROM device are available in the git repository at: git://git.denx.de/u-boot-ti.git master Hi Sandeep, yesterday I sent two patches to make the dig297 board compile again after the mach-types sync. Did you receive them? http://lists.denx.de/pipermail/u-boot/2011-November/108000.html http://lists.denx.de/pipermail/u-boot/2011-November/108001.html Hi Luca, Pushed to u-boot-ti master Hi Albert, Can you please pick up these 2 as well from my master. Regards, Sandeep ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 v6] powerpc/mpc83xx: Add 33.33MHz support for mpc8360emds
Dear chang-ming.hu...@freescale.com, In message 1320302773-6704-2-git-send-email-chang-ming.hu...@freescale.com you wrote: From: Jerry Huang chang-ming.hu...@freescale.com The new MPC8360EMDS board changes the oscillator to 33.33MHz in order to support QE 500MHz since 2008. ... MPC8360EMDS_HOST_33 powerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:PCI,PCI_33M,PQ_MDS_PIB=1 MPC8360EMDS_HOST_66 powerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:PCI,PCI_66M,PQ_MDS_PIB=1 MPC8360EMDS_SLAVEpowerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:PCI,PCISLAVE +MPC8360EMDS_CLKIN33 powerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:CLKIN_33MHZ +MPC8360EMDS_CLKIN33_ATM powerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:CLKIN_33MHZ,PQ_MDS_PIB=1,PQ_MDS_PIB_ATM=1 +MPC8360EMDS_CLKIN33_HOST_33 powerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:CLKIN_33MHZ,PCI,PCI_33M,PQ_MDS_PIB=1 +MPC8360EMDS_CLKIN33_HOST_66 powerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:CLKIN_33MHZ,PCI,PCI_66M,PQ_MDS_PIB=1 +MPC8360EMDS_CLKIN33_SLAVEpowerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:CLKIN_33MHZ,PCI,PCISLAVE Can you please chose somewhat shorter config names? I consider it a personal offense when you coerce me into typing config names like MPC8360EMDS_CLKIN33_HOST_33. Please chose shorter names. For a start, consider what represents the defualt configuration, and omit all options for this, i. e. allow for a plain MPC8360EMDS to represent the default configuration. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Wish not to seem, but to be, the best. - Aeschylus ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [[PATCH V2]] sandbox: Add improved RAM simulation
Am 02.11.2011 21:56, schrieb Simon Glass:
On Wed, Nov 2, 2011 at 1:12 PM, Matthias Weisser weiss...@arcor.de wrote:
Using mmap to allocate memory from the OS for RAM simulation we can use
u-boots own malloc implementation.
Signed-off-by: Matthias Weisser weiss...@arcor.de
---
Changes in V2:
Removed the address hint for mmap
Removed the special handling of dlmalloc in common
Set gd-bd-bi_dram[0].start to 0 again
arch/sandbox/cpu/os.c|7 +++
arch/sandbox/lib/board.c | 17 ++---
common/Makefile |2 --
include/os.h |8
4 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
index 6c175d4..05f91f2 100644
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
@@ -24,6 +24,7 @@
#include unistd.h
#include sys/types.h
#include sys/stat.h
+#include sys/mman.h
#include os.h
@@ -53,3 +54,9 @@ void os_exit(int exit_code)
{
exit(exit_code);
}
+
+void *os_malloc(size_t length)
+{
+ return mmap(NULL, length, PROT_READ | PROT_WRITE,
+ MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+}
diff --git a/arch/sandbox/lib/board.c b/arch/sandbox/lib/board.c
index ae5a517..d71cd6f 100644
--- a/arch/sandbox/lib/board.c
+++ b/arch/sandbox/lib/board.c
@@ -45,8 +45,12 @@
#include version.h
#include serial.h
+#include os.h
+
DECLARE_GLOBAL_DATA_PTR;
+static gd_t gd_mem;
+
/
* Init Utilities *
@@ -147,7 +151,7 @@ void board_init_f(ulong bootflag)
uchar *mem;
unsigned long addr_sp, addr, size;
- gd = malloc(sizeof(gd_t));
+ gd = gd_mem;
assert(gd);
memset((void *)gd, 0, sizeof(gd_t));
@@ -158,7 +162,8 @@ void board_init_f(ulong bootflag)
}
size = CONFIG_SYS_SDRAM_SIZE;
- mem = malloc(size);
+ mem = os_malloc(CONFIG_SYS_SDRAM_SIZE);
+
Just a suggestion if you like: perhaps also assert that
CONFIG_SYS_SDRAM_SIZE is greater than TOTAL_MALLOC_LEN. Or assert
lower down at the end of board_init_f() that addr_sp is still greatrer
than mem?
I will leave out this point for a separate patch.
assert(mem);
gd-ram_buf = mem;
addr = (ulong)(mem + size);
@@ -214,11 +219,9 @@ void board_init_r(gd_t *id, ulong dest_addr)
post_output_backlog();
#endif
-#if 0 /* Sandbox uses system malloc for now */
- /* The Malloc area is immediately below the monitor copy in DRAM */
- malloc_start = dest_addr - TOTAL_MALLOC_LEN;
- mem_malloc_init(malloc_start, TOTAL_MALLOC_LEN);
-#endif
+ /* The Malloc area is at the top of simulated DRAM */
+ mem_malloc_init(gd-ram_buf + gd-ram_size - TOTAL_MALLOC_LEN,
+ TOTAL_MALLOC_LEN);
I get:
board.c:224:4: warning: passing argument 1 of ‘mem_malloc_init’ makes
integer from pointer without a cast [enabled by default]
Fixed. Will send an updated version.
/* initialize environment */
env_relocate();
diff --git a/common/Makefile b/common/Makefile
index 1b672ad..919be42 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -29,9 +29,7 @@ LIB = $(obj)libcommon.o
ifndef CONFIG_SPL_BUILD
COBJS-y += main.o
COBJS-y += command.o
-ifndef CONFIG_SANDBOX
COBJS-y += dlmalloc.o
-endif
I think this can be removed. It was added unconditionally lower down
in the Makefile by this commit:
2d01dd9 omap: spl: fix build break due to changes in FAT
(incidentally this is what has broken sandbox).
Will do.
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] net: introduce per device index
Dear Prafulla Wadaskar, In message f766e4f80769bd478052fb6533fa745d1a14dd9...@sc-vexch4.marvell.com you wrote: These patches are for u-boot-net.git. Copying Ben on this. Ben has resigned long ago. We're currently without Net custodian (any volunteers out there??) so I will have to pick that up - when time comes. The patch was submitted after close of trhe merge window, so it is low priority for now. 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 Minds are like parachutes - they only function when open. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] nds32: toolchains for building ?
where can we actually get a toolchain to build nds32 ? support doesn't appear to be in the mainline FSF projects ... -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] [PATCH V3] sandbox: Add improved RAM simulation
Using mmap to allocate memory from the OS for RAM simulation we can use
u-boot own malloc implementation.
Signed-off-by: Matthias Weisser weiss...@arcor.de
---
Changes in V3:
Fixed a build warning
Changes in V2:
Removed the address hint for mmap
Removed the special handling of dlmalloc in common
Set gd-bd-bi_dram[0].start to 0 again
This patch also fixes the runtime error of sandbox introduced in
2d01dd9 omap: spl: fix build break due to changes in FAT
arch/sandbox/cpu/os.c|7 +++
arch/sandbox/lib/board.c | 17 ++---
common/Makefile |3 ---
include/os.h |8
4 files changed, 25 insertions(+), 10 deletions(-)
diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
index 6c175d4..05f91f2 100644
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
@@ -24,6 +24,7 @@
#include unistd.h
#include sys/types.h
#include sys/stat.h
+#include sys/mman.h
#include os.h
@@ -53,3 +54,9 @@ void os_exit(int exit_code)
{
exit(exit_code);
}
+
+void *os_malloc(size_t length)
+{
+ return mmap(NULL, length, PROT_READ | PROT_WRITE,
+ MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+}
diff --git a/arch/sandbox/lib/board.c b/arch/sandbox/lib/board.c
index ae5a517..b7997e9 100644
--- a/arch/sandbox/lib/board.c
+++ b/arch/sandbox/lib/board.c
@@ -45,8 +45,12 @@
#include version.h
#include serial.h
+#include os.h
+
DECLARE_GLOBAL_DATA_PTR;
+static gd_t gd_mem;
+
/
* Init Utilities *
@@ -147,7 +151,7 @@ void board_init_f(ulong bootflag)
uchar *mem;
unsigned long addr_sp, addr, size;
- gd = malloc(sizeof(gd_t));
+ gd = gd_mem;
assert(gd);
memset((void *)gd, 0, sizeof(gd_t));
@@ -158,7 +162,8 @@ void board_init_f(ulong bootflag)
}
size = CONFIG_SYS_SDRAM_SIZE;
- mem = malloc(size);
+ mem = os_malloc(CONFIG_SYS_SDRAM_SIZE);
+
assert(mem);
gd-ram_buf = mem;
addr = (ulong)(mem + size);
@@ -214,11 +219,9 @@ void board_init_r(gd_t *id, ulong dest_addr)
post_output_backlog();
#endif
-#if 0 /* Sandbox uses system malloc for now */
- /* The Malloc area is immediately below the monitor copy in DRAM */
- malloc_start = dest_addr - TOTAL_MALLOC_LEN;
- mem_malloc_init(malloc_start, TOTAL_MALLOC_LEN);
-#endif
+ /* The Malloc area is at the top of simulated DRAM */
+ mem_malloc_init((ulong)gd-ram_buf + gd-ram_size - TOTAL_MALLOC_LEN,
+ TOTAL_MALLOC_LEN);
/* initialize environment */
env_relocate();
diff --git a/common/Makefile b/common/Makefile
index 1b672ad..015c17e 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -29,9 +29,6 @@ LIB = $(obj)libcommon.o
ifndef CONFIG_SPL_BUILD
COBJS-y += main.o
COBJS-y += command.o
-ifndef CONFIG_SANDBOX
-COBJS-y += dlmalloc.o
-endif
COBJS-y += exports.o
COBJS-$(CONFIG_SYS_HUSH_PARSER) += hush.o
COBJS-y += image.o
diff --git a/include/os.h b/include/os.h
index 3ea6d2d..2bb2fb7 100644
--- a/include/os.h
+++ b/include/os.h
@@ -71,3 +71,11 @@ int os_close(int fd);
* @param exit_codeexit code for U-Boot
*/
void os_exit(int exit_code);
+
+/**
+ * Acquires some memory from the underlying os.
+ *
+ * \param length Number of bytes to be allocated
+ * \return Pointer to length bytes or NULL on error
+ */
+void *os_malloc(size_t length);
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Business Proposal..
I am Mr. Wen Lee director of operations of the Bank Of Taipei Taiwan. I have an obscured business proposal for you. Reply if interested. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
Dear Sandeep, In message be04c0a3bec7354a8bce3db869f4d4930a0...@dlee08.ent.ti.com you wrote: Pushed to u-boot-ti master Hi Albert, Can you please pick up these 2 as well from my master. Umm, no. Can you please send a formal pull request? Also, what about all the other TI related patches that have been queued for a long time? Is there hope you will find time to resume processing this backlog? 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 Freudian slip is when you say one thing but mean your mother. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3] sandbox: Add improved RAM simulation
Acked-by: Mike Frysinger vap...@gentoo.org -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4 V3] PXA: Adapt Voipac PXA270 to OneNAND SPL
On 11/02/2011 08:56 PM, Marek Vasut wrote: + onenand_spl_load_image(CONFIG_SPL_ONENAND_LOAD_ADDR, + CONFIG_SPL_ONENAND_LOAD_SIZE, + (void *)CONFIG_SYS_TEXT_BASE); If we make it nand_spl_load_image, and make the #defines conform, we can have the same code call the function for nand and onenand. I don't see any reason why onenand is a completely different subsystem in general, rather than just another NAND driver. The NAND subsystem's driver interface is lower level than it should be, but that affects other NAND controllers as well (such as fsl_elbc). Switching to the generic nand_boot() in http://patchwork.ozlabs.org/patch/123219/ would get you the ability to load the environment during the SPL. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] net: introduce per device index
Acked-by: Mike Frysinger vap...@gentoo.org -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mvgbe: fix network device indices
On Thursday 27 October 2011 17:31:36 Michael Walle wrote:
--- a/drivers/net/mvgbe.c
+++ b/drivers/net/mvgbe.c
+ /* Extract the MAC address from the environment */
+ while (!eth_getenv_enetaddr_by_index(eth, dev-index,
+ dev-enetaddr)) {
/* Generate Private MAC addr if not set */
dev-enetaddr[0] = 0x02;
dev-enetaddr[1] = 0x50;
this is wrong. net drivers should not be touching the env at all. please fix
your driver to not do that first.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dfu: initial implementation
Dear Andrzej Pietrasiewicz, In message 1320228007-8947-1-git-send-email-andrze...@samsung.com you wrote: Device Firmware Upgrade (DFU) is an extension to the USB specification. As of the time of this writing it is documented at http://www.usb.org/developers/devclass_docs/DFU_1.1.pdf ... Please refer to dfu-util documentation for details. The below ASCII-art presents a connection between the host and the device. +-+--- DFU ---+-+ | e.g. dfu-util |=== USB ===| / altsetting 0 | | host +-+ device - altsetting 1 | | file /| | \ ... | +-+ +-+ Sorry for asking some probably really dumb questions... If I understand correctly, there is no fundamental reason why the DFU protocol would only be possible to implement over a USB link. Or am I missing something here? Eventually it should be possible to run this protocol over Ethernet or even over a serial line? If my assumption is correct, then what would it take to split off protocol part and make it independent of the actual driver interface? 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 Today is the yesterday you worried about tomorrow. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request for u-boot-marvell.git
Hi Prafulla, Le 01/11/2011 09:35, Prafulla Wadaskar a écrit : Hi Albert Please pull The following changes since commit d0a755e860362ca35c6d6e4fa8a7a0d5fc7e3ea6: Michael Walle (1): kirkwood: define CONFIG_SYS_CACHELINE_SIZE are available in the git repository at: u-boot-marvell.git master branch. Holger Brunck (4): arm/km: add boardid and hwkey to kernel command line arm/km: trigger reconfiguration for the Xilinx FPGA arm/km: enable jffs2 cmds arm/km: adapt bootcounter evaluation Lei Wen (2): pantheon: define CONFIG_SYS_CACHELINE_SIZE armada100: define CONFIG_SYS_CACHELINE_SIZE Simon Guinot (2): netspace_v2: fix SDRAM configuration netspace_v2: enable I2C EEPROM support Thomas Herzmann (1): arm/km: portl2 environment address update to P1B Valentin Longchamp (1): ARM: Reintroduce MACH_TYPE_KM_KIRKWOOD for keymile ARM boards arch/arm/include/asm/arch-armada100/config.h |2 + arch/arm/include/asm/arch-pantheon/config.h |2 + board/LaCie/netspace_v2/kwbimage-is2.cfg | 162 ++ board/LaCie/netspace_v2/kwbimage.cfg |4 +- board/keymile/km_arm/km_arm.c| 44 +-- boards.cfg |2 +- include/configs/km/km_arm.h |9 +- include/configs/km_kirkwood.h|3 + include/configs/netspace_v2.h| 18 +++- include/configs/portl2.h |6 +- 10 files changed, 234 insertions(+), 18 deletions(-) create mode 100644 board/LaCie/netspace_v2/kwbimage-is2.cfg Applied to u-boot-arm/master, thanks. Note that I get the following errors when fetching u-boot-marvell: remote: error: refs/remotes/origin/mkimage does not point to a valid object! remote: error: refs/tags/2009.01-rc2 does not point to a valid object! The second one means you have a bigus tag, which should disappear with a git push ssh://gu-marv...@git.denx.de/u-boot-marvell.git :2009.01-rc2 The first one seems more complex, as it is a bogus branch name in a *remote* of u-boot-marvell -- I guess this can only be handled directly by Wolfgang. Regards.. Prafulla . . . Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
Hi Sandeep, Le 03/11/2011 18:52, Paulraj, Sandeep a écrit : Subject: Re: [U-Boot] Please pull u-boot-ti/master s-paul...@ti.com wrote: Albert, Please pull u-boot-ti/master Regards, Sandeep The following changes since commit ce5207e191c59b3135303fd03b98dd2ac3701ba2: Kyle Moffett (1): e1000: Allow direct access to the E1000 SPI EEPROM device are available in the git repository at: git://git.denx.de/u-boot-ti.git master Hi Sandeep, yesterday I sent two patches to make the dig297 board compile again after the mach-types sync. Did you receive them? http://lists.denx.de/pipermail/u-boot/2011-November/108000.html http://lists.denx.de/pipermail/u-boot/2011-November/108001.html Hi Luca, Pushed to u-boot-ti master Hi Albert, Can you please pick up these 2 as well from my master. Branch u-boot-ti/master is based on u-boot/master whereas it should be based on u-boot-arm/master. Please rebase and as Wolfgang asks, submit a formal pull req based on u-boot-arm/master. Currently, that would be commit 6d66073614539d94dabff1f63ebd962840c44b81 (arm/km: portl2 environment address update to P1B). Regards, Sandeep Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
On Thu, Nov 3, 2011 at 11:17 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Sandeep, Le 03/11/2011 18:52, Paulraj, Sandeep a écrit : Subject: Re: [U-Boot] Please pull u-boot-ti/master s-paul...@ti.com wrote: Albert, Please pull u-boot-ti/master Regards, Sandeep The following changes since commit ce5207e191c59b3135303fd03b98dd2ac3701ba2: Kyle Moffett (1): e1000: Allow direct access to the E1000 SPI EEPROM device are available in the git repository at: git://git.denx.de/u-boot-ti.git master Hi Sandeep, yesterday I sent two patches to make the dig297 board compile again after the mach-types sync. Did you receive them? http://lists.denx.de/pipermail/u-boot/2011-November/108000.html http://lists.denx.de/pipermail/u-boot/2011-November/108001.html Hi Luca, Pushed to u-boot-ti master Hi Albert, Can you please pick up these 2 as well from my master. Branch u-boot-ti/master is based on u-boot/master whereas it should be based on u-boot-arm/master. Please rebase and as Wolfgang asks, submit a formal pull req based on u-boot-arm/master. Currently, that would be commit 6d66073614539d94dabff1f63ebd962840c44b81 (arm/km: portl2 environment address update to P1B). Sorry, my fault there. It looks like it'll be a real easy rebase at least. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
On Thu, Nov 3, 2011 at 10:24 AM, Luca Ceresoli luca.ceres...@comelit.it wrote: s-paul...@ti.com wrote: Albert, Please pull u-boot-ti/master Regards, Sandeep The following changes since commit ce5207e191c59b3135303fd03b98dd2ac3701ba2: Kyle Moffett (1): e1000: Allow direct access to the E1000 SPI EEPROM device are available in the git repository at: git://git.denx.de/u-boot-ti.git master Hi Sandeep, yesterday I sent two patches to make the dig297 board compile again after the mach-types sync. Did you receive them? http://lists.denx.de/pipermail/u-boot/2011-November/108000.html http://lists.denx.de/pipermail/u-boot/2011-November/108001.html Sorry, for some reason I had thought Albert was collecting all of the MACH_TYPE fixups that had gone past. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-nds32
Dear =?UTF-8?B?6aas5YWL5rOh?=, In message CACCg+XPfsaHVvUSoS18ey=2eutsztzur1put+w6qt3ndanz...@mail.gmail.com you wrote: The following changes since commit ce5207e191c59b3135303fd03b98dd2ac3701ba2: e1000: Allow direct access to the E1000 SPI EEPROM device (2011-10-28 00:37:01 +0200) are available in the git repository at: git://git.denx.de/u-boot-nds32.git master Macpaul Lin (3): nds32: Use getenv_ulong() in place of getenv(), strtoul nds32: cache: define ARCH_DMA_MINALIGN for DMA buffer alignment nds32: asm/io.h: add __iormb __iowmb and inline io support arch/nds32/include/asm/cache.h | 11 ++ arch/nds32/include/asm/io.h| 72 +--- arch/nds32/lib/board.c | 12 +- 3 files changed, 65 insertions(+), 30 deletions(-) Applied, thanks. Can you please deleted tag 'NIOS2-5_0_0' from your tree? 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 Do we define evil as the absence of goodness? It seems only logical that shit happens--we discover this by the process of elimination. -- Larry Wall ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request for u-boot-x86
Dear Graeme Russ,
In message 4eb122b8.6000...@gmail.com you wrote:
Hi Wolfgang,
Please note that I had to do a force push into u-boot-x86 to delete a
commit that I munged the importing of (Ondrej's patch) and didn't realise
until I have pushed it (the patch title was all wrong)
I don't think this should cause any trouble to you though as everything in
u-boot-x86 on the denx server looks up to date (i.e. no dropped commits)
The following changes since commit ce5207e191c59b3135303fd03b98dd2ac3701ba2:
e1000: Allow direct access to the E1000 SPI EEPROM device (2011-10-28
00:37:01 +0200)
are available in the git repository at:
git://git.denx.de/u-boot-x86.git master
Gabe Black (2):
x86: Remove the prototype for the unused function board_init
x86: Fix a compiler warning in arch/x86/lib/realmode.c
Graeme Russ (1):
x86: Rename include/asm/ic to include/asm/arch-sc520
Ondrej Kupka (1):
x86: turn off cache: set control register properly
arch/x86/cpu/sc520/sc520.c |2 +-
arch/x86/cpu/sc520/sc520_car.S |2 +-
arch/x86/cpu/sc520/sc520_pci.c |4 ++--
arch/x86/cpu/sc520/sc520_reset.c|2 +-
arch/x86/cpu/sc520/sc520_sdram.c|2 +-
arch/x86/cpu/sc520/sc520_ssi.c |4 ++--
arch/x86/cpu/sc520/sc520_timer.c|2 +-
arch/x86/cpu/start16.S |2 +-
arch/x86/include/asm/{ic = arch-sc520}/pci.h |0
arch/x86/include/asm/{ic = arch-sc520}/sc520.h |0
arch/x86/include/asm/{ic = arch-sc520}/ssi.h |0
arch/x86/include/asm/u-boot-x86.h |1 -
arch/x86/lib/realmode.c |2 +-
arch/x86/lib/zimage.c |1 -
board/eNET/eNET.c |2 +-
board/eNET/eNET_pci.c |2 +-
board/eNET/eNET_start16.S |4 +---
17 files changed, 14 insertions(+), 18 deletions(-)
rename arch/x86/include/asm/{ic = arch-sc520}/pci.h (100%)
rename arch/x86/include/asm/{ic = arch-sc520}/sc520.h (100%)
rename arch/x86/include/asm/{ic = arch-sc520}/ssi.h (100%)
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
Uncertain fortune is thoroughly mastered by the equity of the calcu-
lation. - Blaise Pascal
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mmc.git
Dear Andy Fleming, In message 1320305078-24629-1-git-send-email-aflem...@freescale.com you wrote: The following changes since commit ce5207e191c59b3135303fd03b98dd2ac3701ba2: e1000: Allow direct access to the E1000 SPI EEPROM device (2011-10-28 00:37:01 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-mmc.git master Ajay Bhargav (1): mmc: CMD7:MMC_CMD_SELECT_CARD response fix Lei Wen (9): mmc: retry the cmd8 to meet 74 clocks requirement in the spec mmc: mv_sdhci: fix 8bus width access for 88SV331xV5 mmc: change magic number to macro define mmc: test mmc bus width on startup mmc: sdhci: fix cache flush mmc: sdhci: fix build warning mmc: sdhci: add mmc structure for host mmc: sdhci: add timeout for data transfer mmc: sdhci: fix sdma bug for large file transfer Marek Vasut (1): PXA: Add MMC driver using the generic MMC framework Stephen Warren (1): tegra2: Move MMC clock initialization into MMC driver arch/arm/include/asm/arch-pxa/regs-mmc.h | 154 +++ board/nvidia/common/board.c | 13 +- drivers/mmc/Makefile |1 + drivers/mmc/mmc.c| 83 -- drivers/mmc/mv_sdhci.c | 33 +++ drivers/mmc/pxa_mmc_gen.c| 442 ++ drivers/mmc/sdhci.c | 14 +- drivers/mmc/tegra2_mmc.c | 12 +- include/mmc.h| 16 +- include/sdhci.h |6 + 10 files changed, 719 insertions(+), 55 deletions(-) create mode 100644 arch/arm/include/asm/arch-pxa/regs-mmc.h create mode 100644 drivers/mmc/pxa_mmc_gen.c 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 Eeeek! 'eval' on strings should have been named 'evil'.-- Tom Phoenix in pine.gso.3.96.980526121813.27437n-100...@user2.teleport.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request for u-boot-marvell.git
Dear Albert ARIBAUD, In message 4eb2da35.6090...@aribaud.net you wrote: Note that I get the following errors when fetching u-boot-marvell: remote: error: refs/remotes/origin/mkimage does not point to a valid object! remote: error: refs/tags/2009.01-rc2 does not point to a valid object! The second one means you have a bigus tag, which should disappear with a git push ssh://gu-marv...@git.denx.de/u-boot-marvell.git :2009.01-rc2 The first one seems more complex, as it is a bogus branch name in a *remote* of u-boot-marvell -- I guess this can only be handled directly by Wolfgang. I fixed both these. 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 Where humor is concerned there are no standards -- no one can say what is good or bad, although you can be sure that everyone will. - John Kenneth Galbraith ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arch/powerpc/lib/board.c: fix build warning
Dear Wolfgang Denk, In message 1319407132-6590-1-git-send-email...@denx.de you wrote: Commit 1272592 powerpc: Use getenv_ulong() in place of getenv(), strtoul instroduced a build warning for some PPC systems: board.c: In function 'board_init_r': board.c:626: warning: unused variable 's' Fix it. Signed-off-by: Wolfgang Denk w...@denx.de --- arch/powerpc/lib/board.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Overflow on /dev/null, please empty the bit bucket. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/net/ns8382x.c: fix GCC 4.6 build warnings
Dear Wolfgang Denk, In message 1319917054-14002-1-git-send-email...@denx.de you wrote: Fix: ns8382x.c: In function 'ns8382x_check_duplex': ns8382x.c:704:6: warning: variable 'hun' set but not used [-Wunused-but-set-variable] To fix this, we get rid of the NS8382X_DEBUG code and use standard debug() instead. This will now trigger a so far undetected warning: ns8382x.c:780:2: warning: format '%X' expects argument of type 'unsigned int', but argument 2 has type 'long unsigned int' [-Wformat] Fix that, too. Signed-off-by: Wolfgang Denk w...@denx.de --- drivers/net/ns8382x.c | 85 +--- 1 files changed, 37 insertions(+), 48 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I have often regretted my speech, never my silence. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board/jse/flash.c: fix GCC 4.6 build warnings
Dear Wolfgang Denk, In message 1319917060-14045-1-git-send-email...@denx.de you wrote: Fix: flash.c: In function 'flash_erase': flash.c:304:24: warning: variable 'l_sect' set but not used [-Wunused-but-set-variable] In addition, remove some dead code. Signed-off-by: Wolfgang Denk w...@denx.de --- board/jse/flash.c | 15 +-- 1 files changed, 1 insertions(+), 14 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Any time things appear to be going better, you have overlooked some- thing. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board/g2000/strataflash.c: fix GCC 4.6 build warnings
Dear Wolfgang Denk, In message 1319917064-14085-1-git-send-email...@denx.de you wrote: Fix: strataflash.c: In function 'flash_write_cfiword': strataflash.c:669:11: warning: variable 'ctladdr' set but not used [-Wunused-but-set-variable] Signed-off-by: Wolfgang Denk w...@denx.de --- board/g2000/strataflash.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Looks clean and obviously correct to me, but then _everything_ I write always looks obviously correct to me. - Linus Torvalds in pine.lnx.4.10.10012090054360.791-100...@penguin.transmeta.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/net/eepro100.c: fix GCC 4.6 build warnings
Dear Wolfgang Denk, In message 1319917068-14124-1-git-send-email...@denx.de you wrote: Fix: eepro100.c: In function 'read_hw_addr': eepro100.c:926:6: warning: variable 'eeprom' set but not used [-Wunused-but-set-variable] Signed-off-by: Wolfgang Denk w...@denx.de --- drivers/net/eepro100.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Eureka! -- Archimedes ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 4xx_uart.c: fix GCC 4.6 build warnings
Dear Wolfgang Denk, In message 1319917072-14163-1-git-send-email...@denx.de you wrote: Fix: 4xx_uart.c: In function 'get_serial_clock': 4xx_uart.c:204:6: warning: variable 'tmp' set but not used [-Wunused-but-set-variable] Signed-off-by: Wolfgang Denk w...@denx.de Cc: Stefan Roese s...@denx.de --- arch/powerpc/cpu/ppc4xx/4xx_uart.c | 26 ++ 1 files changed, 14 insertions(+), 12 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I can call spirits from the vasty deep. Why so can I, or so can any man; but will they come when you do call for them? - Shakespeare, 1 King Henry IV, Act III, Scene I. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 4xx_enet.c: fix GCC 4.6 build warnings
Dear Wolfgang Denk, In message 1319917076-14202-1-git-send-email...@denx.de you wrote: Fix: 4xx_enet.c: In function 'enet_rcv': 4xx_enet.c:1772:21: warning: variable 'ef_ptr' set but not used [-Wunused-but-set-variable] Signed-off-by: Wolfgang Denk w...@denx.de Cc: Stefan Roese s...@denx.de --- drivers/net/4xx_enet.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The only way you could make a happy marriage is by cuttin' their heads off as soon as they say `I do', yes? You can't make happi- ness... - Terry Pratchett, _Witches Abroad_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board/prodrive/p3mx/mv_eth.c: fix GCC 4.6 build warnings
Dear Wolfgang Denk, In message 1319917101-14282-1-git-send-email...@denx.de you wrote: Fix: mv_eth.c: In function 'mv64460_eth_real_open': mv_eth.c:471:6: warning: variable 'port_status' set but not used [-Wunused-but-set-variable] mv_eth.c: In function 'mv64460_eth_stop': mv_eth.c:722:15: warning: variable 'port_num' set but not used [-Wunused-but-set-variable] mv_eth.c: In function 'mv64460_eth_xmit': mv_eth.c:796:15: warning: variable 'port_num' set but not used [-Wunused-but-set-variable] mv_eth.c: In function 'mv64460_eth_receive': mv_eth.c:877:15: warning: variable 'port_num' set but not used [-Wunused-but-set-variable] mv_eth.c: In function 'mv64460_eth_get_stats': mv_eth.c:979:15: warning: variable 'port_num' set but not used [-Wunused-but-set-variable] mv_eth.c: In function 'mv64460_eth_update_stat': mv_eth.c:1006:24: warning: variable 'dummy' set but not used [-Wunused-but-set-variable] mv_eth.c:1005:15: warning: variable 'port_num' set but not used [-Wunused-but-set-variable] mv_eth.c: In function 'mv64460_eth_print_stat': mv_eth.c:1087:15: warning: variable 'port_num' set but not used [-Wunused-but-set-variable] mv_eth.c: In function 'eth_clear_mib_counters': mv_eth.c:2141:15: warning: variable 'dummy' set but not used [-Wunused-but-set-variable] Signed-off-by: Wolfgang Denk w...@denx.de --- board/prodrive/p3mx/mv_eth.c | 33 ++--- 1 files changed, 6 insertions(+), 27 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A well-written program is its own heaven; a poorly-written program is its own hell. -- Geoffrey James, The Tao of Programming ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 4xx_pci.c: add error checking, fix GCC 4.6 build warning
Dear Wolfgang Denk, In message 1319917111-14323-1-git-send-email...@denx.de you wrote: Fix: 4xx_pci.c: In function 'pci_init_board': 4xx_pci.c:855:6: warning: variable 'busno' set but not used [-Wunused-but-set-variable] Signed-off-by: Wolfgang Denk w...@denx.de Cc: Stefan Roese s...@denx.de --- arch/powerpc/cpu/ppc4xx/4xx_pci.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The computer can't tell you the emotional story. It can give you the exact mathematical design, but what's missing is the eyebrows. - Frank Zappa ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/rtc/ds1337.c: fix GCC 4.6 build warnings
Dear Wolfgang Denk, In message 1319917151-14369-1-git-send-email...@denx.de you wrote: Fix: ds1337.c: In function 'rtc_get': ds1337.c:88:52: warning: variable 'control' set but not used [-Wunused-but-set-variable] Signed-off-by: Wolfgang Denk w...@denx.de --- drivers/rtc/ds1337.c | 16 +++- 1 files changed, 3 insertions(+), 13 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de In an organization, each person rises to the level of his own incom- petency - The Peter Principle ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] common/cmd_ide.c: CodingStyle cleanup
Dear Wolfgang Denk, In message 1319917301-14545-1-git-send-email...@denx.de you wrote: Make file acceptable to checkpatch. This is only a basic clean up to the extend possible without any real changes to the source code. Warnings due to line over 80 characters were accepted because these affect only printf()s with user visible strings. No attempts were made to fix warnings about volatile and externs - these need a more thorough cleanup. Signed-off-by: Wolfgang Denk w...@denx.de --- common/cmd_ide.c | 1714 -- 1 files changed, 874 insertions(+), 840 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de All he had was nothing, but that was something, and now it had been taken away. - Terry Pratchett, _Sourcery_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] common/cmd_ide.c: fix GCC 4.6 build warnings
Dear Wolfgang Denk, In message 1319917301-14545-2-git-send-email...@denx.de you wrote: Fix: cmd_ide.c: In function 'ide_ident': cmd_ide.c:988:6: warning: variable 'do_retry' set but not used [-Wunused-but-set-variable] Delete the unused variable. Signed-off-by: Wolfgang Denk w...@denx.de --- common/cmd_ide.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Life is a game. Money is how we keep score. - Ted Turner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] post/post.c: CodingStyle cleanup
Dear Wolfgang Denk, In message 1319917343-14604-1-git-send-email...@denx.de you wrote: Make checkpatch-clean.. Signed-off-by: Wolfgang Denk w...@denx.de --- post/post.c | 59 +++ 1 files changed, 27 insertions(+), 32 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Women professionals do tend to over-compensate. -- Dr. Elizabeth Dehaver, Where No Man Has Gone Before, stardate 1312.9. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] post/post.c: fix GCC 4.6 build warnings
Dear Wolfgang Denk, In message 1319917343-14604-2-git-send-email...@denx.de you wrote: Fix: post.c: In function 'post_log': post.c:425:7: warning: variable 'i' set but not used [-Wunused-but-set-variable] Signed-off-by: Wolfgang Denk w...@denx.de --- post/post.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Perl already has an IDE. It's called Unix. -- Tom Christiansen in 375bd...@cs.colorado.edu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] config.mk: use memoization in cc-option macro to speed up compilation
Dear Daniel Schwierzeck, In message 4eb1b7dd.40...@googlemail.com you wrote: The patch is still experimental. But I will move that file to include/generated in the final version. Indeed, please do. To see the difference between compilation times with and without this optimization and to do not break existing code. In the final version I would remove the config switch and enable the optimization by default ;) Looking forward to seeing this final version soon :-) Thanks!! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There are two kinds of people, those who do the work and those who take the credit. Try to be in the first group; there is less competition there.- Indira Gandhi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Reduce build times
Dear Daniel Schwierzeck, In message cacuy__w_z85alinuqxmxe3trrhm4aueqobxbqs6dfsrfeph...@mail.gmail.com you wrote: Conclusion: - complete build time reduced from 1m11s to 20s - incremental rebuild time reduced from 20s to 3s - cc-option calls reduced from 3024 to 8 - execve calls reduced from 16502 to 3329 That's really cool. Can we please add another two or three of such optimizations? :-) 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 CONSUMER NOTICE: Because of the Uncertainty Principle, It Is Impossible for the Consumer to Find Out at the Same Time Both Precisely Where This Product Is and How Fast It Is Moving. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
On Thu, Nov 3, 2011 at 10:24 AM, Luca Ceresoli luca.ceres...@comelit.it wrote: s-paul...@ti.com wrote: Albert, Please pull u-boot-ti/master Regards, Sandeep The following changes since commit ce5207e191c59b3135303fd03b98dd2ac3701ba2: Kyle Moffett (1): e1000: Allow direct access to the E1000 SPI EEPROM device are available in the git repository at: git://git.denx.de/u-boot-ti.git master Hi Sandeep, yesterday I sent two patches to make the dig297 board compile again after the mach-types sync. Did you receive them? http://lists.denx.de/pipermail/u-boot/2011-November/108000.html http://lists.denx.de/pipermail/u-boot/2011-November/108001.html Can you condense these into a single patch please? Thanks. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-ti/master
The following changes since commit 6d66073614539d94dabff1f63ebd962840c44b81: Thomas Herzmann (1): arm/km: portl2 environment address update to P1B are available in the git repository at: git://git.denx.de/u-boot-ti.git master Bastian Ruppert (4): Davinci: ea20: set console on UART0 Davinci: ea20: set GPIOs to hold MII-Phy in reset and set UART0-Switch for console Davinci: ea20: add gpio for keeping power on in board_late_init Davinci: ea20: add gpios for LCD backlight control Christian Riesch (1): arm, davinci: Add function lpsc_syncreset() Heiko Schocher (13): arm, davinci: replace CONFIG_PRELOADER with CONFIG_SPL_BUILD arm, arm926: fix missing symbols in NAND_SPL mode usb, davinci: add enable_vbus() weak function arm, usb, davinci: make USBPHY_CTL register configurable net, davinci_emac: make clock divider in MDIO control register configurable spl: add option for adding post memory test to the SPL framework arm, davinci: add support for new spl framework spl, nand: add 4bit HW ecc oob first nand_read_page function arm, davinci: add header files for dm365 arm, davinci: add lowlevel function for dm365 soc arm926ejs, davinci: add cpuinfo for dm365 arm926ejs, davinci: add missing spi defines for dm365 arm, davinci: add cam_enc_4xx support Ilya Yanok (2): davinci_emac: compilation fix, phy is array now omap/spl: actually enable the console Sanjeev Premi (7): omap3evm: Set environment variable 'ethaddr' omap3evm: Reorder related config options omap3evm: Prepare to split configuration omap3evm: move common config options to new file omap3evm: Add (quick) configuration for MMC/SD only omap3evm: Add (quick) configuration for NAND only omap3evm: fix errors caused by multiple definitions Stefano Babic (8): Davinci: ea20: Add NAND support Davinci: ea20: Add early init to get early output from console Davinci: ea20: Add default U-Boot environment ARM: Davinci: added missing registers to hardware.h VIDEO: davinci: add framebuffer to da8xx Davinci: ea20: added video support Davinci: ea20: added I2C support Davinci: ea20: added PREBOOT to configuration MAINTAINERS|1 + Makefile |8 +- README |5 + arch/arm/cpu/arm926ejs/davinci/Makefile|5 + arch/arm/cpu/arm926ejs/davinci/cpu.c | 27 +- arch/arm/cpu/arm926ejs/davinci/dm365_lowlevel.c| 439 ++ arch/arm/cpu/arm926ejs/davinci/psc.c | 20 +- arch/arm/cpu/arm926ejs/davinci/spl.c | 63 ++ arch/arm/cpu/arm926ejs/start.S | 31 +- arch/arm/cpu/armv7/omap-common/spl.c |2 + arch/arm/include/asm/arch-davinci/aintc_defs.h | 50 ++ arch/arm/include/asm/arch-davinci/da8xx-fb.h | 126 +++ arch/arm/include/asm/arch-davinci/dm365_lowlevel.h | 41 + arch/arm/include/asm/arch-davinci/hardware.h | 27 +- arch/arm/include/asm/arch-davinci/pll_defs.h | 84 ++ arch/arm/include/asm/arch-davinci/psc_defs.h | 86 ++ arch/arm/include/asm/arch-davinci/syscfg_defs.h| 66 ++ board/ait/cam_enc_4xx/Makefile | 46 ++ board/ait/cam_enc_4xx/cam_enc_4xx.c| 446 +++ board/ait/cam_enc_4xx/config.mk| 15 + board/ait/cam_enc_4xx/u-boot-spl.lds | 73 ++ board/ait/cam_enc_4xx/ublimage.cfg | 48 ++ board/davinci/common/misc.c|2 +- board/davinci/ea20/ea20.c | 205 - board/ti/evm/evm.c | 15 + boards.cfg |3 + doc/README.SPL |2 + doc/README.davinci.nand_spl| 141 drivers/mtd/nand/Makefile |3 + drivers/mtd/nand/nand_spl_load.c | 56 ++ drivers/mtd/nand/nand_spl_simple.c | 43 +- drivers/net/davinci_emac.c | 11 +- drivers/usb/musb/davinci.c | 20 +- drivers/video/Makefile |1 + drivers/video/da8xx-fb.c | 846 include/configs/cam_enc_4xx.h | 453 +++ include/configs/ea20.h | 126 +++- include/configs/omap3_evm.h| 331 ++--- include/configs/omap3_evm_common.h | 292 +++ include/configs/omap3_evm_quick_mmc.h | 91 +++ include/configs/omap3_evm_quick_nand.h | 79 ++ spl/Makefile |1 + tools/ublimage.h
Re: [U-Boot] Please pull u-boot-ti/master
Branch u-boot-ti/master is based on u-boot/master whereas it should be based on u-boot-arm/master. Please rebase and as Wolfgang asks, submit a formal pull req based on u-boot-arm/master. Currently, that would be commit 6d66073614539d94dabff1f63ebd962840c44b81 (arm/km: portl2 environment address update to P1B). Did just that! Can you please pull Regards, Sandeep ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] powerpc, mpc83xx: mpc83xx.h cleanup and enhancement
On Mon, 26 Sep 2011 13:36:52 +0200 Heiko Schocher h...@denx.de wrote: patches are checkpatch clean, and a MAKEALL -c mpc83xx compiles clean. Heiko Schocher (2): cosmetic, powerpc, mpc83xx: checkpatch cleanup powerpc, mpc83xx: add DDR SDRAM Timing Configuration 3 definitions Cc: Kim Phillips kim.phill...@freescale.com include/mpc83xx.h | 394 +++-- 1 files changed, 262 insertions(+), 132 deletions(-) applied 2 out of 2 patches, thanks. Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/3] ids8313: add support for IDS8313 boards
On Tue, 27 Sep 2011 13:56:32 +0200 sergej.stepa...@ids.de wrote: The patch adds support for IDS8313 boards based on MPC8313 It contains the following components: - both of TSEC's, NOR- and NAND flash, I2C, SPI Signed-off-by: Sergej Stepanov s...@ids.de Signed-off-by: Rolf Riehle r...@ids.de Signed-off-by: Heiko Schocher h...@denx.de Cc: Kim Phillips kim.phill...@freescale.com --- Changes to v2: format issues are fixed split into the patchset Changes to v3: add missing MAINTAINERS entry 3 out of 3 patches squashed and applied. Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mpc83xx: Fix ipic structure definition
On Wed, 5 Oct 2011 18:14:14 -0500
Joe Hershberger joe.hershber...@ni.com wrote:
Signed-off-by: Joe Hershberger joe.hershber...@ni.com
Cc: Joe Hershberger joe.hershber...@gmail.com
Cc: Kim Phillips kim.phill...@freescale.com
---
applied after adding siprr_{b,c} and sepcr for completeness.
Kim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 v6] powerpc/mpc83xx: Add 33.33MHz support for mpc8360emds
On Thu, 3 Nov 2011 18:53:50 +0100 Wolfgang Denk w...@denx.de wrote: Dear chang-ming.hu...@freescale.com, In message 1320302773-6704-2-git-send-email-chang-ming.hu...@freescale.com you wrote: From: Jerry Huang chang-ming.hu...@freescale.com The new MPC8360EMDS board changes the oscillator to 33.33MHz in order to support QE 500MHz since 2008. ... MPC8360EMDS_HOST_33 powerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:PCI,PCI_33M,PQ_MDS_PIB=1 MPC8360EMDS_HOST_66 powerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:PCI,PCI_66M,PQ_MDS_PIB=1 MPC8360EMDS_SLAVEpowerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:PCI,PCISLAVE +MPC8360EMDS_CLKIN33 powerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:CLKIN_33MHZ +MPC8360EMDS_CLKIN33_ATM powerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:CLKIN_33MHZ,PQ_MDS_PIB=1,PQ_MDS_PIB_ATM=1 +MPC8360EMDS_CLKIN33_HOST_33 powerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:CLKIN_33MHZ,PCI,PCI_33M,PQ_MDS_PIB=1 +MPC8360EMDS_CLKIN33_HOST_66 powerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:CLKIN_33MHZ,PCI,PCI_66M,PQ_MDS_PIB=1 +MPC8360EMDS_CLKIN33_SLAVEpowerpc mpc83xx mpc8360emds freescale - MPC8360EMDS:CLKIN_33MHZ,PCI,PCISLAVE Can you please chose somewhat shorter config names? I consider it a personal offense when you coerce me into typing config names like MPC8360EMDS_CLKIN33_HOST_33. Please chose shorter names. For a right, e.g., MPC8360EMDS_33_HOST_33 would match current 8313 nomenclature. start, consider what represents the defualt configuration, and omit all options for this, i. e. allow for a plain MPC8360EMDS to represent the default configuration. actually I'd like the user to check their oscillator and be forced specify the _33 or _66. These changes should also be reflected in the documentation. Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/83xx: move km 83xx specific i2c code to km83xx_i2c
On Wed, 14 Sep 2011 10:54:12 +0200 Holger Brunck holger.bru...@keymile.com wrote: The common code should be valid for more than one architecture. Therefore this code was reorganized and moved to the new file km83xx_i2c.c Signed-off-by: Holger Brunck holger.bru...@keymile.com cc: Kim Phillips kim.phill...@freescale.com --- applied, thanks. Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] mpc83xx: Implement interrupt support for mpc83xx
On Tue, 11 Oct 2011 21:46:05 -0500 Joe Hershberger joe.hershber...@ni.com wrote: Some core ipic code from Linux - commit bbf25010f1a6b761914430f5fca081ec8c7accd1 commit bbf25010f1a6b761914430f5fca081ec8c7accd1 Author: Linus Torvalds torva...@woody.linux-foundation.org Date: Tue Oct 9 13:31:38 2007 -0700 Linux 2.6.23 ...any particular reason to pull in such an old version? diff --git a/arch/powerpc/include/asm/mpc83xx_irq.h b/arch/powerpc/include/asm/mpc83xx_irq.h new file mode 100644 index 000..fc77134 --- /dev/null +++ b/arch/powerpc/include/asm/mpc83xx_irq.h @@ -0,0 +1,72 @@ +#ifndef _MPC83xx_IRQ_H +#define _MPC83xx_IRQ_H + +#define NR_IRQS 128 + +/* + * Some ipic code copied from the linux 2.6 kernel: + * /arch/powerpc/sysdev/ipic.* + * /arch/powerpc/include/asm/ipic.h + */ And why hasn't the Freescale copyright info been retained??? + * This list is specific to the mpc8313e for now. it shouldn't have to be. How is this list used outside of interrupts.c? + */ +#define IPIC_INT_UART1 (0x09) Is it possible to avoid the list altogether somehow? Use an embedded device tree? See doc/README.fdt-control. Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 1/4] gpio: Move common gpio.h to include/asm-generic
On Wed, 12 Oct 2011 15:55:25 + Laurence Withers lwith...@guralp.com wrote: On Tue, Oct 11, 2011 at 10:50:12PM -0500, Joe Hershberger wrote: Common GPIO API used by cmd_gpio should be available to any arch Signed-off-by: Joe Hershberger joe.hershber...@ni.com Cc: Joe Hershberger joe.hershber...@gmail.com Cc: Kim Phillips kim.phill...@freescale.com Tested-by: Laurence Withers lwith...@guralp.com the initial two patches in this patchseries conflict with upstream: commit 9d2cb8e8e6a3650613eab95c1b30023e81beb15c Author: Simon Glass s...@chromium.org Date: Fri Oct 7 13:53:50 2011 + Add generic gpio.h in asm-generic And if I try applying the latter two, I get this: $ ./MAKEALL MPC8313ERDB_33 Configuring for MPC8313ERDB_33 - Board: MPC8313ERDB, Options: SYS_33MHZ mpc83xx_gpio.c:25:22: fatal error: asm/gpio.h: No such file or directory compilation terminated. make[1]: *** No rule to make target `.depend', needed by `libgpio.o'. Stop. make: *** [drivers/gpio/libgpio.o] Error 2 make: *** Waiting for unfinished jobs cmd_gpio.c:12:22: fatal error: asm/gpio.h: No such file or directory compilation terminated. make[1]: *** No rule to make target `.depend', needed by `libcommon.o'. Stop. make[1]: *** Waiting for unfinished jobs make: *** [common/libcommon.o] Error 2 powerpc-linux-gnu-size: './u-boot': No such file please rebase and resubmit. Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
Hi Sandeep, Le 03/11/2011 21:13, Paulraj, Sandeep a écrit : Branch u-boot-ti/master is based on u-boot/master whereas it should be based on u-boot-arm/master. Please rebase and as Wolfgang asks, submit a formal pull req based on u-boot-arm/master. Currently, that would be commit 6d66073614539d94dabff1f63ebd962840c44b81 (arm/km: portl2 environment address update to P1B). Did just that! Can you please pull I will gladly do, as soon as you send out a formal pull request. Regards, Sandeep Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
I will gladly do, as soon as you send out a formal pull request. The mail server seems to be suffering from some delays --Sandeep ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7 v2] integrator: pass configs for core modules
Albert, are the v2 patches OK? In patchworx it's these: http://patchwork.ozlabs.org/patch/121278/ http://patchwork.ozlabs.org/patch/121279/ http://patchwork.ozlabs.org/patch/121280/ http://patchwork.ozlabs.org/patch/121281/ http://patchwork.ozlabs.org/patch/121282/ http://patchwork.ozlabs.org/patch/121283/ http://patchwork.ozlabs.org/patch/121284/ Thanks, Linus Walleij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
Le 03/11/2011 22:11, Paulraj, Sandeep a écrit : I will gladly do, as soon as you send out a formal pull request. The mail server seems to be suffering from some delays Got it, and apologies. --Sandeep Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sandbox: Add asm/cache.h for sandbox
Dear Anton Staaf, In message 1319575683-19180-1-git-send-email-robot...@chromium.org you wrote: This file is required by the new DMA buffer alignment macro. Signed-off-by: Anton Staaf robot...@chromium.org Cc: Simon Glass s...@chromium.org --- arch/sandbox/include/asm/cache.h | 33 + 1 files changed, 33 insertions(+), 0 deletions(-) create mode 100644 arch/sandbox/include/asm/cache.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 Ein weiser Herrscher kann in einem großen Land mehr Gutes bewirken als in einem kleinen - ein dummer Herrscher aber auch viel mehr Un- fug. Da weise Herrscher seltener sind als dumme, war ich schon immer gegen große Reiche skeptisch. - Herbert Rosendorfer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] sandbox: Change md command to use map_physmem
Dear Simon Glass, In message 1319586669-22190-1-git-send-email-...@chromium.org you wrote: Sandbox wants to support commands which use memory. The map_physmen() call provides this feature, so should be used more consistently in U-Boot. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: - Remove check for NULL pointer since map_physmem apparently cannot fail common/cmd_mem.c |9 +++-- 1 files changed, 7 insertions(+), 2 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Unix: Some say the learning curve is steep, but you only have to climb it once. - Karl Lehenbauer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sandbox/tegra2: fix typo in autocomplete define
Dear Mike Frysinger, In message 1319624398-31690-1-git-send-email-vap...@gentoo.org you wrote: Signed-off-by: Mike Frysinger vap...@gentoo.org --- include/configs/sandbox.h |2 +- include/configs/tegra2-common.h |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de At least they're __EXPERIENCED incompetents ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: sandbox: optimize puts
Dear Mike Frysinger, In message 1319624439-31823-1-git-send-email-vap...@gentoo.org you wrote: Signed-off-by: Mike Frysinger vap...@gentoo.org --- drivers/serial/sandbox.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I have a theory that it's impossible to prove anything, but I can't prove it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: sandbox: use ssize_t to match os_read
Dear Mike Frysinger, In message 1319624461-31904-1-git-send-email-vap...@gentoo.org you wrote: Signed-off-by: Mike Frysinger vap...@gentoo.org --- drivers/serial/sandbox.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Unix: Some say the learning curve is steep, but you only have to climb it once. - Karl Lehenbauer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
