On Fri, Oct 30, 2009 at 9:56 AM, Jerry Ling wrote:
> FYI, the following is the compiler options that really executed from my
> environment
>
> $ gcc -mno-cygwin -std=gnu99 -g -O0 -Wall -Wstrict-prototypes
> -Wformat-security -Wextra -Wno-unused-parameter -Wbad-function-cast
> -Wcast-align -Wredund
FYI, the following is the compiler options that really executed from my
environment
$
gcc -mno-cygwin -std=gnu99 -g -O0 -Wall -Wstrict-prototypes -Wformat-security
-Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align
-Wredundant-decls
-Werror ./bin2char.c -o bin2char.exe
I build
On Fri, Oct 30, 2009 at 9:07 AM, Jerry Ling wrote:
> You're right.
> Yes, the problem comes from the file conversion. So the converter need to be
> fixed.
Or perhaps the build options to bin2char are wrong. It should be built for the
build OS and not the OpenOCD host OS.
E.g. did -mno-cygwin sne
On Fri, Oct 30, 2009 at 9:07 AM, Jerry Ling wrote:
> You're right.
> Yes, the problem comes from the file conversion. So the converter need to be
> fixed.
Or perhaps it is a build problem in that -mno-cygwin sneaks into the
compile options
for the converter?
The converter application should be b
You're right.
Yes, the problem comes from the file conversion. So the converter need to be
fixed.
Thanks Dave.
- Original Message -
> On Thursday 29 October 2009, Jerry Ling wrote:
>> Thanks for improving the way to load debug handler...
>>
>> However, I got a problem while doing the bi
On Thursday 29 October 2009, Jerry Ling wrote:
> Thanks for improving the way to load debug handler...
>
> However, I got a problem while doing the bin2char conversion under Cygwin
>$ bin2char xscale_debug_handler < debug_handler.bin > xscale_debug.h
>
> It treats the character "0x1A" as the
Thanks for improving the way to load debug handler...
However, I got a problem while doing the bin2char conversion under Cygwin
$ bin2char xscale_debug_handler < debug_handler.bin > xscale_debug.h
It treats the character "0x1A" as the EOF. So it stopped converting at
offset 0x22 of debug_hand
David Brownell wrote:
> On Wednesday 14 October 2009, Michael Schwingen wrote:
>
>> Have you setup correct Mini-IC entries using the "xscale vector_table"
>> command?
>>
>> Without that, the kernel crashes on the first exception, since the
>> mini-IC does not match ram contents.
>>
>
> We s
On Wednesday 14 October 2009, Michael Schwingen wrote:
>
> Have you setup correct Mini-IC entries using the "xscale vector_table"
> command?
>
> Without that, the kernel crashes on the first exception, since the
> mini-IC does not match ram contents.
We should start collecting hints for Linux de
Wookey wrote:
> I haven't tested new code yet (will do next week), but certainly
> with existing code we find that on pxa270, the kernel does not boot if
> openocd has left the CPU running in debug mode. i.e. to reboot and run
> the kernel we have to do 'jtag_reset 0 1' (to just waggle the reset
>
On Wednesday 14 October 2009, Wookey wrote:
> +++ Michael Schwingen [2009-10-13 19:41 +0200]:
> > David Brownell wrote:
> > Looks quite stable to me. I use it regularly at home on IXP42x (I have a
> > BDI2000 at work), mostly in the mode of "reset halt / erase & program
> > flash / reset run", plus
+++ Michael Schwingen [2009-10-13 19:41 +0200]:
> David Brownell wrote:
> Looks quite stable to me. I use it regularly at home on IXP42x (I have a
> BDI2000 at work), mostly in the mode of "reset halt / erase & program
> flash / reset run", plus from time to time some gdb-based debugging. I
> had s
On Tuesday 13 October 2009, Michael Schwingen wrote:
> David Brownell wrote:
> > How stable do you find the XScale support, by the way?
>
> Looks quite stable to me. I use it regularly at home on IXP42x
I got that impression ("stable for you"); but it's really
not worked well at all on my old
David Brownell wrote:
> On Monday 12 October 2009, Michael Schwingen wrote:
>
>>> I'll ask the folk using XScale to sanity check; I doubt this
>>> set of XScale patches would have broken anything, but I can
>>> only test on this one ancient PXA255 board I've got.
>>>
>> I just made a shor
On Monday 12 October 2009, Michael Schwingen wrote:
> > I'll ask the folk using XScale to sanity check; I doubt this
> > set of XScale patches would have broken anything, but I can
> > only test on this one ancient PXA255 board I've got.
>
> I just made a short test on IXP425 - compiled & installed
David Brownell wrote:
> OK, I'll check that in soon.
>
> I'll ask the folk using XScale to sanity check; I doubt this
> set of XScale patches would have broken anything, but I can
> only test on this one ancient PXA255 board I've got.
>
I just made a short test on IXP425 - compiled & installed c
On Sunday 11 October 2009, Øyvind Harboe wrote:
> > On top of that, I've got the following more substantive change.
> > It should get rid of one regression ... comments? I'm inclined
> > to just check it in. Does anyone really need to support debug
> > hosts that aren't using ELF and GNU AS?
>
>
> On top of that, I've got the following more substantive change.
> It should get rid of one regression ... comments? I'm inclined
> to just check it in. Does anyone really need to support debug
> hosts that aren't using ELF and GNU AS?
I'd say commit. Looks good. You update TODO though there
is
I just committed some xscale updates; mostly cleanups that
change no behavior at all, but some minor bugfixes too (only
one of which, modifying R0 state but attributing it to R15/PC,
is likely to have been observed). See the git history for
details ... or let me know if you really want to see such
19 matches
Mail list logo