Re: [U-Boot] [PATCH v3] arm926ejs: timer: Replace bss variable by gdr
Dear Albert ARIBAUD, > However a general rework of ARM timer code is in order so that all SoCs > and CPUs share the same set of gd variables with the same names and the > same logic; and when we get that, this code shall move along. > > About this rework, as the saying goes... "Patches Welcome ©". :) There were several suggestions about that in the past (including from me) that involve rework everywhere HZ related timeouts are used. I still prefer a method as follows (because it does not need repeated mul/div calculations nor necessarily 64 bit arithmetic): u32 timeout = timeout_init(100); /* 100ms timeout */ do {...} while (!timed_out(timeout)); Internally it would be like: timeout_init(x): return fast_tick + (x * fast_tick_rate) / CONFIG_SYS_HZ; /* this might need 64 bit precision in some implementations */ time_out(x): return ((i32)(x - fast_tick)) < 0; If the tick were really high speed (and then 64 bits), fast_tick could be derived by shifting the tick some bits to the right. But, as long as we cannot agree on something, there will be no time spent to make patches... Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v4 patch 6/6] SMDK6400: Fix SMDK6400 SDRAM init
Dear seedshope, On 22 January 2011 00:34, seedshope wrote: > Since SDRAM init function have already change, So the SDRAM > initial function must be change. > > Signed-off-by: seedshope > --- > board/samsung/smdk6400/smdk6400.c | 10 +- > 1 files changed, 9 insertions(+), 1 deletions(-) > > diff --git a/board/samsung/smdk6400/smdk6400.c > b/board/samsung/smdk6400/smdk6400.c > index 35aa40b..1d03b7a 100644 > --- a/board/samsung/smdk6400/smdk6400.c > +++ b/board/samsung/smdk6400/smdk6400.c > @@ -78,10 +78,18 @@ int board_init(void) > return 0; > } > > -int dram_init(void) > +void dram_init_banksize(void) > { > + DECLARE_GLOBAL_DATA_PTR; Please remove it. > + > gd->bd->bi_dram[0].start = PHYS_SDRAM_1; > gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE; 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] [v4 patch 6/6] SMDK6400: Fix SMDK6400 SDRAM init
Hi seedshope, seedshope gmail.com> writes: > -int dram_init(void) > +void dram_init_banksize(void) > { > + DECLARE_GLOBAL_DATA_PTR; This declaration should be done on file scope, not in a function. > + > gd->bd->bi_dram[0].start = PHYS_SDRAM_1; > gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE; > +} > + Best regards, Thomas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] arm926ejs: timer: Replace bss variable by gdr
Am 22.01.2011 08:46, schrieb Albert ARIBAUD: > Le 22/01/2011 06:39, Alexander Holler a écrit : >> Hello, >> >> Am 21.01.2011 09:56, schrieb Heiko Schocher: >> >>> -static ulong timestamp; >>> -static ulong lastdec; >>> +DECLARE_GLOBAL_DATA_PTR; >>> + >>> +#define timestamp gd->tbl >>> +#define lastdec gd->lastinc >> >> I'm the only one who doesn't like such defines? They might be handy for >> quick fixes, but in regard to style and readablity I don't like them. >> When looking at teh code where they will used, you won't see the actual >> place where they are stored. And in more complex expression they might >> become dangerous to use because they hide the operator "->". > > I accept the patch because it un-breaks support for ARM cpus, and I > prefer a working fix to a perfect fix in this specific, transitional, > situation. My experience is that such quick fixes (or workarounds) usually manifests (because they become forgotten) and later on might even be copied to other places. ;) Anyway, I'll have to thank for that patch, because it fixes at least one of the problems I have while trying to chainload a 2010.12 from a 2010.12 on a kirkwood system. Regards, and again, thanks for the patch, even if I found it ugly, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Бог благословитl
миссис Azeeza Basara, родом из Катара. Мой муж покойный д-р Омар Джалал Basara. Он работе посольства Катара в Судане и Марокко в течение двенадцати лет. И ушел в отставку в нефтяной торговый до его смерти. Я решил не получить себе участие в любой брак после его смерти или получить ребенка вне моего семейного дома. Я страдал от рака матки в течение четырех лет после умер мой муж. Вместе с с нарушениями слуха в связи с лекарственной реакции. У нас не было детей, после восемнадцати лет в мирное брака. Недавно мой врач сказал мне, что моя жизнь не будет превышать трех месяцев, в связи с болезнью рака моя. У меня есть депозит в размере $ 7.6Musd в банк в Англии. И поэтому, я искренне хочет распространять фонда для менее привилегированных в вашей стране (бывшего Советского Союза). Я очень хочу, чтобы использовать его для гуманитарной деятельности. Я не ребенок, который унаследует эти деньги от меня. А родственники моего мужа была плохо для меня, поскольку моя болезнь моя, больных раком. Я ни хочет, ни банку заполучить мои деньги после моей смерти. Как только я получаю ваш ответ, я сообщу мой адвокат, чтобы помочь вам снять деньги из банка, который вы будете использовать в улучшение человечества в вашем регионе (стране). Пожалуйста, уверяют меня, что вы будете искренне помочь мне в этом. Я ожидает Вашего ответа в скором времени с этой электронной почтой (ab76...@hotmail.com) Azeeza Basara. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] A question in lowlevel_init.S
Hi, On 22/01/2011 08:39, Reinhard Meyer wrote: > I am not aware of any AT91SAM9xxx systems right now that uses low-level init, > it > would only make sense for those that boot directly from NOR, without > AT91BOOTSTRAP involved. cpu9260 (at91sam9260 / 9g20 based) is using low-level init as it boots from NOR and is not using at91bootstrap. Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] ARM timing code refactoring
Hi All, I am starting this thread to revive and, hopefully, come to a general agreement on how timers should be implemented and used in the ARM architecture, and get rid of current quick fixes. Let us start with Reinhard's proposal: > There were several suggestions about that in the past (including from > me) that involve rework everywhere HZ related timeouts are used. I > still prefer a method as follows (because it does not need repeated > mul/div calculations nor necessarily 64 bit arithmetic): Agreed for unnecessary mult-div, but 64-bit we would not avoid, and should not IMO, when the HW has it. > u32 timeout = timeout_init(100); /* 100ms timeout */ > > do {...} while (!timed_out(timeout)); > > Internally it would be like: > > timeout_init(x): > return fast_tick + (x * fast_tick_rate) / CONFIG_SYS_HZ; > /* this might need 64 bit precision in some implementations */ > > time_out(x): > return ((i32)(x - fast_tick)) < 0; > > If the tick were really high speed (and then 64 bits), fast_tick > could be derived by shifting the tick some bits to the right. The only thing I slightly dislike about the overall idea is the signed rather than unsigned comparison in the timeout function (I prefer using the full 32-bit range, even if only as an academic point) and the fact that the value of the timeout is encoded in advance in the loop control variable 'timeout'. I'd rather have a single 'time(x)' (or 'ticks_elapsed(x)', names are negotiable) macro which subtract its argument from the current ticks, e.g. 'then = time(0)' would set 'then' to the number of ticks elapsed from boot, while 'now = time(then)' would set 'now' the ticks elapsed from 'then'; and a 'ms_to_ticks(x)' (again, or 'milliseconds(x)') : #define time(x) (ticks - x) #define ms_to_ticks(m) ( (m * fast_tick_rate) / CONFIG_SYS_HZ) Note that time(x) assumes unsigned arguments and amounts to an unsigned compare, because we're always computing an difference time, i.e. even with x = 2 and ticks = 1, the result is correct -- that's assuming ticks is monotonous 32-bits (or 64-bits for the platforms that can support it as an atomic value) Your example would then become then = time(0); do {...} while ( time(then) < ms_to_ticks(100) ); ... moving the actual timeout value impact from the time sample before the 'while' to the 'while' condition at then end. For expressiveness, added macros such as: #define now() time(0) #define ms_elapsed(then,ms) ( time(then) < ms_to_ticks(ms) ) ... would allow writing the same example as: then = now(); do {...} while ( !ms_elapsed(then,100) ); > But, as long as we cannot agree on something, there will be no > time spent to make patches... Makes sense, hence this specific thread. :) > Best Regards, > Reinhard Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] A question in lowlevel_init.S
Dear Eric Bénard wrote: > Hi, > > On 22/01/2011 08:39, Reinhard Meyer wrote: >> I am not aware of any ADD: working >> AT91SAM9xxx systems right now that uses low-level init, it >> would only make sense for those that boot directly from NOR, without >> AT91BOOTSTRAP involved. > > cpu9260 (at91sam9260 / 9g20 based) is using low-level init as it boots from > NOR and is not using at91bootstrap. Those CPUs are broken since relocation was introduced. It would be nice to see them demonstrated working out of NOR with low level init enabled... Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] ARM timing code refactoring
Dear Albert ARIBAUD, > Hi All, > > I am starting this thread to revive and, hopefully, come to a general > agreement on how timers should be implemented and used in the ARM > architecture, and get rid of current quick fixes. Let us start with > Reinhard's proposal: > >> There were several suggestions about that in the past (including from >> me) that involve rework everywhere HZ related timeouts are used. I >> still prefer a method as follows (because it does not need repeated >> mul/div calculations nor necessarily 64 bit arithmetic): > > Agreed for unnecessary mult-div, but 64-bit we would not avoid, and > should not IMO, when the HW has it. > >> u32 timeout = timeout_init(100); /* 100ms timeout */ >> >> do {...} while (!timed_out(timeout)); >> >> Internally it would be like: >> >> timeout_init(x): >> return fast_tick + (x * fast_tick_rate) / CONFIG_SYS_HZ; >> /* this might need 64 bit precision in some implementations */ >> >> time_out(x): >> return ((i32)(x - fast_tick))< 0; >> >> If the tick were really high speed (and then 64 bits), fast_tick >> could be derived by shifting the tick some bits to the right. > > The only thing I slightly dislike about the overall idea is the signed > rather than unsigned comparison in the timeout function (I prefer using > the full 32-bit range, even if only as an academic point) and the fact > that the value of the timeout is encoded in advance in the loop control > variable 'timeout'. 1. you always need signed compares there, unless you never anticipate a rollover of your timer value to zero. 2. whats the problem with initializing the timeout value at the beginning? > > I'd rather have a single 'time(x)' (or 'ticks_elapsed(x)', names are > negotiable) macro which subtract its argument from the current ticks, > e.g. 'then = time(0)' would set 'then' to the number of ticks elapsed > from boot, while 'now = time(then)' would set 'now' the ticks elapsed > from 'then'; and a 'ms_to_ticks(x)' (again, or 'milliseconds(x)') : > > #define time(x) (ticks - x) > #define ms_to_ticks(m) ( (m * fast_tick_rate) / CONFIG_SYS_HZ) We have exactly an equivalent of this in use at AT91. It works only as long as the ticks value does not roll back to zero - which in the current 64 bit implementation I did is after the end of the universe... Note also that "fast_tick_rate" would not be a constant in AT91, it is dynamically calculated from main xtal frequency measured against the 32kHz xtal and PLL settings. > > Note that time(x) assumes unsigned arguments and amounts to an unsigned > compare, because we're always computing an difference time, i.e. even > with x = 2 and ticks = 1, the result is correct -- that's assuming ticks > is monotonous 32-bits (or 64-bits for the platforms that can support it > as an atomic value) Assume: Monotonous AND never wrapping back to zero! > > Your example would then become > > then = time(0); > do {...} while ( time(then)< ms_to_ticks(100) ); That looks ugly to me. We don't want to see the high speed(64 bit) values in the drivers - I think. > > ... moving the actual timeout value impact from the time sample before > the 'while' to the 'while' condition at then end. Which does a multiply and a divide in 64 bit each loop iteration... (fast_tick_rate being a variable) > > For expressiveness, added macros such as: > > #define now() time(0) > #define ms_elapsed(then,ms) ( time(then)< ms_to_ticks(ms) ) > > ... would allow writing the same example as: > > then = now(); > do {...} while ( !ms_elapsed(then,100) ); > Why make everything so complicated??? >> But, as long as we cannot agree on something, there will be no >> time spent to make patches... > > Makes sense, hence this specific thread. :) The how-many-th thread about timers is this ? :) Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] U-boot (was: ARM) timing code refactoring
Dear Albert ARIBAUD, this is not an ARM local issue. The timeouts are used in generic drivers all around u-boot. Have a grep for get_timer, reset_timer... The most ugly use is with reset_timer involved, where the internal pseudo-tick is reset to zero, so all calls to get_timer are relative to that moment. We are looking at replacing all those occurrences of reset_timer and get_timer with "better" methods. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] ARM timing code refactoring
Le 22/01/2011 11:42, Reinhard Meyer a écrit : > Dear Albert ARIBAUD, >> Hi All, >> >> I am starting this thread to revive and, hopefully, come to a general >> agreement on how timers should be implemented and used in the ARM >> architecture, and get rid of current quick fixes. Let us start with >> Reinhard's proposal: >> >>> There were several suggestions about that in the past (including from >>> me) that involve rework everywhere HZ related timeouts are used. I >>> still prefer a method as follows (because it does not need repeated >>> mul/div calculations nor necessarily 64 bit arithmetic): >> >> Agreed for unnecessary mult-div, but 64-bit we would not avoid, and >> should not IMO, when the HW has it. >> >>> u32 timeout = timeout_init(100); /* 100ms timeout */ >>> >>> do {...} while (!timed_out(timeout)); >>> >>> Internally it would be like: >>> >>> timeout_init(x): >>> return fast_tick + (x * fast_tick_rate) / CONFIG_SYS_HZ; >>> /* this might need 64 bit precision in some implementations */ >>> >>> time_out(x): >>> return ((i32)(x - fast_tick))< 0; >>> >>> If the tick were really high speed (and then 64 bits), fast_tick >>> could be derived by shifting the tick some bits to the right. >> >> The only thing I slightly dislike about the overall idea is the signed >> rather than unsigned comparison in the timeout function (I prefer using >> the full 32-bit range, even if only as an academic point) and the fact >> that the value of the timeout is encoded in advance in the loop control >> variable 'timeout'. > > 1. you always need signed compares there, unless you never anticipate a > rollover of your timer value to zero. I don't think rollover to zero is an issue if the tick counter is free-running on 32 (or 64 bits); and if it is free-running on some other number of bits, the time() macro just needs anding to work. > 2. whats the problem with initializing the timeout value at the beginning? There isn't a problem as such; simply, as the timeout is not conceptually needed at the beginning of the timing loop, I would favor implementations which do not need it at the beginning either. >> I'd rather have a single 'time(x)' (or 'ticks_elapsed(x)', names are >> negotiable) macro which subtract its argument from the current ticks, >> e.g. 'then = time(0)' would set 'then' to the number of ticks elapsed >> from boot, while 'now = time(then)' would set 'now' the ticks elapsed >> from 'then'; and a 'ms_to_ticks(x)' (again, or 'milliseconds(x)') : >> >> #define time(x) (ticks - x) >> #define ms_to_ticks(m) ( (m * fast_tick_rate) / CONFIG_SYS_HZ) > > We have exactly an equivalent of this in use at AT91. > It works only as long as the ticks value does not roll back to zero - > which in the current 64 bit implementation I did is after the end of > the universe... Let us take a case where the tick value rolls over 0. Say, ticks is equal to 2^32 - 100, and we should delay for 200 ticks. At the beginning of the loop, 'then' becomes equal to 2^32 - 100. While the loop runs, time(then) equals 'ticks - then', or, '2^32 - 100 + n - (2^32 - 100)', or '2^32 - 100 - 2^32 + 100 +n', or (since we're computing modulo 2^32) '-100 + 100 +n', or 'n', where n is the number of ticks elapsed since 'now' was caculated. When n is 200 or more, the loop end condition is met. Crossing the 0 value did not affect the computation -- or did it? > Note also that "fast_tick_rate" would not be a constant in AT91, it is > dynamically calculated from main xtal frequency measured against the 32kHz > xtal and PLL settings. That's another issue entirely, with two consequences, but they don't really differ with respect to which proposal, yours or mine, is considered. 1. This makes the compiler unable to optimize ms to tick conversions at compile time. Not a really big deal, and unavoidable as soon as the decision is taken to calibrate the fast tick at run time. 2. If calibration is done continuously, then ticks *may* not be monotonous. If it is done once at startup, a la bogomips calculation, then we should be safe. >> Note that time(x) assumes unsigned arguments and amounts to an unsigned >> compare, because we're always computing an difference time, i.e. even >> with x = 2 and ticks = 1, the result is correct -- that's assuming ticks >> is monotonous 32-bits (or 64-bits for the platforms that can support it >> as an atomic value) > > Assume: Monotonous AND never wrapping back to zero! I think zero wraparound is not an issue if the ticks are on N (ideally, 32 or 64) bits, which is most probably the case for a free-running counter. We need to assume monotonous at least during delay loops; since we have little or no parallel execution, we should be able to avoid recalibration while a delay loop is running, right? >> Your example would then become >> >> then = time(0); >> do {...} while ( time(then)< ms_to_ticks(100) ); > > That looks ugly to me. We don't want to see the high speed(64 bit) values > in the drivers - I think. We
Re: [U-Boot] [RFC] U-boot
Hi Reinhard, Le 22/01/2011 12:00, Reinhard Meyer a écrit : > Dear Albert ARIBAUD, > > this is not an ARM local issue. Well, there *is* an ARM specific side of it (use of gd variables during relocation), and that is what prompted me to start the RFC, but generalization to U-boot is welcome if it leads to a satisfactory solution. If not, at least I'll adopt a solution for ARM. > The timeouts are used in generic drivers all around u-boot. > > Have a grep for get_timer, reset_timer... > > The most ugly use is with reset_timer involved, where the internal > pseudo-tick is reset to zero, so all calls to get_timer are > relative to that moment. > > We are looking at replacing all those occurrences of reset_timer > and get_timer with "better" methods. Seems to me this replacement is quite straightforward, as most uses of reset_timer() and subsequent get_timer are actually loops, functionally the same as our proposals, only instead of using a local to store the start or end time, they reset ticks to zero -- which, I concur, is a Bad Thing. But 'reset_timer()' calls just need to be replaced with your 'timeout = timeout_init(N)' or my 'then = now()' and 'get_timer() > N' or 'get_timer_masked() > N' by your 'time_out(timeout)' or my 'ms_elapsed(N)'. Seems to me like a tedious effort, possibly involving occasional time-out value conversions, but not a difficulty. What do I miss? > Best Regards, > Reinhard Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] WARNING: in gcc 4.5.0 and 4.5.1 volatile is ignored
Hello, because I've recently seen some other places where volatile is used to access registers without using read?() or write?() and many people seem to start using 4.5.1, I want to post this warning using a descriptive subject. The keyword volatile might not have any effect when reading when gcc 4.5.0 or 4.5.1 is used. The appropriate bug seems to be that one: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45052 You might either change such code to use readb(), readw() or readl(), or you have to use either an older version of gcc or a version >= 4.5.2 (it is fixed in 4.5.2). A patch for write?() and read?() is currently in the u-boot-arm-repository (but not in the master and not in 2010.12): http://lists.denx.de/pipermail/u-boot/2011-January/084885.html Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] WARNING: in gcc 4.5.0 and 4.5.1 volatile is ignored
Dear Alexander Holler, In message <4d3ad19b.6030...@ahsoftware.de> you wrote: > > because I've recently seen some other places where volatile is used to > access registers without using read?() or write?() and many people seem > to start using 4.5.1, I want to post this warning using a descriptive > subject. > > The keyword volatile might not have any effect when reading when gcc > 4.5.0 or 4.5.1 is used. Actuelly this warning should eventually be extended to carefully check results when using any of the currently available 4.5.x versions of GCC. > The appropriate bug seems to be that one: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45052 This is probably only one part of the problem. Thereare a number of other bugs in thes ecompiler versions, for example this one: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44392 Unfortunately there appears to be little interest within the GCC folks to fix porolems that affect only such lunatic fringe groups as the embedded folks, so I don't expect to see fixes any time soon. Even bigger projects like the Linux Foundation driven Poky (resp. Yocto project) capitulated and stopped using -Os, see for example here: http://thread.gmane.org/gmane.linux.embedded.poky/2311/focus=2565 Yes, "-Os" is default setting for U-Boot - changing it to (for example) -O2 will generate significantly larger code and even break a number of boards. It appears there are a number of other issues with GCC 4.5.x that affect us. If you are using any such tool chain, and see strange results or unexpected breakages, it is probably a very good idea to try another (older, working) tool chain first, before spending any tme on debugging. > You might either change such code to use readb(), readw() or readl(), or > you have to use either an older version of gcc or a version >= 4.5.2 (it > is fixed in 4.5.2). We will take care to provide working (at least with most of the compiler versions) I/O accessors (including sufficient memory barriers), and all code that uses the old volatile pointer approach to access device registers should be converted to use proper I/O acessors. > A patch for write?() and read?() is currently in the > u-boot-arm-repository (but not in the master and not in 2010.12): > > http://lists.denx.de/pipermail/u-boot/2011-January/084885.html Thanks for raising this issue again. 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 The ideal situation is to have massive computing power right at home. Something that dims the streetlights and shrinks the picture on the neighbours' TVs when you boot it up. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] A question in lowlevel_init.S
Sorry for not mentioning the file name. its here uboot/arch/arm/cpu/arm920t/at91rm9200/lowlevel_init.S and also in uboot/board/samsung/smdk2410/lowlevel_init.S Thanks for all your responses so far people. Reinhard Meyer wrote: > > Dear Eric Bénard wrote: >> Hi, >> >> On 22/01/2011 08:39, Reinhard Meyer wrote: >>> I am not aware of any > ADD: working >>> AT91SAM9xxx systems right now that uses low-level init, it >>> would only make sense for those that boot directly from NOR, without >>> AT91BOOTSTRAP involved. >> >> cpu9260 (at91sam9260 / 9g20 based) is using low-level init as it boots >> from >> NOR and is not using at91bootstrap. > > Those CPUs are broken since relocation was introduced. It would be nice to > see > them demonstrated working out of NOR with low level init enabled... > > Best Regards, > Reinhard > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > > -- View this message in context: http://old.nabble.com/A-question-in-lowlevel_init.S-tp30734554p30737145.html Sent from the Uboot - Users mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Cannot access memory at address 0xd8013fa8 when using gdb/BDI3000 to debug u-boot
I'm trying to get u-boot version 1.3.4 working a custom MPC8548 based board (version 1.1.4 currently works fine on this board so the hardware is known to be good). I'm encountering the following problem during the early stages of the u-boot initialization and any insights as to what the problem may be would be greatly appreciated: I have a BDI3000 and i'm using gdb for debug sessions. I started with the MPC8548CDS.h as my template for the build configuration file for this board. 1) in the start.S file the L1 DCache is configured to be used for initial RAM, this occurs in the code at the 'switch_as:' label. I set the CFG_INIT_RAM_ADDR to the value 0xd801 and this value is used to configure the L1CFG0 register. 2) execution soon jumps to the '_start_cont:' label and the stack is set up in this initial RAM area 3) I set a breakpoint at '_start_cont' and tried to examine the initial RAM memory with the gdb 'x' command: (gdb) x/16x 0xd801 0xd801:Cannot access memory at address 0xd801 So at this point should gdb be able to examine this memory area? I compared the code in start.S for 1.3.4 with the code from 1.1.4 and although not identical the instructions to setup the L1 cache and use it for initial RAM end up using the same values and doing the same operations... I can continue to execute code and soon we jump into the c routines where the global data pointer is initialized, attempts to display this gd_t structure give the same error message (no surprise there), so I'm guessing this structure does not get initialized properly and function using it read bogus values... but I can continue stepping thru the initialzation functions, and for example when the console is initialized a long string of garbage shows up in the console terminal window, the baudrate comes from the gd_t struct so its not what I configured... so i think this is close to working but something seems broken with using the L1 Dcache for initial ram... thanks in advance for any ideas and suggestion and please let me know if there is additional info that might be useful for you to understand the problem... davis mcpherson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Cannot access memory at address 0xd8013fa8 when using gdb/BDI3000 to debug u-boot
Dear davis mcpherson, In message <4d3b0525.4080...@gmail.com> you wrote: > > I'm trying to get u-boot version 1.3.4 working a custom MPC8548 based > board (version 1.1.4 currently works fine on this board so the hardware > is known to be good). I'm encountering the following problem during the Sorry, but I don't even continue reading. v1.3.4 is 2.5 years old, i. e. hopelessly obsolete. Any efforts on this old stuff are only a waste of time. Do yourself (and us) a favour and use current code instead (at least v2010.12, or bettter current top of tree from the git repository). 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 "No problem is so formidable that you can't walk away from it." - C. Schulz ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] WARNING: in gcc 4.5.0 and 4.5.1 volatile is ignored
On 22.01.2011 13:46, Alexander Holler wrote: > A patch for write?() and read?() is currently in the > u-boot-arm-repository (but not in the master and not in 2010.12): > > http://lists.denx.de/pipermail/u-boot/2011-January/084885.html What's about pulling it sooner than later into master, then? And would it be worth to think about applying this to 2010.12 and creating a 2010.12.1? Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] WARNING: in gcc 4.5.0 and 4.5.1 volatile is ignored
Hi Dirk, Le 22/01/2011 18:40, Dirk Behme a écrit : > On 22.01.2011 13:46, Alexander Holler wrote: >> A patch for write?() and read?() is currently in the >> u-boot-arm-repository (but not in the master and not in 2010.12): >> >> http://lists.denx.de/pipermail/u-boot/2011-January/084885.html > > What's about pulling it sooner than later into master, then? I will send out a pull request for u-boot-arm once I have applied all outstanding ARM patches from jan 17 or before and all outstanding ARM bug fixes regardless of their date, and pulled other ARM repos whose custodian requests pulling. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] ARM timing code refactoring
Dear Albert ARIBAUD, In message <4d3aaf63.1030...@free.fr> you wrote: > > Agreed for unnecessary mult-div, but 64-bit we would not avoid, and > should not IMO, when the HW has it. When attempting to come up with true generic code, we should probably _always_ use a (virtual) unsigned 64 bit counter. > > u32 timeout = timeout_init(100); /* 100ms timeout */ > > > > do {...} while (!timed_out(timeout)); > > > > Internally it would be like: > > > > timeout_init(x): > > return fast_tick + (x * fast_tick_rate) / CONFIG_SYS_HZ; > > /* this might need 64 bit precision in some implementations */ > > > > time_out(x): > > return ((i32)(x - fast_tick)) < 0; > > > > If the tick were really high speed (and then 64 bits), fast_tick > > could be derived by shifting the tick some bits to the right. > > The only thing I slightly dislike about the overall idea is the signed > rather than unsigned comparison in the timeout function (I prefer using > the full 32-bit range, even if only as an academic point) and the fact > that the value of the timeout is encoded in advance in the loop control > variable 'timeout'. Please don't. Use an unsigned counter and allow it to roll over. Anything else causes additional (and unnecessary) restrictions and makes the code more complicated. > I'd rather have a single 'time(x)' (or 'ticks_elapsed(x)', names are > negotiable) macro which subtract its argument from the current ticks, I'm not sure what you have in mind with "substract". I strongly recommend to avoid problems with wrap-around etc. right from the beginning, and let unsigned arithmentcs handle this for us. > e.g. 'then = time(0)' would set 'then' to the number of ticks elapsed > from boot, while 'now = time(then)' would set 'now' the ticks elapsed > from 'then'; and a 'ms_to_ticks(x)' (again, or 'milliseconds(x)') : Do we really need such a function? As far as I can tell we don't really have any time (in the sense of wallclock time) related requirements, we only need delta times, and nobody really cares about the starting point. We should _always_ be able to use the standard approach of start = get_timer() while ((get_timer() - start) < timeout) { ... wait ... } > Your example would then become > > then = time(0); > do {...} while ( time(then) < ms_to_ticks(100) ); We should NOT do this. It is bound to break as soon as the code in the loop (the "..." part) needs to implement a timeout, too. > #define now() time(0) > #define ms_elapsed(then,ms) ( time(then) < ms_to_ticks(ms) ) This is not a good isea for the same reason. 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 There has been an alarming increase in the number of things you know nothing about. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v4 patch 6/6] SMDK6400: Fix SMDK6400 SDRAM init
On 01/22/2011 03:31 PM, Albert ARIBAUD wrote: > Hi seedshope, > > Le 22/01/2011 02:56, seedshope a écrit : > My patch is ok, I just two tabs in my e-mail, But I sent the mail, It is change. >>> Do you send the patch through git format-patch and git send-email? > >> Yes, I use the git format-patch and git send-email > >>> Many e-mail softwares have weird issues when posting git patches, >>> which is why git has its own tools for sending patches via e-mail. > >> ok > > Since you're using git format-patch and git send-email, then your > original change is not correctly aligned. I suggest you check your > code editor's settings on indentation and use of tabulations, notably > the "tab size": tabs should align on 8-space multiples; also check > that your editor uses a fixed font -- you never know. Hi Amicalement I check my patch 6 on the http://news.gmane.org/gmane.comp.boot-loaders.u-boot, It look fine. I have a bit despondent. Why do you think it has a format problem. Thanks seedshope > > Amicalement, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v4 patch 6/6] SMDK6400: Fix SMDK6400 SDRAM init
On 01/22/2011 01:52 AM, Sergei Shtylyov wrote: > Hello. > > seedshope wrote: > >> Since SDRAM init function have already change, So the SDRAM >> initial function must be change. > > This description sounds somewhat tautological... > >> Signed-off-by: seedshope > > Your real name is required in the signoff. > >> --- >> board/samsung/smdk6400/smdk6400.c | 10 +- >> 1 files changed, 9 insertions(+), 1 deletions(-) > >> diff --git a/board/samsung/smdk6400/smdk6400.c >> b/board/samsung/smdk6400/smdk6400.c >> index 35aa40b..1d03b7a 100644 >> --- a/board/samsung/smdk6400/smdk6400.c >> +++ b/board/samsung/smdk6400/smdk6400.c >> @@ -78,10 +78,18 @@ int board_init(void) >> return 0; >> } >> >> -int dram_init(void) >> +void dram_init_banksize(void) >> { >> + DECLARE_GLOBAL_DATA_PTR; >> + >> gd->bd->bi_dram[0].start = PHYS_SDRAM_1; >> gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE; >> +} >> + >> +int dram_init(void) >> +{ >> + gd->ram_size = get_ram_size((long *)CONFIG_SYS_SDRAM_BASE, >> + PHYS_SDRAM_1_SIZE); You can look at the web site(http://news.gmane.org/gmane.comp.boot-loaders.u-boot) for the patch, It is inconsistent with your description. Thanks seedshope > > Could you move this last line more to the right? > > WBR, Sergei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] WARNING: in gcc 4.5.0 and 4.5.1 volatile is ignored
Dear Albert ARIBAUD, In message <4d3b1c0c.4040...@free.fr> you wrote: > > Le 22/01/2011 18:40, Dirk Behme a =E9crit : > > On 22.01.2011 13:46, Alexander Holler wrote: > >> A patch for write?() and read?() is currently in the > >> u-boot-arm-repository (but not in the master and not in 2010.12): > >> > >> http://lists.denx.de/pipermail/u-boot/2011-January/084885.html > > > > What's about pulling it sooner than later into master, then? > > I will send out a pull request for u-boot-arm once I have applied all > outstanding ARM patches from jan 17 or before and all outstanding ARM > bug fixes regardless of their date, and pulled other ARM repos whose > custodian requests pulling. Thanks - but I also think that Dirk's proposal to create a v2010.12.1 bug fix release makes sense. What do you think? 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 Star Trek Lives! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot Config Parameters on Compact Flash
Dear "Dach Miroslaw", In message <1b4f8000449511488d1a640dd6deca350392a...@mailbox0a.psi.ch> you wrote: > > Could you please direct me to some manual/"how to" to find out how to > configure IDE > access by means of the CONFIG_IDE_* . I have examined several header > files in u-boot/include/configs > and it seems to be that CONFIG_ATA_* could be/should be used in > conjunction with CONFIG_IDE_*? I'm not an expert with Xilinx FPGAs and have no idea what needs to be done to enable the ACE in them. A "grep SYS_ACE" in include/configs/* turns up only the icon and katmai boards that appearently enable a Xilinx ACE controll, but these are PPC440SPe boards, i. e. no Xilinx FPGA based solutions. You will have to read the respective user manuals yourself. Or hire an expert. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Any sufficiently advanced technology is indistinguishable from magic. Clarke's Third Law - _Profiles of the Future_ (1962; rev. 1973) ``Hazards of Prophecy: The Failure of Imagination'' ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] RR v5 PATCH: SMDK6400 Fix some build bug
Change from V1: patch 1: patch 2: Delete some compile information from commit. patch 3: Add LED modify information and Delete some compile information from commit. patch 4: Add new patch for SDRAM init. Change from v2: patch2: Modify Makefile for arch/arm/cpu/arm1176/s3c64xx/cpu_init.s in build error. It will generat redefine information for "mem_ctrl_asm_init" before the Modify. patch4: Modify the Sergei Shtylyov comments and change the SDRAM size variable for PHYS_SDRAM_SIZE_1. Change from v3: Add new patch 3: I discuss with Amicalement, I find the mutiple-link issue: The first, the cpu_init.o have already been link for cmd_link_o_target atfer compile. But, The link script re-link the point file. So the link machine will generate multiple definition error information. The second, Since the first 4kB of nand boot featue code move to nand_spl, So It is not necessary to force the cpu_init.o in non-nand boot. Delete the cpu_init.o from u-boot-nand.lds is safe. patch 4: patch 4 and patch 5 is split from v2 patch4. patch 6: Modify according Minkyu Kang comment Change from v4 1. Modify Signed-off-by for all the patch 2. Modify patch6 for the Sergei, Minkyu and Thomas comments. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [v5 patch 1/6] SMDK6400: Fix CONFIG_SYS_INIT_SP_ADDR undefined
Fix CONFIG_SYS_INIT_SP_ADDR undefined issue. Signed-off-by: Zhong Hongbo diff --git a/include/configs/smdk6400.h b/include/configs/smdk6400.h index 671f2c7..c9acf58 100644 --- a/include/configs/smdk6400.h +++ b/include/configs/smdk6400.h @@ -44,6 +44,11 @@ #define CONFIG_PERIPORT_BASE 0x7000 #define CONFIG_PERIPORT_SIZE 0x13 +#define CONFIG_SYS_IRAM_BASE0x0c00 /* Internal SRAM base address */ +#define CONFIG_SYS_IRAM_SIZE0x2000 /* 8 KB of internal SRAM memory */ +#define CONFIG_SYS_IRAM_END (CONFIG_SYS_IRAM_BASE + CONFIG_SYS_IRAM_SIZE) +#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_IRAM_END - GENERATED_GBL_DATA_SIZE) + #define CONFIG_SYS_SDRAM_BASE 0x5000 /* input clock of PLL: SMDK6400 has 12MHz input clock */ -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [v5 patch 2/6] SMDK6400: Fix some label undefined in build error
Modify Makefile for cpu_init.c and Start.s use some label,this defined u-boot.lds of arch/arm/cpu/arm1176. But SMDK6400 use the link script board/samsung/smdk6400/u-boot-nand.lds. So add some label form u-boot.lds to u-boot-nand.lds Signed-off-by: Zhong Hongbo diff --git a/board/samsung/smdk6400/u-boot-nand.lds b/board/samsung/smdk6400/u-boot-nand.lds index 29a4f61..6771981 100644 --- a/board/samsung/smdk6400/u-boot-nand.lds +++ b/board/samsung/smdk6400/u-boot-nand.lds @@ -56,7 +56,28 @@ SECTIONS .mmudata : { *(.mmudata) } . = ALIGN(4); - __bss_start = .; - .bss : { *(.bss) . = ALIGN(4); } - _end = .; + + .rel.dyn : { + __rel_dyn_start = .; + *(.rel*) + __rel_dyn_end = .; + } + + .dynsym : { + __dynsym_start = .; + *(.dynsym) + } + + .bss __rel_dyn_start (OVERLAY) : { + __bss_start = .; + *(.bss) + . = ALIGN(4); + _end = .; + } + + /DISCARD/ : { *(.dynstr*) } + /DISCARD/ : { *(.dynamic*) } + /DISCARD/ : { *(.plt*) } + /DISCARD/ : { *(.interp*) } + /DISCARD/ : { *(.gnu*) } } -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [v5 patch 3/6] SMDK6400: Fix the mutiple link error
The first, the cpu_init.o have already been link for cmd_link_o_target atfer compile, But, The link script re-link the point file. So the link machine will generate multiple definition error information. The second, Since the first 4kB of nand boot featue code move to nand_spl, So It is not necessary to force the cpu_init.o in non-nand boot. Signed-off-by: Zhong Hongbo diff --git a/board/samsung/smdk6400/u-boot-nand.lds b/board/samsung/smdk6400/u-boot-nand.lds index 6771981..6bf4971 100644 --- a/board/samsung/smdk6400/u-boot-nand.lds +++ b/board/samsung/smdk6400/u-boot-nand.lds @@ -35,7 +35,6 @@ SECTIONS .text : { arch/arm/cpu/arm1176/start.o (.text) - arch/arm/cpu/arm1176/s3c64xx/cpu_init.o (.text) *(.text) } -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [v5 patch 4/6] SMDK6400: Add some labels to u-boot.lds to support nand_spl
In the nand_spl feature of SMDK6400. Add some relocation symbols to nand_spl/board/samsung/smdk6400/u-boot.lds to fix the compile error. Signed-off-by: Zhong Hongbo diff --git a/nand_spl/board/samsung/smdk6400/u-boot.lds b/nand_spl/board/samsung/smdk6400/u-boot.lds index 3ac6aa1..30b1573 100644 --- a/nand_spl/board/samsung/smdk6400/u-boot.lds +++ b/nand_spl/board/samsung/smdk6400/u-boot.lds @@ -55,7 +55,22 @@ SECTIONS __u_boot_cmd_end = .; . = ALIGN(4); + + .rel.dyn : { + __rel_dyn_start = .; + *(.rel*) + __rel_dyn_end = .; + } + + .dynsym : { + __dynsym_start = .; + *(.dynsym) + } + + .bss __rel_dyn_start (OVERLAY) : { __bss_start = .; - .bss : { *(.bss) . = ALIGN(4); } + *(.bss) + . = ALIGN(4); _end = .; + } } -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [v5 patch 5/6] SMDK6400: Disable LED function in start.s on the nand booting
Since nand boot have some limit for the first 4KB, We only disable the LED function to reduce the code space. At the same time, Fix the compile error for LED function undefined in the compile time of nand_spl. Signed-off-by: Zhong Hongbo diff --git a/arch/arm/cpu/arm1176/start.S b/arch/arm/cpu/arm1176/start.S index 237dcfe..ae3706a 100644 --- a/arch/arm/cpu/arm1176/start.S +++ b/arch/arm/cpu/arm1176/start.S @@ -354,9 +354,11 @@ clbss_l:strr2, [r0]/* clear loop...*/ cmp r0, r1 bne clbss_l +#ifndef CONFIG_NAND_SPL bl coloured_LED_init bl red_LED_on #endif +#endif /* * We are done. Do not return, instead branch to second part of board -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [v5 patch 6/6] SMDK6400: Fixup dram_init for relocation support
Signed-off-by: Zhong Hongbo diff --git a/board/samsung/smdk6400/smdk6400.c b/board/samsung/smdk6400/smdk6400.c index 35aa40b..13c7ed5 100644 --- a/board/samsung/smdk6400/smdk6400.c +++ b/board/samsung/smdk6400/smdk6400.c @@ -78,10 +78,16 @@ int board_init(void) return 0; } -int dram_init(void) +void dram_init_banksize(void) { gd->bd->bi_dram[0].start = PHYS_SDRAM_1; gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE; +} + +int dram_init(void) +{ + gd->ram_size = get_ram_size((long *)CONFIG_SYS_SDRAM_BASE, + PHYS_SDRAM_1_SIZE); return 0; } -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot Config Parameters on Compact Flash
Dear Wolfgang, Thank you very much for your hints. This is a good staring point for me to continue with u-boot and Compact Flash. Best Regards Miroslaw Dach -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Sat 1/22/2011 8:39 PM To: Dach Miroslaw Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] U-boot Config Parameters on Compact Flash Dear "Dach Miroslaw", In message <1b4f8000449511488d1a640dd6deca350392a...@mailbox0a.psi.ch> you wrote: > > Could you please direct me to some manual/"how to" to find out how to > configure IDE > access by means of the CONFIG_IDE_* . I have examined several header > files in u-boot/include/configs > and it seems to be that CONFIG_ATA_* could be/should be used in > conjunction with CONFIG_IDE_*? I'm not an expert with Xilinx FPGAs and have no idea what needs to be done to enable the ACE in them. A "grep SYS_ACE" in include/configs/* turns up only the icon and katmai boards that appearently enable a Xilinx ACE controll, but these are PPC440SPe boards, i. e. no Xilinx FPGA based solutions. You will have to read the respective user manuals yourself. Or hire an expert. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Any sufficiently advanced technology is indistinguishable from magic. Clarke's Third Law - _Profiles of the Future_ (1962; rev. 1973) ``Hazards of Prophecy: The Failure of Imagination'' ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] ARM timing code refactoring
Hi Wolfgang, Le 22/01/2011 20:19, Wolfgang Denk a écrit : > Dear Albert ARIBAUD, >> Agreed for unnecessary mult-div, but 64-bit we would not avoid, and >> should not IMO, when the HW has it. > > When attempting to come up with true generic code, we should probably > _always_ use a (virtual) unsigned 64 bit counter. That's fine with me. We'll just have to keep in mind that with a 32-bit HW counter, the upper 32 bits of the 64-bit virtual counter must be managed by SW -- which should not prove to be too much of a problem, but will force us to handle HW-to-SW rollovers in get_timer() on each virtual timer reads. >>> If the tick were really high speed (and then 64 bits), fast_tick >>> could be derived by shifting the tick some bits to the right. >> >> The only thing I slightly dislike about the overall idea is the signed >> rather than unsigned comparison in the timeout function (I prefer using >> the full 32-bit range, even if only as an academic point) and the fact >> that the value of the timeout is encoded in advance in the loop control >> variable 'timeout'. > > Please don't. Use an unsigned counter and allow it to roll over. > Anything else causes additional (and unnecessary) restrictions and > makes the code more complicated. Hmm... don't we actually agree here? I was also expressing my preference for unsigned. >> I'd rather have a single 'time(x)' (or 'ticks_elapsed(x)', names are >> negotiable) macro which subtract its argument from the current ticks, > > I'm not sure what you have in mind with "substract". I strongly > recommend to avoid problems with wrap-around etc. right from the > beginning, and let unsigned arithmentcs handle this for us. That's what I meant with my comment about subtracting: the difference of two unsigned integers is always correct. >> e.g. 'then = time(0)' would set 'then' to the number of ticks elapsed >> from boot, while 'now = time(then)' would set 'now' the ticks elapsed >> from 'then'; and a 'ms_to_ticks(x)' (again, or 'milliseconds(x)') : > > Do we really need such a function? As far as I can tell we don't > really have any time (in the sense of wallclock time) related > requirements, we only need delta times, and nobody really cares about > the starting point. Hmm... My idea with providing time() with an argument was that precisely since we are interested only in elapsed time, not absolute time, our basic time function should be able to tell us relative times. > We should _always_ be able to use the standard approach of > > start = get_timer() > > while ((get_timer() - start)< timeout) { > suall ... wait ... > } Functionally this is the same as what I suggested, minus the absolute get_timer() vs relative time(x) call. Either way works, I'm not going to try and make a point that we use "my" time(x). We still need ms-to-tick and us-to-tick conversions, though, because usually timing constraints will be expressed in us or ms, not in ticks. Just one thing, however: >> Your example would then become >> >> then = time(0); >> do {...} while ( time(then)< ms_to_ticks(100) ); > > We should NOT do this. It is bound to break as soon as the code > in the loop (the "..." part) needs to implement a timeout, too. I'm not sure to understand why. Can you develop how you think this would break with an inner timeout? >> #define now() time(0) >> #define ms_elapsed(then,ms) ( time(then)< ms_to_ticks(ms) ) > > This is not a good isea for the same reason. Those two were just syntactic sugaring anyway; if you don't like them, no worries. > Best regards, > > Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] WARNING: in gcc 4.5.0 and 4.5.1 volatile is ignored
Le 22/01/2011 20:30, Wolfgang Denk a écrit : > Dear Albert ARIBAUD, > > In message<4d3b1c0c.4040...@free.fr> you wrote: >> >> Le 22/01/2011 18:40, Dirk Behme a =E9crit : >>> On 22.01.2011 13:46, Alexander Holler wrote: A patch for write?() and read?() is currently in the u-boot-arm-repository (but not in the master and not in 2010.12): http://lists.denx.de/pipermail/u-boot/2011-January/084885.html >>> >>> What's about pulling it sooner than later into master, then? >> >> I will send out a pull request for u-boot-arm once I have applied all >> outstanding ARM patches from jan 17 or before and all outstanding ARM >> bug fixes regardless of their date, and pulled other ARM repos whose >> custodian requests pulling. > > Thanks - but I also think that Dirk's proposal to create a v2010.12.1 > bug fix release makes sense. What do you think? I didn't comment on this point as it was not for me to decide upon releasing an interim U-boot version :) but I'm fine with it if you do. When I rebase on u-boot/master before sending my pull request, I'll simply skip the corresponding patch in my tree as it will already be on yours. > Best regards, > > Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v4 patch 6/6] SMDK6400: Fix SMDK6400 SDRAM init
Hi seedshope, Le 22/01/2011 20:23, seedshope a écrit : > Hi Amicalement That's Albert, actually. :) > I check my patch 6 on the > http://news.gmane.org/gmane.comp.boot-loaders.u-boot, It look fine. > I have a bit despondent. Why do you think it has a format problem. V5 of your patch has one more tab on as V4 had on the line we're discussion. It is a bit better ; Sergei will tell if that's enough for him. > Thanks > seedshope Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 0/5] Add Pantheon soc and dkb board support
> -Original Message- > From: Lei Wen [mailto:lei...@marvell.com] > Sent: Wednesday, January 19, 2011 12:13 AM > To: Wolfgang Denk; u-boot@lists.denx.de; Prafulla Wadaskar; Yu Tang; > Ashish Karkare; Prabhanjan Sarnaik; Lei Wen > Subject: [PATCH V5 0/5] Add Pantheon soc and dkb board support > > This patch set add the Pantheon soc and dkb board support. > > V2: > This patch seris update the seperate mv_common part as suggested. > > V3: > Fix config.h include place and copyright claim year. > > V4: > Add change log to each patch. > > V5: > Add doc in Readme for new CONFIG_SYS_MVFS. > code style fix. > > Lei Wen (5): > mv: seperate kirkwood and armada from common setting > ARM: Add Support for Marvell Pantheon Familiy SoCs > serial: add pantheon soc support > mvmfp: add MFP configuration support for PANTHEON > Pantheon: Add Board Support for Marvell dkb board > > MAINTAINERS |4 + > README|5 + > arch/arm/cpu/arm926ejs/pantheon/Makefile | 46 ++ > arch/arm/cpu/arm926ejs/pantheon/cpu.c | 78 + > arch/arm/cpu/arm926ejs/pantheon/dram.c| 132 > arch/arm/cpu/arm926ejs/pantheon/timer.c | 207 > + > arch/arm/include/asm/arch-armada100/config.h | 50 ++ > arch/arm/include/asm/arch-kirkwood/config.h | 145 + > arch/arm/include/asm/arch-pantheon/config.h | 44 ++ > arch/arm/include/asm/arch-pantheon/cpu.h | 79 ++ > arch/arm/include/asm/arch-pantheon/mfp.h | 41 + > arch/arm/include/asm/arch-pantheon/pantheon.h | 54 +++ > board/Marvell/dkb/Makefile| 51 ++ > board/Marvell/dkb/dkb.c | 53 +++ > boards.cfg|1 + > drivers/gpio/mvmfp.c |2 + > drivers/serial/serial.c |2 + > include/configs/aspenite.h|1 + > include/configs/dkb.h | 62 > include/configs/mv-common.h | 147 +++--- > 20 files changed, 1078 insertions(+), 126 deletions(-) > create mode 100644 arch/arm/cpu/arm926ejs/pantheon/Makefile > create mode 100644 arch/arm/cpu/arm926ejs/pantheon/cpu.c > create mode 100644 arch/arm/cpu/arm926ejs/pantheon/dram.c > create mode 100644 arch/arm/cpu/arm926ejs/pantheon/timer.c > create mode 100644 arch/arm/include/asm/arch-armada100/config.h > create mode 100644 arch/arm/include/asm/arch-kirkwood/config.h > create mode 100644 arch/arm/include/asm/arch-pantheon/config.h > create mode 100644 arch/arm/include/asm/arch-pantheon/cpu.h > create mode 100644 arch/arm/include/asm/arch-pantheon/mfp.h > create mode 100644 arch/arm/include/asm/arch-pantheon/pantheon.h > create mode 100644 board/Marvell/dkb/Makefile > create mode 100644 board/Marvell/dkb/dkb.c > create mode 100644 include/configs/dkb.h This patch series looks okay to me. Acked-by: Prafulla Wadaskar Regards.. Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v4 patch 6/6] SMDK6400: Fix SMDK6400 SDRAM init
On 01/23/2011 04:28 AM, Albert ARIBAUD wrote: > Hi seedshope, > > Le 22/01/2011 20:23, seedshope a écrit : > >> Hi Amicalement > > That's Albert, actually. :) > >> I check my patch 6 on the >> http://news.gmane.org/gmane.comp.boot-loaders.u-boot, It look fine. >> I have a bit despondent. Why do you think it has a format problem. > > V5 of your patch has one more tab on as V4 had on the line we're > discussion. It is a bit better ; Sergei will tell if that's enough for > him. yes, I just found the error in web site. I miss something in my thunderbird. such as tab convert space, So the format is change. Here, I beg you to forgot my miss. BR seedshope >> Thanks >> seedshope > > Amicalement, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] ARM timing code refactoring
Dear Albert ARIBAUD, In message <4d3b3b5c.2060...@free.fr> you wrote: > > > When attempting to come up with true generic code, we should probably > > _always_ use a (virtual) unsigned 64 bit counter. > > That's fine with me. We'll just have to keep in mind that with a 32-bit > HW counter, the upper 32 bits of the 64-bit virtual counter must be > managed by SW -- which should not prove to be too much of a problem, but > will force us to handle HW-to-SW rollovers in get_timer() on each > virtual timer reads. Yes. > >> The only thing I slightly dislike about the overall idea is the signed > >> rather than unsigned comparison in the timeout function (I prefer using > >> the full 32-bit range, even if only as an academic point) and the fact > >> that the value of the timeout is encoded in advance in the loop control > >> variable 'timeout'. > > > > Please don't. Use an unsigned counter and allow it to roll over. > > Anything else causes additional (and unnecessary) restrictions and > > makes the code more complicated. > > Hmm... don't we actually agree here? I was also expressing my preference > for unsigned. I'm happy if we agree. I just wan't sure. > > I'm not sure what you have in mind with "substract". I strongly > > recommend to avoid problems with wrap-around etc. right from the > > beginning, and let unsigned arithmentcs handle this for us. > > That's what I meant with my comment about subtracting: the difference of > two unsigned integers is always correct. Good. > >> e.g. 'then = time(0)' would set 'then' to the number of ticks elapsed > >> from boot, while 'now = time(then)' would set 'now' the ticks elapsed > >> from 'then'; and a 'ms_to_ticks(x)' (again, or 'milliseconds(x)') : > > > > Do we really need such a function? As far as I can tell we don't > > really have any time (in the sense of wallclock time) related > > requirements, we only need delta times, and nobody really cares about > > the starting point. > > Hmm... My idea with providing time() with an argument was that precisely > since we are interested only in elapsed time, not absolute time, our > basic time function should be able to tell us relative times. The disadvantage of this approach is that such calls cannot be nested, i. e. you must always make sure that the code run within the timeout loop does not attempt to set up a timeout on it's own. From my point of view, this is a killing point. > Functionally this is the same as what I suggested, minus the absolute > get_timer() vs relative time(x) call. Either way works, I'm not going to > try and make a point that we use "my" time(x). See above for the fundamental difference - not in the implementation for a single timeout, but from a system-wide point of view. > >>then = time(0); > >>do {...} while ( time(then)< ms_to_ticks(100) ); > > > > We should NOT do this. It is bound to break as soon as the code > > in the loop (the "..." part) needs to implement a timeout, too. > > I'm not sure to understand why. Can you develop how you think this would > break with an inner timeout? Sure: /* implement something which needs a 100 ms timeout */ then = time(0); do { int then_nested; ... do something... ... do more... /* now do something which needs a 5 ms timeout */ then_nested = time(0); do { ... } while (time(then_nested) < ms_to_ticks(5)); } while (time(then) < ms_to_ticks(100)); You see the problem? 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 Remember, there's a big difference between kneeling down and bending over. - Frank Zappa ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v4 patch 6/6] SMDK6400: Fix SMDK6400 SDRAM init
Dear seedshope, In message <4d3b40ac.8090...@gmail.com> you wrote: > > yes, I just found the error in web site. I miss something in my > thunderbird. such as tab convert space, So the format is change. > Here, I beg you to forgot my miss. It is usually helpful to search for and read the available documentation. See file Documentation/email-clients.txt in your Linux source tree, or: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/email-clients.txt 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 In a business, marketroids, salespukes, and lawyers have different goals from those who actually do work and produce something. Usually, is is the former who triumph over the latter, due to the simple rule that those who print the money make the rules. -- Tom Christiansen in <5jdcls$b04$2...@csnews.cs.colorado.edu> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] ARM timing code refactoring
Dear Wolfgang Denk, > Dear Albert ARIBAUD, With all this half quoting and deleting of important parts, my original proposal was lost again. If you really care to look at it, it 1. does not have issues with rollover 2. does not have problems with nested timeouts 3. does 64 bit mul/div calculations only once at the begin of a timeout 4. is easy and straightforward to use 5. needs very few lines of code to implement Calculating the end time at the begin of a loop is not a problem, I am not aware of any timeout loops where the timeout value needs to be changed inside the loop. Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8 v2] Introduce the Tertiary Program loader
Dear haiying.w...@freescale.com, In message <1291217737-3870-4-git-send-email-haiying.w...@freescale.com> you wrote: > From: Haiying Wang > > TPL is introduced to enable a loader stub that boots out of some type of RAM, > after being loaded by an SPL or similar platform-specific mechanism. > > One example of using this tpl loader is to initialize the ddr through spd code > in case the L2 SRAM size is not big enough to hold the final uboot image and > the nand spl code needs to be limitated to 4K byte, then tpl code will load > the > final uboot image after ddr is initialized. > > Signed-off-by: Haiying Wang > --- > Incorporate Mike's comment to use new variable NAND_SPL_OBJS-y > Makefile | 17 +++-- > README | 27 +++ > 2 files changed, 42 insertions(+), 2 deletions(-) > > diff --git a/Makefile b/Makefile > index 87a383d..94af465 100644 > --- a/Makefile > +++ b/Makefile > @@ -290,6 +290,10 @@ LDPPFLAGS += \ > $(shell $(LD) --version | \ > sed -ne 's/GNU ld version > \([0-9][0-9]*\)\.\([0-9][0-9]*\).*/-DLD_MAJOR=\1 -DLD_MINOR=\2/p') > > +ifeq ($(CONFIG_TPL_U_BOOT),y) > +TPL_BOOT = tpl > +endif I don't understand what the "TPL_BOOT" is good for, or how it's supposed to work. > ifeq ($(CONFIG_NAND_U_BOOT),y) > NAND_SPL = nand_spl > U_BOOT_NAND = $(obj)u-boot-nand.bin > @@ -407,8 +411,15 @@ $(obj)u-boot.lds: $(LDSCRIPT) > $(NAND_SPL): $(TIMESTAMP_FILE) $(VERSION_FILE) depend > $(MAKE) -C nand_spl/board/$(BOARDDIR) all > > -$(U_BOOT_NAND): $(NAND_SPL) $(obj)u-boot.bin > - cat $(obj)nand_spl/u-boot-spl-16k.bin $(obj)u-boot.bin > > $(obj)u-boot-nand.bin > +$(TPL_BOOT): $(TIMESTAMP_FILE) $(VERSION_FILE) depend > + $(MAKE) -C tpl/board/$(BOARDDIR) all Assume CONFIG_TPL_U_BOOT is not defined, then TPL_BOOT is not defined, and this rule will probably cause a build error, doesn't it? Has this code ever been tested? And if we use a variable for the "tlp" string, should this not be ... $(MAKE) -C $(TPL_BOOT)/board/$(BOARDDIR) all ?? > +NAND_SPL_OBJS-y += $(obj)nand_spl/u-boot-spl-16k.bin > +NAND_SPL_OBJS-$(CONFIG_TPL_U_BOOT) += $(obj)tpl/u-boot-tpl.bin > +NAND_SPL_OBJS-y += $(obj)u-boot.bin Ditto here and in the following - but how is NAND_SPL related to TPL building? These should be completely independent? > +- TPL Boot Support > + CONFIG_TPL_U_BOOT > + > + Builds a U-Boot image that contains a loader stub (tertiary > + program loader -- TPL) that boots out of some type of RAM, > + after being loaded by an SPL or similar platform-specific > + mechanism. This symbol will be set in all build phases. > + > + CONFIG_TPL_BOOT > + > + This is set by the build system when compiling code to go into > + the TPL. It is not set when building the code that the TPL > + loads, or when building the SPL. Can we not do with a single variable definition? 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 Things that try to look like things often do look more like things than things. Well-known fact. - Terry Pratchett, _Wyrd Sisters_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8 v2] Introduce the Tertiary Program loader
Dear Kumar Gala, In message you wrote: > > Did you plan on review this patch? Just done - I wonder if this code has ever been tested at all? 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 You can observe a lot just by watchin'. - Yogi Berra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8 v2] powerpc/85xx: add TPL_BOOT support
Dear haiying.w...@freescale.com, In message <1291218463-4211-1-git-send-email-haiying.w...@freescale.com> you wrote: > From: Haiying Wang > > Signed-off-by: Haiying Wang > --- > Splitted from TPL patch to only address 85xx changes > arch/powerpc/cpu/mpc85xx/cpu_init_nand.c | 34 ++- > arch/powerpc/cpu/mpc85xx/start.S | 12 ++-- > arch/powerpc/cpu/mpc85xx/u-boot-tpl.lds | 99 > ++ > 3 files changed, 137 insertions(+), 8 deletions(-) > create mode 100644 arch/powerpc/cpu/mpc85xx/u-boot-tpl.lds ... > - * Copyright 2009 Freescale Semiconductor, Inc. > + * Copyright 2010 Freescale Semiconductor, Inc. You should not undo a previous copyright. I guess you mean: Copyright 2009-2010 Freescale Semiconductor, Inc. ? > +DECLARE_GLOBAL_DATA_PTR; Please move this up to top of file. > +unsigned long get_tbclk(void) > +{ > +#ifdef CONFIG_FSL_CORENET > + return (gd->bus_clk + 8) / 16; > +#else > + return (gd->bus_clk + 4UL)/8UL; > +#endif This looks inconsistent. Either this should be "... +8UL) / 16UL" or "... + 4) / 8;" > -#ifndef CONFIG_NAND_SPL > +#if !defined(CONFIG_NAND_SPL) && !defined(CONFIG_TPL_BOOT) > GOT_ENTRY(_start) > GOT_ENTRY(_start_of_vectors) > GOT_ENTRY(_end_of_vectors) > GOT_ENTRY(transfer_to_handler) > -#endif > +#endif /* !CONFIG_TPL_BOOT || !CONFIG_NAND_SPL*/ Should that be #endif /* !CONFIG_TPL_BOOT && !CONFIG_NAND_SPL*/ instead? And can we please make this consistent, i. e. as you do in the following: > +#endif /* !CONFIG_NAND_SPL && !CONFIG_TPL_BOOT */ 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 The price of curiosity is a terminal experience. - Terry Pratchett, _The Dark Side of the Sun_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] ARM timing code refactoring
Le 22/01/2011 22:26, Wolfgang Denk a écrit : >> Hmm... My idea with providing time() with an argument was that precisely >> since we are interested only in elapsed time, not absolute time, our >> basic time function should be able to tell us relative times. > > The disadvantage of this approach is that such calls cannot be nested, > i. e. you must always make sure that the code run within the timeout > loop does not attempt to set up a timeout on it's own. From my point > of view, this is a killing point. > >> Functionally this is the same as what I suggested, minus the absolute >> get_timer() vs relative time(x) call. Either way works, I'm not going to >> try and make a point that we use "my" time(x). > > See above for the fundamental difference - not in the implementation > for a single timeout, but from a system-wide point of view. > then = time(0); do {...} while ( time(then)< ms_to_ticks(100) ); >>> >>> We should NOT do this. It is bound to break as soon as the code >>> in the loop (the "..." part) needs to implement a timeout, too. >> >> I'm not sure to understand why. Can you develop how you think this would >> break with an inner timeout? > > Sure: > > /* implement something which needs a 100 ms timeout */ > then = time(0); > > do { > int then_nested; > ... do something... > ... do more... > /* now do something which needs a 5 ms timeout */ > then_nested = time(0); > do { > ... > } while (time(then_nested)< ms_to_ticks(5)); > > } while (time(then)< ms_to_ticks(100)); > > You see the problem? Actually no, I don't. As a reminder, I am considering the following definitions: #define time(n) (ticks-n) #define ms_to_ticks(ms) (ms * fast_tick_rate) / CONFIG_SYS_HZ Neither of these has any side effect, so I am at loss as to why that would break when used in nested loops; each loop has its own reference start time by assigning time(0) to its own variable (then and then_nested), and each has its own elapsed time computation by passing its own variable to time() and comparing with its own constant timeout value. Can you point the exact instruction that would break in the code above, and why it would? > Best regards, > > Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot