2012-05-28T01:54:03 *** xiangfu has quit IRC (Ping timeout: 256 seconds) 2012-05-28T02:02:46 *** xiangfu has joined #rtems 2012-05-28T05:52:39 *** QingPei has joined #rtems 2012-05-28T06:06:48 *** panzon has quit IRC (Ping timeout: 256 seconds) 2012-05-28T06:19:03 *** panzon has joined #rtems 2012-05-28T06:20:44 *** xiangfu has quit IRC (Remote host closed the connection) 2012-05-28T08:05:42 *** weiY has joined #rtems 2012-05-28T08:45:41 *** cdcs has joined #rtems 2012-05-28T09:02:38 *** weiY has quit IRC (Ping timeout: 240 seconds) 2012-05-28T09:28:04 *** arvind_khadri has quit IRC (Remote host closed the connection) 2012-05-28T09:30:22 *** arvind_khadri has joined #rtems 2012-05-28T09:37:55 *** Hesham has joined #rtems 2012-05-28T09:52:21 *** arvind_khadri has quit IRC (Quit: Leaving) 2012-05-28T10:02:07 *** weiY has joined #rtems 2012-05-28T10:17:41 *** Hesham has quit IRC (Quit: Leaving.) 2012-05-28T10:25:34 *** A0Sheds has quit IRC (Quit: puff of smoke) 2012-05-28T10:28:39 *** A0Sheds has joined #rtems 2012-05-28T10:53:13 Hi all, where are the basic date types are defined for architecture-independent(which file), like uint32_t 2012-05-28T11:05:03 *** QingPei has quit IRC (Ping timeout: 245 seconds) 2012-05-28T11:14:33 *** weiY has quit IRC (Ping timeout: 244 seconds) 2012-05-28T11:14:54 stdint.h? 2012-05-28T11:39:18 *** QingPei has joined #rtems 2012-05-28T12:17:49 *** Hesham has joined #rtems 2012-05-28T12:23:15 *** QingPei has left #rtems 2012-05-28T12:59:55 *** cdcs has quit IRC (Quit: Page closed) 2012-05-28T14:15:44 *** Hesham has quit IRC (Quit: Leaving.) 2012-05-28T14:16:01 *** Hesham has joined #rtems 2012-05-28T15:17:07 *** Hesham has quit IRC (Ping timeout: 245 seconds) 2012-05-28T15:20:26 *** Hesham has joined #rtems 2012-05-28T16:21:31 *** Hesham has quit IRC (Quit: Leaving.) 2012-05-28T16:35:03 *** Hesham has joined #rtems 2012-05-28T17:21:42 *** Hesham has quit IRC (Quit: Leaving.) 2012-05-28T20:16:59 *** xiangfu has joined #rtems 2012-05-28T23:35:08 *** QingPei has joined #rtems 2012-05-29T00:34:08 *** xiangfu has quit IRC (Ping timeout: 246 seconds) 2012-05-29T00:52:50 *** xiangfu has joined #rtems 2012-05-29T01:34:09 *** alseh has joined #rtems 2012-05-29T03:13:02 *** xiangfu has quit IRC (Ping timeout: 246 seconds) 2012-05-29T03:25:53 *** xiangfu has joined #rtems 2012-05-29T03:42:43 *** Hesham has joined #rtems 2012-05-29T03:55:50 *** Hesham has quit IRC (Quit: Leaving.) 2012-05-29T03:57:15 *** QingPei has left #rtems 2012-05-29T04:40:07 *** xiangfu has quit IRC (Ping timeout: 260 seconds) 2012-05-29T04:44:39 *** xiangfu has joined #rtems 2012-05-29T05:58:11 *** tuxmaniac has quit IRC (Remote host closed the connection) 2012-05-29T07:36:30 *** Hesham has joined #rtems 2012-05-29T07:42:37 *** weiY has joined #rtems 2012-05-29T07:55:00 *** QingPei has joined #rtems 2012-05-29T08:01:49 *** kuzew has quit IRC (Read error: Connection reset by peer) 2012-05-29T08:02:23 *** kuzew has joined #rtems 2012-05-29T08:10:26 *** Hesham has quit IRC (Quit: Leaving.) 2012-05-29T09:21:37 *** Hesham has joined #rtems 2012-05-29T09:38:11 *** Hesham has quit IRC (Quit: Leaving.) 2012-05-29T09:40:50 *** xiangfu has quit IRC (Ping timeout: 246 seconds) 2012-05-29T09:46:40 *** shineworld has joined #rtems 2012-05-29T09:50:01 *** shineworld has quit IRC (Read error: Connection reset by peer) 2012-05-29T11:07:45 *** weiY has quit IRC () 2012-05-29T12:17:00 *** Hesham has joined #rtems 2012-05-29T13:23:15 *** QingPei has left #rtems 2012-05-29T13:54:40 *** antgreen has joined #rtems 2012-05-29T14:11:08 *** Hesham has quit IRC (Quit: Leaving.) 2012-05-29T14:34:12 *** Hesham has joined #rtems 2012-05-29T14:47:53 *** Hesham has quit IRC (Quit: Leaving.) 2012-05-29T15:06:18 *** Hesham has joined #rtems 2012-05-29T15:45:12 *** Hesham has quit IRC (Quit: Leaving.) 2012-05-29T15:47:24 *** Hesham has joined #rtems 2012-05-29T15:49:25 *** Hesham has quit IRC (Client Quit) 2012-05-29T16:11:24 *** antgreen has quit IRC (Remote host closed the connection) 2012-05-29T16:49:03 *** alseh has quit IRC (Quit: Leaving) 2012-05-29T16:55:36 *** Hesham has joined #rtems 2012-05-29T17:17:47 *** Hesham has quit IRC (Quit: Leaving.) 2012-05-29T17:53:55 *** Hesham has joined #rtems 2012-05-29T18:10:52 *** Hesham has quit IRC (Quit: Leaving.) 2012-05-29T20:03:02 *** xiangfu has joined #rtems 2012-05-29T22:10:52 *** QingPei has joined #rtems 2012-05-29T23:55:32 *** xiangfu has quit IRC (Ping timeout: 246 seconds) 2012-05-30T01:33:59 *** sebhub has joined #rtems 2012-05-30T01:34:03 good morning 2012-05-30T02:30:52 *** xiangfu has joined #rtems 2012-05-30T04:03:40 *** QingPei has left #rtems 2012-05-30T04:26:40 moorning 2012-05-30T07:17:32 *** weiY has joined #rtems 2012-05-30T07:22:44 *** QingPei has joined #rtems 2012-05-30T08:54:14 Hi sebhub. good night. are you here? 2012-05-30T09:04:15 *** xiangfu has quit IRC (Read error: Connection reset by peer) 2012-05-30T10:11:20 *** weiY has quit IRC (Ping timeout: 252 seconds) 2012-05-30T10:44:45 *** arvind_khadri has joined #rtems 2012-05-30T10:44:45 *** arvind_khadri has joined #rtems 2012-05-30T10:49:09 *** sebhub has quit IRC (Ping timeout: 248 seconds) 2012-05-30T11:32:57 *** arvind_khadri has quit IRC (Ping timeout: 245 seconds) 2012-05-30T13:05:16 *** cdcs has joined #rtems 2012-05-30T13:14:48 *** QingPei has left #rtems 2012-05-30T13:20:57 *** cdcs has quit IRC (Quit: Page closed) 2012-05-30T15:22:24 *** DrJoel has joined #rtems 2012-05-30T15:22:24 *** DrJoel has quit IRC (Changing host) 2012-05-30T15:22:24 *** DrJoel has joined #rtems 2012-05-30T15:22:24 *** ChanServ sets mode: +o DrJoel 2012-05-30T18:22:18 *** DrJoel has quit IRC (Quit: Leaving) 2012-05-30T22:52:51 *** Deb has joined #rtems 2012-05-30T23:15:27 *** hiddenpearls1 has joined #rtems 2012-05-30T23:27:28 *** arvind_khadri has joined #rtems 2012-05-31T00:34:17 *** Deb has left #rtems ("Leaving") 2012-05-31T00:40:20 *** hiddenpearls has joined #rtems 2012-05-31T00:41:10 *** hiddenpearls1 has quit IRC (Ping timeout: 250 seconds) 2012-05-31T01:15:10 *** sebhub has joined #rtems 2012-05-31T01:19:37 good morning 2012-05-31T02:42:34 *** hiddenpearls1 has joined #rtems 2012-05-31T02:42:39 *** hiddenpearls has quit IRC (Ping timeout: 245 seconds) 2012-05-31T02:52:39 *** alseh has joined #rtems 2012-05-31T03:10:27 *** alseh has quit IRC (Remote host closed the connection) 2012-05-31T03:13:10 *** alseh has joined #rtems 2012-05-31T03:14:00 *** alseh has joined #rtems 2012-05-31T03:30:18 *** hiddenpearls1 has quit IRC (Quit: Leaving.) 2012-05-31T03:49:56 *** arvind_khadri has quit IRC (Ping timeout: 246 seconds) 2012-05-31T03:53:38 *** alseh has quit IRC (Ping timeout: 240 seconds) 2012-05-31T03:53:46 *** cdcs has joined #rtems 2012-05-31T03:57:37 *** hiddenpearls has joined #rtems 2012-05-31T05:18:10 *** ziemke has joined #rtems 2012-05-31T06:53:30 *** Deb has joined #rtems 2012-05-31T07:13:38 *** Deb has quit IRC (Quit: Leaving) 2012-05-31T07:13:42 *** juli1- has joined #rtems 2012-05-31T07:18:14 *** xiangfu has joined #rtems 2012-05-31T07:18:53 *** alseh has joined #rtems 2012-05-31T07:19:14 *** weiY has joined #rtems 2012-05-31T07:25:04 *** alseh has quit IRC (Remote host closed the connection) 2012-05-31T07:42:09 *** zw_yao has joined #rtems 2012-05-31T08:05:31 good night 2012-05-31T08:10:22 *** xiangfu has quit IRC (Quit: Leaving) 2012-05-31T08:22:53 *** hiddenpearls has quit IRC (Quit: Leaving.) 2012-05-31T08:24:09 *** QingPei has joined #rtems 2012-05-31T08:25:51 *** hiddenpearls has joined #rtems 2012-05-31T08:27:07 *** hiddenpearls has joined #rtems 2012-05-31T08:28:12 *** hiddenpearls has joined #rtems 2012-05-31T08:34:38 *** jennifer has joined #rtems 2012-05-31T08:42:21 weiY, Good night 2012-05-31T08:44:39 *** DrJoel has joined #rtems 2012-05-31T08:44:39 *** ChanServ sets mode: +o DrJoel 2012-05-31T08:50:16 zw_yao, good night 2012-05-31T08:50:23 are you from china? 2012-05-31T08:50:38 yeah... 2012-05-31T08:50:51 what is your project? 2012-05-31T08:50:58 my project is atomic for rtems 2012-05-31T08:51:08 the POSIX key project 2012-05-31T08:51:40 ao, how about your project go on? 2012-05-31T08:52:20 I've read some discussion on the list about your project:) 2012-05-31T08:52:24 i just submitted a little code to github, github is really useful and good for us 2012-05-31T08:52:50 Yeah, github is great. 2012-05-31T08:53:00 hah, my progress is a little slow. 2012-05-31T08:53:30 I haven't commit any code until now, I think mine is slower... 2012-05-31T08:54:30 you can little by little to commit, do not mind and just submit code is ok 2012-05-31T08:54:44 what's your workflow of git? I'm not familiar with git yet. 2012-05-31T08:55:51 i just fork a rtems repository on the github. and in my local computer i git clone the repository then modify the code, git commit and git push 2012-05-31T08:56:22 if the code is ok then push the patch to merge to the upstream 2012-05-31T08:56:44 there are so many manual in the web to learn the git 2012-05-31T08:57:54 git is easy to use 2012-05-31T08:58:15 I'm a little confused about git branch, say if several branches are created locally, and all of them aren't ready to merge to master, what can I do if I want to back my work on github? 2012-05-31T08:59:40 Yeah, git is interesting to use, I've read some tutorial, but still haven't figour out what to do with the problem above. 2012-05-31T08:59:56 git push origin your_local_branch_name:other_name_you_want 2012-05-31T09:00:34 git push origin atomic:atomic will push the atomic branch to github 2012-05-31T09:00:53 cdcs, will this operation merge the local branch to the remote origin? 2012-05-31T09:01:01 in the github the repository can also have many branches, in your local computer you can make one branch associate with the github branch 2012-05-31T09:01:23 or this operation will create a branch on the github? 2012-05-31T09:01:57 zw_yao, no it will just create an "atomic" branch in your github repo with the contents of your local "atomic" branch 2012-05-31T09:02:17 your master branch in github will stay untouchet 2012-05-31T09:02:18 yeah, if you want to create a branch on the github, you can also use git push to implement 2012-05-31T09:02:36 cdcs, thanks, I'll try it right now:) 2012-05-31T09:02:44 *untouched 2012-05-31T09:03:26 weiY, thanks, I'm trying it:) 2012-05-31T09:03:41 * DrJoel is just now becoming effective with git 2012-05-31T09:03:50 and by effective I mean not destroying > 50% of what I touch 2012-05-31T09:03:53 you can also delete remote branches by doing "git push origin :branch_you_want_to_delete" 2012-05-31T09:04:16 you must know which branch in your local computer is associated with the github branch which named umstream remote branch 2012-05-31T09:04:16 hah, you are welcome 2012-05-31T09:04:20 yeah, this command is dangers 2012-05-31T09:04:45 DrJoel, LOL 2012-05-31T09:04:54 dangerous 2012-05-31T09:05:40 Hi joel, are you free now. recently i am confuesd about the atomic API design 2012-05-31T09:05:57 re 2012-05-31T09:06:10 DrJoel: the meeting begins in one hour, right ? 2012-05-31T09:06:37 juli1, yes. it does 2012-05-31T09:06:51 great 2012-05-31T09:07:43 in order to improve the performence the atomic implementations should be implemented using inline embedded assemble code 2012-05-31T09:08:38 * DrJoel agrees on inline assembly. UNLESS you are using something that gcc knows as an intrinsic on that architecture. Then you might as well use the gcc intrinsic. 2012-05-31T09:09:14 and i think a .h files is enough to implement all the atomic operations 2012-05-31T09:11:31 so if i include the implementation .h file to the API definition .h file there will be conflicted 2012-05-31T09:12:42 the API definition will be redundant because implementation also contains the api definitions 2012-05-31T09:15:53 or in the API definition .h file we just include the implementation .h file 2012-05-31T09:27:20 *** hiddenpearls has quit IRC (Ping timeout: 246 seconds) 2012-05-31T09:27:35 *** hiddenpearls has joined #rtems 2012-05-31T09:46:15 *** hiddenpearls has quit IRC (Quit: Leaving.) 2012-05-31T09:50:47 http://goo.gl/9n5kx is the status report this week 2012-05-31T09:54:03 *** ziemke has quit IRC (Quit: Verlassend) 2012-05-31T09:54:07 *** ziemke has joined #rtems 2012-05-31T09:55:01 *** claas_ziemke has joined #rtems 2012-05-31T09:57:45 *** ppisa has joined #rtems 2012-05-31T09:57:48 *** WikL has joined #rtems 2012-05-31T09:59:02 ok.. close enough .. who wants to go first? 2012-05-31T09:59:21 http://goo.gl/9n5kx is the status report this week 2012-05-31T09:59:29 I can 2012-05-31T09:59:43 ok.. good news? challenges ahead? 2012-05-31T09:59:59 me can next 2012-05-31T10:00:36 as I wrote in the progress report, I think I know enough about the project now 2012-05-31T10:00:49 I was vague about some of the concepts but that's cleared up 2012-05-31T10:01:17 I think I know how to proceed with the implementation 2012-05-31T10:01:20 *** soh_cah_toa has joined #rtems 2012-05-31T10:01:44 but right now the compilation and linking process is the nearest challenge 2012-05-31T10:02:20 I expect the virtualized BSPs will be similar to some of the BSPs for simulators in that they rely on traps for many actions 2012-05-31T10:02:41 Anything we can do to help.. I am sure the Pok community is helping 2012-05-31T10:03:15 *** Hesham has joined #rtems 2012-05-31T10:03:27 I will have to dig a bit into the Makefiles for both Pok and RTEMS 2012-05-31T10:03:41 ok.. ask questions as you need to. 2012-05-31T10:03:45 I've never been good with these 2012-05-31T10:03:56 :) Magic and more magic :) 2012-05-31T10:04:13 I will 2012-05-31T10:04:16 think of a tree of dependencies and that's what every build system is representing 2012-05-31T10:04:32 I have an 11am meeting so let's move on to weiY 2012-05-31T10:04:42 ok 2012-05-31T10:05:23 now i have commit two file atomic.h which is atomic API definition file and atomic_cpu.h whichi is implementations file to github 2012-05-31T10:05:51 and for each architecture, we will need an atomic_cpu.h? 2012-05-31T10:05:57 but now i have some confuesd question about where place the atomic API definition to 2012-05-31T10:06:17 yeah, each architecture need an atomic_cpu.h 2012-05-31T10:06:49 *** RayX has joined #rtems 2012-05-31T10:06:50 the file name can be fixed or not fixed but should be included in cpu.h or other file in cpu 2012-05-31T10:07:28 There are possibly going to be 3 levels: 2012-05-31T10:07:33 + CPU porting 2012-05-31T10:07:46 + score for internal RTEMS use 2012-05-31T10:08:05 + rtems_ wrapper with more error checking for application use (if desired) 2012-05-31T10:08:29 the first two levels i can understand. 2012-05-31T10:08:36 when is the meeting today? 2012-05-31T10:08:42 verm__, now 2012-05-31T10:08:42 now ;-) 2012-05-31T10:08:55 DOH, i'm about to walk out the door dammit 2012-05-31T10:09:10 the last level do you mean it is above the atomic operation which is wrappered 2012-05-31T10:09:23 The User API level is when you have internal services that make sense to use in applications.. like SuperCore Chain and rtems_chain 2012-05-31T10:09:30 there is no status update for the testing project this week, xiaochen is traveling and will not be back until the 2nd 2012-05-31T10:09:32 yes .. exactly.. if it makes sense to do that in this case 2012-05-31T10:09:37 thanks verm 2012-05-31T10:09:54 *** juli1 has joined #rtems 2012-05-31T10:09:54 i will edit the google document accordingly when i return this evening 2012-05-31T10:10:16 ok, this level we can take it into consider next step 2012-05-31T10:10:20 (hi, sorry, I have some network issues for connecting) 2012-05-31T10:10:54 about the level one and level two, now it seems not so clearly 2012-05-31T10:11:09 weiY, more important to get bottom two layers defined first. User API is relatively easy once you have lower levels and only needed if you and mentor see it needed in applciation space 2012-05-31T10:11:14 The meeting started 10 minutes ago right ? 2012-05-31T10:11:18 yep 2012-05-31T10:11:19 because most of atomic implementations are static inline embedded assemble code 2012-05-31T10:12:02 So it is enough to implement in a .h file 2012-05-31T10:12:10 right.. atomic_cpu.h. :) 2012-05-31T10:12:34 anything we can do or are you on track? 2012-05-31T10:12:42 and if the API definition .h file included atomic_cpu.h , there should be no other things 2012-05-31T10:13:07 i mean the API definition can be defined in the atomic_cpu.h 2012-05-31T10:13:30 and atomic.h just include the atomic_cpu.h directly 2012-05-31T10:13:42 Depends.. the convention has been to note things which are CPU specific by prefixing them with _CPU_ and them renaming or wrapping them in a non-CPU specific layer. 2012-05-31T10:14:15 You could prototype all atomic operations in atomic.h and implement them in atomic_cpu.h. Using static inline methods, this would ensure the CPU ports do the right thing 2012-05-31T10:14:32 The cache.h implementation is something like this 2012-05-31T10:14:50 the cache.h is not a good example 2012-05-31T10:15:01 In my first proposal i just do like thing. 2012-05-31T10:15:30 ok.. sebhub 2012-05-31T10:15:52 weiY, anything else? 2012-05-31T10:16:18 But later i think there are two symbols which indicate the same things 2012-05-31T10:16:28 so i change my idea 2012-05-31T10:16:29 (I can be next) 2012-05-31T10:16:33 *** gedare has joined #rtems 2012-05-31T10:16:59 zw_yao, how are things going? 2012-05-31T10:17:10 i have commit my code to github. if any mentors have time you can give me some comments 2012-05-31T10:17:27 thank you 2012-05-31T10:17:28 Did you post to rtems-devel with a link asking for review? 2012-05-31T10:17:36 yeah 2012-05-31T10:18:13 I've decide to work on the easy approach first(the approach 1 in my design summary) 2012-05-31T10:18:43 That's usually best. Do the simplest solution, evaluate it, and then you understand the problem space. 2012-05-31T10:18:54 Which approach is the most easy one. 2012-05-31T10:19:11 Offhand, I don't know.. it is your project. :) 2012-05-31T10:19:45 Yeah, I'm follow this idea. 2012-05-31T10:20:16 :) I see. and I haven't done any commit yet. 2012-05-31T10:20:52 zw_yao, If nothing else, build a shell of the solution with the desired operations, empty data structures, and weave that into the keyu code. Then plugin in your data structures. 2012-05-31T10:21:09 The first, it worth to have some idea, what is typical and maximal count of posix keys for reasonable size applications. 2012-05-31T10:21:29 I plan to implement the approach next week, and evaluate it. 2012-05-31T10:22:00 Should we have assumption on the number of posix keys? 2012-05-31T10:22:10 The use cases I know are for libraries like the Ada run-time where every Ada task is a POSIX thread with a key for "self" 2012-05-31T10:22:23 similar uses in other libraries for their per thread data 2012-05-31T10:23:14 Have we some idea, what is maximal count of ADA tasks used on some RTEMS sytem? 2012-05-31T10:23:16 newlib has its reent structure which is tied to each thread. Coudl easily be a key 2012-05-31T10:23:51 I have no idea but I would personally be surprised if any system of any type had more than 256 tasks and 1-3 libraries using keys 2012-05-31T10:24:06 OK, but it is one key spread over all RTEMS tasks with task specific data, are not? 2012-05-31T10:24:56 Yes that is correct. A single key could have values for every thread. And since thread ids are unique that would be the most logical value to "index" or "search" on 2012-05-31T10:24:57 one key could be used by all tasks. 2012-05-31T10:25:49 So basically we speak about 10 to 20 keys for max 256 tasks. 2012-05-31T10:25:59 and that is the expected use case. A library would have a single key to hold a pointer to some per thread context information. Then every thread using that library would have a value in the key (e.g. a key slot in my terminology) 2012-05-31T10:26:29 practically speaking .. yes ppisa .. It would be a huge system to do more than that. 2012-05-31T10:26:43 many many libraries needing per thread context.. and LOTS of tasks using those libraries :) 2012-05-31T10:26:51 So my proposal is one RBtree per task. 2012-05-31T10:27:32 The rub is that you have to clean up with either (1) a key is deleted or (2) a thread is deleted 2012-05-31T10:28:05 Hmm, 2012-05-31T10:28:14 That would minimize entries but you have a way to find all clean up on case (1) 2012-05-31T10:28:51 Then the values for same key can be interconnected by doublelinked list. 2012-05-31T10:28:54 I think it requires two structures .. one in the key and one in the thread. Key could be just a list of threads with active key values. Thread owns the rbtree of key values in existence 2012-05-31T10:29:04 If you delete key, iterate that list. 2012-05-31T10:29:18 If you delete thread, clean up the rbtree and remove from each key's list 2012-05-31T10:29:30 list removal/insertion is all but free. 2012-05-31T10:29:49 i think it's simpler to use one rbtree. 2012-05-31T10:30:07 Probably the best, bad is need for global lock for all bidir lists. 2012-05-31T10:30:10 one rbtree owned by ...? 2012-05-31T10:30:13 with a (thread, key) key? 2012-05-31T10:30:18 ya 2012-05-31T10:30:53 this reduces the per thread storage 2012-05-31T10:30:58 not sure if ownership is relevant, set it up with key initialization in posix manager 2012-05-31T10:31:24 One tree has trouble with locking when thread access value. Or option is use of IBM's RCU. 2012-05-31T10:31:27 The one rbtree of all key and key value is good candidator, but I think the memory usage should be evaluated. 2012-05-31T10:31:30 Is that easy to clean up in either case? 2012-05-31T10:32:11 You only need to allocate an entry when the first key set is done for a thread. When no entries, it is assumed to be null. 2012-05-31T10:32:49 we should probably discuss this more on the ml 2012-05-31T10:33:05 or set a meeting for it :) 2012-05-31T10:33:05 But remember allocating memory from the workspace is a different lock than thread disable dispatch. Some caution is in order 2012-05-31T10:33:13 +1 to gedare 2012-05-31T10:34:06 zw_yao, setup an IRC meeting to discuss this 2012-05-31T10:34:13 OK, and I'll do the trivial approach first, and gather more question, and then evaluate it. 2012-05-31T10:34:49 Can we just discuss it on mail list? 2012-05-31T10:34:50 If it was an easy problem, it would have been fixed by now :) 2012-05-31T10:34:52 that would be good. address how to solve the cases raised by drjoel 2012-05-31T10:34:58 sure. that would work 2012-05-31T10:35:13 the issues are thread/key deletion and memory allocation/deallocation 2012-05-31T10:35:41 one rbtree would be an interesting simple approach .. 2012-05-31T10:36:23 evaluate placement in key and thread and see how it holds up under the set, get, key delete, and thread delete scenarios. 2012-05-31T10:36:29 who's next? 2012-05-31T10:36:53 me if nobody else wants go first? :-) 2012-05-31T10:37:00 go ahead 2012-05-31T10:37:09 ok... 2012-05-31T10:37:13 yeah, I see. 2012-05-31T10:37:14 I'll discuss more about this on ml, do a small summary of all question here. 2012-05-31T10:37:17 so first what i did last week... 2012-05-31T10:37:22 go ahead. I finished. 2012-05-31T10:37:40 i brached a "beagle" branch from origin/master 2012-05-31T10:38:04 i copied the lpc32xx folder to beagle folder and renamed everything accordingly 2012-05-31T10:38:19 i adapted the linkcmds to include armv7 instead of armv4 2012-05-31T10:38:47 i altered the makefile to compile with /mcpu=cortex-a8 instead of arm926ej 2012-05-31T10:39:05 i tried that out with qemu+gdb 2012-05-31T10:39:24 and it ran the first time? ;) 2012-05-31T10:39:42 ha 2012-05-31T10:39:46 apparently it boots up until the inittask but then jumps back into boot_card... then i get a “Trying to execute code outside of RAM and ROM at 0x40210000” 2012-05-31T10:39:55 nope for sure not :-) 2012-05-31T10:40:23 if it would have i would give back my money to google and would say, sorry that was too easy :-) 2012-05-31T10:40:43 Check the memory map of the board versus your linkcmds. 2012-05-31T10:40:53 also i read more documentation aboput linker scripts and memory layout... 2012-05-31T10:41:09 thats what i suspect to be the evil detail... 2012-05-31T10:41:10 Turn on debug in bspgetworkarea.c and see what it allocates. That will force you to get the polling console IO working but is worth it. 2012-05-31T10:41:30 also the RTEMS linkcmds are extremely obfuscated for a n00b like me... 2012-05-31T10:41:33 The debug in that file checks for some common mistakes. 2012-05-31T10:41:46 Don't blame those on RTEMS.. those are GNU ld's fault :) 2012-05-31T10:41:46 http://www.math.utah.edu/docs/info/ld_3.html 2012-05-31T10:41:47 ok thx for the hint, how do i do that? 2012-05-31T10:41:52 read that 2012-05-31T10:42:02 There is a commented out #define in that file. 2012-05-31T10:42:06 gedare thx 2012-05-31T10:42:17 ok... i will try that 2012-05-31T10:42:28 the arm linkcmds are pretty well structured 2012-05-31T10:42:35 arm linkcmds use some variables to pass info to the shared core 2012-05-31T10:42:41 those variables will define the memory map of the bsp 2012-05-31T10:42:49 You can also step through that routine and see what addresses it is giving you and compare them to the information in the "num" numerically sorted symbol table. 2012-05-31T10:42:52 so if you did not modify them, the memory map will be wrong 2012-05-31T10:43:00 at least i think i made some good progress because i also learned how to use DDD and have some very nice symbolic remote debugging cappabiliy :-) 2012-05-31T10:43:10 ok 2012-05-31T10:43:12 And that is deadly during initialization and usually a weird failure 2012-05-31T10:43:32 the one other issue i can think of is that a spurious interrupt could be causing a problem also 2012-05-31T10:43:38 but linkcmds seems like a likely problem 2012-05-31T10:43:53 gedare and joel i suspected that... will see if that might be fixed next week... 2012-05-31T10:44:30 i disabled interrupts with rtems_disable_interrupts but it didnt help... so my guess is the memory map 2012-05-31T10:44:41 Make sure interrupts are disabled. There should be no maskable interrupts on during initialization 2012-05-31T10:44:56 you only have to provide the memory map in a file like this: http://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/lpc32xx/startup/linkcmds.lpc32xx_phycore 2012-05-31T10:45:08 don't touch the linkcmds.base 2012-05-31T10:45:18 the mcpu seems to be right now, before fixing that i alwazs got a bad mode when the start.S wrote something iin the CSPR 2012-05-31T10:45:32 and check with objdump -h that you actually have the right mapping 2012-05-31T10:45:38 nono i wont... i only touch anything what is in the beagle folder 2012-05-31T10:46:07 ok 2012-05-31T10:46:23 Getting the memory layout right is critical. 2012-05-31T10:46:53 also make sure that you load the sections if lma != vma 2012-05-31T10:47:10 ok 2012-05-31T10:47:42 do you have the code on github? 2012-05-31T10:48:13 not yet... i was way too crappy to submit, but i will push it this evening... 2012-05-31T10:48:39 All BSPs look like crap in the beginning. They are broken :) 2012-05-31T10:48:41 also can u tell me what files i can clean out to get a more minimal set of files in my pseudo bsp? 2012-05-31T10:49:10 i can look at the stuff once it is on github 2012-05-31T10:49:14 because i see that the lpc32xx is one of the bsp with more files than others... 2012-05-31T10:49:48 you only need the startup, a clock driver and a console driver 2012-05-31T10:50:31 sebhub thx i already told ray that i will write an emai to the mailing list in order to help you setting up the same testing environmet as i have so you can reproduce my failure :-) 2012-05-31T10:50:36 ok 2012-05-31T10:50:45 so i can safely delete the rest? 2012-05-31T10:50:56 yes 2012-05-31T10:51:18 just update the Makefile.am :) 2012-05-31T10:51:31 sure... ok, i think thats all on what i did... let us go on with what i will do next... 2012-05-31T10:51:48 first of all i will try out your hints... 2012-05-31T10:52:11 also as mentioned pushing to github and writing a howto recreat the setup 2012-05-31T10:52:31 *** WikL has quit IRC () 2012-05-31T10:52:44 then learn more about memory maps, linker scripts and overall rtems boot procedure 2012-05-31T10:52:56 claas_ziemke, the smallest BSP in ARM is the one for the simulator in gdb. It does not support interrupts and has a very minimal startup, console, etc. That should give you a feel for a minimal (but not on real HW) BSP 2012-05-31T10:52:59 then fix the supposed memmap problem 2012-05-31T10:53:07 ok thx for the hint 2012-05-31T10:53:19 It only has 8 *.[chS] files :) 2012-05-31T10:53:29 and it runs using the gdb you already have. 2012-05-31T10:53:58 then write a printk, i already have a working bare metal c program which is talking to uart, so that should be (quite) easy, btw. where is the printk routine implemented? 2012-05-31T10:54:52 you don't implement printk, you only implement the output routines. See the code related to console 2012-05-31T10:55:12 http://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/stm32f4/console 2012-05-31T10:55:18 ok got that... so where will i put that and where is the aPI for that documented? 2012-05-31T10:55:23 sebhub thx 2012-05-31T10:55:56 will read that... 2012-05-31T10:55:57 claas_ziemke, the magic is that you are just providing plugin code into a driver framework. Small routines to write and table entries 2012-05-31T10:56:19 I have another meeting in 4 minutes 2012-05-31T10:56:26 yeah i thought that... but i didnt find any docu about that "framework" :-) 2012-05-31T10:56:31 Who is left? Can gedare or sebhub lead the rest 2012-05-31T10:56:33 ok... i will go quick... 2012-05-31T10:56:39 i'm here 2012-05-31T10:56:46 me too 2012-05-31T10:56:47 I think POK related stuff 2012-05-31T10:56:48 :D 2012-05-31T10:56:59 claas_ziemke, There is a BSP and Device Drivers Manual which (if lucky) might be up to date enough. 2012-05-31T10:57:02 juli1: is your student here? 2012-05-31T10:57:05 I also have some slides which might help 2012-05-31T10:57:09 when i have a working printk i will annonce that on the dev ml and file a ull request... thats all 2012-05-31T10:57:17 he was gedare 2012-05-31T10:57:19 DrJoel: dragging your feet will get you out of meetings fast :) 2012-05-31T10:57:25 or slow.. 2012-05-31T10:57:32 gedare: yes, I think 2012-05-31T10:57:45 i think i saw him drop. OK 2012-05-31T10:57:46 i am finished if u dont have any questions anymore... 2012-05-31T10:57:48 gedare: oh no, I quit 5 minutes ago ! 2012-05-31T10:57:49 let's start with soh_cah_toa 2012-05-31T10:57:52 soh_cah_toa: what is your status 2012-05-31T10:57:58 thanks claas_ziemke 2012-05-31T10:58:41 i updated it last night on the google docs. though i think i have a different problem 2012-05-31T10:58:51 i was compiled libbsd for powerpc psim 2012-05-31T10:58:56 *compiling 2012-05-31T10:59:21 and when running the testsuite, received a failure for link01 saying that it couldn't find freebsd/bsd.h 2012-05-31T10:59:41 *** RayX has quit IRC (Quit: ChatZilla 0.9.88.2 [Firefox 14.0a2/20120530042008]) 2012-05-31T10:59:44 despite its obvious existense 2012-05-31T10:59:46 you'll have to submit a report to rtems-devel stating the steps you took to bootstrap, configure, and build 2012-05-31T10:59:53 is the file in your build tree 2012-05-31T10:59:57 yup, i see it 2012-05-31T11:00:01 but... 2012-05-31T11:00:08 Did you do a make install on rtems-libbsd? 2012-05-31T11:00:10 e.g. located at .... powerpc-rtems4.11/psim/lib/include/freebsd/bsd.h 2012-05-31T11:00:13 yes 2012-05-31T11:00:27 Did you changed the config.inc to point to it properly in rtems-libbsd? 2012-05-31T11:01:05 yes 2012-05-31T11:01:10 i did a clean build; removing b-psim and bsp-install and everyhgin and starting all over. now i received an error about rtems_filesystem_location_info_t missing an 'ops' member 2012-05-31T11:01:17 install/include/freebsd/bsd.h for me actually .. it is part of rtems-libbsd 2012-05-31T11:01:34 You need to update the rtems tree 2012-05-31T11:01:43 Your RTEMS source and rtems-libbsd are out of sync.. one or both needs updating :) 2012-05-31T11:01:52 ah 2012-05-31T11:02:07 ok. any other major issues? know what you are doing next? 2012-05-31T11:02:11 so just do a git pull --rebase on each? 2012-05-31T11:02:13 i haven't seen too much on the ml from you yet :) 2012-05-31T11:02:26 that should probably work 2012-05-31T11:02:32 nope, it's just those errors preventing me from running the tests 2012-05-31T11:02:43 depending on how out-of-sync your rtems/ is you may also need to update tools too 2012-05-31T11:02:49 if that fixes it, i can move ahead w/ other archs 2012-05-31T11:02:54 and remember to do things clean from the pull 2012-05-31T11:02:58 yes 2012-05-31T11:03:01 ok 2012-05-31T11:03:27 anything else? 2012-05-31T11:03:49 nope, that's about it :) 2012-05-31T11:03:54 working on it now 2012-05-31T11:03:59 all right. next up Hesham 2012-05-31T11:04:07 i am here 2012-05-31T11:04:09 ok soh_cah_toa feel free to report to the ml also 2012-05-31T11:04:13 Hesham: what is your status 2012-05-31T11:04:50 i've just created libarena.h file and posted it to ml and i got a feedback on my previous design about Arena 2012-05-31T11:05:12 waiting to discuss about how can we make use of this feedback 2012-05-31T11:05:14 on the other hand 2012-05-31T11:05:25 i have merged all libmmu code 2012-05-31T11:05:54 and edited Makefiles/configure 2012-05-31T11:06:14 did you get it to run for psim? 2012-05-31T11:06:26 to be able to run test suites for mmu project 2012-05-31T11:06:35 the test-suite no 2012-05-31T11:06:56 but psim just worked fine with hello.exe 2012-05-31T11:07:02 i have to go to bed, byb 2012-05-31T11:07:18 bye weiY 2012-05-31T11:07:44 i investigated a little why mmutests1( which is the test case ) does not work 2012-05-31T11:08:05 i found the error at the Makefile in libmmu 2012-05-31T11:08:08 ok Hesham you should try to get the test case to run. you may need to revert to some older version too. we can discuss it offline 2012-05-31T11:08:30 i think the problem is not with new updates 2012-05-31T11:08:47 ok 2012-05-31T11:09:13 The error is when compiling init.c in mmutest1 is that it can not find mmu_support.c 2012-05-31T11:09:17 .h ** 2012-05-31T11:09:44 i see. that seems like a broken dependency 2012-05-31T11:09:50 which is at libcpu/powepc/mmu 2012-05-31T11:10:30 what are you working on next? 2012-05-31T11:10:32 but this file is already exists in that directory ! 2012-05-31T11:10:50 *** claas_ziemke has quit IRC (Quit: Verlassend) 2012-05-31T11:11:17 *** weiY has quit IRC (Ping timeout: 246 seconds) 2012-05-31T11:11:35 well, next i wanna discuss about how we would make use of the feedback on ml , and after that i could begin implementation of libarena.c 2012-05-31T11:11:40 i have to leave in 10 minutes 2012-05-31T11:12:00 ok. Hesham how about if you and i discuss some of this in more detail after this meeting? 2012-05-31T11:12:11 i have a little bit of time today, not a lot but enough to plow through :) 2012-05-31T11:12:13 that will be good 2012-05-31T11:12:14 ok 2012-05-31T11:12:22 any other students have to go still? 2012-05-31T11:12:30 i haven't seen WikL come back yet 2012-05-31T11:12:51 he was the first i think :) 2012-05-31T11:13:01 yeah 2012-05-31T11:13:17 oh.. i thought juli1 said he still had to go 2012-05-31T11:13:21 anyway he is not here 2012-05-31T11:13:26 so meeting adjourned 2012-05-31T11:13:35 sounds good then 2012-05-31T11:13:39 all students please update the gdob 2012-05-31T11:13:39 gdoc 2012-05-31T11:13:41 with your status 2012-05-31T11:14:03 http://goo.gl/9n5kx 2012-05-31T11:14:20 lol verm__ nice one 2012-05-31T11:14:50 it's late here, and good night... 2012-05-31T11:14:54 good night zw_yao 2012-05-31T11:15:00 good night 2012-05-31T11:15:03 good night 2012-05-31T11:15:25 Hesham: ric made some good points that you should take into consideration 2012-05-31T11:15:47 putting the implementation lower toward the BSP (at least for hw representations) is a good idea 2012-05-31T11:16:12 it may add some complexity in order to make the higher-level code be generic 2012-05-31T11:16:35 but it can also simplify future modifications to support wider ranges of mmu-type hw 2012-05-31T11:17:40 for the static mmu it just means the applications has full control over mmu contents 2012-05-31T11:17:52 there would be some kind of default settings in the bsp already i think 2012-05-31T11:18:02 High-level code should knows about generic attributes 2012-05-31T11:18:04 at least for bsp's that require mmu support to be functionali 2012-05-31T11:18:24 and it's translated by the BSP hw 2012-05-31T11:18:26 i don't know what attributes the high-level code needs to know 2012-05-31T11:18:42 for example 2012-05-31T11:18:47 it does not do anything with the attributes other than pass them between application and bspo 2012-05-31T11:19:06 if the application needs to enforce r/w access to a given area 2012-05-31T11:19:41 how could this be done without a generic attributes like the one we have 2012-05-31T11:20:26 I mean of course enforcing HW protection would be in bsp code 2012-05-31T11:21:07 but there must be a translation between layers ( application/bsp) 2012-05-31T11:21:31 yes we need generic attributes, but how you represent the attributes is the question 2012-05-31T11:21:36 every bsp translate the generic attributes according to its HW and bit patterns in control register 2012-05-31T11:22:08 bye 2012-05-31T11:22:09 is not Arena_Atrributes a generic one ? 2012-05-31T11:22:12 the high-level interface could make a request to the BSP to obtain an "attribute variable" containing r/w 2012-05-31T11:22:13 later sebhub 2012-05-31T11:22:18 bye sebhub 2012-05-31T11:22:36 the question is whether such translation is a good thing to be doing 2012-05-31T11:22:43 or whether the bsp can be providing a more efficient way 2012-05-31T11:23:27 that's the case when we want to get attributes 2012-05-31T11:23:57 But how could we set attributes at the high-level layer ? 2012-05-31T11:24:20 provide a function like... "set_write" 2012-05-31T11:24:27 "set_read" "set_execute" 2012-05-31T11:24:46 back. 2012-05-31T11:24:55 and store those attributes in the arena_control, with the representation of how to store them chosen by the bsp 2012-05-31T11:25:03 welcome bacl DrJoel 2012-05-31T11:25:15 this way when the arenas are loaded/unloaded, the bsp can most efficiently modify its control registers 2012-05-31T11:25:18 agree with gedare .. keep top simple.. it can grow.. maybe you can even mimic one attribute with another if not supported.. or return an error 2012-05-31T11:25:20 a void pointer ? 2012-05-31T11:25:31 an "opaque type" 2012-05-31T11:25:45 i'm not sure if there is an example of this already hmmm 2012-05-31T11:26:12 where the BSP provides type information for higher-level code 2012-05-31T11:26:18 well, it does not matter actually 2012-05-31T11:26:23 you just need a type name 2012-05-31T11:26:31 and use a pointer to the type field 2012-05-31T11:26:47 we prefer not to use void*, but essentially it is the same thing 2012-05-31T11:26:54 Arena_Attribute* 2012-05-31T11:27:14 typedef struct Arena_Attribute_struct Arena_Attribute; 2012-05-31T11:27:18 in libmmu 2012-05-31T11:27:31 and in the bsp somewhere defines struct Arena_Attribute_struct{...} 2012-05-31T11:28:02 But for high-level design we do not care about attributes now , we just need to set them and leave the other work for BSP code 2012-05-31T11:28:12 that's ok 2012-05-31T11:28:21 yeah 2012-05-31T11:28:25 that's the idea 2012-05-31T11:29:12 another thing , how #include directive works in RTEMS 2012-05-31T11:29:20 i think you want to start with the static mmu as a first step btw 2012-05-31T11:29:24 heh 2012-05-31T11:29:41 it does not include the full path 2012-05-31T11:29:43 Makefile.am files declare various headers as "installed" via xxx_include_HEADERS = ... 2012-05-31T11:29:54 *** sebhub has quit IRC (Ping timeout: 244 seconds) 2012-05-31T11:30:15 those header files get copied into the build tree (under target-rtems4.11/bsp/lib/include) 2012-05-31T11:30:20 and then later into the install path 2012-05-31T11:30:44 the compiler flags specify that location as an include path 2012-05-31T11:30:53 so that the compiler knows to look there for header files 2012-05-31T11:30:58 that are included using < > tags 2012-05-31T11:31:11 ok 2012-05-31T11:31:14 headers with " " are just searched in the source tree as usual, with relative paths 2012-05-31T11:31:22 i know that 2012-05-31T11:31:59 i am just confused when using something like #include 2012-05-31T11:32:13 chain.h* 2012-05-31T11:32:32 although that's not its full path 2012-05-31T11:32:41 yeah 2012-05-31T11:32:49 just a little bit of build system magic 2012-05-31T11:33:12 not a big deal for now 2012-05-31T11:33:15 It is a hack to avoid specifying a bunch of -I in each makefile. It has resulted in many files being installed that probably should be private 2012-05-31T11:33:24 But it isn't your problem :) 2012-05-31T11:33:42 i'm starting to think we should get libmmu working 2012-05-31T11:33:46 and then build arena on top of it 2012-05-31T11:33:52 yeah, i just need to include the write files :) 2012-05-31T11:33:55 and rename libmmu.... maybe libmm is ok 2012-05-31T11:34:05 i dislike tying the code to "mmu" which has a very specific meaning 2012-05-31T11:34:14 memory management \ 2012-05-31T11:34:21 yeah 2012-05-31T11:34:38 but mmu work will still reside in libmm ? 2012-05-31T11:34:43 *** hiddenpearls has joined #rtems 2012-05-31T11:34:44 then you can rename all the functions in libmm from memory_protection to just mm_ 2012-05-31T11:34:46 and arena also ? 2012-05-31T11:34:52 mmu work will reside in libmm 2012-05-31T11:34:58 i think arena will collaborate with libmm 2012-05-31T11:35:08 layer together 2012-05-31T11:35:19 to make developer's job easier 2012-05-31T11:35:40 yeah but where should it resides ? 2012-05-31T11:35:45 in libmm also ? 2012-05-31T11:35:49 nah 2012-05-31T11:36:13 a new dir libarena ? 2012-05-31T11:36:28 maybe. not sure yet 2012-05-31T11:36:39 maybe part of classic api 2012-05-31T11:37:21 i'm not sure. :) 2012-05-31T11:37:34 basically arena is libmm+tasks(+allocator) 2012-05-31T11:38:00 we must care about getting mmutest1 to work now right ? 2012-05-31T11:38:09 yeah 2012-05-31T11:38:09 and then on fixing libmmu 2012-05-31T11:38:17 giving it the proper names... 2012-05-31T11:38:23 moving the implementation of attributes into the bsp 2012-05-31T11:38:34 and changing the name only ? 2012-05-31T11:38:36 giving it a better notion of "region" 2012-05-31T11:38:50 names, and fix the attributes 2012-05-31T11:38:54 yeah to avoid region HW meaning 2012-05-31T11:39:04 they're defined similarly to your proposed libarena 2012-05-31T11:39:17 yeah i just copied them 2012-05-31T11:39:35 yeah. so we'll fix libmmu i think it can be done before the midterm 2012-05-31T11:39:43 Should i work on powepc BSP code ? 2012-05-31T11:39:46 yep 2012-05-31T11:40:02 Ok 2012-05-31T11:40:16 i told you about the problem i have 2012-05-31T11:40:23 exams? 2012-05-31T11:40:26 oh 2012-05-31T11:40:28 in libmmu Makefile 2012-05-31T11:40:28 with powerpc ;) 2012-05-31T11:40:34 yeah. 2012-05-31T11:40:44 i will start exams next sunday :) 2012-05-31T11:41:16 Did not understand the problem yet 2012-05-31T11:41:39 why it says no such file / directory mmu_support.h 2012-05-31T11:41:48 although it exists ? 2012-05-31T11:41:50 check out c/src/lib/libcpu/sparc64/Makefile.am 2012-05-31T11:42:03 does it exist in the build directory thought? that is the problem 2012-05-31T11:42:17 no 2012-05-31T11:42:20 see how there is sun4u_mmu_rel_SOURCES += sun4u/mmu/mmu_support.h 2012-05-31T11:42:39 and then there is in preinstall.am some build script that installs it 2012-05-31T11:42:47 oh actually it is 2012-05-31T11:42:51 include_libcpu_HEADERS += sun4u/mmu/mmu_support.h 2012-05-31T11:42:55 that line which gives the magic 2012-05-31T11:43:05 so you need a line like that iin c/src/lib/libcpu/pwerpoc 2012-05-31T11:43:50 i did not modify any sparc work or added it , just powerpc ! 2012-05-31T11:44:00 check out c/src/lib/libcpu/powerpc 2012-05-31T11:44:07 search for mpc6xx 2012-05-31T11:44:14 and see how it has some mmu-specific stuff 2012-05-31T11:44:25 sorry, Makefile.am 2012-05-31T11:44:32 under c/src/lib/libcpu/powerpc/Makefile.am 2012-05-31T11:44:47 there is a bit that compiles conditional for mpc6xx 2012-05-31T11:44:53 it has include_libcpu_HEADERS += mpc6xx/mmu/bat.h mpc6xx/mmu/pte121.h 2012-05-31T11:45:01 you need to add to it also mmu_support.h 2012-05-31T11:45:21 aha 2012-05-31T11:45:36 and you may need to add the .c files too 2012-05-31T11:45:53 when i updated this code I guess I lost some of the build changes 2012-05-31T11:46:01 so i have to add headers in powepc Makefile.am 2012-05-31T11:46:04 yea 2012-05-31T11:46:35 not mpc6xx ?? 2012-05-31T11:46:43 uh 2012-05-31T11:46:56 i mean the Makefile.am in powerpc 2012-05-31T11:47:00 yeah 2012-05-31T11:47:04 and not in mpc6xx 2012-05-31T11:47:08 there is not one in mpc6xx 2012-05-31T11:47:34 ok 2012-05-31T11:48:08 there are mmu_support.* and pagetable_.c 2012-05-31T11:48:49 should i include another one of them other than mmu_support.h 2012-05-31T11:48:51 ? 2012-05-31T11:49:08 i think you may need to add them to mpc6xx_mmu_rel_SOURCES 2012-05-31T11:49:15 and also the .h file should add to that 2012-05-31T11:49:55 there is also some related files in libcpu/shared 2012-05-31T11:50:09 do i have to do any work with them ? 2012-05-31T11:51:26 yeah 2012-05-31T11:51:30 sun4u_mmu_rel_SOURCES += sun4u/mmu/memoryprotection.c 2012-05-31T11:51:33 oops 2012-05-31T11:51:36 replace with mpc6xx 2012-05-31T11:51:44 mmu_rel_SOURCES += ../shared/src/memoryprotection_manager.c 2012-05-31T11:51:53 again mpc6xx_mmu_rel..... 2012-05-31T11:51:59 that is what you need for the .c files 2012-05-31T11:52:00 file 2012-05-31T11:52:09 the .h file should get added to include_libcpu_HEADERS 2012-05-31T11:52:12 so it gets installed 2012-05-31T11:52:14 include_libcpu_HEADERS += ../shared/include/memoryprotection.h 2012-05-31T11:52:22 yeah 2012-05-31T11:52:35 that's all in libcpu/powerpc/Makefile.am right ? 2012-05-31T11:52:45 yea 2012-05-31T11:53:19 sorry i did not work with Makefiles a lot 2012-05-31T11:53:32 i will try that 2012-05-31T11:54:15 it's ok 2012-05-31T11:54:24 the build system is a bear 2012-05-31T11:54:58 i discovered that :) 2012-05-31T11:55:09 Would you be available tomorrow ? 2012-05-31T11:55:52 no 2012-05-31T11:56:03 next tuesday 2012-05-31T11:56:06 i will be available 2012-05-31T11:56:43 that's ok , i will work on test suites and modifying mmu work and create .diff file 2012-05-31T11:57:01 ok is your work available on github? 2012-05-31T11:57:16 Nope 2012-05-31T11:57:25 i changed my user name 2012-05-31T11:57:33 i think you have to add it again 2012-05-31T11:57:39 it's 2012-05-31T11:57:44 heshamelmatary 2012-05-31T11:57:53 just like me e-mail 2012-05-31T11:58:09 What should/should not commit to github ? 2012-05-31T11:58:21 commit everything to git hub ;) 2012-05-31T11:58:34 fork rtems, make branches, start pushing 2012-05-31T11:59:02 i forked it 2012-05-31T11:59:30 i am afraid of committing needless files 2012-05-31T11:59:30 good. yeah it looks like github updated your account for you 2012-05-31T11:59:40 you can always delete / fix them 2012-05-31T12:00:04 Ok i will keep all my work there 2012-05-31T12:00:09 good 2012-05-31T12:00:41 *** ppisa has left #rtems ("Kopete 0.12.7 : http://kopete.kde.org") 2012-05-31T12:02:56 ok i have to go prep for another meeting 2012-05-31T12:03:30 work on getting libmmu working. i'll check email tonight or tomorrow morning so if you have some problems still i might be able to help, but i'll be offline all weekend 2012-05-31T12:03:47 and then work on making the fixes to the naming, and to how attributes are implemented 2012-05-31T12:04:07 ok 2012-05-31T12:04:22 i will email you with any problems/updates 2012-05-31T12:04:45 sounds good. see you next week 2012-05-31T12:04:50 see you 2012-05-31T12:05:34 *** Hesham has left #rtems 2012-05-31T12:09:30 sniff 2012-05-31T12:11:31 ping 2012-05-31T12:11:31 something smell? 2012-05-31T12:11:36 ;-) 2012-05-31T12:11:39 no no 2012-05-31T12:11:52 but my student went away before talking with him 2012-05-31T12:11:57 no chance :-/ 2012-05-31T12:12:02 ahhh, sniff like sniffling 2012-05-31T12:12:11 not sniff like sniffing ;) 2012-05-31T12:13:01 he was quite fast 2012-05-31T12:13:24 gedare: sniff like I am sad 2012-05-31T12:14:08 aww, i know how sad it can be when your student doesn't show up 2012-05-31T12:22:41 juli1, we can try to schedule a IRC meeting with him. 2012-05-31T12:22:58 cdcs: I think this would be the best 2012-05-31T12:24:19 ok. i will send an e-mail 2012-05-31T12:24:59 ok 2012-05-31T12:25:00 I have to go 2012-05-31T12:25:05 but we have to schedule that 2012-05-31T12:25:10 see you 2012-05-31T12:25:13 *** juli1 has quit IRC (Quit: leaving) 2012-05-31T12:49:31 *** cdcs has quit IRC (Quit: Page closed) 2012-05-31T13:32:19 *** QingPei has left #rtems 2012-05-31T14:02:26 *** gedare has quit IRC (Quit: Ex-Chat) 2012-05-31T14:07:10 *** alseh has joined #rtems 2012-05-31T14:51:23 *** hiddenpearls has quit IRC (Quit: Leaving.) 2012-05-31T14:57:07 *** hiddenpearls has joined #rtems 2012-05-31T15:36:42 *** hiddenpearls has quit IRC (Quit: Leaving.) 2012-05-31T16:31:10 *** DrJoel has quit IRC (Quit: Leaving) 2012-05-31T17:09:52 *** DrJoel has joined #rtems 2012-05-31T17:09:53 *** DrJoel has joined #rtems 2012-05-31T17:09:53 *** ChanServ sets mode: +o DrJoel 2012-05-31T17:09:59 kiwichris, around? 2012-05-31T17:12:33 *** DrJoel has quit IRC (Client Quit) 2012-05-31T17:23:45 *** hiddenpearls has joined #rtems 2012-05-31T17:37:45 *** hiddenpearls has quit IRC (Quit: Leaving.) 2012-05-31T18:11:48 Hmm just missed Joel 2012-05-31T20:13:19 *** xiangfu has joined #rtems 2012-05-31T22:31:59 *** kristianpaul has left #rtems 2012-06-01T00:35:18 *** zw_yao has quit IRC (Remote host closed the connection) 2012-06-01T00:43:09 *** alseh has joined #rtems 2012-06-01T01:34:01 *** sebhub has joined #rtems 2012-06-01T01:50:55 *** QingPei has joined #rtems 2012-06-01T01:58:56 moorning 2012-06-01T02:26:55 *** hiddenpearls has joined #rtems 2012-06-01T03:02:35 *** xiangfu has quit IRC (Ping timeout: 246 seconds) 2012-06-01T03:17:17 *** QingPei has left #rtems 2012-06-01T03:21:02 *** xiangfu has joined #rtems 2012-06-01T03:38:38 *** xiangfu has quit IRC (Ping timeout: 246 seconds) 2012-06-01T03:51:50 *** xiangfu has joined #rtems 2012-06-01T05:07:17 *** hiddenpearls has quit IRC (Quit: Leaving.) 2012-06-01T05:30:44 *** QingPei has joined #rtems 2012-06-01T06:12:47 *** Hesham has joined #rtems 2012-06-01T06:15:23 *** Hesham has left #rtems 2012-06-01T06:51:43 *** cdcs has joined #rtems 2012-06-01T07:03:42 *** cdcs_ has joined #rtems 2012-06-01T07:06:16 *** cdcs has quit IRC (Ping timeout: 245 seconds) 2012-06-01T07:10:21 *** hiddenpearls has joined #rtems 2012-06-01T08:21:03 *** xiangfu has quit IRC (Quit: Leaving) 2012-06-01T08:26:18 *** alseh has quit IRC (Ping timeout: 245 seconds) 2012-06-01T09:10:49 *** hiddenpearls has quit IRC (Quit: Leaving.) 2012-06-01T09:21:37 *** hiddenpearls has joined #rtems 2012-06-01T09:33:06 *** hiddenpearls has quit IRC (Quit: Leaving.) 2012-06-01T09:35:17 *** alseh has joined #rtems 2012-06-01T10:16:13 *** cdcs_ has quit IRC (Quit: Page closed) 2012-06-01T10:22:35 *** sebhub has quit IRC (Remote host closed the connection) 2012-06-01T10:23:03 *** QingPei has quit IRC (Quit: Leaving.) 2012-06-01T10:24:39 *** QingPei has joined #rtems 2012-06-01T10:47:23 *** hiddenpearls has joined #rtems 2012-06-01T10:51:35 *** alseh has quit IRC (Remote host closed the connection) 2012-06-01T12:21:14 *** jennifer has quit IRC (Quit: Leaving) 2012-06-01T12:56:57 *** hiddenpearls has quit IRC (Quit: Leaving.) 2012-06-01T13:02:20 *** hiddenpearls has joined #rtems 2012-06-01T13:47:39 *** hiddenpearls has quit IRC (Quit: Leaving.) 2012-06-01T13:55:17 *** hiddenpearls has joined #rtems 2012-06-01T13:57:33 *** QingPei has left #rtems 2012-06-01T14:18:26 *** soh_cah_toa has quit IRC (Ping timeout: 246 seconds) 2012-06-01T14:56:47 *** hiddenpearls has quit IRC (Quit: Leaving.) 2012-06-01T15:26:44 *** hiddenpearls has joined #rtems 2012-06-01T15:34:12 *** hiddenpearls has quit IRC (Quit: Leaving.) 2012-06-01T15:37:33 *** hiddenpearls has joined #rtems 2012-06-01T16:32:40 *** hiddenpearls has quit IRC (Quit: Leaving.) 2012-06-01T21:07:54 *** xiangfu has joined #rtems 2012-06-01T21:50:59 *** xiangfu has quit IRC (Ping timeout: 245 seconds) 2012-06-01T22:04:10 *** xiangfu has joined #rtems 2012-06-01T22:41:23 *** hiddenpearls has joined #rtems 2012-06-02T00:59:52 *** arvind_khadri has joined #rtems 2012-06-02T01:26:20 *** xiangfu has quit IRC (Remote host closed the connection) 2012-06-02T02:44:55 *** arvind_khadri has quit IRC (Ping timeout: 252 seconds) 2012-06-02T03:29:10 *** hiddenpearls1 has joined #rtems 2012-06-02T03:31:53 *** hiddenpearls has quit IRC (Ping timeout: 244 seconds) 2012-06-02T03:57:48 *** arvind_khadri has joined #rtems 2012-06-02T06:05:25 *** hiddenpearls1 has quit IRC (Quit: Leaving.) 2012-06-02T06:56:34 *** cdcs has joined #rtems 2012-06-02T07:03:38 *** juli1 has joined #rtems 2012-06-02T07:03:42 hi 2012-06-02T07:04:05 cdcs: so, as soon as our student arrived we can start I assume ? 2012-06-02T07:09:05 juli1, Hi 2012-06-02T07:09:09 yes we can 2012-06-02T07:14:27 *** juli1_ has joined #rtems 2012-06-02T07:18:11 *** juli1 has quit IRC (Ping timeout: 244 seconds) 2012-06-02T07:18:23 *** juli1_ is now known as juli1 2012-06-02T07:29:07 *** WikL has joined #rtems 2012-06-02T07:29:50 Hello 2012-06-02T07:30:16 hello all 2012-06-02T07:30:38 *** hiddenpearls has joined #rtems 2012-06-02T07:32:03 juli1, Are you still here? 2012-06-02T07:35:24 yes 2012-06-02T07:35:39 I assume we can start 2012-06-02T07:35:43 right ? 2012-06-02T07:35:47 yes, i think so 2012-06-02T07:35:50 k 2012-06-02T07:35:55 shall we keep this channel or take a private one ? 2012-06-02T07:36:07 i think we should keep in this one 2012-06-02T07:36:10 its logged 2012-06-02T07:36:23 WikL: please take the minutes of the meeting and send them back to us once the meeting is finished. That makes sense ? 2012-06-02T07:36:43 sure 2012-06-02T07:36:50 ok, perfect 2012-06-02T07:36:55 where are the logs available? 2012-06-02T07:36:57 So, please start 2012-06-02T07:37:19 http://www.rtems.org/irclogs/ 2012-06-02T07:37:22 thttp://www.rtems.org/irclogs/index.html 2012-06-02T07:37:25 ups 2012-06-02T07:37:30 thanks 2012-06-02T07:37:31 :D 2012-06-02T07:38:17 so 2012-06-02T07:38:59 I'm not sure about certain requirements for the BSP to work 2012-06-02T07:39:50 right now the closest goal is to establish a working environment and add further functionality 2012-06-02T07:40:05 first, regarding the last email, let me clarify that we are not trying to map RTEMS tasks to POK tasks. 2012-06-02T07:40:16 yes, I understand 2012-06-02T07:40:56 As cdcs said, RTEMS is considered as a black box from POK point of view 2012-06-02T07:40:58 RTEMS will switch between contexts by itself using the POK kernel 2012-06-02T07:41:21 and you just have to adapt the POK kernel layer, not the libpok 2012-06-02T07:42:25 WikL: right and one goal of the project is also to design necessary interfaces so that we can "standardized" the interfaces between the virtualised RTEMS and the separation kernel 2012-06-02T07:42:58 so, POK would be a separation kernel but we could also integrate the very same RTEMS black box on top of another separation kernel like AIR 2012-06-02T07:43:32 that is clear 2012-06-02T07:44:18 you need to indeitfy the point in RTEMS that need to be virtualized 2012-06-02T07:44:23 identify* 2012-06-02T07:44:42 cdcs: this is the work that should be done, no ? :D 2012-06-02T07:44:51 you have already identified one of those: the context switch 2012-06-02T07:45:07 at this time, from what I see, there is the context switch and the console 2012-06-02T07:45:21 (ot lets say, a debugging output) 2012-06-02T07:45:35 we need also the clock tick interrupt 2012-06-02T07:45:42 right 2012-06-02T07:46:50 regarding the console i think there are several options, depending if the I/O registers are mapped or not to the partition address space 2012-06-02T07:48:03 cdcs: in that case, you assume there is only one partition that can print data 2012-06-02T07:48:50 or also, it depends, we can let the user decide if the i/o can be shared. But in that case, this is up to the implementation/tool provider to avoid any crappy stuff 2012-06-02T07:48:54 yes. you can build a printf partition that communicates with the others by ports or share memory 2012-06-02T07:49:22 I didn't understand the POK documentation clearly 2012-06-02T07:49:25 yes juli1. i agree with you 2012-06-02T07:49:28 is there a dedicated partition for drivers? 2012-06-02T07:49:46 WikL: that is the point. In POK, yes, only one partition handles the driver 2012-06-02T07:50:08 WikL: because in fact, partitioned systems are made to separate applications for security and safety purposes 2012-06-02T07:51:00 so, if you share a device among two partitions, this could be a security leak. So, POK makes the assumption that one device is assigned to one partition. 2012-06-02T07:51:27 But on the other hand, if two partitions have the same security level, this requirement does not make any sense from a security point of view. 2012-06-02T07:52:08 *** hiddenpearls has quit IRC (Ping timeout: 240 seconds) 2012-06-02T07:53:35 if running a separate partition for a console driver doesn't have much overhead, it seems like an elegant way of going about it 2012-06-02T07:54:07 we can do that, this can be a solution indeed 2012-06-02T07:54:12 (the safest way to share such a HW device in a partitioned system is to have a dedicated parititon that acts as an I/O server to the other partitions. or to have a HW device that is parition-aware) 2012-06-02T07:55:02 but on the other hand, I suggest that the interface between partition and kernel does not make any assumption about that and we let also open the solution to share one device among different partitions. 2012-06-02T07:55:05 yes a separate printf partition is a simple solution that works 2012-06-02T07:55:21 but for POK, we keep the one partition for a device strategy 2012-06-02T07:55:25 is that ok WikL ? 2012-06-02T07:55:46 clear 2012-06-02T07:56:55 so now the context switch? 2012-06-02T07:57:42 yes ? 2012-06-02T07:58:14 POK has a function which accepts two stack pointers and just pops/pushes them along with the current registers 2012-06-02T07:58:34 yes 2012-06-02T07:59:01 RTEMS' BSP passes a set of registers as the context_switch()'s arguments 2012-06-02T07:59:01 i think RTEMS uses: "_CPU_Context_switch( Context_Control *run, Context_Control *heir );" 2012-06-02T08:00:39 so I'm not sure how to use the POK's function for this 2012-06-02T08:01:47 would RTEMS have to be modified to call the POK's context_switch instead of saving the registers' state in a struct? 2012-06-02T08:02:47 either you modify the RTEMS function, either you make a wrapper that adapts the current code to your interface 2012-06-02T08:03:10 once again, you have to make an interface and then, make sure that POK and RTEMS use these interfaces 2012-06-02T08:04:15 maybe a wrapper is the best way. task context switch is a RTEMS' job. the hypervisor only helps to get the register context. 2012-06-02T08:05:19 cdcs: and also, you keep the current RTEMS code unmodified which is better for maintenance 2012-06-02T08:06:43 yup 2012-06-02T08:06:49 ok then 2012-06-02T08:07:15 you also need to take a look at the clock tick interrupt 2012-06-02T08:07:19 just to make it clear: the interfacing layer will be more or less in the form of a regular BSP, right? 2012-06-02T08:07:33 POK shall call the clock tick in RTEMS 2012-06-02T08:07:59 *** QingPei has joined #rtems 2012-06-02T08:08:15 WikL: not really, The interface is a set of resources for interacting between the separation kernel and RTEMS 2012-06-02T08:09:08 in other words, this can be syscalls (RTEMS call the separation kernel services) or also the way back (POK calls some registered functions of RTEMS) 2012-06-02T08:09:27 cdcs: please also correct me if you do not share these ideas :D 2012-06-02T08:09:32 how we will fit the interface in the RTEMS tree its another issue. But that is more a question for when we have the interface defined. 2012-06-02T08:10:07 and that is a question that probably Joel is better suited to anwser. 2012-06-02T08:10:23 juli1, i agree with you. 2012-06-02T08:10:34 but since things like context switch, channeling interrupts and accessing I/O is done via the BSP 2012-06-02T08:10:51 the interface layer would be just that plus the inter partition services? 2012-06-02T08:11:12 WikL: indeed, for a first start, yes 2012-06-02T08:11:15 this is not so much 2012-06-02T08:11:17 I feel this is important and I don't want to have a bad understanding of it 2012-06-02T08:11:41 and keep in mind that in Real Time and Safety-Critical systems we want software as small as we can 2012-06-02T08:12:07 they do few things. But we want they do them right 2012-06-02T08:12:17 (and this is the most difficult aspect :D) 2012-06-02T08:12:52 the interface at this point will be just what is required to get things working. if its contained in a BSP then that is fine 2012-06-02T08:13:14 we is something more than a BSP, we talk to Joel and we see how can we fit it in RTEMS tree 2012-06-02T08:13:24 for the minimal version, I think it would 2012-06-02T08:13:25 ok 2012-06-02T08:13:59 WikL: so, do you have other questions ? 2012-06-02T08:14:01 so back to the clock interrupt 2012-06-02T08:14:22 the clock interrupt is managed by the POK 2012-06-02T08:14:24 it will not be a true interrupt, just a call from POK to RTEMS? 2012-06-02T08:15:06 the interrupt handler will need to call something in RTEMS, So that RTEMS can have a notion of time passing 2012-06-02T08:15:42 the "true interrupt" exists and is managed by the hypervisor 2012-06-02T08:16:29 this is another "abstraction" point. The hypervisor shall propagate clock ticks to RTEMS. 2012-06-02T08:17:00 will this service fit in the kernel or a partition like the ones for the console driver? 2012-06-02T08:17:35 this is different. The hypervisor mantained interrupt shall call a RTEMS function 2012-06-02T08:17:43 and not otherwise 2012-06-02T08:18:02 so that RTEMS shall issue a syscall to register for interrupt in fact 2012-06-02T08:18:37 yes. we can provide interrupt virtualization 2012-06-02T08:18:41 when rtems initialized, it calls partition syscall of POK to register a function that would be called from POK. And this function is called when a tick passed 2012-06-02T08:18:47 or something similar 2012-06-02T08:18:54 and there is a common interface in POK for registering interrupts on all architectures? 2012-06-02T08:18:58 but this is the principle I guess 2012-06-02T08:19:15 WikL: I did not think about that, you have to investigate this point by yourself 2012-06-02T08:19:44 I think it was RTEMS that had a different way to handle regular interrupt vectors and the PIC (?) 2012-06-02T08:20:38 I'm noting it down as something to look into 2012-06-02T08:21:22 cdcs: any idea ? 2012-06-02T08:22:38 as a first expereince you can just call rtems_clock_tick() from the POK's ISR_Clock_Handler 2012-06-02T08:23:10 we can latter think on a full interrupt virtualization architecture 2012-06-02T08:23:44 rtems_interrupt_catch(...) will map to a hypervisor system call 2012-06-02T08:23:59 that registers a handler to a given interrupt 2012-06-02T08:24:15 when that interrupt happens the hypervisor simply calls that function 2012-06-02T08:24:46 (for a given running partition, if the partition is not running nothing happens) 2012-06-02T08:25:05 but the interrupt is queued? 2012-06-02T08:25:06 (or the interrupt is simply postponed to a later time) 2012-06-02T08:25:10 ok 2012-06-02T08:25:48 this interrupt virtualization requires a virtual trap table for each partition 2012-06-02T08:25:58 this interrupt virtualization archuitecture* 2012-06-02T08:28:37 (the PIC/interrupt controller is always managed by the hypervisor) 2012-06-02T08:29:37 i would advise you to start playing with the code. The partition's entry point will be boot_card() i think :P 2012-06-02T08:29:58 the RTEMS partition's* 2012-06-02T08:30:04 yeah 2012-06-02T08:30:17 I don't yet know how to go about the compilation of all this 2012-06-02T08:30:53 i don't know POK's memory map. That maybe more of a question for juli1 2012-06-02T08:31:30 for the kernel you mean ? 2012-06-02T08:32:12 for the kernel, this is very basic. We cat the partitions at the end of the kernel 2012-06-02T08:32:31 and then, we produce a C file that contains the size of the partition 2012-06-02T08:33:03 then, when loading, the kernel is looking at the end of its memory section and load big memory chunks in different segments 2012-06-02T08:33:21 and identify the memory chunks to load using the siwe written in the C files 2012-06-02T08:34:06 this makes sense ? 2012-06-02T08:35:45 if it is just linear, without Virtual memory, the RTEMS+application can be handled like just a big partition? 2012-06-02T08:36:03 right 2012-06-02T08:36:21 in fact, each RTEMS you have is a big partition you will load in a memory segment 2012-06-02T08:37:51 seems fine to me. AIR uses VM to keep only RTEMS code instance in memory 2012-06-02T08:38:13 to keep only one RTEMS instance* 2012-06-02T08:38:43 ah ok 2012-06-02T08:38:49 no, this is not the way I see it 2012-06-02T08:38:51 :D 2012-06-02T08:39:29 yeah. this way is a lot simpler 2012-06-02T08:39:37 exactly 2012-06-02T08:39:44 every partition has its own code and data 2012-06-02T08:39:54 you do not have to handle shared code and separated data 2012-06-02T08:39:59 much more simpler 2012-06-02T08:40:49 yes. i agree. AIR keeps just one instance of RTEMS code, than maps that code to each partitions' address space 2012-06-02T08:41:27 then* (i'm dyslexic today!!) 2012-06-02T08:41:29 but later, I think we can also keep such a feature as an improvement also 2012-06-02T08:42:50 I understand the concepts, but will most probably have questions when it comes to making it work, I'm pretty bad with Makefiles 2012-06-02T08:44:26 RTEMS will be simply part of each partition 2012-06-02T08:44:39 as if it was part of the application code 2012-06-02T08:44:54 WikL: errrggghhhh 2012-06-02T08:45:28 WikL: writing Makefiles is a basic requirement and I invite you to read documentation and tutorial about that 2012-06-02T08:47:03 *** WikL has quit IRC (Ping timeout: 244 seconds) 2012-06-02T08:47:12 ergh :-/ 2012-06-02T08:47:49 *** WikL has joined #rtems 2012-06-02T08:47:57 sorry, got disconnected 2012-06-02T08:48:05 no problem 2012-06-02T08:48:21 WikL I understand the concepts, but will most probably have questions when it comes to making it work, I'm pretty bad with Makefiles 2012-06-02T08:48:22 cdcs RTEMS will be simply part of each partition 2012-06-02T08:48:24 cdcs as if it was part of the application code 2012-06-02T08:48:25 juli1 WikL: errrggghhhh 2012-06-02T08:48:27 juli1 WikL: writing Makefiles is a basic requirement and I invite you to read documentation and tutorial about that 2012-06-02T08:48:50 I understand 2012-06-02T08:51:05 so right now I should start writing some code since the basic implementation's overview is agreed upon 2012-06-02T08:51:41 I think that you should first write the minutes of this meeting 2012-06-02T08:52:12 is there anything else? 2012-06-02T08:52:17 Then, write the specification of the interface between the separation kernel and RTEMS. It will also help you to have a clear idea of the implementation 2012-06-02T08:52:44 And them, submit it and start coding. Comments will also come once you start the implementation so do not wait for comment before implementation efforts. 2012-06-02T08:53:04 On my side, I have only one question : when do you think you will have a first implementation 2012-06-02T08:53:13 a first example that should works ? 2012-06-02T08:54:34 right now I don't think there's that much to implement but it may change when the interface is put onto paper 2012-06-02T08:54:44 on my side i think i should install POK and Ocarina ;) 2012-06-02T08:54:50 cdcs: :D 2012-06-02T08:55:04 WikL: ok, so, when do you think you might have something ? 2012-06-02T08:55:09 when are the midterm evaluation ? 2012-06-02T08:55:23 checking 2012-06-02T08:55:36 (side question: ocarina/taste outputs an a653.xml file?) 2012-06-02T08:55:50 cdcs: yes, of course :D 2012-06-02T08:56:27 hum... I will that a look at that. 2012-06-02T08:56:41 sorry, not checking. internet connection gone bad, cannot browse www 2012-06-02T08:57:27 julym 9 2012-06-02T08:57:42 I will have the document describing the interface at the beginning of next week 2012-06-02T08:57:49 ok 2012-06-02T08:58:02 ok 2012-06-02T08:58:10 so, I suggest the first example works before the mid term review. That makes sense ? 2012-06-02T08:58:22 yes 2012-06-02T08:58:26 ok 2012-06-02T08:58:29 great 2012-06-02T08:58:44 I have my tasks noted 2012-06-02T08:58:45 minute of meeting -> rtems_gsoc 2012-06-02T08:58:50 so, I think you can send the minutes today and the interface beginning of next week 2012-06-02T08:58:52 + the Makefile crash course on the side 2012-06-02T08:59:01 interface definiftion->rtems_devel 2012-06-02T08:59:04 and then, start coding at your convenience 2012-06-02T08:59:05 ok 2012-06-02T08:59:07 cdcs: exactly 2012-06-02T08:59:12 definition* 2012-06-02T08:59:19 and please contact us as soon as you have ANY question 2012-06-02T08:59:49 thank you both for taking the time to have this meeting 2012-06-02T09:00:00 no proble, 2012-06-02T09:00:05 it is our duty 2012-06-02T09:00:12 yup. send us any question. 2012-06-02T09:00:15 yours now is to make something that works 2012-06-02T09:00:17 :D 2012-06-02T09:00:46 Can we consider this meeting as finished ? 2012-06-02T09:00:48 the fun part 2012-06-02T09:00:57 i think so! 2012-06-02T09:01:01 ok 2012-06-02T09:01:01 I have no more questions 2012-06-02T09:01:09 I have to clean my home now 2012-06-02T09:01:13 see you guys ! 2012-06-02T09:01:15 lol 2012-06-02T09:01:18 see you!~ 2012-06-02T09:01:24 *** juli1 has quit IRC (Quit: ChatZilla 0.9.88.2 [Firefox 12.0/20120420145725]) 2012-06-02T09:01:25 later 2012-06-02T09:01:48 I'm off too, have to get this internet sorted 2012-06-02T09:01:54 ok 2012-06-02T09:01:55 bye 2012-06-02T09:02:04 thanks again, bye 2012-06-02T09:02:08 *** WikL has quit IRC () 2012-06-02T09:12:21 *** cdcs has quit IRC (Quit: Page closed) 2012-06-02T09:41:08 *** arvind_khadri has quit IRC (Ping timeout: 240 seconds) 2012-06-02T11:36:42 *** QingPei has quit IRC (Ping timeout: 245 seconds) 2012-06-02T11:37:49 *** QingPei has joined #rtems 2012-06-02T12:55:05 *** QingPei has left #rtems 2012-06-02T15:27:46 *** Deb has joined #rtems 2012-06-02T18:30:08 *** kiwichris has quit IRC (Quit: This computer has gone to sleep) 2012-06-02T20:31:33 *** zw_yao has joined #rtems 2012-06-02T22:27:42 *** QingPei has joined #rtems 2012-06-02T23:02:10 *** arvind_khadri has joined #rtems 2012-06-03T00:11:30 *** weiY has joined #rtems 2012-06-03T00:56:38 *** arvind_khadri has quit IRC (Ping timeout: 240 seconds) 2012-06-03T01:39:12 *** weiY has quit IRC (Ping timeout: 244 seconds) 2012-06-03T01:44:02 *** weiY has joined #rtems 2012-06-03T01:49:22 *** zw_yao has quit IRC (Remote host closed the connection) 2012-06-03T04:11:37 *** weiY has quit IRC (Ping timeout: 244 seconds) 2012-06-03T04:15:25 *** weiY has joined #rtems 2012-06-03T04:57:26 *** weiY has quit IRC (Ping timeout: 252 seconds) 2012-06-03T04:57:58 *** weiY has joined #rtems 2012-06-03T05:11:07 *** xiangfu has joined #rtems 2012-06-03T05:27:07 *** sevikkk has quit IRC (Ping timeout: 245 seconds) 2012-06-03T05:43:56 *** sevikkk has joined #rtems 2012-06-03T05:44:19 *** xiangfu has quit IRC (Ping timeout: 245 seconds) 2012-06-03T05:50:52 *** xiangfu has joined #rtems 2012-06-03T06:14:36 *** sevikkk has quit IRC (Remote host closed the connection) 2012-06-03T06:18:01 *** sevikkk has joined #rtems 2012-06-03T08:14:28 *** xiangfu has quit IRC (Remote host closed the connection) 2012-06-03T09:01:25 *** weiY has quit IRC (Ping timeout: 248 seconds) 2012-06-03T09:06:49 *** arvind_khadri has joined #rtems 2012-06-03T09:11:02 *** weiY has joined #rtems 2012-06-03T11:03:00 *** weiY has quit IRC (Ping timeout: 252 seconds) 2012-06-03T11:48:29 *** sevikkk has quit IRC (Quit: Leaving.) 2012-06-03T11:53:45 *** sevikkk has joined #rtems 2012-06-03T12:43:52 *** sevikkk has quit IRC (Quit: Leaving.) 2012-06-03T13:00:23 *** sevikkk has joined #rtems 2012-06-03T13:40:13 *** QingPei has quit IRC (Quit: Leaving.) 2012-06-03T16:50:15 *** sevikkk has quit IRC (Quit: Leaving.) 2012-06-03T17:09:08 *** kiwichris has joined #rtems 2012-06-03T18:59:34 *** A0Sheds has quit IRC (Quit: puff of smoke) 2012-06-03T19:01:06 *** A0Sheds has joined #rtems 2012-06-03T19:01:07 *** A0Sheds has joined #rtems 2012-06-03T19:02:37 *** A1Sheds has joined #rtems 2012-06-03T19:08:16 *** kiwichris has quit IRC (Quit: This computer has gone to sleep) 2012-06-03T19:41:46 *** kiwichris has joined #rtems 2012-06-03T20:21:48 *** xiangfu has joined #rtems 2012-06-03T20:47:35 *** A1Sheds has quit IRC (Quit: puff of smoke) 2012-06-03T20:54:22 *** A1Sheds has joined #rtems 2012-06-03T21:36:50 *** xiangfu has quit IRC (Ping timeout: 244 seconds) 2012-06-03T21:40:42 *** QingPei has joined #rtems 2012-06-03T21:56:21 *** xiangfu has joined #rtems 2012-06-03T21:59:43 *** kiwichris has quit IRC (Quit: This computer has gone to sleep) 2012-06-03T22:10:43 *** xiangfu has quit IRC (Ping timeout: 265 seconds) 2012-06-03T22:57:18 *** arvind_khadri has quit IRC (Ping timeout: 260 seconds)