Re: [U-Boot] [PATCH v1 0/7] TI: armv7: add parallel NAND support
From: Igor Grinberg [mailto:grinb...@compulab.co.il] Hi Pekon, On 07/04/14 22:05, Pekon Gupta wrote: This patch series adds support for parallel NAND devices support connected via GPMC chip-select on various boards belonging to AM33xx and OMAPx platforms. This series also moves some board specific CONFIG_NAND_xx from generic files to individual files. Tested using: ./MAKEALL -s am33xx -s omap3 -s oamp4 -s omap5 works fine except for am335x_boneblack_vboot build breaks for am335x_boneblack_vboot for un-related reasons u-boot/scripts/dtc-version.sh: line 17: dtc: command not found This is obvious, apparently beagle bone black wants to use the DT for U-Boot and you don't have dtc installed or it is not in your PATH. Yes, my bad. I was expecting dtc to be part of $UBOOT/scripts/... as in linux. ' am335x_boneblack_vboot' builds cleanly after I fix my $PATH to point to linux kernel dtc. -- Configuring for am335x_boneblack_vboot - Board: am335x_evm, Options: SERIAL1,CONS_INDEX=1,EMMC_BOOT,ENABLE_VBOOT textdata bss dec hex filename 367622 12722 8693820 9074164 8a75f4 ./u-boot 727953084 198024 273903 42def ./spl/u-boot-spl -- One request, as [PATCH 1/7] touches some non-TI board configs, So some tested-by would help here to confirm that this patch isn't breaking anything. with regards, pekon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Question] Is it safe to use 'set verify n' ?
Hi everyone, when it comes to optimizing the boot sequence there are several documents with a lot of hints. One of them is to skip the check sum calculation of the image in U-Boot (set verify n) - some of them say you don't need to verify every time you boot, since it is always the same image you load. I've tested this option and it saves around 900 ms. My question is: I'm a bit worried if this boot sequence is still safe to run. What happens e.g. if there were Flash errors? Does it still makes sense to skip the verification, or wouldn't it be better to accept a longer boot since the risk of errors is too high? What is your opinion? Kind Regards Frank ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] enbw_cmc, da850evm_direct_nor, and calimain vectors table misaligned (was: [PATCH] arm: fix a build error with CONFIG_USE_IRQ)
Hi Albert, On Fri, Jul 4, 2014 at 10:35 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Christian, On Wed, 2 Jul 2014 15:45:17 +0200, Christian Riesch christian.rie...@omicron.at wrote: Hello Albert, On Wed, Jun 18, 2014 at 2:55 PM, Christian Riesch christian.rie...@omicron.at wrote: Am I missing something here? What would be the preferred solution to make the board working again? Any comments on this? What shall we do to get the boards working again? Sorry for the delay. My opinion is that for these boards, there should actually be *no* exception vectors at the start of the image, since it would never serve any purpose anyway unless as you suggest we copy the vectors table from the image to the actual vectors table location (or set the VBAR to the image vector table location for those targets which allow it). (and I don't think this is limited to the three boards discussed here. IOW, the current exception/interrupt system in ARM U-Boot is FUBAR.) As far as fixing the boards, Masahiro had posted a series where one patch fixed the issue. I NAKed the submission for several reasons; I had expected a followup (v3) which I failed to ping for. MAsahiro: do you have a v3 ready? I assume you are talking about [1]. Adding this #include alone does not solve the issue for the calimain board. With adding the include, we would end up with #include config.h #ifdef CONFIG_SYS_DV_NOR_BOOT_CFG .word CONFIG_SYS_DV_NOR_BOOT_CFG #endif _start: ldr pc, _reset ... in arch/arm/lib/vectors.S. As a result, __image_copy_start points to 0x6000 (CONFIG_SYS_TEXT_BASE) and _start points is 0x6004. The relocation code in arch/arm/lib/relocate.S calculates its relocation offset based on __image_copy_start. However, arch/arm/lib/board.c calculates the offset as gd-reloc_off = addr - (ulong)_start; As the two are different, we have different offsets for the relocation code in relocate.S (based on __image_copy_start) and the calculation of the lr register in arch/arm/lib/crt0.S (gd-reloc_off). After relocation, the CPU jumps to the wrong address. So we can either unify the offset calculation (which of the two is the correct one?) or put the _start label where it was in earlier versions of u-boot: #include config.h _start: #ifdef CONFIG_SYS_DV_NOR_BOOT_CFG .word CONFIG_SYS_DV_NOR_BOOT_CFG #endif ldr pc, _reset ... What do you think? Thanks, Christian [1] http://lists.denx.de/pipermail/u-boot/2014-June/181334.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] enbw_cmc, da850evm_direct_nor, and calimain vectors table misaligned (was: [PATCH] arm: fix a build error with CONFIG_USE_IRQ)
Hi again, On Mon, Jul 7, 2014 at 9:15 AM, Christian Riesch christian.rie...@omicron.at wrote: [...] As a result, __image_copy_start points to 0x6000 (CONFIG_SYS_TEXT_BASE) and _start points is 0x6004. The relocation code in arch/arm/lib/relocate.S calculates its relocation offset based on __image_copy_start. However, arch/arm/lib/board.c calculates the offset as gd-reloc_off = addr - (ulong)_start; I just noticed that I did my test without CONFIG_SYS_GENERIC_BOARD. Adding CONFIG_SYS_GENERIC_BOARD solves that problem, as the relocation offset calculation in common/board_f.c is based on CONFIG_SYS_TEXT_BASE. So adding the missing #include in vectors.S and adding CONFIG_SYS_GENERIC_BOARD (patch is already in u-boot-arm/master) fixes the calimain board. I'll post a patch for the missing include. Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: include config.h in arch/arm/lib/vectors.S
config.h is required for CONFIG_SYS_DV_NOR_BOOT_CFG. Signed-off-by: Christian Riesch christian.rie...@omicron.at Reported-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Masahiro Yamada yamad...@jp.panasonic.com Cc: Heiko Schocher h...@denx.de Cc: Sudhakar Rajashekhara sudhakar@ti.com --- arch/arm/lib/vectors.S |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/lib/vectors.S b/arch/arm/lib/vectors.S index e6538ef..493f337 100644 --- a/arch/arm/lib/vectors.S +++ b/arch/arm/lib/vectors.S @@ -13,6 +13,8 @@ * SPDX-License-Identifier:GPL-2.0+ */ +#include config.h + /* * * -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Question] Any plan to refactor Generic Board Framework?
Hi. The generic board code looks really dirty to me: common/board_f.c is sprinkled with ARCH/CPU/BOARD configs For example, #if defined(CONFIG_405GP) || defined(CONFIG_405EP) || \ defined(CONFIG_440EP) || defined(CONFIG_440GR) || \ defined(CONFIG_440EPX) || defined(CONFIG_440GRX) bd-bi_pci_busfreq = get_PCI_freq(); bd-bi_opbfreq = get_OPB_freq(); #elif defined(CONFIG_XILINX_405) bd-bi_pci_busfreq = get_PCI_freq(); #endif or #if defined(CONFIG_8xx) || defined(CONFIG_MPC8260) || defined(CONFIG_5xx) || \ defined(CONFIG_E500) || defined(CONFIG_MPC86xx) bd-bi_immr_base = CONFIG_SYS_IMMR; /* base of IMMR register */ #endif #if defined(CONFIG_MPC5xxx) bd-bi_mbar_base = CONFIG_SYS_MBAR; /* base of internal registers */ #endif #if defined(CONFIG_MPC83xx) bd-bi_immrbar = CONFIG_SYS_IMMR; #endif Is there any plan to fix them? When? By whom? (They include some old platform macros such as CONFIG_8xx. Is it worth refactoring? If so, who will do it? ) Besides, there are many 'TODO' marks. But it seems nothing has happened so far... Now generic board is suppored in ARM, PPC, MIPS, Sandbox, ARC, x86. Accoding to doc/README.generic-board, we are expecting the other architectures will support it before October. I think we should start to do something now. If we keep going without any clean-up, I guess it will be messed up. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Question] Any plan to refactor Generic Board Framework?
Hi Masahiro, On 7 July 2014 20:37, Masahiro Yamada yamad...@jp.panasonic.com wrote: Hi. The generic board code looks really dirty to me: common/board_f.c is sprinkled with ARCH/CPU/BOARD configs For example, #if defined(CONFIG_405GP) || defined(CONFIG_405EP) || \ defined(CONFIG_440EP) || defined(CONFIG_440GR) || \ defined(CONFIG_440EPX) || defined(CONFIG_440GRX) bd-bi_pci_busfreq = get_PCI_freq(); bd-bi_opbfreq = get_OPB_freq(); #elif defined(CONFIG_XILINX_405) bd-bi_pci_busfreq = get_PCI_freq(); #endif or #if defined(CONFIG_8xx) || defined(CONFIG_MPC8260) || defined(CONFIG_5xx) || \ defined(CONFIG_E500) || defined(CONFIG_MPC86xx) bd-bi_immr_base = CONFIG_SYS_IMMR; /* base of IMMR register */ #endif #if defined(CONFIG_MPC5xxx) bd-bi_mbar_base = CONFIG_SYS_MBAR; /* base of internal registers */ #endif #if defined(CONFIG_MPC83xx) bd-bi_immrbar = CONFIG_SYS_IMMR; #endif Is there any plan to fix them? When? By whom? (They include some old platform macros such as CONFIG_8xx. Is it worth refactoring? If so, who will do it? ) Besides, there are many 'TODO' marks. But it seems nothing has happened so far... Now generic board is suppored in ARM, PPC, MIPS, Sandbox, ARC, x86. Accoding to doc/README.generic-board, we are expecting the other architectures will support it before October. I think we should start to do something now. If we keep going without any clean-up, I guess it will be messed up. The code is trying to duplicate the old board init without changing/breaking anything. So the #ifdefs are trying to duplicate those in the old board init code. I didn't want to create lots of test problems/breakages, although even with this approach I am aware of at least one problem. The TODOs are mostly things that I hope board authors will look at when they convert over their boards. The goal was to get all of the archs using the same code, even if it is just as full of #ifdefs as the old arch/xxx/lib/board.c code. The benefit is that we can add new features without doing it in 10 places. The plan is that board init will mostly go away and be replaced by driver model init. What is left in board_f and board_r will be U-Boot generic things like relocation. This is quite a long-term plan, since driver model conversion is going to take a while. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6] arm: ep9315: Return back Cirrus Logic EDB9315A board support
Hi. Sergey, Arbert. On Sat, 5 Jul 2014 00:22:05 +0200 Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Sergey, On Wed, 25 Jun 2014 23:44:29 +0400, Sergey Kostanbev sergey.kostanb...@gmail.com wrote: This patch returns back support for old ep93xx processors family Signed-off-by: Sergey Kostanbaev sergey.kostanb...@gmail.com Cc: albert.u.b...@aribaud.net --- [snip] Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. I have two questions: [1] Is this board really working? This patch added a linker script board/cirrus/edb93xx/u-boot.lds But '.vectors' section is missing from it. In my understanding, commit 41623c91b0 expects '.vectors' section handling for all ARM linker scripts. [2] Why was board/cirrus/edb93xx/u-boot.lds added instead of re-using (or modifying) arch/arm/cpu/arm920t/ep93xx/u-boot.lds ? 'edb9315a' is the only one board with 'ep93xx' SoC. It means, if you add 'board/cirrus/edb93xx/u-boot.lds', 'arch/arm/cpu/arm920t/ep93xx/u-boot.lds' is never used. Please delete either of them. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cosmetic: doc: update README.generic-board
Now MIPS supports 'generic board' feature. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Simon Glass s...@chromium.org --- doc/README.generic-board | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/doc/README.generic-board b/doc/README.generic-board index 17da0b9..37c1b03 100644 --- a/doc/README.generic-board +++ b/doc/README.generic-board @@ -40,10 +40,11 @@ Supported Arcthitectures If you are unlucky then your architecture may not support generic board. -The following architectures are supported at the time of writing: +The following architectures are supported now: arc arm + mips powerpc sandbox x86 -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mtdcore: Fix a build error with CONFIG_CMD_MTDPARTS_SPREAD
This patch fixes the build error for CONFIG_CMD_MTDPARTS_SPREAD
introduced by the commit:
commit dfe64e2c89731a3f9950d7acd8681b68df2bae03
Author: Sergey Lapin sla...@ossfans.org
Date: Mon Jan 14 03:46:50 2013 +
mtd: resync with Linux-3.7.1
Signed-off-by: Maxin B. John maxin.j...@enea.com
---
drivers/mtd/mtdcore.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 0a38fbe..328a2b9 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -167,7 +167,7 @@ void mtd_get_len_incl_bad(struct mtd_info *mtd, uint64_t
offset,
*truncated = 0;
*len_incl_bad = 0;
- if (!mtd-block_isbad) {
+ if (!mtd-_block_isbad) {
*len_incl_bad = length;
return;
}
@@ -183,7 +183,7 @@ void mtd_get_len_incl_bad(struct mtd_info *mtd, uint64_t
offset,
block_len = mtd-erasesize - (offset (mtd-erasesize - 1));
- if (!mtd-block_isbad(mtd, offset ~(mtd-erasesize - 1)))
+ if (!mtd-_block_isbad(mtd, offset ~(mtd-erasesize - 1)))
len_excl_bad += block_len;
*len_incl_bad += block_len;
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH]fix yaffs2 with inband-tags option, mtd_block_markbad mtd_block_isbad parameter error.
Dear xu.xi...@zte.com.cn, In message of377cf5dc.91728031-on48257d0e.001f0ccd-48257d0e.001f3...@zte.com.cn you wrote: when I use yaffs2 with inband-tags, the file always miss some part which filled with 0s. It prints 'yaffs: Chunk -1 not found zero instead' when ytrace is 0x800. I found out mtd_block_markbad mtd_block_isbad parameter is wrong. In file fs\yaffs2\yaffs_guts.c, line 4658 to 4664? /* Sort out space for inband tags, if required */ if (dev-param.inband_tags) dev-data_bytes_per_chunk = dev-param.total_bytes_per_chunk - sizeof(struct yaffs_packed_tags2_tags_only); else dev-data_bytes_per_chunk = dev-param.total_bytes_per_chunk; In inband_tags mode, data_bytes_per_chunk is not page aligned, so in file fs\yaffs2\yaffs_mtdif2.c, line 182 to 184 and line 201 to 203, mtd_block_markbad(mtd, blockNo * dev-param.chunks_per_block * dev-data_bytes_per_chunk); mtd_block_isbad(mtd, blockNo * dev-param.chunks_per_block * dev-data_bytes_per_chunk); the 2nd para is not correct but small. My patch followed, Thanks for analyzing the problem. Please see [1] for the requirements how to format a patch. Please make sure to provide a descriptive commit message, and don't forget your Signed-off-by: line. Please also check if this fix is still needed with the updated MTD code as posted by Heiko Schocher [2]. If yes, then I suggest you rebase your fix against Heiko's code base. Thanks. [1] http://www.denx.de/wiki/view/U-Boot/Patches#General_Patch_Submission_Rules [2] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/189358 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 Quote from a recent meeting: We are going to continue having these meetings everyday until I find out why no work is getting done. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Question] Is it safe to use 'set verify n' ?
Dear Frank, In message 53ba5751024600052...@gwia2.rz.hs-offenburg.de you wrote: My question is: I'm a bit worried if this boot sequence is still safe to run. What happens e.g. if there were Flash errors? Does it still makes sense to skip the verification, or wouldn't it be better to accept a longer boot since the risk of errors is too high? We cannot answer this question for your. You already realized that you are trading speed for security when you switch off the checksum verification. It depends on your use case and your project's requirements if this acceptable or not. If you're building a consumer grade MP3 player or a TV remote control, then it's probably fine. If you build a distress call system or a remote control for medical equipment the technical requirements may be very similar, but your evaluation of the speed vs. risk question may come to totally different results. 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 the source of every error which is blamed on the computer you will find at least two human errors, including the error of blaming it on the computer. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtdcore: Fix a build error with CONFIG_CMD_MTDPARTS_SPREAD
Dear Maxin, In message 1404729444-10957-1-git-send-email-maxin.j...@enea.com you wrote: This patch fixes the build error for CONFIG_CMD_MTDPARTS_SPREAD introduced by the commit: commit dfe64e2c89731a3f9950d7acd8681b68df2bae03 Author: Sergey Lapin sla...@ossfans.org Date: Mon Jan 14 03:46:50 2013 + mtd: resync with Linux-3.7.1 Can you please check if this patch is still needed with the updated MTD code posted by Heiko [1] - and if so, rebase your patch against Heiko's code base? Thanks. [1] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/189358 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 Niklaus Wirth has lamented that, whereas Europeans pronounce his name correctly (Ni-klows Virt), Americans invariably mangle it into (Nick-les Worth). Which is to say that Europeans call him by name, but Americans call him by value. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/10] sunxi: Bug fixes, sun4i and sun5i support and network improvements
Hi Ian,
On 07/06/2014 09:12 PM, Ian Campbell wrote:
On Mon, 2014-06-09 at 11:36 +0200, Hans de Goede wrote:
Here is v2 of my patch series to be applied on top of Ian's recently merged
basic sun7i support.
For the A13-OLinuXinoM and r7-tv-dongle with this series I'm seeing:
arch/arm/cpu/armv7/sunxi/board.c: In function ‘cpu_eth_init’:
arch/arm/cpu/armv7/sunxi/board.c:118:6: warning: unused variable
‘rc’ [-Wunused-variable]
int rc;
^
because they both have neither EMAC or GMAC. This resolves it:
8--
From 4eed69132de51d07586e7b070eda72297825a674 Mon Sep 17 00:00:00 2001
From: Ian Campbell i...@hellion.org.uk
Date: Sun, 6 Jul 2014 20:03:20 +0100
Subject: [PATCH] sunxi: Avoid unused variable warning
Signed-off-by: Ian Campbell i...@hellion.org.uk
---
arch/arm/cpu/armv7/sunxi/board.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/cpu/armv7/sunxi/board.c
b/arch/arm/cpu/armv7/sunxi/board.c
index 1e506b5..f8db9e8 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -115,7 +115,9 @@ void enable_caches(void)
*/
int cpu_eth_init(bd_t *bis)
{
+#if defined(CONFIG_SUNXI_EMAC) || defined(CONFIG_SUNXI_GMAC)
int rc;
+#endif
#ifdef CONFIG_SUNXI_EMAC
rc = sunxi_emac_initialize(bis);
AFAIK we will never define both EMAC and GMAC for the same board,
so IMHO a better fix would be to change this line:
rc = sunxi_emac_initialize(bis);
to:
int rc = sunxi_emac_initialize(bis);
And the same for gmac.
Regards,
Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/10] sunxi: Bug fixes, sun4i and sun5i support and network improvements
Hi, On 07/06/2014 09:26 PM, Ian Campbell wrote: On Mon, 2014-06-09 at 11:36 +0200, Hans de Goede wrote: adds sun4i and sun5i support Does this series omit FEL mode support or did you just not include it for the new boards? I just did not include it. I think in general we want a _FEL variant for every board except the minority which don't have an OTG port etc. I'm not sold on this idea. Normal users (and distros) will never use the FEL variants, and a developer needing a FEL build can just as easily edit boards.cfg, instead of us having 2 lines there for each and every sunxi board (of which there are *a lot*. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/10] sunxi: Bug fixes, sun4i and sun5i support and network improvements
On Mon, Jul 07, 2014 at 02:53:44PM +0200, Hans de Goede wrote: Hi, On 07/06/2014 09:26 PM, Ian Campbell wrote: On Mon, 2014-06-09 at 11:36 +0200, Hans de Goede wrote: adds sun4i and sun5i support Does this series omit FEL mode support or did you just not include it for the new boards? I just did not include it. I think in general we want a _FEL variant for every board except the minority which don't have an OTG port etc. I'm not sold on this idea. Normal users (and distros) will never use the FEL variants, and a developer needing a FEL build can just as easily edit boards.cfg, instead of us having 2 lines there for each and every sunxi board (of which there are *a lot*. ... and once we have Kconfig it will be an easy thing to enable as needed. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtdcore: Fix a build error with CONFIG_CMD_MTDPARTS_SPREAD
Hello John, Am 07.07.2014 15:17, schrieb Maxin B. John: Dear Wolfgang, On Mon, Jul 07, 2014 at 02:17:09PM +0200, Wolfgang Denk wrote: Dear Maxin, In message1404729444-10957-1-git-send-email-maxin.j...@enea.com you wrote: This patch fixes the build error for CONFIG_CMD_MTDPARTS_SPREAD introduced by the commit: commit dfe64e2c89731a3f9950d7acd8681b68df2bae03 Author: Sergey Lapinsla...@ossfans.org Date: Mon Jan 14 03:46:50 2013 + mtd: resync with Linux-3.7.1 Can you please check if this patch is still needed with the updated MTD code posted by Heiko [1] - and if so, rebase your patch against Heiko's code base? Thanks. [1] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/189358 Thank you very much for pointing this out. I have tested Heiko's code available here: repo: git://git.denx.de/u-boot-testing.git branch: update-v3-mtd+ubi-linux-v3.14 Please use the patches posted on the ML, not the branch in u-boot-testing.git for testing. Also you tested with an older version, please use the v5 version: [U-Boot] [PATCH v5 0/5] mtd, ubi, ubifs: resync with Linux-3.14 http://lists.denx.de/pipermail/u-boot/2014-June/182501.html Patchwork [U-Boot,v5,1/5] lib, rbtree: resync with Linux-3.14 http://patchwork.ozlabs.org/patch/363332/ Patchwork [U-Boot,v5,2/5] lib, list_sort: add list_sort from linux 3.14 http://patchwork.ozlabs.org/patch/363335/ Patchwork [U-Boot,v5,3/5] linux include: add ERR_CAST http://patchwork.ozlabs.org/patch/363334/ Patchwork [U-Boot,v5,4/5] lib, linux: move linux specific defines to linux/compat.h http://patchwork.ozlabs.org/patch/36/ Patchwork [U-Boot,v5,5/5] mtd, ubi, ubifs: resync with Linux-3.14 waiting for administrator approval http://patchwork.ozlabs.org/patch/363343/ The build error that was mentioned in this mail is still valid there: LD drivers/pcmcia/built-in.o drivers/mtd/mtdcore.c: In function 'mtd_get_len_incl_bad': drivers/mtd/mtdcore.c:805:10: error: 'struct mtd_info' has no member named 'block_isbad' drivers/mtd/mtdcore.c:821:11: error: 'struct mtd_info' has no member named 'block_isbad' CC drivers/rtc/date.o make[1]: *** [drivers/mtd/mtdcore.o] Error 1 make: *** [drivers/mtd] Error 2 make: *** Waiting for unfinished jobs Also re-created patch against this. Should I send it as a separate patch or would you suggest another branch for this fix ? Looked in the v5 patches, yes it seems, there is the same problem, when enabling CONFIG_CMD_MTDPARTS_SPREAD Please test against the above patches, and resend your patch, thanks for detecting this! And if you test my v5 patches, feel free to send a Tested-by for them to the ML! bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtdcore: Fix a build error with CONFIG_CMD_MTDPARTS_SPREAD
Dear Wolfgang, On Mon, Jul 07, 2014 at 02:17:09PM +0200, Wolfgang Denk wrote: Dear Maxin, In message 1404729444-10957-1-git-send-email-maxin.j...@enea.com you wrote: This patch fixes the build error for CONFIG_CMD_MTDPARTS_SPREAD introduced by the commit: commit dfe64e2c89731a3f9950d7acd8681b68df2bae03 Author: Sergey Lapin sla...@ossfans.org Date: Mon Jan 14 03:46:50 2013 + mtd: resync with Linux-3.7.1 Can you please check if this patch is still needed with the updated MTD code posted by Heiko [1] - and if so, rebase your patch against Heiko's code base? Thanks. [1] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/189358 Thank you very much for pointing this out. I have tested Heiko's code available here: repo: git://git.denx.de/u-boot-testing.git branch: update-v3-mtd+ubi-linux-v3.14 The build error that was mentioned in this mail is still valid there: LD drivers/pcmcia/built-in.o drivers/mtd/mtdcore.c: In function 'mtd_get_len_incl_bad': drivers/mtd/mtdcore.c:805:10: error: 'struct mtd_info' has no member named 'block_isbad' drivers/mtd/mtdcore.c:821:11: error: 'struct mtd_info' has no member named 'block_isbad' CC drivers/rtc/date.o make[1]: *** [drivers/mtd/mtdcore.o] Error 1 make: *** [drivers/mtd] Error 2 make: *** Waiting for unfinished jobs Also re-created patch against this. Should I send it as a separate patch or would you suggest another branch for this fix ? Best regards, Wolfgang Denk Best Regards, Maxin B. John ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtdcore: Fix a build error with CONFIG_CMD_MTDPARTS_SPREAD
Dear Maxin, In message 20140707131710.ga14...@sestofb10.enea.se you wrote: The build error that was mentioned in this mail is still valid there: Thanks for verifying this. Also re-created patch against this. Should I send it as a separate patch or would you suggest another branch for this fix ? Please send it as patch against Heiko's code, and mention in the comment section that it requires Heiko's update to be applied first. Thanks a lot! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A failure will not appear until a unit has passed final inspection. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/4] mx6: Add support for the mx6solox variant
Hi Stefano, On Thu, Jul 3, 2014 at 3:22 PM, Fabio Estevam feste...@gmail.com wrote: Hi Stefano, On Thu, Jul 3, 2014 at 4:15 AM, Stefano Babic sba...@denx.de wrote: I have only taken a short look because the series should flow after 2014.07. Anyway, I could push them into -next. Pushing them into -next would be very helpful, so that we can continue on adding new support for mx6solox. Would it be possible to review the initial series that adds mx6solox support and apply it to -next if you are happy with it? Otherwise, I am not able to proceed with further mx6solox U-boot upstream work. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/10] sunxi: Bug fixes, sun4i and sun5i support and network improvements
On Mon, 2014-07-07 at 14:50 +0200, Hans de Goede wrote: AFAIK we will never define both EMAC and GMAC for the same board, If we are sure of this (and I suspect this is the case, since IIRC they share some pins) then I agree with your suggestion. so IMHO a better fix would be to change this line: rc = sunxi_emac_initialize(bis); to: int rc = sunxi_emac_initialize(bis); And the same for gmac. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/10] sunxi: Bug fixes, sun4i and sun5i support and network improvements
On Mon, 2014-07-07 at 14:53 +0200, Hans de Goede wrote: Hi, On 07/06/2014 09:26 PM, Ian Campbell wrote: On Mon, 2014-06-09 at 11:36 +0200, Hans de Goede wrote: adds sun4i and sun5i support Does this series omit FEL mode support or did you just not include it for the new boards? I just did not include it. I think in general we want a _FEL variant for every board except the minority which don't have an OTG port etc. I'm not sold on this idea. Normal users (and distros) will never use the FEL variants, and a developer needing a FEL build can just as easily edit boards.cfg, instead of us having 2 lines there for each and every sunxi board (of which there are *a lot*. Actually Debian is providing the FEL binaries for CT in its u-boot packages already. I was planning to provide a script to automatically install Debian starting from a bare board booted in FEL mode from a host system and getting the installer to put the bootloader on the MMC etc etc. (I'm a long way from actually having this working...) Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-boot] [Patch v2 3/3] k2hk_evm: add script to automate NAND flash process
On 07/04/2014 08:03 AM, Ivan Khoronzhuk wrote:
Add script to automate NAND flash process. As for now the board has
two burn scripts - burn to boot from SPI NOR flash and burn to boot
from AEMIF NAND flash, rename burn_uboot script to burn_uboot_spi.
Also update README to contain NAND burn U-boot process description.
Signed-off-by: Ivan Khoronzhukivan.khoronz...@ti.com
---
board/ti/k2hk_evm/README | 28 +++-
include/configs/k2hk_evm.h | 4 +++-
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/board/ti/k2hk_evm/README b/board/ti/k2hk_evm/README
index bfeb05b..7426b8d 100644
--- a/board/ti/k2hk_evm/README
+++ b/board/ti/k2hk_evm/README
@@ -38,11 +38,13 @@ board configuration file: include/configs/k2hk_evm.h
Supported boot modes:
- SPI NOR boot
+ - AEMIF NAND boot
Supported image formats:-
- u-boot.bin: for loading and running u-boot.bin through Texas instruments
code composure studio (CCS)
- u-boot-spi.gph: gpimage for programming SPI NOR flash for SPI NOR boot
+ - u-boot-nand.gph: gpimage for programming AEMIF NAND flash for NAND boot
Build instructions:
===
@@ -55,6 +57,10 @@ To build u-boot-spi.gph
make k2hk_evm_config
make u-boot-spi.gph
+To build u-boot-nand.gph
+make k2hk_evm_config
+make u-boot-nand.gph
+
Load and Run U-Boot on K2HK EVM using CCS
=
@@ -115,8 +121,28 @@ instructions:-
5. At the U-Boot console type following to setup u-boot environment variables.
setenv addr_uboot 0x8700
setenv filesizesize in hex of u-boot-spi.gph rounded to hex 0x1
- run burn_uboot
+ run burn_uboot_spi
Once u-boot prompt is available, Power OFF the EVM. Set the SW1 dip switch
to SPI Little Endian Boot mode as per instruction at
http://processors.wiki.ti.com/index.php/EVMK2H_Hardware_Setup.
6. Power ON the EVM. The EVM now boots with u-boot image on the NOR flash.
+
+AEMIF NAND Flash programming instructions
+==
+U-Boot image can be flashed to first 1024KB of the NAND flash using following
+instructions:-
+
+1. Start CCS and run U-boot as described above.
+2. Suspend Target. Select Run - Suspend from top level menu
+ CortexA15_1 (Free Running)
+3. Load u-boot-nand.gph binary from build folder on to DDR address 0x8700
+ through CCS as described in step 2 of Load and Run U-Boot on K2HK EVM
+ using CCS, but using address 0x8700.
+4. Free Run the target as desribed earlier (step 4) to get u-boot prompt
+5. At the U-Boot console type following to setup u-boot environment variables.
+ setenv filesizesize in hex of u-boot-nand.gph rounded to hex 0x1
+ run burn_uboot_nand
+ Once u-boot prompt is available, Power OFF the EVM. Set the SW1 dip switch
+ to ARM NAND Boot mode as per instruction at
+ http://processors.wiki.ti.com/index.php/EVMK2H_Hardware_Setup.
+6. Power ON the EVM. The EVM now boots with u-boot image on the NAND flash.
diff --git a/include/configs/k2hk_evm.h b/include/configs/k2hk_evm.h
index 3f87741..63e0249 100644
--- a/include/configs/k2hk_evm.h
+++ b/include/configs/k2hk_evm.h
@@ -221,8 +221,10 @@
get_mon_net=dhcp ${addr_mon} ${tftp_root}/${name_mon}\0 \
get_mon_ubi=ubifsload ${addr_mon} ${name_mon}\0 \
get_uboot_net=dhcp ${addr_uboot} ${tftp_root}/${name_uboot}\0 \
- burn_uboot=sf probe; sf erase 0 0x10; \
+ burn_uboot_spi=sf probe; sf erase 0 0x10; \
sf write ${addr_uboot} 0 ${filesize}\0 \
+ burn_uboot_nand=nand erase 0 0x10; \
+ nand write ${addr_uboot} 0 ${filesize}\0\
args_all=setenv bootargs console=ttyS0,115200n8 rootwait=1\0\
args_ubi=setenv bootargs ${bootargs} rootfstype=ubifs \
root=ubi0:rootfs rootflags=sync rw ubi.mtd=2,2048\0 \
Acked-by: Murali Karicheri m-kariche...@ti.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/3] mtd, ubi, ubifs: resync with Linux-3.14
On Mon, Jun 30, 2014 at 06:09:53PM -0500, Scott Wood wrote: On Tue, 2014-07-01 at 00:56 +0200, Wolfgang Denk wrote: Dear Scott, In message 1404159636.2435.165.ca...@snotra.buserror.net you wrote: I agree that #ifdef's should be avoided, but then here they also serve a documentation purpose as they clearly mark areas of code that are specific to U-Boot, or that are not used in U-Boot. git diff can do that too, without reducing readability or increasing the likelihood of mismerges. (git) diff needs a reference to diff against. Maybe I missed some earlier comments about that, but how exactly should this be done here? When the code is synced, the corresponding Linux SHA1 or tag should be placed in the commit message. This is the case for the NAND code. Unfortunately it has never been true of the mtd/ubi code, but this do-over in those trees is an opportunity to fix that. If we want to have strictly bisectable code in mainline, I don't really see how to provide an unmodified source reference to show the U-Boot specific diffs. Can you please explain (maybe again, sorry) how you think the code update should be done do both allow such a git diff and remain bisectable? The ways I can see all require a non-working / non-com- piling intermediate step. There is no intermediate step. The unmodified source is in the Linux tree -- most likely in a more accurate/complete form than the ifdefs convey, since minor differences and subsequent local changes are unlikely to be marked. You can either fetch the Linux tree into your local U-Boot repo (or vice versa) so that git diff can compare them, or you can check out separate repositories to the proper tags/SHAs and use ordinary diff. It's not something that I'd expect one to want to do very often, though. Usually you want to know how things work in the codebase you're working on, or you want to compare some specific aspect of the code which can more easily be done manually. So an example of this would be doing say: $ git diff 3dad234 drivers/mtd/nand/nand_base.c Where 3dad234 is the last kernel commit to U-Boot drivers/mtd/nand/nand_base.c where we synced right (and we've fetched the kernel sources into this repo as well) ? (This commit is also valid for atmel_nand.c and I looked over the results there too..). We must, really, follow the general rule where when we sync stuff from the kernel we say what the commit we synced with is, for UBI/etc. We may not have been for forever but the last time we also said that tag it was against. But how we denote U-Boot vs Linux Kernel differences is somewhat up to the subsystem maintainer. We must be careful when syncing back. But looking over the above diff, as a more casual nand developer, I wish there was more in-code context about why we are different. But that's just me and how I develop. It would be pretty easy (but not quite easily scriptable) to whack out the #ifndef/else/endif __UBOOT__'s, commit that, and be back to having the output one wants, if that's how one works. In sum, if Heiko is going to be owning UBI/related code and syncs, whatever makes life easiest on _him_ to make sure we don't have regressions is fine with me (within reason, and this seems to be within reason). Do not get me wrong please, I appreciate all the time you've spent thus far in U-Boot and wish and want you to comment / review / advise as you're still able to find time. But if someone else is taking up doing the re-syncs it needs to also fit their workflow. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] usb: phy: omap_usb_phy: implement usb_phy_power() for AM437x
hi,
On Mon, Jun 23, 2014 at 05:18:24PM -0500, Felipe Balbi wrote:
Newer AM437x silicon requires us to explicitly power up
the USB2 PHY. By implementing usb_phy_power() we can
achieve that.
Signed-off-by: Felipe Balbi ba...@ti.com
---
Changes since v1:
- add macros for USB1_CTRL register and bits
same here. Still pending, am437x will remain broken until this is
applied.
cheers
arch/arm/include/asm/arch-am33xx/hardware_am43xx.h | 5 +
drivers/usb/phy/omap_usb_phy.c | 17 -
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/arch-am33xx/hardware_am43xx.h
b/arch/arm/include/asm/arch-am33xx/hardware_am43xx.h
index 15399dc..b5875e3 100644
--- a/arch/arm/include/asm/arch-am33xx/hardware_am43xx.h
+++ b/arch/arm/include/asm/arch-am33xx/hardware_am43xx.h
@@ -40,6 +40,11 @@
#define VTP0_CTRL_ADDR 0x44E10E0C
#define VTP1_CTRL_ADDR 0x48140E10
+/* USB CTRL Base Address */
+#define USB1_CTRL0x44e10628
+#define USB1_CTRL_CM_PWRDN BIT(0)
+#define USB1_CTRL_OTG_PWRDN BIT(1)
+
/* DDR Base address */
#define DDR_PHY_CMD_ADDR 0x44E12000
#define DDR_PHY_DATA_ADDR0x44E120C8
diff --git a/drivers/usb/phy/omap_usb_phy.c b/drivers/usb/phy/omap_usb_phy.c
index af46db2..f78d532 100644
--- a/drivers/usb/phy/omap_usb_phy.c
+++ b/drivers/usb/phy/omap_usb_phy.c
@@ -222,7 +222,22 @@ static void am437x_enable_usb2_phy2(struct omap_xhci
*omap)
void usb_phy_power(int on)
{
- return;
+ u32 val;
+
+ /* USB1_CTRL */
+ val = readl(USB1_CTRL);
+ if (on) {
+ /*
+ * these bits are re-used on AM437x to power up/down the USB
+ * CM and OTG PHYs, if we don't toggle them, USB will not be
+ * functional on newer silicon revisions
+ */
+ val = ~(USB1_CTRL_CM_PWRDN | USB1_CTRL_OTG_PWRDN);
+ } else {
+ val |= USB1_CTRL_CM_PWRDN | USB1_CTRL_OTG_PWRDN;
+ }
+
+ writel(val, USB1_CTRL);
}
#endif /* CONFIG_AM437X_USB2PHY2_HOST */
--
2.0.0.390.gcb682f8
--
balbi
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] usb: host: xhci: make sure to power up PHY
On Mon, Jun 23, 2014 at 04:25:38PM -0500, Felipe Balbi wrote:
some boards won't work if the PHY isn't explicitly
powered up.
Signed-off-by: Felipe Balbi ba...@ti.com
ping, this is still pending in mainline u-boot. Without this, usb won't
work on am437x-sk.
---
drivers/usb/host/xhci-omap.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/host/xhci-omap.c b/drivers/usb/host/xhci-omap.c
index e667810..912b2bd 100644
--- a/drivers/usb/host/xhci-omap.c
+++ b/drivers/usb/host/xhci-omap.c
@@ -98,6 +98,7 @@ static int omap_xhci_core_init(struct omap_xhci *omap)
{
int ret = 0;
+ usb_phy_power(1);
omap_enable_phy(omap);
ret = dwc3_core_init(omap-dwc3_reg);
--
2.0.0.390.gcb682f8
--
balbi
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/6] cros_ec: Fix two bugs in the SPI implementation
An incorrect message version is passed to the EC in some cases and the
parameters of one function are switched.
Fix these problems.
Signed-off-by: Simon Glass s...@chromium.org
---
drivers/misc/cros_ec_spi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/cros_ec_spi.c b/drivers/misc/cros_ec_spi.c
index 7df709c..015333f 100644
--- a/drivers/misc/cros_ec_spi.c
+++ b/drivers/misc/cros_ec_spi.c
@@ -98,7 +98,7 @@ int cros_ec_spi_command(struct cros_ec_dev *dev, uint8_t cmd,
int cmd_version,
}
out = dev-dout;
- out[0] = cmd_version;
+ out[0] = EC_CMD_VERSION0 + cmd_version;
out[1] = cmd;
out[2] = (uint8_t)dout_len;
memcpy(out + 3, dout, dout_len);
@@ -165,7 +165,7 @@ int cros_ec_spi_decode_fdt(struct cros_ec_dev *dev, const
void *blob)
*/
int cros_ec_spi_init(struct cros_ec_dev *dev, const void *blob)
{
- dev-spi = spi_setup_slave_fdt(blob, dev-parent_node, dev-node);
+ dev-spi = spi_setup_slave_fdt(blob, dev-node, dev-parent_node);
if (!dev-spi) {
debug(%s: Could not setup SPI slave\n, __func__);
return -1;
--
2.0.0.526.g5318336
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/6] exynos: spi: Fix calculation of SPI transaction start time
The SPI transaction delay is supposed to be measured from the end of one transaction to the start of the next. The code does not work that way, so fix it. Signed-off-by: Simon Glass s...@chromium.org --- drivers/spi/exynos_spi.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c index c92276f..2969184 100644 --- a/drivers/spi/exynos_spi.c +++ b/drivers/spi/exynos_spi.c @@ -428,10 +428,6 @@ void spi_cs_activate(struct spi_slave *slave) clrbits_le32(spi_slave-regs-cs_reg, SPI_SLAVE_SIG_INACT); debug(Activate CS, bus %d\n, spi_slave-slave.bus); spi_slave-skip_preamble = spi_slave-mode SPI_PREAMBLE; - - /* Remember time of this transaction so we can honour the bus delay */ - if (spi_slave-bus-deactivate_delay_us) - spi_slave-last_transaction_us = timer_get_us(); } /** @@ -445,6 +441,11 @@ void spi_cs_deactivate(struct spi_slave *slave) struct exynos_spi_slave *spi_slave = to_exynos_spi(slave); setbits_le32(spi_slave-regs-cs_reg, SPI_SLAVE_SIG_INACT); + + /* Remember time of this transaction so we can honour the bus delay */ + if (spi_slave-bus-deactivate_delay_us) + spi_slave-last_transaction_us = timer_get_us(); + debug(Deactivate CS, bus %d\n, spi_slave-slave.bus); } -- 2.0.0.526.g5318336 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/6] spi: Support half-duplex mode in FDT decode
This parameter should also be supported. Signed-off-by: Simon Glass s...@chromium.org --- doc/device-tree-bindings/spi/spi-bus.txt | 2 ++ drivers/spi/spi.c| 2 ++ 2 files changed, 4 insertions(+) diff --git a/doc/device-tree-bindings/spi/spi-bus.txt b/doc/device-tree-bindings/spi/spi-bus.txt index 800dafe..5c8720a 100644 --- a/doc/device-tree-bindings/spi/spi-bus.txt +++ b/doc/device-tree-bindings/spi/spi-bus.txt @@ -59,6 +59,8 @@ contain the following properties. used for MOSI. Defaults to 1 if not present. - spi-rx-bus-width - (optional) The bus width(number of data wires) that used for MISO. Defaults to 1 if not present. +- spi-half-duplex - (optional) Indicates that the SPI bus should wait for + a header byte before reading data from the slave. Some SPI controllers and devices support Dual and Quad SPI transfer mode. It allows data in SPI system transfered in 2 wires(DUAL) or 4 wires(QUAD). diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 7ddea9b..7d81fbd 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -53,6 +53,8 @@ struct spi_slave *spi_base_setup_slave_fdt(const void *blob, int busnum, mode |= SPI_CPHA; if (fdtdec_get_bool(blob, node, spi-cs-high)) mode |= SPI_CS_HIGH; + if (fdtdec_get_bool(blob, node, spi-half-duplex)) + mode |= SPI_PREAMBLE; return spi_setup_slave(busnum, cs, max_hz, mode); } #endif -- 2.0.0.526.g5318336 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/6] cros_ec: power: Add a tunnelled version of the tps65090 driver
Unfortunately on Pit the AP has no direct access to the tps65090 but must
talk through the EC (over SPI) to the EC's I2C bus.
When driver model supports PMICs this will be relatively easy. In the
meantime the best approach is to duplicate the driver. It will be refactored
once driver model support is expanded.
Signed-off-by: Simon Glass s...@chromium.org
---
drivers/power/pmic/Makefile | 1 +
drivers/power/pmic/pmic_tps65090_ec.c | 212 ++
include/power/tps65090_pmic.h | 6 +
3 files changed, 219 insertions(+)
create mode 100644 drivers/power/pmic/pmic_tps65090_ec.c
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index a472f61..0b76611 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
obj-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
obj-$(CONFIG_POWER_PFUZE100) += pmic_pfuze100.o
obj-$(CONFIG_POWER_TPS65090) += pmic_tps65090.o
+obj-$(CONFIG_POWER_TPS65090_EC) += pmic_tps65090_ec.o
obj-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
obj-$(CONFIG_POWER_TPS65218) += pmic_tps65218.o
obj-$(CONFIG_POWER_TPS65910) += pmic_tps65910.o
diff --git a/drivers/power/pmic/pmic_tps65090_ec.c
b/drivers/power/pmic/pmic_tps65090_ec.c
new file mode 100644
index 000..93b7923
--- /dev/null
+++ b/drivers/power/pmic/pmic_tps65090_ec.c
@@ -0,0 +1,212 @@
+/*
+ * Copyright (c) 2013 The Chromium OS Authors. All rights reserved.
+ * Use of this source code is governed by a BSD-style license that can be
+ * found in the LICENSE file.
+ *
+ * Alternatively, this software may be distributed under the terms of the
+ * GNU General Public License (GPL) version 2 as published by the Free
+ * Software Foundation.
+ */
+
+#include common.h
+#include cros_ec.h
+#include errno.h
+#include power/tps65090_pmic.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define TPS65090_ADDR 0x48
+
+static struct tps65090 {
+ struct cros_ec_dev *dev;/* The CROS_EC device */
+} config;
+
+/* TPS65090 register addresses */
+enum {
+ REG_FET1_CTRL = 0x0f,
+ REG_FET2_CTRL,
+ REG_FET3_CTRL,
+ REG_FET4_CTRL,
+ REG_FET5_CTRL,
+ REG_FET6_CTRL,
+ REG_FET7_CTRL,
+ TPS65090_NUM_REGS,
+};
+
+enum {
+ MAX_FET_NUM = 7,
+ MAX_CTRL_READ_TRIES = 5,
+
+ /* TPS65090 FET_CTRL register values */
+ FET_CTRL_TOFET = 1 7, /* Timeout, startup, overload */
+ FET_CTRL_PGFET = 1 4, /* Power good for FET status */
+ FET_CTRL_WAIT = 3 2, /* Overcurrent timeout max */
+ FET_CTRL_ADENFET= 1 1, /* Enable output auto discharge */
+ FET_CTRL_ENFET = 1 0, /* Enable FET */
+};
+
+/**
+ * tps65090_read - read a byte from tps6090
+ *
+ * @param reg The register address to read from.
+ * @param val We'll return value value read here.
+ * @return 0 if ok; error if EC returns failure.
+ */
+static int tps65090_read(u32 reg, u8 *val)
+{
+ return cros_ec_i2c_xfer(config.dev, TPS65090_ADDR, reg, 1,
+ val, 1, true);
+}
+
+/**
+ * tps65090_write - write a byte to tps6090
+ *
+ * @param reg The register address to write to.
+ * @param val The value to write.
+ * @return 0 if ok; error if EC returns failure.
+ */
+static int tps65090_write(u32 reg, u8 val)
+{
+ return cros_ec_i2c_xfer(config.dev, TPS65090_ADDR, reg, 1,
+ val, 1, false);
+}
+
+/**
+ * Checks for a valid FET number
+ *
+ * @param fet_id FET number to check
+ * @return 0 if ok, -1 if FET value is out of range
+ */
+static int tps65090_check_fet(unsigned int fet_id)
+{
+ if (fet_id == 0 || fet_id MAX_FET_NUM) {
+ debug(parameter fet_id is out of range, %u not in 1 ~ %u\n,
+ fet_id, MAX_FET_NUM);
+ return -1;
+ }
+
+ return 0;
+}
+
+/**
+ * Set the power state for a FET
+ *
+ * @param fet_id Fet number to set (1..MAX_FET_NUM)
+ * @param set 1 to power on FET, 0 to power off
+ * @return FET_ERR_COMMS if we got a comms error, FET_ERR_NOT_READY if the
+ * FET failed to change state. If all is ok, returns 0.
+ */
+static int tps65090_fet_set(int fet_id, int set)
+{
+ int retry;
+ u8 reg = 0, value;
+
+ value = FET_CTRL_ADENFET | FET_CTRL_WAIT;
+ if (set)
+ value |= FET_CTRL_ENFET;
+
+ if (tps65090_write(REG_FET1_CTRL + fet_id - 1, value))
+ return FET_ERR_COMMS;
+ /* Try reading until we get a result */
+ for (retry = 0; retry MAX_CTRL_READ_TRIES; retry++) {
+ if (tps65090_read(REG_FET1_CTRL + fet_id - 1, reg))
+ return FET_ERR_COMMS;
+
+ /* Check that the fet went into the expected state */
+ if (!!(reg FET_CTRL_PGFET) == set)
+ return 0;
+
+
[U-Boot] [PATCH 4/6] exynos5: Enable data cashe
Things run faster when the data cache is enabled, so turn it on along with the 'dcache' command. Signed-off-by: Simon Glass s...@chromium.org --- include/configs/exynos5-dt.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/exynos5-dt.h b/include/configs/exynos5-dt.h index e36a031..4e316b9 100644 --- a/include/configs/exynos5-dt.h +++ b/include/configs/exynos5-dt.h @@ -37,8 +37,8 @@ #define CONFIG_TRACE_EARLY_ADDR0x5000 /* Keep L2 Cache Disabled */ -#define CONFIG_SYS_DCACHE_OFF #define CONFIG_SYS_CACHELINE_SIZE 64 +#define CONFIG_CMD_CACHE /* Enable ACE acceleration for SHA1 and SHA256 */ #define CONFIG_EXYNOS_ACE_SHA -- 2.0.0.526.g5318336 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/6] cros_ec: exynos: Use the correct tps65090 driver in each case
Exynos 5250 boards (snow, spring) use the I2C driver but Exynos 5420 boards
cannot due to a hardware design decision. Select out the correct driver to
use in each case.
Signed-off-by: Simon Glass s...@chromium.org
---
board/samsung/common/board.c| 6 ++
drivers/power/pmic/Makefile | 2 +-
include/configs/exynos5250-dt.h | 1 +
include/configs/peach-pit.h | 2 ++
include/configs/smdk5420.h | 2 ++
5 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index 9dc7c83..108c82b 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -21,6 +21,7 @@
#include asm/arch/pinmux.h
#include asm/arch/power.h
#include power/pmic.h
+#include power/tps65090_pmic.h
#include asm/arch/sromc.h
#include lcd.h
#include samsung/misc.h
@@ -157,6 +158,11 @@ int power_init_board(void)
{
set_ps_hold_ctrl();
+#ifdef CONFIG_POWER_TPS65090
+ tps65090_fet_enable(1); /* Enable FET1, backlight */
+ tps65090_fet_enable(6); /* Enable FET6, lcd panel */
+#endif
+
return exynos_power_init();
}
#endif
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index 0b76611..e7b07eb 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -11,7 +11,7 @@ obj-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
obj-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
obj-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
obj-$(CONFIG_POWER_PFUZE100) += pmic_pfuze100.o
-obj-$(CONFIG_POWER_TPS65090) += pmic_tps65090.o
+obj-$(CONFIG_POWER_TPS65090_I2C) += pmic_tps65090.o
obj-$(CONFIG_POWER_TPS65090_EC) += pmic_tps65090_ec.o
obj-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
obj-$(CONFIG_POWER_TPS65218) += pmic_tps65218.o
diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h
index 74e72a5..2c0df29 100644
--- a/include/configs/exynos5250-dt.h
+++ b/include/configs/exynos5250-dt.h
@@ -42,6 +42,7 @@
/* PMIC */
#define CONFIG_POWER_MAX77686
+#define CONFIG_POWER_TPS65090_I2C
/* Sound */
#define CONFIG_CMD_SOUND
diff --git a/include/configs/peach-pit.h b/include/configs/peach-pit.h
index 76b8d7a..41ccd10 100644
--- a/include/configs/peach-pit.h
+++ b/include/configs/peach-pit.h
@@ -22,4 +22,6 @@
#define CONFIG_SYS_PROMPT Peach #
#define CONFIG_IDENT_STRING for Peach
+#define CONFIG_POWER_TPS65090_EC
+
#endif /* __CONFIG_PEACH_PIT_H */
diff --git a/include/configs/smdk5420.h b/include/configs/smdk5420.h
index 606739b..39d235c 100644
--- a/include/configs/smdk5420.h
+++ b/include/configs/smdk5420.h
@@ -24,4 +24,6 @@
#define CONFIG_SYS_PROMPT SMDK5420 #
#define CONFIG_IDENT_STRING for SMDK5420
+#define CONFIG_POWER_TPS65090_EC
+
#endif /* __CONFIG_SMDK5420_H */
--
2.0.0.526.g5318336
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/10] sunxi: Bug fixes, sun4i and sun5i support and network improvements
On Mon, Jul 07, 2014 at 04:10:42PM +0100, Ian Campbell wrote: On Mon, 2014-07-07 at 14:50 +0200, Hans de Goede wrote: AFAIK we will never define both EMAC and GMAC for the same board, If we are sure of this (and I suspect this is the case, since IIRC they share some pins) then I agree with your suggestion. so IMHO a better fix would be to change this line: rc = sunxi_emac_initialize(bis); to: int rc = sunxi_emac_initialize(bis); That's not how we like things to look however when we can help it. Just toss a __maybe_unused in front of the declaration (and make sure we have linux/compiler.h included. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] mtdcore: Fix a build error with CONFIG_CMD_MTDPARTS_SPREAD
This patch fixes the build error for CONFIG_CMD_MTDPARTS_SPREAD
introduced by the commit:
commit dfe64e2c89731a3f9950d7acd8681b68df2bae03
Author: Sergey Lapin slapin at ossfans.org
Date: Mon Jan 14 03:46:50 2013 +
mtd: resync with Linux-3.7.1
v2 changes:
Rebased the patch against Heiko's code base:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/189358
So,Heiko's update should be applied first.
Signed-off-by: Maxin B. John maxin.j...@enea.com
---
drivers/mtd/mtdcore.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 796ac07..3596b06 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -802,7 +802,7 @@ void mtd_get_len_incl_bad(struct mtd_info *mtd, uint64_t
offset,
*truncated = 0;
*len_incl_bad = 0;
- if (!mtd-block_isbad) {
+ if (!mtd-_block_isbad) {
*len_incl_bad = length;
return;
}
@@ -818,7 +818,7 @@ void mtd_get_len_incl_bad(struct mtd_info *mtd, uint64_t
offset,
block_len = mtd-erasesize - (offset (mtd-erasesize - 1));
- if (!mtd-block_isbad(mtd, offset ~(mtd-erasesize - 1)))
+ if (!mtd-_block_isbad(mtd, offset ~(mtd-erasesize - 1)))
len_excl_bad += block_len;
*len_incl_bad += block_len;
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/3] mtd, ubi, ubifs: resync with Linux-3.14
Dear Tom, In message 20140707161204.GM29202@bill-the-cat you wrote: You can either fetch the Linux tree into your local U-Boot repo (or vice versa) so that git diff can compare them, or you can check out separate repositories to the proper tags/SHAs and use ordinary diff. It's not something that I'd expect one to want to do very often, though. Usually you want to know how things work in the codebase you're working on, or you want to compare some specific aspect of the code which can more easily be done manually. So an example of this would be doing say: $ git diff 3dad234 drivers/mtd/nand/nand_base.c Yes - but this works only on a per-file or per-directory base. As I mentioned before, the code is scattered over a number of directories (and I'm not even sure that we don't have any renames to deal with). Where 3dad234 is the last kernel commit to U-Boot drivers/mtd/nand/nand_base.c where we synced right (and we've fetched the kernel sources into this repo as well) ? (This commit is also valid for atmel_nand.c and I looked over the results there too..). As Heiko explains in his posting, his patches are agains kernel tag v3.14 = commit ID 455c6fd We must, really, follow the general rule where when we sync stuff from the kernel we say what the commit we synced with is, for UBI/etc. We may not have been for forever but the last time we also said that tag it was against. Heiko included this information in his posting. In sum, if Heiko is going to be owning UBI/related code and syncs, whatever makes life easiest on _him_ to make sure we don't have regressions is fine with me (within reason, and this seems to be within reason). Do not get me wrong please, I appreciate all the time you've spent thus far in U-Boot and wish and want you to comment / review / advise as you're still able to find time. But if someone else is taking up doing the re-syncs it needs to also fit their workflow. Thanks. Well, officially UBI is in the responsibility of Kyungmin Park (though Stefan Roese did a major part of that work, too), and MTD is something we haven't defined yet. But I think Heiko will watch over this area and care about any upcoing issues related to this update at least for the next weeks and months... 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 best things in life are for a fee. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/4] mx6: Add support for the mx6solox variant
On Mon, Jul 7, 2014 at 11:18 AM, Fabio Estevam feste...@gmail.com wrote: On Thu, Jul 3, 2014 at 3:22 PM, Fabio Estevam feste...@gmail.com wrote: On Thu, Jul 3, 2014 at 4:15 AM, Stefano Babic sba...@denx.de wrote: I have only taken a short look because the series should flow after 2014.07. Anyway, I could push them into -next. Pushing them into -next would be very helpful, so that we can continue on adding new support for mx6solox. Would it be possible to review the initial series that adds mx6solox support and apply it to -next if you are happy with it? Otherwise, I am not able to proceed with further mx6solox U-boot upstream work. I second this request. I see no reason why patches takes so long to get applied in master/next when people agree with them. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] usb: phy: omap_usb_phy: implement usb_phy_power() for AM437x
On Monday, July 07, 2014 at 06:14:23 PM, Felipe Balbi wrote: hi, On Mon, Jun 23, 2014 at 05:18:24PM -0500, Felipe Balbi wrote: Newer AM437x silicon requires us to explicitly power up the USB2 PHY. By implementing usb_phy_power() we can achieve that. Signed-off-by: Felipe Balbi ba...@ti.com --- Changes since v1: - add macros for USB1_CTRL register and bits same here. Still pending, am437x will remain broken until this is applied. What do you need for .07, this and 1/2 of this series ? Or did I miss something else? In any case, sorry, will apply them once I know which ones. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/3] mtd, ubi, ubifs: resync with Linux-3.14
On Mon, 2014-07-07 at 12:12 -0400, Tom Rini wrote: On Mon, Jun 30, 2014 at 06:09:53PM -0500, Scott Wood wrote: The unmodified source is in the Linux tree -- most likely in a more accurate/complete form than the ifdefs convey, since minor differences and subsequent local changes are unlikely to be marked. You can either fetch the Linux tree into your local U-Boot repo (or vice versa) so that git diff can compare them, or you can check out separate repositories to the proper tags/SHAs and use ordinary diff. It's not something that I'd expect one to want to do very often, though. Usually you want to know how things work in the codebase you're working on, or you want to compare some specific aspect of the code which can more easily be done manually. So an example of this would be doing say: $ git diff 3dad234 drivers/mtd/nand/nand_base.c Where 3dad234 is the last kernel commit to U-Boot drivers/mtd/nand/nand_base.c where we synced right (and we've fetched the kernel sources into this repo as well) ? 3dad234 was a cherry-pick, not a sync. The last sync was v3.7.1. To see the differences as of the last sync, do this: git diff cc8605070 dfe64e2c drivers/mtd/nand/nand_base.c (This commit is also valid for atmel_nand.c and I looked over the results there too..). We must, really, follow the general rule where when we sync stuff from the kernel we say what the commit we synced with is, for UBI/etc. We may not have been for forever but the last time we also said that tag it was against. Yes. Unfortunately this can create misleading commit messages when some files are synced to a Linux SHA, and other files are merely touched to avoid resulting breakage. That SHA should be valid for core nand files, but probably not for most drivers. I don't think we've ever done centralized syncing of nand drivers. Future merge commits should be more explicit about which files were synced. But how we denote U-Boot vs Linux Kernel differences is somewhat up to the subsystem maintainer. We must be careful when syncing back. But looking over the above diff, as a more casual nand developer, I wish there was more in-code context about why we are different. But that's just me and how I develop. It would be pretty easy (but not quite easily scriptable) to whack out the #ifndef/else/endif __UBOOT__'s, commit that, and be back to having the output one wants, if that's how one works. FWIW, back when the nand code had such ifdefs, there was rarely any explanation for the difference -- it was just a statement that a difference existed. Nor could I trust that all of the differences were documented that way, or that the code in ifndef sections was kept up to date. Beyond readability and usefulness, my concern is that the ifndef code will cause mismerges in the future, if the if/else section is large enough that git doesn't flag it as a conflict, and thus needed changes don't get applied to the U-Boot side of the if/else. In sum, if Heiko is going to be owning UBI/related code and syncs, whatever makes life easiest on _him_ to make sure we don't have regressions is fine with me (within reason, and this seems to be within reason). Do not get me wrong please, I appreciate all the time you've spent thus far in U-Boot and wish and want you to comment / review / advise as you're still able to find time. But if someone else is taking up doing the re-syncs it needs to also fit their workflow. Yes, of course. For code outside drivers/mtd/nand, I'm just providing advice, based on what I felt did and did not work well in the nand code. That goes for nand as well if and when someone actually takes over the custodian role -- I said as much earlier in this discussion. If that helps motivate Heiko or someone else to formally take over the role sooner rather than later, then great. :-) In the absence of a change in custodianship, my experience has been that a different person ends up submitting a sync each time. I would have also done an occasional sync myself if someone requested one based on missing important changes, but usually people have shown up with patches instead. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/10] sunxi: Bug fixes, sun4i and sun5i support and network improvements
On Mon, 2014-07-07 at 12:47 -0400, Tom Rini wrote:
That's not how we like things to look however when we can help it. Just
toss a __maybe_unused in front of the declaration (and make sure we have
linux/compiler.h included.
OK. How about the following?
Hans, BTW, I spotted this issue with:
CROSS_COMPILE=arm-linux-gnueabihf- ./MAKEALL -s sunxi
which is a very useful invocation indeed!
8---
From 5e0659b772380114a9e86624aefd1dcb09a90bd9 Mon Sep 17 00:00:00 2001
From: Ian Campbell i...@hellion.org.uk
Date: Sun, 6 Jul 2014 20:03:20 +0100
Subject: [PATCH] sunxi: Avoid unused variable warning.
Mark rc as __maybe_unused since it is infact unused on systems with neither
EMAC nor GMAC.
Signed-off-by: Ian Campbell i...@hellion.org.uk
---
arch/arm/cpu/armv7/sunxi/board.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c
index 1e506b5..538ffa7 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -24,6 +24,8 @@
#include asm/arch/sys_proto.h
#include asm/arch/timer.h
+#include linux/compiler.h
+
#ifdef CONFIG_SPL_BUILD
/* Pointer to the global data structure for SPL */
DECLARE_GLOBAL_DATA_PTR;
@@ -115,7 +117,7 @@ void enable_caches(void)
*/
int cpu_eth_init(bd_t *bis)
{
- int rc;
+ __maybe_unused int rc;
#ifdef CONFIG_SUNXI_EMAC
rc = sunxi_emac_initialize(bis);
--
1.9.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/10] sunxi: Bug fixes, sun4i and sun5i support and network improvements
On Mon, Jul 07, 2014 at 09:23:13PM +0100, Ian Campbell wrote: On Mon, 2014-07-07 at 12:47 -0400, Tom Rini wrote: That's not how we like things to look however when we can help it. Just toss a __maybe_unused in front of the declaration (and make sure we have linux/compiler.h included. OK. How about the following? Hans, BTW, I spotted this issue with: CROSS_COMPILE=arm-linux-gnueabihf- ./MAKEALL -s sunxi which is a very useful invocation indeed! FWIW, you might want to run -a arm from time to time since there's some shared drivers between sunxi and others. From 5e0659b772380114a9e86624aefd1dcb09a90bd9 Mon Sep 17 00:00:00 2001 From: Ian Campbell i...@hellion.org.uk Date: Sun, 6 Jul 2014 20:03:20 +0100 Subject: [PATCH] sunxi: Avoid unused variable warning. Mark rc as __maybe_unused since it is infact unused on systems with neither EMAC nor GMAC. Signed-off-by: Ian Campbell i...@hellion.org.uk Acked-by: Tom Rini tr...@ti.com Thanks. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [i2c] Pull request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [Mailing list was missing from the PR On 07/07/2014 09:20 AM, Heiko Schocher wrote: Hello Tom, please pull from u-boot-i2c.git The following changes since commit fe8b3212b7938861eacdefe6115810303a96f9cc: Merge branch 'master' of git://git.denx.de/u-boot-arm (2014-07-02 16:38:02 -0400) are available in the git repository at: git://git.denx.de/u-boot-i2c.git master for you to fetch changes up to ad3091ad03e39f88c0bcc566c7a691c4475e2c40: i2c: tegra: dump alen in debug statements (2014-07-03 06:29:39 +0200) Stephen Warren (3): i2c: tegra: use repeated start for reads i2c: tegra: write clean data to TX FIFO i2c: tegra: dump alen in debug statements arch/arm/include/asm/arch-tegra/tegra_i2c.h | 2 ++ drivers/i2c/tegra_i2c.c | 44 +++- 2 files changed, 29 insertions(+), 17 deletions(-) Applied to u-boot/master, thanks! - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTuwpeAAoJENk4IS6UOR1WPnUP/jUOf/RzPt51Q3rMbGut4gg8 NUfeyXIwVDTD5EdMW4cAqvO84Sgp4xPzLIwFWhOOVyHaK/+DEpx1knOLCnf7Zxia JB6t8Z1oRtiHQNizEqSLwE4UPYiMrXxBjlQ+5xKvqgYpMeYz86ZcJtv9GrWxF2N6 mCo4wYqlQWJR1e9ChSs2cK75e1A1EEpEUVb5vSENGp6HzYZjOS4V1iSPoiAaOuUG jE07/XoNrAkASEaRlg+a8O97EWgX3r27ENqmLJh5p4F+DDmyM1++FooX9a+Daq1+ zJ2DF07SS5fF5pl6O869K9EVH2P+zAUkeAuriAZwRrzc2hBIXLJbkoYj/AVx9+rC nNADzb1LPSmCkUlN2S70vMsYtwT8WLiuAgLFJtVGCBjIQc5x0UxVzkAX4Qaqajo6 FFycDiPsYdwE0TSXn0riZd5cV65y1q8LNSOaY31jEgqs8V+roUcbiqryW8sFaLdo XGmKJal0G6tZj2LEFMZBMxY2lFKdwwNd4dA6U87r5jZmVZTqYpjp8v9hWNYylLVI VNjGwAcA+FLKcmCq6dk/a31QF74KgE6urVRDNAbkeZ8gRDoqhCTbXKZNZ2hmGRr8 d4qTHPGVFmSKt1hl5JwDkNGJP4SSVr/VSDEMMfUhmwiNaY0gE4s18iKtnfDJpaic /2FZwNKZrRrSmk1/45Ca =NBP8 -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL with NAND: programming addresses
On Thu, 2014-06-26 at 02:25 -0600, Danny Gale wrote: Hello everybody, We're trying to boot a custom board loosely based on the T4240QDS. We have the T4240 coming up and getting its RCW / PBL from a SPI EEPROM, and it reads 8 KB of program from NAND flash into SRAM, then dies. The T4240QDS_NAND target assumes that the PBL comes from NAND, not SPI EEPROM, and relies on the PBL to load the SPL into SRAM. The method you describe may be possible -- it's similar to how NAND boot was done prior to PBL -- but it will need some development work. I think we just don't have things in the right places. I'm a little confused and have a couple of questions on addresses and what goes where: 1. The SPL image itself should go at address 0 in the NAND flash, correct? That's where our PowerPC will start to look for it. The PBL-encoded SPL image should go at address 0 in NAND flash. 2. The u-boot.bin image should be programmed to CONFIG_SYS_NAND_U_BOOT_OFFS in the NAND flash, right? (pretty sure this is true -- just sanity-checking myself here) Yes. 3. How does CONFIG_SYS_TEXT_BASE relate to CONFIG_SYS_NAND_U_BOOT_DST and CONFIG_SYS_NAND_U_BOOT_START? Why aren't all three of these the same? They're related, but not necessarily the same. START can be greater than DST if the payload is not block-aligned (e.g. on mpc8313erdb) and/or if the image contains a non-executable header. TEXT_BASE can be greater than START because it is the address of the beginning of the text section, which may not be the first executable section in the image. On e500 nand boot, the bootpg section comes first. 4. What are RESET_VECTOR_OFFSET and BOOT_PAGE_OFFSET? RESET_VECTOR_OFFSET is the offset into the SPL image of the reset vector, and BOOT_PAGE_OFFSET is the offset at which the bootpg section should be linked. I've CCed Shaohui Xie who may be able to say more about how it works in PBL boot scenarios. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] buildman: fix toolchain priority_list
On 6 July 2014 18:47, Masahiro Yamada yamad...@jp.panasonic.com wrote: '-elf' appears twice in the toolchain priority_list. The second one is rudundant. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Simon Glass s...@chromium.org Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] buildman: fix to display warning message for missing [toolchain] section
On 6 July 2014 18:46, Masahiro Yamada yamad...@jp.panasonic.com wrote: Toolchains.__init__ is expected to display a warning message when the [toolchain] section is missing from ~/.buildman file. But it never works. In that case, instead, buildmain fails with an error message which is difficult to understand: Traceback (most recent call last): File tools/buildman/buildman, line 126, in module control.DoBuildman(options, args) File /home/foo/u-boot/tools/buildman/control.py, line 78, in DoBuildman toolchains = toolchain.Toolchains() File /home/foo/u-boot/tools/buildman/toolchain.py, line 106, in __init__ config_fname) NameError: global name 'config_fname' is not defined Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Simon Glass s...@chromium.org Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cosmetic: doc: update README.generic-board
On 7 July 2014 05:08, Masahiro Yamada yamad...@jp.panasonic.com wrote: Now MIPS supports 'generic board' feature. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Simon Glass s...@chromium.org Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC 1/3] spi:fsl_spi:Add compatibility for fsl-qspi and fsl-dspi modules driver
Hi, On 1 July 2014 03:18, Chao Fu b44...@freescale.com wrote: From: Chao Fu b44...@freescale.com Freescale has some series of chips(e.g. vf610) contain two kinds of SPI modules, DSPI and QSPI. U-boot spi current code can't compile and enable the two modules at same time. So add fsl-spi-interface make two spi driver code work together. We are in the process of enabling driver model for SPI and SPI flash. Work in progress is at u-boot-dm.git branch 'working'. It probably makes sense to build on that rather than introduce new infrastructure. Please let me know what you think. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] build: define CPU only when arch/${ARCH}/cpu/${CPU} exists
Hi Masahiro,
On 24 June 2014 07:10, Masahiro Yamada yamad...@jp.panasonic.com wrote:
The directory arch/${ARCH}/cpu/${CPU} does not exist
in avr32, blackfin, microblaze, nios2, openrisc, sandbox, x86.
These architectures have only one CPU type.
Defining CPU should not be required for such architectures.
This commit allows cpu field (= the 3rd field of boards.cfg)
to be kept blank.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Andreas Bießmann andreas.de...@googlemail.com
Cc: Simon Glass s...@chromium.org
Cc: Sonic Zhang sonic.zh...@analog.com
Cc: Michal Simek michal.si...@xilinx.com
Cc: Thomas Chou tho...@wytron.com.tw
Cc: Stefan Kristiansson stefan.kristians...@saunalahti.fi
Acked-by: Simon Glass s...@chromium.org
But see question below.
diff --git a/mkconfig b/mkconfig
index 2bf5897..401f262 100755
--- a/mkconfig
+++ b/mkconfig
@@ -55,6 +55,11 @@ CONFIG_NAME=${7%_config}
arch=$2
cpu=`echo $3 | awk 'BEGIN {FS = :} ; {print $1}'`
spl_cpu=`echo $3 | awk 'BEGIN {FS = :} ; {print $2}'`
+
+if [ $cpu = - ] ; then
+ cpu=
+fi
+
if [ $6 = none ] ; then
board=
elif [ $6 = - ] ; then
@@ -114,10 +119,10 @@ fi
rm -f asm/arch
-if [ -z ${soc} ] ; then
- ln -s ${LNPREFIX}arch-${cpu} asm/arch
-else
+if [ ${soc} ] ; then
Will this work OK in dash? (or non-bash)
ln -s ${LNPREFIX}arch-${soc} asm/arch
+elif [ ${cpu} ] ; then
+ ln -s ${LNPREFIX}arch-${cpu} asm/arch
fi
if [ -z $KBUILD_SRC ] ; then
--
1.9.1
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC 0/2] usb: host: Add a wrapper layer for mutiple host support
Hi, On 26 June 2014 03:21, Marek Vasut ma...@denx.de wrote: On Thursday, June 26, 2014 at 06:46:11 AM, Vivek Gautam wrote: Hi Simon, Marek, On Thu, Jun 26, 2014 at 10:04 AM, Vivek Gautam gautam.vi...@samsung.com wrote: sorry for spamming, the earlier message got sent by mistake. On Thu, Jun 26, 2014 at 8:00 AM, Simon Glass s...@chromium.org wrote: Hi Marek, On 25 June 2014 02:33, Marek Vasut ma...@denx.de wrote: On Wednesday, June 25, 2014 at 08:27:39 AM, Simon Glass wrote: [...] model. Instead, I'd love to see a mean to instantiate each *HCI controller and have a USB core which would track those instances. The USB core would then be able to call whatever generic ops on those instances as needed. Does that make sense please ? True, i understand your point here. I think the second approach i was talking of, goes in this direction. I think i could not put it well in words there. I will prepare an RFC patch for that, and post it as soon as its ready, so that you can have a look. Ah, this would be so very appreciated! Thank you! Should we consider just going straight for driver model? I was thinking about that, but I'm worried it might break USB support on some platforms. Also, the size of U-Boot will grow on many platforms, right? What do you think ? If you add CONFIG_DM_USB as an option, you can then pull in either usb-uclass.c or the old usb code. Since USB is often tied to a board then you can move just that board (or group of boards) to dm. I am keeping a working tree in u-boot-dm.git which does this for serial, SPI, SPI flash and GPIO. It seems to work fairly well as a technique for keeping both things in the tree in the interim.. Ok, so i am having a look at the u-boot-dm tree, and also going through the documentation for driver-model. The driver-model looks a promising choice at the moment keeping in mind that later we would need to move to it anyways. I will try understanding the things and raise a flag in case something is not clear. Even better, if I don't have to do this myself :) I'm really glad to see how many people put effort into the USB and how things are coming together nicely. Thank you guys! Please note I have updated the 'working' branch. A parent device (such as a SPI bus or USB bus) can now have private data for each of its children. This was useful for SPI and may be useful for USB. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] m68k: Fix warnings with gcc 4.6
Hi Jason, On 24 June 2014 07:06, jason@freescale.com jason@freescale.com wrote: [snip] -Original Message- From: Tom Rini [mailto:tom.r...@gmail.com] On Behalf Of Tom Rini Well, lets cycle back and see if we can get some answers, before we need to start taking some more drastic action perhaps. Jason, is there a toolchain for which MAKEALL -a m68k works? If not, do we need to start removing some no longer used / maintained boards? Thanks! It's not relate to the used or no longer used boards. For ColdFire with MMU and non-MMU part, we need two different toolchain, so currently we cannot use MAKEALL -a m68k to build all the ColdFire boards. Thanks. Jason Thank seems a bit unfortunate. I wonder if there is a way to distinguish the two boards from their boards.cfg entry? We could perhaps add a feature to buildman to support building the same arch with two different toolchains if that is what it takes? Also, can you please send a link so I can download the two toolchains? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/9] Add a pre-relocation malloc() implementation
There has been talk on and off of a pre-relocation malloc() implementation. Driver model needs this so that it can work before relocation. A previous implementation was sent in a v1 series. This implementation works by allocating space on the stack. The benefit is that boards do not need to specify the address of the malloc() area, only the size. The down-side is that due to the way board_init_f() is called, architecture-specific code needs to be used to allocate the space. No clever algorithms are used to allocate space, free() is a nop and realloc() is not supported. This fits well with the desire to avoid wasting space on bucket tables and the hassle of supporting BSS data before relocation. We don't expect 'churn' in the pre-relocation case - we just want to allocate small amounts of memory temporarily. After relocation a new malloc() pool is created and the old one is lost, although pointers into it will survive the immediate process of relocation. Implementations are provided for sandbox and arm. A related change is made to the early init for each arch to make this work. Changes in v2: - Tidy up commit message typo Simon Glass (9): Remove form-feeds from dlmalloc.c arm: Set up global data before board_init_f() sandbox: Set up global data before board_init_f() Add a simple malloc() implementation for pre-relocation arm: Support pre-relocation malloc() exynos: Enable pre-relocation malloc() sandbox: Support pre-relocation malloc() sandbox: config: Enable pre-relocation malloc() sandbox: Always enable malloc debug README| 16 arch/arm/include/asm/config.h | 2 - arch/arm/lib/crt0.S | 11 + arch/sandbox/cpu/start.c | 8 arch/sandbox/include/asm/config.h | 1 - common/board_f.c | 12 ++ common/board_r.c | 4 ++ common/dlmalloc.c | 85 --- include/asm-generic/global_data.h | 5 +++ include/configs/exynos5-dt.h | 4 +- include/configs/sandbox.h | 5 ++- lib/asm-offsets.c | 3 ++ 12 files changed, 127 insertions(+), 29 deletions(-) -- 2.0.0.526.g5318336 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/9] Remove form-feeds from dlmalloc.c
These don't really serve any purpose in the modern age. On the other hand they show up as annoying control characters in my editor, which then happily removes them. I believe we can drop these characters from the file. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: - Tidy up commit message typo common/dlmalloc.c | 46 +++--- 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/common/dlmalloc.c b/common/dlmalloc.c index 3c70d5d..d1cd561 100644 --- a/common/dlmalloc.c +++ b/common/dlmalloc.c @@ -220,7 +220,7 @@ */ - + /* Preliminaries */ @@ -1132,7 +1132,7 @@ gAllocatedSize)) #endif - + /* Type declarations @@ -1272,7 +1272,7 @@ nextchunk- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ serviced via calls to mmap, and then later released via munmap. */ - + /* sizes, alignments */ #define SIZE_SZ(sizeof(INTERNAL_SIZE_T)) @@ -1297,7 +1297,7 @@ nextchunk- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ #define aligned_OK(m)(((unsigned long)((m)) (MALLOC_ALIGN_MASK)) == 0) - + /* Physical chunk operations @@ -1332,7 +1332,7 @@ nextchunk- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ #define chunk_at_offset(p, s) ((mchunkptr)(((char*)(p)) + (s))) - + /* Dealing with use bits @@ -1371,7 +1371,7 @@ nextchunk- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (((mchunkptr)(((char*)(p)) + (s)))-size = ~(PREV_INUSE)) - + /* Dealing with size fields @@ -1394,7 +1394,7 @@ nextchunk- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ #define set_foot(p, s) (((mchunkptr)((char*)(p) + (s)))-prev_size = (s)) - + /* @@ -1566,7 +1566,7 @@ void mem_malloc_init(ulong start, ulong size) #define is_small_request(nb) (nb MAX_SMALLBIN_SIZE - SMALLBIN_WIDTH) - + /* To help compensate for the large number of bins, a one-level index @@ -1590,7 +1590,7 @@ void mem_malloc_init(ulong start, ulong size) #define clear_binblock(ii) (binblocks_w = (mbinptr)(binblocks_r ~(idx2binblock(ii - + /* Other static bookkeeping data */ @@ -1628,7 +1628,7 @@ static unsigned int max_n_mmaps = 0; static unsigned long max_mmapped_mem = 0; #endif - + /* Debugging support @@ -1769,7 +1769,7 @@ static void do_check_malloced_chunk(p, s) mchunkptr p; INTERNAL_SIZE_T s; #define check_malloced_chunk(P,N) #endif - + /* Macro-based internal utilities @@ -1841,7 +1841,7 @@ static void do_check_malloced_chunk(p, s) mchunkptr p; INTERNAL_SIZE_T s; (last_remainder-fd = last_remainder-bk = last_remainder) - + /* Routines dealing with mmap(). */ @@ -1972,7 +1972,7 @@ static mchunkptr mremap_chunk(p, new_size) mchunkptr p; size_t new_size; #endif /* HAVE_MMAP */ - + /* Extend the top-most chunk by obtaining memory from system. @@ -2089,7 +2089,7 @@ static void malloc_extend_top(nb) INTERNAL_SIZE_T nb; } - + /* Main public routines */ @@ -2396,7 +2396,7 @@ Void_t* mALLOc(bytes) size_t bytes; } - + /* @@ -2513,7 +2513,7 @@ void fREe(mem) Void_t* mem; } - + /* @@ -2750,7 +2750,7 @@ Void_t* rEALLOc(oldmem, bytes) Void_t* oldmem; size_t bytes; } - + /* @@ -2868,7 +2868,7 @@ Void_t* mEMALIGn(alignment, bytes) size_t alignment; size_t bytes; } - + /* @@ -2975,7 +2975,7 @@ void cfree(mem) Void_t *mem; } #endif - + /* @@ -3056,7 +3056,7 @@ int malloc_trim(pad) size_t pad; } } - + /* malloc_usable_size: @@ -3092,7 +3092,7 @@ size_t malloc_usable_size(mem) Void_t* mem; } - + /* Utility to update current_mallinfo for malloc_stats and mallinfo() */ @@ -3136,7 +3136,7 @@ static void malloc_update_mallinfo() } #endif /* DEBUG */ - + /* @@ -3183,7 +3183,7 @@ struct mallinfo mALLINFo() #endif /* DEBUG */ - + /* mallopt: -- 2.0.0.526.g5318336 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/9] sandbox: Set up global data before board_init_f()
At present sandbox defines CONFIG_SYS_GENERIC_GLOBAL_DATA, meaning that
the global_data pointer is set up in board_init_f().
If we set up and zero the global data before calling board_init_f() then we
don't need to define CONFIG_SYS_GENERIC_GLOBAL_DATA.
Make this change to simplify the init process.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2: None
arch/sandbox/cpu/start.c | 5 +
arch/sandbox/include/asm/config.h | 1 -
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/sandbox/cpu/start.c b/arch/sandbox/cpu/start.c
index aad3b8b..5289291 100644
--- a/arch/sandbox/cpu/start.c
+++ b/arch/sandbox/cpu/start.c
@@ -6,6 +6,7 @@
#include common.h
#include os.h
#include asm/getopt.h
+#include asm/io.h
#include asm/sections.h
#include asm/state.h
@@ -218,6 +219,7 @@ SANDBOX_CMDLINE_OPT_SHORT(terminal, 't', 1,
int main(int argc, char *argv[])
{
struct sandbox_state *state;
+ gd_t data;
int ret;
ret = state_init();
@@ -236,6 +238,9 @@ int main(int argc, char *argv[])
if (state-ram_buf_rm state-ram_buf_fname)
os_unlink(state-ram_buf_fname);
+ memset(data, '\0', sizeof(data));
+ gd = data;
+
/* Do pre- and post-relocation init */
board_init_f(0);
diff --git a/arch/sandbox/include/asm/config.h
b/arch/sandbox/include/asm/config.h
index 6c1bff9..ec7729e 100644
--- a/arch/sandbox/include/asm/config.h
+++ b/arch/sandbox/include/asm/config.h
@@ -7,7 +7,6 @@
#ifndef _ASM_CONFIG_H_
#define _ASM_CONFIG_H_
-#define CONFIG_SYS_GENERIC_GLOBAL_DATA
#define CONFIG_SANDBOX_ARCH
/* Used by drivers/spi/sandbox_spi.c and arch/sandbox/include/asm/state.h */
--
2.0.0.526.g5318336
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 5/9] arm: Support pre-relocation malloc()
Add support for re-relocation malloc() in arm's start-up code. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None README | 3 +++ arch/arm/lib/crt0.S | 4 2 files changed, 7 insertions(+) diff --git a/README b/README index 7450750..46f8f3c 100644 --- a/README +++ b/README @@ -3729,6 +3729,9 @@ Configuration Settings: The memory will be freed (or in fact just forgotton) when U-Boot relocates itself. + Pre-relocation malloc() is only supported on ARM at present + but is fairly easy to enable for other archs. + - CONFIG_SYS_BOOTM_LEN: Normally compressed uImages are limited to an uncompressed size of 8 MBytes. If this is not enough, diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S index bbf3e41..9e81cd9 100644 --- a/arch/arm/lib/crt0.S +++ b/arch/arm/lib/crt0.S @@ -77,6 +77,10 @@ clr_gd: cmp r1, r2 /* while not at end of BSS */ strlo r0, [r1]/* clear 32-bit BSS word */ addlo r1, r1, #4 /* move to next */ blo clr_gd +#if defined(CONFIG_SYS_MALLOC_F_LEN) !defined(CONFIG_SPL_BUILD) + sub sp, sp, #CONFIG_SYS_MALLOC_F_LEN + str sp, [r9, #GD_MALLOC_BASE] +#endif mov r0, #0 bl board_init_f -- 2.0.0.526.g5318336 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/9] Add a simple malloc() implementation for pre-relocation
If we are to have driver model before relocation we need to support some
way of calling memory allocation routines.
The standard malloc() is pretty complicated:
1. It uses some BSS memory for its state, and BSS is not available before
relocation
2. It supports algorithms for reducing memory fragmentation and improving
performace of free(). Before relocation we could happily just not support
free().
3. It includes about 4KB of code (Thumb 2) and 1KB of data. However since
this has been loaded anyway this is not really a problem.
The simplest way to support pre-relocation malloc() is to reserve an area
of memory and allocate it in increasing blocks as needed. This
implementation does this.
To enable it, you need to define the size of the malloc() pool as described
in the README. It will be located above the pre-relocation stack on
supported architectures.
Note that this implementation is only useful on machines which have some
memory available before dram_init() is called - this includes those that
do no DRAM init (like tegra) and those that do it in SPL (quite a few
boards). Enabling driver model preior to relocation for the rest of the
boards is left for a later exercise.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2: None
README| 13 +
common/board_f.c | 12
common/board_r.c | 4
common/dlmalloc.c | 35 +++
include/asm-generic/global_data.h | 5 +
lib/asm-offsets.c | 3 +++
6 files changed, 72 insertions(+)
diff --git a/README b/README
index fe5cacb..7450750 100644
--- a/README
+++ b/README
@@ -3716,6 +3716,19 @@ Configuration Settings:
- CONFIG_SYS_MALLOC_LEN:
Size of DRAM reserved for malloc() use.
+- CONFIG_SYS_MALLOC_F_LEN
+ Size of the malloc() pool for use before relocation. If
+ this is defined, then a very simple malloc() implementation
+ will become available before relocation. The address is just
+ below the global data, and the stack is moved down to make
+ space.
+
+ This feature allocates regions with increasing addresses
+ within the region. calloc() is supported, but realloc()
+ is not available. free() is supported but does nothing.
+ The memory will be freed (or in fact just forgotton) when
+ U-Boot relocates itself.
+
- CONFIG_SYS_BOOTM_LEN:
Normally compressed uImages are limited to an
uncompressed size of 8 MBytes. If this is not enough,
diff --git a/common/board_f.c b/common/board_f.c
index 4ea4cb2..b5e2031 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -776,6 +776,17 @@ static int mark_bootstage(void)
return 0;
}
+static int initf_malloc(void)
+{
+#ifdef CONFIG_SYS_MALLOC_F_LEN
+ assert(gd-malloc_base);/* Set up by crt0.S */
+ gd-malloc_limit = gd-malloc_base + CONFIG_SYS_MALLOC_F_LEN;
+ gd-malloc_ptr = 0;
+#endif
+
+ return 0;
+}
+
static init_fnc_t init_sequence_f[] = {
#ifdef CONFIG_SANDBOX
setup_ram_buf,
@@ -833,6 +844,7 @@ static init_fnc_t init_sequence_f[] = {
sdram_adjust_866,
init_timebase,
#endif
+ initf_malloc,
init_baud_rate, /* initialze baudrate settings */
serial_init,/* serial communications setup */
console_init_f, /* stage 1 init of console */
diff --git a/common/board_r.c b/common/board_r.c
index 602a239..86424a0 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -259,6 +259,10 @@ static int initr_malloc(void)
{
ulong malloc_start;
+#ifdef CONFIG_SYS_MALLOC_F_LEN
+ debug(Pre-reloc malloc() used %#lx bytes (%ld KB)\n, gd-malloc_ptr,
+ gd-malloc_ptr / 1024);
+#endif
/* The malloc area is immediately below the monitor copy in DRAM */
malloc_start = gd-relocaddr - TOTAL_MALLOC_LEN;
mem_malloc_init((ulong)map_sysmem(malloc_start, TOTAL_MALLOC_LEN),
diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index d1cd561..26ba8fd 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -930,6 +930,8 @@ struct mallinfo mALLINFo();
#endif /* 0 */ /* Moved to malloc.h */
#include malloc.h
+#include asm/io.h
+
#ifdef DEBUG
#if __STD_C
static void malloc_update_mallinfo (void);
@@ -2174,6 +2176,20 @@ Void_t* mALLOc(bytes) size_t bytes;
INTERNAL_SIZE_T nb;
+#ifdef CONFIG_SYS_MALLOC_F_LEN
+ if (!(gd-flags GD_FLG_RELOC)) {
+ ulong new_ptr;
+ void *ptr;
+
+ new_ptr = gd-malloc_ptr + bytes;
+ if (new_ptr gd-malloc_limit)
+ panic(Out of pre-reloc memory);
+ ptr = map_sysmem(gd-malloc_base + gd-malloc_ptr, bytes);
+ gd-malloc_ptr = ALIGN(new_ptr, sizeof(new_ptr));
+
[U-Boot] [PATCH v2 6/9] exynos: Enable pre-relocation malloc()
Enable this feature to support driver model before relocation. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None include/configs/exynos5-dt.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/configs/exynos5-dt.h b/include/configs/exynos5-dt.h index 4e316b9..41338db 100644 --- a/include/configs/exynos5-dt.h +++ b/include/configs/exynos5-dt.h @@ -63,7 +63,8 @@ #define INFORM2_OFFSET 0x808 #define INFORM3_OFFSET 0x80c -/* Size of malloc() pool */ +/* Size of malloc() pool before and after relocation */ +#define CONFIG_SYS_MALLOC_F_LEN(1 10) #define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (4 20)) /* select serial console configuration */ @@ -158,7 +159,6 @@ #define CONFIG_SYS_MEMTEST_START CONFIG_SYS_SDRAM_BASE #define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_SDRAM_BASE + 0x5E0) #define CONFIG_SYS_LOAD_ADDR (CONFIG_SYS_SDRAM_BASE + 0x3E0) - #define CONFIG_RD_LVL #define PHYS_SDRAM_1 CONFIG_SYS_SDRAM_BASE -- 2.0.0.526.g5318336 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 8/9] sandbox: config: Enable pre-relocation malloc()
Enable this for sandbox so that we will be able to use driver model before relocation. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None include/configs/sandbox.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h index 12b69d9..e5dca7d 100644 --- a/include/configs/sandbox.h +++ b/include/configs/sandbox.h @@ -16,6 +16,8 @@ #endif +#define CONFIG_MALLOC_F_ADDR 0x001 + #define CONFIG_IO_TRACE #define CONFIG_CMD_IOTRACE @@ -68,8 +70,9 @@ #define CONFIG_EFI_PARTITION /* - * Size of malloc() pool, although we don't actually use this yet. + * Size of malloc() pool, before and after relocation */ +#define CONFIG_SYS_MALLOC_F_LEN(1 10) #define CONFIG_SYS_MALLOC_LEN (32 20) /* 32MB */ #define CONFIG_SYS_HUSH_PARSER -- 2.0.0.526.g5318336 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 7/9] sandbox: Support pre-relocation malloc()
Set up and zero global data before board_init_f() is called so that we can remove the need for CONFIG_SYS_GENERIC_GLOBAL_DATA. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None README | 4 ++-- arch/sandbox/cpu/start.c | 3 +++ 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/README b/README index 46f8f3c..dc020de 100644 --- a/README +++ b/README @@ -3729,8 +3729,8 @@ Configuration Settings: The memory will be freed (or in fact just forgotton) when U-Boot relocates itself. - Pre-relocation malloc() is only supported on ARM at present - but is fairly easy to enable for other archs. + Pre-relocation malloc() is only supported on ARM and sandbox + at present but is fairly easy to enable for other archs. - CONFIG_SYS_BOOTM_LEN: Normally compressed uImages are limited to an diff --git a/arch/sandbox/cpu/start.c b/arch/sandbox/cpu/start.c index 5289291..b3d7051 100644 --- a/arch/sandbox/cpu/start.c +++ b/arch/sandbox/cpu/start.c @@ -240,6 +240,9 @@ int main(int argc, char *argv[]) memset(data, '\0', sizeof(data)); gd = data; +#ifdef CONFIG_SYS_MALLOC_F_LEN + gd-malloc_base = CONFIG_MALLOC_F_ADDR; +#endif /* Do pre- and post-relocation init */ board_init_f(0); -- 2.0.0.526.g5318336 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/9] arm: Set up global data before board_init_f()
At present arm defines CONFIG_SYS_GENERIC_GLOBAL_DATA, meaning that the global_data pointer is set up in board_init_f(). However it is actually set up before this, it just isn't zeroed. If we zero the global data before calling board_init_f() then we don't need to define CONFIG_SYS_GENERIC_GLOBAL_DATA. Make this change to simplify the init process. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None arch/arm/include/asm/config.h | 2 -- arch/arm/lib/crt0.S | 7 +++ 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/arm/include/asm/config.h b/arch/arm/include/asm/config.h index 2a20a77..abf79e5 100644 --- a/arch/arm/include/asm/config.h +++ b/arch/arm/include/asm/config.h @@ -7,8 +7,6 @@ #ifndef _ASM_CONFIG_H_ #define _ASM_CONFIG_H_ -#define CONFIG_SYS_GENERIC_GLOBAL_DATA - #define CONFIG_LMB #define CONFIG_SYS_BOOT_RAMDISK_HIGH diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S index dfc2de9..bbf3e41 100644 --- a/arch/arm/lib/crt0.S +++ b/arch/arm/lib/crt0.S @@ -67,9 +67,16 @@ ENTRY(_main) ldr sp, =(CONFIG_SYS_INIT_SP_ADDR) #endif bic sp, sp, #7 /* 8-byte alignment for ABI compliance */ + mov r2, sp sub sp, sp, #GD_SIZE/* allocate one GD above SP */ bic sp, sp, #7 /* 8-byte alignment for ABI compliance */ mov r9, sp /* GD is above SP */ + mov r1, r9 + mov r0, #0 +clr_gd:cmp r1, r2 /* while not at end of BSS */ + strlo r0, [r1]/* clear 32-bit BSS word */ + addlo r1, r1, #4 /* move to next */ + blo clr_gd mov r0, #0 bl board_init_f -- 2.0.0.526.g5318336 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 9/9] sandbox: Always enable malloc debug
Tun on DEBUG in malloc(). This adds code space and slows things down but for sandbox this is acceptable. We gain the ability to check for memory leaks in tests. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None common/dlmalloc.c | 4 1 file changed, 4 insertions(+) diff --git a/common/dlmalloc.c b/common/dlmalloc.c index 26ba8fd..f987339 100644 --- a/common/dlmalloc.c +++ b/common/dlmalloc.c @@ -1,5 +1,9 @@ #include common.h +#ifdef CONFIG_SANDBOX +#define DEBUG +#endif + #if 0 /* Moved to malloc.h */ /* -- To make a malloc.h, start cutting here */ -- 2.0.0.526.g5318336 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-x86.git branch tom
Hi Tom, I've pick up a few bugfixes for this release in case there is time to pull these. The following changes since commit 6ee3d00d1d9d9977e975bd72c3668ee4f210a99d: Merge branch 'master' of git://git.denx.de/u-boot-i2c (2014-07-07 10:10:52 -0400) are available in the git repository at: x86-public/tom for you to fetch changes up to 8708267f09fa99be8c12e103f2cbdc14a43623cc: buildman: fix toolchain priority_list (2014-07-07 17:22:54 -0600) Masahiro Yamada (3): cosmetic: doc: update README.generic-board buildman: fix to display warning message for missing [toolchain] section buildman: fix toolchain priority_list Simon Glass (1): patman: Only apply patches when we know the original HEAD doc/README.generic-board| 3 ++- tools/buildman/toolchain.py | 4 ++-- tools/patman/gitutil.py | 4 3 files changed, 8 insertions(+), 3 deletions(-) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] vcma9/lowlevel_init.S: trivial: terminate comment
On Wed, Jun 18, 2014 at 10:43:20PM +0200, Jeroen Hofstee wrote: Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Avoid using gawk-specific strtonum()
On Wed, Jun 18, 2014 at 12:10:15AM -0600, Simon Glass wrote: We need to subtract two hex numbers. Avoid using strtonum() by doing the subtraction in bc with a suitable input base. Signed-off-by: Simon Glass s...@chromium.org Reported-by: Vasili Galka vvv...@gmail.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: emif4: wait for CM_DLL_READYST to be set
On Wed, Jun 18, 2014 at 09:22:35PM +0200, Jeroen Hofstee wrote: The code intends for the CM_DLL_READYST to be set, but actually polls till any bit is set since the logical AND is used instead of the bitwise one is used. Fix it. cc: Lokesh Vutla lokeshvu...@ti.com Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/7] mpc8xx: remove qs850, qs860t board support
On Fri, Jun 20, 2014 at 01:54:51PM +0900, Masahiro Yamada wrote: These boards are old enough and have no maintainers. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] tpm: don't use unneeded double brackets
On Wed, Jun 18, 2014 at 10:59:48PM +0200, Jeroen Hofstee wrote: clang is tempted to inteprete such a condition as a assignment as well. Since it isn't don't use double brackets. cc: Tom Wai-Hong Tam waih...@chromium.org Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,6/7] mpc8xx: remove v37 board support
On Fri, Jun 20, 2014 at 01:54:56PM +0900, Masahiro Yamada wrote: This board is old enough and has no maintainer. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,5/7] mpc8xx: remove fads board support
On Fri, Jun 20, 2014 at 01:54:55PM +0900, Masahiro Yamada wrote: These boards are old enough and have no maintainers. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/7] mpc8xx: remove RPXlite_dw, quantum board support
On Fri, Jun 20, 2014 at 01:54:52PM +0900, Masahiro Yamada wrote: These boards are old enough and have no maintainers. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 4/7] mpc8xx: remove netta, netta2, netphone board support
On Fri, Jun 20, 2014 at 01:54:54PM +0900, Masahiro Yamada wrote: These boards are old enough and have no maintainers. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 2/2] README: document the CONFIG_ENV_IS_IN_FAT option
On Tue, Jun 24, 2014 at 05:31:03PM +0800, Wu, Josh wrote: In README file, add document for the missing configuration option: CONFIG_ENV_IS_IN_FAT. Signed-off-by: Josh Wu josh...@atmel.com Reviewed-by: Stephen Warren swar...@nvidia.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TI:omap3: enable CONFIG_CMD_DHCP for omap3_beagle
On Mon, Jun 23, 2014 at 11:11:29AM -0700, Tyler Baker wrote: The following patch re-enables the dhcp functionality on omap3_beagle. It was removed with df4dbb5df6ab1c1d27b3fd4acbaad69b47095daf when omap3_beagle was converted to use ti_omap3_common.h. I have tested beagleboard and beagleboard-xm with this patch and confirmed dhcp is working. Signed-off-by: Tyler Baker tyler.ba...@linaro.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,7/7] mpc8xx: remove spc1920 board support
On Fri, Jun 20, 2014 at 01:54:57PM +0900, Masahiro Yamada wrote: This board is old enough and has no maintainer. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Makefile: drop arch/*/include/asm/proc from make mrproper pattern
On Tue, Jun 24, 2014 at 06:15:45PM +0900, Masahiro Yamada wrote:
Commit 7d89982b stopped creating symbolic link
arch/${arch}/include/asm/proc.
We do not need to delete it by make mrproper any more.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Vasili Galka vvv...@gmail.com
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 1/2] env_fat: use get_device_and_partition() during env save and load
On Tue, Jun 24, 2014 at 05:31:02PM +0800, Wu, Josh wrote: From: Wu, Josh josh...@atmel.com Use get_device_and_partition() is better since: 1. It will call the device initialize function internally. So we can remove the mmc intialization code to save many lines. 2. It is used by fatls/fatload/fatwrite. So saveenv load env should use it too. 3. It can parse the D:P, D, D:, D:auto string to get correct device and partition information by run-time. Also we remove the FAT_ENV_DEVICE and FAT_ENV_PART. We use a string: FAT_ENV_DEVICE_AND_PART. For at91sam9m10g45ek, it is 0. That means use device 0 and if: a)device 0 has no partition table, use the whole device as a FAT file system. b)device 0 has partittion table, use the partition #1. Refer to the commit: 10a37fd7a4 for details of device partition string. Signed-off-by: Josh Wu josh...@atmel.com Reviewed-by: Stephen Warren swar...@nvidia.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] build: define CPU only when arch/${ARCH}/cpu/${CPU} exists
On Tue, Jun 24, 2014 at 10:10:52PM +0900, Masahiro Yamada wrote:
The directory arch/${ARCH}/cpu/${CPU} does not exist
in avr32, blackfin, microblaze, nios2, openrisc, sandbox, x86.
These architectures have only one CPU type.
Defining CPU should not be required for such architectures.
This commit allows cpu field (= the 3rd field of boards.cfg)
to be kept blank.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Andreas Bießmann andreas.de...@googlemail.com
Cc: Simon Glass s...@chromium.org
Cc: Sonic Zhang sonic.zh...@analog.com
Cc: Michal Simek michal.si...@xilinx.com
Cc: Thomas Chou tho...@wytron.com.tw
Cc: Stefan Kristiansson stefan.kristians...@saunalahti.fi
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] board: ti: dra7xx: add mux data for UART3
On Thu, Jun 26, 2014 at 04:38:05PM -0500, Felipe Balbi wrote: J6 EVM can be built with UART3 as console, but currently there's nothing muxing UART3 correctly. Likely this only works because, based on commit log, author was only testing with UART3 boot and - I assume - ROM code leave UART3 correctly muxed in that case. If we want to boot from MMC and still use UART3 as console, then we need to mux those signals correctly. Signed-off-by: Felipe Balbi ba...@ti.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] doc/README.falcon: Clarify steps slightly.
On Fri, Jun 27, 2014 at 09:03:50AM -0400, Tom Rini wrote: Make it clear that we need to load a legacy-formatted (aka uImage) kernel into memory as well as the DT if used before using spl export. Cc: Yebio Mesfin ymes...@ti.com Signed-off-by: Tom Rini tr...@ti.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] m68k: Fix incorrect memory access on M5235
On Mon, Jun 30, 2014 at 12:59:41PM +0300, Vasili Galka wrote: The csarX and cscrX registers in the fbcs_t struct are 16-bit for CONFIG_M5235 and 32-bit wide otherwise. The code in cpu_init.c accessed them always as 32-bit, effectively creating a wrong memory access on M5235. Fixed that by choosing out_be16/out_be32 depending on whether CONFIG_M5235 is defined or not. Cc: Jason Jin jason@freescale.com Signed-off-by: Vasili Galka vvv...@gmail.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/2] am43xx: Tune the system to avoid DSS underflows
On Fri, Jun 27, 2014 at 01:31:15PM -0500, Cooper Jr., Franklin wrote: * This is done by limiting the ARM's bandwidth and setting DSS priority in the EMIF controller to ensure underflows do not occur. Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/2] am43xx: Update EMIF DDR3 Configuration for AM43x GP
On Fri, Jun 27, 2014 at 01:31:14PM -0500, Cooper Jr., Franklin wrote: From: Franklin S. Cooper Jr fcoo...@ti.com * Boot failures have been discovered due to a combination of routing issues and non optimal ddr3 timings in the EMIF * Since ddr3 timings are different after significant board layout changes different timings are required for alpha, beta and production boards. Signed-off-by: Franklin S. Cooper Jr fcoo...@ti.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] m68k: Fix bug, address of operator was forgotten
On Mon, Jun 30, 2014 at 12:59:06PM +0300, Vasili Galka wrote: in_be16() shall be passed a pointer to register and not its value. This is clearly a typo resulting in a wrong memory access, so fix it. Cc: Alison Wang b18...@freescale.com, Jason Jin jason@freescale.com Signed-off-by: Vasili Galka vvv...@gmail.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] blackfin: Add more dcache functions
On Mon, Jun 30, 2014 at 01:00:12PM +0300, Vasili Galka wrote: Add invalidate_dcache_range() and flush_dcache_range() for the blackfin architecture. Such functions already exist on this arch with different names, so just forward the call. This fixes the build of bf609-ezkit board as it uses drivers/net/designware.c which requires the above functions. Cc: Sonic Zhang sonic@gmail.com, Alexey Brodkin abrod...@synopsys.com Signed-off-by: Vasili Galka vvv...@gmail.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] README: document CONFIG_ENV_IS_IN_SPI_FLASH
On Tue, Jul 01, 2014 at 07:30:13PM +0800, Wu, Josh wrote: The option can be used to save the environment in spi flash. Implementation code is already exist in command/env_sf.c. But the documentation is missing. This patch add the details for this option to the README file. Signed-off-by: Josh Wu josh...@atmel.com Reviewed-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] blackfin: Fix warning about undefined function
On Mon, Jun 30, 2014 at 12:59:56PM +0300, Vasili Galka wrote: get_sclk() was not defined in bfin_wdt.c, include the corresponding header. Cc: Sonic Zhang sonic@gmail.com Signed-off-by: Vasili Galka vvv...@gmail.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 02/13] board: gdsys: Adapt sdhc_boot.c to mmc_get_env_addr API change
On Thu, Jul 03, 2014 at 09:28:15AM +0200, Dirk Eibach wrote: From: Dirk Eibach dirk.eib...@gdsys.cc Signed-off-by: Dirk Eibach dirk.eib...@gdsys.cc Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 01/13] board: controlcenterd: Fix pci access
On Thu, Jul 03, 2014 at 09:28:14AM +0200, Dirk Eibach wrote: From: Dirk Eibach dirk.eib...@gdsys.cc readl was called with values instead of pointers to these values. Why this ever did work is a mystery... Signed-off-by: Dirk Eibach dirk.eib...@gdsys.cc Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] blackfin, powerpc: remove redundant definitions of ARRAY_SIZE
On Thu, Jul 03, 2014 at 01:55:51PM +0900, Masahiro Yamada wrote: Since ARRAY_SIZE macro is defined in include/common.h, re-defining it in arch-specific files is redundant. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Stefan Roese s...@denx.de Cc: Sonic Zhang sonic.zh...@analog.com Acked-by: Stefan Roese s...@denx.de Acked-by: Sonic Zhang sonic.zh...@analog.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 03/13] board: controlcenterd: Use new API for setting i2c bus
On Thu, Jul 03, 2014 at 09:28:16AM +0200, Dirk Eibach wrote: From: Dirk Eibach dirk.eib...@gdsys.cc Signed-off-by: Dirk Eibach dirk.eib...@gdsys.cc Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,v4,05/13] i2c: IHS I2C master driver
On Thu, Jul 03, 2014 at 09:28:18AM +0200, Dirk Eibach wrote: From: Dirk Eibach dirk.eib...@gdsys.cc IHS I2C master support was merely a hack in the osd driver. Now it is a proper u-boot I2C framework driver, supporting the v2.00 master features. Signed-off-by: Dirk Eibach dirk.eib...@gdsys.cc Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 04/13] board: iocon: Support DisplayPort hardware
On Thu, Jul 03, 2014 at 09:28:17AM +0200, Dirk Eibach wrote: From: Dirk Eibach dirk.eib...@gdsys.cc There is a new iocon hardware flavor, supporting DisplayPort finally. Signed-off-by: Dirk Eibach dirk.eib...@gdsys.cc Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 07/13] board: gdsys: Increase iocon and dlv10g version string
On Thu, Jul 03, 2014 at 09:28:20AM +0200, Dirk Eibach wrote: From: Dirk Eibach dirk.eib...@gdsys.cc Signed-off-by: Dirk Eibach dirk.eib...@gdsys.cc Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 06/13] board: gdsys: Fix dlvision-10g I2C configuration
On Thu, Jul 03, 2014 at 09:28:19AM +0200, Dirk Eibach wrote: From: Dirk Eibach dirk.eib...@gdsys.cc PPC4xx config options were not complete. ICS8N3QV01 and SIL1178 needed some more configuration. Signed-off-by: Dirk Eibach dirk.eib...@gdsys.cc Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 08/13] board: gdsys: Configure bridge on DP501 to support DDC only
On Thu, Jul 03, 2014 at 09:28:21AM +0200, Dirk Eibach wrote: From: Dirk Eibach dirk.eib...@gdsys.cc The I2C bridge on DP501 supports EDID, MCCS and HDCP by default. Allow EDID only to avoid I2C address conflicts. Signed-off-by: Dirk Eibach dirk.eib...@gdsys.cc Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 09/13] board: gdsys: Make gdsys osd hardware detection more robust
On Thu, Jul 03, 2014 at 09:28:22AM +0200, Dirk Eibach wrote: From: Dirk Eibach dirk.eib...@gdsys.cc Signed-off-by: Dirk Eibach dirk.eib...@gdsys.cc Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 10/13] board: gdsys: Enable scrambling on DP501
On Thu, Jul 03, 2014 at 09:28:23AM +0200, Dirk Eibach wrote: From: Dirk Eibach dirk.eib...@gdsys.cc For proper displayport performance, scrambling has to be enabled, but is turned off on DP501 by default. Signed-off-by: Dirk Eibach dirk.eib...@gdsys.cc Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 11/13] board: iocon: Modify iocon hardware startup
On Thu, Jul 03, 2014 at 09:28:24AM +0200, Dirk Eibach wrote: From: Dirk Eibach dirk.eib...@gdsys.cc To avoid peer ChReceivePathStatus-messages on iocon startup, initialize PHYs as soon as possible. Signed-off-by: Dirk Eibach dirk.eib...@gdsys.cc Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 12/13] board: gdsys: Remove commands to reduce footprint
On Thu, Jul 03, 2014 at 09:28:25AM +0200, Dirk Eibach wrote: From: Dirk Eibach dirk.eib...@gdsys.cc Commit 2842c1c fit: add sha256 support badly increased memory footprint, so some of our boards did not build anymore. Since monitor base must not be changed I removed some commands to save memory. Maybe making sha256 optional for fit would be an option for the future since it really has some beefy footprint. Signed-off-by: Dirk Eibach dirk.eib...@gdsys.cc Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] git-mailrc: Add sunxi custodians.
On Thu, Jul 03, 2014 at 09:25:41PM +0100, Ian Campbell wrote: Signed-off-by: Ian Campbell i...@hellion.org.uk Cc: Hans de Goede hdego...@redhat.com Acked-by: Hans de Goede hdego...@redhat.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,v4,13/13] fit: make sha256 support optional
On Thu, Jul 03, 2014 at 09:28:26AM +0200, Dirk Eibach wrote: From: Dirk Eibach dirk.eib...@gdsys.cc sha256 has some beefy memory footprint. Make it optional for constrained systems. Signed-off-by: Dirk Eibach dirk.eib...@gdsys.cc Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] kmake: include DTB section into u-boot.bin if CONFIG_OF_EMBED enabled
On Mon, Jul 07, 2014 at 03:21:44AM +0400, Alexey Ignatov wrote: Fixes a bug when objcopy doesn't put .dtb.init.rodata section to resulting u-boot.bin, so u-boot was unable to find embedded DTB. Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
