[U-Boot] recommended action for bootloaders regarding modifying device-tree nodes
Greetings, I develop the boot-loader and kernel for a family of boards that have an on-board EEPROM which contains information as to what options are physically loaded on the board such as memory size/config, and peripheral IC's. We allow customers to create special builds of our standard products with sub-loaded components and while each combination of options ends up with a unique model number, it seems silly to create a different static device-trees for each possible option (not to mention we don't create the unique model number until an order is placed). My approach has been to define a per-baseboard device-tree in Linux for a 'fully loaded' board, then remove nodes which the EEPROM claims are not present in the bootloader before it passes the DTB to the kernel. I do this by defining aliases in the device-tree for the peripherals that are 'optional' so that the bootloader itself does not need to know the details about how the device is connected. Is it more appropriate for the bootloader to 'remove' nodes for devices that are not physically present or should I be setting their status property to 'disabled' instead? I'm not clear if either option really has any pros or cons. Thanks for any suggestions or comments, Tim Tim Harvey - Principal Software Engineer Gateworks Corporation 3026 S. Higuera St. San Luis Obispo CA 93401 805-781-2000 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] dts: re-write dts/Makefile more simply with Kbuild
Useful rules in scripts/Makefile.lib allows us to easily generate a device tree blob and wrap it in assembly code. We do not need to parse a linker script to get output format and arch. Signed-off-by: Masahiro Yamada --- This patch uses my Kbuild series as a prerequisite. "Switch over to real Kbuild" series must be applied beforehand. .gitignore | 1 - Makefile| 16 +- arch/arm/lib/board.c| 2 +- arch/microblaze/lib/board.c | 2 +- arch/x86/lib/init_helpers.c | 2 +- common/board_f.c| 2 +- dts/.gitignore | 2 ++ dts/Makefile| 72 + include/common.h| 2 +- scripts/Makefile.lib| 12 10 files changed, 41 insertions(+), 72 deletions(-) create mode 100644 dts/.gitignore diff --git a/.gitignore b/.gitignore index 24019b3..5882ff5 100644 --- a/.gitignore +++ b/.gitignore @@ -48,7 +48,6 @@ /u-boot.lds /u-boot.ubl /u-boot.ais -/u-boot.dtb /u-boot.sb # diff --git a/Makefile b/Makefile index 3bf759a..ab82ed4 100644 --- a/Makefile +++ b/Makefile @@ -743,7 +743,7 @@ ALL-$(CONFIG_RAMBOOT_PBL) += u-boot.pbl ALL-$(CONFIG_SPL) += spl/u-boot-spl.bin ALL-$(CONFIG_SPL_FRAMEWORK) += u-boot.img ALL-$(CONFIG_TPL) += tpl/u-boot-tpl.bin -ALL-$(CONFIG_OF_SEPARATE) += u-boot.dtb u-boot-dtb.bin +ALL-$(CONFIG_OF_SEPARATE) += u-boot-dtb.bin ifneq ($(CONFIG_SPL_TARGET),) ALL-$(CONFIG_SPL) += $(CONFIG_SPL_TARGET:"%"=%) endif @@ -767,11 +767,11 @@ endif all: $(ALL-y) -u-boot.dtb:checkdtc u-boot - $(MAKE) $(build)=dts binary - mv dts/dt.dtb $@ +PHONY += dtbs +dtbs dts/dt.dtb: checkdtc u-boot + $(Q)$(MAKE) $(build)=dts dtbs -u-boot-dtb.bin:u-boot.bin u-boot.dtb +u-boot-dtb.bin: u-boot.bin dts/dt.dtb cat $^ >$@ u-boot.hex:u-boot @@ -898,8 +898,8 @@ u-boot-nodtb-tegra.bin: spl/u-boot-spl.bin u-boot.bin rm spl/u-boot-spl-pad.bin ifeq ($(CONFIG_OF_SEPARATE),y) -u-boot-dtb-tegra.bin: u-boot-nodtb-tegra.bin u-boot.dtb - cat u-boot-nodtb-tegra.bin u-boot.dtb > $@ +u-boot-dtb-tegra.bin: u-boot-nodtb-tegra.bin dts/dt.dtb + cat $^ > $@ endif endif @@ -1184,7 +1184,7 @@ CLOBBER_DIRS += tpl \ $(shell ls -1 --file-type spl 2>/dev/null CLOBBER_FILES += u-boot u-boot.elf u-boot.hex u-boot.img \ u-boot.kwb u-boot.pbl u-boot.ldr \ -u-boot.ubl u-boot.ais u-boot.dtb \ +u-boot.ubl u-boot.ais \ u-boot.sb u-boot.spr MLO MLO.byteswap SPL \ $(patsubst %,spl/%, $(filter-out Makefile %/, \ $(shell ls -1 --file-type spl 2>/dev/null))) \ diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index b770e25..c8cb049 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@ -280,7 +280,7 @@ void board_init_f(ulong bootflag) gd->mon_len = _bss_end_ofs; #ifdef CONFIG_OF_EMBED /* Get a pointer to the FDT */ - gd->fdt_blob = _binary_dt_dtb_start; + gd->fdt_blob = __dtb_db_begin #elif defined CONFIG_OF_SEPARATE /* FDT is at end of image */ gd->fdt_blob = (void *)(_end_ofs + _TEXT_BASE); diff --git a/arch/microblaze/lib/board.c b/arch/microblaze/lib/board.c index 896e73a..0f10c88 100644 --- a/arch/microblaze/lib/board.c +++ b/arch/microblaze/lib/board.c @@ -76,7 +76,7 @@ void board_init_f(ulong not_used) #ifdef CONFIG_OF_EMBED /* Get a pointer to the FDT */ - gd->fdt_blob = _binary_dt_dtb_start; + gd->fdt_blob = __dtb_dt_begin; #elif defined CONFIG_OF_SEPARATE /* FDT is at end of image */ gd->fdt_blob = (void *)__end; diff --git a/arch/x86/lib/init_helpers.c b/arch/x86/lib/init_helpers.c index 582c0ff..b5d937f 100644 --- a/arch/x86/lib/init_helpers.c +++ b/arch/x86/lib/init_helpers.c @@ -92,7 +92,7 @@ int find_fdt(void) { #ifdef CONFIG_OF_EMBED /* Get a pointer to the FDT */ - gd->fdt_blob = _binary_dt_dtb_start; + gd->fdt_blob = __dtb_dt_begin; #elif defined CONFIG_OF_SEPARATE /* FDT is at end of image */ gd->fdt_blob = (ulong *)&_end; diff --git a/common/board_f.c b/common/board_f.c index aa70c3e..d0ee6f7 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -360,7 +360,7 @@ static int setup_fdt(void) { #ifdef CONFIG_OF_EMBED /* Get a pointer to the FDT */ - gd->fdt_blob = _binary_dt_dtb_start; + gd->fdt_blob = __dtb_dt_begin; #elif defined CONFIG_OF_SEPARATE /* FDT is at end of image */ # ifdef CONFIG_SYS_SYM_OFFSETS diff --git a/dts/.gitignore b/dts/.gitignore new file mode 100644 index 000..1b37180 --- /dev/null +++ b/dts/.gitignore @@ -0,0 +1,2 @@ +*.dtb +*.dtb.S diff --git a/dts/Makefile b/dts/Makefile index 1e7609a..c47fba7 100644 --- a/dts/Makefile +++ b/dts/Makefile @@ -7,64 +7,32 @@ # This Makefile builds the internal U-Boot fdt if CO
Re: [U-Boot] recommended action for bootloaders regarding modifying device-tree nodes
Hello, On 30 January 2014 10:11, Tim Harvey wrote: > Greetings, > > > Is it more appropriate for the bootloader to 'remove' nodes for > devices that are not physically present or should I be setting their > status property to 'disabled' instead? I'm not clear if either option > really has any pros or cons. > I am not a DT or u-boot developer but I observe these things: 1) DT include for a SoC has all supported devices. Some which require external parts (eg. physical connectors, extra PHY, ...) are listed as disabled and particular board DT enables them. 2) there is code for setting mac address on ethernet nodes with a specific alias so you could perhaps reuse this code to set disabled option on particular nodes. Thanks Michal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/2] common: Add new clk command
Hi Michal, On 30/01/2014 08:38, Michal Simek wrote: > On 01/23/2014 08:53 AM, Michal Simek wrote: >> On 01/22/2014 08:44 PM, Gerhard Sittig wrote: >>> On Wed, Jan 22, 2014 at 12:02 +0100, Michal Simek wrote: --- /dev/null +++ b/common/cmd_clk.c @@ -0,0 +1,51 @@ +/* + * Copyright (C) 2013 Xilinx, Inc. + * + * SPDX-License-Identifier: GPL-2.0+ + */ +#include +#include +#include + +int __weak soc_clk_dump(void) +{ +puts("Not implemented\n"); +return 1; +} + +static int do_clk_dump(cmd_tbl_t *cmdtp, int flag, int argc, + char *const argv[]) +{ + return soc_clk_dump(); +} >>> >>> Is there a specific reason to not pass on the remaining (not >>> yet consumed) command line arguments? Future implementations >>> may want to take a clock item's name, or a clock group's name, >>> or options related to the format or verbosity of the dump, et >>> al. >> >> Only one reason is that I don't need it for my zynq >> implementation. If this is necessary there is no problem to pass >> them because it is internal API. Also I prefer to pass just >> arguments which I need. >> >> I have looked at i.MXes cases and they do in general what my >> zynq implementation. They can just include clk.h and change >> do_mx6_showclocks to soc_clk_dump. > Agree. > Stefano: Can you give me your ACK? > Sure, go on. ! 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] [PATCH] arm/da850 : [RFC] add bootdsp to cmd_elf
On 01/29/2014 11:37 PM, Tom Rini wrote: On Mon, Jan 27, 2014 at 05:28:22PM +0100, Paul Chavent wrote: On platform with a DSP co-processor, add a command to boot an elf on it. * Test * This patch has been tested on an OMAP-L138 EVM with DSP code generated with TI's code generation tools 7.4.6 with the --abi=eabi option. * Bugs * Some elf generated with older TI's cgt have mis-aligned header sections that lead to u-boot freeze. This point can be checked with readelf (see "Start of program headers" and/or "Start of section headers") if you experience such problem. * Discussion * Our first question is about the interest of the u-boot community for this feature ? For the implementation, we tried to separate platform specific code (dsp's reset and entry point) from the elf generic code (check and load elf in memory). We would like to have your opinion on this design. This seems like the right direction to take for things. The question I have first is, are we talking about loading something into the DSP and then letting it go, or are we talking about getting a result back from the DSP in Linux? I assume the first case. Thank you for having considered the patch. Indeed, this is about loading something into the DSP and then letting it go without worrying about the result. In our use case however, later, the ARM run some programs (under Linux) that will use services provided by the DSP through its L2 cache used as shared memory. Ideally, we would like to be able to soft reset the ARM without killing the DSP that will run the critical code that should survive to hight level apps failures... I wait for your advices to improve the patch integration (I'm not sure that the "extern" declarations on top of cmd_elf.c will be integrated like that). Moreover, i wonder if we should begin to think about a more generic "boot_companion" function that would introduce a framework in order to boot companion cpu... but perhaps it's a bit premature. Regards. Paul Chavent. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/9] kmp204x: I2C deblocking for I2C-bus1 added
On 01/30/2014 08:32 AM, Valentin Longchamp wrote: > On 01/30/2014 03:30 AM, York Sun wrote: >> On 01/27/2014 02:49 AM, Valentin Longchamp wrote: >>> From: Rainer Boschung >>> >>> -uses common deblocking algorithm from ../common/common.c >> >> I don't see any algorithm in the common.c file. > > The file is board/keymile/common/common.c, where the i2c_make_abort() and the > i2c_write_start_seq() functions are defined. I guess that's what Rainer means > with "algorithm". That is what I meant. I will add a more precise comment. > > I agree that the relative path for the file is not very fortunate and that's > why you have not found the functions. > >> >>> -supports deblocking of of I2C-bus1 by means of QRIO GPIO >>> - SCL1 = GPIO_A16 >>> - SDA1 = GPIO_A17 >>> >>> QRIO GPIOs act in an open-drain-like manner, for 0 GPIO drives low >>> and for 1 the GPIO is an input and must be pulled up externaly! >>> >>> Signed-off-by: Rainer Boschung >>> Signed-off-by: Valentin Longchamp >>> --- >>> >>> Changes in v2: None >>> >>> board/keymile/kmp204x/kmp204x.c | 53 >>> ++--- >>> include/configs/km/kmp204x-common.h | 10 +++ >>> 2 files changed, 60 insertions(+), 3 deletions(-) >>> >>> diff --git a/board/keymile/kmp204x/kmp204x.c >>> b/board/keymile/kmp204x/kmp204x.c index bbb2453..8d6eecb 100644 >>> --- a/board/keymile/kmp204x/kmp204x.c >>> +++ b/board/keymile/kmp204x/kmp204x.c >>> @@ -33,12 +33,51 @@ int checkboard(void) >>> return 0; >>> } >>> >>> -/* TODO: implement the I2C deblocking function */ -int >>> i2c_make_abort(void) >>> +/* I2C deblocking uses the algorithm defined in ../common/common.c, >>> +which >>> + * makes use of 2 QRIO GPIOs to act on the SCL and SDA signals of an I2C >>> bus. >>> + * According to the standard I2C IOs must not drive HI-Levels, so >>> +the >>> + * QRIO GPIOs are used in open-drain fashion: >>> + * -> 0 GPIO configured as output that drives low >>> + * -> 1 GPIO configured as input pull-up ties high */ >>> + >> >> I failed to understand these comments as well. Are these comments >> copy-n-paste? >> > > I will let Rainer answer this as he has written this comment. But I don't > think it's copy-n-paste. It's maybe not very clear for people who don't know > the hardware. No the comment isn't copy-n-paste. The GPIO just drives low states, for a high states the pin is not driven (= GPIO configured as input), it is pull-up by a resistor. I will try to clarify this comment. > > Valentin Rainer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net, phy: atheros ar803x bug
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 Cc: Shengzhou Liu Cc: Joe Hershberger --- drivers/net/phy/atheros.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/phy/atheros.c b/drivers/net/phy/atheros.c index 32c2ab9..994500b 100644 --- a/drivers/net/phy/atheros.c +++ b/drivers/net/phy/atheros.c @@ -52,7 +52,7 @@ static struct phy_driver AR8031_driver = { .uid = 0x4dd074, .mask = 0xffef, .features = PHY_GBIT_FEATURES, - .config = ar8021_config, + .config = genphy_config, .startup = genphy_startup, .shutdown = genphy_shutdown, }; -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 2/3] arm: make _end compiler-generated
This prevents references to _end from generating absolute relocation records. This change is binary invariant for ARM targets. Signed-off-by: Albert ARIBAUD --- Changes in v5: - Rebase onto u-boot-arm/master Changes in v4: None Changes in v3: - Replace _end in linker scripts with _image_binary_end Changes in v2: None arch/arm/cpu/arm1136/u-boot-spl.lds| 6 +- arch/arm/cpu/arm920t/ep93xx/u-boot.lds | 5 - arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds | 9 +++-- arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds| 9 +++-- arch/arm/cpu/armv7/am33xx/u-boot-spl.lds | 6 +- arch/arm/cpu/armv7/omap-common/u-boot-spl.lds | 6 +- arch/arm/cpu/armv7/socfpga/u-boot-spl.lds | 6 +- arch/arm/cpu/at91-common/u-boot-spl.lds| 6 +- arch/arm/cpu/ixp/u-boot.lds| 9 +++-- arch/arm/cpu/u-boot-spl.lds| 9 +++-- arch/arm/cpu/u-boot.lds| 11 +-- arch/arm/lib/Makefile | 2 +- arch/arm/lib/sections.c| 1 + board/Barix/ipam390/u-boot-spl-ipam390.lds | 6 +- board/actux1/u-boot.lds| 9 +++-- board/actux2/u-boot.lds| 9 +++-- board/actux3/u-boot.lds| 9 +++-- board/ait/cam_enc_4xx/u-boot-spl.lds | 6 +- board/compulab/cm_t335/u-boot.lds | 9 +++-- board/davinci/da8xxevm/u-boot-spl-da850evm.lds | 6 +- board/davinci/da8xxevm/u-boot-spl-hawk.lds | 5 - board/dvlhost/u-boot.lds | 9 +++-- board/freescale/mx31ads/u-boot.lds | 9 +++-- board/samsung/common/exynos-uboot-spl.lds | 6 +- board/ti/am335x/u-boot.lds | 9 +++-- board/vpac270/u-boot-spl.lds | 9 +++-- 26 files changed, 148 insertions(+), 38 deletions(-) diff --git a/arch/arm/cpu/arm1136/u-boot-spl.lds b/arch/arm/cpu/arm1136/u-boot-spl.lds index bccde73..0299902 100644 --- a/arch/arm/cpu/arm1136/u-boot-spl.lds +++ b/arch/arm/cpu/arm1136/u-boot-spl.lds @@ -33,7 +33,11 @@ SECTIONS .data : { *(SORT_BY_ALIGNMENT(.data*)) } >.sram . = ALIGN(4); __image_copy_end = .; - _end = .; + + .end : + { + *(.__end) + } .bss : { diff --git a/arch/arm/cpu/arm920t/ep93xx/u-boot.lds b/arch/arm/cpu/arm920t/ep93xx/u-boot.lds index 4bed4fc..9699404 100644 --- a/arch/arm/cpu/arm920t/ep93xx/u-boot.lds +++ b/arch/arm/cpu/arm920t/ep93xx/u-boot.lds @@ -50,5 +50,8 @@ SECTIONS .bss : { *(.bss*) } __bss_end = .; - _end = .; + .end : + { + *(.__end) + } } diff --git a/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds b/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds index 80fb9bd..d0b482d 100644 --- a/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds +++ b/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds @@ -49,9 +49,14 @@ SECTIONS __bss_end = .; } - _end = .; + .end : + { + *(.__end) + } + + _image_binary_end = .; - .dynsym _end : { *(.dynsym) } + .dynsym _image_binary_end : { *(.dynsym) } .dynbss : { *(.dynbss) } .dynstr : { *(.dynstr*) } .dynamic : { *(.dynamic*) } diff --git a/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds b/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds index 76b499d..b6d0f65 100644 --- a/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds +++ b/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds @@ -49,9 +49,14 @@ SECTIONS __bss_end = .; } - _end = .; + .end : + { + *(.__end) + } + + _image_binary_end = .; - .dynsym _end : { *(.dynsym) } + .dynsym _image_binary_end : { *(.dynsym) } .dynbss : { *(.dynbss) } .dynstr : { *(.dynstr*) } .dynamic : { *(.dynamic*) } diff --git a/arch/arm/cpu/armv7/am33xx/u-boot-spl.lds b/arch/arm/cpu/armv7/am33xx/u-boot-spl.lds index 9302856..b1c28c9 100644 --- a/arch/arm/cpu/armv7/am33xx/u-boot-spl.lds +++ b/arch/arm/cpu/armv7/am33xx/u-boot-spl.lds @@ -38,7 +38,11 @@ SECTIONS . = ALIGN(4); __image_copy_end = .; - _end = .; + + .end : + { + *(.__end) + } >.sram .bss : { diff --git a/arch/arm/cpu/armv7/omap-common/u-boot-spl.lds b/arch/arm/cpu/armv7/omap-common/u-boot-spl.lds index 02aa129..745603d 100644 --- a/arch/arm/cpu/armv7/omap-common/u-boot-spl.lds +++ b/arch/arm/cpu/armv7/omap-common/u-boot-spl.lds @@ -39,7 +39,11 @@ SECTIONS . = ALIGN(4); __image_copy_end = .; - _end = .; + + .end : + { + *(.__end) + } .bss : { diff --git a/arch/arm/cpu/armv7/socfpga/u-boot-spl.lds b/arch/arm/cpu/armv7/socfpga/u-boot-spl.lds index a7c9c9d..4282beb 100644 --- a/arch/
[U-Boot] [PATCH v5 3/3] arm: remove unneeded symbol offsets and _TEXT_BASE
Remove the last uses of symbol offsets in ARM U-Boot. Remove some needless uses of _TEXT_BASE. Remove all _TEXT_BASE definitions. Signed-off-by: Albert ARIBAUD --- Changes in v5: None Changes in v4: - removed mkexynosspl patch, already fixed in 0fcac1ab Changes in v3: None Changes in v2: - fixed use of _rel_dyn_end instead of _end README | 6 -- arch/arm/cpu/arm1136/start.S| 27 --- arch/arm/cpu/arm1176/start.S| 27 --- arch/arm/cpu/arm720t/start.S| 26 -- arch/arm/cpu/arm920t/start.S| 26 -- arch/arm/cpu/arm926ejs/at91/lowlevel_init.S | 14 +- arch/arm/cpu/arm926ejs/mxs/start.S | 27 --- arch/arm/cpu/arm926ejs/start.S | 27 --- arch/arm/cpu/arm946es/start.S | 26 -- arch/arm/cpu/arm_intcm/start.S | 26 -- arch/arm/cpu/armv7/omap3/lowlevel_init.S| 3 --- arch/arm/cpu/armv7/start.S | 23 --- arch/arm/cpu/ixp/start.S| 26 -- arch/arm/cpu/pxa/start.S| 27 --- arch/arm/cpu/sa1100/start.S | 26 -- arch/arm/lib/board.c| 12 ++-- board/armltd/integrator/lowlevel_init.S | 2 +- board/cm4008/flash.c| 2 +- board/cm41xx/flash.c| 2 +- board/mpl/vcma9/lowlevel_init.S | 5 + board/samsung/goni/lowlevel_init.S | 3 --- board/samsung/smdk2410/lowlevel_init.S | 5 + board/samsung/smdk5250/lowlevel_init.S | 5 + board/samsung/smdkc100/lowlevel_init.S | 3 --- board/ti/omap5912osk/lowlevel_init.S| 4 common/board_f.c| 14 +++--- common/board_r.c| 4 ++-- include/asm-generic/sections.h | 26 +++--- 28 files changed, 25 insertions(+), 399 deletions(-) diff --git a/README b/README index 176de61..405b550 100644 --- a/README +++ b/README @@ -3699,12 +3699,6 @@ Configuration Settings: its config.mk file). If you find problems enabling this option on your board please report the problem and send patches! -- CONFIG_SYS_SYM_OFFSETS - This is set by architectures that use offsets for link symbols - instead of absolute values. So bss_start is obtained using an - offset _bss_start_ofs from CONFIG_SYS_TEXT_BASE, rather than - directly. You should not need to touch this setting. - - CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC (OMAP only) This is set by OMAP boards for the max time that reset should be asserted. See doc/README.omap-reset-time for details on how diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S index 00d1b30..3e2358e 100644 --- a/arch/arm/cpu/arm1136/start.S +++ b/arch/arm/cpu/arm1136/start.S @@ -70,32 +70,6 @@ _end_vect: * */ -.globl _TEXT_BASE -_TEXT_BASE: -#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_TEXT_BASE) - .word CONFIG_SPL_TEXT_BASE -#else - .word CONFIG_SYS_TEXT_BASE -#endif - -/* - * These are defined in the board-specific linker script. - * Subtracting _start from them lets the linker put their - * relative position in the executable instead of leaving - * them null. - */ -.globl _bss_start_ofs -_bss_start_ofs: - .word __bss_start - _start - -.globl _bss_end_ofs -_bss_end_ofs: - .word __bss_end - _start - -.globl _end_ofs -_end_ofs: - .word _end - _start - #ifdef CONFIG_USE_IRQ /* IRQ stack memory (calculated at run-time) */ .globl IRQ_STACK_START @@ -295,7 +269,6 @@ cpu_init_crit: #ifdef CONFIG_SPL_BUILD .align 5 do_hang: - ldr sp, _TEXT_BASE /* use 32 words about stack */ bl hang/* hang and never return */ #else /* !CONFIG_SPL_BUILD */ .align 5 diff --git a/arch/arm/cpu/arm1176/start.S b/arch/arm/cpu/arm1176/start.S index ffd7dd0..ce62011 100644 --- a/arch/arm/cpu/arm1176/start.S +++ b/arch/arm/cpu/arm1176/start.S @@ -77,33 +77,6 @@ _end_vect: * */ -.globl _TEXT_BASE -_TEXT_BASE: -#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_TEXT_BASE) - .word CONFIG_SPL_TEXT_BASE -#else - .word CONFIG_SYS_TEXT_BASE -#endif - -/* - * These are defined in the board-specific linker script. - * Subtracting _start from them lets the linker put their - * relative position in the executable instead of leaving - * them null. - */ - -.globl _bss_start_ofs -_bss_start_ofs: -
[U-Boot] [PATCH v5 1/3] cm_t335: fix linker file to produce full ELF
Newly added cm_t335 was missed in commit 47ed5dd0 which made ARM targets produce full ELF files. Fix its linker script. This change is binary-invariant when only .dynsym, .dynstr, .dynamic, .plt, .interp and .gun sections are declared. Sections .hash, .got.plt, .dynbss and .ARM.exidx are also declared so that their (unused) content is moved out of the u-boot binary. Signed-off-by: Albert ARIBAUD --- Changes in v5: None Changes in v4: None Changes in v3: - fixed cm_t335 linker script Changes in v2: None board/compulab/cm_t335/u-boot.lds | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/board/compulab/cm_t335/u-boot.lds b/board/compulab/cm_t335/u-boot.lds index 1b609a2..d25c19a 100644 --- a/board/compulab/cm_t335/u-boot.lds +++ b/board/compulab/cm_t335/u-boot.lds @@ -92,10 +92,14 @@ SECTIONS KEEP(*(.__bss_end)); } - /DISCARD/ : { *(.dynsym) } - /DISCARD/ : { *(.dynstr*) } - /DISCARD/ : { *(.dynamic*) } - /DISCARD/ : { *(.plt*) } - /DISCARD/ : { *(.interp*) } - /DISCARD/ : { *(.gnu*) } + .dynsym _end : { *(.dynsym) } + .hash : { *(.hash) } + .got.plt : { *(.got.plt) } + .dynbss : { *(.dynbss) } + .dynstr : { *(.dynstr*) } + .dynamic : { *(.dynamic*) } + .plt : { *(.plt*) } + .interp : { *(.interp*) } + .gnu : { *(.gnu*) } + .ARM.exidx : { *(.ARM.exidx*) } } -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] powerpc/t1040qds: Add Video - HDMI support
T1040 has internal display interface unit (DIU) for driving video. T1040QDS supports video mode via -LCD using TI enconder -HDMI type interface via HDMI encoder Chrontel, CH7301C encoder which is I2C programmable is used as HDMI connector on T1040QDS. This patch add support to -enable Video interface for T1040QDS -route qixis multiplexing to enable DIU-HDMI interface on board -program DIU pixel clock gerenartor for T1040 -program HDMI encoder via I2C on board Signed-off-by: Priyanka Jain --- board/freescale/t1040qds/Makefile |1 + board/freescale/t1040qds/diu.c| 168 + board/freescale/t1040qds/t1040qds.h |1 + board/freescale/t1040qds/t1040qds_qixis.h | 12 ++ include/configs/T1040QDS.h| 27 +- 5 files changed, 208 insertions(+), 1 deletions(-) create mode 100644 board/freescale/t1040qds/diu.c diff --git a/board/freescale/t1040qds/Makefile b/board/freescale/t1040qds/Makefile index c7470d7..19ed21b 100644 --- a/board/freescale/t1040qds/Makefile +++ b/board/freescale/t1040qds/Makefile @@ -10,3 +10,4 @@ obj-$(CONFIG_PCI) += pci.o obj-y += law.o obj-y += tlb.o obj-y += eth.o +obj-y += diu.o diff --git a/board/freescale/t1040qds/diu.c b/board/freescale/t1040qds/diu.c new file mode 100644 index 000..b785aa3 --- /dev/null +++ b/board/freescale/t1040qds/diu.c @@ -0,0 +1,168 @@ +/* + * Copyright 2014 Freescale Semiconductor, Inc. + * Author: Priyanka Jain + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include +#include +#include +#include +#include +#include +#include "../common/qixis.h" +#include "t1040qds.h" +#include "t1040qds_qixis.h" + + +#define I2C_DVI_INPUT_DATA_FORMAT_REG 0x1F +#define I2C_DVI_PLL_CHARGE_CNTL_REG0x33 +#define I2C_DVI_PLL_DIVIDER_REG0x34 +#define I2C_DVI_PLL_SUPPLY_CNTL_REG0x35 +#define I2C_DVI_PLL_FILTER_REG 0x36 +#define I2C_DVI_TEST_PATTERN_REG 0x48 +#define I2C_DVI_POWER_MGMT_REG 0x49 +#define I2C_DVI_LOCK_STATE_REG 0x4D +#define I2C_DVI_SYNC_POLARITY_REG 0x56 + +/* + * Set VSYNC/HSYNC to active high. This is polarity of sync signals + * from DIU->DVI. The DIU default is active igh, so DVI is set to + * active high. + */ +#define I2C_DVI_INPUT_DATA_FORMAT_VAL 0x98 + +#define I2C_DVI_PLL_CHARGE_CNTL_HIGH_SPEED_VAL 0x06 +#define I2C_DVI_PLL_DIVIDER_HIGH_SPEED_VAL 0x26 +#define I2C_DVI_PLL_FILTER_HIGH_SPEED_VAL 0xA0 +#define I2C_DVI_PLL_CHARGE_CNTL_LOW_SPEED_VAL 0x08 +#define I2C_DVI_PLL_DIVIDER_LOW_SPEED_VAL 0x16 +#define I2C_DVI_PLL_FILTER_LOW_SPEED_VAL 0x60 + +/* Clear test pattern */ +#define I2C_DVI_TEST_PATTERN_VAL 0x18 +/* Exit Power-down mode */ +#define I2C_DVI_POWER_MGMT_VAL 0xC0 + +/* Monitor polarity is handled via DVI Sync Polarity Register */ +#define I2C_DVI_SYNC_POLARITY_VAL 0x00 + +/* + * DIU Area Descriptor + * + * Note that we need to byte-swap the value before it's written to the AD + * register. So even though the registers don't look like they're in the same + * bit positions as they are on the MPC8610, the same value is written to the + * AD register on the MPC8610 and on the P1022. + */ +#define AD_BYTE_F 0x1000 +#define AD_ALPHA_C_SHIFT 25 +#define AD_BLUE_C_SHIFT23 +#define AD_GREEN_C_SHIFT 21 +#define AD_RED_C_SHIFT 19 +#define AD_PIXEL_S_SHIFT 16 +#define AD_COMP_3_SHIFT12 +#define AD_COMP_2_SHIFT8 +#define AD_COMP_1_SHIFT4 +#define AD_COMP_0_SHIFT0 + +/* Programming of HDMI Chrontel CH7301 connector */ +void diu_set_dvi_encoder(unsigned int pixclock) +{ + int ret; + u8 temp; + select_i2c_ch_pca9547(I2C_MUX_CH_DIU); + + temp = I2C_DVI_TEST_PATTERN_VAL; + ret = i2c_write(CONFIG_SYS_I2C_DVI_ADDR, I2C_DVI_TEST_PATTERN_REG, 1, + &temp, 1); + temp = I2C_DVI_INPUT_DATA_FORMAT_VAL; + ret = i2c_write(CONFIG_SYS_I2C_DVI_ADDR, I2C_DVI_INPUT_DATA_FORMAT_REG, + 1, &temp, 1); + + /* Set Sync polarity register */ + temp = I2C_DVI_SYNC_POLARITY_VAL; + ret = i2c_write(CONFIG_SYS_I2C_DVI_ADDR, I2C_DVI_SYNC_POLARITY_REG, 1, + &temp, 1); + + /* Set PLL registers based on pixel clock rate*/ + if (pixclock > 6500) { + temp = I2C_DVI_PLL_CHARGE_CNTL_HIGH_SPEED_VAL; + ret = i2c_write(CONFIG_SYS_I2C_DVI_ADDR, + I2C_DVI_PLL_CHARGE_CNTL_REG, 1, &temp, 1); + temp = I2C_DVI_PLL_DIVIDER_HIGH_SPEED_VAL; + ret = i2c_write(CONFIG_SYS_I2C_DVI_ADDR, + I2C_DVI_PLL_DIVIDER_REG, 1, &temp, 1); + temp = I2C_DVI_PLL_FILTER_HIGH_SPEED_VAL; + ret = i2c_write(CONFIG_SYS
[U-Boot] [PATCH 1/2] powerpc/mpc85xx: Add SCFG_PIXCLKCR register support for T1040
T1040 SoC has SCFG (Supplement Configuration) Block which provides chip specific configuration and status support. The base address of SCFG block in T1040 is 0xfc000. SCFG contains SCFG_PIXCLKCR (DIU pixel clock control register) at offset 0x28. Add definition of -SCFG block -SCFG_PIXCLKCR register -Bits definition of SCFG_PIXCLK register Signed-off-by: Priyanka Jain --- arch/powerpc/include/asm/immap_85xx.h |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/include/asm/immap_85xx.h b/arch/powerpc/include/asm/immap_85xx.h index 9d08321..0251265 100644 --- a/arch/powerpc/include/asm/immap_85xx.h +++ b/arch/powerpc/include/asm/immap_85xx.h @@ -1770,6 +1770,10 @@ defined(CONFIG_PPC_T1020) || defined(CONFIG_PPC_T1022) #define FSL_CORENET_RCWSR13_MAC2_GMII_SEL 0x0080 #define FSL_CORENET_RCWSR13_MAC2_GMII_SEL_L2_SWITCH0x #define FSL_CORENET_RCWSR13_MAC2_GMII_SEL_ENET_PORT0x8000 +#define CONFIG_SYS_FSL_SCFG_PIXCLKCR_OFFSET0x28 +#define PXCKEN_MASK0x8000 +#define PXCK_MASK 0x00FF +#define PXCK_BITS_START16 #elif defined(CONFIG_PPC_T2080) || defined(CONFIG_PPC_T2081) #define FSL_CORENET2_RCWSR4_SRDS1_PRTCL0xff00 #define FSL_CORENET2_RCWSR4_SRDS1_PRTCL_SHIFT 24 @@ -2845,6 +2849,7 @@ struct ccsr_pman { #define CONFIG_SYS_FSL_CORENET_SERDES_OFFSET 0xEA000 #define CONFIG_SYS_FSL_CORENET_SERDES2_OFFSET 0xEB000 #define CONFIG_SYS_FSL_CPC_OFFSET 0x1 +#define CONFIG_SYS_FSL_SCFG_OFFSET 0xFC000 #define CONFIG_SYS_MPC85xx_DMA1_OFFSET 0x10 #define CONFIG_SYS_MPC85xx_DMA2_OFFSET 0x101000 #define CONFIG_SYS_MPC85xx_DMA3_OFFSET 0x102000 @@ -2962,6 +2967,10 @@ struct ccsr_pman { #define CONFIG_SYS_FSL_CPC_ADDR\ (CONFIG_SYS_CCSRBAR + CONFIG_SYS_FSL_CPC_OFFSET) +#define CONFIG_SYS_FSL_SCFG_ADDR \ + (CONFIG_SYS_CCSRBAR + CONFIG_SYS_FSL_SCFG_OFFSET) +#define CONFIG_SYS_FSL_SCFG_PIXCLK_ADDR\ + (CONFIG_SYS_FSL_SCFG_ADDR + CONFIG_SYS_FSL_SCFG_PIXCLKCR_OFFSET) #define CONFIG_SYS_FSL_QMAN_ADDR \ (CONFIG_SYS_IMMR + CONFIG_SYS_FSL_QMAN_OFFSET) #define CONFIG_SYS_FSL_BMAN_ADDR \ -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Link
Can someone provide me link to download uboot-production source code?? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Link
Hi 2014-01-30 JYOTI DUBEY : > Can someone provide me link to download uboot-production source code?? > The git web interface can be found here: http://git.denx.de/?p=u-boot.git;a=summary But it is as simple as this: git clone git://git.denx.de/u-boot.git greets -- Christian Gmeiner, MSc ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/3] arm: make _end compiler-generated
Hi Albert, On Thursday, January 30, 2014 11:02:46 AM, Albert ARIBAUD wrote: > This prevents references to _end from generating absolute > relocation records. > > This change is binary invariant for ARM targets. > > Signed-off-by: Albert ARIBAUD > --- > > Changes in v5: > - Rebase onto u-boot-arm/master > > Changes in v4: None > Changes in v3: > - Replace _end in linker scripts with _image_binary_end > > Changes in v2: None [...] > diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds > index 4da5d24..f61ef50 100644 > --- a/arch/arm/cpu/u-boot.lds > +++ b/arch/arm/cpu/u-boot.lds > @@ -60,7 +60,12 @@ SECTIONS > *(.__rel_dyn_end) > } > > - _end = .; > + .end : > + { > + *(.__end) > + } > + > + _image_binary_end = .; > > /* >* Deprecated: this MMU section is used by pxa at present but > @@ -91,7 +96,9 @@ SECTIONS > KEEP(*(.__bss_end)); > } > > - .dynsym _end : { *(.dynsym) } > + .dynsym _image_binary_end : { *(.dynsym) } > + .hash : { *(.hash) } > + .got.plt : { *(.got.plt) } Are the two additions above intentional? These lines were present in the context in v4, but not as an addition. They are also unrelated to the topic of this patch. > .dynbss : { *(.dynbss) } > .dynstr : { *(.dynstr*) } > .dynamic : { *(.dynamic*) } [...] Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Porting U-boot
On 30 January 2014 06:58, JYOTI DUBEY wrote: > After compiling the u-boot code what steps must be followed to boot the > current system (system with Grub) with u-boot?I mean how can I port my > system with the u-boot which I compiled? What system do you have? It depends on your system, obviously. You need to place u-boot wherever your system bios looks for a bootloader. Alternatively, you can try loading u-boot from grub for testing. HTH Michal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/9] arc: add architecture header files
Hello Wolfgang, On Wed, 2014-01-29 at 20:54 +0100, Wolfgang Denk wrote: > Dear Alexey Brodkin, > > In message <1391011745-22239-2-git-send-email-abrod...@synopsys.com> you > wrote: > > These are header files used by ARC700 architecture. > ... > > +/* Build Configuration Registers */ > > +#define ARC_REG_DCCMBASE_BCR 0x61/* DCCM Base Addr */ > > +#define ARC_REG_CRC_BCR0x62 > > +#define ARC_REG_DVFB_BCR 0x64 > > +#define ARC_REG_EXTARITH_BCR 0x65 > > +#define ARC_REG_VECBASE_BCR0x68 > > +#define ARC_REG_PERIBASE_BCR 0x69 > > +#define ARC_REG_FP_BCR 0x6B/* Single-Precision FPU */ > > +#define ARC_REG_DPFP_BCR 0x6C/* Dbl Precision FPU */ > > +#define ARC_REG_DCCM_BCR 0x74/* DCCM Present + SZ */ > > +#define ARC_REG_TIMERS_BCR 0x75 > > +#define ARC_REG_ICCM_BCR 0x78 > > +#define ARC_REG_XY_MEM_BCR 0x79 > > +#define ARC_REG_MAC_BCR0x7a > > +#define ARC_REG_MUL_BCR0x7b > > +#define ARC_REG_SWAP_BCR 0x7c > > +#define ARC_REG_NORM_BCR 0x7d > > +#define ARC_REG_MIXMAX_BCR 0x7e > > +#define ARC_REG_BARREL_BCR 0x7f > > +#define ARC_REG_D_UNCACH_BCR 0x6A > > Are you sure that this should not become a C struct declaration? This > looks much like offsets, and we so not allow a base address + offset > notation for device I/O ... > > > +/* status32 Bits Positions */ > > +#define STATUS_AE_BIT 5 /* Exception active */ > > +#define STATUS_DE_BIT 6 /* PC is in delay slot */ > > +#define STATUS_U_BIT 7 /* User/Kernel mode */ > > +#define STATUS_L_BIT 12 /* Loop inhibit */ > > Please uses masks instead of bit numbers. Bitfields are inherently > non-portable and dangerous. > > > +/* These masks correspond to the status word(STATUS_32) bits */ > > +#define STATUS_AE_MASK (1< > +#define STATUS_DE_MASK (1< > +#define STATUS_U_MASK (1< > +#define STATUS_L_MASK (1< > As the STATUS_??_BIT defiens should not be used anywhere else, you > might drop them without loss of readability. > > > +/* > > + ** > > + * Inline ASM macros to read/write AUX Regs > > + * Essentially invocation of lr/sr insns from "C" > > + */ > > Can we drop this "***" line? > > > +#if 1 > > + > > +#define read_aux_reg(reg) __builtin_arc_lr(reg) > > + > > +/* gcc builtin sr needs reg param to be long immediate */ > > +#define write_aux_reg(reg_immed, val) \ > > + __builtin_arc_sr((unsigned int)val, reg_immed) > > + > > +#else > > + > > +#define read_aux_reg(reg) \ > ... > > +#endif > > This pretty long else branch is just dead code. Please get rid of all > such "#if 1" or "#if 0" blocks in your code, globally. > > > +#define READ_BCR(reg, into)\ > > +{ \ > > + unsigned int tmp; \ > > + tmp = read_aux_reg(reg);\ > > + if (sizeof(tmp) == sizeof(into)) { \ > > + into = *((typeof(into) *)&tmp); \ > > + } else {\ > > + extern void bogus_undefined(void); \ > > + bogus_undefined(); \ > > + } \ > > +} > > + > > +#define WRITE_BCR(reg, into) \ > > +{ \ > > + unsigned int tmp; \ > > + if (sizeof(tmp) == sizeof(into)) { \ > > + tmp = (*(unsigned int *)(into));\ > > + write_aux_reg(reg, tmp);\ > > + } else { \ > > + extern void bogus_undefined(void); \ > > + bogus_undefined(); \ > > + } \ > > +} > > Do we really need this? No other architecture does anything like > that. Can you not just use standard I/O accessors? > > > +/* Helpers */ > > +#define TO_KB(bytes) ((bytes) >> 10) > > +#define TO_MB(bytes) (TO_KB(bytes) >> 10) > > +#define PAGES_TO_KB(n_pages) ((n_pages) << (PAGE_SHIFT - 10)) > > +#define PAGES_TO_MB(n_pages) (PAGES_TO_KB(n_pages) >> 10) > > Please drop these. The just make the code harder to read. > > > +struct bcr_identity { > > +#ifdef CONFIG_CPU_BIG_ENDIAN > > + unsigned int chip_id:16, cpu_id:8, family:8; > > +#else > > + unsigned int family:8, cpu_id:8, chip_id:16; > > +#endif > > +}; As it is clearly mentioned in commit message "arcregs.h" came from Linux sources and that's why kept as it was. You may refer to it here - https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arc/include/asm/arcregs.h?id=v3.11 So I'm wonde
Re: [U-Boot] [PATCH v2 7/9] arc: add AXS101 board support
Hello Wolfgang, On Wed, 2014-01-29 at 21:09 +0100, Wolfgang Denk wrote: > Dear Alexey Brodkin, > > In message <1391011745-22239-8-git-send-email-abrod...@synopsys.com> you > wrote: > > AXS101 is a new generation of devlopment boards from Synopsys that houses > > ASIC with ARC700 and lots of DesignWare peripherals: > > > > +#defineCONFIG_HOSTNAME axs101 > > +#defineCONFIG_ETHADDR 4a:56:49:22:3e:43 > > +#defineCONFIG_IPADDR 10.121.8.200 > > +#defineCONFIG_SERVERIP 10.121.8.31 > > +#defineCONFIG_GATEWAYIP10.121.8.1 > > +#defineCONFIG_NETMASK 255.255.255.0 > > We do not allow any such fixed network parameters in the board config > headers. I see tons of boards do have these parameters set in "include/configs/xxx". I may indeed remove them in from my board but why keep it in others? So people won't be confused any longer. Regards, Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Commit 3865ceb7 breaks vexpress_aemv8a build with warnings
Hello, I have just noticed that vexpress_aemv8a seems broken with v2014.01, using gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9). The symptom is a lot of warnings like smc9_eeprom.c: In function 'dump_reg': /home/albert/src/u-boot-arm/include/../drivers/net/smc9.h:261:28: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] #define SMC_outw(a,d,r) (*((volatile word *)((a)->iobase+(r))) = d) ^ /home/albert/src/u-boot-arm/include/../drivers/net/smc9.h:747:33: note: in expansion of macro 'SMC_outw' #define SMC_SELECT_BANK(a,x) { SMC_outw((a), (x), BANK_SELECT ); } A rough search shows that the issue originates in commit 3865ceb7 ("vexpress/armv8: Fix incorrect ethernet controller") submitted by Bhupesh Sharma and committed by Tom Rini, both Cc:ed. Bupesh, can you investigate? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Commit 3865ceb7 breaks vexpress_aemv8a build with warnings
> -Original Message- > From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net] > Sent: Thursday, January 30, 2014 8:06 PM > To: U-Boot > Cc: Sharma Bhupesh-B45370; Tom Rini > Subject: Commit 3865ceb7 breaks vexpress_aemv8a build with warnings > > Hello, > > I have just noticed that vexpress_aemv8a seems broken with v2014.01, > using gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9). > > The symptom is a lot of warnings like > > smc9_eeprom.c: In function 'dump_reg': > /home/albert/src/u-boot-arm/include/../drivers/net/smc9.h:261:28: > warning: cast to pointer from integer of different size [-Wint-to- > pointer-cast] #define SMC_outw(a,d,r) (*((volatile word > *)((a)->iobase+(r))) = d) > ^ /home/albert/src/u-boot-arm/include/../drivers/net/smc9.h:747:33: > note: in expansion of macro 'SMC_outw' #define SMC_SELECT_BANK(a,x) { > SMC_outw((a), (x), BANK_SELECT ); } > > A rough search shows that the issue originates in commit 3865ceb7 > ("vexpress/armv8: Fix incorrect ethernet controller") submitted by > Bhupesh Sharma and committed by Tom Rini, both Cc:ed. > > Bupesh, can you investigate? > I did post a reply to a mail on similar lines before: http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/178502 I did not get much time to look into the same. Let me try the same tomorrow. Regards, Bhupesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/9] arc: add cpu files
Hello Wolfgang, On Wed, 2014-01-29 at 21:06 +0100, Wolfgang Denk wrote: > Dear Alexey Brodkin, > > In message <1391011745-22239-3-git-send-email-abrod...@synopsys.com> you > wrote: > > Signed-off-by: Alexey Brodkin > > > > Cc: Mischa Jonker > > Cc: Francois Bedard > > > > No changes for v2. > > This belongs into the comment section (below the "---" line), not into > the commit message. Good point, will fix next time. > > --- > ... > > +int icache_status(void) > > +{ > > + return (read_aux_reg(ARC_REG_IC_CTRL) & IC_CTRL_CACHE_DISABLE) != > > + IC_CTRL_CACHE_DISABLE; > > +} > > + > > +void icache_enable(void) > > +{ > > + write_aux_reg(ARC_REG_IC_CTRL, read_aux_reg(ARC_REG_IC_CTRL) & > > + ~IC_CTRL_CACHE_DISABLE); > > +} > > > I missed this in patch # 1 - why do you need these read_aux_reg() / > write_aux_reg() macros? Why cannot you use standard I/O accessors > instead? This is already answered by Mischa. > > +/* STATUS32 register bits related to Interrupt Handling */ > > +#define STATUS_E1_BIT 1 /* Int 1 enable */ > > +#define STATUS_E2_BIT 2 /* Int 2 enable */ > > +#define STATUS_A1_BIT 3 /* Int 1 active */ > > +#define STATUS_A2_BIT 4 /* Int 2 active */ > > + > > +#define STATUS_E1_MASK (1< > +#define STATUS_E2_MASK (1< > +#define STATUS_A1_MASK (1< > +#define STATUS_A2_MASK (1< > See before. As I answered in comments for the first patch - most of STATUS_xx_BITs are defined in "arcregs.h" which is a copy of kernel's one. In kernel sources for some reason A1, A2, E1 and E2 bits are defined in separate header "irqflags.h" which as a whole substance we don't need in U-Boot. So I defined these flags in "arch/arc/cpu/arc700/interrupts.c" and did it in the same manner as they are in "arcregs.h". Moreover it is expected that these mask defines all look the same way STATUS_xx_MASK by handy macro: #define STS_BIT(r, bit) r->status32 & STATUS_##bit##_MASK ? #bit : "" So we may easily access each and every status bit. Also IMHO it's good to keep the same defines in both Linux kernel and in U-Boot so reader familiar with Linux for ARC understands what happens in U-Boot and vise versa. That's my motivation here. > > +int disable_interrupts(void) > > +{ > > + int status = read_aux_reg(ARC_REG_STATUS32); > > + int state = (status | STATUS_E1_MASK | STATUS_E2_MASK) ? 1 : 0; > > + status &= ~(STATUS_E1_MASK | STATUS_E2_MASK); > > + __asm__("flag %0" : : "r" (status)); > > + return state; > > +} > > Please insert blankk line between declarations and code. Please fix > globally. > > > +void enable_interrupts(void) > > +{ > > + unsigned int status = read_aux_reg(ARC_REG_STATUS32); > > + status |= STATUS_E1_MASK | STATUS_E2_MASK; > > + __asm__("flag %0" : : "r" (status)); > > +} > > + > > +/* > > + * Common routine to print scratch regs (r0-r12) or callee regs (r13-r25) > > + * -Prints 3 regs per line and a CR. > > Comment and code disagree: You print "\n", not "\r" ! Agree, so I'll remove entire comment before function and put small comments within function itself - IMHO will be easier to understand a logic. Regards, Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] mx6: Enable L2 cache support
Am 29.01.2014 20:39, schrieb Fabio Estevam: From: Fabio Estevam Add L2 cache support and enable it by default. Configure the L2 cache in the same way as done by FSL kernel: http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/mach-mx6/mm.c?h=imx_3.0.35_4.1.0 Signed-off-by: Fabio Estevam Acked-by: Dirk Behme Thanks Dirk --- Changes since v3: - Enable l2 cache using the same method as the kernel Changes since v2: - Add L2_PL310_BASE definition in imx_regs.h Changes since v1: - Fx typo in commit log arch/arm/cpu/armv7/mx6/soc.c | 58 arch/arm/include/asm/arch-mx6/imx-regs.h | 1 + arch/arm/include/asm/pl310.h | 21 include/configs/mx6_common.h | 5 +++ 4 files changed, 85 insertions(+) diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c index 0208cba..396bba5 100644 --- a/arch/arm/cpu/armv7/mx6/soc.c +++ b/arch/arm/cpu/armv7/mx6/soc.c @@ -8,6 +8,8 @@ */ #include +#include +#include #include #include #include @@ -336,3 +338,59 @@ void imx_setup_hdmi(void) writel(reg, &mxc_ccm->chsccdr); } #endif + +#ifndef CONFIG_SYS_L2CACHE_OFF +#define IOMUXC_GPR11_L2CACHE_AS_OCRAM 0x0002 +void v7_outer_cache_enable(void) +{ + struct pl310_regs *const pl310 = (struct pl310_regs *)L2_PL310_BASE; + unsigned int val; + +#if defined CONFIG_MX6SL + struct iomuxc *iomux = (struct iomuxc *)IOMUXC_BASE_ADDR; + val = readl(&iomux->gpr[11]); + if (val & IOMUXC_GPR11_L2CACHE_AS_OCRAM) { + /* L2 cache configured as OCRAM, reset it */ + val &= ~IOMUXC_GPR11_L2CACHE_AS_OCRAM; + writel(val, &iomux->gpr[11]); + } +#endif + + writel(0x132, &pl310->pl310_tag_latency_ctrl); + writel(0x132, &pl310->pl310_data_latency_ctrl); + + val = readl(&pl310->pl310_prefetch_ctrl); + + /* Turn on the L2 I/D prefetch */ + val |= 0x3000; + + /* +* The L2 cache controller(PL310) version on the i.MX6D/Q is r3p1-50rel0 +* The L2 cache controller(PL310) version on the i.MX6DL/SOLO/SL is r3p2 +* But according to ARM PL310 errata: 752271 +* ID: 752271: Double linefill feature can cause data corruption +* Fault Status: Present in: r3p0, r3p1, r3p1-50rel0. Fixed in r3p2 +* Workaround: The only workaround to this erratum is to disable the +* double linefill feature. This is the default behavior. +*/ + +#ifndef CONFIG_MX6Q + val |= 0x4080; +#endif + writel(val, &pl310->pl310_prefetch_ctrl); + + val = readl(&pl310->pl310_power_ctrl); + val |= L2X0_DYNAMIC_CLK_GATING_EN; + val |= L2X0_STNDBY_MODE_EN; + writel(val, &pl310->pl310_power_ctrl); + + setbits_le32(&pl310->pl310_ctrl, L2X0_CTRL_EN); +} + +void v7_outer_cache_disable(void) +{ + struct pl310_regs *const pl310 = (struct pl310_regs *)L2_PL310_BASE; + + clrbits_le32(&pl310->pl310_ctrl, L2X0_CTRL_EN); +} +#endif /* !CONFIG_SYS_L2CACHE_OFF */ diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h b/arch/arm/include/asm/arch-mx6/imx-regs.h index f2ad6e9..c2d210a 100644 --- a/arch/arm/include/asm/arch-mx6/imx-regs.h +++ b/arch/arm/include/asm/arch-mx6/imx-regs.h @@ -53,6 +53,7 @@ #define GLOBAL_TIMER_BASE_ADDR 0x00A00200 #define PRIVATE_TIMERS_WD_BASE_ADDR 0x00A00600 #define IC_DISTRIBUTOR_BASE_ADDR0x00A01000 +#define L2_PL310_BASE 0x00A02000 #define GPV0_BASE_ADDR 0x00B0 #define GPV1_BASE_ADDR 0x00C0 #define PCIE_ARB_BASE_ADDR 0x0100 diff --git a/arch/arm/include/asm/pl310.h b/arch/arm/include/asm/pl310.h index f41ad8c..d4526af 100644 --- a/arch/arm/include/asm/pl310.h +++ b/arch/arm/include/asm/pl310.h @@ -12,6 +12,9 @@ /* Register bit fields */ #define PL310_AUX_CTRL_ASSOCIATIVITY_MASK (1 << 16) +#define L2X0_DYNAMIC_CLK_GATING_EN (1 << 1) +#define L2X0_STNDBY_MODE_EN(1 << 0) +#define L2X0_CTRL_EN 1 struct pl310_regs { u32 pl310_cache_id; @@ -47,6 +50,24 @@ struct pl310_regs { u32 pad9[1]; u32 pl310_clean_inv_line_idx; u32 pl310_clean_inv_way; + u32 pad10[64]; + u32 pl310_lockdown_dbase; + u32 pl310_lockdown_ibase; + u32 pad11[190]; + u32 pl310_addr_filter_start; + u32 pl310_addr_filter_end; + u32 pad12[190]; + u32 pl310_test_operation; + u32 pad13[3]; + u32 pl310_line_data; + u32 pad14[7]; + u32 pl310_line_tag; + u32 pad15[3]; + u32 pl310_debug_ctrl; + u32 pad16[7]; + u32 pl310_prefetch_ctrl; + u32 pad17[7]; + u32 pl310_power_ctrl; }; void pl310_inval_all(void); diff --git a/include/configs/mx6_common.h b/include/configs/mx6_common.h index 514d634..eb107d3 100644 --- a/include/configs/
Re: [U-Boot] [PATCH v4] mx6: Enable L2 cache support
Hi Fabio, On 29/01/2014 20:39, Fabio Estevam wrote: > From: Fabio Estevam > > Add L2 cache support and enable it by default. > > Configure the L2 cache in the same way as done by FSL kernel: > http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/mach-mx6/mm.c?h=imx_3.0.35_4.1.0 > > Signed-off-by: Fabio Estevam > --- > Changes since v3: > - Enable l2 cache using the same method as the kernel > Changes since v2: > - Add L2_PL310_BASE definition in imx_regs.h > Changes since v1: > - Fx typo in commit log > > arch/arm/cpu/armv7/mx6/soc.c | 58 > > arch/arm/include/asm/arch-mx6/imx-regs.h | 1 + > arch/arm/include/asm/pl310.h | 21 > include/configs/mx6_common.h | 5 +++ > 4 files changed, 85 insertions(+) > > diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c > index 0208cba..396bba5 100644 > --- a/arch/arm/cpu/armv7/mx6/soc.c > +++ b/arch/arm/cpu/armv7/mx6/soc.c > @@ -8,6 +8,8 @@ > */ > > #include > +#include > +#include > #include > #include > #include > @@ -336,3 +338,59 @@ void imx_setup_hdmi(void) > writel(reg, &mxc_ccm->chsccdr); > } > #endif > + > +#ifndef CONFIG_SYS_L2CACHE_OFF > +#define IOMUXC_GPR11_L2CACHE_AS_OCRAM 0x0002 > +void v7_outer_cache_enable(void) > +{ > + struct pl310_regs *const pl310 = (struct pl310_regs *)L2_PL310_BASE; > + unsigned int val; > + > +#if defined CONFIG_MX6SL > + struct iomuxc *iomux = (struct iomuxc *)IOMUXC_BASE_ADDR; > + val = readl(&iomux->gpr[11]); > + if (val & IOMUXC_GPR11_L2CACHE_AS_OCRAM) { > + /* L2 cache configured as OCRAM, reset it */ > + val &= ~IOMUXC_GPR11_L2CACHE_AS_OCRAM; > + writel(val, &iomux->gpr[11]); > + } > +#endif > + > + writel(0x132, &pl310->pl310_tag_latency_ctrl); > + writel(0x132, &pl310->pl310_data_latency_ctrl); > + > + val = readl(&pl310->pl310_prefetch_ctrl); > + > + /* Turn on the L2 I/D prefetch */ > + val |= 0x3000; > + > + /* > + * The L2 cache controller(PL310) version on the i.MX6D/Q is r3p1-50rel0 > + * The L2 cache controller(PL310) version on the i.MX6DL/SOLO/SL is r3p2 > + * But according to ARM PL310 errata: 752271 > + * ID: 752271: Double linefill feature can cause data corruption > + * Fault Status: Present in: r3p0, r3p1, r3p1-50rel0. Fixed in r3p2 > + * Workaround: The only workaround to this erratum is to disable the > + * double linefill feature. This is the default behavior. > + */ > + > +#ifndef CONFIG_MX6Q > + val |= 0x4080; > +#endif > + writel(val, &pl310->pl310_prefetch_ctrl); > + > + val = readl(&pl310->pl310_power_ctrl); > + val |= L2X0_DYNAMIC_CLK_GATING_EN; > + val |= L2X0_STNDBY_MODE_EN; > + writel(val, &pl310->pl310_power_ctrl); > + > + setbits_le32(&pl310->pl310_ctrl, L2X0_CTRL_EN); > +} > + > +void v7_outer_cache_disable(void) > +{ > + struct pl310_regs *const pl310 = (struct pl310_regs *)L2_PL310_BASE; > + > + clrbits_le32(&pl310->pl310_ctrl, L2X0_CTRL_EN); > +} > +#endif /* !CONFIG_SYS_L2CACHE_OFF */ > diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h > b/arch/arm/include/asm/arch-mx6/imx-regs.h > index f2ad6e9..c2d210a 100644 > --- a/arch/arm/include/asm/arch-mx6/imx-regs.h > +++ b/arch/arm/include/asm/arch-mx6/imx-regs.h > @@ -53,6 +53,7 @@ > #define GLOBAL_TIMER_BASE_ADDR 0x00A00200 > #define PRIVATE_TIMERS_WD_BASE_ADDR 0x00A00600 > #define IC_DISTRIBUTOR_BASE_ADDR0x00A01000 > +#define L2_PL310_BASE0x00A02000 > #define GPV0_BASE_ADDR 0x00B0 > #define GPV1_BASE_ADDR 0x00C0 > #define PCIE_ARB_BASE_ADDR 0x0100 > diff --git a/arch/arm/include/asm/pl310.h b/arch/arm/include/asm/pl310.h > index f41ad8c..d4526af 100644 > --- a/arch/arm/include/asm/pl310.h > +++ b/arch/arm/include/asm/pl310.h > @@ -12,6 +12,9 @@ > > /* Register bit fields */ > #define PL310_AUX_CTRL_ASSOCIATIVITY_MASK(1 << 16) > +#define L2X0_DYNAMIC_CLK_GATING_EN (1 << 1) > +#define L2X0_STNDBY_MODE_EN (1 << 0) > +#define L2X0_CTRL_EN 1 > > struct pl310_regs { > u32 pl310_cache_id; > @@ -47,6 +50,24 @@ struct pl310_regs { > u32 pad9[1]; > u32 pl310_clean_inv_line_idx; > u32 pl310_clean_inv_way; > + u32 pad10[64]; > + u32 pl310_lockdown_dbase; > + u32 pl310_lockdown_ibase; > + u32 pad11[190]; > + u32 pl310_addr_filter_start; > + u32 pl310_addr_filter_end; > + u32 pad12[190]; > + u32 pl310_test_operation; > + u32 pad13[3]; > + u32 pl310_line_data; > + u32 pad14[7]; > + u32 pl310_line_tag; > + u32 pad15[3]; > + u32 pl310_debug_ctrl; > + u32 pad16[7]; > + u32 pl310_prefetch_ctrl; > + u32 pad17[7]; > + u32 pl310_power_ctrl; > }; > > void pl310_inval_al
Re: [U-Boot] Commit 3865ceb7 breaks vexpress_aemv8a build with warnings
Hi bhupesh.sha...@freescale.com, On Thu, 30 Jan 2014 14:44:49 +, "bhupesh.sha...@freescale.com" wrote: > > -Original Message- > > From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net] > > Sent: Thursday, January 30, 2014 8:06 PM > > To: U-Boot > > Cc: Sharma Bhupesh-B45370; Tom Rini > > Subject: Commit 3865ceb7 breaks vexpress_aemv8a build with warnings > > > > Hello, > > > > I have just noticed that vexpress_aemv8a seems broken with v2014.01, > > using gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9). > > > > The symptom is a lot of warnings like > > > > smc9_eeprom.c: In function 'dump_reg': > > /home/albert/src/u-boot-arm/include/../drivers/net/smc9.h:261:28: > > warning: cast to pointer from integer of different size [-Wint-to- > > pointer-cast] #define SMC_outw(a,d,r) (*((volatile word > > *)((a)->iobase+(r))) = d) > > ^ /home/albert/src/u-boot-arm/include/../drivers/net/smc9.h:747:33: > > note: in expansion of macro 'SMC_outw' #define SMC_SELECT_BANK(a,x) { > > SMC_outw((a), (x), BANK_SELECT ); } > > > > A rough search shows that the issue originates in commit 3865ceb7 > > ("vexpress/armv8: Fix incorrect ethernet controller") submitted by > > Bhupesh Sharma and committed by Tom Rini, both Cc:ed. > > > > Bupesh, can you investigate? > > > > I did post a reply to a mail on similar lines before: > http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/178502 Sorry, I'd missed it. > I did not get much time to look into the same. > Let me try the same tomorrow. Ok. > Regards, > Bhupesh Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/9] kmp204x: I2C deblocking for I2C-bus1 added
On 01/30/2014 01:17 AM, Boschung, Rainer wrote: > On 01/30/2014 08:32 AM, Valentin Longchamp wrote: >> On 01/30/2014 03:30 AM, York Sun wrote: >>> On 01/27/2014 02:49 AM, Valentin Longchamp wrote: From: Rainer Boschung -uses common deblocking algorithm from ../common/common.c >>> >>> I don't see any algorithm in the common.c file. >> >> The file is board/keymile/common/common.c, where the i2c_make_abort() and the >> i2c_write_start_seq() functions are defined. I guess that's what Rainer >> means with "algorithm". > > That is what I meant. I will add a more precise comment. >> Please send v3 for this patch only, or an incremental patch. I will swap/squash the patch. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] tlb15_entry is set wrong in the 4K code when the MPC8572DS boots from nand flash
Hello, The memory of the MPC8572DS can't be read correctly after the setup of the tlb1_entry in the 4K boot code. And also in the create_init_ram code, the tlb1_entry15&14 are set to be in the address space 0 which are supposed to be used in the address space 1. There seems somthing wrong with the writing of the TLB entry. But I don't know why. Do anyone know the reason? Thank you very much. Y.Fan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] at91 gpio: fix typo in compatibility macro
It's called _pio_ in the version that was added to git. Apparently it got renamed without updating the macros before it was applied, c.f. http://u-boot.10912.n7.nabble.com/U-Boot-PATCH-3-9-V3-add-a-new-AT91-GPIO-driver-td75922.html Signed-off-by: Andreas Henriksson --- arch/arm/include/asm/arch-at91/gpio.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/include/asm/arch-at91/gpio.h b/arch/arm/include/asm/arch-at91/gpio.h index ff6142b..7121388 100644 --- a/arch/arm/include/asm/arch-at91/gpio.h +++ b/arch/arm/include/asm/arch-at91/gpio.h @@ -214,7 +214,7 @@ static inline unsigned pin_to_mask(unsigned pin) /* The following macros are need for backward compatibility */ #define at91_set_GPIO_periph(x, y) \ - at91_set_gpio_periph((x - PIN_BASE) / 32,(x % 32), y) + at91_set_pio_periph((x - PIN_BASE) / 32,(x % 32), y) #define at91_set_A_periph(x, y) \ at91_set_a_periph((x - PIN_BASE) / 32,(x % 32), y) #define at91_set_B_periph(x, y) \ -- 1.5.4.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/usb: Workaround for erratum-A006261
On Thu, 2014-01-30 at 10:42 +0530, Suresh Gupta wrote: > +#ifdef CONFIG_SYS_FSL_ERRATUM_A006261 > +static inline bool has_erratum_a006261(void) > +{ > + u32 svr = get_svr(); > + u32 soc = SVR_SOC_VER(svr); > + > + switch (soc) { > + case SVR_P1010: > + return IS_SVR_REV(svr, 1, 0) || IS_SVR_REV(svr, 2, 0); > + case SVR_P2041: > + return IS_SVR_REV(svr, 1, 0) || > + IS_SVR_REV(svr, 1, 1) || IS_SVR_REV(svr, 2, 1); > + case SVR_P3041: > + return IS_SVR_REV(svr, 1, 0) || > + IS_SVR_REV(svr, 1, 1) || > + IS_SVR_REV(svr, 2, 0) || IS_SVR_REV(svr, 2, 1); > + case SVR_P5020: > + return IS_SVR_REV(svr, 1, 0) || IS_SVR_REV(svr, 2, 0); > + case SVR_T4240: > + case SVR_T4160: > + return IS_SVR_REV(svr, 1, 0) || IS_SVR_REV(svr, 2, 0); > + case SVR_T1040: > + return IS_SVR_REV(svr, 1, 0); > + case SVR_P5040: > + return IS_SVR_REV(svr, 1, 0); > + } P2040? P5010? P5021? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/8] omap5_uevm: Add CONFIG_SUPPORT_EMMC_BOOT, document usage
Add a README to the board which lists the commands required to enable booting from the eMMC boot partitions found on the board. Signed-off-by: Tom Rini --- board/ti/omap5_uevm/README | 25 + include/configs/omap5_uevm.h |1 + 2 files changed, 26 insertions(+) create mode 100644 board/ti/omap5_uevm/README diff --git a/board/ti/omap5_uevm/README b/board/ti/omap5_uevm/README new file mode 100644 index 000..970e2ec --- /dev/null +++ b/board/ti/omap5_uevm/README @@ -0,0 +1,25 @@ +Summary +=== + +This document covers various features of the 'omap5_uevm' build and some +related uses. + +eMMC boot partition use +=== + +It is possible, depending on SYSBOOT configuration to boot from the eMMC +boot partitions using (name depending on documentation referenced) +Alternative Boot operation mode or Boot Sequence Option 1/2. In this +example we load MLO and u-boot.img from the build into DDR and then use +'mmc bootbus' to set the required rate (see TRM) and 'mmc partconfig' to +set boot0 as the boot device. +U-Boot # setenv autoload no +U-Boot # usb start +U-Boot # dhcp +U-Boot # mmc dev 1 1 +U-Boot # tftp ${loadaddr} omap5uevm/MLO +U-Boot # mmc write ${loadaddr} 0 100 +U-Boot # tftp ${loadaddr} omap5uevm/u-boot.img +U-Boot # mmc write ${loadaddr} 300 400 +U-Boot # mmc bootbus 1 2 0 2 +U-Boot # mmc partconf 1 1 1 0 diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h index 76c5106..3df502e 100644 --- a/include/configs/omap5_uevm.h +++ b/include/configs/omap5_uevm.h @@ -37,6 +37,7 @@ #define CONFIG_PARTITION_UUIDS #define CONFIG_CMD_PART #define CONFIG_HSMMC2_8BIT +#define CONFIG_SUPPORT_EMMC_BOOT /* Required support for the TCA642X GPIO we have on the uEVM */ #define CONFIG_TCA642X -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 5/8] cmd_mmc.c: Rename 'bootpart' to 'bootpart-resize'
Rename 'bootpart' to 'bootpart-resize' to better reflect what this command is for. Signed-off-by: Tom Rini --- common/cmd_mmc.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c index e118252..a322063 100644 --- a/common/cmd_mmc.c +++ b/common/cmd_mmc.c @@ -312,9 +312,9 @@ static int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) /* acknowledge to be sent during boot operation */ return boot_part_access(mmc, 1, part_num, access); - } else if (strcmp(argv[1], "bootpart") == 0) { + } else if (strcmp(argv[1], "bootpart-resize") == 0) { int dev; - struct *mmc; + struct mmc *mmc; u32 bootsize, rpmbsize; if (argc == 5) { @@ -449,8 +449,8 @@ U_BOOT_CMD( " - Enable boot_part for booting and enable R/W access of boot_part\n" "mmc close \n" " - Enable boot_part for booting and disable access to boot_part\n" - "mmc bootpart \n" - " - change sizes of boot and RPMB partitions of specified device\n" + "mmc bootpart-resize \n" + " - Change sizes of boot and RPMB partitions of specified device\n" #endif "mmc setdsr - set DSR register value\n" ); -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/8] SPL: Add CONFIG_SUPPORT_EMMC_BOOT support to CONFIG_SPL_FRAMEWORK
We use the switch CONFIG_SUPPORT_EMMC_BOOT today to enable some additional features of the eMMC boot partitions. Add support for being told that we have booted from one of these partitions to the spl framework and implement this on TI OMAP/related. Cc: Pantelis Antoniou Signed-off-by: Tom Rini --- arch/arm/cpu/armv7/omap-common/boot-common.c |8 +++- common/spl/spl_mmc.c | 24 include/spl.h|1 + 3 files changed, 32 insertions(+), 1 deletion(-) diff --git a/arch/arm/cpu/armv7/omap-common/boot-common.c b/arch/arm/cpu/armv7/omap-common/boot-common.c index 69fff32..ec0f936 100644 --- a/arch/arm/cpu/armv7/omap-common/boot-common.c +++ b/arch/arm/cpu/armv7/omap-common/boot-common.c @@ -66,7 +66,13 @@ u32 spl_boot_device(void) u32 spl_boot_mode(void) { - return gd->arch.omap_boot_params.omap_bootmode; + u32 val = gd->arch.omap_boot_params.omap_bootmode; + +#ifdef CONFIG_SUPPORT_EMMC_BOOT + if (val == 0) + val = MMCSD_MODE_EMMCBOOT; +#endif + return val; } void spl_board_init(void) diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c index 13fbff0..fa6f891 100644 --- a/common/spl/spl_mmc.c +++ b/common/spl/spl_mmc.c @@ -111,6 +111,30 @@ void spl_mmc_load_image(void) CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION, CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME); #endif +#ifdef CONFIG_SUPPORT_EMMC_BOOT + } else if (boot_mode == MMCSD_MODE_EMMCBOOT) { + /* +* We need to check what the partition is configured to. +* 1 and 2 match up to boot0 / boot1 and 7 is user data +* which is the first physical partition (0). +*/ + int part = (mmc->part_config >> 3) & PART_ACCESS_MASK; + + if (part == 7) + part = 0; + + if (mmc_switch_part(0, part)) { +#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT + puts("MMC partition switch failed\n"); +#endif + hang(); + } +#ifdef CONFIG_SPL_OS_BOOT + if (spl_start_uboot() || mmc_load_image_raw_os(mmc)) +#endif + err = mmc_load_image_raw(mmc, + CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR); +#endif } else { #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT puts("spl: wrong MMC boot mode\n"); diff --git a/include/spl.h b/include/spl.h index 5e24856..dad00c0 100644 --- a/include/spl.h +++ b/include/spl.h @@ -16,6 +16,7 @@ #define MMCSD_MODE_UNDEFINED 0 #define MMCSD_MODE_RAW 1 #define MMCSD_MODE_FAT 2 +#define MMCSD_MODE_EMMCBOOT3 struct spl_image_info { const char *name; -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 8/8] cmd_mmc.c: Drop open/close mmc sub-commands
The open and close mmc sub-commands implement a hard-coded set of values specific to the SMDK5250 platform. Remove these commands as what they did can be done instead with a series of mmc dev / bootpart / bootbus commands instead now. Cc: Amar Cc: Minkyu Kang Cc: Jaehoon Chung Signed-off-by: Tom Rini --- common/cmd_mmc.c | 72 - drivers/mmc/mmc.c | 65 --- include/mmc.h |2 -- 3 files changed, 139 deletions(-) diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c index a028149..2d51927 100644 --- a/common/cmd_mmc.c +++ b/common/cmd_mmc.c @@ -131,36 +131,6 @@ U_BOOT_CMD( "- display info of the current MMC device" ); -#ifdef CONFIG_SUPPORT_EMMC_BOOT -static int boot_part_access(struct mmc *mmc, u8 ack, u8 part_num, u8 access) -{ - int err; - err = mmc_boot_part_access(mmc, ack, part_num, access); - - if ((err == 0) && (access != 0)) { - printf("\t\t\t!!!Notice!!!\n"); - - printf("!You must close EMMC boot Partition"); - printf("after all images are written\n"); - - printf("!EMMC boot partition has continuity"); - printf("at image writing time.\n"); - - printf("!So, do not close the boot partition"); - printf("before all images are written.\n"); - return 0; - } else if ((err == 0) && (access == 0)) - return 0; - else if ((err != 0) && (access != 0)) { - printf("EMMC boot partition-%d OPEN Failed.\n", part_num); - return 1; - } else { - printf("EMMC boot partition-%d CLOSE Failed.\n", part_num); - return 1; - } -} -#endif - static int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) { enum mmc_state state; @@ -273,44 +243,6 @@ static int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) return 0; #ifdef CONFIG_SUPPORT_EMMC_BOOT - } else if ((strcmp(argv[1], "open") == 0) || - (strcmp(argv[1], "close") == 0)) { - int dev; - struct mmc *mmc; - u8 part_num, access = 0; - - if (argc == 4) { - dev = simple_strtoul(argv[2], NULL, 10); - part_num = simple_strtoul(argv[3], NULL, 10); - } else { - return CMD_RET_USAGE; - } - - mmc = find_mmc_device(dev); - if (!mmc) { - printf("no mmc device at slot %x\n", dev); - return 1; - } - - if (IS_SD(mmc)) { - printf("SD device cannot be opened/closed\n"); - return 1; - } - - if ((part_num <= 0) || (part_num > MMC_NUM_BOOT_PARTITION)) { - printf("Invalid boot partition number:\n"); - printf("Boot partition number cannot be <= 0\n"); - printf("EMMC44 supports only 2 boot partitions\n"); - return 1; - } - - if (strcmp(argv[1], "open") == 0) - access = part_num; /* enable R/W access to boot part*/ - else - access = 0; /* No access to boot partition */ - - /* acknowledge to be sent during boot operation */ - return boot_part_access(mmc, 1, part_num, access); } else if (strcmp(argv[1], "partconf") == 0) { int dev; struct mmc *mmc; @@ -498,10 +430,6 @@ U_BOOT_CMD( "mmc dev [dev] [part] - show or set current mmc device [partition]\n" "mmc list - lists available devices\n" #ifdef CONFIG_SUPPORT_EMMC_BOOT - "mmc open \n" - " - Enable boot_part for booting and enable R/W access of boot_part\n" - "mmc close \n" - " - Enable boot_part for booting and disable access to boot_part\n" "mmc bootbus dev boot_bus_width reset_boot_bus_width boot_mode\n" " - Set the BOOT_BUS_WIDTH field of the specified device\n" "mmc bootpart-resize \n" diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index fc1c1dc..3a57ab8 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -1442,71 +1442,6 @@ int mmc_boot_partition_size_change(struct mmc *mmc, unsigned long bootsize, } /* - * This function shall form and send the commands to open / close the - * boot partition specified by user. - * - * Input Parameters: - * ack: 0x0 - No boot acknowledge sent (default) - * 0x1 - Boot acknowledge sent during boot operation - * part_num: User selects boot data that will be sent to master - * 0x0 - Device not boot enabled (default) - * 0x1 - Boot partition 1 enabled for boot - * 0x2 - Boot partition 2 enabled for boot - * access: User selects par
[U-Boot] [PATCH v2 4/8] cmd_mmc.c: Change 'bootpart' code to match normal coding style
Signed-off-by: Tom Rini --- common/cmd_mmc.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c index da5fef9..e118252 100644 --- a/common/cmd_mmc.c +++ b/common/cmd_mmc.c @@ -314,11 +314,18 @@ static int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) } else if (strcmp(argv[1], "bootpart") == 0) { int dev; - dev = simple_strtoul(argv[2], NULL, 10); + struct *mmc; + u32 bootsize, rpmbsize; - u32 bootsize = simple_strtoul(argv[3], NULL, 10); - u32 rpmbsize = simple_strtoul(argv[4], NULL, 10); - struct mmc *mmc = find_mmc_device(dev); + if (argc == 5) { + dev = simple_strtoul(argv[2], NULL, 10); + bootsize = simple_strtoul(argv[3], NULL, 10); + rpmbsize = simple_strtoul(argv[4], NULL, 10); + } else { + return CMD_RET_USAGE; + } + + mmc = find_mmc_device(dev); if (!mmc) { printf("no mmc device at slot %x\n", dev); return 1; -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 6/8] cmd_mmc.c: Add 'partconf' command to mmc
Add a partconf sub-command to the mmc command to allow for setting the boot_ack, boot_partition and partition_access fields of PARTITION_CONFIG (formerly BOOT_CONFIG, EXT_CSD[179]). Part of this requires changing the check for 'part' from an strncmp to a strcmp, like the rest of the sub-commands. Cc: Andy Fleming Cc: Pantelis Antoniou Signed-off-by: Tom Rini --- common/cmd_mmc.c | 30 +- drivers/mmc/mmc.c | 21 + include/mmc.h |2 ++ 3 files changed, 52 insertions(+), 1 deletion(-) diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c index a322063..5842e85 100644 --- a/common/cmd_mmc.c +++ b/common/cmd_mmc.c @@ -195,7 +195,7 @@ static int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) return 1; else return 0; - } else if (strncmp(argv[1], "part", 4) == 0) { + } else if (strcmp(argv[1], "part") == 0) { block_dev_desc_t *mmc_dev; struct mmc *mmc; @@ -311,7 +311,33 @@ static int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) /* acknowledge to be sent during boot operation */ return boot_part_access(mmc, 1, part_num, access); + } else if (strcmp(argv[1], "partconf") == 0) { + int dev; + struct mmc *mmc; + u8 ack, part_num, access; + + if (argc == 6) { + dev = simple_strtoul(argv[2], NULL, 10); + ack = simple_strtoul(argv[3], NULL, 10); + part_num = simple_strtoul(argv[4], NULL, 10); + access = simple_strtoul(argv[5], NULL, 10); + } else { + return CMD_RET_USAGE; + } + + mmc = find_mmc_device(dev); + if (!mmc) { + printf("no mmc device at slot %x\n", dev); + return 1; + } + if (IS_SD(mmc)) { + puts("PARTITION_CONFIG only exists on eMMC\n"); + return 1; + } + + /* acknowledge to be sent during boot operation */ + return mmc_set_part_conf(mmc, ack, part_num, access); } else if (strcmp(argv[1], "bootpart-resize") == 0) { int dev; struct mmc *mmc; @@ -451,6 +477,8 @@ U_BOOT_CMD( " - Enable boot_part for booting and disable access to boot_part\n" "mmc bootpart-resize \n" " - Change sizes of boot and RPMB partitions of specified device\n" + "mmc partconf dev boot_ack boot_partition partition_access\n" + " - Change the bits of the PARTITION_CONFIG field of the specified device\n" #endif "mmc setdsr - set DSR register value\n" ); diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index c6a1c23..1591fce 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -1505,4 +1505,25 @@ int mmc_boot_part_access(struct mmc *mmc, u8 ack, u8 part_num, u8 access) } return 0; } + +/* + * Modify EXT_CSD[179] which is PARTITION_CONFIG (formerly BOOT_CONFIG) + * based on the passed in values for BOOT_ACK, BOOT_PARTITION_ENABLE and + * PARTITION_ACCESS. + * + * Returns 0 on success. + */ +int mmc_set_part_conf(struct mmc *mmc, u8 ack, u8 part_num, u8 access) +{ + int err; + + err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_PART_CONF, +EXT_CSD_BOOT_ACK(ack) | +EXT_CSD_BOOT_PART_NUM(part_num) | +EXT_CSD_PARTITION_ACCESS(access)); + + if (err) + return err; + return 0; +} #endif diff --git a/include/mmc.h b/include/mmc.h index e1060b9..7e026da 100644 --- a/include/mmc.h +++ b/include/mmc.h @@ -312,6 +312,8 @@ int mmc_boot_partition_size_change(struct mmc *mmc, unsigned long bootsize, unsigned long rpmbsize); /* Function to send commands to open/close the specified boot partition */ int mmc_boot_part_access(struct mmc *mmc, u8 ack, u8 part_num, u8 access); +/* Function to modify the PARTITION_CONFIG field of EXT_CSD */ +int mmc_set_part_conf(struct mmc *mmc, u8 ack, u8 part_num, u8 access); /** * Start device initialization and return immediately; it does not block on -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/8] dra7xx_evm: Add CONFIG_SUPPORT_EMMC_BOOT, document usage
Add a README to the board which lists the commands required to enable booting from the eMMC boot partitions found on the board. Cc: Lokesh Vutla Signed-off-by: Tom Rini --- board/ti/dra7xx/README | 25 + include/configs/dra7xx_evm.h |2 ++ 2 files changed, 27 insertions(+) create mode 100644 board/ti/dra7xx/README diff --git a/board/ti/dra7xx/README b/board/ti/dra7xx/README new file mode 100644 index 000..2fdaeac --- /dev/null +++ b/board/ti/dra7xx/README @@ -0,0 +1,25 @@ +Summary +=== + +This document covers various features of the 'dra7xx_evm' build and some +related uses. + +eMMC boot partition use +=== + +It is possible, depending on SYSBOOT configuration to boot from the eMMC +boot partitions using (name depending on documentation referenced) +Alternative Boot operation mode or Boot Sequence Option 1/2. In this +example we load MLO and u-boot.img from the build into DDR and then use +'mmc bootbus' to set the required rate (see TRM) and 'mmc partconfig' to +set boot0 as the boot device. +U-Boot # setenv autoload no +U-Boot # usb start +U-Boot # dhcp +U-Boot # mmc dev 1 1 +U-Boot # tftp ${loadaddr} dra7xx/MLO +U-Boot # mmc write ${loadaddr} 0 100 +U-Boot # tftp ${loadaddr} dra7xx/u-boot.img +U-Boot # mmc write ${loadaddr} 300 400 +U-Boot # mmc bootbus 1 2 0 2 +U-Boot # mmc partconf 1 1 1 0 diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h index f210ed8..3c53f0a 100644 --- a/include/configs/dra7xx_evm.h +++ b/include/configs/dra7xx_evm.h @@ -73,6 +73,8 @@ #define CONFIG_SPL_SPI_CS 0 #define CONFIG_SYS_SPI_U_BOOT_OFFS 0x2 +#define CONFIG_SUPPORT_EMMC_BOOT + /* USB xHCI HOST */ #define CONFIG_CMD_USB #define CONFIG_USB_HOST -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 7/8] cmd_mmc.c: Add bootbus mmc sub-command
Add a bootbus sub-command to the mmc command to allow for setting the boot_bus_width, reset_boot_bus_width and boot_mode fields of BOOT_BUS_WIDTH (EXT_CSD[177]). Signed-off-by: Tom Rini --- common/cmd_mmc.c | 29 + drivers/mmc/mmc.c | 21 + include/mmc.h |5 + 3 files changed, 55 insertions(+) diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c index 5842e85..a028149 100644 --- a/common/cmd_mmc.c +++ b/common/cmd_mmc.c @@ -338,6 +338,33 @@ static int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) /* acknowledge to be sent during boot operation */ return mmc_set_part_conf(mmc, ack, part_num, access); + } else if (strcmp(argv[1], "bootbus") == 0) { + int dev; + struct mmc *mmc; + u8 width, reset, mode; + + if (argc == 6) { + dev = simple_strtoul(argv[2], NULL, 10); + width = simple_strtoul(argv[3], NULL, 10); + reset = simple_strtoul(argv[4], NULL, 10); + mode = simple_strtoul(argv[5], NULL, 10); + } else { + return CMD_RET_USAGE; + } + + mmc = find_mmc_device(dev); + if (!mmc) { + printf("no mmc device at slot %x\n", dev); + return 1; + } + + if (IS_SD(mmc)) { + puts("BOOT_BUS_WIDTH only exists on eMMC\n"); + return 1; + } + + /* acknowledge to be sent during boot operation */ + return mmc_set_boot_bus_width(mmc, width, reset, mode); } else if (strcmp(argv[1], "bootpart-resize") == 0) { int dev; struct mmc *mmc; @@ -475,6 +502,8 @@ U_BOOT_CMD( " - Enable boot_part for booting and enable R/W access of boot_part\n" "mmc close \n" " - Enable boot_part for booting and disable access to boot_part\n" + "mmc bootbus dev boot_bus_width reset_boot_bus_width boot_mode\n" + " - Set the BOOT_BUS_WIDTH field of the specified device\n" "mmc bootpart-resize \n" " - Change sizes of boot and RPMB partitions of specified device\n" "mmc partconf dev boot_ack boot_partition partition_access\n" diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index 1591fce..fc1c1dc 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -1507,6 +1507,27 @@ int mmc_boot_part_access(struct mmc *mmc, u8 ack, u8 part_num, u8 access) } /* + * Modify EXT_CSD[177] which is BOOT_BUS_WIDTH + * based on the passed in values for BOOT_BUS_WIDTH, RESET_BOOT_BUS_WIDTH + * and BOOT_MODE. + * + * Returns 0 on success. + */ +int mmc_set_boot_bus_width(struct mmc *mmc, u8 width, u8 reset, u8 mode) +{ + int err; + + err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_BOOT_BUS_WIDTH, +EXT_CSD_BOOT_BUS_WIDTH_MODE(mode) | +EXT_CSD_BOOT_BUS_WIDTH_RESET(reset) | +EXT_CSD_BOOT_BUS_WIDTH_WIDTH(width)); + + if (err) + return err; + return 0; +} + +/* * Modify EXT_CSD[179] which is PARTITION_CONFIG (formerly BOOT_CONFIG) * based on the passed in values for BOOT_ACK, BOOT_PARTITION_ENABLE and * PARTITION_ACCESS. diff --git a/include/mmc.h b/include/mmc.h index 7e026da..3594286 100644 --- a/include/mmc.h +++ b/include/mmc.h @@ -187,6 +187,9 @@ #define EXT_CSD_BOOT_PART_NUM(x) (x << 3) #define EXT_CSD_PARTITION_ACCESS(x)(x << 0) +#define EXT_CSD_BOOT_BUS_WIDTH_MODE(x) (x << 3) +#define EXT_CSD_BOOT_BUS_WIDTH_RESET(x)(x << 2) +#define EXT_CSD_BOOT_BUS_WIDTH_WIDTH(x)(x) #define R1_ILLEGAL_COMMAND (1 << 22) #define R1_APP_CMD (1 << 5) @@ -314,6 +317,8 @@ int mmc_boot_partition_size_change(struct mmc *mmc, unsigned long bootsize, int mmc_boot_part_access(struct mmc *mmc, u8 ack, u8 part_num, u8 access); /* Function to modify the PARTITION_CONFIG field of EXT_CSD */ int mmc_set_part_conf(struct mmc *mmc, u8 ack, u8 part_num, u8 access); +/* Function to modify the BOOT_BUS_WIDTH field of EXT_CSD */ +int mmc_set_boot_bus_width(struct mmc *mmc, u8 width, u8 reset, u8 mode); /** * Start device initialization and return immediately; it does not block on -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8 0/38] Switch over to real Kbuild
Dear Masahiro Yamada, On 29.01.14 13:25, Masahiro Yamada wrote: > How to Build ? > -- > > We can build the same as before. > Do board configuraton first and then run "make". > > $ make omap4_panda_config > Configuring for omap4_panda board... > $ make CROSS_COMPILE=arm-linux-gnueabi- > GEN include/autoconf.mk.dep > GEN include/autoconf.mk > CC lib/asm-offsets.s > GEN include/generated/generic-asm-offsets.h > CC arch/arm/cpu/armv7/omap4/asm-offsets.s > GEN include/generated/asm-offsets.h > HOSTCC scripts/basic/fixdep >... > > You will find a difference at a glance: short log. > If you need detail log message, please add "V=1". > (You can also use "V=2") > > Please note we can no longer use > $ make omap4_panda CROSS_COMPILE=arm-linux-gnueabi- > to do board configuration and "make" at the same time. > > Instead, we can use Kbuild-ish way for that purpose: > $ make omap4_panda_config all CROSS_COMPILE=arm-linux-gnuabi- compile test for this setup and a few others run successfully on OS X Lion as build-host. Runtime test on at least one avr32 and one at91 board will follow this weekend. I saw a few times full compiler output instead of the shortened 'CC ...'. Especially generating the linker script, reformatting binaries with objcopy and doing the final linkage of u-boot ELF. Maybe you want to sort that out? Sorry if that was discussed before, haven't followed the whole discussion. Nevertheless, many thanks for your great work! Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] recommended action for bootloaders regarding modifying device-tree nodes
Hi Tim, On Thu, Jan 30, 2014 at 01:11:18AM -0800, Tim Harvey wrote: > My approach has been to define a per-baseboard device-tree in Linux > for a 'fully loaded' board, then remove nodes which the EEPROM claims > are not present in the bootloader before it passes the DTB to the > kernel. I do this by defining aliases in the device-tree for the > peripherals that are 'optional' so that the bootloader itself does not > need to know the details about how the device is connected. This is more of a process question: Is there any information captured in your EEPROM that can't be represented in the dtb? iow, at the point when you write the EEPROM, why not write the dtb to it as configured? You could have pre-configured dtsi fragments for each config option, and then dynamically create the board dts from the order. I only ask because it would solve the problem below. However, there's a lot more to changing a manufacturing process than meets the eye. :) > Is it more appropriate for the bootloader to 'remove' nodes for > devices that are not physically present or should I be setting their > status property to 'disabled' instead? I'm not clear if either option > really has any pros or cons. That depends on how you have it structured. Is it a valid dtb? Meaning, do you have four nodes all at the same register address? Perhaps you could provide an example dts? thx, Jason. > Tim Harvey - Principal Software Engineer > Gateworks Corporation btw - one of my first embedded projects was on one of your boards. An ixp425 with 4 mini-pci slots. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] arch: bcm281xx: Initial commit of bcm281xx architecture code
On 14-01-29 02:32 PM, Tom Rini wrote: > On Mon, Jan 27, 2014 at 10:53:26AM -0800, Darwin Rambo wrote: > >> Add bcm281xx architecture support code including a clock framework and >> chip reset. Define register block base addresses for the bcm281xx >> architecture and create an empty gpio header file required when >> CONFIG_CMD_GPIO is set. > [snip] >> +/* Bitfield operations */ >> + >> +/* Produces a mask of set bits covering a range of a 32-bit value */ >> +static inline u32 bitfield_mask(u32 shift, u32 width) >> +{ >> +return ((1 << width) - 1) << shift; >> +} >> + >> +/* Extract the value of a bitfield found within a given register value */ >> +static inline u32 bitfield_extract(u32 reg_val, u32 shift, u32 width) >> +{ >> +return (reg_val & bitfield_mask(shift, width)) >> shift; >> +} >> + >> +/* Replace the value of a bitfield found within a given register value */ >> +static inline u32 bitfield_replace(u32 reg_val, u32 shift, u32 width, u32 >> val) >> +{ >> +u32 mask = bitfield_mask(shift, width); >> + >> +return (reg_val & ~mask) | (val << shift); >> +} > > This all feels horribly generic, isn't there some linux header we've > already got that I can't think off of the top of my head that gives us > these kind of functions? Hi Tom, I had a similar feeling. There are files such as include/linux/bitops.h and arch/arm/include/asm/bitops.h and a host of others, but these seem single bit oriented, and don't provide the functionality here. The bcm281xx clock registers are a myriad of bit fields of different widths and positions, and the driver code is simpler because it uses these generic bitfield functions and data tables to describe the bitfields. Perhaps the bcm281xx clock register hardware has revealed the need for more functions like this now. I've searched through the tree for equivalent functions and they don't seem to exist, but I could be wrong. We could create include/bitfield.h with functions specifically for bitfield operations if it were warranted. But if it only ever got used by one driver, it might be wrong to make it generic. But my gut feel is that if we did create include/bitfield.h it probably would be used by others who wanted to take a similar data-driven approach to register fields. We would also have to make it non-u32 specific I imagine, possibly just 'int' types. Thanks. Darwin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] recommended action for bootloaders regarding modifying device-tree nodes
On Thu, Jan 30, 2014 at 03:45:58PM -0500, Jason Cooper wrote: > This is more of a process question: Is there any information captured > in your EEPROM that can't be represented in the dtb? iow, at the point > when you write the EEPROM, why not write the dtb to it as configured? I can share what we do here.. In our systems the serial EEPROM is only 256 bytes, so storing things in DT format would be challenging. What we do is have a master DTB that has the union of all our configurations. The boot process has a very simple bit of code that runs down the DTB in binary format and replaces entire OF_DT_BEGIN_NODE->OF_DT_END_NODE regions with OF_DT_NOP. The NOP approach is very simple, no other changes (eg offset recalculation) needs to be done to the DT, so we can do this process with a very small code footprint and without libfdt. Choosing which sections to drop is done with some combination of hardwired code and searching for specific property patterns. There are also a few places where placeholder sections are directly fixed up, eg a mac address is written into a placeholder of 0s, etc. So an example might be optional_peripheral@1 { orc,board-style = <1>; [..] } Eg The board-style number comes from the EEPROM and if board-style != 1 then the entire stanza is replaced with NOP. Jason ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] board: bcm28155_ap: Add board files
On 14-01-29 02:33 PM, Tom Rini wrote: > On Mon, Jan 27, 2014 at 10:53:30AM -0800, Darwin Rambo wrote: > >> Add support for the bcm28155_ap reference board. >> >> Signed-off-by: Darwin Rambo >> Reviewed-by: Steve Rae >> Reviewed-by: Tim Kryger > [snip] >> +gd->ram_size = CONFIG_SYS_SDRAM_SIZE; > > Please use get_ram_size(...); We tried using this on our reference board and it hangs accessing memory regions that are not populated. Our memory controller doesn't appear to properly support accessing regions that are not backed by physical sdram. So I think it's best to keep this code as is and consider this approach for future designs. > >> +/* Memory testing range */ >> +#define CONFIG_SYS_MEMTEST_STARTCONFIG_SYS_SDRAM_BASE >> +#define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_MEMTEST_START + >> SZ_1M) > > Please see doc/README.memory-test OK. I think I'll disable CONFIG_CMD_MEMORY and remove this stuff. > >> +#define CONFIG_SYS_BAUDRATE_TABLE {9600, 19200, 38400, 57600, \ >> +115200, 230400, 460800, 921600} > > Unless you really use those higher values in U-Boot, please use the > default table. OK > >> +#define CONFIG_SYS_PROMPT_HUSH_PS2 "> " > > Unneeded now. OK > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] arch: kona: Initial commit of kona-common architecture code
On 14-01-29 02:32 PM, Tom Rini wrote: > On Mon, Jan 27, 2014 at 10:53:25AM -0800, Darwin Rambo wrote: > >> The Kona architecture is present on a number of Broadcom mobile SoCs >> including the bcm281xx family of chips. > [snip] >> +int __weak clk_sdio_enable(void *base, u32 rate, u32 *actual_ratep) >> +{ >> +return 0; >> +} >> +int __weak clk_bsc_enable(void *base, u32 rate, u32 *actual_ratep) >> +{ >> +return 0; >> +} > > Blank lines between functions please. OK > >> diff --git a/arch/arm/cpu/armv7/kona-common/lowlevel_init.S >> b/arch/arm/cpu/armv7/kona-common/lowlevel_init.S >> new file mode 100644 >> index 000..a03afcc >> --- /dev/null >> +++ b/arch/arm/cpu/armv7/kona-common/lowlevel_init.S >> @@ -0,0 +1,15 @@ >> +/* >> +* >> +* Copyright 2013 Broadcom Corporation. All rights reserved. >> +* >> +* SPDX-License-Identifier: GPL-2.0+ >> +* >> +*/ >> + >> +//#include >> +//#include >> +//#include >> + >> +.globl lowlevel_init >> +lowlevel_init: >> +mov pc, lr > > (a) no commented out include lines OK > (b) This is empty, which seems wrong. I strongly suspect you want to > make use of arch/arm/cpu/armv7/lowlevel_init.S and have an s_init > function, ala omap*/tegra/rmobile/etc. Will check this out. Thanks. > >> diff --git a/arch/arm/cpu/armv7/kona-common/proc.c >> b/arch/arm/cpu/armv7/kona-common/proc.c >> new file mode 100644 >> index 000..92fb39b >> --- /dev/null >> +++ b/arch/arm/cpu/armv7/kona-common/proc.c >> @@ -0,0 +1,20 @@ >> +/* >> +* >> +* Copyright 2013 Broadcom Corporation. All rights reserved. >> +* >> +* SPDX-License-Identifier: GPL-2.0+ >> +* >> +*/ >> + >> +#include >> +#include >> +#include >> +#include >> + >> +void do_proc_wfe(int forever) >> +{ >> +do { >> +asm volatile ("wfe @ wait for event\n"); >> +/*printf("wake up from wfe\n"); */ > > No commented out printf, thanks. > OK ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/9] arc: add architecture header files
Dear Alexey, In message <1391088780.3518.33.ca...@abrodkin-8560l.internal.synopsys.com> you wrote: > > As it is clearly mentioned in commit message "arcregs.h" came from Linux > sources and that's why kept as it was. You may refer to it here - > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arc/include/asm/arcregs.h?id=v3.11 > > So I'm wondering if you insist on fixing all mentioned items in > "arcregs.h" or I may keep it as it is still? This is difficult to impossible for me to decide yet. MY general feeling is that there is an overwhelming amount of code that is completely unused in U-Boot. That should really be dropped. Also, it would help if you could give reasons (I mean, other than "this comes form Linux, so it must be good") why this code should be written as it is. Or, for example, if it is realistic to expect that both BE and LE configurations of your systems will be supported in U-Boot, etc. > Ok, I copy-pasted it from "arch/arm/include/asm/byteorder.h". > And it still has __KERNEL__ - > http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/include/asm/byteor> > der.h;h=20cce7657e1059a170fd5ef32688cb96064fcd7f;hb=HEAD > > Are we going to fix it for existing arches (note all arches except M68K, > PowerPC and SPARC have it in "byteorder.h")? IIRC it might go away in the context of the Kconfig changes. > > > +#define writew(val, addr) ({ __asm__ __volatile__ ("stw.di %0,[%1]" : > > > > :\ > > > + "r" ((val)), "r" ((addr))); }) > > > + > > > +#define writel(val, addr) ({ __asm__ __volatile__ ("st.di %0,[%1]" : :> \ > > > + "r" ((val)), "r" ((addr))); }) > > > + > > > +#define readb(addr) ({unsigned int val = 0; __asm__ __volatile__ \ > > > + ("ldb.di %0,[%1]" : "=&r" ((val)) : "r" ((addr))); val; }) > > > + > > > +#define readw(addr) ({unsigned int val = 0; __asm__ __volatile__ \ > > > + ("ldw.di %0,[%1]" : "=&r" ((val)) : "r" ((addr))); val; }) > > > + > > > +#define readl(addr) ({unsigned int val = 0; __asm__ __volatile__ \ > > > + ("ld.di %0,[%1]" : "=&r" ((val)) : "r"((addr))); val; }) > > > > As far as I can tell there is no type checking for the arguments > > passed here. Can this please be added, so the compiler can catch when > > you for example try to use a writel() on a address that points to char > > only? > > Good suggestion, but I'm wondering if this kind of checks are already > implemented in other arches - may I have a reference? It should be sufficient to use inline functions instead of macros; for example something like extern inline u8 readb(const volatile unsigned char __iomem *addr) { u8 val; __asm__ __volatile__( "ldb.di %0,[%1]" : "=&r" ((val)) : "r" ((addr))); return val; } > > > +/* > > > + * Generic virtual read/write > > > + */ > > > +#define iomem_valid_addr(iomem, sz) (1) > > > +#define iomem_to_phys(iomem) (iomem) > > > + > > > +#ifdef __io > > > +#define outb(v, p) __raw_writeb(v, __io(p)) > > > +#define outw(v, p) __raw_writew(cpu_to_le16(v), __io(p)) > > > +#define outl(v, p) __raw_writel(cpu_to_le32(v), __io(p)) > > > + > > > +#define inb(p) ({ unsigned int __v = __raw_readb(__io(p)); __v; }) > > > +#define inw(p) ({ unsigned int __v = le16_to_cpu(__raw_readw(__io(p)> > > > )); __v; }) > > > +#define inl(p) ({ unsigned int __v = le32_to_cpu(__raw_readl(__io(p)> > > > )); __v; }) > > > + > > > +#define outsb(p, d, l)__raw_writesb(__io(p), d, l) > > > +#define outsw(p, d, l)__raw_writesw(__io(p), d, l) > > > +#define outsl(p, d, l)__raw_writesl(__io(p), d, l) > > > + > > > +#define insb(p, d, l) __raw_readsb(__io(p), d, l) > > > +#define insw(p, d, l) __raw_readsw(__io(p), d, l) > > > +#define insl(p, d, l) __raw_readsl(__io(p), d, l) > > > +#endif > > > + > > > +#define outb_p(val, port) outb((val), (port)) > > > +#define outw_p(val, port) outw((val), (port)) > > > +#define outl_p(val, port) outl((val), (port)) > > > + > > > +#define inb_p(port)inb((port)) > > > +#define inw_p(port)inw((port)) > > > +#define inl_p(port)inl((port)) > > > + > > > +#define outsb_p(port, from, len) outsb(port, from, len) > > > +#define outsw_p(port, from, len) outsw(port, from, len) > > > +#define outsl_p(port, from, len) outsl(port, from, len) > > > + > > > +#define insb_p(port, to, len) insb(port, to, len) > > > +#define insw_p(port, to, len) insw(port, to, len) > > > +#define insl_p(port, to, len) insl(port, to, len) > > > > Do we actually need any of this in U-Boot? > > > > Please clean up and remove unused stuff... > > Well for example "inb"/"outb" is used in "drivers/serial/ns16550.c" and > in many other places. So we need to clean drivers and common files > first. Are you sure all of these are actually used? > > > +/* > > > + * Given a physical address and a length, return a virtual address > >
[U-Boot] [PATCH] mmc: set rca to 1 for MMC cards
From: Stephen Warren U-Boot currently sets MMC cards' RCA register to 0. This value is reserved according to the specification. Use a value of 1 instead, just like the Linux kernel. Signed-off-by: Stephen Warren --- drivers/mmc/mmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index c6a1c23fbf1c..7efc2bedbe11 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -430,7 +430,7 @@ int mmc_complete_op_cond(struct mmc *mmc) mmc->ocr = cmd.response[0]; mmc->high_capacity = ((mmc->ocr & OCR_HCS) == OCR_HCS); - mmc->rca = 0; + mmc->rca = 1; return 0; } -- 1.8.1.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] Introducing the Broadcom bcm281xx Architecture
On 14-01-29 02:32 PM, Tom Rini wrote: > On Mon, Jan 27, 2014 at 10:53:24AM -0800, Darwin Rambo wrote: > >> This patchset introduces the Broadcom bcm281xx family of mobile SoC >> chips. Broadcom kona hardware blocks are often found in Broadcom mobile >> SoC chips including the bcm281xx family, so support for some of these >> kona blocks is also provided here. These patches work on u-boot master >> as well as the u-boot-arm custodian tree. >> >> Darwin Rambo (6): >> arch: kona: Initial commit of kona-common architecture code >> arch: bcm281xx: Initial commit of bcm281xx architecture code >> gpio: kona: Add Kona gpio driver >> i2c: kona: Add Kona I2C driver >> mmc: kona: Add Kona mmc driver >> board: bcm28155_ap: Add board files > > Thanks for posting. Globally, please don't introduce another style for > the file header, > /* > * This works > * just fine. > * > * Including what the file is about > */ OK - legacy stuff will be fixed. > > And I also see the incorrect style sprinkled throughout. > > I saw some '#define' mixed in with '#define', and some other > things I'd have sworn checkpatch complains about, so please make sure > things are checkpatch clean (except for very long printed strings, which > are an exception to line length rules). Well, checkpatch was clean, so I think there's a problem with the tool. Another minor gripe is that checkpatch and "indent -linux" don't agree on everything, "int * foo" being one of them. :) > > Finally, please CC the custodians for i2c/mmc for those drivers as they > may have further comments than the above list. OK. There are mmc, i2c and gpio drivers. I assume each driver gets a different CC:? > > Thanks! > Thanks to you too! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/9] arc: add AXS101 board support
Dear Alexey, In message <1391088984.3518.35.ca...@abrodkin-8560l.internal.synopsys.com> you wrote: > > > > +#define CONFIG_HOSTNAME axs101 > > > +#define CONFIG_ETHADDR 4a:56:49:22:3e:43 > > > +#define CONFIG_IPADDR 10.121.8.200 > > > +#define CONFIG_SERVERIP 10.121.8.31 > > > +#define CONFIG_GATEWAYIP10.121.8.1 > > > +#define CONFIG_NETMASK 255.255.255.0 > > > > We do not allow any such fixed network parameters in the board config > > headers. > > I see tons of boards do have these parameters set in > "include/configs/xxx". Pre-historic sins. You happen to have a bit of tough luck when chosing your examples to copy from. > I may indeed remove them in from my board but why keep it in others? > So people won't be confused any longer. Cleanup patches are welcome. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies and the other is to make it so complicated that there are no obvious defi- ciencies. - Charles Anthony Richard Hoare ___ 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 Andreas, Thanks for your test. > I saw a few times full compiler output instead of the shortened 'CC > ...'. Especially generating the linker script, reformatting binaries > with objcopy and doing the final linkage of u-boot ELF. Maybe you want > to sort that out? Yes, I will do this in a follow-up series. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] recommended action for bootloaders regarding modifying device-tree nodes
On Thu, Jan 30, 2014 at 12:45 PM, Jason Cooper wrote: > Hi Tim, > > On Thu, Jan 30, 2014 at 01:11:18AM -0800, Tim Harvey wrote: >> My approach has been to define a per-baseboard device-tree in Linux >> for a 'fully loaded' board, then remove nodes which the EEPROM claims >> are not present in the bootloader before it passes the DTB to the >> kernel. I do this by defining aliases in the device-tree for the >> peripherals that are 'optional' so that the bootloader itself does not >> need to know the details about how the device is connected. > > This is more of a process question: Is there any information captured > in your EEPROM that can't be represented in the dtb? iow, at the point > when you write the EEPROM, why not write the dtb to it as configured? > > You could have pre-configured dtsi fragments for each config option, and > then dynamically create the board dts from the order. > > I only ask because it would solve the problem below. However, there's a > lot more to changing a manufacturing process than meets the eye. :) > our eeprom config section is only 40 bytes. It contains a SKU string, mac addrs, and some bitwise fields for the various optional components that we can subload. >> Is it more appropriate for the bootloader to 'remove' nodes for >> devices that are not physically present or should I be setting their >> status property to 'disabled' instead? I'm not clear if either option >> really has any pros or cons. > > That depends on how you have it structured. Is it a valid dtb? > Meaning, do you have four nodes all at the same register address? > Perhaps you could provide an example dts? yes its a valid dtb - it is just the superset of everything the baseboard (ie schematic design) can support. A good example is a custom SKU of a baseboard with ethernet subloaded. If the EEPROM says there is no ethernet mac or phy, I would want to remove or disable the ethernet node from the devicetree. Another example would be a node for 'gpio-pps' (GPIO based pulse-per-second) support. A baseboard design that has a GPS with its PPS signal tied to a GPIO would define this in the device-tree, but if the EEPROM says the GPS isn't loaded, I would want to remove or disable the gps-pps node. Tim > > thx, > > Jason. > >> Tim Harvey - Principal Software Engineer >> Gateworks Corporation > > btw - one of my first embedded projects was on one of your boards. An > ixp425 with 4 mini-pci slots. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] recommended action for bootloaders regarding modifying device-tree nodes
On Thu, Jan 30, 2014 at 1:15 PM, Jason Gunthorpe wrote: > > On Thu, Jan 30, 2014 at 03:45:58PM -0500, Jason Cooper wrote: > > > This is more of a process question: Is there any information captured > > in your EEPROM that can't be represented in the dtb? iow, at the point > > when you write the EEPROM, why not write the dtb to it as configured? > > I can share what we do here.. In our systems the serial EEPROM is only > 256 bytes, so storing things in DT format would be challenging. > > What we do is have a master DTB that has the union of all our > configurations. The boot process has a very simple bit of code that > runs down the DTB in binary format and replaces entire > OF_DT_BEGIN_NODE->OF_DT_END_NODE regions with OF_DT_NOP. > > The NOP approach is very simple, no other changes (eg offset > recalculation) needs to be done to the DT, so we can do this process > with a very small code footprint and without libfdt. > > Choosing which sections to drop is done with some combination of > hardwired code and searching for specific property patterns. There are > also a few places where placeholder sections are directly fixed up, eg > a mac address is written into a placeholder of 0s, etc. > > So an example might be > >optional_peripheral@1 { > orc,board-style = <1>; > [..] >} > > Eg The board-style number comes from the EEPROM and if board-style != > 1 then the entire stanza is replaced with NOP. > > Jason Jason, Sounds pretty much like what we are doing. I am using u-boot and my current code looks like this: /* * Peripheral Config: * remove nodes by alias path if EEPROM config tells us the * peripheral is not loaded on the board. */ if (!test_bit(EECONFIG_ETH0, info->config)) fdt_del_node_and_alias(blob, "ethernet0"); if (!test_bit(EECONFIG_ETH1, info->config)) fdt_del_node_and_alias(blob, "ethernet1"); if (!test_bit(EECONFIG_HDMI_OUT, info->config)) fdt_del_node_and_alias(blob, "hdmi_out"); if (!test_bit(EECONFIG_SATA, info->config)) fdt_del_node_and_alias(blob, "ahci0"); if (!test_bit(EECONFIG_PCIE, info->config)) fdt_del_node_and_alias(blob, "pcie"); if (!test_bit(EECONFIG_SSI0, info->config)) fdt_del_node_and_alias(blob, "ssi0"); if (!test_bit(EECONFIG_SSI1, info->config)) fdt_del_node_and_alias(blob, "ssi1"); ... I've submitted my code to u-boot and have been asked if its more appropriate to remove nodes as I'm doing above or to mark them as 'disabled'. From what I can tell there really isn't a rule or recommendation for this so I think I'll keep doing what I'm doing above. Thanks! Tim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] pci: mx6: Implement reset callback
On Fri, Jan 24, 2014 at 7:25 AM, Marek Vasut wrote: > Add a callback so that a board can implement it's own specific routine to > toggle the port's nRESET line. > > Signed-off-by: Marek Vasut > Cc: Stefano Babic > --- > drivers/pci/pcie_imx.c | 12 +--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/drivers/pci/pcie_imx.c b/drivers/pci/pcie_imx.c > index 0a74867..b554075 100644 > --- a/drivers/pci/pcie_imx.c > +++ b/drivers/pci/pcie_imx.c > @@ -450,6 +450,13 @@ static int imx6_pcie_init_phy(void) > return 0; > } > > +__weak int imx6_pcie_toggle_reset(void) > +{ > + /* This function ought to be overridden ! */ > + puts("WARNING: Make sure the PCIe nRESET line is connected!\n"); > + return 0; > +} > + > static int imx6_pcie_deassert_core_reset(void) > { > struct iomuxc *iomuxc_regs = (struct iomuxc *)IOMUXC_BASE_ADDR; > @@ -466,10 +473,9 @@ static int imx6_pcie_deassert_core_reset(void) > * Wait for the clock to settle a bit, when the clock are sourced > * from the CPU, we need about 30mS to settle. > */ > - mdelay(30); > + mdelay(50); > > - /* FIXME: GPIO reset goes here */ > - mdelay(100); > + imx6_pcie_toggle_reset(); > > return 0; > } Tested-by: Tim Harvey Acked-by: Tim Harvey Tested on a Gateworks Ventana GW54xx board with a PLX PEX8609 switch on the RC with 2 devices behind it: 00:01.0 - 16c3:abcd - Bridge device 01:00.0- 10b5:8609 - Bridge device 02:01.0 - 10b5:8609 - Bridge device 02:04.0 - 10b5:8609 - Bridge device 02:05.0 - 10b5:8609 - Bridge device 02:06.0 - 10b5:8609 - Bridge device 02:07.0 - 10b5:8609 - Bridge device 02:08.0 - 10b5:8609 - Bridge device 08:00.0 - 11ab:4380 - Network controller 02:09.0 - 10b5:8609 - Bridge device 01:00.1- 10b5:8609 - Base system peripheral I would love to see this merged as the PCI driver won't really work without it for boards that have a proper PCI_RST#. Thanks Merek! Tim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot