Re: [U-Boot] [PATCH v4] i2c, omap24xx: convert driver to new mutlibus/mutliadapter framework
Hello Igor, Am 27.10.2013 08:30, schrieb Igor Grinberg: Hi Heiko, On 10/22/13 11:03, Heiko Schocher wrote: - add omap24xx driver to new multibus/multiadpater support - adapted all config files, which uses this driver Tested on the am335x based siemens boards rut, dxr2 and pxm2 posted here: http://patchwork.ozlabs.org/patch/263211/ Signed-off-by: Heiko Schocherh...@denx.de Tested-by: Tom Rinitr...@ti.com Cc: Lars Poeschelpoesc...@lemonage.de Cc: Steve Sakomansako...@gmail.com Cc: Thomas Weberwe...@corscience.de Cc: Tom Rixtom@windriver.com Cc: Grazvydas Ignotasnota...@gmail.com Cc: Enric Balletbo i Serraeballe...@iseebcn.com Cc: Luca Ceresoliluca.ceres...@comelit.it Cc: Igor Grinberggrinb...@compulab.co.il Cc: Ilya Yanokya...@emcraft.com Cc: Stefano Babicsba...@denx.de Cc: Nishanth Menonn...@ti.com Cc: Pali Rohárpali.ro...@gmail.com Cc: Peter Baradapeter.bar...@logicpd.com Cc: Nagendra T Snagen...@mistralsolutions.com Cc: Michael Jonesmichael.jo...@matrix-vision.de Cc: Raphael Assenatr...@8d.com [...] [...] diff --git a/board/compulab/cm_t35/eeprom.h b/board/compulab/cm_t35/eeprom.h index 02ffbb1..a07559d 100644 --- a/board/compulab/cm_t35/eeprom.h +++ b/board/compulab/cm_t35/eeprom.h @@ -10,7 +10,7 @@ #ifndef _EEPROM_ #define _EEPROM_ -#ifdef CONFIG_DRIVER_OMAP34XX_I2C +#ifdef CONFIG_SYS_I2C_OMAP34XX int cm_t3x_eeprom_read_mac_addr(uchar *buf); u32 cm_t3x_eeprom_get_board_rev(void); #else Please, rebase on top of: http://patchwork.ozlabs.org/patch/275284/ which should be applied any time soon. Otherwise, Acked-by: Igor Grinberggrinb...@compulab.co.il Hmm.. I cannot see, that your patch is accepted ... but I looked in it, and it looks good to me. So, I propose to add this patch to the i2c tree, so I do the necessary changes in my patch when applying it to the i2c tree (as they are trivial changes) ... @Tom: Is this OK for you? bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/T1040EMU: Add T1040 emulator support
Dear Priyanka Jain,
In message 1382936067-30488-1-git-send-email-priyanka.j...@freescale.com you
wrote:
Add emulator support for T1040. Emulator has limited peripherals
and interfaces.
Difference between T1040QDS and emulator includes:
-ECC for DDR is disabled due to procedure to load images
-Depends on raw timing for DDR initialization
-No board FPGA (Qixis)
-No PCI
-No SPI
-No flash support
...
diff --git a/include/configs/T1040EMU.h b/include/configs/T1040EMU.h
new file mode 100644
index 000..7005cb1
--- /dev/null
+++ b/include/configs/T1040EMU.h
@@ -0,0 +1,408 @@
+/*
+ * 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., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
Please convert to SPDX ID.
+#define CONFIG_SYS_MEMTEST_START 0x0020 /* memtest works on */
+#define CONFIG_SYS_MEMTEST_END 0x0040
Does this really make sense?
+/* Serial Port - controlled on board with jumper J8
+ * open - index 2
+ * shorted - index 1
+ */
Incorrect multiline comment style.
+/* new uImage format support */
+#define CONFIG_FIT
+#define CONFIG_FIT_VERBOSE /* enable fit_format_{error,warning}() */
Strictly speaking, FIT image and uImage are completely different
things. FIT is _not_ new uImage.
+#define CONFIG_SYS_PROMPT=/* Monitor Command Prompt */
No need to redefine the default.
+#define CONFIG_EXTRA_ENV_SETTINGS \
+ hwconfig=fsl_ddr:ctlr_intlv=cacheline,\
+ bank_intlv=cs0_cs1; \
It appears hwconfig is not NUL terminated?
+ netdev=eth0\0 \
+ uboot= __stringify(CONFIG_UBOOTPATH) \0 \
+ ubootaddr= __stringify(CONFIG_SYS_TEXT_BASE) \0 \
+ tftpflash=tftpboot $loadaddr $uboot \
+ protect off $ubootaddr +$filesize \
+ erase $ubootaddr +$filesize \
+ cp.b $loadaddr $ubootaddr $filesize \
+ protect on $ubootaddr +$filesize\
+ cmp.b $loadaddr $ubootaddr $filesize\0\
I'd recommend to use indentation to show where the next command
starts.
+ c=ffe\0
I sthis intentional? What's the sense?
+#define CONFIG_PROOF_POINTS \
+ setenv bootargs root=/dev/$bdev rw\
+ console=$consoledev,$baudrate $othbootargs; \
+ cpu 1 release 0x2900 - - -; \
+ cpu 2 release 0x2900 - - -; \
+ cpu 3 release 0x2900 - - -; \
+ cpu 4 release 0x2900 - - -; \
+ cpu 5 release 0x2900 - - -; \
+ cpu 6 release 0x2900 - - -; \
+ cpu 7 release 0x2900 - - -; \
+ go 0x2900 \
Not NUL terminated?
+ setenv bootargs root=/dev/$bdev rw\
+ console=$consoledev,$baudrate $othbootargs; \
+ cpu 1 release 0x2900 - - -; \
+ cpu 2 release 0x2900 - - -; \
+ cpu 3 release 0x2900 - - -; \
+ cpu 4 release 0x2900 - - -; \
+ cpu 5 release 0x2900 - - -; \
+ cpu 6 release 0x2900 - - -; \
+ cpu 7 release 0x2900 - - -; \
+ go 0x2900
Intentionally duplicated?
+#define CONFIG_LINUX \
+ setenv bootargs root=/dev/ram rw \
+ console=$consoledev,$baudrate $othbootargs; \
+ setenv ramdiskaddr 0x0200; \
+ setenv fdtaddr 0x00c0; \
+ setenv loadaddr 0x100; \
+ bootm $loadaddr $ramdiskaddr $fdtaddr
Not NUL terminated?
+#define CONFIG_HDBOOT\
+ setenv bootargs root=/dev/$bdev rw\
+ console=$consoledev,$baudrate $othbootargs; \
+ tftp $loadaddr $bootfile; \
+ tftp $fdtaddr $fdtfile; \
+ bootm $loadaddr - $fdtaddr
Not NUL terminated?
+#define
Re: [U-Boot] [PATCH v4 06/11] mpc8xxx: call i2c_set_bus_num in __get_spd
Hello Valentin, Am 18.10.2013 11:47, schrieb Valentin Longchamp: This is necessary with the new I2C subystem that was introduced lately. Signed-off-by: Valentin Longchampvalentin.longch...@keymile.com --- Changes in v4: None Changes in v3: None Changes in v2: None arch/powerpc/cpu/mpc8xxx/ddr/main.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) Thanks. Acked-by: Heiko Schocher h...@denx.de bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 04/11] KM: define CONFIG_SYS_I2C_INIT_BOARD only for concerned board
Hello Valentin, Am 18.10.2013 11:47, schrieb Valentin Longchamp: This must be defined for all the keymile boards that use the common i2c_abort function that is used to reset the I2C bus. These are currently km82xx and km_arm boards. The km83xx boards use other functions and thus do not need this. This patch removes the CONFIG_SYS_I2C_INIT_BOARD from keymile-common.h and defines it for km_arm.h and km82xx.h. Signed-off-by: Valentin Longchampvalentin.longch...@keymile.com --- Changes in v4: None Changes in v3: - take the new I2C defines into account and use CONFIG_SYS_I2C_INIT_BOARD instead of an additional option and define it only for the I2C bitbang KM boards (km_arm and km82xx) and not for all KM boards. Changes in v2: - Introduce CONFIG_KM_I2C_ABORT #define to avoid #if !defined in common.c board/keymile/common/common.c | 25 - include/configs/km/keymile-common.h | 2 -- include/configs/km/km_arm.h | 4 +--- include/configs/km82xx.h| 2 ++ 4 files changed, 3 insertions(+), 30 deletions(-) Thanks. Acked-by: Heiko Schocher h...@denx.de bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/5] usb: ums: code refactoring to improve reusability on other boards.
Hi Marek, Dear Przemyslaw Marczak, This patch introduces some cleanups to ums code. Changes: ums common: - introduce UMS_START_SECTOR and UMS_NUM_SECTORS as defined in usb_mass_storage.h both default values as 0 if board config doesn't define them common cleanup changes: - change name of struct ums_board_info to ums - ums_device fields are moved to struct ums and dev_num is removed - change function name: board_ums_init to ums_init - remove extern prefixes from usb_mass_storage.h cmd_usb_mass_storage: - change error() to printf() if need to print info message - change return values to command_ret_t type at ums command code - add command usage string Changes v2: ums common: - always returns number of read/write sectors - coding style clean-up ums gadget: - calculate amount of read/write from device returned value. Hi Lukasz, can I get ack/nak on the series? Thanks! For the whole series: Acked-by: Lukasz Majewski l.majew...@samsung.com Best regards, Marek Vasut -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Should be Acked-by and Reviewed-by inherited for updated patches?
Hello exports. When re-posting updated a patch (or patch series), should be Acked-by and Reviewed-by tag inherited? Let me give an example. I posted First step towards Kbuild: Use Kbuild style makefiles v3. Simon reviewed it and issued Acked-by tag. The series: Acked-by: Simon Glass s...@chromium.org But, unfortunately the series cannot be applied on the current u-boot/master any more. I will need to rebase the series on the u-boot/master and re-post them as v4. In this case, should I include Acked-by: Simon Glass s...@chromium.org in the log of v4 series? I think Acked-by tag for v3 cannot garantee the validity of v4. So, strictly speaking, I think I should drop Acked-by tag if any change exists between v3 and v4. Or should I use a common sense? Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/5] usb: ums: code refactoring to improve reusability on other boards.
Hi Lukasz, Przemyslaw, Hi Marek, Dear Przemyslaw Marczak, This patch introduces some cleanups to ums code. Changes: ums common: - introduce UMS_START_SECTOR and UMS_NUM_SECTORS as defined in usb_mass_storage.h both default values as 0 if board config doesn't define them common cleanup changes: - change name of struct ums_board_info to ums - ums_device fields are moved to struct ums and dev_num is removed - change function name: board_ums_init to ums_init - remove extern prefixes from usb_mass_storage.h cmd_usb_mass_storage: - change error() to printf() if need to print info message - change return values to command_ret_t type at ums command code - add command usage string Changes v2: ums common: - always returns number of read/write sectors - coding style clean-up ums gadget: - calculate amount of read/write from device returned value. Hi Lukasz, can I get ack/nak on the series? Thanks! For the whole series: Acked-by: Lukasz Majewski l.majew...@samsung.com Applied all. Thanks! 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 v2] usb: ohci-hcd: submit_common_msg: report actual_length properly
Dear Mateusz Kulikowski, submit_common_msg should report amount of data passed from/to device. Instead, it always returned size requested by Host. Signed-off-by: Mateusz Kulikowski mateusz.kulikow...@gmail.com --- drivers/usb/host/ohci-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c index c33c487..8a9e5f4 100644 --- a/drivers/usb/host/ohci-hcd.c +++ b/drivers/usb/host/ohci-hcd.c @@ -1548,7 +1548,7 @@ int submit_common_msg(struct usb_device *dev, unsigned long pipe, void *buffer, } dev-status = stat; - dev-act_len = transfer_len; + dev-act_len = urb-actual_length; #ifdef DEBUG pkt_print(urb, dev, pipe, buffer, transfer_len, Applied, thanks! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] i2c, omap24xx: convert driver to new mutlibus/mutliadapter framework
On 22/10/2013 11:03, Heiko Schocher wrote: - add omap24xx driver to new multibus/multiadpater support - adapted all config files, which uses this driver Tested on the am335x based siemens boards rut, dxr2 and pxm2 posted here: http://patchwork.ozlabs.org/patch/263211/ Signed-off-by: Heiko Schocher h...@denx.de Tested-by: Tom Rini tr...@ti.com Cc: Lars Poeschel poesc...@lemonage.de Cc: Steve Sakoman sako...@gmail.com Cc: Thomas Weber we...@corscience.de Cc: Tom Rix tom@windriver.com Cc: Grazvydas Ignotas nota...@gmail.com Cc: Enric Balletbo i Serra eballe...@iseebcn.com Cc: Luca Ceresoli luca.ceres...@comelit.it Cc: Igor Grinberg grinb...@compulab.co.il Cc: Ilya Yanok ya...@emcraft.com Cc: Stefano Babic sba...@denx.de Cc: Nishanth Menon n...@ti.com Cc: Pali Rohár pali.ro...@gmail.com Cc: Peter Barada peter.bar...@logicpd.com Cc: Nagendra T S nagen...@mistralsolutions.com Cc: Michael Jones michael.jo...@matrix-vision.de Cc: Raphael Assenat r...@8d.com --- Acked-by: Stefano Babic sba...@denx.de Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cosmetic: sf: hex values are in lower case
All other hex values in sf_probe.c are in lower case so we should
fix this one too.
Signed-off-by: Luka Perkov l...@openwrt.org
---
drivers/mtd/spi/sf_probe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index 5eb8ffe..7ecbd96 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -66,7 +66,7 @@ static const struct spi_flash_params spi_flash_params_table[]
= {
{MX25L6405D, 0xc22017, 0x0, 64 * 1024, 128,
0},
{MX25L12805, 0xc22018, 0x0, 64 * 1024, 256,
0},
{MX25L25635F,0xc22019, 0x0, 64 * 1024, 512,
0},
- {MX25L51235F,0xc2201A, 0x0, 64 * 1024, 1024,
0},
+ {MX25L51235F,0xc2201a, 0x0, 64 * 1024, 1024,
0},
{MX25L12855E,0xc22618, 0x0, 64 * 1024, 256,
0},
#endif
#ifdef CONFIG_SPI_FLASH_SPANSION /* SPANSION */
--
1.8.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] sf: probe: add support for MX25L2006E
Add support for Macronix MX25L2006E SPI flash.
Signed-off-by: Luka Perkov l...@openwrt.org
---
drivers/mtd/spi/sf_probe.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index 7ecbd96..07f8a4b 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -59,6 +59,7 @@ static const struct spi_flash_params spi_flash_params_table[]
= {
{GD25LQ32, 0xc86016, 0x0, 64 * 1024,64,
SECT_4K},
#endif
#ifdef CONFIG_SPI_FLASH_MACRONIX /* MACRONIX */
+ {MX25L2006E, 0xc22012, 0x0, 64 * 1024, 4,
0},
{MX25L4005, 0xc22013, 0x0, 64 * 1024, 8,
0},
{MX25L8005, 0xc22014, 0x0, 64 * 1024,16,
0},
{MX25L1605D, 0xc22015, 0x0, 64 * 1024,32,
0},
--
1.8.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] getstr() function?
Hi, experts: Uboot has provided a getc() function. So how about getstr() function? It seems: not provide getstr() ? Best wishes, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: ATMEL: eb_cpux9k2: fix TEXT_BASE for ramboot target
From: Jens Scharsig (BuS Elektronik) e...@bus-elektronik.de Since more functions are enabled, the eb_cpux9k2_ram target does not boot. This patch changed the TEXT_BASE, that the code fits between TEXT_BASE and ram end. Signed-off-by: Jens Scharsig (BuS Elektronik) e...@bus-elektronik.de --- include/configs/eb_cpux9k2.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/configs/eb_cpux9k2.h b/include/configs/eb_cpux9k2.h index b8e672f..883bbfc 100644 --- a/include/configs/eb_cpux9k2.h +++ b/include/configs/eb_cpux9k2.h @@ -36,7 +36,7 @@ #define CONFIG_SYS_TEXT_BASE 0x #else #define CONFIG_SKIP_LOWLEVEL_INIT -#define CONFIG_SYS_TEXT_BASE 0x21f0 +#define CONFIG_SYS_TEXT_BASE 0x2180 #endif #define CONFIG_SYS_LOAD_ADDR 0x2100 /* default load address */ #define CONFIG_STANDALONE_LOAD_ADDR0x2100 @@ -133,6 +133,7 @@ #define CONFIG_CMD_UBI #define CONFIG_CMD_MTDPARTS #define CONFIG_CMD_UBIFS + #define CONFIG_SYS_LONGHELP /* -- 1.8.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH][v2] powerpc/T1040EMU: Add T1040 emulator support
Add emulator support for T1040. Emulator has limited peripherals
and interfaces.
Difference between T1040QDS and emulator includes:
-ECC for DDR is disabled due to procedure to load images
-Depends on raw timing for DDR initialization
-No board FPGA (Qixis)
-No PCI
-No SPI
-No flash support
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
Signed-off-by: Priyanka Jain priyanka.j...@freescale.com
---
Changes for v2: Incorporated Wolfgang Denk's review comments
Based on u-boot-mpc85xx/next branch.
This patch depends upon following patches:
1)[U-Boot] powerpc/t1040qds: Add DDR Raw Timing support
http://patchwork.ozlabs.org/patch/286112/
2)[U-Boot] powerpc/t1040qds: Correct Maintainer name in boards.cfg
http://patchwork.ozlabs.org/patch/286113/
board/freescale/t1040qds/Makefile |3 +-
board/freescale/t1040qds/ddr.c |3 +
board/freescale/t1040qds/ddr.h | 13 ++
board/freescale/t1040qds/t1040emu.c | 75
board/freescale/t1040qds/tlb.c |4 +
boards.cfg |1 +
include/configs/T1040EMU.h | 344 +++
7 files changed, 442 insertions(+), 1 deletions(-)
create mode 100644 board/freescale/t1040qds/t1040emu.c
create mode 100644 include/configs/T1040EMU.h
diff --git a/board/freescale/t1040qds/Makefile
b/board/freescale/t1040qds/Makefile
index 8f0057b..4bd7103 100644
--- a/board/freescale/t1040qds/Makefile
+++ b/board/freescale/t1040qds/Makefile
@@ -8,7 +8,8 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).o
-COBJS-y+= $(BOARD).o
+COBJS-$(CONFIG_T1040QDS) += t1040qds.o
+COBJS-$(CONFIG_T1040EMU) += t1040emu.o
COBJS-y+= ddr.o
COBJS-$(CONFIG_PCI) += pci.o
COBJS-y+= law.o
diff --git a/board/freescale/t1040qds/ddr.c b/board/freescale/t1040qds/ddr.c
index 16ab829..d46021b 100644
--- a/board/freescale/t1040qds/ddr.c
+++ b/board/freescale/t1040qds/ddr.c
@@ -123,6 +123,9 @@ phys_size_t initdram(int board_type)
puts(Initializingusing SPD\n);
dram_size = fsl_ddr_sdram();
+#ifdef CONFIG_T1040EMU
+ dram_size = CONFIG_SYS_SDRAM_SIZE * 1024 * 1024;
+#endif
dram_size = setup_ddr_tlbs(dram_size / 0x10);
dram_size *= 0x10;
diff --git a/board/freescale/t1040qds/ddr.h b/board/freescale/t1040qds/ddr.h
index 4a4f76a..5e0a078 100644
--- a/board/freescale/t1040qds/ddr.h
+++ b/board/freescale/t1040qds/ddr.h
@@ -54,6 +54,18 @@ struct board_specific_parameters {
* for each n_ranks group.
*/
+#ifdef CONFIG_T1040EMU
+static const struct board_specific_parameters udimm0[] = {
+ /*
+* memory controller 0
+* num| hi| rank| clk| wrlvl | wrlvl | wrlvl | cpo |wrdata|2T
+* ranks| mhz| GB |adjst| start | ctl2| ctl3 | |delay |
+*/
+ {2, 2140, 4, 4, 8, 0x0, 0x0, 0xff,2, 0},
+ {1, 2140, 4, 4, 8, 0x0, 0x0, 0xff,2, 0},
+ {}
+};
+#else
static const struct board_specific_parameters udimm0[] = {
/*
* memory controller 0
@@ -72,6 +84,7 @@ static const struct board_specific_parameters udimm0[] = {
{1, 2140, 0, 4, 8, 0x090a0b0c, 0x0e0f100b, 0xff,2, 0},
{}
};
+#endif
static const struct board_specific_parameters *udimms[] = {
udimm0,
diff --git a/board/freescale/t1040qds/t1040emu.c
b/board/freescale/t1040qds/t1040emu.c
new file mode 100644
index 000..e9362d6
--- /dev/null
+++ b/board/freescale/t1040qds/t1040emu.c
@@ -0,0 +1,75 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include command.h
+#include i2c.h
+#include netdev.h
+#include linux/compiler.h
+#include asm/mmu.h
+#include asm/processor.h
+#include asm/cache.h
+#include asm/immap_85xx.h
+#include asm/fsl_law.h
+#include asm/fsl_serdes.h
+#include asm/fsl_portals.h
+#include asm/fsl_liodn.h
+#include fm_eth.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int checkboard(void)
+{
+ struct cpu_type *cpu = gd-arch.cpu;
+ printf(Board: %sEMU\n, cpu-name);
+ return 0;
+}
+
+int board_early_init_r(void)
+{
+ const unsigned int flashbase = CONFIG_SYS_FLASH_BASE;
+ const u8 flash_esel = find_tlb_idx((void *)flashbase, 1);
+
+ /*
+* Remap Boot flash + PROMJET region to caching-inhibited
+* so that flash can be erased properly.
+*/
+
+ /* Flush d-cache and invalidate i-cache of any FLASH data */
+ flush_dcache();
+ invalidate_icache();
+
+ /* invalidate existing TLB entry for flash + promjet */
+ disable_tlb(flash_esel);
+
+ set_tlb(1, flashbase, CONFIG_SYS_FLASH_BASE_PHYS,
+ MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
+ 0, flash_esel, BOOKE_PAGESZ_256M, 1);
+ set_liodns();
+#ifdef CONFIG_SYS_DPAA_QBMAN
+ setup_portals();
+#endif
+
+ return 0;
+}
+
+
+int
Re: [U-Boot] [RESEND PATCH 2/3] mx28evk: Add 'nandboot' environment command
Hello, I am not sure I agree ... On Sun, Oct 27, 2013 at 6:47 PM, Marek Vasut ma...@denx.de wrote: Dear Otavio Salvador, On Sun, Oct 27, 2013 at 2:16 PM, Marek Vasut ma...@denx.de wrote: Dear Otavio Salvador, This reads the kernel, ftd and boot into ubifs filesystem. While on that, the SD firmware filename definition has been moved next to the other SD related commands. Signed-off-by: Otavio Salvador ota...@ossystems.com.br Any changes to built-in environment are now NAKd I believe. I don't see a reason to not merged it for now; I will work in porting the environments for the external file but this could go now, anyway. Read [1], in particular what Stefano said. http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/169042 Thus this patch shall be rejected as well, sorry. I agree with the goal but until we have a way to insert the /default/ environment into the binary of U-Boot for use (not adding an extra environment image) this should be accepted. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] ARM: mxs: Configure 2 Gbit DDR2 RAM for BG0900
From: Christoph G. Baumann c.baum...@ppc-ag.de
The BG0900 module has 2Gbit DRAM module on it, adjust the DataBahn
DRAM controller registers so the DRAM module will be correctly
recognised.
Signed-off-by: Christoph G. Baumann c.baum...@ppc-ag.de
Cc: Marek Vasut ma...@denx.de
Cc: Stefano Babic sba...@denx.de
Cc: Fabio Estevam fabio.este...@freescale.com
---
board/ppcag/bg0900/spl_boot.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/board/ppcag/bg0900/spl_boot.c b/board/ppcag/bg0900/spl_boot.c
index 2616e1f..a04c955 100644
--- a/board/ppcag/bg0900/spl_boot.c
+++ b/board/ppcag/bg0900/spl_boot.c
@@ -118,6 +118,19 @@ const iomux_cfg_t iomux_setup[] = {
void mxs_adjust_memory_params(uint32_t *dram_vals)
{
+ /*
+* DDR Controller Registers
+* Manufacturer:Winbond
+* Device Part Number: W972GG6JB-25I
+* Clock Freq.: 200MHz
+* Density: 2Gb
+* Chip Selects:1
+* Number of Banks: 8
+* Row address: 14
+* Column address: 10
+*/
+
+ dram_vals[0x74 / 4] = 0x0102010A;
dram_vals[0x98 / 4] = 0x04005003;
dram_vals[0x9c / 4] = 0x09c8;
--
1.8.4.rc3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] ARM: mxs: Enable DCDC converter for battery boot
In case the board detected sufficient voltage for battery boot, make sure the DCDC converter is ON and the board is not running only from linregs, otherwise an instability will be observed. Signed-off-by: Marek Vasut ma...@denx.de Cc: Stefano Babic sba...@denx.de Cc: Fabio Estevam fabio.este...@freescale.com --- arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c index 8ea45be..d25019a 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c @@ -654,6 +654,8 @@ static void mxs_batt_boot(void) clrsetbits_le32(power_regs-hw_power_5vctrl, POWER_5VCTRL_CHARGE_4P2_ILIMIT_MASK, 0x8 POWER_5VCTRL_CHARGE_4P2_ILIMIT_OFFSET); + + mxs_power_enable_4p2(); } /** -- 1.8.4.rc3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH 2/3] mx28evk: Add 'nandboot' environment command
Dear Otavio Salvador, Hello, I am not sure I agree ... On Sun, Oct 27, 2013 at 6:47 PM, Marek Vasut ma...@denx.de wrote: Dear Otavio Salvador, On Sun, Oct 27, 2013 at 2:16 PM, Marek Vasut ma...@denx.de wrote: Dear Otavio Salvador, This reads the kernel, ftd and boot into ubifs filesystem. While on that, the SD firmware filename definition has been moved next to the other SD related commands. Signed-off-by: Otavio Salvador ota...@ossystems.com.br Any changes to built-in environment are now NAKd I believe. I don't see a reason to not merged it for now; I will work in porting the environments for the external file but this could go now, anyway. Read [1], in particular what Stefano said. http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/169042 Thus this patch shall be rejected as well, sorry. I agree with the goal but until we have a way to insert the /default/ environment into the binary of U-Boot for use (not adding an extra environment image) this should be accepted. I disagree with the decision to reject the envs as well, I just present previous discussion here. I will pull out of this discussion and leave the rest up to Stefano, since this is his call afterall. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH 2/3] mx28evk: Add 'nandboot' environment command
Hi Otavio, On 28/10/2013 12:19, Otavio Salvador wrote: Hello, I am not sure I agree ... On Sun, Oct 27, 2013 at 6:47 PM, Marek Vasut ma...@denx.de wrote: Dear Otavio Salvador, On Sun, Oct 27, 2013 at 2:16 PM, Marek Vasut ma...@denx.de wrote: Dear Otavio Salvador, This reads the kernel, ftd and boot into ubifs filesystem. While on that, the SD firmware filename definition has been moved next to the other SD related commands. Signed-off-by: Otavio Salvador ota...@ossystems.com.br Any changes to built-in environment are now NAKd I believe. I don't see a reason to not merged it for now; I will work in porting the environments for the external file but this could go now, anyway. Read [1], in particular what Stefano said. http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/169042 Thus this patch shall be rejected as well, sorry. I agree with the goal but until we have a way to insert the /default/ environment into the binary of U-Boot for use (not adding an extra environment image) this should be accepted. Indeed. However, why cannot we do the right thing soon ? It is very interesting if Simon's patches will flow into mainline soon - as feeling, I see some comments by Wolfgang, but no evident signal that they will be stopped. Octavio, I will wait for your patches for a while and if Simon's patches will be accepted soon, I will kindly ask you to reformat your patches, moving the default environment into an .env file. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC8641D stucks before relocation
I disabled the 2nd core by using cfg_core1_enable and D2_MSRCID1 signal is not connected and we are using DDR controller 2... will this create any obstacles to relocate? Is there any other register configuration for DDR? can somebody help me to understand this or give me some pointer to get more understanding for this... I am getting frusted because I am stuck at this point from last 20 days. please help... thanks in advance and Regards On Sat, Oct 26, 2013 at 12:20 AM, Ashish Khetan curieux.khe...@gmail.comwrote: Thanks For reply, i check DDR configuration using Code warrior, and successfully getting read/write from DDR. I use the following configuration in code warrior and same in u-boot... writemem.l 0xf8006000 0x001f # CS0_BNDSwritemem.l 0xf8006080 0x80914102 # CS0_CONFIGwritemem.l0xf8006100 0x0007 # TIMING_CFG_3writemem.l0xf8006104 0xFF770F0F # TIMING_CFG_0 writemem.l 0xf8006108 0x7F78F777 # TIMING_CFG_1 writemem.l0xf800610C 0x00205114 # TIMING_CFG_2 writemem.l0xf8006110 0x43088008 # DDR_SDRAM_CFG writemem.l0xf8006114 0x24401000 # DDR_SDRAM_CFG2 writemem.l0xf8006118 0x43800E52 # DDR_SDRAM_MODE writemem.l 0xf800611C 0x8000C000 # DDR_SDRAM_MODE_2writemem.l0xf8006120 0x # DDR_SDRAM_MD_CNTL writemem.l0xf8006124 0x0508 # DDR_SDRAM_INTERVAL writemem.l0xf8006128 0x # DDR_DATA_INIT writemem.l0xf8006130 0x0380 # DDR_SDRAM_CLK_CNTL sleep 200 writemem.l0xf8006110 0xC3088008 # DDR_SDRAM_CFG but I did not understand... can you give some light on this. thanks again... On Fri, Oct 25, 2013 at 10:25 PM, York Sun york...@freescale.com wrote: It is probably because your DDR wasn't initialized correctly. You can try to dump all DDR registers and check if anyone is suspicious. You can also override any register before enabling the controller. You may also add some memory test before relocation. York On 10/25/2013 06:38 AM, Ashish Khetan wrote: hii I am using MPC8641D based custom board for evaluation purpose. I am using minimal configuration for this board i.e. only FLASH and DDR initialisation. when I compiled U-boot in debug mode its printing addresses, i check for those addresses and found that it is unable to relocate itself to DDR(4*MT47H64M16). The following message was printed... U-Boot 2013.04 (Oct 25 2013 - 15:05:33) Unicore software on multiprocessor system!! To enable mutlticore build define CONFIG_MP CPU: 8641, Version: 2.1, (0x80900021) Core: E600 Core 0 (MSSCR0=8000, PORDEVSR=ab08307), Version: 2.2, (0x80040202) Clock Configuration: CPU:800 MHz, MPX:400 MHz DDR:200 MHz (400 MT/s data rate), LBC:25 MHz L1:D-cache 32 KB enabled I-cache 32 KB enabled L2:Disabled Board: Wind River SBC8641D DRAM: DDR: 512 MiB Top of RAM usable for U-Boot at: 2000 Reserving 114k for U-Boot at: 1ffe3000 Reserving 136k for malloc() at: 1ffc1000 Reserving 80 Bytes for Board Info at: 1ffc0fb0 Reserving 152 Bytes for Global Data at: 1ffc0f18 Stack Pointer at: 1ffc0f00 New Stack Pointer is: 1ffc0f00 and stuck here... Any pointer or link to get more about this will be helpful. Thanks in Advance ___ 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] [RESEND PATCH 2/3] mx28evk: Add 'nandboot' environment command
On Mon, Oct 28, 2013 at 9:32 AM, Stefano Babic sba...@denx.de wrote: Hi Otavio, On 28/10/2013 12:19, Otavio Salvador wrote: Hello, I am not sure I agree ... On Sun, Oct 27, 2013 at 6:47 PM, Marek Vasut ma...@denx.de wrote: Dear Otavio Salvador, On Sun, Oct 27, 2013 at 2:16 PM, Marek Vasut ma...@denx.de wrote: Dear Otavio Salvador, This reads the kernel, ftd and boot into ubifs filesystem. While on that, the SD firmware filename definition has been moved next to the other SD related commands. Signed-off-by: Otavio Salvador ota...@ossystems.com.br Any changes to built-in environment are now NAKd I believe. I don't see a reason to not merged it for now; I will work in porting the environments for the external file but this could go now, anyway. Read [1], in particular what Stefano said. http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/169042 Thus this patch shall be rejected as well, sorry. I agree with the goal but until we have a way to insert the /default/ environment into the binary of U-Boot for use (not adding an extra environment image) this should be accepted. Indeed. However, why cannot we do the right thing soon ? There're no pending patches to address the root problem yet (allowing changing /internal and default/ environment). It is very interesting if Simon's patches will flow into mainline soon - as feeling, I see some comments by Wolfgang, but no evident signal that they will be stopped. Octavio, I will wait for your patches for a while and if Simon's patches will be accepted soon, I will kindly ask you to reformat your patches, moving the default environment into an .env file. I will rework the environments as .env files but I don't want to hold this change until this is accepted. My patch is fine and could go in now as is. Once Simon's patches get in I will post another series reworking the environment to convert it to the .env file format but please don't block on this. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [[PATCH]pandaboard: 1/1] Modification of Elpida DDR2 RAM for Pandaboard-ES Rev B3
On 10/25/2013 10:42 AM, Hardik wrote: From: Hardik Patel hardik.pa...@volansystech.com Signed-off-by: Hardik Patel hardik.pa...@volansystech.com --- include/configs/omap4_common.h |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h index e9f2383..9aa4030 100644 --- a/include/configs/omap4_common.h +++ b/include/configs/omap4_common.h @@ -240,7 +240,12 @@ #define CONFIG_SYS_CACHELINE_SIZE32 /* Defines for SDRAM init */ -#define CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS + +/* + * Enable automatic sdram detection + * for detecting Elpida RAM on Rev B3 + */ +#undef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS Nak This is used on all other Panda revisions. Why are we just disabling this for all devices when one device is the issue? And as discussed off line I have an older B3 which boots fine on the uBoot mainline. So what is the difference between your B3 and my B3? Please answer this to the community or point to a reference were one can determine what B3 board they have Dan #ifndef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS #define CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION -- -- Dan Murphy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [[PATCH]pandaboard: 1/1] Modification of Elpida DDR2 RAM for Pandaboard-ES Rev B3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/28/2013 08:51 AM, Dan Murphy wrote: On 10/25/2013 10:42 AM, Hardik wrote: From: Hardik Patel hardik.pa...@volansystech.com Signed-off-by: Hardik Patel hardik.pa...@volansystech.com --- include/configs/omap4_common.h |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h index e9f2383..9aa4030 100644 --- a/include/configs/omap4_common.h +++ b/include/configs/omap4_common.h @@ -240,7 +240,12 @@ #define CONFIG_SYS_CACHELINE_SIZE32 /* Defines for SDRAM init */ -#define CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS + +/* + * Enable automatic sdram detection + * for detecting Elpida RAM on Rev B3 + */ +#undef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS Nak This is used on all other Panda revisions. Why are we just disabling this for all devices when one device is the issue? And as discussed off line I have an older B3 which boots fine on the uBoot mainline. So what is the difference between your B3 and my B3? Please answer this to the community or point to a reference were one can determine what B3 board they have I think we've got two issues here: a) Your B3 is apparently an early non-public rev. b) When we use the automatic timing calculation code, it then spits out what the values are (I would swear) so that you can then plug them back in. We should make B3 know what the right timing values to use are. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSbmD5AAoJENk4IS6UOR1WuZcQAIvGDclBm78ecq6NTz+3Otv1 ln5C67Yo+7ZuiP5s7N5Ag7kKP2ZkzioouV+W9qFj/VxQBY6k2auyfXGRQ/aCamm5 pTmvdkQQCnqFgTfBTWofpRTQJkwMTT16cVpe+BQa4EriowklvHRfR8dHGmS5Figp 5Ta/xTo3HVa2eU5AK4StB7eQHjqMxHA5EUSD+c1sSmqSdX6aXi2DDjA3IpvakrOf GsrZ6hKzooMPYPEgg/kqWRO5fOESu+bTw87afkpxntkanTa8XTq8INb4EiR8iMSp 3dyvZxEzmslykPV5k38hN8UPT/ZInn9pD6nXtXp/JqqQm7MQguCR+nvS/BpP3S9z LWwCYtxtHoigw9v+LBTZ93AbgGgeOH8w5l0DFABFNWQhEilSHPYn7t3cpH9GfLjy 1nmTYezYTfoeiIkqtuUmGzJ6zM43W0lka/yCIi0TfFRha6qvR5LYadSe2YmKZaSg yxV4Q6v4VIMQWLXpS2777ExQDcTcGLZR+MHdLfLsmUd4X+3kU9Dk7XO0o0Ek/n8F pleX3+d6QJpPe7kFUReHPGRaGbRo52zwz5J8k2FcUY7aAS2fPBC4l/xbH+iD7TAn q6k7yAs0r5+zsWtosg/tkWwQUzlvgf7KmmYyBnMRtQojvQrhbRfj8a7wuboPmzlT 6XuJH/wGNtgCFZ/IQuBe =+35Q -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] ARM: tegra: Add the Tamonten™ NG Evaluation Carrier board
On Mon, 21 Oct 2013 16:28:46 +0200 Alban Bedel alban.be...@avionic-design.de wrote: Add support for the new Tamonten™ NG platform from Avionic Design. Currently only I2C, MMC, USB and ethernet have been tested. Signed-off-by: Alban Bedel alban.be...@avionic-design.de Is there still some problem with this series? Or I am doing something wrong that prevent the merging? Alban ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-boot] getstr() function?
Dear tiger...@viatech.com.cn, In message fe7aded5c2218b4786c09cd97dc4c49fb06...@exchbj02.viatech.com.bj you wrote: Uboot has provided a getc() function. Correct. So how about getstr() function? What about it? It's not a standard libc function. It's described in the XSI Curses standard, but we don;t have any curses support in U-Boot. It seems: not provide getstr() ? Correct. May I ask where you think getstr() would be beneficial? 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 Beware of the Turing Tar-pit in which everything is possible but nothing of interest is easy. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH 2/3] mx28evk: Add 'nandboot' environment command
Dear Otavio, In message cap9odkpn+pmx1hp+7bemp7u-hc44onc6pepan+nbzbqm8cd...@mail.gmail.com you wrote: Indeed. However, why cannot we do the right thing soon ? There're no pending patches to address the root problem yet (allowing changing /internal and default/ environment). Simon's patch set env: Add support for environment files does exactly that. I will rework the environments as .env files but I don't want to hold this change until this is accepted. Please be patient, like we all are. It's better to wait a bit now, then adding work now, and adding more work later to clean up the mess again. My patch is fine and could go in now as is. Once Simon's patches get in I will post another series reworking the environment to convert it to the .env file format but please don't block on this. I agree with Stefano that we should not add more to the already existing amount of env settings but instead wait for a cleaner way. Please be patient - you lose nothing here. 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 C makes it easy for you to shoot yourself in the foot. C++ makes that harder, but when you do, it blows away your whole leg. -- Bjarne Stroustrup ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH 2/3] mx28evk: Add 'nandboot' environment command
On Mon, Oct 28, 2013 at 11:21 AM, Wolfgang Denk w...@denx.de wrote: Dear Otavio, In message cap9odkpn+pmx1hp+7bemp7u-hc44onc6pepan+nbzbqm8cd...@mail.gmail.com you wrote: Indeed. However, why cannot we do the right thing soon ? There're no pending patches to address the root problem yet (allowing changing /internal and default/ environment). Simon's patch set env: Add support for environment files does exactly that. Doing it without changing source code, directly into the binary? From what I read it allows import / export but this is at runtime, I need it /before/ booting the board. So currently I need to patch the environment files for it. I will rework the environments as .env files but I don't want to hold this change until this is accepted. Please be patient, like we all are. It's better to wait a bit now, then adding work now, and adding more work later to clean up the mess again. The work has already been done. My patch is fine and could go in now as is. Once Simon's patches get in I will post another series reworking the environment to convert it to the .env file format but please don't block on this. I agree with Stefano that we should not add more to the already existing amount of env settings but instead wait for a cleaner way. Please be patient - you lose nothing here. I really see no point in holding it as the work has been done already; it is Stefano call but I disagree with postpone it as work is done and being in use. I will comment on Simon's patch to clarify my understanding there. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/5] Allow U-Boot scripts to be placed in a .env file
Hello, On Sat, Oct 26, 2013 at 3:01 AM, Simon Glass s...@chromium.org wrote: At present U-Boot environment variables, and thus scripts, are defined by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text to this file and dealing with quoting and newlines is harder than it should be. It would be better if we could just type the script into a text file and have it included by U-Boot. Add a feature that brings in a .env file associated with the board config, if present. To use it, create a file in a board/vendor/env directory called board.env (or common.env if you want the same environment for all boards). The environment variables should be of the form var=value. Values can extend to multiple lines. See the README under 'Environment Variables:' for more information and an example. Comments are not permitted in the environment with this commit. Signed-off-by: Simon Glass s...@chromium.org I think people (or myself) are misunderstanding what this patch does. My understand is: - it allow moving environment setting to a .env file - it needs to include the environment at /build/ time This does improve a lot the current status (and I really appreciate it); one missing thing (or I missed it completely) is a way to: - build u-boot (binary) - generate a binary version of the environment - glue both together in a way the new environment /replaces/ the default environment originally written inside u-boot (binary) Am I missing something? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH 2/3] mx28evk: Add 'nandboot' environment command
Dear Otavio, In message CAP9ODKq0Ac6azBOav7R54RncB9=mhtmz+hydjy0uiyuscs1...@mail.gmail.com you wrote: Simon's patch set env: Add support for environment files does exactly that. Doing it without changing source code, directly into the binary? Yes. From what I read it allows import / export but this is at runtime, I need it /before/ booting the board. So currently I need to patch the environment files for it. Please re-read it again. Please be patient, like we all are. It's better to wait a bit now, then adding work now, and adding more work later to clean up the mess again. The work has already been done. Yes, but that's actually your own problem; it seems you ignored the previous discussion. 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 Bureaucracy is the enemy of innovation. - Mark Shepherd, former President and CEO of Texas Instruments ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH 2/3] mx28evk: Add 'nandboot' environment command
Hi Otavio, On 28/10/2013 14:29, Otavio Salvador wrote: On Mon, Oct 28, 2013 at 11:21 AM, Wolfgang Denk w...@denx.de wrote: Dear Otavio, In message cap9odkpn+pmx1hp+7bemp7u-hc44onc6pepan+nbzbqm8cd...@mail.gmail.com you wrote: Indeed. However, why cannot we do the right thing soon ? There're no pending patches to address the root problem yet (allowing changing /internal and default/ environment). Simon's patch set env: Add support for environment files does exactly that. Doing it without changing source code, directly into the binary? From what I read it allows import / export but this is at runtime, I need it /before/ booting the board. So currently I need to patch the environment files for it. The way I see with Simon's patch is to define a .env file for each use case we can have. Because the environment is outside the configuration file, we could select the right environment when we produce the binary. Let's say we have two environments, one defined from you and the other as debian environment. We could select the desired environment at build time by the make command or adding an entry into boards.cfg, exactly as we do now to select the imximage file with IMX_CONFIG (same sources, different imximage.cfg). I understand that even with Simon's patches we will not have a way to have separate u-boot nad environment binaries, and then merge them together. However, we have a way to select which environment type (distro, minimal, ..) at build time. I will rework the environments as .env files but I don't want to hold this change until this is accepted. Please be patient, like we all are. It's better to wait a bit now, then adding work now, and adding more work later to clean up the mess again. The work has already been done. My patch is fine and could go in now as is. Once Simon's patches get in I will post another series reworking the environment to convert it to the .env file format but please don't block on this. I agree with Stefano that we should not add more to the already existing amount of env settings but instead wait for a cleaner way. Please be patient - you lose nothing here. I really see no point in holding it as the work has been done already; it is Stefano call but I disagree with postpone it as work is done and being in use. Another example is maybe not in your wandboard: add Future Eletronics 7 WVGA LCD extension board. In that patch, you add a lot of stuff inside CONFIG_EXTRA_ENV, that is perfectly suitable for your needs, but it is maybe not suitable for someone else who has not a display or maybe another LCD. But again, it fits then perfectly if we define different .env files, and it is possible to select one of them at build time. It is then not exactly as we started, that is having two different images (u-boot and environemnt) and finding a way to merge them together, but it is quite close. I will comment on Simon's patch to clarify my understanding there. Fine, I will follow the discussion. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] cm_t35 tune up
Ping On 10/07/2013 05:28 PM, Nikita Kiryanov wrote: This patchset is a collection of short cm_t35 updates. It changes some configuration parameters and turns on GPIO commands. Nikita Kiryanov (3): cm_t35: reduce default bootdelay to 3 seconds cm_t35: turn on GPIO commands cm_t35: update lcd predefines board/compulab/cm_t35/display.c | 8 +++- include/configs/cm_t35.h| 3 ++- 2 files changed, 9 insertions(+), 2 deletions(-) -- Regards, Nikita. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/8] main: Use autoconf to remove #ifdefs around process_boot_delay()
On 06/17/2013 04:44 PM, Simon Glass wrote:
Use autoconf to make process_boot_delay() be compiled always, and adjust
the caller and related functions as needed.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v4:
- Split out new patch to remove #ifdefs around process_boot_delay()
Changes in v3: None
Changes in v2: None
common/main.c | 71
++-
1 file changed, 31 insertions(+), 40 deletions(-)
diff --git a/common/main.c b/common/main.c
index 3a4754d..dba6cee 100644
--- a/common/main.c
+++ b/common/main.c
@@ -79,8 +79,6 @@ extern void mdm_init(void); /* defined in board.c */
* Watch for 'delay' seconds for autoboot stop or autoboot delay string.
* returns: 0 - no key string, allow autoboot 1 - got key string, abort
*/
-#if defined(CONFIG_BOOTDELAY)
-# if defined(CONFIG_AUTOBOOT_KEYED)
static int abortboot_keyed(int bootdelay)
{
int abort = 0;
@@ -173,8 +171,6 @@ static int abortboot_keyed(int bootdelay)
return abort;
}
-# else /* !defined(CONFIG_AUTOBOOT_KEYED) */
-
static int menukey;
static int abortboot_normal(int bootdelay)
@@ -228,17 +224,14 @@ static int abortboot_normal(int bootdelay)
return abort;
}
-# endif /* CONFIG_AUTOBOOT_KEYED */
static int abortboot(int bootdelay)
{
-#ifdef CONFIG_AUTOBOOT_KEYED
- return abortboot_keyed(bootdelay);
-#else
- return abortboot_normal(bootdelay);
-#endif
+ if (autoconf_autoboot_keyed())
+ return abortboot_keyed(bootdelay);
+ else
+ return abortboot_normal(bootdelay);
}
-#endif /* CONFIG_BOOTDELAY */
/*
* Runs the given boot command securely. Specifically:
@@ -254,7 +247,6 @@ static int abortboot(int bootdelay)
* printing the error message to console.
*/
-#if defined(CONFIG_BOOTDELAY) defined(CONFIG_OF_CONTROL)
static void secure_boot_cmd(char *cmd)
{
cmd_tbl_t *cmdtp;
@@ -295,22 +287,21 @@ static void process_fdt_options(const void *blob)
/* Add an env variable to point to a kernel payload, if available */
addr = fdtdec_get_config_int(gd-fdt_blob, kernel-offset, 0);
- if (addr)
- setenv_addr(kernaddr, (void *)(CONFIG_SYS_TEXT_BASE + addr));
+ if (addr) {
+ setenv_addr(kernaddr,
+ (void *)(autoconf_sys_text_base() + addr));
+ }
/* Add an env variable to point to a root disk, if available */
addr = fdtdec_get_config_int(gd-fdt_blob, rootdisk-offset, 0);
- if (addr)
- setenv_addr(rootaddr, (void *)(CONFIG_SYS_TEXT_BASE + addr));
+ if (addr) {
+ setenv_addr(rootaddr,
+ (void *)(autoconf_sys_text_base() + addr));
+ }
}
-#endif /* CONFIG_OF_CONTROL */
-#ifdef CONFIG_BOOTDELAY
static void process_boot_delay(void)
{
-#ifdef CONFIG_OF_CONTROL
- char *env;
-#endif
char *s;
int bootdelay;
#ifdef CONFIG_BOOTCOUNT_LIMIT
@@ -327,7 +318,7 @@ static void process_boot_delay(void)
#endif /* CONFIG_BOOTCOUNT_LIMIT */
s = getenv (bootdelay);
- bootdelay = s ? (int)simple_strtol(s, NULL, 10) : CONFIG_BOOTDELAY;
+ bootdelay = s ? (int)simple_strtol(s, NULL, 10) : autoconf_bootdelay();
#ifdef CONFIG_OF_CONTROL
bootdelay = fdtdec_get_config_int(gd-fdt_blob, bootdelay,
@@ -357,23 +348,24 @@ static void process_boot_delay(void)
else
#endif /* CONFIG_BOOTCOUNT_LIMIT */
s = getenv (bootcmd);
-#ifdef CONFIG_OF_CONTROL
- /* Allow the fdt to override the boot command */
- env = fdtdec_get_config_string(gd-fdt_blob, bootcmd);
- if (env)
- s = env;
+ if (autoconf_of_control()) {
+ char *env;
- process_fdt_options(gd-fdt_blob);
+ /* Allow the fdt to override the boot command */
+ env = fdtdec_get_config_string(gd-fdt_blob, bootcmd);
+ if (env)
+ s = env;
- /*
- * If the bootsecure option was chosen, use secure_boot_cmd().
- * Always use 'env' in this case, since bootsecure requres that the
- * bootcmd was specified in the FDT too.
- */
- if (fdtdec_get_config_int(gd-fdt_blob, bootsecure, 0))
- secure_boot_cmd(env);
+ process_fdt_options(gd-fdt_blob);
-#endif /* CONFIG_OF_CONTROL */
+ /*
+ * If the bootsecure option was chosen, use secure_boot_cmd().
+ * Always use 'env' in this case, since bootsecure requres that
+ * the bootcmd was specified in the FDT too.
+ */
This indentation doesn't look good to me.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Re: [U-Boot] [PATCH v4 6/8] main: Use autoconf for parser selection
On 10/26/2013 05:14 PM, Simon Glass wrote:
Allow parser selection to make use of autoconf instead of #ifdefs.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v4:
- Rebase on current master
Changes in v3: None
Changes in v2: None
common/main.c | 87
+++---
include/hush.h | 2 --
2 files changed, 41 insertions(+), 48 deletions(-)
diff --git a/common/main.c b/common/main.c
index b744234..060da11 100644
--- a/common/main.c
+++ b/common/main.c
@@ -366,12 +366,10 @@ static void process_boot_delay(void)
void main_loop(void)
{
-#ifndef CONFIG_SYS_HUSH_PARSER
static char lastcommand[CONFIG_SYS_CBSIZE] = { 0, };
int len;
int rc = 1;
int flag;
-#endif
#ifdef CONFIG_PREBOOT
char *p;
#endif
@@ -428,12 +426,11 @@ void main_loop(void)
/*
* Main Loop for Monitor Command Processing
*/
-#ifdef CONFIG_SYS_HUSH_PARSER
- parse_file_outer();
- /* This point is never reached */
- for (;;);
-#else
- for (;;) {
+ if (autoconf_sys_hush_parser()) {
+ parse_file_outer();
+ /* This point is never reached */
+ for (;;);
+ } else {
if (autoconf_boot_retry_time() rc = 0) {
/* Saw enough of a valid command to
* restart the timeout.
@@ -468,7 +465,6 @@ void main_loop(void)
lastcommand[0] = 0;
}
}
-#endif /*CONFIG_SYS_HUSH_PARSER*/
}
/*
@@ -1158,7 +1154,6 @@ int parse_line (char *line, char *argv[])
//
-#ifndef CONFIG_SYS_HUSH_PARSER
static void process_macros (const char *input, char *output)
{
char c, prev;
@@ -1366,7 +1361,6 @@ static int builtin_run_command(const char *cmd, int
flag)
return rc ? rc : repeatable;
}
-#endif
/*
* Run a command using the selected parser.
@@ -1377,22 +1371,21 @@ static int builtin_run_command(const char *cmd, int
flag)
*/
int run_command(const char *cmd, int flag)
{
-#ifndef CONFIG_SYS_HUSH_PARSER
- /*
- * builtin_run_command can return 0 or 1 for success, so clean up
- * its result.
- */
- if (builtin_run_command(cmd, flag) == -1)
- return 1;
-
- return 0;
-#else
- return parse_string_outer(cmd,
+ if (autoconf_sys_hush_parser()) {
+ return parse_string_outer(cmd,
FLAG_PARSE_SEMICOLON | FLAG_EXIT_FROM_LOOP);
-#endif
+ } else {
+ /*
+ * builtin_run_command can return 0 or 1 for success, so
+ * clean up its result.
+ */
same here.
+ if (builtin_run_command(cmd, flag) == -1)
+ return 1;
+
+ return 0;
+ }
}
-#ifndef CONFIG_SYS_HUSH_PARSER
/**
* Execute a list of command separated by ; or \n using the built-in parser.
*
@@ -1433,7 +1426,6 @@ static int builtin_run_command_list(char *cmd, int flag)
return rcode;
}
-#endif
int run_command_list(const char *cmd, int len, int flag)
{
@@ -1443,13 +1435,16 @@ int run_command_list(const char *cmd, int len, int
flag)
if (len == -1) {
len = strlen(cmd);
-#ifdef CONFIG_SYS_HUSH_PARSER
- /* hush will never change our string */
- need_buff = 0;
-#else
- /* the built-in parser will change our string if it sees \n */
- need_buff = strchr(cmd, '\n') != NULL;
-#endif
+ if (autoconf_sys_hush_parser()) {
+ /* hush will never change our string */
+ need_buff = 0;
+ } else {
+ /*
+ * the built-in parser will change our string if it
+ * sees \n
+ */
+ need_buff = strchr(cmd, '\n') != NULL;
+ }
}
if (need_buff) {
buff = malloc(len + 1);
@@ -1458,20 +1453,20 @@ int run_command_list(const char *cmd, int len, int
flag)
memcpy(buff, cmd, len);
buff[len] = '\0';
}
-#ifdef CONFIG_SYS_HUSH_PARSER
- rcode = parse_string_outer(buff, FLAG_PARSE_SEMICOLON);
-#else
- /*
- * This function will overwrite any \n it sees with a \0, which
- * is why it can't work with a const char *. Here we are making
- * using of internal knowledge of this function, to avoid always
- * doing a malloc() which is actually required only in a case that
- * is pretty rare.
- */
- rcode = builtin_run_command_list(buff, flag);
- if (need_buff)
- free(buff);
-#endif
+ if (autoconf_sys_hush_parser()) {
+ rcode = parse_string_outer(buff, FLAG_PARSE_SEMICOLON);
+ } else {
+
Re: [U-Boot] [PATCH v4 0/8] Provide a mechanism to avoid using #ifdef everywhere
Dear Simon, In message 1382800457-26608-1-git-send-email-...@chromium.org you wrote: Many parts of the U-Boot code base are sprinkled with #ifdefs. This makes different boards compile different versions of the source code, meaning that we must build all boards to check for failures. It is easy to misspell an #ifdef and there is not as much checking of this by the compiler. Multiple dependent #ifdefs are harder to do than with if..then..else. Variable declarations must be #idefed as well as the code that uses them, often much later in the file/function. #ifdef indents don't match code indents and have their own separate indent feature. Overall, excessive use of #idef hurts readability and makes the code harder to modify and refactor. For people coming newly into the code base, #ifdefs can be a big barrier. While I agree in general with the goal and the implementation, there is an implementation detail I dislike - this is that the new code is harder to type and to read - I mean, something like CONFIG_SYS_HUSH_PARSER is already clumsy enough, but making this autoconf_sys_hush_parser() appears to be worse. Also, the connection to a CONFIG_* option is not easily visible. I also had feedback from Detlev (who is unfortunately on a business trip again so he didn't find time [yet] to comment himself); he commented that he really likes the idea, but does not like that we now have to access the well-known contants using a new name. Maybe we can find a shorter / easier to read way to do this - I think it would be really nice if we could see the well-known names. 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 Where there's no emotion, there's no motive for violence. -- Spock, Dagger of the Mind, stardate 2715.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/8] Provide a mechanism to avoid using #ifdef everywhere
On Mon, Oct 28, 2013 at 03:44:01PM +0100, Wolfgang Denk wrote:
Dear Simon,
In message 1382800457-26608-1-git-send-email-...@chromium.org you wrote:
Many parts of the U-Boot code base are sprinkled with #ifdefs. This makes
different boards compile different versions of the source code, meaning
that we must build all boards to check for failures. It is easy to misspell
an #ifdef and there is not as much checking of this by the compiler.
Multiple
dependent #ifdefs are harder to do than with if..then..else. Variable
declarations must be #idefed as well as the code that uses them, often much
later in the file/function. #ifdef indents don't match code indents and
have their own separate indent feature. Overall, excessive use of #idef
hurts readability and makes the code harder to modify and refactor. For
people coming newly into the code base, #ifdefs can be a big barrier.
While I agree in general with the goal and the implementation, there
is an implementation detail I dislike - this is that the new code
is harder to type and to read - I mean, something like
CONFIG_SYS_HUSH_PARSER is already clumsy enough, but making this
autoconf_sys_hush_parser() appears to be worse. Also, the connection
to a CONFIG_* option is not easily visible.
I also had feedback from Detlev (who is unfortunately on a business
trip again so he didn't find time [yet] to comment himself); he
commented that he really likes the idea, but does not like that we now
have to access the well-known contants using a new name.
Maybe we can find a shorter / easier to read way to do this - I think
it would be really nice if we could see the well-known names.
I guess this is what I get for not being like Linus sometimes[1]. I think
what this series highlights is that we have a lot of code in
common/main.c that needs either re-thinking, re-factoring or splitting
out into difference functions and files. And when we're turning
#ifdef CONFIG_FOO
... whatever ...
#endif
into
if (autoconf_foo()) {
... whatever ...
}
The code starts looking worse in some cases since we're already 3
indents in. The problem is we have lots of ifdef code, in some areas of
the code. This hides the problem, not fixes the problem.
Looking over the first parts of the series, weak functions for example
would help in a number of cases, especially if we split things out of
main.c and into other files too.
--
Tom
[1]: By which I mean being very forceful when saying I don't like an
idea.
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC8641D stucks before relocation
I see you have relaxed most timing to the slowest. Debugging DDR is not about trial and error because there are so many parameters. Could you get some guidance from hardware designers? If you can't, I suggest you get the spec and do the math yourself, using the DDR driver we have in u-boot. BTW, your TIMING_CFG_2 seems to be fast. I don't know if that would cause any issue. Your mode register also seems suspicious. York On 10/28/2013 05:01 AM, Ashish Khetan wrote: I disabled the 2nd core by using cfg_core1_enable and D2_MSRCID1 signal is not connected and we are using DDR controller 2... will this create any obstacles to relocate? Is there any other register configuration for DDR? can somebody help me to understand this or give me some pointer to get more understanding for this... I am getting frusted because I am stuck at this point from last 20 days. please help... thanks in advance and Regards On Sat, Oct 26, 2013 at 12:20 AM, Ashish Khetan curieux.khe...@gmail.com mailto:curieux.khe...@gmail.com wrote: Thanks For reply, i check DDR configuration using Code warrior, and successfully getting read/write from DDR. I use the following configuration in code warrior and same in u-boot... writemem.l 0xf8006000 0x001f # CS0_BNDS writemem.l 0xf8006080 0x80914102 # CS0_CONFIG writemem.l0xf8006100 0x0007 # TIMING_CFG_3 writemem.l0xf8006104 0xFF770F0F # TIMING_CFG_0 writemem.l0xf8006108 0x7F78F777 # TIMING_CFG_1 writemem.l0xf800610C 0x00205114 # TIMING_CFG_2 writemem.l0xf8006110 0x43088008 # DDR_SDRAM_CFG writemem.l0xf8006114 0x24401000 # DDR_SDRAM_CFG2 writemem.l0xf8006118 0x43800E52 # DDR_SDRAM_MODE writemem.l0xf800611C 0x8000C000 # DDR_SDRAM_MODE_2 writemem.l0xf8006120 0x # DDR_SDRAM_MD_CNTL writemem.l0xf8006124 0x0508 # DDR_SDRAM_INTERVAL writemem.l0xf8006128 0x # DDR_DATA_INIT writemem.l0xf8006130 0x0380 # DDR_SDRAM_CLK_CNTL sleep 200 writemem.l0xf8006110 0xC3088008 # DDR_SDRAM_CFG but I did not understand... can you give some light on this. thanks again... On Fri, Oct 25, 2013 at 10:25 PM, York Sun york...@freescale.com mailto:york...@freescale.com wrote: It is probably because your DDR wasn't initialized correctly. You can try to dump all DDR registers and check if anyone is suspicious. You can also override any register before enabling the controller. You may also add some memory test before relocation. York On 10/25/2013 06:38 AM, Ashish Khetan wrote: hii I am using MPC8641D based custom board for evaluation purpose. I am using minimal configuration for this board i.e. only FLASH and DDR initialisation. when I compiled U-boot in debug mode its printing addresses, i check for those addresses and found that it is unable to relocate itself to DDR(4*MT47H64M16). The following message was printed... U-Boot 2013.04 (Oct 25 2013 - 15:05:33) Unicore software on multiprocessor system!! To enable mutlticore build define CONFIG_MP CPU: 8641, Version: 2.1, (0x80900021) Core: E600 Core 0 (MSSCR0=8000, PORDEVSR=ab08307), Version: 2.2, (0x80040202) Clock Configuration: CPU:800 MHz, MPX:400 MHz DDR:200 MHz (400 MT/s data rate), LBC:25 MHz L1:D-cache 32 KB enabled I-cache 32 KB enabled L2:Disabled Board: Wind River SBC8641D DRAM: DDR: 512 MiB Top of RAM usable for U-Boot at: 2000 Reserving 114k for U-Boot at: 1ffe3000 Reserving 136k for malloc() at: 1ffc1000 Reserving 80 Bytes for Board Info at: 1ffc0fb0 Reserving 152 Bytes for Global Data at: 1ffc0f18 Stack Pointer at: 1ffc0f00 New Stack Pointer is: 1ffc0f00 and stuck here... Any pointer or link to get more about this will be helpful. Thanks in Advance ___ U-Boot mailing list U-Boot@lists.denx.de mailto: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
[U-Boot] Configuring U-Boot through device tree (was: Minutes from the U-Boot Mini Summit 2013)
Am 27.10.2013 18:07, schrieb Detlev Zundel: ... ** Configuring U-Boot through device tree - _What_ should be configured? - Google requires every new U-Boot driver to be configured through device tree in U-Boot - Configuring U-Boot through device trees shall aim for using the exact same tree from the Linux kernel. At ELCE, I attended the Barebox presentation. One Barebox feature presented there was Configure Barbox through device tree. So the Barebox people seem to have this already running for some selected boards. After their presentation I asked them how do you decide which parts are configured in the boot loader, and which in the kernel, then?. And got the quick answer in doubt, the configuration is done two times. Do we really want this? If we use the same device tree for U-Boot and the Linux kernel (which most probably makes sense) do we really want to do the initialization part we do already in U-Boot again in the kernel? I'm thinking about pin mux or clock settings described in the device tree, which are need to get the U-Boot drivers working. If these are done two times, then, what's about the risk of clock or pin glitches doing the same configuration in the kernel a second time? Do we need a mechanism to do some configuration only at one place? Or isn't there any risk and we can do the same configuration two times? What do you think? Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Configuring U-Boot through device tree (was: Minutes from the U-Boot Mini Summit 2013)
Dear Dirk, In message 526e9740.3070...@gmail.com you wrote: At ELCE, I attended the Barebox presentation. One Barebox feature presented there was Configure Barbox through device tree. So the Barebox people seem to have this already running for some selected boards. After their presentation I asked them how do you decide which parts are configured in the boot loader, and which in the kernel, then?. And got the quick answer in doubt, the configuration is done two times. Do we really want this? Well, basically yes, we have to do this. If we use the same device tree for U-Boot and the Linux kernel (which most probably makes sense) do we really want to do the initialization part we do already in U-Boot again in the kernel? We may not want to do it, but in general there is no way around it if you do not want to establish strong interdependencies of a kernel port for some hardware and a specific boot loader for that system - which is generally considered a bad idea. It has always been a good idea for a device driver to not make any assumptions about the previous state of the hardware, and to perform all required initializations. In some cases this may be redundant overhead, in other cases it may be mandatory. We have seen cases (in real life) where certain pieces of the hardware have been used in different, incompatible configurations (say, the SCC port on a PowerQUICC CPU first as a serial port, then as an Ethenret port, and then again as serial) by using loadable modules. In such cases you cannot rely on any previous settings being passed on by the boot loader. Today, where even the hardware can be reconfigured under your feet (see for example Altera's SOCFPGA or Xilinx' Zynq) this may become even more important. Also, I still believe it is a Good Thing (TM) for a boot loader to only initialize such hardware that it actually uses itself (the reasons have been discussed often before). One more reason for Linux drivers not to assume that all necessary initialization was already done. Actually the same is true vice versa: the boot loader cannot know which drivers the Linux kernel will be running. We cannot simply turn on clocks in U-Boot based on the hope they might be useful for Linux, while the system will actually be running an application profile tuned for lowest possible power consumption, so we ruin their setup, or force re-init anyway. I'm thinking about pin mux or clock settings described in the device tree, which are need to get the U-Boot drivers working. If these are done two times, then, what's about the risk of clock or pin glitches doing the same configuration in the kernel a second time? I agree that such things need to be done really carefully to avoid such problems - but actually these are not really new. You have to apply the same care for the initialization already now. Do we need a mechanism to do some configuration only at one place? Or isn't there any risk and we can do the same configuration two times? What do you think? I think any such discussion depends on the answer of a few other questions: * Will the Linux kernel accept to depend on specific features of a specific boot loader? * Who is reponsible to define the interface between the kernel and the boot loader, i. e. for the decision which interfaces shall be initialized, and how? * What is the API for such communication between Linux and U-Boot? Do we have a way to tell Linux about already initiualized interfaces (and eventually even as important: about their state)? How do we pass error status information to Linux? Hm... while writing this my feeling that this will simply not work deepens. I guess, if you want to minimize overlap of activities, you will probably head for setups like SPL in Falcon Mode, where (in production mode) the overlap is at least minimized. 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 Boss, n.: According to the Oxford English Dictionary, in the Middle Ages the words boss and botch were largely synonymous, except that boss, in addition to meaning a supervisor of workers also meant an ornamental stud. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/5] RFC: tegra: Convert to using environment files
On 10/25/2013 11:01 PM, Simon Glass wrote: This seems more intuitive that the current #define way of doing things. The resulting code is shorter, avoids the quoting and line continuation pain, and also improves the clumsy way that stdio variables are created: #ifdef CONFIG_VIDEO_TEGRA #define STDOUT_LCD ,lcd #else #define STDOUT_LCD #endif ... #define TEGRA_DEVICE_SETTINGS \ stdout=serial STDOUT_LCD \0 \ ... The MEM_LAYOUT_ENV_SETTINGS variable is left in the header files, since it depends on the SOC type and we probably don't want to add .emv files for each board at this stage. I guess I'm fine with this as long as e.g. board/compulab/env/trimslice.env can contain: #include ../../../board/nvidia/env/common.env ... or perhaps the include path is set up to include board/nvidia/env already, so it could just contain: #include common-nvidia.env diff --git a/board/nvidia/env/common.env b/board/nvidia/env/common.env +bootcmd_mmc0=setenv devnum 0; run mmc_boot +bootcmd_mmc1=setenv devnum 1; run mmc_booxt +boot_targets+= mmc1 mmc0 I still don't see why = needs no space before/after, but += needs no space before, but a space after. That simply looks like a typo to me, and I'd be inclined to fix it were I editing this file. If a sed script can't handle more flexible white-space, perhaps use Python or perhaps Perl instead? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/8] Provide a mechanism to avoid using #ifdef everywhere
Hi Tom,
On Mon, Oct 28, 2013 at 9:32 AM, Tom Rini tr...@ti.com wrote:
On Mon, Oct 28, 2013 at 03:44:01PM +0100, Wolfgang Denk wrote:
Dear Simon,
In message 1382800457-26608-1-git-send-email-...@chromium.org you wrote:
Many parts of the U-Boot code base are sprinkled with #ifdefs. This makes
different boards compile different versions of the source code, meaning
that we must build all boards to check for failures. It is easy to misspell
an #ifdef and there is not as much checking of this by the compiler.
Multiple
dependent #ifdefs are harder to do than with if..then..else. Variable
declarations must be #idefed as well as the code that uses them, often much
later in the file/function. #ifdef indents don't match code indents and
have their own separate indent feature. Overall, excessive use of #idef
hurts readability and makes the code harder to modify and refactor. For
people coming newly into the code base, #ifdefs can be a big barrier.
While I agree in general with the goal and the implementation, there
is an implementation detail I dislike - this is that the new code
is harder to type and to read - I mean, something like
CONFIG_SYS_HUSH_PARSER is already clumsy enough, but making this
autoconf_sys_hush_parser() appears to be worse. Also, the connection
to a CONFIG_* option is not easily visible.
I also had feedback from Detlev (who is unfortunately on a business
trip again so he didn't find time [yet] to comment himself); he
commented that he really likes the idea, but does not like that we now
have to access the well-known contants using a new name.
Maybe we can find a shorter / easier to read way to do this - I think
it would be really nice if we could see the well-known names.
I guess this is what I get for not being like Linus sometimes[1]. I think
what this series highlights is that we have a lot of code in
common/main.c that needs either re-thinking, re-factoring or splitting
out into difference functions and files. And when we're turning
#ifdef CONFIG_FOO
... whatever ...
#endif
into
if (autoconf_foo()) {
... whatever ...
}
The code starts looking worse in some cases since we're already 3
indents in. The problem is we have lots of ifdef code, in some areas of
the code. This hides the problem, not fixes the problem.
While I agree with this, the question is more whether using the
compiler instead of the preprocessor helps with reducing the number of
code paths and the number of boards we must build to test things. In
many cases the CONFIG options hide features that we don't want to
enable.
I did a series that improved main.c in various ways including
splitting the code differently - there are a few more things that
could be done, but it will still be a mountain of #ifdefs.
I would quite like to split the command editing stuff into its own
file - in fact main.c could be split into several files:
- command line
- command editing
- parser
But does this help? I wasn't entirely sure.
Looking over the first parts of the series, weak functions for example
would help in a number of cases, especially if we split things out of
main.c and into other files too.
I am not a huge fan of weak functions since it isn't clear what
happens when they are called. But again if you have a specific example
it would help me understand your intent here.
Regards,
Simon
--
Tom
[1]: By which I mean being very forceful when saying I don't like an
idea.
BTW I am not sure about this idea either - let's figure out exactly
what it can help with and whether it is worth it. Perhaps main.c was
not the best choice - but board files have loads of #ifdefs also.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/5] RFC: tegra: Convert to using environment files
Hi Stephen, On Mon, Oct 28, 2013 at 1:59 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 10/25/2013 11:01 PM, Simon Glass wrote: This seems more intuitive that the current #define way of doing things. The resulting code is shorter, avoids the quoting and line continuation pain, and also improves the clumsy way that stdio variables are created: #ifdef CONFIG_VIDEO_TEGRA #define STDOUT_LCD ,lcd #else #define STDOUT_LCD #endif ... #define TEGRA_DEVICE_SETTINGS \ stdout=serial STDOUT_LCD \0 \ ... The MEM_LAYOUT_ENV_SETTINGS variable is left in the header files, since it depends on the SOC type and we probably don't want to add .emv files for each board at this stage. I guess I'm fine with this as long as e.g. board/compulab/env/trimslice.env can contain: #include ../../../board/nvidia/env/common.env ... or perhaps the include path is set up to include board/nvidia/env already, so it could just contain: #include common-nvidia.env diff --git a/board/nvidia/env/common.env b/board/nvidia/env/common.env +bootcmd_mmc0=setenv devnum 0; run mmc_boot +bootcmd_mmc1=setenv devnum 1; run mmc_booxt +boot_targets+= mmc1 mmc0 I still don't see why = needs no space before/after, but += needs no space before, but a space after. That simply looks like a typo to me, and I'd be inclined to fix it were I editing this file. If a sed script can't handle more flexible white-space, perhaps use Python or perhaps Perl instead? The old code was similar, in that it had a space after the quote. We need the string to contain mmc0 mmc1 usb0 dhcp or perhaps mmc0 mmc1. I chose to add a space at the start of each string, but certainly we need a space somewhere, or we get mmc0mmc1usb0dhcp. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Question about patman
Hi Masahiro, On Sun, Oct 27, 2013 at 11:37 PM, Masahiro Yamada yamad...@jp.panasonic.com wrote: Hello Simon. I'm trying patman, but it looks like it doesn't work on my Ubuntu box. How can I resove the following issue? The subject of HEAD is ARM: align MVBAR on 32 byte boundary and the result of my dry run is: $ python --version Python 2.7.4 $ tools/patman/patman -n -c1 Cleaned 1 patches Traceback (most recent call last): File tools/patman/patman, line 153, in module not options.ignore_bad_tags) File /home/yamada/workspace/arm-linux-pf/u-boot/tools/patman/series.py, line 225, in MakeCcFile raise_on_error=raise_on_error) File /home/yamada/workspace/arm-linux-pf/u-boot/tools/patman/gitutil.py, line 308, in BuildEmailList raw += LookupEmail(item, alias, raise_on_error=raise_on_error) File /home/yamada/workspace/arm-linux-pf/u-boot/tools/patman/gitutil.py, line 472, in LookupEmail raise ValueError, msg ValueError: Alias 'arm' not found You should put an alias for arm in your ~/.patman file, like this: albert: Albert Aribaud albert.u.b...@aribaud.net arm: albert There is also a -t option to skip bad aliases. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/5] Allow U-Boot scripts to be placed in a .env file
Hi Wolfgang,
On Sat, Oct 26, 2013 at 2:26 PM, Wolfgang Denk w...@denx.de wrote:
Dear Simon,
In message 1382763695-2849-4-git-send-email-...@chromium.org you wrote:
+For example, for snapper9260 you would create a text file called
+board/bluewater/env/snapper9260.env containing the environment text.
+
+
+bootcmd=
+ if [ -z ${tftpserverip} ]; then
+ echo Use 'setenv tftpserverip a.b.c.d' to set IP address.
+ fi
+
+ usb start; setenv autoload n; bootp;
+ tftpboot ${tftpserverip}:
+ bootm
+failed=
+ echo boot failed - please check your image
+
+
+The resulting environment can be exported and importing using the
+'env export/import -t' commands.
I think this statement is misleading. It reads as if thois text coul
actually be imported using env import -t, which is not correct. And
the result of an env export -t of equivalent command settings will
look pretty much different, too.
The point here is that it is possible to export the default
environment that has been created at build time. Agreed this should be
worded better.
I can see why you like such a beautified text format, but I don;t
think you are doing anybody a favour here. Can we not rather use
_exactly_ the same text format as U-Boot uses with it's import /
export commands?
That would be nice, but how to we handle newlines? Some scripts are
quite long. Do we need to put \ at the end of every line? That feels a
bit painful to me.
Also how do we handle #define? Without it I don't think this feature
is useful, since the existing build system often sticks CONFIG
variables into the environment.
This would make it _much_ easier to experiment on a system and modify
the environment until it fits all the requirements and passes all
tests, and then export it as a text file and use this directly
(without editing) for the input needed here?
I believe that is already possible - you should be able to take the
output of 'env export -t' and put it in the .env file. I have not
tried it though.
...
--- /dev/null
+++ b/tools/scripts/env2string.awk
@@ -0,0 +1,48 @@
+#
+# (C) Copyright 2013 Google, Inc
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Sed script to parse a text file containing an environment and convert it
+# to a C string which can be compiled into U-Boot.
That doesn't look like sed to me, looks more like awk :-)
Hmm, yes I gave up on sed after a while. Will fix.
+ # Is this the start of a new environment variable?
+ if (match($0, ^([^ =][^ =]*)=(.*), arr)) {
I think this is a bit naive...
Example (using notation as exported by U-Boot using env export -t):
foo=setenv xxx\
one=1;setenv yyy\
two=2;setenv zzz\
three=3
+ # Print out all the variables
+ for (var in vars) {
+ print var = vars[var] \\0;
+ }
I think it should not be difficult to find examples that would result
incorrect output.
I will take a look at this - here it is the \ at the end of line which
needs to be handled.
I guess this needs more work - but then - why define a new format at
all? Why not use what U-Boot uses itself?
See above, would be good to resolve this issue before going any further.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/5] Allow U-Boot scripts to be placed in a .env file
Hi Otavio, On Mon, Oct 28, 2013 at 7:34 AM, Otavio Salvador ota...@ossystems.com.br wrote: Hello, On Sat, Oct 26, 2013 at 3:01 AM, Simon Glass s...@chromium.org wrote: At present U-Boot environment variables, and thus scripts, are defined by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text to this file and dealing with quoting and newlines is harder than it should be. It would be better if we could just type the script into a text file and have it included by U-Boot. Add a feature that brings in a .env file associated with the board config, if present. To use it, create a file in a board/vendor/env directory called board.env (or common.env if you want the same environment for all boards). The environment variables should be of the form var=value. Values can extend to multiple lines. See the README under 'Environment Variables:' for more information and an example. Comments are not permitted in the environment with this commit. Signed-off-by: Simon Glass s...@chromium.org I think people (or myself) are misunderstanding what this patch does. Possibly, I'm not sure. My understand is: - it allow moving environment setting to a .env file - it needs to include the environment at /build/ time Yes This does improve a lot the current status (and I really appreciate it); one missing thing (or I missed it completely) is a way to: - build u-boot (binary) - generate a binary version of the environment - glue both together in a way the new environment /replaces/ the default environment originally written inside u-boot (binary) Am I missing something? This is something that Wolfgang would like to see (as would I), but I think it is a separate feature. This feature is just trying to simplify creation of the build-time default environment. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/5] RFC: tegra: Convert to using environment files
On 10/28/2013 02:34 PM, Simon Glass wrote: Hi Stephen, On Mon, Oct 28, 2013 at 1:59 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 10/25/2013 11:01 PM, Simon Glass wrote: This seems more intuitive that the current #define way of doing things. The resulting code is shorter, avoids the quoting and line continuation pain, and also improves the clumsy way that stdio variables are created: #ifdef CONFIG_VIDEO_TEGRA #define STDOUT_LCD ,lcd #else #define STDOUT_LCD #endif ... #define TEGRA_DEVICE_SETTINGS \ stdout=serial STDOUT_LCD \0 \ ... The MEM_LAYOUT_ENV_SETTINGS variable is left in the header files, since it depends on the SOC type and we probably don't want to add .emv files for each board at this stage. I guess I'm fine with this as long as e.g. board/compulab/env/trimslice.env can contain: #include ../../../board/nvidia/env/common.env ... or perhaps the include path is set up to include board/nvidia/env already, so it could just contain: #include common-nvidia.env diff --git a/board/nvidia/env/common.env b/board/nvidia/env/common.env +bootcmd_mmc0=setenv devnum 0; run mmc_boot +bootcmd_mmc1=setenv devnum 1; run mmc_booxt +boot_targets+= mmc1 mmc0 I still don't see why = needs no space before/after, but += needs no space before, but a space after. That simply looks like a typo to me, and I'd be inclined to fix it were I editing this file. If a sed script can't handle more flexible white-space, perhaps use Python or perhaps Perl instead? The old code was similar, in that it had a space after the quote. We need the string to contain mmc0 mmc1 usb0 dhcp or perhaps mmc0 mmc1. I chose to add a space at the start of each string, but certainly we need a space somewhere, or we get mmc0mmc1usb0dhcp. Oh, I see. I thought the space was part of the += syntax, not the value. Perhaps to make that more obvious, you could allow: # No space added to value var+=value var+= value var +=value var += value var+=value1 value2 var+= value1 value2 var +=value1 value2 var += value1 value2 var+=value1 value2 var+= value1 value2 var +=value1 value2 var += value1 value2 # One space included at start of addition to value var+= value1 value2 var+= value1 value2 var += value1 value2 var += value1 value2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/5] RFC: tegra: Convert to using environment files
Hi Stephen, On Mon, Oct 28, 2013 at 2:41 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 10/28/2013 02:34 PM, Simon Glass wrote: Hi Stephen, On Mon, Oct 28, 2013 at 1:59 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 10/25/2013 11:01 PM, Simon Glass wrote: This seems more intuitive that the current #define way of doing things. The resulting code is shorter, avoids the quoting and line continuation pain, and also improves the clumsy way that stdio variables are created: #ifdef CONFIG_VIDEO_TEGRA #define STDOUT_LCD ,lcd #else #define STDOUT_LCD #endif ... #define TEGRA_DEVICE_SETTINGS \ stdout=serial STDOUT_LCD \0 \ ... The MEM_LAYOUT_ENV_SETTINGS variable is left in the header files, since it depends on the SOC type and we probably don't want to add .emv files for each board at this stage. I guess I'm fine with this as long as e.g. board/compulab/env/trimslice.env can contain: #include ../../../board/nvidia/env/common.env ... or perhaps the include path is set up to include board/nvidia/env already, so it could just contain: #include common-nvidia.env diff --git a/board/nvidia/env/common.env b/board/nvidia/env/common.env +bootcmd_mmc0=setenv devnum 0; run mmc_boot +bootcmd_mmc1=setenv devnum 1; run mmc_booxt +boot_targets+= mmc1 mmc0 I still don't see why = needs no space before/after, but += needs no space before, but a space after. That simply looks like a typo to me, and I'd be inclined to fix it were I editing this file. If a sed script can't handle more flexible white-space, perhaps use Python or perhaps Perl instead? The old code was similar, in that it had a space after the quote. We need the string to contain mmc0 mmc1 usb0 dhcp or perhaps mmc0 mmc1. I chose to add a space at the start of each string, but certainly we need a space somewhere, or we get mmc0mmc1usb0dhcp. Oh, I see. I thought the space was part of the += syntax, not the value. Perhaps to make that more obvious, you could allow: # No space added to value var+=value var+= value var +=value var += value var+=value1 value2 var+= value1 value2 var +=value1 value2 var += value1 value2 var+=value1 value2 var+= value1 value2 var +=value1 value2 var += value1 value2 # One space included at start of addition to value var+= value1 value2 var+= value1 value2 var += value1 value2 var += value1 value2 I was deliberately trying to avoid using quotes, since then it is really hard when you actually mean 'quote'. For example at present you can put this in an env script at present, but how would you do it if quotes are special? echo This is a test; or it might not be Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/5] Allow U-Boot scripts to be placed in a .env file
Dear Simon,
In message CAPnjgZ0+35Zd6_o=G0=g-yl_mr-gitw+meyqk7bsxu_nvkv...@mail.gmail.com
you wrote:
I can see why you like such a beautified text format, but I don;t
think you are doing anybody a favour here. Can we not rather use
_exactly_ the same text format as U-Boot uses with it's import /
export commands?
That would be nice, but how to we handle newlines? Some scripts are
quite long. Do we need to put \ at the end of every line? That feels a
bit painful to me.
Agreed. But that's what env export -t creates anyway (and I cannot
think of a much better presentation of multiline variable content if
you don't want to run in ambiguities).
Also how do we handle #define? Without it I don't think this feature
is useful, since the existing build system often sticks CONFIG
variables into the environment.
I don't understand this question here. I agree that we should be able
to run the file through the preprocessor such that it can resolve such
macro definitions. But this should be independent of the actual text
format, or am I missing something?
I believe that is already possible - you should be able to take the
output of 'env export -t' and put it in the .env file. I have not
tried it though.
Hm... I really think we should agree on a common format her e- one
that is easy to work with on both sides.
Example (using notation as exported by U-Boot using env export -t):
foo=setenv xxx\
one=1;setenv yyy\
two=2;setenv zzz\
three=3
+ # Print out all the variables
+ for (var in vars) {
+ print var = vars[var] \\0;
+ }
I think it should not be difficult to find examples that would result
incorrect output.
I will take a look at this - here it is the \ at the end of line which
needs to be handled.
Well, I can't see how you avoid such ambiguities in your proposed
format. You need a clear termination for the value of a variable.
If it is spread across multiple lines, you have to find a way to mark
continuation lines. The accepted standard way to do so is by using
a backslash at the end of the line. It appears you want to use
indentation instead - this prevents users from using a free text
format, and quickly becomes messy. And it is incompatible to
(current) U-Boot code.
I guess this needs more work - but then - why define a new format at
all? Why not use what U-Boot uses itself?
See above, would be good to resolve this issue before going any further.
Above I cannot see any explanation why you define a new format
except for the fact that the backslash as marker for continuation
lines is painful. I'm open on discussing a new format for text
representation (which then also should be used by env print and env
export -t ?). But I'd like to see a description of that format
first (and not just a few examples I can guess from).
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
Only two things are infinite, the universe and human stupidity, and
I'm not sure about the former. -- Albert Einstein
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/5] RFC: tegra: Convert to using environment files
On 10/28/2013 02:50 PM, Simon Glass wrote: Hi Stephen, On Mon, Oct 28, 2013 at 2:41 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 10/28/2013 02:34 PM, Simon Glass wrote: Hi Stephen, On Mon, Oct 28, 2013 at 1:59 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 10/25/2013 11:01 PM, Simon Glass wrote: This seems more intuitive that the current #define way of doing things. The resulting code is shorter, avoids the quoting and line continuation pain, and also improves the clumsy way that stdio variables are created: diff --git a/board/nvidia/env/common.env b/board/nvidia/env/common.env +bootcmd_mmc0=setenv devnum 0; run mmc_boot +bootcmd_mmc1=setenv devnum 1; run mmc_booxt +boot_targets+= mmc1 mmc0 I still don't see why = needs no space before/after, but += needs no space before, but a space after. That simply looks like a typo to me, and I'd be inclined to fix it were I editing this file. If a sed script can't handle more flexible white-space, perhaps use Python or perhaps Perl instead? The old code was similar, in that it had a space after the quote. We need the string to contain mmc0 mmc1 usb0 dhcp or perhaps mmc0 mmc1. I chose to add a space at the start of each string, but certainly we need a space somewhere, or we get mmc0mmc1usb0dhcp. Oh, I see. I thought the space was part of the += syntax, not the value. Perhaps to make that more obvious, you could allow: # No space added to value var+=value ... var += value1 value2 # One space included at start of addition to value var+= value1 value2 var+= value1 value2 var += value1 value2 var += value1 value2 I was deliberately trying to avoid using quotes, since then it is really hard when you actually mean 'quote'. Hmm. On the other hand, quoting is standard syntax in any scripting language. For example at present you can put this in an env script at present, but how would you do it if quotes are special? Just escape it; goes around the string and \ or within the string. This seems pretty common... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: at91: support for the Calao USB-A9263 board (based on AT91SAM9263)
Hi Bo Shen, Thanks for the check, please see below. On 28.10.2013 05:57, Bo Shen wrote: Hi Mateusz Kulikowski, Add Andreas in loop. On 10/28/2013 03:34, Mateusz Kulikowski wrote: (...) +/* + * Disable pull-up on: + * RXDV (PC25) = PHY normal mode (not Test mode) + * ERX0 (PE25) = PHY ADDR0 + * ERX1 (PE26) = PHY ADDR1 = PHYADDR = 0x0 + * + * PHY has internal pull-down + */ +writel(1 25, pio-pioc.pudr); +writel((1 25) | (1 26), pio-pioe.pudr); Use GPIO API instead of hard code. Should I also update (in separate patch) at91sam9263ek board (code is the same there, bad side is - I don't have that board to test)? + +#define CONFIG_SYS_TEXT_BASE 0x23f0 This address should be considered as u-boot is top down map, so if your system only 64MiB, there is only 1MiB left. I don't understand something here: - this address is hardcoded in AT91bootstrap (as well as image size - 0x31000), - I can change it, but it will not boot on stock board - should we force people to recompile AT91bootstrap if they want to use new U-Boot? or - Should I add low-level initialization to boot U-Boot from Dataflash without AT91bootstrap (this is a bit more work)? or - There is another way I'm not aware of (perhaps relocate U-Boot in RAM)? Best Regards, Mateusz Kulikowski ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Illegal use of FP ops in clock_ti814x.c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/27/2013 05:11 PM, Wolfgang Denk wrote: Dear Matt, I hope you are the right person to address this to - if not, please help to redirect to the current responsible developer. Function pll_sigma_delta_val() in arch/arm/cpu/armv7/am33xx/clock_ti814x.c incorrectly uses float data, which results in FP operations which are not permitted in U-Boot. The actual computation appears simple enough so a rewrite of the code without using any floating point operations should be fairly easy, but I don't understand the actual logic of this code, so I'd rather leave this to someone who does. Could you please help and clean up these three lines of code? Matt's moved on to Linaro now (and this is a more public poke to update the maintainers entry you owe me). Care to look at this? - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSbt1nAAoJENk4IS6UOR1Wdy8P/RT18/UG5TBQugaSdqAkscS1 oMRz5M35qZvUuTjRj7JwRMXs/WGhVLO4NP5zDM0eYdo6pD/Z4ZnCPXUpRa46w4X/ xvusu9m+fpKsy/+gEOeOw4+JQ1OnMCLuP0OxpJfvKYwXEOjji5mGxAhxpCTogBFX 6l6vAYiEcYYG2S58AuGFYL9l0y0x7kZNnvfAzM5xJgxNOhxmGefGABuILXWRs5mt rHQBrPlofc+E2n73BxSAxk35cqy1Fm6CP35ETuKb3NMonoYbtXebh3ADyjxaNdf6 IZHpTserTNLaSGUSq2QVrF9zOnQKj/R4fuTbV7biUI3lF5JqVLO+jsx+E5XwTJpD bkQlD+vbmSnzK5HebUG6qEFHWxChjPJ0URSvlb0WBrlQJX9TkK4Xetq9ou6FaSpR xnZ/X6zDuBiuyWdmw01D0en8WSTMHCnYHQ7yAZjL3tuvjoJ6p4xCMFe2FZJE4UUn p1pT+h3zMipwjDrZ57NureCY7mWdCsRBgIR18MTmjF7XYzo7+4F+yi2aaGifGmPu zo1zp+1ijjQCVylw2OXGp09ej6azJcVoaRVS7FBEtd5u6MaSBhgfXTvR1bSB5mqw PbxlnXgfumv+VK3S036FtFXuT8lCx6kWlSLOa9HZSHrwjO0eQv+IeuoVigUnzfq/ oMHEAwDoaJbMjPDgFE2O =c8xm -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] ARM: tegra: Add the Tamonten™ NG Evaluation Carrier board
On 10/21/2013 08:28 AM, Alban Bedel wrote:
Add support for the new Tamonten™ NG platform from Avionic Design.
Currently only I2C, MMC, USB and ethernet have been tested.
What changed in v3? There's no changelog here, so I don't know where to
concentrate my re-review of this patch...
diff --git a/board/avionic-design/common/tamonten-ng.c
b/board/avionic-design/common/tamonten-ng.c
+#define MAX_I2C_RETRY3
I don't think that's used any more.
Most of the PMU #defines aren't used either.
+#ifdef CONFIG_BOARD_EARLY_INIT_F
I don't think any of these ifdefs are required, since the config file
hard-codes all those values. Same for #if defined(CONFIG_TEGRA_MMC)
below, and perhaps more?
+void gpio_early_init(void)
+{
+ /* Turn on the alive signal */
+ gpio_request(GPIO_PV2, ALIVE);
+ gpio_direction_output(GPIO_PV2, 1);
+
+ /* Remove the reset on the reset on the external periph */
reset on the reset on the ?
diff --git a/board/avionic-design/dts/tegra30-tamonten.dtsi
b/board/avionic-design/dts/tegra30-tamonten.dtsi
+ i2c@7000c000 {
+ status = okay;
+ clock-frequency = 10;
+ };
+
+ i2c@7000c400 {
+ status = okay;
+ clock-frequency = 10;
+ };
...
Do all the carrier boards guarantee that all those I2C and SPI, and even
SDHCI busses are routed somewhere? It may be best to defer adding
status=okay to the leaf board files, so you know there's actually
something hooked up there.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/5] RFC: tegra: Convert to using environment files
Hi Stephen, On Mon, Oct 28, 2013 at 3:20 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 10/28/2013 02:50 PM, Simon Glass wrote: Hi Stephen, On Mon, Oct 28, 2013 at 2:41 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 10/28/2013 02:34 PM, Simon Glass wrote: Hi Stephen, On Mon, Oct 28, 2013 at 1:59 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 10/25/2013 11:01 PM, Simon Glass wrote: This seems more intuitive that the current #define way of doing things. The resulting code is shorter, avoids the quoting and line continuation pain, and also improves the clumsy way that stdio variables are created: diff --git a/board/nvidia/env/common.env b/board/nvidia/env/common.env +bootcmd_mmc0=setenv devnum 0; run mmc_boot +bootcmd_mmc1=setenv devnum 1; run mmc_booxt +boot_targets+= mmc1 mmc0 I still don't see why = needs no space before/after, but += needs no space before, but a space after. That simply looks like a typo to me, and I'd be inclined to fix it were I editing this file. If a sed script can't handle more flexible white-space, perhaps use Python or perhaps Perl instead? The old code was similar, in that it had a space after the quote. We need the string to contain mmc0 mmc1 usb0 dhcp or perhaps mmc0 mmc1. I chose to add a space at the start of each string, but certainly we need a space somewhere, or we get mmc0mmc1usb0dhcp. Oh, I see. I thought the space was part of the += syntax, not the value. Perhaps to make that more obvious, you could allow: # No space added to value var+=value ... var += value1 value2 # One space included at start of addition to value var+= value1 value2 var+= value1 value2 var += value1 value2 var += value1 value2 I was deliberately trying to avoid using quotes, since then it is really hard when you actually mean 'quote'. Hmm. On the other hand, quoting is standard syntax in any scripting language. For example at present you can put this in an env script at present, but how would you do it if quotes are special? Just escape it; goes around the string and \ or within the string. This seems pretty common... Quoting quotes is currently needed for the header file. So how would my feature actually improve things? Between this and Wolfgang's \ at newline I am wondering if this feature will actually improve anything? It we are really going to insist on making the .env file like a C string then I'm not sure what we gain. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/5] Allow U-Boot scripts to be placed in a .env file
Hi Wolfgang,
On Mon, Oct 28, 2013 at 3:16 PM, Wolfgang Denk w...@denx.de wrote:
Dear Simon,
In message CAPnjgZ0+35Zd6_o=G0=
g-yl_mr-gitw+meyqk7bsxu_nvkv...@mail.gmail.com you wrote:
I can see why you like such a beautified text format, but I don;t
think you are doing anybody a favour here. Can we not rather use
_exactly_ the same text format as U-Boot uses with it's import /
export commands?
That would be nice, but how to we handle newlines? Some scripts are
quite long. Do we need to put \ at the end of every line? That feels a
bit painful to me.
Agreed. But that's what env export -t creates anyway (and I cannot
think of a much better presentation of multiline variable content if
you don't want to run in ambiguities).
I believe the ambiguities are pretty rare. And people tend to indent
multi-line scripts anyway, right?
Also how do we handle #define? Without it I don't think this feature
is useful, since the existing build system often sticks CONFIG
variables into the environment.
I don't understand this question here. I agree that we should be able
to run the file through the preprocessor such that it can resolve such
macro definitions. But this should be independent of the actual text
format, or am I missing something?
Yes we can, agreed. I was thinking you would not want the preprocessor
since 'env export -t' doesn't understand it.
I believe that is already possible - you should be able to take the
output of 'env export -t' and put it in the .env file. I have not
tried it though.
Hm... I really think we should agree on a common format her e- one
that is easy to work with on both sides.
Agreed.
Example (using notation as exported by U-Boot using env export -t):
foo=setenv xxx\
one=1;setenv yyy\
two=2;setenv zzz\
three=3
+ # Print out all the variables
+ for (var in vars) {
+ print var = vars[var] \\0;
+ }
I think it should not be difficult to find examples that would result
incorrect output.
I will take a look at this - here it is the \ at the end of line which
needs to be handled.
Well, I can't see how you avoid such ambiguities in your proposed
format. You need a clear termination for the value of a variable.
If it is spread across multiple lines, you have to find a way to mark
continuation lines. The accepted standard way to do so is by using
a backslash at the end of the line. It appears you want to use
indentation instead - this prevents users from using a free text
format, and quickly becomes messy. And it is incompatible to
(current) U-Boot code.
Indentation is pretty normal in code, so I don't feel embarrassed about
asking for it. I think the primary problem with my feature is that it is
different from 'env export -t', and thus potentially introduces another
format. My argument against that interpretation is that I am in fact
replacing a C header file definition with a text file, so perhaps I'm not
really increasing the number of formats?
I guess this needs more work - but then - why define a new format at
all? Why not use what U-Boot uses itself?
See above, would be good to resolve this issue before going any further.
Above I cannot see any explanation why you define a new format
except for the fact that the backslash as marker for continuation
lines is painful. I'm open on discussing a new format for text
representation (which then also should be used by env print and env
export -t ?). But I'd like to see a description of that format
first (and not just a few examples I can guess from).
From my commit message:
At present U-Boot environment variables, and thus scripts, are defined
by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
to this file and dealing with quoting and newlines is harder than it
should be. It would be better if we could just type the script into a
text file and have it included by U-Boot.
Well yes I could adjust 'env export -t' to use the same format - is that a
good idea, or not? I can see down-sides. We can of course convert existing
files brought in by 'env import -t' (by making the import flexible) but I
worry that there might be external tools that users have which expect the
format to be a certain way.
I agree creating a new format is not ideal - it's just that the existing C
header format is so painful...
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/5] env: Add support for environment files
HI Wolfgang, On Sat, Oct 26, 2013 at 1:26 PM, Wolfgang Denk w...@denx.de wrote: Dear Simon, In message 1382763563-1483-1-git-send-email-...@chromium.org you wrote: (Note that Wolfgang is looking at a way of adjusting the environment within a U-Boot binary - this series could fit with that but aims to improve the creation of the initial default environment). At present U-Boot environment variables, and thus scripts, are defined by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text to this file and dealing with quoting and newlines is harder than it should be. It would be better if we could just type the script into a text file and have it included by U-Boot. I think we need to be very clear hear about what these patches are actually doing. Many users might easily confise the default environment that gets statically built into the U-Boot binary (and that cannot be changed at runtime) with the working environment that gets saved to some persistent storage and is loaded when booting. This is especially important as there are boards where, depending on which state of the boot process you are in, one or the other mightbe in effect (there used to be boards, and probably still are, where full environment access was not possible in the SPL [or whatever it was named then], so you were using the default settings initially, and the real environment only later - which can be extremely confusing - just think of thigs like console baudrate settings etc. Yes agreed, I will have a think about a better title. This series adds a feature that brings in a .env file associated with the board config, if present. To use it, create a file in a board/vendor/env directory called board.env (or common.env if you want the same environment for all boards for that vendor). I understand these patches are trying to improve the way how we initialize the CONFIG_EXTRA_ENV_SETTINGS setting in the _default_ environment _at build time_, right? I feel this should be made really clear in both the Subject: and in the commit message. Agreed. Hm... what was your reason for stopping half-way? Setting only CONFIG_EXTRA_ENV_SETTINGS this way seems inconsequent to me. Why do we not initialize the whole default environment like this? Well just this change has provide quite a bit of discussion - I'm quite pleased I didn't go further! The environment variables should be of the form var=value. Values can extend to multiple lines. See the README under 'Environment Variables:' for more information and an example. I am afraid I dislike the current proposal - see comments to that patch. See my reply there. After discussion on the mailing list the .emv file was moved from include/configs to board/. See here: .emv? Guess this is a typo? Another discussion was compatibility with the environment commands 'env export -t' and 'env import -t'. This series permits these to be used and the environment is exported and imported as expected. I have dropped I can't see how this would work - the examples given in yout README patch definitely cannot be imported using env import -t, which is the reason why I dislike the proposed format. We should probably continue discussion on the other thread. I think I have addressed this now (with your suggestion to perhaps change the format of 'env import -t'). Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Illegal use of FP ops in clock_ti814x.c
Wolfgang Denk w...@denx.de writes:
Dear Matt,
I hope you are the right person to address this to - if not, please
help to redirect to the current responsible developer.
Function pll_sigma_delta_val() in arch/arm/cpu/armv7/am33xx/clock_ti814x.c
incorrectly uses float data, which results in FP operations which
are not permitted in U-Boot.
The actual computation appears simple enough so a rewrite of the code
without using any floating point operations should be fairly easy, but
I don't understand the actual logic of this code, so I'd rather leave
this to someone who does.
Could you please help and clean up these three lines of code?
Something like this should be equivalent. That said, it looks
suspiciously like it's meant to simply do a division and round up. If
that is the case, +225 should be +249. It probably makes no difference
for the values actually encountered.
diff --git a/arch/arm/cpu/armv7/am33xx/clock_ti814x.c
b/arch/arm/cpu/armv7/am33xx/clock_ti814x.c
index ef14f47..9b5a47b 100644
--- a/arch/arm/cpu/armv7/am33xx/clock_ti814x.c
+++ b/arch/arm/cpu/armv7/am33xx/clock_ti814x.c
@@ -211,11 +211,8 @@ static u32 pll_dco_freq_sel(u32 clkout_dco)
static u32 pll_sigma_delta_val(u32 clkout_dco)
{
u32 sig_val = 0;
- float frac_div;
- frac_div = (float) clkout_dco / 250;
- frac_div = frac_div + 0.90;
- sig_val = (int)frac_div;
+ sig_val = (clkout_dco + 225) / 250;
sig_val = sig_val 24;
return sig_val;
--
Måns Rullgård
m...@mansr.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/5] Allow U-Boot scripts to be placed in a .env file
Dear Simon, In message capnjgz3tgwrk2ytm59ekumaipd5kaq39mu9bityl0y6d0h2...@mail.gmail.com you wrote: Agreed. But that's what env export -t creates anyway (and I cannot think of a much better presentation of multiline variable content if you don't want to run in ambiguities). I believe the ambiguities are pretty rare. And people tend to indent multi-line scripts anyway, right? Do they? In the current include/config/*.h files, there is basically zero structuring of the environment as nobody has been using multi-line variables yet. Yes, there is indentation in the header files, but this is not visible at all in the environment variables. I don't understand this question here. I agree that we should be able to run the file through the preprocessor such that it can resolve such macro definitions. But this should be independent of the actual text format, or am I missing something? Yes we can, agreed. I was thinking you would not want the preprocessor since 'env export -t' doesn't understand it. Well, of course it deosn't, as it cannot invert the operation of the C preprocessor... But we can still use the prepro to create output that is digestable to env import -t, right? Well, I can't see how you avoid such ambiguities in your proposed format. You need a clear termination for the value of a variable. If it is spread across multiple lines, you have to find a way to mark continuation lines. The accepted standard way to do so is by using a backslash at the end of the line. It appears you want to use indentation instead - this prevents users from using a free text format, and quickly becomes messy. And it is incompatible to (current) U-Boot code. Indentation is pretty normal in code, so I don't feel embarrassed about asking for it. I think the primary problem with my feature is that it is different from 'env export -t', and thus potentially introduces another format. My argument against that interpretation is that I am in fact replacing a C header file definition with a text file, so perhaps I'm not really increasing the number of formats? Well, I'm afraid you have not yet formally defined the syntax of your format, so I may just misunderstand what you mean. Well yes I could adjust 'env export -t' to use the same format - is that a good idea, or not? I can see down-sides. We can of course convert existing files brought in by 'env import -t' (by making the import flexible) but I worry that there might be external tools that users have which expect the format to be a certain way. Are there any such tools? Anybodyu who is using such please speak up now and here! ;-) I agree creating a new format is not ideal - it's just that the existing C header format is so painful... Yes, I agree on that, and I'm more than willing to get rid of it. But it has to be something that is actually working, and that is easy to work with. --485b3970d160c06fb304e9d48797 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable div dir=3DltrHi Wolfgang,brbrOn Mon, Oct 28, 2013 at 3:16 PM, Wolfg= ang Denk lt;a href=3Dmailto:w...@denx.de;w...@denx.de/agt; wrote:brgt= ... Argh... can you please turn this off? 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 I have never understood the female capacity to avoid a direct answer to any question. -- Spock, This Side of Paradise, stardate 3417.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Illegal use of FP ops in clock_ti814x.c
Dear Måns Rullgård,
In message yw1xd2mp0yqu@unicorn.mansr.com you wrote:
Something like this should be equivalent. That said, it looks
suspiciously like it's meant to simply do a division and round up. If
that is the case, +225 should be +249. It probably makes no difference
for the values actually encountered.
Umm... this is the part which I do not understand.
The original code adds 90%; you add 90%, too. However, to round up,
one usually adds only 50% ?
diff --git a/arch/arm/cpu/armv7/am33xx/clock_ti814x.c
b/arch/arm/cpu/armv7/am33xx/clock_ti814x.c
index ef14f47..9b5a47b 100644
--- a/arch/arm/cpu/armv7/am33xx/clock_ti814x.c
+++ b/arch/arm/cpu/armv7/am33xx/clock_ti814x.c
@@ -211,11 +211,8 @@ static u32 pll_dco_freq_sel(u32 clkout_dco)
static u32 pll_sigma_delta_val(u32 clkout_dco)
{
u32 sig_val = 0;
- float frac_div;
- frac_div = (float) clkout_dco / 250;
- frac_div = frac_div + 0.90;
- sig_val = (int)frac_div;
+ sig_val = (clkout_dco + 225) / 250;
sig_val = sig_val 24;
Where are these 90% coming from? Are they in any way meaningful, or
even critical?
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
I still miss my ex-wife, but my aim is getting better.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Illegal use of FP ops in clock_ti814x.c
Wolfgang Denk w...@denx.de writes:
Dear Måns Rullgård,
In message yw1xd2mp0yqu@unicorn.mansr.com you wrote:
Something like this should be equivalent. That said, it looks
suspiciously like it's meant to simply do a division and round up. If
that is the case, +225 should be +249. It probably makes no difference
for the values actually encountered.
Umm... this is the part which I do not understand.
The original code adds 90%; you add 90%, too. However, to round up,
one usually adds only 50% ?
Adding 50% would round to nearest. For integer division to round up,
you must add one less than the divisor.
diff --git a/arch/arm/cpu/armv7/am33xx/clock_ti814x.c
b/arch/arm/cpu/armv7/am33xx/clock_ti814x.c
index ef14f47..9b5a47b 100644
--- a/arch/arm/cpu/armv7/am33xx/clock_ti814x.c
+++ b/arch/arm/cpu/armv7/am33xx/clock_ti814x.c
@@ -211,11 +211,8 @@ static u32 pll_dco_freq_sel(u32 clkout_dco)
static u32 pll_sigma_delta_val(u32 clkout_dco)
{
u32 sig_val = 0;
- float frac_div;
- frac_div = (float) clkout_dco / 250;
- frac_div = frac_div + 0.90;
- sig_val = (int)frac_div;
+ sig_val = (clkout_dco + 225) / 250;
sig_val = sig_val 24;
Where are these 90% coming from? Are they in any way meaningful, or
even critical?
My guess is that it was someone's approximation of 249 / 250. I don't
know the hardware, so it's conceivable that it really should be this
way, although it seems unlikely.
--
Måns Rullgård
m...@mansr.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ARM: mxs: Enable DCDC converter for battery boot
Hi Marek, On Mon, Oct 28, 2013 at 9:29 AM, Marek Vasut ma...@denx.de wrote: In case the board detected sufficient voltage for battery boot, make sure the DCDC converter is ON and the board is not running only from linregs, otherwise an instability will be observed. Signed-off-by: Marek Vasut ma...@denx.de Cc: Stefano Babic sba...@denx.de Cc: Fabio Estevam fabio.este...@freescale.com --- arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c index 8ea45be..d25019a 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c @@ -654,6 +654,8 @@ static void mxs_batt_boot(void) clrsetbits_le32(power_regs-hw_power_5vctrl, POWER_5VCTRL_CHARGE_4P2_ILIMIT_MASK, 0x8 POWER_5VCTRL_CHARGE_4P2_ILIMIT_OFFSET); + + mxs_power_enable_4p2(); Shouldn't this be conditional? #if defined CONFIG_MXS_ENABLE_4P2 mxs_power_enable_4p2(); #endif Then the boards that need this power supply enable CONFIG_MXS_ENABLE_4P2 in its config file. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/esdhc: Map register for eSDHC host controller 3.0
eSDHC host controller has new register to support SD Spec 3.0.
And the according host controller version was Freescale eSDHC
Version 3.0. Add some new register and it simple description.
Signed-off-by: Haijun Zhang haijun.zh...@freescale.com
---
drivers/mmc/fsl_esdhc.c | 62 +
1 file changed, 37 insertions(+), 25 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 589288b..f3d4b90 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -40,31 +40,43 @@
DECLARE_GLOBAL_DATA_PTR;
struct fsl_esdhc {
- uintdsaddr;
- uintblkattr;
- uintcmdarg;
- uintxfertyp;
- uintcmdrsp0;
- uintcmdrsp1;
- uintcmdrsp2;
- uintcmdrsp3;
- uintdatport;
- uintprsstat;
- uintproctl;
- uintsysctl;
- uintirqstat;
- uintirqstaten;
- uintirqsigen;
- uintautoc12err;
- uinthostcapblt;
- uintwml;
- uintmixctrl;
- charreserved1[4];
- uintfevt;
- charreserved2[168];
- uinthostver;
- charreserved3[780];
- uintscr;
+ uintdsaddr; /* SDMA system address register */
+ uintblkattr;/* Block attributes register */
+ uintcmdarg; /* Command argument register */
+ uintxfertyp;/* Transfer type register */
+ uintcmdrsp0;/* Command response 0 register */
+ uintcmdrsp1;/* Command response 1 register */
+ uintcmdrsp2;/* Command response 2 register */
+ uintcmdrsp3;/* Command response 3 register */
+ uintdatport;/* Buffer data port register */
+ uintprsstat;/* Present state register */
+ uintproctl; /* Protocol control register */
+ uintsysctl; /* System Control Register */
+ uintirqstat;/* Interrupt status register */
+ uintirqstaten; /* Interrupt status enable register */
+ uintirqsigen; /* Interrupt signal enable register */
+ uintautoc12err; /* Auto CMD error status register */
+ uinthostcapblt; /* Host controller capabilities register */
+ uintwml;/* Watermark level register */
+ uintmixctrl;/* For USDHC */
+ charreserved1[4]; /* reserved */
+ uintfevt; /* Force event register */
+ uintadmaes; /* ADMA error status register */
+ uintadsaddr;/* ADMA system address register */
+ charreserved2[160]; /* reserved */
+ uinthostver;/* Host controller version register */
+ charreserved3[4]; /* reserved */
+ uintdmaerraddr; /* DMA error address register */
+ charreserved4[4]; /* reserved */
+ uintdmaerrattr; /* DMA error attribute register */
+ charreserved5[4]; /* reserved */
+ uinthostcapblt2;/* Host controller capabilities register 2 */
+ charreserved6[8]; /* reserved */
+ uinttcr;/* Tuning control register */
+ charreserved7[28]; /* reserved */
+ uintsddirctl; /* SD direction control register */
+ charreserved8[712]; /* reserved */
+ uintscr;/* eSDHC control register */
};
/* Return the XFERTYP flags for a given command and data packet */
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/esdhc: Map register for eSDHC host controller 3.0
eSDHC host controller has new register to support SD Spec 3.0.
And the according host controller version was Freescale eSDHC
Version 3.0. Add some new register and it simple description.
Signed-off-by: Haijun Zhang haijun.zh...@freescale.com
---
drivers/mmc/fsl_esdhc.c | 62 +
1 file changed, 37 insertions(+), 25 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 589288b..f3d4b90 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -40,31 +40,43 @@
DECLARE_GLOBAL_DATA_PTR;
struct fsl_esdhc {
- uintdsaddr;
- uintblkattr;
- uintcmdarg;
- uintxfertyp;
- uintcmdrsp0;
- uintcmdrsp1;
- uintcmdrsp2;
- uintcmdrsp3;
- uintdatport;
- uintprsstat;
- uintproctl;
- uintsysctl;
- uintirqstat;
- uintirqstaten;
- uintirqsigen;
- uintautoc12err;
- uinthostcapblt;
- uintwml;
- uintmixctrl;
- charreserved1[4];
- uintfevt;
- charreserved2[168];
- uinthostver;
- charreserved3[780];
- uintscr;
+ uintdsaddr; /* SDMA system address register */
+ uintblkattr;/* Block attributes register */
+ uintcmdarg; /* Command argument register */
+ uintxfertyp;/* Transfer type register */
+ uintcmdrsp0;/* Command response 0 register */
+ uintcmdrsp1;/* Command response 1 register */
+ uintcmdrsp2;/* Command response 2 register */
+ uintcmdrsp3;/* Command response 3 register */
+ uintdatport;/* Buffer data port register */
+ uintprsstat;/* Present state register */
+ uintproctl; /* Protocol control register */
+ uintsysctl; /* System Control Register */
+ uintirqstat;/* Interrupt status register */
+ uintirqstaten; /* Interrupt status enable register */
+ uintirqsigen; /* Interrupt signal enable register */
+ uintautoc12err; /* Auto CMD error status register */
+ uinthostcapblt; /* Host controller capabilities register */
+ uintwml;/* Watermark level register */
+ uintmixctrl;/* For USDHC */
+ charreserved1[4]; /* reserved */
+ uintfevt; /* Force event register */
+ uintadmaes; /* ADMA error status register */
+ uintadsaddr;/* ADMA system address register */
+ charreserved2[160]; /* reserved */
+ uinthostver;/* Host controller version register */
+ charreserved3[4]; /* reserved */
+ uintdmaerraddr; /* DMA error address register */
+ charreserved4[4]; /* reserved */
+ uintdmaerrattr; /* DMA error attribute register */
+ charreserved5[4]; /* reserved */
+ uinthostcapblt2;/* Host controller capabilities register 2 */
+ charreserved6[8]; /* reserved */
+ uinttcr;/* Tuning control register */
+ charreserved7[28]; /* reserved */
+ uintsddirctl; /* SD direction control register */
+ charreserved8[712]; /* reserved */
+ uintscr;/* eSDHC control register */
};
/* Return the XFERTYP flags for a given command and data packet */
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] i2c: sh_i2c: Update to new CONFIG_SYS_I2C framework
This updates to new I2C framwwork on sh_i2c.
And this also updates boards(kzm9g and ecovec) that using sh_i2c.
Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
Signed-off-by: Nobuhiro Iwamatsu iwama...@nigauri.org
---
v2:
Squash with patch for kzm9g and ecovec.
Remove i2c_init() from kzm9g.c and ecovec.c.
README| 18 +++
board/kmc/kzm9g/kzm9g.c | 1 -
board/renesas/ecovec/ecovec.c | 3 +-
drivers/i2c/Makefile | 2 +-
drivers/i2c/sh_i2c.c | 294 +++---
include/configs/ecovec.h | 15 +--
include/configs/kzm9g.h | 31 ++---
7 files changed, 174 insertions(+), 190 deletions(-)
diff --git a/README b/README
index f0eedbb..d7be66a 100644
--- a/README
+++ b/README
@@ -2028,6 +2028,24 @@ CBFS (Coreboot Filesystem) support
- CONFIG_SYS_RCAR_I2C3_SPEED for for the speed channel 3
- CONFIF_SYS_RCAR_I2C_NUM_CONTROLLERS for number of i2c buses
+ - drivers/i2c/sh_i2c.c:
+ - activate this driver with CONFIG_SYS_I2C_SH
+ - This driver adds from 2 to 5 i2c buses
+
+ - CONFIG_SYS_I2C_SH_BASE0 for setting the register channel 0
+ - CONFIG_SYS_I2C_SH_SPEED0 for for the speed channel 0
+ - CONFIG_SYS_I2C_SH_BASE1 for setting the register channel 1
+ - CONFIG_SYS_I2C_SH_SPEED1 for for the speed channel 1
+ - CONFIG_SYS_I2C_SH_BASE2 for setting the register channel 2
+ - CONFIG_SYS_I2C_SH_SPEED2 for for the speed channel 2
+ - CONFIG_SYS_I2C_SH_BASE3 for setting the register channel 3
+ - CONFIG_SYS_I2C_SH_SPEED3 for for the speed channel 3
+ - CONFIG_SYS_I2C_SH_BASE4 for setting the register channel 4
+ - CONFIG_SYS_I2C_SH_SPEED4 for for the speed channel 4
+ - CONFIG_SYS_I2C_SH_BASE5 for setting the register channel 5
+ - CONFIG_SYS_I2C_SH_SPEED5 for for the speed channel 5
+ - CONFIF_SYS_I2C_SH_NUM_CONTROLLERS for nummber of i2c buses
+
additional defines:
CONFIG_SYS_NUM_I2C_BUSES
diff --git a/board/kmc/kzm9g/kzm9g.c b/board/kmc/kzm9g/kzm9g.c
index b669ffe..ea36fa4 100644
--- a/board/kmc/kzm9g/kzm9g.c
+++ b/board/kmc/kzm9g/kzm9g.c
@@ -289,7 +289,6 @@ void adjust_core_voltage(void)
{
u8 data;
- i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
data = 0x35;
i2c_set_bus_num(0);
i2c_write(0x40, 3, 1, data, 1);
diff --git a/board/renesas/ecovec/ecovec.c b/board/renesas/ecovec/ecovec.c
index e2d365a..fb4acf3 100644
--- a/board/renesas/ecovec/ecovec.c
+++ b/board/renesas/ecovec/ecovec.c
@@ -57,8 +57,7 @@ int board_late_init(void)
outl(inl(MSTPCR2) ~0x1000, MSTPCR2);
- i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
- i2c_set_bus_num(CONFIG_SYS_I2C_MODULE); /* Use I2C 1 */
+ i2c_set_bus_num(1); /* Use I2C 1 */
/* Read MAC address */
i2c_read(0x50, 0x10, 0, mac, 6);
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 84a2754..ff52874 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -22,7 +22,6 @@ COBJS-$(CONFIG_PCA9564_I2C) += pca9564_i2c.o
COBJS-$(CONFIG_DRIVER_S3C24X0_I2C) += s3c24x0_i2c.o
COBJS-$(CONFIG_TSI108_I2C) += tsi108_i2c.o
COBJS-$(CONFIG_U8500_I2C) += u8500_i2c.o
-COBJS-$(CONFIG_SH_I2C) += sh_i2c.o
COBJS-$(CONFIG_SH_SH7734_I2C) += sh_sh7734_i2c.o
COBJS-$(CONFIG_SYS_I2C) += i2c_core.o
COBJS-$(CONFIG_SYS_I2C_FSL) += fsl_i2c.o
@@ -30,6 +29,7 @@ COBJS-$(CONFIG_SYS_I2C_FTI2C010) += fti2c010.o
COBJS-$(CONFIG_SYS_I2C_MXC) += mxc_i2c.o
COBJS-$(CONFIG_SYS_I2C_PPC4XX) += ppc4xx_i2c.o
COBJS-$(CONFIG_SYS_I2C_RCAR) += rcar_i2c.o
+COBJS-$(CONFIG_SYS_I2C_SH) += sh_i2c.o
COBJS-$(CONFIG_SYS_I2C_SOFT) += soft_i2c.o
COBJS-$(CONFIG_SYS_I2C_TEGRA) += tegra_i2c.o
COBJS-$(CONFIG_ZYNQ_I2C) += zynq_i2c.o
diff --git a/drivers/i2c/sh_i2c.c b/drivers/i2c/sh_i2c.c
index 808202c..cc19100 100644
--- a/drivers/i2c/sh_i2c.c
+++ b/drivers/i2c/sh_i2c.c
@@ -6,6 +6,7 @@
*/
#include common.h
+#include i2c.h
#include asm/io.h
DECLARE_GLOBAL_DATA_PTR;
@@ -22,8 +23,6 @@ struct sh_i2c {
};
#undef ureg
-static struct sh_i2c *base;
-
/* ICCR */
#define SH_I2C_ICCR_ICE(1 7)
#define SH_I2C_ICCR_RACK (1 6)
@@ -43,202 +42,165 @@ static struct sh_i2c *base;
#define SH_I2C_ICIC_ICCHB8 (1 6)
#endif
+static const struct sh_i2c *i2c_dev[CONFIG_SYS_I2C_SH_NUM_CONTROLLERS] = {
+ (struct sh_i2c *)CONFIG_SYS_I2C_SH_BASE0,
+#ifdef CONFIG_SYS_I2C_SH_BASE1
+ (struct sh_i2c *)CONFIG_SYS_I2C_SH_BASE1,
+#endif
+#ifdef CONFIG_SYS_I2C_SH_BASE2
+ (struct sh_i2c *)CONFIG_SYS_I2C_SH_BASE2,
+#endif
+#ifdef CONFIG_SYS_I2C_SH_BASE3
+ (struct sh_i2c *)CONFIG_SYS_I2C_SH_BASE3,
+#endif
+#ifdef CONFIG_SYS_I2C_SH_BASE4
+ (struct
Re: [U-Boot] [PATCH] arm: at91: support for the Calao USB-A9263 board (based on AT91SAM9263)
Hello Mateusz, Am 28.10.2013 22:30, schrieb Mateusz Kulikowski: Hi Bo Shen, Thanks for the check, please see below. On 28.10.2013 05:57, Bo Shen wrote: Hi Mateusz Kulikowski, Add Andreas in loop. On 10/28/2013 03:34, Mateusz Kulikowski wrote: (...) [...] +#define CONFIG_SYS_TEXT_BASE 0x23f0 This address should be considered as u-boot is top down map, so if your system only 64MiB, there is only 1MiB left. I don't understand something here: - this address is hardcoded in AT91bootstrap (as well as image size - 0x31000), Do you have the source code? - I can change it, but it will not boot on stock board - should we force people to recompile AT91bootstrap if they want to use new U-Boot? Not the preferred way ... or - Should I add low-level initialization to boot U-Boot from Dataflash without AT91bootstrap (this is a bit more work)? Thats the way I would prefer! We decided for the siemens at91 board ports I recently posted, see here: [U-Boot,v1,1/3] at91: add defines for reset type http://patchwork.ozlabs.org/patch/285365/ [U-Boot,v1,2/3] arm, at91: add Siemens board taurus (based on AT91SAM9G20) http://patchwork.ozlabs.org/patch/285366/ [U-Boot,v1,3/3] arm, at91: add siemens corvus board http://patchwork.ozlabs.org/patch/285367/ to start a try using spl instead of at91bootstrap. I hope to get this ASAP (serial output works :-) running and post a RFC patch. They boot from NAND but that should be no big problem to add dataflash support ... or - There is another way I'm not aware of (perhaps relocate U-Boot in RAM)? You need always some first stage bootloader, currently this is at91bootstrap, but we should integrate this into U-Boot SPL code ... U-Boot gets relocated in RAM, but that is later in the boot process... bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: at91: support for the Calao USB-A9263 board (based on AT91SAM9263)
Hi Mateusz Kulikowski, On 10/29/2013 05:30, Mateusz Kulikowski wrote: Hi Bo Shen, Thanks for the check, please see below. On 28.10.2013 05:57, Bo Shen wrote: Hi Mateusz Kulikowski, Add Andreas in loop. On 10/28/2013 03:34, Mateusz Kulikowski wrote: (...) +/* + * Disable pull-up on: + * RXDV (PC25) = PHY normal mode (not Test mode) + * ERX0 (PE25) = PHY ADDR0 + * ERX1 (PE26) = PHY ADDR1 = PHYADDR = 0x0 + * + * PHY has internal pull-down + */ +writel(1 25, pio-pioc.pudr); +writel((1 25) | (1 26), pio-pioe.pudr); Use GPIO API instead of hard code. Should I also update (in separate patch) at91sam9263ek board (code is the same there, bad side is - I don't have that board to test)? You can use GPIO API for USB-A9263 in this patch. And send another patch to fix at91sam9263ek board (I can help test the patch for at91sam9263ek board). + +#define CONFIG_SYS_TEXT_BASE 0x23f0 This address should be considered as u-boot is top down map, so if your system only 64MiB, there is only 1MiB left. I don't understand something here: - this address is hardcoded in AT91bootstrap (as well as image size - 0x31000), Yes, that's true. And this is a pain for us :( Here just a reminder for the text base. - I can change it, but it will not boot on stock board - should we force people to recompile AT91bootstrap if they want to use new U-Boot? (If you plan to modify the text base, you must ask for that.) For new version bootstrap, we have change this address to 0x21f0 for boards only have 64MiB SDRAM. or - Should I add low-level initialization to boot U-Boot from Dataflash without AT91bootstrap (this is a bit more work)? I am working for SPL for Atmel EK boards, now focus on sama5d3xek board. After finished, I will submit then patch and go on working for other board. or - There is another way I'm not aware of (perhaps relocate U-Boot in RAM)? Best Regards, Mateusz Kulikowski Best Regards, Bo Shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: at91: support for the Calao USB-A9263 board (based on AT91SAM9263)
Hello Bo, Am 29.10.2013 06:24, schrieb Bo Shen: Hi Mateusz Kulikowski, On 10/29/2013 05:30, Mateusz Kulikowski wrote: Hi Bo Shen, Thanks for the check, please see below. On 28.10.2013 05:57, Bo Shen wrote: Hi Mateusz Kulikowski, Add Andreas in loop. On 10/28/2013 03:34, Mateusz Kulikowski wrote: (...) [...] or - Should I add low-level initialization to boot U-Boot from Dataflash without AT91bootstrap (this is a bit more work)? I am working for SPL for Atmel EK boards, now focus on sama5d3xek board. After finished, I will submit then patch and go on working for other board. We just decided to go this way for the siemens boards too... (Just started, serial seems to work in spl code) bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
