Thanks for the suggestion Bob. I have tried setting these bits when no
success. I haven't had a chance to look into the issue further but will
make sure to let the list know what I find when I do.

Jordan

On Thu, Jan 15, 2015 at 5:11 AM, <[email protected]> wrote:

> I had the same issue with an AM335x processor based SoC when using the
> Genode kernel. The issue related to TLB entry attributes: The Am335X
> processors expects cacheability to be:
> Inner --Write-thru, No Write Allocate
> Outer -- Write-back, Write Allocate.
>
> So, based on the info in the ARM Architecture Ref Manual for the Arm_v7
> (pp 1368), I set the attributes in memory_region_attr (Genode 13.08) to :
>
> Device memory:
>          Tex::bits(0) | C::bits(0) | B::bits(1);
>
> Cacheable memory
>          Tex::bits(5) | C::bits(1) | B::bits(0);
>
> Non-cacheable memory
>          Tex::bits(6) | C::bits(1) | B::bits(0);
>
> The above syntax is from Genode code but you can see the bit settings
> needed to create valid TLB entries for this processor.
>
> Hope this helps.
>
>   Bob Stewart
>
> Sent from my android device.
>
>
> -----Original Message-----
> From: Jordan Woehr <[email protected]>
> To: [email protected]
> Sent: Wed, 14 Jan 2015 12:33 PM
> Subject: [seL4] Elfloader faults when MMU activated
>
> Hello,
>
> I am attempting to boot the seL4 kernel (only the kernel, not the
> platform library) on an AM335x chip and am running into difficulties
> when the elfloader enables the MMU. Debug statements indicate that the
> enable_mmu function is not returned from, thus I believe a fault is
> occuring when the processor attempts to execute the first instruction
> following the MMU being enable. Unfortunately I do not have access to
> a JTAG debugger at the moment, so I will relay what information I can.
> I should also mention that I have made no changes to the elfloader
> source code except where noted for debugging purposes.
>
> I have verified that the page table is being setup for supervisor
> access (access protection bit 10 set, bit 11 clear) and that the
> domain is set to 0 for all pages. As I understand it, this means that
> the permissions set in the domain access control register are checked.
> I am booting the elfloader through uboot and since the co-processor
> registers are accessible, I believe I am already in supervisor mode.
> Thus it would seem the elfloader code should work without
> modification. However, the only way I have found to get the kernel to
> boot is by setting access control for domain 0 to manager (write 3
> instead of 1 at
>
> https://github.com/seL4/elfloader-tool/blob/803b92c7a3c9b48bd474b3de7ac9b8cbde155456/src/arch-arm/mmu-v7a.S#L65).
>
> From my examination of the code, I don't believe this should be
> necessary, so I think I have probably configured the project
> incorrectly or am loading the image with uboot somehow incorrectly
> (for the record, I objcopy the elfloader elf to a bin and load the
> image through uboot to memory address 0x82000000 and perform a go
> command).
>
> What confuses me is that if I leave access to the domain set as client
> (no change from what is on the master branch) and instead set the
> permission on the page to bit 10 and bit 11 both set, the processor
> still faults. I would expect this configuration to not produce a fault
> since these permissions should allow supervisor and non-supervisor
> read/write access.
>
> Finally, the code is executing in a region that is 1:1 mapped after
> the MMU is enabled, so I don't think this is a problem.
>
> With all that said, does anyone have any idea why the elfloader isn't
> working out of the box for me? As I understand things, using the
> elfloader is the standard way to boot the kernel on an arm processor.
>
> I have included the options of my build configuration at the end of
> this message.
>
> Thank you for your time,
> Jordan
>
> CONFIG_ARCH_ARM_V7A=y
> CONFIG_ARCH_ARM=y
> CONFIG_ARM_CORTEX_A8=y
> CONFIG_PLAT_AM335X=y
> CONFIG_ROOT_CNODE_SIZE_BITS=16
> CONFIG_TIMER_TICK_MS=2
> CONFIG_TIME_SLICE=5
> CONFIG_RETYPE_FAN_OUT_LIMIT=256
> CONFIG_MAX_NUM_WORK_UNITS_PER_PREEMPTION=100
> CONFIG_MAX_NUM_BOOTINFO_DEVICE_REGIONS=199
> CONFIG_MAX_NUM_BOOTINFO_UNTYPED_CAPS=167
> CONFIG_FASTPATH=y
> CONFIG_NUM_DOMAINS=1
> CONFIG_DOMAIN_SCHEDULE=""
> CONFIG_NUM_PRIORITIES=256
> CONFIG_DEBUG_BUILD=y
> CONFIG_IRQ_REPORTING=y
> CONFIG_OPTIMISATION_O2=y
> CONFIG_LIB_SEL4=y
> CONFIG_LIB_MUSL_C=y
> CONFIG_HAVE_LIBC=y
> CONFIG_HAVE_CRT=y
> CONFIG_LIB_CPIO=y
> CONFIG_LIB_ELFLOADER=y
> CONFIG_ARM_ERRATA_764369=y
> CONFIG_CROSS_COMPILER_PREFIX="arm-none-eabi-"
> CONFIG_KERNEL_COMPILER=""
> CONFIG_KERNEL_CFLAGS=""
> CONFIG_KERNEL_EXTRA_CPPFLAGS=""
> CONFIG_USER_EXTRA_CFLAGS=""
> CONFIG_USER_CFLAGS=""
> CONFIG_USER_OPTIMISATION_O2=y
> CONFIG_USER_DEBUG_BUILD=y
>
> _______________________________________________
> Devel mailing list
> [email protected]
> https://sel4.systems/lists/listinfo/devel
>
_______________________________________________
Devel mailing list
[email protected]
https://sel4.systems/lists/listinfo/devel

Reply via email to