public inbox for ecos-bugs@sourceware.org help / color / mirror / Atom feed
From: bugzilla-daemon@bugs.ecos.sourceware.org To: unassigned@bugs.ecos.sourceware.org Subject: [Bug 1001623] [RFC] eCos FLASH startup from RedBoot Date: Tue, 07 Aug 2012 14:14:00 -0000 [thread overview] Message-ID: <20120807141421.3D8C12F78015@mail.ecoscentric.com> (raw) In-Reply-To: <bug-1001623-777@http.bugs.ecos.sourceware.org/> 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 <ilijak@siva.com.mk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #1825|0 |1 is obsolete| | Attachment #1833|0 |1 is obsolete| | --- Comment #6 from Ilija Kocho <ilijak@siva.com.mk> 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 the assignee for the bug.
next prev parent reply other threads:[~2012-08-07 14:14 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-07-14 16:26 [Bug 1001623] New: " bugzilla-daemon 2012-07-17 12:58 ` [Bug 1001623] " bugzilla-daemon 2012-07-17 18:37 ` bugzilla-daemon 2012-07-18 14:44 ` bugzilla-daemon 2012-07-18 14:48 ` bugzilla-daemon 2012-07-19 1:52 ` bugzilla-daemon 2012-08-07 14:14 ` bugzilla-daemon [this message] 2012-08-07 14:31 ` bugzilla-daemon 2013-02-11 15:01 ` bugzilla-daemon
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20120807141421.3D8C12F78015@mail.ecoscentric.com \ --to=bugzilla-daemon@bugs.ecos.sourceware.org \ --cc=unassigned@bugs.ecos.sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).