[ECOS] redboot startup mode

[ECOS] redboot startup mode

[yrodguez]

hi,
i have a doubt/question?

i'm trying to compile a redboot in romram mode.


At http://sources.redhat.com/ecos/docs-latest/redboot/excaliburarm9.html

say that romram mode runs redboot from ram with redboot in flash. I supossed
that redboot is stored in flash memory and then it is copied from flash to ram.
But when i desassemble the file i get the code is mapped on ram (0x8000):

redboot.elf:     file format elf32-littlearm

Disassembly of section .rom_vectors:

00008000 <__exception_handlers>:
    8000:	ea00000e 	b	8040 <_stext>
    8004:	e59ff018 	ldr	pc, [pc, #24]	; 8024 <.undefined_instruction>
    8008:	e59ff018 	ldr	pc, [pc, #24]	; 8028 <.software_interrupt>
    800c:	e59ff018 	ldr	pc, [pc, #24]	; 802c <.abort_prefetch>
    8010:	e59ff018 	ldr	pc, [pc, #24]	; 8030 <.abort_data>
    8014:	00000000 	andeq	r0, r0, r0
    8018:	e59ff018 	ldr	pc, [pc, #24]	; 8038 <.IRQ>
    801c:	e59ff018 	ldr	pc, [pc, #24]	; 803c <.FIQ>

00008020 <vectors>:
    8020:	00000040 	andeq	r0, r0, r0, asr #32

00008024 <.undefined_instruction>:
    8024:	00008494 	muleq	r0, r4, r4

00008028 <.software_interrupt>:
    8028:	000084b8 	streqh	r8, [r0], -r8

etc....

Maybe i don`t  understand this mode at all.

thanks.

-- 
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] redboot startup mode

[Gary Thomas]

On Tue, 2005-05-24 at 17:41 +0100, yrodguez@iuma.ulpgc.es wrote:
> hi,
> i have a doubt/question?
> 
> i'm trying to compile a redboot in romram mode.
> 
> 
> At http://sources.redhat.com/ecos/docs-latest/redboot/excaliburarm9.html
> 
> say that romram mode runs redboot from ram with redboot in flash. I supossed
> that redboot is stored in flash memory and then it is copied from flash to ram.
> But when i desassemble the file i get the code is mapped on ram (0x8000):
> 

Correct.  It has to be that way - the linker produces an image suitable
for running from RAM.  That said, the image will be stored in FLASH 
(typically this is all that's accessible immediately after RESET).  The
program [RedBoot or whatever] then does some minimal hardware 
initialization, e.g. turning on the SDRAM controller, setting up mapping
registers, etc.  The code is then copied from FLASH to its ultimate RAM
destination and control is then passed there.  Now you are running from
RAM only.  It's up to the startup code to understand all of this and
it must contain [normally position-independent] code that performs these
steps at startup.

Note: this mode is only suitable for *the* initial "ROM" monitor code,
like RedBoot.  This is not how you would write a generic program which
runs in RAM but whose image was stored in FLASH.  For that, you use
RedBoot's FIS commands (create, load)

-- 
------------------------------------------------------------
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] redboot startup mode

[Gary Thomas]

Please reply to the eCos mailing list so that all may benefit.  Private
support is available under contract (from MLB Associates or others)

On Tue, 2005-05-24 at 17:58 +0100, yrodguez@iuma.ulpgc.es wrote:
> But, who exactly have to copy redboot code from flash to ram?, I'm 

Look in the platform startup code:
  <ecos>/packages/arm/arm9/excalibur/current/include/hal_platform_setup.h

> sorry, maybe
> i don't understand it due to my bad level in english
> 
> thanks.
> 
> Quoting Gary Thomas <gary@mlbassoc.com>:
> 
> > On Tue, 2005-05-24 at 17:41 +0100, yrodguez@iuma.ulpgc.es wrote:
> >> hi,
> >> i have a doubt/question?
> >>
> >> i'm trying to compile a redboot in romram mode.
> >>
> >>
> >> At http://sources.redhat.com/ecos/docs-latest/redboot/excaliburarm9.html
> >>
> >> say that romram mode runs redboot from ram with redboot in flash. I supossed
> >> that redboot is stored in flash memory and then it is copied from 
> >> flash to ram.
> >> But when i desassemble the file i get the code is mapped on ram (0x8000):
> >>
> >
> > Correct.  It has to be that way - the linker produces an image suitable
> > for running from RAM.  That said, the image will be stored in FLASH
> > (typically this is all that's accessible immediately after RESET).  The
> > program [RedBoot or whatever] then does some minimal hardware
> > initialization, e.g. turning on the SDRAM controller, setting up mapping
> > registers, etc.  The code is then copied from FLASH to its ultimate RAM
> > destination and control is then passed there.  Now you are running from
> > RAM only.  It's up to the startup code to understand all of this and
> > it must contain [normally position-independent] code that performs these
> > steps at startup.
> >
> > Note: this mode is only suitable for *the* initial "ROM" monitor code,
> > like RedBoot.  This is not how you would write a generic program which
> > runs in RAM but whose image was stored in FLASH.  For that, you use
> > RedBoot's FIS commands (create, load)
> >
> > --
> > ------------------------------------------------------------
> > Gary Thomas                 |  Consulting for the
> > MLB Associates              |    Embedded world
> > ------------------------------------------------------------
> >
> >
> 
> 
-- 
------------------------------------------------------------
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] redboot startup mode

[yrodguez]

Quoting Gary Thomas <gary@mlbassoc.com>:

> Please reply to the eCos mailing list so that all may benefit.  Private
> support is available under contract (from MLB Associates or others)

I'm Sorry.

>
> On Tue, 2005-05-24 at 17:58 +0100, yrodguez@iuma.ulpgc.es wrote:
>> But, who exactly have to copy redboot code from flash to ram?, I'm
>
> Look in the platform startup code:
>  <ecos>/packages/arm/arm9/excalibur/current/include/hal_platform_setup.h
>

My question is: do i need another startup code, different to redboot, to use
this mode or is enough with redboot?

thanks, and, I'm sorry again.

>> sorry, maybe
>> i don't understand it due to my bad level in english
>>
>> thanks.
>>
>> Quoting Gary Thomas <gary@mlbassoc.com>:
>>
>> > On Tue, 2005-05-24 at 17:41 +0100, yrodguez@iuma.ulpgc.es wrote:
>> >> hi,
>> >> i have a doubt/question?
>> >>
>> >> i'm trying to compile a redboot in romram mode.
>> >>
>> >>
>> >> At http://sources.redhat.com/ecos/docs-latest/redboot/excaliburarm9.html
>> >>
>> >> say that romram mode runs redboot from ram with redboot in flash. 
>> I supossed
>> >> that redboot is stored in flash memory and then it is copied from
>> >> flash to ram.
>> >> But when i desassemble the file i get the code is mapped on ram (0x8000):
>> >>
>> >
>> > Correct.  It has to be that way - the linker produces an image suitable
>> > for running from RAM.  That said, the image will be stored in FLASH
>> > (typically this is all that's accessible immediately after RESET).  The
>> > program [RedBoot or whatever] then does some minimal hardware
>> > initialization, e.g. turning on the SDRAM controller, setting up mapping
>> > registers, etc.  The code is then copied from FLASH to its ultimate RAM
>> > destination and control is then passed there.  Now you are running from
>> > RAM only.  It's up to the startup code to understand all of this and
>> > it must contain [normally position-independent] code that performs these
>> > steps at startup.
>> >
>> > Note: this mode is only suitable for *the* initial "ROM" monitor code,
>> > like RedBoot.  This is not how you would write a generic program which
>> > runs in RAM but whose image was stored in FLASH.  For that, you use
>> > RedBoot's FIS commands (create, load)
>> >
>> > --
>> > ------------------------------------------------------------
>> > Gary Thomas                 |  Consulting for the
>> > MLB Associates              |    Embedded world
>> > ------------------------------------------------------------
>> >
>> >
>>
>>
> --
> ------------------------------------------------------------
> 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

[ECOS] Clean room module loader + GPL module + Application

[C.J.]

Hi,
I know eCos mod-GPL have been discussed several times.
I also understand that eCos is not GPL compatible --- 
Using GPL code in eCos kernel will force the license 
of eCos application GPL.

GNU GPL (http://www.gnu.org/copyleft/gpl.html) states:
   The source code for a work means the preferred form of the work for making modifications to it. 
   For an executable work, complete source code means all the source code for all modules it contains, 
   plus any associated interface definition files, plus the scripts used to control compilation and 
   installation of the executable. 
   However, as a special exception, the source code distributed need 
   not include anything that is normally distributed (in either source or binary form) with the major 
   components (compiler, kernel, and so on) of the operating system on which the executable runs, 
   unless that component itself accompanies the executable. 

Considering only legal issues (just ignore any technical or code size issue), 
If an eCos system is implemented like this:
(a) eCos kerenl (mod-GPL)
(b) Clean room module loader  (closed license)
(c) A GPL module registers itself as "/dev/storage" (GPL)
(d) Clean room application, mount  "/dev/storage" and use eCos POSIX layer (via FAT filesystem) 
      to access the device (closed license).

Does the GPL "special exception" apply to this situation?
Is it legal If the provider do not release the source code of  (b) and (d)?

Best Regards,
C.J.

Re: [ECOS] Clean room module loader + GPL module + Application

[Bart Veer]

>>>>> " " == Retallack, Mark (Siemens) <mark.retallack@siemens.com> writes:

     > I know eCos mod-GPL have been discussed several times. I also
     > understand that eCos is not GPL compatible

Incorrect. The old RHEPL license was incompatible with the GPL. The
current GPL+exception license is compatible.

     >  --- Using GPL code in eCos kernel will force the license of
     > eCos application GPL.

The reference to the eCos kernel is irrelevant. Using GPL code means
that you have to comply with the terms of that license. If your
application makes use of two other bits of code released under
different licenses then it must comply with the terms of both
licenses. You cannot ignore the license of one just because the other
happens to be released on more liberal terms.

For an analogy, suppose your application makes use of a proprietary OS
and a proprietary device driver supplied by a different software
company. You would expect to pay two license fees, one to the OS
company and one to the company providing the driver. You cannot avoid
paying the OS license fee because you are paying somebody else for
different software.

     <snip>

     > Considering only legal issues (just ignore any technical or
     > code size issue),

You cannot get a definitive answer to legal questions on this mailing
list. Instead you need to consult a copyright lawyer who understands
these issues, including legal variations between all the countries
where you expect to do business.

     > If an eCos system is implemented like this:
     > (a) eCos kerenl (mod-GPL)
     > (b) Clean room module loader  (closed license)
     > (c) A GPL module registers itself as "/dev/storage" (GPL)
     > (d) Clean room application, mount "/dev/storage" and use eCos
     > POSIX layer (via FAT filesystem) to access the device (closed
     > license).

     > Does the GPL "special exception" apply to this situation? Is it
     > legal If the provider do not release the source code of (b) and
     > (d)?

My understanding is that (b) is fine. Such a module loader would be
equivalent to application code and hence can be kept proprietary.

However (d) is not fine. The application depends on the GPL'd code. My
understanding is that legally this makes it a derived work and hence
subject to the terms of the GPL. You cannot just bypass the GPL by
adding a few indirections, copyright law does not work like that.
Similarly under Linux you cannot just take GPL'd code like the gcc
code generator, turn it into a shared library, and then link your
proprietary application with the shared library.

And before people start quoting the Linux kernel as a counter example,
it has an explicit exemption allowing application code to use kernel
services by the normal Linux system calls. See the top level COPYING
file in the kernel sources. No such exemption applies in your
scenario.

I am not a lawyer and this is not official legal advice. If in doubt
then you need to consult somebody suitably qualified to answer these
questions.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


-- 
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] Clean room module loader + GPL module + Application

[Retallack, Mark (Siemens)]

Opps. Mised not the important bit.

If the Clean room module loader, is realy fully clean room (including
headers etc..), and the GPL module is loaded at runtime. And there are
no GPL sources in the eCos kernel and application, then this should be
ok. But then the question is: Where will the GPL module be stored before
loading? I don't think it could be staticly linked with the
eCos+application binary (like an image used in the HTTP server). It
would need to be stored on the filesystem. 

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of C.J.
Sent: 24 May 2005 18:47
To: ecos-discuss@ecos.sourceware.org
Subject: [ECOS] Clean room module loader + GPL module + Application


Hi,
I know eCos mod-GPL have been discussed several times.
I also understand that eCos is not GPL compatible --- 
Using GPL code in eCos kernel will force the license 
of eCos application GPL.

GNU GPL (http://www.gnu.org/copyleft/gpl.html) states:
   The source code for a work means the preferred form of the work for
making modifications to it. 
   For an executable work, complete source code means all the source
code for all modules it contains, 
   plus any associated interface definition files, plus the scripts used
to control compilation and 
   installation of the executable. 
   However, as a special exception, the source code distributed need 
   not include anything that is normally distributed (in either source
or binary form) with the major 
   components (compiler, kernel, and so on) of the operating system on
which the executable runs, 
   unless that component itself accompanies the executable. 

Considering only legal issues (just ignore any technical or code size
issue), 
If an eCos system is implemented like this:
(a) eCos kerenl (mod-GPL)
(b) Clean room module loader  (closed license)
(c) A GPL module registers itself as "/dev/storage" (GPL)
(d) Clean room application, mount  "/dev/storage" and use eCos POSIX
layer (via FAT filesystem) 
      to access the device (closed license).

Does the GPL "special exception" apply to this situation?
Is it legal If the provider do not release the source code of  (b) and
(d)?

Best Regards,
C.J.




--
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] Clean room module loader + GPL module + Application

[Retallack, Mark (Siemens)]

I am sure others will be able to answer this in a better way, but: 

First off, eCos is (now) GPL compatible. It has an exception for static
linking against a closed source application.

If any GPL source is introduced into the eCos+Applicaion mix, and it
does not have a similar exception, then the whole
eCos+Application+OtherApp mix will become GPL. The only way to prevent
this is to not statically link the OtherApp. This would require runtime
dynamic linking and a very careful development process.   

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of C.J.
Sent: 24 May 2005 18:47
To: ecos-discuss@ecos.sourceware.org
Subject: [ECOS] Clean room module loader + GPL module + Application


Hi,
I know eCos mod-GPL have been discussed several times.
I also understand that eCos is not GPL compatible --- 
Using GPL code in eCos kernel will force the license 
of eCos application GPL.

GNU GPL (http://www.gnu.org/copyleft/gpl.html) states:
   The source code for a work means the preferred form of the work for
making modifications to it. 
   For an executable work, complete source code means all the source
code for all modules it contains, 
   plus any associated interface definition files, plus the scripts used
to control compilation and 
   installation of the executable. 
   However, as a special exception, the source code distributed need 
   not include anything that is normally distributed (in either source
or binary form) with the major 
   components (compiler, kernel, and so on) of the operating system on
which the executable runs, 
   unless that component itself accompanies the executable. 

Considering only legal issues (just ignore any technical or code size
issue), 
If an eCos system is implemented like this:
(a) eCos kerenl (mod-GPL)
(b) Clean room module loader  (closed license)
(c) A GPL module registers itself as "/dev/storage" (GPL)
(d) Clean room application, mount  "/dev/storage" and use eCos POSIX
layer (via FAT filesystem) 
      to access the device (closed license).

Does the GPL "special exception" apply to this situation?
Is it legal If the provider do not release the source code of  (b) and
(d)?

Best Regards,
C.J.




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