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/803b92c7a3c9b48bd474b3de7ac9b8cb...).
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