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,
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
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 meant to
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 any
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-mpc85xx.git)
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 first one
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
