[Bug 1001864] New: Data not relocated to RAM during ROMINT startup

[Bug 1001864] New: Data not relocated to RAM during ROMINT startup

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001864

            Bug ID: 1001864
           Summary: Data not relocated to RAM during ROMINT startup
           Product: eCos
           Version: CVS
            Target: stm3240g_eval (ST STM3240G EVAL board)
  Architecture/Host Cortex-M
                OS:
            Status: NEW
          Severity: normal
          Priority: normal
         Component: HAL
          Assignee: unassigned@bugs.ecos.sourceware.org
          Reporter: john@dallaway.org.uk
                CC: ecos-bugs@ecos.sourceware.org

The STM32x0G-EVAL platform HAL provides a ROMINT startup type (CYG_HAL_STARTUP
== "ROMINT"), but the Cortex-M architectural HAL does not recognize this
startup type as one which requires data relocation to RAM during system
initialization.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001864] Data not relocated to RAM during ROMINT startup

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001864

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ilijak@siva.com.mk

--- Comment #1 from Ilija Kocho <ilijak@siva.com.mk> ---
Probably it would be enough to provide CYG_HAL_STARTUP_ROM macro:

 cdl_option CYGFOO {
    .....
    active_if { CYG_HAL_STARTUP == "ROMINT }
    define -file system.h CYG_HAL_STARTUP_ROM
    ....
  }

At least it works for bug Bug 1001623 (Attachment 1877)
I hope this helps

Ilija

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001864] Data not relocated to RAM during ROMINT startup

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001864

--- Comment #2 from John Dallaway <john@dallaway.org.uk> ---
Created attachment 2542
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2542&action=edit
cortexm-romint-141003.patch

This patch ensures that data is copied from ROM to RAM during ROMINT startup as
for ROM startup.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001864] Data not relocated to RAM during ROMINT startup

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001864

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2542|                            |assignment+, review+
              Flags|                            |

--- Comment #3 from Jonathan Larmour <jifl@ecoscentric.com> ---
Comment on attachment 2542
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2542
cortexm-romint-141003.patch

That patch is fine.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001864] Data not relocated to RAM during ROMINT startup

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001864

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jifl@ecoscentric.com

--- Comment #5 from Jonathan Larmour <jifl@ecoscentric.com> ---
Hi Ilija,

The specific proposal in comment #1 to use CYG_HAL_STARTUP_ROM doesn't feel
quite right to me:

a) it would probably be better for this property to be accessible via CDL, not
just source. A CDL interface presumably.
b) It might make the code appear confusing in the case where you do need to
distinguish "real" ROM startup from ROMINT/FLASH/whatever.

But this is easily dealt with just by using a different name for the abstract
startup type. It could be CYGINT_HAL_STARTUP_ROM or CYGINT_HAL_ROM_STARTUP, but
perhaps it might better express what we're after here if we called it
CYGINT_HAL_STANDALONE_STARTUP. But i've no strong preferences.

Jifl

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001864] Data not relocated to RAM during ROMINT startup

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001864

--- Comment #7 from Jonathan Larmour <jifl@ecoscentric.com> ---
(In reply to comment #6)
> 
> Regarding remaining two options, I have no strong preference either, but
> CYGINT_HAL_ROM_STARTUP seems slightly better distinguished from
> CYG_HAL_STARTUP_ROM than the other one.

Let's go with that then.

Jifl

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001864] Data not relocated to RAM during ROMINT startup

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001864

--- Comment #6 from Ilija Kocho [Илија Кочо] <ilijak@siva.com.mk> ---
Hi Jifl

Thank you for your consideration.

(In reply to comment #5)
> Hi Ilija,
> 
> The specific proposal in comment #1 to use CYG_HAL_STARTUP_ROM doesn't feel
> quite right to me:
> 
> a) it would probably be better for this property to be accessible via CDL,
> not just source. A CDL interface presumably.
> b) It might make the code appear confusing in the case where you do need to
> distinguish "real" ROM startup from ROMINT/FLASH/whatever.

May be confusing indeed. I developed the presented method in order to avoid
changes at architecture level. Now, provided that it is not a taboo - why not?

then for protection of legacy code we can use something like

#if defined(CYG_HAL_STARTUP_ROM) || defined(CYGINT_HAL_...)

> 
> But this is easily dealt with just by using a different name for the
> abstract startup type. It could be CYGINT_HAL_STARTUP_ROM or
> CYGINT_HAL_ROM_STARTUP, but perhaps it might better express what we're after
> here if we called it CYGINT_HAL_STANDALONE_STARTUP.

/ROM/ does not imply /standalone/. FLASH startup from Bug #1001623 is being
started from RedBoot. And it shall implement both RAM and ROM interfaces.

> But i've no strong
> preferences.

Regarding remaining two options, I have no strong preference either, but
CYGINT_HAL_ROM_STARTUP seems slightly better distinguished from
CYG_HAL_STARTUP_ROM than the other one.

Ilija

-- 
You are receiving this mail because:
You are the assignee for the bug.
>From ecos-bugs-return-10904-listarch-ecos-bugs=sources.redhat.com@sourceware.org Tue Oct 07 16:54:25 2014
Return-Path: <ecos-bugs-return-10904-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 27159 invoked by alias); 7 Oct 2014 16:54:23 -0000
Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <ecos-bugs.sourceware.org>
List-Subscribe: <mailto:ecos-bugs-subscribe@sourceware.org>
List-Post: <mailto:ecos-bugs@sourceware.org>
List-Help: <mailto:ecos-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: ecos-bugs-owner@sourceware.org
Delivered-To: mailing list ecos-bugs@sourceware.org
Received: (qmail 27133 invoked by uid 89); 7 Oct 2014 16:54:22 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=1.8 required=5.0 tests=AWL,BAYES_00,BODY_8BITS,GARBLED_BODY autolearn=no version=3.3.2
X-HELO: mail.ecoscentric.com
Received: from albus.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.200)
 by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 07 Oct 2014 16:54:20 +0000
Received: from localhost (localhost [127.0.0.1])
	by mail.ecoscentric.com (Postfix) with ESMTP id 03F1EA88899
	for <ecos-bugs@ecos.sourceware.org>; Tue,  7 Oct 2014 17:54:18 +0100 (BST)
Received: from mail.ecoscentric.com ([127.0.0.1])
	by localhost (albus.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id iaQinz48zT_S; Tue,  7 Oct 2014 17:54:17 +0100 (BST)
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-bugs@ecos.sourceware.org
Subject: [Bug 1001864] Data not relocated to RAM during ROMINT startup
Date: Tue, 07 Oct 2014 16:54:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: HAL
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ilijak@siva.com.mk
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: normal
X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-1001864-13-6F99LTFh1A@http.bugs.ecos.sourceware.org/>
In-Reply-To: <bug-1001864-13@http.bugs.ecos.sourceware.org/>
References: <bug-1001864-13@http.bugs.ecos.sourceware.org/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://bugs.ecos.sourceware.org/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014/txt/msg00271.txt.bz2
Content-length: 1698

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001864

--- Comment #6 from Ilija Kocho [Илија Кочо] <ilijak@siva.com.mk> ---
Hi Jifl

Thank you for your consideration.

(In reply to comment #5)
> Hi Ilija,
> 
> The specific proposal in comment #1 to use CYG_HAL_STARTUP_ROM doesn't feel
> quite right to me:
> 
> a) it would probably be better for this property to be accessible via CDL,
> not just source. A CDL interface presumably.
> b) It might make the code appear confusing in the case where you do need to
> distinguish "real" ROM startup from ROMINT/FLASH/whatever.

May be confusing indeed. I developed the presented method in order to avoid
changes at architecture level. Now, provided that it is not a taboo - why not?

then for protection of legacy code we can use something like

#if defined(CYG_HAL_STARTUP_ROM) || defined(CYGINT_HAL_...)

> 
> But this is easily dealt with just by using a different name for the
> abstract startup type. It could be CYGINT_HAL_STARTUP_ROM or
> CYGINT_HAL_ROM_STARTUP, but perhaps it might better express what we're after
> here if we called it CYGINT_HAL_STANDALONE_STARTUP.

/ROM/ does not imply /standalone/. FLASH startup from Bug #1001623 is being
started from RedBoot. And it shall implement both RAM and ROM interfaces.

> But i've no strong
> preferences.

Regarding remaining two options, I have no strong preference either, but
CYGINT_HAL_ROM_STARTUP seems slightly better distinguished from
CYG_HAL_STARTUP_ROM than the other one.

Ilija

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From ecos-bugs-return-10905-listarch-ecos-bugs=sources.redhat.com@sourceware.org Tue Oct 07 19:39:03 2014
Return-Path: <ecos-bugs-return-10905-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 25014 invoked by alias); 7 Oct 2014 19:39:02 -0000
Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <ecos-bugs.sourceware.org>
List-Subscribe: <mailto:ecos-bugs-subscribe@sourceware.org>
List-Post: <mailto:ecos-bugs@sourceware.org>
List-Help: <mailto:ecos-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: ecos-bugs-owner@sourceware.org
Delivered-To: mailing list ecos-bugs@sourceware.org
Received: (qmail 25002 invoked by uid 89); 7 Oct 2014 19:39:02 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2
X-HELO: mail.ecoscentric.com
Received: from albus.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.200)
 by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 07 Oct 2014 19:39:01 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 512)
	id 47EF4A888DC; Tue,  7 Oct 2014 20:38:58 +0100 (BST)
X-Original-To: unassigned@bugs.ecos.sourceware.org
Delivered-To: unassigned@bugs.ecos.sourceware.org
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: unassigned@bugs.ecos.sourceware.org
Subject: [Bug 1001864] Data not relocated to RAM during ROMINT startup
Date: Tue, 07 Oct 2014 19:39:00 -0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: HAL
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jifl@ecoscentric.com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: normal
X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-1001864-777-1LZXgaL7kJ@http.bugs.ecos.sourceware.org/>
In-Reply-To: <bug-1001864-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001864-777@http.bugs.ecos.sourceware.org/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://bugs.ecos.sourceware.org/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014/txt/msg00272.txt.bz2
Content-length: 497

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001864

--- Comment #7 from Jonathan Larmour <jifl@ecoscentric.com> ---
(In reply to comment #6)
>
> Regarding remaining two options, I have no strong preference either, but
> CYGINT_HAL_ROM_STARTUP seems slightly better distinguished from
> CYG_HAL_STARTUP_ROM than the other one.

Let's go with that then.

Jifl

--
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001864] Data not relocated to RAM during ROMINT startup

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001864

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jifl@ecoscentric.com

--- Comment #5 from Jonathan Larmour <jifl@ecoscentric.com> ---
Hi Ilija,

The specific proposal in comment #1 to use CYG_HAL_STARTUP_ROM doesn't feel
quite right to me:

a) it would probably be better for this property to be accessible via CDL, not
just source. A CDL interface presumably.
b) It might make the code appear confusing in the case where you do need to
distinguish "real" ROM startup from ROMINT/FLASH/whatever.

But this is easily dealt with just by using a different name for the abstract
startup type. It could be CYGINT_HAL_STARTUP_ROM or CYGINT_HAL_ROM_STARTUP, but
perhaps it might better express what we're after here if we called it
CYGINT_HAL_STANDALONE_STARTUP. But i've no strong preferences.

Jifl

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001864] Data not relocated to RAM during ROMINT startup

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001864

--- Comment #4 from Ilija Kocho [Илија Кочо] <ilijak@siva.com.mk> ---
(In reply to comments #2 and #3)

Hi John and Jifl.

Could you please regard my proposal in Comment #1? Here is a little
explanation.

The idea is to promote CYG_HAL_STARTUP_ROM (as well as CYG_HAL_STARTUP_RAM) as
startup "class" or attribute that can be assigned to startup types.

This approach helps us to add new startup types without adding yet another
condition in src/hal_misc.c. An example of application is Bug #1001623

Ilija

-- 
You are receiving this mail because:
You are the assignee for the bug.
>From ecos-bugs-return-10899-listarch-ecos-bugs=sources.redhat.com@sourceware.org Sun Oct 05 10:20:10 2014
Return-Path: <ecos-bugs-return-10899-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 13825 invoked by alias); 5 Oct 2014 10:20:10 -0000
Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <ecos-bugs.sourceware.org>
List-Subscribe: <mailto:ecos-bugs-subscribe@sourceware.org>
List-Post: <mailto:ecos-bugs@sourceware.org>
List-Help: <mailto:ecos-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: ecos-bugs-owner@sourceware.org
Delivered-To: mailing list ecos-bugs@sourceware.org
Received: (qmail 13798 invoked by uid 89); 5 Oct 2014 10:20:08 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=1.8 required=5.0 tests=AWL,BAYES_00,BODY_8BITS,GARBLED_BODY autolearn=no version=3.3.2
X-HELO: mail.ecoscentric.com
Received: from albus.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.200)
 by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sun, 05 Oct 2014 10:20:07 +0000
Received: from localhost (localhost [127.0.0.1])
	by mail.ecoscentric.com (Postfix) with ESMTP id 67BE9A89467
	for <ecos-bugs@ecos.sourceware.org>; Sun,  5 Oct 2014 11:20:04 +0100 (BST)
Received: from mail.ecoscentric.com ([127.0.0.1])
	by localhost (albus.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id D_lW1bUev5kJ; Sun,  5 Oct 2014 11:20:03 +0100 (BST)
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-bugs@ecos.sourceware.org
Subject: [Bug 1001864] Data not relocated to RAM during ROMINT startup
Date: Sun, 05 Oct 2014 10:20:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: HAL
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ilijak@siva.com.mk
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: normal
X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-1001864-13-t9M8CVWUsX@http.bugs.ecos.sourceware.org/>
In-Reply-To: <bug-1001864-13@http.bugs.ecos.sourceware.org/>
References: <bug-1001864-13@http.bugs.ecos.sourceware.org/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://bugs.ecos.sourceware.org/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014/txt/msg00266.txt.bz2
Content-length: 750

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001864

--- Comment #4 from Ilija Kocho [Илија Кочо] <ilijak@siva.com.mk> ---
(In reply to comments #2 and #3)

Hi John and Jifl.

Could you please regard my proposal in Comment #1? Here is a little
explanation.

The idea is to promote CYG_HAL_STARTUP_ROM (as well as CYG_HAL_STARTUP_RAM) as
startup "class" or attribute that can be assigned to startup types.

This approach helps us to add new startup types without adding yet another
condition in src/hal_misc.c. An example of application is Bug #1001623

Ilija

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From ecos-bugs-return-10900-listarch-ecos-bugs=sources.redhat.com@sourceware.org Sun Oct 05 22:55:26 2014
Return-Path: <ecos-bugs-return-10900-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 24139 invoked by alias); 5 Oct 2014 22:55:25 -0000
Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <ecos-bugs.sourceware.org>
List-Subscribe: <mailto:ecos-bugs-subscribe@sourceware.org>
List-Post: <mailto:ecos-bugs@sourceware.org>
List-Help: <mailto:ecos-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: ecos-bugs-owner@sourceware.org
Delivered-To: mailing list ecos-bugs@sourceware.org
Received: (qmail 24124 invoked by uid 89); 5 Oct 2014 22:55:25 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2
X-HELO: mail.ecoscentric.com
Received: from albus.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.200)
 by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sun, 05 Oct 2014 22:55:14 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 512)
	id 9DE04A896FE; Sun,  5 Oct 2014 23:55:11 +0100 (BST)
X-Original-To: unassigned@bugs.ecos.sourceware.org
Delivered-To: unassigned@bugs.ecos.sourceware.org
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: unassigned@bugs.ecos.sourceware.org
Subject: Your Bugzilla bug list needs attention.
X-Bugzilla-Type: whine
X-Bugzilla-URL: http://bugs.ecos.sourceware.org/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Date: Sun, 05 Oct 2014 22:55:00 -0000
Message-Id: <20141005225502.0FCF0A8970A@mail.ecoscentric.com>
X-SW-Source: 2014/txt/msg00267.txt.bz2
Content-length: 2890

[This e-mail has been automatically generated.]

You have one or more bugs assigned to you in the Bugzilla bug tracking system (http://bugs.ecos.sourceware.org/) that require
attention.

All of these bugs are in the CONFIRMED
state, and have not been touched in 7 days or more.
You need to take a look at them, and decide on an initial action.

Generally, this means one of three things:

(1) You decide this bug is really quick to deal with (like, it's INVALID),
    and so you get rid of it immediately.
(2) You decide the bug doesn't belong to you, and you reassign it to
    someone else. (Hint: if you don't know who to reassign it to, make
    sure that the Component field seems reasonable, and then use the
    "Reset Assignee to default" option.)
(3) You decide the bug belongs to you, but you can't solve it this moment.
    Accept the bug by setting the status to IN_PROGRESS.

To get a list of all CONFIRMED bugs, you can use this URL (bookmark
it if you like!):
http://bugs.ecos.sourceware.org/buglist.cgi?bug_status=CONFIRMED&assigned_to=unassigned@bugs.ecos.sourceware.org

Or, you can use the general query page, at
http://bugs.ecos.sourceware.org/query.cgi

Appended below are the individual URLs to get to all of your CONFIRMED bugs
that haven't been touched for 7 days or more.

You will get this message once a day until you've dealt with these bugs!

 STM32 USB driver unplugging/replugging issue
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001084
 Navigation of the documentation using PREV NEXT PARENT arrows broken
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001146
 help documentation tree does not correspond to viewed document
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001148
 documentation tree in navigation panel does not open at viewed document
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001149
 CAN loopback driver requires CYGPKG_DEVS_CAN_LOOP_CAN[01]
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001211
 eCos GNU tools 4.6.3
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001468
 Fix compiler warnings about mismatch between log() format string and argument values.
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001510
 Array index out of bounds in tftp_server.c
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001522
 Cortex-M: Remote 'g' packet reply is too long
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001524
 BSD nc_test_slave chrashes
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001586
 [RFC] eCos FLASH startup from RedBoot
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001623
 Kinetis variant HAL patch: mostly cosmetic and descriptive improvements
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001783
 Kinetis DSPI, flash and platform HAL tidies
    -> http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001784

[Bug 1001864] Data not relocated to RAM during ROMINT startup

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001864

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2542|                            |assignment+, review+
              Flags|                            |

--- Comment #3 from Jonathan Larmour <jifl@ecoscentric.com> ---
Comment on attachment 2542
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2542
cortexm-romint-141003.patch

That patch is fine.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001864] Data not relocated to RAM during ROMINT startup

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001864

--- Comment #2 from John Dallaway <john@dallaway.org.uk> ---
Created attachment 2542
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2542&action=edit
cortexm-romint-141003.patch

This patch ensures that data is copied from ROM to RAM during ROMINT startup as
for ROM startup.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001864] Data not relocated to RAM during ROMINT startup

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001864

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ilijak@siva.com.mk

--- Comment #1 from Ilija Kocho <ilijak@siva.com.mk> ---
Probably it would be enough to provide CYG_HAL_STARTUP_ROM macro:

 cdl_option CYGFOO {
    .....
    active_if { CYG_HAL_STARTUP == "ROMINT }
    define -file system.h CYG_HAL_STARTUP_ROM
    ....
  }

At least it works for bug Bug 1001623 (Attachment 1877)
I hope this helps

Ilija

-- 
You are receiving this mail because:
You are the assignee for the bug.