* 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
[parent not found: <20160527211650.GA43457@galois.com>]
* 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).