> Ok closer look revealed this entry.
> == tlb.c snip ===
> /*
> * TLB 6: 64M Cacheable, non-guarded
> * 0xf000_ 64M LBC SDRAM
> */
> SET_TLB_ENTRY(1, CFG_LBC_CACHE_BASE, CFG_LBC_CACH
On Tue, Mar 11, 2008 at 1:30 PM, Eran Liberty <[EMAIL PROTECTED]> wrote:
> Hi Andy,
>
> I am bringing us back online as I think your insights might enlighten
> others who might be googleing for answers. (I know i try my best when
> faced with problems)
Oops, yes. I hit the wrong button. I mea
On Tue, 11 Mar 2008, Eran Liberty wrote:
Sorry guys for not being able to join you this time, extremely busy making
my programmers' team to meet a delivery deadline... I would've participated
but...
> Hi Andy,
>
> I am bringing us back online as I think your insights might enlighten
> others who
Hi Andy,
I am bringing us back online as I think your insights might enlighten
others who might be googleing for answers. (I know i try my best when
faced with problems)
Andy Fleming wrote:
> On Tue, Mar 11, 2008 at 3:13 AM, Eran Liberty <[EMAIL PROTECTED]> wrote:
>
>> FLASH: ERROR: too many f
Here is my sequence narrated:
U-Boot 1.3.2-rc3 (Mar 6 2008 - 12:00:30)
CPU: 8548, Version: 2.0, (0x80310020)
Core: E500, Version: 2.0, (0x80210020)
Clock Configuration:
CPU: 990 MHz, CCB: 396 MHz,
DDR: 198 MHz, LBC: 49 MHz
L1:D-cache 32 kB enabled
I-cache 32 kB en
On Mon, Mar 10, 2008 at 7:35 AM, Eran Liberty <[EMAIL PROTECTED]> wrote:
> Dear Andy,
>
> I experience the same behavior as ksi described.
Sadly, you are experiencing a slightly different behavior.
>
> => cp.b FF80 FF00 8
> Copy to Flash... External Interrupt Exception at PC: 1ffc
Kumar Gala kernel.crashing.org> writes:
>
>
> On Mar 10, 2008, at 7:35 AM, Eran Liberty wrote:
>
> > Dear Andy,
> >
> > I experience the same behavior as ksi described.
> >
> > I experience this over u-boot-1.3.2-rc3 which should have had this
> > fixed.
> > I assume you referred to commit
On Mar 10, 2008, at 7:35 AM, Eran Liberty wrote:
> Dear Andy,
>
> I experience the same behavior as ksi described.
>
> I experience this over u-boot-1.3.2-rc3 which should have had this
> fixed.
> I assume you referred to commit
> 21fae8b2b4e4e6e648796e07e20ab13e9cb18923.
>
> Are there
Dear Andy,
I experience the same behavior as ksi described.
I experience this over u-boot-1.3.2-rc3 which should have had this fixed.
I assume you referred to commit 21fae8b2b4e4e6e648796e07e20ab13e9cb18923.
Are there any follow ups on this subject?
Liberty
this is a flash 2 flash example. It
On Wed, 27 Feb 2008, Andy Fleming wrote:
>> It is too late today but tomorrow I will try to write something in
> Flash
>> with cp.b and check if this still happens.
>>
>> Everything works OK with the old U-Boot that came with CDS though...
>
> Ok, I found the problem. Check my tree (u-boot-mpc
> It is too late today but tomorrow I will try to write something in Flash
> with cp.b and check if this still happens.
>
> Everything works OK with the old U-Boot that came with CDS though...
Ok, I found the problem. Check my tree (u-boot-mpc85xx.git) now.
It's got a patch
which removes the m
On Wed, 20 Feb 2008, Andy Fleming wrote:
> On Wed, Feb 20, 2008 at 1:13 PM, <[EMAIL PROTECTED]> wrote:
>> 1.3.2-rc1-gb6f29c84-dirty crashes on the very first attempt to write
> in
>> Flash. After that it gets back to the prompt and _ALL_ subsequent
> writes
>> work just fine. Only the very firs
On Wed, Feb 20, 2008 at 1:13 PM, <[EMAIL PROTECTED]> wrote:
> 1.3.2-rc1-gb6f29c84-dirty crashes on the very first attempt to write in
> Flash. After that it gets back to the prompt and _ALL_ subsequent writes
> work just fine. Only the very first one fails.
How did you program u-boot into the f
1.3.2-rc1-gb6f29c84-dirty crashes on the very first attempt to write in
Flash. After that it gets back to the prompt and _ALL_ subsequent writes
work just fine. Only the very first one fails.
Looks like something is not initialized properly. Before I start digging
does anyone has a fix for it? Thi
14 matches
Mail list logo
