Hi all,
I was wondering someone knows about a ARM DCC (debug
communications channel) device driver.
The idea is to run gdbserver on /dev/dcc such that application
debugging does not hog a serial/ethernet port.
I'd modify OpenOCD to forward the DCC onto a TCP/IP port
to connect GDB to the gdbserv
On 10/05/2010 10:39 PM, Ramana Radhakrishnan wrote:
>
>> 9. Fix bswap patterns for ARM / Thumb and Thumb2.
>> http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01238.html
>
> This should already be in 4.5 branch. It was done before the 4.5 branch
> was cut IIRC.
Ramana,
Thanks, it is in 4.5 branch.
On 10/05/2010 10:01 PM, Yao Qi wrote:
> - Fix speed regression
> I found speed regression on EEMBC on linaro 4.5, compared with FSF GCC
> 4.5.0, and I'll investigate why speed regression happens on these cases.
> Here is a table below about speed regression compared between FSF GCC
> 4.5.0 and Li
On 10/06/2010 05:38 AM, Michael Hope wrote:
> ...are available here:
> https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-10-04
>
> A recording of the call is available here:
> http://tc.seabright.co.nz/toolchainwg/
>
> Interesting topics include a discussion on the copyright and lic
On 10/5/2010 8:11 PM, Zach Welch wrote:
> No, this problem derives from the mess of intellectual property laws
> that must be respected in order to preserve the integrity of the myriad
> of projects that want to be using this code, while still allowing all future
> improvements to flow seamless be
Sorry, I should clarify my earlier post. I did not mean to insinuate
that ARM (or their lawyers) have created this problem.
However, they are the author's and copyright holders of the code in
question. Nico asked specifically about the FSF assignment, and my
answer was aimed at that specific situa
On Wed, 6 Oct 2010, Michael Hope wrote:
> Ah, there's all types of things going on here. It's an unusual one as
> string routines such as memcpy() are fundamental and self contained
> and pointless to reimplement. I want to share them almost as a gift,
> usable by anyone under any terms and, ide
Ah, there's all types of things going on here. It's an unusual one as
string routines such as memcpy() are fundamental and self contained
and pointless to reimplement. I want to share them almost as a gift,
usable by anyone under any terms and, ideally, to allow third party
improvements to be fre
On 10/05/2010 06:35 PM, Nicolas Pitre wrote:
> From the minutes:
>
> | * ARM wish to keep rights for anything ARM produces, perhaps
> | through back grant
> | * Future code will be done by Linaro, so by others
> | * Issue is with copyright instead of license
> | * MIT/X11 do
On Wed, 6 Oct 2010, Michael Hope wrote:
> ...are available here:
> https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-10-04
>
> A recording of the call is available here:
> http://tc.seabright.co.nz/toolchainwg/
>
> Interesting topics include a discussion on the copyright and licens
On 10/05/2010 04:10 PM, Loïc Minier wrote:
> On Tue, Oct 05, 2010, Zach Welch wrote:
>> Personally, I think the simplest/best solution will be to encourage
>> upstream to release a new version.
>
> Fully agreed! (I think we're only having this conversation because
> of the feedback that upstream
On Tue, Oct 05, 2010, Zach Welch wrote:
> Personally, I think the simplest/best solution will be to encourage
> upstream to release a new version.
Fully agreed! (I think we're only having this conversation because of
the feedback that upstream didn't seem to be around anymore)
--
Loïc Minier
On Wed, Oct 06, 2010, Michael Hope wrote:
> Hmm. There's a conflict there. One requirement is to be 'traceable
> back to the upstream version'. If we pick up random patches then that
> is hard and calling it ltrace-linaro makes sense. However, we also
> want later upstream ltrace release to aut
On Tue, Oct 05, 2010 at 04:23:01PM -0600, John Rigby wrote:
> Thanks Michael. Just wanted to make sure I understood. The "do no
> harm" goal and the Thumb2 libgcc seem to be somewhat contradictory
> however. I realize that choices need to be made and only odd ducks
> like me will likely run into
On Wed, Oct 6, 2010 at 11:33 AM, Zach Welch wrote:
> On 10/05/2010 01:56 PM, Michael Hope wrote:
>> On Wed, Oct 6, 2010 at 12:20 AM, Loďc Minier wrote:
>>> On Tue, Oct 05, 2010, Michael Hope wrote:
Could you please:
* Mention the idea to upstream to see if anyone disagrees
* See
On Wed, Oct 6, 2010 at 11:23 AM, John Rigby wrote:
> Thanks Michael. Just wanted to make sure I understood. The "do no
> harm" goal and the Thumb2 libgcc seem to be somewhat contradictory
> however. I realize that choices need to be made and only odd ducks
> like me will likely run into issues.
On 10/05/2010 01:56 PM, Michael Hope wrote:
> On Wed, Oct 6, 2010 at 12:20 AM, Loïc Minier wrote:
>> On Tue, Oct 05, 2010, Michael Hope wrote:
>>> Could you please:
>>> * Mention the idea to upstream to see if anyone disagrees
>>> * See if anyone upstream has other ARM or x86 patches to include
Thanks Michael. Just wanted to make sure I understood. The "do no
harm" goal and the Thumb2 libgcc seem to be somewhat contradictory
however. I realize that choices need to be made and only odd ducks
like me will likely run into issues. My particular case is wanting to
build u-boot for old and
(cc'ed to linaro-toolchain, bcc'ed to others who may be interested)
I'm considering adding a new Linaro Toolchain meeting to cover people
in the North/South American timezones. We've got quite a few people
in that area who are interested in the toolchain but can't make the
current 0900 UTC calls.
On Wed, Oct 6, 2010 at 10:44 AM, John Rigby wrote:
> I believe that the libgcc.a in our toolchain contains Thumb-2 code. I
> verified this by doing objdump on libgcc.a and I see combinations of
> 16 and 32 bit instructions. So does that mean that the toolchain is
> only usable for ARM versions t
I believe that the libgcc.a in our toolchain contains Thumb-2 code. I
verified this by doing objdump on libgcc.a and I see combinations of
16 and 32 bit instructions. So does that mean that the toolchain is
only usable for ARM versions that support Thumb-2?
Thanks,
John
...are available here:
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-10-04
A recording of the call is available here:
http://tc.seabright.co.nz/toolchainwg/
Interesting topics include a discussion on the copyright and license
issues on string routines, the upcoming 2010.10 relea
On Wed, Oct 6, 2010 at 12:20 AM, Loïc Minier wrote:
> On Tue, Oct 05, 2010, Michael Hope wrote:
>> Could you please:
>> * Mention the idea to upstream to see if anyone disagrees
>> * See if anyone upstream has other ARM or x86 patches to include
>> * Test under ARM Thumb-2, i686, and x86_64
>>
On Wed, Oct 6, 2010 at 5:39 AM, Ulrich Weigand
wrote:
> Andrew Stubbs wrote:
>
>> As discussed in the meeting yesterday, CodeSourcery has a few MinGW
>> patches that I had not merged into Linaro GCC.
>>
>> I have now investigated these patches, and I'm fairly happy that most
>> are not necessary
Andrew Stubbs wrote:
> As discussed in the meeting yesterday, CodeSourcery has a few MinGW
> patches that I had not merged into Linaro GCC.
>
> I have now investigated these patches, and I'm fairly happy that most
> are not necessary for Linaro. They're mainly about interworking with
Cygwin.
>
>
As discussed in the meeting yesterday, CodeSourcery has a few MinGW
patches that I had not merged into Linaro GCC.
I have now investigated these patches, and I'm fairly happy that most
are not necessary for Linaro. They're mainly about interworking with Cygwin.
The one exception is this one:
> 9. Fix bswap patterns for ARM / Thumb and Thumb2.
> http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01238.html
This should already be in 4.5 branch. It was done before the 4.5 branch
was cut IIRC.
cheers
Ramana
--
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential
First of all, the goal of this work is about investigation on speed
improvement on linaro gcc 4.5. Finally, the output/result of this work
is to list all possible recommendations/actions to improve speed on
linaro 4.5. Comments to this plan are welcome.
So far, we can improve speed in three ways
On Tue, Oct 05, 2010, Michael Hope wrote:
> Could you please:
> * Mention the idea to upstream to see if anyone disagrees
> * See if anyone upstream has other ARM or x86 patches to include
> * Test under ARM Thumb-2, i686, and x86_64
> * Spin a tarball to go out with the 2010.11 release.
NB:
29 matches
Mail list logo
