process table for XMK

xilkernel maintains an internal table of ready/waiting/running processes and their priorities. This table can be statically initialized by specifying a list of process start-addresses and priorities in the MSS (assign to the PROCESS_TABLE parameter). On startup xilkernel starts running the highest priority process in this table. In your example, the process table is initialized with a single element with priority 1 and start address 0xA0000000 so xilkernel will start executing the code at this address. If you want two threads, this main application can start up the other other thread/process using the create_process() or create_thread() function, or you can write the other thread as a separate application with a different start address, and specify that on the PROCESS_TABLE list in the MSS file.

--   Mohan   Frank wrote: Hi, Could anyone explain the meaning of the process_table parameter in the mss file (when using the xilkernel). I have a bootloader with the following stuff in the mss file: BEGIN LIBRARY  PARAMETER LIBRARY_NAME = xilkernel  PARAMETER LIBRARY_VER = 1.00.a  PARAMETER MAX_PROCS = 1  PARAMETER PROCESS_TABLE = ((0xA0000000, 1))  PARAMETER CONFIG_THREAD_SUPPORT = true  PARAMETER MAX_THREADS = 2  PARAMETER THREAD_STACK_SIZE = 0x100  PARAMETER CONFIG_SEMA = true  PARAMETER MAX_SEMA = 1 END Besides that, I have an application (with his own makefile) which should be run from address 0xA0000000, so in the makefile I use the linker option LFLAGS = -xl-mode-xilkernel -Wl,-defsym -Wl,_TEXT_START_ADDR=0xA0000000 When I disassemble the .elf file of the application, it's all ok (addresses starts from 0xA0000000). So what is the meaning of the address in the process_table parameter in the mss file of the bootloader?? Does it make any sense? Or do I not need the process stuff at all, but just use the thread parameters (I only want an application which contains two threads)?! Thanks, Frank

=_NextPart_000_0008_01C3BB14.EA492CB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

So when the bootloader is started, the xilkernel automattically tries to = start executing the code at address 0xA0000000?! But in my case there is = no application at startup! I first have to download it and then I jump = from the code in the bootloader to the address of the application = (0xA0000000). Thus, if I understand it correctly, I MUST remove the = process_table parameter of the mss file?! (The bootloader should do = nothing with xilkernel stuff, only my application is using it).

Frank "mohan" wrote in message = news: snipped-for-privacy@xilinx.com... xilkernel maintains an internal table of ready/waiting/running = processes and their priorities.=20 This table can be statically initialized by specifying a list of = process start-addresses and priorities in the MSS (assign to the = PROCESS_TABLE parameter).=20 On startup xilkernel starts running the highest priority process in = this table.=20 In your example, the process table is initialized with a single = element with priority 1 and start address 0xA0000000 so xilkernel will = start executing the code at this address.=20 If you want two threads, this main application can start up the other = other thread/process using the create_process() or create_thread() = function, or you can write the other thread as a separate application = with a different start address, and specify that on the PROCESS_TABLE = list in the MSS file.=20

So when the bootloader is started, the xilkernel automattically tries to start executing the code at address

0xA0000000?! But in my case there is no application at startup! I first have to download it and then I jump from the code in the bootloader to the address of the application (0xA0000000). Thus, if I understand it correctly, I MUST remove the process_table parameter of the mss file?! (The bootloader should do nothing with xilkernel stuff, only my application is using it).Frank

=_NextPart_000_0007_01C3BD70.5B2A6E00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Well, maybe I am doing it totally wrong. Let me explain how I set it up:

- I have a directory with mhs, mss files code etc (lets call it = bootldr). This is the directory for the bootloader. The bootloader = should do nothing with xilkernel.

- The bootloader should run in BRAM.

- I have a seperate directory for my final application (lets call it = appl) it's at the same level as the bootldr directory. The directory has = its own makefile and code, but no mhs, mss file etc. because it's using = the same architecture as the bootloader (this is why the xilkernel = library block is placed in the mss file of the bootloader). The = application will use the xilkernel facilities (threads, semaphores = etc.).

- The application should run in SDRAM.

- The makefile for the application is like this:

CC=3Dmb-gcc AR=3Dmb-ar

CFLAGS =3D -O2 -g

SRC =3D ../src INC =3D ../include OBJS =3D appl.o hwinit.o debug.o hal.o leds.o crc.o can_sja1k.o irq.o = pci.o pecx.o threads.o \ can.o timer.o

TOPDIR =3D ../mblaze/code SYSTEMDIR =3D ../bootldr/mblaze INCLUDEDIR =3D $(SYSTEMDIR)/include LIBDIR =3D $(SYSTEMDIR)/lib INCLUDES =3D -I$(INCLUDEDIR) -I$(INC) LIBS =3D -L$(LIBDIR) -L$(TOPDIR)

LIBRARIES =3D -lw

# Linker options for the elf file LFLAGS =3D -xl-mode-xilkernel -Wl,-defsym =

-Wl,_TEXT_START_ADDR=3D0xA0000000 VPATH =3D $(SRC)

all: @echo "Makefile to build application which runs on SDRAM" @echo " - SDRAM base address: 0xA0000000" @echo " - application is placed in SDRAM by bootloader" @echo "" @echo "Usage: make appl"

appl: $(OBJS) makefile $(INCLUDEDIR)/xparameters.h $(CC) $(CFLAGS) -o appl.elf $(OBJS) $(LFLAGS) $(LIBS) $(LIBRARIES) @echo "appl.elf created at location 0xA0000000"

%.o:%.c $(CC) $(CFLAGS) -c $< -o $@ $(INCLUDES)

%.o:%.s $(CC) $(CFLAGS) -c $< -o $@=20

clean: rm -f $(OBJS) *.elf

$(INCLUDEDIR)/xparameters.h: $(error Make sure you have built the libraries for the bootloader)

So, in my opinion, the application is linking the xilkernel stuff by use = of the -L option in the LIBS variable. The bootloader is not linking = xilkernel stuff, because it does not use anything from the kernel (no = threads or something else) or am I wrong at this point and is something = linked automatically when using the xilkernel library in the mss file? = Could you tell me if I have to define the process_table parameter in the = mss file in the described situation or not at all?!

0xA0000000 -> transfers control to it. And the app seems to be = configured as a stand-alone executable (not linked to xilkernel).=20 Frank wrote:=20

So when the bootloader is started, the xilkernel automattically = tries to start executing the code at address 0xA0000000?! But in my case = there is no application at startup! I first have to download it and then = I jump from the code in the bootloader to the address of the application = (0xA0000000). Thus, if I understand it correctly, I MUST remove the = process_table parameter of the mss file?! (The bootloader should do = nothing with xilkernel stuff, only my application is using it).Frank

When you use the -lw option for your application you link in the system call library for xilkernel. This library provides functions such as process_create, thread_create, send_message, etc. (see docs for exact function names). When you invoke one of these functions, control goes back to the xilkernel executable which does the necessary bookkeeping actions and returns to your app. The xilkernel info in your MSS files causes an executable called xilkernel.elf to be created if you specify the multi-elf-file mode (the default mode). I would expect the bootloader to load this elf - "xilkernel.elf" into memory, and let xilkernel.elf automatically load the "app" by specifying the app's start address in the process table parameter in the MSS. If you build the bootloader as an "executable" and xilkernel.elf using the default mode (xmdstub), the overall memory map looks like this:

0x0: reset vector, interrupt and exception handler jumps

-- 6 words --

-- xmdstub code for xilkernel.elf or bootloader code for bootloader--

0x400: xilkernel.elf code starts here

-- approx 10K of xilkernel code depending on selections --

0xA0000000: Application code starts here

So if the bootloader code is smaller than the 0x400 bytes, there should be no problem directly loading the xilkernel code. Otherwise, you could force the xilkernel.elf code to start at a higher address by modifying the linker script or the make file that creates this elf file.

Hope this helps, Mohan

Well, that's totally different from what I thought it's working. Okay, I saw that the xilkernel executable is created and also an bootloader executable. Besides I have an application executable. If I understand everything, I have to run the bootloader (which is done automatically, because it's beginning at address 0) located in BRAM. With this bootloader I should download the xilkernel executable and put it in memory. Because the process_table parameter in the MSS file is specified, the kernel wants to start a process (which is my application), so I have to download first the application to

0xA0000000 and then the xilkernel to 0x400. Is that correct?! How to start the application if the process_table parameter is not specified? Jump to application and do a process create here?!

By the way, my bootloader exceeds the 0x400 bytes, thus I have to put the xilkernel at a higher address by using a linkerscript. Can I put it also in external memory? And how to start up the xilkernel when downloaded into external memory, just jump to the start address of it? Does the xilkernel contain startup code for initializing data, stack etc.? (I guess the answer is yes, because a disassembly of the .elf file shows me there is a _crtinit). My application does also contain startup code for initializing data, stack etc, doesn't it? How is this working? Are there different stacks (one for xilkernel and one for application)?

My last question is about getting the xilkernel starting at external memory (if possible): how to easilly change the common makefile (common for bootloader and xilkernel) or linkerscript to let the bootloader start in BRAM and the kernel start at external SDRAM?! Do you have any examples?!

A lot of questions again, hopefully you can make it clear for me.

TIA, Frank

call library for xilkernel. This library provides functions such as process_create, thread_create, send_message, etc. (see docs

goes back to the xilkernel executable which does the necessary bookkeeping actions and returns to your app.

xilkernel.elf to be created if you specify the multi-elf-file mode (the default mode).

memory, and let xilkernel.elf automatically load the "app" by specifying the app's start address in the process table parameter in

default mode (xmdstub), the overall memory map looks like this:

no problem directly loading the xilkernel code.

address by modifying the linker script or the make file that creates this elf file.

That is correct.

There are three ways to start an application that works with xilkernel

1) Put the start address of the app in the process_table in the MSS 2) Use process_create() from some application whose start address was in the process_table in the MSS 3) Use process_create() from some application started in one of the above two ways.

Yes.

Exactly.

That is correct. The application and xilkernel have their own separate stacks and heaps.

The bootloader and xilkernel use separate make files and linker scripts. For the bootloader, the makefile is in your top level project directory. For xilkernel the makefile is in //libsrc/xilkernel_v1_00a/ So you can modify them independently. We do have some examples of xilkernel usage in the xilkernel_*/src/test/arch/* directories. However, none of these examples shows how to use a bootloader. The PowerPC examples have xilkernel and applications running out of different memories (BRAM + SRAM or BRAM + SDRAM or SDRAM alone) but linker scripts for PowerPC are different from MicroBlaze linker scripts and you would have to read the PowerPC+EDK documentation as well.

We are working on more examples and documentation for xilkernel itself and you can expect to see them soon. Meanwhile, if you have more questions please feel free to ask.

Best wishes, Mohan