Re: [U-Boot] [STATUS] v2011.06-rc1 released
Hello Albert ARIBAUD wrote: In message4dd760eb.2050...@elsoft.ch you wrote: please also apply the following patch and friends http://patchwork.ozlabs.org/patch/93595/ this will make VCMA9 board work with current U-Boot release. Applied to arm tree, will send a pull request later today. Could you please also apply the second half of this patch serie: - http://patchwork.ozlabs.org/patch/93598/ - http://patchwork.ozlabs.org/patch/93599/ - http://patchwork.ozlabs.org/patch/93601/ Thank you Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Help with exporting memory power management info in u-boot
Hi, Memory hardware today offers capabilities for managing power consumption, like multiple lower power statest. Few SoCs, like the TI Panda board, offers support for Partial Array Self Refresh (PASR), by which partial areas of memory could be turned off to save power. Further, few other SoCs have multiple memory controllers, like Samsung Exynos 4210, where each controller independently transitions memory under it into lower power states depending on certain criteria. Each of these capabilities are supported by the hardware at a particular granularity. For example, PASR could be supported at the level of a memory bank, i.e, a bank of memory that is free could be turned off, independent of the other banks. Inorder to exploit these features, the Linux VM subsystem needs to be modified to take into account the physical memory topology when managing memory. We proposed a generic memory regions infrastructure, that could be used to tag boundaries of memory blocks which belong to a specific memory power management domain and further enable exploitation of platform capabilities. The details of this framework can be found here: https://lkml.org/lkml/2011/5/27/177 Memory region is a layer of abstraction that would be created at boot time, with information from firmware regarding the granularity at which memory power can be managed on the platform. We would like to work towards having this information exported by u-boot. A sample interface we are looking at is a device tree node that would provide the number, size and starting address corresponding to the memory power domains on the underlying platform. In this regard, we want some help from the u-boot community on designing the interfaces. Further, we would like to collaborate with all the SoCs that have support for managing memory power on their boards, so we could design a generic interface that can be exploited by all. -- Regards, Ankita Garg (ank...@in.ibm.com) Linux Technology Center IBM India Systems Technology Labs, Bangalore, India ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/5] mpc5200: digsy_mtc: add support for graphic extension board
Add detection and initialisation for graphic extension board
and support splash screen when booting. Enable bmp command
in the board configuration and provide disp command to
be able to switch the display on/off.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
v2:
- get rid of exbo.h header and put the needed defines into the .c file
- use accessors when reading/writing gpio registers
- correct GPIO_EE_DO, GPIO_EE_CTS and GPIO_USB1_9 macros for
settings in 8-bit wkup gpio registers
board/digsy_mtc/Makefile|7 ++--
board/digsy_mtc/cmd_disp.c | 57 +
board/digsy_mtc/digsy_mtc.c | 66 +++
include/configs/digsy_mtc.h | 27 +
4 files changed, 154 insertions(+), 3 deletions(-)
create mode 100644 board/digsy_mtc/cmd_disp.c
diff --git a/board/digsy_mtc/Makefile b/board/digsy_mtc/Makefile
index a40076c..19f5b3a 100644
--- a/board/digsy_mtc/Makefile
+++ b/board/digsy_mtc/Makefile
@@ -7,10 +7,11 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).o
-COBJS := $(BOARD).o cmd_mtc.o
+COBJS-y:= $(BOARD).o cmd_mtc.o
+COBJS-$(CONFIG_VIDEO) += cmd_disp.o
-SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
-OBJS := $(addprefix $(obj),$(COBJS))
+SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS-y))
SOBJS := $(addprefix $(obj),$(SOBJS))
$(LIB):$(obj).depend $(OBJS)
diff --git a/board/digsy_mtc/cmd_disp.c b/board/digsy_mtc/cmd_disp.c
new file mode 100644
index 000..d5f5efb
--- /dev/null
+++ b/board/digsy_mtc/cmd_disp.c
@@ -0,0 +1,57 @@
+/*
+ * (C) Copyright 2011 DENX Software Engineering,
+ * Anatolij Gustschin ag...@denx.de
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include command.h
+#include mpc5xxx.h
+#include asm/io.h
+
+#define GPIO_USB1_00x0001
+
+static int cmd_disp(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ struct mpc5xxx_gpio *gpio = (struct mpc5xxx_gpio *)MPC5XXX_GPIO;
+
+ if (argc 2) {
+ printf(%s\n,
+ in_be32(gpio-simple_dvo) GPIO_USB1_0 ? on : off);
+ return 0;
+ }
+
+ if (!strncmp(argv[1], on, 2)) {
+ setbits_be32(gpio-simple_dvo, GPIO_USB1_0);
+ } else if (!strncmp(argv[1], off, 3)) {
+ clrbits_be32(gpio-simple_dvo, GPIO_USB1_0);
+ } else {
+ cmd_usage(cmdtp);
+ return 1;
+ }
+ return 0;
+}
+
+U_BOOT_CMD(disp, 2, 1, cmd_disp,
+ disp [on/off] - switch display on/off,
+ \n- print display on/off status\n
+ on\n- turn on\n
+ off\n- turn off\n
+);
diff --git a/board/digsy_mtc/digsy_mtc.c b/board/digsy_mtc/digsy_mtc.c
index 588face..784ba2a 100644
--- a/board/digsy_mtc/digsy_mtc.c
+++ b/board/digsy_mtc/digsy_mtc.c
@@ -48,6 +48,7 @@
#endif
#include libfdt.h
#include fdt_support.h
+#include i2c.h
DECLARE_GLOBAL_DATA_PTR;
@@ -207,6 +208,69 @@ int checkboard(void)
return 0;
}
+#if defined(CONFIG_VIDEO)
+
+#define GPIO_USB1_00x0001 /* Power-On pin */
+#define GPIO_USB1_90x08/* PX_~EN pin */
+
+#define GPIO_EE_DO 0x10/* PSC6_0 (DO) pin */
+#define GPIO_EE_CTS0x20/* PSC6_1 (CTS) pin */
+#define GPIO_EE_DI 0x1000 /* PSC6_2 (DI) pin */
+#define GPIO_EE_CLK0x2000 /* PSC6_3 (CLK) pin */
+
+#define GPT_GPIO_ON0x0034 /* GPT as simple GPIO, high */
+
+/* ExBo I2C Addresses */
+#define EXBO_EE_I2C_ADDRESS0x56
+
+static void exbo_hw_init(void)
+{
+ struct mpc5xxx_gpt *gpt = (struct mpc5xxx_gpt *)MPC5XXX_GPT;
+ struct mpc5xxx_gpio *gpio = (struct mpc5xxx_gpio *)MPC5XXX_GPIO;
+ struct mpc5xxx_wu_gpio *wu_gpio =
+ (struct mpc5xxx_wu_gpio *)MPC5XXX_WU_GPIO;
+ unsigned char val;
+
+ /* 1st, check if extension board is present */
+ if (i2c_read(EXBO_EE_I2C_ADDRESS, 0, 1, val, 1))
+ return;
+
+ /* configure IrDA pins (PSC6 port) as gpios */
+ gpio-port_config =
[U-Boot] [PATCH v2 5/5] mpc5200: digsy_mtc: add support for writing 'appreg' value
Up to now only reading 'appreg' value was implemented in the
digsyMTC special 'mtc appreg' command. Extend the command to
support writing appreg value, too.
Signed-off-by: Werner Pfister pfister_wer...@intercontrol.de
Signed-off-by: Anatolij Gustschin ag...@denx.de
Acked-by: Detlev Zundel d...@denx.de
---
v2:
- fix typo in error message
board/digsy_mtc/cmd_mtc.c | 46 +++-
1 files changed, 40 insertions(+), 6 deletions(-)
diff --git a/board/digsy_mtc/cmd_mtc.c b/board/digsy_mtc/cmd_mtc.c
index ba0c367..fffcee9 100644
--- a/board/digsy_mtc/cmd_mtc.c
+++ b/board/digsy_mtc/cmd_mtc.c
@@ -31,6 +31,8 @@
DECLARE_GLOBAL_DATA_PTR;
+static uchar user_out;
+
static const char *led_names[] = {
diag,
can1,
@@ -112,6 +114,8 @@ static int do_mtc_led(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
else
pcmd.cmd_val2 = 0;
+ pcmd.user_out = user_out;
+
mtc_calculate_checksum(pcmd);
err = msp430_xfer(pcmd, prx);
@@ -128,6 +132,7 @@ static int do_mtc_key(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
memset(prx, 0, sizeof(prx));
pcmd.cmd = CMD_GET_VIM;
+ pcmd.user_out = user_out;
mtc_calculate_checksum(pcmd);
err = msp430_xfer(pcmd, prx);
@@ -160,6 +165,7 @@ static int do_mtc_digout(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv
pcmd.cmd = CMD_GET_VIM;
pcmd.user_out = channel_mask;
+ user_out = channel_mask;
mtc_calculate_checksum(pcmd);
err = msp430_xfer(pcmd, prx);
@@ -187,6 +193,7 @@ static int do_mtc_digin(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[
memset(prx, 0, sizeof(prx));
pcmd.cmd = CMD_GET_VIM;
+ pcmd.user_out = user_out;
mtc_calculate_checksum(pcmd);
err = msp430_xfer(pcmd, prx);
@@ -205,6 +212,7 @@ static int do_mtc_appreg(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv
rx_msp_cmd prx;
int err;
char buf[5];
+ uchar appreg;
/* read appreg */
memset(pcmd, 0, sizeof(pcmd));
@@ -214,13 +222,34 @@ static int do_mtc_appreg(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv
pcmd.cmd_val0 = 5; /* max. Count */
pcmd.cmd_val1 = 5; /* max. Time */
pcmd.cmd_val2 = 0; /* =0 means read appreg */
+ pcmd.user_out = user_out;
mtc_calculate_checksum(pcmd);
err = msp430_xfer(pcmd, prx);
+ /* on success decide between read or write */
if (!err) {
- sprintf(buf, %d, prx.ack2);
- setenv(appreg, buf);
+ if (argc == 2) {
+ appreg = simple_strtol(argv[1], NULL, 10);
+ if (appreg == 0) {
+ printf(mtc appreg: invalid parameter -
+ must be between 1 and 255\n);
+ return -1;
+ }
+ memset(pcmd, 0, sizeof(pcmd));
+ pcmd.cmd = CMD_WD_PARA;
+ pcmd.cmd_val0 = prx.ack3; /* max. Count */
+ pcmd.cmd_val1 = prx.ack0; /* max. Time */
+ pcmd.cmd_val2 = appreg; /* !=0 means write appreg */
+ pcmd.user_out = user_out;
+ memset(prx, 0, sizeof(prx));
+
+ mtc_calculate_checksum(pcmd);
+ err = msp430_xfer(pcmd, prx);
+ } else {
+ sprintf(buf, %d, prx.ack2);
+ setenv(appreg, buf);
+ }
}
return err;
@@ -236,6 +265,7 @@ static int do_mtc_version(cmd_tbl_t *cmdtp, int flag, int
argc, char * const arg
memset(prx, 0, sizeof(prx));
pcmd.cmd = CMD_FW_VERSION;
+ pcmd.user_out = user_out;
mtc_calculate_checksum(pcmd);
err = msp430_xfer(pcmd, prx);
@@ -259,6 +289,7 @@ static int do_mtc_state(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[
pcmd.cmd = CMD_WD_WDSTATE;
pcmd.cmd_val2 = 1;
+ pcmd.user_out = user_out;
mtc_calculate_checksum(pcmd);
err = msp430_xfer(pcmd, prx);
@@ -288,8 +319,10 @@ cmd_tbl_t cmd_mtc_sub[] = {
returns state of user key, ),
U_BOOT_CMD_MKENT(version, 0, 1, do_mtc_version,
returns firmware version of supervisor uC, ),
- U_BOOT_CMD_MKENT(appreg, 0, 1, do_mtc_appreg,
- reads appreg value and stores in environment variable 'appreg', ),
+ U_BOOT_CMD_MKENT(appreg, 1, 1, do_mtc_appreg,
+ reads or writes appreg value and stores in environment
+ variable 'appreg',
+ [value] - value (1 - 255) to write to appreg),
U_BOOT_CMD_MKENT(digin, 1, 1, do_mtc_digin,
returns state of digital input,
channel_num - get state of digital input (1 or 2)\n),
@@ -342,8 +375,9 @@
Re: [U-Boot] [PATCH 2/5] pci: option for configurable delay between pci reset and pci bus scan
Hi Anatolij, Hi Detlev, On Fri, 27 May 2011 17:26:24 +0200 Detlev Zundel d...@denx.de wrote: ... PCI cards might need some time after reset to respond. On some boards (mpc5200 or mpc8260 based) the PCI bus reset is deasserted at pci_board_init() time, so we can not use available pcidelay option for waiting before pci bus scan here. Add an option to delay bus scan by setting pci_scan_delay environment variable. Hm, I'm not sure I understand the situation, so please correct me. We have a pcidelay variable, which is used to wait before pci_board_init() (I'm not counting the semantically different usage in the esd boards). This does not fit your need, so you define pci_scan_delay which is used _after_ pci_init_board(), correct? yes, this is correct. If this is correct, then why don't you keep your new delay also in the pci_init() function so that the delays are easily visible on code inspection? But wait, if this is only needed for this very board, then why don't we put the delay into digsys pci_init_board? Actually I think this is the best way, as on this board we always need the delay as PCI is not hotplug. The reason for not keeping new delay in pci_init() is: pci_init_board() starts scanning the bus (calls pci_hose_scan()), so when pci_init_board() returns, it is too late, the scanning is already completed. digsy's pci_init_board() just calls pci_mpc5xxx_init(), when the latter returns, the scanning is completed, too. PCI reset is de-asserted in pci_mpc5xxx_init(), so I thought about putting the delay there, but similar situation is also on mpc8260 based boards, pci_mpc8250_init() de-asserts PCI reset and waits on some boards (on MPC8266ADS 1 sec). So the problem is not only digsy specific. The needed time after reset before config cycles could be up to 1 sec, depending on the card. The pci spec 2.2 allows this. Ah, thanks for shedding some light on this. Now I see how you arrived at the solution you propose. I think that it would be good to run arch specific pci init not from the pci_board_init(), but from pci_init(). Then we can add delay code in the board specific way. This would reduce the code duplication, too. Currently we have the same pci_init_board() for many 5200 boards, except for mvbc_p and mvsmr boards. Yes, I have also noticed the massive code duplicatin here. But as I obviously didn't even understand the problem I didn't ponder changing it ;) Apart from that, having two variables pcidelay and pci_scan_delay we would need good documentation to explain their usage - the names do not help (me) much ;) Sure. If there is an agreement to solve the problem as proposed in the patch, I'll add the documentation in the next patch version. Maybe someone have a better idea, lets wait a bit for other comments. Actually I don't like the name of the variable, it is somehow misleading. Any better name? Sorry, no idea. If we are stuck stuck with pcidelay (which I think we are), then it is hard to come up with a differentiating name. So good documentation will have to make up for the lack of good names ;) Cheers Detlev -- Old mathematicians never die; they just lose some of their functions. -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Is there a working 2011 version of u-boot on i.MX31?
Hello Stefano, As Fabio already reported, last release is working on mx31pdk. Yes, I thought so. Thanks to all for the fast response. This is ruled by CONFIG_BOARD_EARLY_INIT_F, that is set for the board you mention and for qong, too. This is a second MX.31 board where I am sure that the last u-boot release is running. Sure, I defined CONFIG_BOARD_EARLY_INIT_F. 1) relocation is done at the end of 'board_init_f' 2) all early init functions are called at the very start of 'board_init_f' 3) these init functions are stored in an array of function pointers 'init_sequence', which is initialized data and which is not initialized yet. 4) the C-code in general is linked using -pie, but the compiler flag -PIE (or -PIC) is missing, so code is not really position independent. It is linked for the RAM addresses (0x87f0), but relocation is not yet done. It seems a problem related to your toolchain. Which gcc compiler are you using ? This can explain what you are reporting. I suspected my toolchain already, so I tested 2 different versions: 1) arm_v6_vfp_le-gcc -v: Using built-in specs. Target: armv6fl-montavista-linux-gnueabi Configured with: ../configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=armv6fl-montavista-linux-gnueabi --prefix=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le --exec-prefix=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le --bindir=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/bin --sbindir=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/sbin --sysconfdir=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/etc --datadir=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/share --includedir=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/include --libdir=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/lib --libexecdir=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/libexec --localstatedir=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/var --sharedstatedir=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/share --mandir=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/man --infodir=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/info --build=i686-pc-linux-gnu --program-transform-name=s,^,arm_v6_vfp_le-, --enable-cross --enable-poison-system-directories --with-sysroot=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/target --with-build-sysroot=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/target --with-build-time-tools=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/bin --enable-shared --enable-languages=c,c++ --enable-__cxa_atexit --enable-c99 --enable-long-long --enable-threads=posix --with-gxx-include-dir=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/lib/gcc/armv6fl-montavista-linux-gnueabi/4.2.0/../../../../target/usr/include/c++/4.2.0 --disable-libmudflap --disable-libssp --disable-libgomp --with-gnu-as --with-gnu-ld --enable-symvers=gnu --enable-checking=release --with-numa-policy=yes --disable-multilib --enable-clocale=gnu --with-cpu=arm1136jf-s --with-interwork --with-arch=armv6j --with-tune=arm1136jf-s --with-fpu=vfp --with-float=softfp --libexecdir=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/lib --with-bugurl=http://www.mvista.com/support --with-versuffix='MontaVista 4.2.0-16.0.46.custom 2009-03-17' Thread model: posix gcc version 4.2.0 (MontaVista 4.2.0-16.0.46.custom 2009-03-17) 2) arm-angstrom-linux-gnueabi-gcc -v Using built-in specs. Target: arm-angstrom-linux-gnueabi Configured with: /home/HALE/vogc/openembedded/tmp/work/i686-armv6-sdk-angstrom-linux-gnueabi/gcc-cross-sdk-4.3.3-r20.3/gcc-4.3.3/configure --build=i686-linux --host=i686-linux --target=arm-angstrom-linux-gnueabi --prefix=/usr/local/angstrom/arm --exec_prefix=/usr/local/angstrom/arm --bindir=/usr/local/angstrom/arm/bin --sbindir=/usr/local/angstrom/arm/bin --libexecdir=/usr/local/angstrom/arm/libexec --datadir=/usr/local/angstrom/arm/share --sysconfdir=/usr/local/angstrom/arm/etc --sharedstatedir=/usr/local/angstrom/arm/share/com --localstatedir=/usr/local/angstrom/arm/var --libdir=/usr/local/angstrom/arm/lib --includedir=/usr/local/angstrom/arm/include --oldincludedir=/usr/local/angstrom/arm/include --infodir=/usr/local/angstrom/arm/share/info --mandir=/usr/local/angstrom/arm/share/man --with-gnu-ld --enable-shared --enable-languages=c,c++,objc,fortran --enable-threads=posix --disable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=arm-angstrom-linux-gnueabi- --enable-target-optspace --enable-cheaders=c_std --enable-libssp --disable-bootstrap --disable-libgomp --disable-libmudflap --with-sysroot=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi --with-build-time-tools=/home/HALE/vogc/openembedded/tmp/sysroots/i686-linux/usr/armv6/arm-angstrom-linux-gnueabi/bin --with-build-sysroot=/home/HALE/vogc/openembedded/tmp/sysroots/armv6-angstrom-linux-gnueabi --disable-libunwind-exceptions --disable-libssp --disable-libgomp --disable-libmudflap
[U-Boot] at91sam9260ek and mmc
Hello,
I'm trying to get u-boot 2010.12 working on at91sam9260ek devkit with
mmc support. I have read several discussions here and followed the
steps described in README.atmel-mci. (my config and board file are
below...)
There are two issues I'm facing.
The first one: When I enable mmc support, the dataflash stops to work.
According to info from boot process, dataflash is detected correctly,
but no data can be read (environment) or written.
RAM Configuration:
Bank #0: 2000 64 MiB
NAND: 256 MiB
DataFlash:AT45DB642
Nb pages: 8192
Page Size: 1056
Size= 8650752 bytes
Logical address: 0xD000
Area 0: D000 to D00041FF (RO) Bootstrap
Area 1: D0004200 to D00083FF Environment
Area 2: D0008400 to D0041FFF (RO) U-Boot
Area 3: D0042000 to D0251FFF Kernel
Area 4: D0252000 to D083 FS
MMC: mci: 0
*** Warning - bad CRC, using default environment
The second one: fatls command causes u-boot to freeze with following message
U-Boot mmc list
mci: 0
U-Boot mmc rescan 0
mci: setting clock 194000 Hz, block size 512
mci: setting clock 24832000 Hz, block size 512
mci: setting clock 194000 Hz, block size 512
mci: setting clock 194000 Hz, block size 512
mci: setting clock 24832000 Hz, block size 512
U-Boot mmc part 0
mci: setting clock 194000 Hz, block size 512
mci: setting clock 24832000 Hz, block size 512
mci: setting clock 194000 Hz, block size 512
mci: setting clock 194000 Hz, block size 512
mci: setting clock 24832000 Hz, block size 512
Partition Map for MMC device 0 -- Partition Type: DOS
Partition Start Sector Num Sectors Type
11 583679 e
U-Boot fatinfo mmc 0:1
Interface: MMC
Device 0: Vendor: Man 035344 Snr 413f90a9 Rev: 8.0 Prod: SU02G
Type: Removable Hard Disk
Capacity: 1886.0 MB = 1.8 GB (3862528 x 512)
Partition 1: Filesystem: FAT16
U-Boot fatls mmc 0:1
gen_atmel_mci: CMDR 000d1052 (18) ARGR 00026200 (SR: c0d7) XFER
DTIP never unset, ignoring
I'm a newbie with u-boot, could please someone give me any hints where
to start to make this working?
best regards
Jan
/*
* (C) Copyright 2007-2008
* Stelian Pop stelian@leadtechdesign.com
* Lead Tech Design www.leadtechdesign.com
*
* Configuation settings for the AT91SAM9260EK AT91SAM9G20EK boards.
*
* 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
*/
#ifndef __CONFIG_H
#define __CONFIG_H
#define CONFIG_AT91_LEGACY
/*
* WARNING:
* The initial boot program needs to be adapted such that it loads U-boot
* at the provided TEXT_BASE below. Note that the Atmel AT91-bootstrap loader
* might be configured such that it loads U-boot at 0x23f0. But since
* U-boot is now being relocated to the end of RAM, this will result in a
* lockup during boot due to an overlap in the BSS segment. So, we choose a
* safe load adress to begin with, namely 0x20a0
*/
#define CONFIG_SYS_TEXT_BASE0x20a0
/* ARM asynchronous clock */
#define CONFIG_SYS_AT91_SLOW_CLOCK 32768/* slow clock xtal */
#define CONFIG_SYS_AT91_MAIN_CLOCK 18432000 /* main clock xtal */
#define CONFIG_SYS_HZ 1000
#define CONFIG_ARM926EJS 1 /* This is an ARM926EJS Core */
#ifdef CONFIG_AT91SAM9G20EK
#define CONFIG_AT91SAM9G20 1 /* It's an Atmel AT91SAM9G20 SoC*/
#else
#define CONFIG_AT91SAM9260 1 /* It's an Atmel AT91SAM9260 SoC*/
#endif
#define CONFIG_AT91FAMILY
#define CONFIG_ARCH_CPU_INIT
#undef CONFIG_USE_IRQ /* we don't need IRQ/FIQ stuff */
#define CONFIG_CMDLINE_TAG/* enable passing of ATAGs */
#define CONFIG_SETUP_MEMORY_TAGS
#define CONFIG_INITRD_TAG
#define CONFIG_SKIP_LOWLEVEL_INIT
/* general purpose I/O */
#define CONFIG_AT91_GPIO
/* serial console */
#define CONFIG_ATMEL_USART
#undef CONFIG_USART0
#undef CONFIG_USART1
#undef CONFIG_USART2
#define CONFIG_USART31 /* USART 3 is DBGU */
#define CONFIG_BAUDRATE 115200
#define CONFIG_SYS_BAUDRATE_TABLE {115200 , 19200, 38400, 57600, 9600 }
/* SD/MMC card */
#define CONFIG_MMC 1
#define CONFIG_GENERIC_MMC 1
#define CONFIG_GENERIC_ATMEL_MCI1
#define CONFIG_ATMEL_MCI_PORTB 1
/*#define CONFIG_SYS_MMC_CD_PIN AT91_PIN_PC9*/
#define CONFIG_CMD_MMC 1
/* LED */
#define CONFIG_AT91_LED
[U-Boot] Full amount of sdram
Hi I'm trying to get the full size of the sdram, not the available size as in gd-ram_size. We use a P2020 so I'm looking in the fsl_ code. I tried it with fsl_ddr_sdram_size() which from the comment should just return the size and don't do anything else. However this is already called in the u-boot code while setting up the correct parameters. Calling it a second time results in a crash in populate_memctl_options. - Should this work or do I need to skip these steps and call fsl_ddr_compute(info, STEP_COMPUTE_REGS, 1); myself? Can I include these function? - Is there another (vendor independent) way to get the full sdram size? Thanks bye Fabi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Help with exporting memory power management info in u-boot
Dear Ankita Garg, In message 20110530063940.gb16...@in.ibm.com you wrote: In this regard, we want some help from the u-boot community on designing the interfaces. Further, we would like to collaborate with all the SoCs that have support for managing memory power on their boards, so we could design a generic interface that can be exploited by all. Could you please be so kind and explain which of such functionality you envision to see in ore expect from U-Boot? I understand why all thisi s a very important topic for an operating system like Linux. But U-Boot is a boot loader. It is being used mainly in two different environments or usage modes: 1) First, U-Boot is a powerful tool for board bringup and for software development purposes. In this environment, power consumption is usually the least of your concerns. Instead, we focus on simplicity and robustness. 2) Second, U-Boot is (sometimes) an inevitable intermediate step when booting an operating system. In this mode, whole purpose of U-Boot is to get it's job done and then get out of the way as quickly as possible. So in real-world applications we may see a few ten, or maybe in worst case up to a few hundred milliseconds of U-Boot runtime compared to hours, days and often weeks and months of run time of the respective operating system. Keeping this in mind, which are the parts of memory power management that are important for the U-Boot context? Thanks. 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 It's not an optical illusion, it just looks like one. -- Phil White ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Help with exporting memory power management info in u-boot
Hi, On Mon, May 30, 2011 at 11:49:26AM +0200, Wolfgang Denk wrote: Dear Ankita Garg, In message 20110530063940.gb16...@in.ibm.com you wrote: In this regard, we want some help from the u-boot community on designing the interfaces. Further, we would like to collaborate with all the SoCs that have support for managing memory power on their boards, so we could design a generic interface that can be exploited by all. Could you please be so kind and explain which of such functionality you envision to see in ore expect from U-Boot? I understand why all thisi s a very important topic for an operating system like Linux. But U-Boot is a boot loader. It is being used mainly in two different environments or usage modes: 1) First, U-Boot is a powerful tool for board bringup and for software development purposes. In this environment, power consumption is usually the least of your concerns. Instead, we focus on simplicity and robustness. 2) Second, U-Boot is (sometimes) an inevitable intermediate step when booting an operating system. In this mode, whole purpose of U-Boot is to get it's job done and then get out of the way as quickly as possible. So in real-world applications we may see a few ten, or maybe in worst case up to a few hundred milliseconds of U-Boot runtime compared to hours, days and often weeks and months of run time of the respective operating system. Keeping this in mind, which are the parts of memory power management that are important for the U-Boot context? I agree with the above. Its not the power consumed by u-boot that is of concern. We want u-boot support in exporting additional information to the kernel, regarding the memory hardware characteristics specific to power management. For instance, if u-boot could inform the kernel about the boundaries at which PASR is supported on the underlying platform, that information could then be used by the kernel to exploit this feature. Like, this information would be encapsulated in a device-tree node maybe ? -- Regards, Ankita Garg (ank...@in.ibm.com) Linux Technology Center IBM India Systems Technology Labs, Bangalore, India ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Dear Simon Glass,
In message banlktim-jzymmzw_twhhhqqyovmk9mz...@mail.gmail.com you wrote:
Sure if you are tracking the timer, and wait for it to increment, and
then wait for it to increment a second time, you can be confident that
the time between the first and second increments is 10ms.
OK. Good.
But in general it is possible that your first read of the timer
happens at 9.999ms after the timer last incremented, just because you
are unlucky. Then perhaps two successive reads of the timer only 1us
apart will see a difference of 10ms in time.
Agreed.
I believe this resolution problem could/should be solved by a function
which returns a time not less than n ms in the future. It would work
by returning something like current_time_ms + (delay_ms +
resolution_ms * 2 - 1) / resolution_ms * resolution_ms, where
resolution_ms is 10 in this case. I think someone else mentioned that
too.
When the timer reaches that time then it is guaranteed that at least
delay_ms ms has passed, although it might be up to delay_ms + 10.
We (well, Detlev and me) discussed this. We think it is important to
realize (and to document) that the timing information provided by
get_timer() is inherently subject to the principles of interval
arithmetics with an implementation dependent interval width.
So far, most (all ?) of the code ignored this property, or silently
assumed that the interval width was equal to or better than 1 milli-
second which is the timing unit used by get_timer().
I think it is important to realize the (most important) use cases of
get_timer(): 1) [longish] timeouts and 2) other timing
computations. For completeness, I also include a third situation
here: 0) [short] timeouts:
0) [short] timeouts:
Short timeouts are obviously all timeouts that are shorter than one
millisecond - it is obvious that get_timer() cannot be used for
these, and instead we use udelay() based delay loops.
Note that this method also can be used for longer timeouts,
especially when we really have to wait for some event to happen,
i. e. when we cannot do something useful while waiting.
A typical implementation to wait for some event with a timeout of
5 seconds might look like this:
int loops = 10; /* timeout after 10 * 500 milliseconds */
while (test_for_event() == 0) {
if (--loops = 0)
handle_timeout();
udelay(50); /delay 500 millisecond */
}
Note that this implementation has the disadvantage that it may
introduce an unnecessary delay of up to 500 milliseconds if the
event happens quickly after the call to test_for_event(), so
typically it is more efficient to use a large number of short loops
intead - due to the loop overhead these are less accurate, but for
timeouts this usually does not matter, but at least they insert
less heavy delays. Example:
int loops = 5; /* timeout after 50,000 * 100 microseconds */
while (test_for_event() == 0) {
if (--loops = 0)
handle_timeout();
udelay(100);
}
Here we lose a maximim of 100 us in the delay call.
The inherent disadvantage of these delay based timeout loops is the
low accuracy - depending on the loop overhead (for example the time
spent in the test_for_event() call and on the size of the argument
to the udelay() call the total execution time of the loop is always
bigger than the assumed duration, especially for short delays.
Usually this is not a problem in such contexts; also it is possible
to trade accuracy for additional delays after the event happens -
see first code example above.
1) [longish] timeouts:
Timeouts in the order of several milliseconds or longer are
frequently implemented using get_timer(). Above 5 second timeout
could be implemented like this:
u32 start,now;
u32 timeout = 5 * CONFIG_SYS_HZ; /* timeout after 5 seconds */
start = get_timer(0);
while (test_for_event() == 0) {
now = get_timer(0);
if ((now - start) timeout)
handle_timeout();
udelay(100);
}
Here the loop overhead caused by short delay which may result in a
high number of calls to test_for_event() gets eliminated because
the time reference is independet of the delay.
2) Other timing computations:
These are usually used to measure the time needed to perform some
specific actions, for example like this:
u32 start, now;
start = get_timer(0);
do_something_complicated();
now = get_timer(0);
printf(execution time: %ld millisec\n, now - start);
Neither 1) nor 2) take into account that both start and now time
stamps depend on the resolution of the underlying, implementation
dependent timer. For large delays this is not critical, but for short
delays (few
Re: [U-Boot] Help with exporting memory power management info in u-boot
Dear Ankita Garg, In message 20110530102030.gd18...@in.ibm.com you wrote: I agree with the above. Its not the power consumed by u-boot that is of concern. We want u-boot support in exporting additional information to the kernel, regarding the memory hardware characteristics specific to power management. For instance, if u-boot could inform the kernel about the boundaries at which PASR is supported on the underlying platform, that information could then be used by the kernel to exploit this feature. Like, this information would be encapsulated in a device-tree node maybe ? I agree that is is a good idea to encode such information in the device tree. U-Boot can also help to update memory related notes in the device tree, for example by inserting their actual physical addresses and sizes. The rest, including information about memory power management properties of such nodes in the device tree, is of no concern to U-Boot and should just be passed on unchanged. In my opinion it is therefore the responsibility of the creator of the device tree to provide a proper description of the hardware, including the memory power management information. 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 Democracy is mob rule, but with income taxes. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Hi Wolfgang,
On 30/05/11 20:57, Wolfgang Denk wrote:
Dear Simon Glass,
In message banlktim-jzymmzw_twhhhqqyovmk9mz...@mail.gmail.com you wrote:
Sure if you are tracking the timer, and wait for it to increment, and
then wait for it to increment a second time, you can be confident that
the time between the first and second increments is 10ms.
OK. Good.
But in general it is possible that your first read of the timer
happens at 9.999ms after the timer last incremented, just because you
are unlucky. Then perhaps two successive reads of the timer only 1us
apart will see a difference of 10ms in time.
Agreed.
I believe this resolution problem could/should be solved by a function
which returns a time not less than n ms in the future. It would work
by returning something like current_time_ms + (delay_ms +
resolution_ms * 2 - 1) / resolution_ms * resolution_ms, where
resolution_ms is 10 in this case. I think someone else mentioned that
too.
When the timer reaches that time then it is guaranteed that at least
delay_ms ms has passed, although it might be up to delay_ms + 10.
We (well, Detlev and me) discussed this. We think it is important to
realize (and to document) that the timing information provided by
get_timer() is inherently subject to the principles of interval
arithmetics with an implementation dependent interval width.
Agree - I fully intend to collate all of this information into an API
document in the source tree
So far, most (all ?) of the code ignored this property, or silently
assumed that the interval width was equal to or better than 1 milli-
second which is the timing unit used by get_timer().
Well, we were until I tried to clean up CFI and found out about the Nios
limitation - Since then, I think we have all been acutely aware that it
was the 'elephant in the room'
I think it is important to realize the (most important) use cases of
get_timer(): 1) [longish] timeouts and 2) other timing
computations. For completeness, I also include a third situation
here: 0) [short] timeouts:
0) [short] timeouts:
Short timeouts are obviously all timeouts that are shorter than one
millisecond - it is obvious that get_timer() cannot be used for
these, and instead we use udelay() based delay loops.
Note that this method also can be used for longer timeouts,
especially when we really have to wait for some event to happen,
i. e. when we cannot do something useful while waiting.
A typical implementation to wait for some event with a timeout of
5 seconds might look like this:
int loops = 10; /* timeout after 10 * 500 milliseconds */
while (test_for_event() == 0) {
if (--loops = 0)
handle_timeout();
udelay(50); /delay 500 millisecond */
}
Note that this implementation has the disadvantage that it may
introduce an unnecessary delay of up to 500 milliseconds if the
event happens quickly after the call to test_for_event(), so
typically it is more efficient to use a large number of short loops
intead - due to the loop overhead these are less accurate, but for
timeouts this usually does not matter, but at least they insert
less heavy delays. Example:
int loops = 5; /* timeout after 50,000 * 100 microseconds */
while (test_for_event() == 0) {
if (--loops = 0)
handle_timeout();
udelay(100);
}
Here we lose a maximim of 100 us in the delay call.
The inherent disadvantage of these delay based timeout loops is the
low accuracy - depending on the loop overhead (for example the time
spent in the test_for_event() call and on the size of the argument
to the udelay() call the total execution time of the loop is always
bigger than the assumed duration, especially for short delays.
Usually this is not a problem in such contexts; also it is possible
to trade accuracy for additional delays after the event happens -
see first code example above.
Some platforms are _way_ worse than this - I am sure I have seen a udelay()
done with the millisecond time - So udelay(100) could be closer to
udelay(1000) - So your above 5 second delay could take as long as 50 seconds!!!
1) [longish] timeouts:
Timeouts in the order of several milliseconds or longer are
frequently implemented using get_timer(). Above 5 second timeout
could be implemented like this:
u32 start,now;
u32 timeout = 5 * CONFIG_SYS_HZ; /* timeout after 5 seconds */
start = get_timer(0);
while (test_for_event() == 0) {
now = get_timer(0);
if ((now - start) timeout)
handle_timeout();
udelay(100);
}
Here the loop overhead caused by short delay which may result in a
high number of calls to test_for_event() gets eliminated
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Dear Graeme Russ,
In message 4de383d3.7020...@gmail.com you wrote:
Some platforms are _way_ worse than this - I am sure I have seen a udelay()
done with the millisecond time - So udelay(100) could be closer to
udelay(1000) - So your above 5 second delay could take as long as 50
seconds!!!
That should show up quickly as soon as you run a sleep 5 command on
the console (which is implemented like that).
while (test_for_event() == 0) {
now = get_timer(0);
if ((now - start) timeout)
handle_timeout();
udelay(100);
}
Here the loop overhead caused by short delay which may result in a
high number of calls to test_for_event() gets eliminated because
the time reference is independet of the delay.
I personally think _any_ timeout greater than 1s (maybe even 500ms) should
be done this way
Agreed. As soon as the timeout is the interval size of the
underlying timer service this is the best we can do.
start = get_timer(0);
do_something_complicated();
now = get_timer(0);
printf(execution time: %ld millisec\n, now - start);
Currently fails spectacularly if do_something_complicated() involves a
delay loop which calls reset_timer()
Note that I (intentionally) always used argument 0 in the calls to
get_timer(). I think we really should get rid of this argument.
I think this may become more popular for performance tuning once the API
has been established. The desire for boot profiling was what initially made
me investigate the API given the current use of reset_timer() prohibits
profiling across a timeout loop.
Agreed.
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 find this a nice feature but it is not according to the documen-
tation. Or is it a BUG? Let's call it an accidental feature. :-)
- Larry Wall in 6...@jpl-devvax.jpl.nasa.gov
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Hi Wolfgang,
On 30/05/11 22:31, Wolfgang Denk wrote:
Dear Graeme Russ,
In message 4de383d3.7020...@gmail.com you wrote:
Some platforms are _way_ worse than this - I am sure I have seen a udelay()
done with the millisecond time - So udelay(100) could be closer to
udelay(1000) - So your above 5 second delay could take as long as 50
seconds!!!
That should show up quickly as soon as you run a sleep 5 command on
the console (which is implemented like that).
while (test_for_event() == 0) {
now = get_timer(0);
if ((now - start) timeout)
handle_timeout();
udelay(100);
}
Here the loop overhead caused by short delay which may result in a
high number of calls to test_for_event() gets eliminated because
the time reference is independet of the delay.
I personally think _any_ timeout greater than 1s (maybe even 500ms) should
be done this way
Agreed. As soon as the timeout is the interval size of the
underlying timer service this is the best we can do.
start = get_timer(0);
do_something_complicated();
now = get_timer(0);
printf(execution time: %ld millisec\n, now - start);
Currently fails spectacularly if do_something_complicated() involves a
delay loop which calls reset_timer()
Note that I (intentionally) always used argument 0 in the calls to
get_timer(). I think we really should get rid of this argument.
Agreed - I am more than willing to update all existing timer usages to a
completely new set of timer API functions. I think suffering the pain of
moving to a more well defined API would be better than trying to clunk
around the existing one.
I think we all fairly well agree on how U-Boot will maintain a millisecond
(and possibly microsecond) timer in a platform independent manner using a
platform defined tick counter. Defining a timer API around that is simply a
matter of taste - particularly when it comes to dealing with precision
issues. I think your delta function is a good start - However maybe
something more like ms_delta(u32 from, u32 to) would be a more appropriate
name as it clears the way for us_delta()
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] pci: option for configurable delay between pci reset and pci bus scan
Hi Anatolij and Detlev, On Monday 30 May 2011 09:45:08 Detlev Zundel wrote: Hm, I'm not sure I understand the situation, so please correct me. We have a pcidelay variable, which is used to wait before pci_board_init() (I'm not counting the semantically different usage in the esd boards). This does not fit your need, so you define pci_scan_delay which is used _after_ pci_init_board(), correct? yes, this is correct. If this is correct, then why don't you keep your new delay also in the pci_init() function so that the delays are easily visible on code inspection? But wait, if this is only needed for this very board, then why don't we put the delay into digsys pci_init_board? Actually I think this is the best way, as on this board we always need the delay as PCI is not hotplug. The reason for not keeping new delay in pci_init() is: pci_init_board() starts scanning the bus (calls pci_hose_scan()), so when pci_init_board() returns, it is too late, the scanning is already completed. Right. With this PCI reset design, the current pcidelay option won't work for these platforms. Too bad. But thinking more about it, couldn't your new code location supersede the old one before pci_init_board()? If this really is the case (we would need to check with users of this pcidelay env variable, Mattias?), then we could remove the old code in pci_init() and only use your new version. We would need to use the old env variable name pcidelay though, since there are boards in the field already using this version. Anatolij, what do you think? Matthias, could you do some tests on some esd boards with the new version when available, to make sure that we don't break backwards compatibility? Best regards, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/8] keymile arm boards update, part 2
Hi Wolfgang, On 05/26/2011 03:36 PM, Valentin Longchamp wrote: Hello everybody, Prafulla Wadaskar wrote: -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Friday, May 20, 2011 6:36 PM To: Valentin Longchamp Cc: Prafulla Wadaskar; albert.u.b...@aribaud.net; u-boot@lists.denx.de; holger.bru...@keymile.com; Ashish Karkare; Prabhanjan Sarnaik; Heiko Schocher Subject: Re: [PATCH v3 0/8] keymile arm boards update, part 2 Dear Valentin Longchamp, In message 4dd65683.60...@keymile.com you wrote: Wolfgang, what is your opinion on how this should be merged ? The patches have really been posted quite a long time ago (they were split in 3 series in the meantime) and you have applied the other two series already. It would be good for us that the 3 series are able to make it for v2011.06. My understanding is that these patches are on Prafulla's desk. Prafulla, can you please comment? Hi Wolfgang I was offline, and will have limited network access this week. I'll check and pull them by coming Tuesday. Regards.. Prafulla . . Albert, what is your current position regarding this series that was acked by Prafulla now that he has sent this message yesterday ? Do you want to apply them in you tree and (and maybe ask for a pull request for the 2011.06 release) or do you think waiting for Prafulla's return on June 1st (here an hint from Wolfgang to know if it's ok to wait until then would be welcome). Thank you and best regards could you please give us a short note how to proceed with this patch serie? Do we wait until Prafulla is back? Is there still a chance for us that these patches are pulled for rc2? Even if this is not the case a short note would be helpfull for us, that we can prepare our updates for u-boot-next. Thanks. Best regards Holger Brunck ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Is there a working 2011 version of u-boot on i.MX31?
I suspected my toolchain already, so I tested 2 different versions: 1) arm_v6_vfp_le-gcc -v: Using built-in specs. Target: armv6fl-montavista-linux-gnueabi Configured with: ../configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=armv6fl-montavista-linux-gnueabi --prefix=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le --exec-prefix=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le --bindir=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/bin --sbindir=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/sbin --sysconfdir=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/etc --datadir=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/share --includedir=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/include --libdir=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/lib --libexecdir=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/libexec --localstatedir=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/var --sharedstatedir=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/share --mandir=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/man --infodir=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/info --build=i686-pc-linux-gnu --program-transform-name=s,^,arm_v6_vfp_le-, --enable-cross --enable-poison-system-directories --with-sysroot=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/target --with-build-sysroot=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/target --with-build-time-tools=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/bin --enable-shared --enable-languages=c,c++ --enable-__cxa_atexit --enable-c99 --enable-long-long --enable-threads=posix --with-gxx-include-dir=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/lib/gcc/armv6fl-montavista-linux-gnueabi/4.2.0/../../../../target/usr/include/c++/4.2.0 --disable-libmudflap --disable-libssp --disable-libgomp --with-gnu-as --with-gnu-ld --enable-symvers=gnu --enable-checking=release --with-numa-policy=yes --disable-multilib --enable-clocale=gnu --with-cpu=arm1136jf-s --with-interwork --with-arch=armv6j --with-tune=arm1136jf-s --with-fpu=vfp --with-float=softfp --libexecdir=/opt/montavista/mobilinux/devkit/arm/v6_vfp_le/lib --with-bugurl=http://www.mvista.com/support --with-versuffix='MontaVista 4.2.0-16.0.46.custom 2009-03-17' Thread model: posix gcc version 4.2.0 (MontaVista 4.2.0-16.0.46.custom 2009-03-17) 2) arm-angstrom-linux-gnueabi-gcc -v Using built-in specs. Target: arm-angstrom-linux-gnueabi Configured with: /home/HALE/vogc/openembedded/tmp/work/i686-armv6-sdk-angstrom-linux-gnueabi/gcc-cross-sdk-4.3.3-r20.3/gcc-4.3.3/configure --build=i686-linux --host=i686-linux --target=arm-angstrom-linux-gnueabi --prefix=/usr/local/angstrom/arm --exec_prefix=/usr/local/angstrom/arm --bindir=/usr/local/angstrom/arm/bin --sbindir=/usr/local/angstrom/arm/bin --libexecdir=/usr/local/angstrom/arm/libexec --datadir=/usr/local/angstrom/arm/share --sysconfdir=/usr/local/angstrom/arm/etc --sharedstatedir=/usr/local/angstrom/arm/share/com --localstatedir=/usr/local/angstrom/arm/var --libdir=/usr/local/angstrom/arm/lib --includedir=/usr/local/angstrom/arm/include --oldincludedir=/usr/local/angstrom/arm/include --infodir=/usr/local/angstrom/arm/share/info --mandir=/usr/local/angstrom/arm/share/man --with-gnu-ld --enable-shared --enable-languages=c,c++,objc,fortran --enable-threads=posix --disable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=arm-angstrom-linux-gnueabi- --enable-target-optspace --enable-cheaders=c_std --enable-libssp --disable-bootstrap --disable-libgomp --disable-libmudflap --with-sysroot=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi --with-build-time-tools=/home/HALE/vogc/openembedded/tmp/sysroots/i686-linux/usr/armv6/arm-angstrom-linux-gnueabi/bin --with-build-sysroot=/home/HALE/vogc/openembedded/tmp/sysroots/armv6-angstrom-linux-gnueabi --disable-libunwind-exceptions --disable-libssp --disable-libgomp --disable-libmudflap --with-mpfr=/home/HALE/vogc/openembedded/tmp/sysroots/i686-linux/usr --enable-__cxa_atexit Thread model: posix gcc version 4.3.3 (GCC) I just tested Sourcery G++ Lite 2011.03-41, again with the same result. This contains gcc 4.5.2. Helmut -- Scanned by MailScanner. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Help with exporting memory power management info in u-boot
Hi, On Mon, May 30, 2011 at 01:01:57PM +0200, Wolfgang Denk wrote: Dear Ankita Garg, In message 20110530102030.gd18...@in.ibm.com you wrote: I agree with the above. Its not the power consumed by u-boot that is of concern. We want u-boot support in exporting additional information to the kernel, regarding the memory hardware characteristics specific to power management. For instance, if u-boot could inform the kernel about the boundaries at which PASR is supported on the underlying platform, that information could then be used by the kernel to exploit this feature. Like, this information would be encapsulated in a device-tree node maybe ? I agree that is is a good idea to encode such information in the device tree. U-Boot can also help to update memory related notes in the device tree, for example by inserting their actual physical addresses and sizes. The rest, including information about memory power management properties of such nodes in the device tree, is of no concern to U-Boot and should just be passed on unchanged. In my opinion it is therefore the responsibility of the creator of the device tree to provide a proper description of the hardware, including the memory power management information. Ok, thats true. So I guess a better place would be the linux-arm-kernel list to discuss about potential device-tree interface design. Thanks Wolfgang ! -- Regards, Ankita Garg (ank...@in.ibm.com) Linux Technology Center IBM India Systems Technology Labs, Bangalore, India ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Dear ALL, it still escapes me why everyone tries to make things so complicated INSIDE the loop. Why not just define an API like this: u32 timeout = make_timeout(5); /* minimum 5 millisecond timeout */ u32 start = get_timer(); while ((get_timer() - start) timeout) ... make_timeout() can be arch/soc/platform specific and take into account to return at least such a value that the timeout is never cut short. (In case of a 10 ms NIOS timer, make_timeout(5) would have to return the value 20, resulting in a real timeout of at least 10 ms but upto 20 ms ) If anyone sees the need, make_timeout (or what ever it might be called) could have a second parameter, indicating whether round up or round down is desired. ... I also agree to remove the parameter of get_timer(), but we should also get rid of CONFIG_SYS_HZ. Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2011.06-rc1 released
Hi David, Le 30/05/2011 08:24, David Müller (ELSOFT AG) a écrit : Hello Albert ARIBAUD wrote: In message4dd760eb.2050...@elsoft.ch you wrote: please also apply the following patch and friends http://patchwork.ozlabs.org/patch/93595/ this will make VCMA9 board work with current U-Boot release. Applied to arm tree, will send a pull request later today. Could you please also apply the second half of this patch serie: - http://patchwork.ozlabs.org/patch/93598/ - http://patchwork.ozlabs.org/patch/93599/ - http://patchwork.ozlabs.org/patch/93601/ These three are not bugfixes, right? As they were submitted after the merge window, they will go in next right now, and will move to master after 2011-06 is released. Thank you Dave Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] at91sam9260ek and mmc
Dear Jan Pohanka, I'm trying to get u-boot 2010.12 working on at91sam9260ek devkit with mmc support. I have read several discussions here and followed the steps described in README.atmel-mci. (my config and board file are below...) 2010.12 is outdated. Use current top of tree. Besides I have a mmc enabled (and working) 9260ek port in my WIP branch that I will post soon. There are two issues I'm facing. The first one: When I enable mmc support, the dataflash stops to work. According to info from boot process, dataflash is detected correctly, but no data can be read (environment) or written. Dataflash and MMC are mutually exclusive on the 9260ek. Only one should be enabled and used. The second one: fatls command causes u-boot to freeze with following message You have to remove the CS jumper to the dataflash chip, otherwise you get contention between mmc and dataflash hardware. Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/8] keymile arm boards update, part 2
Dear Holger Brunck, In message 4de3bf02.3060...@keymile.com you wrote: could you please give us a short note how to proceed with this patch serie? Do we wait until Prafulla is back? Is there still a chance for us that these patches are pulled for rc2? Even if this is not the case a short note would be helpfull for us, that we can prepare our updates for u-boot-next. Prafulla, Albert and me agreed that Albert will take his patches directly while Prafulla is not available. So this is on Albert's plate. I wait for his pull request. Albert, is this your understanding, too? 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 Any sufficiently advanced technology is indistinguishable from magic. Clarke's Third Law - _Profiles of the Future_ (1962; rev. 1973) ``Hazards of Prophecy: The Failure of Imagination'' ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Help with exporting memory power management info in u-boot
Dear Ankita Garg, In message 20110530170917.gc23...@in.ibm.com you wrote: In my opinion it is therefore the responsibility of the creator of the device tree to provide a proper description of the hardware, including the memory power management information. Ok, thats true. So I guess a better place would be the linux-arm-kernel list to discuss about potential device-tree interface design. Indeed. Thanks Wolfgang ! You are welcome. Please feel free to keep the U-Boot list on Cc: with any topics where the boot loader might help to fill in any parameters that should better be determined dynalically. We'll be happy to help with that. 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 didn't know it was impossible when I did it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/8] keymile arm boards update, part 2
Le 30/05/2011 21:24, Wolfgang Denk a écrit : Dear Holger Brunck, In message4de3bf02.3060...@keymile.com you wrote: could you please give us a short note how to proceed with this patch serie? Do we wait until Prafulla is back? Is there still a chance for us that these patches are pulled for rc2? Even if this is not the case a short note would be helpfull for us, that we can prepare our updates for u-boot-next. Prafulla, Albert and me agreed that Albert will take his patches directly while Prafulla is not available. So this is on Albert's plate. I wait for his pull request. Albert, is this your understanding, too? Yes. I'll look at the patches and let you know. Best regards, Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/8] keymile arm boards update, part 2
Le 30/05/2011 21:49, Albert ARIBAUD a écrit : Le 30/05/2011 21:24, Wolfgang Denk a écrit : Dear Holger Brunck, In message4de3bf02.3060...@keymile.com you wrote: could you please give us a short note how to proceed with this patch serie? Do we wait until Prafulla is back? Is there still a chance for us that these patches are pulled for rc2? Even if this is not the case a short note would be helpfull for us, that we can prepare our updates for u-boot-next. Prafulla, Albert and me agreed that Albert will take his patches directly while Prafulla is not available. So this is on Albert's plate. I wait for his pull request. Albert, is this your understanding, too? Yes. I'll look at the patches and let you know. I'll apply the whole series to u-boot-arm as the first submission was within the merge window. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/8] keymile arm boards update, part 2
Le 30/05/2011 21:57, Albert ARIBAUD a écrit : Le 30/05/2011 21:49, Albert ARIBAUD a écrit : Le 30/05/2011 21:24, Wolfgang Denk a écrit : Dear Holger Brunck, In message4de3bf02.3060...@keymile.comyou wrote: could you please give us a short note how to proceed with this patch serie? Do we wait until Prafulla is back? Is there still a chance for us that these patches are pulled for rc2? Even if this is not the case a short note would be helpfull for us, that we can prepare our updates for u-boot-next. Prafulla, Albert and me agreed that Albert will take his patches directly while Prafulla is not available. So this is on Albert's plate. I wait for his pull request. Albert, is this your understanding, too? Yes. I'll look at the patches and let you know. I'll apply the whole series to u-boot-arm as the first submission was within the merge window. Amicalement, Update: in order to apply the series, I will need to pull the current marvell ARM tree master branch into u-boot-arm, and the rebase is not trivial. Sorry for the delay, but I will only be able to do this tomorrow. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Hi Reinhard, On Tue, May 31, 2011 at 4:57 AM, Reinhard Meyer u-b...@emk-elektronik.de wrote: Dear ALL, it still escapes me why everyone tries to make things so complicated INSIDE the loop. Why not just define an API like this: u32 timeout = make_timeout(5); /* minimum 5 millisecond timeout */ u32 start = get_timer(); while ((get_timer() - start) timeout) ... The would work if we typedef'd 'timeout'. Otherwise, one runs the risk of not calling make_timeout() and assuming get_timer() always has a 1ms resolution make_timeout() can be arch/soc/platform specific and take into account to return at least such a value that the timeout is never cut short. (In case of a 10 ms NIOS timer, make_timeout(5) would have to return the value 20, resulting in a real timeout of at least 10 ms but upto 20 ms ) What about this: u32 start = get_timer(); while (!timer_expired(start, timeout)) ... If anyone sees the need, make_timeout (or what ever it might be called) could have a second parameter, indicating whether round up or round down is desired. ... I also agree to remove the parameter of get_timer(), but we should also get rid of CONFIG_SYS_HZ. Wholeheartedly agree Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Dear Graeme Russ, Hi Reinhard, On Tue, May 31, 2011 at 4:57 AM, Reinhard Meyer u-b...@emk-elektronik.de wrote: Dear ALL, it still escapes me why everyone tries to make things so complicated INSIDE the loop. Why not just define an API like this: u32 timeout = make_timeout(5); /* minimum 5 millisecond timeout */ u32 start = get_timer(); while ((get_timer() - start) timeout) ... The would work if we typedef'd 'timeout'. Otherwise, one runs the risk of not calling make_timeout() and assuming get_timer() always has a 1ms resolution If you think people cannot follow API conventions, then typedef it... make_timeout() can be arch/soc/platform specific and take into account to return at least such a value that the timeout is never cut short. (In case of a 10 ms NIOS timer, make_timeout(5) would have to return the value 20, resulting in a real timeout of at least 10 ms but upto 20 ms ) What about this: u32 start = get_timer(); while (!timer_expired(start, timeout)) ... Again.. why put the complicated calculations INSIDE the loop? If anyone sees the need, make_timeout (or what ever it might be called) could have a second parameter, indicating whether round up or round down is desired. ... I also agree to remove the parameter of get_timer(), but we should also get rid of CONFIG_SYS_HZ. Wholeheartedly agree Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Hi Reinhard, On Tue, May 31, 2011 at 2:07 PM, Reinhard Meyer u-b...@emk-elektronik.de wrote: Dear Graeme Russ, Hi Reinhard, On Tue, May 31, 2011 at 4:57 AM, Reinhard Meyer u-b...@emk-elektronik.de wrote: Dear ALL, it still escapes me why everyone tries to make things so complicated INSIDE the loop. Why not just define an API like this: u32 timeout = make_timeout(5); /* minimum 5 millisecond timeout */ u32 start = get_timer(); while ((get_timer() - start) timeout) ... The would work if we typedef'd 'timeout'. Otherwise, one runs the risk of not calling make_timeout() and assuming get_timer() always has a 1ms resolution If you think people cannot follow API conventions, then typedef it... make_timeout() can be arch/soc/platform specific and take into account to return at least Actually, make_timeout() would not need to be platform specific - All it needs is a get_min_ms_resolution() which wuld be a simple inline usually returning a const so the compiler would optimise it away such a value that the timeout is never cut short. (In case of a 10 ms NIOS timer, make_timeout(5) would have to return the value 20, resulting in a real timeout of at least 10 ms but upto 20 ms ) What about this: u32 start = get_timer(); while (!timer_expired(start, timeout)) ... Again.. why put the complicated calculations INSIDE the loop? Well, the calculations are hidden from the user, and we aren't running a high performance system. Also, the most complex calculations will be performed each time you call get_timer() anyway. The additional overhead of performing a precision rounding will be insignificant Best to make the API as defensive as possible rather than try to trim off a few CPU instructions per loop. Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Dear Graeme Russ, Hi Reinhard, On Tue, May 31, 2011 at 2:07 PM, Reinhard Meyer u-b...@emk-elektronik.de wrote: Dear Graeme Russ, Hi Reinhard, On Tue, May 31, 2011 at 4:57 AM, Reinhard Meyer u-b...@emk-elektronik.dewrote: Dear ALL, it still escapes me why everyone tries to make things so complicated INSIDE the loop. Why not just define an API like this: u32 timeout = make_timeout(5); /* minimum 5 millisecond timeout */ u32 start = get_timer(); while ((get_timer() - start)timeout) ... The would work if we typedef'd 'timeout'. Otherwise, one runs the risk of not calling make_timeout() and assuming get_timer() always has a 1ms resolution If you think people cannot follow API conventions, then typedef it... make_timeout() can be arch/soc/platform specific and take into account to return at least Actually, make_timeout() would not need to be platform specific - All it needs is a get_min_ms_resolution() which wuld be a simple inline usually returning a const so the compiler would optimise it away such a value that the timeout is never cut short. (In case of a 10 ms NIOS timer, make_timeout(5) would have to return the value 20, resulting in a real timeout of at least 10 ms but upto 20 ms ) What about this: u32 start = get_timer(); while (!timer_expired(start, timeout)) ... Again.. why put the complicated calculations INSIDE the loop? Well, the calculations are hidden from the user, and we aren't running a high performance system. Also, the most complex calculations will be performed each time you call get_timer() anyway. The additional overhead of performing a precision rounding will be insignificant Best to make the API as defensive as possible rather than try to trim off a few CPU instructions per loop. Excuse me, but THIS API does not prevent the user to do a (get_timer() - start) timeout inside the loop, making your argument moot. But as I said before, it escapes me why by all means the loop must be more complicated and obscure (on the user side) then essentially necessary... Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
On Mon, May 30, 2011 at 5:24 PM, Graeme Russ graeme.r...@gmail.com wrote: Hi Reinhard, On Tue, May 31, 2011 at 4:57 AM, Reinhard Meyer ... make_timeout() can be arch/soc/platform specific and take into account to return at least such a value that the timeout is never cut short. (In case of a 10 ms NIOS timer, make_timeout(5) would have to return the value 20, resulting in a real timeout of at least 10 ms but upto 20 ms ) What about this: u32 start = get_timer(); while (!timer_expired(start, timeout)) ... Hi Graham, I like this, although I have a small preference for: u32 stop = time_get_future_ms(1234); while (!time_reached(stop)) .. since it possibly means the processing happens up front. However any such function is good and I hope you can add it to your API. If anyone sees the need, make_timeout (or what ever it might be called) could have a second parameter, indicating whether round up or round down is desired. ... I also agree to remove the parameter of get_timer(), but we should also get rid of CONFIG_SYS_HZ. Wholeheartedly agree SGTM. Things are getting better all the time. Regards, Simon Regards, Graeme ___ 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] [RFC][Timer API] Revised Specification - Implementation details
Hi Reinhard, On Tue, May 31, 2011 at 2:36 PM, Reinhard Meyer u-b...@emk-elektronik.de wrote: Dear Graeme Russ, Hi Reinhard, On Tue, May 31, 2011 at 2:07 PM, Reinhard Meyer u-b...@emk-elektronik.de wrote: Dear Graeme Russ, Hi Reinhard, On Tue, May 31, 2011 at 4:57 AM, Reinhard Meyer u-b...@emk-elektronik.de wrote: Dear ALL, it still escapes me why everyone tries to make things so complicated INSIDE the loop. Why not just define an API like this: u32 timeout = make_timeout(5); /* minimum 5 millisecond timeout */ u32 start = get_timer(); while ((get_timer() - start) timeout) ... The would work if we typedef'd 'timeout'. Otherwise, one runs the risk of not calling make_timeout() and assuming get_timer() always has a 1ms resolution If you think people cannot follow API conventions, then typedef it... make_timeout() can be arch/soc/platform specific and take into account to return at least Actually, make_timeout() would not need to be platform specific - All it needs is a get_min_ms_resolution() which wuld be a simple inline usually returning a const so the compiler would optimise it away such a value that the timeout is never cut short. (In case of a 10 ms NIOS timer, make_timeout(5) would have to return the value 20, resulting in a real timeout of at least 10 ms but upto 20 ms ) What about this: u32 start = get_timer(); while (!timer_expired(start, timeout)) ... Again.. why put the complicated calculations INSIDE the loop? Well, the calculations are hidden from the user, and we aren't running a high performance system. Also, the most complex calculations will be performed each time you call get_timer() anyway. The additional overhead of performing a precision rounding will be insignificant Best to make the API as defensive as possible rather than try to trim off a few CPU instructions per loop. Excuse me, but THIS API does not prevent the user to do a (get_timer() - start) timeout inside the loop, making your argument moot. Ah true - Oops ;) But as I said before, it escapes me why by all means the loop must be more complicated and obscure (on the user side) then essentially necessary... What about Simon's solution (next post): u32 stop = time_get_future_ms(1234); while (!time_reached(stop)) .. I really like the idea of a simple while(!something(whatever)) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Dear Simon Glass, On Mon, May 30, 2011 at 5:24 PM, Graeme Russgraeme.r...@gmail.com wrote: Hi Reinhard, On Tue, May 31, 2011 at 4:57 AM, Reinhard Meyer ... make_timeout() can be arch/soc/platform specific and take into account to return at least such a value that the timeout is never cut short. (In case of a 10 ms NIOS timer, make_timeout(5) would have to return the value 20, resulting in a real timeout of at least 10 ms but upto 20 ms ) What about this: u32 start = get_timer(); while (!timer_expired(start, timeout)) ... Hi Graham, I like this, although I have a small preference for: u32 stop = time_get_future_ms(1234); while (!time_reached(stop)) .. I would perfectly like such a solution, it is equivalent to what I have been proposing almost a year ago! since it possibly means the processing happens up front. However any such function is good and I hope you can add it to your API. Exactly! And (saying it silently) this would not mandate that the now hidden internal timer needs to be in ms units, it could be the bare natural tick of the hardware... Making time_get_future() to return the tick (in whatever granularity) that has to be passed would reduce time_reached() to a very simple function. But I get the feeling that exactly this simplicity of above concept is the problem for people that have the urge to invent elaborate and complicated solutions ;) Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
On Mon, May 30, 2011 at 3:57 AM, Wolfgang Denk w...@denx.de wrote:
Dear Simon Glass,
In message banlktim-jzymmzw_twhhhqqyovmk9mz...@mail.gmail.com you wrote:
Sure if you are tracking the timer, and wait for it to increment, and
then wait for it to increment a second time, you can be confident that
the time between the first and second increments is 10ms.
OK. Good.
But in general it is possible that your first read of the timer
happens at 9.999ms after the timer last incremented, just because you
are unlucky. Then perhaps two successive reads of the timer only 1us
apart will see a difference of 10ms in time.
Agreed.
I believe this resolution problem could/should be solved by a function
which returns a time not less than n ms in the future. It would work
by returning something like current_time_ms + (delay_ms +
resolution_ms * 2 - 1) / resolution_ms * resolution_ms, where
resolution_ms is 10 in this case. I think someone else mentioned that
too.
When the timer reaches that time then it is guaranteed that at least
delay_ms ms has passed, although it might be up to delay_ms + 10.
We (well, Detlev and me) discussed this. We think it is important to
realize (and to document) that the timing information provided by
get_timer() is inherently subject to the principles of interval
arithmetics with an implementation dependent interval width.
So far, most (all ?) of the code ignored this property, or silently
assumed that the interval width was equal to or better than 1 milli-
second which is the timing unit used by get_timer().
I think it is important to realize the (most important) use cases of
get_timer(): 1) [longish] timeouts and 2) other timing
computations. For completeness, I also include a third situation
here: 0) [short] timeouts:
[lots of horrible things that I believe we all want to deprecate]
Instead, we suggest to introduce a new function delta_timer() which
hides this implementation detail from the user. delta_timer() will
compute the differnce between two time stamps from get_timer(), and
will return the number of milliseconds that are guaranteed to have
passed AT LEAST between these two moments:
/*
* Everybody uses a 1 millisecond interval,
#ifdef CONFIG_NIOS2
static inline u32 timer_interval_size(void) { return 10; }
#else
static inline u32 timer_interval_size(void) { return 1; }
#endif
u32 delta_timer(u32 from, u32 to)
{
u32 delta = to - from;
if (delta timer_interval_size())
return 0;
return detla - timer_interval_size();
}
Hi Wolfgang,
I think this is a big step forward from what we might call the
'manually coded' loops.
We could also design a more complicated API like this one, but I doubt
this is needed:
I doubt it too.
[snip]
So our timeout from case 1) above would now be written like this:
u32 start,now;
u32 timeout = 5 * CONFIG_SYS_HZ; /* timeout after 5 seconds */
start = get_timer(0);
while (test_for_event() == 0) {
now = get_timer(0);
if (delta_timer(start, now) timeout)
handle_timeout();
udelay(100);
}
and would be guaranteed never to terminate early.
Comments?
Great!
I do think it would be nice to put a time_ prefix before all the time
functions, but this is a pretty minor point.
See my other message about computing a future time. But the less
ad-hoc time calculation we can leave to callers of get_timer() the
better. I think these things are actually a sign of an API which is
too low level. There is a certain purity and simplicity with
get_timer(), sort of minimalist, but the ugly constructs that people
build on top of it need to be considered and brought into the equation
too.
Regards,
Simon
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 bugs in the above code; I have only proved it correct, not
tried it. - Donald Knuth
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
On Tue, May 31, 2011 at 2:53 PM, Reinhard Meyer u-b...@emk-elektronik.de wrote: Dear Simon Glass, On Mon, May 30, 2011 at 5:24 PM, Graeme Russgraeme.r...@gmail.com wrote: Hi Reinhard, On Tue, May 31, 2011 at 4:57 AM, Reinhard Meyer ... make_timeout() can be arch/soc/platform specific and take into account to return at least such a value that the timeout is never cut short. (In case of a 10 ms NIOS timer, make_timeout(5) would have to return the value 20, resulting in a real timeout of at least 10 ms but upto 20 ms ) What about this: u32 start = get_timer(); while (!timer_expired(start, timeout)) ... Hi Graham, I like this, although I have a small preference for: u32 stop = time_get_future_ms(1234); while (!time_reached(stop)) .. I would perfectly like such a solution, it is equivalent to what I have been proposing almost a year ago! Don't forget the API will have a get_current_ms() so we can do duration measurements. So you could still accidentally do: u32 stop = get_current_ms() + 1234; bypassing the resolution correction. If time_reached() did the resolution correction, would this solve the problem of API misuse (yes, I know it puts a complicated calculation back in the loop) since it possibly means the processing happens up front. However any such function is good and I hope you can add it to your API. Exactly! And (saying it silently) this would not mandate that the now hidden internal timer needs to be in ms units, it could be the bare natural tick of the hardware... Making time_get_future() to return the tick (in whatever granularity) that has to be passed would reduce time_reached() to a very simple function. Half the point of refreshing the timer API was to solidify the fact that timers operate on a fixed time base (milliseconds or microseconds) so they can be used trivially for a variety of things (delays, timeouts, durations measurement etc). Ticks can be very short, so doing durations would require 64-bit 'start tick', and a conversion at the end: u64 start = get_current_tick(); ... do something ... u32 duration = ticks_to_ms(get_current_tick() - start); Yetch! - We will not be exposing ticks! But I get the feeling that exactly this simplicity of above concept is the problem for people that have the urge to invent elaborate and complicated solutions ;) I like simple as much as the next guy - I also like hard to misuse ;) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Dear Graeme Russ, On Tue, May 31, 2011 at 2:53 PM, Reinhard Meyer u-b...@emk-elektronik.de wrote: Dear Simon Glass, On Mon, May 30, 2011 at 5:24 PM, Graeme Russgraeme.r...@gmail.com wrote: Hi Reinhard, On Tue, May 31, 2011 at 4:57 AM, Reinhard Meyer ... make_timeout() can be arch/soc/platform specific and take into account to return at least such a value that the timeout is never cut short. (In case of a 10 ms NIOS timer, make_timeout(5) would have to return the value 20, resulting in a real timeout of at least 10 ms but upto 20 ms ) What about this: u32 start = get_timer(); while (!timer_expired(start, timeout)) ... Hi Graham, I like this, although I have a small preference for: u32 stop = time_get_future_ms(1234); while (!time_reached(stop)) .. I would perfectly like such a solution, it is equivalent to what I have been proposing almost a year ago! Don't forget the API will have a get_current_ms() so we can do duration measurements. So you could still accidentally do: u32 stop = get_current_ms() + 1234; bypassing the resolution correction. If time_reached() did the resolution correction, would this solve the problem of API misuse (yes, I know it puts a complicated calculation back in the loop) since it possibly means the processing happens up front. However any such function is good and I hope you can add it to your API. Exactly! And (saying it silently) this would not mandate that the now hidden internal timer needs to be in ms units, it could be the bare natural tick of the hardware... Making time_get_future() to return the tick (in whatever granularity) that has to be passed would reduce time_reached() to a very simple function. Half the point of refreshing the timer API was to solidify the fact that timers operate on a fixed time base (milliseconds or microseconds) so they can be used trivially for a variety of things (delays, timeouts, durations measurement etc). Ticks can be very short, so doing durations would require 64-bit 'start tick', and a conversion at the end: u64 start = get_current_tick(); ... do something ... u32 duration = ticks_to_ms(get_current_tick() - start); Yetch! - We will not be exposing ticks! Moot argument again. Any fast 64 bit tick can be very simply brought into a 32 bit, just sub-ms granularity by a simple right shift. But I would also be happy with 64 bits as well, since all calculations in the loop would be just add/subtracts and no mul/divs. But I get the feeling that exactly this simplicity of above concept is the problem for people that have the urge to invent elaborate and complicated solutions ;) I like simple as much as the next guy - I also like hard to misuse ;) typedefs would prevent accidental misuses, there is no cure against deliberate misuses except peer review... Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Dear Reinhard Meyer, In message 4de4743c.5040...@emk-elektronik.de you wrote: Exactly! And (saying it silently) this would not mandate that the now hidden internal timer needs to be in ms units, it could be the bare natural tick of the hardware... Yes. We can throw everything away and restart evolution from the amoeba, or even with a big bang. Are we discussing API changes or a complete rewrite of everything? 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] [RFC][Timer API] Revised Specification - Implementation details
Dear Wolfgang Denk, Dear Reinhard Meyer, In message4de4743c.5040...@emk-elektronik.de you wrote: Exactly! And (saying it silently) this would not mandate that the now hidden internal timer needs to be in ms units, it could be the bare natural tick of the hardware... Yes. We can throw everything away and restart evolution from the amoeba, or even with a big bang. All you can throw into the timer discussion is critics and pointless remarks, but I miss any productive input from you except sometimes pointing out how powerpc does it. Are we discussing API changes or a complete rewrite of everything? We DO have most of the tick based functions in the current API... And as it seems, the current ms based API is a Pandora's box of problems: - granularity problems in some hardware - early timeouts that need complicated solutions inside the loop - complicated algorithms to convert a natural, non-ms tick into ms values All this would go if the timer would be left in natural ticks of the hardware and simple helper functions be used to convert to and from that to ms, if so desired: tick_t start = get_tick(); ... tick_t end = get_tick(); printf(Elapsed time in ms: %u, ticks2ms(end - start)); OR: tick_t end_tick = time_get_future_tick(1234); /* parameter is in ms, tick will be calculated such that it causes at least xxx ms delay */ while (!tick_reached(end_tick)) ... Perhaps just too simple and too brilliant... Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Dear Simon Glass, In message BANLkTi=t_pzb9toptqunzxarvqshn80...@mail.gmail.com you wrote: I do think it would be nice to put a time_ prefix before all the time functions, but this is a pretty minor point. Agree. By now, I also find get_timer() kind of misleading - one might expect from that name that it allocates one of (eventually several available) timers. We should probably rename it into time_read(); the newly suggested function would then become time_delta() [or time_diff()]. See my other message about computing a future time. But the less I disagree with this, mostly because it seems a too narrow design to me. There is not always and only the need for wait-until-time-X type of tasks. The time_delta() way to do things also gives you the option to compare timestamps that have been recorded any time before. ad-hoc time calculation we can leave to callers of get_timer() the better. I think these things are actually a sign of an API which is too low level. There is a certain purity and simplicity with get_timer(), sort of minimalist, but the ugly constructs that people build on top of it need to be considered and brought into the equation too. It is certainly a good idea to provide simple and reliable ways for standard tasks - but see sig below. 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 UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. - Doug Gwyn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Dear Reinhard Meyer, In message 4de47046.3010...@emk-elektronik.de you wrote: Excuse me, but THIS API does not prevent the user to do a (get_timer() - start) timeout inside the loop, making your argument moot. You can be pretty sure that I will NAK any design that _prevents_ me from doing this when I have specific reasons to do exactly this or something similar. It is definitely a good idea to provide simple and reliable ways for standard tasks - but you also must provide the freedom to do things differently when the standard way does not fit for a reason or another. This is also why I consider it mandatory that get_timer() (or time_read() or whatever it is going t be called) uses a standard unit of time like milliseconds, and not som random internal scaling. 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 Just because your doctor has a name for your condition doesn't mean he knows what it is. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
