http://blog.gmane.org/gmane.os.prex.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.os.prex.devel/312 <pre>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? </pre> David Given 2013-05-22T17:24:11 http://comments.gmane.org/gmane.os.prex.devel/310 <pre>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 ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite fo</pre> Gustavo Luiz Pasqualini 2013-03-15T00:44:24 http://comments.gmane.org/gmane.os.prex.devel/309 <pre>http://dnfhw.com/dF8SbpvO3qHUTsB/templets/hbbbs.htm ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d </pre> alireza ghassemi 2011-11-22T04:10:38 http://comments.gmane.org/gmane.os.prex.devel/306 <pre>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 ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 </pre> Tony Garnock-Jones 2011-05-30T11:38:39 http://comments.gmane.org/gmane.os.prex.devel/305 <pre>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 ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 </pre> Elinam Hini 2011-05-28T20:39:42 http://comments.gmane.org/gmane.os.prex.devel/300 <pre>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. </pre> Peter Desnoyers 2011-02-11T03:46:55 http://comments.gmane.org/gmane.os.prex.devel/299 <pre>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</pre> bifferos 2011-01-10T11:17:26 http://comments.gmane.org/gmane.os.prex.devel/298 <pre>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 蚀 ------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev _______________________________________________ Prex-devel mailing list Prex-devel&lt; at &gt;lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/prex-dev</pre> Dave Skidmore 2010-11-10T22:57:12 http://comments.gmane.org/gmane.os.prex.devel/297 <pre>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 ==&gt;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 À : rpandion&lt; at &gt;caramail.com, prex-devel&lt; at &gt;lists.sourceforge.net Objet : Re: [Prex-devel] BeaglePort with MMU and CACHE Hi&gt; 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 := $(s</pre> Richard PANDION 2010-10-01T21:31:30 http://comments.gmane.org/gmane.os.prex.devel/295 <pre>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 sta</pre> rpandion< at >caramail.com 2010-09-30T19:19:57 http://comments.gmane.org/gmane.os.prex.devel/294 <pre>------------------------------------------------------------------------------ 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 Prex-devel&lt; at &gt;lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/prex-devel </pre> alireza ghassemi 2010-09-12T13:36:38 http://comments.gmane.org/gmane.os.prex.devel/292 <pre>Hello all, I believe I've detected a bug in Prex 0.9.0 bootloader. 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-&gt;p_paddr); This seems to be wrong and should be: load_base = (paddr_t)kvtop(phdr-&gt;p_vaddr); This is a nasty bug as it remains silent if you stick to the default config where offset to the kernel area start address (0x80000000) from ram base (0x00000000) equals 0x80000000. Indeed, phdr-&gt;p_paddr and phdr-&gt;p_vaddr both holds the same value as CONFIG_KERNEL_TEXT while the kernel is loaded and, in MMU-enabled default config, this value is &gt; 0x80000000. But adding 0x80000000 (this is what ptokv() does) or substrating 0x80000000 (this is what kvtop() does) to such address actually gives the exact same result since we are here dealing with 32-bits wide unsigned longs! Now, if for any reason, offset to kernel start address from ram base does no equal 0x80000000, the bug comes out. Hopefully, fixing this </pre> Richard PANDION 2010-07-13T11:07:02 http://comments.gmane.org/gmane.os.prex.devel/291 <pre>------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first_______________________________________________ Prex-devel mailing list Prex-devel&lt; at &gt;lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/prex-devel </pre> Richard PANDION 2010-06-29T05:16:58 http://comments.gmane.org/gmane.os.prex.devel/289 <pre>Hello Andrew, FYI, this patch also seems to fix the issue wile building PREX (for the BeagleBoard) with the latest CodeSourcery G++ toolchains. Indeed, I used to be unable to compile PREX correctly using any version higher that 2007q3 (relocation error) and after applying this patch, It builds flawlessly with 2009q1 and 2010q1. Thanks a lot! RICHARD ----- Message d'origine ----- De : Andrew Dennison Envoyés : 22.06.10 14:30 À : way Objet : Re: [Prex-devel] prex in QEMU I've pushed up a version that seems to support R_ARM_V4BX relocations. http://github.com/AndrewD/prex/commit/4caaaef28ae65ab403b4c23b13fa11324c2b1c3e Works for me but this is lightly tested so I've pushed it to a branch for now. ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ________________________</pre> Richard PANDION 2010-06-29T08:30:37 http://comments.gmane.org/gmane.os.prex.devel/283 <pre>------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo_______________________________________________ Prex-devel mailing list Prex-devel&lt; at &gt;lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/prex-devel </pre> way 2010-06-17T11:24:54 http://comments.gmane.org/gmane.os.prex.devel/282 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Huzzah, I'm now booting (very slowly) to a shell on my emulated Cybiko! It's nowhere near checkin yet --- apart from anything else, I need to write a serial driver so I can interact with the shell --- but there is one Prex bugfix that people may be interested in: http://github.com/davidgiven/prex/commit/0e8f157eff55b8ae9b933debc6c2aa2b9da52613 This fixes a bug in the ELF loader where rela relocations relative to the *ABS* section would garble the address. These are used on the H8300S, where jsr instructions are always relative and so even jumps to absolute addresses need fixing up. - -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ │ "Money is a sign of poverty." --- Iain Banks │ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFMGVVmf9E0noFvlzgRAhxgAJ0ScQDsipxchO+Wc6Pl+wsfNQjFWgCffpYx eQCfJu170VBNV5</pre> David Given 2010-06-16T22:51:18 http://comments.gmane.org/gmane.os.prex.devel/274 <pre>So I appear to be terminally stuck with my vfork() issue --- I think there's at least one thing wrong that I'm doing plus at least one thing wrong that Prex is doing. The next stage is to try and duplicate the issue on GBA and right now I don't have the energy to build the wacky gcc variant it needs. However: in the process of working on the Cybiko, I ran out of ROM space (it's only got 256kB). To work round this I implemented a compressed ROM file system using zlib's puff lightweight inflator. This compresses each 512 byte block individually so the compression ratio's not brilliant, but it's still achieving about 2:1 and supports true random access. puff is about 2kB of code and is under a pretty much identical license to Prex. So is this useful to anybody? Shall I try and clean up the patch, and if so, what should I do with it (the Prex mailing list doesn't seem to accept patches)? One complication is that it needs a custom program to create the compressed file system image, and right now th</pre> David Given 2010-06-14T16:24:29 http://comments.gmane.org/gmane.os.prex.devel/268 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am confused about how the implementation of vfork for non-MMU devices works. It's late, but I'm pretty sure it *can't* work, and would like to know if anyone has any non-MMU devices where init starts properly. What it does is to create a child task and then go to sleep. The child longjmps back into the parent task's stack, vfork returns, and the child runs code until it calls exec() or exit(). At this point the parent wakes up again and continues executing. Except that because both the child and the parent are running on the same stack, and the child is *returning* from vfork, won't the child trash the stack that the parent is going to need to use when it wakes up again? What's worse, when the new task is created, no new user-mode stack is specified. This means that the new task runs on the same stack as the old task --- but starting from the top again, so overwriting the old task's stack, resulting in horrible stack corruption. Has anyone seen this work? </pre> David Given 2010-06-02T23:56:11 http://comments.gmane.org/gmane.os.prex.devel/266 <pre>Hi Kohsuke, Is there anything I can do to help setup a public tree that you can push your changes into? I would really like to help work out a mechanism that you are happy with so Prex can gain some momentum. Do you have any particular tools and procedures in mind? Regards, Andrew ------------------------------------------------------------------------------ </pre> Andrew Dennison 2010-06-02T01:41:30 http://comments.gmane.org/gmane.os.prex.devel/258 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There's a possibility I might be able to restart work on my Cybiko[*] port some time in the future. Since I stopped work, a new version of Prex came out; it's probably best for me to restart with a clean build. Where's the recommended place to start these days --- Kohsuke Ohtani's 0.9.0 version, or Andrew Dennison's 0.8.1 tree? To make life more complicated, the Cybiko only has 256kB ROM and 256-512kB RAM, so I have to be very careful about space. If I could run the kernel as XIP, rather than loading it into memory, that'd be ideal. Is that possible these days? [*] Cheap, now defunct, handheld toy computer with a Hitachi H8300S processor and proprietary wireless connection. - -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ │ life←{ ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ } │ --- Conway's Game Of Life, in one line of APL -----BEGIN PGP SIGNATURE----- Version: GnuPG v</pre> David Given 2010-05-26T22:44:44 http://comments.gmane.org/gmane.os.prex.devel/257 <pre>The attached file is fatfs for Prex 0.9.0. In the implementation, FAT32 is merged. Besides, the operations of FAT &amp; Directory table entries are buffered. File read/write operations will get better performance. For further imformation, please check CONFIG_FATFS_CACHE macro. best regards champ yen == Champ Yen http://champyen.blogspot.com ------------------------------------------------------------------------------ Download Intel&amp;#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev_______________________________________________ Prex-devel mailing list Prex-devel&lt; at &gt;lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/prex-devel </pre> champ yen 2010-04-17T11:39:01 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.os.prex.devel