prex-devel Mailing List for Prex Embedded Real-time OS
Status: Beta
Brought to you by:
kohtani
You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
(9) |
Apr
(4) |
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
(17) |
Oct
(4) |
Nov
(1) |
Dec
(22) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(15) |
Feb
(4) |
Mar
(10) |
Apr
|
May
|
Jun
|
Jul
(90) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
(4) |
Feb
(2) |
Mar
|
Apr
(25) |
May
(12) |
Jun
(33) |
Jul
|
Aug
(2) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
(11) |
2008 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(6) |
Sep
(1) |
Oct
(2) |
Nov
(5) |
Dec
|
2009 |
Jan
|
Feb
(1) |
Mar
|
Apr
(6) |
May
(1) |
Jun
(23) |
Jul
(52) |
Aug
(26) |
Sep
(12) |
Oct
(19) |
Nov
(5) |
Dec
(4) |
2010 |
Jan
(13) |
Feb
(6) |
Mar
(1) |
Apr
(2) |
May
(5) |
Jun
(29) |
Jul
(2) |
Aug
|
Sep
(3) |
Oct
(1) |
Nov
(1) |
Dec
|
2011 |
Jan
(1) |
Feb
(5) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
2013 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Andrew D. <and...@gm...> - 2020-07-12 02:45:18
|
I'm not sure if anyone is still subscribed, but a few of us are still working with a fork of prex, but it has evolved a long way from the original. In the spirit of open source it is now available under a new name: Apex RTOS. See here: http://apexrtos.com We (well mostly Patrick) are actively developing for the NXP i.MX RT platform but it remains small and portable and is getting even more posix compliant. If you are still listening here then you may be interested - it has moved forward a long way... Andrew ps: we use this in a real product |
From: Richard P. <ri...@pe...> - 2015-01-03 17:51:26
|
On 01/03/2015 11:12 AM, Eli Hini wrote: > Hello Richard, > > It is good to hear that someone is still interested in Prex. I'm also wanting to use Prex for embedded projects using a micro kernel architecture similar to Minix. I will take a look at ELCC. I am still working on the layers above and considering if I can use LLVM to provide a base for a language like Erlang/Elixir that will run on atop a bare metal type of kernel as you described, possibly Prex or a heavily modified Minix kernel (if it comes to it). > > Keep on exploring and let's keep the channel open for mor dialogues. > > Eli > Hi Eli, I agree, let's keep the channel open. I'm sorry to say that although I use a lot of Prex code, my ELK is not a micro kernel. -Rich |
From: Eli H. <eh...@ve...> - 2015-01-03 17:50:44
|
Hello Richard, It is good to hear that someone is still interested in Prex. I'm also wanting to use Prex for embedded projects using a micro kernel architecture similar to Minix. I will take a look at ELCC. I am still working on the layers above and considering if I can use LLVM to provide a base for a language like Erlang/Elixir that will run on atop a bare metal type of kernel as you described, possibly Prex or a heavily modified Minix kernel (if it comes to it). Keep on exploring and let's keep the channel open for mor dialogues. Eli > On Jan 3, 2015, at 02:51, Richard Pennington <ri...@pe...> wrote: > > Hi, > > I know this list was been quiet for some time, but I thought that there > might still be some interest is some Prex related work that I've been doing. > I have been developing a cross compilation tool chain based on > clang/LLVM for ARM, Mips, PowerPC, and x86 processors. I call the > project ELLCC (pronounced "elk") http://ellcc.org > The project currently fully supports C and C++ compilation for all the > target processors running Linux. I also want to support bare metal > development on all the targets, so I started a sub-project called ELK > ("Embedded Little Kernel") for that purpose. The goal of ELK is to use > the same C/C++ run-time libraries (using the BSD or BSD-like licensed > libc++, musl, and compiler-rt) for both the Linux and ELK environments > and it has been coming along very well. > About a month and a half ago I decided I wanted to add file system > support to ELK and after some googling I stumbled across Prex. I was > very impressed by the design and clarity of the code, so I decided to > borrow some of it for my ELK project. I won't go into too much detail > here, but here's what I've done so far: > * Incorporated the Prex file system, console/tty and VM code (both MMU > and non-MMU). > * Cleaned up a few minor design issues (e.g. vnode locks can be read > only or R/W, no schedule_lock(), finer grained locking) > This week I added networking support by incorporating the LwIP TCP/IP > stack. (It currently can only communicate on 127.0.0.1 because I haven't > added Ethernet drivers yet.) > > The current incarnation of ELK only runs on ARM. I'd like to add the > glue for the other targets soon as time allows. > > Just thought you'd like to know that Prex lives on. > > -Rich > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > _______________________________________________ > Prex-devel mailing list > Pre...@li... > https://lists.sourceforge.net/lists/listinfo/prex-devel |
From: Richard P. <ri...@pe...> - 2015-01-03 11:05:28
|
Hi, I know this list was been quiet for some time, but I thought that there might still be some interest is some Prex related work that I've been doing. I have been developing a cross compilation tool chain based on clang/LLVM for ARM, Mips, PowerPC, and x86 processors. I call the project ELLCC (pronounced "elk") http://ellcc.org The project currently fully supports C and C++ compilation for all the target processors running Linux. I also want to support bare metal development on all the targets, so I started a sub-project called ELK ("Embedded Little Kernel") for that purpose. The goal of ELK is to use the same C/C++ run-time libraries (using the BSD or BSD-like licensed libc++, musl, and compiler-rt) for both the Linux and ELK environments and it has been coming along very well. About a month and a half ago I decided I wanted to add file system support to ELK and after some googling I stumbled across Prex. I was very impressed by the design and clarity of the code, so I decided to borrow some of it for my ELK project. I won't go into too much detail here, but here's what I've done so far: * Incorporated the Prex file system, console/tty and VM code (both MMU and non-MMU). * Cleaned up a few minor design issues (e.g. vnode locks can be read only or R/W, no schedule_lock(), finer grained locking) This week I added networking support by incorporating the LwIP TCP/IP stack. (It currently can only communicate on 127.0.0.1 because I haven't added Ethernet drivers yet.) The current incarnation of ELK only runs on ARM. I'd like to add the glue for the other targets soon as time allows. Just thought you'd like to know that Prex lives on. -Rich |
From: Paul D. <duf...@gm...> - 2014-03-19 04:13:26
|
unchanged version 0.9.0 was compiling fine on gcc 4.8.2. But when I was $mcopy prex-0.9.0/prexos a:\prexos (choosing overwrite) with /etc/mtools.conf having drive a: file="/home/paul/prex-0.8.0,i386-pc.img" then $qemu-kvm -fda ./prex-0.8.0.i386-pc.img -localtime messages was going very fast, but was having time to read Booting Prexos, then blackscreen. So I did manually apply: http://www.eighty-twenty.org/index.cgi/tech/prex-bug-20110317.html did not use -p option of patch... had to manually apply (not used to apply patches). But it did not help. Then I tried to recompile 0.8.1 but had problem: first configure had not --target=pc-x86 was not working so I only ./configure, but then make: .../boot/common/debug.c:50: undefined reference to '__builtin_stdarg_start' So I begin trying older gcc (4.2.4) but no better results. So I then compiled back 0.9.0 (make clean; make) And this time after the mcopy command, qemu worked! And this must be really 0.9.0 because I now can play tetris, and was not having tetris in 0.8.0. So it appears that 0.9.0 build fine with gcc 4.8.2 but then does not boot. Builds fine, and boots with gcc 4.2.4. Did not (yet) tested gcc versions between 4.2.4 and 4.8.2. |
From: Tony Garnock-J. <to...@cc...> - 2013-05-22 17:33:43
|
On 05/22/2013 01:24 PM, David Given wrote: > While I'm aware that the Sourceforge site isn't receiving updates any > more, has anyone been doing any work on Prex and happen to have a DVCS > site with updates in it? https://github.com/tonyg/prex has a bug fix for exception handling (see http://www.eighty-twenty.org/index.cgi/tech/prex-bug-20110317.html) on its "master" branch, and a PIO IDE hard disk driver and PCI bus scan on its "hdd" branch. Both came about from class project work. I'm not working on Prex anymore. Cheers, Tony |
From: David G. <dg...@co...> - 2013-05-22 17:24:21
|
I have a hardware project for which I need a simple operating system that works without an MMU, and Prex would seem to be a decent candidate. While I'm aware that the Sourceforge site isn't receiving updates any more, has anyone been doing any work on Prex and happen to have a DVCS site with updates in it? -- ┌─── dg@cowlark.com ───── http://www.cowlark.com ───── │ │ 𝕻𝖍'𝖓𝖌𝖑𝖚𝖎 𝖒𝖌𝖑𝖜'𝖓𝖆𝖋𝖍 𝕮𝖙𝖍𝖚𝖑𝖍𝖚 𝕽'𝖑𝖞𝖊𝖍 𝖜𝖌𝖆𝖍'𝖓𝖆𝖌𝖑 𝖋𝖍𝖙𝖆𝖌𝖓. │ |
From: <to...@on...> - 2013-03-15 08:03:19
|
Gustavo Luiz Pasqualini писал 15-03-2013 04:44: > Hello, > > I am a student of Masters in Mechatronics by IFSC (Federal Institute > of Science and Technology). I don't thinks its any chance you have an answer about prex. As you can see last update was in 2010. Main author left development long time ago. There was some attempts to continue development, but AFAIK they have no luck. -- toc...@to... |
From: Gustavo L. P. <pas...@gm...> - 2013-03-15 00:44:42
|
Hello, I am a student of Masters in Mechatronics by IFSC (Federal Institute of Science and Technology). My research includes testing different RTOS (hard and soft) in order to determine which best responds to certain events of mechatronic systems and give a comparative result of these activities and performance time control and supervision. The ideia is to load in the same hardware these compatibles RTOS. The plataform is the Kit Luminary lm3s8962(Stellaris Arm Cortex - Texas) and after make the tests. My doubt is whether the license of the RTOS that you develop, and allows comparative study such as this survey will become part of the library and maybe future projects with public access. Do you have any material / documentation / articles / monographies about this RTOS for i attach in my work? Best Regards, Gustavo |
From: alireza g. <rav...@gm...> - 2011-11-22 04:10:45
|
http://dnfhw.com/dF8SbpvO3qHUTsB/templets/hbbbs.htm |
From: Andrew D. <and...@gm...> - 2011-07-16 22:33:43
|
On 11 February 2011 14:46, Peter Desnoyers <pj...@cc...> wrote: > I'm using Prex in an operating systems class this term, and was > wondering if anyone else had tried this. Hi Peter, Was using Prex in your class successful? Which areas of Prex did your students work on? Andrew |
From: Tony Garnock-J. <to...@cc...> - 2011-05-30 11:39:10
|
Hi all, Prex on x86 has a bug in its exception handler. I've tried a couple of times to post this to the list, but each time it has been held back, so this time I'll try linking to a blog post I wrote about it instead: http://www.eighty-twenty.org/index.cgi/tech/prex-bug-20110317.html Regards, Tony |
From: Elinam H. <eh...@ve...> - 2011-05-28 21:06:29
|
Hey Guys, What is the status of Prex, is it stable? I would like to use Prex to develop access points for a wireless sensor node project. I am targeting technologic's TS-7552 and TS 7300 single board computers. The are ARM based. Thanks, Eli |
From: Andrew D. <and...@gm...> - 2011-02-12 20:11:53
|
On 13 February 2011 03:38, Peter Desnoyers <pj...@cc...> wrote: > On 2/11/2011 11:45 PM, Andrew Dennison wrote: > >> Normally you would maintain a debug context for each process, and swap >> the debug context as part of the task switch - the OS needs to >> cooperate in this exercise. I've done this for some simple debug >> support using the hardware debug support in our target processor: I'll >> setup a gdb stub one day. > > What I'm not sure about is how to get gdb to take advantage of that, > especially e.g. via the QEMU debug stub. There is one way to you can work around this - link the task(s) you want to debug at a different virtual address. This way you can use QEMU debug without modification: as long as the virtual address spaces do not overlap. Of course this means an alternate link script for each task you want to debug, but that is fairly simple to do with some make file tweaking. > On the other hand, I can easily > see how to create a couple of debug operations to allow one thread to > get/set another's registers, and to single-step a thread; given this it > should be straightforward to add a thread to a process which implements > the gdb remote protocol. You could manipulate another threads context by hacking its stack, but a more generic solution might be to add a GDB stub to the kernel as you have access to the appropriate data structures from there. An earlier version of Prex (0.4.2?) had a gdb stub for i386 in the kernel but it was only really for kernel debug, it didn't hook in the context switch. Andrew |
From: Peter D. <pj...@cc...> - 2011-02-12 16:38:23
|
On 2/11/2011 11:45 PM, Andrew Dennison wrote: > Normally you would maintain a debug context for each process, and swap > the debug context as part of the task switch - the OS needs to > cooperate in this exercise. I've done this for some simple debug > support using the hardware debug support in our target processor: I'll > setup a gdb stub one day. What I'm not sure about is how to get gdb to take advantage of that, especially e.g. via the QEMU debug stub. On the other hand, I can easily see how to create a couple of debug operations to allow one thread to get/set another's registers, and to single-step a thread; given this it should be straightforward to add a thread to a process which implements the gdb remote protocol. > I haven't played with qemu debug - I've only used qemu for some basic > sanity checking that I haven't broken the architectures I don't have > hardware for. It's more useful if you're working with the PC platform. All the devices are supported out of the box, plus there's no such thing as a JTAG port on a PC :-) -- ..................................................................... Peter Desnoyers pj...@cc... Northeastern Computer & Information Science |
From: Andrew D. <and...@gm...> - 2011-02-12 04:45:23
|
Replying to the list too... On 12 February 2011 14:48, Peter Desnoyers <pj...@cc...> wrote: > On 02/11/2011 07:27 PM, Andrew Dennison wrote: >> On 11 February 2011 14:46, Peter Desnoyers <pj...@cc...> wrote: >>> I'm using Prex in an operating systems class this term, and was >>> wondering if anyone else had tried this. >>> >>> I was also wondering whether the project has gone dead, as there are >>> very few messages on this list since last July. >> >> This sounds like a very good use of Prex, as it has a fairly clean >> structure and good abstraction of the architecture specific >> components. > > Yes, as a matter of fact my class just came up with a very good list of > possible projects this morning. > > By the way, do you know if anyone has a good solution to debugging > user-space code on MMU systems? It should be straightforward on NOMMU, > but gdb e.g. through the QEMU stub is justifiably confused by the re-use > of the same address space in every task. If there isn't anything, we > have some ideas for a gdb stub that could be linked with an executable, > and a couple of extensions to sys_debug. Normally you would maintain a debug context for each process, and swap the debug context as part of the task switch - the OS needs to cooperate in this exercise. I've done this for some simple debug support using the hardware debug support in our target processor: I'll setup a gdb stub one day. I haven't played with qemu debug - I've only used qemu for some basic sanity checking that I haven't broken the architectures I don't have hardware for. > >> >> We haven't heard from Kohsuke for a while but I'm sure he is working >> away adding some interesting features. > > At this point I've already committed to Prex for this term, but the > development model is making me nervous. In particular, I'm worried that > any effort I put in will be wasted, or else I'll be stuck using an old > version just like you are. That is currently one of the challenges - I think it has scared off a few other users. I started maintaining a public git tree based on 0.8.1 to fill this void, but the large changes in the 0.9 tarball stalled that effort. Kohsuke mentioned setting up a public repository a few years ago and it would be fantastic if he took that step. There are a few of us who would like to contribute to Prex on a regular basis. Andrew |
From: Andrew D. <and...@gm...> - 2011-02-12 00:29:57
|
On 11 February 2011 14:46, Peter Desnoyers <pj...@cc...> wrote: > I'm using Prex in an operating systems class this term, and was > wondering if anyone else had tried this. > > I was also wondering whether the project has gone dead, as there are > very few messages on this list since last July. This sounds like a very good use of Prex, as it has a fairly clean structure and good abstraction of the architecture specific components. The Prex mailing list has always been quiet, but there seem to be a few of us lurking and ready to join in whenever some discussion starts. For the most part we're been just _using_ Prex for the last 6 months or so, it is now nice and stable so our efforts have all been focused on our product rather than more enhancements to Prex. Unfortunately I can't comment on Prex 0.9, as I haven't yet found the time to merge our changes with the latest release. We haven't heard from Kohsuke for a while but I'm sure he is working away adding some interesting features. Andrew |
From: Peter D. <pj...@cc...> - 2011-02-11 03:47:13
|
I'm using Prex in an operating systems class this term, and was wondering if anyone else had tried this. I was also wondering whether the project has gone dead, as there are very few messages on this list since last July. -- ..................................................................... Peter Desnoyers pj...@cc... Northeastern Computer & Information Science |
From: bifferos <bif...@ya...> - 2011-01-10 11:17:35
|
Hi all, I just thought I'd mention I have ne2000 support added to my own small IP stack in another project and thought it might be useful for Prex. I remember some time in a post long ago someone mentioning they'd be prepared to port an IP stack to Prex so long as someone else wrote a driver. I started looking at which was the simplest driver in Linux (ne2k), then removed all the parts that aren't needed for the Qemu emulated version by inspecting the Qemu sources, also removed interrupt support so you have to poll it. All I've tested is that I can use the driver to do DHCP query and get an IP address back from Qemu, there could be plenty of bugs, but it's certainly helping me with my work, so thought I'd share it here. The driver is C++ but in a C style, see attachment at the bottom of the page: http://sites.google.com/site/bifferboard/Home/rtos/grub-configuration-on-floppy-disk Hopefully it's a trivial job to convert to C. best regards, Biff. PS: Consider the code to be in the public domain! |
From: Dave S. <dav...@gm...> - 2010-11-10 22:57:19
|
hello: I have good news for you. Last week I have Order china 16 Products Apple iPhone 4 HD 16GB Black I completed bank transfer payments,I have received the product! w e b: tooaomo.com It's amazing! The item is original, brand new and has high quality, but it's muc cheaper. I'm pleased to share this good news with you! I believe you will find what you want there and have an good experience on shopping from them Regards! vcvcv cv 蚀 |
From: Richard P. <rpa...@ca...> - 2010-10-01 21:44:30
|
Hello all, The diff file I posted yesterday does actually work on BeagleBoard RevB but not on BeagleBoard RevC. I have posted a new diff (available at the same pastebin URL ==>http://pastebin.com/JV2Mipbq) which fixes the issue and now works on both RevB and RevC boards. Thanks a lot to Yocto for his precious help tracking down the issue. Basically, it failed on BeagleBoard RevC because this board has a 2nd memory bank which start address spans over memory bank 1 start address+4 MB and Prex ARM core cannot cope with this. Drop me a line if you want more details. Please continue sharing your experiments with this new BeagleBoard port. Cheers, RICHARD ----- Message d'origine ----- De : Yocto Envoyés : 01.10.10 01:03 À : rpa...@ca..., pre...@li... Objet : Re: [Prex-devel] BeaglePort with MMU and CACHE Hi> Please share your experiments with this patch!In order to build on CYGWIN, you need the following changesto LIBGCC_PATH and PLATFORM_LIBS in mk/gcc.mk: LIBGCC_PATH := $(shell $(CC) $(CFLAGS) -print-file-name=) PLATFORM_LIBS+= -L"$(LIBGCC_PATH)" -lgccWith these, your patch build Prex 0.9.0 and generate a 249670 bytes prexos.$ openssl dgst -md5 prexosMD5(prexos)= 2af3784c6d3bca3989d9be37d2d428c7But it hang after starting. [ CodeSourcery G++ lite 2007q3-53 ]ps: I miss stuff like "--build=builddir/beagle" from Prex 0.8 that kept the dir clean... Do you have any news for the release of Prex 1.0 ?Thanks// Yocto----- Original Message ----- From: <rpa...@ca...>To: <pre...@li...>Sent: Thursday, September 30, 2010 3:19 PMSubject: [Prex-devel] BeaglePort with MMU and CACHE> Hello all,>> I have finally updated my port of Prex 0.9.0 for the BeagleBoard to > support the MMU and the CACHE (L1 cache only for the moment).>> As the diff file is more than 2,000 lines long, I make it available via > PasteBin at the following URL: http://pastebin.com/JV2Mipbq>> This patch also provides support for R_ARM_V4BX relocations (thank you > Andrew - this makes it possible to use latest CodeSoursourcey G++ > toolchain 2010q1 to compile for the BeagleBoard) and includes a few bug > fixes (including a nasty one in usr/sbin/init/init.c which only showed up > when DEBUG was turned off!).>> As a reminder, to load this patch on the BeagleBoard, put the prexos > compiled image on a FAT formatted SD CARD and issue the following commands > in u-boot:> mmc init> fatload mmc 0 0x80300000 prexos> go 0x80300000>> Please share your experiments with this patch!>> Cheers,>> RICHARD>> ------------------------------------------------------------------------------> Start uncovering the many advantages of virtual appliances> and start using them to simplify application deployment and> accelerate your shift to cloud computing.> http://p.sf.net/sfu/novell-sfdev2dev> _______________________________________________> Prex-devel mailing list> Pre...@li...> https://lists.sourceforge.net/lists/listinfo/prex-devel> |
From: Yocto <yoc...@gm...> - 2010-09-30 23:04:16
|
Hi > Please share your experiments with this patch! In order to build on CYGWIN, you need the following changes to LIBGCC_PATH and PLATFORM_LIBS in mk/gcc.mk: LIBGCC_PATH := $(shell $(CC) $(CFLAGS) -print-file-name=) PLATFORM_LIBS+= -L"$(LIBGCC_PATH)" -lgcc With these, your patch build Prex 0.9.0 and generate a 249670 bytes prexos. $ openssl dgst -md5 prexos MD5(prexos)= 2af3784c6d3bca3989d9be37d2d428c7 But it hang after starting. [ CodeSourcery G++ lite 2007q3-53 ] ps: I miss stuff like "--build=builddir/beagle" from Prex 0.8 that kept the dir clean... Do you have any news for the release of Prex 1.0 ? Thanks // Yocto ----- Original Message ----- From: <rpa...@ca...> To: <pre...@li...> Sent: Thursday, September 30, 2010 3:19 PM Subject: [Prex-devel] BeaglePort with MMU and CACHE > Hello all, > > I have finally updated my port of Prex 0.9.0 for the BeagleBoard to > support the MMU and the CACHE (L1 cache only for the moment). > > As the diff file is more than 2,000 lines long, I make it available via > PasteBin at the following URL: http://pastebin.com/JV2Mipbq > > This patch also provides support for R_ARM_V4BX relocations (thank you > Andrew - this makes it possible to use latest CodeSoursourcey G++ > toolchain 2010q1 to compile for the BeagleBoard) and includes a few bug > fixes (including a nasty one in usr/sbin/init/init.c which only showed up > when DEBUG was turned off!). > > As a reminder, to load this patch on the BeagleBoard, put the prexos > compiled image on a FAT formatted SD CARD and issue the following commands > in u-boot: > mmc init > fatload mmc 0 0x80300000 prexos > go 0x80300000 > > Please share your experiments with this patch! > > Cheers, > > RICHARD > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Prex-devel mailing list > Pre...@li... > https://lists.sourceforge.net/lists/listinfo/prex-devel > |
From: <rpa...@ca...> - 2010-09-30 20:05:22
|
Hello all, I have finally updated my port of Prex 0.9.0 for the BeagleBoard to support the MMU and the CACHE (L1 cache only for the moment). As the diff file is more than 2,000 lines long, I make it available via PasteBin at the following URL: http://pastebin.com/JV2Mipbq This patch also provides support for R_ARM_V4BX relocations (thank you Andrew - this makes it possible to use latest CodeSoursourcey G++ toolchain 2010q1 to compile for the BeagleBoard) and includes a few bug fixes (including a nasty one in usr/sbin/init/init.c which only showed up when DEBUG was turned off!). As a reminder, to load this patch on the BeagleBoard, put the prexos compiled image on a FAT formatted SD CARD and issue the following commands in u-boot: mmc init fatload mmc 0 0x80300000 prexos go 0x80300000 Please share your experiments with this patch! Cheers, RICHARD |
From: alireza g. <rav...@ya...> - 2010-09-12 13:36:50
|
Hi I posted a thread in the prex forum, but since no one replied in a long time, I decided to try the mailing list. I have problem booting prex 0.9.0. I have successfully compiled prex 0.9.0 using gcc and I have the "prexos" file as output, but apparently the information on the prex website about how to boot prex is out of date. First of all because it talks about files that are not being generated from the compilation and second, it speaks of how to make a bootable floppy disc(not a cd) which is obsolete and hard to access. So I was hoping if anyone call tell me how to make a bootable CD from the output of my prex 0.9.0 compilation. thanx in advance. |
From: Kohsuke O. <ko...@us...> - 2010-07-14 17:17:58
|
Hi, (7/13/2010 8:07 PM) Richard PANDION wrote: > Indeed, in the load_elf() function in bsp/boot/common/elf.c, at line #75, there is the following assignment: > > load_base = (vaddr_t)ptokv(phdr->p_paddr); > > This seems to be wrong and should be: > > load_base = (paddr_t)kvtop(phdr->p_vaddr); I've applied fix. Thanks. - Kohsuke |