[U-Boot] [PATCH] arm: omap5: echi: Add GPL-2.0+ SPDX-License-Identifier
Signed-off-by: Nobuhiro Iwamatsu --- arch/arm/include/asm/arch-omap5/ehci.h | 15 +-- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/arch/arm/include/asm/arch-omap5/ehci.h b/arch/arm/include/asm/arch-omap5/ehci.h index 3921e4a..63aaa02 100644 --- a/arch/arm/include/asm/arch-omap5/ehci.h +++ b/arch/arm/include/asm/arch-omap5/ehci.h @@ -2,20 +2,7 @@ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com* * Author: Govindraj R * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation; either version 2 of - * the License, or (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, - * MA 02111-1307 USA + * SPDX-License-Identifier: GPL-2.0+ */ #ifndef _EHCI_H -- 1.8.4.rc3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] Add device tree support for VxWorks
Hello Wolfgang, I think this is not a good idea, for two reasons. First, it means the behaviour of the "bootm" command is not consistent - with FDT address passed as argument it behaves one way, without it behaves different. Second, You may want to support images that have the FDT attached or embedded or similar - maybe not now, but I bet such requests will pop up. You cannot do this in your code. I understand this. The only reason that I did this way is that I am afraid of breaking existing 'bootm' users, but I just searched the mailing, seems that VxWorks volume is rather low, maybe it's OK to separate the two without hurting anyone. If there is no way to inquire from the image itself wether it is one with FDT support or not (we might even assign a new IH_OS_ type for the new ones?), then it would probably be better to make "bootm" support only the new FDT aware images, and keep "bootvx" as compatibility command to boot older images. I don't prefer to add a new OS type. It is still VxWorks after all, and with the fact that I am not allowed to disclose any information of the new version (not GA yet) makes it harder to come up with a meaningful name like IH_OS_VXWORKS_xxx. I would prefer to do it as you said, just making 'bootm' work with new versions and keeping 'bootvx' for the older ones. This makes things a lot easier. On the other hand - what exactly is the difference between both boot ways to start an image? Does the additional address passed for the FDT really hurt old style images, so do we need the differentiation at all? 90% of the 'do_bootvx' function is about bootline setup (storing bootline to random memory locations that totally depend on individual BSP), which doesn't apply to the new kernel (in fact, if not doing right, it will likely result in memory corruption and hang the board). And I don't see a reliable way to distinguish the new and old kernels at runtime. Mixing them would make the code hard to maintain. I'd rather see them separated so we could focus on supporting the new one. Miao ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: prevent using movt/movw address loads
Hi, experts: >The movt/movw instruction can be used to hardcode an >memory location in the instruction itself. The linker >starts complaining about this if the compiler decides >to do so: "relocation R_ARM_MOVW_ABS_NC against `a local >symbol' can not be used" and it is not support by U-boot >as well. Prevent their use by requiring word relocations. >This allows u-boot to be build at other optimalization >levels then -Os. Would this patch be included in 2013.10 release verion? So u-boot could be built at other optimalization levels than -Os. I tested 2013.10-rc2, but still failed to build by -O0 / -O1 etc. Best wishes, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/19] First step towards Kbuild: Use Kbuild style makefiles
On Tue, Sep 17, 2013 at 09:35 +0900, Masahiro Yamada wrote: > > > [ Makefiles rearranged, how to verify the change? ] > > But your suggestion sounds interesting. > If we could programmatically compare the generated executables > in an easy way, that would be worth checking. > > So I gave it a try. > Finally it turned out to be much harder than I had expected. (Almost > nightware) > > Anyway, let's see what I did one by one. > > [ ... time stamps, version information, symbol order, etc ... ] > > (10) Results > > [ ... most architectures, matching md5sum ... ] > > (12) Conclusion > > I made as much effort as I could do now > in order to get md5sum matching. > > I found one file (arch/powerpc/cpu/mpc8260/Makefile) > to be fixed. (Working but better to be fixed.) > > I will post version2 with this fix plus rebased on the current master. What a fine display of Lemming control^H^H^H^W^W persistence. :) Woah, this is awesome! You spent a lot of effort to verify the results, and further improved the series upon detecting a previously unspotted difference. This is very much appreciated. So you gained even more confidence in the change and have proven that apart from the wanted modification nothing else is affected. This is a very good thing! Especially since the nature of the bootloader's project is rather sensitive to not passing a flag, or passing a wrong flag to architecture specific code. The essence of your notes (the spots of potential conflict, how to "unify" them to shadow "unwanted diffs", and how to compare results after building most of the targets) are worth keeping around somewhere, I guess. Those who setup build and test farms may want to reference them. For now it's in the ML archive. > I could not compile lots of minor architecture boards, > but the results of md5sum for arm, powerpc, sandbox architectures > is sufficient to support my correctness. > > But I want to know the reason why the compile failed for such many boards. > Of course my procedure might be wrong, but I think at least some of warnings > are caused by immature code. I mean more or less boards look to be already > broken. That was my other motivation for the "compare binaries" approach in contrast to run-testing the result on the targets. You want to prove that your modification only has wanted effects and does nothing else, regardless of which state you initially find the source code in. Not being able to build need not mean that you broke it, it might have been in this state before already. And not being able to run software in the absence of hardware may even be the rule instead of an exception. Getting those targets to build again which currently don't appears to be a separate task, independent from your modification (re-write) of the build instructions. virtually yours Gerhard Sittig -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: prevent using movt/movw address loads
Dear tiger...@viatech.com.cn, In message you wrote: > > I tested 2013.10-rc2, but still failed to build by -O0 / -O1 etc. May I ask why you want to use other optimization levels? Do you just hope that your code may run faster, or do you have actual proof (i. e. measurements) that this is the case? It would be interesting if you could share any such measured 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 "What if" is a trademark of Hewlett Packard, so stop using it in your sentences without permission, or risk being sued. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v10 1/6] core support of arm64
> -原始邮件- > 发件人: "Scott Wood" > 发送时间: 2013年9月17日 星期二 > 收件人: feng...@phytium.com.cn > 抄送: u-boot@lists.denx.de, tr...@ti.com, albert.u.b...@aribaud.net, > w...@denx.de, b45...@freescale.com > 主题: Re: [PATCH v10 1/6] core support of arm64 > > On Mon, 2013-09-16 at 16:08 +0800, feng...@phytium.com.cn wrote: > > From: David Feng > > > > Signed-off-by: David Feng > > --- > > You've still got CONFIG_ARMV8 in places that should be CONFIG_ARM64 I am hesitate to use CONFIG_ARM64 instead of CONFIG _ARMV8. I am not sure whether all the CONFIG_ARMV8 could be replaced with CONFIG_ARM64 or CONFIG_ARMV8 and CONFIG_ARMV64 are both needed. I will take this into account in the next. > > > diff --git a/arch/arm/cpu/armv8/exceptions.S > > b/arch/arm/cpu/armv8/exceptions.S > > new file mode 100644 > > index 000..b2f62c9 > > --- /dev/null > > +++ b/arch/arm/cpu/armv8/exceptions.S > > @@ -0,0 +1,115 @@ > > +/* > > + * (C) Copyright 2013 > > + * David Feng > > + * > > + * SPDX-License-Identifier:GPL-2.0+ > > + */ > > Note that Tom said he'd be OK with using GPL2-only code from Linux, as > long as it's properly attributed. > Currently, the stack preservation code has no comparability with it's original copy. I think it could be licensed with GPL-2.0+. > > +2. GOT is used to relocate u-boot and CONFIG_NEEDS_MANUAL_RELOC is needed. > > + > > +3. Fdt should be placed at a 2-megabyte boundary and within the first 512 > > + megabytes from the start of the kernel image. So, fdt_high should be > > + defined specially. > > + Please reference linux/Documentation/arm64/booting.txt for detail. > > + > > +4. Generic board is supported. > > + > > +Contributor: > > + Tom Rini > > + Scott Wood > > + Sharma Bhupesh > > + Rob Herring > > Should it be: > Bhupesh Sharma > ? It seems that Bhupesh Sharma own two mail box and he usually use b45...@freescale.com at u-boot mailing list. I will fix it in the next. Best regards. > -Scott > > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] SPDX: fix IBM-pibs license identifier
The SPDX License List version 1.19 now contains an official entry for the IBM-pibs license. However, instead of our suggestion "ibm-pibs", the SPDX License List uses "IBM-pibs", with the following rationale: "The reason being that all other SPDX License List short identifiers tend towards using capital letters unless spelling a word. I'd prefer to be consistent to this end". Change the license IDs to use the official name. Signed-off-by: Wolfgang Denk --- Tom, this is a formal change which does not touch any code at all. It is supposed to have zero impact on any system, so you might even consider to apply it to the tree even now, in this late state of the release cycle. On the other hand, it's not urgent, so please also feel free to hold it for the next release. Thanks! -wd Licenses/README| 2 +- arch/powerpc/cpu/ppc4xx/4xx_pci.c | 2 +- arch/powerpc/cpu/ppc4xx/4xx_uart.c | 2 +- arch/powerpc/cpu/ppc4xx/miiphy.c | 2 +- arch/powerpc/cpu/ppc4xx/start.S| 2 +- arch/powerpc/include/asm/ppc405.h | 2 +- arch/powerpc/include/asm/ppc440.h | 2 +- arch/powerpc/include/asm/ppc4xx-emac.h | 2 +- arch/powerpc/include/asm/ppc4xx-mal.h | 2 +- arch/powerpc/include/asm/ppc4xx.h | 2 +- board/cray/L1/init.S | 2 +- board/csb272/init.S| 2 +- board/csb472/init.S| 2 +- board/esd/pci405/writeibm.S| 2 +- board/jse/init.S | 2 +- board/mpl/common/pci.c | 2 +- board/mpl/mip405/init.S| 2 +- board/mpl/pip405/init.S| 2 +- board/sc3/init.S | 2 +- board/w7o/init.S | 2 +- drivers/net/4xx_enet.c | 2 +- drivers/net/npe/miiphy.c | 2 +- include/miiphy.h | 2 +- 23 files changed, 23 insertions(+), 23 deletions(-) diff --git a/Licenses/README b/Licenses/README index 4196125..9f61192 100644 --- a/Licenses/README +++ b/Licenses/README @@ -52,5 +52,5 @@ GNU Lesser General Public License v2.1 or later LGPL-2.1+ Y lgpl-2.1.txthttp: eCos license version 2.0 eCos-2.0 eCos-2.0.txthttp://www.gnu.org/licenses/ecos-license.html BSD 2-Clause License BSD-2-ClauseY bsd-2-clause.txthttp://spdx.org/licenses/BSD-2-Clause BSD 3-clause "New" or "Revised" LicenseBSD-3-ClauseY bsd-3-clause.txt http://spdx.org/licenses/BSD-3-Clause#licenseText -IBM PIBS (PowerPC Initialization and ibm-pibs ibm-pibs.txt +IBM PIBS (PowerPC Initialization and IBM-pibs ibm-pibs.txt Boot Software) license diff --git a/arch/powerpc/cpu/ppc4xx/4xx_pci.c b/arch/powerpc/cpu/ppc4xx/4xx_pci.c index 5584e0f..08781a1 100644 --- a/arch/powerpc/cpu/ppc4xx/4xx_pci.c +++ b/arch/powerpc/cpu/ppc4xx/4xx_pci.c @@ -1,5 +1,5 @@ /* - * SPDX-License-Identifier:GPL-2.0 ibm-pibs + * SPDX-License-Identifier:GPL-2.0 IBM-pibs * * File Name: 405gp_pci.c * diff --git a/arch/powerpc/cpu/ppc4xx/4xx_uart.c b/arch/powerpc/cpu/ppc4xx/4xx_uart.c index 50c28a0..c02058f 100644 --- a/arch/powerpc/cpu/ppc4xx/4xx_uart.c +++ b/arch/powerpc/cpu/ppc4xx/4xx_uart.c @@ -5,7 +5,7 @@ * (C) Copyright 2010 * Stefan Roese, DENX Software Engineering, s...@denx.de. * - * SPDX-License-Identifier:GPL-2.0 ibm-pibs + * SPDX-License-Identifier:GPL-2.0 IBM-pibs */ #include diff --git a/arch/powerpc/cpu/ppc4xx/miiphy.c b/arch/powerpc/cpu/ppc4xx/miiphy.c index e4a9db6..10147de 100644 --- a/arch/powerpc/cpu/ppc4xx/miiphy.c +++ b/arch/powerpc/cpu/ppc4xx/miiphy.c @@ -1,5 +1,5 @@ /* - * SPDX-License-Identifier:GPL-2.0 ibm-pibs + * SPDX-License-Identifier:GPL-2.0 IBM-pibs */ /*-+ | diff --git a/arch/powerpc/cpu/ppc4xx/start.S b/arch/powerpc/cpu/ppc4xx/start.S index d9d8cbf..38bbc5a 100644 --- a/arch/powerpc/cpu/ppc4xx/start.S +++ b/arch/powerpc/cpu/ppc4xx/start.S @@ -6,7 +6,7 @@ * Copyright (c) 2008 Nuovation System Designs, LLC *Grant Erickson * - * SPDX-License-Identifier:GPL-2.0 ibm-pibs + * SPDX-License-Identifier:GPL-2.0 IBM-pibs */ /* diff --git a/arch/powerpc/include/asm/ppc405.h b/arch/powerpc/include/asm/ppc405.h index 8bb342b..f2ed16a 100644 --- a/arch/powerpc/include/asm/ppc405.h +++ b/arch/powerpc/include/asm/ppc405.h @@ -1,5 +1,5 @@ /* - * SPDX-License-Identifier:GPL-2.0 ibm-pibs + * SPDX-License-Identifier:GPL-2.0 IBM-pibs */ #ifndef__PPC405_H__ diff --git a/arch/powerpc/include/asm/ppc440.h b/arch/powerpc/include/asm/ppc440.h index 0f5bc8d..0cfa88b 100644 --- a/arch/powerpc/include/asm/ppc440.h +++ b/arch/powerpc/include/asm/ppc440.h @@ -9,7 +9,7 @@ * (C) Copyright 2010
Re: [U-Boot] [ANN] v2013.10-rc3
Dear Tom, In message <20130917001120.GB3040@oliver-linux> you wrote: > > I've put v2013.10-rc3 out and tarballs should be out soon. Tarball is out on the FTP server, see [1]. [1] ftp://ftp.denx.de/pub/u-boot/u-boot-2013.10-rc3.tar.bz2 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] arm: prevent using movt/movw address loads
Hi, Denk: >May I ask why you want to use other optimization levels? Do you just >hope that your code may run faster, or do you have actual proof (i. e. >measurements) that this is the case? It would be interesting if you >could share any such measured results. Not for running faster. I just think: If turn off compiler optimization, some bugs would be analysed easily. Best wishes, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: prevent using movt/movw address loads
Dear tiger...@viatech.com.cn, In message you wrote: > > >May I ask why you want to use other optimization levels? Do you just > >hope that your code may run faster, or do you have actual proof (i. e. > >measurements) that this is the case? It would be interesting if you > >could share any such measured results. > > Not for running faster. > I just think: > If turn off compiler optimization, some bugs would be analysed easily. Hm... that does not match my experience. A pretty large percentage of actual bugs is of Heisenbug nature. Changin the buil environment will create a completely different image with different behaviour - you may be lucky, but too often the changes actually side-track you from the actual issues. 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 Pig: An animal (Porcus omnivorous) closely allied to the human race by the splendor and vivacity of its appetite, which, however, is in- ferior in scope, for it balks at pig.- Ambrose Bierce ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Loading U-Boot from a Different Location on the Flash
Hi, I'm working on a P3041 processor and would like to load the u-boot from a different flash address than 0xeff8 (where it is normally placed). Could you please direct me to the sources and headers that need to be changed for that? Is it enough to update: #define CONFIG_SYS_TEXT_BASE 0xeff8 #define CONFIG_RESET_VECTOR_ADDRESS 0xeffc from /include/configs/corenet_ds.h or something else should be changed? Thanks in advance, Roy This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: prevent using movt/movw address loads
Hi, experts: >-# check that only R_ARM_RELATIVE relocations are generated > ifneq ($(CONFIG_SPL_BUILD),y) >-ALL-y += checkarmreloc >+# Check that only R_ARM_RELATIVE relocations are generated. >+ALL-y += checkarmreloc >+# The movt / movw can hardcode 16 bit parts of the addresses in the >+# instruction. Relocation is not supported for that case, so disable >+# such usage by requiring word relocations. >+PLATFORM_CPPFLAGS += $(call cc-option, -mword-relocations) > endif Jeroen's patch is very simple. So, is there any side-effect? If not, why not add it into 2013.10 release version? :) Best wishes, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 00/10] arm: vf610/vf610twr: vybrid tower fixes and enhancements
arm: vf610: vf610twr: vybrid tower fixes and enhancements This patch series addresses several vixes and enhancements for the vybrid tower. Tested on a TWR-VF65GS10 Rev G. Marcel Ziswiler (10): arm: vf610: fix anadig register struct arm: vf610: clean-up anadig register struct arm: vf610: add uart0 clock definition arm: vf610: add anadig pll5 definitions arm: vf610: add enet1 base address definition arm: vf610: add rmii clkout iomux definition arm: vf610: add uart0 tx/rx iomux definitions arm: vf610: add rmii1 iomux definitions arm: vf610: fix double iomux configuration for vf610twr board arm: vf610: remove obsolete uart port configuration arch/arm/include/asm/arch-vf610/crm_regs.h| 57 ++--- arch/arm/include/asm/arch-vf610/imx-regs.h|1 + arch/arm/include/asm/arch-vf610/iomux-vf610.h | 12 ++ board/freescale/vf610twr/vf610twr.c |1 - include/configs/vf610twr.h|1 - 5 files changed, 45 insertions(+), 27 deletions(-) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 03/10] arm: vf610: add uart0 clock definition
Add CCM_CCGR0_UART0_CTRL_MASK clock definition for UART0 aka SCI0.
Signed-off-by: Marcel Ziswiler
---
arch/arm/include/asm/arch-vf610/crm_regs.h |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/include/asm/arch-vf610/crm_regs.h
b/arch/arm/include/asm/arch-vf610/crm_regs.h
index d5c9387..490e368 100644
--- a/arch/arm/include/asm/arch-vf610/crm_regs.h
+++ b/arch/arm/include/asm/arch-vf610/crm_regs.h
@@ -166,6 +166,7 @@ struct anadig_reg {
#define CCM_CSCMR2_RMII_CLK_SEL(v) (((v) & 0x3) << 4)
#define CCM_REG_CTRL_MASK 0x
+#define CCM_CCGR0_UART0_CTRL_MASK (0x3 << 14)
#define CCM_CCGR0_UART1_CTRL_MASK (0x3 << 16)
#define CCM_CCGR1_PIT_CTRL_MASK(0x3 << 14)
#define CCM_CCGR1_WDOGA5_CTRL_MASK (0x3 << 28)
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 02/10] arm: vf610: clean-up anadig register struct
Re-number all the resv reserved fields.
Signed-off-by: Marcel Ziswiler
---
arch/arm/include/asm/arch-vf610/crm_regs.h | 54 ++--
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/arch/arm/include/asm/arch-vf610/crm_regs.h
b/arch/arm/include/asm/arch-vf610/crm_regs.h
index 57a0242..d5c9387 100644
--- a/arch/arm/include/asm/arch-vf610/crm_regs.h
+++ b/arch/arm/include/asm/arch-vf610/crm_regs.h
@@ -55,59 +55,59 @@ struct ccm_reg {
/* Analog components control digital interface (ANADIG) */
struct anadig_reg {
- u32 resvA[4];
+ u32 resv0[4];
u32 pll3_ctrl;
- u32 resv0[3];
- u32 pll7_ctrl;
u32 resv1[3];
- u32 pll2_ctrl;
+ u32 pll7_ctrl;
u32 resv2[3];
- u32 pll2_ss;
+ u32 pll2_ctrl;
u32 resv3[3];
- u32 pll2_num;
+ u32 pll2_ss;
u32 resv4[3];
- u32 pll2_denom;
+ u32 pll2_num;
u32 resv5[3];
- u32 pll4_ctrl;
+ u32 pll2_denom;
u32 resv6[3];
- u32 pll4_num;
+ u32 pll4_ctrl;
u32 resv7[3];
+ u32 pll4_num;
+ u32 resv8[3];
u32 pll4_denom;
- u32 resvB[3];
+ u32 resv9[3];
u32 pll6_ctrl;
- u32 resv8[3];
+ u32 resv10[3];
u32 pll6_num;
- u32 resv9[3];
+ u32 resv11[3];
u32 pll6_denom;
- u32 resv10[7];
+ u32 resv12[7];
u32 pll5_ctrl;
- u32 resv11[3];
+ u32 resv13[3];
u32 pll3_pfd;
- u32 resv12[3];
+ u32 resv14[3];
u32 pll2_pfd;
- u32 resv13[3];
+ u32 resv15[3];
u32 reg_1p1;
- u32 resv14[3];
+ u32 resv16[3];
u32 reg_3p0;
- u32 resv15[3];
+ u32 resv17[3];
u32 reg_2p5;
- u32 resv16[7];
+ u32 resv18[7];
u32 ana_misc0;
- u32 resv17[3];
+ u32 resv19[3];
u32 ana_misc1;
- u32 resv18[63];
+ u32 resv20[63];
u32 anadig_digprog;
- u32 resv19[3];
+ u32 resv21[3];
u32 pll1_ctrl;
- u32 resv20[3];
+ u32 resv22[3];
u32 pll1_ss;
- u32 resv21[3];
+ u32 resv23[3];
u32 pll1_num;
- u32 resv22[3];
+ u32 resv24[3];
u32 pll1_denom;
- u32 resv23[3];
+ u32 resv25[3];
u32 pll1_pdf;
- u32 resv24[3];
+ u32 resv26[3];
u32 pll_lock;
};
#endif
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 01/10] arm: vf610: fix anadig register struct
The anadig_reg structure started at the wrong offset (fixed by adding
resvA[4]), was missing some reserved field required for alignment
purpose (resvB[3] between pll4_denom and pll6_ctrl) and further
contained too short a reserved field causing further miss-alignment
(resv10[7]).
Discovered and tested by temporarily putting the following debug
instrumentation into board_init():
struct anadig_reg *anadig = (struct anadig_reg *)ANADIG_BASE_ADDR;
printf("&anadig->pll3_ctrl=0x%p\n", &anadig->pll3_ctrl);
printf("&anadig->pll5_ctrl=0x%p\n", &anadig->pll5_ctrl);
Signed-off-by: Marcel Ziswiler
---
arch/arm/include/asm/arch-vf610/crm_regs.h |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/arch-vf610/crm_regs.h
b/arch/arm/include/asm/arch-vf610/crm_regs.h
index 85f1fda..57a0242 100644
--- a/arch/arm/include/asm/arch-vf610/crm_regs.h
+++ b/arch/arm/include/asm/arch-vf610/crm_regs.h
@@ -55,6 +55,7 @@ struct ccm_reg {
/* Analog components control digital interface (ANADIG) */
struct anadig_reg {
+ u32 resvA[4];
u32 pll3_ctrl;
u32 resv0[3];
u32 pll7_ctrl;
@@ -72,12 +73,13 @@ struct anadig_reg {
u32 pll4_num;
u32 resv7[3];
u32 pll4_denom;
+ u32 resvB[3];
u32 pll6_ctrl;
u32 resv8[3];
u32 pll6_num;
u32 resv9[3];
u32 pll6_denom;
- u32 resv10[3];
+ u32 resv10[7];
u32 pll5_ctrl;
u32 resv11[3];
u32 pll3_pfd;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/10] arm: vf610: add anadig pll5 definitions
Add ANADIG PLL5 control definitions required for Ethernet RMII clock
configuration.
Signed-off-by: Marcel Ziswiler
---
arch/arm/include/asm/arch-vf610/crm_regs.h |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/include/asm/arch-vf610/crm_regs.h
b/arch/arm/include/asm/arch-vf610/crm_regs.h
index 490e368..d4ad957 100644
--- a/arch/arm/include/asm/arch-vf610/crm_regs.h
+++ b/arch/arm/include/asm/arch-vf610/crm_regs.h
@@ -187,6 +187,10 @@ struct anadig_reg {
#define CCM_CCGR9_FEC0_CTRL_MASK 0x3
#define CCM_CCGR9_FEC1_CTRL_MASK (0x3 << 2)
+#define ANADIG_PLL5_CTRL_BYPASS (1 << 16)
+#define ANADIG_PLL5_CTRL_ENABLE (1 << 13)
+#define ANADIG_PLL5_CTRL_POWERDOWN (1 << 12)
+#define ANADIG_PLL5_CTRL_DIV_SELECT1
#define ANADIG_PLL2_CTRL_ENABLE(1 << 13)
#define ANADIG_PLL2_CTRL_POWERDOWN (1 << 12)
#define ANADIG_PLL2_CTRL_DIV_SELECT1
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 05/10] arm: vf610: add enet1 base address definition
Add secondary Ethernet MAC RMII1 base address definition in preparation of potential secondary only board configurations. Signed-off-by: Marcel Ziswiler --- arch/arm/include/asm/arch-vf610/imx-regs.h |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/include/asm/arch-vf610/imx-regs.h b/arch/arm/include/asm/arch-vf610/imx-regs.h index b8c877f..c2f9761 100644 --- a/arch/arm/include/asm/arch-vf610/imx-regs.h +++ b/arch/arm/include/asm/arch-vf610/imx-regs.h @@ -85,6 +85,7 @@ #define ESDHC0_BASE_ADDR (AIPS1_BASE_ADDR + 0x00031000) #define ESDHC1_BASE_ADDR (AIPS1_BASE_ADDR + 0x00032000) #define ENET_BASE_ADDR (AIPS1_BASE_ADDR + 0x0005) +#define ENET1_BASE_ADDR(AIPS1_BASE_ADDR + 0x00051000) /* MUX mode and PAD ctrl are in one register */ #define CONFIG_IOMUX_SHARE_CONF_REG -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 10/10] arm: vf610: remove obsolete uart port configuration
Get rid of obsolete CONFIG_SYS_UART_PORT configuration option. Signed-off-by: Marcel Ziswiler --- include/configs/vf610twr.h |1 - 1 file changed, 1 deletion(-) diff --git a/include/configs/vf610twr.h b/include/configs/vf610twr.h index 5a7a066..432a69d 100644 --- a/include/configs/vf610twr.h +++ b/include/configs/vf610twr.h @@ -39,7 +39,6 @@ /* Allow to overwrite serial and ethaddr */ #define CONFIG_ENV_OVERWRITE -#define CONFIG_SYS_UART_PORT (1) #define CONFIG_BAUDRATE115200 #undef CONFIG_CMD_IMLS -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 09/10] arm: vf610: fix double iomux configuration for vf610twr board
Get rid of double VF610_PAD_DDR_A15__DDR_A_15 iomux configuration.
Signed-off-by: Marcel Ziswiler
---
board/freescale/vf610twr/vf610twr.c |1 -
1 file changed, 1 deletion(-)
diff --git a/board/freescale/vf610twr/vf610twr.c
b/board/freescale/vf610twr/vf610twr.c
index 699ea7f..4ee74c0 100644
--- a/board/freescale/vf610twr/vf610twr.c
+++ b/board/freescale/vf610twr/vf610twr.c
@@ -31,7 +31,6 @@ void setup_iomux_ddr(void)
{
static const iomux_v3_cfg_t ddr_pads[] = {
VF610_PAD_DDR_A15__DDR_A_15,
- VF610_PAD_DDR_A15__DDR_A_15,
VF610_PAD_DDR_A14__DDR_A_14,
VF610_PAD_DDR_A13__DDR_A_13,
VF610_PAD_DDR_A12__DDR_A_12,
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 08/10] arm: vf610: add rmii1 iomux definitions
Add secondary RMII1 iomux definitions.
Signed-off-by: Marcel Ziswiler
---
arch/arm/include/asm/arch-vf610/iomux-vf610.h |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
index a6f7132..1b410c3 100644
--- a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
+++ b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
@@ -36,6 +36,15 @@ enum {
VF610_PAD_PTC6__RMII0_TD1 = IOMUX_PAD(0x00cc, 0x00cc, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
VF610_PAD_PTC7__RMII0_TD0 = IOMUX_PAD(0x00D0, 0x00D0, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
VF610_PAD_PTC8__RMII0_TXEN = IOMUX_PAD(0x00D4, 0x00D4, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
+ VF610_PAD_PTC10__RMII1_MDIO = IOMUX_PAD(0x00dc, 0x00b8, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
+ VF610_PAD_PTC9__RMII1_MDC = IOMUX_PAD(0x00d8, 0x00b4, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
+ VF610_PAD_PTC11__RMII1_CRS_DV = IOMUX_PAD(0x00e0, 0x00bc, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
+ VF610_PAD_PTC12__RMII1_RD1 = IOMUX_PAD(0x00e4, 0x00c0, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
+ VF610_PAD_PTC13__RMII1_RD0 = IOMUX_PAD(0x00e8, 0x00c4, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
+ VF610_PAD_PTC14__RMII1_RXER = IOMUX_PAD(0x00ec, 0x00c8, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
+ VF610_PAD_PTC15__RMII1_TD1 = IOMUX_PAD(0x00f0, 0x00cc, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
+ VF610_PAD_PTC16__RMII1_TD0 = IOMUX_PAD(0x00f4, 0x00D0, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
+ VF610_PAD_PTC17__RMII1_TXEN = IOMUX_PAD(0x00f8, 0x00D4, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
VF610_PAD_PTA24__ESDHC1_CLK = IOMUX_PAD(0x0038, 0x0038, 5,
__NA_, 0, VF610_SDHC_PAD_CTRL),
VF610_PAD_PTA25__ESDHC1_CMD = IOMUX_PAD(0x003c, 0x003c, 5,
__NA_, 0, VF610_SDHC_PAD_CTRL),
VF610_PAD_PTA26__ESDHC1_DAT0= IOMUX_PAD(0x0040, 0x0040, 5,
__NA_, 0, VF610_SDHC_PAD_CTRL),
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 06/10] arm: vf610: add rmii clkout iomux definition
Add VF610_PAD_PTA6__RMII0_CLKOUT iomux definition eventually required
for internal (e.g. crystal-less) Ethernet clocking.
Signed-off-by: Marcel Ziswiler
---
arch/arm/include/asm/arch-vf610/iomux-vf610.h |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
index 4a39eb0..e315fe4 100644
--- a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
+++ b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
@@ -22,6 +22,7 @@
enum {
VF610_PAD_PTA6__RMII0_CLKIN = IOMUX_PAD(0x, 0x, 2,
__NA_, 0, VF610_ENET_PAD_CTRL),
+ VF610_PAD_PTA6__RMII0_CLKOUT= IOMUX_PAD(0x, 0x, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
VF610_PAD_PTB4__UART1_TX= IOMUX_PAD(0x0068, 0x0068, 2,
0x0380, 0, VF610_UART_PAD_CTRL),
VF610_PAD_PTB5__UART1_RX= IOMUX_PAD(0x006c, 0x006c, 2,
0x037c, 0, VF610_UART_PAD_CTRL),
VF610_PAD_PTC1__RMII0_MDIO = IOMUX_PAD(0x00b8, 0x00b8, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 07/10] arm: vf610: add uart0 tx/rx iomux definitions
Add UART0 aka SCI0 TX/RX iomux definitions.
Signed-off-by: Marcel Ziswiler
---
arch/arm/include/asm/arch-vf610/iomux-vf610.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
index e315fe4..a6f7132 100644
--- a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
+++ b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
@@ -25,6 +25,8 @@ enum {
VF610_PAD_PTA6__RMII0_CLKOUT= IOMUX_PAD(0x, 0x, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
VF610_PAD_PTB4__UART1_TX= IOMUX_PAD(0x0068, 0x0068, 2,
0x0380, 0, VF610_UART_PAD_CTRL),
VF610_PAD_PTB5__UART1_RX= IOMUX_PAD(0x006c, 0x006c, 2,
0x037c, 0, VF610_UART_PAD_CTRL),
+ VF610_PAD_PTB10__UART0_TX = IOMUX_PAD(0x0080, 0x0080, 1,
__NA_, 0, VF610_UART_PAD_CTRL),
+ VF610_PAD_PTB11__UART0_RX = IOMUX_PAD(0x0084, 0x0084, 1,
__NA_, 0, VF610_UART_PAD_CTRL),
VF610_PAD_PTC1__RMII0_MDIO = IOMUX_PAD(0x00b8, 0x00b8, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
VF610_PAD_PTC0__RMII0_MDC = IOMUX_PAD(0x00b4, 0x00b4, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
VF610_PAD_PTC2__RMII0_CRS_DV= IOMUX_PAD(0x00bc, 0x00bc, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] bootm: use BOOTM_STATE_OS_CMDLINE flag for plain bootm
*ping* (Also CCing MIPS custodian) Paul On 06/09/13 11:23, Paul Burton wrote: A plain bootm used to call the architecture specific boot function with no flags, but was modified by commit 35fc84fa "Refactor the bootm command to reduce code duplication" to call the architecture specific boot function multiple times with various flags in sequence. The BOOTM_STATE_OS_CMDLINE flag was not used, indeed it seems that at least ARM prepares the command line on BOOTM_STATE_OS_PREP. However on MIPS since commit 59e8cbdb "MIPS: bootm: refactor initialisation of kernel cmdline" the command line is not prepared in response to a BOOTM_STATE_OS_PREP flag, only on BOOTM_STATE_OS_CMDLINE or a call with no flags. The end result is that a combination of those 2 commits leads to MIPS boards booting kernels with no command line arguments. An extra invocation of the architecture specific boot function with BOOTM_STATE_OS_CMDLINE fixes this. Signed-off-by: Paul Burton --- common/cmd_bootm.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c index 1685c14..b8255eb 100644 --- a/common/cmd_bootm.c +++ b/common/cmd_bootm.c @@ -797,8 +797,9 @@ int do_bootm(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) return do_bootm_states(cmdtp, flag, argc, argv, BOOTM_STATE_START | BOOTM_STATE_FINDOS | BOOTM_STATE_FINDOTHER | - BOOTM_STATE_LOADOS | BOOTM_STATE_OS_PREP | - BOOTM_STATE_OS_FAKE_GO | BOOTM_STATE_OS_GO, &images, 1); + BOOTM_STATE_LOADOS | BOOTM_STATE_OS_CMDLINE | + BOOTM_STATE_OS_PREP | BOOTM_STATE_OS_FAKE_GO | + BOOTM_STATE_OS_GO, &images, 1); } int bootm_maybe_autostart(cmd_tbl_t *cmdtp, const char *cmd) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec_mxc: Fix timeouts during tftp transfer
Hi Marek, On Tuesday, September 17, 2013 5:00:58 AM, Marek Vasut wrote: > Dear Fabio Estevam, > > > From: Fabio Estevam > > > > Performing tftp transfers on mx28 results in random timeouts. > > > > Hector Palacios and Robert Hodaszi analyzed the root cause being related to > > the alignment of the 'buff' buffer inside fec_recv(). > > > > GCC versions such as 4.4/4.5 are more likely to exhibit such problem. > > > > Use ALLOC_CACHE_ALIGN_BUFFER() for making the proper alignment of buffer. > > > > Reported-by: Hector Palacios > > Tested-by: Oliver Metz > > Signed-off-by: Fabio Estevam > > --- > > drivers/net/fec_mxc.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c > > index 690e572..b423ff6 100644 > > --- a/drivers/net/fec_mxc.c > > +++ b/drivers/net/fec_mxc.c > > @@ -794,7 +794,7 @@ static int fec_recv(struct eth_device *dev) > > uint16_t bd_status; > > uint32_t addr, size, end; > > int i; > > - uchar buff[FEC_MAX_PKT_SIZE] __aligned(ARCH_DMA_MINALIGN); > > + ALLOC_CACHE_ALIGN_BUFFER(uchar, buff, FEC_MAX_PKT_SIZE); > > OK, it's gonna be safer this way, still what's the root cause of the issue? > > FEC_MAX_PKT_SIZE is 1536 (which is aligned to 32b and even 64b) > __aligned(ARCH_DMA_MINALIGN) aligns the stuff to 32b or 64b depending on CPU > > So how can the above not properly align the buffer? Is that a compiler bug > then? > > btw. using ALLOC_CACHE_ALIGN_BUFFER will be safer were someone to change > FEC_MAX_PKT_SIZE, the buffer would still be safe for cache flush/inval ops. I have encountered the same kind of alignment issue recently on something else. It looks like GCC for ARM just silently ignores the aligned attribute for auto (stacked) variables. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] bootm: use BOOTM_STATE_OS_CMDLINE flag for plain bootm
2013/9/6 Paul Burton : > A plain bootm used to call the architecture specific boot function with > no flags, but was modified by commit 35fc84fa "Refactor the bootm > command to reduce code duplication" to call the architecture specific > boot function multiple times with various flags in sequence. The > BOOTM_STATE_OS_CMDLINE flag was not used, indeed it seems that at least > ARM prepares the command line on BOOTM_STATE_OS_PREP. However on MIPS > since commit 59e8cbdb "MIPS: bootm: refactor initialisation of kernel > cmdline" the command line is not prepared in response to a > BOOTM_STATE_OS_PREP flag, only on BOOTM_STATE_OS_CMDLINE or a call with > no flags. The end result is that a combination of those 2 commits leads > to MIPS boards booting kernels with no command line arguments. > > An extra invocation of the architecture specific boot function with > BOOTM_STATE_OS_CMDLINE fixes this. > > Signed-off-by: Paul Burton > --- > common/cmd_bootm.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c > index 1685c14..b8255eb 100644 > --- a/common/cmd_bootm.c > +++ b/common/cmd_bootm.c > @@ -797,8 +797,9 @@ int do_bootm(cmd_tbl_t *cmdtp, int flag, int argc, char * > const argv[]) > > return do_bootm_states(cmdtp, flag, argc, argv, BOOTM_STATE_START | > BOOTM_STATE_FINDOS | BOOTM_STATE_FINDOTHER | > - BOOTM_STATE_LOADOS | BOOTM_STATE_OS_PREP | > - BOOTM_STATE_OS_FAKE_GO | BOOTM_STATE_OS_GO, &images, 1); > + BOOTM_STATE_LOADOS | BOOTM_STATE_OS_CMDLINE | > + BOOTM_STATE_OS_PREP | BOOTM_STATE_OS_FAKE_GO | > + BOOTM_STATE_OS_GO, &images, 1); > } > > int bootm_maybe_autostart(cmd_tbl_t *cmdtp, const char *cmd) > -- > 1.8.3.4 > > you should also add BOOTM_STATE_OS_BD_T. Though it is not used by MIPS, it is also needed if single call of bootm should execute all available bootm sub-commands. The patch is already assigned to Tom in patchwork, so I hope he'll pick it up for 2013.10. -- Best regards, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec_mxc: Fix timeouts during tftp transfer
Dear Benoît Thébaudeau, In message <1135126743.1842859.1379415574013.javamail.zim...@advansee.com> you wrote: > > > So how can the above not properly align the buffer? Is that a compiler bug > > then? > > > > btw. using ALLOC_CACHE_ALIGN_BUFFER will be safer were someone to change > > FEC_MAX_PKT_SIZE, the buffer would still be safe for cache flush/inval ops. > > I have encountered the same kind of alignment issue recently on something > else. > It looks like GCC for ARM just silently ignores the aligned attribute for auto > (stacked) variables. I would really like to see the generated code from such a system, so we verify if this is indeed true, or if something else is causing such issues. Even if the suggested patch fixes the current problem, it leaves a bad feeling as it's only based on speculation about the causes. 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 Brain off-line, please wait. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/5] Add device tree support for VxWorks
Hello Wolfgang and All, The next release of VxWorks will adopt device tree as its hardware description mechanism (for PowerPC and ARM), thus requiring boot interface changes for these two architechtures. And we would like to better support U-Boot with our operating system, because almost all the PowerPC and ARM boards that we support come with U-Boot pre-flashed and we would like to create better experience for our users. Currently, U-Boot provides a 'bootvx' command (bootm internally uses bootvx) to load and run VxWorks image (for both ELF format or raw binary), for example: bootvx 0x100 or just: bootvx if the environmental variable 'loadaddr' is set. The 'bootvx' will setup bootline and jump to the VxWorks entry using the following calling convention: (void)(*entry)(int arg /* 0 */) With the new VxWorks, the kernel entry interface for PowerPC is going to be changed to conform to the ePAPR standard, and for ARM, we need deivce tree's physical address to be passed to the kernel like this: (void)(*entry)(void *fdt_addr) And VxWorks bootline will be saved into deivce tree's 'bootargs' node as specified by the ePAPR (for both PowerPC and ARM). The 'bootvx' commnad stays unchaged, and is still avalaible under the configuration option CONFIG_CMD_ELF for older kernels. A new option CONFIG_BOOTM_VXWORKS is added for bootm to align with other bootm supported operating systems. So the do_bootm_vxworks will work wit new versions of VxWorks which need device tree support, and do_bootvx will work with older VxWorks kernels as before. Thanks, Changes for v2: 1) seperating legacy do_bootvx code from do_bootm_vxworks, thus making do_bootm_vxworks only work with new kernels, old kernels can still use 'bootvx' 2) minor fixes to make code more clear Miao Yan (5): common/cmd_bootm.c: seperate do_bootm_vxworks related code from CONFIG_CMD_ELF. common/config_defaults.h: make CONFIG_BOOTM_VXWORKS default configuration common/cmd_bootm: extend do_bootm_vxworks to support the new VxWorks boot interface. common/fdt_support.c: avoid unintended return from fdt_fixup_memory_banks() doc/README.vxworks: add a document describing the new VxWorks boot interface arch/arm/lib/bootm.c | 23 + arch/powerpc/lib/bootm.c | 55 +++ common/cmd_bootm.c| 80 - common/fdt_support.c |5 +-- doc/README.vxworks| 34 +++ include/common.h |4 +++ include/config_defaults.h |1 + include/vxworks.h |3 ++ 8 files changed, 194 insertions(+), 11 deletions(-) create mode 100644 doc/README.vxworks -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/5] common/config_defaults.h: make CONFIG_BOOTM_VXWORKS default configuration
Signed-off-by: Miao Yan --- Changes for v2: none include/config_defaults.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/config_defaults.h b/include/config_defaults.h index 567b46c..ad08c1d 100644 --- a/include/config_defaults.h +++ b/include/config_defaults.h @@ -14,6 +14,7 @@ #define CONFIG_BOOTM_NETBSD 1 #define CONFIG_BOOTM_PLAN9 1 #define CONFIG_BOOTM_RTEMS 1 +#define CONFIG_BOOTM_VXWORKS 1 #define CONFIG_GZIP 1 #define CONFIG_ZLIB 1 -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 5/5] doc/README.vxworks: add a document describing the new VxWorks boot interface
Signed-off-by: Miao Yan --- Changes for v2: none doc/README.vxworks | 34 ++ 1 file changed, 34 insertions(+) create mode 100644 doc/README.vxworks diff --git a/doc/README.vxworks b/doc/README.vxworks new file mode 100644 index 000..08c3813 --- /dev/null +++ b/doc/README.vxworks @@ -0,0 +1,34 @@ +From VxWorks 6.9+ (not include 6.9), VxWorks starts adopting device tree as its hardware +decription mechansim (for PowerPC and ARM), thus requiring boot interface changes. +This section will describe the new interface. + +For PowerPC, the calling convention of the new VxWorks entry point conforms to the ePAPR standard[1], +which is shown below (see ePAPR for more details): + +void (*kernel_entry)(ulong fdt_addr, + ulong r4 /* 0 */, ulong r5 /* 0 */, + ulong r6 /* EPAPR_MAGIC */ + ulong r7 /* boot IMA */, + ulong r8 /* 0 */, ulong r9 /* 0 */) + +For ARM, the calling convention is show below: + +void (*kernel_entry)(void *fdt_addr) + +When booting new VxWorks kernel (uImage format), the parameters passed to bootm is like below: + +bootm - + +for example, booting p2020rdb kernel: (kernel is placed at address 0x100 and device tree blob +is places at address 0xf00) + +setenv bootargs "gei(0,0)." +tftp 0x100 vxWorks.uboot +tftp 0xf00 p2020rdb.dtb +bootm 0x100 - 0xf00 + +The second parameter to bootm is always '-' for VxWorks (VxWorks kernel doesn't make use of initrd) + +The bootvx command still works as it was for older kernels. + +[1] www.power.org -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/5] common/cmd_bootm.c: seperate do_bootm_vxworks related code from CONFIG_CMD_ELF.
do_bootm_vxworks now is available under the configuration option
CONFIG_BOOTM_VXWORKS, thus aligned with other operating systems
that supported by bootm command. The bootvx command still depneds
on CONFIG_CMD_ELF.
Signed-off-by: Miao Yan
---
Changes for v2: none
common/cmd_bootm.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index b07b0f4..973c9f5 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -120,8 +120,10 @@ static boot_os_fn do_bootm_ose;
#if defined(CONFIG_BOOTM_PLAN9)
static boot_os_fn do_bootm_plan9;
#endif
-#if defined(CONFIG_CMD_ELF)
+#if defined(CONFIG_BOOTM_VXWORKS)
static boot_os_fn do_bootm_vxworks;
+#endif
+#if defined(CONFIG_CMD_ELF)
static boot_os_fn do_bootm_qnxelf;
int do_bootvx(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]);
int do_bootelf(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]);
@@ -149,8 +151,10 @@ static boot_os_fn *boot_os[] = {
#if defined(CONFIG_BOOTM_PLAN9)
[IH_OS_PLAN9] = do_bootm_plan9,
#endif
-#if defined(CONFIG_CMD_ELF)
+#if defined(CONFIG_BOOTM_VXWORKS)
[IH_OS_VXWORKS] = do_bootm_vxworks,
+#endif
+#if defined(CONFIG_CMD_ELF)
[IH_OS_QNX] = do_bootm_qnxelf,
#endif
#ifdef CONFIG_INTEGRITY
@@ -1683,7 +1687,7 @@ static int do_bootm_plan9(int flag, int argc, char *
const argv[],
}
#endif /* CONFIG_BOOTM_PLAN9 */
-#if defined(CONFIG_CMD_ELF)
+#if defined(CONFIG_BOOTM_VXWORKS)
static int do_bootm_vxworks(int flag, int argc, char * const argv[],
bootm_headers_t *images)
{
@@ -1703,11 +1707,16 @@ static int do_bootm_vxworks(int flag, int argc, char *
const argv[],
sprintf(str, "%lx", images->ep); /* write entry-point into string */
setenv("loadaddr", str);
+
+#if defined(CONFIG_CMD_ELF)
do_bootvx(NULL, 0, 0, NULL);
+#endif
return 1;
}
+#endif
+#if defined(CONFIG_CMD_ELF)
static int do_bootm_qnxelf(int flag, int argc, char * const argv[],
bootm_headers_t *images)
{
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/5] common/cmd_bootm: extend do_bootm_vxworks to support the new VxWorks boot interface.
The next version VxWorks adopts device tree (for PowerPC and ARM) as its
hardware
description mechanism. For PowerPC, the boot interface conforms to
the ePAPR standard, which is:
void (*kernel_entry)(ulong fdt_addr,
ulong r4 /* 0 */,
ulong r5 /* 0 */,
ulong r6 /* EPAPR_MAGIC */, ulong r7 /* IMA size */,
ulong r8 /* 0 */, ulong r9 /* 0 */)
For ARM, the boot interface is:
void (*kernel_entry)(void *fdt_addr)
Signed-off-by: Miao Yan
---
Changes for v2:
1) remove legacy do_bootvx code from do_bootm_vxworks, thus
making do_bootm_vxworks work only with new kernels, old
kernels can still use 'bootvx'
2) minor fixes to make code more clear
arch/arm/lib/bootm.c | 23 ++
arch/powerpc/lib/bootm.c | 55 +
common/cmd_bootm.c | 77 ++
include/common.h |4 +++
include/vxworks.h|3 ++
5 files changed, 150 insertions(+), 12 deletions(-)
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index eefb456..6b8a951 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -308,3 +308,26 @@ int bootz_setup(ulong image, ulong *start, ulong *end)
}
#endif /* CONFIG_CMD_BOOTZ */
+
+#if defined(CONFIG_BOOTM_VXWORKS)
+void boot_prep_vxworks(bootm_headers_t *images)
+{
+#if defined(CONFIG_OF_LIBFDT)
+ int off;
+
+ if (images->ft_addr) {
+ off = fdt_path_offset(images->ft_addr, "/memory");
+ if (off < 0) {
+ if (arch_fixup_memory_node(images->ft_addr))
+ puts("## WARNING: fixup memory failed!\n");
+ }
+ }
+#endif
+ cleanup_before_linux();
+}
+void boot_jump_vxworks(bootm_headers_t *images)
+{
+ /* ARM VxWorks requires device tree physical address to be passed */
+ ((void (*)(void *))images->ep)(images->ft_addr);
+}
+#endif
diff --git a/arch/powerpc/lib/bootm.c b/arch/powerpc/lib/bootm.c
index e7153b0..5398092 100644
--- a/arch/powerpc/lib/bootm.c
+++ b/arch/powerpc/lib/bootm.c
@@ -277,3 +277,58 @@ static void set_clocks_in_mhz (bd_t *kbd)
#endif /* CONFIG_MPC5xxx */
}
}
+
+#if defined(CONFIG_BOOTM_VXWORKS)
+void boot_prep_vxworks(bootm_headers_t *images)
+{
+#if defined(CONFIG_OF_LIBFDT)
+ int off;
+ u64 base, size;
+
+ if (!images->ft_addr)
+ return;
+
+ base = (u64)gd->bd->bi_memstart;
+ size = (u64)gd->bd->bi_memsize;
+
+ off = fdt_path_offset(images->ft_addr, "/memory");
+ if (off < 0)
+ fdt_fixup_memory(images->ft_addr, base, size);
+
+#if defined(CONFIG_MP)
+#if defined(CONFIG_MPC85xx)
+ ft_fixup_cpu(images->ft_addr, base + size);
+ ft_fixup_num_cores(images->ft_addr);
+#elif defined(CONFIG_MPC86xx)
+ off = fdt_add_mem_rsv(images->ft_addr,
+ determin_mp_bootpg(NULL), (u64)4096);
+ if (off < 0)
+ printf("## WARNING %s: %s\n", __func__, fdt_strerror(off));
+ ft_fixup_num_cores(images->ft_addr);
+#endif
+ flush_cache((unsigned long)images->ft_addr, images->ft_len);
+#endif
+#endif
+}
+
+void boot_jump_vxworks(bootm_headers_t *images)
+{
+ /* PowerPC VxWorks boot interface conforms to the ePAPR standard
+* general purpuse registers:
+*
+* r3: Effective address of the device tree image
+* r4: 0
+* r5: 0
+* r6: ePAPR magic value
+* r7: shall be the size of the boot IMA in bytes
+* r8: 0
+* r9: 0
+* TCR: WRC = 0, no watchdog timer reset will occur
+*/
+ WATCHDOG_RESET();
+
+ ((void (*)(void *, ulong, ulong, ulong,
+ ulong, ulong, ulong))images->ep)(images->ft_addr,
+ 0, 0, EPAPR_MAGIC, getenv_bootm_mapsize(), 0, 0);
+}
+#endif
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 973c9f5..cf712c2 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -23,6 +23,11 @@
#include
#include
+#if defined(CONFIG_BOOTM_VXWORKS) && \
+ (defined(CONFIG_PPC) || defined(CONFIG_ARM))
+#include
+#endif
+
#if defined(CONFIG_CMD_USB)
#include
#endif
@@ -120,7 +125,8 @@ static boot_os_fn do_bootm_ose;
#if defined(CONFIG_BOOTM_PLAN9)
static boot_os_fn do_bootm_plan9;
#endif
-#if defined(CONFIG_BOOTM_VXWORKS)
+#if defined(CONFIG_BOOTM_VXWORKS) && \
+ (defined(CONFIG_PPC) || defined(CONFIG_ARM))
static boot_os_fn do_bootm_vxworks;
#endif
#if defined(CONFIG_CMD_ELF)
@@ -151,7 +157,8 @@ static boot_os_fn *boot_os[] = {
#if defined(CONFIG_BOOTM_PLAN9)
[IH_OS_PLAN9] = do_bootm_plan9,
#endif
-#if defined(CONFIG_BOOTM_VXWORKS)
+#if defined(CONFIG_BOOTM_VXWORKS) && \
+ (defined(CONFIG_PPC) || defined(CONFIG_ARM))
[IH_OS_VXWORKS] = do_bootm_vxworks,
#endif
#if defined(CONFIG_CMD_ELF)
@@ -337,7 +344,8 @@ static int bootm_find_other(cmd_tb
[U-Boot] [PATCH v2 4/5] common/fdt_support.c: avoid unintended return from fdt_fixup_memory_banks()
fdt_fixup_memory_banks() will add and update /memory node in
device tree blob. In the case that /memory node doesn't exist,
after adding a new one, this function returns error.
The correct behavior should be continuing to update its properties.
Signed-off-by: Miao Yan
---
Changes for v2: none
common/fdt_support.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index b034c98..a97a705 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -400,10 +400,11 @@ int fdt_fixup_memory_banks(void *blob, u64 start[], u64
size[], int banks)
nodeoffset = fdt_path_offset(blob, "/memory");
if (nodeoffset < 0) {
nodeoffset = fdt_add_subnode(blob, 0, "memory");
- if (nodeoffset < 0)
+ if (nodeoffset < 0) {
printf("WARNING: could not create /memory: %s.\n",
fdt_strerror(nodeoffset));
- return nodeoffset;
+ return nodeoffset;
+ }
}
err = fdt_setprop(blob, nodeoffset, "device_type", "memory",
sizeof("memory"));
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/10] USB: XHCI: Add xHCI host controller stack driver
Dear Marek Vasut, On 17 September 2013 12:07, Marek Vasut wrote: > Hi Minkyu, > > do you want to pick the exynos adjustments (04..10/10) via -samsung tree or > shall I take the whole set via -usb ? I'd be inclined to the later, since > it > will make things easier to keep in sync, but it might produce a merge > conflict. > Nonetheless, I'd like to apply this only for -next. > OK. Please take patchset to -usb. > > Thanks! > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > Thanks, Minkyu Kang. -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 3/3] samsung: trats2: add support for new board Trats2
Dear Piotr Wilczek,
On 29 August 2013 17:49, Piotr Wilczek wrote:
> This patch add support for a new Samsung board Trats2.
>
> Signed-off-by: Piotr Wilczek
> Signed-off-by: Kyungmin Park
> CC: Minkyu Kang
> ---
> MAINTAINERS |4 +
> board/samsung/trats2/Makefile | 34 +++
> board/samsung/trats2/trats2.c | 510
> +
> boards.cfg|1 +
> include/configs/trats2.h | 308 +
> 5 files changed, 857 insertions(+)
> create mode 100644 board/samsung/trats2/Makefile
> create mode 100644 board/samsung/trats2/trats2.c
> create mode 100644 include/configs/trats2.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 23965a8..dbc6b7b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1041,6 +1041,10 @@ Matthias Weisser
> jadecpu ARM926EJS (MB86R01 SoC)
> zmx25 ARM926EJS (imx25 SoC)
>
> +Piotr Wilczek
> +
> + trats2 ARM ARMV7 (EXYNOS4412 SoC)
> +
>
MAINTAINERS and boards.cfg are reformatted.
Please check it.
Josh Wu
> at91sam9n12ek ARM926EJS (AT91SAM9N12 SoC)
>
> diff --git a/board/samsung/trats2/Makefile b/board/samsung/trats2/Makefile
> new file mode 100644
> index 000..4cc3f10
> --- /dev/null
> +++ b/board/samsung/trats2/Makefile
> @@ -0,0 +1,34 @@
> +#
> +# Copyright (c) 2000 - 2011 Samsung Electronics Co., Ltd. All rights
> reserved.
> +# Sanghee Kim
> +#
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +
> +include $(TOPDIR)/config.mk
> +
> +LIB= $(obj)lib$(BOARD).o
> +
> +COBJS-y:= trats2.o
> +
> +SRCS:= $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
> +OBJS := $(addprefix $(obj),$(COBJS-y))
> +
> +
> +$(LIB):$(obj).depend $(OBJS)
> + $(call cmd_link_o_target, $(OBJS))
> +
> +clean:
> + rm -f $(OBJS)
> +
> +distclean: clean
> + rm -f $(LIB) core *.bak $(obj).depend
> +
> +#
> +
> +# defines $(obj).depend target
> +include $(SRCTREE)/rules.mk
> +
> +sinclude $(obj).depend
> +
> +#
> diff --git a/board/samsung/trats2/trats2.c b/board/samsung/trats2/trats2.c
> new file mode 100644
> index 000..e8dc602
> --- /dev/null
> +++ b/board/samsung/trats2/trats2.c
> @@ -0,0 +1,510 @@
> +/*
> + * Copyright (c) 2000 - 2013 Samsung Electronics Co., Ltd. All rights
> reserved.
> + * Sanghee Kim
> + * Piotr Wilczek
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +static struct exynos4x12_gpio_part1 *gpio1;
> +static struct exynos4x12_gpio_part2 *gpio2;
> +
> +static unsigned int board_rev = -1;
> +
> +static inline u32 get_model_rev(void);
> +
> +static void check_hw_revision(void)
> +{
> + int modelrev = 0;
> + int i;
> +
> + gpio2 = (struct exynos4x12_gpio_part2 *)EXYNOS4X12_GPIO_PART2_BASE;
> +
> + /*
> +* GPM1[1:0]: MODEL_REV[1:0]
> +* Don't set as pull-none for these N/C pin.
> +* TRM say that it may cause unexcepted state and leakage current.
> +* and pull-none is only for output function.
> +*/
> + for (i = 0; i < 2; i++)
> + s5p_gpio_cfg_pin(&gpio2->m1, i, GPIO_INPUT);
> +
> + /* GPM1[5:2]: HW_REV[3:0] */
> + for (i = 2; i < 6; i++) {
> + s5p_gpio_cfg_pin(&gpio2->m1, i, GPIO_INPUT);
> + s5p_gpio_set_pull(&gpio2->m1, i, GPIO_PULL_NONE);
> + }
> +
> + /* GPM1[1:0]: MODEL_REV[1:0] */
> + for (i = 0; i < 2; i++)
> + modelrev |= (s5p_gpio_get_value(&gpio2->m1, i) << i);
> +
> + /* board_rev[15:8] = model */
> + board_rev = modelrev << 8;
> +}
> +
> +#ifdef CONFIG_DISPLAY_BOARDINFO
> +int checkboard(void)
> +{
> + puts("Board:\tTRATS2\n");
> + return 0;
> +}
> +#endif
> +
> +static void show_hw_revision(void)
> +{
> + printf("HW Revision:\t0x%04x\n", board_rev);
> +}
> +
> +u32 get_board_rev(void)
> +{
> + return board_rev;
> +}
> +
> +static inline u32 get_model_rev(void)
> +{
> + return (board_rev >> 8) & 0xff;
> +}
> +
> +static void board_external_gpio_init(void)
> +{
> + gpio2 = (struct exynos4x12_gpio_part2 *)EXYNOS4X12_GPIO_PART2_BASE;
> +
> + /*
> +* some pins which in alive block are connected with external
> pull-up
> +* but it's default setting is pull-down.
> +* if that pin set as input then that floated
> +*/
> +
> + s5p_gpio_set_pull(&gpio2->x0, 2, GPIO_PULL_NONE); /*
> PS_ALS_INT */
> + s5p_gpio_set_pull(&gpio2->x0, 4, GPIO_PULL_NONE); /*
> TSP_nINT */
> + s5p_gpio_set_pull(&gpio2->
Re: [U-Boot] [PATCH V4 1/3] power:battery: add battery support for Trats2 board
On 11 September 2013 19:48, Lukasz Majewski wrote: > Hi Minkyu, > > > Dear Piotr Wilczek, > > > > On 30/08/13 15:00, Piotr Wilczek wrote: > > > Dear Minkyu Kang, > > > > > >> -Original Message- > > >> From: Minkyu Kang [mailto:mk7.k...@samsung.com] > > >> Sent: Friday, August 30, 2013 6:39 AM > > >> To: Piotr Wilczek > > >> Cc: u-boot@lists.denx.de; Kyungmin Park; Lukasz Majewski > > >> Subject: Re: [PATCH V4 1/3] power:battery: add battery support for > > >> Trats2 board > > >> > > >> Dear Piotr Wilczek, > > >> > > >> On 29/08/13 17:49, Piotr Wilczek wrote: > > >>> Signed-off-by: Piotr Wilczek > > >>> Signed-off-by: Kyungmin Park > > >>> --- > > >>> drivers/power/battery/Makefile |1 + > > >>> drivers/power/battery/bat_trats2.c | 65 > > >> > > >>> 2 files changed, 66 insertions(+) > > >>> create mode 100644 drivers/power/battery/bat_trats2.c > > >>> > > >> > > >> bat_trats2.c is almost same with bat_trat.c I think, it can be > > >> reuse bat_trat.c Do you have special reason to add new file? > > > > > > If several boards would use that file, any change to it will affect > > > all these boards. Also why it should be named 'bat_trats' then? > > > > OK. I understood what you said. > > > > But, I don't understand why this file (or directory - battery) is > > needed. It is not a driver, > > In the pmic framework the battery is treated in the same way as MUIC, > PMIC, FG. This is the reason for separate directory. > > > it just settings for specific board. > > If so, why don't you move to board file instead? > > > I would like to avoid code duplication. > > > > Do we need to make new files for every boards? > > The problem here is with the way we are handling charging. Trats uses > the "busy loop" approach. > In the TRATS2 the busy loop is omitted, and only charging is enabled. > > Those are two different approaches for handling charging (this may also > depend on PMIC capabilities). > > > > > > Lukasz, > > how you think? > > For the PMIC itself - it needs to be rewritten to be prepared for multi > board support for u-boot. It doesn't support it now (as Tom pointed > out recently). > > Also - as shown with PMIC batteries - different charging "profiles" are > needed. > > The bat_trats.c, bat_trats2.c [*] would be renamed to bat_profile1.c and > bat_profile2.c. Also some common code from [*] would be extracted. > > Now it seems, that acceptance of Trats2 board depends on the > shortcoming in the PMIC framework. > > My proposition - accept the Trats2 code (since it works and is tested). > > The battery code is going to be cleaned up when we finish and post PMIC > framework rework. > > I will post request for PMIC v3 requirements soon. > OK. > > > > > > > > > Other reason is that I don't want to block command line while > > > charging battery as in 'bat_trats'. > > > > > > Anyway it's not that important. I will modify it the way you prefer. > > > > > > Best regards, > > > Piotr Wilczek > > > > > >> > > >> Thanks, > > >> Minkyu Kang. > > > > > > > > > > > > > Thanks, > > Minkyu Kang. > > > -- > Best regards, > > Lukasz Majewski > > Samsung R&D Institute Poland (SRPOL) | Linux Platform Group > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > Thanks, Minkyu Kang. -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/10] arm: vf610: fix anadig register struct
On Tue, Sep 17, 2013 at 7:45 AM, Marcel Ziswiler wrote:
> The anadig_reg structure started at the wrong offset (fixed by adding
> resvA[4]), was missing some reserved field required for alignment
> purpose (resvB[3] between pll4_denom and pll6_ctrl) and further
> contained too short a reserved field causing further miss-alignment
> (resv10[7]).
>
> Discovered and tested by temporarily putting the following debug
> instrumentation into board_init():
> struct anadig_reg *anadig = (struct anadig_reg *)ANADIG_BASE_ADDR;
> printf("&anadig->pll3_ctrl=0x%p\n", &anadig->pll3_ctrl);
> printf("&anadig->pll5_ctrl=0x%p\n", &anadig->pll5_ctrl);
>
> Signed-off-by: Marcel Ziswiler
I agree with the way to fix it but it is a little bit hard to get it
is a 'reserved'; we used reserved_ to make it more explicit.
Take a look at
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/include/asm/arch-mxs/regs-power-mx28.h;h=9528e3ce9ad805ec30a1c0595924dbddb296c50f
for an usage example.
--
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
[U-Boot] [PATCH] arm: vf610: initial integration for colibri vf50
Add initial Colibri VF50 support based off Freescale's implementation
for the Vybrid Tower System TWR-VF65GS10:
- New machine ID.
- Default UART_A on SCI0.
- FEC1 only.
- Enabled command line editing.
- PLL5 based RMII clocking (e.g. no external crystal).
- UART_A and UART_C I/O muxing.
Tested on early Colibri VF50 prototypes V1.0a booting off SD card
(mandatory for initial loading). Loading Linux kernel off SD card or by
TFTP.
Signed-off-by: Marcel Ziswiler
---
board/toradex/colibri_vf50/Makefile | 26 ++
board/toradex/colibri_vf50/colibri_vf50.c | 413 +
board/toradex/colibri_vf50/imximage.cfg | 17 ++
boards.cfg|1 +
include/configs/colibri_vf50.h| 224
5 files changed, 681 insertions(+)
create mode 100644 board/toradex/colibri_vf50/Makefile
create mode 100644 board/toradex/colibri_vf50/colibri_vf50.c
create mode 100644 board/toradex/colibri_vf50/imximage.cfg
create mode 100644 include/configs/colibri_vf50.h
diff --git a/board/toradex/colibri_vf50/Makefile
b/board/toradex/colibri_vf50/Makefile
new file mode 100644
index 000..43d21ab
--- /dev/null
+++ b/board/toradex/colibri_vf50/Makefile
@@ -0,0 +1,26 @@
+#
+# Copyright 2013 Toradex, Inc.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS := $(BOARD).o
+
+SRCS := $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+ $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/toradex/colibri_vf50/colibri_vf50.c
b/board/toradex/colibri_vf50/colibri_vf50.c
new file mode 100644
index 000..f65f10d
--- /dev/null
+++ b/board/toradex/colibri_vf50/colibri_vf50.c
@@ -0,0 +1,413 @@
+/*
+ * Copyright 2013 Toradex, Inc.
+ *
+ * Based on vf610twr.c:
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define UART_PAD_CTRL (PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
+ PAD_CTL_DSE_25ohm | PAD_CTL_OBE_IBE_ENABLE)
+
+#define ESDHC_PAD_CTRL (PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_HIGH | \
+ PAD_CTL_DSE_20ohm | PAD_CTL_OBE_IBE_ENABLE)
+
+#define ENET_PAD_CTRL (PAD_CTL_PUS_47K_UP | PAD_CTL_SPEED_HIGH | \
+ PAD_CTL_DSE_50ohm | PAD_CTL_OBE_IBE_ENABLE)
+
+void setup_iomux_ddr(void)
+{
+ static const iomux_v3_cfg_t ddr_pads[] = {
+ VF610_PAD_DDR_A15__DDR_A_15,
+ VF610_PAD_DDR_A14__DDR_A_14,
+ VF610_PAD_DDR_A13__DDR_A_13,
+ VF610_PAD_DDR_A12__DDR_A_12,
+ VF610_PAD_DDR_A11__DDR_A_11,
+ VF610_PAD_DDR_A10__DDR_A_10,
+ VF610_PAD_DDR_A9__DDR_A_9,
+ VF610_PAD_DDR_A8__DDR_A_8,
+ VF610_PAD_DDR_A7__DDR_A_7,
+ VF610_PAD_DDR_A6__DDR_A_6,
+ VF610_PAD_DDR_A5__DDR_A_5,
+ VF610_PAD_DDR_A4__DDR_A_4,
+ VF610_PAD_DDR_A3__DDR_A_3,
+ VF610_PAD_DDR_A2__DDR_A_2,
+ VF610_PAD_DDR_A1__DDR_A_1,
+ VF610_PAD_DDR_BA2__DDR_BA_2,
+ VF610_PAD_DDR_BA1__DDR_BA_1,
+ VF610_PAD_DDR_BA0__DDR_BA_0,
+ VF610_PAD_DDR_CAS__DDR_CAS_B,
+ VF610_PAD_DDR_CKE__DDR_CKE_0,
+ VF610_PAD_DDR_CLK__DDR_CLK_0,
+ VF610_PAD_DDR_CS__DDR_CS_B_0,
+ VF610_PAD_DDR_D15__DDR_D_15,
+ VF610_PAD_DDR_D14__DDR_D_14,
+ VF610_PAD_DDR_D13__DDR_D_13,
+ VF610_PAD_DDR_D12__DDR_D_12,
+ VF610_PAD_DDR_D11__DDR_D_11,
+ VF610_PAD_DDR_D10__DDR_D_10,
+ VF610_PAD_DDR_D9__DDR_D_9,
+ VF610_PAD_DDR_D8__DDR_D_8,
+ VF610_PAD_DDR_D7__DDR_D_7,
+ VF610_PAD_DDR_D6__DDR_D_6,
+ VF610_PAD_DDR_D5__DDR_D_5,
+ VF610_PAD_DDR_D4__DDR_D_4,
+ VF610_PAD_DDR_D3__DDR_D_3,
+ VF610_PAD_DDR_D2__DDR_D_2,
+ VF610_PAD_DDR_D1__DDR_D_1,
+ VF610_PAD_DDR_D0__DDR_D_0,
+ VF610_PAD_DDR_DQM1__DDR_DQM_1,
+ VF610_PAD_DDR_DQM0__DDR_DQM_0,
+ VF610_PAD_DDR_DQS1__DDR_DQS_1,
+ VF610_PAD_DDR_DQS0__DDR_DQS_0,
+ VF610_PAD_DDR_RAS__DDR_RAS_B,
+ VF610_PAD_DDR_WE__DDR_WE_B,
+ VF610_PAD_DDR_ODT1__DDR_ODT_0,
+ VF610_PAD_DDR_ODT0__DDR_ODT_1,
+ };
+
+ imx_iomux_v3_setup_multiple_pads(ddr_pads, ARRAY_SIZE(ddr_pads));
+}
+
+void dd
[U-Boot] [PATCH 3/3] usb:g_dnl:dfu: Download gadget and DFU function code clean up
The download gadget code and DFU function lacks of proper declarations
for the case when a target board wants to use only one of available usb
functions.
Moreover the relevant declarations have been moved to consistent
localization (like ).
Signed-off-by: Lukasz Majewski
Cc: Marek Vasut
---
drivers/usb/gadget/f_dfu.h |3 ---
drivers/usb/gadget/g_dnl.c |2 +-
include/dfu.h |9 +
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/f_dfu.h b/drivers/usb/gadget/f_dfu.h
index 34a4dde..cc2c455 100644
--- a/drivers/usb/gadget/f_dfu.h
+++ b/drivers/usb/gadget/f_dfu.h
@@ -82,7 +82,4 @@ struct dfu_function_descriptor {
__le16 wTransferSize;
__le16 bcdDFUVersion;
} __packed;
-
-/* configuration-specific linkup */
-int dfu_add(struct usb_configuration *c);
#endif /* __F_DFU_H_ */
diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c
index 29d08a3..40868c0 100644
--- a/drivers/usb/gadget/g_dnl.c
+++ b/drivers/usb/gadget/g_dnl.c
@@ -15,7 +15,7 @@
#include
#include
-#include "f_dfu.h"
+#include
#include "gadget_chips.h"
#include "composite.c"
diff --git a/include/dfu.h b/include/dfu.h
index 6f25341..f3f7f0b 100644
--- a/include/dfu.h
+++ b/include/dfu.h
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
enum dfu_device_type {
DFU_DEV_MMC = 1,
@@ -139,4 +140,12 @@ static inline int dfu_fill_entity_nand(struct dfu_entity
*dfu, char *s)
}
#endif
+#ifdef CONFIG_DFU_FUNCTION
+int dfu_add(struct usb_configuration *c);
+#else
+int dfu_add(struct usb_configuration *c)
+{
+ return 0;
+}
+#endif
#endif /* __DFU_ENTITY_H_ */
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] usb:g_dnl:ums: Conditional compilation for mass storage function (f_mass_storage)
The mass storage composite function is now compiled in only when
CONFIG_USB_GADGET_MASS_STORAGE is defined.
Such change provides binary size reduction for boards which use USB
download gadget (like am335x_evm) with DFU, but don't use UMS.
For example at am335x_evm board reduction is more than 2KiB for
text and around 120B for data.
Signed-off-by: Lukasz Majewski
Cc: Marek Vasut
---
drivers/usb/gadget/Makefile |1 +
drivers/usb/gadget/g_dnl.c |2 +-
include/usb_mass_storage.h |9 +
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index 4d51f59..1590c4a 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -23,6 +23,7 @@ COBJS-$(CONFIG_USB_GADGET_S3C_UDC_OTG) += s3c_udc_otg.o
COBJS-$(CONFIG_USB_GADGET_FOTG210) += fotg210.o
COBJS-$(CONFIG_USBDOWNLOAD_GADGET) += g_dnl.o
COBJS-$(CONFIG_DFU_FUNCTION) += f_dfu.o
+COBJS-$(CONFIG_USB_GADGET_MASS_STORAGE) += f_mass_storage.o
endif
ifdef CONFIG_USB_ETHER
COBJS-y += ether.o
diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c
index a3e05a8..19011bf 100644
--- a/drivers/usb/gadget/g_dnl.c
+++ b/drivers/usb/gadget/g_dnl.c
@@ -15,11 +15,11 @@
#include
#include
+#include
#include "f_dfu.h"
#include "gadget_chips.h"
#include "composite.c"
-#include "f_mass_storage.c"
/*
* One needs to define the following:
diff --git a/include/usb_mass_storage.h b/include/usb_mass_storage.h
index 35cdcc3..e08deb4 100644
--- a/include/usb_mass_storage.h
+++ b/include/usb_mass_storage.h
@@ -11,6 +11,7 @@
#define SECTOR_SIZE0x200
#include
+#include
struct ums_device {
struct mmc *mmc;
@@ -39,4 +40,12 @@ extern struct ums_board_info *board_ums_init(unsigned int,
extern int usb_gadget_handle_interrupts(void);
extern int fsg_main_thread(void *);
+#ifdef CONFIG_USB_GADGET_MASS_STORAGE
+int fsg_add(struct usb_configuration *c);
+#else
+int fsg_add(struct usb_configuration *c)
+{
+ return 0;
+}
+#endif
#endif /* __USB_MASS_STORAGE_H__ */
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] usb:gadget:Remove redundant #includes for USB composite gadget and its functions
Only the requires error.h include. Hence, several includes of error.h at USB gadget functions are not needed. Moreover unnecessary malloc.h includes were also removed. Signed-off-by: Lukasz Majewski Cc: Marek Vasut --- common/cmd_dfu.c |3 --- common/cmd_usb_mass_storage.c |1 - drivers/usb/gadget/g_dnl.c|1 - include/linux/usb/gadget.h|1 + 4 files changed, 1 insertion(+), 5 deletions(-) diff --git a/common/cmd_dfu.c b/common/cmd_dfu.c index d3658cf..7ce92ce 100644 --- a/common/cmd_dfu.c +++ b/common/cmd_dfu.c @@ -9,10 +9,7 @@ */ #include -#include -#include #include -#include #include static int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) diff --git a/common/cmd_usb_mass_storage.c b/common/cmd_usb_mass_storage.c index 33a4715..ccf7195 100644 --- a/common/cmd_usb_mass_storage.c +++ b/common/cmd_usb_mass_storage.c @@ -5,7 +5,6 @@ * SPDX-License-Identifier:GPL-2.0+ */ -#include #include #include #include diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c index 19011bf..29d08a3 100644 --- a/drivers/usb/gadget/g_dnl.c +++ b/drivers/usb/gadget/g_dnl.c @@ -7,7 +7,6 @@ * SPDX-License-Identifier:GPL-2.0+ */ -#include #include #include diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h index 220d068..a8a5763 100644 --- a/include/linux/usb/gadget.h +++ b/include/linux/usb/gadget.h @@ -18,6 +18,7 @@ #ifndef __LINUX_USB_GADGET_H #define __LINUX_USB_GADGET_H +#include #include struct usb_ep; -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec_mxc: Fix timeouts during tftp transfer
Dear Wolfgang Denk,
On Tuesday, September 17, 2013 1:47:02 PM, Wolfgang Denk wrote:
> Dear Benoît Thébaudeau,
>
> In message <1135126743.1842859.1379415574013.javamail.zim...@advansee.com>
> you wrote:
> >
> > > So how can the above not properly align the buffer? Is that a compiler
> > > bug
> > > then?
> > >
> > > btw. using ALLOC_CACHE_ALIGN_BUFFER will be safer were someone to change
> > > FEC_MAX_PKT_SIZE, the buffer would still be safe for cache flush/inval
> > > ops.
> >
> > I have encountered the same kind of alignment issue recently on something
> > else.
> > It looks like GCC for ARM just silently ignores the aligned attribute for
> > auto
> > (stacked) variables.
>
> I would really like to see the generated code from such a system, so
> we verify if this is indeed true, or if something else is causing such
> issues.
>
> Even if the suggested patch fixes the current problem, it leaves a bad
> feeling as it's only based on speculation about the causes.
Here is a basic alignment test that I have run on ARM:
---
#include
void foo(void *var)
{
printf("var=0x%.8x\n", (int)var);
}
int main(void)
{
unsigned char var[1536] __attribute__((__aligned__(64)));
unsigned int i;
for (i = 0; i < 10; i++)
foo(&var);
return 0;
}
---
I have built it using:
$ cross-gcc align.c -o align
With GCC 4.5.4, the kind of output that I get is 'var=0x7ee1a6b8' (i.e. not
aligned as requested).
The generated asm is:
---
849c :
849c: e92d4800push{fp, lr}
84a0: e28db004add fp, sp, #4
84a4: e24ddc06sub sp, sp, #1536 ; 0x600
84a8: e24dd008sub sp, sp, #8
84ac: e3a03000mov r3, #0
84b0: e50b3008str r3, [fp, #-8]
84b4: ea07b 84d8
84b8: e24b3c06sub r3, fp, #1536 ; 0x600
84bc: e2433004sub r3, r3, #4
84c0: e2433008sub r3, r3, #8
84c4: e1a3mov r0, r3
84c8: ebe7bl 846c
84cc: e51b3008ldr r3, [fp, #-8]
84d0: e2833001add r3, r3, #1
84d4: e50b3008str r3, [fp, #-8]
84d8: e51b3008ldr r3, [fp, #-8]
84dc: e3530009cmp r3, #9
84e0: 9af4bls 84b8
84e4: e3a03000mov r3, #0
84e8: e1a3mov r0, r3
84ec: e24bd004sub sp, fp, #4
84f0: e8bd8800pop {fp, pc}
---
With GCC 4.6.2, the kind of output that I get is 'var=0x7e808680' (i.e. aligned
as requested).
The generated asm is:
---
83a4 :
83a4: e92d4810push{r4, fp, lr}
83a8: e28db008add fp, sp, #8
83ac: e24dd00csub sp, sp, #12
83b0: e24ddd19sub sp, sp, #1600 ; 0x640
83b4: e1a0300dmov r3, sp
83b8: e283303fadd r3, r3, #63 ; 0x3f
83bc: e1a03323lsr r3, r3, #6
83c0: e1a04303lsl r4, r3, #6
83c4: e3a03000mov r3, #0
83c8: e50b3010str r3, [fp, #-16]
83cc: ea04b 83e4
83d0: e1a4mov r0, r4
83d4: ebe6bl 8374
83d8: e51b3010ldr r3, [fp, #-16]
83dc: e2833001add r3, r3, #1
83e0: e50b3010str r3, [fp, #-16]
83e4: e51b3010ldr r3, [fp, #-16]
83e8: e3530009cmp r3, #9
83ec: 9af7bls 83d0
83f0: e3a03000mov r3, #0
83f4: e1a3mov r0, r3
83f8: e24bd008sub sp, fp, #8
83fc: e8bd8810pop {r4, fp, pc}
---
I did not succeed to duplicate the issue with GCC 4.6.2, while GCC 4.5.4 almost
always produces an unexpected alignment for auto variables.
Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 01/10] usb: Move 'bmRequestType' USB device request macros from EHCI header
Dear Vivek Gautam, > Hi Marek, > > On Tue, Sep 17, 2013 at 8:32 AM, Marek Vasut wrote: > > Dear Vivek Gautam, > > > >> Macros defining bmRequestType field of USB device request, > >> given in table 9.2 USB 2.0 spec, are rather generic macros > >> which can be further used by other Host controller stacks. > >> So moving them to usb_defs header. > >> > >> Signed-off-by: Vivek Gautam > >> Cc: Julius Werner > >> Cc: Simon Glass > >> Cc: Minkyu Kang > >> Cc: Dan Murphy > >> Cc: Marek Vasut > > > > Why not just use include/usb.h ? > > The bit field definitions for usb-types usb-recipient, and directions > are itself defined in usb_defs.h; > so i thought of keeping their combination just below it, so that it > would not be difficult to reference. > > Please let me know if you want me to move them to include/usb.h Ah, we already have usb_defs.h , then this is OK. The headers are mess and will eventually need cleanup too, not in this patchset of course. 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] MMC: DWMMC: Correct the CLKDIV register value
Hi Rajesh,
I guess we wait for an updated patch here?
Regards
-- Pantelis
On Sep 11, 2013, at 4:25 PM, Rajeshwari Birje wrote:
> Hi Jaehoon Chung,
>
> Thank you for comments,
>
>
>
> On Wed, Sep 11, 2013 at 11:31 AM, Jaehoon Chung
> wrote:
>> On 09/11/2013 02:28 PM, Rajeshwari Birje wrote:
>>> Hi All,
>>>
>>> Please do let me know if any comments on the same.
>>>
>>> Regards,
>>> Rajeshwari Shinde.
>>>
>>> On Thu, Aug 29, 2013 at 4:34 PM, Rajeshwari Birje
>>> wrote:
CCing the MMC Maintainer.
On Thu, Aug 29, 2013 at 4:22 PM, Rajeshwari S Shinde
wrote:
> This patch corrects the divider value written to CLKDIV register.
> Since SDCLKIN is divided inside controller by the DIVRATIO value set
> in the CLKSEL register, we need to use the same output clock value to
> calculate the CLKDIV value.
> as per user manual: cclk_in = SDCLKIN / (DIVRATIO + 1)
>
> Input parameter to mmc_clk is changed to dwmci_host, since
> we need the same to read DWMCI_CLKSEL register.
>
> This improves the read timing values for channel 0 on SMDK5250
> from 0.288sec to 0.144sec
>
> Signed-off-by: Rajeshwari S Shinde
> ---
> arch/arm/include/asm/arch-exynos/dwmmc.h | 4
> drivers/mmc/dw_mmc.c | 2 +-
> drivers/mmc/exynos_dw_mmc.c | 17 +++--
> include/dwmmc.h | 2 +-
> 4 files changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-exynos/dwmmc.h
> b/arch/arm/include/asm/arch-exynos/dwmmc.h
> index b9eca76..f1c8d8a 100644
> --- a/arch/arm/include/asm/arch-exynos/dwmmc.h
> +++ b/arch/arm/include/asm/arch-exynos/dwmmc.h
> @@ -14,6 +14,10 @@
> #define DWMCI_SET_DRV_CLK(x) ((x) << 16)
> #define DWMCI_SET_DIV_RATIO(x) ((x) << 24)
>
> +/* CLKSEL Register */
> +#define DWMCI_DIVRATIO_BIT 24
> +#define DWMCI_DIVRATIO_MASK0x7
> +
> #ifdef CONFIG_OF_CONTROL
> int exynos_dwmmc_init(const void *blob);
> #endif
> diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
> index a82ee17..3406bdd 100644
> --- a/drivers/mmc/dw_mmc.c
> +++ b/drivers/mmc/dw_mmc.c
> @@ -224,7 +224,7 @@ static int dwmci_setup_bus(struct dwmci_host *host,
> u32 freq)
> * host->bus_hz should be set from user.
> */
>if (host->mmc_clk)
> - sclk = host->mmc_clk(host->dev_index);
> + sclk = host->mmc_clk(host);
>else if (host->bus_hz)
>sclk = host->bus_hz;
>else {
> diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c
> index 4ef9fec..1ed4afe 100644
> --- a/drivers/mmc/exynos_dw_mmc.c
> +++ b/drivers/mmc/exynos_dw_mmc.c
> @@ -29,9 +29,22 @@ static void exynos_dwmci_clksel(struct dwmci_host
> *host)
>dwmci_writel(host, DWMCI_CLKSEL, host->clksel_val);
> }
>
> -unsigned int exynos_dwmci_get_clk(int dev_index)
> +unsigned int exynos_dwmci_get_clk(struct dwmci_host *host)
> {
> - return get_mmc_clk(dev_index);
> + unsigned long sclk;
> + int8_t clk_div;
> +
> + /*
> +* Since SDCLKIN is divided inside controller by the DIVRATIO
> +* value set in the CLKSEL register, we need to use the same
> output
> +* clock value to calculate the CLKDIV value.
> +* as per user manual:cclk_in = SDCLKIN / (DIVRATIO + 1)
> +*/
> + clk_div = ((dwmci_readl(host, DWMCI_CLKSEL) >> DWMCI_DIVRATIO_BIT)
> + & DWMCI_DIVRATIO_MASK) + 1;
>> I known DIVRATIO is only exynos5 feature..
>> And If clk_div is set to 0, then clk_phase/clk_strength is also set to 0.
>>
>> And I think we can fixed this problem into exynos_dwmci_add_port.
>>
>> Best Regards,
>> Jaehoon Chung
>
> during the dwmci_setup_bus we call for mmc_clk, this is where the
> get_mmc_clk(host->dev_index) retruns you the parent clock but since
> we need the output of mux " cclk_in",
> added in the exynos_dwmci_get_clk.
> --
> Regards,
> Rajeshwari Shinde
>>
> + sclk = get_mmc_clk(host->dev_index);
> +
> + return sclk / clk_div;
> }
>
> /*
> diff --git a/include/dwmmc.h b/include/dwmmc.h
> index 08ced0b..26b53af 100644
> --- a/include/dwmmc.h
> +++ b/include/dwmmc.h
> @@ -138,7 +138,7 @@ struct dwmci_host {
>struct mmc *mmc;
>
>void (*clksel)(struct dwmci_host *host);
> - unsigned int (*mmc_clk)(int dev_index);
> + unsigned int (*mmc_clk)(struct dwmci_host *host);
> };
>
> struct dwmci_idmac {
> --
> 1.7.12.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/lis
Re: [U-Boot] [PATCH v4] usb: new board-specific USB init interface
Hello,
On 09/10/2013 06:10 PM, Mateusz Zalega wrote:
> This commit unifies board-specific USB initialization implementations
> under one symbol (usb_board_init), declaration of which is available in
> usb.h.
>
> New API allows selective initialization of USB controllers whenever needed.
>
> Signed-off-by: Mateusz Zalega
> Signed-off-by: Kyungmin Park
> Reviewed-by: Lukasz Majewski
> Cc: Marek Vasut
> Cc: Lukasz Majewski
I think, you should Cc respective board maintainers as well.
Acked-by: Igor Grinberg
> Change-Id: Ia78a1378f30a55dd14598c9a1a1b4b8a762e2cd8
> ---
> Changes since RFC (v1):
> - NVIDIA Tegra doesn't postpone its USB init anymore
> - board_usb_init()'s sole argument name was shortened
> - networking code comment style (/* blurb...) dropped
> - squashed RFC changes so that patch won't break bisect
>
> v2 changes:
> - commit message fixup
>
> v3 changes:
> - added 'index' argument to perform selective port initialization
>
> v4 changes:
> - board_usb_init_fail() renamed to board_usb_cleanup()
> - board_usb_cleanup() accepts controller index and init type
> - DFU and UMS commands don't init all USB controllers anymore
> - minor related fixes & refactorization
> ---
> arch/arm/include/asm/arch-tegra/usb.h | 3 +-
> arch/arm/include/asm/ehci-omap.h | 4 +--
> board/amcc/canyonlands/canyonlands.c | 5 +--
> board/balloon3/balloon3.c | 7 +++--
> board/compulab/cm_t35/cm_t35.c| 2 +-
> board/esd/apc405/apc405.c | 8 ++---
> board/esd/pmc440/pmc440.c | 8 ++---
> board/htkw/mcx/mcx.c | 2 +-
> board/icpdas/lp8x4x/lp8x4x.c | 7 +++--
> board/nvidia/common/board.c | 4 ++-
> board/samsung/trats/trats.c | 5 +--
> board/technexion/twister/twister.c| 2 +-
> board/teejet/mt_ventoux/mt_ventoux.c | 2 +-
> board/ti/beagle/beagle.c | 2 +-
> board/ti/omap5_uevm/evm.c | 2 +-
> board/ti/panda/panda.c| 2 +-
> board/toradex/colibri_pxa270/colibri_pxa270.c | 7 +++--
> board/trizepsiv/conxs.c | 7 +++--
> board/vpac270/vpac270.c | 7 +++--
> common/cmd_dfu.c | 31 +++
> common/cmd_usb_mass_storage.c | 44
> ++-
> common/usb.c | 5 +++
> drivers/dfu/dfu.c | 2 +-
> drivers/usb/host/ehci-omap.c | 12 ++--
> drivers/usb/host/ehci-tegra.c | 2 +-
> drivers/usb/host/ohci-hcd.c | 4 +--
> drivers/usb/host/ohci.h | 11 +++
> include/g_dnl.h | 2 --
> include/usb.h | 30 +-
> include/usb_mass_storage.h| 13 +++-
> 30 files changed, 138 insertions(+), 104 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-tegra/usb.h
> b/arch/arm/include/asm/arch-tegra/usb.h
> index f66257c..a1efd07 100644
> --- a/arch/arm/include/asm/arch-tegra/usb.h
> +++ b/arch/arm/include/asm/arch-tegra/usb.h
> @@ -131,8 +131,7 @@
> /* USB3_IF_USB_PHY_VBUS_SENSORS_0 */
> #define VBUS_VLD_STS (1 << 26)
>
> -
> /* Setup USB on the board */
> -int board_usb_init(const void *blob);
> +int usb_process_devicetree(const void *blob);
>
> #endif /* _TEGRA_USB_H_ */
> diff --git a/arch/arm/include/asm/ehci-omap.h
> b/arch/arm/include/asm/ehci-omap.h
> index ac83a53..c7bca05 100644
> --- a/arch/arm/include/asm/ehci-omap.h
> +++ b/arch/arm/include/asm/ehci-omap.h
> @@ -145,8 +145,8 @@ struct omap_ehci {
> struct ehci_hccr;
> struct ehci_hcor;
>
> -int omap_ehci_hcd_init(struct omap_usbhs_board_data *usbhs_pdata,
> - struct ehci_hccr **hccr, struct ehci_hcor **hcor);
> +int omap_ehci_hcd_init(int index, struct omap_usbhs_board_data *usbhs_pdata,
> +struct ehci_hccr **hccr, struct ehci_hcor **hcor);
> int omap_ehci_hcd_stop(void);
>
> #endif /* _OMAP_COMMON_EHCI_H_ */
> diff --git a/board/amcc/canyonlands/canyonlands.c
> b/board/amcc/canyonlands/canyonlands.c
> index cc36f45..395095e 100644
> --- a/board/amcc/canyonlands/canyonlands.c
> +++ b/board/amcc/canyonlands/canyonlands.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
>
> extern flash_info_t flash_info[CONFIG_SYS_MAX_FLASH_BANKS]; /* info for
> FLASH chips */
>
> @@ -188,7 +189,7 @@ int board_early_init_f(void)
> }
>
> #if defined(CONFIG_USB_OHCI_NEW) && defined(CONFIG_SYS_USB_OHCI_BOARD_INIT)
> -int usb_board_init(void)
> +int board_usb_init(int index, enum board_usb_init_type init)
> {
> struct board_bcsr *bcsr_data =
> (struct board_bcsr *)CONFIG_SYS_BCSR_BASE;
> @@ -229,7 +230,7 @@ int usb_board_sto
[U-Boot] How do ARM platform initialize DDR?
Albert, Pardon me if this is a dumb question. I have been working on powerpc platforms in the past. Now we (the developers I work with) are exploring ARM cores. I am searching how memory is initialized and found different solutions. Some platforms have memory ready before u-boot even starts, some simply write to a set of registers. I understand many platforms don't share the IP of DDR controller. I am wondering if there is generic DDR driver used by many ARM platforms, like the one we have for powerpc/mpc85xx SoCs. Regards, York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-boot] Some questions about BootStage functions
Hi Tiger, On Mon, Sep 16, 2013 at 11:09 PM, wrote: > Hi, Simon: > > I have some questions about bootstage functions.(common/bootstage.c) > > 1. mark_bootsage record relocation question > > board_init_f() will call mark_bootstage() function to record the elapsed > time when system > > From power on to board_init_f point. > > But after running board_init_f() function, uboot will relocate u-boot code > base. > > So, the boot stage record “board_init_f” would be abnormal ? ! > > Because i did not find any code to do relocation operation for boot stage > records. Please see bootstage_relocate(). > > 2. how to understand “start_us” fiedld in bootstage_record struct ? > > bootstage_start() function will init bootstage_record->start_us. > > But not find which file will call bootstage_start() . This is used by functions which want to measure accumulated time. bootstage_start() is called first, then bootstage_accum(). I have a few patches to add this for SPI flash, but have not sent them yet. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-mmc
Hi Tom, The following changes since commit 46ef4faed18196472eb95216b2f74c1397ecf024: Prepare v2013.10-rc3 (2013-09-16 20:08:33 -0400) are available in the git repository at: git://git.denx.de/u-boot-mmc.git master for you to fetch changes up to b31c9beb9bdde1714b1131cf0e64b8b68350e824: mmc: don't support write & erase for SPL builds (2013-09-17 20:03:44 +0300) Jaehoon Chung (1): mmc: sdhci: use the SDHCI_QUIRK_USE_WIDE8 for samsung SoC Lubomir Popov (1): ARM: OMAP: Enable 8-bit eMMC access for OMAP4/5/DRA7xx Oleksandr Tyshchenko (2): mmc: Remove unused variable backup from mmc_send_cmd() omap_hsmmc: omap4+/am335x: modify MMC controller internal fsm reset func Paul Burton (5): spl: remove unnecessary (& ARM specific) include of asm/utils.h spl_mmc: only call printf or puts with CONFIG_SPL_LIBCOMMON_SUPPORT mmc: don't call *printf or puts when SPL & !CONFIG_SPL_LIBCOMMON_SUPPORT mmc: size optimization when !CONFIG_MMC_SPI mmc: don't support write & erase for SPL builds common/spl/spl_mmc.c | 17 +- drivers/mmc/Makefile | 2 ++ drivers/mmc/mmc.c | 205 +-- drivers/mmc/mmc_private.h | 45 ++ drivers/mmc/mmc_write.c | 189 ++ drivers/mmc/omap_hsmmc.c | 41 +-- drivers/mmc/s5p_sdhci.c | 4 ++- drivers/mmc/sdhci.c | 13 include/mmc.h | 4 +++ include/sdhci.h | 3 ++ 10 files changed, 337 insertions(+), 186 deletions(-) create mode 100644 drivers/mmc/mmc_private.h create mode 100644 drivers/mmc/mmc_write.c Regards -- Pantelis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How do ARM platform initialize DDR?
Hi York, There is no generic driver. AFAIK. Having worked on both mpc85xx and ARM I can tell you about samsung 5250. There are 2 uboots (one spl and other main). In case of sd/mmc boot the internal rom copies the spl uboot to iRAM and the spl boot loader initialises the DDR3. you can check for board/samsung/smdk5250/dmc_init_ddr3.c -Regards mj On 9/17/13, York Sun wrote: > Albert, > > Pardon me if this is a dumb question. I have been working on powerpc > platforms in the past. Now we (the developers I work with) are exploring > ARM cores. I am searching how memory is initialized and found different > solutions. Some platforms have memory ready before u-boot even starts, > some simply write to a set of registers. I understand many platforms > don't share the IP of DDR controller. I am wondering if there is generic > DDR driver used by many ARM platforms, like the one we have for > powerpc/mpc85xx SoCs. > > Regards, > > York > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How do ARM platform initialize DDR?
Dear MJ, Thanks for your reply. I don't see the file in my copy. Probably it is not merged yet? Anyway, you just confirmed what I found so far. Do you use static setting in dmc_init_ddr3.c? I mean does it adapt to different DDR speeds and modules (if applicable)? In my mind, I am thinking to restructure arch/powerpc/cpu/mpc8xxx/ddr/ to driver/ddr/fsl/ so the same driver can be shared as far as the DDR IP is the same (or similar). York On 09/17/2013 09:34 AM, MJ embd wrote: > Hi York, > > There is no generic driver. AFAIK. Having worked on both mpc85xx and ARM > > I can tell you about samsung 5250. There are 2 uboots (one spl and other > main). > In case of sd/mmc boot the internal rom copies the spl uboot to iRAM > and the spl boot loader initialises the DDR3. > > you can check for board/samsung/smdk5250/dmc_init_ddr3.c > > -Regards > mj > > On 9/17/13, York Sun wrote: >> Albert, >> >> Pardon me if this is a dumb question. I have been working on powerpc >> platforms in the past. Now we (the developers I work with) are exploring >> ARM cores. I am searching how memory is initialized and found different >> solutions. Some platforms have memory ready before u-boot even starts, >> some simply write to a set of registers. I understand many platforms >> don't share the IP of DDR controller. I am wondering if there is generic >> DDR driver used by many ARM platforms, like the one we have for >> powerpc/mpc85xx SoCs. >> >> Regards, >> >> York >> >> ___ >> U-Boot mailing list >> U-Boot@lists.denx.de >> http://lists.denx.de/mailman/listinfo/u-boot >> > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How do ARM platform initialize DDR?
yes, I am using uboot for arndale board. The code is written by samsung only and it is not static. The best option would be to have an eth / serial driver kind of arch which all soc vendors can share. But ddr is scattered, in absence of that, your point seems valid for fsl specific. -mj On 9/17/13, York Sun wrote: > Dear MJ, > > Thanks for your reply. > > I don't see the file in my copy. Probably it is not merged yet? > Anyway, you just confirmed what I found so far. Do you use static > setting in dmc_init_ddr3.c? I mean does it adapt to different DDR speeds > and modules (if applicable)? > > In my mind, I am thinking to restructure arch/powerpc/cpu/mpc8xxx/ddr/ > to driver/ddr/fsl/ so the same driver can be shared as far as the DDR IP > is the same (or similar). > > York > > > On 09/17/2013 09:34 AM, MJ embd wrote: >> Hi York, >> >> There is no generic driver. AFAIK. Having worked on both mpc85xx and ARM >> >> I can tell you about samsung 5250. There are 2 uboots (one spl and other >> main). >> In case of sd/mmc boot the internal rom copies the spl uboot to iRAM >> and the spl boot loader initialises the DDR3. >> >> you can check for board/samsung/smdk5250/dmc_init_ddr3.c >> >> -Regards >> mj >> >> On 9/17/13, York Sun wrote: >>> Albert, >>> >>> Pardon me if this is a dumb question. I have been working on powerpc >>> platforms in the past. Now we (the developers I work with) are exploring >>> ARM cores. I am searching how memory is initialized and found different >>> solutions. Some platforms have memory ready before u-boot even starts, >>> some simply write to a set of registers. I understand many platforms >>> don't share the IP of DDR controller. I am wondering if there is generic >>> DDR driver used by many ARM platforms, like the one we have for >>> powerpc/mpc85xx SoCs. >>> >>> Regards, >>> >>> York >>> >>> ___ >>> U-Boot mailing list >>> U-Boot@lists.denx.de >>> http://lists.denx.de/mailman/listinfo/u-boot >>> >> >> > > > -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] i2c:zynq: I2C multi-bus support on Zynq
Zynq PS has two I2C bus masters (called 'I2C0' and 'I2C1'):
> Implement 'i2c_set_bus_num' routine to select from these.
Support I2C devices which do not use internal addresses:
> Handle case of 'alen == 0' in 'i2c_read', 'i2c_write'.
This supports PCA9548 bus multiplexer on Xilinx ZC702 board.
Tested cases of 'alen == 0' and 'alen == 1' on this board.
Further minor corrections:
> Write 'address' register before 'data' register.
> Write 'transfer_size' register before 'address' register.
Signed-off-by: Michael Burr
Cc: Albert Aribaud
Cc: Heiko Schocher
Cc: Michal Simek
---
drivers/i2c/zynq_i2c.c | 87 ++--
1 file changed, 55 insertions(+), 32 deletions(-)
diff --git a/drivers/i2c/zynq_i2c.c b/drivers/i2c/zynq_i2c.c
index ce2d23f..1c9ae30 100644
--- a/drivers/i2c/zynq_i2c.c
+++ b/drivers/i2c/zynq_i2c.c
@@ -7,7 +7,7 @@
*
* Copyright (c) 2012-2013 Xilinx, Michal Simek
*
- * SPDX-License-Identifier:GPL-2.0+
+ * SPDX-License-Identifier:GPL-2.0+
*/
#include
@@ -64,18 +64,19 @@ struct zynq_i2c_registers {
#define ZYNQ_I2C_FIFO_DEPTH16
#define ZYNQ_I2C_TRANSFERT_SIZE_MAX255 /* Controller transfer limit */
-#if defined(CONFIG_ZYNQ_I2C0)
-# define ZYNQ_I2C_BASE ZYNQ_I2C_BASEADDR0
-#else
-# define ZYNQ_I2C_BASE ZYNQ_I2C_BASEADDR1
+#ifdef CONFIG_I2C_MULTI_BUS
+static unsigned int current_bus;
#endif
-
-static struct zynq_i2c_registers *zynq_i2c =
- (struct zynq_i2c_registers *)ZYNQ_I2C_BASE;
+static struct zynq_i2c_registers *zynq_i2c;
/* I2C init called by cmd_i2c when doing 'i2c reset'. */
void i2c_init(int requested_speed, int slaveadd)
{
+#ifdef CONFIG_I2C_MULTI_BUS
+ current_bus = 0;
+#endif
+ zynq_i2c = (struct zynq_i2c_registers *)ZYNQ_I2C_BASEADDR0;
+
/* 111MHz / ( (3 * 17) * 22 ) = ~100KHz */
writel((16 << ZYNQ_I2C_CONTROL_DIV_B_SHIFT) |
(2 << ZYNQ_I2C_CONTROL_DIV_A_SHIFT), &zynq_i2c->control);
@@ -187,26 +188,29 @@ int i2c_read(u8 dev, uint addr, int alen, u8 *data, int
length)
* Temporarily disable restart (by clearing hold)
* It doesn't seem to work.
*/
- clrbits_le32(&zynq_i2c->control, ZYNQ_I2C_CONTROL_RW |
- ZYNQ_I2C_CONTROL_HOLD);
+ clrbits_le32(&zynq_i2c->control, ZYNQ_I2C_CONTROL_HOLD);
+
writel(0xFF, &zynq_i2c->interrupt_status);
- while (alen--)
- writel(addr >> (8*alen), &zynq_i2c->data);
- writel(dev, &zynq_i2c->address);
+ if (alen) {
+ clrbits_le32(&zynq_i2c->control, ZYNQ_I2C_CONTROL_RW);
+ writel(dev, &zynq_i2c->address);
+ while (alen--)
+ writel(addr >> (8*alen), &zynq_i2c->data);
- /* Wait for the address to be sent */
- if (!zynq_i2c_wait(ZYNQ_I2C_INTERRUPT_COMP)) {
- /* Release the bus */
- clrbits_le32(&zynq_i2c->control, ZYNQ_I2C_CONTROL_HOLD);
- return -ETIMEDOUT;
+ /* Wait for the address to be sent */
+ if (!zynq_i2c_wait(ZYNQ_I2C_INTERRUPT_COMP)) {
+ /* Release the bus */
+ clrbits_le32(&zynq_i2c->control, ZYNQ_I2C_CONTROL_HOLD);
+ return -ETIMEDOUT;
+ }
+ debug("Device acked address\n");
}
- debug("Device acked address\n");
setbits_le32(&zynq_i2c->control, ZYNQ_I2C_CONTROL_CLR_FIFO |
ZYNQ_I2C_CONTROL_RW);
/* Start reading data */
- writel(dev, &zynq_i2c->address);
writel(length, &zynq_i2c->transfer_size);
+ writel(dev, &zynq_i2c->address);
/* Wait for data */
do {
@@ -244,17 +248,18 @@ int i2c_write(u8 dev, uint addr, int alen, u8 *data, int
length)
ZYNQ_I2C_CONTROL_HOLD);
clrbits_le32(&zynq_i2c->control, ZYNQ_I2C_CONTROL_RW);
writel(0xFF, &zynq_i2c->interrupt_status);
- while (alen--)
- writel(addr >> (8*alen), &zynq_i2c->data);
- /* Start the tranfer */
writel(dev, &zynq_i2c->address);
- if (!zynq_i2c_wait(ZYNQ_I2C_INTERRUPT_COMP)) {
- /* Release the bus */
- clrbits_le32(&zynq_i2c->control, ZYNQ_I2C_CONTROL_HOLD);
- return -ETIMEDOUT;
+ if (alen) {
+ while (alen--)
+ writel(addr >> (8*alen), &zynq_i2c->data);
+ /* Start the tranfer */
+ if (!zynq_i2c_wait(ZYNQ_I2C_INTERRUPT_COMP)) {
+ /* Release the bus */
+ clrbits_le32(&zynq_i2c->control, ZYNQ_I2C_CONTROL_HOLD);
+ return -ETIMEDOUT;
+ }
+ debug("Device acked address\n");
}
-
- debug("Device acked address\n");
while (length--) {
writel(*(cur_data++), &zynq_i2c->data);
if (readl(&zynq_i2c->transfer_size) == ZYNQ_I2C_FIFO_DEPTH) {
@@ -277,14 +
[U-Boot] (Intro) i2c:zynq: I2C multi-bus support on Zynq
First time contributing to U-Boot. I tried to CC anybody who might be relevant. Very sorry if this looks like spamming! Please let me know if you have any feedback! FYI: this change is intended for u-boot-xlnx as well as for mainline. Patch message follows... Michael R. Burr Software Engineer Logic PD Minneapolis, MN, USA ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: prevent using movt/movw address loads
On 09/17/2013 12:44 PM, tiger...@viatech.com.cn wrote: Jeroen's patch is very simple. So, is there any side-effect? Not that I am aware of. If not, why not add it into 2013.10 release version? :) That is up to Albert and Tom. Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] (Intro) i2c:zynq: I2C multi-bus support on Zynq
Thanks for your interest on u-boot contribution. Few notices, look like your newbie for u-boot contribution. 1. For patches which are less number may not require cover-letter unlit unless required. 2. Please CC to respective custodian, for your case i2c custodian if require CC to initial driver contributor and board maintainer. 3. Cover-letter is not require for less number of patches, until unless if needed. 4. what is "Intro", use git format-patch -M --subject-prefix="PATCH" --cover-letter See the below link for more info http://www.denx.de/wiki/U-Boot/Patches 5. Try to use Simon's patman, solid u-boot tool for git ops, commit's and patches creation and git sen-email..etc tools/patman On Tue, Sep 17, 2013 at 10:59 PM, Michael Burr wrote: > First time contributing to U-Boot. I tried to CC anybody who might > be relevant. Very sorry if this looks like spamming! > > Please let me know if you have any feedback! > > FYI: this change is intended for u-boot-xlnx as well as for mainline. > > Patch message follows... > > Michael R. Burr > Software Engineer > Logic PD > Minneapolis, MN, USA > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot -- Thanks, Jagan. Jagannadha Sutradharudu Teki, E: jagannadh.t...@gmail.com, P: +91-9676773388 Engineer - System Software, Opensource Hacker U-boot - SPI Custodian and Zynq APSOC Ln: http://www.linkedin.com/in/jaganteki ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec_mxc: Fix timeouts during tftp transfer
Dear Benoît, In message <16119766.1853628.1379428952428.javamail.zim...@advansee.com> you wrote: > > Here is a basic alignment test that I have run on ARM: ... > I did not succeed to duplicate the issue with GCC 4.6.2, while GCC 4.5.4 > almost > always produces an unexpected alignment for auto variables. Thanks a lot, I highly appreciate your efforts. Yes, this is really a good indication that we are fighting against a compiler bug. 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 Well, the way I see it, logic is only a way of being ignorant by num- bers. - Terry Pratchett, _Small Gods_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec_mxc: Fix timeouts during tftp transfer
Hi Wolfgang, On Tue, Sep 17, 2013 at 4:27 PM, Wolfgang Denk wrote: > Dear Benoît, > > In message <16119766.1853628.1379428952428.javamail.zim...@advansee.com> you > wrote: >> >> Here is a basic alignment test that I have run on ARM: > ... >> I did not succeed to duplicate the issue with GCC 4.6.2, while GCC 4.5.4 >> almost >> always produces an unexpected alignment for auto variables. > > Thanks a lot, I highly appreciate your efforts. Yes, this is really a > good indication that we are fighting against a compiler bug. Yes, very good analysis. Will send a v2 containig Benoît's report in the commit log. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 0/3] dfu ram support
Hi, DFU spec mentions it as a method to upgrade firmware (software stored in writable non-volatile memory). It also says other potential uses of DFU is beyond scope of the spec. Here such a beyond the scope use is being attempted - directly pumping binary images from host via USB to RAM. This facility is a developer centric one in that it gives advantage over upgrading non-volatile memory for testing new images every time during development and/or testing. Directly putting image onto RAM would speed up upgrade process. This and convenience was the initial thoughts that led to doing this, speed improvement over MMC was only 1 second though - 6 sec on RAM as opposed to 7 sec on MMC in beagle bone, perhaps enabling cache and/or optimizing DFU framework to avoid multiple copy for ram (if worth) may help, and on other platforms and other boot media like NAND maybe improvement would be higher. And for a platform that doesn't yet have proper DFU suppport for non-volatile media's, DFU to RAM can be used. Another minor advantage would be to increase life of mmc/nand as it would be less used during development/testing. usage: ram eg. kernel ram 0x8100 0x100 Downloading images to RAM using DFU is not something new, this is acheived in openmoko also. DFU on RAM can be used for extracting RAM contents to host using dfu upload. Perhaps this can be extended to io for squeezing out register dump through usb, if it is worth. In addition to ram support, a minor unification of dfu read/write enum's currently duplicated in mmc/nand is done, helping ram support too. Also dfu ram support is added for am335x SoC based boards. Based on: usb master branch Regards Afzal v5: add README entry collect additional tags v4: avoid doing prefix increment in argument of simple_strtoul() collect more tags v3: collected tags, error used instead of printf v2: unified read/write dfu ops enum, added am335x support Afzal Mohammed (3): dfu: unify mmc/nand read/write ops enum dfu: ram support am335x_evm: enable DFU RAM README | 6 drivers/dfu/Makefile | 1 + drivers/dfu/dfu.c| 7 ++-- drivers/dfu/dfu_mmc.c| 9 ++ drivers/dfu/dfu_nand.c | 7 +--- drivers/dfu/dfu_ram.c| 77 include/configs/am335x_evm.h | 6 include/dfu.h| 23 + 8 files changed, 121 insertions(+), 15 deletions(-) create mode 100644 drivers/dfu/dfu_ram.c -- 1.8.2.135.g7b592fa ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 3/3] am335x_evm: enable DFU RAM
Enable DFU for RAM, provide example dfu_alt_info
Signed-off-by: Afzal Mohammed
Cc: Heiko Schocher
Cc: Tom Rini
Cc: Marek Vasut
Cc: Lukasz Majewski
Cc: Pantelis Antoniou
Reviewed-by: Lukasz Majewski
---
v3: collected tag
v2: new
include/configs/am335x_evm.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 3de30fc..978fdf9 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -100,6 +100,7 @@
"loadbootenv=load mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \
"importbootenv=echo Importing environment from mmc ...; " \
"env import -t $loadaddr $filesize\0" \
+ "dfu_alt_info_ram=" DFU_ALT_INFO_RAM "\0" \
"ramargs=setenv bootargs console=${console} " \
"${optargs} " \
"root=${ramroot} " \
@@ -321,6 +322,11 @@
"kernel part 0 8;" \
"rootfs part 0 9"
#endif
+#define CONFIG_DFU_RAM
+#define DFU_ALT_INFO_RAM \
+ "kernel ram 0x8020 0xD8;" \
+ "fdt ram 0x80F8 0x8;" \
+ "ramdisk ram 0x8100 0x400"
/*
* Default to using SPI for environment, etc.
--
1.8.2.135.g7b592fa
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 1/3] dfu: unify mmc/nand read/write ops enum
MMC and NAND independently defines same enumerators for read/write.
Unify them by defining enum in dfu header. RAM support that is being
added newly also can make use of it.
Signed-off-by: Afzal Mohammed
Cc: Heiko Schocher
Cc: Marek Vasut
Cc: Lukasz Majewski
Cc: Pantelis Antoniou
Acked-by: Lukasz Majewski
Acked-by: Marek Vasut
Acked-by: Heiko Schocher
---
v5: collect one more tag
v4: collect more tag
v3: collected tag
v2: new
drivers/dfu/dfu_mmc.c | 9 ++---
drivers/dfu/dfu_nand.c | 7 +--
include/dfu.h | 5 +
3 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index 0871a77..f942758 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -13,16 +13,11 @@
#include
#include
-enum dfu_mmc_op {
- DFU_OP_READ = 1,
- DFU_OP_WRITE,
-};
-
static unsigned char __aligned(CONFIG_SYS_CACHELINE_SIZE)
dfu_file_buf[CONFIG_SYS_DFU_MAX_FILE_SIZE];
static long dfu_file_buf_len;
-static int mmc_block_op(enum dfu_mmc_op op, struct dfu_entity *dfu,
+static int mmc_block_op(enum dfu_op op, struct dfu_entity *dfu,
u64 offset, void *buf, long *len)
{
char cmd_buf[DFU_CMD_BUF_SIZE];
@@ -65,7 +60,7 @@ static int mmc_file_buffer(struct dfu_entity *dfu, void *buf,
long *len)
return 0;
}
-static int mmc_file_op(enum dfu_mmc_op op, struct dfu_entity *dfu,
+static int mmc_file_op(enum dfu_op op, struct dfu_entity *dfu,
void *buf, long *len)
{
char cmd_buf[DFU_CMD_BUF_SIZE];
diff --git a/drivers/dfu/dfu_nand.c b/drivers/dfu/dfu_nand.c
index 0ec12cf..edbf5a9 100644
--- a/drivers/dfu/dfu_nand.c
+++ b/drivers/dfu/dfu_nand.c
@@ -19,12 +19,7 @@
#include
#include
-enum dfu_nand_op {
- DFU_OP_READ = 1,
- DFU_OP_WRITE,
-};
-
-static int nand_block_op(enum dfu_nand_op op, struct dfu_entity *dfu,
+static int nand_block_op(enum dfu_op op, struct dfu_entity *dfu,
u64 offset, void *buf, long *len)
{
loff_t start, lim;
diff --git a/include/dfu.h b/include/dfu.h
index 392cef1..6a3e253 100644
--- a/include/dfu.h
+++ b/include/dfu.h
@@ -29,6 +29,11 @@ enum dfu_layout {
DFU_FS_EXT4,
};
+enum dfu_op {
+ DFU_OP_READ = 1,
+ DFU_OP_WRITE,
+};
+
struct mmc_internal_data {
/* RAW programming */
unsigned int lba_start;
--
1.8.2.135.g7b592fa
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 2/3] dfu: ram support
DFU spec mentions it as a method to upgrade firmware (software stored
in writable non-volatile memory). It also says other potential uses of
DFU is beyond scope of the spec.
Here such a beyond the scope use is being attempted - directly pumping
binary images from host via USB to RAM. This facility is a developer
centric one in that it gives advantage over upgrading non-volatile
memory for testing new images every time during development and/or
testing.
Directly putting image onto RAM would speed up upgrade process. This and
convenience was the initial thoughts that led to doing this, speed
improvement over MMC was only 1 second though - 6 sec on RAM as opposed
to 7 sec on MMC in beagle bone, perhaps enabling cache and/or optimizing
DFU framework to avoid multiple copy for ram (if worth) may help, and
on other platforms and other boot media like NAND maybe improvement
would be higher.
And for a platform that doesn't yet have proper DFU suppport for
non-volatile media's, DFU to RAM can be used.
Another minor advantage would be to increase life of mmc/nand as it
would be less used during development/testing.
usage: ram
eg. kernel ram 0x8100 0x100
Downloading images to RAM using DFU is not something new, this is
acheived in openmoko also.
DFU on RAM can be used for extracting RAM contents to host using dfu
upload. Perhaps this can be extended to io for squeezing out register
dump through usb, if it is worth.
Signed-off-by: Afzal Mohammed
Cc: Heiko Schocher
Cc: Marek Vasut
Cc: Lukasz Majewski
Cc: Pantelis Antoniou
Cc: Gerhard Sittig
Acked-by: Marek Vasut
Acked-by: Lukasz Majewski
Acked-by: Heiko Schocher
---
v5:
add README entry
collect additional tag
v4:
avoid doing prefix increment in argument of simple_strtoul()
collect more tags
v3: error used instead of printf
v2: remove read/write enumerator define's, instead use new common ones
README| 6
drivers/dfu/Makefile | 1 +
drivers/dfu/dfu.c | 7 +++--
drivers/dfu/dfu_ram.c | 77 +++
include/dfu.h | 18
5 files changed, 107 insertions(+), 2 deletions(-)
create mode 100644 drivers/dfu/dfu_ram.c
diff --git a/README b/README
index 63706be..500f240 100644
--- a/README
+++ b/README
@@ -1405,6 +1405,12 @@ The following options need to be configured:
CONFIG_DFU_NAND
This enables support for exposing NAND devices via DFU.
+ CONFIG_DFU_RAM
+ This enables support for exposing RAM via DFU.
+ Note: DFU spec refer to non-volatile memory usage, but
+ allow usages beyond the scope of spec - here RAM usage,
+ one that would help mostly the developer.
+
CONFIG_SYS_DFU_DATA_BUF_SIZE
Dfu transfer uses a buffer before writing data to the
raw storage device. Make the size (in bytes) of this buffer
diff --git a/drivers/dfu/Makefile b/drivers/dfu/Makefile
index fca370a..de9e44e 100644
--- a/drivers/dfu/Makefile
+++ b/drivers/dfu/Makefile
@@ -12,6 +12,7 @@ LIB = $(obj)libdfu.o
COBJS-$(CONFIG_DFU_FUNCTION) += dfu.o
COBJS-$(CONFIG_DFU_MMC) += dfu_mmc.o
COBJS-$(CONFIG_DFU_NAND) += dfu_nand.o
+COBJS-$(CONFIG_DFU_RAM) += dfu_ram.o
SRCS:= $(COBJS-y:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS-y))
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 689f5db..56b21c7 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -348,6 +348,9 @@ static int dfu_fill_entity(struct dfu_entity *dfu, char *s,
int alt,
} else if (strcmp(interface, "nand") == 0) {
if (dfu_fill_entity_nand(dfu, s))
return -1;
+ } else if (strcmp(interface, "ram") == 0) {
+ if (dfu_fill_entity_ram(dfu, s))
+ return -1;
} else {
printf("%s: Device %s not (yet) supported!\n",
__func__, interface);
@@ -397,14 +400,14 @@ int dfu_config_entities(char *env, char *interface, int
num)
const char *dfu_get_dev_type(enum dfu_device_type t)
{
- const char *dev_t[] = {NULL, "eMMC", "OneNAND", "NAND" };
+ const char *dev_t[] = {NULL, "eMMC", "OneNAND", "NAND", "RAM" };
return dev_t[t];
}
const char *dfu_get_layout(enum dfu_layout l)
{
const char *dfu_layout[] = {NULL, "RAW_ADDR", "FAT", "EXT2",
- "EXT3", "EXT4" };
+ "EXT3", "EXT4", "RAM_ADDR" };
return dfu_layout[l];
}
diff --git a/drivers/dfu/dfu_ram.c b/drivers/dfu/dfu_ram.c
new file mode 100644
index 000..335a8e1
--- /dev/null
+++ b/drivers/dfu/dfu_ram.c
@@ -0,0 +1,77 @@
+/*
+ * (C) Copyright 2013
+ * Afzal Mohammed
+ *
+ * Reference: dfu_mmc.c
+ * Copyright (C) 2012 Samsung Electronics
+ * author: Lukasz Majewski
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+#include
+#inclu
Re: [U-Boot] [RFC 5/5] B4860QDS: Add support of 2 stage NAND boot loader
Dear Prabhakar Kushwaha, Prabhakar Kushwaha freescale.com> writes: > > Add support of 2 stage NAND boot loader using SPL framework. > here, PBL initialise the internal SRAM and copy SPL(96K). This further > initialise DDR using SPD and environment and copy u-boot(512 kb) from NAND to DDR. > Finally SPL transer control to u-boot. These are just some quick comments after a build test and a quick code review. The environment is latest with some patches from patchworks. 1) Your code does not build with http://patchwork.ozlabs.org/patch/274193/ powerpc-linux-objcopy --gap-fill=0xff -O binary /export/home/git.denx.de/local/obj-B4860QDS_NAND/u-boot /export/home/git.denx.de/local/obj-B4860QDS_NAND/u-boot.bin /export/home/git.denx.de/local/obj-B4860QDS_NAND/tools/mkimage -n \ -R -T pblimage \ -d /export/home/git.denx.de/local/obj-B4860QDS_NAND/u- boot.bin /export/home//git.denx.de/local/obj-B4860QDS_NAND/u-boot.pbl Error:-R - Can't open make: *** [/export/home/git.denx.de/local/obj-B4860QDS_NAND/u-boot.pbl] Error 1 You mention you use the PBL... but probably not a pblimage. The patch correctly fixes RAMBOOT_PBL as a trigger to generate the pblimage (u- boot.pbl) but there seems to be no RCW or PBI file defined. 2) Use the new SPDX identifiers http://patchwork.ozlabs.org/patch/261356/ This was mainlined a few revisions ago. 3) Watch out for the new boards.cfg layout I have one question, can this scenario be implemented on a P5040? i.e. simulate that CPC is around 128Kb and load u-boot via SPL? Now all corenet processors seem to only support pblimage booting. All the best, Rommel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cosmetic: FIT: fix typos in comments
Signed-off-by: Masahiro Yamada --- common/image-fit.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/common/image-fit.c b/common/image-fit.c index 199b4ed..1c2ef31 100644 --- a/common/image-fit.c +++ b/common/image-fit.c @@ -58,7 +58,7 @@ static int fit_parse_spec(const char *spec, char sepc, ulong addr_curr, * @conf_name double pointer to a char, will hold pointer to a configuration * unit name * - * fit_parse_conf() expects configuration spec in the for of []#, + * fit_parse_conf() expects configuration spec in the form of []#, * where is a FIT image address that contains configuration * with a unit name. * @@ -84,7 +84,7 @@ int fit_parse_conf(const char *spec, ulong addr_curr, * subimage * @image_name: double pointer to a char, will hold pointer to a subimage name * - * fit_parse_subimage() expects subimage spec in the for of + * fit_parse_subimage() expects subimage spec in the form of * []:, where is a FIT image address that contains * subimage with a unit name. * -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] usb: ehci: Fix test mode for connected ports
The EHCI controller has some very specific requirements for the USB 2.0
port test modes, which were not closely followed in the initial test
mode commit. It demands that the host controller is completely shut down
(all ports suspended, Run/Stop bit unset) when activating test mode, and
will not work on an already enumerated port.
This patch fixes that by introducing a new ehci_shutdown() function that
closely follows the procedure listed in EHCI 4.14. Also, when we have
such a function anyway, we might as well also use it in
usb_lowlevel_stop() to make the normal host controller shutdown cleaner.
Signed-off-by: Julius Werner
---
drivers/usb/host/ehci-hcd.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index fdad739..3143021 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -190,6 +190,35 @@ out:
return ret;
}
+static int ehci_shutdown(struct ehci_ctrl *ctrl)
+{
+ int i, ret = 0;
+ uint32_t cmd, reg;
+
+ cmd = ehci_readl(&ctrl->hcor->or_usbcmd);
+ cmd &= ~(CMD_PSE | CMD_ASE);
+ ehci_writel(&ctrl->hcor->or_usbcmd, cmd);
+ ret = handshake(&ctrl->hcor->or_usbsts, STS_ASS | STS_PSS, 0, 8 * 1000);
+
+ if (!ret) {
+ for (i = 0; i < CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS; i++) {
+ reg = ehci_readl(&ctrl->hcor->or_portsc[i]);
+ reg |= EHCI_PS_SUSP;
+ ehci_writel(&ctrl->hcor->or_portsc[i], reg);
+ }
+
+ cmd &= ~CMD_RUN;
+ ehci_writel(&ctrl->hcor->or_usbcmd, cmd);
+ ret = handshake(&ctrl->hcor->or_usbsts, STS_HALT, STS_HALT,
+ 8 * 1000);
+ }
+
+ if (ret)
+ printf("EHCI failed to shut down host controller.\n");
+
+ return ret;
+}
+
static int ehci_td_buffer(struct qTD *td, void *buf, size_t sz)
{
uint32_t delta, next;
@@ -808,6 +837,7 @@ ehci_submit_root(struct usb_device *dev, unsigned long
pipe, void *buffer,
}
break;
case USB_PORT_FEAT_TEST:
+ ehci_shutdown(ctrl);
reg &= ~(0xf << 16);
reg |= ((le16_to_cpu(req->index) >> 8) & 0xf) << 16;
ehci_writel(status_reg, reg);
@@ -878,6 +908,7 @@ unknown:
int usb_lowlevel_stop(int index)
{
+ ehci_shutdown(&ehcic[index]);
return ehci_hcd_stop(index);
}
--
1.7.12.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] FIT: delete unnecessary casts
Becuase fdt_check_header function takes (const void *)
type argument, img_addr should be passed to it
without being casted to (char *).
Signed-off-by: Masahiro Yamada
---
common/image-fdt.c | 2 +-
common/image-fit.c | 2 +-
common/image.c | 6 +-
tools/fit_image.c | 2 +-
4 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/common/image-fdt.c b/common/image-fdt.c
index 2e22cca..6f9ce7d 100644
--- a/common/image-fdt.c
+++ b/common/image-fdt.c
@@ -55,7 +55,7 @@ static const image_header_t *image_get_fdt(ulong fdt_addr)
fdt_error("uImage is compressed");
return NULL;
}
- if (fdt_check_header((char *)image_get_data(fdt_hdr)) != 0) {
+ if (fdt_check_header((void *)image_get_data(fdt_hdr)) != 0) {
fdt_error("uImage data is not a fdt");
return NULL;
}
diff --git a/common/image-fit.c b/common/image-fit.c
index 1c2ef31..a657c13 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -1596,7 +1596,7 @@ int fit_image_load(bootm_headers_t *images, const char
*prop_name, ulong addr,
len = (ulong)size;
/* verify that image data is a proper FDT blob */
- if (image_type == IH_TYPE_FLATDT && fdt_check_header((char *)buf)) {
+ if (image_type == IH_TYPE_FLATDT && fdt_check_header(buf)) {
puts("Subimage data is not a FDT");
return -ENOEXEC;
}
diff --git a/common/image.c b/common/image.c
index 2c88091..e0a4c12 100644
--- a/common/image.c
+++ b/common/image.c
@@ -652,17 +652,13 @@ int genimg_get_format(const void *img_addr)
{
ulong format = IMAGE_FORMAT_INVALID;
const image_header_t *hdr;
-#if defined(CONFIG_FIT) || defined(CONFIG_OF_LIBFDT)
- char *fit_hdr;
-#endif
hdr = (const image_header_t *)img_addr;
if (image_check_magic(hdr))
format = IMAGE_FORMAT_LEGACY;
#if defined(CONFIG_FIT) || defined(CONFIG_OF_LIBFDT)
else {
- fit_hdr = (char *)img_addr;
- if (fdt_check_header(fit_hdr) == 0)
+ if (fdt_check_header(img_addr) == 0)
format = IMAGE_FORMAT_FIT;
}
#endif
diff --git a/tools/fit_image.c b/tools/fit_image.c
index 47beaaf..0400a60 100644
--- a/tools/fit_image.c
+++ b/tools/fit_image.c
@@ -23,7 +23,7 @@ static image_header_t header;
static int fit_verify_header (unsigned char *ptr, int image_size,
struct mkimage_params *params)
{
- return fdt_check_header ((void *)ptr);
+ return fdt_check_header(ptr);
}
static int fit_check_image_types (uint8_t type)
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx6sabresd: Fix the fdt file for the mx6dl version
From: Fabio Estevam We need to load 'imx6dl-sabresd.dtb' in the mx6dl version. Signed-off-by: Fabio Estevam --- include/configs/mx6sabresd.h | 4 1 file changed, 4 insertions(+) diff --git a/include/configs/mx6sabresd.h b/include/configs/mx6sabresd.h index a3dd74a..3229bc7 100644 --- a/include/configs/mx6sabresd.h +++ b/include/configs/mx6sabresd.h @@ -16,7 +16,11 @@ #define CONFIG_MXC_UART_BASE UART1_BASE #define CONFIG_CONSOLE_DEV "ttymxc0" #define CONFIG_MMCROOT "/dev/mmcblk1p2" +#if defined(CONFIG_MX6Q) #define CONFIG_DEFAULT_FDT_FILE"imx6q-sabresd.dtb" +#elif defined(CONFIG_MX6DL) +#define CONFIG_DEFAULT_FDT_FILE"imx6dl-sabresd.dtb" +#endif #define PHYS_SDRAM_SIZE(1u * 1024 * 1024 * 1024) #include "mx6sabre_common.h" -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-boot] Some questions about BootStage functions
Hi, Simon: Got it! Thanks! My codebase is 2013.04 release version. It seemed board_f.c / board_r.c had been moved to common directory. Arch/Arm/Lib/Board.c would be compiled conditionally. Best wishes, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6sabresd: Fix the fdt file for the mx6dl version
On Tue, Sep 17, 2013 at 10:55 PM, Fabio Estevam wrote: > From: Fabio Estevam > > We need to load 'imx6dl-sabresd.dtb' in the mx6dl version. > > Signed-off-by: Fabio Estevam I fully agree with this. Acked-by: Otavio Salvador -- 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] [U-boot] Some questions about BootStage functions
Hi Tiger, On Tue, Sep 17, 2013 at 7:58 PM, wrote: > Hi, Simon: > Got it! > Thanks! > My codebase is 2013.04 release version. > It seemed board_f.c / board_r.c had been moved to common directory. > Arch/Arm/Lib/Board.c would be compiled conditionally. > Yes, trying to deprecate that! Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] net: fec_mxc: Fix timeouts during tftp transfer
From: Fabio Estevam Performing tftp transfers on mx28 results in random timeouts. Hector Palacios and Robert Hodaszi analyzed the root cause being related to the wrong alignment of the 'buff' buffer inside fec_recv(). Benoît Thébaudeau provided an excellent analysis of the alignment bug that is present on older versions, such as GCC 4.5.4: http://marc.info/?l=u-boot&m=137942904906131&w=2 Use ALLOC_CACHE_ALIGN_BUFFER() to avoid alignment issues from older GCC versions. Reported-by: Hector Palacios Tested-by: Oliver Metz Tested-by: Hector Palacios Signed-off-by: Fabio Estevam --- Changes since v1: - Improve commit log - Add Hector's Tested-by tag drivers/net/fec_mxc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c index 690e572..b423ff6 100644 --- a/drivers/net/fec_mxc.c +++ b/drivers/net/fec_mxc.c @@ -794,7 +794,7 @@ static int fec_recv(struct eth_device *dev) uint16_t bd_status; uint32_t addr, size, end; int i; - uchar buff[FEC_MAX_PKT_SIZE] __aligned(ARCH_DMA_MINALIGN); + ALLOC_CACHE_ALIGN_BUFFER(uchar, buff, FEC_MAX_PKT_SIZE); /* * Check if any critical events have happened -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: ehci: Fix test mode for connected ports
Hi,
On Tue, Sep 17, 2013 at 6:29 PM, Julius Werner wrote:
> The EHCI controller has some very specific requirements for the USB 2.0
> port test modes, which were not closely followed in the initial test
> mode commit. It demands that the host controller is completely shut down
> (all ports suspended, Run/Stop bit unset) when activating test mode, and
> will not work on an already enumerated port.
>
> This patch fixes that by introducing a new ehci_shutdown() function that
> closely follows the procedure listed in EHCI 4.14. Also, when we have
> such a function anyway, we might as well also use it in
> usb_lowlevel_stop() to make the normal host controller shutdown cleaner.
>
Marek this seems like a bug fix - should we pick it up for the release?
>
> Signed-off-by: Julius Werner
> ---
> drivers/usb/host/ehci-hcd.c | 31 +++
> 1 file changed, 31 insertions(+)
>
> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
> index fdad739..3143021 100644
> --- a/drivers/usb/host/ehci-hcd.c
> +++ b/drivers/usb/host/ehci-hcd.c
> @@ -190,6 +190,35 @@ out:
> return ret;
> }
>
> +static int ehci_shutdown(struct ehci_ctrl *ctrl)
>
Suggest a comment as to what this function does (e.g. a few lines from your
commit message).
> +{
> + int i, ret = 0;
>
nit: = 0 not needed I think
> + uint32_t cmd, reg;
> +
> + cmd = ehci_readl(&ctrl->hcor->or_usbcmd);
> + cmd &= ~(CMD_PSE | CMD_ASE);
> + ehci_writel(&ctrl->hcor->or_usbcmd, cmd);
> + ret = handshake(&ctrl->hcor->or_usbsts, STS_ASS | STS_PSS, 0, 8 *
> 1000);
> +
> + if (!ret) {
> + for (i = 0; i < CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS; i++) {
> + reg = ehci_readl(&ctrl->hcor->or_portsc[i]);
> + reg |= EHCI_PS_SUSP;
> + ehci_writel(&ctrl->hcor->or_portsc[i], reg);
> + }
> +
> + cmd &= ~CMD_RUN;
> + ehci_writel(&ctrl->hcor->or_usbcmd, cmd);
> + ret = handshake(&ctrl->hcor->or_usbsts, STS_HALT, STS_HALT,
> + 8 * 1000);
> + }
> +
> + if (ret)
> + printf("EHCI failed to shut down host controller.\n");
> +
> + return ret;
> +}
> +
> static int ehci_td_buffer(struct qTD *td, void *buf, size_t sz)
> {
> uint32_t delta, next;
> @@ -808,6 +837,7 @@ ehci_submit_root(struct usb_device *dev, unsigned long
> pipe, void *buffer,
> }
> break;
> case USB_PORT_FEAT_TEST:
> + ehci_shutdown(ctrl);
>
If it cannot be shut down, I suppose there is nothing that can be done
here. Should this function exit here, or not?
> reg &= ~(0xf << 16);
> reg |= ((le16_to_cpu(req->index) >> 8) & 0xf) <<
> 16;
> ehci_writel(status_reg, reg);
> @@ -878,6 +908,7 @@ unknown:
>
> int usb_lowlevel_stop(int index)
> {
> + ehci_shutdown(&ehcic[index]);
> return ehci_hcd_stop(index);
> }
>
> --
> 1.7.12.4
>
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/3] dfu: ram support
Hi Heiko, On Tue, Sep 17, 2013 at 06:32:37AM +0200, Heiko Schocher wrote: > Thanks for this work! Hmm... minor comment. Could you add a entry in > README? > > Beside of that: > > Acked-by: Heiko Schocher Thanks, v5 has been posted with README entry. Regards Afzal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Makefile: Do not show make debug messages
In commit 27af930, the top Makefile was adjusted to the new
boards.cfg format.
But at the same time, -d option was added.
If you configure and make separately, for example
like follows:
make omap4_panda_config
make CROSS_COMPILE=
it works fine as it did before.
But if you do them in one time like follows:
make omap4_panda CROSS_COMPILE=
The log is sprinkled with annoying make debug messages.
This commit deletes -d option again.
Signed-off-by: Masahiro Yamada
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 28ddb7e..bc639b3 100644
--- a/Makefile
+++ b/Makefile
@@ -838,7 +838,7 @@ unconfig:
sinclude $(obj).boards.depend
$(obj).boards.depend: boards.cfg
- @awk '(NF && $$1 !~ /^#/) { print $$7 ": " $$7 "_config; $$(MAKE) -d"
}' $< > $@
+ @awk '(NF && $$1 !~ /^#/) { print $$7 ": " $$7 "_config; $$(MAKE)" }'
$< > $@
#
# Functions to generate common board directory names
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Annoying make debug messages at v2013.10-rc3
Hello Albert.
Commit 27af930e modified top Makefile as follows:
--- a/Makefile
+++ b/Makefile
@@ -838,7 +838,7 @@ unconfig:
sinclude $(obj).boards.depend
$(obj).boards.depend: boards.cfg
- @awk '(NF && $$1 !~ /^#/) { print $$1 ": " $$1 "_config; $$(MAKE)"
}' $< > $@
+ @awk '(NF && $$1 !~ /^#/) { print $$7 ": " $$7 "_config; $$(MAKE)
-d" }' $< > $@
#
# Functions to generate common board directory names
I thought adding -d option is not what you intended.
So, I posted a patch "[U-Boot] Makefile: Do not show make debug messages"
to delete -d option again.
Does my patch seem to be OK?
I am really suffering from lots of debug messages like follows:
$ make CROSS_COMPILE=arm-linux-gnueabi- omap4_panda
Configuring for omap4_panda board...
make -d
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for x86_64-pc-linux-gnu
Reading makefiles...
Reading makefile `Makefile'...
Reading makefile `include/autoconf.mk.dep' (search path) (don't care) (no ~
expansion)...
Reading makefile `include/autoconf.mk' (search path) (don't care) (no ~
expansion)...
Reading makefile `include/config.mk' (search path) (no ~ expansion)...
Reading makefile `/home/yamada/workspace/u-boot/config.mk' (search path) (no ~
expansion)...
Reading makefile
`/home/yamada/workspace/u-boot/include/generated/cc_options.mk' (search path)
(don't care) (no ~ expansion)...
Reading makefile `/home/yamada/workspace/u-boot/include/autoconf.mk' (search
path) (don't care) (no ~ expansion)...
Reading makefile `/home/yamada/workspace/u-boot/include/config.mk' (search
path) (don't care) (no ~ expansion)...
Reading makefile `/home/yamada/workspace/u-boot/arch/arm/config.mk' (search
path) (don't care) (no ~ expansion)...
Reading makefile `/home/yamada/workspace/u-boot/arch/arm/cpu/armv7/config.mk'
(search path) (don't care) (no ~ expansion)...
Reading makefile
`/home/yamada/workspace/u-boot/arch/arm/cpu/armv7/omap4/config.mk' (search
path) (don't care) (no ~ expansion)...
Reading makefile `/home/yamada/workspace/u-boot/board/ti/panda/config.mk'
(search path) (don't care) (no ~ expansion)...
Reading makefile `.boards.depend' (search path) (don't care) (no ~ expansion)...
Updating makefiles
Considering target file `.boards.depend'.
Considering target file `boards.cfg'.
Looking for an implicit rule for `boards.cfg'.
Trying pattern rule with stem `boards.cfg'.
Trying implicit prerequisite `boards.cfg.o'.
Trying pattern rule with stem `boards.cfg'.
.
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] mkimage: added 'static' specifier to match function's prototype.
From: Guilherme Maciel Ferreira
Signed-off-by: Guilherme Maciel Ferreira
---
tools/mkimage.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/mkimage.c b/tools/mkimage.c
index 7f22101..08aa634 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -632,8 +632,8 @@ copy_file (int ifd, const char *datafile, int pad)
(void) close (dfd);
}
-void
-usage ()
+static void
+usage (void)
{
fprintf (stderr, "Usage: %s -l image\n"
" -l ==> list image header information\n",
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] dumpimage: Added a tool to extract "data files" from U-Boot multifile images
From: Guilherme Maciel Ferreira
Given a multifile image created through the mkimage's -d option:
$ mkimage -A x86 -O linux -T multi -n x86 -d vmlinuz:initrd.img:System.map \
multi.img
Image Name: x86
Created: Thu Jul 25 10:29:13 2013
Image Type: Intel x86 Linux Multi-File Image (gzip compressed)
Data Size:13722956 Bytes = 13401.32 kB = 13.09 MB
Load Address:
Entry Point:
Contents:
Image 0: 4040128 Bytes = 3945.44 kB = 3.85 MB
Image 1: 7991719 Bytes = 7804.41 kB = 7.62 MB
Image 2: 1691092 Bytes = 1651.46 kB = 1.61 MB
It is possible to perform the converse operation -- extracting any file from
the image -- by using the dumpimage's -i option:
$ dumpimage -i multi.img -p 2 System.map
Although it's feasible to retrieve "data files" from image through scripting,
the requirement to embed tools such 'dd', 'awk' and 'sed' for this sole purpose
is cumbersome and unreliable -- once you must keep track of file sizes inside
the image. Furthermore, extracting data files using "dumpimage" tool is faster
than through scripting.
Signed-off-by: Guilherme Maciel Ferreira
---
Makefile |1 +
README|9 ++
tools/.gitignore |1 +
tools/Makefile| 26
tools/default_image.c | 55 +
tools/dumpimage.c | 318 +
tools/dumpimage.h | 33 +
tools/imagetool.h | 11 ++
8 files changed, 454 insertions(+), 0 deletions(-)
create mode 100644 tools/dumpimage.c
create mode 100644 tools/dumpimage.h
diff --git a/Makefile b/Makefile
index 28ddb7e..c9b6c4d 100644
--- a/Makefile
+++ b/Makefile
@@ -866,6 +866,7 @@ clean:
$(obj)tools/envcrc \
$(obj)tools/gdb/{astest,gdbcont,gdbsend} \
$(obj)tools/gen_eth_addr$(obj)tools/img2srec \
+ $(obj)tools/dump{env,}image\
$(obj)tools/mk{env,}image $(obj)tools/mpc86x_clk \
$(obj)tools/mk{$(BOARD),}spl \
$(obj)tools/mxsboot\
diff --git a/README b/README
index ccd47fa..da1c1e8 100644
--- a/README
+++ b/README
@@ -5097,6 +5097,15 @@ when your kernel is intended to use an initial ramdisk:
Load Address: 0x
Entry Point: 0x
+The "dumpimage" is a tool to disassemble images built by mkimage. Its "-i"
+option performs the converse operation of the mkimage's second form (the "-d"
+option). Given an image built by mkimage, the dumpimage extracts a "data file"
+from the image:
+
+ tools/dumpimage -i image -p position data_file
+ -i ==> extract from the 'image' a specific 'data_file', \
+ indexed by 'position'
+
Installing a Linux Image:
-
diff --git a/tools/.gitignore b/tools/.gitignore
index a7fee26..2320fd8 100644
--- a/tools/.gitignore
+++ b/tools/.gitignore
@@ -3,6 +3,7 @@
/gen_eth_addr
/img2srec
/kwboot
+/dumpimage
/mkenvimage
/mkimage
/mpc86x_clk
diff --git a/tools/Makefile b/tools/Makefile
index 4936d54..ea9e51a 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -50,6 +50,7 @@ BIN_FILES-$(CONFIG_BUILD_ENVCRC) += envcrc$(SFX)
BIN_FILES-$(CONFIG_CMD_NET) += gen_eth_addr$(SFX)
BIN_FILES-$(CONFIG_CMD_LOADS) += img2srec$(SFX)
BIN_FILES-$(CONFIG_XWAY_SWAP_BYTES) += xway-swap-bytes$(SFX)
+BIN_FILES-y += dumpimage$(SFX)
BIN_FILES-y += mkenvimage$(SFX)
BIN_FILES-y += mkimage$(SFX)
BIN_FILES-$(CONFIG_EXYNOS5250) += mk$(BOARD)spl$(SFX)
@@ -72,6 +73,7 @@ EXT_OBJ_FILES-y += lib/sha1.o
# Source files located in the tools directory
NOPED_OBJ_FILES-y += aisimage.o
NOPED_OBJ_FILES-y += default_image.o
+NOPED_OBJ_FILES-y += dumpimage.o
NOPED_OBJ_FILES-y += fit_image.o
NOPED_OBJ_FILES-y += image-host.o
NOPED_OBJ_FILES-y += imximage.o
@@ -200,6 +202,30 @@ $(obj)xway-swap-bytes$(SFX): $(obj)xway-swap-bytes.o
$(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $^
$(HOSTSTRIP) $@
+$(obj)dumpimage$(SFX): $(obj)aisimage.o \
+ $(FIT_SIG_OBJS) \
+ $(obj)crc32.o \
+ $(obj)default_image.o \
+ $(obj)fit_image.o \
+ $(obj)image-fit.o \
+ $(obj)image.o \
+ $(obj)image-host.o \
+ $(obj)imagetool.o \
+ $(obj)imximage.o \
+ $(obj)kwbimage.o \
+ $(obj)dumpimage.o \
+ $(obj)md5.o \
+ $(obj)mxsimage.o \
+ $(obj)omapimage.o \
+ $(obj)os_support.o \
+ $(obj)pblimage.o \
+ $(obj)sha1.o \
+ $(obj)ublimage.o \
+ $(LIBFDT_OBJS) \
+
[U-Boot] [PATCH 4/4] sandbox: dumpimage: Test dumpimage
From: Guilherme Maciel Ferreira
Signed-off-by: Guilherme Maciel Ferreira
---
test/image/test-imagetools.sh | 107 +
1 files changed, 107 insertions(+), 0 deletions(-)
create mode 100755 test/image/test-imagetools.sh
diff --git a/test/image/test-imagetools.sh b/test/image/test-imagetools.sh
new file mode 100755
index 000..b243794
--- /dev/null
+++ b/test/image/test-imagetools.sh
@@ -0,0 +1,107 @@
+#!/bin/bash
+#
+# Written by Guilherme Maciel Ferreira
+#
+# Sanity check for mkimage and dumpimage tools
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+# To run this:
+#
+# make O=sandbox sandbox_config
+# make O=sandbox
+# ./test/image/test-imagetools.sh
+
+
+BASEDIR=sandbox
+
+LINUX_VERSION=`uname -r`
+IMAGE=linux-${LINUX_VERSION}.img
+DATAFILE0=vmlinuz-${LINUX_VERSION}
+DATAFILE1=initrd.img-${LINUX_VERSION}
+DATAFILE2=System.map-${LINUX_VERSION}
+
+MKIMAGE=${BASEDIR}/tools/mkimage
+DUMPIMAGE=${BASEDIR}/tools/dumpimage
+MKIMAGE_LIST=mkimage.list
+DUMPIMAGE_LIST=dumpimage.list
+
+cleanup()
+{
+ rm -f ${DATAFILE0}
+ rm -f ${DATAFILE1}
+ rm -f ${DATAFILE2}
+ rm -f ${IMAGE}
+ rm -f ${DUMPIMAGE_LIST}
+ rm -f ${MKIMAGE_LIST}
+}
+
+assert_equal()
+{
+ FILE_1=$1
+ FILE_2=$2
+ diff ${FILE_1} ${FILE_2}
+ ret=$?
+ if [ $ret -ne 0 ]; then
+ echo "Failed."
+ cleanup
+ exit $ret
+ fi
+}
+
+compress_image()
+{
+ BOOTDIR=$1
+
DATAFILES=${BOOTDIR}/${DATAFILE0}:${BOOTDIR}/${DATAFILE1}:${BOOTDIR}/${DATAFILE2}
+
+ echo -e "\nBuilding image..."
+ echo "# ${MKIMAGE} -A x86 -O linux -T multi -n \"${LINUX_VERSION}\" -d
${DATAFILES} ${IMAGE}"
+ ./${MKIMAGE} -A x86 -O linux -T multi -n "${LINUX_VERSION}" -d
${DATAFILES} ${IMAGE}
+ echo -e "done.\n"
+}
+
+extract_image()
+{
+ echo -e "\nExtracting image contents..."
+ echo "# ${DUMPIMAGE} -i ${IMAGE} -p 0 ${DATAFILE0}"
+ ./${DUMPIMAGE} -i ${IMAGE} -p 0 ${DATAFILE0}
+ echo "# ${DUMPIMAGE} -i ${IMAGE} -p 1 ${DATAFILE1}"
+ ./${DUMPIMAGE} -i ${IMAGE} -p 1 ${DATAFILE1}
+ echo "# ${DUMPIMAGE} -i ${IMAGE} -p 2 ${DATAFILE2}"
+ ./${DUMPIMAGE} -i ${IMAGE} -p 2 ${DATAFILE2}
+ echo -e "done.\n"
+}
+
+list_image()
+{
+ echo -e "\nListing image contents..."
+ echo "# ${MKIMAGE} -l ${IMAGE}"
+ ./${MKIMAGE} -l ${IMAGE} > ${MKIMAGE_LIST} 2>&1
+ echo "# ${DUMPIMAGE} -l ${IMAGE}"
+ ./${DUMPIMAGE} -l ${IMAGE} > ${DUMPIMAGE_LIST} 2>&1
+ echo -e "done.\n"
+}
+
+main()
+{
+ # Assume kernel images lie in /boot dir
+ BOOTDIR=/boot
+
+ # Compress and extract multifile images, compare the result
+ compress_image ${BOOTDIR}
+ extract_image
+ assert_equal ${DATAFILE0} ${BOOTDIR}/${DATAFILE0}
+ assert_equal ${DATAFILE1} ${BOOTDIR}/${DATAFILE1}
+ assert_equal ${DATAFILE2} ${BOOTDIR}/${DATAFILE2}
+
+ # List contents and compares output fro tools
+ list_image
+ assert_equal ${DUMPIMAGE_LIST} ${MKIMAGE_LIST}
+
+ # Remove files created
+ cleanup
+
+ echo "Success."
+}
+
+main
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] tools: moved code common to all image tools to a separated module.
From: Guilherme Maciel Ferreira
In order to avoid duplicating code and keep only one point of modification,
the functions, structs and defines useful for "dumpimage" were moved from
"mkimage" to a common module called "imagetool".
This modification also weakens the coupling between image types (FIT, IMX, MXS,
and so on) and image tools (mkimage and dumpimage). Any tool may initialize the
"imagetool" through register_image_tool() function, while the image types
register themselves within an image tool using the register_image_type()
function:
+---+
+--| fit_image |
+--+ +---+ | +---+
|mkimage |> | | <-+
+--+ | | +---+
| imagetool | <|imximage |
+--+ | | +---+
| dumpimage |> | | <-+
+--+ +---+ | +---+
+--| default_image |
+---+
register_image_tool() register_image_type()
Also, the struct "mkimage_params" was renamed to "image_tool_params" to make
clear its general purpose.
Signed-off-by: Guilherme Maciel Ferreira
---
tools/Makefile|2 +
tools/aisimage.c | 16 +++---
tools/default_image.c | 10 ++--
tools/fit_image.c | 11 ++--
tools/imagetool.c | 58 ++
tools/imagetool.h | 159 +
tools/imximage.c | 12 ++--
tools/kwbimage.c | 10 ++--
tools/mkimage.c | 24 ++--
tools/mkimage.h | 123 +-
tools/mxsimage.c | 12 ++--
tools/omapimage.c | 10 ++--
tools/pblimage.c | 10 ++--
tools/ublimage.c | 10 ++--
14 files changed, 276 insertions(+), 191 deletions(-)
create mode 100644 tools/imagetool.c
create mode 100644 tools/imagetool.h
diff --git a/tools/Makefile b/tools/Makefile
index c36cde2..4936d54 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -76,6 +76,7 @@ NOPED_OBJ_FILES-y += fit_image.o
NOPED_OBJ_FILES-y += image-host.o
NOPED_OBJ_FILES-y += imximage.o
NOPED_OBJ_FILES-y += kwbimage.o
+NOPED_OBJ_FILES-y += imagetool.o
NOPED_OBJ_FILES-y += mkenvimage.o
NOPED_OBJ_FILES-y += mkimage.o
NOPED_OBJ_FILES-y += mxsimage.o
@@ -212,6 +213,7 @@ $(obj)mkimage$(SFX):$(obj)aisimage.o \
$(obj)image-fit.o \
$(obj)image-host.o \
$(obj)image.o \
+ $(obj)imagetool.o \
$(obj)imximage.o \
$(obj)kwbimage.o \
$(obj)md5.o \
diff --git a/tools/aisimage.c b/tools/aisimage.c
index 980bf2e..31dfb4f 100644
--- a/tools/aisimage.c
+++ b/tools/aisimage.c
@@ -5,7 +5,7 @@
* SPDX-License-Identifier:GPL-2.0+
*/
-#include "mkimage.h"
+#include "imagetool.h"
#include "aisimage.h"
#include
@@ -176,7 +176,7 @@ static uint32_t *ais_insert_cmd_header(uint32_t cmd,
uint32_t nargs,
}
-static uint32_t *ais_alloc_buffer(struct mkimage_params *params)
+static uint32_t *ais_alloc_buffer(struct image_tool_params *params)
{
int dfd;
struct stat sbuf;
@@ -216,7 +216,7 @@ static uint32_t *ais_alloc_buffer(struct mkimage_params
*params)
return ptr;
}
-static uint32_t *ais_copy_image(struct mkimage_params *params,
+static uint32_t *ais_copy_image(struct image_tool_params *params,
uint32_t *aisptr)
{
@@ -252,7 +252,7 @@ static uint32_t *ais_copy_image(struct mkimage_params
*params,
}
-static int aisimage_generate(struct mkimage_params *params,
+static int aisimage_generate(struct image_tool_params *params,
struct image_type_params *tparams)
{
FILE *fd = NULL;
@@ -370,7 +370,7 @@ static int aisimage_check_image_types(uint8_t type)
}
static int aisimage_verify_header(unsigned char *ptr, int image_size,
- struct mkimage_params *params)
+ struct image_tool_params *params)
{
struct ais_header *ais_hdr = (struct ais_header *)ptr;
@@ -384,11 +384,11 @@ static int aisimage_verify_header(unsigned char *ptr, int
image_size,
}
static void aisimage_set_header(void *ptr, struct stat *sbuf, int ifd,
- struct mkimage_params *params)
+ struct image_tool_params *params)
{
}
-int aisimage_check_params(struct mkimage_params *params)
+int aisimage_check_params(struct image_tool_params *params)
{
if (!params)
return CFG_INVALID;
@@ -427,5 +427,5 @@ static struct image_type_params aisimage_params = {
Re: [U-Boot] How do ARM platform initialize DDR?
Adding Vipin to the thread as he has better knowledge on this than me. Vipin can you please add your comments here as well.. As far as I can remember for the ARM based SPEAr SoCs on which we worked in the past: - At the moment the DDR initialization code for various ARM SoCs in u-boot is scattered across ARCH directories: See examples of SPEAr (based on ARM926ejs) [1] and OMAP4 (ARmv7) [2] DDR drivers. - There is no unified driver model in place for DDR driver similar to what is available for eth/serial drivers and we need to formulate a DDR model (something using the suggested framework in [3]) so that the same DDR driver can be shared across PPC and ARM SoCs. References: [1] SPEAr DDR drivers for Denali MPMC - http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/arm926ejs/spear/start.S;h=7dbd5dbf99e8c6e216cc50e789ec7f103e0ecaea;hb=HEAD#l105 http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/arm926ejs/spear/spl.c;h=b550404352b8c04f2e5d5d71df41c750c07ab1a8;hb=HEAD#l69 http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/arm926ejs/spear/spr600_mt47h128m8_3_266_cl5_async.c;h=cc45ab7016b1658eceb545c959bb1b59f33c06c7;hb=HEAD#l12 [2] OMAP4 Elpida DDR drivers - http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/omap4/sdram_elpida.c;h=67a79261f778c6afab3d0e3870eac1e18cff8411;hb=HEAD http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/omap4/emif.c;h=e89032be75dc916891ccfd70c66e19c4b7b38839;hb=HEAD [3] UDM-cores.txt - http://git.denx.de/?p=u-boot.git;a=blob;f=doc/driver-model/UDM-cores.txt;h=4e1318871a8d9f7f6f329800d6394158e42f85dd;hb=HEAD Regards, Bhupesh > -Original Message- > From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] > On Behalf Of MJ embd > Sent: Tuesday, September 17, 2013 10:37 PM > To: sun york-R58495 > Cc: u-boot@lists.denx.de > Subject: Re: [U-Boot] How do ARM platform initialize DDR? > > yes, I am using uboot for arndale board. > The code is written by samsung only and it is not static. > > The best option would be to have an eth / serial driver kind of arch > which all soc vendors can share. But ddr is scattered, in absence of > that, your point seems valid for fsl specific. > > -mj > > On 9/17/13, York Sun wrote: > > Dear MJ, > > > > Thanks for your reply. > > > > I don't see the file in my copy. Probably it is not merged yet? > > Anyway, you just confirmed what I found so far. Do you use static > > setting in dmc_init_ddr3.c? I mean does it adapt to different DDR > > speeds and modules (if applicable)? > > > > In my mind, I am thinking to restructure arch/powerpc/cpu/mpc8xxx/ddr/ > > to driver/ddr/fsl/ so the same driver can be shared as far as the DDR > > IP is the same (or similar). > > > > York > > > > > > On 09/17/2013 09:34 AM, MJ embd wrote: > >> Hi York, > >> > >> There is no generic driver. AFAIK. Having worked on both mpc85xx and > >> ARM > >> > >> I can tell you about samsung 5250. There are 2 uboots (one spl and > >> other main). > >> In case of sd/mmc boot the internal rom copies the spl uboot to iRAM > >> and the spl boot loader initialises the DDR3. > >> > >> you can check for board/samsung/smdk5250/dmc_init_ddr3.c > >> > >> -Regards > >> mj > >> > >> On 9/17/13, York Sun wrote: > >>> Albert, > >>> > >>> Pardon me if this is a dumb question. I have been working on powerpc > >>> platforms in the past. Now we (the developers I work with) are > >>> exploring ARM cores. I am searching how memory is initialized and > >>> found different solutions. Some platforms have memory ready before > >>> u-boot even starts, some simply write to a set of registers. I > >>> understand many platforms don't share the IP of DDR controller. I am > >>> wondering if there is generic DDR driver used by many ARM platforms, > >>> like the one we have for powerpc/mpc85xx SoCs. > >>> > >>> Regards, > >>> > >>> York > >>> > >>> ___ > >>> U-Boot mailing list > >>> U-Boot@lists.denx.de > >>> http://lists.denx.de/mailman/listinfo/u-boot > >>> > >> > >> > > > > > > > > > -- > -mj > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] dumpimage: Added a tool to extract "data files" from U-Boot multifile images
On Tue, Sep 17, 2013 at 9:42 PM, wrote:
> From: Guilherme Maciel Ferreira
>
> Given a multifile image created through the mkimage's -d option:
>
> $ mkimage -A x86 -O linux -T multi -n x86 -d vmlinuz:initrd.img:System.map \
> multi.img
>
> Image Name: x86
> Created: Thu Jul 25 10:29:13 2013
> Image Type: Intel x86 Linux Multi-File Image (gzip compressed)
> Data Size:13722956 Bytes = 13401.32 kB = 13.09 MB
> Load Address:
> Entry Point:
> Contents:
> Image 0: 4040128 Bytes = 3945.44 kB = 3.85 MB
> Image 1: 7991719 Bytes = 7804.41 kB = 7.62 MB
> Image 2: 1691092 Bytes = 1651.46 kB = 1.61 MB
>
> It is possible to perform the converse operation -- extracting any file from
> the image -- by using the dumpimage's -i option:
>
> $ dumpimage -i multi.img -p 2 System.map
>
> Although it's feasible to retrieve "data files" from image through scripting,
> the requirement to embed tools such 'dd', 'awk' and 'sed' for this sole
> purpose
> is cumbersome and unreliable -- once you must keep track of file sizes inside
> the image. Furthermore, extracting data files using "dumpimage" tool is faster
> than through scripting.
>
> Signed-off-by: Guilherme Maciel Ferreira
> ---
> Makefile |1 +
> README|9 ++
> tools/.gitignore |1 +
> tools/Makefile| 26
> tools/default_image.c | 55 +
> tools/dumpimage.c | 318
> +
> tools/dumpimage.h | 33 +
> tools/imagetool.h | 11 ++
> 8 files changed, 454 insertions(+), 0 deletions(-)
> create mode 100644 tools/dumpimage.c
> create mode 100644 tools/dumpimage.h
>
> diff --git a/Makefile b/Makefile
> index 28ddb7e..c9b6c4d 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -866,6 +866,7 @@ clean:
>$(obj)tools/envcrc \
>$(obj)tools/gdb/{astest,gdbcont,gdbsend} \
>$(obj)tools/gen_eth_addr$(obj)tools/img2srec \
> + $(obj)tools/dump{env,}image\
Is this handled by Make or shell? In case this is shell, I think this
is a Bashism, isn't it?
>$(obj)tools/mk{env,}image $(obj)tools/mpc86x_clk \
>$(obj)tools/mk{$(BOARD),}spl \
>$(obj)tools/mxsboot\
> diff --git a/README b/README
> index ccd47fa..da1c1e8 100644
> --- a/README
> +++ b/README
> @@ -5097,6 +5097,15 @@ when your kernel is intended to use an initial ramdisk:
> Load Address: 0x
> Entry Point: 0x
>
> +The "dumpimage" is a tool to disassemble images built by mkimage. Its "-i"
> +option performs the converse operation of the mkimage's second form (the "-d"
> +option). Given an image built by mkimage, the dumpimage extracts a "data
> file"
> +from the image:
> +
> + tools/dumpimage -i image -p position data_file
> + -i ==> extract from the 'image' a specific 'data_file', \
> + indexed by 'position'
> +
>
> Installing a Linux Image:
> -
> diff --git a/tools/.gitignore b/tools/.gitignore
> index a7fee26..2320fd8 100644
> --- a/tools/.gitignore
> +++ b/tools/.gitignore
> @@ -3,6 +3,7 @@
> /gen_eth_addr
> /img2srec
> /kwboot
> +/dumpimage
> /mkenvimage
> /mkimage
> /mpc86x_clk
> diff --git a/tools/Makefile b/tools/Makefile
> index 4936d54..ea9e51a 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -50,6 +50,7 @@ BIN_FILES-$(CONFIG_BUILD_ENVCRC) += envcrc$(SFX)
> BIN_FILES-$(CONFIG_CMD_NET) += gen_eth_addr$(SFX)
> BIN_FILES-$(CONFIG_CMD_LOADS) += img2srec$(SFX)
> BIN_FILES-$(CONFIG_XWAY_SWAP_BYTES) += xway-swap-bytes$(SFX)
> +BIN_FILES-y += dumpimage$(SFX)
> BIN_FILES-y += mkenvimage$(SFX)
> BIN_FILES-y += mkimage$(SFX)
> BIN_FILES-$(CONFIG_EXYNOS5250) += mk$(BOARD)spl$(SFX)
> @@ -72,6 +73,7 @@ EXT_OBJ_FILES-y += lib/sha1.o
> # Source files located in the tools directory
> NOPED_OBJ_FILES-y += aisimage.o
> NOPED_OBJ_FILES-y += default_image.o
> +NOPED_OBJ_FILES-y += dumpimage.o
> NOPED_OBJ_FILES-y += fit_image.o
> NOPED_OBJ_FILES-y += image-host.o
> NOPED_OBJ_FILES-y += imximage.o
> @@ -200,6 +202,30 @@ $(obj)xway-swap-bytes$(SFX):
> $(obj)xway-swap-bytes.o
> $(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $^
> $(HOSTSTRIP) $@
>
> +$(obj)dumpimage$(SFX): $(obj)aisimage.o \
> + $(FIT_SIG_OBJS) \
> + $(obj)crc32.o \
> + $(obj)default_image.o \
> + $(obj)fit_image.o \
> + $(obj)image-fit.o \
> + $(obj)image.o \
> + $(obj)image-host.o \
> + $(obj)imagetool.o \
> + $(obj)imximage.o \
> + $(obj)kwbimage.o \
> +
Re: [U-Boot] [PATCH v2 0/5] Add device tree support for VxWorks
Hi Wolfgang, Changes for v2: 1) separating legacy do_bootvx code from do_bootm_vxworks, thus making do_bootm_vxworks only work with new kernels, old kernels can still use 'bootvx' 2) minor fixes to make code more clear I've posted the v2 patches, how do you think of them ? Thanks. Miao ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] HACK: enable HYP mode on OMAP5
Few quick comments
1) wouldnt it be better to create a .S file and move big chunk of
inline assembly there
2) can the multiple occurences of .word be substituted with something else?
On 9/17/13, Alexander Tarasikov wrote:
> ---
> arch/arm/lib/bootm.c | 89
> ++--
> 1 file changed, 87 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
> index eefb456..63395c3 100644
> --- a/arch/arm/lib/bootm.c
> +++ b/arch/arm/lib/bootm.c
> @@ -8,6 +8,9 @@
> * Marius Groeger
> *
> * Copyright (C) 2001 Erik Mouw (j.a.k.m...@its.tudelft.nl)
> + * HYP entry (C) 2012 Ian Molton
> + *and Clemens Fischer
> + * (C) 2013 Alexander Tarasikov
> *
> * SPDX-License-Identifier: GPL-2.0+
> */
> @@ -26,6 +29,89 @@ DECLARE_GLOBAL_DATA_PTR;
>
> static struct tag *params;
>
> +/*
> + * function called by cpu 1 after wakeup
> + */
> +extern void __hyp_init_sec(void);
> +
> +asm (
> + ".pushsection .text\n"
> + ".global __hyp_init_sec\n"
> + "__hyp_init_sec:\n"
> + "ldr r12, =0x102\n"
> + "adr r0, hyp_init_cont\n"
> + "dsb\n"
> + "isb\n"
> + "dmb\n"
> + "smc #0\n"
> + "hyp_init_cont: ldr r1, =0x48281800\n" // AUX_CORE_BOOT_0
> + "mov r2, #0\n"
> + "str r2, [r1, #4]\n"
> + "dsb\n"
> + "isb\n"
> + "dmb\n"
> + "wait: wfe\n"
> + "ldr r2, [r1, #4]\n"
> + "cmp r2, #0\n"
> + "movne pc, r2\n"
> + "b wait\n"
> + ".popsection\n"
> +);
> +
> +/*
> + * Enable HYP mode on the OMAP5 CPU
> + *
> + * FIXME: this needs to test to make sure its running on an OMAP5
> + *
> + * We wake up CPU1 at __hyp_init_sec which allows us to put it into HYP
> + * mode.
> + *
> + * CPU1 then clears AUX_CORE_BOOT_0 and enters WFE, until the kernel wakes
> it.
> + *
> + * In order to avoid CPU1 continuing execution on just about any event, we
> + * wait for AUX_CORE_BOOT_0 to contain a non-zero address, at which point
> + * we continue execution at that address.
> + *
> + */
> +
> +static void hyp_enable(void) {
> + /*Wake up CPU1 and enable HYP on CPU0. */
> + asm(
> + "ldr r1, =0x48281800\n" // AUX_CORE_BOOT_1
> + "ldr r2, =__hyp_init_sec\n"
> + "str r2, [r1, #4]\n"
> + "mov r2, #0x20\n"
> + "str r2, [r1]\n"// AUX_CORE_BOOT_0
> + "isb\n"
> + "dmb\n"
> + "dsb\n"
> + "sev\n" // Wake CPU1
> + "adr r1, hyp_stack\n"
> + "stm r1, {r4-r14}\n" //save registers on the temporary stack
> + "ldr r12, =0x102\n" //start hypervisor SMC code
> + "adr r0, hyp_ena_cont\n" //address after SMC instruction
> + "dsb\n"
> + "isb\n"
> + "dmb\n"
> + "smc #0\n" // CPU0 -> HYP mode
> + "hyp_stack:\n"
> + ".word 0x0\n"
> + ".word 0x0\n"
> + ".word 0x0\n"
> + ".word 0x0\n"
> + ".word 0x0\n"
> + ".word 0x0\n"
> + ".word 0x0\n"
> + ".word 0x0\n"
> + ".word 0x0\n"
> + ".word 0x0\n"
> + ".word 0x0\n"
> + "hyp_ena_cont: adr r1,hyp_stack\n"
> + "ldm r1, {r4-r14}\n"
> + :::"r0", "r1", "r2", "r3", "cc", "memory"
> + );
> +};
> +
> static ulong get_sp(void)
> {
> ulong ret;
> @@ -144,7 +230,6 @@ static void setup_initrd_tag(bd_t *bd, ulong
> initrd_start, ulong initrd_end)
>
> params->u.initrd.start = initrd_start;
> params->u.initrd.size = initrd_end - initrd_start;
> -
> params = tag_next (params);
> }
>
> @@ -185,7 +270,6 @@ __weak void setup_board_tags(struct tag **in_params) {}
> static void boot_prep_linux(bootm_headers_t *images)
> {
> char *commandline = getenv("bootargs");
> -
> if (IMAGE_ENABLE_OF_LIBFDT && images->ft_len) {
> #ifdef CONFIG_OF_LIBFDT
> debug("using: FDT\n");
> @@ -246,6 +330,7 @@ static void boot_jump_linux(bootm_headers_t *images, int
> flag)
> else
> r2 = gd->bd->bi_boot_params;
>
> + hyp_enable();
> if (!fake)
> kernel_entry(0, machid, r2);
> }
> --
> 1.8.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
--
-mj
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 0/5] powerpc: Add support 2 stage boot loader for corenet platform
Trivial Question, Which part of the SPL code uses HEAP? On 9/16/13, Prabhakar Kushwaha wrote: > > Signed-off-by: Prabhakar Kushwaha > --- > > Add support of 2 stage NAND boot loader in cornet platforms using SPL > framework. > This will be helpful for those SoC which has less internal SRAM(128K). > > here, PBL initialise the internal SRAM and copy SPL(96K) in SRAM. > SPL further initialise DDR using SPD and environment variables and copy > u-boot(512 KB) from NAND flash to DDR. > Finally SPL transer control to u-boot for futher booting. > > SPL has following features: > - Executes within 128K > - SPL size 96K > - No relocation required > > Run time view of SPL framework > == > --- > Area| Address | > --- > GD, BD | 0xFFFE (1K) | > --- > HEAP| 0xFFFE0400 (26K) grow downwards | > --- > STACK | 0xFFFE8000 (5K) grow upwards | > --- > U-boot SPL | 0xfffe8000 – 0xfffc (96K) | > --- > > 96K + 5K + 26K + 1K = 128K > --- > This patch set contains:- > > [RFC 1/5] powerpc:Add support of SPL non-relocation > > [RFC 2/5] powerpc/SPL:Allow Parsing of LAW table in both SPL & non SPL > > [RFC 3/5] common/env: Point default envirenoment for GD > > [RFC 4/5] SPL:Defines function required to env read for IFC & env_nand > > [RFC 5/5] B4860QDS: Add support of 2 stage NAND boot loader > -- > 1.7.9.5 > > > -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Exynos 5250 Query] Smp Boot
Hi Simon/All, Any comments On 9/17/13, Simon Glass wrote: > Hi, > > You could try to cc whoever wrote the code. You can use git blame to find > out. > > But it sounds like you are on the right track. I may be able to help, will > email tomorrow if so. > > Regards, > Simon > On Sep 16, 2013 8:26 PM, "MJ embd" wrote: > >> Reminder, Please can anyone respond >> >> On 9/16/13, MJ embd wrote: >> > Hi, >> > >> > I was trying to understand the booting (till linux) on samsung exynos >> > 5250. As this is my first on ARM Cortex. I have a few questions, so >> > following is a step by step understanding and [Q] mentions the >> > question I am asking >> > >> > [1] At POR (Power on Reset) the Internal Boot rom code executes, and >> > checks the boot location and if it finds sd card, it copies 14k from >> > the sd card (which is u-boot-spl.bin) into iRAM. >> > [2] the internal boot rom branches pc to the entry point of spl at >> > __start (0x2023400) >> > [3] First instruction at __start is b reset. >> > [4] this takes the route reset | cpu_init_crit | low_level_init | >> first_cpu >> > >> > [Q 1] At this point what is the state of secondary core, is it held in >> reset >> > ? >> > As per document, "" >> > "the secondary CPUs (CPU1, CPU2, and CPU3) execute a WFI instruction, >> > which is actually a loop that checks the value of SYS_FLAGS register." >> > >> > I couldnt find the SYS_FLAGS register in Cortex A15 manual, can some >> > one >> > point. >> > >> > [Q 2] The secondary core until the point the boot core calls >> > smp_kick_secondary is just waiting in WFI. >> > [5] the smp_kick_secondary does the following >> > (a) at the address SYSFLAGS_ADDR (0x202) which is not in spl but >> > above it, it write the b reset instruction and >> > (b) Issues a SGI to the secondary core >> > >> > [Q 3] Does this mean that secondary core is listening at address >> > 0x202, I couldnt find that in any document? >> > >> > [6] Supposedly it does and it starts executing the reset function, >> > secondary core would end up in enter_smp_pen. >> > [Q 4] I dont understand what is trying to achieve here, Can some one >> > explain. >> > >> > >> > I am planning to pen down the complete boot sequence, all help >> appreciated. >> > >> > Thanks in advance. >> > mj >> > >> >> >> -- >> -mj >> ___ >> U-Boot mailing list >> U-Boot@lists.denx.de >> http://lists.denx.de/mailman/listinfo/u-boot >> > -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] powerpc/83xx: remove staticness for qe_iop_conf_tab
Hi Kim,
On 07/04/2013 03:37 PM, Holger Brunck wrote:
> commit a5510058 powerpc/83xx/km: make local functions and structs static
>
> removed the staticness also from this struct. But this struct is needed
> in arch/powerpc/cpu/mpc83xx/cpu_init.c and declared as extern.
>
> Signed-off-by: Holger Brunck
> ---
> board/keymile/km83xx/km83xx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/board/keymile/km83xx/km83xx.c b/board/keymile/km83xx/km83xx.c
> index 812a436..47c40f5 100644
> --- a/board/keymile/km83xx/km83xx.c
> +++ b/board/keymile/km83xx/km83xx.c
> @@ -31,7 +31,7 @@
>
> #include "../common/common.h"
>
> -static const qe_iop_conf_t qe_iop_conf_tab[] = {
> +const qe_iop_conf_t qe_iop_conf_tab[] = {
> /* port pin dir open_drain assign */
> #if defined(CONFIG_MPC8360)
> /* MDIO */
>
we are already at rc3 for v2013.10-rc3 could you please pull these 4 patches
into your tree to get them merge for mainline u-boot?
Thanks!
Holger
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
