[seL4] am335x and question

Tim Newsham tim.newsham at gmail.com
Sat Feb 14 07:51:53 EST 2015


please ignore my "UART_PPTR" question, I read it backwards, oops.

Thank you Jordan, the workaround you mention fixes my MMU problem.
I am not sure why.

project tools/elfloader/
diff --git a/src/arch-arm/mmu-v7a.S b/src/arch-arm/mmu-v7a.S
index ce40478..3b02873 100644
--- a/src/arch-arm/mmu-v7a.S
+++ b/src/arch-arm/mmu-v7a.S
@@ -62,7 +62,7 @@ arm_enable_mmu:
      * Setup client to only have access to domain 0, and setup
      * the DACR.
      */
-    mov     r1, #1
+    mov     r1, #3      // XXX am335x hack, was 1.
     mcr     p15, 0, r1, c3, c0, 0

     /* Setup misc MMU. */

the test is now making it to userland, but not for long.. more bugs to hunt...


On Fri, Feb 13, 2015 at 10:08 AM, Jordan Woehr <jordanwoehr at gmail.com> wrote:
> Hi Tim,
>
> I believe I recently ran into the same problem as you on the am335x. I
> posted it to the mailing list, see
> http://sel4.systems/pipermail/devel/2015-January/000167.html
>
> Unfortunately I haven't found a solution to the problem yet except for
> working around it by modifying domain access bits in the MMU to allow full
> access instead of kernel access. I must be overlooking something because I
> would expect what is currently in the elfloader to work. After making this
> modification I am able to boot into the kernel successfully (I'm booting
> directly into the kernel though and not using seL4-test).
>
> The check for UART_PPTR < virt_region_start should be true on the am335x but
> may not be for other platforms.
>
> Jordan
>
> On Fri, Feb 13, 2015 at 12:59 PM, Tim Newsham <tim.newsham at gmail.com> wrote:
>>
>> I'm playing around with the am335x code now and have the
>> sel4 test building but not working properly.  If anyone else is
>> interested in playing with this, let me know.
>>
>> I have a question about the boot loader, I'm seeing:
>>
>>     if (UART_PPTR < kernel_info.virt_region_start) {
>>         printf("Jumping to kernel-image entry point...\n\n");
>>     } else {
>>         /* Our serial port is no longer accessible */
>>     }
>>
>> is this necessary?  It looks like init_boot_pd established a
>> 1:1 mapping for all addresses lower than the kernel vaddr
>> (which for me is 0xf0000000). Shouldnt the UART be accesible
>> here?
>>
>> I'm seeing the bootloader run up to mmu is turned on but nothing
>> after that and trying to track down where the failure is happening.
>> printf's after arm_enable_mmu are not working for me, and I don't
>> understand if this is due to mmu bringup problems or something else.
>>
>> By the way, I started a "#seL4" channel on freenode IRC.
>>
>> --
>> Tim Newsham | www.thenewsh.com/~newsham | @newshtwit |
>> thenewsh.blogspot.com
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at sel4.systems
>> https://sel4.systems/lists/listinfo/devel
>
>



-- 
Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com



More information about the Devel mailing list