Jenn's Support Shop

    C:/OSE/OSE5.4.1_PPC/bin/win32/osegwcmd -s tcp://177.77.7.77:21768 -e100,100


and look for something called "checksum" or "checksum offload" or "Rx Checksum Offload" or similar. If it is set "on" , flip it to "off", restart the SFK and Optima and try again. Generally hardware checksumming only needs to be disabled if the soft kernel and the other software (e.g. Optima) that communicates with the soft kernel via TCP/IP is running on the same machine. If you run the two across different systems, then this most likely isn't the problem.

Labels: Optima, osegw, sfk, win32, winxp

Q: I have installed the BSP for SFK for 5.5.1 on my Linux system, but without installing any of the BSP documentation (I didn't need it and already have a copy of it elsewhere). When I try to build the rtose, I get a "No such file or directory" errors on rtose_defaults.mk and environment.mk.Checking the SFK delivery shows these and other important build files missing - in fact, the /refsys directory only has /rtose in it, and nothing else.

A: There is a weird problem with the installer that causes it to omit a lot of important files if you don't install the BSP documentation. Re-install it with all the documentation checked, which is the default. Then the environment.mk and other files should appear in the distro where they belong.

Labels: BSP, installation, OSE5, sfk

Q: I am using a local FLEXlm license server, whose license expired recently. I just updated it with my new license file, and tried to start the soft kernel. But I get this error:

10:42:37 (osedaemon) UNSUPPORTED: "softose_win32" (PORT_AT_HOST_PLUS ) jmir@jenshostname (License server system does not support this feature. (-18,327:10054 ""))

Why am I getting this even though I updated the license file to the new one?

A: Most likely because the license manager was not restarted. Just copying the license file over in the correct place is not enough. You must stop the license manager and restart it (with lmgrd -z) so that it picks up the new license. Here is a console output of a successful license acquisition:

10:42:51 (lmgrd)
10:42:51 (lmgrd) pid 1740
10:42:51 (lmgrd) Done rereading
10:42:51 (lmgrd) FLEXnet Licensing (v11.4.100.0 build 50818 i86_n3) started on jenshostname (IBM PC) (7/7/2010)
10:42:51 (lmgrd) Copyright (c) 1988-2007 Macrovision Europe Ltd. and/or Macrovision Corporation. All Rights Reserved.
10:42:51 (lmgrd) US Patents 5,390,297 and 5,671,412.
10:42:51 (lmgrd) World Wide Web: http://www.macrovision.com
10:42:51 (lmgrd) License file(s): c:/flexlm/license.dat
10:42:51 (lmgrd) lmgrd tcp-port 744
10:42:51 (lmgrd) Starting vendor daemons ...
10:42:51 (lmgrd) Started osedaemon (pid 6108)
10:42:51 (osedaemon) FLEXnet Licensing version v11.4.100.0 build 50818 i86_n3
10:42:51 (osedaemon) Server started on jenshostname for: softose
10:42:51 (osedaemon) softose softose_win32 com.ose.cdt.launch
10:42:51 (osedaemon) com.ose.system.ui com.ose.ck.system.ui com.ose.pmd
10:42:51 (osedaemon) com.ose.event.ui com.ose.prof.ui com.zealcore.se.core
10:42:51 (osedaemon) EXTERNAL FILTERS are OFF
10:42:51 (lmgrd) osedaemon using TCP-port 1996
10:42:59 (osedaemon) TCP_NODELAY NOT enabled
10:42:59 (osedaemon) OUT: "softose_win32" jmir@jenshostname

Q: I did that, but i'm still getting the same error.

A: You should also check that your settings in the license file for OSEDAEMON and SERVER are up-to-date as well. Sometimes admins copy a new license file over but forget to fix these. When we ship them, they have default settings and each time you get a new one you should customize them to your server. Example of a correct configuration of a license.dat file:

SERVER jenshostname 001641e67507 744
DAEMON osedaemon c:/OSE/OSE5.4.1_PPC/bin/win32/osedaemon.exe
USE_SERVER

Labels: flexlm, Optima, OSE4, OSE5, sfk

Q: I'm trying to build a BSP under OSE5.4.1 and got this error:

$ make all../../rtose/common_rtose.mk:169: *** multiple target patterns. Stop.make: *** [mods] Error 2

This makes no sense whatsoever. I've already done the required mod to environment.mk.

A: Sometimes there is more than one cause.

For example, the OSE baseline is set up differently starting in OSE5.3.x, and is also matched to a BSP for each release. So you should only use the cygwin shipped with OSE5.3.x for building BSPs intended for OSE5.3.x; If you try to use OSE5.3.x cygwin to build a BSP delivered for use with OSE5.4.x, you may get strange errors. Verify that your cygwin is the correct one and that $OSE_ROOT and toolset is pointing to the right place, e.g.:

$ echo $OSE_ROOT
C:/OSE/OSE5.4.1_PPC
$ which powerpc-eabi-gcc
/cygdrive/c/OSE/OSE5.4.1_PPC/gcc_win32_powerpc_4.2.3/bin/powerpc-eabi-gcc

Another problem may be with corrupted cygwin environment. If you see strange make errors you might quickly check the environment, e.g. run "alias" and see what comes out:

$ alias
'lias gd='grep --directories=recurse
'lias java='E:/ThirdParty/jre1.5.0_06/bin/java.exe
'lias ll='ls -la

Clearly this shows the aliases are not being interpreted correctly, and possibly that the ~/.bash_profile (which has the aliases defined) is corrupted. A quick cleaning with the col utility takes care of this:

$ cp .bash_profile orig.bash_profile
$ col -b < .bash_profile > out.bash_profile
$ cp out.bash_profile .bash_profile

The col utility will remove any escape and other "invisible" chars that may be in the cygwin init files. Not the solution to every strange problem, but something to eliminate and to restart cygwin after fixing.

Labels: cygwin, make, OSE5, sfk

Q: I want to try a load module in my soft kernel before putting it on the real target. How can I build this? The sfk-win32 ARCH target doesn't work.

A: The trick to getting the LMs to build for sfk is to use ARCH=x86 instead. E.g.:

$ C:/OSE/BSP_SFK_OSE5.4.1/refsys/modules/pingpong
$ make ARCH=x86 all
--- Compiling src/ping.c
--- Compiling src/pong.c
--- Compiling ../../modules/src/libwhat.c for obj/x86/debug/libwhat.o
--- Building lib/x86/debug/libpingpong.a
--- Compiling src/debug_friendly.c
--- Compiling src/pingpong_main.c
--- Concatenating osemain.con fragments
--- Compiling c:/OSE/ose5.4.1_ppc/src/osemain.c
--- Compiling c:/OSE/ose5.4.1_ppc/src/crt0_lm.c
--- Compiling c:/OSE/ose5.4.1_ppc/src/ose_confd.c
--- Linking obj/x86/debug/unconfigured (pass 1)
--- Linking obj/x86/debug/unconfigured (pass 2)
--- Stripping load module from symbol and debug information
--- Postlinking obj/x86/debug/unconfigured
--- Inserting configuration ../../modules/src/default.lmconf
--- Sizing bin/x86/pingpong_debug.elf
Size of text : 29704 (29K) (t)
Size of initdata : 0 (0K) (id)
Size of data : 2084 (2K) (d)
Size of bss : 344 (0K) (b)
ROM footprint : 31788 (31K) (t+d)
RAM footprint : 36864 (36K) (t+id+d+b)

The resulting elf file is located in :

C:/OSE/BSP_SFK_OSE5.4.1/refsys/modules/pingpong/bin/x86/pingpong_debug.elf

This applies for OSE5.4.1 but holds for older releases as well. To upload it, remember that the directory for sfk is mounted locally (for newer OSE5 releases) so you don't need the /tftp/ in the pathname. The default pathname is /host, which represents your root C: level. Just create a temp directory from your C: top-level directory and mount from there, e.g. create C:/oselm, copy the elf file over there, then download it to the rtose for sfk-win32 with:

rtose@softwin> pm_install pingpong /host/oselm/pingpong_debug.elf
rtose@softwin> pm_create pingpong
rtose@softwin> pm_lminfo
core_module
pingpong

Labels: lm, load module, OSE5, sfk

Q: I’m using OSE5.1 in Eclipse IDE and trying to debug a soft kernel. When I “Run->Debug” I’m getting no debug launch, only “No stack” error instead. If I try to “Run->Run” I see an error complaining about not being able to find lmgr9a.dll. This used to work – what is wrong?

A: Sometimes on some systems, Eclipse does not inherit the environment from windows properly and doesn’t know your path. Specifically, it cannot find the lmgr9a.dll license file required for the soft kernel license. However you’ll only get that hint when you Run and you won’t see this file mentioned when you Debug. There is no good long-term solution I know of, and I don’t why this happens to some users. But the quickest way around it for now is to just copy over the lmgr9a.dll file from $OSE_ROOT/bin/win32/ over to your rtose/sfk-win32 directory. Then it will always be found by the debug launcher.

Q: I’m running a soft kernel with some C++ in the application, and it’s crashing:
(gdb) run -c rtose5.conf
Starting program: /cygdrive/c/ose/ose5.1/refsys/rtose/sfk-win32/obj/rtose_debug/
rtose.exe -c rtose5.conf
SFK: biosCall 0x4a before bios initialized!!
SFK: Cannot error calls or any other syscalls this early, exiting.

A: One possible cause is dead code in the cpp source file of a problem class. The dead code may be outside of the class. For example:
tFILE* gfpStdOut = stdout;

The pointer does not have to be used at all. But referencing this class the SFK will crash, even if the dead code is outside of the class definition. If you don't reference that class the SFK will boot OK.

Q: My application, which is a refsys module, generates a really long compile line and causes this error in Win2k:
The input line is too long.
The syntax of the command is incorrect.
make[1]: *** [obj/rtose_debug/sigdb.c] Error 255

A: Win2k, unlike WinXP, has a 2K line length limit for batch files. If this is a problem, there is a patch for it for OSE5.x available from support.

Q: Trying to use OSE with the ARMulator and want to use “printf”, because ARMulator has restrictions in output (e.g. no file system, no serial port). Does the libc from OSE support printf that goes straight to a software interrupt which allows ARMulator to print out in its own way? Instead of going through efs_stdout() as it normally does in OSE?

A: Yes our libc supports printf(), but not really in this context. To get around this problem for now, you must trick the ARM compiler into using its own printf() rather than OSEs. The easiest way is to change the link order at link time so that ARM’s libc preceeds (overrides) OSE’s. That way you’ll link up to the ARM version of printf() which has the SWI capability built-in.

Q: I’m using Emanate and I’m looking for a MIB browser that works with their stuff.

A: There isn’t one available in the older releases of Emanate, which are all the releases that OSE supports. However the next Emanate release coming up which is 17.1 does have a new GUI MIB browser tool.

Q: I want to do run-time source analysis of our OSE system at the source level. I.e. not System-level like Illuminator, but at the function level, e.g. how many times is a function called and how much time is spent running each function. Is there a vendor that supplies a tool like this that is already OSE-aware?

A: Not at the present time. There are several vendor tools that come close to what you want, and work for other RTOS. With some effort they could be made to work on OSE. Here are some:
-----------------
Site: www.suresofttech.com / www.codescroll.com
Product: CodeScroll
This Korean co. makes an embedded testing software that already works with lots of other OS including Wind River, QNX, Nucleus, and others.
-----------------
Site: www.s2technologies.com
Product: STRIDE
S2 is based in SoCal and their product is a full-blown SDK toolkit with panel, dev studio etc. – all GUI based.
-----------------
Vendor: DDC-I
Site: www.ddci.com
Product: internal
At one time they had a profiling type of tool that worked with OSE, but its been in the archives for a while.

Q: We are using Green Hills as our compiler with OSE4.6.1, but we are running into an undefined reference in librtc to what appears to be a 64-bit math function, __udivdi3, that is only defined in libgcc.a. Are we supposed to link with libgcc even with Green Hills?

A: You'll need to add libgcc.a to the end of your list of libraries input to the linker. That's because we build rtc now with gcc, and gcc apparently doesn't resolve all the math functions till link time. If this library is last, it won't affect anything else.

Q: I’m using MULTI Debugger and I see in the OSE documentation a reference to “oseinit 50000”. I can’t figure out what this is.

A: It’s an obsolete command that no longer works for OSE/MULTI combination. It has been removed in the newer releases, but the “oseserv” command is the correct one.

Labels: emanate, flexlm, ghs, lmgr9a.dll, sfk, win2k