From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12085 invoked by alias); 7 Aug 2012 14:14:42 -0000 Received: (qmail 12076 invoked by uid 22791); 7 Aug 2012 14:14:40 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 07 Aug 2012 14:14:27 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id B1C0B2F78019 for ; Tue, 7 Aug 2012 15:14:25 +0100 (BST) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brfsq-+LFaVm; Tue, 7 Aug 2012 15:14:20 +0100 (BST) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-patches@ecos.sourceware.org Subject: [Bug 1001623] [RFC] eCos FLASH startup from RedBoot X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: Patches and contributions X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: ilijak@siva.com.mk X-Bugzilla-Status: NEW X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Attachment #1825 is obsolete Attachment #1833 is obsolete In-Reply-To: References: X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Tue, 07 Aug 2012 14:14:00 -0000 Message-Id: <20120807141420.D87AA2F78012@mail.ecoscentric.com> Mailing-List: contact ecos-patches-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-patches-owner@ecos.sourceware.org X-SW-Source: 2012-08/txt/msg00008.txt.bz2 Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001623 Ilija Kocho changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #1825|0 |1 is obsolete| | Attachment #1833|0 |1 is obsolete| | --- Comment #6 from Ilija Kocho 2012-08-07 15:14:17 BST --- Created an attachment (id=1877) --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1877) Kinetis Flash Startup 120807 Hi Jifl Thanks for your comment and sorry for the delayed answer, I had (and still have) to learn about ELF stuff. (In reply to comment #5) > This sort of thing could just as easily apply to most other targets, on any > architecture. The reason this hasn't been done with those either is because you > can't guarantee the flash base address is what you think it is - e.g. in this > patch it's fixed at 0x20000. Yea, I picked 0x20000 AKA CYGBLD_REDBOOT_MIN_IMAGE_SIZE default value, but you're right, we need some freedom. With the attached patch I'm following your notion regarding CDL config. What we really need is a relocating loader. It would be of benefit even for RAM systems and could be a real advantage for _RAM_constrained_/_FLASH_reach_ devices such as many modern and announced single chip controllers. I am interested for remote maintenance, so I am going to spend some time on this. I would appreciate some pointers to ELF loader library with compatible license. >But on a target with Flash managed by FIS, it > could be located at arbitrary addresses. And you wouldn't be able to have two > applications stored in flash without another startup type. > > And on many other targets with more RAM, we can use ROMRAM startup type, which > usually offers better speed anyway. That seem to be changing. Devices with 1 MiB or more Flash are available and equipped with Flash accelerators and caches that offer near SRAM performance. > > Basically things start getting complicated enough that you can't easily solve > everybody's requirements, at which point it may be better to leave it to them > to know what they're doing, e.g. by modifying the base address in the mlt files > themselves. > > It might be able to be argued that we could add a CDL config option for a flash > offset, which is then added into the addresses in the ROM startup mlt files (it > would default to 0x0). As I mentioned before I find this idea useful, regardless of some limitations. Once we have the relocating loader, this CDL will be a default load address. > But I'm slightly mindful of the fact that at some point > we would like to get back to having some form of new version of the old MLT > host tool, and the more exotic the customisations here, the more work it would > be to sort it all out later. Coming to MLT is probably little-bit slower than asymptotic :-). I think that we can build a relocating loader (as part of the eCos runtime or a utility) in a reasonable time. Ilija -- Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.