> I do write SDRAM setup code, and believe me, I would rather
> skip re-doing that in the form of a openocd init script if I
> can. On the IXP42x, getting the SDRAM up is quite easy, but
> on some DDR1/DDR2 controllers I have seen that require DQS
> calibration depending on the board layout, it
Timothy Clacy wrote:
> I'm not sure the details of setting-up SDRAM/DDR2 are too much of a
> problem. I would imagine many OpenOCD users are embedded system
> developers and have to write the SDRAM/DDR setup code anyway for their
> firmware. Also, I'm sure you would quickly build-up code sequences
> michael> That depends. Getting DDR2 SDRAM controllers
> initialized can be
> a quite tedious task,
> michael> so you may be stuck with what internal SRAM you
> have available.
> michael> The IXP42x has 2k mini-IC available for code, other CPUs may
> have even smaller TCMs
The PXA25x (and PXA2
On Tue, Oct 7, 2008 at 12:19 PM, Duane Ellis <[EMAIL PROTECTED]> wrote:
> Øyvind Harboe wrote:
>>
>> DRAM makes this more complicated in that non-working ram
>> mode has to be supported.
>>
>> Obviously with DRAM *quantity* of RAM is even less of a problem.
>>
>>
>
> Why must "non-working-ram" mode
Michael Schwingen wrote:
duane> Assertion:
duane> During "flash programing", openocd controls the world and the chip.
duane> And - there is "ram to be had some where" that openocd can use.
michael> That depends. Getting DDR2 SDRAM controllers initialized can be
a quite tedious task,
michael> so
John McCarthy wrote:
> I was thinking along the same lines. This way we write an opcode stream
> definition for each flash type which works for all targets (with
> external flash). And for each target implementation we provide an
> opcode interpreter and a fast buffer transfer mechanism. The tar
Øyvind Harboe wrote:
> DRAM makes this more complicated in that non-working ram
> mode has to be supported.
>
> Obviously with DRAM *quantity* of RAM is even less of a problem.
>
>
Why must "non-working-ram" mode be supported?
___
Openocd-developm
Duane Ellis wrote:
> Michael Schwingen wrote:
>> The C code reads its parameters directly from params, and writes its
>> result there.
> Agreed, sounds simple. But I do not think "code-lets" is the right idea.
> It is too simplistic.
>
> Reasoning:
>
> Most "flash sequences" are simplistic, ther
Duane Ellis wrote:
>> There is an objloader in eCos w/a suitable license model.
>> But perhaps we can do position independent code on all targets w/GCC?
>>
> If it requires a "obj loader" we have made something to complex.
It it either that or requiring relocatable code. However, that decision
Duane Ellis wrote:
> Michael Schwingen wrote:
>> First, I think the target code should stay as small as possible,
>> because there may be targets where very little RAM is available for
>> the code.
>
> I disagree, I think we always have 4K of ram, here's why:
>
> Generally:
>There are two
On Tue, Oct 7, 2008 at 3:37 AM, Duane Ellis <[EMAIL PROTECTED]> wrote:
> Michael Schwingen wrote:
>> The C code reads its parameters directly from params, and writes its result
>> there.
> Agreed, sounds simple. But I do not think "code-lets" is the right idea.
> It is too simplistic.
>
> Reasonin
On Tue, Oct 7, 2008 at 2:37 AM, Duane Ellis <[EMAIL PROTECTED]> wrote:
> Michael Schwingen wrote:
>> First, I think the target code should stay as small as possible, because
>> there may be targets where very little RAM is available for the code.
>>
>
> I disagree, I think we always have 4K of ram
On Mon, 2008-10-06 at 21:37 -0400, Duane Ellis wrote:
> Michael Schwingen wrote:
> > The C code reads its parameters directly from params, and writes its result
> > there.
> Agreed, sounds simple. But I do not think "code-lets" is the right idea.
> It is too simplistic.
>
> Reasoning:
I was th
Michael Schwingen wrote:
>> Now the question is: can we generate position-independent code using
gcc on all platforms?
But remember, today OpenOCD supports exactly 2 targets: ARM and MIPS
(sort of).
For ARM, this is simple. In C - might be tough to coax the compiler into
working the way you
Michael Schwingen wrote:
> The C code reads its parameters directly from params, and writes its result
> there.
Agreed, sounds simple. But I do not think "code-lets" is the right idea.
It is too simplistic.
Reasoning:
Most "flash sequences" are simplistic, there are no more then 10 to 20
comm
Øyvind Harboe wrote:
> There is an objloader in eCos w/a suitable license model.
> But perhaps we can do position independent code on all targets w/GCC?
>
If it requires a "obj loader" we have made something to complex.
-Duane.
___
Openocd-developmen
Michael Schwingen wrote:
> First, I think the target code should stay as small as possible, because
> there may be targets where very little RAM is available for the code.
>
I disagree, I think we always have 4K of ram, here's why:
Generally:
There are two classes of devices.
1) Thos
duane> (A) Take a page from the "arm-semi-hosting".
oyvind> [snip] What's "arm-semi-hosting"?
Also see this:
http://www.arm.com/support/faqdev/1494.html
ARM defined a specific "SWI" instruction & SWI number that allow the
debugger to communicate with the host system via the debugger.
Sup
Øyvind Harboe wrote:
>> - fixup/relocate the code for the target address where it is used.
>
> There is an objloader in eCos w/a suitable license model.
>
> But perhaps we can do position independent code on all targets w/GCC?
That would be great - at least for a start.
We can decide what to d
> - fixup/relocate the code for the target address where it is used.
There is an objloader in eCos w/a suitable license model.
But perhaps we can do position independent code on all targets w/GCC?
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash
Duane Ellis wrote:
> Oyvind/Georg,
>
> I see you both are talking about the flash algorithm support in openocd.
>
> There is a few tricks that I see that could be done to simplify the
> situation.
>
> To communicate with a "flash driver" - first - do not call it a flash
> driver.
> Call it an
I'd love to see some progress made on this issue... :-) Especially
important if we want to make headway w/the non-ARM32 targets...
> (A) Take a page from the "arm-semi-hosting".
I don't understand the above sentence. Could you rephrase? Wha'ts
"arm-semi-hosting"?
>
> Option #1 - it is purpo
Oyvind/Georg,
I see you both are talking about the flash algorithm support in openocd.
There is a few tricks that I see that could be done to simplify the
situation.
To communicate with a "flash driver" - first - do not call it a flash
driver.
Call it an 'execution engine' you'll understand wh
23 matches
Mail list logo
