[ECOS] Running application from RAM without Redboot

[ECOS] Running application from RAM without Redboot

[Jerome Souquieres]

  Hi,

  I would like to have some advice about how to fit my specific need 
within the eCos structure.

  I have written a package derived from hal\mips\idt79s334a for my own 
CPU board (IDT32334 MIPS-based microprocessor). So far, so good. 
However, the way my application is launched is a bit peculiar: I have a 
ROM monitor (which is NOT Redboot and which I cannot change) that simply 
loads an hex file at a fixed address in RAM (0x80200000, should that 
matter). However, to build my application under eCos, I'm in trouble to 
choose the startup option:
- CYG_HAL_STARTUP_ROM: is not available for my target. No more discussion.
- CYG_HAL_STARTUP_ROMRAM: not suitable. I don't need all code to be 
copied from RAM to ROM, I don't want the SDRAM controller to be 
configured (because it is obsviously already configured at this point 
since I'm running from RAM), I don't want the exception vectors to be 
located in ROM, etc...
- CYG_HAL_STARTUP_RAM: almost suitable,but this configuration relies on 
Redboot to provide exception vectors.

  For now, what I've done is tweaking the CYG_HAL_STARTUP_RAM 
configuration so that it takes control of exception vectors. This works, 
but is a bit rough because I've somewhat changed the semantics of 
CYG_HAL_STARTUP_RAM.

  Could an eCos architect give me a hint for a proper implementation ? 
Should I create my own CYG_HAL_STARTUP_xxx ? Should I add a sub-option ? 
Another idea ?

  Thanks in advance,

  Jerome Souquieres


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Running application from RAM without Redboot

[Gary Thomas]

On Fri, 2005-04-22 at 14:16 +0200, Jerome Souquieres wrote:
>   Hi,
> 
>   I would like to have some advice about how to fit my specific need 
> within the eCos structure.
> 
>   I have written a package derived from hal\mips\idt79s334a for my own 
> CPU board (IDT32334 MIPS-based microprocessor). So far, so good. 
> However, the way my application is launched is a bit peculiar: I have a 
> ROM monitor (which is NOT Redboot and which I cannot change) that simply 
> loads an hex file at a fixed address in RAM (0x80200000, should that 
> matter). However, to build my application under eCos, I'm in trouble to 
> choose the startup option:
> - CYG_HAL_STARTUP_ROM: is not available for my target. No more discussion.
> - CYG_HAL_STARTUP_ROMRAM: not suitable. I don't need all code to be 
> copied from RAM to ROM, I don't want the SDRAM controller to be 
> configured (because it is obsviously already configured at this point 
> since I'm running from RAM), I don't want the exception vectors to be 
> located in ROM, etc...
> - CYG_HAL_STARTUP_RAM: almost suitable,but this configuration relies on 
> Redboot to provide exception vectors.
> 
>   For now, what I've done is tweaking the CYG_HAL_STARTUP_RAM 
> configuration so that it takes control of exception vectors. This works, 
> but is a bit rough because I've somewhat changed the semantics of 
> CYG_HAL_STARTUP_RAM.
> 
>   Could an eCos architect give me a hint for a proper implementation ? 
> Should I create my own CYG_HAL_STARTUP_xxx ? Should I add a sub-option ? 
> Another idea ?

CYG_HAL_STARTUP_RAM is the right mode to use.  All you probably need is
to make sure that CYGSEM_HAL_USE_ROM_MONITOR is disabled.  In this 
setup, your application should take over the hardware completely, 
initializing all the exceptions and I/O

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Running application from RAM without Redboot

[Jerome Souquieres]

Gary,

Thanks for your quick answer. CYGSEM_HAL_USE_ROM_MONITOR does not work 
for me out of the box, but I will change my HAL to fit my needs in this 
configuration. Thanks again.

Jerome Souquieres

Gary Thomas wrote:

>On Fri, 2005-04-22 at 14:16 +0200, Jerome Souquieres wrote:
>  
>
>>  Hi,
>>
>>  I would like to have some advice about how to fit my specific need 
>>within the eCos structure.
>>
>>  I have written a package derived from hal\mips\idt79s334a for my own 
>>CPU board (IDT32334 MIPS-based microprocessor). So far, so good. 
>>However, the way my application is launched is a bit peculiar: I have a 
>>ROM monitor (which is NOT Redboot and which I cannot change) that simply 
>>loads an hex file at a fixed address in RAM (0x80200000, should that 
>>matter). However, to build my application under eCos, I'm in trouble to 
>>choose the startup option:
>>- CYG_HAL_STARTUP_ROM: is not available for my target. No more discussion.
>>- CYG_HAL_STARTUP_ROMRAM: not suitable. I don't need all code to be 
>>copied from RAM to ROM, I don't want the SDRAM controller to be 
>>configured (because it is obsviously already configured at this point 
>>since I'm running from RAM), I don't want the exception vectors to be 
>>located in ROM, etc...
>>- CYG_HAL_STARTUP_RAM: almost suitable,but this configuration relies on 
>>Redboot to provide exception vectors.
>>
>>  For now, what I've done is tweaking the CYG_HAL_STARTUP_RAM 
>>configuration so that it takes control of exception vectors. This works, 
>>but is a bit rough because I've somewhat changed the semantics of 
>>CYG_HAL_STARTUP_RAM.
>>
>>  Could an eCos architect give me a hint for a proper implementation ? 
>>Should I create my own CYG_HAL_STARTUP_xxx ? Should I add a sub-option ? 
>>Another idea ?
>>    
>>
>
>CYG_HAL_STARTUP_RAM is the right mode to use.  All you probably need is
>to make sure that CYGSEM_HAL_USE_ROM_MONITOR is disabled.  In this 
>setup, your application should take over the hardware completely, 
>initializing all the exceptions and I/O
>
>  
>

-- 

Jerome Souquieres

*/Ingenieur Electronique et Systemes embarques/*

Tel. : +33 (0)4 76 33 96 14

Fax : +33 (0)4 76 20 35 01

_jerome.souquieres@kis.fr <mailto:jerome.souquieres@kis.fr>_

<http://www.kis-photome.com/> <http://www.myphotoplanet.com/>

KIS, Photo-Me Group – 2110, av. du General de Gaulle – 38130 Echirolles 
– France – Tel : +33 (0)4 76 33 30 00 – www.kis-photome.com

Les informations contenues dans le present courrier electronique sont 
strictement confidentielles. Seul son ou ses destinataire(s) 
expressement indique(s) comme tel(s) est/sont autorise(s) a en prendre 
connaissance. Le fait dÂ’intercepter, de detourner, dÂ’utiliser ou de 
divulguer un courrier transmis par voie electronique est interdit et 
passible de sanctions penales en vertu de lÂ’article 226-15 du Code 
penal. Merci de repondre immediatement a tout courrier electronique reçu 
par erreur afin dÂ’en informer son expediteur, avant de le supprimer 
completement de votre ordinateur. La societe KIS (ainsi que toute 
societe du Groupe Photo-Me International) nÂ’autorise pas la conclusion 
de contrat en son nom par voie electronique. Tous les fichiers joints 
ont ete soumis a un logiciel anti-virus mis a jour regulierement. KIS 
decline toute responsabilite en matiere de dommages subis suite a un 
virus. The information contained in this e-mail is privileged and 
confidential and is intended only for the use of the addressee. 
Unauthorised interception, diversion, disclosure or use of the contents 
is strictly prohibited according to Article 226-15 of the French 
Criminal Code (“Code Pénal”). Please reply immediately if you receive 
this e-mail in error and then immediately delete it from your system. 
KIS (as well as any company of the Photo-Me International Group) does 
not authorise the creation of contracts on its behalf by e-mail. All 
attachments have been scanned for viruses using regularly updates 
programs. KIS cannot accept liability for any damage you incur as a 
result of virus infection


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss