* Basic bare metal ARM domain interface
@ 2016-05-25 19:42 Ivan Pavić2
2016-05-27 10:04 ` Julien Grall
0 siblings, 1 reply; 12+ messages in thread
From: Ivan Pavić2 @ 2016-05-25 19:42 UTC (permalink / raw)
To: xen-devel
Hello,
I'm working on bare metal application for ARM Cortex A7/15 on Odroid XU3
platform. I'm using Xen 4.6.
After successfully creating bare metal example(by successful I mean I've stuck
processor in while loop in main function), I probably should initialize memory
management unit and similiar. I've found FreeRTOS project on Github where
similiar stuff was done for ARM Cortex A15. Project is done for Xen 4.4.
Xen FreeRTOS project: https://github.com/GaloisInc/FreeRTOS-Xen/ .
1) I'm using 4.6. so I don't know if code from is fully compatible? (I had to
comment out lot of things because they block program, printing for example)
2) Additionally , I would like to implement basic serial output to dom0 from my
bare metal domU. What is the minimum one should do for implementing console
output?
3) Furthermore, as this should be bare metal application, I would like at least
to be able to toggle LED. How can interface hardware from domU? My first guess
would be to directly address Exynos 5422 GPIO registers but I don't know if
that would work beacause application is running on VCPU (probably not??) ??
Any answer, example of implementation, specific documentation or advice would
be very helpful.
Thank you in advance...
Regards,
Ivan Pavić
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Basic bare metal ARM domain interface
2016-05-25 19:42 Basic bare metal ARM domain interface Ivan Pavić2
@ 2016-05-27 10:04 ` Julien Grall
2016-05-27 13:19 ` Ivan Pavić2
[not found] ` <20160527211650.GA43457@galois.com>
0 siblings, 2 replies; 12+ messages in thread
From: Julien Grall @ 2016-05-27 10:04 UTC (permalink / raw)
To: Ivan Pavić2, xen-devel; +Cc: jtd
On 25/05/16 20:42, Ivan Pavić2 wrote:
> Hello,
Hello Ivan,
> I'm working on bare metal application for ARM Cortex A7/15 on Odroid XU3
> platform. I'm using Xen 4.6.
>
> After successfully creating bare metal example(by successful I mean I've stuck
> processor in while loop in main function), I probably should initialize memory
> management unit and similiar. I've found FreeRTOS project on Github where
> similiar stuff was done for ARM Cortex A15. Project is done for Xen 4.4.
> Xen FreeRTOS project: https://github.com/GaloisInc/FreeRTOS-Xen/ .
>
> 1) I'm using 4.6. so I don't know if code from is fully compatible? (I had to
> comment out lot of things because they block program, printing for example)
If I remember correctly, FreeRTOS is not using the device-tree to find
where reside the GIC MMIO regions (and possible other MMIOs).
The memory layout has been reworked between Xen 4.4 and Xen 4.5. So you
will need to update the base address hardcoded in FreeRTOS.
I have CCed, Jonathan who did the FreeRTOS port for Xen. He will be able
to give you more details about it.
>
> 2) Additionally , I would like to implement basic serial output to dom0 from my
> bare metal domU. What is the minimum one should do for implementing console
> output?
We provide a PV console interface. The backend is already implement in
dom0 (assuming you are using Linux). For the frontend, you can give a
look, how mini-os [1] has implemented it.
>
> 3) Furthermore, as this should be bare metal application, I would like at least
> to be able to toggle LED. How can interface hardware from domU? My first guess
> would be to directly address Exynos 5422 GPIO registers but I don't know if
> that would work beacause application is running on VCPU (probably not??) ??
By default, the guest has no access to the hardware. You will need to
specify in the configure file the list of MMIO regions the guest is
allowed to access. You can find more details about it here [2].
>
> Any answer, example of implementation, specific documentation or advice would
> be very helpful.
There were a few talks to explain how to port an OS on XEN:
-
https://events.linuxfoundation.org/sites/events/files/slides/FreeRTOSXenSummit_0.pdf
- http://fr.slideshare.net/xen_com_mgr/bsdcan-2015-how-to-port-your-bsd
I hope this will help you to create your bare metal app. Feel free to
send an e-email if you have more questions.
Regards,
[1]
http://xenbits.xen.org/gitweb/?p=mini-os.git;a=tree;f=console;h=61f51490a1aefc15148b6e1f016d9e63bbfe61aa;hb=HEAD
[2] https://events.linuxfoundation.org/sites/events/files/slides/talk_5.pdf
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Basic bare metal ARM domain interface
2016-05-27 10:04 ` Julien Grall
@ 2016-05-27 13:19 ` Ivan Pavić2
[not found] ` <20160527211650.GA43457@galois.com>
1 sibling, 0 replies; 12+ messages in thread
From: Ivan Pavić2 @ 2016-05-27 13:19 UTC (permalink / raw)
To: Julien Grall, xen-devel; +Cc: jtd
Hello,
Jullien, thanks for docs and references.
I used FreeRTOS code for console output. It is based on Mini OS code. There are two problems as I've determined with debugging. First is that vsnprintf blocks for some reason in print function so i commented it out. After the hypercall function blocked as well. I modified hypercall function so it looks like this:
(void)HYPERVISOR_console_io(CONSOLEIO_write, 3, "yes");
hoping to get "yes" as output..., but this blocked as well.
xenctx output after HYPERVISOR_console_io:
PC: 4000828c
CPSR: 200001d7
USR: SP:00000000 LR:00000000
SVC: SPSR:00000000 SP:4011bff4 LR:4000a37f
FIQ: SPSR:00000000 SP:40124200 LR:00000000
IRQ: SPSR:00000000 SP:40120200 LR:00000000
ABT: SPSR:200001f7 SP:40008140 LR:3f741306
UND: SPSR:00000000 SP:4012c200 LR:00000000
r0_usr: 4000815f r1_usr: 00000000 r2_usr: 40008160
r3_usr: 4000815c r4_usr: ffffa338 r5_usr: 4000c948
r6_usr: 00000000 r7_usr: 4000a53c r8_usr: 00000000
r9_usr: 00000000 r10_usr: 00000065 r11_usr: 00000000
r12_usr: 00000000
r8_fiq: 00000000
r9_fiq: 00000000 r10_fiq: 00000000 r11_fiq: 00000000
r12_fiq: 00000000
SCTLR: 00c50078
TTBCR: 0000000000000000
TTBR0: 0000000000000000
TTBR1: 0000000000000000
r10 = 101, I used it for debugging, to locate code where it is stuck. What could it be?
Thanks in advance,
Ivan Pavic.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Basic bare metal ARM domain interface
[not found] ` <20160527211650.GA43457@galois.com>
@ 2016-05-28 11:21 ` Ivan Pavić2
2016-05-30 20:21 ` Odgovor: " Ivan Pavić2
0 siblings, 1 reply; 12+ messages in thread
From: Ivan Pavić2 @ 2016-05-28 11:21 UTC (permalink / raw)
To: Jonathan Daugherty, Julien Grall, xen-devel; +Cc: Adam Wick
Hello,
> I used FreeRTOS code for console output. It is based on Mini OS code. There are two problems as I've determined
> with debugging. First is that vsnprintf blocks for some reason in print function so i commented it out. After the
snprintf blocks...
> hypercall function blocked as well. I modified hypercall function so it looks like this:
> (void)HYPERVISOR_console_io(CONSOLEIO_write, 3, "yes");
As the call failed I decided to make hypervisor call directly in boot procedure, so I put this assembler code just before
branch to main:
mov r12, #18 ; console io code
mov r0, #0 ; write operation(first parameter)
mov r1, #5 ; length of message (second parameter)
ldr r2, =msg ; message address (third parameter)
.long 0xe140ea71 ; hvc instruction
b main ; branch to main
msg is defined as:
msg:
.asciz "hello"
I get deadbeef in registers, apperently something happened (xenctx output):
PC: 4000c5bc
CPSR: 600001f3
USR: SP:00000000 LR:00000000
SVC: SPSR:00000000 SP:4011c200 LR:400080a8
FIQ: SPSR:00000000 SP:40124200 LR:00000000
IRQ: SPSR:00000000 SP:40120200 LR:00000000
ABT: SPSR:00000000 SP:40128200 LR:00000000
UND: SPSR:00000000 SP:4012c200 LR:00000000
r0_usr: 00000000 r1_usr: deadbeef r2_usr: deadbeef
r3_usr: 00000000 r4_usr: 00000000 r5_usr: 00000000
r6_usr: 00000000 r7_usr: 00000000 r8_usr: 00000000
r9_usr: 00000064 r10_usr: 00000064 r11_usr: 00000000
r12_usr: deadbeef
According to arch-arm.h r0 is return value of call. It is 0, operation successful???? Still I don't get output on
console...
Thank you in advance,
Regards,
Ivan Pavic
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Odgovor: Basic bare metal ARM domain interface
2016-05-28 11:21 ` Ivan Pavić2
@ 2016-05-30 20:21 ` Ivan Pavić2
2016-05-31 9:53 ` Julien Grall
0 siblings, 1 reply; 12+ messages in thread
From: Ivan Pavić2 @ 2016-05-30 20:21 UTC (permalink / raw)
To: Jonathan Daugherty, Julien Grall, xen-devel; +Cc: Adam Wick
Hello,
>> I used FreeRTOS code for console output. It is based on Mini OS code. There are two problems as I've >determined
>> with debugging. First is that vsnprintf blocks for some reason in print function so i commented it out. After the
>snprintf blocks...
>> hypercall function blocked as well. I modified hypercall function so it looks like this:
>>(void)HYPERVISOR_console_io(CONSOLEIO_write, 3, "yes");
>As the call failed I decided to make hypervisor call directly in boot procedure, so I put this assembler code just >before
>branch to main:
> mov r12, #18 ; console io code
> mov r0, #0 ; write operation(first parameter)
> mov r1, #5 ; length of message (second parameter)
> ldr r2, =msg ; message address (third parameter)
> .long 0xe140ea71 ; hvc instruction
> b main ; branch to main
>msg is defined as:
>msg:
> .asciz "hello"
>I get deadbeef in registers, apperently something happened (xenctx output):
>PC: 4000c5bc
>CPSR: 600001f3
>USR: SP:00000000 LR:00000000
>SVC: SPSR:00000000 SP:4011c200 LR:400080a8
>FIQ: SPSR:00000000 SP:40124200 LR:00000000
>IRQ: SPSR:00000000 SP:40120200 LR:00000000
>ABT: SPSR:00000000 SP:40128200 LR:00000000
>UND: SPSR:00000000 SP:4012c200 LR:00000000
>r0_usr: 00000000 r1_usr: deadbeef r2_usr: deadbeef
>r3_usr: 00000000 r4_usr: 00000000 r5_usr: 00000000
>r6_usr: 00000000 r7_usr: 00000000 r8_usr: 00000000
>r9_usr: 00000064 r10_usr: 00000064 r11_usr: 00000000
>r12_usr: deadbeef
>According to arch-arm.h r0 is return value of call. It is 0, operation successful???? Still I don't get output on
>console...
>Thank you in advance,
>Regards,
>Ivan Pavic
I still didn't solve why I don't see no output on emergency console, I think I should because if deadbeef in registers it
do_console_io should have been called. However new problem emerged i tried to add iomem
parameter in configuration file to get access over gpio but domain won't start because operation is not permitted.
Should I somehow release disable that memory space for dom0, perhaps in dts for dom0?
Snippet from dom.cfg file:
iomem = ["0x13400000,1@0x41400000"]
0x13400000 is base address of GPIO that I want to use.
I get this error: (snippet from xl -vvv create -c dom.cfg)
libxl: debug: libxl_create.c:1213:domcreate_launch_dm: dom4 iomem 13400000-13400000
libxl: error: libxl_create.c:1220:domcreate_launch_dm: failed give dom4 access to iomem range 13400000-13400000: Operation not permitted
libxl: debug: libxl.c:1719:devices_destroy_cb: forked pid 3835 for destroy of domain 4
Thank you in advance,
Ivan Pavic
_______________________________________________
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Odgovor: Basic bare metal ARM domain interface
2016-05-30 20:21 ` Odgovor: " Ivan Pavić2
@ 2016-05-31 9:53 ` Julien Grall
2016-06-01 20:06 ` Ivan Pavic
0 siblings, 1 reply; 12+ messages in thread
From: Julien Grall @ 2016-05-31 9:53 UTC (permalink / raw)
To: Ivan Pavić2, Jonathan Daugherty, xen-devel
Cc: Adam Wick, Stefano Stabellini
On 30/05/16 21:21, Ivan Pavić2 wrote:
> Hello,
Hello Ivan,
Sorry for the late answer.
>>> I used FreeRTOS code for console output. It is based on Mini OS code. There are two problems as I've >determined
>>> with debugging. First is that vsnprintf blocks for some reason in print function so i commented it out. After the
>
>> snprintf blocks...
>
>>> hypercall function blocked as well. I modified hypercall function so it looks like this:
>>> (void)HYPERVISOR_console_io(CONSOLEIO_write, 3, "yes");
>
>> As the call failed I decided to make hypervisor call directly in boot procedure, so I put this assembler code just >before
>> branch to main:
>
>> mov r12, #18 ; console io code
>> mov r0, #0 ; write operation(first parameter)
>> mov r1, #5 ; length of message (second parameter)
>> ldr r2, =msg ; message address (third parameter)
>> .long 0xe140ea71 ; hvc instruction
>> b main ; branch to main
For your information, hypervisor calls have to be done with data cache
enabled. Otherwise you not may get garbage (or nothing at all) on the
console.
>
>> msg is defined as:
>
>> msg:
>> .asciz "hello"
>
>> I get deadbeef in registers, apperently something happened (xenctx output):
>> PC: 4000c5bc
>> CPSR: 600001f3
>> USR: SP:00000000 LR:00000000
>> SVC: SPSR:00000000 SP:4011c200 LR:400080a8
>> FIQ: SPSR:00000000 SP:40124200 LR:00000000
>> IRQ: SPSR:00000000 SP:40120200 LR:00000000
>> ABT: SPSR:00000000 SP:40128200 LR:00000000
>> UND: SPSR:00000000 SP:4012c200 LR:00000000
>
> >r0_usr: 00000000 r1_usr: deadbeef r2_usr: deadbeef
> >r3_usr: 00000000 r4_usr: 00000000 r5_usr: 00000000
> >r6_usr: 00000000 r7_usr: 00000000 r8_usr: 00000000
> >r9_usr: 00000064 r10_usr: 00000064 r11_usr: 00000000
>> r12_usr: deadbeef
>
>
>> According to arch-arm.h r0 is return value of call. It is 0, operation successful???? Still I don't get output on
>> console...
>
>> Thank you in advance,
>
>> Regards,
>
>> Ivan Pavic
>
> I still didn't solve why I don't see no output on emergency console, I think I should because if deadbeef in registers it
> do_console_io should have been called.
The emergency console and any Xen debug facilities (hvc 0xffxx) only
works when the hypervisor has been built with debug enabled.
By default, release version are built with debug disabled. You will have
to pass debug=y on the build command line to enable debug.
> However new problem emerged i tried to add iomem
> parameter in configuration file to get access over gpio but domain won't start because operation is not permitted.
> Should I somehow release disable that memory space for dom0, perhaps in dts for dom0?
>
> Snippet from dom.cfg file:
>
> iomem = ["0x13400000,1@0x41400000"]
>
> 0x13400000 is base address of GPIO that I want to use.
iomem expects a physical page number (see the documentation in
docs/man/xl.cfg.pod.5). So it should be:
iomem = ["0x13400,1@0x41400"]
>
> I get this error: (snippet from xl -vvv create -c dom.cfg)
>
> libxl: debug: libxl_create.c:1213:domcreate_launch_dm: dom4 iomem 13400000-13400000
> libxl: error: libxl_create.c:1220:domcreate_launch_dm: failed give dom4 access to iomem range 13400000-13400000: Operation not permitted
> libxl: debug: libxl.c:1719:devices_destroy_cb: forked pid 3835 for destroy of domain 4
>
> Thank you in advance,
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Basic bare metal ARM domain interface
2016-05-31 9:53 ` Julien Grall
@ 2016-06-01 20:06 ` Ivan Pavic
2016-06-02 11:41 ` Julien Grall
0 siblings, 1 reply; 12+ messages in thread
From: Ivan Pavic @ 2016-06-01 20:06 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, Jonathan Daugherty, Adam Wick, Stefano Stabellini
On Tue, May 31, 2016 at 10:53:06AM +0100, Julien Grall wrote:
>
>
> On 30/05/16 21:21, Ivan Pavić2 wrote:
> >Hello,
>
> Hello Ivan,
>
> Sorry for the late answer.
>
> >>>I used FreeRTOS code for console output. It is based on Mini OS code. There are two problems as I've >determined
> >>>with debugging. First is that vsnprintf blocks for some reason in print function so i commented it out. After the
> >
> >>snprintf blocks...
> >
> >>>hypercall function blocked as well. I modified hypercall function so it looks like this:
> >>>(void)HYPERVISOR_console_io(CONSOLEIO_write, 3, "yes");
> >
> >>As the call failed I decided to make hypervisor call directly in boot procedure, so I put this assembler code just >before
> >>branch to main:
> >
> >> mov r12, #18 ; console io code
> >> mov r0, #0 ; write operation(first parameter)
> >> mov r1, #5 ; length of message (second parameter)
> >> ldr r2, =msg ; message address (third parameter)
> >> .long 0xe140ea71 ; hvc instruction
> >> b main ; branch to main
>
> For your information, hypervisor calls have to be done with data
> cache enabled. Otherwise you not may get garbage (or nothing at all)
> on the console.
>
> >
> >>msg is defined as:
> >
> >>msg:
> >> .asciz "hello"
> >
> >>I get deadbeef in registers, apperently something happened (xenctx output):
> >>PC: 4000c5bc
> >>CPSR: 600001f3
> >>USR: SP:00000000 LR:00000000
> >>SVC: SPSR:00000000 SP:4011c200 LR:400080a8
> >>FIQ: SPSR:00000000 SP:40124200 LR:00000000
> >>IRQ: SPSR:00000000 SP:40120200 LR:00000000
> >>ABT: SPSR:00000000 SP:40128200 LR:00000000
> >>UND: SPSR:00000000 SP:4012c200 LR:00000000
> >
> > >r0_usr: 00000000 r1_usr: deadbeef r2_usr: deadbeef
> > >r3_usr: 00000000 r4_usr: 00000000 r5_usr: 00000000
> > >r6_usr: 00000000 r7_usr: 00000000 r8_usr: 00000000
> > >r9_usr: 00000064 r10_usr: 00000064 r11_usr: 00000000
> >>r12_usr: deadbeef
> >
> >
> >>According to arch-arm.h r0 is return value of call. It is 0, operation successful???? Still I don't get output on
> >>console...
> >
> >>Thank you in advance,
> >
> >>Regards,
> >
> >>Ivan Pavic
> >
> >I still didn't solve why I don't see no output on emergency console, I think I should because if deadbeef in registers it
> >do_console_io should have been called.
>
> The emergency console and any Xen debug facilities (hvc 0xffxx) only
> works when the hypervisor has been built with debug enabled.
>
> By default, release version are built with debug disabled. You will
> have to pass debug=y on the build command line to enable debug.
>
> >However new problem emerged i tried to add iomem
> >parameter in configuration file to get access over gpio but domain won't start because operation is not permitted.
> >Should I somehow release disable that memory space for dom0, perhaps in dts for dom0?
> >
> >Snippet from dom.cfg file:
> >
> >iomem = ["0x13400000,1@0x41400000"]
> >
> >0x13400000 is base address of GPIO that I want to use.
>
> iomem expects a physical page number (see the documentation in
> docs/man/xl.cfg.pod.5). So it should be:
>
> iomem = ["0x13400,1@0x41400"]
>
> >
> >I get this error: (snippet from xl -vvv create -c dom.cfg)
> >
> >libxl: debug: libxl_create.c:1213:domcreate_launch_dm: dom4 iomem 13400000-13400000
> >libxl: error: libxl_create.c:1220:domcreate_launch_dm: failed give dom4 access to iomem range 13400000-13400000: Operation not permitted
> >libxl: debug: libxl.c:1719:devices_destroy_cb: forked pid 3835 for destroy of domain 4
> >
> >Thank you in advance,
>
> Regards,
>
> --
> Julien Grall
Hello Julien,
thank you very much, I succeded with debug console and pin toggle (iomem).
It's actually good that you answered late, because it made me look through xen
traps.c and console.c code, so I recompiled xen few times. The main problem with
was compiler, I think. I've always got data abort with hypervisor calls and
similiar. Now I'm using gcc-linaro-arm-none-eabi-4.9 for both xen and
application. I'll try to document this as much as possible and I'll put code
on github. (github.com/dumpram). Next thing I will do, is to measure gpio
latency in dom0 and guest domain with different schedulers. Final step would
be to create starting point for porting some RTOS. Thank you once again for the
patience, with my beginner questions, but I'm afraid that there will be more...
Regards,
Ivan Pavic
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Basic bare metal ARM domain interface
2016-06-01 20:06 ` Ivan Pavic
@ 2016-06-02 11:41 ` Julien Grall
2016-06-02 19:09 ` Ivan Pavic
0 siblings, 1 reply; 12+ messages in thread
From: Julien Grall @ 2016-06-02 11:41 UTC (permalink / raw)
To: Ivan Pavic; +Cc: xen-devel, Jonathan Daugherty, Adam Wick, Stefano Stabellini
On 01/06/16 21:06, Ivan Pavic wrote:
> On Tue, May 31, 2016 at 10:53:06AM +0100, Julien Grall wrote:
> Hello Julien,
Hello Ivan,
> thank you very much, I succeded with debug console and pin toggle (iomem).
> It's actually good that you answered late, because it made me look through xen
> traps.c and console.c code, so I recompiled xen few times. The main problem with
> was compiler, I think. I've always got data abort with hypervisor calls and
> similiar. Now I'm using gcc-linaro-arm-none-eabi-4.9 for both xen and
> application.
Your guest (i.e the application) and Xen should not need to be built
with the same compiler.
Which compiler led to use a data abort? And where was the data abort? In
Xen or the guest?
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Basic bare metal ARM domain interface
2016-06-02 11:41 ` Julien Grall
@ 2016-06-02 19:09 ` Ivan Pavic
2016-06-03 10:23 ` Julien Grall
0 siblings, 1 reply; 12+ messages in thread
From: Ivan Pavic @ 2016-06-02 19:09 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, Jonathan Daugherty, Adam Wick, Stefano Stabellini
Hello Julien,
On Thu, Jun 02, 2016 at 12:41:02PM +0100, Julien Grall wrote:
>
> Which compiler led to use a data abort? And where was the data
> abort? In Xen or the guest?
>
When I compile app directly on ODROID I used:
arm-linux-gnueabihf
gcc version 4.8.4 (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.1)
HVC instruction works form assembler, but when I call it from main, for
example:
HYPERVISOR_console_io (HYPERCALL_WRITE, SYSTEM_UP_LEN, SYSTEM_UP_MSG);
then I get this in xl dmesg:
traps.c:2450:d2v0 HSR=0x90000046 pc=0x40008250 gva=0 gpa=0000000000000000
This doesn't happen with other compiler.
Regards,
Ivan Pavic
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Basic bare metal ARM domain interface
2016-06-02 19:09 ` Ivan Pavic
@ 2016-06-03 10:23 ` Julien Grall
2016-06-06 23:31 ` Ivan Pavic
0 siblings, 1 reply; 12+ messages in thread
From: Julien Grall @ 2016-06-03 10:23 UTC (permalink / raw)
To: Ivan Pavic; +Cc: xen-devel, Jonathan Daugherty, Adam Wick, Stefano Stabellini
On 02/06/16 20:09, Ivan Pavic wrote:
> Hello Julien,
Hello Ivan,
> On Thu, Jun 02, 2016 at 12:41:02PM +0100, Julien Grall wrote:
>>
>> Which compiler led to use a data abort? And where was the data
>> abort? In Xen or the guest?
>>
>
> When I compile app directly on ODROID I used:
> arm-linux-gnueabihf
> gcc version 4.8.4 (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.1)
>
> HVC instruction works form assembler, but when I call it from main, for
> example:
> HYPERVISOR_console_io (HYPERCALL_WRITE, SYSTEM_UP_LEN, SYSTEM_UP_MSG);
> then I get this in xl dmesg:
> traps.c:2450:d2v0 HSR=0x90000046 pc=0x40008250 gva=0 gpa=0000000000000000
To be honest this looks like a latent issue in your app rather than a
bug in the compiler.
I would try to find which instruction is causing the data abort. Also is
your app running with page table and cache enabled?
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Basic bare metal ARM domain interface
2016-06-03 10:23 ` Julien Grall
@ 2016-06-06 23:31 ` Ivan Pavic
2016-06-07 14:18 ` Julien Grall
0 siblings, 1 reply; 12+ messages in thread
From: Ivan Pavic @ 2016-06-06 23:31 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, Jonathan Daugherty, Adam Wick, Stefano Stabellini
Hello Julien,
On Fri, Jun 03, 2016 at 11:23:33AM +0100, Julien Grall wrote:
>
>
> On 02/06/16 20:09, Ivan Pavic wrote:
> >Hello Julien,
>
> Hello Ivan,
>
> >On Thu, Jun 02, 2016 at 12:41:02PM +0100, Julien Grall wrote:
> >>
> >>Which compiler led to use a data abort? And where was the data
> >>abort? In Xen or the guest?
> >>
> >
> >When I compile app directly on ODROID I used:
> >arm-linux-gnueabihf
> >gcc version 4.8.4 (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.1)
> >
> >HVC instruction works form assembler, but when I call it from main, for
> >example:
> >HYPERVISOR_console_io (HYPERCALL_WRITE, SYSTEM_UP_LEN, SYSTEM_UP_MSG);
> >then I get this in xl dmesg:
> >traps.c:2450:d2v0 HSR=0x90000046 pc=0x40008250 gva=0 gpa=0000000000000000
>
> To be honest this looks like a latent issue in your app rather than
> a bug in the compiler.
>
> I would try to find which instruction is causing the data abort.
> Also is your app running with page table and cache enabled?
>
Page table and cache are related to MMU, right? I didn't initialize MMU
so far.
Regards,
Ivan Pavic
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Basic bare metal ARM domain interface
2016-06-06 23:31 ` Ivan Pavic
@ 2016-06-07 14:18 ` Julien Grall
0 siblings, 0 replies; 12+ messages in thread
From: Julien Grall @ 2016-06-07 14:18 UTC (permalink / raw)
To: Ivan Pavic; +Cc: xen-devel, Jonathan Daugherty, Adam Wick, Stefano Stabellini
On 07/06/16 00:31, Ivan Pavic wrote:
> Hello Julien,
Hello Ivan,
> On Fri, Jun 03, 2016 at 11:23:33AM +0100, Julien Grall wrote:
>>
>>
>> On 02/06/16 20:09, Ivan Pavic wrote:
>>> Hello Julien,
>>
>> Hello Ivan,
>>
>>> On Thu, Jun 02, 2016 at 12:41:02PM +0100, Julien Grall wrote:
>>>>
>>>> Which compiler led to use a data abort? And where was the data
>>>> abort? In Xen or the guest?
>>>>
>>>
>>> When I compile app directly on ODROID I used:
>>> arm-linux-gnueabihf
>>> gcc version 4.8.4 (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.1)
>>>
>>> HVC instruction works form assembler, but when I call it from main, for
>>> example:
>>> HYPERVISOR_console_io (HYPERCALL_WRITE, SYSTEM_UP_LEN, SYSTEM_UP_MSG);
>>> then I get this in xl dmesg:
>>> traps.c:2450:d2v0 HSR=0x90000046 pc=0x40008250 gva=0 gpa=0000000000000000
>>
>> To be honest this looks like a latent issue in your app rather than
>> a bug in the compiler.
>>
>> I would try to find which instruction is causing the data abort.
>> Also is your app running with page table and cache enabled?
>>
>
> Page table and cache are related to MMU, right? I didn't initialize MMU
> so far.
All the memory buffer passed to the hypercall should be cacheable (see
xen/include/public/asm-arm.h for more details). I.e the MMU should be
enabled.
Otherwise, the behavior is unreliable because the memory attribute will
be different in Xen and the guest. Xen is mapping the region cacheable.
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2016-06-07 14:18 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-05-25 19:42 Basic bare metal ARM domain interface Ivan Pavić2
2016-05-27 10:04 ` Julien Grall
2016-05-27 13:19 ` Ivan Pavić2
[not found] ` <20160527211650.GA43457@galois.com>
2016-05-28 11:21 ` Ivan Pavić2
2016-05-30 20:21 ` Odgovor: " Ivan Pavić2
2016-05-31 9:53 ` Julien Grall
2016-06-01 20:06 ` Ivan Pavic
2016-06-02 11:41 ` Julien Grall
2016-06-02 19:09 ` Ivan Pavic
2016-06-03 10:23 ` Julien Grall
2016-06-06 23:31 ` Ivan Pavic
2016-06-07 14:18 ` Julien Grall
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).