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
process table for XMK
Started by ●December 4, 2003
Reply by ●December 4, 20032003-12-04
<!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> Mohan <br> <p>Frank wrote: <blockquote TYPE=CITE>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> PARAMETER LIBRARY_NAME = xilkernel <br> PARAMETER LIBRARY_VER = 1.00.a <br> PARAMETER MAX_PROCS = 1 <br> PARAMETER PROCESS_TABLE = ((0xA0000000, 1)) <br> PARAMETER CONFIG_THREAD_SUPPORT = true <br> PARAMETER MAX_THREADS = 2 <br> PARAMETER THREAD_STACK_SIZE = 0x100 <br> PARAMETER CONFIG_SEMA = true <br> 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</blockquote> </html>
Reply by ●December 5, 20032003-12-05
This is a multi-part message in MIME format. ------=_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" <mohan@xilinx.com> wrote in message = news:3FCFACBF.E47332F4@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 --=20 Mohan=20 =20 Frank wrote:=20 Hi,=20 Could anyone explain the meaning of the process_table parameter in = the mss=20 file (when using the xilkernel). I have a bootloader with the = following=20 stuff in the mss file:=20 BEGIN LIBRARY=20 PARAMETER LIBRARY_NAME =3D xilkernel=20 PARAMETER LIBRARY_VER =3D 1.00.a=20 PARAMETER MAX_PROCS =3D 1=20 PARAMETER PROCESS_TABLE =3D ((0xA0000000, 1))=20 PARAMETER CONFIG_THREAD_SUPPORT =3D true=20 PARAMETER MAX_THREADS =3D 2=20 PARAMETER THREAD_STACK_SIZE =3D 0x100=20 PARAMETER CONFIG_SEMA =3D true=20 PARAMETER MAX_SEMA =3D 1=20 END=20 Besides that, I have an application (with his own makefile) which = should be=20 run from address 0xA0000000, so in the makefile I use the linker = option=20 LFLAGS =3D -xl-mode-xilkernel -Wl,-defsym = -Wl,_TEXT_START_ADDR=3D0xA0000000=20 When I disassemble the .elf file of the application, it's all ok = (addresses=20 starts from 0xA0000000). So what is the meaning of the address in = the=20 process_table parameter in the mss file of the bootloader?? Does it = make any=20 sense? Or do I not need the process stuff at all, but just use the = thread=20 parameters (I only want an application which contains two threads)?! = Thanks,=20 Frank ------=_NextPart_000_0008_01C3BB14.EA492CB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV>So when the bootloader is started, the xilkernel automattically = tries to=20 start executing the code at address 0xA0000000?! But in my case there is = no=20 application at startup! I first have to download it and then I jump from = the=20 code in the bootloader to the address of the application (0xA0000000). = Thus, if=20 I understand it correctly, I MUST remove the process_table parameter of = the mss=20 file?! (The bootloader should do nothing with xilkernel stuff, only my=20 application is using it).<BR></DIV> <DIV><FONT face=3DArial size=3D2>Frank</FONT></DIV> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; = BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px"> <DIV>"mohan" <<A = href=3D"mailto:mohan@xilinx.com">mohan@xilinx.com</A>>=20 wrote in message <A=20 = href=3D"news:3FCFACBF.E47332F4@xilinx.com">news:3FCFACBF.E47332F4@xilinx.= com</A>...</DIV>xilkernel=20 maintains an internal table of ready/waiting/running processes and = their=20 priorities. <BR>This table can be statically initialized by specifying = a list=20 of process start-addresses and priorities in the MSS (assign to the=20 PROCESS_TABLE parameter). <BR>On startup xilkernel starts running the = highest=20 priority process in this table. <BR>In your example, the process table = is=20 initialized with a single element with priority 1 and start address = 0xA0000000=20 so xilkernel will start executing the code at this address. <BR>If you = want=20 two threads, this main application can start up the other other = thread/process=20 using the create_process() or create_thread() function, or you can = write the=20 other thread as a separate application with a different start address, = and=20 specify that on the PROCESS_TABLE list in the MSS file.=20 <P>-- <BR> Mohan <BR> =20 <P>Frank wrote:=20 <BLOCKQUOTE TYPE=3D"CITE">Hi,=20 <P>Could anyone explain the meaning of the process_table parameter = in the=20 mss <BR>file (when using the xilkernel). I have a bootloader with = the=20 following <BR>stuff in the mss file:=20 <P>BEGIN LIBRARY <BR> PARAMETER LIBRARY_NAME =3D xilkernel=20 <BR> PARAMETER LIBRARY_VER =3D 1.00.a <BR> PARAMETER = MAX_PROCS =3D 1=20 <BR> PARAMETER PROCESS_TABLE =3D ((0xA0000000, 1)) = <BR> PARAMETER=20 CONFIG_THREAD_SUPPORT =3D true <BR> PARAMETER MAX_THREADS =3D 2 = <BR> PARAMETER THREAD_STACK_SIZE =3D 0x100 <BR> PARAMETER=20 CONFIG_SEMA =3D true <BR> PARAMETER MAX_SEMA =3D 1 <BR>END=20 <P>Besides that, I have an application (with his own makefile) which = should=20 be <BR>run from address 0xA0000000, so in the makefile I use the = linker=20 option=20 <P>LFLAGS =3D -xl-mode-xilkernel -Wl,-defsym = -Wl,_TEXT_START_ADDR=3D0xA0000000=20 <P>When I disassemble the .elf file of the application, it's all ok=20 (addresses <BR>starts from 0xA0000000). So what is the meaning of = the=20 address in the <BR>process_table parameter in the mss file of the=20 bootloader?? Does it make any <BR>sense? Or do I not need the = process stuff=20 at all, but just use the thread <BR>parameters (I only want an = application=20 which contains two threads)?!=20 <P>Thanks, <BR>Frank</P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_0008_01C3BB14.EA492CB0--
Reply by ●December 5, 20032003-12-05
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <body bgcolor="#FFFFFF"> Just curious - where does xilkernel fit in? Bootloader -> loads app at 0xA0000000 -> transfers control to it. And the app seems to be configured as a stand-alone executable (not linked to xilkernel). <p>Frank wrote: <blockquote TYPE=CITE><style></style> 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).<font face="Arial"><font size=-1>Frank</font></font></blockquote> </body> </html>
Reply by ●December 8, 20032003-12-08
This is a multi-part message in MIME format. ------=_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?! TIA, Frank "mohan" <mohan@xilinx.com> wrote in message = news:3FD0CA73.D3F0E9E5@xilinx.com... Just curious - where does xilkernel fit in? Bootloader -> loads app at = 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 ------=_NextPart_000_0007_01C3BD70.5B2A6E00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR></HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>Well, maybe I am doing it totally = wrong. Let me=20 explain how I set it up:</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>- I have a directory with mhs, mss = files code etc=20 (lets call it bootldr). This is the directory for the bootloader. The = bootloader=20 should do nothing with xilkernel.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>- The bootloader should run in = BRAM.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>- I have a seperate directory for my = final=20 application (lets call it appl) it's at the same level as the bootldr = directory.=20 The directory has its own makefile and code, but no mhs, mss file etc. = because=20 it's using the same architecture as the bootloader (this is why the = xilkernel=20 library block is placed in the mss file of the bootloader). The = application=20 will use the xilkernel facilities (threads, semaphores = etc.).</FONT></DIV> <DIV><FONT face=3DArial size=3D2>- The application should run in = SDRAM.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>- The makefile for the application is = like=20 this:</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>CC=3Dmb-gcc<BR>AR=3Dmb-ar</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>CFLAGS =3D -O2 -g<BR></FONT><FONT = face=3DArial=20 size=3D2></FONT></DIV> <DIV><FONT face=3DArial size=3D2>SRC =3D ../src<BR>INC =3D=20 ../include<BR>OBJS =3D appl.o hwinit.o debug.o hal.o leds.o crc.o = can_sja1k.o=20 irq.o pci.o pecx.o = threads.o \<BR> =20 can.o timer.o</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>TOPDIR =3D ../mblaze/code<BR>SYSTEMDIR = =3D=20 ../bootldr/mblaze<BR>INCLUDEDIR =3D $(SYSTEMDIR)/include<BR>LIBDIR =3D=20 $(SYSTEMDIR)/lib<BR>INCLUDES =3D -I$(INCLUDEDIR) -I$(INC)<BR>LIBS =3D = -L$(LIBDIR)=20 -L$(TOPDIR)</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>LIBRARIES =3D -lw</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2># Linker options for the elf = file<BR>LFLAGS =3D=20 -xl-mode-xilkernel -Wl,-defsym = -Wl,_TEXT_START_ADDR=3D0xA0000000</FONT></DIV> <DIV><FONT face=3DArial size=3D2>VPATH =3D $(SRC)</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>all:<BR> @echo "Makefile to build = application=20 which runs on SDRAM"<BR> @echo " - SDRAM base address:=20 0xA0000000"<BR> @echo " - application is placed in = SDRAM by=20 bootloader"<BR> @echo ""<BR> @echo "Usage: make = appl"</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>appl: $(OBJS) makefile=20 $(INCLUDEDIR)/xparameters.h<BR> $(CC) $(CFLAGS) -o appl.elf $(OBJS) = $(LFLAGS) $(LIBS) $(LIBRARIES)<BR> @echo "appl.elf created at = location=20 0xA0000000"</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>%.o:%.c<BR> $(CC) $(CFLAGS) -c = $< -o $@=20 $(INCLUDES)</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>%.o:%.s<BR> $(CC) $(CFLAGS) -c = $< -o $@=20 </FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>clean:<BR> rm -f $(OBJS) = *.elf</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial = size=3D2>$(INCLUDEDIR)/xparameters.h:<BR> $(error Make=20 sure you have built the libraries for the bootloader)<BR></FONT></DIV> <DIV><FONT face=3DArial size=3D2>So, in my opinion, the = application is linking=20 the xilkernel stuff by use of the -L option in the LIBS variable. The = bootloader=20 is not linking xilkernel stuff, because it does not use anything from = the kernel=20 (no threads or something else) or am I wrong at this point and is = something=20 linked automatically when using the xilkernel library in the mss file? = Could you=20 tell me if I have to define the process_table parameter in the mss file = in the=20 described situation or not at all?!</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>TIA,</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Frank</DIV></FONT> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; = BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px"> <DIV>"mohan" <<A = href=3D"mailto:mohan@xilinx.com">mohan@xilinx.com</A>>=20 wrote in message <A=20 = href=3D"news:3FD0CA73.D3F0E9E5@xilinx.com">news:3FD0CA73.D3F0E9E5@xilinx.= com</A>...</DIV>Just=20 curious - where does xilkernel fit in? Bootloader -> loads app at=20 0xA0000000 -> transfers control to it. And the app seems to be = configured=20 as a stand-alone executable (not linked to xilkernel).=20 <P>Frank wrote:=20 <BLOCKQUOTE TYPE=3D"CITE"> <STYLE></STYLE> So when the bootloader is started, the xilkernel automattically = tries to=20 start executing the code at address 0xA0000000?! But in my case = there is no=20 application at startup! I first have to download it and then I jump = from the=20 code in the bootloader to the address of the application = (0xA0000000). Thus,=20 if I understand it correctly, I MUST remove the process_table = parameter of=20 the mss file?! (The bootloader should do nothing with xilkernel = stuff, only=20 my application is using it).<FONT face=3DArial><FONT=20 = size=3D-1>Frank</FONT></FONT></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_0007_01C3BD70.5B2A6E00--
Reply by ●December 8, 20032003-12-08
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
Reply by ●December 9, 20032003-12-09
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" <mohan@xilinx.com> wrote in message news:3FD4EE73.F5C7F556@xilinx.com...> When you use the -lw option for your application you link in the systemcall 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, controlgoes 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 calledxilkernel.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" intomemory, 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 thedefault 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 beno problem directly loading the xilkernel code.> Otherwise, you could force the xilkernel.elf code to start at a higheraddress by modifying the linker script or the make file that creates this elf file.> > Hope this helps, > Mohan
Reply by ●December 9, 20032003-12-09
> 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?!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?!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?Yes.> And how to start up the xilkernel when downloaded into > external memory, just jump to the start address of it?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)?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?!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 <project-dir>/<mblaze>/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