Hello Reinhard,
Reinhard Meyer wrote:
> Dear Wolfgang Denk,
>>> The environment issues still persist. I am at a loss
>>> there now.
>>>
>>> Observation: the old style commands "setenv", "printenv", etc.
>>> work, but any "env" command except for "env" alone crashes.
>> OK. If "printenv" works and
Hello Wolfgang, Reinhard,
Wolfgang Denk wrote:
> Dear Reinhard Meyer,
>
> In message <4ca5d857.5010...@emk-elektronik.de> you wrote:
>> The environment issues still persist. I am at a loss
>> there now.
>>
>> Observation: the old style commands "setenv", "printenv", etc.
>> work, but any "env" co
On Fri, Oct 1, 2010 at 5:55 AM, Wolfgang Denk wrote:
> Dear Reinhard Meyer,
>
> In message <4ca5d857.5010...@emk-elektronik.de> you wrote:
>>
>> The environment issues still persist. I am at a loss
>> there now.
>>
>> Observation: the old style commands "setenv", "printenv", etc.
>> work, but any
Dear Wolfgang Denk,
>> The environment issues still persist. I am at a loss
>> there now.
>>
>> Observation: the old style commands "setenv", "printenv", etc.
>> work, but any "env" command except for "env" alone crashes.
>
> OK. If "printenv" works and "env print" fails then it has nothing to
> d
Dear Wolfgang Denk,
> In message <4ca5d26d.2090...@emk-elektronik.de> you wrote:
>>> If this is really for all AT91 SoCs, then please feel free to
>>> introduce a common define (CONFIG_SYS_AT91 ?) and use that. Eventually
>>> you can clean up some other such #if's on the way.
>> That would have to
Dear Reinhard Meyer,
In message <4ca5d857.5010...@emk-elektronik.de> you wrote:
>
> The environment issues still persist. I am at a loss
> there now.
>
> Observation: the old style commands "setenv", "printenv", etc.
> work, but any "env" command except for "env" alone crashes.
OK. If "printenv"
Dear Reinhard Meyer,
In message <4ca5d26d.2090...@emk-elektronik.de> you wrote:
>
> > If this is really for all AT91 SoCs, then please feel free to
> > introduce a common define (CONFIG_SYS_AT91 ?) and use that. Eventually
> > you can clean up some other such #if's on the way.
>
> That would have
> I did the changes of adding the clock values to gd, and it became somewhat
> better, but there are still issues pending:
>
> 1. NAND accesses cause "raise: Signal # 8 caught"
> but still work, kernel boots normally.
> 2. environment is still invalid - when I boot the
> "CONFIG_SYS_ARM_WITHOUT_RE
Dear Wolfgang Denk,
>> For the fix, I see an ugly multiline
>> #if defined(AT91SAM9260) || defined(AT91SAM9G20) || ...
>> coming into arch/arm/asm/global_data.h.
>>
>> There is no common defined value for all AT91 SoCs that could be used.
>
> If this is really for all AT91 SoCs, then please feel f
Dear Reinhard Meyer,
In message <4ca5c7de.6010...@emk-elektronik.de> you wrote:
>
> For the fix, I see an ugly multiline
> #if defined(AT91SAM9260) || defined(AT91SAM9G20) || ...
> coming into arch/arm/asm/global_data.h.
>
> There is no common defined value for all AT91 SoCs that could be used.
Dear Wolfgang Denk,
>>
>> it became illegal once u-boot for AT91 became required to be relocated
>>
>
> No, it has always been illegal. You might thave been lucky that in
> your case the erros did not show up erarlier, but this does not change
> anything.
Sorry, before recently there was no rel
Dear Reinhard Meyer,
In message <4ca5bfef.3090...@emk-elektronik.de> you wrote:
>
>
> it became illegal once u-boot for AT91 became required to be relocated
>
No, it has always been illegal. You might thave been lucky that in
your case the erros did not show up erarlier, but this does not chan
Dear Wolfgang Denk,
> ...which is, and always has been, illegal.
it became illegal once u-boot for AT91 became required to be relocated
> Not bd-> but gd-> which was made for exactly that purpose.
typedef struct global_data...
I will try that. And fix the whitespace error as well...:)
Th
Dear Reinhard Meyer,
In message <4ca5bb7a.8050...@emk-elektronik.de> you wrote:
>
> > in "static unsigned long" vars ... as this code
> > runs before relocation, this seems to me as it
> > could be the reason for your problems ... but I
> > can;t try it here ... can you check this?
>
> Indeed, t
Dear Heiko Schocher,
> Hmm.. mabe something with at91_clock_init()
>
> This is called in arch_cpu_init(), and
> at the end, clocks are stored in
>
> arch/arm/cpu/arm926ejs/at91/clock.c
>
> in "static unsigned long" vars ... as this code
> runs before relocation, this seems to me as it
> could be t
Dear Wolfgang Denk,
> Dear Reinhard Meyer,
>
> In message <4ca590e6.6070...@emk-elektronik.de> you wrote:
>> it seems, that with relocation enabled, some
>> data does not seem to get initialized properly:
>
> I rather suspect you have code running that violates the
> pre-relocation restrictions (
Dear Reinhard Meyer,
In message <4ca590e6.6070...@emk-elektronik.de> you wrote:
>
> it seems, that with relocation enabled, some
> data does not seem to get initialized properly:
I rather suspect you have code running that violates the
pre-relocation restrictions (no bss segment available, read-
Hello Reinhard,
Reinhard Meyer wrote:
> it seems, that with relocation enabled, some
> data does not seem to get initialized properly:
>
> w/o relocation:
>
> mmci
> mci: setting clock 194000 Hz, block size 512
> mci: setting clock 194000 Hz, block size 512
> mci: setting clock 194000 Hz, block s
Hello,
it seems, that with relocation enabled, some
data does not seem to get initialized properly:
w/o relocation:
mmci
mci: setting clock 194000 Hz, block size 512
mci: setting clock 194000 Hz, block size 512
mci: setting clock 194000 Hz, block size 512
mci: setting clock 194000 Hz, block size
19 matches
Mail list logo
