Jenn's Support Shop

Q: I'm switching over to windows 7 and am having problems getting ose to build. I followed the instructions in the installation guide regarding installing as admin etc., but am seeing the following errors:

The syntax of the command is incorrect.

"--- Making modules/badapp"

The syntax of the command is incorrect.

"--- Compiling src/badapp.c"

"--- Making modules/corecmds"

The syntax of the command is incorrect.

"--- Compiling src/cmd_pool.c"

"--- Making modules/ddi"

I'm also seeing this problem with sigdb1:

SigDB1: Error: I/O error using file: obj\rtose_debug\sigdb1.c (The system cannot find the path specified)

make[1]: *** [obj/rtose_debug/sigdb.c] Error 1

"--- Error building RTOSE(debug) for C:\Enea\OSE\BSP_P2020RDB_OSE5.5\refsys\rtose\p2020rdb"

A: This is likely an installation issue with Windows 7. Re-install and re-run the install using all the instructions in the OSE installation doc for changing UAC permissions etc. After about the 3rd time and several reboots it started working. (info from Larry G)

Change the owners from "admin" to yourself, i.e. your own account, reboot, rebuild. (from J.M.)

Make sure you're using cygwin, not DOS - alot of the commands no longer work with DOS. (from E.B.)
 

Labels: installation, OSE, refsys, windows 7

Q: I just got a BSP delivery for my OSE5.5 product. I used the refsys reference build in OSE5 previously; however there isn't a /refsys directory in this BSP at all (!), only an /examples directory, and a /doc directory.

A: Your BSP delivery is actually a new style called "modsys" and is designed to be the new paradigm for reference platforms in OSE systems that support multicore. Starting in OSE5.5, all BSP that support multiple cores will be delivered in the modsys style rather than the refsys one.

To learn how to build in for modsys, refer to the new Modsys User's Guide, delivered with all modsys BSPs in the doc directory. There is a documentation error in the book-installation-guide.pdf delivered with the modsys BSPs for OSE5.5 which omits the mention of this guide, but this is corrected in subsequent OSE5.5.x releases.

Q: I just tried "make all" in my BSP examples/ and it gave this error:

/vobs/ose5/system/gcc_win32_mips_4.4.3/bin/mips-elf-gcc: not found

A: Since BSPs are delivered separately from the OSE delivery, the BSP architecture type must be matched to the OSE one. In this case you tried to build a BSP for a MIPS board using the OSE delivery for PowerPC. (The customization for internal paths doesn't help either.)

1. First verify you have the correct OSE architecture installed.

2. Change dir into $BSP_ROOT/examples//sysmake

3. Edit tools.mk to change this:

OSEROOT_ABS ?= /vobs/ose5/system
to this:
OSEROOT_ABS ?= C:/OSE/OSE5.5_MIPS
or whatever is appropriate.

Q: I don't see the rtose5.conf file either. Or rtose.mk. What happened there?

A: It's sort of been split up. In the modsys way, there are three main make targets now: "kernel", "lmbuild", and "image."

If you "make kernel", your build will extract .conf parameters from a new file called examples//kernel/kernel.conf. This conf file also contains any necessary parameters to make the bare-bones kernel.elf binary (e.g. dda, pm). The kernel.conf however is missing quite a few items that aren't valid for just a kernel build.

If you "make lmbuild" you will end up building all the load modules in the modules directory, for which .conf parameters aren't really valid.

When you "make image", the sys.conf file defines system parameters for all the core extensions along with krn parameters, such as inet, ramdisk, ffx, heap, and so on. However, it won't actually work unless you build the kernel and lmbuild targets first.

So a full build command after make clean is now: "make kernel lmbuild image". This is equivalent to "make all." And it builds rtose_release by default;the "FLAVOR=debug" make option still works though.

The osemain.con is also split among kernel and load modules, as it was in the old refsys.

Labels: BSP, modsys, OSE5, refsys

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.

Labels: dbgprintf, migration, OSE5.3, refsys