Re: [U-Boot] [PULL] u-boot-pxa/master
Hi Marek, On Thu, 6 Feb 2014 02:54:11 +0100, Marek Vasut ma...@denx.de wrote: The following changes since commit e97f9d817e600cd6f43d1d0da76f5787e33a5c56: Merge branch 'u-boot-ti/master' into 'u-boot-arm/master' (2014-01-29 14:07:50 +0100) are available in the git repository at: git://git.denx.de/u-boot-pxa.git master for you to fetch changes up to f8d1086851409ee16344932ef367b8a05c365b09: ARM: serial: Remove the IXP UART driver (2014-02-06 02:51:52 +0100) Marek Vasut (10): ARM: IXP: Remove actux1 board ARM: IXP: Remove actux2 board ARM: IXP: Remove actux3 board ARM: IXP: Remove actux4 board ARM: IXP: Remove dvl_host board ARM: IXP: Remove the IXP architecture support ARM: USB: Remove the IXP EHCI driver ARM: PCI: Remove the IXP PCI driver ARM: NET: Remove the IXP NPE ethernet driver ARM: serial: Remove the IXP UART driver MAKEALL |2 - Makefile |1 - README|1 - arch/arm/cpu/ixp/Makefile | 12 - arch/arm/cpu/ixp/config.mk| 16 - arch/arm/cpu/ixp/cpu.c| 100 --- arch/arm/cpu/ixp/interrupts.c | 66 -- arch/arm/cpu/ixp/start.S | 430 - arch/arm/cpu/ixp/timer.c | 101 arch/arm/cpu/ixp/u-boot.lds | 91 --- arch/arm/include/asm/arch-ixp/ixp425.h| 548 - arch/arm/include/asm/arch-ixp/ixp425pci.h | 174 -- arch/arm/include/asm/global_data.h|3 - board/actux1/Makefile |8 - board/actux1/actux1.c | 148 - board/actux1/actux1_hw.h | 41 -- board/actux1/u-boot.lds | 99 --- board/actux2/Makefile |8 - board/actux2/actux2.c | 122 board/actux2/actux2_hw.h | 43 -- board/actux2/u-boot.lds | 99 --- board/actux3/Makefile |8 - board/actux3/actux3.c | 149 - board/actux3/actux3_hw.h | 44 -- board/actux3/u-boot.lds | 99 --- board/actux4/Makefile |8 - board/actux4/actux4.c | 129 board/actux4/actux4_hw.h | 33 - board/dvlhost/Makefile|8 - board/dvlhost/dvlhost.c | 112 board/dvlhost/dvlhost_hw.h| 31 - board/dvlhost/u-boot.lds | 99 --- board/dvlhost/watchdog.c | 27 - boards.cfg|8 - doc/README.scrapyard |5 + doc/driver-model/UDM-pci.txt |4 - doc/driver-model/UDM-serial.txt |4 - drivers/i2c/soft_i2c.c|3 - drivers/net/npe/IxEthAcc.c| 237 drivers/net/npe/IxEthAccCommon.c | 1025 --- drivers/net/npe/IxEthAccControlInterface.c| 509 drivers/net/npe/IxEthAccDataPlane.c | 2459 -- drivers/net/npe/IxEthAccMac.c | 2617 --- drivers/net/npe/IxEthAccMii.c | 386 drivers/net/npe/IxEthDBAPI.c | 424 - drivers/net/npe/IxEthDBAPISupport.c | 651 drivers/net/npe/IxEthDBCore.c | 439 -- drivers/net/npe/IxEthDBEvents.c | 496 --- drivers/net/npe/IxEthDBFeatures.c | 638 drivers/net/npe/IxEthDBFirewall.c | 242 drivers/net/npe/IxEthDBHashtable.c| 618 --- drivers/net/npe/IxEthDBLearning.c |
Re: [U-Boot] [PATCH] part_efi: fix protective_mbr struct allocation
Hi Albert, Tom Hi Lukasz, On Wed, 12 Feb 2014 21:45:41 +0100, Lukasz Majewski l.majew...@majess.pl wrote: I think, that the patch for fixing the unaligned access in this function has already been posted by Piotr Wilczek. We have experienced similar issues with Samsung's Exynos4 based targets. [PATCH V2] disk:efi: avoid unaligned access on efi partition Despite its disappearance from patchwork it shall be available at mailing list archive. The v1 can be found at the following link: http://patchwork.ozlabs.org/patch/282753/ Neither V1 nor V2 have disappeared from patchwork. A filter on the subject, selecting any state and both archived and non-archived patches will return both: V1: http://patchwork.ozlabs.org/patch/282753/ (New) V2: http://patchwork.ozlabs.org/patch/314717/ (Deferred) (I think that the patchwork web interface does not make it possible at all to remove a patch anyway) Thanks for pointing out. Now it is perfectly visible :-) Inclusion of v2 has been postponed since there was a discussion if we shall allow unaligned access (-mno-unaligned-access flag) at armv7 (after patches posted by Tom). As fair as I can tell, we will keep the current approach so, I think that Tom will be willing to pull this patch (v2) now. Agreed, but then we should make sure no one has comments on V2 that they might have withheld due to the initial rejection of V2. Any comments? This patch do fix unaligned access problem on Trats2 (Exynos4412), when we restore/create GPT, so I would like to know if there are any new inquires regarding this patch. Best regards, Lukasz Majewski Amicalement, -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] pre-compiled ARC gcc
Hello Alexey, So for Debian/Ubuntu host you need following. Little-endian toolchain: https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-4.8-R2/arc_gnu_4.8-R2_prebuilt_uclibc_le_ubuntu_install.tar.gz Big-endian toolchain: https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-4.8-R2/arc_gnu_4.8-R2_prebuilt_uclibc_be_ubuntu_install.tar.gz Worked for me. Thanks! I could build all ARC boards. (I needed to apply http://ork.ozlabs.org/patch/318375/ for axs101.) Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] pre-compiled ARC gcc
Hello Masahiro-san, On Wed, 2014-02-19 at 17:23 +0900, Masahiro Yamada wrote: Hello Alexey, So for Debian/Ubuntu host you need following. Little-endian toolchain: https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-4.8-R2/arc_gnu_4.8-R2_prebuilt_uclibc_le_ubuntu_install.tar.gz Big-endian toolchain: https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-4.8-R2/arc_gnu_4.8-R2_prebuilt_uclibc_be_ubuntu_install.tar.gz Worked for me. Thanks! I could build all ARC boards. (I needed to apply http://ork.ozlabs.org/patch/318375/ for axs101.) Good to know! Even though if I build with ./MAKEALL -a arc I see error reported for axs101 even though u-boot executable gets built. So could be an issue in compiler output parser in MAKEALL script. Regards, Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [GIT PULL] Zynq patches v2
Hi Albert, here is the second pull request with the rest of changes for zynq which haven't been applied. I have rebased my repo based on your master/next branch. As I wrote this pull request has on more patch from Siva about fixing bug in lldiv function. Compare to the first there is just 11 my patches because 2 were already applied. Please ping me if there is something wrong. Thanks, Michal The following changes since commit a87a0ce7028d5371c81d77ba72c1ba43a1ca77bc: Merge branch 'u-boot-pxa/master' into 'u-boot-arm/master' (2014-02-19 07:15:01 +0100) are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git zynq for you to fetch changes up to e158665c1e4c4665302f0d95e26b7c7e6b70a83c: arm: zynq: correct the argument to lldiv (2014-02-19 09:41:22 +0100) Michal Simek (11): zynq: Do not explicitely enable icache zynq: Enable dcache support zynq: Fix incorrect header name zynq: Extend kernel image size to 20MB zynq: Enable tftp put command zynq: Use board_eth_init if CMD_NET is not enabled zynq: Move bootmode to headers zynq: serial: Simplify serial driver initialization zynq: timer: Fix hangs if network activity attempted after about one hour zynq: Update CLK in bdinfo zynq: Add support for U-BOOT SPL Siva Durga Prasad Paladugu (1): arm: zynq: correct the argument to lldiv Soren Brinkmann (7): common: Provide DIV_ROUND_CLOSEST macro zynq: Provide a framework to read clock frequencies zynq: timer: Migrate to zynq clock framework net: zynq_gem: Move RCLK details out of driver net: zynq_gem: Calculate clock dividers dynamically serial_zynq: Migrate to Zynq clock framework zynq: Implement dump clock command arch/arm/cpu/armv7/zynq/Makefile | 2 + arch/arm/cpu/armv7/zynq/clk.c | 664 + arch/arm/cpu/armv7/zynq/cpu.c | 14 ++- arch/arm/cpu/armv7/zynq/slcr.c | 17 +-- arch/arm/cpu/armv7/zynq/spl.c | 69 +++ arch/arm/cpu/armv7/zynq/timer.c| 14 ++- arch/arm/cpu/armv7/zynq/u-boot-spl.lds | 61 ++ arch/arm/include/asm/arch-zynq/clk.h | 29 + arch/arm/include/asm/arch-zynq/hardware.h | 40 ++- arch/arm/include/asm/arch-zynq/spl.h | 18 +++ arch/arm/include/asm/arch-zynq/sys_proto.h | 2 +- board/xilinx/zynq/Makefile | 1 + board/xilinx/zynq/board.c | 10 -- board/xilinx/zynq/ps7_init.c | 12 ++ drivers/net/zynq_gem.c | 20 ++-- drivers/serial/serial_zynq.c | 33 +++-- include/common.h | 16 +++ include/configs/zynq-common.h | 102 +--- include/configs/zynq_zc70x.h | 2 +- include/configs/zynq_zed.h | 2 +- 20 files changed, 1055 insertions(+), 73 deletions(-) create mode 100644 arch/arm/cpu/armv7/zynq/clk.c create mode 100644 arch/arm/cpu/armv7/zynq/spl.c create mode 100644 arch/arm/cpu/armv7/zynq/u-boot-spl.lds create mode 100644 arch/arm/include/asm/arch-zynq/clk.h create mode 100644 arch/arm/include/asm/arch-zynq/spl.h create mode 100644 board/xilinx/zynq/ps7_init.c -- Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] question about one env variable size
Hi, experts: I want to know the size limit for a single env variable. I have reviewed the code: 1. It seems the size limit for a single env variable is 1M bytes, right? #defineMAX_ENV_SIZE (1 20) /* 1 MiB */ (in common/cmd_nvedit.c) Best wishes, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] show_boot_progress
I use u-boot version 1.3.3. The function call __show_boot_progress is
defined in common/main.c as
void inline __show_boot_progress (int val) {}
There are many calls to this function in particular locations with
specific parameters. But it does nothing. What is the purpose of this?
Since I'm not a very good programmer, I also wonder the meaning of
void inline show_boot_progress (int val) __attribute__((weak,
alias(__show_boot_progress)));
Is it a directive to the compiler?
abdullah
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Exynos5250: Remove lowlevelinit
Hi Rajeshwari,
On Fri, 14 Feb 2014 13:52:48 +0530, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
From: Rajeshwari S Shinde rajeshwar...@samsung.com
Since we use CONFIG_SKIP_LOWLEVEL_INIT for Exynos baords, we dont need to a
lowlevel_init.S file.
Signed-off-by: Rajeshwari S Shinde rajeshwar...@samsung.com
---
board/samsung/smdk5250/lowlevel_init.S | 82
--
1 file changed, 82 deletions(-)
delete mode 100644 board/samsung/smdk5250/lowlevel_init.S
diff --git a/board/samsung/smdk5250/lowlevel_init.S
b/board/samsung/smdk5250/lowlevel_init.S
deleted file mode 100644
index 9003e2d..000
--- a/board/samsung/smdk5250/lowlevel_init.S
+++ /dev/null
@@ -1,82 +0,0 @@
-/*
- * Lowlevel setup for SMDK5250 board based on S5PC520
- *
- * Copyright (C) 2012 Samsung Electronics
- *
- * SPDX-License-Identifier: GPL-2.0+
- */
-
-#include config.h
-#include version.h
-#include asm/arch/cpu.h
-
-_TEXT_BASE:
- .word CONFIG_SYS_TEXT_BASE
-
- .globl lowlevel_init
-lowlevel_init:
-
- /* use iRAM stack in bl2 */
- ldr sp, =CONFIG_IRAM_STACK
- stmdb r13!, {ip,lr}
-
- /* check reset status */
- ldr r0, =(EXYNOS5_POWER_BASE + INFORM1_OFFSET)
- ldr r1, [r0]
-
- /* AFTR wakeup reset */
- ldr r2, =S5P_CHECK_DIDLE
- cmp r1, r2
- beq exit_wakeup
-
- /* LPA wakeup reset */
- ldr r2, =S5P_CHECK_LPA
- cmp r1, r2
- beq exit_wakeup
-
- /* Sleep wakeup reset */
- ldr r2, =S5P_CHECK_SLEEP
- cmp r1, r2
- beq wakeup_reset
-
- /*
- * If U-boot is already running in RAM, no need to relocate U-Boot.
- * Memory controller must be configured before relocating U-Boot
- * in ram.
- */
- ldr r0, =0x0ff /* r0 - Mask Bits*/
- bic r1, pc, r0 /* pc - current addr of code */
- /* r1 - unmasked bits of pc */
- ldr r2, _TEXT_BASE /* r2 - original base addr in ram */
- bic r2, r2, r0 /* r2 - unmasked bits of r2*/
- cmp r1, r2 /* compare r1, r2 */
- beq 1f /* r0 == r1 then skip sdram init */
-
- /* init system clock */
- bl system_clock_init
-
- /* Memory initialize */
- bl mem_ctrl_init
-
-1:
- bl arch_cpu_init
- bl tzpc_init
- ldmia r13!, {ip,pc}
-
-wakeup_reset:
- bl system_clock_init
- bl mem_ctrl_init
- bl arch_cpu_init
- bl tzpc_init
-
-exit_wakeup:
- /* Load return address and jump to kernel */
- ldr r0, =(EXYNOS5_POWER_BASE + INFORM0_OFFSET)
-
- /* r1 = physical address of exynos5_cpu_resume function*/
- ldr r1, [r0]
-
- /* Jump to kernel */
- mov pc, r1
- nop
- nop
Applied to u-boot-arm/master, thanks!
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8 0/38] Switch over to real Kbuild
Hello Simon, Thanks for your feedback. Hmm, Kbuild is 9 times slower on your computer. This is a big difference. (It was about 1.6 x slower on my box.) I don't know where such a difference came from. Note this is a 32-core machine. You are passing -j1 to the command line in here, time CROSS_COMPILE=/opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.8-2013.08_linux/bin/arm -linux-gnueabihf- ARCH=arm make -j1 So you are using only 1 core, right? There seem to be noticeable pauses between things happening. I'm not quite sure how to dig into it more. Is it possible that cc-option is no-longer caching the various compiler options? I guess it's possible. Is sandbox build slow as well? Sandbox has no cc-option. If cc-option is the cause of pauses, sandbox build should be faster. Yes actually sandbox is pretty fast. It's interesting and I want to know how fast. Could you post the result of Sandbox build? Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i.MX6: nitrogen6x: pedantic: BOOT_FROM==spi, not sd
On 10/02/2014 18:22, Eric Nelson wrote: Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] imx6 SION bit has to be on for the pins that are used as ENET_REF_CLK
Hi Andy, On 12/02/2014 15:31, Andy Ng wrote: Signed-off-by: Andy Ng andreas2...@gmail.com --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] : Please pull u-boot-imx
Hi Albert, please pull from u-boot-imx, thanks ! The following changes since commit e97f9d817e600cd6f43d1d0da76f5787e33a5c56: Merge branch 'u-boot-ti/master' into 'u-boot-arm/master' (2014-01-29 14:07:50 +0100) are available in the git repository at: git://www.denx.de/git/u-boot-imx.git master for you to fetch changes up to da781c60e5d55904d77931fcb63f25e65e2228be: imx6 SION bit has to be on for the pins that are used as ENET_REF_CLK (2014-02-19 10:57:25 +0100) Andy Ng (1): imx6 SION bit has to be on for the pins that are used as ENET_REF_CLK Anson Huang (2): imx6: ensure AHB clock is 132MHz in low freq boot mode imx6: make sure MMDC_CHx_MASK is clear to avoid warm reset failure Eric Nelson (1): i.MX6: nitrogen6x: pedantic: BOOT_FROM==spi, not sd Fabio Estevam (8): nitrogen6x: README: Only calling 'make' is enough nitrogen6x: README: Do not refer to MAINTAINERS file mx6sl: Adjust fdt_addr to avoid address overlapping hummingboard: Return from cpu_eth_init() directly imx: Introduce a header for the imx cpu versions mx6: Distinguish mx6dual from mx6quad mx6qsabreauto: Update imximage.cfg mx6: Enable L2 cache support Marek Vasut (7): ARM: armv7: Make indirect vector addresses globl ARM: mx6: Add PCI express clock configuration ARM: mx6: Add PCI express driver ARM: mx6: Enable PCIe on Sabrelite ARM: m53evk: Rename mxc-nand to mxc_nand ARM: m53evk: Enable CONFIG_REGEX pci: mx6: Implement reset callback Markus Niebel (2): ARM: imx6: fix wrong fec clk NET: fec_mxc: fix MDIO clock prescaler calculation Otavio Salvador (11): cgtqmx6eval: Set default environment to use zImage hummingboard: Set default environment to use zImage mx23evk: Set default environment to use zImage mx28evk: Set default environment to use zImage mx51evk: Set default environment to use zImage mx53loco: Set default environment to use zImage mx6qarm2: Set default environment to use zImage mx6sabre_common: Set default environment to use zImage mx6slevk: Set default environment to use zImage udoo: Set default environment to use zImage vf610twr: Set default environment to use zImage Stefano Babic (2): Merge branch 'master' of git://git.denx.de/u-boot-arm Merge branch 'master' of git://git.denx.de/u-boot-arm arch/arm/cpu/armv7/mx6/clock.c | 77 +++- arch/arm/cpu/armv7/mx6/soc.c| 103 - arch/arm/cpu/armv7/start.S |7 + arch/arm/imx-common/cpu.c |2 + arch/arm/include/asm/arch-imx/cpu.h | 13 + arch/arm/include/asm/arch-mx5/sys_proto.h |7 +- arch/arm/include/asm/arch-mx6/clock.h |1 + arch/arm/include/asm/arch-mx6/imx-regs.h|1 + arch/arm/include/asm/arch-mx6/iomux.h | 27 ++ arch/arm/include/asm/arch-mx6/mx6dl_pins.h |6 +- arch/arm/include/asm/arch-mx6/mx6q_pins.h |6 +- arch/arm/include/asm/arch-mx6/sys_proto.h |8 +- arch/arm/include/asm/pl310.h| 21 + board/boundary/nitrogen6x/README|4 +- board/boundary/nitrogen6x/nitrogen6dl.cfg |2 +- board/boundary/nitrogen6x/nitrogen6dl2g.cfg |2 +- board/boundary/nitrogen6x/nitrogen6q.cfg|2 +- board/boundary/nitrogen6x/nitrogen6q2g.cfg |2 +- board/boundary/nitrogen6x/nitrogen6s.cfg|2 +- board/boundary/nitrogen6x/nitrogen6s1g.cfg |2 +- board/freescale/mx6qsabreauto/imximage.cfg | 136 +++--- board/solidrun/hummingboard/hummingboard.c |6 +- drivers/net/fec_mxc.c |8 +- drivers/pci/Makefile|1 + drivers/pci/pcie_imx.c | 606 +++ include/configs/cgtqmx6eval.h | 14 +- include/configs/hummingboard.h | 20 +- include/configs/m53evk.h|6 +- include/configs/mx23evk.h | 12 +- include/configs/mx28evk.h | 26 +- include/configs/mx51evk.h | 20 +- include/configs/mx53loco.h | 20 +- include/configs/mx6_common.h|5 + include/configs/mx6qarm2.h | 10 +- include/configs/mx6sabre_common.h | 20 +- include/configs/mx6slevk.h | 22 +- include/configs/nitrogen6x.h| 11 + include/configs/udoo.h | 20 +- include/configs/vf610twr.h | 20 +- 39 files changed, 1049 insertions(+), 229 deletions(-) create mode 100644 arch/arm/include/asm/arch-imx/cpu.h create mode 100644 drivers/pci/pcie_imx.c -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office:
Re: [U-Boot] [PATCH] part_efi: fix protective_mbr struct allocation
Hi Lukasz, On Wed, 19 Feb 2014 09:19:04 +0100, Lukasz Majewski l.majew...@samsung.com wrote: Hi Albert, Tom Hi Lukasz, On Wed, 12 Feb 2014 21:45:41 +0100, Lukasz Majewski l.majew...@majess.pl wrote: I think, that the patch for fixing the unaligned access in this function has already been posted by Piotr Wilczek. We have experienced similar issues with Samsung's Exynos4 based targets. [PATCH V2] disk:efi: avoid unaligned access on efi partition Despite its disappearance from patchwork it shall be available at mailing list archive. The v1 can be found at the following link: http://patchwork.ozlabs.org/patch/282753/ Neither V1 nor V2 have disappeared from patchwork. A filter on the subject, selecting any state and both archived and non-archived patches will return both: V1: http://patchwork.ozlabs.org/patch/282753/ (New) V2: http://patchwork.ozlabs.org/patch/314717/ (Deferred) (I think that the patchwork web interface does not make it possible at all to remove a patch anyway) Thanks for pointing out. Now it is perfectly visible :-) Inclusion of v2 has been postponed since there was a discussion if we shall allow unaligned access (-mno-unaligned-access flag) at armv7 (after patches posted by Tom). As fair as I can tell, we will keep the current approach so, I think that Tom will be willing to pull this patch (v2) now. Agreed, but then we should make sure no one has comments on V2 that they might have withheld due to the initial rejection of V2. Any comments? This patch do fix unaligned access problem on Trats2 (Exynos4412), when we restore/create GPT, so I would like to know if there are any new inquires regarding this patch. Does not seem to be, so I will apply V2. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] part_efi: fix protective_mbr struct allocation
On Wed, 19 Feb 2014 11:08:03 +0100, Albert ARIBAUD Thanks for pointing out. Now it is perfectly visible :-) Inclusion of v2 has been postponed since there was a discussion if we shall allow unaligned access (-mno-unaligned-access flag) at armv7 (after patches posted by Tom). As fair as I can tell, we will keep the current approach so, I think that Tom will be willing to pull this patch (v2) now. Agreed, but then we should make sure no one has comments on V2 that they might have withheld due to the initial rejection of V2. Any comments? This patch do fix unaligned access problem on Trats2 (Exynos4412), when we restore/create GPT, so I would like to know if there are any new inquires regarding this patch. Does not seem to be, so I will apply V2. Correction: I would like it to be applied as per current ARM alignment policy, but this patch is not ARM per se and is in Tom's hands. Tom, can you apply http://patchwork.ozlabs.org/patch/314717/ ? This would by no means close the discussion I opened, and in the event of a policy change, the patch could always be reverted; meanwhile, it matches our current policy. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] show_boot_progress
Hi Abdullah,
On Wed, 19 Feb 2014 11:44:26 +0200, Abdullah YILDIZ
abdullah.ma...@gmail.com wrote:
I use u-boot version 1.3.3.
Any reason to use a five-years-old release?
The function call __show_boot_progress is
defined in common/main.c as
void inline __show_boot_progress (int val) {}
There are many calls to this function in particular locations with
specific parameters. But it does nothing. What is the purpose of this?
See below.
Since I'm not a very good programmer, I also wonder the meaning of
void inline (int val) __attribute__((weak,
alias(__show_boot_progress)));
Is it a directive to the compiler?
Yes, it is.
It tells the compiler that the function name 'show_boot_progress'
actually refers to function '__show_boot_progress', but that if
someother part of the program defines an actual function called
'show_boot_progress', then that definition is strong and will
replace the weak definition.
This is a common way to define a generic functionality where some
functions should be adapted on specific architectures or even boards.
Here, the boot progress framework defines a function to call to show
boot progress, but each board will have its own way of presenting that
progress to the board operator, and will implement is own strong
show_boot_progress function for this.
abdullah
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-boot] question about one env variable size
Dear tiger...@via-alliance.com, In message fe7aded5c2218b4786c09cd97dc4c49fdae...@exchbj02.viatech.com.bj you wrote: I want to know the size limit for a single env variable. In theory the size of the variable is only limited by the free room in the envrionment (the size of which you configure in your board config file). I have reviewed the code: 1. It seems the size limit for a single env variable is 1M bytes, right? #defineMAX_ENV_SIZE (1 20) /* 1 MiB */ (in common/cmd_nvedit.c) Wrong. This limit applies only for the env import code - it is a (theoretical) limit for the size of an environment blob that we can import. Note however, that you will hit other limits much earlier: - Typically, the environment size (i. e. the room for all variables) is a few KiB; 8...16 KiB is a reasonable size which fits even very complex situations. - To be able to manipulate the environment, you need to be able to actually enter the commands, i. e. you are limited by the console I/O Buffer Size (CONFIG_SYS_CBSIZE) and also by the print buffer size (CONFIG_SYS_PBSIZE). In many cases, these are set to 256... 1024 bytes - only 3 boards use more (2 x 2 KiB, 1 x 4 KiB). In general, your question makes me fear you are considering to do something seriously wrong. The environment is not a sutiable means to store any larger blobs of data. It is intended for a few (maybe some ten) variables, and theier values should be not longer than typical commands you might use on the command line - say, some 20...60 characters. When you find that your used environment size significantly exceeds 2...4 KiB, you should lean back and review what you are doing, because most probably you are doing something pretty much wrong. What exactly was your reason to worry about the maximum size for env vars? 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 Es sind überhaupt nur die Dummköpfe, die sich den Befehlen der Mäch- tigen widersetzen. Um sie zu ruinieren ist es genug, ihre Befehle treu zu erfüllen. - Peter Hacks: Die schöne Helena ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Zynq patches v2
Hi Michal, On Wed, 19 Feb 2014 09:48:13 +0100, Michal Simek mon...@monstr.eu wrote: Hi Albert, here is the second pull request with the rest of changes for zynq which haven't been applied. I have rebased my repo based on your master/next branch. As I wrote this pull request has on more patch from Siva about fixing bug in lldiv function. Compare to the first there is just 11 my patches because 2 were already applied. Please ping me if there is something wrong. Thanks, Michal The following changes since commit a87a0ce7028d5371c81d77ba72c1ba43a1ca77bc: Merge branch 'u-boot-pxa/master' into 'u-boot-arm/master' (2014-02-19 07:15:01 +0100) are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git zynq for you to fetch changes up to e158665c1e4c4665302f0d95e26b7c7e6b70a83c: arm: zynq: correct the argument to lldiv (2014-02-19 09:41:22 +0100) Michal Simek (11): zynq: Do not explicitely enable icache zynq: Enable dcache support zynq: Fix incorrect header name zynq: Extend kernel image size to 20MB zynq: Enable tftp put command zynq: Use board_eth_init if CMD_NET is not enabled zynq: Move bootmode to headers zynq: serial: Simplify serial driver initialization zynq: timer: Fix hangs if network activity attempted after about one hour zynq: Update CLK in bdinfo zynq: Add support for U-BOOT SPL Siva Durga Prasad Paladugu (1): arm: zynq: correct the argument to lldiv Soren Brinkmann (7): common: Provide DIV_ROUND_CLOSEST macro zynq: Provide a framework to read clock frequencies zynq: timer: Migrate to zynq clock framework net: zynq_gem: Move RCLK details out of driver net: zynq_gem: Calculate clock dividers dynamically serial_zynq: Migrate to Zynq clock framework zynq: Implement dump clock command arch/arm/cpu/armv7/zynq/Makefile | 2 + arch/arm/cpu/armv7/zynq/clk.c | 664 + arch/arm/cpu/armv7/zynq/cpu.c | 14 ++- arch/arm/cpu/armv7/zynq/slcr.c | 17 +-- arch/arm/cpu/armv7/zynq/spl.c | 69 +++ arch/arm/cpu/armv7/zynq/timer.c| 14 ++- arch/arm/cpu/armv7/zynq/u-boot-spl.lds | 61 ++ arch/arm/include/asm/arch-zynq/clk.h | 29 + arch/arm/include/asm/arch-zynq/hardware.h | 40 ++- arch/arm/include/asm/arch-zynq/spl.h | 18 +++ arch/arm/include/asm/arch-zynq/sys_proto.h | 2 +- board/xilinx/zynq/Makefile | 1 + board/xilinx/zynq/board.c | 10 -- board/xilinx/zynq/ps7_init.c | 12 ++ drivers/net/zynq_gem.c | 20 ++-- drivers/serial/serial_zynq.c | 33 +++-- include/common.h | 16 +++ include/configs/zynq-common.h | 102 +--- include/configs/zynq_zc70x.h | 2 +- include/configs/zynq_zed.h | 2 +- 20 files changed, 1055 insertions(+), 73 deletions(-) create mode 100644 arch/arm/cpu/armv7/zynq/clk.c create mode 100644 arch/arm/cpu/armv7/zynq/spl.c create mode 100644 arch/arm/cpu/armv7/zynq/u-boot-spl.lds create mode 100644 arch/arm/include/asm/arch-zynq/clk.h create mode 100644 arch/arm/include/asm/arch-zynq/spl.h create mode 100644 board/xilinx/zynq/ps7_init.c Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] ventana: Add Gateworks Ventana family support
Hi Stefano, On Fri, Feb 14, 2014 at 12:44 PM, Stefano Babic sba...@denx.de wrote: Hi Tim, On 13/02/2014 08:48, Tim Harvey wrote: Gateworks Ventana is a product family based on the i.MX6. This patch adds support for all boards in the Ventana family. Where possible, data from the boards EEPROM is used to determine various details about the board at runtime. Signed-off-by: Tim Harvey thar...@gateworks.com Cc: Stefano Babic sba...@denx.de Acked-by: Stefano Babic sba...@denx.de I noticed that this series is not part of your latest pull request to Albert. I would like to add support for PF100 PMIC into some boards, so it would be nice to have this series applied in your tree. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] getting environment variable
Hi, I am using uboot-toradex. In that How can i get environment variables from u boot and extract that variables in to linux? please reply.. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ENGR00299356 ARM:imx6 Fix USDHC driver bug in PIO mode
When configure the USDHC driver to PIO mode by defining
CONFIG_SYS_FSL_ESDHC_USE_PIO, the SD/MMC read and write will fail.
Two bugs in the driver to cause the issue:
1. The read buffer was invalidated after reading from DATAPORT register,
which should be only applied to DMA mode. The valid data in cache was
overwritten by physical memory.
2. The watermarks are not set in PIO mode, will cause according state not
be set.
Signed-off-by: Ye.Li b37...@freescale.com
---
drivers/mmc/fsl_esdhc.c | 23 +--
1 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index b5f6d62..bd0399a 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -190,7 +190,7 @@ static int esdhc_setup_data(struct mmc *mmc, struct
mmc_data *data)
int timeout;
struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg-esdhc_base;
-#ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
+
uint wml_value;
wml_value = data-blocksize/4;
@@ -200,12 +200,15 @@ static int esdhc_setup_data(struct mmc *mmc, struct
mmc_data *data)
wml_value = WML_RD_WML_MAX_VAL;
esdhc_clrsetbits32(regs-wml, WML_RD_WML_MASK, wml_value);
+#ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
esdhc_write32(regs-dsaddr, (u32)data-dest);
+#endif
} else {
+#ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
flush_dcache_range((ulong)data-src,
(ulong)data-src+data-blocks
*data-blocksize);
-
+#endif
if (wml_value WML_WR_WML_MAX)
wml_value = WML_WR_WML_MAX_VAL;
if ((esdhc_read32(regs-prsstat) PRSSTAT_WPSPL) == 0) {
@@ -215,19 +218,10 @@ static int esdhc_setup_data(struct mmc *mmc, struct
mmc_data *data)
esdhc_clrsetbits32(regs-wml, WML_WR_WML_MASK,
wml_value 16);
+#ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
esdhc_write32(regs-dsaddr, (u32)data-src);
+#endif
}
-#else /* CONFIG_SYS_FSL_ESDHC_USE_PIO */
- if (!(data-flags MMC_DATA_READ)) {
- if ((esdhc_read32(regs-prsstat) PRSSTAT_WPSPL) == 0) {
- printf(\nThe SD card is locked.
- Can not write to a locked card.\n\n);
- return TIMEOUT;
- }
- esdhc_write32(regs-dsaddr, (u32)data-src);
- } else
- esdhc_write32(regs-dsaddr, (u32)data-dest);
-#endif /* CONFIG_SYS_FSL_ESDHC_USE_PIO */
esdhc_write32(regs-blkattr, data-blocks 16 | data-blocksize);
@@ -410,9 +404,10 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd,
struct mmc_data *data)
if (irqstat DATA_ERR)
return COMM_ERR;
} while ((irqstat DATA_COMPLETE) != DATA_COMPLETE);
-#endif
+
if (data-flags MMC_DATA_READ)
check_and_invalidate_dcache_range(cmd, data);
+#endif
}
esdhc_write32(regs-irqstat, -1);
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-boot] question about one env variable size
Hi, Denk: Thanks a lot! I got it! Not exceed CONFIG_SYS_PBSIZE defined in my platform config file is a good choice! What exactly was your reason to worry about the maximum size for env vars? My colleage wanted to save a variable which contains 8KB data. He asked me whether it was ok for u-boot code. So, i asked this question! Best regards, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] ventana: Add Gateworks Ventana family support
Hi Fabio, On 19/02/2014 12:35, Fabio Estevam wrote: Hi Stefano, On Fri, Feb 14, 2014 at 12:44 PM, Stefano Babic sba...@denx.de wrote: Hi Tim, On 13/02/2014 08:48, Tim Harvey wrote: Gateworks Ventana is a product family based on the i.MX6. This patch adds support for all boards in the Ventana family. Where possible, data from the boards EEPROM is used to determine various details about the board at runtime. Signed-off-by: Tim Harvey thar...@gateworks.com Cc: Stefano Babic sba...@denx.de Acked-by: Stefano Babic sba...@denx.de I noticed that this series is not part of your latest pull request to Albert. Right, I left this one in the queue. I applied only the older ones. I would like to add support for PF100 PMIC into some boards, so it would be nice to have this series applied in your tree. ok - I have not open points with the patch, and I do not think there will be more comments. I will apply it soon. Regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Zynq patches v2
On 02/19/2014 12:03 PM, Albert ARIBAUD wrote: Hi Michal, On Wed, 19 Feb 2014 09:48:13 +0100, Michal Simek mon...@monstr.eu wrote: Hi Albert, here is the second pull request with the rest of changes for zynq which haven't been applied. I have rebased my repo based on your master/next branch. As I wrote this pull request has on more patch from Siva about fixing bug in lldiv function. Compare to the first there is just 11 my patches because 2 were already applied. Please ping me if there is something wrong. Thanks, Michal The following changes since commit a87a0ce7028d5371c81d77ba72c1ba43a1ca77bc: Merge branch 'u-boot-pxa/master' into 'u-boot-arm/master' (2014-02-19 07:15:01 +0100) are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git zynq for you to fetch changes up to e158665c1e4c4665302f0d95e26b7c7e6b70a83c: arm: zynq: correct the argument to lldiv (2014-02-19 09:41:22 +0100) Michal Simek (11): zynq: Do not explicitely enable icache zynq: Enable dcache support zynq: Fix incorrect header name zynq: Extend kernel image size to 20MB zynq: Enable tftp put command zynq: Use board_eth_init if CMD_NET is not enabled zynq: Move bootmode to headers zynq: serial: Simplify serial driver initialization zynq: timer: Fix hangs if network activity attempted after about one hour zynq: Update CLK in bdinfo zynq: Add support for U-BOOT SPL Siva Durga Prasad Paladugu (1): arm: zynq: correct the argument to lldiv Soren Brinkmann (7): common: Provide DIV_ROUND_CLOSEST macro zynq: Provide a framework to read clock frequencies zynq: timer: Migrate to zynq clock framework net: zynq_gem: Move RCLK details out of driver net: zynq_gem: Calculate clock dividers dynamically serial_zynq: Migrate to Zynq clock framework zynq: Implement dump clock command arch/arm/cpu/armv7/zynq/Makefile | 2 + arch/arm/cpu/armv7/zynq/clk.c | 664 + arch/arm/cpu/armv7/zynq/cpu.c | 14 ++- arch/arm/cpu/armv7/zynq/slcr.c | 17 +-- arch/arm/cpu/armv7/zynq/spl.c | 69 +++ arch/arm/cpu/armv7/zynq/timer.c| 14 ++- arch/arm/cpu/armv7/zynq/u-boot-spl.lds | 61 ++ arch/arm/include/asm/arch-zynq/clk.h | 29 + arch/arm/include/asm/arch-zynq/hardware.h | 40 ++- arch/arm/include/asm/arch-zynq/spl.h | 18 +++ arch/arm/include/asm/arch-zynq/sys_proto.h | 2 +- board/xilinx/zynq/Makefile | 1 + board/xilinx/zynq/board.c | 10 -- board/xilinx/zynq/ps7_init.c | 12 ++ drivers/net/zynq_gem.c | 20 ++-- drivers/serial/serial_zynq.c | 33 +++-- include/common.h | 16 +++ include/configs/zynq-common.h | 102 +--- include/configs/zynq_zc70x.h | 2 +- include/configs/zynq_zed.h | 2 +- 20 files changed, 1055 insertions(+), 73 deletions(-) create mode 100644 arch/arm/cpu/armv7/zynq/clk.c create mode 100644 arch/arm/cpu/armv7/zynq/spl.c create mode 100644 arch/arm/cpu/armv7/zynq/u-boot-spl.lds create mode 100644 arch/arm/include/asm/arch-zynq/clk.h create mode 100644 arch/arm/include/asm/arch-zynq/spl.h create mode 100644 board/xilinx/zynq/ps7_init.c Applied to u-boot-arm/master, thanks! Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] ventana: Add Gateworks Ventana family support
Hi Fabio, On 19/02/2014 12:35, Fabio Estevam wrote: Hi Stefano, On Fri, Feb 14, 2014 at 12:44 PM, Stefano Babic sba...@denx.de wrote: Hi Tim, On 13/02/2014 08:48, Tim Harvey wrote: Gateworks Ventana is a product family based on the i.MX6. This patch adds support for all boards in the Ventana family. Where possible, data from the boards EEPROM is used to determine various details about the board at runtime. Signed-off-by: Tim Harvey thar...@gateworks.com Cc: Stefano Babic sba...@denx.de Acked-by: Stefano Babic sba...@denx.de I noticed that this series is not part of your latest pull request to Albert. I would like to add support for PF100 PMIC into some boards, so it would be nice to have this series applied in your tree. I see now in patchworks that PF100's patch is assigned to Tom - this makes sense because it is not strictly i.MX code. I can apply it myself if Tom agrees. Regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 3/3] move wandboard over to use the generic distro configuratin and environment
Hello Dennis,
the short log should use the standard for the commit logs.
On Mon, Feb 17, 2014 at 2:56 PM, Dennis Gilmore den...@ausil.us wrote:
Signed-off-by: Dennis Gilmore den...@ausil.us
---
include/configs/wandboard.h | 87
+++--
1 file changed, 12 insertions(+), 75 deletions(-)
diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
index 3488472..bb7aadd 100644
--- a/include/configs/wandboard.h
+++ b/include/configs/wandboard.h
@@ -41,6 +41,11 @@
#define CONFIG_CONS_INDEX 1
#define CONFIG_BAUDRATE115200
+#ifndef CONFIG_SPL_BUILD
+#include config_distro_defaults.h
+#include config_distro_bootcmd.h
+#endif
+
/* Command definition */
#include config_cmd_default.h
@@ -49,8 +54,6 @@
#define CONFIG_CMD_BMODE
#define CONFIG_CMD_SETEXPR
-#define CONFIG_BOOTDELAY 5
-
#define CONFIG_SYS_MEMTEST_START 0x1000
#define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_MEMTEST_START + 500 *
SZ_1M)
#define CONFIG_LOADADDR0x1200
@@ -66,15 +69,8 @@
#define CONFIG_CMD_MMC
#define CONFIG_GENERIC_MMC
#define CONFIG_BOUNCE_BUFFER
-#define CONFIG_CMD_EXT2
-#define CONFIG_CMD_FAT
-#define CONFIG_DOS_PARTITION
/* Ethernet Configuration */
-#define CONFIG_CMD_PING
-#define CONFIG_CMD_DHCP
-#define CONFIG_CMD_MII
-#define CONFIG_CMD_NET
#define CONFIG_FEC_MXC
#define CONFIG_MII
#define IMX_FEC_BASE ENET_BASE_ADDR
@@ -114,8 +110,12 @@
fdt_high=0x\0 \
initrd_high=0x\0 \
fdt_file= CONFIG_DEFAULT_FDT_FILE \0 \
- fdt_addr=0x1800\0 \
+ fdt_addr_r=0x1800\0 \
boot_fdt=try\0 \
+ pxefile_addr_r=0x17e0\0 \
+ scriptaddr=0x17d0\0 \
+ kernel_addr_r=0x1300\0 \
+ ramdisk_addr_r=0x1500\0 \
At least the address that are common to SoCs shouldn't be duplicated
here, do it?
ip_dyn=yes\0 \
mmcdev= __stringify(CONFIG_SYS_MMC_ENV_DEV) \0 \
mmcpart=1\0 \
@@ -134,70 +134,12 @@
mmc write ${loadaddr} 0x2 ${fw_sz}; \
fi; \
fi\0 \
- mmcargs=setenv bootargs console=${console},${baudrate} \
- root=${mmcroot}\0 \
- loadbootscript= \
- fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0 \
- bootscript=echo Running bootscript from mmc ...; \
- source\0 \
- loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0 \
- loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0 \
- mmcboot=echo Booting from mmc ...; \
- run mmcargs; \
- if test ${boot_fdt} = yes || test ${boot_fdt} = try; then \
- if run loadfdt; then \
- bootz ${loadaddr} - ${fdt_addr}; \
- else \
- if test ${boot_fdt} = try; then \
- bootz; \
- else \
- echo WARN: Cannot load the DT; \
- fi; \
- fi; \
- else \
- bootz; \
- fi;\0 \
- netargs=setenv bootargs console=${console},${baudrate} \
- root=/dev/nfs \
- ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0 \
- netboot=echo Booting from net ...; \
- run netargs; \
- if test ${ip_dyn} = yes; then \
- setenv get_cmd dhcp; \
- else \
- setenv get_cmd tftp; \
- fi; \
- ${get_cmd} ${image}; \
- if test ${boot_fdt} = yes || test ${boot_fdt} = try; then \
- if ${get_cmd} ${fdt_addr} ${fdt_file}; then \
- bootz ${loadaddr} - ${fdt_addr}; \
- else \
- if test ${boot_fdt} = try; then \
- bootz; \
- else \
- echo WARN: Cannot load the DT; \
- fi; \
- fi; \
- else \
- bootz; \
- fi;\0
+ BOOTCMDS_COMMON
#define CONFIG_BOOTCOMMAND \
- mmc dev ${mmcdev}; if mmc rescan; then \
- if run loadbootscript; then \
- run bootscript; \
- else \
- if run loadimage; then \
- run mmcboot; \
- else run netboot; \
- fi; \
- fi; \
Re: [U-Boot] [PATCH] part_efi: fix protective_mbr struct allocation
On 02/19/2014 11:16 AM, Albert ARIBAUD wrote: On Wed, 19 Feb 2014 11:08:03 +0100, Albert ARIBAUD Thanks for pointing out. Now it is perfectly visible :-) Inclusion of v2 has been postponed since there was a discussion if we shall allow unaligned access (-mno-unaligned-access flag) at armv7 (after patches posted by Tom). As fair as I can tell, we will keep the current approach so, I think that Tom will be willing to pull this patch (v2) now. Agreed, but then we should make sure no one has comments on V2 that they might have withheld due to the initial rejection of V2. Any comments? This patch do fix unaligned access problem on Trats2 (Exynos4412), when we restore/create GPT, so I would like to know if there are any new inquires regarding this patch. Does not seem to be, so I will apply V2. Correction: I would like it to be applied as per current ARM alignment policy, but this patch is not ARM per se and is in Tom's hands. Tom, can you apply http://patchwork.ozlabs.org/patch/314717/ ? This would by no means close the discussion I opened, and in the event of a policy change, the patch could always be reverted; meanwhile, it matches our current policy. I tested Piotr's patch on i.MX6 (armv7) custom board and it is working fine without the -mno-unaligned-access flag. Tested-by: Hector Palacios hector.palac...@digi.com -- Héctor Palacios ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8 0/38] Switch over to real Kbuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/18/2014 08:57 PM, Masahiro Yamada wrote: Hello Tom, I notice Kbuild fails to build venice2 board because commit 52ef43b0529 added an empty Makefile, arch/arm/cpu/armv7/tegra124/Makefile. What shall we do with this? Do you need v10 or shall I fix it in a follow-up patch? Lets go with follow up patch. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTBKluAAoJENk4IS6UOR1WxNAP/0ITe8+c1IjxQjdNL2Otyh4K y23jEXo3wypC1t1NO11b0wuhr/3eXMgmKIE3S3vuo/zgNatCiPuuer+XDaHyYW00 4IZcD/CFulMyWOFAzoZvdvInuY60QPvBZi2LEjmtlsm35CC/gR7jtPWzOTOvdPxl Fnk0tUNa1p5s7B+lRWnVbp6Mg6UEBP55p3nO0jKwYO6dQkGXj0qvqr21eMz+QcDL 3T+pV/llPieh+gwkHgz6Ze6sOOhQpAWmUr3GmYEUiXTJFTyTzxplWNEcluAzwGU/ RjboXErzNPdr3nRUjQ6qGwUe0plR4DU39uxjd87ipxK+4kvRpT2yiDQIxQp+0Aqi 6OthFlR0UJzEg2yFYwz1oQsRLoGzPJeYhfNtBXhBU0Jv1iBEEZb83+narnhgkyQg kXHUeoRmfctlNPqAxMVv5k6UpHTB8cchZ1btNaaxLNv+hcQ7sfecfEPflmUyf/aD sttN43PvT26GvcnH79x8dgR/r/ShJPlTVkvW32Z8hRostrGHyL7IefEMLe9zGYC5 +BG65pz0U0d9/taYwdL+UfukYzbjiOQufGlfnoQ1JJjsN7L30rrTcMSgOc0PzJXN oDIEpcNwyUvbM4e8MnIexVtLmdm44mOWqvSfOvVrPTMzlkDYsWFOYmsgeLKhtW2j Q6efuCYcEvJWP1zcdP+X =KiYY -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ENGR00299356 ARM:imx6 Fix USDHC driver bug in PIO mode
Hi Ye.Li,
On Wed, 19 Feb 2014 18:33:31 +0800, Ye.Li b37...@freescale.com wrote:
When configure the USDHC driver to PIO mode by defining
CONFIG_SYS_FSL_ESDHC_USE_PIO, the SD/MMC read and write will fail.
Two bugs in the driver to cause the issue:
1. The read buffer was invalidated after reading from DATAPORT register,
which should be only applied to DMA mode. The valid data in cache was
overwritten by physical memory.
2. The watermarks are not set in PIO mode, will cause according state not
be set.
What does the ENGR00299356 part of the subject line mean?
Also, in subject line: rewrite arm:imx6 as arm: imx56:
Signed-off-by: Ye.Li b37...@freescale.com
---
drivers/mmc/fsl_esdhc.c | 23 +--
1 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index b5f6d62..bd0399a 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -190,7 +190,7 @@ static int esdhc_setup_data(struct mmc *mmc, struct
mmc_data *data)
int timeout;
struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg-esdhc_base;
-#ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
+
uint wml_value;
wml_value = data-blocksize/4;
@@ -200,12 +200,15 @@ static int esdhc_setup_data(struct mmc *mmc, struct
mmc_data *data)
wml_value = WML_RD_WML_MAX_VAL;
esdhc_clrsetbits32(regs-wml, WML_RD_WML_MASK, wml_value);
+#ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
esdhc_write32(regs-dsaddr, (u32)data-dest);
+#endif
} else {
+#ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
flush_dcache_range((ulong)data-src,
(ulong)data-src+data-blocks
*data-blocksize);
-
+#endif
if (wml_value WML_WR_WML_MAX)
wml_value = WML_WR_WML_MAX_VAL;
if ((esdhc_read32(regs-prsstat) PRSSTAT_WPSPL) == 0) {
@@ -215,19 +218,10 @@ static int esdhc_setup_data(struct mmc *mmc, struct
mmc_data *data)
esdhc_clrsetbits32(regs-wml, WML_WR_WML_MASK,
wml_value 16);
+#ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
esdhc_write32(regs-dsaddr, (u32)data-src);
+#endif
}
-#else/* CONFIG_SYS_FSL_ESDHC_USE_PIO */
- if (!(data-flags MMC_DATA_READ)) {
- if ((esdhc_read32(regs-prsstat) PRSSTAT_WPSPL) == 0) {
- printf(\nThe SD card is locked.
- Can not write to a locked card.\n\n);
- return TIMEOUT;
- }
- esdhc_write32(regs-dsaddr, (u32)data-src);
- } else
- esdhc_write32(regs-dsaddr, (u32)data-dest);
-#endif /* CONFIG_SYS_FSL_ESDHC_USE_PIO */
esdhc_write32(regs-blkattr, data-blocks 16 | data-blocksize);
@@ -410,9 +404,10 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd,
struct mmc_data *data)
if (irqstat DATA_ERR)
return COMM_ERR;
} while ((irqstat DATA_COMPLETE) != DATA_COMPLETE);
-#endif
+
if (data-flags MMC_DATA_READ)
check_and_invalidate_dcache_range(cmd, data);
+#endif
}
esdhc_write32(regs-irqstat, -1);
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] microblaze: remove an empty file arch/microblaze/lib/time.c
Commit 779bf42c moved timer functions from arch/microblaze/lib/time.c to arch/microblaze/cpu/timer.c. But the empty file, arch/microblaze/lib/time.c has been remaining probably for a human mistake. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Michal Simek michal.si...@xilinx.com --- arch/microblaze/lib/time.c | 0 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 arch/microblaze/lib/time.c diff --git a/arch/microblaze/lib/time.c b/arch/microblaze/lib/time.c deleted file mode 100644 index e69de29..000 -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] show_boot_progress
Hi Albert, On Wed, Feb 19, 2014 at 12:32 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Abdullah, I use u-boot version 1.3.3. Any reason to use a five-years-old release? The development board I use supports u-boot version 1.3.3 and I couldn't manage to port the functions to newer releases of u-boot. abdullah ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] ventana: Add Gateworks Ventana family support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/19/2014 06:51 AM, Stefano Babic wrote: Hi Fabio, On 19/02/2014 12:35, Fabio Estevam wrote: Hi Stefano, On Fri, Feb 14, 2014 at 12:44 PM, Stefano Babic sba...@denx.de wrote: Hi Tim, On 13/02/2014 08:48, Tim Harvey wrote: Gateworks Ventana is a product family based on the i.MX6. This patch adds support for all boards in the Ventana family. Where possible, data from the boards EEPROM is used to determine various details about the board at runtime. Signed-off-by: Tim Harvey thar...@gateworks.com Cc: Stefano Babic sba...@denx.de Acked-by: Stefano Babic sba...@denx.de I noticed that this series is not part of your latest pull request to Albert. I would like to add support for PF100 PMIC into some boards, so it would be nice to have this series applied in your tree. I see now in patchworks that PF100's patch is assigned to Tom - this makes sense because it is not strictly i.MX code. I can apply it myself if Tom agrees. Go ahead and take it, thanks! - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTBK9KAAoJENk4IS6UOR1W6UQP/1FU2EZrh7EEl4mCFPuQQbMb dpQ/QmDjrWoqjGCcxXIce03Fv2y35lHbezOZ3CsWUsZ1No3jmz0SDw4nK1VNMxg7 Un0n2PmMzj5Fez3vF2I33C1gDo7jfbuLdPob/IRgh0rI9T1LDuMfVI3v4GggqCZg eTXW9KISsdZk2/jYcwgt7B4ZIXYFPU02NlmzCvH816NZsntcNZCdn+SJ4oM7uMBo 2mZNCtcso/c9s6BgcnPOaX66vPM2hGpcaQ+yakOkkcLO273ZoqK35iMU3tAl90fb lCWQkLogwEf9JJo4i9hGdgl3NB3Cic+kLO3bVlcBMb6I3xQyQt8QXRlNXnp76QEj HPPYzEgZW1mCg6ahmQlYYpTPojj5YPH6ddk+hNx5acz3t0DUOJmi4EwS78q/Odx8 gaAMA7a3C+3EezssnutKWDKe/hgRoji02qDEuv6460ksDwXfdzPFWiTAy0nVFHQD 2oK6CF0hyR5nuSvQDd9vXDZnBwfKkNxUODo62t5VC2BwdPLs18+GJ1eQ3JEsa636 BbFSxK1Y+wYngpT4CxT01Yux5+D3T7/6n1Lm16/5HTvG78itRDrf9D8b/ugWQrjy 2KUZpRtGVTRNM9htyvokJDG1RNRnKpCeObCxWte5YYgLAnWv4N4qesLQnuAZ/t3B rz3WjkF7nBIb/kgbezEs =/5pp -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] kbuild,tegra124: add dummy obj- for Kbuild
In Kbuild, every makefile must have non-empty obj- or obj-y. Otherwise, built-in.o will not be created and the link stage will fail. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- Tom, Please apply this along with the Kbuild series. arch/arm/cpu/armv7/tegra124/Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/cpu/armv7/tegra124/Makefile b/arch/arm/cpu/armv7/tegra124/Makefile index 7f127b1..9478d44 100644 --- a/arch/arm/cpu/armv7/tegra124/Makefile +++ b/arch/arm/cpu/armv7/tegra124/Makefile @@ -4,3 +4,6 @@ # # SPDX-License-Identifier: GPL-2.0+ # + +# necessary to create built-in.o +obj- := __dummy__.o -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8 0/38] Switch over to real Kbuild
Hello Tom, I notice Kbuild fails to build venice2 board because commit 52ef43b0529 added an empty Makefile, arch/arm/cpu/armv7/tegra124/Makefile. What shall we do with this? Do you need v10 or shall I fix it in a follow-up patch? Lets go with follow up patch. I have posted it. http://patchwork.ozlabs.org/patch/321899/ Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC unified boot environment
On Tue, Feb 18, 2014 at 10:09:10AM -0600, Dennis Gilmore wrote: I'm putting what I have for the documentation so far at the end of this email. I think that soc families should have a common settings file, each board should have its on file and then we have a common set of configurations on how to boot. For the next round, please put this into doc/ as part of the first patch. Thanks! [snip] fdt_addr_r: Mandatory, This is the location where the sysboot/pxeboot with load the dtb to, using the fdtdir/devicetreedir or fdt/devicetree options in the pxe/extlinux config file. The location can be anywhere in ram it just needs to not overlap with anything, allowing 1 megabyte seems to be a safe option. ramdisk_addr_r: Mandatory, This is the location where the sysboot/pxeboot with load the initramfs to, using the initrd option in the pxe/extlinux config file, the location of the initramfs does not matter, there needs to be enough room to be able to store any image. Making the image the last item stored should allow for any initramfs to fit and not overwrite anything else. kernel_addr_r: Mandatory, pxe_addr_r: Mandatory, used by the PXE code to hold the pxelinux config file. The location can be anywhere in ram it just needs to not overlap with anything, allowing 1 megabyte seems to be a safe option. scriptaddr: Mandatory, suggested mapping: 16M We need to talk much more about the suggested mapping as there's a few hard requirements that must be obeyed. The device tree _must_ be placed within kernel accessible low mem and not overwritten by zImage decompression. A reference to Documentation/arm/Booting in the kernel would also be helpful and then summarize saying kernel_addr_r should be above 32MiB and below 128MiB from the base of system ram. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ENGR00299356 ARM:imx6 Fix USDHC driver bug in PIO mode
Hi Ye.Li, On 19/02/2014 11:33, Ye.Li wrote: When configure the USDHC driver to PIO mode by defining CONFIG_SYS_FSL_ESDHC_USE_PIO, the SD/MMC read and write will fail. Two bugs in the driver to cause the issue: 1. The read buffer was invalidated after reading from DATAPORT register, which should be only applied to DMA mode. The valid data in cache was overwritten by physical memory. 2. The watermarks are not set in PIO mode, will cause according state not be set. Signed-off-by: Ye.Li b37...@freescale.com --- Why is this an ARM/i.MX6 issue only ? As far as I read, this is not strictly related to the SOC. Currently, there is no ARM boards setting CONFIG_SYS_FSL_ESDHC_USE_PIO. The only boards using it are PowerPC boards (the driver is platform independent): P1_P2_RDB and MPC8308RDB. Regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
On Mon, Feb 17, 2014 at 11:56:36AM -0600, Dennis Gilmore wrote:
Signed-off-by: Dennis Gilmore den...@ausil.us
[snip]
+ if ${usb_need_init}; then \
+ set usb_need_init false; \
+ usb start 0; \
Checking common/cmd_usb.c, 'start' doesn't take arguments.
+#ifdef CONFIG_CMD_SATA
+#define BOOTCMDS_SATA \
+ sata_boot= \
+ setenv devtype sata; \
+ if sata dev ${devnum}; then \
+ run scan_boot; \
+ fi\0 \
+ \
+ bootcmd_sata0=setenv devnum 0; run sata_boot;\0
+ bootcmd_sata1=setenv devnum 1; run sata_boot;\0
+#define BOOT_TARGETS_USB sata0 sata1
Typo, s/USB/SATA/
+#ifdef CONFIG_CMD_DHCP
+#define BOOTCMDS_DHCP \
+ bootcmd_dhcp= \
+ BOOTCMD_INIT_USB \
Why BOOTCMD_INIT_USB here? For USB based networking? If so, add some
comments please.
+ if dhcp ${scriptaddr} boot.scr.uimg; then \
+ source ${scriptaddr}; \
+ fi\0
This relies on autoload being true, so we should set that.
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Patchwork would not pick my patch again
Hello Jeremy, I'd like to file a bug report of Patchwork. I posted a patch to delete an empty file: http://lists.denx.de/pipermail/u-boot/2014-February/173795.html But it would not appear on Patchwork. A few month ago, I mentioned Patchwork did not grab a patch that changes file permissons. (I don't know if it has been already fixed.) This is another case Patchwork misses a patch, right? Tom, could you pick up my trivial patch directly from ML? Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 2/3] move the beaglebones over to the generic configs
On Mon, Feb 17, 2014 at 11:56:37AM -0600, Dennis Gilmore wrote:
[snip]
- nand read ${fdtaddr} u-boot-spl-os; \
+ nand read ${fdt_addr} u-boot-spl-os; \
nand read ${loadaddr} kernel; \
- bootz ${loadaddr} - ${fdtaddr}\0
+ bootz ${loadaddr} - ${fdt_addr}\0
In all of these conversions you should switch loadaddr to kernel_addr_r
too.
[snip]
- fdtfile=undefined\0 \
That's a problem. Need this for 'findfdt' to work.
- rootpath=/export/rootfs\0 \
- nfsopts=nolock\0 \
- static_ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname} \
- ::off\0 \
[snip]
- spiroot=/dev/mtdblock4 rw\0 \
- spirootfstype=jffs2\0 \
- spisrcaddr=0xe\0 \
- spiimgsize=0x362000\0 \
- spibusno=0\0 \
- spiargs=setenv bootargs console=${console} \
- ${optargs} \
- root=${spiroot} \
- rootfstype=${spirootfstype}\0 \
- netargs=setenv bootargs console=${console} \
- ${optargs} \
- root=/dev/nfs \
- nfsroot=${serverip}:${rootpath},${nfsopts} rw \
- ip=dhcp\0 \
[snip]
- spiboot=echo Booting from spi ...; \
- run spiargs; \
- sf probe ${spibusno}:0; \
- sf read ${loadaddr} ${spisrcaddr} ${spiimgsize}; \
- bootz ${loadaddr}\0 \
- netboot=echo Booting from network ...; \
- setenv autoload no; \
- dhcp; \
- tftp ${loadaddr} ${bootfile}; \
- tftp ${fdtaddr} ${fdtfile}; \
- run netargs; \
- bootz ${loadaddr} - ${fdtaddr}\0 \
- ramboot=echo Booting from ramdisk ...; \
- run ramargs; \
- bootz ${loadaddr} ${rdaddr} ${fdtaddr}\0 \
And this is functionality I don't see in the generic distro config that
we still need.
[snip]
/*
- * Common filesystems support. When we have removable storage we
- * enabled a number of useful commands and support.
+ * Include the generic config options and boot environment when not
+ * building our SPL
*/
-#if defined(CONFIG_MMC) || defined(CONFIG_USB_STORAGE)
-#define CONFIG_DOS_PARTITION
-#define CONFIG_CMD_FAT
-#define CONFIG_FAT_WRITE
-#define CONFIG_CMD_EXT2
-#define CONFIG_CMD_EXT4
-#define CONFIG_CMD_FS_GENERIC
+#ifndef CONFIG_SPL_BUILD
+#include config_distro_defaults.h
+#include config_distro_bootcmd.h
#endif
This is fine, for now, but I'll have to shuffle things around later as
some of the good feedback I'd gotten off-list about ti_armv7_common.h is
that it's not as useful for non-Linux targets, so I need to adjust the
contents a bit more.
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] microblaze: remove an empty file arch/microblaze/lib/time.c
Hi, On 02/19/2014 02:10 PM, Masahiro Yamada wrote: Commit 779bf42c moved timer functions from arch/microblaze/lib/time.c to arch/microblaze/cpu/timer.c. But the empty file, arch/microblaze/lib/time.c has been remaining probably for a human mistake. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Michal Simek michal.si...@xilinx.com --- arch/microblaze/lib/time.c | 0 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 arch/microblaze/lib/time.c diff --git a/arch/microblaze/lib/time.c b/arch/microblaze/lib/time.c deleted file mode 100644 index e69de29..000 Applied to microblaze next branch. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Patchwork would not pick my patch again
On Wed, Feb 19, 2014 at 10:43:07PM +0900, Masahiro Yamada wrote: Hello Jeremy, I'd like to file a bug report of Patchwork. I posted a patch to delete an empty file: http://lists.denx.de/pipermail/u-boot/2014-February/173795.html But it would not appear on Patchwork. A few month ago, I mentioned Patchwork did not grab a patch that changes file permissons. (I don't know if it has been already fixed.) This is another case Patchwork misses a patch, right? Tom, could you pick up my trivial patch directly from ML? I will, yes, thanks. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
On Wed, 19 Feb 2014 08:42:57 -0500
Tom Rini tr...@ti.com wrote:
On Mon, Feb 17, 2014 at 11:56:36AM -0600, Dennis Gilmore wrote:
Signed-off-by: Dennis Gilmore den...@ausil.us
[snip]
+ if ${usb_need_init}; then \
+ set usb_need_init false; \
+ usb start 0; \
Checking common/cmd_usb.c, 'start' doesn't take arguments.
Copied from tegra-common-post.h as is, will fix it up
+#ifdef CONFIG_CMD_SATA
+#define BOOTCMDS_SATA \
+ sata_boot= \
+ setenv devtype sata; \
+ if sata dev ${devnum}; then \
+ run scan_boot; \
+ fi\0 \
+ \
+ bootcmd_sata0=setenv devnum 0; run sata_boot;\0
+ bootcmd_sata1=setenv devnum 1; run sata_boot;\0
+#define BOOT_TARGETS_USB sata0 sata1
Typo, s/USB/SATA/
will fix
+#ifdef CONFIG_CMD_DHCP
+#define BOOTCMDS_DHCP \
+ bootcmd_dhcp= \
+ BOOTCMD_INIT_USB \
Why BOOTCMD_INIT_USB here? For USB based networking? If so, add some
comments please.
It was Copied from tegra-common-post.h im assuming that it to support
booting from a usb attached nic
+ if dhcp ${scriptaddr} boot.scr.uimg; then \
+ source ${scriptaddr}; \
+ fi\0
This relies on autoload being true, so we should set that.
okay, will fix it up.
Thanks
Dennis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] microblaze: remove an empty file arch/microblaze/lib/time.c
On Wed, Feb 19, 2014 at 02:55:19PM +0100, Michal Simek wrote: Hi, On 02/19/2014 02:10 PM, Masahiro Yamada wrote: Commit 779bf42c moved timer functions from arch/microblaze/lib/time.c to arch/microblaze/cpu/timer.c. But the empty file, arch/microblaze/lib/time.c has been remaining probably for a human mistake. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Michal Simek michal.si...@xilinx.com --- arch/microblaze/lib/time.c | 0 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 arch/microblaze/lib/time.c diff --git a/arch/microblaze/lib/time.c b/arch/microblaze/lib/time.c deleted file mode 100644 index e69de29..000 Applied to microblaze next branch. We'll need this soonish, I'm going to grab it and apply shortly if you don't mind. Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MAKEALL
Hello Simon, It is not used by default, but there is a -j option. If you use -j, first make sure you reduce the number of threads to compensate. So for example you can use: buildman -j 8 -T 1 Ooh! I did not know buildman has such options. Thanks! The intent was that buildman supported everything that MAKEALL does and more. I believe that is true except for the in-tree build you mention above. However, I think there might also be some small difference between the way the -f option is implemented in buildman, and the way MAKEALL works. It might be worth splitting the -f option into two: - one to force rebuild of a board - another to force a reconfigure on every build Then we could be sure. In summary, if we do that and support in-tree builds then I think buildman has all the features of MAKEALL. That's good to know. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] microblaze: remove an empty file arch/microblaze/lib/time.c
On 02/19/2014 03:03 PM, Tom Rini wrote: On Wed, Feb 19, 2014 at 02:55:19PM +0100, Michal Simek wrote: Hi, On 02/19/2014 02:10 PM, Masahiro Yamada wrote: Commit 779bf42c moved timer functions from arch/microblaze/lib/time.c to arch/microblaze/cpu/timer.c. But the empty file, arch/microblaze/lib/time.c has been remaining probably for a human mistake. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Michal Simek michal.si...@xilinx.com --- arch/microblaze/lib/time.c | 0 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 arch/microblaze/lib/time.c diff --git a/arch/microblaze/lib/time.c b/arch/microblaze/lib/time.c deleted file mode 100644 index e69de29..000 Applied to microblaze next branch. We'll need this soonish, I'm going to grab it and apply shortly if you don't mind. Thanks! Sure. Feel free to take it directly. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] part_efi: fix protective_mbr struct allocation
Hi Hector, On Wed, 19 Feb 2014 13:52:07 +0100, Palacios, Hector hector.palac...@digi.com wrote: On 02/19/2014 11:16 AM, Albert ARIBAUD wrote: On Wed, 19 Feb 2014 11:08:03 +0100, Albert ARIBAUD Thanks for pointing out. Now it is perfectly visible :-) Inclusion of v2 has been postponed since there was a discussion if we shall allow unaligned access (-mno-unaligned-access flag) at armv7 (after patches posted by Tom). As fair as I can tell, we will keep the current approach so, I think that Tom will be willing to pull this patch (v2) now. Agreed, but then we should make sure no one has comments on V2 that they might have withheld due to the initial rejection of V2. Any comments? This patch do fix unaligned access problem on Trats2 (Exynos4412), when we restore/create GPT, so I would like to know if there are any new inquires regarding this patch. Does not seem to be, so I will apply V2. Correction: I would like it to be applied as per current ARM alignment policy, but this patch is not ARM per se and is in Tom's hands. Tom, can you apply http://patchwork.ozlabs.org/patch/314717/ ? This would by no means close the discussion I opened, and in the event of a policy change, the patch could always be reverted; meanwhile, it matches our current policy. I tested Piotr's patch on i.MX6 (armv7) custom board and it is working fine without the -mno-unaligned-access flag. Tested-by: Hector Palacios hector.palac...@digi.com You've just Tested-By-ed your own patch, I think. ... but I am the one to blame, and should not have discussed Piotr's patch in this thread. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] show_boot_progress
Hi Abdullah, On Wed, 19 Feb 2014 15:14:42 +0200, Abdullah YILDIZ abdullah.ma...@gmail.com wrote: Hi Albert, On Wed, Feb 19, 2014 at 12:32 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Abdullah, I use u-boot version 1.3.3. Any reason to use a five-years-old release? The development board I use supports u-boot version 1.3.3 and I couldn't manage to port the functions to newer releases of u-boot. What board is that? abdullah Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] part_efi: fix protective_mbr struct allocation
On Wed, Feb 19, 2014 at 09:19:04AM +0100, Lukasz Majewski wrote: Hi Albert, Tom Hi Lukasz, On Wed, 12 Feb 2014 21:45:41 +0100, Lukasz Majewski l.majew...@majess.pl wrote: I think, that the patch for fixing the unaligned access in this function has already been posted by Piotr Wilczek. We have experienced similar issues with Samsung's Exynos4 based targets. [PATCH V2] disk:efi: avoid unaligned access on efi partition Despite its disappearance from patchwork it shall be available at mailing list archive. The v1 can be found at the following link: http://patchwork.ozlabs.org/patch/282753/ Neither V1 nor V2 have disappeared from patchwork. A filter on the subject, selecting any state and both archived and non-archived patches will return both: V1: http://patchwork.ozlabs.org/patch/282753/ (New) V2: http://patchwork.ozlabs.org/patch/314717/ (Deferred) (I think that the patchwork web interface does not make it possible at all to remove a patch anyway) Thanks for pointing out. Now it is perfectly visible :-) I've also un-deferred, for now, the patch as well. Inclusion of v2 has been postponed since there was a discussion if we shall allow unaligned access (-mno-unaligned-access flag) at armv7 (after patches posted by Tom). As fair as I can tell, we will keep the current approach so, I think that Tom will be willing to pull this patch (v2) now. Agreed, but then we should make sure no one has comments on V2 that they might have withheld due to the initial rejection of V2. Any comments? This patch do fix unaligned access problem on Trats2 (Exynos4412), when we restore/create GPT, so I would like to know if there are any new inquires regarding this patch. Can you give me some steps on how to hit this bug? I believe it's a bug and I believe we need to fix it, I just want to investigate a few things while we've got a trigger case right now. Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] part_efi: fix protective_mbr struct allocation
Hi Albert, Hi Hector, On Wed, 19 Feb 2014 13:52:07 +0100, Palacios, Hector hector.palac...@digi.com wrote: On 02/19/2014 11:16 AM, Albert ARIBAUD wrote: On Wed, 19 Feb 2014 11:08:03 +0100, Albert ARIBAUD Thanks for pointing out. Now it is perfectly visible :-) Inclusion of v2 has been postponed since there was a discussion if we shall allow unaligned access (-mno-unaligned-access flag) at armv7 (after patches posted by Tom). As fair as I can tell, we will keep the current approach so, I think that Tom will be willing to pull this patch (v2) now. Agreed, but then we should make sure no one has comments on V2 that they might have withheld due to the initial rejection of V2. Any comments? This patch do fix unaligned access problem on Trats2 (Exynos4412), when we restore/create GPT, so I would like to know if there are any new inquires regarding this patch. Does not seem to be, so I will apply V2. Correction: I would like it to be applied as per current ARM alignment policy, but this patch is not ARM per se and is in Tom's hands. Tom, can you apply http://patchwork.ozlabs.org/patch/314717/ ? This would by no means close the discussion I opened, and in the event of a policy change, the patch could always be reverted; meanwhile, it matches our current policy. I tested Piotr's patch on i.MX6 (armv7) custom board and it is working fine without the -mno-unaligned-access flag. Tested-by: Hector Palacios hector.palac...@digi.com You've just Tested-By-ed your own patch, I think. Nope. Patch prepared by Piotr is orthogonal to the one prepared by Hector. Hector has spotted other mistake at GPT code (made by me). Fix for it has been posted a few days ago: http://patchwork.ozlabs.org/patch/319914/ ... but I am the one to blame, and should not have discussed Piotr's patch in this thread. Amicalement, -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] part_efi: fix protective_mbr struct allocation
Hi Lukasz, On Wed, 19 Feb 2014 15:25:37 +0100, Lukasz Majewski l.majew...@samsung.com wrote: Hi Albert, Hi Hector, On Wed, 19 Feb 2014 13:52:07 +0100, Palacios, Hector hector.palac...@digi.com wrote: On 02/19/2014 11:16 AM, Albert ARIBAUD wrote: On Wed, 19 Feb 2014 11:08:03 +0100, Albert ARIBAUD Thanks for pointing out. Now it is perfectly visible :-) Inclusion of v2 has been postponed since there was a discussion if we shall allow unaligned access (-mno-unaligned-access flag) at armv7 (after patches posted by Tom). As fair as I can tell, we will keep the current approach so, I think that Tom will be willing to pull this patch (v2) now. Agreed, but then we should make sure no one has comments on V2 that they might have withheld due to the initial rejection of V2. Any comments? This patch do fix unaligned access problem on Trats2 (Exynos4412), when we restore/create GPT, so I would like to know if there are any new inquires regarding this patch. Does not seem to be, so I will apply V2. Correction: I would like it to be applied as per current ARM alignment policy, but this patch is not ARM per se and is in Tom's hands. Tom, can you apply http://patchwork.ozlabs.org/patch/314717/ ? This would by no means close the discussion I opened, and in the event of a policy change, the patch could always be reverted; meanwhile, it matches our current policy. I tested Piotr's patch on i.MX6 (armv7) custom board and it is working fine without the -mno-unaligned-access flag. Tested-by: Hector Palacios hector.palac...@digi.com You've just Tested-By-ed your own patch, I think. Nope. Patch prepared by Piotr is orthogonal to the one prepared by Hector. Hector has spotted other mistake at GPT code (made by me). Fix for it has been posted a few days ago: http://patchwork.ozlabs.org/patch/319914/ I did not comment on the relationship between patches, I only commented on the fact that Hector said he has tested Piotr's patch but sent his Tested-by on his own patch thread, not on Piotr's. To verify this, look up http://patchwork.ozlabs.org/patch/319649/ ... which is Hector's patchwork entry and has his own Tested-by, and http://patchwork.ozlabs.org/patch/314717/ ... which is Piotr's patch and does not have Hector's (or anyone's) Tested-by. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] kbuild,tegra124: add dummy obj- for Kbuild
Hi Masahiro, On Wed, 19 Feb 2014 22:26:43 +0900, Masahiro Yamada yamad...@jp.panasonic.com wrote: In Kbuild, every makefile must have non-empty obj- or obj-y. Otherwise, built-in.o will not be created and the link stage will fail. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- Tom, Please apply this along with the Kbuild series. arch/arm/cpu/armv7/tegra124/Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/cpu/armv7/tegra124/Makefile b/arch/arm/cpu/armv7/tegra124/Makefile index 7f127b1..9478d44 100644 --- a/arch/arm/cpu/armv7/tegra124/Makefile +++ b/arch/arm/cpu/armv7/tegra124/Makefile @@ -4,3 +4,6 @@ # # SPDX-License-Identifier: GPL-2.0+ # + +# necessary to create built-in.o +obj- := __dummy__.o Is there really no other way than to specify an unexisting __dummy__.o in order to build a useless built-in.o? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] disk:efi: avoid unaligned access on efi partition
On 01/28/2014 01:46 PM, Piotr Wilczek wrote:
This patch fixes part_efi code to avoid unaligned access exception
on some ARM platforms.
Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Tom Rini tr...@ti.com
CC: Albert ARIBAUD albert.u.b...@aribaud.net
---
Chnages for V2:
- used put_unaligned to copy value;
- use __aligned to align local array;
disk/part_efi.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/disk/part_efi.c b/disk/part_efi.c
index 9c33ae7..eb2cd57 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -225,7 +225,7 @@ static int set_protective_mbr(block_dev_desc_t *dev_desc)
p_mbr-signature = MSDOS_MBR_SIGNATURE;
p_mbr-partition_record[0].sys_ind = EFI_PMBR_OSTYPE_EFI_GPT;
p_mbr-partition_record[0].start_sect = 1;
- p_mbr-partition_record[0].nr_sects = (u32) dev_desc-lba;
+ put_unaligned(dev_desc-lba, p_mbr-partition_record[0].nr_sects);
/* Write MBR sector to the MMC device */
if (dev_desc-block_write(dev_desc-dev, 0, 1, p_mbr) != 1) {
@@ -361,6 +361,8 @@ int gpt_fill_pte(gpt_header *gpt_h, gpt_entry *gpt_e,
#ifdef CONFIG_PARTITION_UUIDS
char *str_uuid;
#endif
+ static efi_guid_t basic_guid __aligned(0x04) =
+ PARTITION_BASIC_DATA_GUID;
for (i = 0; i parts; i++) {
/* partition starting lba */
@@ -388,8 +390,7 @@ int gpt_fill_pte(gpt_header *gpt_h, gpt_entry *gpt_e,
gpt_e[i].ending_lba = cpu_to_le64(offset - 1);
/* partition type GUID */
- memcpy(gpt_e[i].partition_type_guid.b,
- PARTITION_BASIC_DATA_GUID, 16);
+ gpt_e[i].partition_type_guid = basic_guid;
#ifdef CONFIG_PARTITION_UUIDS
str_uuid = partitions[i].uuid;
Sorry, I sent my tested-by on a different thread:
http://patchwork.ozlabs.org/patch/319649/
Tested on i.MX6 (armv7) custom board and it is working fine without
the -mno-unaligned-access flag.
Tested-by: Hector Palacios hector.palac...@digi.com
Replying to Tom's question in that other thread, regarding the issue:
Can you give me some steps on how to hit this bug? I believe it's a bug
and I believe we need to fix it, I just want to investigate a few things
while we've got a trigger case right now. Thanks!
GPT partition table needs to write a protective MBR to sector 0.
The MBR structure has four partition entries (each occupying 16 bytes) at unaligned
offsets +1BEh, +1CEh, +1DEh, +1EEh (see [1]). The structure of each partition entry is
defined at include/part_efi.h
struct partition {
u8 boot_ind;/* 0x80 - active */
u8 head;/* starting head */
u8 sector; /* starting sector */
u8 cyl; /* starting cylinder */
u8 sys_ind; /* What partition type */
u8 end_head;/* end head */
u8 end_sector; /* end sector */
u8 end_cyl; /* end cylinder */
__le32 start_sect; /* starting sector counting from 0 */
__le32 nr_sects;/* nr of sectors in partition */
} __packed;
showing eight 1-byte fields and two 4-byte fields. Since the offsets for each
partition entry are unaligned, the last two fields (which are 32bit) are unaligned as
well. But it's not an error, it's just the specification of the MBR requires these
fields to be at those exact offsets. So the usage of unaligned macros for accessing
those fields is justified.
[1] http://en.wikipedia.org/wiki/Master_boot_record#Sector_layout
Best regards,
--
Hector Palacios
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] uboot/linux version compatibilty
Hi Wolfgang Denk, If I am not wrong, the kernel 2.6.18 has included fdt (firmware device tree) . In that case, can we expect any compatibility issues with U-Boot v1.1.2. Please let us know , if there is any backward compatibility is maintained . Thanks in advance. Kiran Kumar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] show_boot_progress
Hi Albert, What board is that? The board is DevKit3250 from Embest. Actually, there is limited support of the board in the latest version of u-boot. There is no NAND or ethernet support, for example. abdullah On Wed, Feb 19, 2014 at 4:16 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Abdullah, On Wed, 19 Feb 2014 15:14:42 +0200, Abdullah YILDIZ abdullah.ma...@gmail.com wrote: Hi Albert, On Wed, Feb 19, 2014 at 12:32 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Abdullah, I use u-boot version 1.3.3. Any reason to use a five-years-old release? The development board I use supports u-boot version 1.3.3 and I couldn't manage to port the functions to newer releases of u-boot. What board is that? abdullah Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] bootstage: arm: fix fdt stashing code
The conditional is using a variable that is not defined. Signed-off-by: Rommel G Custodio sessyargc+u-b...@gmail.com --- arch/arm/lib/bootm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c index a8295bf..7f1b2e0 100644 --- a/arch/arm/lib/bootm.c +++ b/arch/arm/lib/bootm.c @@ -71,8 +71,7 @@ static void announce_and_cleanup(int fake) (fake run for tracing) : ); bootstage_mark_name(BOOTSTAGE_ID_BOOTM_HANDOFF, start_kernel); #ifdef CONFIG_BOOTSTAGE_FDT - if (flag == BOOTM_STATE_OS_FAKE_GO) - bootstage_fdt_add_report(); + bootstage_fdt_add_report(); #endif #ifdef CONFIG_BOOTSTAGE_REPORT bootstage_report(); -- 1.9.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] disk:efi: avoid unaligned access on efi partition
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/19/2014 09:56 AM, Hector Palacios wrote:
On 01/28/2014 01:46 PM, Piotr Wilczek wrote:
This patch fixes part_efi code to avoid unaligned access exception
on some ARM platforms.
Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Tom Rini tr...@ti.com
CC: Albert ARIBAUD albert.u.b...@aribaud.net
---
Chnages for V2:
- used put_unaligned to copy value;
- use __aligned to align local array;
disk/part_efi.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/disk/part_efi.c b/disk/part_efi.c
index 9c33ae7..eb2cd57 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -225,7 +225,7 @@ static int set_protective_mbr(block_dev_desc_t
*dev_desc)
p_mbr-signature = MSDOS_MBR_SIGNATURE;
p_mbr-partition_record[0].sys_ind = EFI_PMBR_OSTYPE_EFI_GPT;
p_mbr-partition_record[0].start_sect = 1;
-p_mbr-partition_record[0].nr_sects = (u32) dev_desc-lba;
+put_unaligned(dev_desc-lba, p_mbr-partition_record[0].nr_sects);
/* Write MBR sector to the MMC device */
if (dev_desc-block_write(dev_desc-dev, 0, 1, p_mbr) != 1) {
@@ -361,6 +361,8 @@ int gpt_fill_pte(gpt_header *gpt_h, gpt_entry *gpt_e,
#ifdef CONFIG_PARTITION_UUIDS
char *str_uuid;
#endif
+static efi_guid_t basic_guid __aligned(0x04) =
+PARTITION_BASIC_DATA_GUID;
for (i = 0; i parts; i++) {
/* partition starting lba */
@@ -388,8 +390,7 @@ int gpt_fill_pte(gpt_header *gpt_h, gpt_entry *gpt_e,
gpt_e[i].ending_lba = cpu_to_le64(offset - 1);
/* partition type GUID */
-memcpy(gpt_e[i].partition_type_guid.b,
-PARTITION_BASIC_DATA_GUID, 16);
+gpt_e[i].partition_type_guid = basic_guid;
#ifdef CONFIG_PARTITION_UUIDS
str_uuid = partitions[i].uuid;
Sorry, I sent my tested-by on a different thread:
http://patchwork.ozlabs.org/patch/319649/
Tested on i.MX6 (armv7) custom board and it is working fine without
the -mno-unaligned-access flag.
Tested-by: Hector Palacios hector.palac...@digi.com
Replying to Tom's question in that other thread, regarding the issue:
Can you give me some steps on how to hit this bug? I believe it's a bug
and I believe we need to fix it, I just want to investigate a few things
while we've got a trigger case right now. Thanks!
GPT partition table needs to write a protective MBR to sector 0.
The MBR structure has four partition entries (each occupying 16 bytes)
at unaligned offsets +1BEh, +1CEh, +1DEh, +1EEh (see [1]). The structure
of each partition entry is defined at include/part_efi.h
struct partition {
u8 boot_ind;/* 0x80 - active */
u8 head;/* starting head */
u8 sector;/* starting sector */
u8 cyl;/* starting cylinder */
u8 sys_ind;/* What partition type */
u8 end_head;/* end head */
u8 end_sector;/* end sector */
u8 end_cyl;/* end cylinder */
__le32 start_sect;/* starting sector counting from 0 */
__le32 nr_sects;/* nr of sectors in partition */
} __packed;
showing eight 1-byte fields and two 4-byte fields. Since the offsets for
each partition entry are unaligned, the last two fields (which are
32bit) are unaligned as well. But it's not an error, it's just the
specification of the MBR requires these fields to be at those exact
offsets. So the usage of unaligned macros for accessing those fields is
justified.
Right. I would have sworn I used the GPT commands since we've dropped
- -mno-unaligned-access but I'll just go re-test locally now then, thanks.
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJTBMfWAAoJENk4IS6UOR1Wm/IP/1sOKxdJvLljPxOQ5myKhT0k
PWFMVuN9ZomSkr9+yYt87cVtz28OV42dqVIig7i96TYbzA19AxWY6jWVlPxlmbAZ
0qIwILgogtytJPDad/4NMWXy8GyHP6f9iYIui/DRImsZaErSek+egEshf46M5oyH
0Fd6H/HcpLlJ1QydN1jQzKSppS3HadlwVKEQqC2vN2WjKv3li/m84xoSdiNty2Lj
WgqEBOTfbS5dYQub72WiiaCvs2QVBAP2jRk1Lmtu/gj/L5Av0uc+J8JFV6+Un+Tt
VNUKigG8PdLonex6gCOwpULX6Lft+9x0YWJXIp0ow3JFStpxbHPgMqqKkVyC7Jgp
n14dHO4mG5ZdT2m0y/Tyu1sg7tllTPtW2k+GBsRa8vnOzHq11I6/wQ712S6BK4aB
jjuQsxOoxbGSzMEpMrotf4knc0tuL72Lh46Lz1ksRZNdu7NGOAO+DjGuXnzKn8H4
oEB6aFEewaMV8o2XBNaMddMg8MyPtVC4qZiN2uuMMKjxkTukKUCV9xCl9YkJLAV2
oXdVtEoczjWY6made42olvTeev5R1NDD1ex63q0sZIylJQrQSjMju+1PpQQxAwAh
/Kv5xn+13JtX7eaHY2oogHRLmLB5Cp2EUwg/ZVzArNTnlVdzOsr72v7BLi/fz6T2
NA5qIFUntQunN2OweEE+
=32uL
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] : Please pull u-boot-imx
Hi Stefano, On Wed, 19 Feb 2014 11:04:53 +0100, Stefano Babic sba...@denx.de wrote: Hi Albert, please pull from u-boot-imx, thanks ! The following changes since commit e97f9d817e600cd6f43d1d0da76f5787e33a5c56: Merge branch 'u-boot-ti/master' into 'u-boot-arm/master' (2014-01-29 14:07:50 +0100) are available in the git repository at: git://www.denx.de/git/u-boot-imx.git master for you to fetch changes up to da781c60e5d55904d77931fcb63f25e65e2228be: imx6 SION bit has to be on for the pins that are used as ENET_REF_CLK (2014-02-19 10:57:25 +0100) Andy Ng (1): imx6 SION bit has to be on for the pins that are used as ENET_REF_CLK Anson Huang (2): imx6: ensure AHB clock is 132MHz in low freq boot mode imx6: make sure MMDC_CHx_MASK is clear to avoid warm reset failure Eric Nelson (1): i.MX6: nitrogen6x: pedantic: BOOT_FROM==spi, not sd Fabio Estevam (8): nitrogen6x: README: Only calling 'make' is enough nitrogen6x: README: Do not refer to MAINTAINERS file mx6sl: Adjust fdt_addr to avoid address overlapping hummingboard: Return from cpu_eth_init() directly imx: Introduce a header for the imx cpu versions mx6: Distinguish mx6dual from mx6quad mx6qsabreauto: Update imximage.cfg mx6: Enable L2 cache support Marek Vasut (7): ARM: armv7: Make indirect vector addresses globl ARM: mx6: Add PCI express clock configuration ARM: mx6: Add PCI express driver ARM: mx6: Enable PCIe on Sabrelite ARM: m53evk: Rename mxc-nand to mxc_nand ARM: m53evk: Enable CONFIG_REGEX pci: mx6: Implement reset callback Markus Niebel (2): ARM: imx6: fix wrong fec clk NET: fec_mxc: fix MDIO clock prescaler calculation Otavio Salvador (11): cgtqmx6eval: Set default environment to use zImage hummingboard: Set default environment to use zImage mx23evk: Set default environment to use zImage mx28evk: Set default environment to use zImage mx51evk: Set default environment to use zImage mx53loco: Set default environment to use zImage mx6qarm2: Set default environment to use zImage mx6sabre_common: Set default environment to use zImage mx6slevk: Set default environment to use zImage udoo: Set default environment to use zImage vf610twr: Set default environment to use zImage Stefano Babic (2): Merge branch 'master' of git://git.denx.de/u-boot-arm Merge branch 'master' of git://git.denx.de/u-boot-arm arch/arm/cpu/armv7/mx6/clock.c | 77 +++- arch/arm/cpu/armv7/mx6/soc.c| 103 - arch/arm/cpu/armv7/start.S |7 + arch/arm/imx-common/cpu.c |2 + arch/arm/include/asm/arch-imx/cpu.h | 13 + arch/arm/include/asm/arch-mx5/sys_proto.h |7 +- arch/arm/include/asm/arch-mx6/clock.h |1 + arch/arm/include/asm/arch-mx6/imx-regs.h|1 + arch/arm/include/asm/arch-mx6/iomux.h | 27 ++ arch/arm/include/asm/arch-mx6/mx6dl_pins.h |6 +- arch/arm/include/asm/arch-mx6/mx6q_pins.h |6 +- arch/arm/include/asm/arch-mx6/sys_proto.h |8 +- arch/arm/include/asm/pl310.h| 21 + board/boundary/nitrogen6x/README|4 +- board/boundary/nitrogen6x/nitrogen6dl.cfg |2 +- board/boundary/nitrogen6x/nitrogen6dl2g.cfg |2 +- board/boundary/nitrogen6x/nitrogen6q.cfg|2 +- board/boundary/nitrogen6x/nitrogen6q2g.cfg |2 +- board/boundary/nitrogen6x/nitrogen6s.cfg|2 +- board/boundary/nitrogen6x/nitrogen6s1g.cfg |2 +- board/freescale/mx6qsabreauto/imximage.cfg | 136 +++--- board/solidrun/hummingboard/hummingboard.c |6 +- drivers/net/fec_mxc.c |8 +- drivers/pci/Makefile|1 + drivers/pci/pcie_imx.c | 606 +++ include/configs/cgtqmx6eval.h | 14 +- include/configs/hummingboard.h | 20 +- include/configs/m53evk.h|6 +- include/configs/mx23evk.h | 12 +- include/configs/mx28evk.h | 26 +- include/configs/mx51evk.h | 20 +- include/configs/mx53loco.h | 20 +- include/configs/mx6_common.h|5 + include/configs/mx6qarm2.h | 10 +- include/configs/mx6sabre_common.h | 20 +- include/configs/mx6slevk.h | 22 +- include/configs/nitrogen6x.h| 11 + include/configs/udoo.h | 20 +- include/configs/vf610twr.h | 20 +- 39 files changed, 1049 insertions(+), 229 deletions(-) create mode 100644 arch/arm/include/asm/arch-imx/cpu.h create mode 100644
[U-Boot] [PATCH 0/2] bootstage: fix fdt stashing and reporting
In arm, it seems there is a discrepancy in the code. The fdt stashing code uses an undefined variable. In powerpc, implement fdt stashing and pre-boot reporting of bootstage timing data. Rommel G Custodio (2): bootstage: arm: fix fdt stashing code ootstage: powerpc: support fdt stash and reporting arch/arm/lib/bootm.c | 3 +-- arch/powerpc/lib/bootm.c | 7 +++ 2 files changed, 8 insertions(+), 2 deletions(-) -- 1.9.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] part_efi: fix protective_mbr struct allocation
Hi Tom, On Wed, Feb 19, 2014 at 09:19:04AM +0100, Lukasz Majewski wrote: Hi Albert, Tom Hi Lukasz, On Wed, 12 Feb 2014 21:45:41 +0100, Lukasz Majewski l.majew...@majess.pl wrote: I think, that the patch for fixing the unaligned access in this function has already been posted by Piotr Wilczek. We have experienced similar issues with Samsung's Exynos4 based targets. [PATCH V2] disk:efi: avoid unaligned access on efi partition Despite its disappearance from patchwork it shall be available at mailing list archive. The v1 can be found at the following link: http://patchwork.ozlabs.org/patch/282753/ Neither V1 nor V2 have disappeared from patchwork. A filter on the subject, selecting any state and both archived and non-archived patches will return both: V1: http://patchwork.ozlabs.org/patch/282753/ (New) V2: http://patchwork.ozlabs.org/patch/314717/ (Deferred) (I think that the patchwork web interface does not make it possible at all to remove a patch anyway) Thanks for pointing out. Now it is perfectly visible :-) I've also un-deferred, for now, the patch as well. Inclusion of v2 has been postponed since there was a discussion if we shall allow unaligned access (-mno-unaligned-access flag) at armv7 (after patches posted by Tom). As fair as I can tell, we will keep the current approach so, I think that Tom will be willing to pull this patch (v2) now. Agreed, but then we should make sure no one has comments on V2 that they might have withheld due to the initial rejection of V2. Any comments? This patch do fix unaligned access problem on Trats2 (Exynos4412), when we restore/create GPT, so I would like to know if there are any new inquires regarding this patch. Can you give me some steps on how to hit this bug? I believe it's a bug and I believe we need to fix it, I just want to investigate a few things while we've got a trigger case right now. Thanks! The easiest way is to type: gpt write mmc 0 $partitions before that you shall define several uuid's. For reference please look into the Trats2/Trats code and ./doc/README.gpt As a side note - I'm using following toolchain: CROSS_COMPILE=/opt/eldk-5.4/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/arm-linux-gnueabi- It is 4.7.2 from denx.de. -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] part_efi: fix protective_mbr struct allocation
Hi Albert, Hi Lukasz, On Wed, 19 Feb 2014 15:25:37 +0100, Lukasz Majewski l.majew...@samsung.com wrote: Hi Albert, Hi Hector, On Wed, 19 Feb 2014 13:52:07 +0100, Palacios, Hector hector.palac...@digi.com wrote: On 02/19/2014 11:16 AM, Albert ARIBAUD wrote: On Wed, 19 Feb 2014 11:08:03 +0100, Albert ARIBAUD Thanks for pointing out. Now it is perfectly visible :-) Inclusion of v2 has been postponed since there was a discussion if we shall allow unaligned access (-mno-unaligned-access flag) at armv7 (after patches posted by Tom). As fair as I can tell, we will keep the current approach so, I think that Tom will be willing to pull this patch (v2) now. Agreed, but then we should make sure no one has comments on V2 that they might have withheld due to the initial rejection of V2. Any comments? This patch do fix unaligned access problem on Trats2 (Exynos4412), when we restore/create GPT, so I would like to know if there are any new inquires regarding this patch. Does not seem to be, so I will apply V2. Correction: I would like it to be applied as per current ARM alignment policy, but this patch is not ARM per se and is in Tom's hands. Tom, can you apply http://patchwork.ozlabs.org/patch/314717/ ? This would by no means close the discussion I opened, and in the event of a policy change, the patch could always be reverted; meanwhile, it matches our current policy. I tested Piotr's patch on i.MX6 (armv7) custom board and it is working fine without the -mno-unaligned-access flag. Tested-by: Hector Palacios hector.palac...@digi.com You've just Tested-By-ed your own patch, I think. Nope. Patch prepared by Piotr is orthogonal to the one prepared by Hector. Hector has spotted other mistake at GPT code (made by me). Fix for it has been posted a few days ago: http://patchwork.ozlabs.org/patch/319914/ I did not comment on the relationship between patches, I only commented on the fact that Hector said he has tested Piotr's patch but sent his Tested-by on his own patch thread, not on Piotr's. To verify this, look up http://patchwork.ozlabs.org/patch/319649/ ... which is Hector's patchwork entry and has his own Tested-by, and http://patchwork.ozlabs.org/patch/314717/ ... which is Piotr's patch and does not have Hector's (or anyone's) Tested-by. Hmm. I've misunderstood you a bit. Anyway thanks for clarification :-). Amicalement, -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 2/2] bootstage: powerpc: support fdt stash and reporting
This implements stashing of bootstage timing data to FDT and automatic timing reporting. To enable define CONFIG_BOOTSTAGE_FDT and CONFIG_BOOTSTAGE_REPORT respectively. Signed-off-by: Rommel G Custodio sessyargc+u-b...@gmail.com --- arch/powerpc/lib/bootm.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/powerpc/lib/bootm.c b/arch/powerpc/lib/bootm.c index 41fc8f7..1e36bec 100644 --- a/arch/powerpc/lib/bootm.c +++ b/arch/powerpc/lib/bootm.c @@ -54,6 +54,13 @@ static void boot_jump_linux(bootm_headers_t *images) bootstage_mark(BOOTSTAGE_ID_RUN_OS); +#ifdef CONFIG_BOOTSTAGE_FDT + bootstage_fdt_add_report(); +#endif +#ifdef CONFIG_BOOTSTAGE_REPORT + bootstage_report(); +#endif + #if defined(CONFIG_SYS_INIT_RAM_LOCK) !defined(CONFIG_E500) unlock_ram_in_cache(); #endif -- 1.9.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 0/2] bootstage: fix fdt stashing and reporting
In arm, it seems there is a discrepancy in the code. The fdt stashing code uses an undefined variable. In powerpc, implement fdt stashing and pre-boot reporting of bootstage timing data. Fixed a typo in the commit log. Rommel G Custodio (2): bootstage: arm: fix fdt stashing code bootstage: powerpc: support fdt stash and reporting arch/arm/lib/bootm.c | 3 +-- arch/powerpc/lib/bootm.c | 7 +++ 2 files changed, 8 insertions(+), 2 deletions(-) -- 1.9.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 1/2] bootstage: arm: fix fdt stashing code
The conditional is using a variable that is not defined. Signed-off-by: Rommel G Custodio sessyargc+u-b...@gmail.com --- arch/arm/lib/bootm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c index a8295bf..7f1b2e0 100644 --- a/arch/arm/lib/bootm.c +++ b/arch/arm/lib/bootm.c @@ -71,8 +71,7 @@ static void announce_and_cleanup(int fake) (fake run for tracing) : ); bootstage_mark_name(BOOTSTAGE_ID_BOOTM_HANDOFF, start_kernel); #ifdef CONFIG_BOOTSTAGE_FDT - if (flag == BOOTM_STATE_OS_FAKE_GO) - bootstage_fdt_add_report(); + bootstage_fdt_add_report(); #endif #ifdef CONFIG_BOOTSTAGE_REPORT bootstage_report(); -- 1.9.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] disk:efi: avoid unaligned access on efi partition
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/19/2014 10:03 AM, Tom Rini wrote:
On 02/19/2014 09:56 AM, Hector Palacios wrote:
On 01/28/2014 01:46 PM, Piotr Wilczek wrote:
This patch fixes part_efi code to avoid unaligned access exception
on some ARM platforms.
Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Tom Rini tr...@ti.com
CC: Albert ARIBAUD albert.u.b...@aribaud.net
---
Chnages for V2:
- used put_unaligned to copy value;
- use __aligned to align local array;
disk/part_efi.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/disk/part_efi.c b/disk/part_efi.c
index 9c33ae7..eb2cd57 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -225,7 +225,7 @@ static int set_protective_mbr(block_dev_desc_t
*dev_desc)
p_mbr-signature = MSDOS_MBR_SIGNATURE;
p_mbr-partition_record[0].sys_ind = EFI_PMBR_OSTYPE_EFI_GPT;
p_mbr-partition_record[0].start_sect = 1;
-p_mbr-partition_record[0].nr_sects = (u32) dev_desc-lba;
+put_unaligned(dev_desc-lba, p_mbr-partition_record[0].nr_sects);
/* Write MBR sector to the MMC device */
if (dev_desc-block_write(dev_desc-dev, 0, 1, p_mbr) != 1) {
@@ -361,6 +361,8 @@ int gpt_fill_pte(gpt_header *gpt_h, gpt_entry *gpt_e,
#ifdef CONFIG_PARTITION_UUIDS
char *str_uuid;
#endif
+static efi_guid_t basic_guid __aligned(0x04) =
+PARTITION_BASIC_DATA_GUID;
for (i = 0; i parts; i++) {
/* partition starting lba */
@@ -388,8 +390,7 @@ int gpt_fill_pte(gpt_header *gpt_h, gpt_entry *gpt_e,
gpt_e[i].ending_lba = cpu_to_le64(offset - 1);
/* partition type GUID */
-memcpy(gpt_e[i].partition_type_guid.b,
-PARTITION_BASIC_DATA_GUID, 16);
+gpt_e[i].partition_type_guid = basic_guid;
#ifdef CONFIG_PARTITION_UUIDS
str_uuid = partitions[i].uuid;
Sorry, I sent my tested-by on a different thread:
http://patchwork.ozlabs.org/patch/319649/
Tested on i.MX6 (armv7) custom board and it is working fine without
the -mno-unaligned-access flag.
Tested-by: Hector Palacios hector.palac...@digi.com
Replying to Tom's question in that other thread, regarding the issue:
Can you give me some steps on how to hit this bug? I believe it's a bug
and I believe we need to fix it, I just want to investigate a few things
while we've got a trigger case right now. Thanks!
GPT partition table needs to write a protective MBR to sector 0.
The MBR structure has four partition entries (each occupying 16 bytes)
at unaligned offsets +1BEh, +1CEh, +1DEh, +1EEh (see [1]). The structure
of each partition entry is defined at include/part_efi.h
struct partition {
u8 boot_ind;/* 0x80 - active */
u8 head;/* starting head */
u8 sector;/* starting sector */
u8 cyl;/* starting cylinder */
u8 sys_ind;/* What partition type */
u8 end_head;/* end head */
u8 end_sector;/* end sector */
u8 end_cyl;/* end cylinder */
__le32 start_sect;/* starting sector counting from 0 */
__le32 nr_sects;/* nr of sectors in partition */
} __packed;
showing eight 1-byte fields and two 4-byte fields. Since the offsets for
each partition entry are unaligned, the last two fields (which are
32bit) are unaligned as well. But it's not an error, it's just the
specification of the MBR requires these fields to be at those exact
offsets. So the usage of unaligned macros for accessing those fields is
justified.
Right. I would have sworn I used the GPT commands since we've dropped
-mno-unaligned-access but I'll just go re-test locally now then, thanks.
Indeed I hadn't re-tested recently enough, thanks.
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJTBMxeAAoJENk4IS6UOR1WmKAP/05tEc0Ix4vrbI+WEYv4s26v
Up3Uj1yMHBgHhCmdUops6C6eNjoSX2Z2TzfFx8jQ1YCTrGXO229CSi0U/oXkTWCB
lbdMxQ6IyKh1v+Z4MdEJBq43XxcGMVE8g75Z8Eb/7B74kHRvsLeLGIDMg4A3z1yB
b95HOCaifhSykBELsrqWXpMhJr4KMkn+GT9lNA5umLJdHT/1A2pEglbkZWAu4tAt
ybDpdpXI3Ai8eVg9NuMJXEAcYEGezlg55esFv57gJfLfBPM/e0WLF4MtZYyFJmC/
0SLe46OG19E6JzHMKrHngZbyVSC+Iwzh5Mw6vY40IyVxA6fpXZEZ119AyxLtP4m8
BiWjjRAO65KC6qzRJJYzXKoXSD8Ky+VJ3ATWzUhVSeLQRHeE2am8JsT8ENj5dngC
f93pzqTmOp9LPqOB81dlIbu+R8QoruX0mOQxygNy+7tpTTijLn+UUu23z165j42b
qsBzrAddgFZzUxqfyJLHIr/bvrVqBpEP6BGv2i+5eA6Q/dPHMvVLV3hTZjnxtK52
I6RVfK2R4uTX8mK+yN2HzBdqZhCJqDgxbWYUMuDIkVq7QeY5rtPBaFlOguLPqwx2
+i38rtGj5abZcqr9ASDcmrfIoe1mIAj2NPuJejNLzbwyipyqRVO0CT+GG/FwXLLG
LFWWTaNc/X4FMjGctcyr
=1et2
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] ootstage: powerpc: support fdt stash and reporting
This implements stashing of bootstage timing data to FDT and automatic timing reporting. To enable define CONFIG_BOOTSTAGE_FDT and CONFIG_BOOTSTAGE_REPORT respectively. Signed-off-by: Rommel G Custodio sessyargc+u-b...@gmail.com --- arch/powerpc/lib/bootm.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/powerpc/lib/bootm.c b/arch/powerpc/lib/bootm.c index 41fc8f7..1e36bec 100644 --- a/arch/powerpc/lib/bootm.c +++ b/arch/powerpc/lib/bootm.c @@ -54,6 +54,13 @@ static void boot_jump_linux(bootm_headers_t *images) bootstage_mark(BOOTSTAGE_ID_RUN_OS); +#ifdef CONFIG_BOOTSTAGE_FDT + bootstage_fdt_add_report(); +#endif +#ifdef CONFIG_BOOTSTAGE_REPORT + bootstage_report(); +#endif + #if defined(CONFIG_SYS_INIT_RAM_LOCK) !defined(CONFIG_E500) unlock_ram_in_cache(); #endif -- 1.9.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] show_boot_progress
Hi Abdullah, On Wed, 19 Feb 2014 16:57:37 +0200, Abdullah YILDIZ abdullah.ma...@gmail.com wrote: Hi Albert, What board is that? The board is DevKit3250 from Embest. Actually, there is limited support of the board in the latest version of u-boot. There is no NAND or ethernet support, for example. If support for booting to the console is already there, then the most critical parts of (sup)porting the board are there, and I would suggest exploring and adding the missing NAND and Ethernet support. abdullah Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] config: remove platform CONFIG_SYS_HZ definition part 3
On Tue, Jan 28, 2014 at 06:08:13PM +0900, Masahiro Yamada wrote: This commit removes platform CONFIG_SYS_HZ definition for the remainders of part1 (commit cdb23792) and part2 (commit f232950f). Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Rob Herring rob.herr...@calxeda.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] microblaze: remove an empty file arch/microblaze/lib/time.c
On Wed, Feb 19, 2014 at 10:10:04PM +0900, Masahiro Yamada wrote: Commit 779bf42c moved timer functions from arch/microblaze/lib/time.c to arch/microblaze/cpu/timer.c. But the empty file, arch/microblaze/lib/time.c has been remaining probably for a human mistake. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Michal Simek michal.si...@xilinx.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] doc: README: Correct file name of signature verification documentation
On Mon, Jan 20, 2014 at 04:21:46PM +0100, Detlev Zundel wrote: Signed-off-by: Detlev Zundel d...@denx.de Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mini2440.h: Delete remainder of dead board
On Tue, Jan 28, 2014 at 06:06:12PM +0900, Masahiro Yamada wrote: Commit af5b9b1f removed mini2440 board support, but missed to delete include/configs/mini2440.h. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] EXT4: Fix number base handling of ext4write command
On Fri, Jan 31, 2014 at 09:28:25AM +0100, Wolfgang Denk wrote:
Unlike other commands (for example, fatwrite), ext4write would
interpret the sizebytes as decimal number. This is not only
inconsistend and unexpected to most users, it also breaks usage
like this:
tftp ${addr} ${name}
ext4write mmc 0:2 ${addr} ${filename} ${filesize}
Change this to use the standard notation of base 16 input format.
See also commit b770e88
WARNING: this is a change to the user interface!!
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Uma Shankar uma.shan...@samsung.com
Cc: Stephen Warren swar...@nvidia.com
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] net, phy: atheros ar803x bug
On Thu, Jan 30, 2014 at 11:02:13AM +0100, Heiko Schocher wrote: commit 626ee1e3 phylib: update atheros ar803x phy leads in failing ethernet on the pxm2 board. Calling genphy_config() instead of ar8021_config(), which seems for ar8021 phys not ar803x phys, make it working again. Signed-off-by: Heiko Schocher h...@denx.de Cc: Shengzhou Liu shengzhou@freescale.com Cc: Joe Hershberger joe.hershber...@gmail.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2] tools: correct proftool build rule
On Fri, Jan 31, 2014 at 11:54:44PM +, Ian Campbell wrote: The incorrect substitution made it rebuild every time. Signed-off-by: Ian Campbell i...@hellion.org.uk Cc: Tom Rini tr...@ti.com Cc: Simon Glass s...@chromium.org Acked-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fdt: rename IMAAGE_OF_BOARD_SETUP to IMAGE_OF_BOARD_SETUP
On Wed, Jan 29, 2014 at 04:29:16PM +0900, Masahiro Yamada wrote: Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Simon Glass s...@chromium.org Acked-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,2/2] ARM: O5/dra7xx: Add SATA boot support
On Mon, Feb 03, 2014 at 06:59:02AM -0600, Dan Murphy wrote: Add the SATA boot support for OMAP5 and dra7xx. Renamed the omap_sata_init to the common init_sata(int dev) for commonality in with sata stack. Added the ROM boot device ID for SATA. Signed-off-by: Dan Murphy dmur...@ti.com Reviewed-by: Roger Quadros rog...@ti.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 1/2] common: spl: Add spl sata boot support
On Mon, Feb 03, 2014 at 06:59:01AM -0600, Dan Murphy wrote: Add spl_sata to read a fat partition from a bootable SATA drive. Signed-off-by: Dan Murphy dmur...@ti.com Reviewed-by: Roger Quadros rog...@ti.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3: igep00x0: Enable required clocks for GPIO that are used.
Hi Tom, 2014-01-25 22:52 GMT+01:00 Enric Balletbo i Serra eballe...@gmail.com: Enable required clocks for GPIO to fix a boot issue introduced by commit f33b9bd3984fb11e1d8566a866adc5957b1e1c9d (arm: omap3: Enable clocks for peripherals only if they are used). Without this patch the u-boot freezes after the following messages OMAP36XX/37XX-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 Ghz IGEPv2 + LPDDR/NAND I2C: ready DRAM: 512 MiB NAND: 512 MiB MMC: OMAP SD/MMC: 0 Diving into the issue, the sequence that produces the u-boot freezes is setup_net_chip |-- gpio_direction_out |-- _set_gpio_dataout |-- __raw_writel To avoid this we just need enable the clocks for GPIOs that are used, but it would be interesting implement a mechanism to protect these situations and make sure that the clock is enabled when we request a GPIO. Signed-off-by: Enric Balletbo i Serra eballe...@gmail.com --- include/configs/omap3_igep00x0.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/configs/omap3_igep00x0.h b/include/configs/omap3_igep00x0.h index 20fbbec..8cc23c1 100644 --- a/include/configs/omap3_igep00x0.h +++ b/include/configs/omap3_igep00x0.h @@ -37,6 +37,11 @@ #define CONFIG_SHOW_BOOT_PROGRESS #endif +/* GPIO banks */ +#define CONFIG_OMAP3_GPIO_3/* GPIO64 .. 95 is in GPIO bank 3 */ +#define CONFIG_OMAP3_GPIO_5/* GPIO128..159 is in GPIO bank 5 */ +#define CONFIG_OMAP3_GPIO_6/* GPIO160..191 is in GPIO bank 6 */ + /* USB */ #define CONFIG_MUSB_UDC1 #define CONFIG_USB_OMAP3 1 -- 1.8.3.2 Any plan or inconvenient to include this ? It's important as current support for IGEP boards is broken ... Thanks, Enric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
On Monday, February 17, 2014 at 06:56:36 PM, Dennis Gilmore wrote: Signed-off-by: Dennis Gilmore den...@ausil.us --- include/config_distro_bootcmd.h | 172 1 file changed, 172 insertions(+) create mode 100644 include/config_distro_bootcmd.h diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h new file mode 100644 index 000..d32dc12 --- /dev/null +++ b/include/config_distro_bootcmd.h @@ -0,0 +1,172 @@ +/* + * (C) Copyright 2014 + * NVIDIA Corporation www.nvidia.com + * + * Copyright 2014 Red Hat, Inc. + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H +#define _CONFIG_CMD_DISTRO_BOOTCMD_H + + +#ifdef CONFIG_CMD_MMC +#define BOOTCMDS_MMC \ You might want to #undef all this temporary stuff so it's not propagated into the U-Boot further. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net: phy: micrel: add support for KSZ8895 switch in SMI mode
This patch adds a phy driver for the Micrel KSZ8895 switch. As the SoC MAC
is directly connected to the switch MAC the link to the switch is always up.
But the KSZ8895 switch can be hardwired in three configuration modes :
- not configurable with eventually an eeprom-stored configuration
- configurable by the mdio/mdc connection (SMI protocol)
- configurable by a SPI connection.
In not configurable mode, the switch starts automatically, but in the
other modes, it must be started programmatically, by writing 1 in
configuration register 1.
We only support the not configurable and mdio/mdc (aka SMI) modes here.
Signed-off-by: Philippe De Muyter p...@macqel.be
Cc: Christian Gmeiner christian.gmei...@gmail.com
---
drivers/net/phy/micrel.c | 58 ++
1 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 5d7e3be..8fbd7d5 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -22,6 +22,63 @@ static struct phy_driver KSZ804_driver = {
.shutdown = genphy_shutdown,
};
+/**
+ * KSZ8895
+ */
+
+static unsigned short smireg_to_phy(unsigned short reg)
+{
+ return ((reg 0xc0) 3) + 0x06 + ((reg 0x20) 5);
+}
+
+static unsigned short smireg_to_reg(unsigned short reg)
+{
+ return reg 0x1F;
+}
+
+static void ksz8895_write_smireg(struct phy_device *phydev, int smireg, int
val)
+{
+ phydev-bus-write(phydev-bus, smireg_to_phy(smireg), MDIO_DEVAD_NONE,
+ smireg_to_reg(smireg), val);
+}
+
+#if 0
+static int ksz8895_read_smireg(struct phy_device *phydev, int smireg)
+{
+ return phydev-bus-read(phydev-bus, smireg_to_phy(smireg),
+ MDIO_DEVAD_NONE, smireg_to_reg(smireg));
+}
+#endif
+
+int ksz8895_config(struct phy_device *phydev)
+{
+ /* we are connected directly to the switch without
+* dedicated PHY. SCONF1 == 001 */
+ phydev-link = 1;
+ phydev-duplex = DUPLEX_FULL;
+ phydev-speed = SPEED_100;
+
+ /* Force the switch to start */
+ ksz8895_write_smireg(phydev, 1, 1);
+
+ return 0;
+}
+
+static int ksz8895_startup(struct phy_device *phydev)
+{
+ return 0;
+}
+
+static struct phy_driver ksz8895_driver = {
+ .name = Micrel KSZ8895/KSZ8864,
+ .uid = 0x221450,
+ .mask = 0xe1,
+ .features = PHY_BASIC_FEATURES,
+ .config = ksz8895_config,
+ .startup = ksz8895_startup,
+ .shutdown = genphy_shutdown,
+};
+
#ifndef CONFIG_PHY_MICREL_KSZ9021
/*
* I can't believe Micrel used the exact same part number
@@ -222,5 +279,6 @@ int phy_micrel_init(void)
phy_register(KS8721_driver);
#endif
phy_register(ksz9031_driver);
+ phy_register(ksz8895_driver);
return 0;
}
--
1.7.5.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] kbuild,tegra124: add dummy obj- for Kbuild
On 02/19/2014 07:46 AM, Albert ARIBAUD wrote: Hi Masahiro, On Wed, 19 Feb 2014 22:26:43 +0900, Masahiro Yamada yamad...@jp.panasonic.com wrote: In Kbuild, every makefile must have non-empty obj- or obj-y. Otherwise, built-in.o will not be created and the link stage will fail. ... diff --git a/arch/arm/cpu/armv7/tegra124/Makefile b/arch/arm/cpu/armv7/tegra124/Makefile ... +# necessary to create built-in.o +obj- := __dummy__.o obj- or obj-y? Adding something to obj-, which presumably isn't used at all, seems very odd. Is there really no other way than to specify an unexisting __dummy__.o in order to build a useless built-in.o? I haven't looked at Kbuild at all, but in the build systems I've written, for each sub-directory makefile that was included, the makefiles would include a pre-makefile first and a post-makefile after. The post-makefile could easily do something like: ifeq ($(obj-y),) obg-y := __dummy__.o endif ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] pxe: prepend fdtdir to DTB name irrespective of source
On 02/14/2014 11:49 AM, Dennis Gilmore wrote:
On Wed, 12 Feb 2014 14:30:04 -0700
Stephen Warren swar...@wwwdotorg.org wrote:
From: Stephen Warren swar...@nvidia.com
The directory name from an fdtdir directive in a PXE config file
should always be pre-pended to the DTB filename; it shouldn't matter
whether the DTB filename came from the $fdtfile environment variable,
or whether it was constructed dynamically from ${soc}-${board}.dtb.
Fix the code to always prepend the directory name.
Reviewed-by: Dennis Gilmore den...@ausil.us
Tested-by: Dennis Gilmore den...@ausil.us
Thanks for the fix
Tom, does this patch look good?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] pxe: prepend fdtdir to DTB name irrespective of source
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/19/2014 12:00 PM, Stephen Warren wrote:
On 02/14/2014 11:49 AM, Dennis Gilmore wrote:
On Wed, 12 Feb 2014 14:30:04 -0700
Stephen Warren swar...@wwwdotorg.org wrote:
From: Stephen Warren swar...@nvidia.com
The directory name from an fdtdir directive in a PXE config file
should always be pre-pended to the DTB filename; it shouldn't matter
whether the DTB filename came from the $fdtfile environment variable,
or whether it was constructed dynamically from ${soc}-${board}.dtb.
Fix the code to always prepend the directory name.
Reviewed-by: Dennis Gilmore den...@ausil.us
Tested-by: Dennis Gilmore den...@ausil.us
Thanks for the fix
Tom, does this patch look good?
Yes. Sorry, I'm doing the following today:
- - Clean out patches in my TODO list older than v9 of the kbuild series
(done).
- - Do v9 of kbuild series (in progress)
- - Do stuff after v9 of kbuild series (hopefully later today).
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJTBOOuAAoJENk4IS6UOR1WhggP/1QSELUbzznfDUNcapSG9lhO
8tZTUGgmTaKTr2v6ruRHyKbf4RnzP+RfJrecXLXqdR2ymEzhS1Xs0TSrCBApAYub
R2YFnvJWwH53IsZcwgH4B6zdGbO+OaaNcwL9waJ9aoXaSKYeiktrZQCEf8KYUx5r
UaPAD/fPW7BygAjwys03YlVxW4GEsxfRGWXU7I/6uT+ytBXgbNkbHmkXcYSp0LpG
YLbhc6pUZtkXTw8tXoKc6oxW+LNpVxdLZhtbPdse/h2T3SSGuuqnky1/agrlYXtg
tJ3rOBmIP5n1Z2dvTLMTS58kB+lZssxcGcsDcMLT2BLZiPhhseISte4NMgBedk/E
GMhOpvIktDa1VWShjOo5EI/8NFRO7mlhGqfFWV3HoO25olBdPGtHj9UZQJkOeKni
pT/2OoGTjM+Wq/F2ybrUDOpRKBVwC+OjgTZ8trgmXiJMEaBspa+aE7w5k5FAoK3E
IF6zE9HN6nEu68DP2XAV1ySKn8WAiet/6P6ePf9AI4C+H5XEUVmdscOsCymiu5or
saORS7GrHd3CAJzSZtGDVjnCcAfg4W9Cwb5IVfWyfN4H0f0sx7RkbV6CfwK3AdPQ
f/YhOtt4LDR9yY063bag7SX6rFStdWm3UUcmOhCtms2rZI2ueU0VPB4lR/k7wtyY
SaBqo0iDDaUeeTeIWlan
=bbfE
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
On 02/19/2014 08:54 AM, Marek Vasut wrote: On Monday, February 17, 2014 at 06:56:36 PM, Dennis Gilmore wrote: Signed-off-by: Dennis Gilmore den...@ausil.us --- include/config_distro_bootcmd.h | 172 1 file changed, 172 insertions(+) create mode 100644 include/config_distro_bootcmd.h diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h new file mode 100644 index 000..d32dc12 --- /dev/null +++ b/include/config_distro_bootcmd.h @@ -0,0 +1,172 @@ +/* + * (C) Copyright 2014 + * NVIDIA Corporation www.nvidia.com + * + * Copyright 2014 Red Hat, Inc. + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H +#define _CONFIG_CMD_DISTRO_BOOTCMD_H + + +#ifdef CONFIG_CMD_MMC +#define BOOTCMDS_MMC \ You might want to #undef all this temporary stuff so it's not propagated into the U-Boot further. I don't understand. What temporary stuff are you referring to? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8 0/38] Switch over to real Kbuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/18/2014 04:02 AM, Masahiro Yamada wrote: Hello Simon, I'm not sure whether to start a new thread or not, but here in one observations which might be useful. With current master, a 'null' build (with nothing changed) takes about 5s for me. time CROSS_COMPILE=/opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.8-2013.08_linux/bin/arm - -linux-gnueabihf- ARCH=arm make -j1 real 0m4.978s user 0m1.144s sys 0m0.360s With the kbuild series, it takes a lot longer: real 0m46.600s user 0m17.628s sys 0m8.664s Thanks for your feedback. Hmm, Kbuild is 9 times slower on your computer. This is a big difference. (It was about 1.6 x slower on my box.) I don't know where such a difference came from. There seem to be noticeable pauses between things happening. I'm not quite sure how to dig into it more. Is it possible that cc-option is no-longer caching the various compiler options? I guess it's possible. Is sandbox build slow as well? Sandbox has no cc-option. If cc-option is the cause of pauses, sandbox build should be faster. Anyway, evaluating cc-option multiple times isn't nice and its optimization is on my TODO list. Can we move this up on the TODO list please? Some quick testing around here says that this is the big culprit on build times. I get pre-Kbuild series build time to match post-Kbuild series by building with CONFIG_CC_OPT_CACHE_DISABLE=y. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTBOnSAAoJENk4IS6UOR1WlKsP/ArbW+W4MkrKoAM6WCyWrPRh 6uDCK9Hhf3HanF49ejwGFUhvI2dHNAKuuvQ2PF523OVfxzZRUPH+D8FJQ5eA7ezO N+yIcTDpvGI4y6aR4X/H5QCwvqeL0GsUhqP+xDQ4exAkaI/Ij92i/BYuZSwyoU8w yfJU13RRjwstXcVheERJzQRdsC7lY2O+c1Z0+o+S9L0aJ25iuo57huUPD+6V0zsg VEgzfFUGjPWtjtfkU9jzCIMqedhQbz4Hoewav1Bn8SNq6aG6mZtysUJitWanjJrl fCb9a1vPbkhgJLACewkpbtUDLTys+sofSl5mbULT03bGNKDK+QG443nvSvPkfh/I 6QDdk7bH/o38ZP1kvLuzatFUXK7Z66LPwOIMVlgheIbZnyVkryOfpA8stwWRhpGk rueQjJBuhbrcfdwRswfAX8iDRYMcuXsMyk4/Kpg2KcwEC+H540pEeZZKJYL3Enf6 Mpe7koYtnhN0AFdgIK97qQ7QYSJ9DmrsDVYAro1oL4jTqDQS8y02zdW2rhlIpIFW vqlQ861AiXdmzUPkJS5t9qAEU9JqfK7SKS53yNBPD0tocEeJOWp9veEjvoUgm3rH LmwCGmdNzQLlyVj0w+gTeFb90L4fb/MAfwGcb7cQak6Rc7FbgX/3MkMB6cDOpYKu AIQTrHf3stEVnjPSAHAm =gu7X -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
On Wednesday, February 19, 2014 at 06:28:39 PM, Stephen Warren wrote: On 02/19/2014 08:54 AM, Marek Vasut wrote: On Monday, February 17, 2014 at 06:56:36 PM, Dennis Gilmore wrote: Signed-off-by: Dennis Gilmore den...@ausil.us --- include/config_distro_bootcmd.h | 172 1 file changed, 172 insertions(+) create mode 100644 include/config_distro_bootcmd.h diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h new file mode 100644 index 000..d32dc12 --- /dev/null +++ b/include/config_distro_bootcmd.h @@ -0,0 +1,172 @@ +/* + * (C) Copyright 2014 + * NVIDIA Corporation www.nvidia.com + * + * Copyright 2014 Red Hat, Inc. + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H +#define _CONFIG_CMD_DISTRO_BOOTCMD_H + + +#ifdef CONFIG_CMD_MMC +#define BOOTCMDS_MMC \ You might want to #undef all this temporary stuff so it's not propagated into the U-Boot further. I don't understand. What temporary stuff are you referring to? BOOTCMDS_MMC for example. This certainly doesn't need to propagate into the rest of the U-Boot build, does it ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
On 02/19/2014 10:30 AM, Marek Vasut wrote: On Wednesday, February 19, 2014 at 06:28:39 PM, Stephen Warren wrote: On 02/19/2014 08:54 AM, Marek Vasut wrote: On Monday, February 17, 2014 at 06:56:36 PM, Dennis Gilmore wrote: Signed-off-by: Dennis Gilmore den...@ausil.us --- include/config_distro_bootcmd.h | 172 1 file changed, 172 insertions(+) create mode 100644 include/config_distro_bootcmd.h diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h new file mode 100644 index 000..d32dc12 --- /dev/null +++ b/include/config_distro_bootcmd.h @@ -0,0 +1,172 @@ +/* + * (C) Copyright 2014 + * NVIDIA Corporation www.nvidia.com + * + * Copyright 2014 Red Hat, Inc. + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H +#define _CONFIG_CMD_DISTRO_BOOTCMD_H + + +#ifdef CONFIG_CMD_MMC +#define BOOTCMDS_MMC \ You might want to #undef all this temporary stuff so it's not propagated into the U-Boot further. I don't understand. What temporary stuff are you referring to? BOOTCMDS_MMC for example. This certainly doesn't need to propagate into the rest of the U-Boot build, does it ? Oh, you mean #undef it at the end of the file? That would probably work. I thought you meant something else, although I wasn't sure what. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
On 02/17/2014 10:56 AM, Dennis Gilmore wrote:
Signed-off-by: Dennis Gilmore den...@ausil.us
Patch description?
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
+#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H
+#define _CONFIG_CMD_DISTRO_BOOTCMD_H
+
+
Is there a need for 2 blank lines there?
+#define BOOTCMDS_COMMON \
+ rootpart=1\0 \
We should really stop hard-coding that. I meant to (but evidently never
got around to) re-write the commands so that they could automatically
determine which partition to use, based on the MBR bootable flag or GPT
partition flags.
Still, we can probably make that enhancement separately later.
+#define BOOT_TARGETS_MMC mmc1 mmc0
We really ought to make the order of multiple MMC devices in
BOOT_TARGETS configurable. For example, we may have 2 boards that both
want to boot from SD card if present, else fall back to internal eMMC,
yet one has mmc0=eMMC,mmc1=SD, and the other mmc0=SD,mmc1=eMMC. On
Tegra, we're just lucky that hasn't been an issue yet. Equally, not all
boards have 2 eMMC devices.
+ scan_boot= \
+ echo Scanning ${devtype} ${devnum}...; \
+ for prefix in ${boot_prefixes}; do \
+ run sysboot_boot; \
+ run envimport; \
+ run script_boot;\
This isn't quite right for the Raspberry Pi at least.
What I wanted was for uEnv.txt to *always* be loaded from SD card before
any other boot activity. The SD card is known to exist on this platform,
since it's the only place the SoC's boot ROM can load the initial binary
firmware from.
The idea is that since the Pi has nowhere to store any environment, and
the default environment's boot_targets is hard-coded in the U-Boot
binary, we need some way for the user to configure the value of
boot_targets to e.g. force network or USB boot. We want to do this
before executing bootcmd, so that bootcmd looks at the user's desired
boot_targets, rather than part way through executing bootcmd, which is
far too late.
Now, on the Pi, this all happens via CONFIG_PREBOOT, so it will still
work even with the run envimport as above. However, I think we want to
make the run envimport within scan_boot optional, so it doesn't get
repeated.
I wouldn't be surprised if other platforms ought to be working in the
exact same way?
+ boot_targets= \
+ BOOT_TARGETS_MMC\
+ BOOT_TARGETS_USB\
+ BOOT_TARGETS_SATA \
+ BOOT_TARGETS_PXE\
+ BOOT_TARGETS_DHCP \
+ \0 \
I'd be tempted to require the board-specific config to set boot_targets,
so that appropriate customization can be applied?
+ boot_envs=uEnv.txt\0 \
I wonder if boards want to customize that for backwards-compatibility?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
On Wednesday, February 19, 2014 at 06:41:17 PM, Stephen Warren wrote: On 02/19/2014 10:30 AM, Marek Vasut wrote: On Wednesday, February 19, 2014 at 06:28:39 PM, Stephen Warren wrote: On 02/19/2014 08:54 AM, Marek Vasut wrote: On Monday, February 17, 2014 at 06:56:36 PM, Dennis Gilmore wrote: Signed-off-by: Dennis Gilmore den...@ausil.us --- include/config_distro_bootcmd.h | 172 1 file changed, 172 insertions(+) create mode 100644 include/config_distro_bootcmd.h diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h new file mode 100644 index 000..d32dc12 --- /dev/null +++ b/include/config_distro_bootcmd.h @@ -0,0 +1,172 @@ +/* + * (C) Copyright 2014 + * NVIDIA Corporation www.nvidia.com + * + * Copyright 2014 Red Hat, Inc. + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H +#define _CONFIG_CMD_DISTRO_BOOTCMD_H + + +#ifdef CONFIG_CMD_MMC +#define BOOTCMDS_MMC \ You might want to #undef all this temporary stuff so it's not propagated into the U-Boot further. I don't understand. What temporary stuff are you referring to? BOOTCMDS_MMC for example. This certainly doesn't need to propagate into the rest of the U-Boot build, does it ? Oh, you mean #undef it at the end of the file? That would probably work. I thought you meant something else, although I wasn't sure what. That's what I meant, sorry. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 2/3] move the beaglebones over to the generic configs
On 02/17/2014 10:56 AM, Dennis Gilmore wrote:
Signed-off-by: Dennis Gilmore den...@ausil.us
Patch description?
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
#define CONFIG_EXTRA_ENV_SETTINGS \
loadaddr=0x8020\0 \
- fdtaddr=0x80F8\0 \
+ fdt_addr=0x80F8\0 \
+ fdt_addr_r=0x80F8\0 \
Why set both? Surely only fdt_addr_r is required/useful?
- mmcroot=/dev/mmcblk0p2 ro\0 \
That implies that rootpart=1 in config_distro_bootcmd.h isn't correct
for this board?
- rootpath=/export/rootfs\0 \
- nfsopts=nolock\0 \
- static_ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname} \
- ::off\0 \
- ramroot=/dev/ram0 rw ramdisk_size=65536 initrd=${rdaddr},64M\0 \
- ramrootfstype=ext2\0 \
- mmcargs=setenv bootargs console=${console} \
- ${optargs} \
- root=${mmcroot} \
- rootfstype=${mmcrootfstype}\0 \
- spiroot=/dev/mtdblock4 rw\0 \
- spirootfstype=jffs2\0 \
- spisrcaddr=0xe\0 \
- spiimgsize=0x362000\0 \
- spibusno=0\0 \
- spiargs=setenv bootargs console=${console} \
- ${optargs} \
- root=${spiroot} \
- rootfstype=${spirootfstype}\0 \
- netargs=setenv bootargs console=${console} \
- ${optargs} \
- root=/dev/nfs \
- nfsroot=${serverip}:${rootpath},${nfsopts} rw \
- ip=dhcp\0 \
I'm not at all familiar with this board, but this seems to be removing
NFS and SPI boot capabilities, maybe others too?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 3/3] move wandboard over to use the generic distro configuratin and environment
On 02/17/2014 10:56 AM, Dennis Gilmore wrote:
Signed-off-by: Dennis Gilmore den...@ausil.us
diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
- netargs=setenv bootargs console=${console},${baudrate} \
- root=/dev/nfs \
- ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0 \
- netboot=echo Booting from net ...; \
- run netargs; \
- if test ${ip_dyn} = yes; then \
- setenv get_cmd dhcp; \
- else \
- setenv get_cmd tftp; \
...
This one also removes nfsroot stuff.
Admittedly I would personally argue that nfsroot setup belong in the
boot.scr that comes from some TFTP server, and I wrote the Tegra boot
scripts assuming that, but I probably got away with that for Tegra since
we never had any nfsroot setup in the default environment. People using
these boards might like to keep their working features:-) Perhaps we
could persuade people to adapt though?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
Signed-off-by: Dennis Gilmore den...@ausil.us
---
include/config_distro_bootcmd.h | 172
1 file changed, 172 insertions(+)
create mode 100644 include/config_distro_bootcmd.h
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
new file mode 100644
index 000..d32dc12
--- /dev/null
+++ b/include/config_distro_bootcmd.h
@@ -0,0 +1,172 @@
+/*
+ * (C) Copyright 2014
+ * NVIDIA Corporation www.nvidia.com
+ *
+ * Copyright 2014 Red Hat, Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H
+#define _CONFIG_CMD_DISTRO_BOOTCMD_H
+
+
+#ifdef CONFIG_CMD_MMC
+#define BOOTCMDS_MMC \
+ mmc_boot= \
+ setenv devtype mmc; \
+ if mmc dev ${devnum}; then \
+ run scan_boot; \
+ fi\0 \
+ bootcmd_mmc0=setenv devnum 0; run mmc_boot;\0 \
+ bootcmd_mmc1=setenv devnum 1; run mmc_boot;\0
+#define BOOT_TARGETS_MMC mmc1 mmc0
+#else
+#define BOOTCMDS_MMC
+#define BOOT_TARGETS_MMC
+#endif
+
+#ifdef CONFIG_CMD_USB
+#define BOOTCMD_INIT_USB run usb_init;
+#define BOOTCMDS_USB \
+ usb_init= \
+ if ${usb_need_init}; then \
+ set usb_need_init false; \
+ usb start 0; \
+ fi\0 \
+ \
+ usb_boot= \
+ setenv devtype usb; \
+ BOOTCMD_INIT_USB \
+ if usb dev ${devnum}; then \
This may have already been highlighted but I don't see where the kernel command
line arguments can be set.
If you have the file system on the USB stick won't you need to direct the root
to the stick?
Maybe I don't want to have a uEnv.txt file.
This is what I had to do when I did the similar implementation on the TI common
file
http://patchwork.ozlabs.org/patch/292851/
+ run scan_boot; \
+ fi\0 \
+ \
+ bootcmd_usb0=setenv devnum 0; run usb_boot;\0
+#define BOOT_TARGETS_USB usb0
+#else
+#define BOOTCMD_INIT_USB
+#define BOOTCMDS_USB
+#define BOOT_TARGETS_USB
+#endif
+
+#ifdef CONFIG_CMD_SATA
+#define BOOTCMDS_SATA \
+ sata_boot= \
+ setenv devtype sata; \
+ if sata dev ${devnum}; then \
+ run scan_boot; \
Same as above
+ fi\0 \
+ \
+ bootcmd_sata0=setenv devnum 0; run sata_boot;\0
+ bootcmd_sata1=setenv devnum 1; run sata_boot;\0
+#define BOOT_TARGETS_USB sata0 sata1
+#else
+#define BOOTCMDS_SATA
+#define BOOT_TARGETS_SATA
+#endif
+
+#ifdef CONFIG_CMD_DHCP
+#define BOOTCMDS_DHCP \
+ bootcmd_dhcp= \
+ BOOTCMD_INIT_USB \
+ if dhcp ${scriptaddr} boot.scr.uimg; then \
+ source ${scriptaddr}; \
+ fi\0
+#define BOOT_TARGETS_DHCP dhcp
+#else
+#define BOOTCMDS_DHCP
+#define BOOT_TARGETS_DHCP
+#endif
+
+#if defined(CONFIG_CMD_DHCP) defined(CONFIG_CMD_PXE)
+#define BOOTCMDS_PXE \
+ bootcmd_pxe= \
+ BOOTCMD_INIT_USB \
+ dhcp; \
+ if pxe get; then \
+ pxe boot; \
+ fi\0
+#define BOOT_TARGETS_PXE pxe
+#else
+#define BOOTCMDS_PXE
+#define BOOT_TARGETS_PXE
+#endif
+
--
--
Dan Murphy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
On 02/19/2014 11:44 AM, Dan Murphy wrote:
On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
Signed-off-by: Dennis Gilmore den...@ausil.us
diff --git a/include/config_distro_bootcmd.h
b/include/config_distro_bootcmd.h
+#ifdef CONFIG_CMD_USB
+#define BOOTCMD_INIT_USB run usb_init;
+#define BOOTCMDS_USB \
+usb_init= \
+if ${usb_need_init}; then \
+set usb_need_init false; \
+usb start 0; \
+fi\0 \
+\
+usb_boot= \
+setenv devtype usb; \
+BOOTCMD_INIT_USB \
+if usb dev ${devnum}; then \
This may have already been highlighted but I don't see where the kernel
command line arguments can be set.
If you have the file system on the USB stick won't you need to direct the
root to the stick?
They would be set in boot.scr or extlinux.cfg on the disk that the
system boots from; the kernel cmdline is part of the OS that's installed
there, not part of U-Boot. This is why these boot scripts load a
script/config-file from the disk which in turn defines which
kernel/DTB/cmdline to use, rather than directly loading a kernel and
DTB. This approach should even be suitable for booting a non-Linux-OS,
with suitable commands in boot.scr.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
On 02/19/2014 12:48 PM, Stephen Warren wrote:
On 02/19/2014 11:44 AM, Dan Murphy wrote:
On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
Signed-off-by: Dennis Gilmore den...@ausil.us
diff --git a/include/config_distro_bootcmd.h
b/include/config_distro_bootcmd.h
+#ifdef CONFIG_CMD_USB
+#define BOOTCMD_INIT_USB run usb_init;
+#define BOOTCMDS_USB \
+ usb_init= \
+ if ${usb_need_init}; then \
+ set usb_need_init false; \
+ usb start 0; \
+ fi\0 \
+ \
+ usb_boot= \
+ setenv devtype usb; \
+ BOOTCMD_INIT_USB \
+ if usb dev ${devnum}; then \
This may have already been highlighted but I don't see where the kernel
command line arguments can be set.
If you have the file system on the USB stick won't you need to direct the
root to the stick?
They would be set in boot.scr or extlinux.cfg on the disk that the
system boots from; the kernel cmdline is part of the OS that's installed
there, not part of U-Boot. This is why these boot scripts load a
script/config-file from the disk which in turn defines which
kernel/DTB/cmdline to use, rather than directly loading a kernel and
DTB. This approach should even be suitable for booting a non-Linux-OS,
with suitable commands in boot.scr.
But shouldn't the config file just be an override?
I don't know if we should be having to need to load a boot.scr or any config
file just to get the kernel to boot.
If no config file exists should we not try to default to a known good default
tested case?
Dan
--
--
Dan Murphy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
On 02/19/2014 11:52 AM, Dan Murphy wrote:
On 02/19/2014 12:48 PM, Stephen Warren wrote:
On 02/19/2014 11:44 AM, Dan Murphy wrote:
On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
Signed-off-by: Dennis Gilmore den...@ausil.us
diff --git a/include/config_distro_bootcmd.h
b/include/config_distro_bootcmd.h
+#ifdef CONFIG_CMD_USB
+#define BOOTCMD_INIT_USB run usb_init;
+#define BOOTCMDS_USB \
+ usb_init= \
+ if ${usb_need_init}; then \
+ set usb_need_init false; \
+ usb start 0; \
+ fi\0 \
+ \
+ usb_boot= \
+ setenv devtype usb; \
+ BOOTCMD_INIT_USB \
+ if usb dev ${devnum}; then \
This may have already been highlighted but I don't see where the kernel
command line arguments can be set.
If you have the file system on the USB stick won't you need to direct the
root to the stick?
They would be set in boot.scr or extlinux.cfg on the disk that the
system boots from; the kernel cmdline is part of the OS that's installed
there, not part of U-Boot. This is why these boot scripts load a
script/config-file from the disk which in turn defines which
kernel/DTB/cmdline to use, rather than directly loading a kernel and
DTB. This approach should even be suitable for booting a non-Linux-OS,
with suitable commands in boot.scr.
But shouldn't the config file just be an override?
I don't know if we should be having to need to load a boot.scr or any config
file just to get the kernel to boot.
If no config file exists should we not try to default to a known good default
tested case?
I believe always loading a script/config-file is the simplest and most
flexible approach, for a *distro* *oriented* boot process.
Now, specific U-Boot board configs can always add extra stuff on the end
(or start?) of bootcmd in order to do some custom fallbacks or
backwards-compatibility if they want, but I'm certainly not planning on
doing anything like that for Tegra or Raspberry Pi, for example.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
On 02/19/2014 12:57 PM, Stephen Warren wrote:
On 02/19/2014 11:52 AM, Dan Murphy wrote:
On 02/19/2014 12:48 PM, Stephen Warren wrote:
On 02/19/2014 11:44 AM, Dan Murphy wrote:
On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
Signed-off-by: Dennis Gilmore den...@ausil.us
diff --git a/include/config_distro_bootcmd.h
b/include/config_distro_bootcmd.h
+#ifdef CONFIG_CMD_USB
+#define BOOTCMD_INIT_USB run usb_init;
+#define BOOTCMDS_USB \
+ usb_init= \
+ if ${usb_need_init}; then \
+ set usb_need_init false; \
+ usb start 0; \
+ fi\0 \
+ \
+ usb_boot= \
+ setenv devtype usb; \
+ BOOTCMD_INIT_USB \
+ if usb dev ${devnum}; then \
This may have already been highlighted but I don't see where the kernel
command line arguments can be set.
If you have the file system on the USB stick won't you need to direct the
root to the stick?
They would be set in boot.scr or extlinux.cfg on the disk that the
system boots from; the kernel cmdline is part of the OS that's installed
there, not part of U-Boot. This is why these boot scripts load a
script/config-file from the disk which in turn defines which
kernel/DTB/cmdline to use, rather than directly loading a kernel and
DTB. This approach should even be suitable for booting a non-Linux-OS,
with suitable commands in boot.scr.
But shouldn't the config file just be an override?
I don't know if we should be having to need to load a boot.scr or any config
file just to get the kernel to boot.
If no config file exists should we not try to default to a known good
default tested case?
I believe always loading a script/config-file is the simplest and most
flexible approach, for a *distro* *oriented* boot process.
Now, specific U-Boot board configs can always add extra stuff on the end
(or start?) of bootcmd in order to do some custom fallbacks or
backwards-compatibility if they want, but I'm certainly not planning on
doing anything like that for Tegra or Raspberry Pi, for example.
Yeah I am not seeing how the board config can do that if there is no provisions
in the common file.
On another note there is no support in here for NAND. Was there a plan to pull
that in as well?
Dan
--
--
Dan Murphy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
On 02/19/2014 11:57 AM, Stephen Warren wrote:
On 02/19/2014 11:52 AM, Dan Murphy wrote:
On 02/19/2014 12:48 PM, Stephen Warren wrote:
On 02/19/2014 11:44 AM, Dan Murphy wrote:
On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
Signed-off-by: Dennis Gilmore den...@ausil.us
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
+#ifdef CONFIG_CMD_USB
+#define BOOTCMD_INIT_USB run usb_init;
+#define BOOTCMDS_USB \
+ usb_init= \
+ if ${usb_need_init}; then \
+ set usb_need_init false; \
+ usb start 0; \
+ fi\0 \
+ \
+ usb_boot= \
+ setenv devtype usb; \
+ BOOTCMD_INIT_USB \
+ if usb dev ${devnum}; then \
This may have already been highlighted but I don't see where the kernel command
line arguments can be set.
If you have the file system on the USB stick won't you need to direct the root
to the stick?
They would be set in boot.scr or extlinux.cfg on the disk that the
system boots from; the kernel cmdline is part of the OS that's installed
there, not part of U-Boot. This is why these boot scripts load a
script/config-file from the disk which in turn defines which
kernel/DTB/cmdline to use, rather than directly loading a kernel and
DTB. This approach should even be suitable for booting a non-Linux-OS,
with suitable commands in boot.scr.
But shouldn't the config file just be an override?
I don't know if we should be having to need to load a boot.scr or any config
file just to get the kernel to boot.
If no config file exists should we not try to default to a known good default
tested case?
I believe always loading a script/config-file is the simplest and most
flexible approach, for a *distro* *oriented* boot process.
+1
Scripts have the benefit of putting everything into a relatively
easy-to-read form that only uses documented U-Boot commands, not
board-specific constructs.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
On 02/19/2014 11:59 AM, Dan Murphy wrote:
On 02/19/2014 12:57 PM, Stephen Warren wrote:
On 02/19/2014 11:52 AM, Dan Murphy wrote:
On 02/19/2014 12:48 PM, Stephen Warren wrote:
On 02/19/2014 11:44 AM, Dan Murphy wrote:
On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
Signed-off-by: Dennis Gilmore den...@ausil.us
diff --git a/include/config_distro_bootcmd.h
b/include/config_distro_bootcmd.h
+#ifdef CONFIG_CMD_USB
+#define BOOTCMD_INIT_USB run usb_init;
+#define BOOTCMDS_USB \
+usb_init= \
+if ${usb_need_init}; then \
+set usb_need_init false; \
+usb start 0; \
+fi\0 \
+\
+usb_boot= \
+setenv devtype usb; \
+BOOTCMD_INIT_USB \
+if usb dev ${devnum}; then \
This may have already been highlighted but I don't see where the kernel
command line arguments can be set.
If you have the file system on the USB stick won't you need to direct the
root to the stick?
They would be set in boot.scr or extlinux.cfg on the disk that the
system boots from; the kernel cmdline is part of the OS that's installed
there, not part of U-Boot. This is why these boot scripts load a
script/config-file from the disk which in turn defines which
kernel/DTB/cmdline to use, rather than directly loading a kernel and
DTB. This approach should even be suitable for booting a non-Linux-OS,
with suitable commands in boot.scr.
But shouldn't the config file just be an override?
I don't know if we should be having to need to load a boot.scr or any
config file just to get the kernel to boot.
If no config file exists should we not try to default to a known good
default tested case?
I believe always loading a script/config-file is the simplest and most
flexible approach, for a *distro* *oriented* boot process.
Now, specific U-Boot board configs can always add extra stuff on the end
(or start?) of bootcmd in order to do some custom fallbacks or
backwards-compatibility if they want, but I'm certainly not planning on
doing anything like that for Tegra or Raspberry Pi, for example.
Yeah I am not seeing how the board config can do that if there is no
provisions in the common file.
Presumably all it needs is an extra hook/variable that is added to the
start/end of bootcmd. Should be pretty easy to add in a future patch
rev, or followon patch.
On another note there is no support in here for NAND. Was there a plan to
pull that in as well?
A generic Linux distro wouldn't be installing a kernel to NAND, but
would rather put it into the /boot filesystem. NAND boot is something
that'd be best supported by the custom hook we discussed above.
The commit description for this commit should have set the scene that
this series is all about providing a way for a generic Linux distro to
create a generic installable media set that boots the same way across n
different boards with U-Boot, and similarly also to set up the installed
distro filesystem in a single generic way that can boot on any board it
gets installed to. It's all about avoiding board-specific boot options
such as NAND, and hence may well not be applicable to boards that
primarily/only boot from NAND; they would still need custom distro
install media and hooks to set up the installed filesystem.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
On Wed, Feb 19, 2014 at 12:04:12PM -0700, Stephen Warren wrote:
On 02/19/2014 11:59 AM, Dan Murphy wrote:
On 02/19/2014 12:57 PM, Stephen Warren wrote:
On 02/19/2014 11:52 AM, Dan Murphy wrote:
On 02/19/2014 12:48 PM, Stephen Warren wrote:
On 02/19/2014 11:44 AM, Dan Murphy wrote:
On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
Signed-off-by: Dennis Gilmore den...@ausil.us
diff --git a/include/config_distro_bootcmd.h
b/include/config_distro_bootcmd.h
+#ifdef CONFIG_CMD_USB
+#define BOOTCMD_INIT_USB run usb_init;
+#define BOOTCMDS_USB \
+ usb_init= \
+ if ${usb_need_init}; then \
+ set usb_need_init false; \
+ usb start 0; \
+ fi\0 \
+ \
+ usb_boot= \
+ setenv devtype usb; \
+ BOOTCMD_INIT_USB \
+ if usb dev ${devnum}; then \
This may have already been highlighted but I don't see where the kernel
command line arguments can be set.
If you have the file system on the USB stick won't you need to direct
the root to the stick?
They would be set in boot.scr or extlinux.cfg on the disk that the
system boots from; the kernel cmdline is part of the OS that's installed
there, not part of U-Boot. This is why these boot scripts load a
script/config-file from the disk which in turn defines which
kernel/DTB/cmdline to use, rather than directly loading a kernel and
DTB. This approach should even be suitable for booting a non-Linux-OS,
with suitable commands in boot.scr.
But shouldn't the config file just be an override?
I don't know if we should be having to need to load a boot.scr or any
config file just to get the kernel to boot.
If no config file exists should we not try to default to a known good
default tested case?
I believe always loading a script/config-file is the simplest and most
flexible approach, for a *distro* *oriented* boot process.
Now, specific U-Boot board configs can always add extra stuff on the end
(or start?) of bootcmd in order to do some custom fallbacks or
backwards-compatibility if they want, but I'm certainly not planning on
doing anything like that for Tegra or Raspberry Pi, for example.
Yeah I am not seeing how the board config can do that if there is no
provisions in the common file.
Presumably all it needs is an extra hook/variable that is added to the
start/end of bootcmd. Should be pretty easy to add in a future patch
rev, or followon patch.
On another note there is no support in here for NAND. Was there a plan to
pull that in as well?
A generic Linux distro wouldn't be installing a kernel to NAND, but
would rather put it into the /boot filesystem. NAND boot is something
that'd be best supported by the custom hook we discussed above.
Wait, why would a generic Linux distro be installing to eMMC but not to
NAND ? Not that this series needs to be the final point in the
discussion and all.
The commit description for this commit should have set the scene that
this series is all about providing a way for a generic Linux distro to
create a generic installable media set that boots the same way across n
different boards with U-Boot, and similarly also to set up the installed
distro filesystem in a single generic way that can boot on any board it
gets installed to. It's all about avoiding board-specific boot options
such as NAND, and hence may well not be applicable to boards that
primarily/only boot from NAND; they would still need custom distro
install media and hooks to set up the installed filesystem.
Why is NAND special but SATA not, other than desktops often have SATA
exposed but not NAND? Even more so when you consider that from the
Linux side of things, dealing with NAND is dealing with NAND and it's
not board specific.
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
On 02/19/2014 01:02 PM, Eric Nelson wrote:
On 02/19/2014 11:57 AM, Stephen Warren wrote:
On 02/19/2014 11:52 AM, Dan Murphy wrote:
On 02/19/2014 12:48 PM, Stephen Warren wrote:
On 02/19/2014 11:44 AM, Dan Murphy wrote:
On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
Signed-off-by: Dennis Gilmore den...@ausil.us
diff --git a/include/config_distro_bootcmd.h
b/include/config_distro_bootcmd.h
+#ifdef CONFIG_CMD_USB
+#define BOOTCMD_INIT_USB run usb_init;
+#define BOOTCMDS_USB \
+usb_init= \
+if ${usb_need_init}; then \
+set usb_need_init false; \
+usb start 0; \
+fi\0 \
+\
+usb_boot= \
+setenv devtype usb; \
+BOOTCMD_INIT_USB \
+if usb dev ${devnum}; then \
This may have already been highlighted but I don't see where the kernel
command line arguments can be set.
If you have the file system on the USB stick won't you need to direct the
root to the stick?
They would be set in boot.scr or extlinux.cfg on the disk that the
system boots from; the kernel cmdline is part of the OS that's installed
there, not part of U-Boot. This is why these boot scripts load a
script/config-file from the disk which in turn defines which
kernel/DTB/cmdline to use, rather than directly loading a kernel and
DTB. This approach should even be suitable for booting a non-Linux-OS,
with suitable commands in boot.scr.
But shouldn't the config file just be an override?
I don't know if we should be having to need to load a boot.scr or any
config file just to get the kernel to boot.
If no config file exists should we not try to default to a known good
default tested case?
I believe always loading a script/config-file is the simplest and most
flexible approach, for a *distro* *oriented* boot process.
+1
Scripts have the benefit of putting everything into a relatively
easy-to-read form that only uses documented U-Boot commands, not
board-specific constructs.
Oh don't get me wrong I agree with having the scripts.
Just sayin we should not rely on the scripts being there and mandating their
usage.
We may want to have a fall back to a known good tested configuration.
Dan
--
--
Dan Murphy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
On 02/19/2014 12:10 PM, Tom Rini wrote: ... A generic Linux distro wouldn't be installing a kernel to NAND, but would rather put it into the /boot filesystem. NAND boot is something that'd be best supported by the custom hook we discussed above. Wait, why would a generic Linux distro be installing to eMMC but not to NAND ? Not that this series needs to be the final point in the discussion and all. I should point out that I was talking about raw NAND MTD partitions rather than a NAND device with a regular partition table and normal filesystems within it. If the NAND is exposed as a regular block device with a regular filesystem, then it'd look just like any other block device to a generic distro installer, and hence it could put /boot there, and this patch (or future enhancement) could certainly usefully contain a generic bootcmd_nand that used it. However, if the NAND has hard-coded MTD partitions, and/or the partitions have no filesystem but rather contain e.g. a raw zImage/uImage, then that would require board-/SoC-specific support in the distro kernel and installer, and hence we wouldn't be talking about a *generic* installer/distro, and *generic* installers/distros are what this patch series is all about. The commit description for this commit should have set the scene that this series is all about providing a way for a generic Linux distro to create a generic installable media set that boots the same way across n different boards with U-Boot, and similarly also to set up the installed distro filesystem in a single generic way that can boot on any board it gets installed to. It's all about avoiding board-specific boot options such as NAND, and hence may well not be applicable to boards that primarily/only boot from NAND; they would still need custom distro install media and hooks to set up the installed filesystem. Why is NAND special but SATA not, other than desktops often have SATA exposed but not NAND? Even more so when you consider that from the Linux side of things, dealing with NAND is dealing with NAND and it's not board specific. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
On Wed, Feb 19, 2014 at 01:05:15PM -0600, Dan Murphy wrote:
On 02/19/2014 01:02 PM, Eric Nelson wrote:
On 02/19/2014 11:57 AM, Stephen Warren wrote:
On 02/19/2014 11:52 AM, Dan Murphy wrote:
On 02/19/2014 12:48 PM, Stephen Warren wrote:
On 02/19/2014 11:44 AM, Dan Murphy wrote:
On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
Signed-off-by: Dennis Gilmore den...@ausil.us
diff --git a/include/config_distro_bootcmd.h
b/include/config_distro_bootcmd.h
+#ifdef CONFIG_CMD_USB
+#define BOOTCMD_INIT_USB run usb_init;
+#define BOOTCMDS_USB \
+usb_init= \
+if ${usb_need_init}; then \
+set usb_need_init false; \
+usb start 0; \
+fi\0 \
+\
+usb_boot= \
+setenv devtype usb; \
+BOOTCMD_INIT_USB \
+if usb dev ${devnum}; then \
This may have already been highlighted but I don't see where the kernel
command line arguments can be set.
If you have the file system on the USB stick won't you need to direct
the root to the stick?
They would be set in boot.scr or extlinux.cfg on the disk that the
system boots from; the kernel cmdline is part of the OS that's installed
there, not part of U-Boot. This is why these boot scripts load a
script/config-file from the disk which in turn defines which
kernel/DTB/cmdline to use, rather than directly loading a kernel and
DTB. This approach should even be suitable for booting a non-Linux-OS,
with suitable commands in boot.scr.
But shouldn't the config file just be an override?
I don't know if we should be having to need to load a boot.scr or any
config file just to get the kernel to boot.
If no config file exists should we not try to default to a known good
default tested case?
I believe always loading a script/config-file is the simplest and most
flexible approach, for a *distro* *oriented* boot process.
+1
Scripts have the benefit of putting everything into a relatively
easy-to-read form that only uses documented U-Boot commands, not
board-specific constructs.
Oh don't get me wrong I agree with having the scripts.
Just sayin we should not rely on the scripts being there and mandating
their usage.
We may want to have a fall back to a known good tested configuration.
I think I see where you're coming from, but it's already expected that
you're passing in a good device tree too, so it would be making sure
that you also have a useful env file to get loaded in the DHCP or PXE
case.
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
