Re: [U-Boot] [PATCH] nvme: add more cache flushes

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

Re: [U-Boot] [PATCH 1/3] spl: ram: Do not memcpy() identical buffers

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:

Re: [U-Boot] [PATCH] libfdt: Initialize the stack variable

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 <tien.fong.c...@intel.com> Report Coverity log: The code uses a variable that has not been initialized, l

Re: [U-Boot] [PATCH] libfdt: Initialize the stack variable

that just initializing the variable to 0 is a "Bad Idea(tm)". 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 alr

Re: [U-Boot] [PATCH 2/2] arm: config: enforce -fno-pic for SPL and normal U-Boot

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 ;

Re: [U-Boot] [PATCH v2] NS16550: buffer reads

On 10/24/2011 3:22 PM, Graeme Russ wrote: Hi Wolfgang, On Tue, Oct 25, 2011 at 8:59 AM, Wolfgang Denkw...@denx.de wrote: Dear Graeme Russ, In message4ea5cd39.2070...@gmail.com you wrote: Assume we have a simple device with a small Rx FIFO - say, 8 bytes only. Guess what the chances are

Re: [U-Boot] [RFC] Timer API (again!)

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 and

Re: [U-Boot] [PATCH v2] ARM926ejs: Add routines to invalidate D-Cache

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 correct. If the buffer that

Re: [U-Boot] i.MX51: FEC: Cache coherency problem?

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

Re: [U-Boot] i.MX51: FEC: Cache coherency problem?

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 type write-back (as opposed to write-thru). From

Re: [U-Boot] i.MX51: FEC: Cache coherency problem?

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 and mapping

Re: [U-Boot] i.MX51: FEC: Cache coherency problem?

On 7/19/2011 11:14 AM, Anton Staaf wrote: On Tue, Jul 19, 2011 at 7:36 AM, J. William Campbell jwilliamcampb...@comcast.net 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 sending packets / starting external memory

Re: [U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite

On 7/15/2011 12:17 AM, Wolfgang Denk wrote: Dear J. William Campbell, In message4e1f8127.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 you refer to. Could you point me to one, because

Re: [U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite

On 7/15/2011 11:34 AM, Wolfgang Denk wrote: Dear J. William Campbell, In message4e208227.6010...@comcast.net you wrote: If the I2C protocol must be available before interrupts are available, then udelay must be used. In the above examples, there are some loops in i2c and spi

Re: [U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite

On 7/14/2011 12:41 PM, Wolfgang Denk wrote: Dear J. William Campbell, In message4e1cf2e0.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 resolution) . I think you had That would IMHO

Re: [U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite

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

Re: [U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite

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 period of

Re: [U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite

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. Remove all *masked() and *reset() functions

Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details

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, In messagebanlktinwvy9b4qzelnawf7mkt9z1zem...@mail.gmail.com you wrote: I

Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details

On 5/26/2011 9:33 PM, Graeme Russ wrote: Hi Bill, snip 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

Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details

On 5/27/2011 12:28 AM, Wolfgang Denk wrote: Dear J. William Campbell, In message4ddefdbc.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 already shown, you do not need them in general. We

Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details

On 5/27/2011 12:33 AM, Wolfgang Denk wrote: Dear J. William Campbell, In message4ddf2072.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 counter wrap time, which it essentially always

Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details

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 messagebanlktinwvy9b4qzelnawf7mkt9z1zem...@mail.gmail.com you wrote: I think we will need to define get_timer() weak - Nios will have to override the default implementation

Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details

On 5/27/2011 6:07 AM, Scott McNutt wrote: Graeme Russ wrote: Hi Wolfgang On Friday, May 27, 2011, Wolfgang Denk w...@denx.de wrote: Dear Graeme Russ, In message banlktik2sum4sm8aljcrcmz+kcmgwge...@mail.gmail.com you wrote: Besides, Nios can return an increment of 10 (presumably ms)

Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details

On 5/26/2011 11:54 PM, Graeme Russ wrote: On Fri, May 27, 2011 at 4:33 PM, J. William Campbell jwilliamcampb...@comcast.net wrote: On 5/26/2011 9:33 PM, Graeme Russ wrote: Hi Bill, snip [massive snip] OK, you have my ears pricked - Can you give me code samples for: - get_ticks

Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details

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 w...@denx.de wrote: Dear Graeme Russ, In message banlktik2sum4sm8aljcrcmz+kcmgwge...@mail.gmail.com you

Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details

On 5/27/2011 8:13 AM, Simon Glass wrote: On Fri, May 27, 2011 at 8:00 AM, J. William Campbell jwilliamcampb...@comcast.net 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 you have

Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details

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

Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details

On 5/26/2011 12:16 PM, Wolfgang Denk wrote: Dear J. William Campbell, In message4ddea165.9010...@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 may wrap at some final count that is not all ones

Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details

On 5/26/2011 1:27 PM, Wolfgang Denk wrote: Dear J. William Campbell, In message4ddeafe0.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 systems that have only a 32 bit or less timer register

Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details

On 5/26/2011 4:28 PM, Graeme Russ wrote: Hi Bill, On Fri, May 27, 2011 at 2:56 AM, J. William Campbell jwilliamcampb...@comcast.net wrote: 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

Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details

On 5/26/2011 6:51 PM, Graeme Russ wrote: Hi Bill, On Fri, May 27, 2011 at 11:26 AM, J. William Campbell jwilliamcampb...@comcast.net 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 your platform code) when carting

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

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

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

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

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

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

On 5/24/2011 7:12 AM, Wolfgang Denk wrote: Dear Albert ARIBAUD, In message4ddb4c1c.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 -- asuming it

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

On 5/24/2011 9:51 AM, Graeme Russ wrote: On 25/05/11 00:19, Wolfgang Denk wrote: = snip 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

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

On 5/24/2011 12:19 PM, Wolfgang Denk wrote: Dear Graeme Russ, In message4ddbe22d.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 currently stands can as

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

On 5/24/2011 5:17 PM, Graeme Russ wrote: On Wed, May 25, 2011 at 5:19 AM, Wolfgang Denkw...@denx.de wrote: Dear Graeme Russ, In message4ddbe22d.6050...@gmail.com you wrote: Why must get_timer() be used to perform meaningful time measurement? Excellent question! It was never intended to be

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

/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 jwilliamcampb...@comcast.net wrote: On 5/22/2011 6:42 PM, Graeme Russ wrote: OK, so in summary, we can

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

On 5/23/2011 6:19 AM, Wolfgang Denk wrote: Dear Graeme Russ, In message4dda5334.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

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

On 5/23/2011 6:19 AM, Wolfgang Denk wrote: Dear Graeme Russ, snip 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

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

On 5/23/2011 12:33 PM, Wolfgang Denk wrote: Dear J. William Campbell, In message4ddaa705.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 PPC timer system is that it uses

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

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 wrote: On 23/05/11 22:19, Scott McNutt wrote: Hi Graeme, Graeme Russ wrote: There is no need to use

Re: [U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

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/23/2011 6:12 AM, Scott McNutt wrote: Dear Graeme, Graeme Russ wrote: On 23/05

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

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 what I

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

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 than I expected!

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

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

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

On 5/22/2011 5:02 PM, Graeme Russ wrote: Dear Reinhard, On Sun, May 22, 2011 at 6:15 PM, Reinhard Meyer u-b...@emk-elektronik.de 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

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

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

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

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 less with just shifts and multiplies) can convert a free

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

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() --- - Useful for profiling - A 32-bit microsecond counter

Re: [U-Boot] [RFC] ARM timing code refactoring

On 1/24/2011 5:02 AM, Wolfgang Denk wrote: Dear Albert ARIBAUD, In message4d3d2942.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-bit range,

Re: [U-Boot] [RFC] ARM timing code refactoring

On 1/23/2011 2:57 PM, Wolfgang Denk wrote: Dear Reinhard Meyer, In message4d3c9bfc.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. Exactly that wrap

Re: [U-Boot] TIMER cleanup RFC, was: [PATCH 4/4] arm920t/at91/timer: replace bss variables by gd

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 a

Re: [U-Boot] TIMER cleanup RFC, was: [PATCH 4/4] arm920t/at91/timer: replace bss variables by gd

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 at a rate of at least 1 MHz. As someone pointed out a while ago, even

Re: [U-Boot] Timer implementations

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 underlying timer wrapped around (most probable

Re: [U-Boot] [PATCH v2] mmc: omap: timeout counter fix

On 10/25/2010 11:01 PM, Reinhard Meyer wrote: Dear Wolfgang Denk, Dear Reinhard Meyer, In message4cc66a67.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 end = 0x10, the while

Re: [U-Boot] Timer implementations

On 10/26/2010 6:33 AM, Reinhard Meyer wrote: Dear Wolfgang Denk, Then the define CONFIG_SYS_HZ should not be in everyboard.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 IMPORTANT

Re: [U-Boot] [PATCH 2/2] ARM: fix relocation support for onenand device.

On 10/23/2010 1:56 PM, Wolfgang Denk wrote: Dear Enric Balletbo i Serra, In message1287479602-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 Balletbo i

Re: [U-Boot] [PATCH] mpc83xx: Add -fpic relocation support

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, and it

Re: [U-Boot] [PATCH] futile c relocation attempt

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

Re: [U-Boot] ARM relocation, question to Heiko

On 10/4/2010 3:13 AM, Wolfgang Denk wrote: Dear Albert ARIBAUD, In message4ca999ee.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 relocation

Re: [U-Boot] ARM relocation, question to Heiko

On 10/4/2010 10:06 AM, Wolfgang Denk wrote: Dear J. William Campbell, In message4ca9f294.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 you intend to use any

Re: [U-Boot] [RFC] [PATCH] arm: arm926ejs: use ELF relocations

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 ARIBAUDalbert.arib...@free.fr wrote: Le 05/10/2010 00:22, Graeme Russ a écrit : On Tue, Oct 5, 2010 at 9:01 AM, Albert Aribaudalbert.arib...@free.fr wrote:

Re: [U-Boot] [RFC] [PATCH] arm: arm926ejs: use ELF relocations

On 10/4/2010 10:30 PM, Wolfgang Denk wrote: Dear Albert ARIBAUD, In message4caa50aa.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 more.

Re: [U-Boot] ARM relocation, question to Heiko

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 relocation to

Re: [U-Boot] ARM relocation, question to Heiko

On 10/3/2010 11:29 AM, Wolfgang Denk wrote: Dear Reinhard Meyer, In message4ca79896.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 fixup his

Re: [U-Boot] ARM relocation, question to Heiko

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

Re: [U-Boot] [PATCH] flash.h: pull in common.h for types

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 should be

Re: [U-Boot] Relocation size penalty calculation

Graeme Russ wrote: On Thu, Oct 15, 2009 at 3:45 AM, J. William Campbell jwilliamcampb...@comcast.net wrote: Joakim Tjernlund wrote: megasnip 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

Re: [U-Boot] Relocation size penalty calculation

Joakim Tjernlund wrote: J. William Campbell jwilliamcampb...@comcast.net wrote on 14/10/2009 01:48:52: Joakim Tjernlund wrote: Graeme Russ graeme.r...@gmail.com wrote on 13/10/2009 22:06:56: On Tue, Oct 13, 2009 at 10:53 PM, Joakim Tjernlund joakim.tjernl...@transmode.se

Re: [U-Boot] Relocation size penalty calculation

Joakim Tjernlund wrote: Graeme Russ graeme.r...@gmail.com wrote on 14/10/2009 13:48:27: On Wed, Oct 14, 2009 at 6:25 PM, Joakim Tjernlund joakim.tjernl...@transmode.se wrote: J. William Campbell jwilliamcampb...@comcast.net wrote on 14/10/2009 01:48:52: Joakim Tjernlund

Re: [U-Boot] Relocation size penalty calculation

Joakim Tjernlund wrote: J. William Campbell jwilliamcampb...@comcast.net wrote on 14/10/2009 17:35:44: Joakim Tjernlund wrote: J. William Campbell jwilliamcampb...@comcast.net wrote on 14/10/2009 01:48:52: Joakim Tjernlund wrote: Graeme Russ graeme.r

Re: [U-Boot] Relocation size penalty calculation

Joakim Tjernlund wrote: Graeme Russ graeme.r...@gmail.com wrote on 13/10/2009 13:21:05: On Sun, Oct 11, 2009 at 11:51 PM, Joakim Tjernlund joakim.tjernl...@transmode.se wrote: Graeme Russ graeme.r...@gmail.com wrote on 11/10/2009 12:47:19: [Massive Snip :)] So, all

Re: [U-Boot] Relocation size penalty calculation

Joakim Tjernlund wrote: Graeme Russ graeme.r...@gmail.com wrote on 13/10/2009 22:06:56: On Tue, Oct 13, 2009 at 10:53 PM, Joakim Tjernlund joakim.tjernl...@transmode.se wrote: Graeme Russ graeme.r...@gmail.com wrote on 13/10/2009 13:21:05: On Sun, Oct 11, 2009 at 11:51 PM,

Re: [U-Boot] Relocation size penalty calculation

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, formatted):

Re: [U-Boot] Relocation size penalty calculation

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

Re: [U-Boot] Relocation size penalty calculation

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 how much of a size penalty I am incurring by using gcc -fpic / ld -pic on my

Re: [U-Boot] Relocation size penalty calculation

Graeme Russ wrote: On Fri, Oct 9, 2009 at 2:58 AM, J. William Campbell jwilliamcampb...@comcast.net 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. Here are the results

Re: [U-Boot] Relocation size penalty calculation

Joakim Tjernlund wrote: On Fri, Oct 9, 2009 at 9:27 AM, J. William Campbell jwilliamcampb...@comcast.net wrote: Graeme Russ wrote: On Fri, Oct 9, 2009 at 2:58 AM, J. William Campbell jwilliamcampb...@comcast.net wrote: Graeme Russ wrote: Out

Re: [U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0

Joakim Tjernlund wrote: On Wed, Oct 7, 2009 at 5:55 PM, Wolfgang Denk w...@denx.de wrote: Dear Graeme Russ, In message d66caabb0910061824s4165d33bu5d5213f6783c0...@mail.gmail.com you wrote: I think that even the -mrelocatable / .fixup method may not be needed at all. -pie /

Re: [U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0

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 keeps U-Boot's

Re: [U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0

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, In message 1254843932.24664.2083.ca...@localhost.localdomain you wrote: I

Re: [U-Boot] [PATCH] CFI Driver: Reset watchdog timer after each flash operation

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

Re: [U-Boot] Virtual addresses, u-boot, and the MMU

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 discussion here: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/50705 ... In quick summary

Re: [U-Boot] Virtual addresses, u-boot, and the MMU

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

Re: [U-Boot] Virtual addresses, u-boot, and the MMU

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 address at which the flash is mapped. This discussion has