process table for XMK

F

Frank

Guest
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
 
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
xilkernel maintains an internal table of ready/waiting/running processes
and their priorities.
<br>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).
<br>On startup xilkernel starts running the highest priority process in
this table.
<br>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.
<br>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.
<p>--
<br>&amp;nbsp; Mohan
<br>&amp;nbsp;
<p>Frank wrote:
&lt;blockquote TYPE=CITE&gt;Hi,
<p>Could anyone explain the meaning of the process_table parameter in the
mss
<br>file (when using the xilkernel). I have a bootloader with the following
<br>stuff in the mss file:
<p>BEGIN LIBRARY
<br>&amp;nbsp;PARAMETER LIBRARY_NAME = xilkernel
<br>&amp;nbsp;PARAMETER LIBRARY_VER = 1.00.a
<br>&amp;nbsp;PARAMETER MAX_PROCS = 1
<br>&amp;nbsp;PARAMETER PROCESS_TABLE = ((0xA0000000, 1))
<br>&amp;nbsp;PARAMETER CONFIG_THREAD_SUPPORT = true
<br>&amp;nbsp;PARAMETER MAX_THREADS = 2
<br>&amp;nbsp;PARAMETER THREAD_STACK_SIZE = 0x100
<br>&amp;nbsp;PARAMETER CONFIG_SEMA = true
<br>&amp;nbsp;PARAMETER MAX_SEMA = 1
<br>END
<p>Besides that, I have an application (with his own makefile) which should
be
<br>run from address 0xA0000000, so in the makefile I use the linker option
<p>LFLAGS = -xl-mode-xilkernel -Wl,-defsym -Wl,_TEXT_START_ADDR=0xA0000000
<p>When I disassemble the .elf file of the application, it's all ok (addresses
<br>starts from 0xA0000000). So what is the meaning of the address in the
<br>process_table parameter in the mss file of the bootloader?? Does it
make any
<br>sense? Or do I not need the process stuff at all, but just use the
thread
<br>parameters (I only want an application which contains two threads)?!
<p>Thanks,
<br>Frank&lt;/blockquote&gt;
&lt;/html&gt;
 
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" &lt;mohan@xilinx.com&gt; wrote in message news:3FCFACBF.E47332F4@xilinx.com...
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
 
&lt;!doctype html public "-//w3c//dtd html 4.0 transitional//en"&gt;
&lt;html&gt;
&lt;body bgcolor="#FFFFFF"&gt;
Just curious - where does xilkernel fit in? Bootloader -&gt; loads app at
0xA0000000 -&gt; transfers control to it. And the app seems to be configured
as a stand-alone executable (not linked to xilkernel).
<p>Frank wrote:
&lt;blockquote TYPE=CITE&gt;&lt;style&gt;&lt;/style&gt;
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).&lt;font face="Arial"&gt;&lt;font size=-1&gt;Frank&lt;/font&gt;&lt;/font&gt;&lt;/blockquote&gt;

&lt;/body&gt;
&lt;/html&gt;
 
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=mb-gcc
AR=mb-ar

CFLAGS = -O2 -g

SRC = ../src
INC = ../include
OBJS = 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 = ../mblaze/code
SYSTEMDIR = ../bootldr/mblaze
INCLUDEDIR = $(SYSTEMDIR)/include
LIBDIR = $(SYSTEMDIR)/lib
INCLUDES = -I$(INCLUDEDIR) -I$(INC)
LIBS = -L$(LIBDIR) -L$(TOPDIR)

LIBRARIES = -lw

# Linker options for the elf file
LFLAGS = -xl-mode-xilkernel -Wl,-defsym -Wl,_TEXT_START_ADDR=0xA0000000
VPATH = $(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 $&lt; -o $@ $(INCLUDES)

%.o:%.s
$(CC) $(CFLAGS) -c $&lt; -o $@

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?!

TIA,
Frank
"mohan" &lt;mohan@xilinx.com&gt; wrote in message news:3FD0CA73.D3F0E9E5@xilinx.com...
Just curious - where does xilkernel fit in? Bootloader -&gt; loads app at 0xA0000000 -&gt; transfers control to it. And the app seems to be configured as a stand-alone executable (not linked to xilkernel).
Frank wrote:

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

"mohan" &lt;mohan@xilinx.com&gt; wrote in message
news:3FD4EE73.F5C7F556@xilinx.com...
When you use the -lw option for your application you link in the system
call library for xilkernel. This library provides functions such as
Click to expand...
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
Click to expand...
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
Click to expand...
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
Click to expand...
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
Click to expand...
elf file.
Hope this helps,
Mohan
Click to expand...
 
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?!
Click to expand...
That is correct.

How to start the application if the process_table parameter is not
specified? Jump to application and do a process create here?!
Click to expand...
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.

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?
Click to expand...
Yes.

And how to start up the xilkernel when downloaded into
external memory, just jump to the start address of it?
Click to expand...
Exactly.
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)?
Click to expand...
That is correct. The application and xilkernel have their own separate stacks and heaps.

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?!
Click to expand...
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 &lt;project-dir&gt;/&lt;mblaze&gt;/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
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top