prex-devel Mailing List for Prex Embedded Real-time OS (Page 3)
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...> - 2010-06-02 01:55:55
|
On Wed, Jun 2, 2010 at 3:25 AM, David Given <dg...@co...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 28/05/10 00:00, Andrew Dennison wrote: > [...] >> I can describe it in general terms. > [...snip...] > > That's very interesting; it's nice to hear how this sort of thing works > in the real world. ARM, I presume? If I may ask, what made you decide to > use Prex and not a more established OS like ECOS or FreeRTOS? BookE PowerPC. First think I did with Prex was port it to a new architecture. We wanted to use the MMU for security reasons as we run "untrusted" generated code. Once we collated our requirements the list of RTOS options got rather narrow. We seriously consider some expensive commercial options too but in the end Prex was the best fit. [...] > I suspect Kohsuke Ohtani simply doesn't have > time/inclination to be a source herder. As you know, it's a thankless > and surprisingly complicated job. In our early discussions he was always keen to get more contributors to Prex. Maybe real life has got in the way over the last few years? I started up my public tree because I wanted to help in this area but all the changes in 0.9 have stalled that effort. > > However, the really nasty bits were (a) figuring out how to drive ld to > link my image together in really non-standard ways and (b) figuring out > the build system. Prex's Make-based build system is a paragon of > excellence compared to most Make build systems, but it's still a Make > build system and therefore inscrutable and horribly inflexible, and I > had to rewrite big chunks of it to support my kernel XIP stuff. We have fixed up a lot of the make file issues in the tree I published. For example we added full dependency checking and support for parallel make. Thinking about it I could not use a Vanilla 0.9 prex as we have improved this area a lot in our tree. I can see why XIP was hard for you. One thing I added long ago was the ability to have static drivers linked into kernel which is why kernel XIP was easy for us. Maybe I should have pushed you towards my 0.8.1 tree after all... Andrew |
From: Andrew D. <and...@gm...> - 2010-06-02 01:47:16
|
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 |
From: David G. <dg...@co...> - 2010-06-02 00:07:18
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/06/10 20:54, Ivo Vachkov wrote: [...] > Please, keep the make/gmake build system. It may be a bit clumsy but > at least it's portable and already present on all major OSs. I really > don't want to install yet another make alternative for every project i > [try to] participate into :) Don't worry, I have neither the authority nor the ability to change anything with the project unless asked! But I'm spending about half my time now rebuilding everything from scratch whenever I make a minor change, because there's no dependency management. (If you make a change to, say, systraps.h, you need to rebuild all the user-space programs, recreate the boot disk, and then regenerate the boot image. None of this happens automatically.) I wrote Prime Mover when trying to deal with a big compiler project that used lots of dynamically generated source files, lots of rebuilding the same source file with slightly different options, lots of cross-compiling big chunks of the tree multiple times for different architectures --- all stuff that make does *really badly*. Also, there are no dependencies! The whole Prime Mover executable is a single shell script that deploys with the project, so no installation needed. Basic summary and example here: http://primemover.sourceforge.net/about.html As this is a blatant advertisement, anyone who's interested please mail me directly so as not to spam the list. - -- ┌─── dg@cowlark.com ───── 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 v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFMBaCof9E0noFvlzgRAof+AJ9nX0KISNs+QBXkuCG+RrJSI6FPBQCgnaqr DLJ+rZWUoHvgQBhzKDRcu9I= =eZnr -----END PGP SIGNATURE----- |
From: Ivo V. <ivo...@gm...> - 2010-06-01 19:55:27
|
Hello, On Tue, Jun 1, 2010 at 8:25 PM, David Given <dg...@co...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 28/05/10 00:00, Andrew Dennison wrote: > [...] >> I can describe it in general terms. > [...snip...] > > That's very interesting; it's nice to hear how this sort of thing works > in the real world. ARM, I presume? If I may ask, what made you decide to > use Prex and not a more established OS like ECOS or FreeRTOS? > > [...] >> I would like to add features to Prex like tickless operation, Futexes >> and a better model for task / server memory operations as a few >> examples but it would be nice to have a proper collaborative >> development model so I'm not effectively maintaining a fork that has >> to be rebased onto the moving target of the "official" tarballs that >> come out occasionally. > > Yes, it's a pity. I suspect Kohsuke Ohtani simply doesn't have > time/inclination to be a source herder. As you know, it's a thankless > and surprisingly complicated job. > > Incidentally, I'm making decent progress with the Cybiko port. I managed > to persuade the build system to produce a linked-together image > consisting of kernel and bootup tasks, which lets me run them all out of > flash. I've got it booting up into 'user' mode and trying to load > /boot/init. Currently that's failing because I haven't done an H8300S > elf relocator yet. But it's running multiple processes and threads, > interrupts are working, the timer is running --- no preemption or > exceptions yet, but that's not bad for under a week's work. > > The biggest hurdles in the code were getting my head around the rather > strange and undocumented way user/kernel stacks work (it's not obvious > it's necessary to remember what your kernel stack is when switching to > user mode, and switching back to it on a syscall or interrupt). And > syscall_ret has nothing to do with returning from system calls. > > However, the really nasty bits were (a) figuring out how to drive ld to > link my image together in really non-standard ways and (b) figuring out > the build system. Prex's Make-based build system is a paragon of > excellence compared to most Make build systems, but it's still a Make > build system and therefore inscrutable and horribly inflexible, and I > had to rewrite big chunks of it to support my kernel XIP stuff. Please, keep the make/gmake build system. It may be a bit clumsy but at least it's portable and already present on all major OSs. I really don't want to install yet another make alternative for every project i [try to] participate into :) > It just so happens that I have a build tool of my own <plug> > http://primemover.sf.net </plug> that is ideally suited for this sort of > project. Would anyone be interested in a new, better build system? > > - -- > ┌─── dg@cowlark.com ───── 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 v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkwFQqQACgkQf9E0noFvlzjSyACfUODseY2hCx2kLYBE3ibMjK95 > M2oAniw+rpONMOXtmC28ZGpxlxValjmC > =SPIc > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > > _______________________________________________ > Prex-devel mailing list > Pre...@li... > https://lists.sourceforge.net/lists/listinfo/prex-devel > -- "UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." Dennis Ritchie |
From: David G. <dg...@co...> - 2010-06-01 17:26:18
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28/05/10 00:00, Andrew Dennison wrote: [...] > I can describe it in general terms. [...snip...] That's very interesting; it's nice to hear how this sort of thing works in the real world. ARM, I presume? If I may ask, what made you decide to use Prex and not a more established OS like ECOS or FreeRTOS? [...] > I would like to add features to Prex like tickless operation, Futexes > and a better model for task / server memory operations as a few > examples but it would be nice to have a proper collaborative > development model so I'm not effectively maintaining a fork that has > to be rebased onto the moving target of the "official" tarballs that > come out occasionally. Yes, it's a pity. I suspect Kohsuke Ohtani simply doesn't have time/inclination to be a source herder. As you know, it's a thankless and surprisingly complicated job. Incidentally, I'm making decent progress with the Cybiko port. I managed to persuade the build system to produce a linked-together image consisting of kernel and bootup tasks, which lets me run them all out of flash. I've got it booting up into 'user' mode and trying to load /boot/init. Currently that's failing because I haven't done an H8300S elf relocator yet. But it's running multiple processes and threads, interrupts are working, the timer is running --- no preemption or exceptions yet, but that's not bad for under a week's work. The biggest hurdles in the code were getting my head around the rather strange and undocumented way user/kernel stacks work (it's not obvious it's necessary to remember what your kernel stack is when switching to user mode, and switching back to it on a syscall or interrupt). And syscall_ret has nothing to do with returning from system calls. However, the really nasty bits were (a) figuring out how to drive ld to link my image together in really non-standard ways and (b) figuring out the build system. Prex's Make-based build system is a paragon of excellence compared to most Make build systems, but it's still a Make build system and therefore inscrutable and horribly inflexible, and I had to rewrite big chunks of it to support my kernel XIP stuff. It just so happens that I have a build tool of my own <plug> http://primemover.sf.net </plug> that is ideally suited for this sort of project. Would anyone be interested in a new, better build system? - -- ┌─── dg@cowlark.com ───── 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 v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwFQqQACgkQf9E0noFvlzjSyACfUODseY2hCx2kLYBE3ibMjK95 M2oAniw+rpONMOXtmC28ZGpxlxValjmC =SPIc -----END PGP SIGNATURE----- |
From: Andrew D. <and...@gm...> - 2010-05-27 23:00:09
|
On Thu, May 27, 2010 at 10:42 PM, David Given <dg...@co...> wrote: > On 2010-05-27 05:02, Andrew Dennison wrote: >> ... >> We are >> also doing XIP of userspace in our product, this was mainly just >> writing a file system that stores files in aligned chunks of flash and >> a few scattered tweaks. > > Ooh --- can you tell us anything about this product? How does Prex scale to > platforms with real functionality? Hi David, I can describe it in general terms. We are building a deeply embedded product that controls a complex mechanical system, running periodic tasks at rates up to 1kHz. It also incorporates data acquisition capable of operating at the same rate for performance analysis of both the control strategy and the mechanical environment. The device is "headless", it is managed by a PC application using a standard protocol over IPV6 UDP on 10/100 Ethernet. All Ethernet comms is "link local" and we have taken advantage of that fact to write a small and efficient UDP only IPV6 stack. The code for the control strategy is generated based on a high level description and automatically compiled and loaded into the device as a separate process. The end user can implement their own control strategy. The product implements robust security protected at the hardware level, device software level with full MMU protection and communications level with Public key cryptography and other normal security measures. We have reached a point with Prex where it "just works". There are some performance limitations we would like to address but we have fixed lots of bugs and it is now nice and stable. All of those fixes up to a certain date are in my public tree as we want to avoid others duplicating our efforts. I would like to add features to Prex like tickless operation, Futexes and a better model for task / server memory operations as a few examples but it would be nice to have a proper collaborative development model so I'm not effectively maintaining a fork that has to be rebased onto the moving target of the "official" tarballs that come out occasionally. Andrew |
From: David G. <dg...@co...> - 2010-05-27 15:00:53
|
On 2010-05-27 05:02, Andrew Dennison wrote: [...] > I've been having a break from maintaining a public version of Prex as > I don't have time to merge 0.9 with the product I'm working on. I > would really like to be tracking a public tree, instead of taking the > hit of another huge merge and the flow on round of bug fixing. Cool. Will do. [...] > XIP for the kernel is fairly easy, there is support for that in my > tree and you should be able to port that to 0.9 fairly easily. Can you give me a pointer to the appropriate place? I had a look but didn't spot any unusual link scripts. > We are > also doing XIP of userspace in our product, this was mainly just > writing a file system that stores files in aligned chunks of flash and > a few scattered tweaks. Ooh --- can you tell us anything about this product? How does Prex scale to platforms with real functionality? -- ┌─── dg@cowlark.com ───── http://www.cowlark.com ───── │ │ life←{ ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ } │ --- Conway's Game Of Life, in one line of APL |
From: Andrew D. <and...@gm...> - 2010-05-27 04:02:45
|
On Thu, May 27, 2010 at 8:44 AM, David Given <dg...@co...> wrote: > -----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? Hi David, You may as well start with 0.9.0. I've been having a break from maintaining a public version of Prex as I don't have time to merge 0.9 with the product I'm working on. I would really like to be tracking a public tree, instead of taking the hit of another huge merge and the flow on round of bug fixing. I've been meaning to strike up some discussion with Kohsuke to see if I can help get a public tree going. > 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? XIP for the kernel is fairly easy, there is support for that in my tree and you should be able to port that to 0.9 fairly easily. We are also doing XIP of userspace in our product, this was mainly just writing a file system that stores files in aligned chunks of flash and a few scattered tweaks. Andrew |
From: Rob W. <rw...@az...> - 2010-05-27 00:00:33
|
On Wed, 26 May 2010 18:44:44 -0400, David Given <dg...@co...> wrote: > [*] Cheap, now defunct, handheld toy computer with a Hitachi H8300S > processor and proprietary wireless connection. > ...it is probably an H8S/2xxx series microcontroller and not an H8/300. Unlike the 300-series, the 2000-series has an external address and data bus. Some (a few) have on-chip memory controllers. When building a cross-compiler for the H8 family, you specify the target=h8300 and it will build for all variants, including the relatively new H8SX. When compiling for your target, you will want to specify the 'S' variant and probably a 32-bit integer, which I thought/think Prex wants. -ms -mint32 You'll want to create a suitable linker script for your target that speaks to your memory map. Take Care. Rob! |
From: David G. <dg...@co...> - 2010-05-26 23:05:21
|
-----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. - -- ┌─── dg@cowlark.com ───── 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 v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFL/aRcf9E0noFvlzgRAsH0AKDDZY/HIYN86wtfLxqlwUTHvhA+AwCcCS/T etySGiiM5eRKFt6/zjtxBm4= =po32 -----END PGP SIGNATURE----- |
From: champ y. <cha...@gm...> - 2010-04-17 11:39:08
|
The attached file is fatfs for Prex 0.9.0. In the implementation, FAT32 is merged. Besides, the operations of FAT & 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 |
From: Raymond H. <ray...@gm...> - 2010-04-09 14:45:10
|
Has anyone taken the time and effort to enable the MMU on the Beagle Board? I have the MMU-less version of PREX running on the Beagle Board right now. It works fine, but I may want to have the memory protection of an MMU. Thanks ray |
From: champ y. <cha...@gm...> - 2010-03-29 09:54:09
|
Hello Sammy: The reason of disabling cache for MMU is cache consistency. Currently my port of prex uses write-through cache with MMU successfully by flushing cache with test-clean-flush loop method in copyin/copyout/copystr(locore.S) and switch_ttb(cpufunc.S). For write-back cache, more works must be done and I'm trying now. best regards champ yen On Sat, Jan 23, 2010 at 8:13 AM, sasamy <sa...@ya...> wrote: > > Hi. I got a working system on AT91SAM9260 (ARM926EJ-S) with MMU. I had to disable the cache for all pages of memory, without it does not work and I do not know how to do properly. This patch for MMU changes, fixes the drivers are too large to print here. > > > Alexander > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Prex-devel mailing list > Pre...@li... > https://lists.sourceforge.net/lists/listinfo/prex-devel |
From: cyril.L <lis...@lu...> - 2010-02-13 19:23:01
|
Yes it would be nice :), Why not starting by merging Andrew's github with 0.9 (directory structure at least) ? I am not really interested in improving the kernel, but sharing ports and drivers (nearly finished a Nintendo DS port). I am also involved in robotics and I would like to see the Carnegie Mellon team contributing to the project ! cyril Le 12 févr. 10 à 22:33, L D a écrit : > 0.8.1 was an example. 0.9.0 is fine. What matters is how we go from > there. I think we should collaborate early on before this thing > becomes too complicated. > > On Fri, Feb 12, 2010 at 6:28 PM, Alt <al...@al...> wrote: >> why not 0.9.0? >> >> On Fri, Feb 12, 2010 at 2:35 PM, L D <emb...@gm...> wrote: >>> Hello everyone, >>> >>> I am looking for developers that are interested in a more >>> collaborative, evolutionary development process for prex 0.8.1. I >>> would like to be involved in the development of prex instead of >>> trying >>> to figure out what changed when the next version is "delivered". If >>> there are developers out there who are happy with 0.8.1 and want to >>> improve on it then I would like to hear from them. It does not >>> have to >>> be 0.8.1, any common starting point will do. >>> Please feel free to express your opinion. Thank you. >>> >>> embedpro >>> >>> ------------------------------------------------------------------------------ >>> SOLARIS 10 is the OS for Data Centers - provides features such as >>> DTrace, >>> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW >>> http://p.sf.net/sfu/solaris-dev2dev >>> _______________________________________________ >>> Prex-devel mailing list >>> Pre...@li... >>> https://lists.sourceforge.net/lists/listinfo/prex-devel >>> >> >> >> >> -- >> .alt. >> > > ------------------------------------------------------------------------------ > SOLARIS 10 is the OS for Data Centers - provides features such as > DTrace, > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > http://p.sf.net/sfu/solaris-dev2dev > _______________________________________________ > Prex-devel mailing list > Pre...@li... > https://lists.sourceforge.net/lists/listinfo/prex-devel |
From: L D <emb...@gm...> - 2010-02-13 03:34:02
|
0.8.1 was an example. 0.9.0 is fine. What matters is how we go from there. I think we should collaborate early on before this thing becomes too complicated. On Fri, Feb 12, 2010 at 6:28 PM, Alt <al...@al...> wrote: > why not 0.9.0? > > On Fri, Feb 12, 2010 at 2:35 PM, L D <emb...@gm...> wrote: >> Hello everyone, >> >> I am looking for developers that are interested in a more >> collaborative, evolutionary development process for prex 0.8.1. I >> would like to be involved in the development of prex instead of trying >> to figure out what changed when the next version is "delivered". If >> there are developers out there who are happy with 0.8.1 and want to >> improve on it then I would like to hear from them. It does not have to >> be 0.8.1, any common starting point will do. >> Please feel free to express your opinion. Thank you. >> >> embedpro >> >> ------------------------------------------------------------------------------ >> SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, >> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW >> http://p.sf.net/sfu/solaris-dev2dev >> _______________________________________________ >> Prex-devel mailing list >> Pre...@li... >> https://lists.sourceforge.net/lists/listinfo/prex-devel >> > > > > -- > .alt. > |
From: L D <emb...@gm...> - 2010-02-12 22:39:53
|
Is the word prex allowed in an email? |
From: L D <emb...@gm...> - 2010-02-12 22:35:58
|
Hello everyone, I am looking for developers that are interested in a more collaborative, evolutionary development process for prex 0.8.1. I would like to be involved in the development of prex instead of trying to figure out what changed when the next version is "delivered". If there are developers out there who are happy with 0.8.1 and want to improve on it then I would like to hear from them. It does not have to be 0.8.1, any common starting point will do. Please feel free to express your opinion. Thank you. embedpro |
From: Andrew D. <and...@gm...> - 2010-02-10 03:21:05
|
On Wed, Feb 10, 2010 at 1:11 PM, Bradford Neuman <bn...@an...> wrote: > Hello developers, > > I am on a team at Carnegie Mellon working to develop a new small > robotics research platform called Colony Scout. We are designing a > custom ARM-based board for the processing and control of hardware. We > are looking for a light weight POSIX complaint soft real-time OS for > our platform and the goal of Prex seems like exactly what we want. > > Feel free to take a look at www.colonyscout.com for some preliminary > information. Hi Brad, Looks like a fun project. > So far we have started looking at the arm-integrator port and are > planning to work from there. I would like to know how we should go > about this work. Should we work from version 0.9.9 listed on the > homepage or is there a more up-to-date repository somewhere? We also > hope to implement some networking using the ZigBee protocol down the > road and I see that networking support is in the works. Unfortunately the owner of Prex has not made any public source control available. I was maintaining a git tree of my changes against 0.8.1, including board ports from others, however there were extensive changes when the 0.9.0 tarball was released. I haven't had the energy to undertake yet another big merge to bring my tree up to date and this list has got rather quiet again. > Also, is it appropriate to post specific porting-related questions > here or should those be in the forum? This list is the best place. The sourceforge forum was even more quiet than this list last I looked. I agree that Prex is a great project, it just needs a live public tree and a review process to get changes accepted in a timely manner to help foster a proper active community of developers. Andrew |
From: Bradford N. <bn...@an...> - 2010-02-10 02:17:26
|
Hello developers, I am on a team at Carnegie Mellon working to develop a new small robotics research platform called Colony Scout. We are designing a custom ARM-based board for the processing and control of hardware. We are looking for a light weight POSIX complaint soft real-time OS for our platform and the goal of Prex seems like exactly what we want. Feel free to take a look at www.colonyscout.com for some preliminary information. So far we have started looking at the arm-integrator port and are planning to work from there. I would like to know how we should go about this work. Should we work from version 0.9.9 listed on the homepage or is there a more up-to-date repository somewhere? We also hope to implement some networking using the ZigBee protocol down the road and I see that networking support is in the works. Also, is it appropriate to post specific porting-related questions here or should those be in the forum? Thanks, Brad Neuman |
From: sasamy <sa...@ya...> - 2010-01-23 00:48:31
|
Hi. I got a working system on AT91SAM9260 (ARM926EJ-S) with MMU. I had to disable the cache for all pages of memory, without it does not work and I do not know how to do properly. This patch for MMU changes, fixes the drivers are too large to print here. diff -Naur prex-0.9.0.orig/bsp/hal/arm/arch/locore.S prex-0.9.0/bsp/hal/arm/arch/locore.S --- prex-0.9.0.orig/bsp/hal/arm/arch/locore.S 2009-07-29 09:52:52.000000000 +0000 +++ prex-0.9.0/bsp/hal/arm/arch/locore.S 2010-01-21 04:13:25.000000000 +0000 @@ -88,6 +88,8 @@ init_done: .word init_done_value #ifdef CONFIG_MMU reload_pc_target: .word reload_pc +clear_ctl: .word 0x00007f3f +set_ctl: .word 0x0000313d #endif ENTRY(reset_entry) @@ -118,57 +120,71 @@ #ifdef CONFIG_MMU /* - * Setup control register - */ - mov r0, #CTL_DEFAULT - mcr p15, 0, r0, c1, c0, 0 - - /* * Initialize page table * The physical address 0-4M is mapped on virtual address 2G. */ - mov r1, #BOOT_PGD_PHYS /* Clear page directory */ - mov r2, #(BOOT_PGD_PHYS + 0x4000) /* +16k */ + ldr r1, =BOOT_PGD_PHYS /* Clear page directory */ + add r2, r1, #0x4000 /* +16k */ mov r0, #0 1: str r0, [r1], #4 teq r1, r2 bne 1b - mov r1, #(BOOT_PGD_PHYS + 0x2000) /* Set PTE0 address in pgd */ - mov r0, #BOOT_PTE0_PHYS /* WBUF/CACHE/SYSTEM attribute */ - orr r0, r0, #0x03 + ldr r1, =(BOOT_PGD_PHYS + 0x2000 + PHYS >> 18) /* Set PTE0 address in pgd */ + ldr r0, =(BOOT_PTE0_PHYS | 0x11) str r0, [r1] - mov r1, #BOOT_PTE0_PHYS /* Fill boot page table entry */ - add r2, r1, #0x1000 - mov r0, #0x1e + ldr r1, =BOOT_PTE0_PHYS /* Fill boot page table entry */ + add r2, r1, #0x400 + ldr r0, =(PHYS | 0x552) 1: str r0, [r1], #4 add r0, r0, #0x1000 teq r1, r2 bne 1b + ldr r1, =(BOOT_PGD_PHYS + 0x3ffc) /* Set PTE1 address */ + ldr r0, =(BOOT_PTE1_PHYS | 0x11) + str r0, [r1] + + ldr r1, =BOOT_PTE1_PHYS /* Clear PTE1 page table */ + add r2, r1, #0x1000 + mov r0, #0 +1: + str r0, [r1], #4 + teq r1, r2 + bne 1b + + ldr r1, = BOOT_PTE1_PHYS + ldr r0, =(CONFIG_UART_BASE | 0x552) /* premap diag port */ + str r0, [r1, #(CONFIG_UART_BASE >> 10 & 0x3fc)] + + ldr r0, =0x552 /* premap vector page */ + str r0, [r1, #(CONFIG_ARM_VECTORS >> 10 & 0x3fc)] + /* * Enable paging - * The physical address 0-4M is temporarily mapped to virtial - * address 0-4M. This is needed to enable paging. */ - mov r1, #BOOT_PGD_PHYS /* Set PTE0 address in pgd */ - mov r0, #BOOT_PTE0_PHYS /* WBUF/CACHE/SYSTEM attribute */ - orr r0, r0, #0x03 + ldr r1, =(BOOT_PGD_PHYS + PHYS >> 18) /* Set PTE0 address in pgd */ + ldr r0, =(BOOT_PTE0_PHYS | 0x11) str r0, [r1] + mov r0, #4 /* disable write-back */ + mcr p15, 7, r0, c15, c0, 0 + mov r0, #0 mcr p15, 0, r0, c7, c10, 4 /* drain write buffer */ mcr p15, 0, r0, c8, c7, 0 /* flush I,D TLBs */ - mov r1, #BOOT_PGD_PHYS + ldr r1, =BOOT_PGD_PHYS mcr p15, 0, r1, c2, c0, 0 /* load page table pointer */ mov r0, #-1 mcr p15, 0, r0, c3, c0 /* load domain access register */ mrc p15, 0, r0, c1, c0, 0 - orr r0, r0, #0x1000 /* I-cache enable */ - orr r0, r0, #0x003d /* Write buffer, mmu */ + ldr r1, clear_ctl + bic r0, r0, r1 + ldr r1, set_ctl + orr r0, r0, r1 mcr p15, 0, r0, c1, c0, 0 /* @@ -177,17 +193,6 @@ ldr pc, reload_pc_target /* Reset pc here */ reload_pc: - /* - * Unmap 0-4M. - * Since the first page must be accessible for exception - * vector, we have to map it later. - */ - mov r1, #BOOT_PGD_PHYS /* Set PTE0 address in pgd */ - add r1, r1, #KERNBASE - mov r0, #0 - str r0, [r1] - mcr p15, 0, r0, c8, c7, 0 /* flush I,D TLBs */ - #endif /* !CONFIG_MMU */ /* diff -Naur prex-0.9.0.orig/bsp/hal/arm/arch/mmu.c prex-0.9.0/bsp/hal/arm/arch/mmu.c --- prex-0.9.0.orig/bsp/hal/arm/arch/mmu.c 2009-10-01 12:28:55.000000000 +0000 +++ prex-0.9.0/bsp/hal/arm/arch/mmu.c 2010-01-21 03:27:31.000000000 +0000 @@ -143,6 +143,7 @@ default: panic("mmu_map"); } +pte_flag = (uint32_t)(PTE_PRESENT | PTE_SYSTEM); /* * Map all pages */ @@ -198,8 +199,6 @@ i = PAGE_DIR(KERNBASE); memcpy(&pgd[i], &boot_pgd[i], (size_t)(L1TBL_SIZE - i * 4)); - /* Map vector page (address 0) */ - mmu_map(pgd, 0, 0, PAGE_SIZE, PG_SYSTEM); return pgd; } @@ -272,20 +271,6 @@ } /* - * Map I/O memory for diagnostic device at very early stage. - */ -void -mmu_premap(paddr_t phys, vaddr_t virt) -{ - pte_t pte = (pte_t)BOOT_PTE1; - - memset(pte, 0, L2TBL_SIZE); - boot_pgd[PAGE_DIR(virt)] = (uint32_t)kvtop(pte) | PDE_PRESENT; - pte[PAGE_TABLE(virt)] = (uint32_t)phys | PTE_PRESENT | PTE_SYSTEM; - flush_tlb(); -} - -/* * Initialize mmu * * Paging is already enabled in locore.S. And, physical address @@ -320,6 +305,6 @@ /* * Map vector page. */ - if (mmu_map(boot_pgd, 0, CONFIG_ARM_VECTORS, PAGE_SIZE, PG_SYSTEM)) + if (mmu_map(boot_pgd, PHYS, CONFIG_ARM_VECTORS, PAGE_SIZE, PG_SYSTEM)) panic("mmu_init"); } diff -Naur prex-0.9.0.orig/bsp/hal/arm/at91/diag.c prex-0.9.0/bsp/hal/arm/at91/diag.c --- prex-0.9.0.orig/bsp/hal/arm/at91/diag.c 2010-01-21 04:13:36.000000000 +0000 +++ prex-0.9.0/bsp/hal/arm/at91/diag.c 2010-01-21 03:27:31.000000000 +0000 @@ -68,7 +68,4 @@ diag_init(void) { -#ifdef CONFIG_MMU - mmu_premap(UART_BASE, UART_BASE); -#endif } diff -Naur prex-0.9.0.orig/bsp/hal/arm/at91/machdep.c prex-0.9.0/bsp/hal/arm/at91/machdep.c --- prex-0.9.0.orig/bsp/hal/arm/at91/machdep.c 2010-01-21 04:13:36.000000000 +0000 +++ prex-0.9.0/bsp/hal/arm/at91/machdep.c 2010-01-21 03:27:31.000000000 +0000 @@ -54,12 +54,14 @@ /* * External SDRAM (32M) */ - { 0xA0000000, CONFIG_RAM_BASE, CONFIG_RAM_SIZE, VMT_RAM }, + { 0xa0000000, CONFIG_RAM_BASE, CONFIG_RAM_SIZE, VMT_RAM }, /* * Internal Peripherals (544K) */ - { 0xFFF78000, 0xFFF78000, 0x88000, VMT_IO }, + { 0xfffa0000, 0xfffa0000, 0x44000, VMT_IO }, + + { 0xffffc000, 0xffffc000, 0x4000, VMT_IO }, { 0,0,0,0 } }; @@ -148,7 +150,7 @@ /* * Setup vector page. */ - vector_copy((vaddr_t)ptokv(CONFIG_ARM_VECTORS)); + vector_copy(SYSPAGE); #ifdef CONFIG_MMU /* diff -Naur prex-0.9.0.orig/bsp/hal/arm/include/mmu.h prex-0.9.0/bsp/hal/arm/include/mmu.h --- prex-0.9.0.orig/bsp/hal/arm/include/mmu.h 2009-10-01 12:28:53.000000000 +0000 +++ prex-0.9.0/bsp/hal/arm/include/mmu.h 2010-01-21 03:27:31.000000000 +0000 @@ -36,13 +36,13 @@ typedef uint32_t *pte_t; /* page table entry */ #define L1TBL_SIZE 0x4000 -#define L2TBL_SIZE 0x1000 +#define L2TBL_SIZE 0x400 /* * Page directory entry (L1) */ -#define PDE_PRESENT 0x00000003 -#define PDE_ADDRESS 0xfffff000 +#define PDE_PRESENT 0x00000011 +#define PDE_ADDRESS 0xfffffc00 /* * Page table entry (L2) @@ -50,11 +50,11 @@ #define PTE_PRESENT 0x00000002 #define PTE_WBUF 0x00000004 #define PTE_CACHE 0x00000008 -#define PTE_SYSTEM 0x00000010 -#define PTE_USER_RO 0x00000020 -#define PTE_USER_RW 0x00000030 -#define PTE_ATTR_MASK 0x00000030 -#define PTE_ADDRESS 0xfffffc00 +#define PTE_SYSTEM 0x00000550 +#define PTE_USER_RO 0x00000aa0 +#define PTE_USER_RW 0x00000ff0 +#define PTE_ATTR_MASK 0x00000ff0 +#define PTE_ADDRESS 0xfffff000 /* * Virtual and physical address translation diff -Naur prex-0.9.0.orig/conf/arm/at91 prex-0.9.0/conf/arm/at91 --- prex-0.9.0.orig/conf/arm/at91 2010-01-21 04:13:36.000000000 +0000 +++ prex-0.9.0/conf/arm/at91 2010-01-21 03:27:31.000000000 +0000 @@ -13,9 +13,9 @@ memory RAM_BASE 0x20000000 # Start of ram memory RAM_SIZE 0x2000000 # Size of ram memory LOADER_TEXT 0x20010000 # Start of boot loader -memory KERNEL_TEXT 0x20080000 # Start of kernel -memory BOOTIMG_BASE 0x20012000 # Location of boot image -memory SYSPAGE_BASE 0x20000000 # Location of system page +memory KERNEL_TEXT 0xa0080000 # Start of kernel +memory BOOTIMG_BASE 0xa0012000 # Location of boot image +memory SYSPAGE_BASE 0xa0000000 # Location of system page # # Tunable paramters @@ -30,7 +30,7 @@ # Platform settings # options ARM926EJS # Processor core -#options MMU # Memory management unit +options MMU # Memory management unit options CACHE # Cache memory #options FPU # Floating point unit #options ROMBOOT # Boot from ROM @@ -41,7 +41,7 @@ # options POSIX # POSIX support options CMDBOX # Core utilities -#options TINY # Optimize for size +options TINY # Optimize for size # # Kernel hacking @@ -86,7 +86,7 @@ # # Hardware configuations # -options ARM_VECTORS=0x00000000 +options ARM_VECTORS=0xffff0000 options MCK=98304000 options UART_BASE=0xfffb8000 options UART_IRQ=8 diff -Naur prex-0.9.0.orig/conf/etc/files.mk prex-0.9.0/conf/etc/files.mk --- prex-0.9.0.orig/conf/etc/files.mk 2009-10-01 12:14:25.000000000 +0000 +++ prex-0.9.0/conf/etc/files.mk 2010-01-21 03:27:31.000000000 +0000 @@ -63,6 +63,6 @@ #FILES+= $(SRCDIR)/usr/test/stderr/stderr #FILES+= $(SRCDIR)/usr/test/umount/umount -FILES+= $(SRCDIR)/doc/LICENSE +#FILES+= $(SRCDIR)/doc/LICENSE endif # !CONFIG_POSIX diff -Naur prex-0.9.0.orig/conf/etc/fstab prex-0.9.0/conf/etc/fstab --- prex-0.9.0.orig/conf/etc/fstab 2009-10-01 12:31:55.000000000 +0000 +++ prex-0.9.0/conf/etc/fstab 2010-01-21 03:27:31.000000000 +0000 @@ -6,7 +6,7 @@ /dev/ram0 /boot arfs none /dev devfs none /mnt/fifo fifofs -/dev/fd0 /mnt/floppy fatfs +#/dev/fd0 /mnt/floppy fatfs #/dev/mtd0 /bin ffs #/dev/mtd1 /etc ffs diff -Naur prex-0.9.0.orig/include/arm/syspage.h prex-0.9.0/include/arm/syspage.h --- prex-0.9.0.orig/include/arm/syspage.h 2009-05-14 12:23:00.000000000 +0000 +++ prex-0.9.0/include/arm/syspage.h 2010-01-21 03:27:31.000000000 +0000 @@ -81,9 +81,10 @@ #define BOOT_PTE0 (SYSPAGE + 0x8000) #define BOOT_PTE1 (SYSPAGE + 0x9000) -#define BOOT_PGD_PHYS 0x4000 -#define BOOT_PTE0_PHYS 0x8000 -#define BOOT_PTE1_PHYS 0x9000 +#define PHYS CONFIG_RAM_BASE +#define BOOT_PGD_PHYS (PHYS + 0x4000) +#define BOOT_PTE0_PHYS (PHYS + 0x8000) +#define BOOT_PTE1_PHYS (PHYS + 0x9000) #define INTSTKSZ 0x1000 #define SYSSTKSZ 0x1000 diff -Naur prex-0.9.0.orig/sys/include/hal.h prex-0.9.0/sys/include/hal.h --- prex-0.9.0.orig/sys/include/hal.h 2009-10-01 12:13:44.000000000 +0000 +++ prex-0.9.0/sys/include/hal.h 2010-01-21 03:27:31.000000000 +0000 @@ -104,7 +104,6 @@ void context_dump(context_t); void mmu_init(struct mmumap *); -void mmu_premap(paddr_t, vaddr_t); pgd_t mmu_newmap(void); void mmu_terminate(pgd_t); int mmu_map(pgd_t, paddr_t, vaddr_t, size_t, int); Alexander |
From: sasamy <sa...@ya...> - 2010-01-16 19:16:12
|
Hi. I have detected more errors which do not allow prex to work on the real processor, but in qemu all ok. For example pte_flag = (uint32_t)(PTE_PRESENT | PTE_WBUF | PTE_CACHE | PTE_SYSTEM); PTE_WBUF | PTE_CACHE - allow writeback cache policy. After remap pages, in which is tables pgd and pte, and invalidate TLB, it leads to unpredictable resultsand and errors. Alexander |
From: sasamy <sa...@ya...> - 2010-01-06 07:11:37
|
Hi. I have found a small error in operation with mmu arm. L2 page tables represents 1 MB of virtual memory - not 4 MB. This patch uses 4 coarse page tables instead of 1 fine page table. With this patch integrator works in qemu with mmu. diff -Naur prex-0.9.0_orig/bsp/hal/arm/arch/locore.S prex-0.9.0/bsp/hal/arm/arch/locore.S --- prex-0.9.0_orig/bsp/hal/arm/arch/locore.S 2009-07-29 09:52:52.000000000 +0000 +++ prex-0.9.0/bsp/hal/arm/arch/locore.S 2010-01-06 09:19:02.000000000 +0000 @@ -137,7 +137,13 @@ mov r1, #(BOOT_PGD_PHYS + 0x2000) /* Set PTE0 address in pgd */ mov r0, #BOOT_PTE0_PHYS /* WBUF/CACHE/SYSTEM attribute */ - orr r0, r0, #0x03 + orr r0, r0, #0x11 + str r0, [r1], #4 + add r0, r0, #0x400 + str r0, [r1], #4 + add r0, r0, #0x400 + str r0, [r1], #4 + add r0, r0, #0x400 str r0, [r1] mov r1, #BOOT_PTE0_PHYS /* Fill boot page table entry */ @@ -156,7 +162,7 @@ */ mov r1, #BOOT_PGD_PHYS /* Set PTE0 address in pgd */ mov r0, #BOOT_PTE0_PHYS /* WBUF/CACHE/SYSTEM attribute */ - orr r0, r0, #0x03 + orr r0, r0, #0x11 str r0, [r1] mov r0, #0 diff -Naur prex-0.9.0_orig/bsp/hal/arm/include/mmu.h prex-0.9.0/bsp/hal/arm/include/mmu.h --- prex-0.9.0_orig/bsp/hal/arm/include/mmu.h 2009-10-01 12:28:53.000000000 +0000 +++ prex-0.9.0/bsp/hal/arm/include/mmu.h 2010-01-06 09:20:24.000000000 +0000 @@ -36,13 +36,13 @@ typedef uint32_t *pte_t; /* page table entry */ #define L1TBL_SIZE 0x4000 -#define L2TBL_SIZE 0x1000 +#define L2TBL_SIZE 0x400 /* * Page directory entry (L1) */ -#define PDE_PRESENT 0x00000003 -#define PDE_ADDRESS 0xfffff000 +#define PDE_PRESENT 0x00000011 +#define PDE_ADDRESS 0xfffffc00 /* * Page table entry (L2) Alexander |
From: xaxes <xax...@fo...> - 2010-01-04 22:30:17
|
Hey, in fact that very often people have problems building their own cross-compiling toolchain I want to show you a litte, very nice project. git://git.infradead.org/users/segher/buildall.git It's maintained by Segher, a activ member of #gcc (freenode). So get the latest sources of binutils, gcc and untar them. Modify the config, and run the build script and you'll have a (for me) working toolchain in only few minutes. Greets phil David Welch <dw...@dw...> wrote: > > No doubt a lot of effort to find the right combination of gcc and > binutils. The combination and your build produce something that can > build prex. I am running on an ubuntu 9.10 machine, wait no this is > 9.04, hmmm what happened there. Will try with a 9.10 machine soon. > Thank you for that effort. > > David > > David Welch wrote: > > Understood, your version, and may other variations, I have tried many > > times over the years, I guess you didnt understand my goals and response. > > > > I will try this particular variation. > > > > Thanks for the info and the web page. > > David > > > > David Given wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> On 03/01/10 21:50, David Welch wrote: > >> [...] > >>> Sure, just tested it using an arm-elf target instead of arm-none-eabi, > >>> it built a usable arm cross toolchain. But prex wants more than a cross > >>> compiler. It wants libraries too. > >> My instructions should build the *runtime* libraries --- which is what > >> Prex needs (I originally wrote these while struggling with an H8S port > >> of Prex). But they won't build the *C* libraries (libc etc). > >> > >> Building gcc is horribly magic --- some versions just don't work. The > >> CFLAGS setting is very important. I'd suggest try following my > >> instructions straight and making sure that it actually works before > >> trying again with a different version. > >> > >> - -- > >> ┌─── dg@cowlark.com ───── http://www.cowlark.com ───── > >> │ > >> │ "Sufficiently advanced incompetence is indistinguishable from > >> │ malice." -- Vernon Schryver > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG v1.4.9 (GNU/Linux) > >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > >> > >> iEYEARECAAYFAktBEqwACgkQf9E0noFvlzh/pwCg0RXqBRzLpjfYVVvgQMU/mD3n > >> OlUAn0ztnENNHxsT80aO3I4YUym6vWR/ > >> =TGcI > >> -----END PGP SIGNATURE----- > >> > >> ------------------------------------------------------------------------------ > >> This SF.Net email is sponsored by the Verizon Developer Community > >> Take advantage of Verizon's best-in-class app development support > >> A streamlined, 14 day to market process makes app distribution fast and easy > >> Join now and get one step closer to millions of Verizon customers > >> http://p.sf.net/sfu/verizon-dev2dev > >> _______________________________________________ > >> Prex-devel mailing list > >> Pre...@li... > >> https://lists.sourceforge.net/lists/listinfo/prex-devel > > > > > > ------------------------------------------------------------------------------ > > This SF.Net email is sponsored by the Verizon Developer Community > > Take advantage of Verizon's best-in-class app development support > > A streamlined, 14 day to market process makes app distribution fast and easy > > Join now and get one step closer to millions of Verizon customers > > http://p.sf.net/sfu/verizon-dev2dev > > _______________________________________________ > > Prex-devel mailing list > > Pre...@li... > > https://lists.sourceforge.net/lists/listinfo/prex-devel > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Prex-devel mailing list > Pre...@li... > https://lists.sourceforge.net/lists/listinfo/prex-devel |
From: David W. <dw...@dw...> - 2010-01-04 18:30:19
|
No doubt a lot of effort to find the right combination of gcc and binutils. The combination and your build produce something that can build prex. I am running on an ubuntu 9.10 machine, wait no this is 9.04, hmmm what happened there. Will try with a 9.10 machine soon. Thank you for that effort. David David Welch wrote: > Understood, your version, and may other variations, I have tried many > times over the years, I guess you didnt understand my goals and response. > > I will try this particular variation. > > Thanks for the info and the web page. > David > > David Given wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 03/01/10 21:50, David Welch wrote: >> [...] >>> Sure, just tested it using an arm-elf target instead of arm-none-eabi, >>> it built a usable arm cross toolchain. But prex wants more than a cross >>> compiler. It wants libraries too. >> My instructions should build the *runtime* libraries --- which is what >> Prex needs (I originally wrote these while struggling with an H8S port >> of Prex). But they won't build the *C* libraries (libc etc). >> >> Building gcc is horribly magic --- some versions just don't work. The >> CFLAGS setting is very important. I'd suggest try following my >> instructions straight and making sure that it actually works before >> trying again with a different version. >> >> - -- >> ┌─── dg@cowlark.com ───── http://www.cowlark.com ───── >> │ >> │ "Sufficiently advanced incompetence is indistinguishable from >> │ malice." -- Vernon Schryver >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.9 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAktBEqwACgkQf9E0noFvlzh/pwCg0RXqBRzLpjfYVVvgQMU/mD3n >> OlUAn0ztnENNHxsT80aO3I4YUym6vWR/ >> =TGcI >> -----END PGP SIGNATURE----- >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> Prex-devel mailing list >> Pre...@li... >> https://lists.sourceforge.net/lists/listinfo/prex-devel > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Prex-devel mailing list > Pre...@li... > https://lists.sourceforge.net/lists/listinfo/prex-devel |
From: David W. <dw...@dw...> - 2010-01-03 22:10:52
|
Understood, your version, and may other variations, I have tried many times over the years, I guess you didnt understand my goals and response. I will try this particular variation. Thanks for the info and the web page. David David Given wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 03/01/10 21:50, David Welch wrote: > [...] >> Sure, just tested it using an arm-elf target instead of arm-none-eabi, >> it built a usable arm cross toolchain. But prex wants more than a cross >> compiler. It wants libraries too. > > My instructions should build the *runtime* libraries --- which is what > Prex needs (I originally wrote these while struggling with an H8S port > of Prex). But they won't build the *C* libraries (libc etc). > > Building gcc is horribly magic --- some versions just don't work. The > CFLAGS setting is very important. I'd suggest try following my > instructions straight and making sure that it actually works before > trying again with a different version. > > - -- > ┌─── dg@cowlark.com ───── http://www.cowlark.com ───── > │ > │ "Sufficiently advanced incompetence is indistinguishable from > │ malice." -- Vernon Schryver > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAktBEqwACgkQf9E0noFvlzh/pwCg0RXqBRzLpjfYVVvgQMU/mD3n > OlUAn0ztnENNHxsT80aO3I4YUym6vWR/ > =TGcI > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Prex-devel mailing list > Pre...@li... > https://lists.sourceforge.net/lists/listinfo/prex-devel |