[Bug 1002026] uSTL does not build

[bugzilla-daemon@bugs.ecos.sourceware.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 6057 bytes --]

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

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

Ilija Kocho [Илија Кочо] <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2555|0                           |1
        is obsolete|                            |

--- Comment #9 from Ilija Kocho [Илија Кочо] <ilijak@siva.com.mk> ---
Created attachment 2556
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2556&action=edit
stdint.h with applied patch. 141201

(In reply to comment #8)
> Hi Ilija 
> 
> (In reply to comment #7)
> 
> > RFC / proposal
> > 
> > stdint.h file does not belong to USTL. Probably it has been added in order
> > to satisfy USTL need for some (ISO) typedefs.
> > 
> > The file in it's contents and design is quite general and the types that it
> > defines are needed by many software packages.
> > 
> > Therefore I propose to move this file in isoinfra/current/include .
> > 
> > Please comment. If necessary I can open a bug.
> 
> Agree. stdint.h is not part of uSTL upstream. Ideally we would update eCos
> to fully support C99. I have no problem with relocating stdint.h as a step
> in this direction. The isoinfra/current/include/*.h headers appear to wrap
> headers provided by the various C library packages so we should probably
> mirror the mechanism used with these other headers.
> 

I did some overview of isoinfra includes. Then I tried /#include_next/ method,
used by some headers but it didn't work for stdint.h. I also found out that the
stdint.h found in USTL package is adapted for eCos from NewLib [Ref:
https://sourceware.org/ml/newlib/2005/msg00555.html]. Here I attach the patched
version for easy inclusion.


> Regarding the compiler warnings, they may be already fixed upstream.
> Ideally, this sort of fix should be contributed upstream first to keep
> divergence to an absolute minimum.

I am not involved inuSTL project, and producing parches would take me too much
time. However I can submit eCos paches, they should be able to locate them in
their code.

Ilija

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From ecos-bugs-return-10937-listarch-ecos-bugs=sources.redhat.com@sourceware.org Sat Dec 06 22:30:20 2014
Return-Path: <ecos-bugs-return-10937-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 26167 invoked by alias); 6 Dec 2014 22:30:20 -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 26144 invoked by uid 89); 6 Dec 2014 22:30:19 -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; Sat, 06 Dec 2014 22:30:17 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 512)
	id 73357A89E6D; Sat,  6 Dec 2014 22:30:14 +0000 (GMT)
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 1002027] New: STM32 HSI clock initialized incorrectly
Date: Sat, 06 Dec 2014 22:30:00 -0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: HAL
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: mmajchrzycki@antmicro.com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: low
X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform
 op_sys bug_status bug_severity priority component assigned_to reporter cc
Message-ID: <bug-1002027-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/msg00304.txt.bz2
Content-length: 1215

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

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

            Bug ID: 1002027
           Summary: STM32 HSI clock initialized incorrectly
           Product: eCos
           Version: CVS
            Target: stm32f4dis (ST STM32F4DISCOVERY)
  Architecture/Host Cortex-M
                OS:
            Status: UNCONFIRMED
          Severity: major
          Priority: low
         Component: HAL
          Assignee: unassigned@bugs.ecos.sourceware.org
          Reporter: mmajchrzycki@antmicro.com
                CC: ecos-bugs@ecos.sourceware.org

Created attachment 2557
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id%57&actioníit
Patch to fix HSI bug in STM32 architecture

In any STM32 platform, selecting internal RC oscillator (HSI) as clock source
causes a generate unstable frequency. This is because the HSITRIM field in
RCC_CR is cleared during clock initialization process.
Restoration of the default value of HSITRIM restores generation of stable
frequency by internal RC oscillator.

In attachment is a patch which fixes bug that is mentioned above.

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