[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: eCos on Cris



>Is the --jump address the one that i get if I do readelf -h <prog>, and
>look at the Entry point address entry?

When booting to RAM eCos should be loaded to 0xc0000000 and the jump
should also be to that address (for the Linux kernel the address
is 0xc0004000 because two pages are reserved at the bottom of the
memory).

So, do boot_linux -i kimage -p and then replace 
--file kimage c0004000 --jump c0004000
with
--file ecos.bin c0000000 --jump c0000000

(First you should do bin-cris -o ecos.bin <ecos ELF file>)

/Mikael

-----Original Message-----
From: owner-dev-etrax@xxxxxxx.com">mailto:owner-dev-etrax@xxxxxxx.com] On
Behalf Of Simon Posnjak
Sent: Tuesday, September 14, 2004 10:27 PM
To: dev-etrax
Subject: RE: eCos on Cris


V tor, 14.09.2004 ob 20:12 je Henrik Eriksson napisal(a):
> You can use the same parameters to e100boot as boot_linux does
> when you are loading a linux image to the same hardware; you might
> need to change the --jump address though.  (I recommend trying it
> out using RAM boots at first though.

Is the --jump address the one that i get if I do readelf -h <prog>, and
look at the Entry point address entry?

> Btw, the generic HAL for CRIS is not configured for any specific
> hardware; it basically just pulls in the default values from the
> register header files for all registers.  You will need to set
> it up for the hardware you are using to get eCos to boot.  I can
> provide you with the template for the devboard if you need it.

Yes, please. I would be very grateful. Thank you. (I have devboard 82)

> The port is almost exactly the eCos 2.0 release (which is about
> two years old now IIRC) with a few minor tweaks and the HAL and
> driver (ethernet and serial) packages needed to run it on
> ETRAX100(LX).  We have used it internally for some time without
> problems, beware that we have not used the eCos TCP/IP stack
> extensively though.  Also, the port is provided as-is; we are
> not doing active work on eCos and if you require support you
> will have to discuss that with our sales people.

OK, fair enough. What I am doing is developing a device driver which
needs about 100 us resolution. But the standard kernel has the
resolution of about 10 ms. So I am planing to develop one by using fast
timers. But all so I am thinking of using this project for my BS thesis
and because of that I will develop one more driver that will use the
RTAI kernel extensions (if I will ever get the RTAI patched kernel to
compile) and it would be very nice if I could develop one more that will
use eCos. So that I will be able to compere how they behave under heavy
load.

		Regards Simon