[ECOS] Re: Re: unable to execute linux kernel with Redboot

[ECOS] Re: Re: unable to execute linux kernel with Redboot

[Claudio Scordino]

On Monday 04 September 2006 12:20, Claudio Scordino wrote:
> >>>>> Jan van de Wijdeven writes:
> >
> > Hi,
> > I'm unable to run a linux kernel from the Redboot bootloader. I'm
> > using a XScale board through a serial port.
> >
> > First I load the zImage into memory with the "load" command. Then I
> > give the "exec" command. This doesn't do anything and I have to reset
> > the board. I've been trying to find a solution and some people speak
> > of an entry point for the linux kernel. My redboot manual states this
> > to be 0xc0008000 for the SA1100, but since this processor is similar
> > to the XScale I tried that one.
> > Here's the command I give:
>
> 0xc0008000 is the kernel entry point, not the zImage entry port. And its
> wrong for XScale.
>
> RedBoot> exec 0xc0008000 -c "console=ttyS0,115200n8"
>
> > Using base address 0x00017c00 and length 0x000b1660
> >
> > Then nothing happens.
>
> No surprise.
>
> > Can anyone tell me what I'm doing wrong? The redboot manual doesn't
> > give me any more information.
>
> You need to find out where the zImage wants to be. This depends on the
> kernel version with later zImage being relocatable. If not relocatable,
> you want to use ZTEXTADDR. ZTEXTADDR is a physical address, so you need
> to convert to virtual address for RedBoot to use for the load command.
> ZTEXTADDR is typically defined in arch/arm/boot/Makefile.
>
> So, assume ZTEXTADDR is 0xA0080000. Just clear the top bits to get the
> virtual address in RedBoot (at least for most XScale boards). In this
> case, 0x80000. Therefore, something like this should work:
>
>   RedBoot> load -r -b 0x80000 zImage
>   RedBoot> exec -b 0x80000 -l 0 -c "console=ttyS0,115200" 0xA0080000
>
> Note that the last part of the exec command is the physical address.
> This should also work for a relocatable zImage.

Hi,

     I'm having the same problem with my IXDP465 board with RedBoot 2.02.

My documentation suggests to use

load -r -v -b 0x01600000 zImage
load -r -v -b 0x00800000 ramdisk.gz

which does not work.

My linux-2.6.x/arch/arm/boot/compressed/Makefile sets ZTEXTADDR to 0, so
based on Mark's instructions, my RedBoot commands would be something like 

RedBoot> load -r -b 0x0000 zImage
RedBoot> exec -b 0x0000 -l 0 -c "console=ttyS0,115200" 0x000000

which is very odd, and probably makes no sense.

Any suggestion is welcome.

Many thanks,

                Claudio

-- 
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] Re: unable to execute linux kernel with Redboot

[Amitesh Singh]

Hi
 I am assuming that ur RootFS lives in RAM.
RedBoot>load -r -v -b 0x01600000
RedBot> load -r -v -b 0x00800000 ramdisk.gz
RedBoot> exec -b 0x01600000 -l 0x10000 -c "console=ttyS0,115200
root=/dev/ram0 initrd=0x00800000,8M mem=32M@0x00000000"

Note: 8M is ur RamDisk size and 32M is ur SD RAM size.

Let me know if it works.

Best Regards
Amitesh Singh
http://www.amitesh.info



On 9/4/06, Claudio Scordino <cloud.of.andor@gmail.com> wrote:
> On Monday 04 September 2006 12:20, Claudio Scordino wrote:
> > >>>>> Jan van de Wijdeven writes:
> > >
> > > Hi,
> > > I'm unable to run a linux kernel from the Redboot bootloader. I'm
> > > using a XScale board through a serial port.
> > >
> > > First I load the zImage into memory with the "load" command. Then I
> > > give the "exec" command. This doesn't do anything and I have to reset
> > > the board. I've been trying to find a solution and some people speak
> > > of an entry point for the linux kernel. My redboot manual states this
> > > to be 0xc0008000 for the SA1100, but since this processor is similar
> > > to the XScale I tried that one.
> > > Here's the command I give:
> >
> > 0xc0008000 is the kernel entry point, not the zImage entry port. And its
> > wrong for XScale.
> >
> > RedBoot> exec 0xc0008000 -c "console=ttyS0,115200n8"
> >
> > > Using base address 0x00017c00 and length 0x000b1660
> > >
> > > Then nothing happens.
> >
> > No surprise.
> >
> > > Can anyone tell me what I'm doing wrong? The redboot manual doesn't
> > > give me any more information.
> >
> > You need to find out where the zImage wants to be. This depends on the
> > kernel version with later zImage being relocatable. If not relocatable,
> > you want to use ZTEXTADDR. ZTEXTADDR is a physical address, so you need
> > to convert to virtual address for RedBoot to use for the load command.
> > ZTEXTADDR is typically defined in arch/arm/boot/Makefile.
> >
> > So, assume ZTEXTADDR is 0xA0080000. Just clear the top bits to get the
> > virtual address in RedBoot (at least for most XScale boards). In this
> > case, 0x80000. Therefore, something like this should work:
> >
> >   RedBoot> load -r -b 0x80000 zImage
> >   RedBoot> exec -b 0x80000 -l 0 -c "console=ttyS0,115200" 0xA0080000
> >
> > Note that the last part of the exec command is the physical address.
> > This should also work for a relocatable zImage.
>
> Hi,
>
>      I'm having the same problem with my IXDP465 board with RedBoot 2.02.
>
> My documentation suggests to use
>
> load -r -v -b 0x01600000 zImage
> load -r -v -b 0x00800000 ramdisk.gz
>
> which does not work.
>
> My linux-2.6.x/arch/arm/boot/compressed/Makefile sets ZTEXTADDR to 0, so
> based on Mark's instructions, my RedBoot commands would be something like
>
> RedBoot> load -r -b 0x0000 zImage
> RedBoot> exec -b 0x0000 -l 0 -c "console=ttyS0,115200" 0x000000
>
> which is very odd, and probably makes no sense.
>
> Any suggestion is welcome.
>
> Many thanks,
>
>                 Claudio
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
>

-- 
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] Re: unable to execute linux kernel with Redboot

[Amitesh Singh]

On 9/5/06, Claudio Scordino <cloud.of.andor@gmail.com> wrote:
> On Monday 04 September 2006 13:14, Amitesh Singh wrote:
> > Hi
> >  I am assuming that ur RootFS lives in RAM.
> > RedBoot>load -r -v -b 0x01600000
> > RedBot> load -r -v -b 0x00800000 ramdisk.gz
> > RedBoot> exec -b 0x01600000 -l 0x10000 -c "console=ttyS0,115200
> > root=/dev/ram0 initrd=0x00800000,8M mem=32M@0x00000000"
> >
> > Note: 8M is ur RamDisk size and 32M is ur SD RAM size.
> >
> > Let me know if it works.
>
>
> It worked and I  was able to succcesfully run a big-endian kernel :) Many
> thanks.
>
> I also tried to execute a little-endian kernel on the target, using the
> "-x" option of the exec command, but it didn't work.
>
> Many thanks,
>
>                      Claudio
>
>
Hi,
Cool,its good to know that it worked for Big-endian kernel. :)

For little endian kernel.

use Swab to byteswap the image before executing the kernel.
1)load the kernel
2)byteswap the kernel using swab command
3)execute it using exec command with -x switch.

It should work.


Good Luck
Amitesh
http://www.amitesh.info

-- 
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] Re: unable to execute linux kernel with Redboot

[Claudio Scordino]

On Tuesday 05 September 2006 15:50, Amitesh Singh wrote:
> On 9/5/06, Claudio Scordino <cloud.of.andor@gmail.com> wrote:
> > On Monday 04 September 2006 13:14, Amitesh Singh wrote:
> > > Hi
> > >  I am assuming that ur RootFS lives in RAM.
> > > RedBoot>load -r -v -b 0x01600000
> > > RedBot> load -r -v -b 0x00800000 ramdisk.gz
> > > RedBoot> exec -b 0x01600000 -l 0x10000 -c "console=ttyS0,115200
> > > root=/dev/ram0 initrd=0x00800000,8M mem=32M@0x00000000"
> > >
> > > Note: 8M is ur RamDisk size and 32M is ur SD RAM size.
> > >
> > > Let me know if it works.
> >
> > It worked and I  was able to succcesfully run a big-endian kernel :)
> > Many thanks.
> >
> > I also tried to execute a little-endian kernel on the target, using
> > the "-x" option of the exec command, but it didn't work.
> >
> > Many thanks,
> >
> >                      Claudio
>
> Hi,
> Cool,its good to know that it worked for Big-endian kernel. :)
>
> For little endian kernel.
>
> use Swab to byteswap the image before executing the kernel.
> 1)load the kernel
> 2)byteswap the kernel using swab command
> 3)execute it using exec command with -x switch.
>
> It should work.

It worked !! (I never tried both the options at the same time). 

Your help was really precious.

Many thanks,

                 Claudio


-- 
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] little mistake in redboot.cdl?

[Wang Cui]

The description of CYGSEM_REDBOOT_DISK_EXT2FS component is: "When this
option is enabled, RedBoot will support IDE disks."
It is exactly same as the description of CYGSEM_REDBOOT_DISK_IDE component.
Shouldn't they be different?


-- 
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] How to build a executed-in-flash application?

[Wang Cui]

As I know, normally RedBoot use startup type "ROM", and application use
startup type "RAM", then we can use RedBoot "load" application into ram and
"go" it.

On my target board, this method works pretty well now. But since the ram
size is only 512K, I want the application image executed-in-place in the
flash to save ram for usage.

Could anyone give me some advices for it? Thanks in advance.



-- 
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] How to build a executed-in-flash application?

[Andrew Lunn]

On Thu, Sep 07, 2006 at 01:42:07PM +0800, Wang Cui wrote:
> As I know, normally RedBoot use startup type "ROM", and application use
> startup type "RAM", then we can use RedBoot "load" application into ram and
> "go" it.
> 
> On my target board, this method works pretty well now. But since the ram
> size is only 512K, I want the application image executed-in-place in the
> flash to save ram for usage.
> 
> Could anyone give me some advices for it? Thanks in advance.

You need to make a custom set of .ldi and .h files in the
$HAL/current/include/pkgconf directory. This should be set so that the
image is linked for the location it will be in FLASH. 

To execute it, just do

go <address_in_flash>

   Andrew

-- 
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] How to build a executed-in-flash application?

[wang cui]

Thank you Andrew. I have create and run it successfully. 

There are still little problem: 
Since the applications has been wrote into flash, how to use "fis create" 
command to add it into FIS? I tried "fis create -n twothreads", but doesn't 
work. It report "*** invalid 'fis' command: required parameter missing".

However, I can use "fis create twothreads" to directly add the application 
after "load".

>From: Andrew Lunn <andrew@lunn.ch>
>To: Wang Cui <iucgnaw@msn.com>
>CC: ecos-discuss@sources.redhat.com
>Subject: Re: [ECOS] How to build a executed-in-flash application?
>Date: Thu, 7 Sep 2006 09:38:20 +0200
>
>On Thu, Sep 07, 2006 at 01:42:07PM +0800, Wang Cui wrote:
> > As I know, normally RedBoot use startup type "ROM", and application use
> > startup type "RAM", then we can use RedBoot "load" application into ram 
and
> > "go" it.
> >
> > On my target board, this method works pretty well now. But since the 
ram
> > size is only 512K, I want the application image executed-in-place in 
the
> > flash to save ram for usage.
> >
> > Could anyone give me some advices for it? Thanks in advance.
>
>You need to make a custom set of .ldi and .h files in the
>$HAL/current/include/pkgconf directory. This should be set so that the
>image is linked for the location it will be in FLASH.
>
>To execute it, just do
>
>go <address_in_flash>
>
>    Andrew
>
>--
>Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
>and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>



-- 
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] How to build a executed-in-flash application?

[Andrew Lunn]

On Thu, Sep 07, 2006 at 09:35:40AM +0000, wang cui wrote:
> Thank you Andrew. I have create and run it successfully. 
> 
> There are still little problem: 
> Since the applications has been wrote into flash, how to use "fis create" 
> command to add it into FIS? I tried "fis create -n twothreads", but doesn't 
> work. It report "*** invalid 'fis' command: required parameter missing".
> 
> However, I can use "fis create twothreads" to directly add the application 
> after "load".

You probably need to pass all the parameters. Eg the example in the
documentation at 
http://ecos.sourceware.org/docs-latest/redboot/fis-create-command.html

is

fis create RedBoot -f 0xa0000000 -b 0x8c400000 -l 0x20000

ie load it into flash at address 0xa0000000 from RAM address
0x8c400000 with 0x20000 bytes of image data.

    Andrew

-- 
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] How to build a executed-in-flash application?

[wang cui]

You are right.

I looked through the source code:
Because the last "load" write the image into flash, which means the values 
of "entry_address/load_address/load_address_end" are not located in the 
"ram_start - ram_end" region.
So these values are treated as invalid in fis_create() function.

I use the commands below and it works.
"fis create -f 0x80040000 -l 0x000C0000 -n twothreads"
"go 0x80040000"

>From: Andrew Lunn <andrew@lunn.ch>
>To: wang cui <iucgnaw@msn.com>
>CC: andrew@lunn.ch, ecos-discuss@sources.redhat.com
>Subject: Re: [ECOS] How to build a executed-in-flash application?
>Date: Thu, 7 Sep 2006 11:43:43 +0200
>
>On Thu, Sep 07, 2006 at 09:35:40AM +0000, wang cui wrote:
> > Thank you Andrew. I have create and run it successfully.
> >
> > There are still little problem:
> > Since the applications has been wrote into flash, how to use "fis 
create"
> > command to add it into FIS? I tried "fis create -n twothreads", but 
doesn't
> > work. It report "*** invalid 'fis' command: required parameter 
missing".
> >
> > However, I can use "fis create twothreads" to directly add the 
application
> > after "load".
>
>You probably need to pass all the parameters. Eg the example in the
>documentation at
>http://ecos.sourceware.org/docs-latest/redboot/fis-create-command.html
>
>is
>
>fis create RedBoot -f 0xa0000000 -b 0x8c400000 -l 0x20000
>
>ie load it into flash at address 0xa0000000 from RAM address
>0x8c400000 with 0x20000 bytes of image data.
>
>     Andrew



-- 
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] How to build a executed-in-flash application?

[Bart Veer]

>>>>> "Wang" == Wang Cui <iucgnaw@msn.com> writes:

    Wang> As I know, normally RedBoot use startup type "ROM", and
    Wang> application use startup type "RAM", then we can use RedBoot
    Wang> "load" application into ram and "go" it.

    Wang> On my target board, this method works pretty well now. But
    Wang> since the ram size is only 512K, I want the application
    Wang> image executed-in-place in the flash to save ram for usage.

Having a ROM RedBoot and a RAM application is only one of the standard
scenarios. If you want the application to run from flash then there
should be no need to have RedBoot in the system at all. Instead
configure eCos itself for ROM startup, link your application with
that, and install it in place of RedBoot. The application now has
control over all the hardware. The obvious caveats are:

  1) you need some way of programming the flash without RedBoot. This
     is likely to involve a hardware debug solution such as BDM or
     jtag.

  2) debugging applications in flash is generally a lot harder than
     ones in RAM (although that is going to be a problem whenever code
     resides in flash, irrespective of whether or not RedBoot is
     involved).

  3) upgrading an application in the field becomes more difficult.

  4) not all platforms will be tested in this scenario. Depending on
     your hardware there may be platform HAL issues.

Andrew has been describing an alternative approach where RedBoot is
still in use and the application resides in a non-standard location in
flash. That can also be made to work, but having a ROM startup
application would be more conventional.

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] How to build a executed-in-flash application?

[wang cui]

Thank you, Bart.

Actually, I did think about the caveats you mentioned, and my product 
really need the "in the field update" function. That's why I need a ROM 
RedBoot and ROM applications. 
With the help of Andrew, I have done it.

Anyway, your reply clarifies this issue for me.

>From: Bart Veer <bartv@ecoscentric.com>
>To: iucgnaw@msn.com
>CC: ecos-discuss@sources.redhat.com
>Subject: Re: [ECOS] How to build a executed-in-flash application?
>Date: 07 Sep 2006 14:38:37 +0100
>
> >>>>> "Wang" == Wang Cui <iucgnaw@msn.com> writes:
>
>     Wang> As I know, normally RedBoot use startup type "ROM", and
>     Wang> application use startup type "RAM", then we can use RedBoot
>     Wang> "load" application into ram and "go" it.
>
>     Wang> On my target board, this method works pretty well now. But
>     Wang> since the ram size is only 512K, I want the application
>     Wang> image executed-in-place in the flash to save ram for usage.
>
>Having a ROM RedBoot and a RAM application is only one of the standard
>scenarios. If you want the application to run from flash then there
>should be no need to have RedBoot in the system at all. Instead
>configure eCos itself for ROM startup, link your application with
>that, and install it in place of RedBoot. The application now has
>control over all the hardware. The obvious caveats are:
>
>   1) you need some way of programming the flash without RedBoot. This
>      is likely to involve a hardware debug solution such as BDM or
>      jtag.
>
>   2) debugging applications in flash is generally a lot harder than
>      ones in RAM (although that is going to be a problem whenever code
>      resides in flash, irrespective of whether or not RedBoot is
>      involved).
>
>   3) upgrading an application in the field becomes more difficult.
>
>   4) not all platforms will be tested in this scenario. Depending on
>      your hardware there may be platform HAL issues.
>
>Andrew has been describing an alternative approach where RedBoot is
>still in use and the application resides in a non-standard location in
>flash. That can also be made to work, but having a ROM startup
>application would be more conventional.
>
>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

[ECOS] Re: Re: unable to execute linux kernel with Redboot

[Mark Salter]

On Mon, 2006-09-04 at 12:34 +0200, Claudio Scordino wrote:

>      I'm having the same problem with my IXDP465 board with RedBoot 2.02.
> 
> My documentation suggests to use
> 
> load -r -v -b 0x01600000 zImage
> load -r -v -b 0x00800000 ramdisk.gz
> 
> which does not work.
> 
> My linux-2.6.x/arch/arm/boot/compressed/Makefile sets ZTEXTADDR to 0, so
> based on Mark's instructions, my RedBoot commands would be something like 
> 
> RedBoot> load -r -b 0x0000 zImage
> RedBoot> exec -b 0x0000 -l 0 -c "console=ttyS0,115200" 0x000000
> 
> which is very odd, and probably makes no sense.

No it doesn't and I hope I didn't suggest it. :)

Zero ZTEXTADDR is normal for the position independent decompressor.

There is a CDL option to set the default exec address of the kernel. For
IXDP465 it is:

cdl_option CYGHWR_REDBOOT_ARM_LINUX_EXEC_ADDRESS_DEFAULT {
    inferred_value 0x6000000
};

I don't recall why we ended up with that, but the address is largely
arbitrary. To override this, you have to specify the desired address
on the exec commandline. The exec command will try to move the kernel
from the -b <addr> address to the exec address. This isn't really
necessary with a self decompressing image as the decompressor will
do this for you. Just specify "-l 0" to prevent this move. So, I
think something like this will work for you:

   RedBoot> load -r -b 0x1600000 zImage
   RedBoot> exec -b 0x1600000 -l 0 -c "console=ttyS0,115200" 0x1600000


--Mark




-- 
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] Multiple code images in flash

[Laurie Gellatly]

Hi All,
I am developing an ARM based system that has room in flash for maybe 3
copies of its code.
There is insufficient room in RAM for a copy of the code to run so the app
must run from flash.
I'd like to provide a system that can support downloadable firmware updates.

I believe that the app code is position dependant so although I could have
copies at different flash locations it becomes messy to maintain.

I'm interested in hearing how others have solved this problem.

Also, I gather that I'll need to run any flash programming from RAM rather
than from an unaffected section of flash.
I'm interested in hearing how this affects and is catered for in the
solution.

Thanks			...Laurie:{)


-- 
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] Multiple code images in flash

[Bart Veer]

>>>>> "Laurie" == Laurie Gellatly <laurie.gellatly@netic.com> writes:

    Laurie> Hi All,
    Laurie> I am developing an ARM based system that has room in flash
    Laurie> for maybe 3 copies of its code. There is insufficient room
    Laurie> in RAM for a copy of the code to run so the app must run
    Laurie> from flash. I'd like to provide a system that can support
    Laurie> downloadable firmware updates.

    Laurie> I believe that the app code is position dependant so
    Laurie> although I could have copies at different flash locations
    Laurie> it becomes messy to maintain.

    Laurie> I'm interested in hearing how others have solved this
    Laurie> problem.

You do not say whether or not the application is an eCos one. eCos
applications are not position-independent, they are linked to run at
specific addresses. That is fine if the application will end up
running from RAM, but not if it may run from one of three locations in
the flash. To complicate things further, if the code is in flash then
you cannot achieve position-indepence by having some relocation info
within the image and then going through the image at run-time to
adjust various addresses. So what you are describing is very hard. It
might be possible to do something with an MMU, but I do not think
anybody has solved this particular problem in the eCos world before.

    Laurie> Also, I gather that I'll need to run any flash programming
    Laurie> from RAM rather than from an unaffected section of flash.
    Laurie> I'm interested in hearing how this affects and is catered
    Laurie> for in the solution.

eCos flash drivers arrange for the critical low-level flash
manipulation functions to reside in RAM, even if the main application
runs from flash. Look at a typical flash driver and search for .2ram
sections. Care still has to be taken, e.g. you do not want an
interrupt to go off while the flash is in a funny state if the
interrupt handler resides in flash.

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] Multiple code images in flash

[Ilija Koco]

Bart Veer wrote:
> You do not say whether or not the application is an eCos one. eCos
> applications are not position-independent, they are linked to run at
> specific addresses.
Could it be possible with some compile/link options to produce position
independent code? I have experience with other RTOS (Microware OS-9)
that is completely position independent, and I may say that it would
bring a benefit. It would provide simple method for dynamic loading of
user applications, remote (through net) updates, etc.

I would like to have some comments from eCos architects.

Regards
Ilija



-- 
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] Multiple code images in flash

[Bart Veer]

>>>>> "Ilija" == Ilija Koco <ilijak@siva.com.mk> writes:

    Ilija> Bart Veer wrote:
    >> You do not say whether or not the application is an eCos one.
    >> eCos applications are not position-independent, they are linked
    >> to run at specific addresses.
    Ilija> Could it be possible with some compile/link options to
    Ilija> produce position independent code? I have experience with
    Ilija> other RTOS (Microware OS-9) that is completely position
    Ilija> independent, and I may say that it would bring a benefit.
    Ilija> It would provide simple method for dynamic loading of user
    Ilija> applications, remote (through net) updates, etc.

Position-independent code that resides in flash and with no MMU
mangling? Rather tricky. Consider the following:

    const CYG_FLASH_FUNS(cyg_mcf52xx_cfm_core_funs,
               &cyg_mcf52xx_cfm_init,
               &cyg_flash_devfn_query_nop,
               &cyg_mcf52xx_cfm_erase,
               &cyg_mcf52xx_cfm_program,
               (int (*)(struct cyg_flash_dev*, const cyg_flashaddr_t, void*, size_t))0,
               0,
               0
    );

i.e. define a data structure that contains a number of function
pointers like &cyg_mcf52xx_cfm_init(). That statically initialized
data structure needs to have the real function addresses, no amount of
PC-relative addressing in the instruction set is going to help with
that. Because the structure is const it is going to reside in flash
rather than RAM, so there is no opportunity at run-time to process
relocation information and update the data structure.

So either:

  1) ban this sort of construct. Sorry, but there may be any number of
     places within the existing source code that already uses such
     constructs.

  2) use an MMU to rearrange the memory map to match what the
     application expects. By design eCos does not play games with the
     MMU like that.

  3) perform some sort of relocation as you are programming the
     application into flash at one of the three addresses.

  4) forget about position-independent code and link for a fixed
     address, which is the way eCos is designed to work. In theory you
     could link your application three times, once for each of the
     valid addresses, and install the appropriate application image
     when you have decided which block of flash to overwrite.

    Ilija> I would like to have some comments from eCos architects.

Check my signature.

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] Multiple code images in flash

[Laurie Gellatly]

All,
Thanks for all the replies. Yes, this is an eCos application.
I was hoping that either someone would say you run this fancy load routine
and it does the reloaction for you
OR
We always run from the same flash location and this is how we manage the 3
copies we do xxx and copy
and erase and ... and then we are using the new version.

The first one sounds impossible to me now.
Sounds like the second approach is still possible.
Anyone done that?			...Laurie:{)


-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org]On Behalf Of Bart Veer
Sent: Tuesday, 5 September 2006 7:27 PM
To: ilijak@siva.com.mk
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] Multiple code images in flash


>>>>> "Ilija" == Ilija Koco <ilijak@siva.com.mk> writes:

    Ilija> Bart Veer wrote:
    >> You do not say whether or not the application is an eCos one.
    >> eCos applications are not position-independent, they are linked
    >> to run at specific addresses.
    Ilija> Could it be possible with some compile/link options to
    Ilija> produce position independent code? I have experience with
    Ilija> other RTOS (Microware OS-9) that is completely position
    Ilija> independent, and I may say that it would bring a benefit.
    Ilija> It would provide simple method for dynamic loading of user
    Ilija> applications, remote (through net) updates, etc.

Position-independent code that resides in flash and with no MMU
mangling? Rather tricky. Consider the following:

    const CYG_FLASH_FUNS(cyg_mcf52xx_cfm_core_funs,
               &cyg_mcf52xx_cfm_init,
               &cyg_flash_devfn_query_nop,
               &cyg_mcf52xx_cfm_erase,
               &cyg_mcf52xx_cfm_program,
               (int (*)(struct cyg_flash_dev*, const cyg_flashaddr_t, void*,
size_t))0,
               0,
               0
    );

i.e. define a data structure that contains a number of function
pointers like &cyg_mcf52xx_cfm_init(). That statically initialized
data structure needs to have the real function addresses, no amount of
PC-relative addressing in the instruction set is going to help with
that. Because the structure is const it is going to reside in flash
rather than RAM, so there is no opportunity at run-time to process
relocation information and update the data structure.

So either:

  1) ban this sort of construct. Sorry, but there may be any number of
     places within the existing source code that already uses such
     constructs.

  2) use an MMU to rearrange the memory map to match what the
     application expects. By design eCos does not play games with the
     MMU like that.

  3) perform some sort of relocation as you are programming the
     application into flash at one of the three addresses.

  4) forget about position-independent code and link for a fixed
     address, which is the way eCos is designed to work. In theory you
     could link your application three times, once for each of the
     valid addresses, and install the appropriate application image
     when you have decided which block of flash to overwrite.

    Ilija> I would like to have some comments from eCos architects.

Check my signature.

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


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