Re: [U-Boot] [RFC] Review of U-Boot timer API
Hi Wolfgang On Wed, May 25, 2011 at 3:25 PM, Wolfgang Denk w...@denx.de wrote: Dear Graeme Russ, In message banlktink+bxtz+sumyztvuhcd_ft+jf...@mail.gmail.com you wrote: Yes, but without any guarantee for accuracy or resolution. This is good enough for timeouts, but nothing for time measurements. Out of curiosity, are there any platforms that do not use their most accurate source(*) as the timebase for get_timer()? If a platform is using it's most accurate, commonly available, source for get_timer() the the whole accuracy argument is moot - You can't get any better anyway so why sweat the details. Actually most boards do that, at least most of those who have a RTC chip on board. Almost always these RTCs provide much better accuracy than the system clock used for the CPU-internal timers. In an OS like Linux you will frequently see NTP being used to keep the system time in sync with the more accurate RTC (and eventually other, external time sources) Well, I think we can leave NTP out of the picture for U-Boot - What I am really getting at is are the time bases for udelay() and get_timer() the same, and are they always the most accurate which is readily available to U-Boot. I am thinking the answer is not always 'Yes' as udelay() is needed before relocation and therefore may only have access to a poor-man's time base (using port-mapped I/O to force wait-states on the x86 for example) (*)I'm actually referring to what is commonly available for that platform, and not where a board has a high precision/accuracy source in addition to the common source. I'm not sure what you mean here. Quite frequently even SoCs have a number of different clock sources, say a master clock which is used to derive the processor clock, and a 32768 Hz clock which is used to drive a SoC-internal RTC. The eNET board for example has a microsecond counter in the FPGA which is independently clocked to the CPU As a followup question, how many platforms use two completely independent sources for udelay() and get_timer() - x86 does, but I plan to change this so the interrupt kicks the new prescaler which can be done at 1ms period and udelay() and get_timer() will use the same tick source and therefore have equivalent accuracy. Define completely independent - on PowerPC one uses the timebase register, while the other uses the decrementer. But in the end, both of them are most likely derived from the same system clock (or not - depending on SoC design). But this does not matter at all. I mean udelay() clocked by a tick counter and get_timer() clocked by an interrupt versus both being clocked by the same phyiscal tick counter (even though both are clocked by the same on-board xtal) Hmmm, I think it is worthwhile at least comparing the two - What is the lesser of two evils 1. Exposing 'ticks' through a HAL for the prescaler 2. Duplicating a function with identical code 50+ times across the source tree If it's identical code, all these implementations can share common code, right? Yes I personally think #2 is way worse - The massive redundant duplication and blind copying of code is what has get us into this (and many other) messes That don;t do it, and use common code for this. But to do that, I need to make get_ticks() non static so the prescaler can access the tick counter Currently we have unsigned long long get_ticks(void) =A0which is better as it matches existing hardware. Matches PPC - Does it match every other platform? I know it does not match the sc520 which has a 16-bit millisecond and a 16-bit microsecond counter (which only counts to 999 before resetting to 0) Don't assume every platform can implement a 64-bit tick counter. But yes, we should cater for those platforms that can There are counters of many different sizes around. You cannot squeeze a bigger counter into a smaller data ubit, but you can easily stick smaller data into a bigger container. So it seems most natural to me to chose that data type that fits all, i. e. a bigger one. Putting the smaller counter into a larger bit space causes problems because it wraps to All 0's before it gets to All 1's - This makes a simple unsigned 'current - last' calculation fail at the rollover point. The same problem does not occur if you truncate a larger counter into a smaller bit space Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 0/2] SMDKV310 Board Support
Hi, This patchset adds support for a new board SMDKV310, based on S5PV310 SOC. This SOC is very similar to S5PC210 SOC, hence we are re-using this SOC code. Specific changes in patch versions are mentioned in specific patch files. Chander Kashyap (2): ARMV7: Add support for Samsung SMDKV310 Board ARMV7: MMC SPL Boot support for SMDKV310 board MAINTAINERS|4 + Makefile | 11 + board/samsung/smdkv310/Makefile| 46 ++ board/samsung/smdkv310/lowlevel_init.S | 470 board/samsung/smdkv310/mem_setup.S | 365 +++ board/samsung/smdkv310/smdkv310.c | 136 ++ boards.cfg |1 + include/configs/smdkv310.h | 169 +++ mmc_spl/board/samsung/smdkv310/Makefile| 105 + mmc_spl/board/samsung/smdkv310/mmc_boot.c | 85 .../board/samsung/smdkv310/tools/mkv310_image.c| 116 + mmc_spl/board/samsung/smdkv310/u-boot.lds | 86 12 files changed, 1594 insertions(+), 0 deletions(-) create mode 100644 board/samsung/smdkv310/Makefile create mode 100644 board/samsung/smdkv310/lowlevel_init.S create mode 100644 board/samsung/smdkv310/mem_setup.S create mode 100644 board/samsung/smdkv310/smdkv310.c create mode 100644 include/configs/smdkv310.h create mode 100644 mmc_spl/board/samsung/smdkv310/Makefile create mode 100644 mmc_spl/board/samsung/smdkv310/mmc_boot.c create mode 100644 mmc_spl/board/samsung/smdkv310/tools/mkv310_image.c create mode 100644 mmc_spl/board/samsung/smdkv310/u-boot.lds -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 1/2] ARMV7: Add support for Samsung SMDKV310 Board
SMDKV310 board is based on Samsung S5PV310 SOC. This SOC is very much
similar to S5PC210.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
Changes for v2:
- Coding Style Cleanup
- Removed unwanted macros from board config file.
- Ethernet controllor configuration is done using gpio structures.
- MMC Controllor gpio configuration corrected.
- Added MAINTAINERS entry.
- Removed unwanted code from mem_setup.S.
Changes for v3:
- Comment style fixed
- Added New macro in board config file.
Changes for v4:
- Fixed line with more than 80 characters in board config file
MAINTAINERS|4 +
board/samsung/smdkv310/Makefile| 46 +++
board/samsung/smdkv310/lowlevel_init.S | 470
board/samsung/smdkv310/mem_setup.S | 365 +
board/samsung/smdkv310/smdkv310.c | 136 +
boards.cfg |1 +
include/configs/smdkv310.h | 169
7 files changed, 1191 insertions(+), 0 deletions(-)
create mode 100644 board/samsung/smdkv310/Makefile
create mode 100644 board/samsung/smdkv310/lowlevel_init.S
create mode 100644 board/samsung/smdkv310/mem_setup.S
create mode 100644 board/samsung/smdkv310/smdkv310.c
create mode 100644 include/configs/smdkv310.h
diff --git a/MAINTAINERS b/MAINTAINERS
index e2c48a8..a3f6ef2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -702,6 +702,10 @@ Minkyu Kang mk7.k...@samsung.com
s5p_goniARM ARMV7 (S5PC110 SoC)
s5pc210_universal ARM ARMV7 (S5PC210 SoC)
+Chander Kashyap k.chan...@samsung.com
+
+ SMDKV310ARM ARMV7 (S5PC210 SoC)
+
Frederik Kriewitz frede...@kriewitz.eu
devkit8000 ARM ARMV7 (OMAP3530 SoC)
diff --git a/board/samsung/smdkv310/Makefile b/board/samsung/smdkv310/Makefile
new file mode 100644
index 000..8e9b703
--- /dev/null
+++ b/board/samsung/smdkv310/Makefile
@@ -0,0 +1,46 @@
+#
+# Copyright (C) 2011 Samsung Electronics
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+SOBJS := mem_setup.o
+SOBJS += lowlevel_init.o
+COBJS += smdkv310.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
+
+all:$(obj).depend $(LIB)
+
+$(LIB):$(OBJS)
+ $(AR) $(ARFLAGS) $@ $(OBJS)
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/samsung/smdkv310/lowlevel_init.S
b/board/samsung/smdkv310/lowlevel_init.S
new file mode 100644
index 000..359cff4
--- /dev/null
+++ b/board/samsung/smdkv310/lowlevel_init.S
@@ -0,0 +1,470 @@
+/*
+ * Lowlevel setup for SMDKV310 board based on S5PC210
+ *
+ * Copyright (C) 2011 Samsung Electronics
+ *
+ * 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 config.h
+#include version.h
+#include asm/arch/cpu.h
+
+/*
+ * Register usages:
+ *
+ * r5 has zero always
+ * r7 has GPIO part1 base 0x1140
+ * r6 has GPIO part2 base 0x1100
+ */
+
+#define MEM_DLLl_ON
+
+_TEXT_BASE:
+ .word CONFIG_SYS_TEXT_BASE
+
+ .globl lowlevel_init
+lowlevel_init:
+ push{lr}
+
[U-Boot] [PATCH v5 2/2] ARMV7: MMC SPL Boot support for SMDKV310 board
Added MMC SPL boot support for SMDKV310. This framework design is
based on nand_spl support.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
Changes for v3:
- spl file renamed to u-boot-mmc-spl.bin
- spl directory renamed to mmc_spl
- comments added in mkv310_image.c file
Changes for v5:
- Compilation warning
mmc_boot.c: In function 'board_init_r':
mmc_boot.c:51: warning: 'noreturn' function does return
fixed.
Makefile | 11 ++
mmc_spl/board/samsung/smdkv310/Makefile| 105 ++
mmc_spl/board/samsung/smdkv310/mmc_boot.c | 85 ++
.../board/samsung/smdkv310/tools/mkv310_image.c| 116
mmc_spl/board/samsung/smdkv310/u-boot.lds | 86 +++
5 files changed, 403 insertions(+), 0 deletions(-)
create mode 100644 mmc_spl/board/samsung/smdkv310/Makefile
create mode 100644 mmc_spl/board/samsung/smdkv310/mmc_boot.c
create mode 100644 mmc_spl/board/samsung/smdkv310/tools/mkv310_image.c
create mode 100644 mmc_spl/board/samsung/smdkv310/u-boot.lds
diff --git a/Makefile b/Makefile
index 384a59e..25b87b0 100644
--- a/Makefile
+++ b/Makefile
@@ -322,6 +322,10 @@ ALL += $(obj)u-boot-onenand.bin
ONENAND_BIN ?= $(obj)onenand_ipl/onenand-ipl-2k.bin
endif
+ifeq ($(CONFIG_MMC_U_BOOT),y)
+ALL += $(obj)mmc_spl/u-boot-mmc-spl.bin
+endif
+
all: $(ALL)
$(obj)u-boot.hex: $(obj)u-boot
@@ -413,6 +417,11 @@ onenand_ipl: $(TIMESTAMP_FILE) $(VERSION_FILE)
$(obj)include/autoconf.mk
$(obj)u-boot-onenand.bin: onenand_ipl $(obj)u-boot.bin
cat $(ONENAND_BIN) $(obj)u-boot.bin $(obj)u-boot-onenand.bin
+mmc_spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend
+ $(MAKE) -C mmc_spl/board/$(BOARDDIR) all
+
+$(obj)mmc_spl/u-boot-mmc-spl.bin: mmc_spl
+
$(VERSION_FILE):
@( localvers='$(shell $(TOPDIR)/tools/setlocalversion
$(TOPDIR))' ; \
printf '#define PLAIN_VERSION %s%s\n' \
@@ -1123,6 +1132,7 @@ clean:
@rm -f $(obj)lib/asm-offsets.s
@rm -f $(obj)nand_spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,System.map}
@rm -f $(obj)onenand_ipl/onenand-{ipl,ipl.bin,ipl.map}
+ @rm -f
$(obj)mmc_spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,u-boot-spl.bin,u-boot-mmc-spl.bin}
@rm -f $(ONENAND_BIN)
@rm -f $(obj)onenand_ipl/u-boot.lds
@rm -f $(TIMESTAMP_FILE) $(VERSION_FILE)
@@ -1147,6 +1157,7 @@ clobber: clean
@rm -fr $(obj)include/generated
@[ ! -d $(obj)nand_spl ] || find $(obj)nand_spl -name * -type l
-print | xargs rm -f
@[ ! -d $(obj)onenand_ipl ] || find $(obj)onenand_ipl -name * -type l
-print | xargs rm -f
+ @[ ! -d $(obj)mmc_spl ] || find $(obj)mmc_spl -name * -type l -print
| xargs rm -f
ifeq ($(OBJTREE),$(SRCTREE))
mrproper \
diff --git a/mmc_spl/board/samsung/smdkv310/Makefile
b/mmc_spl/board/samsung/smdkv310/Makefile
new file mode 100644
index 000..f1ce066
--- /dev/null
+++ b/mmc_spl/board/samsung/smdkv310/Makefile
@@ -0,0 +1,105 @@
+#
+# (C) Copyright 2006-2007
+# Stefan Roese, DENX Software Engineering, s...@denx.de.
+#
+# (C) Copyright 2008
+# Guennadi Liakhovetki, DENX Software Engineering, l...@denx.de
+#
+# (C) Copyright 2011
+# Chander Kashyap, Samsung Electronics, k.chan...@samsung.com
+#
+# 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
+#
+
+CONFIG_MMC_SPL = y
+
+include $(TOPDIR)/config.mk
+
+LDSCRIPT= $(TOPDIR)/mmc_spl/board/$(BOARDDIR)/u-boot.lds
+LDFLAGS= -Bstatic -T $(mmcobj)u-boot.lds -Ttext
$(CONFIG_SYS_TEXT_BASE) $(PLATFORM_LDFLAGS)
+AFLAGS += -DCONFIG_MMC_SPL
+CFLAGS += -DCONFIG_MMC_SPL
+CFLAGS += -DCONFIG_PRELOADER
+
+SOBJS = start.o mem_setup.o lowlevel_init.o
+COBJS = mmc_boot.o
+
+SRCS := $(addprefix $(obj),$(SOBJS:.o=.S) $(COBJS:.o=.c))
+OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS))
+__OBJS := $(SOBJS) $(COBJS)
+LNDIR := $(OBJTREE)/mmc_spl/board/$(BOARDDIR)
+
+mmcobj := $(OBJTREE)/mmc_spl/
+
+
+MKV310_MMC_SPL_EXEC = mkv310_mmc_spl_exec
+MMC_SPL_BIN = u-boot-mmc-spl.bin
+
+ALL = $(mmcobj)u-boot-spl $(mmcobj)u-boot-spl.bin $(mmcobj)$(MMC_SPL_BIN)
+
+all:
Re: [U-Boot] [RFC] Review of U-Boot timer API
Hi Wolfgang, On Wed, May 25, 2011 at 3:28 PM, Wolfgang Denk w...@denx.de wrote: Dear J. William Campbell, In message 4ddc6f46.4090...@comcast.net you wrote: Well, it is not quite that simple. The accuracy of the 1 ms interrupt rate is controlled in all cases I know about by the resolution of the programmable divider used to produce it. It appears that the x86 I mentioned a couple of times before that accuracy has never been a design criterion. Please also keep in mind that there are areas in the code where we block interrupts, and we make zero efforts to detect or compensate for this in the timer code. This simply is not important. We are not talking about ppm here, we are talking about somting that is just good enough for what it is being used, and that allows easily for +/- 10% tolerances. With the prescaler design we are discussing, as long as we have access to a free-running tick counter, it does not matter one iota if the interrupt is delayed by one tick, a hundred ticks or a thousand ticks privided it eventually happens within the roll-over interval of the tick counter And if get_timer() is called in the meantime, the roll-over interval gets reset Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Job Vacancies
I am Vicky Spore from Canada, Working with the Five Star Alliance Hotel Management; I wish to inform you about the placement of Hotel Jobs availability here in Canada. We seek Job-seekers, men and women, married and single, that would like to work and live in Canada .The Five Star Hotel will pay for your flight ticket and assist you to process your visa in your country of resident, if you are interested contact the secretary via E-mail : fivestarallia...@ymail.com And we shall reach you with the Hotel information immediately. Thanks. Vicky Spore. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Job Vacancies
I am Vicky Spore from Canada, Working with the Five Star Alliance Hotel Management; I wish to inform you about the placement of Hotel Jobs availability here in Canada. We seek Job-seekers, men and women, married and single, that would like to work and live in Canada .The Five Star Hotel will pay for your flight ticket and assist you to process your visa in your country of resident, if you are interested contact the secretary via E-mail : fivestarallia...@ymail.com And we shall reach you with the Hotel information immediately. Thanks. Vicky Spore. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
Dear Graeme Russ, In message BANLkTi==emvE+2Xu-R=hzh3tgfjxs9d...@mail.gmail.com you wrote: Well, I think we can leave NTP out of the picture for U-Boot - What I am really getting at is are the time bases for udelay() and get_timer() the same, and are they always the most accurate which is readily available to U-Boot. Please assume no to both questions. Even more important: stop worrying about this. The implementation is noit supposed to make ANY such assumptions. I mean udelay() clocked by a tick counter and get_timer() clocked by an interrupt versus both being clocked by the same phyiscal tick counter (even though both are clocked by the same on-board xtal) You really should not care about those low-level details. They can and shall be ignored. There are counters of many different sizes around. You cannot squeeze a bigger counter into a smaller data ubit, but you can easily stick smaller data into a bigger container. So it seems most natural to me to chose that data type that fits all, i. e. a bigger one. Putting the smaller counter into a larger bit space causes problems because it wraps to All 0's before it gets to All 1's - This makes a simple unsigned 'current - last' calculation fail at the rollover point. The same problem does not occur if you truncate a larger counter into a smaller bit space But then you may significantly reduce the available time-span; you may see the counter wrapping around every few seconds. You will not be able to implement - say - a 10 second delay because you cannot know if there were 1, 2, or more rollovers inbetween. I see two options: 1) either we can have some signal when the timer wrapes around (like an interrupt); in this case it does not matter how big the counter itself is, we just increment our own local 64 bit timestamp. 2) Alternatively, I could imagine we use a 64 bit container plus a mask which specifiec how many bits are actually used - then we can accommodate counters with any numbers of valid bits. 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 PUBLIC NOTICE AS REQUIRED BY LAW: Any Use of This Product, in Any Manner Whatsoever, Will Increase the Amount of Disorder in the Universe. Although No Liability Is Implied Herein, the Consumer Is Warned That This Process Will Ultimately Lead to the Heat Death of the Universe. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
Dear Graeme Russ, In message BANLkTinZ_q8_vqd9mzm7BY64Hi=zuyf...@mail.gmail.com you wrote: With the prescaler design we are discussing, as long as we have access to a free-running tick counter, it does not matter one iota if the interrupt is delayed by one tick, a hundred ticks or a thousand ticks privided it eventually happens within the roll-over interval of the tick counter I don't get you. In such a system, the interrupt would be the tick (see the PPC implementation). If you miss interrupts, you miss ticks. 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 Real computer scientists don't comment their code. The identifiers are so long they can't afford the disk space. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
On 25/05/11 18:06, Wolfgang Denk wrote: Dear Graeme Russ, In message BANLkTi==emvE+2Xu-R=hzh3tgfjxs9d...@mail.gmail.com you wrote: Well, I think we can leave NTP out of the picture for U-Boot - What I am really getting at is are the time bases for udelay() and get_timer() the same, and are they always the most accurate which is readily available to U-Boot. Please assume no to both questions. Thought so Even more important: stop worrying about this. The implementation is noit supposed to make ANY such assumptions. I'm not really worrying about from the perspective of the new timer API, it's idle curiosity and getting a better understanding I mean udelay() clocked by a tick counter and get_timer() clocked by an interrupt versus both being clocked by the same phyiscal tick counter (even though both are clocked by the same on-board xtal) You really should not care about those low-level details. They can and shall be ignored. Yes, but you find that there is another level of simplification available... There are counters of many different sizes around. You cannot squeeze a bigger counter into a smaller data ubit, but you can easily stick smaller data into a bigger container. So it seems most natural to me to chose that data type that fits all, i. e. a bigger one. Putting the smaller counter into a larger bit space causes problems because it wraps to All 0's before it gets to All 1's - This makes a simple unsigned 'current - last' calculation fail at the rollover point. The same problem does not occur if you truncate a larger counter into a smaller bit space But then you may significantly reduce the available time-span; you may see the counter wrapping around every few seconds. You will not be able to implement - say - a 10 second delay because you cannot know if there were 1, 2, or more rollovers inbetween. I see two options: 1) either we can have some signal when the timer wrapes around (like an interrupt); in this case it does not matter how big the counter itself is, we just increment our own local 64 bit timestamp. 2) Alternatively, I could imagine we use a 64 bit container plus a mask which specifiec how many bits are actually used - then we can accommodate counters with any numbers of valid bits. 3) Keep calling get_timer() (which you do when checking protocol time-outs) - This keeps kicking the prescaler Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
On 25/05/11 18:08, Wolfgang Denk wrote: Dear Graeme Russ, In message BANLkTinZ_q8_vqd9mzm7BY64Hi=zuyf...@mail.gmail.com you wrote: With the prescaler design we are discussing, as long as we have access to a free-running tick counter, it does not matter one iota if the interrupt is delayed by one tick, a hundred ticks or a thousand ticks privided it eventually happens within the roll-over interval of the tick counter I don't get you. In such a system, the interrupt would be the tick (see the PPC implementation). If you miss interrupts, you miss ticks. Yes, you miss ticks, but if the hardware is keeping the tick counter current in the background (i.e. without software or interrupts) then this does not matter - The prescaler takes care of this... The key is the prescaler takes a 'tick delta' between the last time it was called and now, uses the 'tick frequency' to calculate a corresponding 'timer delta' which it adds to the current timer So the frequency of calling the prescaler _does not matter_ (it does not even need to be a regular frequency) provided the tick-counter does not do a complete wrap (at 4GHz this is 4 seconds for a 32-bit counter) - So as long as you call the prescaler at least every 4 seconds (and get_timer() calls the prescaler) then you will never have a timer glitch in your timing loop. This relies on the tick counter wrapping properly. So, if your tick counter is accurate, your timer is accurate even if you are using an ISR to call the prescaler and temporarily disable interrupts How many platforms have no hardware counter whatsoever? - These will have to implement the timer using interrupts and suffer the accuracy loss when interrupts are disabled (and how would these implement udelay() anyway - hard loops I guess) And now for the kicker - If your tick counter is microsecond resolution or better, you can maintain microsecond, millisecond (second, minute etc) timers trivially with a new prescaler Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Hotel Job Vacancies
I am Vicky Spore from Canada, Working with the Five Star Alliance Hotel Management; I wish to inform you about the placement of Hotel Jobs availability here in Canada. We seek Job-seekers, men and women, married and single, that would like to work and live in Canada .The Five Star Hotel will pay for your flight ticket and assist you to process your visa in your country of resident, if you are interested contact the secretary via E-mail : fivestarallia...@ymail.com And we shall reach you with the Hotel information immediately. Thanks. Vicky Spore. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mpc5567
Dear cengiz.uen...@bergerelektronik.de, In message of2d3c57bc.4f3c8b7e-onc125789b.0029dab7-c125789b.002a0...@star-cooperation.com you wrote: ich arbeite gerade an einem projekt mit dem MPC5567 von Freescale und suche nach einem passenden Bootloader, da bin ich auf diese Website gestoßen. Ist es möglich diesen U-Boot Bootloader für diesen uC zu benutzen ohne Linux-Betriebssystem ? Please note that this is an international mailing list, so please post in English here. Thanks. Q: Can I use U-Boot on a MPC5567 based board? A: Yes, there should be no fundamental problems to port U-Boot on such a system. Note that such a port, even if more or less straightforward, is not exactly a trivial task. Ich muss später über die Ethernet Schnittstelle meinen MPC5567 flashen also kurzgesagt: Ethernet (PC) = XCP = Ethernet (MPC5567) = Bootlo ader = MPC5567 Q: Can I update the flash over ethernet? Yes, you can. U_Boot supports file download through TFTP or NFS, and of course you can erase and program the flash with the loaded images. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A meeting is an event at which the minutes are kept and the hours are lost. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
Dear Graeme Russ, In message 4ddcbd3d.4080...@gmail.com you wrote: I see two options: 1) either we can have some signal when the timer wrapes around (like an interrupt); in this case it does not matter how big the counter itself is, we just increment our own local 64 bit timestamp. 2) Alternatively, I could imagine we use a 64 bit container plus a mask which specifiec how many bits are actually used - then we can accommodate counters with any numbers of valid bits. 3) Keep calling get_timer() (which you do when checking protocol time-outs) - This keeps kicking the prescaler We cannot guarantee for this, so this is not really an option. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A door is what a dog is perpetually on the wrong side of. - Ogden Nash ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
Dear Graeme Russ, In message 4ddcbff4.40...@gmail.com you wrote: I don't get you. In such a system, the interrupt would be the tick (see the PPC implementation). If you miss interrupts, you miss ticks. Yes, you miss ticks, but if the hardware is keeping the tick counter current in the background (i.e. without software or interrupts) then this does not matter - The prescaler takes care of this... I think you don't want to understand. Look at the PPC implementation. The decrementer causes an interrupt every millisecond. This is our tick. We never ever actually read the decrementer register itself. We just use the interrupt. The key is the prescaler takes a 'tick delta' between the last time it was called and now, uses the 'tick frequency' to calculate a corresponding 'timer delta' which it adds to the current timer The tick frequency in above example is 1,000 Hz, and determined by the frequency of the interrupts. There is not any timer count register we are accessing here. This relies on the tick counter wrapping properly. The tick counter is already in the higher level, i. e. implemented in software, without any hardware based registers. 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 Diplomacy is the art of saying nice doggy until you can find a rock. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
Hi Wolfgang,
On 25/05/11 21:37, Wolfgang Denk wrote:
Dear Graeme Russ,
In message 4ddcbff4.40...@gmail.com you wrote:
I don't get you. In such a system, the interrupt would be the tick
(see the PPC implementation). If you miss interrupts, you miss ticks.
Yes, you miss ticks, but if the hardware is keeping the tick counter
current in the background (i.e. without software or interrupts) then this
does not matter - The prescaler takes care of this...
I think you don't want to understand.
Look at the PPC implementation. The decrementer causes an interrupt
every millisecond. This is our tick. We never ever actually read the
decrementer register itself. We just use the interrupt.
x86 is the same - a 1ms interrupt which increments the timer
The key is the prescaler takes a 'tick delta' between the last time it was
called and now, uses the 'tick frequency' to calculate a corresponding
'timer delta' which it adds to the current timer
The tick frequency in above example is 1,000 Hz, and determined by
the frequency of the interrupts. There is not any timer count
register we are accessing here.
This relies on the tick counter wrapping properly.
The tick counter is already in the higher level, i. e. implemented
in software, without any hardware based registers.
And in the PPC case - No prescaler and life is easy
BUT - I just found something very disturbing in /board/zylonite/flash.c -
Interrupts are disables before the timer is used to detect a timeout!
Yes, this is in a board specific flash driver which is bad but who knows
where else this might (quite unintentionally) occur
No if you have:
start = get_timer(0)
while (hardware_busy) {
if (get_timer(start) TIMEOUT) {
/* deal with timeout */
break;
}
/* Do stuf (poll hardware etc) */
}
Now every time get_timer() is called, the prescaler updates the timer from
the current tick count - This cannot fail if interrupts are inadvertently
disabled.
And if you do not care about the timer updating while you are not 'using
it' (i.e. checking for a timeout) - it doesn't really matter - You will get
a glitch, but this glitch is 'reset' by the call to get_timer() and your
timeout check starts a new timer increment afresh
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
Hi Wolfgang, On 25/05/11 21:32, Wolfgang Denk wrote: Dear Graeme Russ, In message 4ddcbd3d.4080...@gmail.com you wrote: I see two options: 1) either we can have some signal when the timer wrapes around (like an interrupt); in this case it does not matter how big the counter itself is, we just increment our own local 64 bit timestamp. 2) Alternatively, I could imagine we use a 64 bit container plus a mask which specifiec how many bits are actually used - then we can accommodate counters with any numbers of valid bits. 3) Keep calling get_timer() (which you do when checking protocol time-outs) - This keeps kicking the prescaler We cannot guarantee for this, so this is not really an option. You can when you are waiting for a timeout Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/
On 24/05/11 20:54, Graeme Russ wrote: There is no need to use set_timer() and reset_timer() and there are build breakages occuring because of them (specifically cfi_flash). Remove any usage outside arch/ to fix build breakages and to prepare for complete removal The Nios2 timer implentation updates every 10ms (increases in 10ms steps) and required a reset_timer() call before timing operations. For Nios2, call reset_timer() when get_timer() is called with a parameter value of 0 That's not going to work either - start = get_timer(0) will reset the timer and set start to zero so get_timer(start) will continually reset the timer and return zero :( Stay tuned for v3 :) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
Dear Graeme Russ, In message 4ddced75.8030...@gmail.com you wrote: I don't get you. In such a system, the interrupt would be the tick (see the PPC implementation). If you miss interrupts, you miss ticks. ... The tick counter is already in the higher level, i. e. implemented in software, without any hardware based registers. ... Now every time get_timer() is called, the prescaler updates the timer from the current tick count - This cannot fail if interrupts are inadvertently disabled. Arghh... But in this szenario, if interrupts are disabled, then the ISR will not run, so the tick count will not be incremented BECAUSE THE TICK COUNTER IS A VARIABLE THAT GETS INCREMENTED BY ONE EACH TIME THE ISR RUNS. So your prescaler will read a constant value. Sorry for shouting, but I feel either you are not listening to me or I cannot make myself understood to you. 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 Violence in reality is quite different from theory. -- Spock, The Cloud Minders, stardate 5818.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
Dear Graeme Russ, In message 4ddceda1.2010...@gmail.com you wrote: 3) Keep calling get_timer() (which you do when checking protocol time-outs) - This keeps kicking the prescaler We cannot guarantee for this, so this is not really an option. You can when you are waiting for a timeout We may not be waiting for any timeouts for arbitrary long times. 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 Men will always be men -- no matter where they are. -- Harry Mudd, Mudd's Women, stardate 1329.8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
Graeme Russ wrote: OK, let's wind back - My original suggestion made no claim towards changing what the API is used for, or how it looks to those who use it (for all practical intents and purposes). I suggested: - Removing set_timer() and reset_timer() - Implement get_timer() as a platform independent function Why do you suggest removing set_timer() and reset_timer() ? --Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
Hi Wolfgang, On 25/05/11 22:26, Wolfgang Denk wrote: Dear Graeme Russ, In message 4ddced75.8030...@gmail.com you wrote: I don't get you. In such a system, the interrupt would be the tick (see the PPC implementation). If you miss interrupts, you miss ticks. ... The tick counter is already in the higher level, i. e. implemented in software, without any hardware based registers. ... Now every time get_timer() is called, the prescaler updates the timer from the current tick count - This cannot fail if interrupts are inadvertently disabled. Arghh... But in this szenario, if interrupts are disabled, then the ISR will not run, so the tick count will not be incremented BECAUSE THE TICK COUNTER IS A VARIABLE THAT GETS INCREMENTED BY ONE EACH TIME THE ISR RUNS. So your prescaler will read a constant value. Sorry for shouting, but I feel either you are not listening to me or I cannot make myself understood to you. What you are saying is 100% correct - For PPC. Now please - step back from PPC for a minute Many platforms have a hardware counter which is incremented without assistance from software - not by an ISR, nothing (I mentioned this before, but I can't track down the exact email) - THIS is the tick counter returned by get_ticks() which the prescaler uses to update the timer when you either: - Explicitly call get_timer() - Call the prescaler from an ISR The thing is, I have now highlighted that relying on interrupts to keep get_timer() working is a really bad idea - We have no way of stopping anyone from calling disable_interrupts() before using the timer The suggested architecture makes ISR servicing of the timer 'nice' for long delays where the tick counter might wrap and 'always works' for timeout loops which repeatedly call get_timer() Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
Hi Scott, On 25/05/11 22:36, Scott McNutt wrote: Graeme Russ wrote: OK, let's wind back - My original suggestion made no claim towards changing what the API is used for, or how it looks to those who use it (for all practical intents and purposes). I suggested: - Removing set_timer() and reset_timer() - Implement get_timer() as a platform independent function Why do you suggest removing set_timer() and reset_timer() ? Because if the timer API is done right, they are not needed Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
Dear Graeme Russ, In message 4ddcf926.1050...@gmail.com you wrote: Many platforms have a hardware counter which is incremented without assistance from software - not by an ISR, nothing (I mentioned this before, but I can't track down the exact email) - THIS is the tick counter returned by get_ticks() which the prescaler uses to update the timer when you either: - Explicitly call get_timer() - Call the prescaler from an ISR The thing is, I have now highlighted that relying on interrupts to keep get_timer() working is a really bad idea - We have no way of stopping anyone from calling disable_interrupts() before using the timer There may be code which doe snot call get_timer() for _long_ times. And somebody disables interrupts. What's then? 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 Your csh still thinks true is false. Write to your vendor today and tell them that next year Configure ought to rm /bin/csh unless they fix their blasted shell. :-) - Larry Wall in Configure from the perl distribution ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
Graeme Russ wrote: Hi Scott, On 25/05/11 22:36, Scott McNutt wrote: Graeme Russ wrote: OK, let's wind back - My original suggestion made no claim towards changing what the API is used for, or how it looks to those who use it (for all practical intents and purposes). I suggested: - Removing set_timer() and reset_timer() - Implement get_timer() as a platform independent function Why do you suggest removing set_timer() and reset_timer() ? Because if the timer API is done right, they are not needed To continue the wind back ... In several implementations, reset_timer() actually reloads or re-initializes the hardware timer. This has the effect of synchronizing get_timer() calls with subsequent interrupts. This prevents the early timeouts if the implementer chooses to use an interrupt rate less than 1 ms. So my original question was, how do we address this issue? --Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
On Wednesday, May 25, 2011, Wolfgang Denk w...@denx.de wrote: Dear Graeme Russ, In message 4ddcf926.1050...@gmail.com you wrote: Many platforms have a hardware counter which is incremented without assistance from software - not by an ISR, nothing (I mentioned this before, but I can't track down the exact email) - THIS is the tick counter returned by get_ticks() which the prescaler uses to update the timer when you either: - Explicitly call get_timer() - Call the prescaler from an ISR The thing is, I have now highlighted that relying on interrupts to keep get_timer() working is a really bad idea - We have no way of stopping anyone from calling disable_interrupts() before using the timer There may be code which doe snot call get_timer() for _long_ times. And somebody disables interrupts. What's then? We're hosed, but at least we are one better than relying on interrupts alone ;) And what about platforms that do not support interrupts? Are you mandating that get_timer() MUST always be supported by a timer updated by an ISR? Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
Hi Scott, On Wednesday, May 25, 2011, Scott McNutt smcn...@psyent.com wrote: Graeme Russ wrote: Hi Scott, On 25/05/11 22:36, Scott McNutt wrote: Graeme Russ wrote: OK, let's wind back - My original suggestion made no claim towards changing what the API is used for, or how it looks to those who use it (for all practical intents and purposes). I suggested: - Removing set_timer() and reset_timer() - Implement get_timer() as a platform independent function Why do you suggest removing set_timer() and reset_timer() ? Because if the timer API is done right, they are not needed To continue the wind back ... In several implementations, reset_timer() actually reloads or re-initializes the hardware timer. This has the effect of synchronizing get_timer() calls with subsequent interrupts. This prevents the early timeouts if the implementer chooses to use an interrupt rate less than 1 ms. So my original question was, how do we address this issue? We fix them dear Liza dear Liza ;) That is what this thread is trying to figure out Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
Dear Graeme Russ, In message banlktimhtqynwgvwr6w8knosv4u_tzs...@mail.gmail.com you wrote: And what about platforms that do not support interrupts? Are you mandating that get_timer() MUST always be supported by a timer updated by an ISR? No, not at all. And I already answered this. For example on PPC, just reading the timebase would be perfectly sufficient, and simpler and more reliable than the current interrupt based approach. 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 Ein weiser Herrscher kann in einem großen Land mehr Gutes bewirken als in einem kleinen - ein dummer Herrscher aber auch viel mehr Un- fug. Da weise Herrscher seltener sind als dumme, war ich schon immer gegen große Reiche skeptisch. - Herbert Rosendorfer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
Graeme Russ wrote: Hi Scott, On Wednesday, May 25, 2011, Scott McNutt smcn...@psyent.com wrote: Graeme Russ wrote: Hi Scott, On 25/05/11 22:36, Scott McNutt wrote: Graeme Russ wrote: OK, let's wind back - My original suggestion made no claim towards changing what the API is used for, or how it looks to those who use it (for all practical intents and purposes). I suggested: - Removing set_timer() and reset_timer() - Implement get_timer() as a platform independent function Why do you suggest removing set_timer() and reset_timer() ? Because if the timer API is done right, they are not needed To continue the wind back ... In several implementations, reset_timer() actually reloads or re-initializes the hardware timer. This has the effect of synchronizing get_timer() calls with subsequent interrupts. This prevents the early timeouts if the implementer chooses to use an interrupt rate less than 1 ms. So my original question was, how do we address this issue? We fix them dear Liza dear Liza ;) That is what this thread is trying to figure out I'm getting a bit frustrated here as I can see we're going in circles. So I'll just make a few statements a leave well enough alone. - I'm not convinced that reset_timer() and set_timer() should be removed simply because you state that if the timer API is done right, they are not needed. - If an implementation can't use interrupts that occur less frequently than 1 msec to satisfy the prevailing use of get_timer(), without breaking existing capability, I consider the interface that is done right to be wrong. Best Regards, --Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] testing mmc slot w/ generic mmc
I have a custom OMAP3-based board with 2 MMC slots. During my boot sequence, I want to test whether a card is present in mmc slot 1, and boot from it if so. Otherwise it will continue to look at other options. Until now, w/o CONFIG_GENERIC_MMC, I have used 'mmc init 1' to do this, which would return false if there was no card. It sounds like I should be using generic MMC, so now I'm trying to change my boot script to use the generic mmc commands. However, none of them (aside from read/write) seems to return false just because there is no card. A workaround of course is to just try to read from it. Wouldn't it make sense for 'mmc dev N', or at least 'mmc rescan' to return failed if there's no card in slot N? Or is there a use case for setting the current MMC device to an empty slot? They both call mmc_init(), which returns UNUSABLE_ERR, but this is ignored. I would like them to return 1 when mmc_init() fails. Sound reasonable? Or is there already a better way to test whether an mmc slot is populated? Am I supposed to wait until the next merge window to submit such a patch for review? -Michael MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [u-boot][PATCH 0/2] igep00x0: updates for IGEP boards
Hello, This is a couple of patches to update the support for IGEP boards, please consider to adding. Thanks in advance, Enric Balletbo i Serra (2): igep00x0: enable the use of a plain text file igep00x0: change mpurate from 500 to auto include/configs/igep0020.h | 30 +- include/configs/igep0030.h | 30 +- 2 files changed, 34 insertions(+), 26 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [u-boot][PATCH 1/2] igep00x0: enable the use of a plain text file
Based on commit cf073e49bc3502be1b48a0e3faf0cde9edbb89db for beagleboard
Using the new env import command it is possible to use plain text files instead
of script-images. Plain text files are much easier to handle.
E.g. If your boot.scr contains the following:
---
setenv dvimode 1024x768-16@60
run loaduimage
run mmcboot
---
you could create a file named uEnv.txt and use that instead of boot.scr:
---
dvimode=1024x768-16@60
uenvcmd=run loaduimage; run mmcboot
---
The variable uenvcmd (if existent) will be executed (using run) after uEnv.txt
was loaded. If uenvcmd doesn't exist the default boot sequence will be started,
therefore you could just use
---
dvimode=1024x768-16@60
---
as uEnv.txt because loaduimage and mmcboot is part of the default boot sequence
Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
---
include/configs/igep0020.h | 28
include/configs/igep0030.h | 28
2 files changed, 32 insertions(+), 24 deletions(-)
diff --git a/include/configs/igep0020.h b/include/configs/igep0020.h
index 5af9bec..afd9077 100644
--- a/include/configs/igep0020.h
+++ b/include/configs/igep0020.h
@@ -163,9 +163,9 @@
omapdss.def_disp=${defaultdisplay} \
root=${nandroot} \
rootfstype=${nandrootfstype}\0 \
- loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0 \
- bootscript=echo Running bootscript from mmc ...; \
- source ${loadaddr}\0 \
+ loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0 \
+ importbootenv=echo Importing environment from mmc ...; \
+ env import -t $loadaddr $filesize\0 \
loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0 \
mmcboot=echo Booting from mmc ...; \
run mmcargs; \
@@ -177,15 +177,19 @@
#define CONFIG_BOOTCOMMAND \
if mmc rescan ${mmcdev}; then \
- if run loadbootscript; then \
- run bootscript; \
- else \
- if run loaduimage; then \
- run mmcboot; \
- else run nandboot; \
- fi; \
- fi; \
- else run nandboot; fi
+ echo SD/MMC found on device ${mmcdev}; \
+ if run loadbootenv; then \
+ run importbootenv; \
+ fi; \
+ if test -n $uenvcmd; then \
+ echo Running uenvcmd ...; \
+ run uenvcmd; \
+ fi; \
+ if run loaduimage; then \
+ run mmcboot; \
+ fi; \
+ fi; \
+ run nandboot; \
#define CONFIG_AUTO_COMPLETE 1
diff --git a/include/configs/igep0030.h b/include/configs/igep0030.h
index 92144af..cb7194e 100644
--- a/include/configs/igep0030.h
+++ b/include/configs/igep0030.h
@@ -161,9 +161,9 @@
omapdss.def_disp=${defaultdisplay} \
root=${nandroot} \
rootfstype=${nandrootfstype}\0 \
- loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0 \
- bootscript=echo Running bootscript from mmc ...; \
- source ${loadaddr}\0 \
+ loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0 \
+ importbootenv=echo Importing environment from mmc ...; \
+ env import -t $loadaddr $filesize\0 \
loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0 \
mmcboot=echo Booting from mmc ...; \
run mmcargs; \
@@ -175,15 +175,19 @@
#define CONFIG_BOOTCOMMAND \
if mmc rescan ${mmcdev}; then \
- if run loadbootscript; then \
- run bootscript; \
- else \
- if run loaduimage; then \
- run mmcboot; \
- else run nandboot; \
- fi; \
- fi; \
- else run nandboot; fi
+ echo SD/MMC found on device ${mmcdev}; \
+ if run loadbootenv; then \
+ run importbootenv; \
+ fi; \
+ if test -n $uenvcmd; then \
+ echo Running uenvcmd ...; \
+ run uenvcmd; \
+ fi; \
+ if run loaduimage; then \
+ run mmcboot; \
+ fi; \
+ fi; \
+ run nandboot; \
#define CONFIG_AUTO_COMPLETE 1
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [u-boot][PATCH 2/2] igep00x0: change mpurate from 500 to auto
This patch changes the default mpurate variable from 500 to auto on all IGEP boards, with this the default rate is autoselected. Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com --- include/configs/igep0020.h |2 +- include/configs/igep0030.h |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/configs/igep0020.h b/include/configs/igep0020.h index afd9077..5d3060c 100644 --- a/include/configs/igep0020.h +++ b/include/configs/igep0020.h @@ -138,7 +138,7 @@ loadaddr=0x8200\0 \ usbtty=cdc_acm\0 \ console=ttyS2,115200n8\0 \ - mpurate=500\0 \ + mpurate=auto\0 \ vram=12M\0 \ dvimode=1024x768MR-16@60\0 \ defaultdisplay=dvi\0 \ diff --git a/include/configs/igep0030.h b/include/configs/igep0030.h index cb7194e..85d5d00 100644 --- a/include/configs/igep0030.h +++ b/include/configs/igep0030.h @@ -136,7 +136,7 @@ loadaddr=0x8200\0 \ usbtty=cdc_acm\0 \ console=ttyS2,115200n8\0 \ - mpurate=500\0 \ + mpurate=auto\0 \ vram=12M\0 \ dvimode=1024x768MR-16@60\0 \ defaultdisplay=dvi\0 \ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
Hi Scott, On Wednesday, May 25, 2011, Scott McNutt smcn...@psyent.com wrote: Graeme Russ wrote: Hi Scott, On Wednesday, May 25, 2011, Scott McNutt smcn...@psyent.com wrote: Graeme Russ wrote: Hi Scott, On 25/05/11 22:36, Scott McNutt wrote: Graeme Russ wrote: OK, let's wind back - My original suggestion made no claim towards changing what the API is used for, or how it looks to those who use it (for all practical intents and purposes). I suggested: - Removing set_timer() and reset_timer() - Implement get_timer() as a platform independent function Why do you suggest removing set_timer() and reset_timer() ? Because if the timer API is done right, they are not needed To continue the wind back ... In several implementations, reset_timer() actually reloads or re-initializes the hardware timer. This has the effect of synchronizing get_timer() calls with subsequent interrupts. This prevents the early timeouts if the implementer chooses to use an interrupt rate less than 1 ms. So my original question was, how do we address this issue? We fix them dear Liza dear Liza ;) That is what this thread is trying to figure out I'm getting a bit frustrated here as I can see we're going in circles. So I'll just make a few statements a leave well enough alone. - I'm not convinced that reset_timer() and set_timer() should be removed simply because you state that if the timer API is done right, they are not needed. Sorry, I should have been more specific - get and reset break nested loops. Some implementations (mostly ARM) also do a silent reset in udelay(), which breaks loops containing udelay. - If an implementation can't use interrupts that occur less frequently than 1 msec to satisfy the prevailing use of get_timer(), without breaking existing capability, I consider the interface that is done right to be wrong. Sorry, I don't understand what you mean here I hope to get an implementation agreed upon that does not require interrupts at all, provided a tick counter with sufficiently long roll over time is available (longer than the maximum expected period between 'related' get_timer() calls, for example calls to get_timer() in a timeout testing while loop). This 'bare minimum' implementation can be optionally augmented with an ISR which kicks the timer calculation in the background (typically by just calling get_timer()) It really is quite simple in the end. Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] testing mmc slot w/ generic mmc
On Wednesday, May 25, 2011 10:11:21 Michael Jones wrote: Am I supposed to wait until the next merge window to submit such a patch for review? you post patches at any time. they only get merged (if new feature based) into the main tree during the merge window. but things need to be hashed out and reviewed before they can even be merged. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] I2C: OMAP: spurious i2c probe addresses
While running v2011.06-rc1, I noticed some new behavior on my OMAP3 i2c bus. I tracked it to commit 0e57968a215d1b, I2C: OMAP: detect more devices when probing an i2c bus. It detects more devices indeed, such as some that don't even exist. Even better than that, it detects different devices every time. It looks like just false positives, the existent devices seem to always be found among the ghost devices. Here's the behavior I see: -- # i2c probe Valid chip addresses: 05 18 30 49 50 51 5E 7A # i2c probe Valid chip addresses: 02 06 0B 18 1D 24 25 30 35 50 51 57 5D 6F 7C # i2c probe Valid chip addresses: 18 2E 30 33 35 50 51 62 6F # i2c probe Valid chip addresses: 18 1B 1F 2D 30 46 50 51 5C 5D # i2c probe Valid chip addresses: 0A 18 21 26 2B 30 32 50 51 60 66 69 6D 79 # i2c probe Valid chip addresses: 08 09 18 1B 30 50 51 5E 6C Here's what it looks like after reverting the commit: -- # i2c probe Valid chip addresses: 18 30 50 51 # i2c probe Valid chip addresses: 18 30 50 51 # i2c probe Valid chip addresses: 18 30 50 51 # i2c probe Valid chip addresses: 18 30 50 51 -Michael MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
On 5/24/2011 10:17 PM, Wolfgang Denk wrote: Dear J. William Campbell, In message4ddc31eb.6040...@comcast.net you wrote: ... A tick is defined as the smallest increment of system time as measured by a computer system (seehttp://en.wikipedia.org/wiki/System_time): System time is measured by a system clock, which is typically implemented as a simple count of the number of ticks that have transpired since some arbitrary starting date, called the epoch. Unfortunately, this definition is obsolete, and has been for quite some Do you have any proof for such a claim? Hi Wolfgang, Well, yes, in fact the same reference you used. Note that the statement A tick is defined as the smallest increment of system time as measured by a computer system is NOT found in http://en.wikipedia.org/wiki/System_time. That page is defining system time, and what we are discussing is the definition of a tick. In fact, on the same wiki page you cite, there IS the statement Windows NT http://en.wikipedia.org/wiki/Windows_NT counts the number of 100-nanosecond ticks since 1 January 1601 00:00:00 UT as reckoned in the proleptic Gregorian calendar http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar, but returns the current time to the nearest millisecond. Here 100 nanosecond ticks clearly does not refer to any hardware 100 ns clock that exists on the pc. The 100 ns is a computed (dare I say virtual) tick value. The point here is that the definition of tick is yours, not wikipedia.org's. (Although we all are aware if it is wikipedia, it MUST be so). Further, http://en.wikipedia.org/wiki/Jiffy_%28time%29#Use_in_computing contains the statement In computing http://en.wikipedia.org/wiki/Computing, a jiffy is the duration of one tick of the system timer http://en.wikipedia.org/wiki/System_time interrupt http://en.wikipedia.org/wiki/Interrupt.. If a tick is the smallest increment of system time as measured by the computer system, the of the system timer interrupt part of the statement would be unnecessary. The fact it IS present indicates there are other kinds of ticks present in the universe. AFAIK, all timers tick, and the definition of the tick rate is 1/timer resolution. The concept of timer ticks and clock ticks has been around forever, and exists independent of System Time. For example, there may be a watchdog timer on a system that does not measure time at all, yet the watchdog still ticks. When you read a value from a timer that was not the system timer, what do you call the value you read? I would call it ticks, and I bet just about everybody else would too. The only reason I feel this point matters at all is that when one refers to a routine called get_ticks, it is not obvious to me which timer ticks are being referenced. You are saying that, by definition, it refers to the system clock. My feeling is that it is not obvious why that is so on a system that has many clocks. The name of the function or an argument to the function should, IMNSHO, specify which timer ticks are being returned. Best Regards, Bill Campbell years. When computers had a single timer, the above definition worked, but it no longer does, as many (most?) computers have several hardware timers. A tick today is the time increment of any particular timer of a computer system. So, when one writes a function called get_ticks on a PPC, does one mean read the decrementer, or does one read the RTC or does one read the TB register(s) A similar situation exists on the Blackfin BF531/2/3, that has a preformance counter, a real-time clock, and three programmable timers. Which tick do you want? For each u-boot Please re-read the definition. At least as far as U-Boot and Linux are concerned, there is only a single clock source used to implement the _system_time_. And I doubt that other OS do different. implementation, we can pick one timer as the master timer, but it may not be the one with the most rapid tick rate. It may be the one with the most USEFUL tick rate for get_timer. If you take the above definition at face value, only the fastest counter value has ticks, and all other counters time increments are not ticks. If they are not ticks, what are they? Clocks, timers? Best regards, Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Your Mailbox Has Exceeded It Storage Limit
Your Mailbox Has Exceeded It Storage Limit As Set By Your Administrator, And You Will Not Be Able To Receive New Mails Until You Re-Validate It. To Re-Validate - Click Here https://spreadsheets.google.com/spreadsheet/viewform?formkey=dFdGSDZyR2JkUDI3dng5TXJKbVBWQmc6MQ : System Administrator. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
Dear Graeme Russ,
In message banlktikm3lpynzcknp64kjeq5v+te7y...@mail.gmail.com you wrote:
I hope to get an implementation agreed upon that does not require
interrupts at all, provided a tick counter with sufficiently long roll
over time is available (longer than the maximum expected period
between 'related' get_timer() calls, for example calls to get_timer()
in a timeout testing while loop). This 'bare minimum' implementation
can be optionally augmented with an ISR which kicks the timer
calculation in the background (typically by just calling get_timer())
It really is quite simple in the end.
The length of this thread shows that it is not as simple as you want
to make us believe.
If all you have in mind are timeouts, then we don't need get_timer()
at all. We can implement all types of timeout where we wait for some
eent to happen using udelay() alone.
Need a 10 second timeout? Here we go:
int cnt = 0;
int limit = 10 * 1000;
while (!condition) {
usleep(1000); /* wait 1 millisec */
if (++cnt limit)
break;
}
if (cnt limit)
error(timeout);
get_timer() comes into play only if we want to calculate a time
difference, for example if we want to run some code where we don't
know how long it runs, and later come back and check if a certain
amount of time has passed.
When we don't know how long this code runs, we also cannot know (and
espeically not in advance) wether or not this time will be longer or
not than the rollover time of the tick counter.
Your plan to require that get_timer() gets called often enough to
prevent or detect tick counter overflows is putting things on their
head. It should be the opposite: The implementation of get_timer()
should be such that it becomes independent from such low level
details.
I have stated this before: I consider any design that requires
get_timer() to be called often enough broken.
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
Well, the way I see it, logic is only a way of being ignorant by num-
bers. - Terry Pratchett, _Small Gods_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
Dear J. William Campbell, In message 4ddd3354.8030...@comcast.net you wrote: A tick is defined as the smallest increment of system time as measured by a computer system (seehttp://en.wikipedia.org/wiki/System_time): System time is measured by a system clock, which is typically implemented as a simple count of the number of ticks that have transpired since some arbitrary starting date, called the epoch. Unfortunately, this definition is obsolete, and has been for quite some Do you have any proof for such a claim? Hi Wolfgang, Well, yes, in fact the same reference you used. Note that the statement A tick is defined as the smallest increment of system time as measured by a computer system is NOT found in http://en.wikipedia.org/wiki/System_time. That page is defining system I derived this from http://en.wikipedia.org/wiki/Tick_%28disambiguation%29: Tick, the smallest increment of system time as measured by a computer system the current time to the nearest millisecond. Here 100 nanosecond ticks clearly does not refer to any hardware 100 ns clock that exists on the Above definition nowhere requres that the tick must be a hardware clock. pc. The 100 ns is a computed (dare I say virtual) tick value. The point here is that the definition of tick is yours, not wikipedia.org's. Not quite. But while I do now want to claim authorship for words I just copied pasted, I think the definition is still a good one. Let's say it's the definition I want to see used to this discussion here :-) http://en.wikipedia.org/wiki/Interrupt.. If a tick is the smallest increment of system time as measured by the computer system, the of the system timer interrupt part of the statement would be unnecessary. The fact it IS present indicates there are other kinds of ticks present in the universe. I disagree here. AFAIK, all timers tick, and the definition of the tick rate is 1/timer resolution. The concept of timer ticks and clock ticks has been around forever, and exists independent of System Time. For example, there may be a watchdog timer on a system that does not measure time at all, yet the watchdog still ticks. When you read a value from a timer that was not the system timer, what do you call the value you read? I would call it ticks, and I bet just about everybody else would too. I have no reason to argument about this. But we don't care about any timers that may be present or even in use for one pourpose or anothe rin the system. All we care about her ein this discussion is a single time, and a single timer, and a single tick: the one that represents the system time. The only reason I feel this point matters at all is that when one refers to a routine called get_ticks, it is not obvious to me which timer ticks are being referenced. You are saying that, by definition, it refers to the system clock. My feeling is that it is not obvious why that is so on a system that has many clocks. The name of the function or an argument to the function should, IMNSHO, specify which timer ticks are being returned. THe reason is simply that it is the only clock that is being used anywhere in U-Boot. We have a only one system time, or clock. 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 mean, I . . . think to understand you, I just don't know what you are saying ...- Terry Pratchett, _Soul Music_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Patch] MPC83XX: Fix PCI express clock setup
On a 8308 based board it was found that the PEX_GLK_RATIO register (programmed in arch/powerpc/cpu/mpc83xx/pcie.c) was getting set to 0, This was tracked to the fact that the pci express clock frequency was not being assigned to the pciexp1_clk entry in the global data structure in file arch/powerpc/cpu/mpc83xx/speed.c. Fix this and a similiar issue in 'do_clocks' command. Signed-off-by: Bill Cook c...@isgchips.com --- This also points to another problem. The description of the PEX_CLK_RATIO for the various SOCs in question (I checked the RMs for 8308, 8315, and 8378) shows a different maximum freqency for the PCIe core. So the divider in the equation on line 271 should reflect these differences. This seems to be the only mention of a maximum core frequency though, so I hesitate to patch pcie.c without feedback from Freescale. As I'm not a PCI expert, I would rather someone at Freescale look at this and provide appropriate patches. Also, if the max PCIe core frequency on the 8308 is really 125MHz, shouldn't the SCCR PCIEXPCM field of the SCCR be programmed with a 2 instead of 1, this is given by the definition of CONFIG_SYS_SCCR_PCIEXP1CM in the board config file. arch/powerpc/cpu/mpc83xx/speed.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/cpu/mpc83xx/speed.c b/arch/powerpc/cpu/mpc83xx/speed.c index 5e616dd..86d2e18 100644 --- a/arch/powerpc/cpu/mpc83xx/speed.c +++ b/arch/powerpc/cpu/mpc83xx/speed.c @@ -481,7 +481,8 @@ int get_clocks(void) gd-qe_clk = qe_clk; gd-brg_clk = brg_clk; #endif -#if defined(CONFIG_MPC837x) +#if defined(CONFIG_MPC8308) || defined(CONFIG_MPC831x) || \ + defined(CONFIG_MPC837x) gd-pciexp1_clk = pciexp1_clk; gd-pciexp2_clk = pciexp2_clk; #endif @@ -541,7 +542,8 @@ int do_clocks (cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[]) #if defined(CONFIG_MPC834x) printf( USB MPH: %-4s MHz\n, strmhz(buf, gd-usbmph_clk)); #endif -#if defined(CONFIG_MPC837x) +#if defined(CONFIG_MPC8308) || defined(CONFIG_MPC831x) || \ + defined(CONFIG_MPC837x) printf( PCIEXP1: %-4s MHz\n, strmhz(buf, gd-pciexp1_clk)); printf( PCIEXP2: %-4s MHz\n, strmhz(buf, gd-pciexp2_clk)); #endif -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] apology
Hello Friends. There are few patches I need to review, few I need to accept and apply and send pull request. Due to my personal reasons I an unable to do so in time. I will be active on the mailing list from 1st June onwards. Meanwhile I have limited access :-( I am very sorry about this, I express my apology. For any urgent issues, I request Albert to do the needful. Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
On 5/25/2011 12:46 PM, Wolfgang Denk wrote:
Dear Graeme Russ,
In messagebanlktikm3lpynzcknp64kjeq5v+te7y...@mail.gmail.com you wrote:
I hope to get an implementation agreed upon that does not require
interrupts at all, provided a tick counter with sufficiently long roll
over time is available (longer than the maximum expected period
between 'related' get_timer() calls, for example calls to get_timer()
in a timeout testing while loop). This 'bare minimum' implementation
can be optionally augmented with an ISR which kicks the timer
calculation in the background (typically by just calling get_timer())
It really is quite simple in the end.
The length of this thread shows that it is not as simple as you want
to make us believe.
If all you have in mind are timeouts, then we don't need get_timer()
at all. We can implement all types of timeout where we wait for some
eent to happen using udelay() alone.
Need a 10 second timeout? Here we go:
int cnt = 0;
int limit = 10 * 1000;
while (!condition) {
usleep(1000); /* wait 1 millisec */
if (++cnt limit)
break;
}
if (cnt limit)
error(timeout);
get_timer() comes into play only if we want to calculate a time
difference, for example if we want to run some code where we don't
know how long it runs, and later come back and check if a certain
amount of time has passed.
When we don't know how long this code runs, we also cannot know (and
espeically not in advance) wether or not this time will be longer or
not than the rollover time of the tick counter.
Your plan to require that get_timer() gets called often enough to
prevent or detect tick counter overflows is putting things on their
head. It should be the opposite: The implementation of get_timer()
should be such that it becomes independent from such low level
details.
HI all,
We also cannot know if this code disables interrupts. If it does,
the existing PPC design is broken. If interrupts are disabled during the
entire code being executed, the elapsed run time will be 0. You can say
that disabling interrupts in the code is not allowed. Fine, then that
becomes a constraint on the code. Calling get_timer explicitly often
enough is also a constraint on the code. One constraint is acceptable to
you, the other is not. Ok, that's fine too. If the interrupt routine
calls get_timer, then get_timer is called often enough and everything
works the same as it presently does on PPC, It is not different than
requiring the interrupt routine to be executed often enough. The two
methods are functionally identical. The only problems arise on systems
that don't support interrupts and don't have any timers with enough bits
available to meet the 4294967 seconds maximum interval requirement.
Those systems will be broken no matter what we do, as we have all agreed.
Right now, almost all ARM cases are broken, because they have short
timers and don't use interrupts. In some cases, there are actual bugs
involved. We can make these cases less broken than they now are with a
common get_timer approach as outlined previously. However, we cannot fix
them to the standard Wolfgang is stating here, to be not broken. So,
back to what I was asking before, is the improvement worth the effort if
the result is still broken?
Best Regards,
Bill Campbell
I have stated this before: I consider any design that requires
get_timer() to be called often enough broken.
Best regards,
Wolfgang Denk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] apology
Hi Prafulla, Le 25/05/2011 22:11, Prafulla Wadaskar a écrit : Hello Friends. There are few patches I need to review, few I need to accept and apply and send pull request. Due to my personal reasons I an unable to do so in time. I will be active on the mailing list from 1st June onwards. Meanwhile I have limited access :-( I am very sorry about this, I express my apology. For any urgent issues, I request Albert to do the needful. Will do. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
Dear J. William Campbell, In message 4ddd6930.2080...@comcast.net you wrote: methods are functionally identical. The only problems arise on systems that don't support interrupts and don't have any timers with enough bits available to meet the 4294967 seconds maximum interval requirement. Where exactly is this requirement coming from? Right now, almost all ARM cases are broken, because they have short timers and don't use interrupts. In some cases, there are actual bugs involved. We can make these cases less broken than they now are with a common get_timer approach as outlined previously. However, we cannot fix We could also make them use interrupts for this type of timer service? How do these systems implement system time in other environments, say in Linux? Or in Barebox? 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 Human beings were created by water to transport it uphill. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
On 25/05/11 23:38, Wolfgang Denk wrote: Dear Graeme Russ, In message banlktimhtqynwgvwr6w8knosv4u_tzs...@mail.gmail.com you wrote: And what about platforms that do not support interrupts? Are you mandating that get_timer() MUST always be supported by a timer updated by an ISR? No, not at all. And I already answered this. For example on PPC, just reading the timebase would be perfectly sufficient, and simpler and more reliable than the current interrupt based approach. I assume by 'timebase' you mean the 64-bit tick counter. If so, that is _exactly_ what I am suggesting we do (and what does already happen on ARM). The big change is, the prescaler is common code rather than haven dozens (some of them broken) implementations Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
Dear Graeme Russ, In message 4ddd7066.4000...@gmail.com you wrote: No, not at all. And I already answered this. For example on PPC, just reading the timebase would be perfectly sufficient, and simpler and more reliable than the current interrupt based approach. I assume by 'timebase' you mean the 64-bit tick counter. If so, that is By timebase I mean the timebase register, implemented as two 32 bit registers tbu and tbl, holding the upper and the lower 32 bits of the free-running 64 bit counter, respective. _exactly_ what I am suggesting we do (and what does already happen on ARM). I don't think so. 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 ...this does not mean that some of us should not want, in a rather dispassionate sort of way, to put a bullet through csh's head. - Larry Wall in 1992aug6.221512.5...@netlabs.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
Hi Wolfgang On Thu, May 26, 2011 at 7:16 AM, Wolfgang Denk w...@denx.de wrote: Dear Graeme Russ, In message 4ddd7066.4000...@gmail.com you wrote: No, not at all. And I already answered this. For example on PPC, just reading the timebase would be perfectly sufficient, and simpler and more reliable than the current interrupt based approach. I assume by 'timebase' you mean the 64-bit tick counter. If so, that is By timebase I mean the timebase register, implemented as two 32 bit registers tbu and tbl, holding the upper and the lower 32 bits of the free-running 64 bit counter, respective. And remember, not all platforms have this implementation. The AMD sc520 for example has a microsecond register which counts 0-999 that ticks a 16-bit millisecond register and resets to zero. And the millisecond register latches the value of the microsecond register and resets (the millisecond register) back to zero. The thing is, this can all be abstracted away via get_tick() which (provided it is called every 65 seconds or so) can maintain a software version of the timebase register. So, every 65 seconds, the prescaler needs to be kicked. Now, if all we want to use get_timer() for is to monitor a timeout (which I think might be every single use in U-Boot to date) then the while (get_timer(start) timeout) loop will work. If get_timer() is needed to measure time between two arbitrary events (which I 100% agree it should be able to do) then the prescaler will need to be kicked (typically by an interrupt) _exactly_ what I am suggesting we do (and what does already happen on ARM). I don't think so. On closer inspection, some do, some don't. All ARMv7 (OMAP, S5P, Tegra2) do. at91 is odd - It looks like it uses interrupts, but get_timer() and udelay() both end up calling get_timer_raw() (with udelay only having millisecond resolution it seems). Some others can be configured to increment the timer using an interrupt. ARM is, quite frankly, a complete mess - It has a mass of *_timer_masked() functions which the core timer functions are 'wafer thin' wrapper around, udelay() silently resets the timebase trashing get_timer() loops etc. So let's wind back and distill the approach I am suggesting: 1) A common prescaler function in /lib/ - It's purpose is to maintain a 1ms resolution timer (if the platform cannot otherwise do so)[1] The prescaler utilises a platform provided get_ticks()[2] 2) A get_ticks() function provided by the platform - This function must return an unsigned counter which wraps from all 1's to all 0's - It DOES NOT have to be initialised to zero at system start. get_ticks() hides the low-level tick counter implementation - The sc520 example above is a classic example, so is your PPC tbu/tbl example. 3) [Optional]An ISR which calls the prescaler[3] Now there is an optimisation if your tick counter has a 1ms resolution and is not small (i.e. 64-bits) - The prescaler is defined weak, so in the platform code, re-implement the prescaler to simply copy the tick counter to the timer variable. And what are the specific implementation types (in decending order of preference)? I think: 1) A 64-bit micro-second tick counter[5] - No interrupts needed - Can be used by udelay() and get_timer() trivially 2) A 64-bit sub-micro-second tick counter - Interrupts most likely undeeded unless the tick frequency is insanely high - Can be used by udelay() and get_timer() trivially 3) A 64-bit milli-second tick counter - No interrupts needed - No prescaler needed - Can be used by get_timer() trivially - udelay() needs another tick source (if available) or be reduced to millisecond resolution 4) A 32-bit milli-second tick counter - No prescaler needed[6] - Max 'glitch free' duration is ~50 days - ISR needed to kick prescaler if events longer than 50 days need to be timed - Can be used by get_timer() trivially - udelay() needs another tick source (if available) or be reduced to millisecond resolution 5) A 24-bit milli-second tick counter - No prescaler needed[6] - Max 'glitch free' duration is ~4.5 hours - ISR needed to kick prescaler if events longer than 4.5 hours need to be timed - Can be used by get_timer() trivially - udelay() needs another tick source (if available) or be reduced to millisecond resolution 6) A 32-bit micro-second tick counter - No prescaler needed[6] - Max 'glitch free' duration is 71 minutes - ISR needed to kick prescaler if events longer than 71 minutes need to be timed - Can be used by get_timer() trivially - udelay() needs another tick source (if available) or be reduced to millisecond resolution Any implementation which does not fit withing the above is going to require an ISR to kick the prescaler in order to support timing of 'long events' (i.e. not just
Re: [U-Boot] [RFC] Review of U-Boot timer API
On 5/25/2011 4:13 PM, Graeme Russ wrote: Hi Wolfgang On Thu, May 26, 2011 at 7:16 AM, Wolfgang Denkw...@denx.de wrote: Dear Graeme Russ, In message4ddd7066.4000...@gmail.com you wrote: No, not at all. And I already answered this. For example on PPC, just reading the timebase would be perfectly sufficient, and simpler and more reliable than the current interrupt based approach. I assume by 'timebase' you mean the 64-bit tick counter. If so, that is By timebase I mean the timebase register, implemented as two 32 bit registers tbu and tbl, holding the upper and the lower 32 bits of the free-running 64 bit counter, respective. And remember, not all platforms have this implementation. The AMD sc520 for example has a microsecond register which counts 0-999 that ticks a 16-bit millisecond register and resets to zero. And the millisecond register latches the value of the microsecond register and resets (the millisecond register) back to zero. The thing is, this can all be abstracted away via get_tick() which (provided it is called every 65 seconds or so) can maintain a software version of the timebase register. So, every 65 seconds, the prescaler needs to be kicked. Now, if all we want to use get_timer() for is to monitor a timeout (which I think might be every single use in U-Boot to date) then the while (get_timer(start) timeout) loop will work. If get_timer() is needed to measure time between two arbitrary events (which I 100% agree it should be able to do) then the prescaler will need to be kicked (typically by an interrupt) _exactly_ what I am suggesting we do (and what does already happen on ARM). I don't think so. Hi All, Just to be clear, while ARMv7 has a 64 bit performance counter, it is not presently used by get_time. This is a change we want to make correct? On closer inspection, some do, some don't. All ARMv7 (OMAP, S5P, Tegra2) do. at91 is odd - It looks like it uses interrupts, but get_timer() and udelay() both end up calling get_timer_raw() (with udelay only having millisecond resolution it seems). I am not sure why you say at91 appears to use interrupts. There is a comment in arch/arm/cpu/arm930t/at91/timer.c that says timer without interrupts (line 73). There is the same comment in arch/arm/cpu/arm930t/at91rm9200/timer.c Nothing in either routine refers to interrupts, so I would say the timer doesn't use them. I could be wrong of course. Some others can be configured to increment the timer using an interrupt. ARM is, quite frankly, a complete mess - It has a mass of *_timer_masked() functions which the core timer functions are 'wafer thin' wrapper around, udelay() silently resets the timebase trashing get_timer() loops etc. I sure agree with this last part. The only arm timer I found that clearly thought it could use interrupts was in arch/arm/cpu/ixp, and that was conditional, not mandatory. So let's wind back and distill the approach I am suggesting: 1) A common prescaler function in /lib/ - It's purpose is to maintain a 1ms resolution timer (if the platform cannot otherwise do so)[1] The prescaler utilises a platform provided get_ticks()[2] 2) A get_ticks() function provided by the platform - This function must return an unsigned counter which wraps from all 1's to all 0's - It DOES NOT have to be initialised to zero at system start. get_ticks() hides the low-level tick counter implementation - The sc520 example above is a classic example, so is your PPC tbu/tbl example. 3) [Optional]An ISR which calls the prescaler[3] Now there is an optimisation if your tick counter has a 1ms resolution and is not small (i.e. 64-bits) - The prescaler is defined weak, so in the platform code, re-implement the prescaler to simply copy the tick counter to the timer variable. And what are the specific implementation types (in decending order of preference)? I think: 1) A 64-bit micro-second tick counter[5] - No interrupts needed - Can be used by udelay() and get_timer() trivially 2) A 64-bit sub-micro-second tick counter - Interrupts most likely undeeded unless the tick frequency is insanely high - Can be used by udelay() and get_timer() trivially 3) A 64-bit milli-second tick counter - No interrupts needed - No prescaler needed - Can be used by get_timer() trivially - udelay() needs another tick source (if available) or be reduced to millisecond resolution 4) A 32-bit milli-second tick counter - No prescaler needed[6] - Max 'glitch free' duration is ~50 days - ISR needed to kick prescaler if events longer than 50 days need to be timed - Can be used by get_timer() trivially - udelay() needs another tick source (if available) or be reduced to millisecond resolution 5) A 24-bit milli-second tick counter - No prescaler needed[6]
Re: [U-Boot] [RFC] Review of U-Boot timer API
On Thu, May 26, 2011 at 10:15 AM, J. William Campbell jwilliamcampb...@comcast.net wrote: On 5/25/2011 4:13 PM, Graeme Russ wrote: Hi Wolfgang On Thu, May 26, 2011 at 7:16 AM, Wolfgang Denkw...@denx.de wrote: Dear Graeme Russ, In message4ddd7066.4000...@gmail.com you wrote: [snip] _exactly_ what I am suggesting we do (and what does already happen on ARM). I don't think so. Hi All, Just to be clear, while ARMv7 has a 64 bit performance counter, it is not presently used by get_time. This is a change we want to make correct? If it is a constant time-base then yes, that would be preferable - But I doubt all ARM CPUs have these, so these need to be enabled on a case by case basis - get_ticks() can then use them trivially On closer inspection, some do, some don't. All ARMv7 (OMAP, S5P, Tegra2) do. at91 is odd - It looks like it uses interrupts, but get_timer() and udelay() both end up calling get_timer_raw() (with udelay only having millisecond resolution it seems). I am not sure why you say at91 appears to use interrupts. There is a comment in arch/arm/cpu/arm930t/at91/timer.c that says timer without interrupts (line 73). There is the same comment in arch/arm/cpu/arm930t/at91rm9200/timer.c Nothing in either routine refers to interrupts, so I would say the timer doesn't use them. I could be wrong of course. You are correct [snip] 6) A 32-bit micro-second tick counter - No prescaler needed[6] - Max 'glitch free' duration is 71 minutes - ISR needed to kick prescaler if events longer than 71 minutes need to be timed - Can be used by get_timer() trivially I think this should be Can be used by udelay and get_timer trivially Yes, you are again correct Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [HELP] How to load a big image file(40M)
Hi, folks I got a problem while loading big kernel image(size 40M) on ti pandaboard. - ## Booting kernel from Legacy Image at 8200 ... Image Name: Linux-2.6.39 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:44882584 Bytes = 42.8 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK kernel loaded at 0x80008000, end = 0x82ad5a98 images.os.start = 0x8200, images.os.end = 0x84acdad8 images.os.load = 0x80008000, load_end = 0x82ad5a98 Starting kernel ... Uncompressing Linux... done, booting the kernel. - Then nothing show, it seems overlap happened. But even I changed env loadaddr from 0x8200 to 0x8300, the kernel still can't boot. -- Booting from mmc0 ... ## Booting kernel from Legacy Image at 8300 ... Image Name: Linux-2.6.39 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:44882584 Bytes = 42.8 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK kernel loaded at 0x80008000, end = 0x82ad5a98 images.os.start = 0x8300, images.os.end = 0x85acdad8 images.os.load = 0x80008000, load_end = 0x82ad5a98 Starting kernel ... Uncompressing Linux... done, booting the kernel. -- Any ideas is welcome, thanks -- Regards, --Bob ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
Dear Graeme Russ, On closer inspection, some do, some don't. All ARMv7 (OMAP, S5P, Tegra2) do. at91 is odd - It looks like it uses interrupts, but get_timer() and udelay() both end up calling get_timer_raw() (with udelay only having millisecond resolution it seems). Some others can be configured to increment the timer using an interrupt. ARM is, quite frankly, a complete mess - It has a mass of *_timer_masked() functions which the core timer functions are 'wafer thin' wrapper around, udelay() silently resets the timebase trashing get_timer() loops etc. Please look at current master for at91. http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/arm926ejs/at91/timer.c;h=a0876879d3907af553d832bea187a062a22b9bd4;hb=5d1ee00b1fe1180503f6dfc10e87a6c6e74778f3 AT91 uses a 32 bit hardware register that by means of a prescaler is made to increment at a rate in the low megahertz range. This results in a wrap approximately every 1000 seconds. Actually this would be sufficient for all known uses of udelay() and get_timer() timeout loops. However, this hardware register is extended to 64 bits by software every time it is read (by detecting rollovers). Since a wrap of that 64 bit tick would occur after the earth has ended, it is simple to obtain milliseconds from it by doing a 64 bit division. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
On Thu, May 26, 2011 at 2:19 PM, Reinhard Meyer
u-b...@emk-elektronik.de wrote:
Dear Graeme Russ,
On closer inspection, some do, some don't. All ARMv7 (OMAP, S5P, Tegra2)
do. at91 is odd - It looks like it uses interrupts, but get_timer() and
udelay() both end up calling get_timer_raw() (with udelay only having
millisecond resolution it seems). Some others can be configured to
increment the timer using an interrupt. ARM is, quite frankly, a complete
mess - It has a mass of *_timer_masked() functions which the core timer
functions are 'wafer thin' wrapper around, udelay() silently resets
the timebase trashing get_timer() loops etc.
Please look at current master for at91.
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/arm926ejs/at91/timer.c;h=a0876879d3907af553d832bea187a062a22b9bd4;hb=5d1ee00b1fe1180503f6dfc10e87a6c6e74778f3
AT91 uses a 32 bit hardware register that by means of a prescaler is made
to increment at a rate in the low megahertz range.
Yes, I see that now
This results in a wrap approximately every 1000 seconds.
Actually this would be sufficient for all known uses of udelay() and
get_timer()
timeout loops. However, this hardware register is extended to 64 bits by
software
every time it is read (by detecting rollovers).
Which makes it 100% compatible with my proposed solution - The software
prescaler will trigger the 64-bit extension and rollover detection
Since a wrap of that 64 bit tick would occur after the earth has ended,
it is simple to obtain milliseconds from it by doing a 64 bit division.
Which would be done in the common prescaler in /lib/
Currently, most ARM specific utilisations of get_timer() enforce a reset
of the tick counter by calling reset_timer() - Subsequent calls to
get_timer() then assume a start time of zero. Provided the internal timer
rolls over currectly, the initial call of get_timer(0) will reset the ms
timer and remove and 'glitch' present due to not calling the 'extender'
function between 32-bit rollovers which makes the reset_timer() call
unneccessary - I believe at91 behaves correctly in this regard.
In any case, the underlying assumption made by the ARM timer interface
(call reset_timer() first always) is inherently broken as not all users
of the timer API do this - They assume a sane behaviour of:
start = get_timer(0);
elapsed_time = get_timer(start);
Add to this udelay() resetting the timer make the following very broken:
start = get_timer(0);
while(condition) {
udelay(delay);
}
elapsed_time = get_timer(start);
NOTE: In this case, if udelay() also calls the prescaler then no interrupt
triggered every 1000s would be required in the above example to get
correct elapsed_time even if the loop ran for several hours (provided
udelay() is called at least every 1000s
However, to allow timing of independent events with no intervening
udelay() or get_timer() calls, an 1000s interrupt to kick the prescaler is
all that is needed to make this particular implementation behave correctly.
Of course disabling interruts and not calling get_timer() or udelay() will
break the timer - But there is nothing that can be done about that)
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
On 5/25/2011 9:19 PM, Reinhard Meyer wrote: Dear Graeme Russ, On closer inspection, some do, some don't. All ARMv7 (OMAP, S5P, Tegra2) do. at91 is odd - It looks like it uses interrupts, but get_timer() and udelay() both end up calling get_timer_raw() (with udelay only having millisecond resolution it seems). Some others can be configured to increment the timer using an interrupt. ARM is, quite frankly, a complete mess - It has a mass of *_timer_masked() functions which the core timer functions are 'wafer thin' wrapper around, udelay() silently resets the timebase trashing get_timer() loops etc. Please look at current master for at91. http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/arm926ejs/at91/timer.c;h=a0876879d3907af553d832bea187a062a22b9bd4;hb=5d1ee00b1fe1180503f6dfc10e87a6c6e74778f3 AT91 uses a 32 bit hardware register that by means of a prescaler is made to increment at a rate in the low megahertz range. This results in a wrap approximately every 1000 seconds. Actually this would be sufficient for all known uses of udelay() and get_timer() Hi All Yes, you are correct. It would be sufficient for all known uses of udelay and get_timer(). However, Wolfgang has indicated a strong desire that the performance of the new API work properly over the full 32 bit range of the millisecond delay time. That has been the basic issue for some time here. timeout loops. However, this hardware register is extended to 64 bits by software every time it is read (by detecting rollovers). Yes, but this extension ONLY happens if get_ticks is called via udelay or get_timer. It doesn't happen if you are sitting at the command prompt or off executing a downloaded stand alone program. You might ask who cares, and I would answer that Wolfgang cares, at least to some level. If the timer overflow triggered an interrupt, we could call get_ticks to update the extended time inside the interrupt routine. But, as far as I know, it doesn't. There are some other ARM processors that have a 32 bit clock derived from a 32 kHz crystal, The will work much as you example does up to 134217 seconds, in fact much longer than your AT91 example does. However, that doesn't touch the 4294967 seconds that the PPC can manage. Without interrupts, the 32 bit (or smaller) counters will NEVER get to the PPC standard if their tick rate exceeds 1 msec. It may be that we need a lower standard, perhaps saying 1000 seconds is enough. But that is not my decision to make. Since a wrap of that 64 bit tick would occur after the earth has ended, it is simple to obtain milliseconds from it by doing a 64 bit division. True, but moot because of the above. Best Regards, Bill Campbell Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
On 5/25/2011 9:40 PM, Graeme Russ wrote:
On Thu, May 26, 2011 at 2:19 PM, Reinhard Meyer
u-b...@emk-elektronik.de wrote:
Dear Graeme Russ,
On closer inspection, some do, some don't. All ARMv7 (OMAP, S5P, Tegra2)
do. at91 is odd - It looks like it uses interrupts, but get_timer() and
udelay() both end up calling get_timer_raw() (with udelay only having
millisecond resolution it seems). Some others can be configured to
increment the timer using an interrupt. ARM is, quite frankly, a complete
mess - It has a mass of *_timer_masked() functions which the core timer
functions are 'wafer thin' wrapper around, udelay() silently resets
the timebase trashing get_timer() loops etc.
Please look at current master for at91.
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/arm926ejs/at91/timer.c;h=a0876879d3907af553d832bea187a062a22b9bd4;hb=5d1ee00b1fe1180503f6dfc10e87a6c6e74778f3
AT91 uses a 32 bit hardware register that by means of a prescaler is made
to increment at a rate in the low megahertz range.
Yes, I see that now
This results in a wrap approximately every 1000 seconds.
Actually this would be sufficient for all known uses of udelay() and
get_timer()
timeout loops. However, this hardware register is extended to 64 bits by
software
every time it is read (by detecting rollovers).
Which makes it 100% compatible with my proposed solution - The software
prescaler will trigger the 64-bit extension and rollover detection
Since a wrap of that 64 bit tick would occur after the earth has ended,
it is simple to obtain milliseconds from it by doing a 64 bit division.
Which would be done in the common prescaler in /lib/
Currently, most ARM specific utilisations of get_timer() enforce a reset
of the tick counter by calling reset_timer() - Subsequent calls to
get_timer() then assume a start time of zero. Provided the internal timer
rolls over currectly, the initial call of get_timer(0) will reset the ms
timer and remove and 'glitch' present due to not calling the 'extender'
function between 32-bit rollovers which makes the reset_timer() call
unneccessary - I believe at91 behaves correctly in this regard.
In any case, the underlying assumption made by the ARM timer interface
(call reset_timer() first always) is inherently broken as not all users
of the timer API do this - They assume a sane behaviour of:
start = get_timer(0);
elapsed_time = get_timer(start);
Add to this udelay() resetting the timer make the following very broken:
start = get_timer(0);
while(condition) {
udelay(delay);
}
elapsed_time = get_timer(start);
NOTE: In this case, if udelay() also calls the prescaler then no interrupt
triggered every 1000s would be required in the above example to get
correct elapsed_time even if the loop ran for several hours (provided
udelay() is called at least every 1000s
However, to allow timing of independent events with no intervening
udelay() or get_timer() calls, an 1000s interrupt to kick the prescaler is
all that is needed to make this particular implementation behave correctly.
Hi All,
True, if the processor supports timer interrupts. The problem is
that the existing u-boots in many cases do not. I think that is really
the crux of the problem. So what are we going to do? I am open to ideas
here.
Best Regards,
Bill Campbell
Of course disabling interruts and not calling get_timer() or udelay() will
break the timer - But there is nothing that can be done about that)
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
Dear J. William Campbell, In message 4f2e.8070...@comcast.net you wrote: True, if the processor supports timer interrupts. The problem is that the existing u-boots in many cases do not. I think that is really the crux of the problem. So what are we going to do? I am open to ideas here. Which of the processors we're discussing here does not support timer interrupts? If there is any, how is the Linux system time implemented on this processor? 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 When properly administered, vacations do not diminish productivity: for every week you're away and get nothing done, there's another when your boss is away and you get twice as much done. -- Daniel B. Luten ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/2] ARMV7: Add support for Samsung SMDKV310 Board
Dear Chander Kashyap, On 25 May 2011 15:02, Chander Kashyap chander.kash...@linaro.org wrote: SMDKV310 board is based on Samsung S5PV310 SOC. This SOC is very much similar to S5PC210. Signed-off-by: Chander Kashyap chander.kash...@linaro.org Signed-off-by: Tushar Behera tushar.beh...@linaro.org --- Changes for v2: - Coding Style Cleanup - Removed unwanted macros from board config file. - Ethernet controllor configuration is done using gpio structures. - MMC Controllor gpio configuration corrected. - Added MAINTAINERS entry. - Removed unwanted code from mem_setup.S. Changes for v3: - Comment style fixed - Added New macro in board config file. Changes for v4: - Fixed line with more than 80 characters in board config file MAINTAINERS | 4 + board/samsung/smdkv310/Makefile | 46 +++ board/samsung/smdkv310/lowlevel_init.S | 470 board/samsung/smdkv310/mem_setup.S | 365 + board/samsung/smdkv310/smdkv310.c | 136 + boards.cfg | 1 + include/configs/smdkv310.h | 169 7 files changed, 1191 insertions(+), 0 deletions(-) create mode 100644 board/samsung/smdkv310/Makefile create mode 100644 board/samsung/smdkv310/lowlevel_init.S create mode 100644 board/samsung/smdkv310/mem_setup.S create mode 100644 board/samsung/smdkv310/smdkv310.c create mode 100644 include/configs/smdkv310.h applied to u-boot-samsung Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/2] ARMV7: MMC SPL Boot support for SMDKV310 board
Dear Chander Kashyap, On 25 May 2011 15:02, Chander Kashyap chander.kash...@linaro.org wrote: Added MMC SPL boot support for SMDKV310. This framework design is based on nand_spl support. Signed-off-by: Chander Kashyap chander.kash...@linaro.org --- Changes for v3: - spl file renamed to u-boot-mmc-spl.bin - spl directory renamed to mmc_spl - comments added in mkv310_image.c file Changes for v5: - Compilation warning mmc_boot.c: In function 'board_init_r': mmc_boot.c:51: warning: 'noreturn' function does return fixed. Makefile | 11 ++ mmc_spl/board/samsung/smdkv310/Makefile | 105 ++ mmc_spl/board/samsung/smdkv310/mmc_boot.c | 85 ++ .../board/samsung/smdkv310/tools/mkv310_image.c | 116 mmc_spl/board/samsung/smdkv310/u-boot.lds | 86 +++ 5 files changed, 403 insertions(+), 0 deletions(-) create mode 100644 mmc_spl/board/samsung/smdkv310/Makefile create mode 100644 mmc_spl/board/samsung/smdkv310/mmc_boot.c create mode 100644 mmc_spl/board/samsung/smdkv310/tools/mkv310_image.c create mode 100644 mmc_spl/board/samsung/smdkv310/u-boot.lds applied to u-boot-samsung Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-samsung/master
Dear Albert Aribaud,
The following changes since commit 0cecc52c233e5f607f826a4e5c97f92c7a7d6dc4:
Merge branch 'master' of git://git.denx.de/u-boot-arm into next (2011-05-23
17:47:29 +0900)
are available in the git repository at:
git://git.denx.de/u-boot-samsung master
Chander Kashyap (4):
S5P: GPIO Macro Values Corrected.
S5P:SROM config code moved to s5p-common directory
ARMV7: Add support for Samsung SMDKV310 Board
ARMV7: MMC SPL Boot support for SMDKV310 board
David Müller (ELSOFT AG) (4):
SMDK2410: activate ARM relocation feature
SMDK2410: remove unneeded config.mk
SMDK2410: use the CFI driver (and remove the old one)
SMDK2410: various cleanup/code style fixes
Dirk Behme (1):
MMC S5P: Fix typo
Jaehoon Chung (1):
S5P: add set_mmc_clk for external clock control
Minkyu Kang (2):
S5PC2XX: Support the cpu revision
S5PC2XX: clock: support pwm clock for evt1 (cpu revision 1)
seedshope (1):
Add _end for the end of u-boot image for SMDK6400
MAINTAINERS|4 +
Makefile | 11 +
arch/arm/cpu/armv7/s5p-common/Makefile |3 +-
arch/arm/cpu/armv7/s5p-common/cpu_info.c |2 +
arch/arm/cpu/armv7/{s5pc1xx = s5p-common}/sromc.c | 22 +-
arch/arm/cpu/armv7/s5pc1xx/Makefile|1 -
arch/arm/cpu/armv7/s5pc1xx/clock.c |5 +
arch/arm/cpu/armv7/s5pc2xx/clock.c | 76 +++-
arch/arm/include/asm/arch-s5pc1xx/clk.h|1 +
arch/arm/include/asm/arch-s5pc1xx/gpio.h |4 +-
arch/arm/include/asm/arch-s5pc1xx/mmc.h|1 +
.../include/asm/arch-s5pc1xx/{smc.h = sromc.h}|8 +-
arch/arm/include/asm/arch-s5pc2xx/clk.h|1 +
arch/arm/include/asm/arch-s5pc2xx/cpu.h| 12 +-
arch/arm/include/asm/arch-s5pc2xx/gpio.h |7 +-
arch/arm/include/asm/arch-s5pc2xx/mmc.h|1 +
arch/arm/include/asm/arch-s5pc2xx/sromc.h | 51 +++
board/samsung/smdk2410/Makefile|2 +-
board/samsung/smdk2410/config.mk | 25 -
board/samsung/smdk2410/flash.c | 433 --
board/samsung/smdk2410/smdk2410.c | 73 ++--
board/samsung/smdkc100/smdkc100.c |4 +-
board/samsung/smdkv310/Makefile| 46 ++
board/samsung/smdkv310/lowlevel_init.S | 470
board/samsung/smdkv310/mem_setup.S | 365 +++
board/samsung/smdkv310/smdkv310.c | 136 ++
boards.cfg |1 +
drivers/mmc/s5p_mmc.c |6 +-
include/configs/smdk2410.h | 181 +---
include/configs/smdkv310.h | 169 +++
mmc_spl/board/samsung/smdkv310/Makefile| 105 +
mmc_spl/board/samsung/smdkv310/mmc_boot.c | 85
.../board/samsung/smdkv310/tools/mkv310_image.c| 116 +
mmc_spl/board/samsung/smdkv310/u-boot.lds | 86
nand_spl/board/samsung/smdk6400/u-boot.lds |2 +
35 files changed, 1921 insertions(+), 594 deletions(-)
rename arch/arm/cpu/armv7/{s5pc1xx = s5p-common}/sromc.c (68%)
rename arch/arm/include/asm/arch-s5pc1xx/{smc.h = sromc.h} (92%)
create mode 100644 arch/arm/include/asm/arch-s5pc2xx/sromc.h
delete mode 100644 board/samsung/smdk2410/config.mk
delete mode 100644 board/samsung/smdk2410/flash.c
create mode 100644 board/samsung/smdkv310/Makefile
create mode 100644 board/samsung/smdkv310/lowlevel_init.S
create mode 100644 board/samsung/smdkv310/mem_setup.S
create mode 100644 board/samsung/smdkv310/smdkv310.c
create mode 100644 include/configs/smdkv310.h
create mode 100644 mmc_spl/board/samsung/smdkv310/Makefile
create mode 100644 mmc_spl/board/samsung/smdkv310/mmc_boot.c
create mode 100644 mmc_spl/board/samsung/smdkv310/tools/mkv310_image.c
create mode 100644 mmc_spl/board/samsung/smdkv310/u-boot.lds
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
On Thu, May 26, 2011 at 3:16 PM, Wolfgang Denk w...@denx.de wrote:
Dear J. William Campbell,
In message 4f2e.8070...@comcast.net you wrote:
True, if the processor supports timer interrupts. The problem is
that the existing u-boots in many cases do not. I think that is really
the crux of the problem. So what are we going to do? I am open to ideas
here.
Which of the processors we're discussing here does not support timer
interrupts? If there is any, how is the Linux system time implemented
on this processor?
Well, they all support timer interrupts - It's just that that support
is not supported in U-Boot (yet)
I think we can still rationalise the timer API as suggested which, as
a minimum will:
- Not diminish current functionality for any platform
- Will dramatically reduce the current amount of code duplication
- Improve functionality on some platforms
- Simplify the whole API
and then start banging on arch maintainers heads to implement the trivial
ISR to kick the prescaler:
void timer_isr(void *unused)
{
prescaler();
}
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-samsung/master
Hi Minkyu, Le 26/05/2011 07:22, Minkyu Kang a écrit : Dear Albert Aribaud, Please make sure the 'at free dot fr' address of mine is not used any more -- there are good chances I won't see U-Boot mail on it anyway. The following changes since commit 0cecc52c233e5f607f826a4e5c97f92c7a7d6dc4: Merge branch 'master' of git://git.denx.de/u-boot-arm into next (2011-05-23 17:47:29 +0900) are available in the git repository at: git://git.denx.de/u-boot-samsung master Rather than a merge, could you please do a rebase (onto f14a522a (Beagleboard: fixed typo in typecast) as indicated in http://www.denx.de/wiki/view/U-Boot/CustodianGitTrees#BEFORE_Requesting_a_Pull)? In addition with making the commit tree simpler, it will ensure that the since commit mentioned in your request is actually one that exists in the pulling repo. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
Le 26/05/2011 07:25, Graeme Russ a écrit :
I think we can still rationalise the timer API as suggested which, as
a minimum will:
- Not diminish current functionality for any platform
- Will dramatically reduce the current amount of code duplication
- Improve functionality on some platforms
- Simplify the whole API
and then start banging on arch maintainers heads to implement the trivial
ISR to kick the prescaler:
I personally am in favor of cooperation rather than coercion, so please,
ask before banging on heads. :)
void timer_isr(void *unused)
{
prescaler();
}
Regards,
Graeme
Seems like we're asymptotically getting to some kind of agreement. For
the sake of clarity, could someone summarize what the expected API would
be, so that I save my scalp and start looking as the order in which
changes should be done on ARM?
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
