2013-09-09T00:28:15 *** monstr has joined #rtems 2013-09-09T00:35:20 *** the9a3eedi has quit IRC (Read error: Connection reset by peer) 2013-09-09T00:40:50 *** the9a3eedi has joined #rtems 2013-09-09T01:46:17 *** sebhub has joined #rtems 2013-09-09T01:46:25 good morning 2013-09-09T02:39:57 Finally got the task working on RTL :D still needs a bit of debugging though. Again thanks kiwichris and freenix 2013-09-09T02:40:27 the9a3eedi, great news. I have pushed all of Peng's changes to my repo. 2013-09-09T02:41:30 the9a3eedi, I am working through some changes with the rtl-host tools. I will split the rtems-ra tools into rtems-ar to allow RAP files to be managed in archives like ELF objects in a .a archive. 2013-09-09T02:44:38 ah yes, gsoc deadline is soon right? Everything is getting wrapped up I suppose 2013-09-09T02:47:39 Yes it is close to the end. 2013-09-09T02:48:05 This is just about making the tools needed to manage applications appear similar to the standard tools so the learning curve is less 2013-09-09T02:48:47 good stuff 2013-09-09T04:03:28 *** phipse has joined #rtems 2013-09-09T04:10:26 *** the9a3eedi has quit IRC (Ping timeout: 245 seconds) 2013-09-09T04:50:35 *** mwalle has quit IRC (Quit: WeeChat 0.3.8) 2013-09-09T07:30:42 Has someone experience with transitions to user space and back during an ISR? 2013-09-09T07:31:50 To be more precises: I want to execute some code in user mode during an ISR and then finish the ISR in kernel mode. 2013-09-09T07:59:30 *** antgreen has quit IRC (Read error: Operation timed out) 2013-09-09T08:01:19 in rtems there is no user/kernel space separation 2013-09-09T08:30:56 In my gsoc project I am working with POK as host. To get the RTEMS guest notified about the IRQ I need to call the handler with the RTEMS environment. 2013-09-09T08:31:58 But I need to get back into the kernel, after the user space handler is done. maybe someone has experience with something similar? 2013-09-09T08:35:59 which context is interrupted by the ISR? 2013-09-09T08:38:52 you mean kernel or user space? 2013-09-09T08:40:51 Normally it should be the user space, meaning the RTEMS partition. 2013-09-09T08:41:19 (or any other partition) 2013-09-09T08:51:48 does the ISR interrupt the RTEMS context? 2013-09-09T08:52:50 yes 2013-09-09T08:54:11 ok, then why can't you use the normal ISR entry/exit code? 2013-09-09T08:55:06 because, I run RTEMS virtualized as a POK partition and the interrupt invokes the POK kernel and not the rtems kernel 2013-09-09T08:56:00 sry, I have too little knowledge of this POK stuff to help here 2013-09-09T08:57:20 It's not the pok stuff I have a problem with, it's the transition between kernel mode and user mode done in asm 2013-09-09T08:57:52 thanks anyway 2013-09-09T08:58:11 *** gedare has joined #rtems 2013-09-09T09:05:30 Is there a way to (magically) acquire variables defined in the user's CS/DS and change them from the kernel space? And (magically) find out which variables are touched by the user's ISR? 2013-09-09T09:05:50 s/ISR/handler/ 2013-09-09T09:07:06 on standard x86 RTEMS the address space in kernel and user space should be identical 2013-09-09T09:11:58 I was thinking more general x86 here, where user and kernel space aren't identical. 2013-09-09T09:12:54 But I am getting to the point where I need to accept that my design might not work. 2013-09-09T09:19:14 if kernel code knows where the registers are saved, it should be possible. 2013-09-09T09:20:00 i doubt there is any way to detect what memory was modified by an ISR efficiently though. 2013-09-09T09:20:49 hmm, the kernel would need to have the symbol table for the program 2013-09-09T09:21:06 and then it would only give it the globally defined symbols 2013-09-09T09:21:33 just looking at a segment would not work out, because there is not enough information about what the memory layout is. 2013-09-09T09:22:26 what's the problem you try to solve? 2013-09-09T09:23:32 I will forward you the email from the POK list. 2013-09-09T09:24:25 I need to run an ISR handler from the user space (read pok partition) inside the pok kernel and then finish the ISR 2013-09-09T09:24:58 ahh. 2013-09-09T09:25:40 Isr occurres, kernel handler runs, $1, user handler runs, $2, isr finish, iret. whereas $1 is a transititon from kernel space to user space and $2 the transition back (which should be impossible for security reasons, shouldn't it?). 2013-09-09T09:26:50 $2 should be accomplished by a trap 2013-09-09T09:26:53 or a syscall 2013-09-09T09:27:20 but I need to jump to the right place and finish the isr. 2013-09-09T09:27:58 you could store the context somewhere before $1, and restore that context in a syscall at $2 2013-09-09T09:28:03 it might work... 2013-09-09T09:28:18 pretty hackish. 2013-09-09T09:28:19 and how do I check if an ISR is running, which would be the only case this syscall would be justified? 2013-09-09T09:28:29 the structure is valid? 2013-09-09T09:28:34 the stored context that is 2013-09-09T09:28:49 there might be TOCTOU issues, but otherwise it might be OK 2013-09-09T09:28:56 TOCTOU? 2013-09-09T09:29:01 time-of-check, time-of-use 2013-09-09T09:29:24 actually slightly different problem arises in the situation i describe 2013-09-09T09:29:28 if you store something before $1 2013-09-09T09:29:33 and check that thing in $2 2013-09-09T09:29:38 you don't know that it was the ISR that called $2 2013-09-09T09:29:47 you just know that something called $2 after $1 2013-09-09T09:29:57 hm. 2013-09-09T09:29:59 by now I doubt the design will work. However I had the base_sp sample running magically. by now it is broke again ;) 2013-09-09T09:30:06 heh 2013-09-09T09:30:26 But at least I have a proving screenshow :P 2013-09-09T09:30:30 *screenshot 2013-09-09T09:30:48 other OSs provide user-level drivers, they must go through a similar transition? 2013-09-09T09:32:47 I am looking at the L4 code at the moment, maybe I find something, there the vCPU interface is passing along interrupts to the virtual guest too. But I haven't found the right code yet. 2013-09-09T09:33:08 ok. maybe it does the guest ISRs after the kernel finishes? 2013-09-09T09:33:42 if i were doing it, i would probably set up a list of ISRs to run in guest space during my kernel handler, and schedule those ISRs in a schedulable thread outside of the ISR mode. 2013-09-09T09:33:53 rather, that is the design that first comes to mind. 2013-09-09T09:34:55 i dunno. there must be some answers that exist. 2013-09-09T09:35:55 I thought about just sending the irq to RTEMS and let RTEMS deal with this internally 2013-09-09T09:37:04 but this wouldn't be paravirtualization anymore ;) 2013-09-09T09:39:02 ok so.. 2013-09-09T09:39:46 the guest ISR could be given a 'context' argument by $1, which it returns when it traps into the $2 syscall? 2013-09-09T09:40:27 this context would match against something the host can verify and use to determine which ISR to continue/finish? 2013-09-09T09:40:41 something about this design just does not seem right. 2013-09-09T09:40:53 yes 2013-09-09T09:40:54 I find it bothersome that the kernel will wait for the user. 2013-09-09T09:45:15 What I can't do is using the IDT of the CPU for the RTEMS guest, so I would need to build an software idt to lookup the handler, a signal notifying RTEMS to schedule the table-lookup routine. I don't know such a signal. 2013-09-09T09:47:51 I cannot change a value inside RTEMS from the kernel without changing to user space. So I cannot build a table logging the occurred interrupts. And beginning with the clock interrupt I won't have a signal running the scheduler, which would lead to checking this table. 2013-09-09T09:49:56 Your proposed must run next to RTEMS in the partition to get the same user space, but needs to be scheduled by the pok kernel, as it delivers the clock tick to RTEMS 2013-09-09T09:53:23 so right now you switch to the user-space successfully? 2013-09-09T09:53:55 or not? 2013-09-09T09:54:15 no, something isn't working correctly, but I haven't found it yet 2013-09-09T09:55:48 oh, ok. 2013-09-09T09:59:13 then i think the best thing to do is figure out how others accomplish calling user-space code from the kernel. :) 2013-09-09T09:59:20 which it sounds like you are doing, with L4. 2013-09-09T10:04:20 it looks like I need to redesign this stuff 2013-09-09T10:05:12 *** sebhub has quit IRC (Ping timeout: 256 seconds) 2013-09-09T10:12:07 :( 2013-09-09T10:38:09 no time to be sad, there is enough to do ;) I can't continue with the virtual clock handler in RTEMS. Currently it doesn't register it right and then everything crashes due to a null pointer call 2013-09-09T10:38:23 s/can't/can 2013-09-09T10:38:44 good. did your school start up yet? 2013-09-09T10:39:26 no, it starts again in the mid of october 2013-09-09T10:40:20 ok good 2013-09-09T10:44:47 *** antgreen has joined #rtems 2013-09-09T12:08:39 *** Hesham-- has joined #rtems 2013-09-09T12:08:57 Hi gedare 2013-09-09T12:09:01 hey 2013-09-09T12:09:12 good. let's start with patch 0000. 2013-09-09T12:09:19 been awhile since we chatted. 2013-09-09T12:09:39 sure 2013-09-09T12:09:47 i thought we mentioned putting the mm_lock into a structure? 2013-09-09T12:10:26 That's for POSIX work yes, I can implement it now. 2013-09-09T12:10:42 oh ok. it might also be sensible for the supercore interfaces 2013-09-09T12:11:12 especially it would be good if you can implement most of the posix stuff within supercore, and just provide the posix interface functions 2013-09-09T12:11:17 maybe good, i don't know 2013-09-09T12:11:33 this is often an approach taken in rtems, to implement in score, and provide thin interface in posix 2013-09-09T12:11:46 it depends on whether the implementation might be shareable. 2013-09-09T12:11:54 maybe for now don't worry about that though... 2013-09-09T12:11:59 I noticed that the code for mmap used this kind of lock encapsulation too. 2013-09-09T12:12:04 ok 2013-09-09T12:12:13 we can just note it and mark it for future improvement 2013-09-09T12:12:25 Yes, page-tables are shareable 2013-09-09T12:12:39 or, if it makes sense when you do the posix implementation you can update the score one. 2013-09-09T12:12:45 ok, good. that is all for patch 0. 2013-09-09T12:13:01 oh wait 2013-09-09T12:13:05 there should be better doxygen ;) 2013-09-09T12:13:11 this documentation is very light. 2013-09-09T12:13:24 Ok marked as TODO for the next patch 2013-09-09T12:13:39 I know 2013-09-09T12:13:43 ok 2013-09-09T12:13:55 it can be worked on after pencils down 2013-09-09T12:14:21 ok patch 0002 2013-09-09T12:14:23 Maybe in the final week if that's not urgently 2013-09-09T12:14:25 yeah 2013-09-09T12:14:47 you should try to give useful commit messages on these patches. 2013-09-09T12:14:54 when you do submit them 2013-09-09T12:15:20 0002 is libcpu-shared right ? 2013-09-09T12:15:24 You mean at github ? 2013-09-09T12:15:36 yes. from the ones you emailed me 2013-09-09T12:15:43 when you squash them for submission 2013-09-09T12:16:20 you should make a branch, rebase your commits, give them useful commit messages, and use git-format-patch to create the patches 2013-09-09T12:16:33 that way we will have useful commit messages and also have your authorship info embedded in the patch. 2013-09-09T12:16:49 I squashed them for one commit, because I remember Chris or Sebastian said before that you are concerned with the final work 2013-09-09T12:16:58 All commit messages are at github 2013-09-09T12:17:14 ok. patch 0002 looks ok. the only issue i see is that we are mixing libcpu and libbsp definitions a little bit, because of the issue from the mm_init 2013-09-09T12:17:24 I just create local tmp branch to generate these squashed patches 2013-09-09T12:17:51 yeah it is good to do, i'm just saying that when you finally submit, you can also give the squased commits some good messages 2013-09-09T12:18:22 Sure, I can do that. 2013-09-09T12:18:45 ok, we should consider moving the entire libcpu layer into libbsp/shared 2013-09-09T12:19:02 That's issue no.3 (after doxygen and lock struct) 2013-09-09T12:19:10 ok 2013-09-09T12:19:21 moving on to patch 3 2013-09-09T12:19:35 I have some concerns about moving the entire libcpu to libbsp 2013-09-09T12:20:08 Dr Joel said that Cache defines should be kept at libcpu 2013-09-09T12:20:29 If we are willing to unify Cache manager with libmm, I think that will raise a problem 2013-09-09T12:21:07 don't worry about the cache manager issue for now 2013-09-09T12:21:34 i think the momentum is starting to get rid of libcpu and turn it into libbsp/shared code. 2013-09-09T12:21:42 OK, that means the only files to be moved are the shared mm.h header and stubs 2013-09-09T12:21:49 correct. 2013-09-09T12:22:12 and rename _CPU_Memory_management_Set_attributes() -> bsp_memory_management_set_attributes() 2013-09-09T12:23:07 I kept it for the previously mentioned reason too, but now it's OK I will rename it. 2013-09-09T12:24:07 Moving to 4 ? 2013-09-09T12:24:18 yeah. patch 3 seems ok to me. it will be up to sebhub really 2013-09-09T12:24:53 ok, what does this do: 2013-09-09T12:24:56 ttb [i] = (i << ARM_MMU_SECT_BASE_SHIFT) | ARMV7_MMU_DATA_READ_WRITE; 2013-09-09T12:25:34 Yes, Sebastian set it as unmapped 2013-09-09T12:25:44 or fault sections = 0 2013-09-09T12:26:22 what is this code doing, and why do you need it? 2013-09-09T12:26:29 same with the change to: 2013-09-09T12:26:34 + ctrl |= ARM_CP15_CTRL_AFE | ARM_CP15_CTRL_S | ARM_CP15_CTRL_I | 2013-09-09T12:26:34 + ARM_CP15_CTRL_C | ARM_CP15_CTRL_M | ARM_CP15_CTRL_XP; 2013-09-09T12:27:24 I preferred to set it as READ_WRITE (and maybe cached) as the default behavior for RTEMS is "there is no protection" and the new behavior now is that we can set protection. 2013-09-09T12:27:58 for ctrl, the new flags are for raspberry ARM core (ARMv6) 2013-09-09T12:28:02 ok 2013-09-09T12:28:27 will they be ok for the other arm targets that use this already? 2013-09-09T12:28:28 It does not affect realview or xilinx behavior 2013-09-09T12:28:30 ok 2013-09-09T12:28:50 you should change " /* Initialize translation table with invalid entries */" 2013-09-09T12:29:07 the comment to reflect the new approach off setting up default entries with valid settings 2013-09-09T12:29:12 Yes sure, I re-built every BSP and make sure test cases run after any new modification 2013-09-09T12:29:39 Sure, part of the doxygen comment task 2013-09-09T12:29:44 1 sec phone 2013-09-09T12:30:16 tyt, I will be back in about 5 minutes too. 2013-09-09T12:30:55 k 2013-09-09T12:32:38 *** antgreen has quit IRC (Ping timeout: 264 seconds) 2013-09-09T12:37:17 Back, let's continue ? 2013-09-09T12:39:58 still on phone 2013-09-09T12:40:27 OK tyt, I am not in hurry 2013-09-09T12:48:20 *** antgreen has joined #rtems 2013-09-09T12:53:57 ok Hesham-- 2013-09-09T12:54:03 you ready to proceed? 2013-09-09T12:55:17 Yeah 2013-09-09T12:55:17 still on patch 0004 2013-09-09T12:55:20 arm_cp15_start_setup_mmu_and_cache 2013-09-09T12:55:22 erm 2013-09-09T12:55:28 -BSP_START_TEXT_SECTION static inline uint32_t 2013-09-09T12:55:28 +BSP_START_TEXT_SECTION inline uint32_t 2013-09-09T12:55:32 why did you remove "static" 2013-09-09T12:56:09 Do not remember actually why I did this 2013-09-09T12:56:18 ok i suggest you restore it 2013-09-09T12:56:24 seems like it should be 2013-09-09T12:56:24 OK 2013-09-09T12:56:45 ok, the monster macro for "translate_attributes()" should have some brief comments 2013-09-09T12:57:03 where did this macro come from? 2013-09-09T12:57:07 Sure 2013-09-09T12:57:08 you wrote it? 2013-09-09T12:57:11 Yes 2013-09-09T12:57:32 and according to Sebastian suggestion of how flags should be translated 2013-09-09T12:57:38 you might consider simplifying it by introducing another macro that does a "check_attribute()" 2013-09-09T12:57:38 at the mailing list 2013-09-09T12:58:01 ok 2013-09-09T12:58:26 like, check_attribute(attr, RTEMS_MM_REGION_BIT_WRITE, 0U, ARM_MMU_SECT_AP_2) 2013-09-09T12:58:32 How could check_attribute() simplify the old one 2013-09-09T12:58:54 I see 2013-09-09T12:59:04 It returns 1 or 0 ? 2013-09-09T12:59:05 where check_attribute(a,b,c,d) ((a)>>b)&1U)?c : (d) 2013-09-09T12:59:10 sorry not really check_Attribute 2013-09-09T12:59:12 more like... 2013-09-09T12:59:18 is_XXX 2013-09-09T12:59:21 set_attribute_if() 2013-09-09T12:59:22 or shwatever 2013-09-09T12:59:23 yeah 2013-09-09T12:59:30 ok I got it 2013-09-09T12:59:30 that encodes all of your repeated logic 2013-09-09T12:59:36 that will make this much nicer to read. 2013-09-09T12:59:48 Sure I agree 2013-09-09T13:00:10 why is end uint32_t and not uintptr_t? 2013-09-09T13:00:18 it should be pointer type 2013-09-09T13:00:34 it probably is uint32_t for this architecture, but it is better to be generic 2013-09-09T13:00:58 OK 2013-09-09T13:02:01 also, you don't need to make those variables 2013-09-09T13:02:07 that's a nitpick on my side though :) 2013-09-09T13:02:21 this function could be just: 2013-09-09T13:02:35 arm_cp15_set_translation_table_entries(base, base + (uintptr_t)size, translate_attributes(attr)); 2013-09-09T13:03:14 I just wanted to make the code more readable, is not the compiler optimizing it anyway ? 2013-09-09T13:03:19 yeah it shouldn't matter 2013-09-09T13:03:23 either way 2013-09-09T13:03:33 don't worry about it 2013-09-09T13:03:51 for bsp_memory_management_Initialize 2013-09-09T13:03:57 the I should be lower-case i 2013-09-09T13:03:58 Ok, I can make it (optional) TODO :) 2013-09-09T13:04:12 fix that in the other patches too. 2013-09-09T13:04:30 and, the function declaration should not be in mminit.c 2013-09-09T13:04:34 there should be an include file 2013-09-09T13:04:48 (I think already it is in libmm.h?" 2013-09-09T13:05:13 + arm_cp15_start_setup_translation_table_and_enable_mmu_and_cache( 2013-09-09T13:05:13 + ctrl, 2013-09-09T13:05:13 + (uint32_t *) bsp_translation_table_base, 2013-09-09T13:05:13 + ARM_MMU_DEFAULT_CLIENT_DOMAIN, 2013-09-09T13:05:13 + &_cpu_mmu_config_table[0], 2013-09-09T13:05:13 + RTEMS_ARRAY_SIZE(&_cpu_mmu_config_table) 2013-09-09T13:05:13 I remember you suggested to move prototype to mminit.c and keep both prototype and implementation in one file 2013-09-09T13:05:15 + ); 2013-09-09T13:05:21 the nested lines should be space-indented 2013-09-09T13:05:33 hmm, no. prototype should be in a .h file. 2013-09-09T13:05:56 if you move libmm to libbsp/shared, it will be 2013-09-09T13:06:13 I think I misunderstood this 2013-09-09T13:06:16 ok 2013-09-09T13:08:36 What else other that nested lines spaces ? 2013-09-09T13:10:25 did you copy this mminit code from somewhere? 2013-09-09T13:11:23 or you generalized this from the other arm code? 2013-09-09T13:11:23 mminit was initially form mm.c 2013-09-09T13:12:09 ah, ok 2013-09-09T13:12:59 oh, when you change the libmm to be in libbsp, you'll have to relocate the code we commited for arm920/powerpc 2013-09-09T13:13:00 I use arm_cp15_start_setup_translation_table_and_enable_mmu_and_cache function, It was called at bspstarthook.c for realview/xilinx 2013-09-09T13:13:04 ok 2013-09-09T13:13:06 I made it working for rpi 2013-09-09T13:13:18 ok looks good.. 2013-09-09T13:13:48 moving on to patch 5 2013-09-09T13:13:49 I will try to merge mm.c/mminit with arm920 code too 2013-09-09T13:13:54 ok 2013-09-09T13:15:44 in rpi's linkcmds, does RAM and RAM_MMU overlap? 2013-09-09T13:16:42 RAM_MMU is part of RAM (the last 16 KB of RAM) 2013-09-09T13:17:36 It's for first-level page table (sections' entries) 2013-09-09T13:17:58 ok 2013-09-09T13:19:48 that is a problem 2013-09-09T13:20:28 i think? 2013-09-09T13:20:29 hm 2013-09-09T13:20:36 Why ? 2013-09-09T13:20:58 i think the rtems workspace/heap will overlap with the RAM_MMU? 2013-09-09T13:20:58 The board that Alan worked on is 128 M 2013-09-09T13:21:29 Nope 2013-09-09T13:21:52 Sorry, RAM_MMU is not part of RAM 2013-09-09T13:21:53 RAM (AIW) : ORIGIN = 0x00008000, LENGTH = 128M - 0x8000 2013-09-09T13:22:29 The top limit of RAM is 16 KB less than 128M 2013-09-09T13:23:25 no 2013-09-09T13:23:26 the bottom is 32KB offset from 0 2013-09-09T13:23:26 the top is aligned to 128M 2013-09-09T13:23:34 you need to carve out another 16K from the top in order to fit the RAM_MMU in 2013-09-09T13:23:40 i think 2013-09-09T13:23:50 you should do some testing perhaps to see 2013-09-09T13:25:16 Making length of RAM = 128M - 16KB solve this ? 2013-09-09T13:25:28 no... 2013-09-09T13:25:42 RAM length in RPI is 128M - 32K right now 2013-09-09T13:25:45 you take out another 16K 2013-09-09T13:25:51 so you want it to be 128M - 48K 2013-09-09T13:25:54 right? 2013-09-09T13:26:15 because of the RAM_VECTOR at the lower 32KB 2013-09-09T13:26:25 rather, VECTOR_RAM. 2013-09-09T13:26:56 I am not concerned with bottom RAM_VECTOR area 2013-09-09T13:27:04 ... 2013-09-09T13:27:13 VECTOR_RAM starts at 0x0 and occupies 32KB 2013-09-09T13:27:20 RAM starts at 32KB and occupies the remaining 128M 2013-09-09T13:27:29 you want to place RAM_MMU at 128M - 16K 2013-09-09T13:27:43 Ok I see yes 2013-09-09T13:27:44 this means RAM now starts at 32KB and occupies the remainder - 16K 2013-09-09T13:27:47 ok. 2013-09-09T13:27:55 so RAM is 128M - 48K 2013-09-09T13:27:56 I will do my calculations 2013-09-09T13:27:57 ok 2013-09-09T13:28:14 I got it 2013-09-09T13:28:33 for mm_config_table.h, you copied the approach taken in some of the other ARM BSPs 2013-09-09T13:28:45 but you did not name it as "raspberrypi_mmu_config_table 2013-09-09T13:28:46 Yes 2013-09-09T13:28:46 why not? 2013-09-09T13:29:22 oh i see 2013-09-09T13:29:23 Because mminit.c is shared 2013-09-09T13:29:28 you generalize the config tables 2013-09-09T13:29:49 It uses general mmu_config_table 2013-09-09T13:30:03 ok. i'm not sure about the name you chose though 2013-09-09T13:30:21 We can change the name, not a problem 2013-09-09T13:31:21 yeah. i think maybe bsp_mmu_config_table. 2013-09-09T13:31:26 but, names of tables for different BSPs can not vary, because mminit uses the same and its shared for ARM 2013-09-09T13:31:39 Sure 2013-09-09T13:32:08 We can make it bsp_mm_config_table. 2013-09-09T13:32:14 change the +#include to be #include 2013-09-09T13:32:22 in the BSP directories 2013-09-09T13:32:32 I think they only should be accessing the bsp interfaces to libmm 2013-09-09T13:33:38 sebhub may have other comments on these changes of course. 2013-09-09T13:33:50 Where is change the +#include ? 2013-09-09T13:34:38 search patch 5 for score/mm.h 2013-09-09T13:34:49 c/src/lib/libbsp/arm/realview-pbx-a9/startup/bspstarthooks.c 2013-09-09T13:35:42 i think this mm_config_table.h design is weird 2013-09-09T13:35:56 it should probably be mm_config_table.c 2013-09-09T13:36:36 with a declaration of the array at arm-cp15-start.h 2013-09-09T13:37:28 mm_config_table was containing a the translation macro before, that's why it was a header, it make since to make it a source file now. 2013-09-09T13:37:34 ok 2013-09-09T13:39:12 moving on to patch 6 2013-09-09T13:39:17 Yes one other issue 2013-09-09T13:39:20 yes? 2013-09-09T13:39:50 I made it a header so that I can use the size_of (mm_config_table) 2013-09-09T13:40:03 ah. 2013-09-09T13:40:26 does this work... 2013-09-09T13:40:26 If it was a c file and I use extern 2013-09-09T13:40:33 it does not work 2013-09-09T13:40:46 extern const int mm_config_table_size; 2013-09-09T13:41:07 const int mm_config_table_size = sizeof(bsp_mmu_config_table); 2013-09-09T13:41:12 Yes, if I defined a new mm_config_table_size at the c file 2013-09-09T13:41:47 try that out i guess. give it a proper name since it is a global symbol 2013-09-09T13:41:50 a new "size" variable that's defined at BSP/startup and externed at mminit 2013-09-09T13:42:42 bsp_mm_config_table_size ? 2013-09-09T13:42:57 in mmtest1, get rid of unused variables (a1, s2, a), and make size, region1, and region2 local variables inside of Init(). 2013-09-09T13:43:04 sure 2013-09-09T13:43:42 where the table is called bsp_mm_config_table[] 2013-09-09T13:43:43 Ok 2013-09-09T13:44:06 um, one other issue 2013-09-09T13:44:18 i don't think the definition of _cpu_mmu_config_table[] should be static. 2013-09-09T13:44:35 (rather, bsp_mm_config_table[]) 2013-09-09T13:45:28 It's public, why should it be static ? 2013-09-09T13:45:46 I think it should not be 2013-09-09T13:45:49 "I don't think" 2013-09-09T13:45:55 ah sorry 2013-09-09T13:46:23 I agree with you 2013-09-09T13:46:44 do the same thing to mmtest2 as you do for mmtest1 2013-09-09T13:47:09 fix the .scn file for both mmtest1 and mmtest2. 2013-09-09T13:47:11 I think all variables at mmtest2 are used 2013-09-09T13:47:18 ok, but make them local 2013-09-09T13:47:22 ok 2013-09-09T13:47:28 other than the global memory_pool 2013-09-09T13:47:34 which should stay global so you don't smash your stack 2013-09-09T13:47:42 but can be declared static 2013-09-09T13:47:49 static char memory_pool[] 2013-09-09T13:47:54 ok sure 2013-09-09T13:48:07 doesn't matter much, but it is good programming practice 2013-09-09T13:48:15 Yes sure 2013-09-09T13:48:20 um 2013-09-09T13:48:26 What about BSPs that are less than 1M ? 2013-09-09T13:48:27 i don't think fatal_extension should be static 2013-09-09T13:48:48 i'm not sure what we should do yet. 2013-09-09T13:49:16 probably not worry for now. 2013-09-09T13:49:19 ok, let's deal with this issue later 2013-09-09T13:49:22 yeah. 2013-09-09T13:49:28 plenty of fixes for you to do 2013-09-09T13:49:37 That's all ? 2013-09-09T13:49:42 once you get these things fixed, i think you can send your patches directly to rtems-devel 2013-09-09T13:49:49 make sure you create useful commit messages for them 2013-09-09T13:50:01 Sure 2013-09-09T13:50:02 use git-format-patch to create them with commit messages and authorship info. 2013-09-09T13:50:23 oh um 2013-09-09T13:50:24 I will spend tonight fixing these issues 2013-09-09T13:50:45 put MAX_TASKS to 1 or 2 2013-09-09T13:50:52 and get rid of CONFIGURE_MEMORY_OVERHEAD 2013-09-09T13:51:28 I think mmtests do not work without CONFIGURE_MEMORY_OVERHEAD *** 2013-09-09T13:52:15 they should now if you do not allocate from workspace 2013-09-09T13:52:22 you needed it before when you were using workspace allocate 2013-09-09T13:53:38 I might remember that this macro affected test even with new memory_pool, but anyway I will git rid of it and tell you if there were any problems. 2013-09-09T13:54:27 That's all ? 2013-09-09T14:00:02 yup 2013-09-09T14:01:30