Re: [U-Boot] [RFC] Review of U-Boot timer API

Dear Albert ARIBAUD, > 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 >>

Re: [U-Boot] Please pull u-boot-samsung/master

Dear Albert ARIBAUD, On 26 May 2011 14:49, Albert ARIBAUD wrote: > 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. OK

Re: [U-Boot] [RFC] Review of U-Boot timer API

Hi Albert, On Thu, May 26, 2011 at 3:55 PM, Albert ARIBAUD wrote: > 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

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

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:

Re: [U-Boot] [RFC] Review of U-Boot timer API

On Thu, May 26, 2011 at 3:16 PM, Wolfgang Denk 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 >> th

[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)

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 wrote: > Added MMC SPL boot support for SMDKV310. This framework design is > based on nand_spl support. > > Signed-off-by: Chander Kashyap > --- > Changes for v3: >        - spl file renamed to u-boot-mmc-spl.bin >        - spl director

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 wrote: > SMDKV310 board is based on Samsung S5PV310 SOC. This SOC is very much > similar to S5PC210. > > Signed-off-by: Chander Kashyap > Signed-off-by: Tushar Behera > --- > Changes for v2: >        - Coding Style Cleanup >        - R

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 t

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 > 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 u

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 >> millisec

Re: [U-Boot] [RFC] Review of U-Boot timer API

On Thu, May 26, 2011 at 2: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 h

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 confi

[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 A

Re: [U-Boot] [RFC] Review of U-Boot timer API

On Thu, May 26, 2011 at 10:15 AM, J. William Campbell wrote: > On 5/25/2011 4:13 PM, Graeme Russ wrote: >> >> Hi Wolfgang >> >> On Thu, May 26, 2011 at 7:16 AM, Wolfgang Denk  wrote: >>> >>> Dear Graeme Russ, >>> >>> In message<4ddd7066.4000...@gmail.com>  you wrote: > [snip] _exactly_

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 Denk 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

Re: [U-Boot] [RFC] Review of U-Boot timer API

Hi Wolfgang On Thu, May 26, 2011 at 7:16 AM, Wolfgang Denk 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 >> >

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 'ti

Re: [U-Boot] [RFC] Review of U-Boot timer API

On 25/05/11 23:38, Wolfgang Denk wrote: > Dear Graeme Russ, > > In message 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. Fo

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 requirem

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 onwa

Re: [U-Boot] [RFC] Review of U-Boot timer API

On 5/25/2011 12:46 PM, Wolfgang Denk wrote: > Dear Graeme Russ, > > In message 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 perio

[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 ex

[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/powerp

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 t

Re: [U-Boot] [RFC] Review of U-Boot timer API

Dear Graeme Russ, In message 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 exam

[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 : System Administrato

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 message<4ddc31eb.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 mea

[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 eve

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 ou

Re: [U-Boot] [RFC] Review of U-Boot timer API

Hi Scott, On Wednesday, May 25, 2011, Scott McNutt wrote: > Graeme Russ wrote: > > Hi Scott, > > On Wednesday, May 25, 2011, Scott McNutt 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

[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 --- include/configs/igep0020.h |2 +- include/configs/igep0030.h |2 +- 2 files changed, 2 insertions(+), 2 deletions(-)

[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: ---

[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 +---

[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 re

Re: [U-Boot] [RFC] Review of U-Boot timer API

Graeme Russ wrote: > Hi Scott, > > On Wednesday, May 25, 2011, Scott McNutt 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

Re: [U-Boot] [RFC] Review of U-Boot timer API

Dear Graeme Russ, In message 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 p

Re: [U-Boot] [RFC] Review of U-Boot timer API

Hi Scott, On Wednesday, May 25, 2011, Scott McNutt 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 u

Re: [U-Boot] [RFC] Review of U-Boot timer API

On Wednesday, May 25, 2011, Wolfgang Denk 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

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 suggeste

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

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()

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 "

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 platf

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

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. implemente

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 implent

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

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 t

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 > curren

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

Re: [U-Boot] mpc5567

Dear cengiz.uen...@bergerelektronik.de, In message 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

[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

Re: [U-Boot] [RFC] Review of U-Boot timer API

On 25/05/11 18:08, Wolfgang Denk wrote: > Dear Graeme Russ, > > In message 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 thousa

Re: [U-Boot] [RFC] Review of U-Boot timer API

On 25/05/11 18:06, Wolfgang Denk wrote: > Dear Graeme Russ, > > In message 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

Re: [U-Boot] [RFC] Review of U-Boot timer API

Dear Graeme Russ, In message 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

Re: [U-Boot] [RFC] Review of U-Boot timer API

Dear Graeme Russ, In message 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

[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

[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