From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31743 invoked by alias); 2 Dec 2012 15:44:42 -0000 Received: (qmail 31729 invoked by uid 22791); 2 Dec 2012 15:44:41 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from p02c12o141.mxlogic.net (HELO p02c12o141.mxlogic.net) (208.65.145.74) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 02 Dec 2012 15:44:34 +0000 Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p02c12o141.mxlogic.net(mxl_mta-6.16.0-0) with ESMTP id 1677bb05.0.46195.00-2385.88173.p02c12o141.mxlogic.net (envelope-from ); Sun, 02 Dec 2012 08:44:34 -0700 (MST) X-MXL-Hash: 50bb7762492d0c39-0d4aa51d8545b56fff9710425476a30a2a7a1398 Received: from smtpauth1.linear.com (localhost [127.0.0.1]) by smtpauth1.linear.com (Postfix) with ESMTP id 781AE740A5; Sun, 2 Dec 2012 07:44:33 -0800 (PST) Received: from [192.168.0.119] (75-163-186-131.clsp.qwest.net [75.163.186.131]) by smtpauth1.linear.com (Postfix) with ESMTPSA id 1F480740A2; Sun, 2 Dec 2012 07:44:33 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Michael Jones In-Reply-To: <50BB299F.5070404@siva.com.mk> Date: Sun, 02 Dec 2012 15:44:00 -0000 Cc: eCos Discussion Content-Transfer-Encoding: quoted-printable Message-Id: References: <88A5F92E-1AE1-4246-B566-3EFE5DEA360B@linear.com> <50BB299F.5070404@siva.com.mk> To: Ilija Kocho X-AnalysisOut: [v=2.0 cv=arAF/1lV c=1 sm=1 a=glloKNylpeYNumXQcclYyA==:17 a] X-AnalysisOut: [=gTASQVg5WCMA:10 a=D2_GN2MmYMYA:10 a=BLceEmwcHowA:10 a=8nJ] X-AnalysisOut: [EP1OIZ-IA:10 a=MqDINYqSAAAA:8 a=l9cmVeDug7kA:10 a=O8eIFpr9] X-AnalysisOut: [AAAA:8 a=CCpqsmhAAAAA:8 a=LpuIle_gJEXAGM74FpoA:9 a=wPNLvfG] X-AnalysisOut: [TeEIA:10] X-MAIL-FROM: X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Kinetis CYG_HAL_STARTUP_VAR conflict X-SW-Source: 2012-12/txt/msg00006.txt.bz2 IIija, In my case, I already have an application in MQX, and it fits in a K60N512 = with room to spare. There is a lot of value in applications that have minim= um component count, and minimum cost. My goal is to port the application to= eCos so that I de-constrain the target choice. The eCos architecture is si= milar enough to MQX to make the port practical. For this application to wor= k, I will have to add support for I2C, create a disk from part of the FLASH= (MQX can do this through the BSP and Posix calls), use an SD card, use ser= ial, and ethernet. The real constraints on the application are fast handling of interrupts and= accurate timers triggering small amounts of time sensitive IO tasks. Memor= y is not such an issue. Once I get a hello world working that does not depend on external memory, I= 'll post a bug and my results, etc. Mike On Dec 2, 2012, at 3:12 AM, Ilija Kocho wrote: > Hi Mike >=20 > On 01.12.2012 22:07, Michael Jones wrote: >> BACKGROUND >> ---------------------- >>=20 >> I am having a little bit of trouble trying to get my first hello world a= pp on a K60 Tower Board. >>=20 >> I have RedBoot running from ROM and I can ping the ethernet port, so pre= sumably I will eventually get GDB to talk to it. >>=20 >> I am having trouble building an initial app that uses the ROM monitor. F= ollowing the example in the eCos book, I went hunting for CYGSEM_HAL_USE_RO= M_MONITOR, enabled it and then set startup to SRAM. This seems the obvious = way to run and debug. >>=20 >> PROBLEM >> -------------- >>=20 >> I am getting a conflict I don't know how to resolve. I have set CYG_HAL_= STARTUP_VAR =3D SRAM. This results in CYG_HAL_STARTUP =3D SRAM by calculati= on. >>=20 >> But I get a conflict from CYGSEM_HAL_USE_ROM_MONITOR that wants CYG_HAL_= STARTUP =3D=3D RAM > SRAM and RAM startups are not the same. RAM startup is intended for > using under control of RedBoot and has some special properties: RAM, > unlike other startup types uses RedBoot's vectors, etc... >=20 > SRAM startup is kind of "stand-alone" in a way it does not depend on > RedBoot (but depends on JTAG debugger) >=20 >> QUESTIONS >> ----------------- >>=20 >> 1) Can I ignore this conflict and get the monitor and app to work? > I'm afraid not because, SRAM startup collides with RedBoot. >>=20 >> 2) Is there a better approach? > The right approach is to create RAM startup. It could live on variant > level and be available to all Kinetis platforms (though some may have > too little memory to utilize it). > The attached patches should produce proper variant-level RAM startup. >=20 > I did not add it from beginning since I consider internal SRAM too > little for practical work, seems that other people have different view. > You are not the first to look for. > This being said, I am considering to add this startup to the main > repository. Would you open a Bug on Bugzilla? >=20 >>=20 >> 3) Has anyone succeeded to use RedBoot on the K60 and can you supply an = example config project that works that I can look at? > You may want to try this: > http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001623 but beware, it > is experimental, and at present it may be broken as it's not synced with > recent Kinetis patches. > Take care not to lock your Kinetis flash - You have been warned :) >=20 > I hope this helps and I would appreciate feedback. >=20 > Regards > Ilija > --=20 > Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss