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

_______________________________________________
Devel mailing list
Devel@sel4.systems
https://sel4.systems/lists/listinfo/devel

Reply via email to