From dpc at ucore.info Thu Feb 11 00:33:10 2010 From: dpc at ucore.info (=?UTF-8?B?RGF3aWQgQ2nEmcW8YXJraWV3aWN6?=) Date: Thu, 11 Feb 2010 01:33:10 +0100 Subject: Build environment improvement. Message-ID: Hi, Each time I'm having to set up codezero environment I found it so time consuming that I've decided to automate it. I've wrote a script: http://github.com/dpc/codezero/blob/init-build-env/tools/init-build-env.sh which does the job fine for me. I'm just playing with codezero - just like many people would, I guess. So having an easy tool to setup the environment safely and easily can give codezero much greater audience, I think. I've made some modification to the run-qemu-insight as well: http://github.com/dpc/codezero/blob/init-build-env/tools/run-qemu-insight so that insight setup is less intrusive to the rest of the system. The whole fork on which I'm working can be found here: http://github.com/dpc/codezero/tree/init-build-env To be honest I've never managed to get codezero building environment fully working. I think I'm close now, however I can't find the file required for: sym /opt/codezero/tasks/mm0/mm0.axf command to work in gdbinit. Can someone help me with this one? -- http://dpc.ucore.info From amit.mahajan at b-labs.co.uk Thu Feb 11 04:36:09 2010 From: amit.mahajan at b-labs.co.uk (Amit Mahajan) Date: Thu, 11 Feb 2010 10:06:09 +0530 Subject: Build environment improvement. In-Reply-To: References: Message-ID: <1265862969.3682.6.camel@amit-laptop> Hi Dawid, On Thu, 2010-02-11 at 01:33 +0100, Dawid Ci??arkiewicz wrote: > Hi, > > Each time I'm having to set up codezero environment I found it so time > consuming that I've decided to automate it. > > I've wrote a script: > http://github.com/dpc/codezero/blob/init-build-env/tools/init-build-env.sh > > which does the job fine for me. Looks fine to me. > I'm just playing with codezero - just like many people would, I guess. > So having an easy tool to setup the environment safely and easily can > give codezero much greater audience, I think. > > I've made some modification to the run-qemu-insight as well: > http://github.com/dpc/codezero/blob/init-build-env/tools/run-qemu-insight > so that insight setup is less intrusive to the rest of the system. > > The whole fork on which I'm working can be found here: > http://github.com/dpc/codezero/tree/init-build-env > > > To be honest I've never managed to get codezero building environment > fully working. I think I'm close now, however I can't find the file > required for: > sym /opt/codezero/tasks/mm0/mm0.axf > command to work in gdbinit. > > Can someone help me with this one? Please let us know in some detail what issues you are facing in building codezero? Also, mm0.axf file corresponds to the symbol information of pager task(namely mm0) for __POSIX__ containers , so you will only find this binary incase you are building codezero with Posix container support. Also, i think the path you are looking for is old, if you are building codezero v0.2, Posix container gets build at codezero/build/contXX/posix/mm0, where contXX corresponds to the container number of posix container. -- Thanks and Regards Amit Mahajan From bahadir at l4dev.org Thu Feb 11 09:46:51 2010 From: bahadir at l4dev.org (Bahadir Balban) Date: Thu, 11 Feb 2010 11:46:51 +0200 Subject: Build environment improvement. In-Reply-To: References: Message-ID: <4B73D20B.7050106@l4dev.org> Dawid Ci??arkiewicz wrote: > I've wrote a script: > http://github.com/dpc/codezero/blob/init-build-env/tools/init-build-env.sh > > which does the job fine for me. > Dawid, We may also have a script like this eventually. But how often do you need set it up? You need the compiler/insight/qemu and you are done. I would guess it is only insight that requires manual configure/compile stages. > I'm just playing with codezero - just like many people would, I guess. > So having an easy tool to setup the environment safely and easily can > give codezero much greater audience, I think. > > I've made some modification to the run-qemu-insight as well: > http://github.com/dpc/codezero/blob/init-build-env/tools/run-qemu-insight > so that insight setup is less intrusive to the rest of the system. > > The whole fork on which I'm working can be found here: > http://github.com/dpc/codezero/tree/init-build-env > > > To be honest I've never managed to get codezero building environment > fully working. I think I'm close now, however I can't find the file > required for: > sym /opt/codezero/tasks/mm0/mm0.axf > command to work in gdbinit. > > Can someone help me with this one? We have now everything built under build/ but I believe that was a forgotten line. You need to open up the insight console, type sym /kernel.elf and do a stepi. You should see all symbols. As soon as you hit userspace, you may then do a sym of mm0.elf but pass the correct path. Its just loading symbols from actual executables. -- Bahadir From dpc at ucore.info Thu Feb 11 10:03:12 2010 From: dpc at ucore.info (=?UTF-8?B?RGF3aWQgQ2nEmcW8YXJraWV3aWN6?=) Date: Thu, 11 Feb 2010 10:03:12 +0000 Subject: Build environment improvement. In-Reply-To: <1265862969.3682.6.camel@amit-laptop> References: <1265862969.3682.6.camel@amit-laptop> Message-ID: 2010/2/11 Amit Mahajan : >> To be honest I've never managed to get codezero building environment >> fully working. I think I'm close now, however I can't find the file >> required for: >> sym /opt/codezero/tasks/mm0/mm0.axf >> command to work in gdbinit. >> >> Can someone help me with this one? > > Please let us know in some detail what issues you are facing in building > codezero? > > Also, mm0.axf file corresponds to the symbol information of pager > task(namely mm0) for __POSIX__ containers , so you will only find this > binary incase you are building codezero with Posix container support. > > Also, i think the path you are looking for is old, if you are building > codezero v0.2, Posix container gets build at > codezero/build/contXX/posix/mm0, where contXX corresponds to the > container number of posix container. As a newcomer I come with a C and linux kernel development background, but getting into any project is some starting barrier as I don't fully understand what is where and for what purpose. And I have little experience with embedded development practice. "Getting starting" guide is very nice, but as I said - time consuming to follow. This path ( codezero/build/contXX/posix/mm0 ) is in the current (devel branch) in the tools/gdbinit. And I used default settings to build codezero. At the moment I can set up everything to play with codezore (as a newbie): ./tools/init-build-env.sh add the toolchain to the PATH ./configure.py (with defaults) ./build.py ./tools/run-qemu-insight I get a connected insight debugger, but without symbols loaded it seems - probably due to what you've pointed out. I'm currently at work, but I'll try what you suggested when I get back home. I think it would be best if instead of time consuming "Getting started" the impatient user (like me) could just follow such easy and straightforward instruction and in result get the fully working insight with running codezero kernel in which he could click around and enjoy the feeling of having a working L4 kernel in front of him. Regards, Dawid -- http://dpc.ucore.info From bahadir at l4dev.org Thu Feb 11 10:11:11 2010 From: bahadir at l4dev.org (Bahadir Balban) Date: Thu, 11 Feb 2010 12:11:11 +0200 Subject: Build environment improvement. In-Reply-To: References: <1265862969.3682.6.camel@amit-laptop> Message-ID: <4B73D7BF.8030609@l4dev.org> Dawid Ci??arkiewicz wrote: > I get a connected insight debugger, but without symbols loaded it > seems - probably due to what you've pointed out. I'm currently at > work, but I'll try what you suggested when I get back home. > > I think it would be best if instead of time consuming "Getting > started" the impatient user (like me) could just follow such easy and > straightforward instruction and in result get the fully working > insight with running codezero kernel in which he could click around > and enjoy the feeling of having a working L4 kernel in front of him. > > Regards, > Dawid > Yes I think it is a good idea. I will add to todo list. -- Bahadir From dpc at ucore.info Thu Feb 11 10:12:59 2010 From: dpc at ucore.info (=?UTF-8?B?RGF3aWQgQ2nEmcW8YXJraWV3aWN6?=) Date: Thu, 11 Feb 2010 10:12:59 +0000 Subject: Build environment improvement. In-Reply-To: <4B73D20B.7050106@l4dev.org> References: <4B73D20B.7050106@l4dev.org> Message-ID: 2010/2/11 Bahadir Balban : > Dawid, > > We may also have a script like this eventually. But how often do you > need set it up? You need the compiler/insight/qemu and you are done. I > would guess it is only insight that requires manual configure/compile > stages. How often? Well. Each time someone want/consider to start playing with codezore. That is one for each Internet user and potential developer you'd like to have in the future. :) Please don't misunderstand my reasons. I've posted this script hoping it may be useful for someone else then me. I'm perfectly fine with you adding it to your tree as well as ignoring it. I just think it is a good thing to lower the entry barriers for any project. And I hope to get help for finish setting up the tools so I can start use codezore myself. >> To be honest I've never managed to get codezero building environment >> fully working. I think I'm close now, however I can't find the file >> required for: >> sym /opt/codezero/tasks/mm0/mm0.axf >> command to work in gdbinit. >> >> Can someone help me with this one? > > We have now everything built under build/ but I believe that was a > forgotten line. You need to open up the insight console, type sym > /kernel.elf and do a stepi. You should see all symbols. > As soon as you hit userspace, you may then do a sym of mm0.elf but pass > the correct path. Its just loading symbols from actual executables. Will try that. Thanks! -- http://dpc.ucore.info From dpc at ucore.info Thu Feb 11 16:38:53 2010 From: dpc at ucore.info (=?UTF-8?B?RGF3aWQgQ2nEmcW8YXJraWV3aWN6?=) Date: Thu, 11 Feb 2010 16:38:53 +0000 Subject: Build environment improvement. In-Reply-To: References: <4B73D20B.7050106@l4dev.org> Message-ID: I'm trying to run the codezero build on a shell account, so I can develop it in the free time remotely. Instead of gdb I'd like to use just plain gdb (no X11). However I can not run a VM with 128MB of memory there, and I can see: $ ./tools/run-qemu-gdb qemu: fatal: Trying to execute code outside RAM or ROM at 0x00e00000 R00=00000000 R01=00000000 R02=00000000 R03=00000000 R04=00000000 R05=00000000 R06=00000000 R07=00000000 R08=00000000 R09=00000000 R10=00000000 R11=00000000 R12=00000000 R13=00000000 R14=00000000 R15=00e00000 PSR=400001d3 -Z-- A svc32 GNU gdb (Sourcery G++ Lite 2009q3-68) 6.8.50.20090630-cvs Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-none-eabi". For bug reporting instructions, please see: when limiting the qemu-system-arm's -m parameter. My question is ... isn't 128MB a little big for a *micro*kernel? :D Is this due to development stage of project? Will I will be able to throw codezero into the real ARM hardware with 1MB of RAM? I guess there is something hardcoded (memory layout?). How do I change this... easily? --- http://dpc.ucore.info From bahadir at l4dev.org Thu Feb 11 17:16:33 2010 From: bahadir at l4dev.org (Bahadir Balban) Date: Thu, 11 Feb 2010 19:16:33 +0200 Subject: Build environment improvement. In-Reply-To: References: <4B73D20B.7050106@l4dev.org> Message-ID: <4B743B71.4090903@l4dev.org> Dawid Ci??arkiewicz wrote: > I'm trying to run the codezero build on a shell account, so I can > develop it in the free time remotely. Instead of gdb I'd like to use > just plain gdb (no X11). > > However I can not run a VM with 128MB of memory there, and I can see: > > $ ./tools/run-qemu-gdb > qemu: fatal: Trying to execute code outside RAM or ROM at 0x00e00000 > This is due to wrong machine type. The loader loads it at 0xe00000 and QEMU machine type you are running does not have ram at that address. Try -M versatilepb -- Bahadir From dpc at ucore.info Thu Feb 11 18:24:22 2010 From: dpc at ucore.info (=?UTF-8?B?RGF3aWQgQ2nEmcW8YXJraWV3aWN6?=) Date: Thu, 11 Feb 2010 19:24:22 +0100 Subject: Build environment improvement. In-Reply-To: <4B743B71.4090903@l4dev.org> References: <4B73D20B.7050106@l4dev.org> <4B743B71.4090903@l4dev.org> Message-ID: 2010/2/11 Bahadir Balban : > This is due to wrong machine type. The loader loads it at 0xe00000 and > QEMU machine type you are running does not have ram at that address. Try > -M versatilepb It seems it the default (and thus I'm trying to us it): qemu-system-arm -s -p 22446 -kernel final.elf -nographic -m 8 -M versatilepb Regards, Dawid -- http://dpc.ucore.info From dpc at ucore.info Thu Feb 11 19:05:55 2010 From: dpc at ucore.info (=?UTF-8?B?RGF3aWQgQ2nEmcW8YXJraWV3aWN6?=) Date: Thu, 11 Feb 2010 20:05:55 +0100 Subject: Build environment improvement. In-Reply-To: References: <4B73D20B.7050106@l4dev.org> <4B743B71.4090903@l4dev.org> Message-ID: I'm unable to get codezero debugging working here. When I'm trying insight I got connected, but nothing lets me get it working. I 've decided to switch to to gdb as I know it a bit better and the frontend could introduce some problems, I've tried both: arm-none-linux-gnueabi-gdb and arm-none-eabi-gdb and what I get is: $ ./tools/run-qemu-gdb2 ELF Loader: Started. Loading the kernel... Entry point: 0x8000 Loading containers... Loading section .cont.0 from top-level elf file. Loading .img.0 section image... Entry point: 0xa0000000 Total of 1 images in this container. Total of 1 container images. elf-loader: kernel entry point is 0x8000 elf-loader: Starting kernel code0: start kernel... code0: Virtual memory enabled. code0: Kernel area 0xf0008000 - 0xf003a000 remapped as 50 pages code0: Kernel built on Feb 10 2010, 23:34:21 code0: Initial page tables moved from 0x30000 to 0xe04000 physical GNU gdb (Sourcery G++ Lite 2009q3-67) 6.8.50.20090630-cvs Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-none-linux-gnueabi". For bug reporting instructions, please see: . code0: Mapping 0x3000 bytes (3 pages) from 0x100000 to 0xa0000000 for baremetal_noname0 (gdb) code0: Freed 44 KB init memory, of which 40 KB was used. (gdb) target remote localhost:1234 Remote debugging using localhost:1234 0xa000000c in ?? () (gdb) load final.elf Loading section .text, size 0x5158 lma 0xe00000 Load failed Any ideas? -- http://dpc.ucore.info From dpc at ucore.info Fri Feb 12 00:12:27 2010 From: dpc at ucore.info (=?UTF-8?B?RGF3aWQgQ2nEmcW8YXJraWV3aWN6?=) Date: Fri, 12 Feb 2010 01:12:27 +0100 Subject: Build environment improvement. In-Reply-To: References: <4B73D20B.7050106@l4dev.org> <4B743B71.4090903@l4dev.org> Message-ID: 2010/2/11 Dawid Ci??arkiewicz : > I'm unable to get codezero debugging working here. I got it. It was the lacking -S flag in qemu which led to the actual code to be run before gdb even connects with it. How could I not understood that before ... Also - I've managed to improve all the scripts altogether. http://github.com/dpc/codezero/commit/37a1adca2f9a63511d09856a2952ddc2e5966e23 I have now fully working testing and debugging environment. The bad news is I've managed to screw my repository a little so I've recreated it. I hope noone yet pulled from it and as I guess that's the case I've simply recreated it. So as I can now traverse through the running codezero in gdb/insight - I will dive into the actual implementation details and actually learn how it works. The last problem is to run codezero in less then ... 8MB. (described in one of previous emails). Can you advise on this one as well? Thanks! -- http://dpc.ucore.info From amit.mahajan at b-labs.co.uk Fri Feb 12 05:21:02 2010 From: amit.mahajan at b-labs.co.uk (Amit Mahajan) Date: Fri, 12 Feb 2010 10:51:02 +0530 Subject: Build environment improvement. In-Reply-To: References: <4B73D20B.7050106@l4dev.org> <4B743B71.4090903@l4dev.org> Message-ID: <1265952062.3693.8.camel@amit-laptop> On Fri, 2010-02-12 at 01:12 +0100, Dawid Ci??arkiewicz wrote: > 2010/2/11 Dawid Ci??arkiewicz : > > I'm unable to get codezero debugging working here. > > The last problem is to run codezero in less then ... 8MB. (described > in one of previous emails). Can you advise on this one as well? > Thanks! Dawid, Its quiet simple, see you are building codezero with some container (which is basically a user task). We have configured codezero physical memory regions like: 0x00 to 0x100000 --- Microkernel 0x100000 to 0xe00000 --- first container .. .. .. other containers .. Load Address of final.elf. So, in your case you are building with 1 container, so final.elf gets linked at 0xe00000 physical address. So when you run qemu, it tries to load it at this address, and your ram is 8MB, so we get an out of ram crash. PS: 1. Though we are using quiet big regions for kernel and containers, these are not fully occupied. 2. If you see the Platform's supported by codezero, you will find all these platform's have 128+ MB of memory, so why bother about 8MB? -- Thanks and Regards Amit Mahajan From dpc at ucore.info Fri Feb 12 10:08:03 2010 From: dpc at ucore.info (=?UTF-8?B?RGF3aWQgQ2nEmcW8YXJraWV3aWN6?=) Date: Fri, 12 Feb 2010 11:08:03 +0100 Subject: Build environment improvement. In-Reply-To: <1265952062.3693.8.camel@amit-laptop> References: <4B73D20B.7050106@l4dev.org> <4B743B71.4090903@l4dev.org> <1265952062.3693.8.camel@amit-laptop> Message-ID: I guess it shouldn't be hard to change this for my own use? Or is it badly hardcoded everywhere for a moment? 128MB is a lot. I was thinking about buying: http://www.propox.com/products/t_232.html (site is in Polish) 64MB SDRAM, ARM926-EJ for some fun projects of mine. One of such projects would be to put L4 on it. Looks like it should be quite easily supportable by codezero, I guess. It's perfectly capable of running Linux, so not being able to run an microkernel would be weird. :) However my current reason is just to run it codezero in a smaller VM on a remote shell server, because I can't have processes with 128MB there. Regards, Dawid 2010/2/12 Amit Mahajan : > On Fri, 2010-02-12 at 01:12 +0100, Dawid Ci??arkiewicz wrote: >> 2010/2/11 Dawid Ci??arkiewicz : >> > I'm unable to get codezero debugging working here. > >> >> The last problem is to run codezero in less then ... 8MB. (described >> in one of previous emails). Can you advise on this one as well? >> Thanks! > > Dawid, > > Its quiet simple, see you are building codezero with some container > (which is basically a user task). We have configured codezero physical > memory regions like: > > 0x00 ? ? ? ? to 0x100000 --- Microkernel > 0x100000 ? ? to 0xe00000 --- first container > .. > .. > .. ? ? ? ? ? ? ?other containers > .. > Load Address of final.elf. > > > So, in your case you are building with 1 container, so final.elf gets > linked at 0xe00000 physical address. So when you run qemu, it tries to > load it at this address, and your ram is 8MB, so we get an out of ram > crash. > > > PS: > 1. Though we are using quiet big regions for kernel and containers, > these are not fully occupied. > 2. If you see the Platform's supported by codezero, you will find all > these platform's have 128+ MB of memory, so why bother about 8MB? > > > > -- > Thanks and Regards > Amit Mahajan > > -- http://dpc.ucore.info From dpc at ucore.info Fri Feb 12 10:32:55 2010 From: dpc at ucore.info (=?UTF-8?B?RGF3aWQgQ2nEmcW8YXJraWV3aWN6?=) Date: Fri, 12 Feb 2010 11:32:55 +0100 Subject: Build environment improvement. In-Reply-To: References: <4B73D20B.7050106@l4dev.org> <4B743B71.4090903@l4dev.org> <1265952062.3693.8.camel@amit-laptop> Message-ID: I'm sorry for top posting. Job in corporation is killing my manners. -- http://dpc.ucore.info From amit.mahajan at b-labs.co.uk Fri Feb 12 10:35:06 2010 From: amit.mahajan at b-labs.co.uk (Amit Mahajan) Date: Fri, 12 Feb 2010 16:05:06 +0530 Subject: Build environment improvement. In-Reply-To: References: <4B73D20B.7050106@l4dev.org> <4B743B71.4090903@l4dev.org> <1265952062.3693.8.camel@amit-laptop> Message-ID: <1265970906.5467.10.camel@amit-laptop> On Fri, 2010-02-12 at 11:08 +0100, Dawid Ci??arkiewicz wrote: > I guess it shouldn't be hard to change this for my own use? Or is it > badly hardcoded everywhere for a moment? > Ok, you can customise this easily, when you run the configurator, just go to container setting options, and change the physical memory region used there, based on your system ram, say 1MB to 2MB for ex. Load address of final.elf will be automatically set to immediately after the last container, so you dont need to worry about this. PS: The above mentioned points will remove your issues in loader etc addresses. But if you compile for pb926 platform and try to run this code on the below mention board (having less RAM), then you may see a crash in microkernel, mainly due to the fact that kernel assumes RAM extends till 128MB for versatile 926. To solve this, just update the file: codezero/include/l4/platform/pb926/offsets.h with correct RAM SIZE, as defined by macros PLATFORM_PHYS_MEM_START PLATFORM_PHYS_MEM_END. > 128MB is a lot. I was thinking about buying: > http://www.propox.com/products/t_232.html (site is in Polish) > 64MB SDRAM, ARM926-EJ > for some fun projects of mine. One of such projects would be to put L4 > on it. Looks like it should be quite easily supportable by codezero, I > guess. It's perfectly capable of running Linux, so not being able to > run an microkernel would be weird. :) > -- Thanks and Regards Amit Mahajan From bahadir at l4dev.org Fri Feb 12 14:37:06 2010 From: bahadir at l4dev.org (Bahadir Balban) Date: Fri, 12 Feb 2010 16:37:06 +0200 Subject: Build environment improvement. In-Reply-To: References: <4B73D20B.7050106@l4dev.org> <4B743B71.4090903@l4dev.org> Message-ID: <4B756792.7070209@l4dev.org> Dawid Ci??arkiewicz wrote: > I'm unable to get codezero debugging working here. > It seems to be working just fine. > (gdb) code0: Freed 44 KB init memory, of which 40 KB was used. > This is the last message you got from codezero itself. The .gdbinit script has automatically connected to qemu, loaded your executable and ran it. > (gdb) target remote localhost:1234 > Remote debugging using localhost:1234 > 0xa000000c in ?? () At this point you are in userspace. Your empty application is busy-looping. If you add some code in your empty project and recompile (or just try hello world) then you will see a printout on qemu, if you turned the serial port on. > (gdb) load final.elf > Loading section .text, size 0x5158 lma 0xe00000 > Load failed > > Any ideas? > This fails since you already ran the image. The qemu command line must be included somewhere in the getting started manual, you needn't figure out every flag yourself. -- Bahadir From bahadir at l4dev.org Fri Feb 12 14:47:10 2010 From: bahadir at l4dev.org (Bahadir Balban) Date: Fri, 12 Feb 2010 16:47:10 +0200 Subject: Build environment improvement. In-Reply-To: References: <4B73D20B.7050106@l4dev.org> <4B743B71.4090903@l4dev.org> <1265952062.3693.8.camel@amit-laptop> Message-ID: <4B7569EE.7040305@l4dev.org> Dawid Ci??arkiewicz wrote: > I guess it shouldn't be hard to change this for my own use? Or is it > badly hardcoded everywhere for a moment? > > 128MB is a lot. I was thinking about buying: > http://www.propox.com/products/t_232.html (site is in Polish) > 64MB SDRAM, ARM926-EJ > for some fun projects of mine. One of such projects would be to put L4 > on it. Looks like it should be quite easily supportable by codezero, I > guess. It's perfectly capable of running Linux, so not being able to > run an microkernel would be weird. :) > > However my current reason is just to run it codezero in a smaller VM > on a remote shell server, because I can't have processes with 128MB > there. > > Regards, > Dawid > The reason loader is loaded at 0xe00000 at time being is to leave room for elf images that reside in lower memory. At this set up loader copies the images to lower ram without clashing. Except this detail the microkernel itself runs in Kbs of memory and the run-time consumption is based on how you determine your container resources (e.g. ram, number of threads, spaces etc.) The loader set up currently is not bothersome as most platforms have 16mb of memory or more. -- Bahadir From dpc at ucore.info Fri Feb 12 16:05:50 2010 From: dpc at ucore.info (=?UTF-8?B?RGF3aWQgQ2nEmcW8YXJraWV3aWN6?=) Date: Fri, 12 Feb 2010 17:05:50 +0100 Subject: Build environment improvement. In-Reply-To: <4B7569EE.7040305@l4dev.org> References: <4B743B71.4090903@l4dev.org> <1265952062.3693.8.camel@amit-laptop> <4B7569EE.7040305@l4dev.org> Message-ID: 2010/2/12 Bahadir Balban : > > The reason loader is loaded at 0xe00000 at time being is to leave room > for elf images that reside in lower memory. At this set up loader copies > the images to lower ram without clashing. Except this detail the > microkernel itself runs in Kbs of memory and the run-time consumption is > based on how you determine your container resources (e.g. ram, number of > threads, spaces etc.) > > The loader set up currently is not bothersome as most platforms have > 16mb of memory or more. Thanks. I was able to get everything working and I have beautiful scripts for easy creating an environment and debugging. Out of curiosity - how big is codezero kernel itself at the moment? Regards, Dawid -- http://dpc.ucore.info From dpc at ucore.info Sun Feb 21 01:24:59 2010 From: dpc at ucore.info (=?UTF-8?B?RGF3aWQgQ2nEmcW8YXJraWV3aWN6?=) Date: Sun, 21 Feb 2010 02:24:59 +0100 Subject: Codezero (L4 microkernel) developer starting guide Message-ID: Hi, With your help I was able to start playing with L4. I've written down my experiences, hoping that some people will find it useful. I'm posting a link here for your acknowledge. http://dpc.ucore.info/forum/t-221203/codezero-l4-microkernel-developer-starting-guide Regards, Dawid -- http://dpc.ucore.info From john.van.v at gmail.com Sun Feb 21 15:52:09 2010 From: john.van.v at gmail.com (John van V.) Date: Sun, 21 Feb 2010 10:52:09 -0500 Subject: Codezero (L4 microkernel) developer starting guide In-Reply-To: References: Message-ID: <5b6039b91002210752w6c3fac1bo24f730f19f1d7580@mail.gmail.com> Its really good to see this work in progress accompanied by helpful documentation. I have not officially managed OS level systems for nearly a decade (and have branched to psychology and art). But I attempt to follow the progress and keep in mind the need for user participation in the implementation of the software, and the design of the higher level components that will reside over this work. I am hoping to implement it as a local community project. John > With your help I was able to start playing with L4. I've written down > my experiences, hoping that some people will find it useful. I'm > posting a link here for your acknowledge. > > http://dpc.ucore.info/forum/t-221203/codezero-l4-microkernel-developer-starting-guide > > Regards, > Dawid > -- > http://dpc.ucore.info Empathy http://thinman.com/empathy Photography http://thinman.com/photography Technology http://thinman.com From dev at cordney.com Mon Feb 22 18:04:54 2010 From: dev at cordney.com (=?iso-8859-1?Q?Ren=E9_Korthaus?=) Date: Mon, 22 Feb 2010 19:04:54 +0100 Subject: Documentation update needed Message-ID: <76818CD9-E5BC-4BB2-A1D1-87A612A0BFF6@cordney.com> Hi folks, while reviewing Codezero during research as a student project, I found that the documentation on the website seems a bit outdated on a few pages, especially: * The directory structures listed at http://l4dev.org/application_development:codezero_project_overview#software_overview, #codezero_debugging_overview mention the "tasks" folder, which is not existent in the current build. * It appears unclear if mm0 and fs0 currently (v0.2) run in their own container. The documentation announces this feature for future versions, from the source it looks like they're already "containered". * http://l4dev.org/application_development:codezero_project_overview#codezero_debugging_overview mentions scripts "l4-qemu" (would now be "run-qemu-insight"), ./packer.sh, and ./buildall.sh. * http://l4dev.org/application_development:writing_applications seems to refer to version 0.1, specifically it states that build process currently doesn't allow adding new applications or user space servers to Codezero. Keep the good work up. Best, Ren? ------------------------------- Ren? Korthaus B.Sc. IT-Security Ruhr University Bochum, Germany -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3372 bytes Desc: not available Url : http://lists.l4dev.org/pipermail/codezero-devel/attachments/20100222/71edce59/attachment.bin From bahadir at l4dev.org Mon Feb 22 20:28:26 2010 From: bahadir at l4dev.org (Bahadir Balban) Date: Mon, 22 Feb 2010 22:28:26 +0200 Subject: Documentation update needed In-Reply-To: <76818CD9-E5BC-4BB2-A1D1-87A612A0BFF6@cordney.com> References: <76818CD9-E5BC-4BB2-A1D1-87A612A0BFF6@cordney.com> Message-ID: <4B82E8EA.7010409@l4dev.org> Ren? Korthaus wrote: > Hi folks, > > while reviewing Codezero during research as a student project, I found that the documentation on the website seems a bit outdated on a few pages, especially: > > * The directory structures listed at http://l4dev.org/application_development:codezero_project_overview#software_overview, #codezero_debugging_overview mention the "tasks" folder, which is not existent in the current build. > * It appears unclear if mm0 and fs0 currently (v0.2) run in their own container. The documentation announces this feature for future versions, from the source it looks like they're already "containered". > * http://l4dev.org/application_development:codezero_project_overview#codezero_debugging_overview mentions scripts "l4-qemu" (would now be "run-qemu-insight"), ./packer.sh, and ./buildall.sh. > * http://l4dev.org/application_development:writing_applications seems to refer to version 0.1, specifically it states that build process currently doesn't allow adding new applications or user space servers to Codezero. > > Keep the good work up. > Best, Ren? > Hi Ren?, You are correct - those pages are outdated at the moment. I will update all at a convenient time. Everything now builds under build/, except individual baremetal projects that get their own project directories created under conts/ mm0 and fs0 are now merged into mm0, and same sources can be used to build multiple containers. You can select this behaviour by running ./configure.py and selecting containers -> container setup -> container parameters. The easiest way to get started is to choose an empty container and (say with default name empty0) start writing code under conts/empty0/main.c For api calls it is best to follow the man pages: man -M docs/man l4_thread_control and so on. Thanks, -- Bahadir From dev at cordney.com Mon Feb 22 20:40:50 2010 From: dev at cordney.com (=?iso-8859-1?Q?Ren=E9_Korthaus?=) Date: Mon, 22 Feb 2010 21:40:50 +0100 Subject: Documentation update needed In-Reply-To: <4B82E8EA.7010409@l4dev.org> References: <76818CD9-E5BC-4BB2-A1D1-87A612A0BFF6@cordney.com> <4B82E8EA.7010409@l4dev.org> Message-ID: <63041C03-33B9-41A4-811A-9BC117A5E74C@cordney.com> Hi Bahadir, thanks, I already figured out the things mentioned using the sources and built a new project successfully. Just thought of other people that may get confused in the future. Its not a major problem IMHO, as the whole documentation is really good and complete. Best, Ren? Am 22.02.2010 um 21:28 schrieb Bahadir Balban: > Ren? Korthaus wrote: >> Hi folks, >> >> while reviewing Codezero during research as a student project, I found that the documentation on the website seems a bit outdated on a few pages, especially: >> >> * The directory structures listed at http://l4dev.org/application_development:codezero_project_overview#software_overview, #codezero_debugging_overview mention the "tasks" folder, which is not existent in the current build. >> * It appears unclear if mm0 and fs0 currently (v0.2) run in their own container. The documentation announces this feature for future versions, from the source it looks like they're already "containered". >> * http://l4dev.org/application_development:codezero_project_overview#codezero_debugging_overview mentions scripts "l4-qemu" (would now be "run-qemu-insight"), ./packer.sh, and ./buildall.sh. >> * http://l4dev.org/application_development:writing_applications seems to refer to version 0.1, specifically it states that build process currently doesn't allow adding new applications or user space servers to Codezero. >> >> Keep the good work up. >> Best, Ren? >> > > Hi Ren?, > > You are correct - those pages are outdated at the moment. I will update > all at a convenient time. Everything now builds under build/, except > individual baremetal projects that get their own project directories > created under conts/ > > mm0 and fs0 are now merged into mm0, and same sources can be used to > build multiple containers. You can select this behaviour by running > ./configure.py and selecting containers -> container setup -> container > parameters. > > The easiest way to get started is to choose an empty container and (say > with default name empty0) start writing code under conts/empty0/main.c > > For api calls it is best to follow the man pages: > > man -M docs/man l4_thread_control and so on. > > Thanks, > > -- > Bahadir -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3372 bytes Desc: not available Url : http://lists.l4dev.org/pipermail/codezero-devel/attachments/20100222/da4bd95c/attachment.bin From bahadir at l4dev.org Tue Feb 23 07:59:21 2010 From: bahadir at l4dev.org (Bahadir Balban) Date: Tue, 23 Feb 2010 09:59:21 +0200 Subject: Documentation update needed In-Reply-To: <63041C03-33B9-41A4-811A-9BC117A5E74C@cordney.com> References: <76818CD9-E5BC-4BB2-A1D1-87A612A0BFF6@cordney.com> <4B82E8EA.7010409@l4dev.org> <63041C03-33B9-41A4-811A-9BC117A5E74C@cordney.com> Message-ID: <4B838AD9.8020200@l4dev.org> Ren? Korthaus wrote: > Hi Bahadir, > > thanks, I already figured out the things mentioned using the sources and built a new project successfully. Just thought of other people that may get confused in the future. Its not a major problem IMHO, as the whole documentation is really good and complete. > > Best, Ren? > On second thought, if you wish you may update some of the pages yourself. It is a community site after all. The requirements are obvious ones - they should be written in good english using proper wording. Thanks, -- Bahadir From john.van.v at gmail.com Tue Feb 23 14:27:48 2010 From: john.van.v at gmail.com (John van V.) Date: Tue, 23 Feb 2010 09:27:48 -0500 Subject: Documentation update needed In-Reply-To: <4B838AD9.8020200@l4dev.org> References: <76818CD9-E5BC-4BB2-A1D1-87A612A0BFF6@cordney.com> <4B82E8EA.7010409@l4dev.org> <63041C03-33B9-41A4-811A-9BC117A5E74C@cordney.com> <4B838AD9.8020200@l4dev.org> Message-ID: <5b6039b91002230627w577f234eqd6890681b7650b3f@mail.gmail.com> My writing has improved greatly since my OS management days. Despite being a native New Yorker, my English was like a second language until I finished my degree which was independent and writing-based. I can work on that aspect for you if English is not your main priority, and possibly transplant the writing into a centralized location such as the Wikiversity to prepare it for the upstream journey to the Wikipedia. John === Bahadir wrote: On second thought, if you wish you may update some of the pages yourself. It is a community site after all. The requirements are obvious ones - they should be written in good english using proper wording. From norman.feske at genode-labs.com Wed Feb 24 10:35:49 2010 From: norman.feske at genode-labs.com (Norman Feske) Date: Wed, 24 Feb 2010 11:35:49 +0100 Subject: Announcement: Genode framework available on Codezero Message-ID: <4B850105.5060705@genode-labs.com> Dear Codezero community, The Genode project has released the new version 10.02 of the Genode OS Framework with added support for the Codezero microkernel. The framework is a modular user-level infrastructure comprising device drivers, a GUI, networking support, and ports of popular open-source libraries. It can be executed directly on different microkernels including the whole family of L4 kernels. Starting with the current release, the framework can be used on Codezero, executed within a Codezero container. The initial support is mainly geared towards the Codezero developers to stress the kernel and evaluate new kernel interfaces. However, we intend to further advance the framework to make it a first-grade citizen on Codezero and the user-land of choice for implementing dynamic workloads on this platform. In addition to the new support for Codezero, Genode 10.02 introduces support for the NOVA hypervisor and contains a variety of platform- related improvements, for example a new concept for managing real- time priorities. Functionality-wise, the most significant addition is the initial port of the Python 2.6.4 script interpreter (not yet usable on Codezero). Release-notes summary for version 10.02 --------------------------------------- * Platform support * NOVA hypervisor * Codezero kernel * New thread-context management * Real-time priorities * Python scripting You can find the complete release notes for the version 10.02 here: http://genode.org/documentation/release-notes/10.02/ The new release is available via the project's subversion repository and at the Genode download page: http://genode.org/download/latest-release Regards -- Norman Feske Genode Labs http://www.genode-labs.com ? http://genode.org From bahadir at l4dev.org Thu Feb 25 09:57:39 2010 From: bahadir at l4dev.org (Bahadir Balban) Date: Thu, 25 Feb 2010 11:57:39 +0200 Subject: Announcement: Genode framework available on Codezero In-Reply-To: <4B850105.5060705@genode-labs.com> References: <4B850105.5060705@genode-labs.com> Message-ID: <4B864993.5020106@l4dev.org> Hi Norman, This is great news. I also very much enjoyed reading the release notes. A lot of technical details are covered on how the Genode port works on various kernels. Keep up the good work! -- Bahadir Norman Feske wrote: > Dear Codezero community, > > The Genode project has released the new version 10.02 of the Genode > OS Framework with added support for the Codezero microkernel. The > framework is a modular user-level infrastructure comprising device > drivers, a GUI, networking support, and ports of popular open-source > libraries. It can be executed directly on different microkernels > including the whole family of L4 kernels. Starting with the current > release, the framework can be used on Codezero, executed within a > Codezero container. The initial support is mainly geared towards > the Codezero developers to stress the kernel and evaluate new kernel > interfaces. However, we intend to further advance the framework to > make it a first-grade citizen on Codezero and the user-land of > choice for implementing dynamic workloads on this platform. > > In addition to the new support for Codezero, Genode 10.02 introduces > support for the NOVA hypervisor and contains a variety of platform- > related improvements, for example a new concept for managing real- > time priorities. Functionality-wise, the most significant addition > is the initial port of the Python 2.6.4 script interpreter (not yet > usable on Codezero). > > Release-notes summary for version 10.02 > --------------------------------------- > * Platform support > * NOVA hypervisor > * Codezero kernel > * New thread-context management > * Real-time priorities > * Python scripting > > You can find the complete release notes for the version 10.02 here: > > http://genode.org/documentation/release-notes/10.02/ > > The new release is available via the project's subversion repository > and at the Genode download page: > > http://genode.org/download/latest-release > > Regards From john.van.v at gmail.com Thu Feb 25 15:37:37 2010 From: john.van.v at gmail.com (John van V.) Date: Thu, 25 Feb 2010 10:37:37 -0500 Subject: Announcement: Genode framework available on Codezero In-Reply-To: <4B864993.5020106@l4dev.org> References: <4B850105.5060705@genode-labs.com> <4B864993.5020106@l4dev.org> Message-ID: <5b6039b91002250737w5908309eo368a406840c1ff67@mail.gmail.com> What is it useful for? I looked over the documents as well, and I understand how it works. I see that it "attempts to tame the OS," but what is it good for? From norman.feske at genode-labs.com Fri Feb 26 11:07:42 2010 From: norman.feske at genode-labs.com (Norman Feske) Date: Fri, 26 Feb 2010 12:07:42 +0100 Subject: Announcement: Genode framework available on Codezero In-Reply-To: <5b6039b91002250737w5908309eo368a406840c1ff67@mail.gmail.com> References: <4B850105.5060705@genode-labs.com> <4B864993.5020106@l4dev.org> <5b6039b91002250737w5908309eo368a406840c1ff67@mail.gmail.com> Message-ID: <4B87AB7E.6050303@genode-labs.com> Hi John, John van V. wrote: > What is it useful for? > > I looked over the documents as well, and I understand how it works. I > see that it "attempts to tame the OS," but what is it good for? admittedly, I am in doubt about the point of your question. So I will give you three possible answers and hope that one of them matches your intent. Question: What is the purpose of Genode in general? Genode provides a unified API for creating dynamic applications running on microkernels, comparible to how POSIX provides a unified API for developing applications on UNIX-like operating systems. Because POSIX is not compatible with microkernel design principles, a differnt API is needed. Prior Genode, there was no such API that supported more than one microkernel. Each microkernel OS project had their own user land, tied to the respective kernel and covered only a limited set of use cases. With Genode, we want to bring dynamic general-purpose workload to the world of microkernels. Question: What functionality do I gain from Genode compared to established operating systems such as Linux? At the moment, not much. But for application areas where microkernels are desired, Genode brings along functionality that is hard to get elsewhere, for example a way to execute Linux device drivers and the Qt4 framework directly on the microkernel, and powerful concepts to organize dynamic processes and physical resource on top of a microkernel. Question: Which value brings Genode to the Codezero community? Quote from the release notes: "At the current stage, the Genode version for Codezero is primarily geared towards the developers of Codezero as a workload to stress their kernel." So many Genode features (such as Qt4) are not functional on Codezero, yet. But if you like, you can help to change that. ;-) Regards Norman -- Norman Feske Genode Labs http://www.genode-labs.com ? http://genode.org From john.van.v at gmail.com Fri Feb 26 14:53:06 2010 From: john.van.v at gmail.com (John van V.) Date: Fri, 26 Feb 2010 09:53:06 -0500 Subject: Announcement: Genode framework available on Codezero In-Reply-To: <4B87AB7E.6050303@genode-labs.com> References: <4B850105.5060705@genode-labs.com> <4B864993.5020106@l4dev.org> <5b6039b91002250737w5908309eo368a406840c1ff67@mail.gmail.com> <4B87AB7E.6050303@genode-labs.com> Message-ID: <5b6039b91002260653l7025f41bm61ff9188befc5f1a@mail.gmail.com> Norman wrote: "admittedly, I am in doubt about the point of your question" No worries, you got it! * Bahadir included in the codezero design criteria an Xwindows-derived graphical interface * I don't really see a viable open system w/o a shell How can Gnode help create a path to these? -- Empathy http://thinman.com/empathy Photography http://thinman.com/photography Technology http://thinman.com From norman.feske at genode-labs.com Sat Feb 27 15:20:57 2010 From: norman.feske at genode-labs.com (Norman Feske) Date: Sat, 27 Feb 2010 16:20:57 +0100 Subject: Announcement: Genode framework available on Codezero In-Reply-To: <5b6039b91002260653l7025f41bm61ff9188befc5f1a@mail.gmail.com> References: <4B850105.5060705@genode-labs.com> <4B864993.5020106@l4dev.org> <5b6039b91002250737w5908309eo368a406840c1ff67@mail.gmail.com> <4B87AB7E.6050303@genode-labs.com> <5b6039b91002260653l7025f41bm61ff9188befc5f1a@mail.gmail.com> Message-ID: <4B893859.5090206@genode-labs.com> Hi John, John van V. wrote: > * Bahadir included in the codezero design criteria an Xwindows-derived > graphical interface > * I don't really see a viable open system w/o a shell > > How can Gnode help create a path to these? the best way to find out is downloading the source code and start experimenting. Many building blocks needed for such setups are already in place: windowed GUI, USB-HID support, PS/2 driver, USB storage, C library, networking, process-management facilities etc. But there are also several pieces missing, in particular a terminal emulator and a shell. Regards Norman