[U-Boot] [PATCH] cmd_mem: fix cp command
The "cp" command has not worked since
commit 0628ab8ec59834f98ede267edd21ddb8ba0bb57b,
because of the following lines, which set the destination
and the source to the same address.
buf = map_sysmem(addr, bytes);
src = map_sysmem(addr, bytes);
Signed-off-by: Masahiro Yamada
---
common/cmd_mem.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/cmd_mem.c b/common/cmd_mem.c
index 64dd76a..6df00b1 100644
--- a/common/cmd_mem.c
+++ b/common/cmd_mem.c
@@ -445,7 +445,7 @@ static int do_mem_cp(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
#endif
bytes = size * count;
- buf = map_sysmem(addr, bytes);
+ buf = map_sysmem(dest, bytes);
src = map_sysmem(addr, bytes);
while (count-- > 0) {
if (size == 4)
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-Boot configuration on LM3S8962 problem
Dear man: I'm sorry to troubling you,but i come cross some problem that can't be solved.I want to use U-Boot as a bootloader to bulid the embeded linux development platform.I'm using TI's LM3S8962 processor ,but i can't find the type or similar in board/ti directory.So I can't complement the configuration. I will be appreciated if you can give me some help.Thank you! ——A newbie ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 V5] EXYNOS5: GPIO: Enable GPIO Command for EXYNOS5
Dear Rajeshwari Shinde,
On 03/04/13 20:54, Rajeshwari Shinde wrote:
> This patch enables GPIO Command for EXYNOS5.
> Function has been added to asm/gpio.h to decode the
> input gpio name to gpio number.
> example: gpio set gpa00
>
> Signed-off-by: Rajeshwari Shinde
> ---
> Changes in V2:
> - New patch
> Changes in V3:
> - Created a table to know the base address of input bank.
> Changes in V4:
> - Moved the function name_to_gpio to s5p gpio driver and
> renamed to s5p_name_to_gpio.
> Changes in V5:
> - Rebased on latest u-boot-samsung tree
> arch/arm/include/asm/arch-exynos/gpio.h |8 +
> drivers/gpio/s5p_gpio.c | 49
> +++
> include/configs/exynos5250-dt.h |1 +
> 3 files changed, 58 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-exynos/gpio.h
> b/arch/arm/include/asm/arch-exynos/gpio.h
> index d8000af..9b31dc2 100644
> --- a/arch/arm/include/asm/arch-exynos/gpio.h
> +++ b/arch/arm/include/asm/arch-exynos/gpio.h
> @@ -660,6 +660,14 @@ static inline unsigned int get_bank_num(void)
> return 0;
> }
>
> +struct gpio_name_num_table {
> + char bank;
> + unsigned int base;
> +};
> +
> +int s5p_name_to_gpio(const char *name);
> +#define name_to_gpio(n) s5p_name_to_gpio(n)
> +
> void gpio_cfg_pin(int gpio, int cfg);
> void gpio_set_pull(int gpio, int mode);
> void gpio_set_drv(int gpio, int mode);
> diff --git a/drivers/gpio/s5p_gpio.c b/drivers/gpio/s5p_gpio.c
> index d6650c3..824977b 100644
> --- a/drivers/gpio/s5p_gpio.c
> +++ b/drivers/gpio/s5p_gpio.c
> @@ -36,6 +36,21 @@
> #define RATE_MASK(x) (0x1 << (x + 16))
> #define RATE_SET(x) (0x1 << (x + 16))
>
> +struct gpio_name_num_table exynos5_gpio_table[] = {
> + { 'a', EXYNOS5_GPIO_A00 },
> + { 'b', EXYNOS5_GPIO_B00 },
> + { 'c', EXYNOS5_GPIO_C00 },
> + { 'd', EXYNOS5_GPIO_D00 },
> + { 'y', EXYNOS5_GPIO_Y00 },
> + { 'x', EXYNOS5_GPIO_X00 },
> + { 'e', EXYNOS5_GPIO_E00 },
> + { 'f', EXYNOS5_GPIO_F00 },
> + { 'g', EXYNOS5_GPIO_G00 },
> + { 'h', EXYNOS5_GPIO_H00 },
> + { 'v', EXYNOS5_GPIO_V00 },
> + { 'z', EXYNOS5_GPIO_Z0 },
> +};
> +
> void s5p_gpio_cfg_pin(struct s5p_gpio_bank *bank, int gpio, int cfg)
> {
> unsigned int value;
> @@ -238,3 +253,37 @@ void gpio_cfg_pin(int gpio, int cfg)
> s5p_gpio_cfg_pin(s5p_gpio_get_bank(gpio),
>s5p_gpio_get_pin(gpio), cfg);
> }
> +
> +int s5p_name_to_gpio(const char *name)
> +{
> + unsigned int num, i;
> +
> + name++;
Maybe you missing my comments on V3 patch.
Please check.
http://lists.denx.de/pipermail/u-boot/2013-February/146206.html
> +
> + if (*name == 'p')
> + ++name;
> +
> + for (i = 0; i < ARRAY_SIZE(exynos5_gpio_table); i++) {
> + if (*name == exynos5_gpio_table[i].bank) {
> + if (*name == 'c') {
> + name++;
> + num = simple_strtoul(name, NULL, 10);
> + if (num >= 40) {
> + num = EXYNOS5_GPIO_C40 + (num - 40);
> + } else {
> + num = simple_strtoul(name, NULL, 8);
> + num = exynos5_gpio_table[i].base + num;
> + }
> + } else {
> + name++;
> + num = simple_strtoul(name, NULL, 8);
> + num = exynos5_gpio_table[i].base + num;
> + }
> + break;
> + }
> + }
> +
> + if (i == ARRAY_SIZE(exynos5_gpio_table))
> + return -1;
> + return num;
> +}
> diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h
> index cbd1c4e..46a4e75 100644
> --- a/include/configs/exynos5250-dt.h
> +++ b/include/configs/exynos5250-dt.h
> @@ -122,6 +122,7 @@
> #define CONFIG_CMD_FAT
> #define CONFIG_CMD_NET
> #define CONFIG_CMD_HASH
> +#define CONFIG_CMD_GPIO
>
> #define CONFIG_BOOTDELAY 3
> #define CONFIG_ZERO_BOOTDELAY_CHECK
>
Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/12] Introduce Samsung's new board Trats2
Dear Piotr Wilczek, On 17/05/13 21:55, Piotr Wilczek wrote: > This patchset add support for a new Samsung board Trats2. > The board use now new i2c framework. > Support for new multi function pmic max77693 is added. > > This patchset depends on: > commit: 8faefadb7305b95d02df38bd2ea61429d59483e5 > Author: Marc Dietrich 2013-03-29 08:57:10 > disk: fix unaligned access in efi partitions > > Changes in v3: > - I2C_GET_BUS replaced by i2c_get_bus_num() function > - use i2c_set_bus_num() instead I2C_SET_BUS maro > That macro should be completly replaced when all i2c drivers > are adapted to new i2c framework > - add Maintainer entry > - changed T-flash detect pin to GPX3[3] > - removed MMC_ASYNC > - swiched to new i2c framework, use hardware and soft i2c > - adapted s3c24x0 i2c driver to new i2c framework > > Changes in v2: > - changed printf to debug > - removed lcd callback in panel_info > - changed i2c from hardware to software > - use max77693 multifunction pmic > > Piotr Wilczek (12): > pmic:max77686: add function to set voltage and mode > drivers:power:max77693: add support for new multi function pmic > max77693 > arm:exynos:gpio: fix s5p_gpio_part_max for exynos4x12 > i2c:multi_i2c: adapt file to new i2c framework > power: fix pmic command > drivers:power:power_i2c: adapt file to new i2c framework > driver:i2c:s3c24x0: adapt driver to new i2c framework > drivers:video:s6e8ax0: change data_to_send array to static > drivers:lcd: fix unaligned access on lcd > samsung: trats2: add support for new board Trats2 > board:VCMA9 switch to ne i2c framework > board:smdk5250: switch to new i2c framework > > MAINTAINERS |4 + > Makefile|1 + > arch/arm/include/asm/arch-exynos/gpio.h | 17 +- > board/samsung/common/multi_i2c.c| 37 ++- > board/samsung/smdk5250/smdk5250.c |2 +- > board/samsung/trats2/Makefile | 50 +++ > board/samsung/trats2/trats2.c | 533 > +++ > boards.cfg |1 + > common/lcd.c| 12 +- > drivers/i2c/Makefile|2 +- > drivers/i2c/s3c24x0_i2c.c | 100 +++--- > drivers/power/battery/Makefile |1 + > drivers/power/battery/bat_trats2.c | 81 + > drivers/power/mfd/Makefile | 49 +++ > drivers/power/mfd/fg_max77693.c | 143 + > drivers/power/mfd/muic_max77693.c | 91 ++ > drivers/power/mfd/pmic_max77693.c | 110 +++ > drivers/power/pmic/pmic_max77686.c | 186 +++ > drivers/power/power_core.c |8 + > drivers/power/power_i2c.c |6 + > drivers/video/s6e8ax0.c | 26 +- > include/configs/VCMA9.h |9 +- > include/configs/exynos5250-dt.h |8 +- > include/configs/trats2.h| 326 +++ > include/power/max77686_pmic.h | 11 + > include/power/max77693_fg.h | 65 > include/power/max77693_muic.h | 90 ++ > include/power/max77693_pmic.h | 56 > 28 files changed, 1949 insertions(+), 76 deletions(-) > create mode 100644 board/samsung/trats2/Makefile > create mode 100644 board/samsung/trats2/trats2.c > create mode 100644 drivers/power/battery/bat_trats2.c > create mode 100644 drivers/power/mfd/Makefile > create mode 100644 drivers/power/mfd/fg_max77693.c > create mode 100644 drivers/power/mfd/muic_max77693.c > create mode 100644 drivers/power/mfd/pmic_max77693.c > create mode 100644 include/configs/trats2.h > create mode 100644 include/power/max77693_fg.h > create mode 100644 include/power/max77693_muic.h > create mode 100644 include/power/max77693_pmic.h This patchset doesn't match with subject of patchset. Why this patchset contain many other subjects in it? I think GPIO, I2C, LCD, Power.. are not related with supporting the trats2. Please split them. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v03 0/2] OMAP3+: introduce generic Adaptive Body Bias Support
Adaptive Body Biasing (ABB) modulates transistor bias voltages dynamically in order to optimize switching speed versus leakage. Adaptive Body-Bias ldos are present for some voltage domains: starting with OMAP3630. There are three modes of operation: * Bypass - the default, it just follows the vdd voltage * Foward Body-Bias - applies voltage bias to increase transistor performance at the cost of power. Used to operate safely at high OPPs. * Reverse Body-Bias - applies voltage bias to decrease leakage and save power. Used to save power at lower OPPs. The application of FBB/RBB technique is determined for each unique device in some process nodes, whereas, they are mandated on other process nodes. OMAP5 silicon requires ABB to be properly configured on early boot stage. The following patch series adds generic ABB configuration and enables it for OMAP5 silicons. v02: series contains minor comments fixes. v03: series contains: - clearing pending ABB interrupts before beginning of ABB configuration. - clearing ABB "setup" and "control" registers before beginning of ABB configuration. - removing superfluous wait on ABB "in transition" done status. Andrii Tseglytskyi (2): OMAP3+: introduce generic ABB support OMAP5: add ABB setup for MPU voltage domain arch/arm/cpu/armv7/omap-common/Makefile|1 + arch/arm/cpu/armv7/omap-common/abb.c | 137 arch/arm/cpu/armv7/omap-common/clocks-common.c |9 ++ arch/arm/cpu/armv7/omap5/Makefile |1 + arch/arm/cpu/armv7/omap5/abb.c | 67 arch/arm/cpu/armv7/omap5/prcm-regs.c |7 ++ arch/arm/include/asm/arch-omap3/omap3.h|7 ++ arch/arm/include/asm/arch-omap4/omap.h |7 ++ arch/arm/include/asm/arch-omap5/omap.h | 13 +++ arch/arm/include/asm/omap_common.h | 22 10 files changed, 271 insertions(+) create mode 100644 arch/arm/cpu/armv7/omap-common/abb.c create mode 100644 arch/arm/cpu/armv7/omap5/abb.c -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v03 2/2] OMAP5: add ABB setup for MPU voltage domain
Patch adds a call of abb_setup() function, and proper registers
definitions needed for ABB setup sequence. ABB is initialized
for MPU voltage domain.
Signed-off-by: Andrii Tseglytskyi
---
arch/arm/cpu/armv7/omap-common/clocks-common.c |9 +
arch/arm/cpu/armv7/omap5/prcm-regs.c |7 +++
2 files changed, 16 insertions(+)
diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index 2b955c7..bdecaf8 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -533,6 +533,15 @@ void scale_vcores(struct vcores_data const *vcores)
do_scale_vcore(vcores->mpu.addr, vcores->mpu.value,
vcores->mpu.pmic);
+ /* Configure MPU ABB LDO after scale */
+ abb_setup((*ctrl)->control_std_fuse_opp_vdd_mpu_2,
+ (*ctrl)->control_wkup_ldovbb_mpu_voltage_ctrl,
+ (*prcm)->prm_abbldo_mpu_setup,
+ (*prcm)->prm_abbldo_mpu_ctrl,
+ (*prcm)->prm_irqstatus_mpu_2,
+ OMAP_ABB_MPU_TXDONE_MASK,
+ OMAP_ABB_FAST_OPP);
+
do_scale_vcore(vcores->mm.addr, vcores->mm.value,
vcores->mm.pmic);
diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index b8a61fe..b4b624e 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -311,6 +311,7 @@ struct prcm_regs const omap5_es1_prcm = {
struct omap_sys_ctrl_regs const omap5_ctrl = {
.control_status = 0x4A002134,
+ .control_std_fuse_opp_vdd_mpu_2 = 0x4A0021B4,
.control_paconf_global = 0x4A002DA0,
.control_paconf_mode= 0x4A002DA4,
.control_smart1io_padconf_0 = 0x4A002DA8,
@@ -358,6 +359,7 @@ struct omap_sys_ctrl_regs const omap5_ctrl = {
.control_port_emif2_sdram_config= 0x4AE0C118,
.control_emif1_sdram_config_ext = 0x4AE0C144,
.control_emif2_sdram_config_ext = 0x4AE0C148,
+ .control_wkup_ldovbb_mpu_voltage_ctrl = 0x4AE0C318,
.control_smart1nopmio_padconf_0 = 0x4AE0CDA0,
.control_smart1nopmio_padconf_1 = 0x4AE0CDA4,
.control_padconf_mode = 0x4AE0CDA8,
@@ -709,6 +711,9 @@ struct prcm_regs const omap5_es2_prcm = {
.cm_l3init_fsusb_clkctrl = 0x4a0096d0,
.cm_l3init_ocp2scp1_clkctrl = 0x4a0096e0,
+ /* prm irqstatus regs */
+ .prm_irqstatus_mpu_2 = 0x4ae06014,
+
/* l4 wkup regs */
.cm_abe_pll_ref_clksel = 0x4ae0610c,
.cm_sys_clksel = 0x4ae06110,
@@ -739,6 +744,8 @@ struct prcm_regs const omap5_es2_prcm = {
.prm_sldo_mpu_ctrl = 0x4ae07cd0,
.prm_sldo_mm_setup = 0x4ae07cd4,
.prm_sldo_mm_ctrl = 0x4ae07cd8,
+ .prm_abbldo_mpu_setup = 0x4ae07cdc,
+ .prm_abbldo_mpu_ctrl = 0x4ae07ce0,
};
struct prcm_regs const dra7xx_prcm = {
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v03 1/2] OMAP3+: introduce generic ABB support
Adaptive Body Biasing (ABB) modulates transistor bias voltages
dynamically in order to optimize switching speed versus leakage.
Adaptive Body-Bias ldos are present for some voltage domains
starting with OMAP3630. There are three modes of operation:
* Bypass - the default, it just follows the vdd voltage
* Foward Body-Bias - applies voltage bias to increase transistor
performance at the cost of power. Used to operate safely at high
OPPs.
* Reverse Body-Bias - applies voltage bias to decrease leakage and
save power. Used to save power at lower OPPs.
Signed-off-by: Andrii Tseglytskyi
---
arch/arm/cpu/armv7/omap-common/Makefile |1 +
arch/arm/cpu/armv7/omap-common/abb.c| 137 +++
arch/arm/cpu/armv7/omap5/Makefile |1 +
arch/arm/cpu/armv7/omap5/abb.c | 67 +++
arch/arm/include/asm/arch-omap3/omap3.h |7 ++
arch/arm/include/asm/arch-omap4/omap.h |7 ++
arch/arm/include/asm/arch-omap5/omap.h | 13 +++
arch/arm/include/asm/omap_common.h | 22 +
8 files changed, 255 insertions(+)
create mode 100644 arch/arm/cpu/armv7/omap-common/abb.c
create mode 100644 arch/arm/cpu/armv7/omap5/abb.c
diff --git a/arch/arm/cpu/armv7/omap-common/Makefile
b/arch/arm/cpu/armv7/omap-common/Makefile
index 55e82ba..c4b9809 100644
--- a/arch/arm/cpu/armv7/omap-common/Makefile
+++ b/arch/arm/cpu/armv7/omap-common/Makefile
@@ -34,6 +34,7 @@ COBJS += hwinit-common.o
COBJS += clocks-common.o
COBJS += emif-common.o
COBJS += vc.o
+COBJS += abb.o
endif
ifneq ($(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TI814X),)
diff --git a/arch/arm/cpu/armv7/omap-common/abb.c
b/arch/arm/cpu/armv7/omap-common/abb.c
new file mode 100644
index 000..87d1fb8
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap-common/abb.c
@@ -0,0 +1,137 @@
+/*
+ *
+ * Adaptive Body Bias programming sequence for OMAP family
+ *
+ * (C) Copyright 2013
+ * Texas Instruments,
+ *
+ * Andrii Tseglytskyi
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+
+__weak s8 abb_setup_ldovbb(u32 fuse, u32 ldovbb)
+{
+ return -1;
+}
+
+static void abb_setup_timings(u32 setup)
+{
+ u32 sys_rate, sr2_cnt, clk_cycles;
+
+ /*
+* SR2_WTCNT_VALUE is the settling time for the ABB ldo after a
+* transition and must be programmed with the correct time at boot.
+* The value programmed into the register is the number of SYS_CLK
+* clock cycles that match a given wall time profiled for the ldo.
+* This value depends on:
+* settling time of ldo in micro-seconds (varies per OMAP family),
+* of clock cycles per SYS_CLK period (varies per OMAP family),
+* the SYS_CLK frequency in MHz (varies per board)
+* The formula is:
+*
+* ldo settling time (in micro-seconds)
+* SR2_WTCNT_VALUE = --
+* (# system clock cycles) * (sys_clk period)
+*
+* Put another way:
+*
+* SR2_WTCNT_VALUE = settling time / (# SYS_CLK cycles / SYS_CLK rate))
+*
+* To avoid dividing by zero multiply both "# clock cycles" and
+* "settling time" by 10 such that the final result is the one we want.
+*/
+
+ /* calculate SR2_WTCNT_VALUE */
+ sys_rate = DIV_ROUND(V_OSCK, 100);
+ clk_cycles = DIV_ROUND(OMAP_ABB_CLOCK_CYCLES * 10, sys_rate);
+ sr2_cnt = DIV_ROUND(OMAP_ABB_SETTLING_TIME * 10, clk_cycles);
+
+ setbits_le32(setup,
+sr2_cnt << (ffs(OMAP_ABB_SETUP_SR2_WTCNT_VALUE_MASK) - 1));
+}
+
+void abb_setup(u32 fuse, u32 ldovbb, u32 setup, u32 control,
+ u32 txdone, u32 txdone_mask, u32 opp)
+{
+ u32 abb_type_mask, opp_sel_mask;
+
+ /* sanity check */
+ if (!setup || !control || !txdone)
+ return;
+
+ /* setup ABB only in case of Fast or Slow OPP */
+ switch (opp) {
+ case OMAP_ABB_FAST_OPP:
+ abb_type_mask = OMAP_ABB_SETUP_ACTIVE_FBB_SEL_MASK;
+ opp_sel_mask = OMAP_ABB_CONTROL_FAST_OPP_SEL_MASK;
+ break;
+
Re: [U-Boot] [PATCH v3 0/12] Introduce Samsung's new board Trats2
Dear Minkyu Kang, > -Original Message- > From: Minkyu Kang [mailto:mk7.k...@samsung.com] > Sent: Tuesday, May 21, 2013 10:36 AM > To: Piotr Wilczek > Cc: u-boot@lists.denx.de; Kyungmin Park; Lukasz Majewski > Subject: Re: [PATCH v3 0/12] Introduce Samsung's new board Trats2 > > Dear Piotr Wilczek, > > On 17/05/13 21:55, Piotr Wilczek wrote: > > This patchset add support for a new Samsung board Trats2. > > The board use now new i2c framework. > > Support for new multi function pmic max77693 is added. > > > > This patchset depends on: > > commit: 8faefadb7305b95d02df38bd2ea61429d59483e5 > > Author: Marc Dietrich 2013-03-29 08:57:10 > > disk: fix unaligned access in efi partitions > > > > Changes in v3: > > - I2C_GET_BUS replaced by i2c_get_bus_num() function > > - use i2c_set_bus_num() instead I2C_SET_BUS maro That macro should be > > completly replaced when all i2c drivers are adapted to new i2c > > framework > > - add Maintainer entry > > - changed T-flash detect pin to GPX3[3] > > - removed MMC_ASYNC > > - swiched to new i2c framework, use hardware and soft i2c > > - adapted s3c24x0 i2c driver to new i2c framework > > > > Changes in v2: > > - changed printf to debug > > - removed lcd callback in panel_info > > - changed i2c from hardware to software > > - use max77693 multifunction pmic > > > > Piotr Wilczek (12): > > pmic:max77686: add function to set voltage and mode > > drivers:power:max77693: add support for new multi function pmic > > max77693 > > arm:exynos:gpio: fix s5p_gpio_part_max for exynos4x12 > > i2c:multi_i2c: adapt file to new i2c framework > > power: fix pmic command > > drivers:power:power_i2c: adapt file to new i2c framework > > driver:i2c:s3c24x0: adapt driver to new i2c framework > > drivers:video:s6e8ax0: change data_to_send array to static > > drivers:lcd: fix unaligned access on lcd > > samsung: trats2: add support for new board Trats2 > > board:VCMA9 switch to ne i2c framework > > board:smdk5250: switch to new i2c framework > > > > MAINTAINERS |4 + > > Makefile|1 + > > arch/arm/include/asm/arch-exynos/gpio.h | 17 +- > > board/samsung/common/multi_i2c.c| 37 ++- > > board/samsung/smdk5250/smdk5250.c |2 +- > > board/samsung/trats2/Makefile | 50 +++ > > board/samsung/trats2/trats2.c | 533 > +++ > > boards.cfg |1 + > > common/lcd.c| 12 +- > > drivers/i2c/Makefile|2 +- > > drivers/i2c/s3c24x0_i2c.c | 100 +++--- > > drivers/power/battery/Makefile |1 + > > drivers/power/battery/bat_trats2.c | 81 + > > drivers/power/mfd/Makefile | 49 +++ > > drivers/power/mfd/fg_max77693.c | 143 + > > drivers/power/mfd/muic_max77693.c | 91 ++ > > drivers/power/mfd/pmic_max77693.c | 110 +++ > > drivers/power/pmic/pmic_max77686.c | 186 +++ > > drivers/power/power_core.c |8 + > > drivers/power/power_i2c.c |6 + > > drivers/video/s6e8ax0.c | 26 +- > > include/configs/VCMA9.h |9 +- > > include/configs/exynos5250-dt.h |8 +- > > include/configs/trats2.h| 326 +++ > > include/power/max77686_pmic.h | 11 + > > include/power/max77693_fg.h | 65 > > include/power/max77693_muic.h | 90 ++ > > include/power/max77693_pmic.h | 56 > > 28 files changed, 1949 insertions(+), 76 deletions(-) create mode > > 100644 board/samsung/trats2/Makefile create mode 100644 > > board/samsung/trats2/trats2.c create mode 100644 > > drivers/power/battery/bat_trats2.c > > create mode 100644 drivers/power/mfd/Makefile create mode 100644 > > drivers/power/mfd/fg_max77693.c create mode 100644 > > drivers/power/mfd/muic_max77693.c create mode 100644 > > drivers/power/mfd/pmic_max77693.c create mode 100644 > > include/configs/trats2.h create mode 100644 > > include/power/max77693_fg.h create mode 100644 > > include/power/max77693_muic.h create mode 100644 > > include/power/max77693_pmic.h > > This patchset doesn't match with subject of patchset. > Why this patchset contain many other subjects in it? > I think GPIO, I2C, LCD, Power.. are not related with supporting the > trats2. > Please split them. > Ok, I will split this patchset. > Thanks, > Minkyu Kang. Best regards, Piotr Wilczek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-BOOT] mmc: sdhci: Enable 8-bit bus width only for 3.0 spec onwards
CAP register don't have any information for 8-bit buswidth support
on 2.0 sdhci spec, only from 3.0 onwards bit[18] got this information.
Due to this misassignment in sdhci, mmc is setting 8-bit buswidth using
mmc_set_bus_width even if controller doesn't support.
Below change has code information.
"mmc: Properly determine maximum supported bus width"
(sha1: 7798f6dbd5e1a3030ed81a81da5dfb57c3307cac)
Bug log: mmcinfo
Error detected in status(0x208100)!
Device: zynq_sdhci
Manufacturer ID: fe
.
So enable 8-bit support only for 3.0 spec using CAP and for below 3.0
assign mmc->host_caps = MMC_MODE_8BIT on respective platform driver
if host have a support.
Signed-off-by: Jagannadha Sutradharudu Teki
---
drivers/mmc/sdhci.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 1eaea04..c5631bf 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -486,8 +486,10 @@ int add_sdhci(struct sdhci_host *host, u32 max_clk, u32
min_clk)
mmc->voltages |= host->voltages;
mmc->host_caps = MMC_MODE_HS | MMC_MODE_HS_52MHz | MMC_MODE_4BIT;
- if (caps & SDHCI_CAN_DO_8BIT)
- mmc->host_caps |= MMC_MODE_8BIT;
+ if ((host->version & SDHCI_SPEC_VER_MASK) >= SDHCI_SPEC_300) {
+ if (caps & SDHCI_CAN_DO_8BIT)
+ mmc->host_caps |= MMC_MODE_8BIT;
+ }
if (host->host_caps)
mmc->host_caps |= host->host_caps;
--
1.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 4/6] arm: mvf600: Add watchdog support for Vybrid MVF600
This patch adds watchdog support for Vybrid MVF600 platform. Signed-off-by: Alison Wang --- Changes in v3: None Changes in v2: - Add watchdog support - Use reset_cpu() in imx_watchdog.c drivers/watchdog/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile index 13e7c37..40946df 100644 --- a/drivers/watchdog/Makefile +++ b/drivers/watchdog/Makefile @@ -27,7 +27,7 @@ LIB := $(obj)libwatchdog.o COBJS-$(CONFIG_AT91SAM9_WATCHDOG) += at91sam9_wdt.o COBJS-$(CONFIG_FTWDT010_WATCHDOG) += ftwdt010_wdt.o -ifneq (,$(filter $(SOC), mx31 mx35 mx5 mx6)) +ifneq (,$(filter $(SOC), mx31 mx35 mx5 mx6 mvf600)) COBJS-y += imx_watchdog.o endif COBJS-$(CONFIG_TNETV107X_WATCHDOG) += tnetv107x_wdt.o -- 1.8.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/6] arm: mvf600: Add IOMUX support for Vybrid MVF600
This patch adds the IOMUX support for Vybrid MVF600 platform. There is a little difference for IOMUXC module between MVF600 and i.MX platform, the muxmode and pad configuration share one 32bit register on MVF600, but they are two independent registers on I.MX platform. A CONFIG_IOMUX_SHARE_CONFIG_REG was introduced to fit this difference. Signed-off-by: Alison Wang --- Changes in v3: - Define PAD_CTL_PUE with PKE enabled Changes in v2: - Use common iomux-v3 code arch/arm/imx-common/Makefile | 2 +- arch/arm/imx-common/iomux-v3.c | 6 ++ arch/arm/include/asm/imx-common/iomux-v3.h | 18 ++ 3 files changed, 25 insertions(+), 1 deletion(-) diff --git a/arch/arm/imx-common/Makefile b/arch/arm/imx-common/Makefile index 8bba8a5..3378931 100644 --- a/arch/arm/imx-common/Makefile +++ b/arch/arm/imx-common/Makefile @@ -27,7 +27,7 @@ include $(TOPDIR)/config.mk LIB = $(obj)libimx-common.o -ifeq ($(SOC),$(filter $(SOC),mx25 mx35 mx5 mx6)) +ifeq ($(SOC),$(filter $(SOC),mx25 mx35 mx5 mx6 mvf600)) COBJS-y= iomux-v3.o endif ifeq ($(SOC),$(filter $(SOC),mx5 mx6)) diff --git a/arch/arm/imx-common/iomux-v3.c b/arch/arm/imx-common/iomux-v3.c index 7fe5ce7..35880c7 100644 --- a/arch/arm/imx-common/iomux-v3.c +++ b/arch/arm/imx-common/iomux-v3.c @@ -48,8 +48,14 @@ void imx_iomux_v3_setup_pad(iomux_v3_cfg_t pad) if (sel_input_ofs) __raw_writel(sel_input, base + sel_input_ofs); +#ifdef CONFIG_IOMUX_SHARE_CONF_REG + if (!(pad_ctrl & NO_PAD_CTRL)) + __raw_writel((mux_mode << PAD_MUX_MODE_SHIFT) | pad_ctrl, + base + pad_ctrl_ofs); +#else if (!(pad_ctrl & NO_PAD_CTRL) && pad_ctrl_ofs) __raw_writel(pad_ctrl, base + pad_ctrl_ofs); +#endif } void imx_iomux_v3_setup_multiple_pads(iomux_v3_cfg_t const *pad_list, diff --git a/arch/arm/include/asm/imx-common/iomux-v3.h b/arch/arm/include/asm/imx-common/iomux-v3.h index 0b4e763..012d66a 100644 --- a/arch/arm/include/asm/imx-common/iomux-v3.h +++ b/arch/arm/include/asm/imx-common/iomux-v3.h @@ -121,6 +121,24 @@ typedef u64 iomux_v3_cfg_t; #define PAD_CTL_DSE_40ohm (6 << 3) #define PAD_CTL_DSE_34ohm (7 << 3) +#elif defined(CONFIG_MVF600) + +#define PAD_MUX_MODE_SHIFT 20 + +#definePAD_CTL_PUS_47K_UP (1 << 4) +#definePAD_CTL_PUS_100K_UP (2 << 4) +#define PAD_CTL_PUE(1 << 2 | PAD_CTL_PKE) +#definePAD_CTL_PKE (1 << 3) + +#define PAD_CTL_SPEED_HIGH (3 << 12) +#define PAD_CTL_SPEED_MED (1 << 12) + +#define PAD_CTL_DSE_20ohm (7 << 6) +#define PAD_CTL_DSE_25ohm (6 << 6) +#define PAD_CTL_DSE_50ohm (3 << 6) + +#define PAD_CTL_OBE_IBE_ENABLE (3 << 0) + #else #define PAD_CTL_DVS(1 << 13) -- 1.8.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 5/6] arm: mvf600: Add uart support for Vybrid MVF600
This patch adds lpuart support for Vybrid MVF600 platform.
Signed-off-by: TsiChung Liew
Signed-off-by: Alison Wang
---
Changes in v3:
- Move the structure definition to imx-regs.h
Changes in v2:
- Define C structures and access C structures to set/read registers
- Change the names to reuse this driver on other platforms
drivers/serial/Makefile| 1 +
drivers/serial/serial_lpuart.c | 132 +
2 files changed, 133 insertions(+)
create mode 100644 drivers/serial/serial_lpuart.c
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index fbc4e97..bb6559b 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -52,6 +52,7 @@ COBJS-$(CONFIG_XILINX_UARTLITE) += serial_xuartlite.o
COBJS-$(CONFIG_SANDBOX_SERIAL) += sandbox.o
COBJS-$(CONFIG_SCIF_CONSOLE) += serial_sh.o
COBJS-$(CONFIG_ZYNQ_SERIAL) += serial_zynq.o
+COBJS-$(CONFIG_FSL_LPUART) += serial_lpuart.o
ifndef CONFIG_SPL_BUILD
COBJS-$(CONFIG_USB_TTY) += usbtty.o
diff --git a/drivers/serial/serial_lpuart.c b/drivers/serial/serial_lpuart.c
new file mode 100644
index 000..51d5666
--- /dev/null
+++ b/drivers/serial/serial_lpuart.c
@@ -0,0 +1,132 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define US1_TDRE(1 << 7)
+#define US1_RDRF(1 << 5)
+#define UC2_TE (1 << 3)
+#define UC2_RE (1 << 2)
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct lpuart_fsl *base = (struct lpuart_fsl *)LPUART_BASE;
+
+static void lpuart_serial_setbrg(void)
+{
+ u32 clk = mxc_get_clock(MXC_UART_CLK);
+ u16 sbr;
+
+ if (!gd->baudrate)
+ gd->baudrate = CONFIG_BAUDRATE;
+
+ sbr = (u16)(clk / (16 * gd->baudrate));
+ /* place adjustment later - n/32 BRFA */
+
+ __raw_writeb(sbr >> 8, &base->ubdh);
+ __raw_writeb(sbr & 0xff, &base->ubdl);
+}
+
+static int lpuart_serial_getc(void)
+{
+ u8 status;
+
+ while (!(__raw_readb(&base->us1) & US1_RDRF))
+ WATCHDOG_RESET();
+
+ status = __raw_readb(&base->us1);
+ status |= US1_RDRF;
+ __raw_writeb(status, &base->us1);
+
+ return __raw_readb(&base->ud);
+}
+
+static void lpuart_serial_putc(const char c)
+{
+ if (c == '\n')
+ serial_putc('\r');
+
+ while (!(__raw_readb(&base->us1) & US1_TDRE))
+ WATCHDOG_RESET();
+
+ __raw_writeb(c, &base->ud);
+}
+
+/*
+ * Test whether a character is in the RX buffer
+ */
+static int lpuart_serial_tstc(void)
+{
+ if (__raw_readb(&base->urcfifo) == 0)
+ return 0;
+
+ return 1;
+}
+
+/*
+ * Initialise the serial port with the given baudrate. The settings
+ * are always 8 data bits, no parity, 1 stop bit, no start bits.
+ */
+static int lpuart_serial_init(void)
+{
+ u8 ctrl;
+
+ ctrl = __raw_readb(&base->uc2);
+ ctrl &= ~UC2_RE;
+ ctrl &= ~UC2_TE;
+ __raw_writeb(ctrl, &base->uc2);
+
+ __raw_writeb(0, &base->umodem);
+ __raw_writeb(0, &base->uc1);
+
+ /* provide data bits, parity, stop bit, etc */
+
+ serial_setbrg();
+
+ __raw_writeb(UC2_RE | UC2_TE, &base->uc2);
+
+ return 0;
+}
+
+static struct serial_device lpuart_serial_drv = {
+ .name = "lpuart_serial",
+ .start = lpuart_serial_init,
+ .stop = NULL,
+ .setbrg = lpuart_serial_setbrg,
+ .putc = lpuart_serial_putc,
+ .puts = default_serial_puts,
+ .getc = lpuart_serial_getc,
+ .tstc = lpuart_serial_tstc,
+};
+
+void lpuart_serial_initialize(void)
+{
+ serial_register(&lpuart_serial_drv);
+}
+
+__weak struct serial_device *default_serial_console(void)
+{
+ return &lpuart_serial_drv;
+}
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 0/6] arm: mvf600: Add Freescale Vybrid MVF600 CPU and MVF600TWR board support
This series contain the support for Freescale Vybrid MVF600 CPU and MVF600TWR board. Vybird devices are built on an asymmetrical-multiprocessing architecture using ARM cores. The families in the Vybrid portfolio span entry-level, single core Cortex-A class SoCs all the way to dual heterogeneous core SoCs with multiple communication and connectivity options. Part of the Vybrid platform, MVF600 is a dual-core eMPU combining the ARM Cortex A5 and Cortex M4 cores. MVF600 shares some IPs with i.MX family, such as FEC,ESDHC,WATCHDOG,I2C,ASRC and ESAI. MVF600 also shares some IPs with ColdFire family, such as eDMA and DSPI. MVF600 still has its own IPs, such as PIT,SAI,UART,QSPI and DCU. More documents for this soc can be found at: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=VF6xx&fsrch=1&sr=5 http://www.freescale.com/webapp/sps/site/homepage.jsp?code=VYBRID The u-boot runs on Cortex A5 core. Changes in v3: - Rename the common functions and enums - Move the structure definitions to imx-regs.h - Define PAD_CTL_PUE with PKE enabled - Remove the changes for FEC_RCNTRL_RGMII / FEC_RCNTRL_RMII / FEC_RCNTRL_MII_MODE bits, as they are already set in fec_reg_setup() - Replace BOOT_FROM by BOOT_OFFSET - Enable CONFIG_OF_LIBFDT option - Add useful define instead of raw number - Use clrsetbits_le32 to set the single bits - Move setup_iomux_enet() to board_early_init_f and remove board_eth_init() - Remove redundant define - Move CONFIG_IOMUX_SHARE_CONF_REG to imx-regs.h Changes in v2: - Remove vybrid-common directory - Rename directory name 'vybrid' to 'mvf600' - Add generic.c file - Rewrite get_reset_cause() to make it readable - Remove reset_cpu(), and use the function in imx_watchdog.c - Rewrite timer.c file - Use vybrid_get_clock(VYBRID_UART_CLK) instead of vybrid_get_uartclk() - Remove lowlevel_init.S, and add clock_init() in board_early_init_f() - Remove useless CONFIG_SYS_ defines - Move CONFIG_MACH_TYPE to board configuration file - Define C structures and access C structures to set/read registers - Remove useless errata - Remove useless macros - Rename directory 'arch-vybrid' to 'arch-mvf600' - Use common iomux-v3 code - Use common FEC driver fec_mxc.c - Add watchdog support - Add an entry to MAINTAINERS file - Rename directory name 'vybird' to 'mvf600twr' - Use standard method to set gd->ram_size - Rewrite board_mmc_getcd() function - Remove useless undef - Remove hardcoded IP addresses and MAC addresses - Move CONFIG_MACH_TYPE to board configuration file Alison Wang (6): arm: mvf600: Add Vybrid MVF600 CPU support arm: mvf600: Add IOMUX support for Vybrid MVF600 net: fec_mxc: Add support for Vybrid MVF600 arm: mvf600: Add watchdog support for Vybrid MVF600 arm: mvf600: Add uart support for Vybrid MVF600 arm: mvf600: Add basic support for Vybrid MVF600TWR board MAINTAINERS | 4 ++ Makefile| 2 +- arch/arm/cpu/armv7/mvf600/Makefile | 42 +++ arch/arm/cpu/armv7/mvf600/generic.c | 324 ++ arch/arm/cpu/armv7/mvf600/timer.c | 103 ++ arch/arm/imx-common/Makefile| 2 +- arch/arm/imx-common/iomux-v3.c | 6 ++ arch/arm/include/asm/arch-mvf600/clock.h| 39 ++ arch/arm/include/asm/arch-mvf600/crm_regs.h | 225 + arch/arm/include/asm/arch-mvf600/imx-regs.h | 411 arch/arm/include/asm/arch-mvf600/mvf_pins.h | 92 arch/arm/include/asm/imx-common/iomux-v3.h | 18 + board/freescale/mvf600twr/Makefile | 39 ++ board/freescale/mvf600twr/imximage.cfg | 33 + board/freescale/mvf600twr/mvf600twr.c | 413 + boards.cfg | 1 + drivers/net/fec_mxc.c | 4 +- drivers/serial/Makefile | 1 + drivers/serial/serial_lpuart.c | 132 ++ drivers/watchdog/Makefile | 2 +- include/configs/mvf600twr.h | 140 21 files changed, 2027 insertions(+), 6 deletions(-) create mode 100644 arch/arm/cpu/armv7/mvf600/Makefile create mode 100644 arch/arm/cpu/armv7/mvf600/generic.c create mode 100644 arch/arm/cpu/armv7/mvf600/timer.c create mode 100644 arch/arm/include/asm/arch-mvf600/clock.h create mode 100644 arch/arm/include/asm/arch-mvf600/crm_regs.h create mode 100644 arch/arm/include/asm/arch-mvf600/imx-regs.h create mode 100644 arch/arm/inc
[U-Boot] [PATCH v3 3/6] net: fec_mxc: Add support for Vybrid MVF600
This patch adds FEC support for Vybrid MVF600 platform.
In function fec_open(), RCR register is only set as RGMII mode. But RCR
register should be set as RMII mode for MVF600 platform.
This configuration is already done in fec_reg_setup(), so this piece of
code could just leave untouched the FEC_RCNTRL_RGMII / FEC_RCNTRL_RMII /
FEC_RCNTRL_MII_MODE bits.
Signed-off-by: Alison Wang
---
Changes in v3:
- Remove the changes for FEC_RCNTRL_RGMII / FEC_RCNTRL_RMII /
FEC_RCNTRL_MII_MODE bits, as they are already set in fec_reg_setup()
Changes in v2:
- Use common FEC driver fec_mxc.c
drivers/net/fec_mxc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 4dbcdca..da95e28 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -516,9 +516,7 @@ static int fec_open(struct eth_device *edev)
#ifdef FEC_QUIRK_ENET_MAC
{
u32 ecr = readl(&fec->eth->ecntrl) & ~FEC_ECNTRL_SPEED;
- u32 rcr = (readl(&fec->eth->r_cntrl) &
- ~(FEC_RCNTRL_RMII | FEC_RCNTRL_RMII_10T)) |
- FEC_RCNTRL_RGMII | FEC_RCNTRL_MII_MODE;
+ u32 rcr = readl(&fec->eth->r_cntrl) & ~FEC_RCNTRL_RMII_10T;
if (speed == _1000BASET)
ecr |= FEC_ECNTRL_SPEED;
else if (speed != _100BASET)
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,1/3] ARM: at91: add Atmel sama5d3 SoC new pmc register
Dear Bo Shen, Bo Shen writes: >Add Atmel sama5d3 SoC new pmc register > >Signed-off-by: Bo Shen > >--- >Changes in v3: > - New splitted patch file. > >Changes in v2: > - No change > > arch/arm/include/asm/arch-at91/at91_pmc.h | 23 +++ > 1 file changed, 23 insertions(+) applied to u-boot-atmel/master, thanks! 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] [U-Boot,2/3] USB: ohci-at91: support sama5d3x devices
Dear Bo Shen, Bo Shen writes: >Add OHCI support for sama5d3x devices > >Signed-off-by: Bo Shen > >--- >Changes in v3: > - Rebase to u-boot-atmel master branch > >Changes in v2: > - No Change > > drivers/usb/host/ohci-at91.c | 14 -- > 1 file changed, 12 insertions(+), 2 deletions(-) applied to u-boot-atmel/master, thanks! 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] [U-Boot,3/3] ARM: atmel: add sama5d3xek support
Dear Bo Shen, Bo Shen writes: >Add sama5d3xek support with following feature > - boot from NAND flash, PMECC support, 4bit ECC @ 512 bytes sector > - boot from SPI flash support > - boot from SD card support > - LCD support > - EMAC support > - USB OHCI support > >Signed-off-by: Bo Shen > >--- >Changes in v3: > - Split new pmc register in a standalone patch > - The EMAC support need: net: macb: using AT91FAMILY replace #ifdeferry >- http://patchwork.ozlabs.org/patch/239064/ > >Changes in v2: > - Remove unneeded #undef > - Using string directly > - Add missed copyright > - Using pull up for usart Tx line > - Using pull up for spi cs > - make code more readable in clock.c file > - move LCD higher 8 bit to board file (This is board related) > > MAINTAINERS |1 + > arch/arm/cpu/armv7/at91/Makefile | 52 + > arch/arm/cpu/armv7/at91/clock.c | 125 > arch/arm/cpu/armv7/at91/cpu.c| 90 + > arch/arm/cpu/armv7/at91/reset.c | 47 + > arch/arm/cpu/armv7/at91/sama5d3_devices.c| 196 ++ > arch/arm/cpu/armv7/at91/timer.c | 139 + > arch/arm/include/asm/arch-at91/at91_dbu.h|4 + > arch/arm/include/asm/arch-at91/clk.h |1 + > arch/arm/include/asm/arch-at91/hardware.h|2 + > arch/arm/include/asm/arch-at91/sama5d3.h | 212 > arch/arm/include/asm/arch-at91/sama5d3_smc.h | 79 > board/atmel/sama5d3xek/Makefile | 51 + > board/atmel/sama5d3xek/sama5d3xek.c | 275 ++ > boards.cfg |3 + > include/configs/sama5d3xek.h | 245 +++ > 16 files changed, 1522 insertions(+) > create mode 100644 arch/arm/cpu/armv7/at91/Makefile > create mode 100644 arch/arm/cpu/armv7/at91/clock.c > create mode 100644 arch/arm/cpu/armv7/at91/cpu.c > create mode 100644 arch/arm/cpu/armv7/at91/reset.c > create mode 100644 arch/arm/cpu/armv7/at91/sama5d3_devices.c > create mode 100644 arch/arm/cpu/armv7/at91/timer.c > create mode 100644 arch/arm/include/asm/arch-at91/sama5d3.h > create mode 100644 arch/arm/include/asm/arch-at91/sama5d3_smc.h > create mode 100644 board/atmel/sama5d3xek/Makefile > create mode 100644 board/atmel/sama5d3xek/sama5d3xek.c > create mode 100644 include/configs/sama5d3xek.h applied to u-boot-atmel/master, thanks! 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] [U-Boot,1/3] ARM: at91: fix and update README.at91 document
Dear Bo Shen, Bo Shen writes: >This patch implement following things > - The link no longer accessable > - Remove the error configuration command > - Update soldered data flash memory map > - Update at91sam9m10g45ek memory size to 128MiB > >Signed-off-by: Bo Shen > >--- >doc/README.at91 | 23 ++- > 1 file changed, 6 insertions(+), 17 deletions(-) applied to u-boot-atmel/master, thanks! 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] [U-Boot,3/3] ARM: at91: add NAND partition table and index
Dear Bo Shen, Bo Shen writes: >Add NAND partition table, EK board support boot up NAND flash using >the same NAND partition table > >Add Index in this file > >Signed-off-by: Bo Shen > >--- >doc/README.at91 | 21 - > 1 file changed, 20 insertions(+), 1 deletion(-) applied to u-boot-atmel/master, thanks! 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] [U-Boot,2/3] ARM: at91: add at91sam9x5 and sama5d3x information
Dear Bo Shen, Bo Shen writes: >This patch add following EK information > - at91sam9n12ek, at91sam9x5ek > - sama5d3xek > >Signed-off-by: Bo Shen > >--- >doc/README.at91 | 42 ++ > 1 file changed, 42 insertions(+) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] please pull u-boot-atmel/master
Dear Albert Aribaud, please pull the following changes from u-boot-atmel/master into u-boot-arm/master. The following changes since commit d0a51373131c4ba565a2391d5ed78b87c406ce98: at91sam9260ek: move board id setup to config header (2013-05-12 16:49:14 +0200) are available in the git repository at: git://git.denx.de/u-boot-atmel.git master for you to fetch changes up to 5ba444f092ae9f68a0bd1f53956be2e69d26cf61: ARM: at91: add NAND partition table and index (2013-05-21 11:54:21 +0200) Bo Shen (6): ARM: at91: add Atmel sama5d3 SoC new pmc register USB: ohci-at91: support sama5d3x devices ARM: atmel: add sama5d3xek support ARM: at91: fix and update README.at91 document ARM: at91: add at91sam9x5 and sama5d3x information ARM: at91: add NAND partition table and index MAINTAINERS |1 + arch/arm/cpu/armv7/at91/Makefile | 52 + arch/arm/cpu/armv7/at91/clock.c | 125 arch/arm/cpu/armv7/at91/cpu.c| 90 + arch/arm/cpu/armv7/at91/reset.c | 47 + arch/arm/cpu/armv7/at91/sama5d3_devices.c| 196 ++ arch/arm/cpu/armv7/at91/timer.c | 139 + arch/arm/include/asm/arch-at91/at91_dbu.h|4 + arch/arm/include/asm/arch-at91/at91_pmc.h| 23 +++ arch/arm/include/asm/arch-at91/clk.h |1 + arch/arm/include/asm/arch-at91/hardware.h|2 + arch/arm/include/asm/arch-at91/sama5d3.h | 212 arch/arm/include/asm/arch-at91/sama5d3_smc.h | 79 board/atmel/sama5d3xek/Makefile | 51 + board/atmel/sama5d3xek/sama5d3xek.c | 275 ++ boards.cfg |3 + doc/README.at91 | 84 ++-- drivers/usb/host/ohci-at91.c | 14 +- include/configs/sama5d3xek.h | 245 +++ 19 files changed, 1624 insertions(+), 19 deletions(-) create mode 100644 arch/arm/cpu/armv7/at91/Makefile create mode 100644 arch/arm/cpu/armv7/at91/clock.c create mode 100644 arch/arm/cpu/armv7/at91/cpu.c create mode 100644 arch/arm/cpu/armv7/at91/reset.c create mode 100644 arch/arm/cpu/armv7/at91/sama5d3_devices.c create mode 100644 arch/arm/cpu/armv7/at91/timer.c create mode 100644 arch/arm/include/asm/arch-at91/sama5d3.h create mode 100644 arch/arm/include/asm/arch-at91/sama5d3_smc.h create mode 100644 board/atmel/sama5d3xek/Makefile create mode 100644 board/atmel/sama5d3xek/sama5d3xek.c create mode 100644 include/configs/sama5d3xek.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 6/6] arm: mvf600: Add basic support for Vybrid MVF600TWR board
MVF600TWR is a board based on Vybrid MVF600 SoC. This patch adds basic support for Vybrid MVF600TWR board. Signed-off-by: Alison Wang Signed-off-by: Jason Jin Signed-off-by: TsiChung Liew --- Changes in v3: - Replace BOOT_FROM by BOOT_OFFSET - Enable CONFIG_OF_LIBFDT option - Add useful define instead of raw number - Use clrsetbits_le32 to set the single bits - Move setup_iomux_enet() to board_early_init_f and remove board_eth_init() - Remove redundant define - Move CONFIG_IOMUX_SHARE_CONF_REG to imx-regs.h Changes in v2: - Add an entry to MAINTAINERS file - Rename directory name 'vybird' to 'mvf600twr' - Use standard method to set gd->ram_size - Rewrite board_mmc_getcd() function - Remove useless undef - Remove hardcoded IP addresses and MAC addresses - Remove useless CONFIG_SYS_ defines - Define C structures and access C structures to set/read registers - Move CONFIG_MACH_TYPE to board configuration file - Use common iomux-v3 code MAINTAINERS| 4 + board/freescale/mvf600twr/Makefile | 39 board/freescale/mvf600twr/imximage.cfg | 33 +++ board/freescale/mvf600twr/mvf600twr.c | 413 + boards.cfg | 1 + include/configs/mvf600twr.h| 140 +++ 6 files changed, 630 insertions(+) create mode 100644 board/freescale/mvf600twr/Makefile create mode 100644 board/freescale/mvf600twr/imximage.cfg create mode 100644 board/freescale/mvf600twr/mvf600twr.c create mode 100644 include/configs/mvf600twr.h diff --git a/MAINTAINERS b/MAINTAINERS index c05433a..d32ac66 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1057,6 +1057,10 @@ Eric Nelson nitrogen6s i.MX6S 512MB nitrogen6s1gi.MX6S 1GB +Alison Wang + + mvf600twr MVF600 + - Unknown / orphaned boards: diff --git a/board/freescale/mvf600twr/Makefile b/board/freescale/mvf600twr/Makefile new file mode 100644 index 000..7416228 --- /dev/null +++ b/board/freescale/mvf600twr/Makefile @@ -0,0 +1,39 @@ +# +# Copyright 2013 Freescale Semiconductor, Inc. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).o + +COBJS := $(BOARD).o + +SRCS := $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) + +$(LIB):$(obj).depend $(OBJS) + $(call cmd_link_o_target, $(OBJS)) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/freescale/mvf600twr/imximage.cfg b/board/freescale/mvf600twr/imximage.cfg new file mode 100644 index 000..b00d4c1 --- /dev/null +++ b/board/freescale/mvf600twr/imximage.cfg @@ -0,0 +1,33 @@ +/* + * Copyright 2013 Freescale Semiconductor, Inc. + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not write to the Free Software + * Foundation Inc. 51 Franklin Street Fifth Floor Boston, + * MA 02110-1301 USA + * + * Refer docs/README.imxmage for more details about how-to configure + * and create imximage boot image + * + * The syntax is taken as close as possible with the kwbimage + */ +#include + +/* image version */ +IMAGE_VERSION 2 + +/* Boot Offset 0x400, valid for both SD and NAND boot */ +BOOT_OFFSETFLASH_OFFSET_STANDARD diff --git a/board/freescale/mvf600twr/mvf600twr.c b/board/freescale/mvf600twr/mvf600twr.c new file mode 100644 index 000..71ee12b --- /dev/null +++ b/board/freescale/mvf600twr/mvf60
[U-Boot] [PATCH v3 1/6] arm: mvf600: Add Vybrid MVF600 CPU support
This patch adds generic codes to support Freescale's Vybrid MVF600 CPU. It aligns Vybrid MVF600 platform with i.MX platform. As there are some differences between MVF600 and i.MX platforms, the specific codes are in the arch/arm/cpu/armv7/mvf600 directory. Signed-off-by: Alison Wang --- Changes in v3: - Rename the common functions and enums - Move the structure definitions to imx-regs.h Changes in v2: - Remove vybrid-common directory - Rename directory name 'vybrid' to 'mvf600' - Add generic.c file - Rewrite get_reset_cause() to make it readable - Remove reset_cpu(), and use the function in imx_watchdog.c - Rewrite timer.c file - Use vybrid_get_clock(VYBRID_UART_CLK) instead of vybrid_get_uartclk() - Remove lowlevel_init.S, and add clock_init() in board_early_init_f() - Remove useless CONFIG_SYS_ defines - Move CONFIG_MACH_TYPE to board configuration file - Define C structures and access C structures to set/read registers - Remove useless errata - Remove useless macros - Rename directory 'arch-vybrid' to 'arch-mvf600' Makefile| 2 +- arch/arm/cpu/armv7/mvf600/Makefile | 42 +++ arch/arm/cpu/armv7/mvf600/generic.c | 324 ++ arch/arm/cpu/armv7/mvf600/timer.c | 103 +++ arch/arm/include/asm/arch-mvf600/clock.h| 39 +++ arch/arm/include/asm/arch-mvf600/crm_regs.h | 225 +++ arch/arm/include/asm/arch-mvf600/imx-regs.h | 411 arch/arm/include/asm/arch-mvf600/mvf_pins.h | 92 +++ 8 files changed, 1237 insertions(+), 1 deletion(-) create mode 100644 arch/arm/cpu/armv7/mvf600/Makefile create mode 100644 arch/arm/cpu/armv7/mvf600/generic.c create mode 100644 arch/arm/cpu/armv7/mvf600/timer.c create mode 100644 arch/arm/include/asm/arch-mvf600/clock.h create mode 100644 arch/arm/include/asm/arch-mvf600/crm_regs.h create mode 100644 arch/arm/include/asm/arch-mvf600/imx-regs.h create mode 100644 arch/arm/include/asm/arch-mvf600/mvf_pins.h diff --git a/Makefile b/Makefile index c52f0f1..9df2138 100644 --- a/Makefile +++ b/Makefile @@ -341,7 +341,7 @@ ifneq ($(CONFIG_AM33XX)$(CONFIG_OMAP34XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(C LIBS-y += $(CPUDIR)/omap-common/libomap-common.o endif -ifneq (,$(filter $(SOC), mx25 mx27 mx5 mx6 mx31 mx35 mxs)) +ifneq (,$(filter $(SOC), mx25 mx27 mx5 mx6 mx31 mx35 mxs mvf600)) LIBS-y += arch/$(ARCH)/imx-common/libimx-common.o endif diff --git a/arch/arm/cpu/armv7/mvf600/Makefile b/arch/arm/cpu/armv7/mvf600/Makefile new file mode 100644 index 000..9232cd4 --- /dev/null +++ b/arch/arm/cpu/armv7/mvf600/Makefile @@ -0,0 +1,42 @@ +# +# Copyright 2013 Freescale Semiconductor, Inc. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(SOC).o + +COBJS += generic.o +COBJS += timer.o + +SRCS := $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) + +all: $(obj).depend $(LIB) + +$(LIB):$(OBJS) + $(call cmd_link_o_target, $(OBJS)) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/arch/arm/cpu/armv7/mvf600/generic.c b/arch/arm/cpu/armv7/mvf600/generic.c new file mode 100644 index 000..f47ab1e --- /dev/null +++ b/arch/arm/cpu/armv7/mvf600/generic.c @@ -0,0 +1,324 @@ +/* + * Copyright 2013 Freescale Semiconductor, Inc. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include +#include +#include +#include +#include +#i
Re: [U-Boot] [PATCH] arm: pxa: config option for PXA270 turbo mode
Dear Sergey Yanovich,
> PXA270 CPU has turbo mode. The mode is 2.5 times faster than the
> default run mode. Activating the mode early significantly speeds
> up boot process.
>
> Signed-off-by: Sergey Yanovich
What's the difference? Where does this macro get used ?
> ---
> arch/arm/cpu/pxa/pxa2xx.c |7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/cpu/pxa/pxa2xx.c b/arch/arm/cpu/pxa/pxa2xx.c
> index 09e8177..6c918ac 100644
> --- a/arch/arm/cpu/pxa/pxa2xx.c
> +++ b/arch/arm/cpu/pxa/pxa2xx.c
> @@ -32,6 +32,10 @@
> #include
> #include
>
> +#ifndef CONFIG_SYS_CLKCFG
> +#define CONFIG_SYS_CLKCFG0x0002
> +#endif
> +
> /* Flush I/D-cache */
> static void cache_flush(void)
> {
> @@ -244,7 +248,8 @@ void pxa_clock_setup(void)
> {
> writel(CONFIG_SYS_CKEN, CKEN);
> writel(CONFIG_SYS_CCCR, CCCR);
> - asm volatile("mcr p14, 0, %0, c6, c0, 0" : : "r"(2));
> + asm volatile("mcr p14, 0, %0, c6, c0, 0" : :
> + "r"(CONFIG_SYS_CLKCFG));
>
> /* enable the 32Khz oscillator for RTC and PowerManager */
> writel(OSCC_OON, OSCC);
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: pxa: PXA270 D-Cache as ram
Dear Sergey Yanovich, > 2.2.5.2 of Marvell PXA27x Processor Family Developers Manual says: > "The PXA27x processor cache configuration is identical to that of > the PXA255 processor." > > As a result, it is perfectly legitimate to use PXA25X > 'lock_cache_for_stack' on PXA27X as well. > > Signed-off-by: Sergey Yanovich > --- > arch/arm/cpu/pxa/start.S | 10 -- > include/configs/lp8x4x.h |5 +++-- > 2 files changed, 11 insertions(+), 4 deletions(-) Why would you need this on PXA27x ? Is SRAM not enough? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: pxa: PXA270 D-Cache as ram
Dear Marek Vasut, On Tue, 2013-05-21 at 12:39 +0200, Marek Vasut wrote: > > 2.2.5.2 of Marvell PXA27x Processor Family Developers Manual says: > > "The PXA27x processor cache configuration is identical to that of > > the PXA255 processor." > > > > As a result, it is perfectly legitimate to use PXA25X > > 'lock_cache_for_stack' on PXA27X as well. > Why would you need this on PXA27x ? Is SRAM not enough? SRAM is battery-backup. It can be used as a ultra-fast persistent storage in OS. Wasting a quater of it just to boot the system isn't the best choice. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: pxa: Add support for ICP DAS LP-8x4x
Dear Sergey Yanovich, > LP-8x4x is a programmable automation controller by ICP DAS. It is > shipped with outdated U-Boot v1.3.0 > > This patch adds enough supports to boot the board: > - 128M of 128M SDRAM > - 32M of 48M NOR Flash memory > - 1 of 4 Serial consoles (PXA FFUART) > - 2 of 2 Ethernet controllers (DM9000) > > Signed-off-by: Sergey Yanovich > Series-to: u-boot > Series-cc: marex Looks good. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: pxa: config option for PXA270 turbo mode
Dear Marek Vasut, On Tue, 2013-05-21 at 12:35 +0200, Marek Vasut wrote: > > PXA270 CPU has turbo mode. The mode is 2.5 times faster than the > > default run mode. Activating the mode early significantly speeds > > up boot process. > What's the difference? Where does this macro get used ? Difference -- approx. 2.5 times faster system. Who uses it -- ex. LP-8x4x board, support for which I am trying to merge in a separate patch. Any PXA27X board can use it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: pxa: PXA270 D-Cache as ram
Dear Sergey Yanovich, > Dear Marek Vasut, > > On Tue, 2013-05-21 at 12:39 +0200, Marek Vasut wrote: > > > 2.2.5.2 of Marvell PXA27x Processor Family Developers Manual says: > > > "The PXA27x processor cache configuration is identical to that of > > > the PXA255 processor." > > > > > > As a result, it is perfectly legitimate to use PXA25X > > > 'lock_cache_for_stack' on PXA27X as well. > > > > Why would you need this on PXA27x ? Is SRAM not enough? > > SRAM is battery-backup. SRAM is just the in-CPU bit of fast RAM. What do you mean by "battery-backup" ? > It can be used as a ultra-fast persistent > storage in OS. Wasting a quater of it just to boot the system isn't the > best choice. The SRAM is used for stack in U-Boot until you leave board_init_f, then the stack is relocated to DRAM. The OS can use SRAM as needed, U-Boot is no longer operational once you load subsequent OS. What's the problem? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: pxa: config option for PXA270 turbo mode
Dear Sergey Yanovich, > Dear Marek Vasut, > > On Tue, 2013-05-21 at 12:35 +0200, Marek Vasut wrote: > > > PXA270 CPU has turbo mode. The mode is 2.5 times faster than the > > > default run mode. Activating the mode early significantly speeds > > > up boot process. > > > > What's the difference? Where does this macro get used ? > > Difference -- approx. 2.5 times faster system. > > Who uses it -- ex. LP-8x4x board, support for which I am trying to merge > in a separate patch. Any PXA27X board can use it. Why don't you enable it globally then ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: pxa: config option for PXA270 turbo mode
Dear Marek Vasut, On Tue, 2013-05-21 at 12:55 +0200, Marek Vasut wrote: > > Difference -- approx. 2.5 times faster system. > > > > Who uses it -- ex. LP-8x4x board, support for which I am trying to merge > > in a separate patch. Any PXA27X board can use it. > > Why don't you enable it globally then ? It increases power consumption proportionally. Not everyone would agree with this. Especially those with portable devices may rightfully object. It is up to you to enable it globally. I could alter the patch to switch turbo mode on by default and provide an option to disable it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Exynos5: clock: Update the equation to calculate PLL output frequency
Dear Akshay Saraswat,
On 22/03/13 21:26, Akshay Saraswat wrote:
> According to the latest exynos5 user manual, the equation for
> calculating PLL output was changed to
> FOUT= MDIV x FIN/(PDIV x 2^SDIV)
> earlier it was
> FOUT= MDIV x FIN/(PDIV x 2^(SDIV -1))
> So updating the clock code accordingly.
>
> Signed-off-by: Hatim Ali
> Signed-off-by: Akshay Saraswat
> ---
> arch/arm/cpu/armv7/exynos/clock.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/exynos/clock.c
> b/arch/arm/cpu/armv7/exynos/clock.c
> index 956427c..5299bc7 100644
> --- a/arch/arm/cpu/armv7/exynos/clock.c
> +++ b/arch/arm/cpu/armv7/exynos/clock.c
> @@ -73,10 +73,8 @@ static int exynos_get_pll_clk(int pllreg, unsigned int r,
> unsigned int k)
> /* FOUT = (MDIV + K / 1024) * FIN / (PDIV * 2^SDIV) */
> fout = (m + k / 1024) * (freq / (p * (1 << s)));
> } else {
> - if (s < 1)
> - s = 1;
> - /* FOUT = MDIV * FIN / (PDIV * 2^(SDIV - 1)) */
> - fout = m * (freq / (p * (1 << (s - 1;
> + /* FOUT = MDIV * FIN / (PDIV * 2^SDIV) */
> + fout = m * (freq / (p * (1 << s)));
> }
>
> return fout;
>
applied to u-boot-samsung.
Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] fw_env: fix building w/out a config.h
On 12/15/2012 07:04 PM, Joe Hershberger wrote:
>> -#ifndef CONFIG_BOOTCOMMAND
>> -#define CONFIG_BOOTCOMMAND
>>\
>> - "bootp; "
>>\
>> - "setenv bootargs root=/dev/nfs nfsroot=${serverip}:${rootpath} "
>>\
>> - "ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off;
>> " \
>> - "bootm"
>> -#endif
>> -
>
> I agree that some of this should be cleaned up, but not as a result of
> removing the config.h.
>
>> extern int fw_printenv(int argc, char *argv[]);
>> extern char *fw_getenv (char *name);
>> extern int fw_setenv (int argc, char *argv[]);
>> --
>> 1.7.12.4
>>
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>
> NAK
Mike, any chance that you might find some time to rework this patch for
mainline acceptance?
BTW: I'm using this patch for Yocto builds of the Linux environment
tools. Without it, building fails.
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: pxa: config option for PXA270 turbo mode
Dear Sergey Yanovich, > Dear Marek Vasut, > > On Tue, 2013-05-21 at 12:55 +0200, Marek Vasut wrote: > > > Difference -- approx. 2.5 times faster system. > > > > > > Who uses it -- ex. LP-8x4x board, support for which I am trying to > > > merge in a separate patch. Any PXA27X board can use it. > > > > Why don't you enable it globally then ? > > It increases power consumption proportionally. Not everyone would agree > with this. Especially those with portable devices may rightfully object. > > It is up to you to enable it globally. I could alter the patch to switch > turbo mode on by default and provide an option to disable it. Actually, I wonder if Linux's cpufreq still does depend on bootloader speed settings. Especially the turbo bit. Can you please check that? It'd be interesting to know ... I'd say enable it by default ... I probably have all the PXA devices supported in U-Boot and I'm quite sure none of them will mind ;-) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: pxa: config option for PXA270 turbo mode
[..] > Actually, I wonder if Linux's cpufreq still does depend on bootloader speed > settings. Especially the turbo bit. Can you please check that? It'd be > interesting to know ... > > I'd say enable it by default ... I probably have all the PXA devices > supported in U-Boot and I'm quite sure none of them will mind ;-) Still, I'm surprised it wasn't enabled. I recall seeing it enabled. Weird ... Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: pxa: PXA270 D-Cache as ram
Dear Marek Vasut, On Tue, 2013-05-21 at 12:54 +0200, Marek Vasut wrote: > SRAM is just the in-CPU bit of fast RAM. What do you mean by "battery-backup" > ? Yes, you are right. It is 'for high speed code or data storage preserved during low-power states' using a quote from PXA270 EMTS (top of page 1). Battery-backup is optional. I mixed PXA270 and LP-8x4x specs. > > It can be used as a ultra-fast persistent > > storage in OS. Wasting a quater of it just to boot the system isn't the > > best choice. > > The SRAM is used for stack in U-Boot until you leave board_init_f, then the > stack is relocated to DRAM. The OS can use SRAM as needed, U-Boot is no > longer > operational once you load subsequent OS. What's the problem? Anyway, SRAM preserves its state when power is off. Poweroff time could be in years with a backup battery. In addition, D-Cache is an order of magnitude faster than SRAM (approx. 9 times) for both reads and writes. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Exynos: uart: s5p: enabling the uart tx/rx fifo
On 22/03/13 15:33, Akshay Saraswat wrote: > This patch enables the uart tx/rx fifo. Now that fifo is enabled, > the uart read/write functions are modfied to check the UFSTAT register > for fifo status instead of UTRSTAT (as required with fifo's enabled). > Tested by booting linux kernel. Before enabling tx/rx fifo > "Uncompressing linux" message is garbled and after enabling it is proper. > > Signed-off-by: Alim Akhtar > Signed-off-by: Akshay Saraswat > --- > drivers/serial/serial_s5p.c | 13 + > 1 file changed, 9 insertions(+), 4 deletions(-) > applied to u-boot-samsung. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: pxa: PXA270 D-Cache as ram
Dear Sergey Yanovich, > Dear Marek Vasut, > > On Tue, 2013-05-21 at 12:54 +0200, Marek Vasut wrote: > > SRAM is just the in-CPU bit of fast RAM. What do you mean by > > "battery-backup" ? > > Yes, you are right. It is 'for high speed code or data storage preserved > during low-power states' using a quote from PXA270 EMTS (top of page 1). > Battery-backup is optional. I mixed PXA270 and LP-8x4x specs. Yes, it's just an in-CPU RAM. > > > It can be used as a ultra-fast persistent > > > storage in OS. Wasting a quater of it just to boot the system isn't the > > > best choice. > > > > The SRAM is used for stack in U-Boot until you leave board_init_f, then > > the stack is relocated to DRAM. The OS can use SRAM as needed, U-Boot is > > no longer operational once you load subsequent OS. What's the problem? > > Anyway, SRAM preserves its state when power is off. Poweroff time could > be in years with a backup battery. In addition, D-Cache is an order of > magnitude faster than SRAM (approx. 9 times) for both reads and writes. Is there any measurable difference between using DCache and SRAM? Do you have any evidence that a speedup happens? Still, the SRAM/DCache is only used until you leave board_init_f(), then it's all DRAM. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: pxa: config option for PXA270 turbo mode
PXA270 CPU has turbo mode. The mode is 2.5 times faster than the
default run mode. Activating the mode early significantly speeds
up boot process.
Signed-off-by: Sergey Yanovich
---
Changes for v2:
- activate turbo mode and fast bus by default
---
arch/arm/cpu/pxa/pxa2xx.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/pxa/pxa2xx.c b/arch/arm/cpu/pxa/pxa2xx.c
index 09e8177..c874ec0 100644
--- a/arch/arm/cpu/pxa/pxa2xx.c
+++ b/arch/arm/cpu/pxa/pxa2xx.c
@@ -32,6 +32,10 @@
#include
#include
+#ifndef CONFIG_SYS_CLKCFG
+#define CONFIG_SYS_CLKCFG 0x000b
+#endif
+
/* Flush I/D-cache */
static void cache_flush(void)
{
@@ -244,7 +248,8 @@ void pxa_clock_setup(void)
{
writel(CONFIG_SYS_CKEN, CKEN);
writel(CONFIG_SYS_CCCR, CCCR);
- asm volatile("mcr p14, 0, %0, c6, c0, 0" : : "r"(2));
+ asm volatile("mcr p14, 0, %0, c6, c0, 0" : :
+ "r"(CONFIG_SYS_CLKCFG));
/* enable the 32Khz oscillator for RTC and PowerManager */
writel(OSCC_OON, OSCC);
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: pxa: PXA270 D-Cache as ram
Dear Marek Vasut, On Tue, 2013-05-21 at 13:38 +0200, Marek Vasut wrote: > Yes, it's just an in-CPU RAM. Well, it is not 'just' RAM. It preserves its state during deep sleep and power off modes. > > Anyway, SRAM preserves its state when power is off. Poweroff time could > > be in years with a backup battery. In addition, D-Cache is an order of > > magnitude faster than SRAM (approx. 9 times) for both reads and writes. > > Is there any measurable difference between using DCache and SRAM? Do you have > any evidence that a speedup happens? I haven't done any special profiling. I am just relying on PXA270 EMTS table 6-14. The table says SRAM reads take 9 cycles, writes take 7 cycles. D-Cache operations take 1 cycle. > Still, the SRAM/DCache is only used until you leave board_init_f(), then it's > all DRAM. Yes, the patch as it is will only affects relocation speed and preserve SRAM from corruption. The speed gain can also be applied to uImage copying/unpacking, but that requires deeper understanding than I have at the moment. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM v7: Flush icache when executing a program with go
Dear Henrik Nordström, In message <1368792981.765.21.camel@localhost> you wrote: > > > There is a common, architecture-independent C API that implements > > cache flushing/invalidation; please re-read the summary at [1] > > Sorry I missed that discussion. Had a bit too much mail for a while. No problem; that's why I pointed you to the sumnmary (and the rest of the thread). > > The cache commands currently do not support subcommands for flushing > > / invalidating the caches. See again [1]. > > From what I see the cache commands do have a sub commands for flushing. > > "icache flush" calls icache_invalidate_all(). > > "dcache flush" calls flush_dcache_all(). Indeed. I was not aware of this :-( > but imho the user shouldn't really need to care for these and is why I > hooked into the go command. In this case you should use the common C API. > I don't see much of a performance problem with a automatic full cache > flush when using the go command on platforms with incoherent caches. In > most use cases it's not very different from the bootm command which also > needs to do the same (and using a similar hooking mechanism as what I > used for go, but not saying that is a good thing) No. bootm knows exactly the location and size of the image, so it is sufficient to flush / invalidate a part of the memory, usually a pretty small one compared to the total RAM size. > And I do not think there needs to be commands for flushing specific > regions other than for testing. Region based flushing is better done by > code which knows what is needed. It's hard for users to get this right > as most times it works anyway. The code should know which ranges need flushing, not the user. 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 "Now here's something you're really going to like!" - Rocket J. Squirrel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] load file to memory in standalone program
Dear Scott A, In message you wrote: > > Hi,I am attempting to read a set of files from the fat file system into a > location in memory.This is easy using the command interface using somethin > g likefatload mmc 0:1 0x4800 file.txt > However i want to do this in a standalone program. Is there a function call > available to do this in a standalone program.if so could someone give an e > xample. > Note: i tried do_fat_fsload function call however compiling threw undefined > reference. If this is the correct method maybe i am just using it wrong. No, such functionality is not available in standalone programs. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A failure will not appear until a unit has passed final inspection. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] EXYNOS: SPI: Support SPI_PREAMBLE mode
Dear Rajeshwari Shinde,
On 12/05/13 00:04, Simon Glass wrote:
> From: Rajeshwari Shinde
>
> Support interfaces with a preamble before each received message.
>
> We handle this when the client has requested a SPI_XFER_END, meaning
> that we must close of the transaction. In this case we read until we
> see the preamble (or a timeout occurs), skipping all data before and
> including the preamble. The client will receive only data bytes after
> the preamble.
>
> Signed-off-by: Simon Glass
> Signed-off-by: Rajeshwari Shinde
> ---
> Changes in v2:
> - Remove preamable_count variable which is not really needed
> - Fix checkpatch warning (multiple assignments)
>
> drivers/spi/exynos_spi.c | 62
> +---
> 1 file changed, 54 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c
> index 607e1cd..b7b2ea5 100644
> --- a/drivers/spi/exynos_spi.c
> +++ b/drivers/spi/exynos_spi.c
> @@ -51,6 +51,7 @@ struct exynos_spi_slave {
> unsigned int mode;
> enum periph_id periph_id; /* Peripheral ID for this device */
> unsigned int fifo_size;
> + int skip_preamble;
> };
>
> static struct spi_bus *spi_get_bus(unsigned dev_index)
> @@ -105,6 +106,8 @@ struct spi_slave *spi_setup_slave(unsigned int busnum,
> unsigned int cs,
> else
> spi_slave->fifo_size = 256;
>
> + spi_slave->skip_preamble = 0;
> +
> spi_slave->freq = bus->frequency;
> if (max_hz)
> spi_slave->freq = min(max_hz, spi_slave->freq);
> @@ -217,17 +220,23 @@ static void spi_request_bytes(struct exynos_spi *regs,
> int count)
> writel(count | SPI_PACKET_CNT_EN, ®s->pkt_cnt);
> }
>
> -static void spi_rx_tx(struct exynos_spi_slave *spi_slave, int todo,
> - void **dinp, void const **doutp)
> +static int spi_rx_tx(struct exynos_spi_slave *spi_slave, int todo,
> + void **dinp, void const **doutp, unsigned long flags)
> {
> struct exynos_spi *regs = spi_slave->regs;
> uchar *rxp = *dinp;
> const uchar *txp = *doutp;
> int rx_lvl, tx_lvl;
> uint out_bytes, in_bytes;
> + int toread;
> + unsigned start = get_timer(0);
> + int stopping;
>
> out_bytes = in_bytes = todo;
>
> + stopping = spi_slave->skip_preamble && (flags & SPI_XFER_END) &&
> + !(spi_slave->mode & SPI_SLAVE);
> +
> /*
>* If there's something to send, do a software reset and set a
>* transaction size.
> @@ -238,6 +247,7 @@ static void spi_rx_tx(struct exynos_spi_slave *spi_slave,
> int todo,
>* Bytes are transmitted/received in pairs. Wait to receive all the
>* data because then transmission will be done as well.
>*/
> + toread = in_bytes;
please add blank line here.
> while (in_bytes) {
> int temp;
>
> @@ -250,13 +260,41 @@ static void spi_rx_tx(struct exynos_spi_slave
> *spi_slave, int todo,
> }
> if (rx_lvl > 0 && in_bytes) {
I think, in_bytes is always true.
It's a redundant checking.
> temp = readl(®s->rx_data);
> - if (rxp)
> + if (!rxp && !stopping) {
> + in_bytes--;
> + } else if (spi_slave->skip_preamble) {
> + if (temp == SPI_PREAMBLE_END_BYTE) {
> + spi_slave->skip_preamble = 0;
> + stopping = 0;
> + }
> + } else {
> *rxp++ = temp;
> - in_bytes--;
> + in_bytes--;
> + }
> + toread--;
> + }
I think, this if statement is not logical.
The checking condition is differ, so it looks confused.
How about this?
+ temp = readl(®s->rx_data);
+ if (spi_slave->skip_preamble) {
+ if (temp == SPI_PREAMBLE_END_BYTE) {
+ spi_slave->skip_preamble = 0;
+ stopping = 0;
+ }
+ } else {
+ if (rxp || stopping)
+ *rxp++ = temp;
+ in_bytes--;
+ }
+
+ toread--;
> + /*
> + * We have run out of input data, but haven't read enough
> + * bytes after the preamble yet. Read some more, and make
> + * sure that we transmit dummy bytes too, to keep things
> + * going.
> + */
This comment is what for?
please move this comment into the brace.
> + else if (in_bytes && !toread) {
in_bytes.. ditto.
And plea
Re: [U-Boot] load file to memory in standalone program
Dear Henrik, In message <1368920138.23379.14.camel@localhost> you wrote: > > I think it would be a great addition to add generic filesystem > operations to the standalone API. The fs_read() and fs_write() functions > should be possible to export via the standalone API as-is, but should > probably be wrapped a little bit to select which filesystem/partition to > operate on, similar to do_load() but without the u-boot env magics or > variable arguments. Technically you may be right. The reason why we intentionally maintain a very lean interface to standalone programs is that we allow such applications to be distributed even under non-GPL licenses. If you need more fancy features, just add your code to U-Boot and distribute it under GPL. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de In a business, marketroids, salespukes, and lawyers have different goals from those who actually do work and produce something. Usually, is is the former who triumph over the latter, due to the simple rule that those who print the money make the rules. -- Tom Christiansen in <5jdcls$b04$2...@csnews.cs.colorado.edu> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM v7: Flush icache when executing a program with go
Dear Kuo-Jung Su, In message you wrote: > > How about making the weak aliased arch_preboot_os() global, and then > get it invoked > in both bootm & go? > It looks much pretty to me, and we don't even worry about the i-cache issues. That would not really help as it would be architecure specific, so it does not really solve the problem buty instead create new ones like incompatible code & behaviour. 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 Include the success of others in your dreams for your own success. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] common: Add CCACHE variable to allow use of ccache
Dear Marek Vasut, In message <1369070715-9585-2-git-send-email-ma...@denx.de> you wrote: > Prefix HOSTCC and CC with CCACHE variable to allow easy use of ccache. > In case the user wants to use ccache, exporting CCACHE=ccache will do > the trick. It is of course possible to either make the cross-compiler > name into a shellscript which invokes the ccache and the compiler, but > setting this variable makes use of ccache easier and more convenient. ... > -AS = $(CROSS_COMPILE)as > +AS = $(CCACHE) $(CROSS_COMPILE)as > > # Always use GNU ld > LD = $(shell if $(CROSS_COMPILE)ld.bfd -v > /dev/null 2>&1; \ > then echo "$(CROSS_COMPILE)ld.bfd"; else echo > "$(CROSS_COMPILE)ld"; fi;) > > -CC = $(CROSS_COMPILE)gcc > +CC = $(CCACHE) $(CROSS_COMPILE)gcc > CPP = $(CC) -E Why not for CPP ? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The use of Microsoft crippleware systems is a sin that carries with it its own punishment. -- Tom Christiansen in <6bo3fr$pj8$5...@csnews.cs.colorado.edu> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] common: Use separate dirs for each board for ccache
Dear Marek Vasut,
In message <1369070715-9585-3-git-send-email-ma...@denx.de> you wrote:
> + # Use per-board CCACHE directory
> + if [ "x${CCACHE}" != "x" ] ; then
Why not simply:
if [ "${CCACHE}" ] ; then
?
> + export CCACHE_DIR="`${CCACHE} -s | grep "^cache directory" | \
> + tr -s " " | cut -d " " -f 3`/u-boot/${target}" ;
> + mkdir -p "${CCACHE_DIR}"
> + fi
How can I cleanup all the mess of created files and directories after
a build?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Do not simplify the design of a program if a way can be found to make
it complex and wonderful.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools/fw_env: use fsync to ensure that data is physically stored
Dear Michael Heimpold, In message <1369078482-5863-1-git-send-email-m...@heimpold.de> you wrote: > Closing a file descriptor does not guarantee that the data has been > successfully saved to disk, as the kernel might defer the write. What is the exact problem you are trying to fix? I mean, when exactly does adding the sync play a role? 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 Old programmers never die, they just branch to a new address. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM v7: Flush icache when executing a program with go
Hello, On Thu, May 16, 2013 at 5:37 PM, Henrik Nordström wrote: > Or maybe just punt it. If you are on an arch with incoherent caches then > make sure to make use of the cache command to flush caches and maybe > even disable caches before using go. This is indeed the behaviour one would expect from a bootloader. To my understanding also enabling d-cache on ARM has no effect as long as the MMU is not turned on so I totally miss the point. Greetings ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] Add Arndale board support
On 26/03/13 18:37, Inderpal Singh wrote: > The Arndale board is based on samsung's exynos5250 SOC. > > First patch just removes the redundant SPI configs from common exynos5250 > config file. Second patch moves the board specific configs to board specific > config file. The third adds the andale board support. > > This patchset depends on [1] for tzpc initialization, on [2] for copying > u-boot to RAM from spl, and on first 6 patches of [3] for mmc support. > > [1] http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/156168 > [2] http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/156272 > [3] http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/155368 > > Inderpal Singh (3): > exynos5250: remove redundant SPI related configs > exynos5250: move board specific configs to board specific config file > exynos5250: Add arndale board support > > MAINTAINERS |4 + > board/samsung/arndale/Makefile | 54 +++ > board/samsung/arndale/arndale.c | 117 ++ > board/samsung/arndale/arndale_spl.c | 66 +++ > board/samsung/arndale/clock_init.c | 655 > ++ > board/samsung/arndale/clock_init.h | 149 +++ > board/samsung/arndale/dmc_common.c | 199 + > board/samsung/arndale/dmc_init_ddr3.c| 228 +++ > board/samsung/arndale/lowlevel_init.S| 92 + > board/samsung/arndale/setup.h| 569 ++ > board/samsung/dts/exynos5250-arndale.dts | 36 ++ > boards.cfg |1 + > include/configs/arndale.h| 39 ++ > include/configs/exynos5250-dt.h | 29 +- > include/configs/smdk5250.h | 12 +- > include/configs/snow.h | 12 +- > tools/Makefile |2 + > 17 files changed, 2232 insertions(+), 32 deletions(-) > create mode 100644 board/samsung/arndale/Makefile > create mode 100644 board/samsung/arndale/arndale.c > create mode 100644 board/samsung/arndale/arndale_spl.c > create mode 100644 board/samsung/arndale/clock_init.c > create mode 100644 board/samsung/arndale/clock_init.h > create mode 100644 board/samsung/arndale/dmc_common.c > create mode 100644 board/samsung/arndale/dmc_init_ddr3.c > create mode 100644 board/samsung/arndale/lowlevel_init.S > create mode 100644 board/samsung/arndale/setup.h > create mode 100644 board/samsung/dts/exynos5250-arndale.dts > create mode 100644 include/configs/arndale.h > Patch 1,2 looks good. But please rebase. please split patch 3 to another patchset. And please check Wolfgang's review. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Issue in DWMMC in mainline
Hi All, I use the DWMMC driver in u-boot mainline on exynos board and face the following issue. I do a mmc rescan 3 times, then fourth time I get a DATA ERROR, which is due to FIFO underun/overun, after which I don't even get Command done interrupt. Later on the mmcinfo value also is displayed wrong. Please do let me know if anybody have a solution for same. -- Thanks and Regards, Rajeshwari Shinde ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] drivers:power:max77686: add function to set voltage and mode
This patch add new functions to pmic max77686 to set voltage and mode.
Signed-off-by: Piotr Wilczek
Signed-off-by: Kyungmin Park
CC: Minkyu Kang
CC: Rajeshwari Shinde
Acked-by: Rajeshwari Shinde
---
Changes in v2:
- changed printf to debug
drivers/power/pmic/pmic_max77686.c | 186
include/power/max77686_pmic.h | 11 +++
2 files changed, 197 insertions(+)
diff --git a/drivers/power/pmic/pmic_max77686.c
b/drivers/power/pmic/pmic_max77686.c
index 7fcb4c0..dabd6b6 100644
--- a/drivers/power/pmic/pmic_max77686.c
+++ b/drivers/power/pmic/pmic_max77686.c
@@ -30,6 +30,192 @@
DECLARE_GLOBAL_DATA_PTR;
+static const char max77686_buck_addr[] = {
+ 0xff, 0x10, 0x12, 0x1c, 0x26, 0x30, 0x32, 0x34, 0x36, 0x38
+};
+
+static unsigned int max77686_ldo_volt2hex(int ldo, ulong uV)
+{
+ unsigned int hex = 0;
+ const unsigned int max_hex = 0x3f;
+
+ switch (ldo) {
+ case 1:
+ case 2:
+ case 6:
+ case 7:
+ case 8:
+ case 15:
+ hex = (uV - 80) / 25000;
+ break;
+ default:
+ hex = (uV - 80) / 5;
+ }
+
+ if (0 <= hex && hex <= max_hex)
+ return hex;
+
+ debug("%s: %ld is wrong voltage value for LDO%d\n", __func__, uV, ldo);
+ return 0;
+}
+
+int max77686_set_ldo_voltage(struct pmic *p, int ldo, ulong uV)
+{
+ unsigned int val, ret, hex, adr, mask;
+
+ if (ldo < 1 && 26 < ldo) {
+ printf("%s: %d is wrong ldo number\n", __func__, ldo);
+ return -1;
+ }
+
+ adr = MAX77686_REG_PMIC_LDO1CTRL1 + ldo - 1;
+ mask = 0x3f;
+ hex = max77686_ldo_volt2hex(ldo, uV);
+
+ if (!hex)
+ return -1;
+
+ ret = pmic_reg_read(p, adr, &val);
+ val &= ~mask;
+ val |= hex;
+ ret |= pmic_reg_write(p, adr, val);
+
+ return ret;
+}
+
+int max77686_set_ldo_mode(struct pmic *p, int ldo, char opmode)
+{
+ unsigned int val, ret, mask, adr, mode;
+
+ if (ldo < 1 && 26 < ldo) {
+ printf("%s: %d is wrong ldo number\n", __func__, ldo);
+ return -1;
+ }
+
+ adr = MAX77686_REG_PMIC_LDO1CTRL1 + ldo - 1;
+
+ /* mask */
+ mask = 0xc0;
+
+ /* mode */
+ if (opmode == OPMODE_OFF) {
+ mode = 0x00;
+ } else if (opmode == OPMODE_STANDBY) {
+ switch (ldo) {
+ case 2:
+ case 6:
+ case 7:
+ case 8:
+ case 10:
+ case 11:
+ case 12:
+ case 14:
+ case 15:
+ case 16:
+ mode = 0x40;
+ break;
+ default:
+ mode = 0xff;
+ }
+ } else if (opmode == OPMODE_LPM) {
+ mode = 0x80;
+ } else if (opmode == OPMODE_ON) {
+ mode = 0xc0;
+ } else {
+ mode = 0xff;
+ }
+
+ if (mode == 0xff) {
+ printf("%s: %d is not supported on LDO%d\n",
+ __func__, opmode, ldo);
+ return -1;
+ }
+
+ ret = pmic_reg_read(p, adr, &val);
+ val &= ~mask;
+ val |= mode;
+ ret |= pmic_reg_write(p, adr, val);
+
+ return ret;
+}
+
+int max77686_set_buck_mode(struct pmic *p, int buck, char opmode)
+{
+ unsigned int val, ret, mask, adr, size, mode;
+
+ size = sizeof(max77686_buck_addr) / sizeof(*max77686_buck_addr);
+ if (buck >= size) {
+ printf("%s: %d is wrong buck number\n", __func__, buck);
+ return -1;
+ }
+
+ adr = max77686_buck_addr[buck];
+
+ /* mask */
+ switch (buck) {
+ case 2:
+ case 3:
+ case 4:
+ mask = 0x30;
+ break;
+ default:
+ mask = 0x03;
+ }
+
+ /* mode */
+ if (opmode == OPMODE_OFF) {
+ mode = 0x00;
+ } else if (opmode == OPMODE_STANDBY) {
+ switch (buck) {
+ case 1:
+ mode = 0x01;
+ break;
+ case 2:
+ case 3:
+ case 4:
+ mode = 0x10;
+ break;
+ default:
+ mode = 0xff;
+ }
+ } else if (opmode == OPMODE_LPM) {
+ switch (buck) {
+ case 2:
+ case 3:
+ case 4:
+ mode = 0x20;
+ break;
+ default:
+ mode = 0xff;
+ }
+ } else if (opmode == OPMODE_ON) {
+ switch (buck) {
+ case 2:
+ case 3:
+ case 4:
+ mode = 0x30;
+ break;
+ default:
+
[U-Boot] [PATCH] drivers:power:max77693: add support for new multi function pmic max77693
This patch add support for new multi function pmic max77693.
The driver is split into three modules: pmic, muic and fuelgage.
Signed-off-by: Piotr Wilczek
Signed-off-by: Kyungmin Park
CC: Minkyu Kang
---
Makefile |1 +
drivers/power/mfd/Makefile| 49 +
drivers/power/mfd/fg_max77693.c | 143 +
drivers/power/mfd/muic_max77693.c | 91 +++
drivers/power/mfd/pmic_max77693.c | 110
include/power/max77693_fg.h | 65 +
include/power/max77693_muic.h | 90 +++
include/power/max77693_pmic.h | 56 +++
8 files changed, 605 insertions(+)
create mode 100644 drivers/power/mfd/Makefile
create mode 100644 drivers/power/mfd/fg_max77693.c
create mode 100644 drivers/power/mfd/muic_max77693.c
create mode 100644 drivers/power/mfd/pmic_max77693.c
create mode 100644 include/power/max77693_fg.h
create mode 100644 include/power/max77693_muic.h
create mode 100644 include/power/max77693_pmic.h
diff --git a/Makefile b/Makefile
index c52f0f1..ea2cc11 100644
--- a/Makefile
+++ b/Makefile
@@ -298,6 +298,7 @@ LIBS-y += drivers/pci/libpci.o
LIBS-y += drivers/pcmcia/libpcmcia.o
LIBS-y += drivers/power/libpower.o \
drivers/power/fuel_gauge/libfuel_gauge.o \
+ drivers/power/mfd/libmfd.o \
drivers/power/pmic/libpmic.o \
drivers/power/battery/libbattery.o
LIBS-y += drivers/spi/libspi.o
diff --git a/drivers/power/mfd/Makefile b/drivers/power/mfd/Makefile
new file mode 100644
index 000..2ab3b00
--- /dev/null
+++ b/drivers/power/mfd/Makefile
@@ -0,0 +1,49 @@
+#
+# Copyright (C) 2013 Samsung Electronics
+# Piotr Wilczek
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB:= $(obj)libmfd.o
+
+COBJS-$(CONFIG_POWER_PMIC_MAX77693) += pmic_max77693.o
+COBJS-$(CONFIG_POWER_MUIC_MAX77693) += muic_max77693.o
+COBJS-$(CONFIG_POWER_FG_MAX77693) += fg_max77693.o
+
+COBJS := $(COBJS-y)
+SRCS := $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+
+all: $(LIB)
+
+$(LIB):$(obj).depend $(OBJS)
+ $(call cmd_link_o_target, $(OBJS))
+
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+
diff --git a/drivers/power/mfd/fg_max77693.c b/drivers/power/mfd/fg_max77693.c
new file mode 100644
index 000..0004cf8
--- /dev/null
+++ b/drivers/power/mfd/fg_max77693.c
@@ -0,0 +1,143 @@
+/*
+ * Copyright (C) 2013 Samsung Electronics
+ * Piotr Wilczek
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int max77693_get_vcell(u32 *vcell)
+{
+ u16 value;
+ u8 ret;
+
+ ret = i2c_read(MAX77693_FUEL_I2C_ADDR, MAX77693_VCELL, 1,
+ (u8 *)&value, 2);
+ if (ret)
+ return -1;
+
+ *vcell = (u32)(value >> 3);
+ *vcell = *vcell * 625;
+
+ return 0;
+}
+
+static int max77693_get_soc(u32 *soc)
+{
+ u16 value;
+ u8 ret;
+
+ ret = i2c_read(MAX77693_FUEL_I2C_ADDR, MAX77693_VFSOC, 1,
+ (u8 *)&value, 2);
+ if (ret)
+ return -1;
+
+ *soc = (u32)(value >> 8);
+
+ return
Re: [U-Boot] [PATCH 1/2 V2] SF: Add driver for Gigabyte device GD25LQ and GD25Q64B
Hi,
I think this reviewed already, but have a very few comments.
On Wed, Jan 23, 2013 at 12:00 PM, Rajeshwari Shinde
wrote:
> This patch adds driver for the gigabyte devices
> GD25LQ and GD25Q64B required for Snow Board.
>
> Signed-off-by: Rajeshwari Shinde
> ---
> Changes in V2:
> - Added U-Boot copyright header to gigadevice.c
> - Removed unnecessary blank lines.
> drivers/mtd/spi/Makefile |1 +
> drivers/mtd/spi/gigadevice.c | 81
> ++
> drivers/mtd/spi/spi_flash.c |3 +
> drivers/mtd/spi/spi_flash_internal.h |1 +
> 4 files changed, 86 insertions(+), 0 deletions(-)
> create mode 100644 drivers/mtd/spi/gigadevice.c
>
> diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile
> index 90f8392..ecbb210 100644
> --- a/drivers/mtd/spi/Makefile
> +++ b/drivers/mtd/spi/Makefile
> @@ -32,6 +32,7 @@ endif
> COBJS-$(CONFIG_SPI_FLASH) += spi_flash.o
> COBJS-$(CONFIG_SPI_FLASH_ATMEL)+= atmel.o
> COBJS-$(CONFIG_SPI_FLASH_EON) += eon.o
> +COBJS-$(CONFIG_SPI_FLASH_GIGADEVICE) += gigadevice.o
> COBJS-$(CONFIG_SPI_FLASH_MACRONIX) += macronix.o
> COBJS-$(CONFIG_SPI_FLASH_SPANSION) += spansion.o
> COBJS-$(CONFIG_SPI_FLASH_SST) += sst.o
> diff --git a/drivers/mtd/spi/gigadevice.c b/drivers/mtd/spi/gigadevice.c
> new file mode 100644
> index 000..b5e1ebe
> --- /dev/null
> +++ b/drivers/mtd/spi/gigadevice.c
> @@ -0,0 +1,81 @@
> +/*
> + * Gigadevice SPI flash driver
> + * Copyright 2013, Samsung Electronics Co., Ltd.
> + * Author: Banajit Goswami
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include "spi_flash_internal.h"
> +
> +struct gigadevice_spi_flash_params {
> + uint16_tid;
> + uint16_tnr_blocks;
I think it's better to use u16 instead of uint16_t, uin16_t will get
back to arch include from include/linux which does u16 for directly
for first time.
> + const char *name;
> +};
> +
> +static const struct gigadevice_spi_flash_params gigadevice_spi_flash_table[]
> = {
> + {
> + .id = 0x6016,
> + .nr_blocks = 64,
> + .name = "GD25LQ",
> + },
> + {
> + .id = 0x4017,
> + .nr_blocks = 128,
> + .name = "GD25Q64B",
> + },
Better to use clean code shape like..
{
.id = 0x60,
.nr_blocks = 64,
.name = "GD25LQ",
}
> +};
> +
> +struct spi_flash *spi_flash_probe_gigadevice(struct spi_slave *spi, u8
> *idcode)
> +{
> + const struct gigadevice_spi_flash_params *params;
> + struct spi_flash *flash;
> + unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(gigadevice_spi_flash_table); i++) {
> + params = &gigadevice_spi_flash_table[i];
> + if (params->id == ((idcode[1] << 8) | idcode[2]))
> + break;
> + }
> +
> + if (i == ARRAY_SIZE(gigadevice_spi_flash_table)) {
> + debug("SF: Unsupported Gigadevice ID %02x%02x\n",
> + idcode[1], idcode[2]);
> + return NULL;
> + }
> +
> + flash = spi_flash_alloc_base(spi, params->name);
> + if (!flash) {
> + debug("SF: Failed to allocate memory\n");
> + return NULL;
> + }
better to add a space here
> + /* page_size */
> + flash->page_size = 256;
> + /* sector_size = page_size * pages_per_sector */
> + flash->sector_size = flash->page_size * 16;
> + /* size = sector_size * sector_per_block * number of blocks */
> + flash->size = flash->sector_size * 16 * params->nr_blocks;
comments on above size calculations are good, but not that much
important i guess.
And also please provide a stand' link for flash part data sheet on
commit message, if possible.
I thought it's a good to refers don't no this sounds valid..
Thanks,
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
h
Re: [U-Boot] [PATCH v4 0/4] Factorize ARM relocate_code instances
Hi Benoît, On Mon, May 20, 2013 at 12:39 PM, Benoît Thébaudeau wrote: > Can you test this series on mx31pdk (directly changed by this series), and > some > other i.MX EVK (e.g. ARMv7, so mx51evk or mx53*) board please? That should be > enough for ARM. I don't have access to my mx31pdk currently, but I will try to get access to it later this week. Then I can test this series on mx31pdk and also on mx53loco. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm:exynos:gpio: fix s5p_gpio_part_max for exynos4x12
This patch fix wrong value returned by 's5p_gpio_part_max' function
for Exynos4412.
Signed-off-by: Piotr Wilczek
Signed-off-by: Kyungmin Park
CC: Minkyu Kang
---
arch/arm/include/asm/arch-exynos/gpio.h | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/gpio.h
b/arch/arm/include/asm/arch-exynos/gpio.h
index cfe1024..20a4e3f 100644
--- a/arch/arm/include/asm/arch-exynos/gpio.h
+++ b/arch/arm/include/asm/arch-exynos/gpio.h
@@ -303,10 +303,19 @@ static inline unsigned int s5p_gpio_part_max(int nr)
return EXYNOS5_GPIO_PART2_MAX;
} else if (cpu_is_exynos4()) {
- if (nr < EXYNOS4_GPIO_PART1_MAX)
- return 0;
- else
- return EXYNOS4_GPIO_PART1_MAX;
+ if (proid_is_exynos4412()) {
+ if (nr < EXYNOS4X12_GPIO_PART1_MAX)
+ return 0;
+ else if (nr < EXYNOS4X12_GPIO_PART2_MAX)
+ return EXYNOS4X12_GPIO_PART1_MAX;
+ else
+ return EXYNOS4X12_GPIO_PART2_MAX;
+ } else {
+ if (nr < EXYNOS4_GPIO_PART1_MAX)
+ return 0;
+ else
+ return EXYNOS4_GPIO_PART1_MAX;
+ }
}
return 0;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/6] arm: mvf600: Add Vybrid MVF600 CPU support
On 05/21/2013 06:02 AM, Alison Wang wrote:
+#ifdef CONFIG_MXC_OCOTP
+void enable_ocotp_clk(unsigned char enable)
+{
+ struct ccm_reg *ccm = (struct ccm_reg *)CCM_BASE_ADDR;
+ u32 reg;
+
+ reg = readl(&ccm->ccgr6);
+ if (enable)
+ reg |= CCM_CCGR6_OCOTP_CTRL_MASK;
+ else
+ reg |= ~CCM_CCGR6_OCOTP_CTRL_MASK;
Don't you mean: reg &= ~CCM_CCGR6_OCOTP_CTRL_MASK; ?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Issue in DWMMC in mainline
Hi, On Tue, May 21, 2013 at 6:24 PM, Rajeshwari Birje wrote: > Hi All, > > I use the DWMMC driver in u-boot mainline on exynos board and face the > following issue. > > I do a mmc rescan 3 times, then fourth time I get a DATA ERROR, which > is due to FIFO underun/overun, after which I don't even get Command > done interrupt. > Later on the mmcinfo value also is displayed wrong. > > Please do let me know if anybody have a solution for same. You may know it already, can you try by enable CONFIG_MMC_TRACE on board config. so-that at-least we may come to know on which CMD this over/underrun occur. Thanks, Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] common: Add CCACHE variable to allow use of ccache
Dear Wolfgang Denk, > Dear Marek Vasut, > > In message <1369070715-9585-2-git-send-email-ma...@denx.de> you wrote: > > Prefix HOSTCC and CC with CCACHE variable to allow easy use of ccache. > > In case the user wants to use ccache, exporting CCACHE=ccache will do > > the trick. It is of course possible to either make the cross-compiler > > name into a shellscript which invokes the ccache and the compiler, but > > setting this variable makes use of ccache easier and more convenient. > > ... > > > -AS = $(CROSS_COMPILE)as > > +AS = $(CCACHE) $(CROSS_COMPILE)as > > > > # Always use GNU ld > > LD = $(shell if $(CROSS_COMPILE)ld.bfd -v > /dev/null 2>&1; \ > > > > then echo "$(CROSS_COMPILE)ld.bfd"; else echo "$(CROSS_COMPILE)ld"; > > fi;) > > > > -CC = $(CROSS_COMPILE)gcc > > +CC = $(CCACHE) $(CROSS_COMPILE)gcc > > > > CPP= $(CC) -E > > Why not for CPP ? CPP is invoked via $(CC) -E and CCACHE is set for CC right above, so that'd call ccache twice. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: pxa: PXA270 D-Cache as ram
Dear Sergey Yanovich, > Dear Marek Vasut, > > On Tue, 2013-05-21 at 13:38 +0200, Marek Vasut wrote: > > Yes, it's just an in-CPU RAM. > > Well, it is not 'just' RAM. It preserves its state during deep sleep and > power off modes. So does RAM during sleep state ;-) > > > Anyway, SRAM preserves its state when power is off. Poweroff time could > > > be in years with a backup battery. In addition, D-Cache is an order of > > > magnitude faster than SRAM (approx. 9 times) for both reads and writes. > > > > Is there any measurable difference between using DCache and SRAM? Do you > > have any evidence that a speedup happens? > > I haven't done any special profiling. I am just relying on PXA270 EMTS > table 6-14. The table says SRAM reads take 9 cycles, writes take 7 > cycles. D-Cache operations take 1 cycle. > > > Still, the SRAM/DCache is only used until you leave board_init_f(), then > > it's all DRAM. > > Yes, the patch as it is will only affects relocation speed and preserve > SRAM from corruption. Now this is the right (convincing) argument! What kind of corruption ? When does it occur ? > The speed gain can also be applied to uImage > copying/unpacking, but that requires deeper understanding than I have at > the moment. Uh ... I lost you here. Can you please elaborate some more ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] common: Use separate dirs for each board for ccache
Dear Wolfgang Denk,
> Dear Marek Vasut,
>
> In message <1369070715-9585-3-git-send-email-ma...@denx.de> you wrote:
> > + # Use per-board CCACHE directory
> > + if [ "x${CCACHE}" != "x" ] ; then
>
> Why not simply:
>
> if [ "${CCACHE}" ] ; then
>
> ?
>
> > + export CCACHE_DIR="`${CCACHE} -s | grep "^cache directory" | \
> > + tr -s " " | cut -d " " -f 3`/u-boot/${target}" ;
> > + mkdir -p "${CCACHE_DIR}"
> > + fi
>
> How can I cleanup all the mess of created files and directories after
> a build?
Ignoring this patch, it's FUBAR, sorry.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: pxa: config option for PXA270 turbo mode
On Tue, 2013-05-21 at 13:22 +0200, Marek Vasut wrote: > > Actually, I wonder if Linux's cpufreq still does depend on bootloader speed > > settings. Especially the turbo bit. Can you please check that? It'd be > > interesting to know ... > > > > I'd say enable it by default ... I probably have all the PXA devices > > supported in U-Boot and I'm quite sure none of them will mind ;-) > > Still, I'm surprised it wasn't enabled. I recall seeing it enabled. Weird ... Yes, you are right. Linux's cpufreq-pxa2xx.c always sets the turbo bit. However, if CONFIG_CPU_FREQ is not set (my case), bootloader's settings are used. I work on a system that has focus on low latency (industrial controller) rather than battery life (since it has no battery). ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: pxa: PXA270 D-Cache as ram
On Tue, 2013-05-21 at 17:00 +0200, Marek Vasut wrote: > > Yes, the patch as it is will only affects relocation speed and preserve > > SRAM from corruption. > > Now this is the right (convincing) argument! What kind of corruption ? When > does > it occur ? The whole 256 kB of SRAM could be used for persistent storage with the patch. Without it, part of SRAM should be dedicated for U-Boot stack or be overwritten on boot. > > The speed gain can also be applied to uImage > > copying/unpacking, but that requires deeper understanding than I have at > > the moment. > > Uh ... I lost you here. Can you please elaborate some more ? You are right. After SDRAM is configured, it is enough to turn on data caching to receive its speed benefits. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/6] arm: mvf600: Add Freescale Vybrid MVF600 CPU and MVF600TWR board support
Hi Alison, On Tuesday, May 21, 2013 11:02:55 AM, Alison Wang wrote: > This series contain the support for Freescale Vybrid MVF600 CPU and MVF600TWR > board. > > Vybird devices are built on an asymmetrical-multiprocessing architecture > using ARM cores. The families in the Vybrid portfolio span entry-level, > single core Cortex-A class SoCs all the way to dual heterogeneous core SoCs > with multiple communication and connectivity options. > > Part of the Vybrid platform, MVF600 is a dual-core eMPU combining the ARM > Cortex A5 and Cortex M4 cores. > > MVF600 shares some IPs with i.MX family, such as FEC,ESDHC,WATCHDOG,I2C,ASRC > and ESAI. > MVF600 also shares some IPs with ColdFire family, such as eDMA and DSPI. > MVF600 still has its own IPs, such as PIT,SAI,UART,QSPI and DCU. > > More documents for this soc can be found at: > http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=VF6xx&fsrch=1&sr=5 > http://www.freescale.com/webapp/sps/site/homepage.jsp?code=VYBRID I have a question about the naming of this SoC. On Freescale's website, it is VF6xx everywhere, but you add a leading M (_M_VF600). Is it because you are using an internal SoC name known only by Freescale and different from the marketing SoC name, or is this M from the part number, or will the marketing SoC name change later, or some other reason? Please clarify. U-Boot users must be able to identify a SoC and to find information about it easily. > > The u-boot runs on Cortex A5 core. [...] Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM v7: Flush icache when executing a program with go
Hi Kees, On Tue, 21 May 2013 14:38:01 +0200, Kees Jongenburger wrote: > To my > understanding also enabling d-cache on ARM has no effect as long as > the MMU is not turned on so I totally miss the point. Enabling dcache gives DDR access performance benefits regardless of enabling MMU. > Greetings Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/6] arm: mvf600: Add Vybrid MVF600 CPU support
Hi Alison, On Tuesday, May 21, 2013 11:02:56 AM, Alison Wang wrote: > This patch adds generic codes to support Freescale's Vybrid MVF600 CPU. > > It aligns Vybrid MVF600 platform with i.MX platform. As there are > some differences between MVF600 and i.MX platforms, the specific > codes are in the arch/arm/cpu/armv7/mvf600 directory. > > Signed-off-by: Alison Wang > --- > Changes in v3: > - Rename the common functions and enums > - Move the structure definitions to imx-regs.h > > Changes in v2: > - Remove vybrid-common directory > - Rename directory name 'vybrid' to 'mvf600' > - Add generic.c file > - Rewrite get_reset_cause() to make it readable > - Remove reset_cpu(), and use the function in imx_watchdog.c > - Rewrite timer.c file > - Use vybrid_get_clock(VYBRID_UART_CLK) instead of vybrid_get_uartclk() > - Remove lowlevel_init.S, and add clock_init() in board_early_init_f() > - Remove useless CONFIG_SYS_ defines > - Move CONFIG_MACH_TYPE to board configuration file > - Define C structures and access C structures to set/read registers > - Remove useless errata > - Remove useless macros > - Rename directory 'arch-vybrid' to 'arch-mvf600' > > Makefile| 2 +- > arch/arm/cpu/armv7/mvf600/Makefile | 42 +++ > arch/arm/cpu/armv7/mvf600/generic.c | 324 ++ > arch/arm/cpu/armv7/mvf600/timer.c | 103 +++ > arch/arm/include/asm/arch-mvf600/clock.h| 39 +++ > arch/arm/include/asm/arch-mvf600/crm_regs.h | 225 +++ > arch/arm/include/asm/arch-mvf600/imx-regs.h | 411 > > arch/arm/include/asm/arch-mvf600/mvf_pins.h | 92 +++ > 8 files changed, 1237 insertions(+), 1 deletion(-) > create mode 100644 arch/arm/cpu/armv7/mvf600/Makefile > create mode 100644 arch/arm/cpu/armv7/mvf600/generic.c > create mode 100644 arch/arm/cpu/armv7/mvf600/timer.c > create mode 100644 arch/arm/include/asm/arch-mvf600/clock.h > create mode 100644 arch/arm/include/asm/arch-mvf600/crm_regs.h > create mode 100644 arch/arm/include/asm/arch-mvf600/imx-regs.h > create mode 100644 arch/arm/include/asm/arch-mvf600/mvf_pins.h [...] Since this includes support for OCOTP on this SoC, the following hunks should also be added: doc/README.mxc_ocotp: --- on MXC This IP can be found on the following SoCs: + - Vybrid MVF600, - i.MX6. Note that this IP is different from albeit similar to the IPs of the same name --- doc/README.mvf600: --- +U-Boot for Freescale Vybrid MVF600 + +This file contains information for the port of U-Boot to the Freescale Vybrid +MVF600 SoC. + +1. CONVENTIONS FOR FUSE ASSIGNMENTS +--- + +1.1 MAC Address: It is stored in fuse bank 4, with the 16 msbs in word 2 and the +32 lsbs in word 3. --- You can also add the definition of the fuses for UID if any, like uid_low/high in struct fuse_bank0_regs in arch/arm/include/asm/arch-mx6/imx-regs.h. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: spi: winbond: add W25PXX support
Hi,
I have a simple question like these parts are legacy flashes i guess.
Could you please tell me on which boards these were used?
Thanks,
Jagan.
On Fri, Apr 26, 2013 at 1:32 PM, Kuo-Jung Su wrote:
> From: Kuo-Jung Su
>
> Signed-off-by: Kuo-Jung Su
> ---
> drivers/mtd/spi/winbond.c | 17 -
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
> index 2716209..2a27837 100644
> --- a/drivers/mtd/spi/winbond.c
> +++ b/drivers/mtd/spi/winbond.c
> @@ -18,6 +18,21 @@ struct winbond_spi_flash_params {
>
> static const struct winbond_spi_flash_params winbond_spi_flash_table[] = {
> {
> + .id = 0x2014,
> + .nr_blocks = 16,
> + .name = "W25P80",
> + },
> + {
> + .id = 0x2015,
> + .nr_blocks = 32,
> + .name = "W25P16",
> + },
> + {
> + .id = 0x2016,
> + .nr_blocks = 64,
> + .name = "W25P32",
> + },
> + {
> .id = 0x3013,
> .nr_blocks = 8,
> .name = "W25X40",
> @@ -104,7 +119,7 @@ struct spi_flash *spi_flash_probe_winbond(struct
> spi_slave *spi, u8 *idcode)
> }
>
> flash->page_size = 256;
> - flash->sector_size = 4096;
> + flash->sector_size = (idcode[1] == 0x20) ? 65536 : 4096;
> flash->size = 4096 * 16 * params->nr_blocks;
>
> return flash;
> --
> 1.7.9.5
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/6] arm: mvf600: Add IOMUX support for Vybrid MVF600
Hi Alison, On Tuesday, May 21, 2013 11:02:57 AM, Alison Wang wrote: > This patch adds the IOMUX support for Vybrid MVF600 platform. > > There is a little difference for IOMUXC module between MVF600 and i.MX > platform, the muxmode and pad configuration share one 32bit register on > MVF600, but they are two independent registers on I.MX platform. A > CONFIG_IOMUX_SHARE_CONFIG_REG was introduced to fit this difference. > > Signed-off-by: Alison Wang > --- > Changes in v3: > - Define PAD_CTL_PUE with PKE enabled > > Changes in v2: > - Use common iomux-v3 code > > arch/arm/imx-common/Makefile | 2 +- > arch/arm/imx-common/iomux-v3.c | 6 ++ > arch/arm/include/asm/imx-common/iomux-v3.h | 18 ++ > 3 files changed, 25 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/imx-common/Makefile b/arch/arm/imx-common/Makefile > index 8bba8a5..3378931 100644 > --- a/arch/arm/imx-common/Makefile > +++ b/arch/arm/imx-common/Makefile > @@ -27,7 +27,7 @@ include $(TOPDIR)/config.mk > > LIB = $(obj)libimx-common.o > > -ifeq ($(SOC),$(filter $(SOC),mx25 mx35 mx5 mx6)) > +ifeq ($(SOC),$(filter $(SOC),mx25 mx35 mx5 mx6 mvf600)) > COBJS-y = iomux-v3.o > endif > ifeq ($(SOC),$(filter $(SOC),mx5 mx6)) > diff --git a/arch/arm/imx-common/iomux-v3.c b/arch/arm/imx-common/iomux-v3.c > index 7fe5ce7..35880c7 100644 > --- a/arch/arm/imx-common/iomux-v3.c > +++ b/arch/arm/imx-common/iomux-v3.c > @@ -48,8 +48,14 @@ void imx_iomux_v3_setup_pad(iomux_v3_cfg_t pad) > if (sel_input_ofs) > __raw_writel(sel_input, base + sel_input_ofs); > > +#ifdef CONFIG_IOMUX_SHARE_CONF_REG > + if (!(pad_ctrl & NO_PAD_CTRL)) > + __raw_writel((mux_mode << PAD_MUX_MODE_SHIFT) | pad_ctrl, > + base + pad_ctrl_ofs); > +#else > if (!(pad_ctrl & NO_PAD_CTRL) && pad_ctrl_ofs) > __raw_writel(pad_ctrl, base + pad_ctrl_ofs); > +#endif > } > > void imx_iomux_v3_setup_multiple_pads(iomux_v3_cfg_t const *pad_list, > diff --git a/arch/arm/include/asm/imx-common/iomux-v3.h > b/arch/arm/include/asm/imx-common/iomux-v3.h > index 0b4e763..012d66a 100644 > --- a/arch/arm/include/asm/imx-common/iomux-v3.h > +++ b/arch/arm/include/asm/imx-common/iomux-v3.h > @@ -121,6 +121,24 @@ typedef u64 iomux_v3_cfg_t; > #define PAD_CTL_DSE_40ohm(6 << 3) > #define PAD_CTL_DSE_34ohm(7 << 3) > > +#elif defined(CONFIG_MVF600) > + > +#define PAD_MUX_MODE_SHIFT 20 > + > +#define PAD_CTL_PUS_47K_UP (1 << 4) > +#define PAD_CTL_PUS_100K_UP (2 << 4) PAD_CTL_PUE should be bitwise-OR-ed to the two values above to make it easy to use, just like you added PAD_CTL_PKE to PAD_CTL_PUE below. > +#define PAD_CTL_PUE (1 << 2 | PAD_CTL_PKE) > +#define PAD_CTL_PKE (1 << 3) > + > +#define PAD_CTL_SPEED_HIGH (3 << 12) > +#define PAD_CTL_SPEED_MED(1 << 12) > + > +#define PAD_CTL_DSE_20ohm(7 << 6) > +#define PAD_CTL_DSE_25ohm(6 << 6) > +#define PAD_CTL_DSE_50ohm(3 << 6) > + > +#define PAD_CTL_OBE_IBE_ENABLE (3 << 0) Please organize those definitions by decreasing offset value and increasing value in order to follow the reference manual order for easier review: PAD_MUX_MODE_SHIFT, then PAD_CTL_SPEED_MED, PAD_CTL_SPEED_HIGH, PAD_CTL_DSE_50ohm, PAD_CTL_DSE_25ohm, PAD_CTL_DSE_20ohm, PAD_CTL_PUS_47K_UP, PAD_CTL_PUS_100K_UP, PAD_CTL_PKE, PAD_CTL_PUE, and PAD_CTL_OBE_IBE_ENABLE. Also, the spaces/tabs are still not correct in those definitions. They should be: #define<1 space>NAME<1 or more tabs to align column>value > + > #else > > #define PAD_CTL_DVS (1 << 13) Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/6] net: fec_mxc: Add support for Vybrid MVF600
Hi Alison,
On Tuesday, May 21, 2013 11:02:58 AM, Alison Wang wrote:
> This patch adds FEC support for Vybrid MVF600 platform.
>
> In function fec_open(), RCR register is only set as RGMII mode. But RCR
> register should be set as RMII mode for MVF600 platform.
> This configuration is already done in fec_reg_setup(), so this piece of
> code could just leave untouched the FEC_RCNTRL_RGMII / FEC_RCNTRL_RMII /
> FEC_RCNTRL_MII_MODE bits.
>
> Signed-off-by: Alison Wang
> ---
> Changes in v3:
> - Remove the changes for FEC_RCNTRL_RGMII / FEC_RCNTRL_RMII /
> FEC_RCNTRL_MII_MODE bits, as they are already set in fec_reg_setup()
>
> Changes in v2:
> - Use common FEC driver fec_mxc.c
>
> drivers/net/fec_mxc.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
> index 4dbcdca..da95e28 100644
> --- a/drivers/net/fec_mxc.c
> +++ b/drivers/net/fec_mxc.c
> @@ -516,9 +516,7 @@ static int fec_open(struct eth_device *edev)
> #ifdef FEC_QUIRK_ENET_MAC
> {
> u32 ecr = readl(&fec->eth->ecntrl) & ~FEC_ECNTRL_SPEED;
> - u32 rcr = (readl(&fec->eth->r_cntrl) &
> - ~(FEC_RCNTRL_RMII | FEC_RCNTRL_RMII_10T)) |
> - FEC_RCNTRL_RGMII | FEC_RCNTRL_MII_MODE;
> + u32 rcr = readl(&fec->eth->r_cntrl) & ~FEC_RCNTRL_RMII_10T;
> if (speed == _1000BASET)
> ecr |= FEC_ECNTRL_SPEED;
> else if (speed != _100BASET)
Reviewed-by: Benoît Thébaudeau
Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/9] wandboard: Return error if the SDHC port index is invalid
When the SDHC port number index is invalid we should return an error code
immediately.
Currently we return 'status', which has a value of zero, causing
board_mmc_init() to incorrectly return sucess.
Fix this by returning -EINVAL instead.
Signed-off-by: Fabio Estevam
---
board/wandboard/wandboard.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/wandboard/wandboard.c b/board/wandboard/wandboard.c
index bb98352..70e070c 100644
--- a/board/wandboard/wandboard.c
+++ b/board/wandboard/wandboard.c
@@ -164,7 +164,7 @@ int board_mmc_init(bd_t *bis)
printf("Warning: you configured more USDHC controllers"
"(%d) then supported by the board (%d)\n",
index + 1, CONFIG_SYS_FSL_USDHC_NUM);
- return status;
+ return -EINVAL;
}
status |= fsl_esdhc_initialize(bis, &usdhc_cfg[index]);
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/9] mx53loco: Return error if the SDHC port index is invalid
When the SDHC port number index is invalid we should return an error code
immediately.
Currently we return 'status', which has a value of zero, causing
board_mmc_init() to incorrectly return sucess.
Fix this by returning -EINVAL instead.
Signed-off-by: Fabio Estevam
---
board/freescale/mx53loco/mx53loco.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/freescale/mx53loco/mx53loco.c
b/board/freescale/mx53loco/mx53loco.c
index 10e9d36..f1b2c40 100644
--- a/board/freescale/mx53loco/mx53loco.c
+++ b/board/freescale/mx53loco/mx53loco.c
@@ -204,7 +204,7 @@ int board_mmc_init(bd_t *bis)
printf("Warning: you configured more ESDHC controller"
"(%d) as supported by the board(2)\n",
CONFIG_SYS_FSL_ESDHC_NUM);
- return status;
+ return -EINVAL;
}
status |= fsl_esdhc_initialize(bis, &esdhc_cfg[index]);
}
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/9] mx6qarm2: Return error if the SDHC port index is invalid
When the SDHC port number index is invalid we should return an error code
immediately.
Currently we return 'status', which has a value of zero, causing
board_mmc_init() to incorrectly return sucess.
Fix this by returning -EINVAL instead.
Signed-off-by: Fabio Estevam
---
board/freescale/mx6qarm2/mx6qarm2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/freescale/mx6qarm2/mx6qarm2.c
b/board/freescale/mx6qarm2/mx6qarm2.c
index e336746..e3e0b76 100644
--- a/board/freescale/mx6qarm2/mx6qarm2.c
+++ b/board/freescale/mx6qarm2/mx6qarm2.c
@@ -156,7 +156,7 @@ int board_mmc_init(bd_t *bis)
printf("Warning: you configured more USDHC controllers"
"(%d) then supported by the board (%d)\n",
index + 1, CONFIG_SYS_FSL_USDHC_NUM);
- return status;
+ return -EINVAL;
}
status |= fsl_esdhc_initialize(bis, &usdhc_cfg[index]);
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/9] mx53evk: Return error if the SDHC port index is invalid
When the SDHC port number index is invalid we should return an error code
immediately.
Currently we return 'status', which has a value of zero, causing
board_mmc_init() to incorrectly return sucess.
Fix this by returning -EINVAL instead.
Signed-off-by: Fabio Estevam
---
board/freescale/mx53evk/mx53evk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/freescale/mx53evk/mx53evk.c
b/board/freescale/mx53evk/mx53evk.c
index 727ad65..6e9f62c 100644
--- a/board/freescale/mx53evk/mx53evk.c
+++ b/board/freescale/mx53evk/mx53evk.c
@@ -230,7 +230,7 @@ int board_mmc_init(bd_t *bis)
printf("Warning: you configured more ESDHC controller"
"(%d) as supported by the board(2)\n",
CONFIG_SYS_FSL_ESDHC_NUM);
- return status;
+ return -EINVAL;
}
status |= fsl_esdhc_initialize(bis, &esdhc_cfg[index]);
}
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/9] mx53ard: Return error if the SDHC port index is invalid
When the SDHC port number index is invalid we should return an error code
immediately.
Currently we return 'status', which has a value of zero, causing
board_mmc_init() to incorrectly return sucess.
Fix this by returning -EINVAL instead.
Signed-off-by: Fabio Estevam
---
board/freescale/mx53ard/mx53ard.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/freescale/mx53ard/mx53ard.c
b/board/freescale/mx53ard/mx53ard.c
index e2dbf63..1813bf5 100644
--- a/board/freescale/mx53ard/mx53ard.c
+++ b/board/freescale/mx53ard/mx53ard.c
@@ -201,7 +201,7 @@ int board_mmc_init(bd_t *bis)
printf("Warning: you configured more ESDHC controller"
"(%d) as supported by the board(2)\n",
CONFIG_SYS_FSL_ESDHC_NUM);
- return status;
+ return -EINVAL;
}
status |= fsl_esdhc_initialize(bis, &esdhc_cfg[index]);
}
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 8/9] mx6qsabrelite: Return error if the SDHC port index is invalid
When the SDHC port number index is invalid we should return an error code
immediately.
Currently we return 'status', which has a value of zero, causing
board_mmc_init() to incorrectly return sucess.
Fix this by returning -EINVAL instead.
Signed-off-by: Fabio Estevam
---
board/freescale/mx6qsabrelite/mx6qsabrelite.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
index 8ce054e..8a2e4b3 100644
--- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
+++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
@@ -287,7 +287,7 @@ int board_mmc_init(bd_t *bis)
printf("Warning: you configured more USDHC controllers"
"(%d) then supported by the board (%d)\n",
index + 1, CONFIG_SYS_FSL_USDHC_NUM);
- return status;
+ return -EINVAL;
}
status |= fsl_esdhc_initialize(bis, &usdhc_cfg[index]);
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 9/9] mx6qsabresd: Return error if the SDHC port index is invalid
When the SDHC port number index is invalid we should return an error code
immediately.
Currently we return 'status', which has a value of zero, causing
board_mmc_init() to incorrectly return sucess.
Fix this by returning -EINVAL instead.
Signed-off-by: Fabio Estevam
---
board/freescale/mx6qsabresd/mx6qsabresd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/freescale/mx6qsabresd/mx6qsabresd.c
b/board/freescale/mx6qsabresd/mx6qsabresd.c
index 2529826..094382b 100644
--- a/board/freescale/mx6qsabresd/mx6qsabresd.c
+++ b/board/freescale/mx6qsabresd/mx6qsabresd.c
@@ -198,7 +198,7 @@ int board_mmc_init(bd_t *bis)
printf("Warning: you configured more USDHC controllers"
"(%d) then supported by the board (%d)\n",
i + 1, CONFIG_SYS_FSL_USDHC_NUM);
- return status;
+ return -EINVAL;
}
status |= fsl_esdhc_initialize(bis, &usdhc_cfg[i]);
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools/fw_env: use fsync to ensure that data is physically stored
Hi Wolfgang Denx, > > Closing a file descriptor does not guarantee that the data has been > > successfully saved to disk, as the kernel might defer the write. > > What is the exact problem you are trying to fix? > > I mean, when exactly does adding the sync play a role? I'm using fw_setenv during system update process. The sequence of such a shell script is something like (much simplified): ... fw_setenv state=2 dd if=... of=/dev/mmcblk0... fw_setenv state=1 ... reboot The (redundant) environment is stored in a eMMC flash. The env var 'state' gives a hint to U-Boot whether/where the process was interrupted. So my intension is to be absolutely sure, that when fw_setenv returns, the environment is written out to disk. Best regards, Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/6] arm: mvf600: Add basic support for Vybrid MVF600TWR board
Hi Alison, On Tuesday, May 21, 2013 11:03:01 AM, Alison Wang wrote: > MVF600TWR is a board based on Vybrid MVF600 SoC. > > This patch adds basic support for Vybrid MVF600TWR board. > > Signed-off-by: Alison Wang > Signed-off-by: Jason Jin > Signed-off-by: TsiChung Liew [...] > diff --git a/include/configs/mvf600twr.h b/include/configs/mvf600twr.h > new file mode 100644 > index 000..1cfb9f6 > --- /dev/null > +++ b/include/configs/mvf600twr.h > @@ -0,0 +1,140 @@ > +/* > + * Copyright 2013 Freescale Semiconductor, Inc. > + * > + * Configuration settings for the Freescale Vybrid mvf600twr board. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation; either version 2 of > + * the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, > + * MA 02111-1307 USA > + */ > + > +#ifndef __CONFIG_H > +#define __CONFIG_H > + > +#include > +#include > + > +#define CONFIG_MVF600 > + [...] > +#define CONFIG_CMD_PING > +#define CONFIG_CMD_DHCP > +#define CONFIG_CMD_MII > +#define CONFIG_CMD_NET > +#define CONFIG_FEC_MXC > +#define CONFIG_MII > +#define IMX_FEC_BASE ENET_BASE_ADDR > +#define CONFIG_FEC_XCV_TYPE RMII > +#define CONFIG_ETHPRIME "FEC" You don't need to define this one with only 1 Ethernet interface defined. But isn't the MVF600 a dual-Ethernet SoC? > +#define CONFIG_FEC_MXC_PHYADDR 0 > +#define CONFIG_PHYLIB > +#define CONFIG_PHY_MICREL > + > +#define CONFIG_BOOTDELAY 3 > + > +#define CONFIG_SYS_TEXT_BASE 0x3f008000 > + > +/* Miscellaneous configurable options */ > +#define CONFIG_SYS_LONGHELP /* undef to save memory */ > +#define CONFIG_SYS_HUSH_PARSER /* use "hush" command parser */ > +#define CONFIG_SYS_PROMPT_HUSH_PS2 "> " > +#define CONFIG_SYS_PROMPT"Vybrid U-Boot > " > +#undef CONFIG_AUTO_COMPLETE > +#define CONFIG_SYS_CBSIZE256 /* Console I/O Buffer Size */ > +#define CONFIG_SYS_PBSIZE\ > + (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) + 16) > +#define CONFIG_SYS_MAXARGS 16 /* max number of command args */ > +#define CONFIG_SYS_BARGSIZE CONFIG_SYS_CBSIZE > + > +#define CONFIG_SYS_MEMTEST_START 0x8001 > +#define CONFIG_SYS_MEMTEST_END 0x87C0 You now have to #define CONFIG_CMD_MEMTEST for those to be useful. > + > +#define CONFIG_SYS_LOAD_ADDR 0x8001 > + > +#define CONFIG_SYS_HZ1000 > + > +/* > + * Stack sizes > + * The stack sizes are set up in start.S using the settings below > + */ > +#define CONFIG_STACKSIZE (128 * 1024)/* regular stack */ > + > +/* Physical memory map */ > +#define CONFIG_NR_DRAM_BANKS 1 > +#define PHYS_SDRAM (0x8000) > +#define PHYS_SDRAM_SIZE (128 * 1024 * 1024) > + > +#define CONFIG_SYS_SDRAM_BASEPHYS_SDRAM > +#define CONFIG_SYS_INIT_RAM_ADDR IRAM_BASE_ADDR > +#define CONFIG_SYS_INIT_RAM_SIZE IRAM_SIZE > + > +#define CONFIG_SYS_INIT_SP_OFFSET \ > + (CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE) > +#define CONFIG_SYS_INIT_SP_ADDR \ > + (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET) > + > +/* FLASH and environment organization */ > +#define CONFIG_SYS_NO_FLASH > + > +#define CONFIG_ENV_SIZE (8 * 1024) > +#define CONFIG_ENV_IS_IN_MMC > + > +#define CONFIG_ENV_OFFSET(12 * 64 * 1024) > +#define CONFIG_SYS_MMC_ENV_DEV 0 > + > +#define CONFIG_OF_LIBFDT > +#define CONFIG_CMD_BOOTZ > + > +#endif > -- > 1.8.0 Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/9] mx53smd: Return error if the SDHC port index is invalid
When the SDHC port number index is invalid we should return an error code
immediately.
Currently we return 'status', which has a value of zero, causing
board_mmc_init() to incorrectly return sucess.
Fix this by returning -EINVAL instead.
Signed-off-by: Fabio Estevam
---
board/freescale/mx53smd/mx53smd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/freescale/mx53smd/mx53smd.c
b/board/freescale/mx53smd/mx53smd.c
index d04f44f..a6a6bbe 100644
--- a/board/freescale/mx53smd/mx53smd.c
+++ b/board/freescale/mx53smd/mx53smd.c
@@ -137,7 +137,7 @@ int board_mmc_init(bd_t *bis)
printf("Warning: you configured more ESDHC controller"
"(%d) as supported by the board(1)\n",
CONFIG_SYS_FSL_ESDHC_NUM);
- return status;
+ return -EINVAL;
}
status |= fsl_esdhc_initialize(bis, &esdhc_cfg[index]);
}
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/9] mx51evk: Return error if the SDHC port index is invalid
When the SDHC port number index is invalid we should return an error code
immediately.
Currently we return 'status', which has a value of zero, causing
board_mmc_init() to incorrectly return sucess.
Fix this by returning -EINVAL instead.
Signed-off-by: Fabio Estevam
---
board/freescale/mx51evk/mx51evk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/freescale/mx51evk/mx51evk.c
b/board/freescale/mx51evk/mx51evk.c
index 369da6d..80749eb 100644
--- a/board/freescale/mx51evk/mx51evk.c
+++ b/board/freescale/mx51evk/mx51evk.c
@@ -356,7 +356,7 @@ int board_mmc_init(bd_t *bis)
printf("Warning: you configured more ESDHC controller"
"(%d) as supported by the board(2)\n",
CONFIG_SYS_FSL_ESDHC_NUM);
- return status;
+ return -EINVAL;
}
status |= fsl_esdhc_initialize(bis, &esdhc_cfg[index]);
}
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: arm720t: Add missing CONFIG_SKIP_LOWLEVEL_INIT guard for cpu_init_crit
Albert (& Axel), > -Original Message- > From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net] > Sent: Saturday, May 18, 2013 11:58 AM > To: Tom Warren > Cc: Stephen Warren; Axel Lin; Wolfgang Denk; Heiko Schocher; u- > b...@lists.denx.de > Subject: Re: [U-Boot] [PATCH] ARM: arm720t: Add missing > CONFIG_SKIP_LOWLEVEL_INIT guard for cpu_init_crit > > Hi Tom, > > On Fri, 17 May 2013 15:11:26 -0700, Tom Warren > wrote: > > > Axel (& Albert) > > > > > -Original Message- > > > From: Stephen Warren [mailto:swar...@wwwdotorg.org] > > > Sent: Wednesday, May 15, 2013 9:29 PM > > > To: Axel Lin > > > Cc: Wolfgang Denk; Heiko Schocher; Tom Warren; u-boot@lists.denx.de > > > Subject: Re: [U-Boot] [PATCH] ARM: arm720t: Add missing > > > CONFIG_SKIP_LOWLEVEL_INIT guard for cpu_init_crit > > > > > > On 05/15/2013 07:00 PM, Axel Lin wrote: > > > > 2013/5/15 Stephen Warren : > > > >> On 05/14/2013 09:04 PM, Axel Lin wrote: > > > >>> cpu_init_crit() can be skipped, but the code is still enabled > > > >>> requiring a platform to supply lowlevel_init(). > > > >> > > > >>> diff --git a/arch/arm/cpu/arm720t/start.S > > > >>> b/arch/arm/cpu/arm720t/start.S > > > >> > > > >>> +#ifndef CONFIG_SKIP_LOWLEVEL_INIT > > > >>> cpu_init_crit: > > > >>> > > > >>> #if !defined(CONFIG_TEGRA) > > > >>> @@ -258,6 +259,7 @@ cpu_init_crit: > > > >>> #endif > > > >>> > > > >>> mov pc, lr > > > >>> +#endif /* CONFIG_SKIP_LOWLEVEL_INIT */ > > > >> > > > >> If you're going to make changes here, you should probably ensure > > > >> that Tegra is setting CONFIG_SKIP_LOWLEVEL_INIT, and then remove > > > >> the Tegra-specific ifdef from the body of that function. That's > > > >> assuming that setting CONFIG_SKIP_LOWLEVEL_INIT doesn't have any > > > >> other side- > > > effects. > > > > > > > > Tegra exists in both arm720t and armv7: > > > > > > > > ./arch/arm/cpu/arm720t/tegra-common > > > > ./arch/arm/cpu/arm720t/tegra30 > > > > ./arch/arm/cpu/arm720t/tegra20 > > > > ./arch/arm/cpu/arm720t/tegra114 > > > > > > > > ./arch/arm/cpu/armv7/tegra-common > > > > ./arch/arm/cpu/armv7/tegra30 > > > > ./arch/arm/cpu/armv7/tegra20 > > > > ./arch/arm/cpu/armv7/tegra114 > > > > > > > > I'm wondering if we set CONFIG_SKIP_LOWLEVEL_INIT for tegra will > > > > also impact the code path in arch/arm/cpu/armv7/start.S ? > > > > > > Yes, you certainly only want to set CONFIG_SKIP_LOWLEVEL_INIT for > > > the SPL build. There's a whole section of > > > include/configs/tegra-common-post.h > > > which is ifdef CONFIG_SPL_BUILD, so it might make sense to #define > > > CONFIG_SKIP_LOWLEVEL_INIT there. > > I've applied your two patches (this one and the RFT for Tegra) to u-boot- > tegra/next and I'm running a MAKEALL right now, then I'll do a test on Cardhu > and Dalmore. > > > > Both of these are assigned to me in PatchWork - Albert - do you want me > to take them both in via the Tegra tree, or do you want to take the ARM > patch and I'll take the Tegra patch? Let me know. > > Please take both in Tegra tree. Will do. Axel - please resend these 2 patches w/o the RFT tag as a v2 and I'll take them in to the Tegra repo. Tom > > > Axel - I'll let you know how testing goes, and then you can resubmit the RFT > patch as a real patch against Tegra. > > > > Thanks, > > > > Tom > > -- > > nvpublic > > Amicalement, > -- > Albert. -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix device detection for API consumers
Hello Ilya,
On 05/19/2013 12:09 PM, Ilya Bakulin wrote:
Hi list,
I use U-Boot for starting FreeBSD/arm on Globalscale DreamPlug.
On this platform FreeBSD uses "ubldr" second-stage bootloader, which is
an U-Boot API consumer and uses U-Boot API to access block devices, network,
etc.
Dreamplug has several block devices accessible: internal SD card, SD card
reader,
and any number of USB-attached mass storage devices.
But when I boot ubldr, I can see only one block device.
I have traced down the problem and it seems to be in U-Boot API. When doing
block device enumeration, the "more" flag is not set properly on first access.
This patch fixes the problem for me. After applying the patch, FreeBSD ubldr
is able to see and access all block devices that U-Boot self knows.
diff --git a/api/api_storage.c b/api/api_storage.c
index c535712..1147e79 100644
--- a/api/api_storage.c
+++ b/api/api_storage.c
@@ -129,6 +129,9 @@ static int dev_stor_get(int type, int first, int *more,
struct device_info *di)
else
found = 1;
+ if (specs[type].max_dev > 1)
+ *more = 1;
+
} else {
for (i = 0; i < specs[type].max_dev; i++)
if (di->cookie == (void *)get_dev(specs[type].name, i))
{
I would personally prefer to set i = 0 in the "first" block and move the
/* provide
hint if.. */ out of the else and into the if (found) block. So there
is only one
place for checking the next device, but haven't tested that, just
looking at the
code. Since *more is already set to 0 initially any early problems which
return 0
will already have more = 0. When a device is found, as an exit routine it is
checked if more devices are present, and might set it to 1.
But more important, read http://www.denx.de/wiki/U-Boot/Patches.
This patch misses a signed-off-by (and please make the commit message
reflect
why the api is broken and optionally the cover letter how you found it,
that is a bit
more to the point in my mind).
Regards,
Jeroen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9] wandboard: Return error if the SDHC port index is invalid
On Tue, May 21, 2013 at 2:32 PM, Fabio Estevam wrote: > When the SDHC port number index is invalid we should return an error code > immediately. > > Currently we return 'status', which has a value of zero, causing > board_mmc_init() to incorrectly return sucess. > > Fix this by returning -EINVAL instead. > > Signed-off-by: Fabio Estevam > When I looked at this code I didn't change it because it raises a warning. So it returns the status if any failed. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9] wandboard: Return error if the SDHC port index is invalid
On Tue, May 21, 2013 at 3:26 PM, Otavio Salvador wrote: > When I looked at this code I didn't change it because it raises a warning. > So it returns the status if any failed. Which warning are you talking about? Build warning or run-time warning? I did not see any of these here. status is zero at that point of code, so we should not 'return 0' on failure. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9] wandboard: Return error if the SDHC port index is invalid
On Tue, May 21, 2013 at 3:39 PM, Fabio Estevam wrote: > On Tue, May 21, 2013 at 3:26 PM, Otavio Salvador > wrote: > > > When I looked at this code I didn't change it because it raises a > warning. > > So it returns the status if any failed. > > Which warning are you talking about? Build warning or run-time warning? > > I did not see any of these here. > > status is zero at that point of code, so we should not 'return 0' on > failure. > In the loop; it does: status |= fsl... so it gets the output of it. In case any fails it won't be 0. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9] wandboard: Return error if the SDHC port index is invalid
On Tue, May 21, 2013 at 3:44 PM, Otavio Salvador wrote: > In the loop; it does: > > status |= fsl... > > so it gets the output of it. In case any fails it won't be 0. It's good practice to return immediately when an error condition happens. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9] wandboard: Return error if the SDHC port index is invalid
On Tue, May 21, 2013 at 3:49 PM, Fabio Estevam wrote: > On Tue, May 21, 2013 at 3:44 PM, Otavio Salvador > wrote: > > > In the loop; it does: > > > > status |= fsl... > > > > so it gets the output of it. In case any fails it won't be 0. > > It's good practice to return immediately when an error condition happens. > Well the idea of the code was to return in case anything goes wrong. So it outputs a 'WARN'. If you wish to change this, please change to ERROR. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: pxa: PXA270 D-Cache as ram
Dear Sergey Yanovich, > On Tue, 2013-05-21 at 17:00 +0200, Marek Vasut wrote: > > > Yes, the patch as it is will only affects relocation speed and preserve > > > SRAM from corruption. > > > > Now this is the right (convincing) argument! What kind of corruption ? > > When does it occur ? > > The whole 256 kB of SRAM could be used for persistent storage with the > patch. Without it, part of SRAM should be dedicated for U-Boot stack or > be overwritten on boot. This won't hold on any PXA that uses SPL, like the vpac270 with OneNAND SPL and PXA3xx (which is out of tree, none of your concern ;-) ) > > > The speed gain can also be applied to uImage > > > copying/unpacking, but that requires deeper understanding than I have > > > at the moment. > > > > Uh ... I lost you here. Can you please elaborate some more ? > > You are right. After SDRAM is configured, it is enough to turn on data > caching to receive its speed benefits. You must make sure anything that uses DMA won't crash. But I don't understand how locking cachelines as RAM and enabling dcache relate to each other in this context. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/6] arm: mvf600: Add Vybrid MVF600 CPU support
Hi Alison,
On Tuesday, May 21, 2013 11:02:56 AM, Alison Wang wrote:
[...]
> diff --git a/arch/arm/include/asm/arch-mvf600/mvf_pins.h
> b/arch/arm/include/asm/arch-mvf600/mvf_pins.h
> new file mode 100644
> index 000..0fd89af
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-mvf600/mvf_pins.h
> @@ -0,0 +1,92 @@
> +/*
> + * Copyright 2013 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#ifndef __ASM_ARCH_MVF_PINS_H__
> +#define __ASM_ARCH_MVF_PINS_H__
> +
> +#include
> +
> +enum {
> + MVF600_PAD_PTA6__RMII0_CLKIN= IOMUX_PAD(0x, 0x, 2,
> 0x, 0, 0),
> + MVF600_PAD_PTB4__UART1_TX = IOMUX_PAD(0x0068, 0x0068, 2,
> 0x0380, 0, 0),
> + MVF600_PAD_PTB5__UART1_RX = IOMUX_PAD(0x006C, 0x006C, 2,
> 0x037C, 0, 0),
> + MVF600_PAD_PTC1__RMII0_MDIO = IOMUX_PAD(0x00B8, 0x00B8, 1,
> 0x, 0, 0),
> + MVF600_PAD_PTC0__RMII0_MDC = IOMUX_PAD(0x00B4, 0x00B4, 1,
> 0x, 0, 0),
> + MVF600_PAD_PTC2__RMII0_CRS_DV = IOMUX_PAD(0x00BC, 0x00BC, 1,
> 0x, 0,
> 0),
> + MVF600_PAD_PTC3__RMII0_RD1 = IOMUX_PAD(0x00C0, 0x00C0, 1,
> 0x, 0, 0),
> + MVF600_PAD_PTC4__RMII0_RD0 = IOMUX_PAD(0x00C4, 0x00C4, 1,
> 0x, 0, 0),
> + MVF600_PAD_PTC5__RMII0_RXER = IOMUX_PAD(0x00C8, 0x00C8, 1,
> 0x, 0, 0),
> + MVF600_PAD_PTC6__RMII0_TD1 = IOMUX_PAD(0x00CC, 0x00CC, 1,
> 0x, 0, 0),
> + MVF600_PAD_PTC7__RMII0_TD0 = IOMUX_PAD(0x00D0, 0x00D0, 1,
> 0x, 0, 0),
> + MVF600_PAD_PTC8__RMII0_TXEN = IOMUX_PAD(0x00D4, 0x00D4, 1,
> 0x, 0, 0),
> + MVF600_PAD_PTA24__ESDHC1_CLK= IOMUX_PAD(0x0038, 0x0038, 5,
> 0x, 0, 0),
> + MVF600_PAD_PTA25__ESDHC1_CMD= IOMUX_PAD(0x003C, 0x003C, 5,
> 0x, 0, 0),
> + MVF600_PAD_PTA26__ESDHC1_DAT0 = IOMUX_PAD(0x0040, 0x0040, 5,
> 0x, 0,
> 0),
> + MVF600_PAD_PTA27__ESDHC1_DAT1 = IOMUX_PAD(0x0044, 0x0044, 5,
> 0x, 0,
> 0),
> + MVF600_PAD_PTA28__ESDHC1_DAT2 = IOMUX_PAD(0x0048, 0x0048, 5,
> 0x, 0,
> 0),
> + MVF600_PAD_PTA29__ESDHC1_DAT3 = IOMUX_PAD(0x004C, 0x004C, 5,
> 0x, 0,
> 0),
> + MVF600_PAD_DDR_A15__DDR_A_15= IOMUX_PAD(0x0220, 0x0220, 0,
> 0x, 0, 0),
> + MVF600_PAD_DDR_A14__DDR_A_14= IOMUX_PAD(0x0224, 0x0224, 0,
> 0x, 0, 0),
> + MVF600_PAD_DDR_A13__DDR_A_13= IOMUX_PAD(0x0228, 0x0228, 0,
> 0x, 0, 0),
> + MVF600_PAD_DDR_A12__DDR_A_12= IOMUX_PAD(0x022c, 0x022c, 0,
> 0x, 0, 0),
> + MVF600_PAD_DDR_A11__DDR_A_11= IOMUX_PAD(0x0230, 0x0230, 0,
> 0x, 0, 0),
> + MVF600_PAD_DDR_A10__DDR_A_10= IOMUX_PAD(0x0234, 0x0234, 0,
> 0x, 0, 0),
> + MVF600_PAD_DDR_A9__DDR_A_9 = IOMUX_PAD(0x0238, 0x0238, 0,
> 0x, 0, 0),
> + MVF600_PAD_DDR_A8__DDR_A_8 = IOMUX_PAD(0x023c, 0x023c, 0,
> 0x, 0, 0),
> + MVF600_PAD_DDR_A7__DDR_A_7 = IOMUX_PAD(0x0240, 0x0240, 0,
> 0x, 0, 0),
> + MVF600_PAD_DDR_A6__DDR_A_6 = IOMUX_PAD(0x0244, 0x0244, 0,
> 0x, 0, 0),
> + MVF600_PAD_DDR_A5__DDR_A_5 = IOMUX_PAD(0x0248, 0x0248, 0,
> 0x, 0, 0),
> + MVF600_PAD_DDR_A4__DDR_A_4 = IOMUX_PAD(0x024c, 0x024c, 0,
> 0x, 0, 0),
> + MVF600_PAD_DDR_A3__DDR_A_3 = IOMUX_PAD(0x0250, 0x0250, 0,
> 0x, 0, 0),
> + MVF600_PAD_DDR_A2__DDR_A_2 = IOMUX_PAD(0x0254, 0x0254, 0,
> 0x, 0, 0),
> + MVF600_PAD_DDR_A1__DDR_A_1 = IOMUX_PAD(0x0258, 0x0258, 0,
> 0x, 0, 0),
> + MVF600_PAD_DDR_BA2__DDR_BA_2= IOMUX_PAD(0x0260, 0x0260, 0,
> 0x, 0, 0),
> + MVF600_PAD_DDR_BA1__DDR_BA_1= IOMUX_PAD(0x0264, 0x0264, 0,
> 0x, 0, 0),
> + MVF600_PAD_DDR_BA0__DDR_BA_0= IOMUX_PAD(0x0268, 0x0268, 0,
> 0x, 0, 0),
> + MVF600_PAD_DDR_CAS__DDR_CAS_B = IOMUX_PAD(0x026c, 0x026c, 0,
> 0x, 0,
> 0),
> + MVF600_PAD_DDR_CKE__DDR_CKE_0 = IOMUX_PAD(0x0270, 0x0270, 0,
> 0x, 0,
> 0),
> + MVF600_PAD_DDR_CLK__DDR_CLK_0 =
Re: [U-Boot] [PATCH] common/Makefile: Add new symbol CONFIG_SPL_ENV_SUPPORT for environment in SPL
On 05/20/2013 09:43:53 PM, Zhang Ying-B40530 wrote: -Original Message- From: Wood Scott-B07421 Sent: Tuesday, May 21, 2013 2:56 AM To: Zhang Ying-B40530 Cc: Wood Scott-B07421; u-boot@lists.denx.de; aflem...@gmail.com; Xie Xiaobo-R63061; Tom Rini Subject: Re: [PATCH] common/Makefile: Add new symbol CONFIG_SPL_ENV_SUPPORT for environment in SPL I'm not that familiar with CONFIG_SPL_NET_SUPPORT, but it looks like it just enables the net/ directory in an SPL. How does that conflict with env stuff? Perhaps there's some other symbol that better describes the actual conflict. [Zhang Ying] This is Tom's words: a3m071 relies on SPL always building cmd_nvedit.o and env_common.o and duplicated CONFIG_ENV_IS_IN_FLASH in the SPL section. CONFIG_SPL_NET_SUPPORT relies on the same always-built ins and adds env_nowhere.o which works because the regular CONFIG_ENV_IS_IN_... section is in the non-SPL-only area. If "SPL: Makefile: Build a separate autoconf.mk for SPL" gets merged, we could just have a3m071 define CONFIG_ENV_IS_NOWHERE in the SPL build case. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: pxa: PXA270 D-Cache as ram
Dear Marek Vasut, On Tue, 2013-05-21 at 21:02 +0200, Marek Vasut wrote: > > The whole 256 kB of SRAM could be used for persistent storage with the > > patch. Without it, part of SRAM should be dedicated for U-Boot stack or > > be overwritten on boot. > > This won't hold on any PXA that uses SPL, like the vpac270 with OneNAND SPL > and > PXA3xx (which is out of tree, none of your concern ;-) ) I am no way trying to enforce D-Cache as RAM. The patch just provides an option for those who needs it. > > You are right. After SDRAM is configured, it is enough to turn on data > > caching to receive its speed benefits. > > You must make sure anything that uses DMA won't crash. I wasn't sure why data cache is disabled in U-Boot for every board I saw configuration of. Thanks for pointing out. > But I don't understand > how locking cachelines as RAM and enabling dcache relate to each other in > this > context. I meant D-Cache is several times faster than SDRAM, so it may be possible to get a bit faster, if stack remains on D-Cache even after SDRAM is configured. Repeating my hedge, I don't see the full picture, yet. It may well be impossible (if U-Boot needs more than 32 kB of stack) or not worth the effort (if the gain is too small). ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: pxa: PXA270 D-Cache as ram
Dear Sergey Yanovich, > Dear Marek Vasut, > > On Tue, 2013-05-21 at 21:02 +0200, Marek Vasut wrote: > > > The whole 256 kB of SRAM could be used for persistent storage with the > > > patch. Without it, part of SRAM should be dedicated for U-Boot stack or > > > be overwritten on boot. > > > > This won't hold on any PXA that uses SPL, like the vpac270 with OneNAND > > SPL and PXA3xx (which is out of tree, none of your concern ;-) ) > > I am no way trying to enforce D-Cache as RAM. The patch just provides an > option for those who needs it. I'd love to have a uniform way to do this cache thing, really ... > > > You are right. After SDRAM is configured, it is enough to turn on data > > > caching to receive its speed benefits. > > > > You must make sure anything that uses DMA won't crash. > > I wasn't sure why data cache is disabled in U-Boot for every board I saw > configuration of. Thanks for pointing out. > > > But I don't understand > > how locking cachelines as RAM and enabling dcache relate to each other in > > this context. > > I meant D-Cache is several times faster than SDRAM, so it may be > possible to get a bit faster, if stack remains on D-Cache even after > SDRAM is configured. Not really, enabling dcache altogether and marking DRAM region as cached would be much better. > Repeating my hedge, I don't see the full picture, > yet. It may well be impossible (if U-Boot needs more than 32 kB of > stack) No way. > or not worth the effort (if the gain is too small). The larger gain would be from fixing the U-Boot drivers for PXA to work well with DCache ;-) Then the speedup would really be plenty significant, this can be well confirmed on many other ARM chips. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/6] arm: mvf600: Add basic support for Vybrid MVF600TWR board
Hi Alison,
On Tuesday, May 21, 2013 11:03:01 AM, Alison Wang wrote:
> MVF600TWR is a board based on Vybrid MVF600 SoC.
>
> This patch adds basic support for Vybrid MVF600TWR board.
>
> Signed-off-by: Alison Wang
> Signed-off-by: Jason Jin
> Signed-off-by: TsiChung Liew
[...]
> diff --git a/board/freescale/mvf600twr/mvf600twr.c
> b/board/freescale/mvf600twr/mvf600twr.c
> new file mode 100644
> index 000..71ee12b
> --- /dev/null
> +++ b/board/freescale/mvf600twr/mvf600twr.c
> @@ -0,0 +1,413 @@
> +/*
> + * Copyright 2013 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +#define UART_PAD_CTRL(PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
> + PAD_CTL_DSE_25ohm | PAD_CTL_OBE_IBE_ENABLE)
> +
> +#define ESDHC_PAD_CTRL (PAD_CTL_PUE | PAD_CTL_PUS_100K_UP | \
> + PAD_CTL_SPEED_HIGH | PAD_CTL_DSE_20ohm | \
> + PAD_CTL_OBE_IBE_ENABLE)
With the changes that I have suggested in my review of your IOMUX patch,
ESDHC_PAD_CTRL could be simplified by removing PAD_CTL_PUE.
And without those changes, UART_PAD_CTRL and ENET_PAD_CTRL in your current code
set pull values that are actually unused (unless the corresponding PKE/PUE bits
do not exist and default to pull in the pad control registers used with these
definitions).
> +
> +#define ENET_PAD_CTRL(PAD_CTL_PUS_47K_UP | PAD_CTL_SPEED_HIGH | \
> + PAD_CTL_DSE_50ohm | PAD_CTL_OBE_IBE_ENABLE)
> +
> +#define DDR_PAD_CTRL PAD_CTL_DSE_25ohm
MUX_PAD_CTRL() could be added to the 4 pad control definitions above in order to
avoid repeating it everywhere below. But using MUX_PAD_CTRL() relies on the fact
that the pad control values in mvf_pins.h are all 0 (which is the case, but this
is dangerous if this is changed later), so a better approach could be to use
NEW_PAD_CTRL(), e.g.:
NEW_PAD_CTRL(MVF600_PAD_DDR_A15__DDR_A_15, DDR_PAD_CTRL),
instead of:
MVF600_PAD_DDR_A15__DDR_A_15 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> +
> +iomux_v3_cfg_t const ddr_pads[] = {
> + MVF600_PAD_DDR_A15__DDR_A_15 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_A14__DDR_A_14 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_A13__DDR_A_13 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_A12__DDR_A_12 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_A11__DDR_A_11 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_A10__DDR_A_10 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_A9__DDR_A_9 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_A8__DDR_A_8 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_A7__DDR_A_7 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_A6__DDR_A_6 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_A5__DDR_A_5 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_A4__DDR_A_4 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_A3__DDR_A_3 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_A2__DDR_A_2 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_A1__DDR_A_1 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_BA2__DDR_BA_2 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_BA1__DDR_BA_1 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_BA0__DDR_BA_0 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_CAS__DDR_CAS_B | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_CKE__DDR_CKE_0 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_CLK__DDR_CLK_0 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_CS__DDR_CS_B_0 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_D15__DDR_D_15 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_D14__DDR_D_14 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_D13__DDR_D_13 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_D12__DDR_D_12 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_D11__DDR_D_11 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_D10__DDR_D_10 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_D9__DDR_D_9 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_D8__DDR_D_8 | MUX_PAD_CTRL(DDR_PAD_CTRL),
> + MVF600_PAD_DDR_D7__DDR_D_7 | MUX_PAD_CTRL(DD
Re: [U-Boot] [PATCH] arm: pxa: config option for PXA270 turbo mode
Dear Sergey Yanovich, > On Tue, 2013-05-21 at 13:22 +0200, Marek Vasut wrote: > > > Actually, I wonder if Linux's cpufreq still does depend on bootloader > > > speed settings. Especially the turbo bit. Can you please check that? > > > It'd be interesting to know ... > > > > > > I'd say enable it by default ... I probably have all the PXA devices > > > supported in U-Boot and I'm quite sure none of them will mind ;-) > > > > Still, I'm surprised it wasn't enabled. I recall seeing it enabled. Weird > > ... > > Yes, you are right. Linux's cpufreq-pxa2xx.c always sets the turbo bit. > > However, if CONFIG_CPU_FREQ is not set (my case), bootloader's settings > are used. > > I work on a system that has focus on low latency (industrial controller) > rather than battery life (since it has no battery). So why not just make this patch into -(2) +(0xb) instead of adding new (and undocumented ...) macro? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] powerpc/mpc85xx: modify the functionality clear_bss and the end address of the BSS
On 05/20/2013 01:07:24 AM, ying.zh...@freescale.com wrote: From: Ying Zhang There will clear the BSS in the function clear_bss(), the reset address of the BSS started from the __bss_start, and increased by four-byte increments, finally stoped depending on the address is equal to the _bss_end. If the end address __bss_end is not alignment to 4byte, it will be an infinite loop. 1. The reset action stoped depending on the reset address is greater than or equal the end address of the BSS. 2. The end address of the BSS should be 4byte aligned. Because the reset unit is 4 Bytes. Should we add explicit alignment of the BSS start as well? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] spl: Make CONFIG_SPL_BUILD contain more functionality
Please change the title and the rest of the changelog to describe what functionality you're adding and why. On 05/20/2013 01:07:27 AM, ying.zh...@freescale.com wrote: diff --git a/common/env_common.c b/common/env_common.c index 906b41f..8cb81e9 100644 --- a/common/env_common.c +++ b/common/env_common.c @@ -156,7 +156,6 @@ int set_default_vars(int nvars, char * const vars[]) H_NOCLEAR | H_INTERACTIVE, nvars, vars); } -#ifndef CONFIG_SPL_BUILD /* * Check if CRC is valid and (if yes) import the environment. * Note that "buf" may or may not be aligned. @@ -188,7 +187,6 @@ int env_import(const char *buf, int check) return 0; } -#endif This ifndef was introduced by Ilya Yanok in commit 7ac2fe2da21d292aeaf3af74e5c80de9ce9dab56. Ilya, what are the consequences of removing this? Is there some other symbol we can use here? diff --git a/include/configs/MPC8313ERDB.h b/include/configs/MPC8313ERDB.h index c28dfe0..a2bdcff 100644 --- a/include/configs/MPC8313ERDB.h +++ b/include/configs/MPC8313ERDB.h @@ -40,7 +40,9 @@ #define CONFIG_SPL_INIT_MINIMAL #define CONFIG_SPL_SERIAL_SUPPORT #define CONFIG_SPL_NAND_SUPPORT +#ifdef CONFIG_SPL_BUILD #define CONFIG_SPL_NAND_MINIMAL +#endif #define CONFIG_SPL_FLUSH_IMAGE #define CONFIG_SPL_TARGET "u-boot-with-spl.bin" #define CONFIG_SPL_MPC83XX_WAIT_FOR_NAND diff --git a/include/configs/P1022DS.h b/include/configs/P1022DS.h index 8b13b10..5bdd44a 100644 --- a/include/configs/P1022DS.h +++ b/include/configs/P1022DS.h @@ -41,7 +41,9 @@ #define CONFIG_SPL_INIT_MINIMAL #define CONFIG_SPL_SERIAL_SUPPORT #define CONFIG_SPL_NAND_SUPPORT +#ifdef CONFIG_SPL_BUILD #define CONFIG_SPL_NAND_MINIMAL +#endif #define CONFIG_SPL_FLUSH_IMAGE #define CONFIG_SPL_TARGET "u-boot-with-spl.bin" diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h index 7ed634b..bc48d62 100644 --- a/include/configs/p1_p2_rdb_pc.h +++ b/include/configs/p1_p2_rdb_pc.h @@ -159,7 +159,9 @@ #define CONFIG_SPL_INIT_MINIMAL #define CONFIG_SPL_SERIAL_SUPPORT #define CONFIG_SPL_NAND_SUPPORT +#ifdef CONFIG_SPL_BUILD #define CONFIG_SPL_NAND_MINIMAL +#endif #define CONFIG_SPL_FLUSH_IMAGE #define CONFIG_SPL_TARGET "u-boot-with-spl.bin" Are you sure this belongs in this patch? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: pxa: PXA270 D-Cache as ram
Dear Marek Vasut, On Tue, 2013-05-21 at 21:24 +0200, Marek Vasut wrote: > I'd love to have a uniform way to do this cache thing, really ... Requoting the spec 'The PXA27x processor cache configuration is identical to that of the PXA255 processor'. It looks safe to configure all PXA2XX chipsets this way. Maybe I am missing something, but SPL is no exception in this case. > Not really, enabling dcache altogether and marking DRAM region as cached > would > be much better. > > > Repeating my hedge, I don't see the full picture, > > yet. It may well be impossible (if U-Boot needs more than 32 kB of > > stack) > > No way. > > > or not worth the effort (if the gain is too small). > > The larger gain would be from fixing the U-Boot drivers for PXA to work well > with DCache ;-) Then the speedup would really be plenty significant, this can > be > well confirmed on many other ARM chips. I have plans to dig deeper into this after I complete the current project. Faster boot is always a good thing. Thanks for explaining in details. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: pxa: config option for PXA270 turbo mode
Dear Marek Vasut, On Tue, 2013-05-21 at 21:25 +0200, wrote: > So why not just make this patch into > > -(2) > +(0xb) > > instead of adding new (and undocumented ...) macro? Point taken. Looks like I am too careful in this case. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: pxa: config option for PXA270 turbo mode
PXA270 CPU has turbo mode. The mode is 2.5 times faster than the
default run mode. Activating the mode early significantly speeds
up boot process.
Signed-off-by: Sergey Yanovich
---
Changes for v3:
- make the change unconditional
Changes for v2:
- activate turbo mode and fast bus by default
---
arch/arm/cpu/pxa/pxa2xx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/pxa/pxa2xx.c b/arch/arm/cpu/pxa/pxa2xx.c
index 09e8177..67a2ce1 100644
--- a/arch/arm/cpu/pxa/pxa2xx.c
+++ b/arch/arm/cpu/pxa/pxa2xx.c
@@ -244,7 +244,7 @@ void pxa_clock_setup(void)
{
writel(CONFIG_SYS_CKEN, CKEN);
writel(CONFIG_SYS_CCCR, CCCR);
- asm volatile("mcr p14, 0, %0, c6, c0, 0" : : "r"(2));
+ asm volatile("mcr p14, 0, %0, c6, c0, 0" : : "r"(0x0b));
/* enable the 32Khz oscillator for RTC and PowerManager */
writel(OSCC_OON, OSCC);
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: pxa: config option for PXA270 turbo mode
Dear Sergey Yanovich, > PXA270 CPU has turbo mode. The mode is 2.5 times faster than the > default run mode. Activating the mode early significantly speeds > up boot process. > > Signed-off-by: Sergey Yanovich OK, applied. Thanks Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
