* [ECOS] Memory Layout @ 2001-04-18 2:01 james chen 2001-04-18 5:24 ` Gary Thomas 0 siblings, 1 reply; 7+ messages in thread From: james chen @ 2001-04-18 2:01 UTC (permalink / raw) To: ecos-discuss Hello, From memory layout, I find that Redboot( startup in ROM) and Applications( startup in RAM ) both share the same memory address and size. When I use GDB debugging applications through redboot's gdb stub. Will redboot's memory be cracked by Applications? Thanks in advance! Regards, james chen ^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: [ECOS] Memory Layout 2001-04-18 2:01 [ECOS] Memory Layout james chen @ 2001-04-18 5:24 ` Gary Thomas 2001-04-18 18:05 ` james chen 0 siblings, 1 reply; 7+ messages in thread From: Gary Thomas @ 2001-04-18 5:24 UTC (permalink / raw) To: james chen; +Cc: ecos-discuss On 18-Apr-2001 james chen wrote: > Hello, > > From memory layout, I find that Redboot( startup in ROM) and > Applications( startup in RAM ) both share the same memory address and size. > When I use GDB debugging applications through redboot's gdb stub. Will > redboot's memory be cracked by Applications? Thanks in advance! Memory used by RedBoot and "normal" applications do not overlap. The MLT files imply that they do, but this is because RedBoot is just a ROM application and the MLT setup is to allow for any application to use all available resources. In general, RedBoot uses a chunk of low memory (128k is typical) and RAM based applications are set up to load just above that and use the remaining memory. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ECOS] Memory Layout 2001-04-18 5:24 ` Gary Thomas @ 2001-04-18 18:05 ` james chen 2001-04-19 5:12 ` Gary Thomas 0 siblings, 1 reply; 7+ messages in thread From: james chen @ 2001-04-18 18:05 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-discuss > > On 18-Apr-2001 james chen wrote: > > Hello, > > > > From memory layout, I find that Redboot( startup in ROM) and > > Applications( startup in RAM ) both share the same memory address and size. > > When I use GDB debugging applications through redboot's gdb stub. Will > > redboot's memory be cracked by Applications? Thanks in advance! > > Memory used by RedBoot and "normal" applications do not overlap. The MLT > files imply that they do, but this is because RedBoot is just a ROM > application and the MLT setup is to allow for any application to use all > available resources. > > In general, RedBoot uses a chunk of low memory (128k is typical) and > RAM based applications are set up to load just above that and use the > remaining memory. > After looking many ARM based platform in eCos. RAM based applications leave different size memory( from 0x8000--0x20000), I think these memory is used by RedBoot except vectors( sure?:-) ). Which size will I leave memory for RedBoot, I am using my custom board based on ARM7TDMI. Another quesiton, when I release my applications and RedBoot will not ship in. Will the memory used by redboot be lost( can't used by normal applicationss). If then, how can I re-use it? Thanks in advance! james chen ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ECOS] Memory Layout 2001-04-18 18:05 ` james chen @ 2001-04-19 5:12 ` Gary Thomas 2001-04-19 17:37 ` james chen 0 siblings, 1 reply; 7+ messages in thread From: Gary Thomas @ 2001-04-19 5:12 UTC (permalink / raw) To: james chen; +Cc: ecos-discuss On 19-Apr-2001 james chen wrote: >> >> On 18-Apr-2001 james chen wrote: >> > Hello, >> > >> > From memory layout, I find that Redboot( startup in ROM) and >> > Applications( startup in RAM ) both share the same memory address and > size. >> > When I use GDB debugging applications through redboot's gdb stub. Will >> > redboot's memory be cracked by Applications? Thanks in advance! >> >> Memory used by RedBoot and "normal" applications do not overlap. The MLT >> files imply that they do, but this is because RedBoot is just a ROM >> application and the MLT setup is to allow for any application to use all >> available resources. >> >> In general, RedBoot uses a chunk of low memory (128k is typical) and >> RAM based applications are set up to load just above that and use the >> remaining memory. >> > After looking many ARM based platform in eCos. RAM based applications > leave different size memory( from 0x8000--0x20000), I think these memory is > used by RedBoot except vectors( sure?:-) ). Which size will I leave memory > for RedBoot, I am using my custom board based on ARM7TDMI. > Another quesiton, when I release my applications and RedBoot will not > ship in. Will the memory used by redboot be lost( can't used by normal > applicationss). If then, how can I re-use it? If your application is to run in RAM, then you should leave things as is. There *will* be a monitor of some sort, even if it is not RedBoot, and it will require memory to run. We have carved out the space up to 0x20000 for this. If your application runs in ROM, then there is no problem as it will have access to all of RAM. Question: if you are building a custom board and shipping a bundled application with it, why would you _not_ want RedBoot, even in the final product? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ECOS] Memory Layout 2001-04-19 5:12 ` Gary Thomas @ 2001-04-19 17:37 ` james chen 2001-04-19 17:48 ` Gary Thomas 2001-04-19 17:53 ` [ECOS] Bootloaders (was Re: [ECOS] Memory Layout) Lewin A.R.W. Edwards 0 siblings, 2 replies; 7+ messages in thread From: james chen @ 2001-04-19 17:37 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-discuss Hi, Thomas: > > Question: if you are building a custom board and shipping a bundled application > with it, why would you _not_ want RedBoot, even in the final product? > First, I don't know whether it will cost down the performance or not. Second, it will require extra flash memory to hold it. Third, I want to replace redboot with my hardware check code in final product. when power on, it will run code to check hardware, if the hardware is all OK, then load eCos to RAM from flash memory and run eCos automatically. it seems RedBoot doesn't support it. Regards, James ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ECOS] Memory Layout 2001-04-19 17:37 ` james chen @ 2001-04-19 17:48 ` Gary Thomas 2001-04-19 17:53 ` [ECOS] Bootloaders (was Re: [ECOS] Memory Layout) Lewin A.R.W. Edwards 1 sibling, 0 replies; 7+ messages in thread From: Gary Thomas @ 2001-04-19 17:48 UTC (permalink / raw) To: james chen; +Cc: ecos-discuss On 20-Apr-2001 james chen wrote: > Hi, Thomas: >> >> Question: if you are building a custom board and shipping a bundled > application >> with it, why would you _not_ want RedBoot, even in the final product? >> > First, I don't know whether it will cost down the performance or not. None. > > Second, it will require extra flash memory to hold it. There would be this cost, but IMO it's minor, especially when weighed against the flexibility and features which are available. Things like: * Ability to debug code in the field (things _do_ break) * Ability to update code in FLASH - RedBoot, applications, etc * If your target has networking hardware, ability to connect via network to the debug/bootstrap environment. * Flexible & extensible control over the boot-time behaviour * Support for POST and BIST > > Third, I want to replace redboot with my hardware check code in final > product. when power on, it will run code to check hardware, if the hardware > is all OK, then load eCos to RAM from flash memory and run eCos > automatically. it seems RedBoot doesn't support it. This mode of operation is fully supported by RedBoot and already in place on a number of targets. ^ permalink raw reply [flat|nested] 7+ messages in thread
* [ECOS] Bootloaders (was Re: [ECOS] Memory Layout) 2001-04-19 17:37 ` james chen 2001-04-19 17:48 ` Gary Thomas @ 2001-04-19 17:53 ` Lewin A.R.W. Edwards 1 sibling, 0 replies; 7+ messages in thread From: Lewin A.R.W. Edwards @ 2001-04-19 17:53 UTC (permalink / raw) To: ecos-discuss > > with it, why would you _not_ want RedBoot, even in the final product? > Second, it will require extra flash memory to hold it. > Third, I want to replace redboot with my hardware check code in final >product. when power on, it will run code to check hardware, if the hardware >is all OK, then load eCos to RAM from flash memory and run eCos >automatically. it seems RedBoot doesn't support it. Good points. Our application is exactly the same. The flash device we are using has a 16Kword (32Kbyte) bootblock. In this 32K resides my power-on self-test code, manufacturing test code (LCD test patterns, serial/USB test, switch test, storage device test and so on) and also the code that can be used for re-flashing the remainder of the device from serial port or removable media if the power-on checksum test fails. I think this is a very standard and normal way of implementing a field-upgradable embedded system. The constraint of the typical sizes of flash bootblocks (or in evenly-sectored devices, the sector size) is a *very* important consideration, and overall flash budget is a not-too-distant second. RedBoot for EDB7212 is >80K which is way too big for my bootblock, and anyway I want the bootloader in my board to contain a lot of custom functionality (the aforementioned manufacturing support code). In a second case we are working with an absolutely bare-minimum size bootable OTP EPROM that loads the main application from cheap NAND flash or hard disk. Again, size of the bootloader, and custom functionality, is paramount. I haven't had time to study in depth what has changed now that RH has moved towards RedBoot, but I agree with comments Grant Edwards made some months ago on the topic. Essentially the thing we want to do is (once the app is debugged) compile for RAM startup, manually stuff the resultant binary together with the custom bootloader into a flash chip, and have the custom bootloader copy [decompress] from the ROM image into RAM. === Lewin A.R.W. Edwards (Embedded Engineer) Work: http://www.digi-frame.com/ Personal: http://www.zws.com/ and http://www.larwe.com/ "... a man who is endowed with real qualities of leadership will be tempted to refrain from taking part in political life; because [...] the situation does not call for a man who has a capacity for constructive statesmanship but rather for a man who is capable of bargaining for the favour of the majority. Thus the situation will appeal to small minds and will attract them accordingly." ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2001-04-19 17:53 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-04-18 2:01 [ECOS] Memory Layout james chen 2001-04-18 5:24 ` Gary Thomas 2001-04-18 18:05 ` james chen 2001-04-19 5:12 ` Gary Thomas 2001-04-19 17:37 ` james chen 2001-04-19 17:48 ` Gary Thomas 2001-04-19 17:53 ` [ECOS] Bootloaders (was Re: [ECOS] Memory Layout) Lewin A.R.W. Edwards
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).