loadModule() with target-resident object files
Ken Cecka
Found a thread on this issue while digging through the google archive:
http://groups.google.com/groups?q=loadmodule+vxworks&hl=en&lr=&safe=off&rnum=7&seld=929786427&ic=1
But there was no apparent resolution. Basically, what I want to do is put
a bootable vxWorks image in flash, and then embed my application as an
object file (ARM-COFF) in flash. After booting VxWorks, I want to use the
dynamic linker to load/link the application and run it.
In the setup I've been playing with, I have a 2MB region of flash at
address 0x08000000. I have a working vxWorks image in flash which I can
boot without difficulty. I've embedded my object file in flash at
0x08100000, and the file size is 625 bytes.
Since this object file is the only file I ever plan to use, I've been
trying to take a minimalist approach in setting up a file-system (I'd skip
the file-system entirely if I could find a way). I've been prototyping
this from a Host-based shell (maybe that's my problem!), and the following
is an example of what I've tried:
1. LOADING THE MODULE FROM THE HOST WITH LD (to verify object file works)
-----------------------------------------------------------
-> ld < test.o
Loading g:/devl/netrom/tmp/test.o |
value = 17432640 = 0x10a0040
-> testfunction
this is a test function!
value = 25 = 0x19
-> reboot
...
2. LOADING THE MODULE FROM FLASH WITH LD
---------------------------------------
-> ramDevCreate(0x08100000, 625, 1, 1, 0)
value = 8376360 = 0x7fd028
-> rawFsDevInit("testobj.o", 0x7fd028)
value = 8376316 = 0x7fcffc
-> devs
drv name
0 /null
1 /tyCo/0
5 bootHost:
6 /vio
3 testobj.o
value = 0 = 0x0
-> ld < testobj.o
Loading testobj.o WTX Error 0x10140 (API_FILE_NOT_ACCESSIBLE)
value = -1 = 0xffffffff
-> ld(0, 0, "testobj.o")
Loading testobj.o WTX Error 0x10140 (API_FILE_NOT_ACCESSIBLE)
value = -1 = 0xffffffff
-> reboot
...
3. LOADING THE MODULE FROM FLASH WITH LOADMODULE
------------------------------------------------
-> ramDevCreate(0x08100000, 625, 1, 1, 0)
value = 8376360 = 0x7fd028
-> rawFsDevInit("testobj.o", 0x7fd028)
value = 8376316 = 0x7fcffc
-> devs
drv name
0 /null
1 /tyCo/0
5 bootHost:
6 /vio
3 testobj.o
value = 0 = 0x0
-> open("testobj.o",0)
value = 7 = 0x7
-> errnoSet(0)
value = 0 = 0x0
-> loadModule(7,0)
value = 0 = 0x0
-> errnoGet()
value = 0 = 0x0
-> reboot
...
I've also tried examining the file using open() and read() to make sure the
file-system is mapped correctly, and the data matches that of the
host-resident test.o file. Can anyone see what I may be doing wrong? OR,
is there a better way to do dynamic loading of flash-resident applications?
Any info would be greatly appreciated! Thanks,
Ken
Werner Schiendl
VxWorks users guide, IO chapter) that does nothing else than delivering
bytes from a given address im memory (flash in your case, but this does not
matter). You only need to implement the services required by moduleLoad, at
least this will be open, read and maybe a handful of ioctls for seek. But
everything should be trivial to implement.
Now load your application from that device.
hth
werner
"Ken Cecka" <cec...@home.com> wrote in message
news:TfMy6.675421$U46.20...@news1.sttls1.wa.home.com...
Ken Cecka
This sounds like a good solution, but I'm worried I'll run into the same
problems I am now. As things stand at the moment, I can open(), read() and
close() the file. So the file system seems to be present and working.
What I don't understand, is how to successfully load the module.
loadModule() always fails (returns 0) when I try to load my file. IS there
some way I can find out what services loadModule uses and then verify that
rawFs provides these services?
Ken
Werner Schiendl
Some remarks on that
option 2 simply does not work, because you are invoking the host resident
version of the shell command.
try @ld instead of ld
in general, you can invoke the target version of a host resident command by
prefixing @
since the file you created lives in the target filesystem, the host ld
version cannot access it.
If loading the file with the raw file system works well, I do not see a
reason to change that.
However, with your own driver you can easily print out information what is
going on and if your file is loaded at all.
Maybe your problem is reading the errno value. I had such problems some
time.
I cannot see any obvious error in your code.
I compared it to the source of ld(), located in /target/src/usr/usrLib.c and
cannot find remarkable differences.
regards
werner
Don Small
possibilities. Our final method was the one described by Werner, but we
went through several other choices on the way.
1) Add you code into the kernel using MACH_EXTRA in the vxWorks
Makefile. Then you can run your code automatically by defining
INCLUDE_USER_APPL and USER_APPL_INIT (see (WIND_PATH)/target/config/all
directory).
+ Quick, easy to do (once)
- Not very flexible. This is great if your code never needs to be
changed.
2) Similar to what you attempted to do with a ram drive.
pBlkDev = ramDevCreate(0, 512, 400, 400, 0);
dosFsMkfs("A:", pBlkDev);
fd = creat("A:testobj.o", O_RDWR);
write(fd, 0x08100000, 625);
Now you have a ramDrive with the file visible to all existing vxWorks
functions. Now you can ls, ld , loadModule or whatever.
+ Much more flexible, does not require a modified kernel.
- I could never get rid of the ramDrive. I had a single file that was
1.6Mb so the ramDrive had to be big. And this on a cpu that only had 4M
of memory.
3) Write a device driver.
+ No ramDrive to get rid of. Drive is limited only by amount of flash
you have. You can actually use the startup script to either run
automatically or in a development environment turn off the script and
run by hand.
- Need a modified kernel (only once) that installs the flashFile driver
and creates each of the required drives.
I can send you source, if your interested. We have been using it for
about 1.5 years.
Ken Cecka
> option 2 simply does not work, because you are invoking the host resident
> version of the shell command.
> try @ld instead of ld
> in general, you can invoke the target version of a host resident command
> by prefixing @
> since the file you created lives in the target filesystem, the host ld
> version cannot access it.
I was looking for something like this. I could see that some of the shell
commands only seemed to be aware of host files, but hadn't found a way to
make them look at the local file system. I tried the ld with an @ prefix,
and it didn't work, but I'll keep fiddling.
>
> If loading the file with the raw file system works well, I do not see a
> reason to change that.
> However, with your own driver you can easily print out information what is
> going on and if your file is loaded at all.
> Maybe your problem is reading the errno value. I had such problems some
> time.
This sounds like a good idea. I'm still not getting any further, but
you've given me some good pointers on places to dig deeper.
I'll post again if I figure it out. Thanks,
Ken
Ken Cecka
It looks like the big difference in your second approach from what I have
tried so far is that you created a device/filesystem in RAM, then copied
your image to it, whereas I have been trying to simply map a device to the
block of flash. Maybe the fact that my file is a device rather than a
standard file is causing me problems -- I'll have to play with it some
more. Please do send me the code if it's not a problem. I'd be intersted
in digging through it. You can post it here, or send it by email.
Ken
Urban Lindberg
Have a look on the memDrv library, I think this was the way I solved
a similar problem a couple of years ago. I also saw in your first post
that you tried to read errno after loadmodule. You will always get
errno = 0 because the shell spawns a task that calls the function.
If you want to see for yourself:
Start two shells and in one shell execute taskDelay(600) and switch
to the second shell and do an i and you will se that there is task
task called t1 (or something similar) that has a delay. If you this
one more time you will see that the task name is t2 (or something
similar)
Urban
Ken Cecka wrote:
>
> Thanks Don,
>
> It looks like the big difference in your second approach from what I have
> tried so far is that you created a device/filesystem in RAM, then copied
> your image to it, whereas I have been trying to simply map a device to the
> block of flash. Maybe the fact that my file is a device rather than a
> standard file is causing me problems -- I'll have to play with it some
> more. Please do send me the code if it's not a problem. I'd be intersted
> in digging through it. You can post it here, or send it by email.
>
> Ken
>
[Snip}
Diego Serafin
says...
>
>Thanks Don,
>
>It looks like the big difference in your second approach from what I have
>tried so far is that you created a device/filesystem in RAM, then copied
>your image to it, whereas I have been trying to simply map a device to the
>block of flash. Maybe the fact that my file is a device rather than a
>standard file is causing me problems -- I'll have to play with it some
>more. Please do send me the code if it's not a problem. I'd be intersted
>in digging through it. You can post it here, or send it by email.
>
>Ken
Ken,
did you ever tried memDrv() ? It's a pseudo memory device driver that:
" ... allows the I/O system to access memory directly as a pseudo-I/O device.
Memory location and size are specified when the device is created. ..."(VxWorks
Reference Manual, 5.4 p. 1-226).
The driver allows seek-ing so it is suitable for loadModule() use (and I use it
actually to "loadModule" a VxWorks module from RAM).
Instead I found some troubles with symbols: if I tried to symFinByName a symbol
of a function defined in the "loadModule'd" module and execute the function a
missing symbol problem was blocking execution (I had to link FLASH-resident
module symbols to memory-loaded one ...).
Now I have the trouble of sync-ing target resident symbol table and host
resident one, in order to make debugger work ... "symbolically" !
Unfortunately our target board does not have a net connection and so I cannot
use synchronization tools provided with VxWorks. Do you have some idea ? It
should be possible to fetch symbols from target-based symbol table and drop them
into host resident one ...
Greetings,
Diego.