Hi All,
On 10/17/2019 12:12 AM, Patrick Wildt wrote:
On Thu, Oct 17, 2019 at 03:08:59PM +0800, Bin Meng wrote:
Hi Patrick,
On Thu, Oct 17, 2019 at 2:44 PM Patrick Wildt wrote:
On Thu, Oct 17, 2019 at 10:55:11AM +0800, Bin Meng wrote:
Hi Patrick,
On Wed, Oct 16, 2019 at 11:35 PM Patrick Wild
On 10/2/2010 3:17 AM, Joakim Tjernlund wrote:
Hello Reinhard,
Reinhard Meyer wrote:
Dear Albert ARIBAUD,
I try to understand how the relocation process could handle pointers (to
functions or other data) in const or data sections.
Your code cannot know what is data and what is a pointer that n
On 10/3/2010 1:58 AM, Albert ARIBAUD wrote:
> Le 03/10/2010 10:44, Graeme Russ a écrit :
>
>>> Bill just said that -pic (or, for ARM, -fPIC or -fPIE) was unnecessary
>>> for relocation. You seem to imply it actually is... In my experience,
>>> -fPIC and-fPIE do increase code by adding GOT relocat
On 10/3/2010 11:14 AM, Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message<4ca75bfb.5030...@comcast.net> you wrote:
>>>>> And I think there are more places of this type in u-boot...
>>>> Yes, maybe. But relocation as I did for
On 10/3/2010 11:29 AM, Wolfgang Denk wrote:
> Dear Reinhard Meyer,
>
> In message<4ca79896.2010...@emk-elektronik.de> you wrote:
>> I agree here. _If_ relocation, it should work without hand-adding
>> fixup stuff to all functions using initialized data with pointers.
>> Even Wolfgang forgot to f
On 10/4/2010 3:13 AM, Wolfgang Denk wrote:
> Dear Albert ARIBAUD,
>
> In message<4ca999ee.5030...@free.fr> you wrote:
>> Note however that linking for base address 0 is not mandatory for
>> achieving true position independence. What is required is that the code
>> which runs from power-up until
On 10/4/2010 10:06 AM, Wolfgang Denk wrote:
Dear "J. William Campbell",
In message<4ca9f294.8080...@comcast.net> you wrote:
Yes, I think Wolfgang is correct. This is not going to be easy to do in
general. To run anywhere, the code must be true Position Independent
code. If y
On 10/4/2010 5:16 PM, Albert ARIBAUD wrote:
> Le 05/10/2010 01:21, Graeme Russ a écrit :
>> On Tue, Oct 5, 2010 at 9:57 AM, Albert ARIBAUD
>> wrote:
>>> Le 05/10/2010 00:22, Graeme Russ a écrit :
On Tue, Oct 5, 2010 at 9:01 AM, Albert Aribaud
wrote:
>>> The output from MAKEALL is
On 10/4/2010 10:30 PM, Wolfgang Denk wrote:
> Dear Albert ARIBAUD,
>
> In message<4caa50aa.3000...@free.fr> you wrote:
>> Remember: this patch only applies to boards which boot from NOR FLASH!
>> You can test it on other types of boards (NAND-based, etc) for
>> regression testing, but nothing mo
On 10/6/2010 2:43 AM, Graeme Russ wrote:
> On 06/10/10 01:48, Reinhard Meyer wrote:
>> ---
>> arch/arm/cpu/arm926ejs/start.S |8 -
>> arch/arm/lib/board.c | 57
>> +++-
>> include/configs/top9000_9xe.h |1 +
>> 3 files changed, 63
I have followed the recent discussions about problems in the CFI
driver caused by the need to change the attributes of the address at
which the flash is mapped. This discussion has raised some questions in
my mind regarding the assumptions u-boot makes regarding the behavior of
the addres
Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message <4a9d5ef2.4030...@comcast.net> you wrote:
>
>> I have followed the recent discussions about problems in the CFI
>> driver caused by the need to change the attributes of the addres
Becky Bruce wrote:
>
> On Sep 2, 2009, at 2:59 AM, Wolfgang Denk wrote:
>
>> Dear "J. William Campbell",
>>
>> In message <4a9d99b1.1010...@comcast.net> you wrote:
>>>
>> ...
>>>> Becky then posted the summary of this discus
Mike Frysinger wrote:
> On Tuesday 17 November 2009 16:56:58 Wolfgang Denk wrote:
>
>> Scott Wood wrote:
>>
My question: is there a definitive position somewhere (for example
for the Linux kernel; I'm sure we don't have one for U-Boot [yet]),
whether system headers shoul
Mike Frysinger wrote:
> On Friday 02 October 2009 08:30:51 Wolfgang Denk wrote:
>
>> Ingo van Lil wrote:
>>
>>> The CFI driver does not reset the device's watchdog, so long-running
>>> flash operations will cause the watchdog timer to expire. A comment in
>>> flash_status_check() suggests t
Peter Tyser wrote:
> On Tue, 2009-10-06 at 19:51 +0200, Wolfgang Denk wrote:
>
>> Dear Peter Tyser,
>>
>> In message <1254843932.24664.2083.ca...@localhost.localdomain> you wrote:
>>
>>> I personally like the current implementation of putting the bss after
>>> the entire U-Boot image. It k
Peter Tyser wrote:
> On Tue, 2009-10-06 at 13:34 -0700, J. William Campbell wrote:
>
>> Peter Tyser wrote:
>>
>>> On Tue, 2009-10-06 at 19:51 +0200, Wolfgang Denk wrote:
>>>
>>>
>>>> Dear Peter Tyser,
>>>>
&g
Joakim Tjernlund wrote:
>> On Wed, Oct 7, 2009 at 5:55 PM, Wolfgang Denk wrote:
>>
>>> Dear Graeme Russ,
>>>
>>> In message
>>> you wrote:
>>>
I think that even the -mrelocatable / .fixup method may not be needed at
all. -pie / -pic used by themselves creates enough informa
Peter Tyser wrote:
> On Thu, 2009-10-08 at 22:54 +1100, Graeme Russ wrote:
>
>> Out of curiosity, I wanted to see just how much of a size penalty I am
>> incurring by using gcc -fpic / ld -pic on my x86 u-boot build. Here are
>> the results (fixed width font will help - its space, not tab, forma
Graeme Russ wrote:
> Out of curiosity, I wanted to see just how much of a size penalty I am
> incurring by using gcc -fpic / ld -pic on my x86 u-boot build. Here are
> the results (fixed width font will help - its space, not tab, formatted):
>
> Section non-reloc reloc
> ---
Peter Tyser wrote:
> On Thu, 2009-10-08 at 08:53 -0700, J. William Campbell wrote:
>
>> Peter Tyser wrote:
>>
>>> On Thu, 2009-10-08 at 22:54 +1100, Graeme Russ wrote:
>>>
>>>
>>>> Out of curiosity, I wanted to see just ho
Graeme Russ wrote:
> On Fri, Oct 9, 2009 at 2:58 AM, J. William Campbell
> wrote:
>
>> Graeme Russ wrote:
>>
>>> Out of curiosity, I wanted to see just how much of a size penalty I am
>>> incurring by using gcc -fpic / ld -pic on my x86 u-boot build
Joakim Tjernlund wrote:
>> On Fri, Oct 9, 2009 at 9:27 AM, J. William Campbell
>> wrote:
>>
>>> Graeme Russ wrote:
>>>
>>>> On Fri, Oct 9, 2009 at 2:58 AM, J. William Campbell
>>>> wrote:
>>>>
>>>>
Joakim Tjernlund wrote:
> Graeme Russ wrote on 13/10/2009 13:21:05:
>
>> On Sun, Oct 11, 2009 at 11:51 PM, Joakim Tjernlund
>> wrote:
>>
>>> Graeme Russ wrote on 11/10/2009 12:47:19:
>>>
>> [Massive Snip :)]
>>
>>
So, all that is left are .dynsym and .dynamic ...
Joakim Tjernlund wrote:
> Graeme Russ wrote on 13/10/2009 22:06:56:
>
>
>> On Tue, Oct 13, 2009 at 10:53 PM, Joakim Tjernlund
>> wrote:
>>
>>> Graeme Russ wrote on 13/10/2009 13:21:05:
>>>
On Sun, Oct 11, 2009 at 11:51 PM, Joakim Tjernlund
wrote:
> Gra
Joakim Tjernlund wrote:
> "J. William Campbell" wrote on 14/10/2009
> 01:48:52:
>
>> Joakim Tjernlund wrote:
>>
>>> Graeme Russ wrote on 13/10/2009 22:06:56:
>>>
>>>
>>>
>>>> On Tue, Oct 13, 2009
Joakim Tjernlund wrote:
> Graeme Russ wrote on 14/10/2009 13:48:27:
>
>> On Wed, Oct 14, 2009 at 6:25 PM, Joakim Tjernlund
>> wrote:
>>
>>> "J. William Campbell" wrote on 14/10/2009
>>> 01:48:52:
>>>
>>>>
Joakim Tjernlund wrote:
> "J. William Campbell" wrote on 14/10/2009
> 17:35:44:
>
>> Joakim Tjernlund wrote:
>>
>>> "J. William Campbell" wrote on 14/10/2009
>>> 01:48:52:
>>>
>>>
>>>> J
Graeme Russ wrote:
> On Thu, Oct 15, 2009 at 3:45 AM, J. William Campbell
> wrote:
>
>> Joakim Tjernlund wrote:
>>
>
> Apologies if this is getting way off-topic for a simple boot loader, but
> this is information I have gathered from far and wide over
On 1/23/2011 2:57 PM, Wolfgang Denk wrote:
> Dear Reinhard Meyer,
>
> In message<4d3c9bfc.1010...@emk-elektronik.de> you wrote:
get_timer() returns a monotonous upward counting time stamp with a
resolution of milliseconds. After reaching ULONG_MAX the timer wraps
around to 0.
>> Exa
On 1/24/2011 5:02 AM, Wolfgang Denk wrote:
> Dear Albert ARIBAUD,
>
> In message<4d3d2942.4060...@free.fr> you wrote:
>> That is assuming a 64-bit timebase, isn't it? for CPUs / SoCs that don't>
>> have such a timebase but only a 32-bit timer, the bogo_ms/jiffy would>
>> not go through the full 32
On 5/21/2011 5:06 PM, Graeme Russ wrote:
> On 22/05/11 01:33, J. William Campbell wrote:
>> On 5/21/2011 5:38 AM, Graeme Russ wrote:
>>> Hi All,
>>> 4. Implement microsecond API - get_usec_timer()
>>> ---
>>>
On 5/21/2011 9:26 PM, Reinhard Meyer wrote:
> Dear Graeme Russ,
>> Hi All,
>>
>> I've just had a good look through the timer API code with the view of
>> rationalising it and fixing up some of the inconsistencies. What I found
>> was a little scarier than I expected! Anyway, here is a write-up of w
On 5/21/2011 11:23 PM, Graeme Russ wrote:
> On 22/05/11 14:26, Reinhard Meyer wrote:
>> Dear Graeme Russ,
>>> Hi All,
>>>
>>> I've just had a good look through the timer API code with the view of
>>> rationalising it and fixing up some of the inconsistencies. What I found
>>> was a little scarier t
On 5/22/2011 1:15 AM, Reinhard Meyer wrote:
Dear J. William Campbell,
please demonstrate for me (and others), by a practical example,
how _any_ arithmetic (even less with just shifts and multiplies)
can convert a free running 3.576 MHz (wild example) free running
32 bit counter (maybe software
On 5/22/2011 5:02 PM, Graeme Russ wrote:
> Dear Reinhard,
>
> On Sun, May 22, 2011 at 6:15 PM, Reinhard Meyer
> wrote:
>> Dear J. William Campbell,
>>
>> please demonstrate for me (and others), by a practical example,
>> how _any_ arithmetic (even less wit
On 5/22/2011 6:42 PM, Graeme Russ wrote:
> OK, so in summary, we can (in theory) have:
> - A timer API in /lib/ with a single u32 get_timer(u32 base) function
> - A HAL with two functions
> - u32 get_raw_ticks()
> - u32 get_raw_tick_rate() which returns the tick rate in kHz (which
>
On 5/22/2011 8:26 PM, Reinhard Meyer wrote:
> Dear J. William Campbell,
>> On 5/22/2011 1:15 AM, Reinhard Meyer wrote:
>>> Dear J. William Campbell,
>>>
>>> please demonstrate for me (and others), by a practical example,
>>> how _any_ arithmetic (even
/oversight/questions that we can get, as this is a
change that will affect all architectures.
Le 23/05/2011 07:25, Graeme Russ a écrit :
On Mon, May 23, 2011 at 3:02 PM, J. William Campbell
wrote:
On 5/22/2011 6:42 PM, Graeme Russ wrote:
OK, so in summary, we can (in theory) have:
- A
On 5/23/2011 6:19 AM, Wolfgang Denk wrote:
Dear Graeme Russ,
In message<4dda5334.4060...@gmail.com> you wrote:
- A helper function in /lib/ u32 get_raw_ms() which uses get_raw_ticks()
and get_tick_rate() to correctly maintain the ms counter used by
get_timer() - This function can be
On 5/23/2011 6:19 AM, Wolfgang Denk wrote:
> Dear Graeme Russ,
> This is what PPC is doing. And I understand that Reinhard did the same
> in software for AT91.
Hi All,
My apologies for being a little (perhaps more than a little)
dense. As they say, "after further review", I think the key as
On 5/23/2011 12:33 PM, Wolfgang Denk wrote:
Dear "J. William Campbell",
In message<4ddaa705.1040...@comcast.net> you wrote:
My apologies for being a little (perhaps more than a little)
dense. As they say, "after further review", I think the key aspect of
the P
On 5/23/2011 1:10 PM, Graeme Russ wrote:
> On 24/05/11 04:29, Scott McNutt wrote:
>> Hi Bill,
>>
>> J. William Campbell wrote:
>>> On 5/23/2011 6:12 AM, Scott McNutt wrote:
>>>> Dear Graeme,
>>>>
>>>> Graeme Russ wr
On 5/23/2011 2:02 PM, Graeme Russ wrote:
> On 24/05/11 06:49, J. William Campbell wrote:
>> On 5/23/2011 1:10 PM, Graeme Russ wrote:
>>> On 24/05/11 04:29, Scott McNutt wrote:
>>>> Hi Bill,
>>>>
>>>> J. William Campbell wrote:
>>>
On 5/24/2011 7:12 AM, Wolfgang Denk wrote:
> Dear Albert ARIBAUD,
>
> In message<4ddb4c1c.7030...@aribaud.net> you wrote:
>> Not sure I still follow what the two options are -- a heads up is welcome.
>> However, I do like the simplicity in having a single time unit (ticks)
>> for the timer API --
On 5/23/2011 10:13 PM, Graeme Russ wrote:
> On Tue, May 24, 2011 at 7:02 AM, Graeme Russ wrote:
>
> [snip]
>> Well, we have no control over the argument in cfi driver (unless you plan
>> to put #ifdef NIOS all over the place)
>>
>> Maybe we could round up the parameter inside get_timer() itself?
>
On 5/24/2011 9:51 AM, Graeme Russ wrote:
> On 25/05/11 00:19, Wolfgang Denk wrote:
> =
Hi all,
I have a few of questions.
First, it seems that the get_timer interface is expected to work
properly only after relocation and only when bss is available. I say
this because the PP
On 5/24/2011 12:19 PM, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message<4ddbe22d.6050...@gmail.com> you wrote:
Why must get_timer() be used to perform "meaningful time measurement?"
>>> Excellent question! It was never intended to be used as such.
>> Because get_timer() as it currentl
On 5/24/2011 5:17 PM, Graeme Russ wrote:
> On Wed, May 25, 2011 at 5:19 AM, Wolfgang Denk wrote:
>> Dear Graeme Russ,
>>
>> In message<4ddbe22d.6050...@gmail.com> you wrote:
> Why must get_timer() be used to perform "meaningful time measurement?"
Excellent question! It was never intende
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):
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
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
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
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
On 5/26/2011 6:27 AM, Graeme Russ wrote:
> Hello Everyone,
>
> OK - Starting a new thread to discuss implementation details. This is a
> heads-up for arch/platform maintainers - Once this is a bit more stable, I
> will put it on the wiki
>
> Assumed Capabilities of the Platform
> - Has a 'tick co
On 5/26/2011 10:53 AM, Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message<4dde8639.3090...@comcast.net> you wrote:
>
>> I think it is the task of get_ticks to return the hardware tick counter
>> as an increasing counter, period. The counter
On 5/26/2011 12:16 PM, Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message<4ddea165.9010...@comcast.net> you wrote:
>>>> I think it is the task of get_ticks to return the hardware tick counter
>>>> as an increasing counter, perio
On 5/26/2011 1:27 PM, Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message<4ddeafe0.8060...@comcast.net> you wrote:
>> I certainly agree using 64 bits for all calculations is vast overkill.
>> In fact, I think using 64 bit calculations on syste
On 5/26/2011 4:28 PM, Graeme Russ wrote:
> Hi Bill,
>
> On Fri, May 27, 2011 at 2:56 AM, J. William Campbell
> wrote:
>> On 5/26/2011 6:27 AM, Graeme Russ wrote:
>>> Hello Everyone,
>>>
>>> OK - Starting a new thread to discuss implementation deta
On 5/26/2011 6:51 PM, Graeme Russ wrote:
> Hi Bill,
>
> On Fri, May 27, 2011 at 11:26 AM, J. William Campbell
> wrote:
>> On 5/26/2011 4:28 PM, Graeme Russ wrote:
>>> Why mess around with bit shifting (which you would then have to cludge
>>> into
>>>
On 5/26/2011 9:33 PM, Graeme Russ wrote:
> Hi Bill,
>
> get_ticks() does not care about the clock rate - It simply looks at the
> current value of the hardware tick counter and the value of the hardware
> tick counter the last time get_ticks() was called, calculates the difference
> and adds that
On 5/27/2011 12:28 AM, Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message<4ddefdbc.7050...@comcast.net> you wrote:
>> I really STRONGLY disagree with this statement. If you actually needed
>> 64 bit variables, fine use them. But as I have alre
On 5/27/2011 12:33 AM, Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message<4ddf2072.5090...@comcast.net> you wrote:
> ...
>> The problem is that the way we previously detected wrapping does not
>> work if the interrupt rate is == to the co
On 5/27/2011 12:35 AM, Graeme Russ wrote:
> Hi Wolfgang,
>
> On 27/05/11 17:13, Wolfgang Denk wrote:
>> Dear Graeme Russ,
>>
>> In message you wrote:
>>> I think we will need to define get_timer() weak - Nios will have to
>>> override the default implementation to cater for it's (Nios') limitation
On 5/27/2011 6:07 AM, Scott McNutt wrote:
> Graeme Russ wrote:
>> Hi Wolfgang
>>
>> On Friday, May 27, 2011, Wolfgang Denk wrote:
>>> Dear Graeme Russ,
>>>
>>> In message you
>>> wrote:
Besides, Nios can return an increment of 10 (presumably ms) between
two immediately consecutive call
On 5/26/2011 11:54 PM, Graeme Russ wrote:
> On Fri, May 27, 2011 at 4:33 PM, J. William Campbell
> wrote:
>> On 5/26/2011 9:33 PM, Graeme Russ wrote:
>>> Hi Bill,
>>>
>>
> [massive snip]
>
> OK, you have my ears pricked - Can you give me code sample
On 5/27/2011 8:44 AM, Scott McNutt wrote:
> J. William Campbell wrote:
>> On 5/27/2011 6:07 AM, Scott McNutt wrote:
>>> Graeme Russ wrote:
>>>> Hi Wolfgang
>>>>
>>>> On Friday, May 27, 2011, Wolfgang Denk wrote:
>>>>> Dear
On 5/27/2011 8:13 AM, Simon Glass wrote:
> On Fri, May 27, 2011 at 8:00 AM, J. William Campbell
> wrote:
> [snip]
>> Hi All,
>> A more precise statement of the problem is that all timer delays
>> may be shortened by the timer resolution. So this means that if yo
On 5/27/2011 10:53 PM, Graeme Russ wrote:
> Hi Bill,
>
> On 28/05/11 00:23, J. William Campbell wrote:
>> On 5/27/2011 12:35 AM, Graeme Russ wrote:
>>> Hi Wolfgang,
>>>
>>> On 27/05/11 17:13, Wolfgang Denk wrote:
>>>> Dear Graeme Russ,
>&g
city of the rest of u-boot to stick a 64 bit requirement on
timestamps used to determine if the boot delay is expired.
Best Regards,
J. William Campbell
> Best regards,
>
>
> Wolfgang Denk
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
On 7/12/2011 8:23 AM, Scott McNutt wrote:
> Dear Wolfgang
>
> Wolfgang Denk wrote:
>
>> What exactly is the reason that we cannot have better timer
>> resolutions in NIOS?
> You _can_ have better timer resolutions in Nios. However, there
> are legacy systems that implement timer(s) with a fixed per
On 7/12/2011 5:33 PM, Graeme Russ wrote:
> Hi Reinhard,
>
> On 13/07/11 02:08, Reinhard Meyer wrote:
>> Dear J. William Campbell, All
> [snip]
>
>> Lets just keep the current functions udelay(us) and u32 get_timer(), the
>> latter maybe without parameter
On 7/14/2011 12:41 PM, Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message<4e1cf2e0.1030...@comcast.net> you wrote:
>> Yes, this is true. However, the time_elapsed_since routine can do
>> this dynamically (i.e. add twice the timer resol
On 7/15/2011 12:17 AM, Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message<4e1f8127.8030...@comcast.net> you wrote:
>> I am pretty sure that is long enough for someone to notice. . I would be
>> interested in seeing an example of such code as y
On 7/15/2011 11:34 AM, Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message<4e208227.6010...@comcast.net> you wrote:
>> If the I2C protocol must be available before interrupts are
>> available, then udelay must be used. In the above exa
On 7/19/2011 2:05 AM, Albert ARIBAUD wrote:
> Le 19/07/2011 10:43, Aneesh V a écrit :
>
You would have to flush (before sending packets / starting external
memory-to-device DMA) and invalidate (before reading received packets /
after external device-to-memory DMA is done); using MMU
On 7/19/2011 11:14 AM, Anton Staaf wrote:
> On Tue, Jul 19, 2011 at 7:36 AM, J. William Campbell
> wrote:
>> On 7/19/2011 2:05 AM, Albert ARIBAUD wrote:
>>> Le 19/07/2011 10:43, Aneesh V a écrit :
>>>
>>>>>> You would have to flush (before send
On 7/20/2011 7:35 AM, Albert ARIBAUD wrote:
> Le 20/07/2011 16:01, J. William Campbell a écrit :
>> On 7/20/2011 6:02 AM, Albert ARIBAUD wrote:
>>> Le 19/07/2011 22:11, J. William Campbell a écrit :
>>>
>>>> If this is true, then it means that the cache is of
On 7/23/2011 6:04 AM, Albert ARIBAUD wrote:
> Le 21/07/2011 08:48, David Jander a écrit :
>
>>> However, it is still correct that copying from an non-cached area is
>>> slower than from cached areas, because of burst reads vs. individual
>>> reads. However, I doubt that the u-boot user can tell the
On 8/5/2011 4:51 AM, Aneesh V wrote:
> Hi Albert,
>
> On Friday 05 August 2011 04:33 PM, Albert ARIBAUD wrote:
>> Hi Aneesh,
>>
>> On 05/08/2011 12:47, Aneesh V wrote:
>>> Hi Eric,
>>>
>>> On Friday 05 August 2011 04:03 PM, Hong Xu wrote:
Hi Aneesh,
>>> [snip ..]
> IMHO, Hong's approach is
On 10/24/2011 3:22 PM, Graeme Russ wrote:
> Hi Wolfgang,
>
> On Tue, Oct 25, 2011 at 8:59 AM, Wolfgang Denk wrote:
>> Dear Graeme Russ,
>>
>> In message<4ea5cd39.2070...@gmail.com> you wrote:
Assume we have a simple device with a small Rx FIFO - say, 8 bytes
only. Guess what the chances
On 9/16/2011 4:53 AM, Graeme Russ wrote:
> Hi All,
>
> Well, here we are again, a Timer API discussion
>
> All things considered, I don't think the Linux approach is right for
U-Boot
> - It is designed to cater for way more use-cases than U-Boot will
ever need
> to deal with (time queues a
On 10/12/2010 11:30 PM, Albert ARIBAUD wrote:
> Le 12/10/2010 23:00, Joakim Tjernlund a écrit :
>
>> Yes, but the difference isn't really the arch. It is the -mrelocatable
>> flag that is the big difference.
> Not only: obviously, implementing GOT relocation is not done the same on
> both archs,
On 10/23/2010 1:56 PM, Wolfgang Denk wrote:
> Dear Enric Balletbo i Serra,
>
> In message<1287479602-21721-3-git-send-email-eballe...@iseebcn.com> you
> wrote:
>> We also have to relocate the onenand command table manually, otherwise
>> onenand command don't work.
>>
>> Signed-off-by: Enric Balle
On 10/25/2010 11:01 PM, Reinhard Meyer wrote:
> Dear Wolfgang Denk,
>> Dear Reinhard Meyer,
>>
>> In message<4cc66a67.4000...@emk-elektronik.de> you wrote:
It fails in case the timer wraps around.
Assume 32 bit counters, start time = 0xFFF0, delay = 0x20. It
will compute e
On 10/26/2010 6:33 AM, Reinhard Meyer wrote:
> Dear Wolfgang Denk,
>>> Then the define CONFIG_SYS_HZ should not be in every.h since that
>>> suggests that a board developer has some freedom there...
>> Agreed - there are historical reasons this has ever been changable at
>> all.
>>
>>> and MOST IMP
On 10/27/2010 11:02 PM, Reinhard Meyer wrote:
> Dear J. William Campbell,
>> Hi All,
>>
>> I am pretty sure the migration to 64 bits was caused by 1) people not
>> understanding that the timer operating on time DIFFERENCES would work
>> fine even if the unde
On 11/30/2010 1:14 AM, Reinhard Meyer wrote:
> Dear Wolfgang Denk,
>
> what we really need is only a 32 bit monotonous free running tick that
> increments
> at a rate of at least 1 MHz. As someone pointed out a while ago, even at 1GHz
> that would
> last for four seconds before it rolls over. But
On 11/30/2010 7:48 AM, Reinhard Meyer wrote:
> Dear J. William Campbell,
>> On 11/30/2010 1:14 AM, Reinhard Meyer wrote:
>>> Dear Wolfgang Denk,
>>>
>>> what we really need is only a 32 bit monotonous free running tick that
>>> increments
>>>
On 7/3/2017 8:12 PM, Peng Fan wrote:
-Original Message-
From: Tom Rini [mailto:tr...@konsulko.com]
Sent: Tuesday, July 04, 2017 10:47 AM
To: Peng Fan
Cc: Simon Glass ; Philipp Tomsich
; albert.u.b...@aribaud.net; u-
b...@lists.denx.de
Subject: Re: [U-Boot] [PATCH 2/2] arm: config: enfo
m)". If it is case 1 or 2, there should be a Coverity code
annotation comment added to that effect, and if it is case 3, it should
be fixed. Initializing this variable makes the binary larger to no
purpose unless there is a bug already.
Best Regards,
J. William Campbell
char *e
On 9/4/2017 8:41 PM, Chee, Tien Fong wrote:
On Rab, 2017-08-30 at 06:31 -0700, J. William Campbell wrote:
On 8/29/2017 10:15 PM, tien.fong.c...@intel.com wrote:
From: Tien Fong Chee
Report Coverity log:
The code uses a variable that has not
been initialized, leading to unpredictable
or
On 5/28/2019 4:19 AM, Tom Rini wrote:
On Tue, May 28, 2019 at 05:24:34AM +0200, Marek Vasut wrote:
On 5/28/19 5:04 AM, Tom Rini wrote:
On Tue, May 28, 2019 at 04:44:52AM +0200, Marek Vasut wrote:
On 5/28/19 4:42 AM, Tom Rini wrote:
On Tue, May 28, 2019 at 04:07:44AM +0200, Marek Vasut wrote:
93 matches
Mail list logo
