Here is a patch to fix a startup in C100 (arm1136). Basically make sure
that UART is configured before using it.
Michal
diff --git a/tcl/target/c100helper.tcl b/tcl/target/c100helper.tcl
index 477fe5c..2a12c36 100644
--- a/tcl/target/c100helper.tcl
+++ b/tcl/target/c100helper.tcl
@@ -469,11 +469,
On Friday 11 September 2009, Øyvind Harboe wrote:
> There are *lots* of snippets around the code.
And they're mostly core-specific. Stuff like the
DCC support on ARMs, where ARMv4 and ARMv5 share
the same model (cp14 based), XScale morphed it by
taking away one bit, and newer ARM cores changed
th
Duane Ellis wrote:
> The idea is this:
> Let us assume there is a 4K block (working space) of ram some where.
> The code could be 2K, set aside 1K for stack (yes 1K)
> And 1K for a download buffer - could be bigger..
> Maybe we work with 4K and 4K...
>
>The entry point would
There are *lots* of snippets around the code.
I'd like to see what's running under MIPS exercised by
and large by the ARM target
Nothing has happened so far though. Nobody is doing
this manual translation, nor has anyone suggested a
solution that everybody has fallen for...
I don't know if t
On Thursday 10 September 2009, Øyvind Harboe wrote:
> W.r.t. run_algorithm, I was thinking about how much work
> it would be to write a *small* machine code translator
> that would translate generic code in to machine specific
> code... Sounds impossibly hard, but is it really? I haven't
> looked a
On Thursday 10 September 2009, Duane Ellis wrote:
> When this idea would be bad: Little quick downloads
Depends how little...
> When this idea would be good: BULK transfers, flash programing, etc.
>
> The idea is this:
> Let us assume there is a 4K block (working space) of ram some
Øyvind Harboe wrote:
> Regarding the run_algorithm. This makes me think about
> the refactoring I did for the arm simulation code
>
> W.r.t. run_algorithm, I was thinking about how much work
> it would be to write a *small* machine code translator
> that would translate generic code in to machi
Regarding the run_algorithm. This makes me think about
the refactoring I did for the arm simulation code
W.r.t. run_algorithm, I was thinking about how much work
it would be to write a *small* machine code translator
that would translate generic code in to machine specific
code... Sounds impos
On Thursday 10 September 2009, Øyvind Harboe wrote:
> > I can see there is run_algorithm implemented in arm11.c. Can you give me
> > some pointers on what needs to be added/changed? I can take a stab at
> > this.
>
> I think David looked at this...
>
> Can you share David?
One issue I have with
On Thu, Sep 10, 2009 at 10:03 PM, michal smulski
wrote:
>
> I can see there is run_algorithm implemented in arm11.c. Can you give me
> some pointers on what needs to be added/changed? I can take a stab at
> this.
I think David looked at this...
Can you share David?
> Note that I see a really sl
I can see there is run_algorithm implemented in arm11.c. Can you give me
some pointers on what needs to be added/changed? I can take a stab at
this.
Note that I see a really slow times for coping uboot to DDR memory
(load_image). Is this expected as well?
If I turn on burst writes, things go mu
11 matches
Mail list logo
