Monday, March 20, 2006
Tips for the week: March 19 2006
(It's been pretty busy the last couple of weeks so the are lots of tips lately)
Q: I’m building/porting an application for the first time, and I noticed my compile is failing due to __int64 types not being defined. E.g. __time64_t isn’t working and I can’t support 64-bit time without it. Doesn’t OSE support 64-bit access?
A: Yes it does, but not directly. In osetypes.h there is a struct type U64 which defines two 32-bit values and simulates a 64-bit one, using struct members msw and lsw (most significant word, least significant word) to create the full value. You’ll find osetypes.h in different places depending on your release:
OSE5.1: $OSE_ROOT/include
OSE4.x: $OSE_ROOT/powerpc/krn-xxx/include or
$OSE_ROOT/sfk-win32/krn-win32/include
Note that this holds true even if you included - the 64 bit support doesn’t come automatically, you have to adapt your system for it for use with OSE.
Q: I was trying to get gdb going yesterday on my target and I noticed I could not attach it to an ose_* type of process or set a breakpoint inside of an ose_* routine. Is that a limitation with the other debuggers?
A: There is in OSE something that prevents you from attaching to a system process with a debugger (by default), but can be overridden using the SYSTEM_PROCESS macro in ospp.con. Just change it to something other than ose_*. If/when you use GHS Multi, there's also a string in the GHS oseserv you'll need to change with a binary editor to get this capability.
Q: I am debugging with the MULTI plug-in and I cannot see any OSE system processes come up, but I know they’re normally visible. Why can’t I see them?
A: The MULTI plug-in used by Illuminator creates a special custom debug configuration. There are several standard (i.e. non-custom debug configuration types) that allow you to check or un-check a checkbox saying “Hide System Processes,” however in the custom config this is not offered. So you can select OSE (current config used by the Illuminator plug-in) and use that configuration, or just create your own debug config completely and not use the plug-in version at all.
To get to the “Hide System Processes” check box in MULTI, when you bring up the processes window, select
Target -> Show Connection Organizer
In Connection Organizer window, on the top right corner there is a pane with some "User Methods" which are just configurations for connections. Select the currently connected one, which is probably called "OSE," and right-click menu then select "Edit." This brings up the Connection Editor where you'll find find three tabs, and one of those is the "Advanced" tab and under here you’ll find the checkbox for system processes.
Q: I upgraded from 4.6 to 4.6.1. I was using a ported example from the older /examples directory and my shell commands behave differently – when you enter an unknown command for example, the error handling doesn’t look right and the shell login process restarts.
A: 4.6.1 changes many things about the OSE shell. It expects the shell to be a system built by refsys, namely. If you didn’t build with refsys, you might expect some strange behavior particularly in the shell. Two possible workarounds for the unknown command problem:
1) call prh_asf_shell_mode from a start hook, or
2) add a shell_add_cmd call somewhere in your code for a default command. This works well if you didn’t include PRH in your system.
shell_add_cmd("" , "< command > [< parameters >...]", "default shell command", cmd_pgrun);
Q: I’m building/porting an application for the first time, and I noticed my compile is failing due to __int64 types not being defined. E.g. __time64_t isn’t working and I can’t support 64-bit time without it. Doesn’t OSE support 64-bit access?
A: Yes it does, but not directly. In osetypes.h there is a struct type U64 which defines two 32-bit values and simulates a 64-bit one, using struct members msw and lsw (most significant word, least significant word) to create the full value. You’ll find osetypes.h in different places depending on your release:
OSE5.1: $OSE_ROOT/include
OSE4.x: $OSE_ROOT/powerpc/krn-xxx/include or
$OSE_ROOT/sfk-win32/krn-win32/include
Note that this holds true even if you included
Q: I was trying to get gdb going yesterday on my target and I noticed I could not attach it to an ose_* type of process or set a breakpoint inside of an ose_* routine. Is that a limitation with the other debuggers?
A: There is in OSE something that prevents you from attaching to a system process with a debugger (by default), but can be overridden using the SYSTEM_PROCESS macro in ospp.con. Just change it to something other than ose_*. If/when you use GHS Multi, there's also a string in the GHS oseserv you'll need to change with a binary editor to get this capability.
Q: I am debugging with the MULTI plug-in and I cannot see any OSE system processes come up, but I know they’re normally visible. Why can’t I see them?
A: The MULTI plug-in used by Illuminator creates a special custom debug configuration. There are several standard (i.e. non-custom debug configuration types) that allow you to check or un-check a checkbox saying “Hide System Processes,” however in the custom config this is not offered. So you can select OSE (current config used by the Illuminator plug-in) and use that configuration, or just create your own debug config completely and not use the plug-in version at all.
To get to the “Hide System Processes” check box in MULTI, when you bring up the processes window, select
Target -> Show Connection Organizer
In Connection Organizer window, on the top right corner there is a pane with some "User Methods" which are just configurations for connections. Select the currently connected one, which is probably called "OSE," and right-click menu then select "Edit." This brings up the Connection Editor where you'll find find three tabs, and one of those is the "Advanced" tab and under here you’ll find the checkbox for system processes.
Q: I upgraded from 4.6 to 4.6.1. I was using a ported example from the older /examples directory and my shell commands behave differently – when you enter an unknown command for example, the error handling doesn’t look right and the shell login process restarts.
A: 4.6.1 changes many things about the OSE shell. It expects the shell to be a system built by refsys, namely. If you didn’t build with refsys, you might expect some strange behavior particularly in the shell. Two possible workarounds for the unknown command problem:
1) call prh_asf_shell_mode from a start hook, or
2) add a shell_add_cmd call somewhere in your code for a default command. This works well if you didn’t include PRH in your system.
shell_add_cmd("" , "< command > [< parameters >...]", "default shell command", cmd_pgrun);
Labels: 64-bit, gdb, MULTI, OSE4.6.1, shell
Thursday, March 16, 2006
Tips for the week : March 16
Q: I am migrating to refsys and I can’t find dbgprintf anywhere. Where is it?
A: dbgprintf has been replaced by ramlog_printf in the refsys model. The ramlog_printf version stores in a RAM area that survives a restart. If it doesn’t suit your needs though, you’ll need to port dbgprintf over to your refsys build yourself. There is some tricky business to this, particularly if you want to send debug output to the serial port, so consult support before you attempt it.
Q: I am creating a new refsys modules in OSE5.1 for my application, and I want to pull in the standard C includes which are OSE-adapted. However there are multiple versions of certain includes in the 5.1 distribution, e.g. assert.h exists in both OSE5.1/include and OSE5.1/cygwin/usr/include . Which one should I use?
A: To pull to your module source the OSE-aware versions of the includes, use the standard include brackets e.g. “include < assert.h >”. Make sure your local myapp.mk file for your app has the OSE include directory added to the include path:
INCLUDE += -I$(OSEROOT)/include
Q: I’m trying to debug some code that’s in a refsys module, and I’m not able to attach the debugger to the process that came from the module. The debugger prints out an error and a bad PC counter when it attaches. What could be wrong?
A: One thing to check is your refsys/rtose/< board >/Makefile entry for “mods” target. It is always “release” by default, and FLAVOR=debug option doesn’t always generate debuggable code for some boards. You can change this in the Makefile to be “debug” instead for the mods target. This is known to be a problem in EST8260 and perhaps other boards as well.
A: dbgprintf has been replaced by ramlog_printf in the refsys model. The ramlog_printf version stores in a RAM area that survives a restart. If it doesn’t suit your needs though, you’ll need to port dbgprintf over to your refsys build yourself. There is some tricky business to this, particularly if you want to send debug output to the serial port, so consult support before you attempt it.
Q: I am creating a new refsys modules in OSE5.1 for my application, and I want to pull in the standard C includes which are OSE-adapted. However there are multiple versions of certain includes in the 5.1 distribution, e.g. assert.h exists in both OSE5.1/include and OSE5.1/cygwin/usr/include . Which one should I use?
A: To pull to your module source the OSE-aware versions of the includes, use the standard include brackets e.g. “include < assert.h >”. Make sure your local myapp.mk file for your app has the OSE include directory added to the include path:
INCLUDE += -I$(OSEROOT)/include
Q: I’m trying to debug some code that’s in a refsys module, and I’m not able to attach the debugger to the process that came from the module. The debugger prints out an error and a bad PC counter when it attaches. What could be wrong?
A: One thing to check is your refsys/rtose/< board >/Makefile entry for “mods” target. It is always “release” by default, and FLAVOR=debug option doesn’t always generate debuggable code for some boards. You can change this in the Makefile to be “debug” instead for the mods target. This is known to be a problem in EST8260 and perhaps other boards as well.
Labels: dbgprintf, migration, OSE5.3, refsys
Friday, March 10, 2006
Tips for the week: Mar 10 2006
Q: I hear there’s a way to tell OSE to boot with debug capability enabled, but not actually running. I.e. ose_dbgserver, ose_sdm, and ose_ldm are not actually running until a “debug” shell command is invoked. But when I enter that command in my shell it isn’t recognized. How do I get it?
A: The “debug” shell command can be enabled in refsys builds only. You must make sure you’ve got refsys build capability for your binary. If you do (OSE4.6 and up) you can enable it by adding the following:
rtose.mk : add “USE_DEBUG = yes”
rtose4.conf : set debug option to “debug=enable:no”
Then “make all” in the refsys target directory and your rtose.elf binary will have “debug” command enabled.
NOTE: In OSE4.5.2 the rtose.mk file is actually Makefile instead. (But I haven’t been able to test refsys with 4.5.2 yet.)
Q: I am trying to connect to my already-running target using powerpc-ose-gdb, but when I type “info ose targets” it just returns nothing. What is wrong?
A: If you’ve waited a bit already (at least 15 secs), then sounds like your host cannot communicate with the target. Possible reasons include
- incorrect inet configuration (rtose*.conf)
- inet/default_gw is incorrect (try leaving it blank for static IP)
- ose_dbgserver not running (“ps ose_d*”)
- binary not compiled with proper gcc flavor (different target flavors in 5.1)
- network card or cable malfunction (can host/target ping each other? Can Illuminator System Browser see the target?)
- misc. software interference (VMWare, VPN etc)
Q: I’m compiling with GHS MULTI and got this error:
[elxr] (error) cannot find library –lc
A: Alas, you are trying to compile MULTI on OSE5.x which isn’t yet supported. Stick with 4.x for now.
Q: I’m new to this RTOS and I have no idea to find out which version of OSE I’m running currently, and I only have a shell to work with.
A: The built-in version shell command is different in 4.x and 5.x .
OSE4.x : “ver”
OSE5.x : “build_info”
Failing that, when the system boots check the console at boot time.
Q: I’m booting with POLO and I noticed that POLO reports it only downloaded 2MB of binary, which doesn’t sound right – I know the binary is at least 10MB. However it appears to boot and run without problems.
A: POLO may or may not accurately report the actual total downloadable size of the binary image, based on the compiler used. Some compilers are better than others at giving POLO correct information. Others will simply report the size of the stripped elf (rtose_s.elf) rather than the full-blown size of a release or debug elf. It’s confusing but not a big cause for concern.
A: The “debug” shell command can be enabled in refsys builds only. You must make sure you’ve got refsys build capability for your binary. If you do (OSE4.6 and up) you can enable it by adding the following:
rtose.mk : add “USE_DEBUG = yes”
rtose4.conf : set debug option to “debug=enable:no”
Then “make all” in the refsys target directory and your rtose.elf binary will have “debug” command enabled.
NOTE: In OSE4.5.2 the rtose.mk file is actually Makefile instead. (But I haven’t been able to test refsys with 4.5.2 yet.)
Q: I am trying to connect to my already-running target using powerpc-ose-gdb, but when I type “info ose targets” it just returns nothing. What is wrong?
A: If you’ve waited a bit already (at least 15 secs), then sounds like your host cannot communicate with the target. Possible reasons include
- incorrect inet configuration (rtose*.conf)
- inet/default_gw is incorrect (try leaving it blank for static IP)
- ose_dbgserver not running (“ps ose_d*”)
- binary not compiled with proper gcc flavor (different target flavors in 5.1)
- network card or cable malfunction (can host/target ping each other? Can Illuminator System Browser see the target?)
- misc. software interference (VMWare, VPN etc)
Q: I’m compiling with GHS MULTI and got this error:
[elxr] (error) cannot find library –lc
A: Alas, you are trying to compile MULTI on OSE5.x which isn’t yet supported. Stick with 4.x for now.
Q: I’m new to this RTOS and I have no idea to find out which version of OSE I’m running currently, and I only have a shell to work with.
A: The built-in version shell command is different in 4.x and 5.x .
OSE4.x : “ver”
OSE5.x : “build_info”
Failing that, when the system boots check the console at boot time.
Q: I’m booting with POLO and I noticed that POLO reports it only downloaded 2MB of binary, which doesn’t sound right – I know the binary is at least 10MB. However it appears to boot and run without problems.
A: POLO may or may not accurately report the actual total downloadable size of the binary image, based on the compiler used. Some compilers are better than others at giving POLO correct information. Others will simply report the size of the stripped elf (rtose_s.elf) rather than the full-blown size of a release or debug elf. It’s confusing but not a big cause for concern.
Monday, March 06, 2006
Tips for the week: Mar 6 2006
Q: I uninstalled WinPCap and installed a newer version, now I'm not able to boot my soft kernels anymore, and get this instead:
0.090 netw: Configuring INET.
win32eth: Failed to open adapter '???????????????r?????????????????????????????
?????????????????????}?????????????????????????', error 20
0.090 netw: Failed to open Ethernet device driver sfketh unit 0.
A: Manual -> OSE Getting Started -> Environment Preparation -> Network Access in Soft Kernels:
"OSE has been tested with versions 2.3 and 3.0 of WinPCap. Be careful when using alpha or beta versions of WinPCap, experience have shown that these are often unreliable or introduce interface changes (requiring an updated win32eth driver). A working version of WinPCap is included in the OSE release. "
Hint: You can also get around it temporarily by commenting out the lnh/udp in rtose4.conf (usually).
Q: Arrggh, I can't/won't use this WinPCap stuff, but I still need to boot soft kernels. Is there any hope?
A: There is a little-documented way to get around using WinPCap while still having networking on releases 5.1 and up. (Doesn't work as well with 4.x) Find your refsys/rtose/sfk-win32/rtose.mk file and comment out the lines for BSP_ETHERNET and win32eth.o, and add a USE_NETWORK line to include the inetapi network:
USE_NETWORK = inetapi
#DEFINE += -DBSP_ETHERNET
#OBJECTS += win32eth.o
Then "make clean cleanall cleanobj" and "make all" again and your network should be working without WinPCap.
Q: I'm trying to build refsys for OSE5.1 using Eclipse under Windows 2000, and it's not finding the REFSYSROOT properly and causing the builds to fail. They build okay outside of Eclipse, but in Eclipse when you build the target "all" they do this:
rtose.mk:41: /rtose/common_rtose.mk: No such file or directory
make[1]: *** No rule to make target > > > > `/rtose/common_rtose.mk'. Stop.
And editing refsys/environment.mk to point to REFSYSROOT properly as "../.." does not help.
A: In the manual: Eclipse for OSE User's guide -> Configuration -> Using Cygwin on Windows
"
free invisible web counter
