I attached the Lauterbach and it seems when executing elf_getMemoryBounds()
it jumps to invalid memory region when initializing
uint64_t mem_min = UINT64_MAX;
Disassembled it seems it happens when executing this instruction:
vmov.64 d16,0xFFFFFFFFFFFFFFFF
Does somebody has an idea whats going wrong in that case?
Same thing happens when executing such code e.g. in platform_init().
Thanks!
Wladislav Wiebe
2017-01-16 14:17 GMT+01:00 Wladislav Wiebe <wladislav...@gmail.com>:
> another interesting thing is, even putting a debug print to:
> diff --git a/elfloader-tool/src/arch-arm/elf/elf.c
> b/elfloader-tool/src/arch-arm/elf/elf.c
> index 1751c5c..f16492d 100644
> --- a/elfloader-tool/src/arch-arm/elf/elf.c
> +++ b/elfloader-tool/src/arch-arm/elf/elf.c
> @@ -267,7 +267,7 @@ elf_getMemoryBounds(void *elfFile, int phys,
> uint64_t *min, uint64_t *max)
> uint64_t mem_min = UINT64_MAX;
> uint64_t mem_max = 0;
> int i;
> -
> + printf("init elf_getMemoryBounds\n");
>
>
>
> will not be visible in the startup anymore ..
>
>
> 2017-01-13 15:06 GMT+01:00 Wladislav Wiebe <wladislav...@gmail.com>:
>> Hi Alex,
>>
>> I am right now stopping u-boot before it changes to LPAE.
>> Boot log from u-boot shows:
>> [ 8.638] RAM Configuration:
>> [ 8.641] Bank #0: 80000000 2 GiB
>>
>> checking
>> [ 11.049] uboot# md 0x80000000
>> [ 30.803] 80000000: fffffffe ffffbcdd ffff79bc ffff369b .........y...6..
>> seems the memory is available and accessible.
>>
>> [ 30.912] uboot# md 0x82000000
>> [ 96.775] 82000000: 00000000 00000000 00000000 00000000 ................
>> shows empty memory.
>>
>> I am setting up the
>> "keystone")
>> ENTRY_ADDR=0x82008000
>>
>> Configuring the linkerl.lds to
>> KERNEL_BASE = 0xe0000000;
>> PHYS_BASE = 0x80000000;
>>
>>
>> and the hardware.h looks like:
>> #define physBase 0x80000000
>> #define kernelBase 0xe0000000
>>
>> static const kernel_frame_t BOOT_RODATA kernel_devices[] = {
>> {
>> /* UART */
>> UART0_PADDR,
>> UART0_PPTR,
>> true /* armExecuteNever */
>> }
>> };
>>
>> static const p_region_t BOOT_RODATA avail_p_regs[] = {
>> /* 2 GiB -1 page to prevent uin32_t overflow */
>> { /* .start = */ 0x80000000, /* .end = */ 0xfffff000 }
>> };
>>
>> static const p_region_t BOOT_RODATA dev_p_regs[] = {
>> { /* .start = */ UART0_PADDR, /* .end = */ UART0_PADDR + (1 <<
>> PAGE_BITS) }
>> };
>>
>> Now starting:
>>
>> [ 42.255] uboot# bootelf
>> [ 84.351] ## Starting application at 0x82008000 ...
>>
>> ELF-loader started on CPU: ARM Ltd. Cortex-A15 r2p4
>> paddr=[82008000..8232c41f]
>> load_images()
>> Load kernel
>> Load kernel - OK
>> elf_checkFile
>> elf_checkFile - OK
>> elf_getMemoryBounds
>>
>>
>> I added some debug prints to elfloader and seems to stop
>> again at elf_getMemoryBounds()
>>
>>
>> Let me know if you further suggestions on debugging this.
>>
>> Thanks!
>> - Wladislav Wiebe
>>
>>
>> 2017-01-13 3:59 GMT+01:00 <alexander.k...@data61.csiro.au>:
>>>
>>> Hi Wladislav,
>>>
>>> I don't have much experience with this platform, but can RAM be remapped
>>> to a lower physical address range by using the MPAX?
>>>
>>> Although you might have problems later regarding LPAE, your current
>>> issue might be unrelated. It could be memory corruption caused by
>>> conflicting/aliasing addresses for the bootloader, elfloader or their
>>> associated stacks.
>>>
>>> You could try changing the address at which the elfloader is loaded and
>>> executed:
>>> https://github.com/seL4/seL4_tools/blob/master/elfloader-tool/gen_boot_image.sh#L29
>>>
>>> - Alex Kroh
>>>
>>>
>>>
>>>
>>>
>>> On Fri, 2017-01-13 at 01:22 +0000, adrian.da...@data61.csiro.au wrote:
>>>> Hi Wladislav,
>>>>
>>>> The short answer is that LPAE is not currently used or supported by
>>>> seL4 and so you will not be able to describe physical memory that
>>>> resides above 4gb to it.
>>>>
>>>> Adrian
>>>>
>>>> On Fri 13-Jan-2017 12:20 AM, Wladislav Wiebe wrote:
>>>>
>>>> > Hello,
>>>> >
>>>> > I am trying to integrate TI Keystone 2 platform to seL4.
>>>> > What I have done so far is basically an initial port of the
>>>> > Kernel/libs/elfloader/Platform components
>>>> > and introducing a new keystone defconfig.
>>>> >
>>>> > Relevant config parts about the setup:
>>>> > CONFIG_ARCH_ARM_V7A=y
>>>> > CONFIG_ARCH_ARM=y
>>>> > CONFIG_ARCH_AARCH32=y
>>>> > CONFIG_ARM_CORTEX_A15=y
>>>> > CONFIG_PLAT_KEYSTONE=y
>>>> >
>>>> > At the end I am able to generate an image which looks like:
>>>> >
>>>> > $ arm-cortexa15-linux-gnueabihf-readelf -e
>>>> > images/sel4test-driver-image-arm-keystone
>>>> > ELF Header:
>>>> > Class: ELF32
>>>> > ..
>>>> > Entry point address: 0xc0008000
>>>> > ..
>>>> > (I am using the same entry point as Linux use it)
>>>> >
>>>> >
>>>> > So far, it stops booting in the elfloader -- output log:
>>>> > ..
>>>> > [ 29.705] ## Starting application at 0xc0008000 ...
>>>> >
>>>> > ELF-loader started on CPU: ARM Ltd. Cortex-A15 r2p4
>>>> > paddr=[c0008000..c032841f]
>>>> >
>>>> > -> Stop here <-
>>>> >
>>>> > Seems it stops loading @ elf_getMemoryBounds().
>>>> >
>>>> > I suppose it is related to fact that the physical start address
>>>> > starts @ 0x840000000 which is beyond 32 Bit - so, LPAE support is
>>>> > required.
>>>> >
>>>> > The physical RAM setup looks like:
>>>> > bank 0:
>>>> > addr: 0x840000000
>>>> > size: 0x17ec5000 (382 MB)
>>>> >
>>>> > bank 1:
>>>> > addr: 0x880000000
>>>> > size: 0x80000000 (2048 MB)
>>>> >
>>>> > Do you have an idea if this is supposed to be supported on seL4?
>>>> > What should be the "physBase" and the "kernelBase" for such a setup?
>>>> > How should the "static const p_region_t BOOT_RODATA avail_p_regs" looks
>>>> > like?
>>>> >
>>>> > Thanks in advance!
>>>>
>>>> _______________________________________________
>>>> Devel mailing list
>>>> Devel@sel4.systems
>>>> https://sel4.systems/lists/listinfo/devel
>>>
>>
>>
>>
>> --
>> WBR, Wladislav WIebe
>
>
>
> --
> WBR, Wladislav WIebe
--
WBR, Wladislav WIebe
_______________________________________________
Devel mailing list
Devel@sel4.systems
https://sel4.systems/lists/listinfo/devel
