* [ECOS] Re: Re: unable to execute linux kernel with Redboot
@ 2006-09-04 10:34 Claudio Scordino
2006-09-04 11:14 ` [ECOS] " Amitesh Singh
2006-09-04 15:08 ` [ECOS] Re: Re: unable to execute linux kernel with Redboot Mark Salter
0 siblings, 2 replies; 18+ messages in thread
From: Claudio Scordino @ 2006-09-04 10:34 UTC (permalink / raw)
To: ecos-discuss; +Cc: msalter, list
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [ECOS] Re: unable to execute linux kernel with Redboot
2006-09-04 10:34 [ECOS] Re: Re: unable to execute linux kernel with Redboot Claudio Scordino
@ 2006-09-04 11:14 ` Amitesh Singh
[not found] ` <200609051509.40563.cloud.of.andor@gmail.com>
2006-09-04 15:08 ` [ECOS] Re: Re: unable to execute linux kernel with Redboot Mark Salter
1 sibling, 1 reply; 18+ messages in thread
From: Amitesh Singh @ 2006-09-04 11:14 UTC (permalink / raw)
To: Claudio Scordino; +Cc: ecos-discuss
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [ECOS] Re: Re: unable to execute linux kernel with Redboot
2006-09-04 10:34 [ECOS] Re: Re: unable to execute linux kernel with Redboot Claudio Scordino
2006-09-04 11:14 ` [ECOS] " Amitesh Singh
@ 2006-09-04 15:08 ` Mark Salter
2006-09-05 0:53 ` [ECOS] Multiple code images in flash Laurie Gellatly
1 sibling, 1 reply; 18+ messages in thread
From: Mark Salter @ 2006-09-04 15:08 UTC (permalink / raw)
To: Claudio Scordino; +Cc: ecos-discuss
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [ECOS] Multiple code images in flash
2006-09-04 15:08 ` [ECOS] Re: Re: unable to execute linux kernel with Redboot Mark Salter
@ 2006-09-05 0:53 ` Laurie Gellatly
2006-09-05 7:37 ` Bart Veer
0 siblings, 1 reply; 18+ messages in thread
From: Laurie Gellatly @ 2006-09-05 0:53 UTC (permalink / raw)
To: ecos-discuss
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] Multiple code images in flash
2006-09-05 0:53 ` [ECOS] Multiple code images in flash Laurie Gellatly
@ 2006-09-05 7:37 ` Bart Veer
2006-09-05 8:48 ` Ilija Koco
0 siblings, 1 reply; 18+ messages in thread
From: Bart Veer @ 2006-09-05 7:37 UTC (permalink / raw)
To: laurie.gellatly; +Cc: ecos-discuss
>>>>> "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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] Multiple code images in flash
2006-09-05 7:37 ` Bart Veer
@ 2006-09-05 8:48 ` Ilija Koco
2006-09-05 9:31 ` Bart Veer
0 siblings, 1 reply; 18+ messages in thread
From: Ilija Koco @ 2006-09-05 8:48 UTC (permalink / raw)
To: Bart Veer; +Cc: ecos-discuss
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ECOS] Multiple code images in flash
2006-09-05 8:48 ` Ilija Koco
@ 2006-09-05 9:31 ` Bart Veer
2006-09-05 11:25 ` Laurie Gellatly
0 siblings, 1 reply; 18+ messages in thread
From: Bart Veer @ 2006-09-05 9:31 UTC (permalink / raw)
To: ilijak; +Cc: ecos-discuss
>>>>> "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
^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: [ECOS] Multiple code images in flash
2006-09-05 9:31 ` Bart Veer
@ 2006-09-05 11:25 ` Laurie Gellatly
0 siblings, 0 replies; 18+ messages in thread
From: Laurie Gellatly @ 2006-09-05 11:25 UTC (permalink / raw)
To: Bart Veer, ilijak; +Cc: ecos-discuss
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
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2006-09-08 2:53 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-09-04 10:34 [ECOS] Re: Re: unable to execute linux kernel with Redboot Claudio Scordino
2006-09-04 11:14 ` [ECOS] " Amitesh Singh
[not found] ` <200609051509.40563.cloud.of.andor@gmail.com>
2006-09-05 13:51 ` Amitesh Singh
2006-09-05 13:58 ` Claudio Scordino
2006-09-06 6:58 ` [ECOS] little mistake in redboot.cdl? Wang Cui
2006-09-07 5:42 ` [ECOS] How to build a executed-in-flash application? Wang Cui
2006-09-07 7:38 ` Andrew Lunn
2006-09-07 9:35 ` wang cui
2006-09-07 9:43 ` Andrew Lunn
2006-09-08 2:53 ` wang cui
2006-09-07 13:38 ` Bart Veer
2006-09-08 1:22 ` wang cui
2006-09-04 15:08 ` [ECOS] Re: Re: unable to execute linux kernel with Redboot Mark Salter
2006-09-05 0:53 ` [ECOS] Multiple code images in flash Laurie Gellatly
2006-09-05 7:37 ` Bart Veer
2006-09-05 8:48 ` Ilija Koco
2006-09-05 9:31 ` Bart Veer
2006-09-05 11:25 ` Laurie Gellatly
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).