This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: redboot on IXDP425
On Wednesday 12 January 2005 12:28, Nickolay wrote:
> jerzy dyrda wrote:
> >On Tuesday 11 January 2005 19:39, Nickolay wrote:
> >>Mark Salter wrote:
> >>>On Tue, 2005-01-11 at 09:31 -0700, Gary Thomas wrote:
> >>>>On Tue, 2005-01-11 at 17:13 +0100, jerzy dyrda wrote:
> >>>>>On Tuesday 11 January 2005 16:55, Mark Salter wrote:
> >>>>>>On Tue, 2005-01-11 at 18:47 +0300, Nickolay wrote:
> >>>>>>>Mark Salter wrote:
> >>>>>>>>On Tue, 2005-01-11 at 18:17 +0300, Nickolay wrote:
> >>>>>>>>>Hello Guys!
> >>>>>>>>>
> >>>>>>>>>Anyone know, how i can install redboot on IXDP425 target?
> >>>>>>>>>I has vxWorks bootloader installed, and i need rewrite them or
> >>>>>>>>> boot redboot on them.
> >>>>>>>>
> >>>>>>>>The flash is socketed on the IXDP425, so you can use a device
> >>>>>>>>programmer. The alternative is to use a jtag based flash
> >>>>>>>>programmer.
> >>>>>>>>
> >>>>>>>>--Mark
> >>>>>>>
> >>>>>>>That's true!
> >>>>>>>But maybe anyone know how load redboot via vxworks bootloader?
> >>>>>>>Can i use redboot.bin for this purpose, or redboot.bin is for
> >>>>>>> upgrade redboot from redboot the self?
> >>>>>>
> >>>>>>redboot.bin is just a raw binary image. It needs to get programmed
> >>>>>>to the start of flash. I'm not sure about the vxworks bootloader
> >>>>>>capabilities.
> >>>>>>
> >>>>>>--Mark
> >>>>>
> >>>>>Hello
> >>>>>
> >>>>>I heard from vxWorks guys - it isn't possibility to write image by
> >>>>>vxWorks bootloader and this bootloader don't configure hardware e.g
> >>>>> PCI - Do you have other loader?
> >>>>
> >>>>Why not use the VxWorks loader to load a RAM version of RedBoot
> >>>>(from ELF). Then use that to load & program the FLASH (ROM) version.
> >>>>
> >>>>Mark - should this work? [it certainly does for most platforms]
> >>>
> >>>I'm not sure. VxWorks may use a different mmu mapping than RedBoot.
> >>>
> >>>--Mark
> >>
> >>Hmm... but we talk about vxWorks loader, not vxWorks operation system.
> >>And i think that vxWorks loader doesn't use MMU?
> >
> >Hi again,
> >
> >Probably , this is only suppose because it isn't all sources for vxWorks,
> >loader use MMU with translation one to one (virtual to physical). You can
> >use loader's option copy and go.
> >
> >Best Regards,
> >jerzy
>
> Hmm...
> vxWorks loader doesn't has opton "copy and go".
> I used option 'm' for modify memory and write redboot.bin at 0x80000,
> and then option
> 'g' for go to 0x80040, but it isn't work...
>
> This is all bootloader options:
> [VxWorks Boot]: ?
>
> ? - print this list
> @ - boot (load and go)
> p - print boot params
> c - change boot params
> l - load boot file
> g adrs - go to adrs
> d adrs[,n] - display memory
> m adrs - modify memory
> f adrs, nbytes, value - fill memory
> t adrs, adrs, nbytes - copy memory
> e - print fatal exception
> n netif - print network interface device address
> $dev(0,procnum)host:/file h=# e=# b=# g=# u=usr [pw=passwd] f=#
> tn=targetname s=script o=other
> Boot flags:
> 0x02 - load local system symbols
> 0x04 - don't autoboot
> 0x08 - quick autoboot (no countdown)
> 0x20 - disable login security
> 0x40 - use bootp to get boot parameters
> 0x80 - use tftp to get boot image
> 0x100 - use proxy arp
Hi Nicolay,
I think about :
1.> t adrs, adrs, nbytes - copy memory - to copy program in proper place
2. > g adrs - go to adrs - go to selected address
Probably this loader "make something special" for vxWorks image -
documentation for loader is very poor ( I spoke today morning with someone
from vxWorks but he told me only that : load, copy to proper place and go
adrs).
Best Regards,
jerzy
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss