ARM bare metal application test

ARM bare metal application test

[Ivan Pavić2]

Hello,

I'm trying to build simple bare metal application on ARM Cortex A7.
I reached the phase in which I successfully created domain. Now,
I would like to check if application is really running (it runs according
xl list). But i need some simple interaction or at least console output.

So far this is my code:

    .section ".start", "x"
    .align
    .globl    _start

_start:
    @ zImage header
.rept   8
    mov     r0, r0
.endr
    b       work
    .word   0x016f2818      @ Magic numbers to help the loader
    .word   _start          @ absolute load/run zImage address
    .word   _end - _start   @ zImage size
    @ end of zImage header

work:  b work

I've made linker script so that entry point is at address _start and
it is initial value of PC (it is 0x80008000). So is there any quick
way to check registers from dom0 so I can be sure that "work" is
being done? I'm testing this on Odroid XU3 platform...





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: ARM bare metal application test

[Julien Grall]

On 09/05/2016 09:34, Ivan Pavić2 wrote:
> Hello,

Hello Ivan,

> I'm trying to build simple bare metal application on ARM Cortex A7.
> I reached the phase in which I successfully created domain. Now,
> I would like to check if application is really running (it runs according
> xl list). But i need some simple interaction or at least console output.
>
> So far this is my code:
>
>      .section ".start", "x"
>      .align
>      .globl    _start
>
> _start:
>      @ zImage header
> .rept   8
>      mov     r0, r0
> .endr
>      b       work
>      .word   0x016f2818      @ Magic numbers to help the loader
>      .word   _start          @ absolute load/run zImage address
>      .word   _end - _start   @ zImage size
>      @ end of zImage header
>
> work:  b work
>
> I've made linker script so that entry point is at address _start and
> it is initial value of PC (it is 0x80008000). So is there any quick
> way to check registers from dom0 so I can be sure that "work" is
> being done? I'm testing this on Odroid XU3 platform...

You can dump the registers of a vCPU with xenctx.

$PREFIX/lib/xen/bin/xenctx domid

$PREFIX is the path where xen tools have been installed (i.e --prefix on 
the configure). The default path is /usr/local/

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

ARM bare metal application test

[Ivan Pavić2]

Julien Grail wrote:

> You can dump the registers of a vCPU with xenctx.

> $PREFIX/lib/xen/bin/xenctx domid

> $PREFIX is the path where xen tools have been installed (i.e --prefix on
> the configure). The default path is /usr/local/

Thanks for advice. I discovered that the PC has value 0x0C and SPSR of ABT mode is same
as CPSR so I think that is prefetch abort. But I don't understand why it happens? Invalid memory
access? I'm using simple linker script:

...
OUTPUT_ARCH(arm)
ENTRY(_start)
SECTIONS
{
  _start = 0x80008000;

  . = _start;

  .text : {
    *(.start);
    *(.text);
  }
...
 
Thanks in advance.
Ivan Pavić

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: ARM bare metal application test

[Konrad Rzeszutek Wilk]

On Mon, May 09, 2016 at 10:29:09AM +0000, Ivan Pavić2 wrote:
> Julien Grail wrote:
> 
> > You can dump the registers of a vCPU with xenctx.
> 
> > $PREFIX/lib/xen/bin/xenctx domid
> 
> > $PREFIX is the path where xen tools have been installed (i.e --prefix on
> > the configure). The default path is /usr/local/
> 
> Thanks for advice. I discovered that the PC has value 0x0C and SPSR of ABT mode is same
> as CPSR so I think that is prefetch abort. But I don't understand why it happens? Invalid memory
> access? I'm using simple linker script:


What does objdump tell you for the binary? 

Julien, is there an document outlining what the state of the CPU is when a guest
is started on ARM? Ah in the Linux Documentation/arm/Booting 

> 
> ...
> OUTPUT_ARCH(arm)
> ENTRY(_start)
> SECTIONS
> {
>   _start = 0x80008000;
> 
>   . = _start;
> 
>   .text : {
>     *(.start);
>     *(.text);
>   }

OK, but that makes an ELF file. I believe (based on the Booting) you need to extract
the binary code out and also fixup the branch instructions (maybe make __Start = 0;?).

The Booting says:

- The boot loader is expected to call the kernel image by jumping               
  directly to the first instruction of the kernel image.  

So if it is ELF it will jump in the ELF header, not the code.

> ...
>  
> Thanks in advance.
> Ivan Pavić
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Odgovor: ARM bare metal application test

[Ivan Pavić2]

Konrad Rzeszutek Wilk wrote:

> OK, but that makes an ELF file. I believe (based on the Booting) you need to extract
> the binary code out and also fixup the branch instructions (maybe make __Start = 0;?).

> The Booting says:

> - The boot loader is expected to call the kernel image by jumping
> directly to the first instruction of the kernel image.

> So if it is ELF it will jump in the ELF header, not the cod

Ok,

this is objdump -h app.elf

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000034  80008000  80008000  00008000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .ARM.attributes 0000001f  00000000  00000000  00008034  2**0
                  CONTENTS, READONLY

I extracted binary with objcopy and used it to start domain:
Segment of output of: xl -vvv create dom.cfg

...
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM32) loader ... 
domainbuilder: detail: loader probe OK
domainbuilder: detail: xc_dom_parse_zimage32_kernel: called
...
domainbuilder: detail: vcpu_arm32: called
domainbuilder: detail: Initial state CPSR 0x1d3 PC 0x80008000
...

Only thing I can think of is that I'm accessing memory I can't access by default of MMU and that causes
prefetch abort but I don't know which memory segment I can use?

Regards, 
Ivan Pavic.



 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: ARM bare metal application test

[Julien Grall]

Hello Ivan,

On 09/05/16 11:29, Ivan Pavić2 wrote:
> Julien Grail wrote:
>
>> You can dump the registers of a vCPU with xenctx.
>
>> $PREFIX/lib/xen/bin/xenctx domid
>
>> $PREFIX is the path where xen tools have been installed (i.e --prefix on
>> the configure). The default path is /usr/local/
>
> Thanks for advice. I discovered that the PC has value 0x0C and SPSR of ABT mode is same
> as CPSR so I think that is prefetch abort. But I don't understand why it happens? Invalid memory
> access? I'm using simple linker script:

Guest are booting with MMU disabled, so 0x80008000 will be the physical 
address.

The toolstack will load the kernel at this physical address. However, 
the start of the guest RAM for Xen 4.7 is 0x40000000 (see 
include/public/arch-arm.h). Can you try to use 0x40008000 for the guest 
address?

By the way, how much RAM did you give to the guest?

> ...
> OUTPUT_ARCH(arm)
> ENTRY(_start)
> SECTIONS
> {
>    _start = 0x80008000;
>
>    . = _start;
>
>    .text : {
>      *(.start);
>      *(.text);
>    }
> ...
>
> Thanks in advance.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

ARM bare metal application test

[Ivan Pavić2]

Hello Julien,

Julien Grall wrote: 
> Guest are booting with MMU disabled, so 0x80008000 will be the physical
> address.

> The toolstack will load the kernel at this physical address. However,
> the start of the guest RAM for Xen 4.7 is 0x40000000 (see
> include/public/arch-arm.h). Can you try to use 0x40008000 for the guest
> address?

I changed address. It seems the problem is solved because PC is now 
40008030 (that is address of "work: b work" i think). 

> By the way, how much RAM did you give to the guest?

I wrote "memory = 32" in cfg file, I think that stands for 32 MB? 

I will continue working on this. 

Thank you very much,
Ivan Pavić.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: ARM bare metal application test

[Julien Grall]

On 09/05/16 17:43, Ivan Pavić2 wrote:
> Hello Julien,

Hello Ivan,

>
> Julien Grall wrote:
>> Guest are booting with MMU disabled, so 0x80008000 will be the physical
>> address.
>
>> The toolstack will load the kernel at this physical address. However,
>> the start of the guest RAM for Xen 4.7 is 0x40000000 (see
>> include/public/arch-arm.h). Can you try to use 0x40008000 for the guest
>> address?
>
> I changed address. It seems the problem is solved because PC is now
> 40008030 (that is address of "work: b work" i think).

You can figure out the associated instruction with objdump.

>
>> By the way, how much RAM did you give to the guest?
>
> I wrote "memory = 32" in cfg file, I think that stands for 32 MB?

Correct, so the end of the RAM bank would be 0x42000000. I am a bit 
surprised that the toolstack does not complain when trying to load the 
kernel at 0x80008000.

Can you paste the dump of xl -vvv create... ?

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Odgovor: ARM bare metal application test

[Ivan Pavić2]

Hello,

> Correct, so the end of the RAM bank would be 0x42000000. I am a bit
> surprised that the toolstack does not complain when trying to load the
> kernel at 0x80008000.

> Can you paste the dump of xl -vvv create... ?

$ xl -vvv create dom.cfg
Parsing config from dom.cfg
libxl: debug: libxl_create.c:1557:do_domain_create: ao 0x3c1c8: create: how=(nil) callback=(nil) poller=0x3c228
libxl: debug: libxl_arm.c:59:libxl__arch_domain_prepare_config: Configure the domain
libxl: debug: libxl_arm.c:62:libxl__arch_domain_prepare_config:  - Allocate 0 SPIs
libxl: debug: libxl_create.c:945:initiate_domain_create: running bootloader
libxl: debug: libxl_bootloader.c:330:libxl__bootloader_run: no bootloader configured, using user supplied kernel
libxl: debug: libxl_event.c:691:libxl__ev_xswatch_deregister: watch w=0x363a0: deregister unregistered
domainbuilder: detail: xc_dom_allocate: cmdline="(null)", features="(null)"
libxl: debug: libxl_dom.c:624:libxl__build_pv: pv kernel mapped 0 path kernel.bin
domainbuilder: detail: xc_dom_kernel_file: filename="kernel.bin"
domainbuilder: detail: xc_dom_boot_xen_init: ver 4.6, caps xen-3.0-armv7l 
domainbuilder: detail: xc_dom_rambase_init: RAM starts at 40000
domainbuilder: detail: xc_dom_parse_image: called
domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader ... 
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM64) loader ... 
domainbuilder: detail: xc_dom_probe_zimage64_kernel: kernel image too small
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM32) loader ... 
domainbuilder: detail: loader probe OK
domainbuilder: detail: xc_dom_parse_zimage32_kernel: called
domainbuilder: detail: xc_dom_parse_zimage32_kernel: xen-3.0-armv7l: 0x40008000 -> 0x40008034
libxl: debug: libxl_arm.c:776:libxl__arch_domain_init_hw_description: constructing DTB for Xen version 4.6 guest
libxl: debug: libxl_arm.c:777:libxl__arch_domain_init_hw_description:  - vGIC version: V2
libxl: debug: libxl_arm.c:380:make_memory_nodes: Creating placeholder node /memory@40000000
libxl: debug: libxl_arm.c:380:make_memory_nodes: Creating placeholder node /memory@200000000
libxl: debug: libxl_arm.c:871:libxl__arch_domain_init_hw_description: fdt total size 1237
domainbuilder: detail: xc_dom_devicetree_mem: called
domainbuilder: detail: xc_dom_mem_init: mem 32 MB, pages 0x2000 pages, 4k each
domainbuilder: detail: xc_dom_mem_init: 0x2000 pages
domainbuilder: detail: xc_dom_boot_mem_init: called
domainbuilder: detail: set_mode: guest xen-3.0-armv7l, address size 32
domainbuilder: detail: populate_guest_memory: populating RAM @ 0000000040000000-0000000042000000 (32MB)
domainbuilder: detail: populate_one_size: populated 0x10/0x10 entries with shift 9
domainbuilder: detail: arch_setup_meminit: placing boot modules at 0x41fff000
domainbuilder: detail: arch_setup_meminit: devicetree: 0x41fff000 -> 0x42000000
libxl: debug: libxl_arm.c:902:finalise_one_memory_node: Populating placeholder node /memory@40000000
libxl: debug: libxl_arm.c:896:finalise_one_memory_node: Nopping out placeholder node /memory@200000000                                                            [0/47]
domainbuilder: detail: xc_dom_build_image: called
domainbuilder: detail: xc_dom_alloc_segment:   kernel       : 0x40008000 -> 0x40009000  (pfn 0x40008 + 0x1 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x40008+0x1 at 0xb6f82000
domainbuilder: detail: xc_dom_load_zimage_kernel: called
domainbuilder: detail: xc_dom_load_zimage_kernel: kernel seg 0x40008000-0x40009000
domainbuilder: detail: xc_dom_load_zimage_kernel: copy 52 bytes from blob 0xb6f83000 to dst 0xb6f82000
domainbuilder: detail: xc_dom_alloc_segment:   devicetree   : 0x41fff000 -> 0x42000000  (pfn 0x41fff + 0x1 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x41fff+0x1 at 0xb6f81000
domainbuilder: detail: alloc_magic_pages: called
domainbuilder: detail: count_pgtables_arm: called
domainbuilder: detail: xc_dom_build_image  : virt_alloc_end : 0x42000000
domainbuilder: detail: xc_dom_build_image  : virt_pgtab_end : 0x0
domainbuilder: detail: xc_dom_boot_image: called
domainbuilder: detail: arch_setup_bootearly: doing nothing
domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-armv7l <= matches
domainbuilder: detail: setup_pgtables_arm: called
domainbuilder: detail: clear_page: pfn 0x39000, mfn 0x39000
domainbuilder: detail: clear_page: pfn 0x39001, mfn 0x39001
domainbuilder: detail: start_info_arm: called
domainbuilder: detail: domain builder memory footprint
domainbuilder: detail:    allocated
domainbuilder: detail:       malloc             : 66 kB
domainbuilder: detail:       anon mmap          : 0 bytes
domainbuilder: detail:    mapped
domainbuilder: detail:       file mmap          : 52 bytes
domainbuilder: detail:       domU mmap          : 8192 bytes
domainbuilder: detail: vcpu_arm32: called
domainbuilder: detail: Initial state CPSR 0x1d3 PC 0x40008000
domainbuilder: detail: launch_vm: called, ctxt=0xb6f85004
domainbuilder: detail: xc_dom_gnttab_hvm_seed: called, pfn=0x38000
domainbuilder: detail: xc_dom_release: called
libxl: debug: libxl_event.c:2183:libxl__ao_progress_report: ao 0x3c1c8: progress report: ignored
libxl: debug: libxl_event.c:1874:libxl__ao_complete: ao 0x3c1c8: complete, rc=0
libxl: debug: libxl_create.c:1580:do_domain_create: ao 0x3c1c8: inprogress: poller=0x3c228, flags=ic
libxl: debug: libxl_event.c:1843:libxl__ao__destroy: ao 0x3c1c8: destroy
xc: debug: hypercall buffer: total allocations:95 total releases:95
xc: debug: hypercall buffer: current allocations:0 maximum allocations:3
xc: debug: hypercall buffer: cache current size:3
xc: debug: hypercall buffer: cache hits:84 misses:3 toobig:8

Here it is.

Regards,
Ivan Pavic
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: ARM bare metal application test

[Wei Liu]

On Mon, May 09, 2016 at 05:47:38PM +0100, Julien Grall wrote:
> 
> 
> On 09/05/16 17:43, Ivan Pavić2 wrote:
> >Hello Julien,
> 
> Hello Ivan,
> 
> >
> >Julien Grall wrote:
> >>Guest are booting with MMU disabled, so 0x80008000 will be the physical
> >>address.
> >
> >>The toolstack will load the kernel at this physical address. However,
> >>the start of the guest RAM for Xen 4.7 is 0x40000000 (see
> >>include/public/arch-arm.h). Can you try to use 0x40008000 for the guest
> >>address?
> >
> >I changed address. It seems the problem is solved because PC is now
> >40008030 (that is address of "work: b work" i think).
> 
> You can figure out the associated instruction with objdump.
> 
> >
> >>By the way, how much RAM did you give to the guest?
> >
> >I wrote "memory = 32" in cfg file, I think that stands for 32 MB?
> 
> Correct, so the end of the RAM bank would be 0x42000000. I am a bit
> surprised that the toolstack does not complain when trying to load the
> kernel at 0x80008000.
> 

I don't think toolstack tries to load kernel to that guest physical
address -- reading from Ivan's log it suggests toolstack loaded the
kernel to 0x40008000.

That (0x8000800) is the address set in PC, right?  I don't think
toolstack is in a position to sanitise that nor should it care.

Wei.

> Can you paste the dump of xl -vvv create... ?
> 
> Regards,
> 
> -- 
> Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: ARM bare metal application test

[Julien Grall]

On 09/05/16 18:39, Wei Liu wrote:
> On Mon, May 09, 2016 at 05:47:38PM +0100, Julien Grall wrote:
>>
>>
>> On 09/05/16 17:43, Ivan Pavić2 wrote:
>>> Hello Julien,
>>
>> Hello Ivan,
>>
>>>
>>> Julien Grall wrote:
>>>> Guest are booting with MMU disabled, so 0x80008000 will be the physical
>>>> address.
>>>
>>>> The toolstack will load the kernel at this physical address. However,
>>>> the start of the guest RAM for Xen 4.7 is 0x40000000 (see
>>>> include/public/arch-arm.h). Can you try to use 0x40008000 for the guest
>>>> address?
>>>
>>> I changed address. It seems the problem is solved because PC is now
>>> 40008030 (that is address of "work: b work" i think).
>>
>> You can figure out the associated instruction with objdump.
>>
>>>
>>>> By the way, how much RAM did you give to the guest?
>>>
>>> I wrote "memory = 32" in cfg file, I think that stands for 32 MB?
>>
>> Correct, so the end of the RAM bank would be 0x42000000. I am a bit
>> surprised that the toolstack does not complain when trying to load the
>> kernel at 0x80008000.
>>
>
> I don't think toolstack tries to load kernel to that guest physical
> address -- reading from Ivan's log it suggests toolstack loaded the
> kernel to 0x40008000.
>
> That (0x8000800) is the address set in PC, right?  I don't think
> toolstack is in a position to sanitise that nor should it care.

The zImage format offers the opportunity to either choose the base 
address or let the loader do it for you.

Based on the specification, this address is supposed to be both the PC 
and the loading address. However, libxc (see 
xc_dom_parse_zimage32_kernel) seems to handle the first case incorrectly.

It will be fairly easy to sanitize or even fix it. I will send a patch 
for it.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

ARM bare metal application test

[Ivan Pavić2]

Hello,

> I don't think toolstack tries to load kernel to that guest physical
> address -- reading from Ivan's log it suggests toolstack loaded the
> kernel to 0x40008000.

> That (0x8000800) is the address set in PC, right?  I don't think
> toolstack is in a position to sanitise that nor should it care.


I posted xl create output when i changed address in linker script. This output when it is set to 0x80008000:
PC is incorrect?

Parsing config from dom.cfg
libxl: debug: libxl_create.c:1557:do_domain_create: ao 0x3c1c8: create: how=(nil) callback=(nil) poller=0x3c228
libxl: debug: libxl_arm.c:59:libxl__arch_domain_prepare_config: Configure the domain
libxl: debug: libxl_arm.c:62:libxl__arch_domain_prepare_config:  - Allocate 0 SPIs
libxl: debug: libxl_create.c:945:initiate_domain_create: running bootloader
libxl: debug: libxl_bootloader.c:330:libxl__bootloader_run: no bootloader configured, using user supplied kernel
libxl: debug: libxl_event.c:691:libxl__ev_xswatch_deregister: watch w=0x363a0: deregister unregistered
domainbuilder: detail: xc_dom_allocate: cmdline="(null)", features="(null)"
libxl: debug: libxl_dom.c:624:libxl__build_pv: pv kernel mapped 0 path kernel.bin
domainbuilder: detail: xc_dom_kernel_file: filename="kernel.bin"
domainbuilder: detail: xc_dom_boot_xen_init: ver 4.6, caps xen-3.0-armv7l 
domainbuilder: detail: xc_dom_rambase_init: RAM starts at 40000
domainbuilder: detail: xc_dom_parse_image: called
domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader ... 
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM64) loader ... 
domainbuilder: detail: xc_dom_probe_zimage64_kernel: kernel image too small
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM32) loader ... 
domainbuilder: detail: loader probe OK
domainbuilder: detail: xc_dom_parse_zimage32_kernel: called
domainbuilder: detail: xc_dom_parse_zimage32_kernel: xen-3.0-armv7l: 0x40008000 -> 0x40008034
libxl: debug: libxl_arm.c:776:libxl__arch_domain_init_hw_description: constructing DTB for Xen version 4.6 guest
libxl: debug: libxl_arm.c:777:libxl__arch_domain_init_hw_description:  - vGIC version: V2
libxl: debug: libxl_arm.c:380:make_memory_nodes: Creating placeholder node /memory@40000000
libxl: debug: libxl_arm.c:380:make_memory_nodes: Creating placeholder node /memory@200000000
libxl: debug: libxl_arm.c:871:libxl__arch_domain_init_hw_description: fdt total size 1237
domainbuilder: detail: xc_dom_devicetree_mem: called
domainbuilder: detail: xc_dom_mem_init: mem 32 MB, pages 0x2000 pages, 4k each
domainbuilder: detail: xc_dom_mem_init: 0x2000 pages
domainbuilder: detail: xc_dom_boot_mem_init: called
domainbuilder: detail: set_mode: guest xen-3.0-armv7l, address size 32
domainbuilder: detail: populate_guest_memory: populating RAM @ 0000000040000000-0000000042000000 (32MB)
domainbuilder: detail: populate_one_size: populated 0x10/0x10 entries with shift 9
domainbuilder: detail: arch_setup_meminit: placing boot modules at 0x41fff000
domainbuilder: detail: arch_setup_meminit: devicetree: 0x41fff000 -> 0x42000000
libxl: debug: libxl_arm.c:902:finalise_one_memory_node: Populating placeholder node /memory@40000000
libxl: debug: libxl_arm.c:896:finalise_one_memory_node: Nopping out placeholder node /memory@200000000
domainbuilder: detail: xc_dom_build_image: called
domainbuilder: detail: xc_dom_alloc_segment:   kernel       : 0x40008000 -> 0x40009000  (pfn 0x40008 + 0x1 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x40008+0x1 at 0xb6eef000
domainbuilder: detail: xc_dom_load_zimage_kernel: called
domainbuilder: detail: xc_dom_load_zimage_kernel: kernel seg 0x40008000-0x40009000
domainbuilder: detail: xc_dom_load_zimage_kernel: copy 52 bytes from blob 0xb6ef0000 to dst 0xb6eef000
domainbuilder: detail: xc_dom_alloc_segment:   devicetree   : 0x41fff000 -> 0x42000000  (pfn 0x41fff + 0x1 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x41fff+0x1 at 0xb6eee000
domainbuilder: detail: alloc_magic_pages: called
domainbuilder: detail: count_pgtables_arm: called
domainbuilder: detail: xc_dom_build_image  : virt_alloc_end : 0x42000000
domainbuilder: detail: xc_dom_build_image  : virt_pgtab_end : 0x0
domainbuilder: detail: xc_dom_boot_image: called
domainbuilder: detail: arch_setup_bootearly: doing nothing
domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-armv7l <= matches
domainbuilder: detail: setup_pgtables_arm: called
domainbuilder: detail: clear_page: pfn 0x39000, mfn 0x39000
domainbuilder: detail: clear_page: pfn 0x39001, mfn 0x39001
domainbuilder: detail: start_info_arm: called
domainbuilder: detail: domain builder memory footprint
domainbuilder: detail:    allocated
domainbuilder: detail:       malloc             : 66 kB
domainbuilder: detail:       anon mmap          : 0 bytes
domainbuilder: detail:    mapped
domainbuilder: detail:       file mmap          : 52 bytes
domainbuilder: detail:       domU mmap          : 8192 bytes
domainbuilder: detail: vcpu_arm32: called
domainbuilder: detail: Initial state CPSR 0x1d3 PC 0x80008000
domainbuilder: detail: launch_vm: called, ctxt=0xb6ef2004
domainbuilder: detail: xc_dom_gnttab_hvm_seed: called, pfn=0x38000
domainbuilder: detail: xc_dom_release: called
libxl: debug: libxl_event.c:2183:libxl__ao_progress_report: ao 0x3c1c8: progress report: ignored
libxl: debug: libxl_event.c:1874:libxl__ao_complete: ao 0x3c1c8: complete, rc=0
libxl: debug: libxl_create.c:1580:do_domain_create: ao 0x3c1c8: inprogress: poller=0x3c228, flags=ic
libxl: debug: libxl_event.c:1843:libxl__ao__destroy: ao 0x3c1c8: destroy
xc: debug: hypercall buffer: total allocations:95 total releases:95
xc: debug: hypercall buffer: current allocations:0 maximum allocations:3
xc: debug: hypercall buffer: cache current size:3
xc: debug: hypercall buffer: cache hits:84 misses:3 toobig:8

Regards, 
Ivan Pavic.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: ARM bare metal application test

[Wei Liu]

On Mon, May 09, 2016 at 05:59:09PM +0000, Ivan Pavić2 wrote:
> Hello,
> 
> > I don't think toolstack tries to load kernel to that guest physical
> > address -- reading from Ivan's log it suggests toolstack loaded the
> > kernel to 0x40008000.
> 
> > That (0x8000800) is the address set in PC, right?  I don't think
> > toolstack is in a position to sanitise that nor should it care.
> 
> 
> I posted xl create output when i changed address in linker script. This output when it is set to 0x80008000:
> PC is incorrect?
> 

The PC is correct in the sense that it is what the image says. It is
incorrect in the sense that it points to invalid memory.

See below:

> domainbuilder: detail: xc_dom_load_zimage_kernel: kernel seg 0x40008000-0x40009000
> domainbuilder: detail: xc_dom_load_zimage_kernel: copy 52 bytes from blob 0xb6ef0000 to dst 0xb6eef000
> domainbuilder: detail: xc_dom_alloc_segment:   devicetree   : 0x41fff000 -> 0x42000000  (pfn 0x41fff + 0x1 pages)
> domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x41fff+0x1 at 0xb6eee000
> domainbuilder: detail: alloc_magic_pages: called
> domainbuilder: detail: count_pgtables_arm: called
> domainbuilder: detail: xc_dom_build_image  : virt_alloc_end : 0x42000000
> domainbuilder: detail: xc_dom_build_image  : virt_pgtab_end : 0x0

[...]

> domainbuilder: detail: Initial state CPSR 0x1d3 PC 0x80008000


Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: ARM bare metal application test

[Wei Liu]

On Mon, May 09, 2016 at 06:57:13PM +0100, Julien Grall wrote:
> 
> 
> On 09/05/16 18:39, Wei Liu wrote:
> >On Mon, May 09, 2016 at 05:47:38PM +0100, Julien Grall wrote:
> >>
> >>
> >>On 09/05/16 17:43, Ivan Pavić2 wrote:
> >>>Hello Julien,
> >>
> >>Hello Ivan,
> >>
> >>>
> >>>Julien Grall wrote:
> >>>>Guest are booting with MMU disabled, so 0x80008000 will be the physical
> >>>>address.
> >>>
> >>>>The toolstack will load the kernel at this physical address. However,
> >>>>the start of the guest RAM for Xen 4.7 is 0x40000000 (see
> >>>>include/public/arch-arm.h). Can you try to use 0x40008000 for the guest
> >>>>address?
> >>>
> >>>I changed address. It seems the problem is solved because PC is now
> >>>40008030 (that is address of "work: b work" i think).
> >>
> >>You can figure out the associated instruction with objdump.
> >>
> >>>
> >>>>By the way, how much RAM did you give to the guest?
> >>>
> >>>I wrote "memory = 32" in cfg file, I think that stands for 32 MB?
> >>
> >>Correct, so the end of the RAM bank would be 0x42000000. I am a bit
> >>surprised that the toolstack does not complain when trying to load the
> >>kernel at 0x80008000.
> >>
> >
> >I don't think toolstack tries to load kernel to that guest physical
> >address -- reading from Ivan's log it suggests toolstack loaded the
> >kernel to 0x40008000.
> >
> >That (0x8000800) is the address set in PC, right?  I don't think
> >toolstack is in a position to sanitise that nor should it care.
> 
> The zImage format offers the opportunity to either choose the base address
> or let the loader do it for you.
> 
> Based on the specification, this address is supposed to be both the PC and
> the loading address. However, libxc (see xc_dom_parse_zimage32_kernel) seems
> to handle the first case incorrectly.
> 

 99     /*                                                                          
100      * If start is invalid then the guest will start at some invalid
101      * address and crash, but this happens in guest context so doesn't
102      * concern us here.
103      */
104     start = zimage[ZIMAGE32_START_OFFSET/4];

It looks like the comment agrees with me.  But at the end of the day it
is your call to determine what is the correct behaviour.

> It will be fairly easy to sanitize or even fix it. I will send a patch for
> it.
> 

Cool, thanks.

Though I suspect you also need to work out how rambase is arranged so it
might not be as simple as you thought. :-/

Wei.

> Cheers,
> 
> -- 
> Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel