Re: [U-Boot] U-Boot Digest, Vol 61, Issue 36
Hi All,
Hope everyone is doing great:)
I am trying to build U-boot:2013-04.But running into this error: mips64-nlm-elf-ld: arch/mips/cpu/mips64/start.o: relocation (null) against `board_init_f' can not be used when making a shared object; recompile with -fPIC arch/mips/cpu/mips64/start.o: could not read symbols: Bad value.
Initially,In file arch/mips/config.mk,I commented the flag: #LDFLAGS_FINAL += -pie This error resolved.But after relocation of u-boot code,we need this flag.So i need to uncomment this flag.and again i am running into this error agian.
Anyone faced this issue earlier.Anyone please provide pointers to resolve this.
Thanks in advance!!
Regards, Krishna
On Tue, Jun 25, 2013 at 3:30 PM, u-boot-request@lists.denx.de wrote:
Send U-Boot mailing list submissions to u-boot@lists.denx.de
To subscribe or unsubscribe via the World Wide Web, visit http://lists.denx.de/mailman/listinfo/u-boot or, via email, send a message with subject or body 'help' to u-boot-request@lists.denx.de
You can reach the person managing the list at u-boot-owner@lists.denx.de
When replying, please edit your Subject line so it is more specific than "Re: Contents of U-Boot digest..."
Today's Topics:
- Re: [PATCH v2 6/7] ARM: extend non-secure switch to also go into HYP mode (Andre Przywara)
- Re: dfu: using dfu-util -l shows different output (Lukasz Majewski)
- Re: dfu: using dfu-util -l shows different output (Heiko Schocher)
- Re: [PATCH] OpenRD: relocate environment to 640kB (Sascha Silbe)
Message: 1 Date: Tue, 25 Jun 2013 10:27:30 +0200 From: Andre Przywara andre.przywara@linaro.org Subject: Re: [U-Boot] [PATCH v2 6/7] ARM: extend non-secure switch to also go into HYP mode To: Nikolay Nikolaev nicknickolaev@gmail.com Cc: geoff.levand@linaro.org, u-boot@lists.denx.de, trini@ti.com, kvmarm@lists.cs.columbia.edu Message-ID: 51C95472.9030000@linaro.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 06/21/2013 04:38 PM, Nikolay Nikolaev wrote:
Hello,
On Thu, Jun 13, 2013 at 2:01 PM, Andre Przywara <andre.przywara@linaro.org mailto:andre.przywara@linaro.org> wrote:
For the KVM and XEN hypervisors to be usable, we need to enter the kernel in HYP mode. Now that we already are in non-secure state, HYP mode switching is within short reach. While doing the non-secure switch, we have to enable the HVC instruction and setup the HYP mode HVBAR (while still secure). The actual switch is done by dropping back from a HYP mode handler without actually leaving HYP mode, so we introduce a new handler routine in our new secure exception vector table. In the assembly switching routine we save and restore the banked LR and SP registers around the hypercall to do the actual HYP mode switch. The C routine first checks whether we are in HYP mode already and also whether the virtualization extensions are available. It also checks whether the HYP mode switch was finally successful. The bootm command part only adds and adjusts some error reporting. Signed-off-by: Andre Przywara <andre.przywara@linaro.org <mailto:andre.przywara@linaro.org>> --- arch/arm/cpu/armv7/nonsec_virt.S | 31++++++++++++++++++++++++++++---
arch/arm/include/asm/armv7.h | 7 +++++-- arch/arm/lib/bootm.c | 14 ++++++++++---- arch/arm/lib/virt-v7.c | 27 ++++++++++++++++++++++----- 4 files changed, 65 insertions(+), 14 deletions(-) diff --git a/arch/arm/cpu/armv7/nonsec_virt.S b/arch/arm/cpu/armv7/nonsec_virt.S index 919f6e9..950da6f 100644 --- a/arch/arm/cpu/armv7/nonsec_virt.S +++ b/arch/arm/cpu/armv7/nonsec_virt.S @@ -1,5 +1,5 @@ /* - * code for switching cores into non-secure state + * code for switching cores into non-secure state and into HYP mode * * Copyright (c) 2013 Andre Przywara <andre.przywara@linaro.org <mailto:andre.przywara@linaro.org>> * @@ -26,14 +26,14 @@ #include <asm/gic.h> #include <asm/armv7.h> -/* the vector table for secure state */ +/* the vector table for secure state and HYP mode */ _secure_vectors: .word 0 /* reset */ .word 0 /* undef */ adr pc, _secure_monitor .word 0 .word 0 - .word 0 + adr pc, _hyp_trap .word 0 .word 0 .word 0 /* pad */ @@ -50,10 +50,23 @@ _secure_monitor: bic r1, r1, #0x4e @ clear IRQ, FIQ, EA, nET bits orr r1, r1, #0x31 @ enable NS, AW, FW bits + mrc p15, 0, r0, c0, c1, 1 @ read ID_PFR1 + and r0, r0, #CPUID_ARM_VIRT_MASK @ mask virtualization bits + cmp r0, #(1 << CPUID_ARM_VIRT_SHIFT) + orreq r1, r1, #0x100 @ allow HVCinstruction
+ mcr p15, 0, r1, c1, c1, 0 @ write SCR (with NS bit set) + mrceq p15, 0, r0, c12, c0, 1 @ get MVBAR value + mcreq p15, 4, r0, c12, c0, 0 @ write HVBAR + movs pc, lr @ return to non-secure SVC +_hyp_trap: + .byte 0x00, 0xe3, 0x0e, 0xe1 @ mrs lr, elr_hyp + mov pc, lr @ do no switch modes, but + @ return to caller + /* * Secondary CPUs start here and call the code for the core specific parts * of the non-secure and HYP mode transition. The GIC distributor specific @@ -69,6 +82,7 @@ _smp_pen: mcr p15, 0, r1, c12, c0, 0 @ set VBAR bl _nonsec_init + bl _hyp_initIf I get it right, _nonsec_init stores the GICC address. Adding _hyp_init here overwrites r3. In effect the following lines do something on the stack (sp).
Eek. Good catch. Thanks for spotting. The fix will be included in the next round. Which kind of hints that acknowledging the wakeup IPI is not really necessary, as it was suspected earlier already.
ldr r1, [r3, #0x0c] @ read GICDacknowledge
str r1, [r3, #0x10] @ write GICD EOIcan you add these 0x0c and 0x10 constants to gic.h.
Sure. And I will fix the wrong comments on the way ;-)
Thanks for the review! Andre
@@ -145,3 +159,14 @@ _nonsec_init: str r1, [r2] @ allow private interrupts bx lr + +.globl _hyp_init +_hyp_init: + mov r2, lr + mov r3, sp @ save SVC copy of LR and SP + isb + .byte 0x70, 0x00, 0x40, 0xe1 @ hvc #0 + mov sp, r3 + mov lr, r2 @ fix HYP mode banked LR and SP + + bx lr diff --git a/arch/arm/include/asm/armv7.hb/arch/arm/include/asm/armv7.h
index 04545b9..8c3a85e 100644 --- a/arch/arm/include/asm/armv7.h +++ b/arch/arm/include/asm/armv7.h @@ -89,15 +89,18 @@ void v7_outer_cache_inval_range(u32 start, u32end);
#ifdef CONFIG_ARMV7_VIRT -#define HYP_ERR_NO_SEC_EXT 2 +#define HYP_ERR_ALREADY_HYP_MODE 1 +#define HYP_ERR_NO_VIRT_EXT 2 #define HYP_ERR_NO_GIC_ADDRESS 3 #define HYP_ERR_GIC_ADDRESS_ABOVE_4GB 4 +#define HYP_ERR_NOT_HYP_MODE 5 -int armv7_switch_nonsec(void); +int armv7_switch_hyp(void); /* defined in cpu/armv7/nonsec_virt.S */ void _nonsec_init(void); void _smp_pen(void); +void _hyp_init(void); #endif /* CONFIG_ARMV7_VIRT */ #endif /* ! __ASSEMBLY__ */ diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c index 8251a89..7edd84d 100644 --- a/arch/arm/lib/bootm.c +++ b/arch/arm/lib/bootm.c @@ -227,12 +227,15 @@ static void boot_prep_linux(bootm_headers_t *images) hang(); } #ifdef CONFIG_ARMV7_VIRT - switch (armv7_switch_nonsec()) { + switch (armv7_switch_hyp()) { case 0: - debug("entered non-secure state\n"); + debug("entered HYP mode\n"); break; - case HYP_ERR_NO_SEC_EXT: - printf("HYP mode: Security extensions not implemented.\n"); + case HYP_ERR_ALREADY_HYP_MODE: + debug("CPU already in HYP mode\n"); + break; + case HYP_ERR_NO_VIRT_EXT: + printf("HYP mode: Virtualization extensions not implemented.\n"); break; case HYP_ERR_NO_GIC_ADDRESS: printf("HYP mode: could not determine GICaddress.\n");
@@ -240,6 +243,9 @@ static void boot_prep_linux(bootm_headers_t*images)
case HYP_ERR_GIC_ADDRESS_ABOVE_4GB: printf("HYP mode: PERIPHBASE is above 4 GB, cannot access this.\n"); break; + case HYP_ERR_NOT_HYP_MODE: + printf("HYP mode: switch not successful.\n"); + break; } #endif } diff --git a/arch/arm/lib/virt-v7.c b/arch/arm/lib/virt-v7.c index 6946e4d..1e206b9 100644 --- a/arch/arm/lib/virt-v7.c +++ b/arch/arm/lib/virt-v7.c @@ -3,6 +3,7 @@ * Andre Przywara, Linaro * * Routines to transition ARMv7 processors from secure into non-secure state + * and from non-secure SVC into HYP mode * needed to enable ARMv7 virtualization for current hypervisors * * See file CREDITS for list of people who contributed to this @@ -29,6 +30,14 @@ #include <asm/gic.h> #include <asm/io.h> +static unsigned int read_cpsr(void) +{ + unsigned int reg; + + asm volatile ("mrs %0, cpsr\n" : "=r" (reg)); + return reg; +} + static unsigned int read_id_pfr1(void) { unsigned int reg; @@ -110,16 +119,20 @@ static void kick_secondary_cpus(char *gicdptr) writel(1U << 24, &gicdptr[GICD_SGIR]); } -int armv7_switch_nonsec(void) +int armv7_switch_hyp(void) { unsigned int reg, ret; char *gicdptr; unsigned itlinesnr, i; - /* check whether the CPU supports the security extensions */ + /* check whether we are in HYP mode already */ + if ((read_cpsr() & 0x1f) == 0x1a) + return HYP_ERR_ALREADY_HYP_MODE; + + /* check whether the CPU supports the virtualization extensions */ reg = read_id_pfr1(); - if ((reg & 0xF0) == 0) - return HYP_ERR_NO_SEC_EXT; + if ((reg & CPUID_ARM_VIRT_MASK) != 1 << CPUID_ARM_VIRT_SHIFT) + return HYP_ERR_NO_VIRT_EXT; set_generic_timer_frequency(); @@ -147,8 +160,12 @@ int armv7_switch_nonsec(void) kick_secondary_cpus(gicdptr); - /* call the non-sec switching code on this CPU also */ + /* call the HYP switching code on this CPU also */ _nonsec_init(); + _hyp_init(); + + if ((read_cpsr() & 0x1F) != 0x1a) + return HYP_ERR_NOT_HYP_MODE; return 0; } -- 1.7.12.1 _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu <mailto:kvmarm@lists.cs.columbia.edu> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarmregards, Nikolay Nikolaev
Message: 2 Date: Tue, 25 Jun 2013 10:44:38 +0200 From: Lukasz Majewski l.majewski@samsung.com Subject: Re: [U-Boot] dfu: using dfu-util -l shows different output To: Heiko Schocher hs@denx.de Cc: Marek Vasut marex@denx.de, "u-boot@lists.denx.de" u-boot@lists.denx.de, Kyungmin Park kyungmin.park@samsung.com, Pantelis Antoniou panto@antoniou-consulting.com, "Egli, Samuel" samuel.egli@siemens.com Message-ID: 20130625104438.2538a880@amdc308.digital.local Content-Type: text/plain; charset=US-ASCII
Hi Heiko,
Hello Pantelis,
Am 25.06.2013 10:16, schrieb Pantelis Antoniou:
Heiko,
I don't think the gadget is initialized before you issue a dfu call.
So that makes sense.
?
I call from the host "dfu-util -l" so the gadget on the board should do the answer ... or?
The gadget is not initialized here (so the dfu-util -l shows no output).
After transfer it shows information about proper alt settings.
This is correct behaviour, but I had discussion about this with Tom and we agreed, that it would be nice to have "dfu-util -l" exporting from very beginning the alt setting information.
Frankly, I had too much other work to implement it.
However, I think, that it would be a very useful feature (e.g. to get alt settings layout at HOST to facilitate automated flashing).
Let's wait until Tom wakes up and have an authoritative answer.
Ok!
bye, Heiko
Regards
-- Pantelis
On Jun 25, 2013, at 11:08 AM, Heiko Schocher wrote:
Hello,
using "dfu-util -l" shows different output connecting to an am335x based board and using dfu_nand.c with current u-boot:
after resetting the board I get:
# dfu-util -l dfu-util 0.5
(C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc. (C) 2010-2011 Tormod Volden (DfuSe support) This program is Free Software and has ABSOLUTELY NO WARRANTY
dfu-util does currently only support DFU version 1.0
Found Runtime: [0525:bd00] devnum=0, cfg=2, intf=0, alt=0, name="Device Firmware Upgrade" #
after a dfu transfer I see:
# dfu-util -l dfu-util 0.5
(C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc. (C) 2010-2011 Tormod Volden (DfuSe support) This program is Free Software and has ABSOLUTELY NO WARRANTY
dfu-util does currently only support DFU version 1.0
Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=0, name="SPL" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=1, name="SPL.backup1" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=2, name="SPL.backup2" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=3, name="SPL.backup3" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=4, name="u-boot" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=5, name="kernel_a" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=6, name="kernel_b" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=7, name="rootfs" #
Which I expected ...
U-Boot environment variable:
U-Boot# print dfu_alt_info dfu_alt_info=SPL part 0 1;SPL.backup1 part 0 2;SPL.backup2 part 0 3;SPL.backup3 part 0 4;u-boot part 0 5;kernel_a part 0 7;kernel_b part 0 8;rootfs part 0 10 U-Boot#
Is this a bug or a feature?
bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
-- Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
Message: 3 Date: Tue, 25 Jun 2013 10:55:14 +0200 From: Heiko Schocher hs@denx.de Subject: Re: [U-Boot] dfu: using dfu-util -l shows different output To: Lukasz Majewski l.majewski@samsung.com Cc: Marek Vasut marex@denx.de, "u-boot@lists.denx.de" u-boot@lists.denx.de, Kyungmin Park kyungmin.park@samsung.com, Pantelis Antoniou panto@antoniou-consulting.com, "Egli, Samuel" samuel.egli@siemens.com Message-ID: 51C95AF2.6030201@denx.de Content-Type: text/plain; charset=ISO-8859-1
Hello Lukasz,
Am 25.06.2013 10:44, schrieb Lukasz Majewski:
Hi Heiko,
Hello Pantelis,
Am 25.06.2013 10:16, schrieb Pantelis Antoniou:
Heiko,
I don't think the gadget is initialized before you issue a dfu call.
So that makes sense.
?
I call from the host "dfu-util -l" so the gadget on the board should do the answer ... or?
The gadget is not initialized here (so the dfu-util -l shows no output).
After transfer it shows information about proper alt settings.
This is correct behaviour, but I had discussion about this with Tom and we agreed, that it would be nice to have "dfu-util -l" exporting from very beginning the alt setting information.
Yes, I vote for this too. Connecting to a board, I first would do a "dfu-util -l" to look, what is possible to update here ...
Frankly, I had too much other work to implement it.
However, I think, that it would be a very useful feature (e.g. to get alt settings layout at HOST to facilitate automated flashing).
Hmm... I digged into the code, but not really found a place where I have to start. Can you give me a hint where to start? So maybe, I can do it?
Thanks!
bye, Heiko
Let's wait until Tom wakes up and have an authoritative answer.
Ok!
bye, Heiko
Regards
-- Pantelis
On Jun 25, 2013, at 11:08 AM, Heiko Schocher wrote:
Hello,
using "dfu-util -l" shows different output connecting to an am335x based board and using dfu_nand.c with current u-boot:
after resetting the board I get:
# dfu-util -l dfu-util 0.5
(C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc. (C) 2010-2011 Tormod Volden (DfuSe support) This program is Free Software and has ABSOLUTELY NO WARRANTY
dfu-util does currently only support DFU version 1.0
Found Runtime: [0525:bd00] devnum=0, cfg=2, intf=0, alt=0, name="Device Firmware Upgrade" #
after a dfu transfer I see:
# dfu-util -l dfu-util 0.5
(C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc. (C) 2010-2011 Tormod Volden (DfuSe support) This program is Free Software and has ABSOLUTELY NO WARRANTY
dfu-util does currently only support DFU version 1.0
Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=0, name="SPL" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=1, name="SPL.backup1" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=2, name="SPL.backup2" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=3, name="SPL.backup3" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=4, name="u-boot" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=5, name="kernel_a" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=6, name="kernel_b" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=7, name="rootfs" #
Which I expected ...
U-Boot environment variable:
U-Boot# print dfu_alt_info dfu_alt_info=SPL part 0 1;SPL.backup1 part 0 2;SPL.backup2 part 0 3;SPL.backup3 part 0 4;u-boot part 0 5;kernel_a part 0 7;kernel_b part 0 8;rootfs part 0 10 U-Boot#
Is this a bug or a feature?
bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Message: 4 Date: Tue, 25 Jun 2013 11:42:53 +0200 From: Sascha Silbe t-uboot@infra-silbe.de Subject: Re: [U-Boot] [PATCH] OpenRD: relocate environment to 640kB To: Albert ARIBAUD albert.u.boot@aribaud.net Cc: Tom Rini trini@ti.com, u-boot@lists.denx.de Message-ID: toeppvail0i.fsf@twin.sascha.silbe.org Content-Type: text/plain; charset="us-ascii"
Hello Albert, hello Tom,
Albert ARIBAUD albert.u.boot@aribaud.net writes:
[Move environment to account for increase in U-Boot size]
This patch is for 2013.10, not 2013.07, but I prefer raising the issue as early as possible.
If there is no way to make things smoother, then I think the 2013.10 release notes should contain a red, blinking, paragraph about this. I would *hate* it if people were not warned and given a method to port their current environment setting over.
Possibly even, the 2013.07 could have a warning about the change to come, so that people have a better chance yet to prepare for the change.
The situation has gotten better recently and U-Boot fits into the previous partition size of 384KiB again. So it isn't broken on OpenRD anymore and the above would seem like a good approach.
Where are the U-Boot Release Notes located? Who is responsible for editing them?
Sascha
Hi All,
I am trying to build U-boot:2013-04.But running into this error: mips64-nlm-elf-ld: arch/mips/cpu/mips64/start.o: relocation (null) against `board_init_f' can not be used when making a shared object; recompile with -fPIC arch/mips/cpu/mips64/start.o: could not read symbols: Bad value. Can ayone please provide me pointer what could be issue here.
Regards, krishna
On Wed, Jun 26, 2013 at 11:52 AM, krishna dwivedi < krishna.dwivedi01@gmail.com> wrote:
Hi All,
Hope everyone is doing great:)
I am trying to build U-boot:2013-04.But running into this error: mips64-nlm-elf-ld: arch/mips/cpu/mips64/start.o: relocation (null) against `board_init_f' can not be used when making a shared object; recompile with -fPIC arch/mips/cpu/mips64/start.o: could not read symbols: Bad value.
Initially,In file arch/mips/config.mk,I commented the flag: #LDFLAGS_FINAL += -pie This error resolved.But after relocation of u-boot code,we need this flag.So i need to uncomment this flag.and again i am running into this error agian.
Anyone faced this issue earlier.Anyone please provide pointers to resolve this.
Thanks in advance!!
Regards, Krishna
On Tue, Jun 25, 2013 at 3:30 PM, u-boot-request@lists.denx.de wrote:
Send U-Boot mailing list submissions to u-boot@lists.denx.de
To subscribe or unsubscribe via the World Wide Web, visit http://lists.denx.de/mailman/listinfo/u-boot or, via email, send a message with subject or body 'help' to u-boot-request@lists.denx.de
You can reach the person managing the list at u-boot-owner@lists.denx.de
When replying, please edit your Subject line so it is more specific than "Re: Contents of U-Boot digest..."
Today's Topics:
- Re: [PATCH v2 6/7] ARM: extend non-secure switch to also go into HYP mode (Andre Przywara)
- Re: dfu: using dfu-util -l shows different output (Lukasz Majewski)
- Re: dfu: using dfu-util -l shows different output (Heiko Schocher)
- Re: [PATCH] OpenRD: relocate environment to 640kB (Sascha Silbe)
Message: 1 Date: Tue, 25 Jun 2013 10:27:30 +0200 From: Andre Przywara andre.przywara@linaro.org Subject: Re: [U-Boot] [PATCH v2 6/7] ARM: extend non-secure switch to also go into HYP mode To: Nikolay Nikolaev nicknickolaev@gmail.com Cc: geoff.levand@linaro.org, u-boot@lists.denx.de, trini@ti.com, kvmarm@lists.cs.columbia.edu Message-ID: 51C95472.9030000@linaro.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 06/21/2013 04:38 PM, Nikolay Nikolaev wrote:
Hello,
On Thu, Jun 13, 2013 at 2:01 PM, Andre Przywara <andre.przywara@linaro.org mailto:andre.przywara@linaro.org> wrote:
For the KVM and XEN hypervisors to be usable, we need to enter the kernel in HYP mode. Now that we already are in non-secure state, HYP mode switching is within short reach. While doing the non-secure switch, we have to enable the HVC instruction and setup the HYP mode HVBAR (while still secure). The actual switch is done by dropping back from a HYP mode handler without actually leaving HYP mode, so we introduce a new handler routine in our new secure exception vector table. In the assembly switching routine we save and restore the banked LR and SP registers around the hypercall to do the actual HYP mode switch. The C routine first checks whether we are in HYP mode already and also whether the virtualization extensions are available. It also checks whether the HYP mode switch was finally successful. The bootm command part only adds and adjusts some error reporting. Signed-off-by: Andre Przywara <andre.przywara@linaro.org <mailto:andre.przywara@linaro.org>> --- arch/arm/cpu/armv7/nonsec_virt.S | 31++++++++++++++++++++++++++++---
arch/arm/include/asm/armv7.h | 7 +++++-- arch/arm/lib/bootm.c | 14 ++++++++++---- arch/arm/lib/virt-v7.c | 27 ++++++++++++++++++++++----- 4 files changed, 65 insertions(+), 14 deletions(-) diff --git a/arch/arm/cpu/armv7/nonsec_virt.S b/arch/arm/cpu/armv7/nonsec_virt.S index 919f6e9..950da6f 100644 --- a/arch/arm/cpu/armv7/nonsec_virt.S +++ b/arch/arm/cpu/armv7/nonsec_virt.S @@ -1,5 +1,5 @@ /* - * code for switching cores into non-secure state + * code for switching cores into non-secure state and into HYP mode * * Copyright (c) 2013 Andre Przywara <andre.przywara@linaro.org <mailto:andre.przywara@linaro.org>> * @@ -26,14 +26,14 @@ #include <asm/gic.h> #include <asm/armv7.h> -/* the vector table for secure state */ +/* the vector table for secure state and HYP mode */ _secure_vectors: .word 0 /* reset */ .word 0 /* undef */ adr pc, _secure_monitor .word 0 .word 0 - .word 0 + adr pc, _hyp_trap .word 0 .word 0 .word 0 /* pad */ @@ -50,10 +50,23 @@ _secure_monitor: bic r1, r1, #0x4e @ clear IRQ, FIQ, EA, nET bits orr r1, r1, #0x31 @ enable NS, AW, FW bits + mrc p15, 0, r0, c0, c1, 1 @ read ID_PFR1 + and r0, r0, #CPUID_ARM_VIRT_MASK @ mask virtualization bits + cmp r0, #(1 << CPUID_ARM_VIRT_SHIFT) + orreq r1, r1, #0x100 @ allow HVCinstruction
+ mcr p15, 0, r1, c1, c1, 0 @ write SCR (with NS bit set) + mrceq p15, 0, r0, c12, c0, 1 @ get MVBAR value + mcreq p15, 4, r0, c12, c0, 0 @ write HVBAR + movs pc, lr @ return to non-secure SVC +_hyp_trap: + .byte 0x00, 0xe3, 0x0e, 0xe1 @ mrs lr, elr_hyp + mov pc, lr @ do no switch modes, but + @ return to caller + /* * Secondary CPUs start here and call the code for the core specific parts * of the non-secure and HYP mode transition. The GIC distributor specific @@ -69,6 +82,7 @@ _smp_pen: mcr p15, 0, r1, c12, c0, 0 @ set VBAR bl _nonsec_init + bl _hyp_initIf I get it right, _nonsec_init stores the GICC address. Adding _hyp_init here overwrites r3. In effect the following lines do something on the stack (sp).
Eek. Good catch. Thanks for spotting. The fix will be included in the next round. Which kind of hints that acknowledging the wakeup IPI is not really necessary, as it was suspected earlier already.
ldr r1, [r3, #0x0c] @ read GICDacknowledge
str r1, [r3, #0x10] @ write GICD EOIcan you add these 0x0c and 0x10 constants to gic.h.
Sure. And I will fix the wrong comments on the way ;-)
Thanks for the review! Andre
@@ -145,3 +159,14 @@ _nonsec_init: str r1, [r2] @ allow private interrupts bx lr + +.globl _hyp_init +_hyp_init: + mov r2, lr + mov r3, sp @ save SVC copy of LR and SP + isb + .byte 0x70, 0x00, 0x40, 0xe1 @ hvc #0 + mov sp, r3 + mov lr, r2 @ fix HYP mode banked LR and SP + + bx lr diff --git a/arch/arm/include/asm/armv7.hb/arch/arm/include/asm/armv7.h
index 04545b9..8c3a85e 100644 --- a/arch/arm/include/asm/armv7.h +++ b/arch/arm/include/asm/armv7.h @@ -89,15 +89,18 @@ void v7_outer_cache_inval_range(u32 start, u32end);
#ifdef CONFIG_ARMV7_VIRT -#define HYP_ERR_NO_SEC_EXT 2 +#define HYP_ERR_ALREADY_HYP_MODE 1 +#define HYP_ERR_NO_VIRT_EXT 2 #define HYP_ERR_NO_GIC_ADDRESS 3 #define HYP_ERR_GIC_ADDRESS_ABOVE_4GB 4 +#define HYP_ERR_NOT_HYP_MODE 5 -int armv7_switch_nonsec(void); +int armv7_switch_hyp(void); /* defined in cpu/armv7/nonsec_virt.S */ void _nonsec_init(void); void _smp_pen(void); +void _hyp_init(void); #endif /* CONFIG_ARMV7_VIRT */ #endif /* ! __ASSEMBLY__ */ diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c index 8251a89..7edd84d 100644 --- a/arch/arm/lib/bootm.c +++ b/arch/arm/lib/bootm.c @@ -227,12 +227,15 @@ static void boot_prep_linux(bootm_headers_t *images) hang(); } #ifdef CONFIG_ARMV7_VIRT - switch (armv7_switch_nonsec()) { + switch (armv7_switch_hyp()) { case 0: - debug("entered non-secure state\n"); + debug("entered HYP mode\n"); break; - case HYP_ERR_NO_SEC_EXT: - printf("HYP mode: Security extensions not implemented.\n"); + case HYP_ERR_ALREADY_HYP_MODE: + debug("CPU already in HYP mode\n"); + break; + case HYP_ERR_NO_VIRT_EXT: + printf("HYP mode: Virtualization extensions not implemented.\n"); break; case HYP_ERR_NO_GIC_ADDRESS: printf("HYP mode: could not determine GICaddress.\n");
@@ -240,6 +243,9 @@ static void boot_prep_linux(bootm_headers_t*images)
case HYP_ERR_GIC_ADDRESS_ABOVE_4GB: printf("HYP mode: PERIPHBASE is above 4 GB, cannot access this.\n"); break; + case HYP_ERR_NOT_HYP_MODE: + printf("HYP mode: switch not successful.\n"); + break; } #endif } diff --git a/arch/arm/lib/virt-v7.c b/arch/arm/lib/virt-v7.c index 6946e4d..1e206b9 100644 --- a/arch/arm/lib/virt-v7.c +++ b/arch/arm/lib/virt-v7.c @@ -3,6 +3,7 @@ * Andre Przywara, Linaro * * Routines to transition ARMv7 processors from secure into non-secure state + * and from non-secure SVC into HYP mode * needed to enable ARMv7 virtualization for current hypervisors * * See file CREDITS for list of people who contributed to this @@ -29,6 +30,14 @@ #include <asm/gic.h> #include <asm/io.h> +static unsigned int read_cpsr(void) +{ + unsigned int reg; + + asm volatile ("mrs %0, cpsr\n" : "=r" (reg)); + return reg; +} + static unsigned int read_id_pfr1(void) { unsigned int reg; @@ -110,16 +119,20 @@ static void kick_secondary_cpus(char *gicdptr) writel(1U << 24, &gicdptr[GICD_SGIR]); } -int armv7_switch_nonsec(void) +int armv7_switch_hyp(void) { unsigned int reg, ret; char *gicdptr; unsigned itlinesnr, i; - /* check whether the CPU supports the security extensions */ + /* check whether we are in HYP mode already */ + if ((read_cpsr() & 0x1f) == 0x1a) + return HYP_ERR_ALREADY_HYP_MODE; + + /* check whether the CPU supports the virtualization extensions */ reg = read_id_pfr1(); - if ((reg & 0xF0) == 0) - return HYP_ERR_NO_SEC_EXT; + if ((reg & CPUID_ARM_VIRT_MASK) != 1 <<CPUID_ARM_VIRT_SHIFT)
+ return HYP_ERR_NO_VIRT_EXT; set_generic_timer_frequency(); @@ -147,8 +160,12 @@ int armv7_switch_nonsec(void) kick_secondary_cpus(gicdptr); - /* call the non-sec switching code on this CPU also */ + /* call the HYP switching code on this CPU also */ _nonsec_init(); + _hyp_init(); + + if ((read_cpsr() & 0x1F) != 0x1a) + return HYP_ERR_NOT_HYP_MODE; return 0; } -- 1.7.12.1 _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu <mailto:kvmarm@lists.cs.columbia.edu> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarmregards, Nikolay Nikolaev
Message: 2 Date: Tue, 25 Jun 2013 10:44:38 +0200 From: Lukasz Majewski l.majewski@samsung.com Subject: Re: [U-Boot] dfu: using dfu-util -l shows different output To: Heiko Schocher hs@denx.de Cc: Marek Vasut marex@denx.de, "u-boot@lists.denx.de" u-boot@lists.denx.de, Kyungmin Park <kyungmin.park@samsung.com
,
Pantelis Antoniou <panto@antoniou-consulting.com>, "Egli,Samuel" samuel.egli@siemens.com Message-ID: 20130625104438.2538a880@amdc308.digital.local Content-Type: text/plain; charset=US-ASCII
Hi Heiko,
Hello Pantelis,
Am 25.06.2013 10:16, schrieb Pantelis Antoniou:
Heiko,
I don't think the gadget is initialized before you issue a dfu call.
So that makes sense.
?
I call from the host "dfu-util -l" so the gadget on the board should do the answer ... or?
The gadget is not initialized here (so the dfu-util -l shows no output).
After transfer it shows information about proper alt settings.
This is correct behaviour, but I had discussion about this with Tom and we agreed, that it would be nice to have "dfu-util -l" exporting from very beginning the alt setting information.
Frankly, I had too much other work to implement it.
However, I think, that it would be a very useful feature (e.g. to get alt settings layout at HOST to facilitate automated flashing).
Let's wait until Tom wakes up and have an authoritative answer.
Ok!
bye, Heiko
Regards
-- Pantelis
On Jun 25, 2013, at 11:08 AM, Heiko Schocher wrote:
Hello,
using "dfu-util -l" shows different output connecting to an am335x based board and using dfu_nand.c with current u-boot:
after resetting the board I get:
# dfu-util -l dfu-util 0.5
(C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc. (C) 2010-2011 Tormod Volden (DfuSe support) This program is Free Software and has ABSOLUTELY NO WARRANTY
dfu-util does currently only support DFU version 1.0
Found Runtime: [0525:bd00] devnum=0, cfg=2, intf=0, alt=0, name="Device Firmware Upgrade" #
after a dfu transfer I see:
# dfu-util -l dfu-util 0.5
(C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc. (C) 2010-2011 Tormod Volden (DfuSe support) This program is Free Software and has ABSOLUTELY NO WARRANTY
dfu-util does currently only support DFU version 1.0
Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=0, name="SPL" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=1, name="SPL.backup1" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=2, name="SPL.backup2" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=3, name="SPL.backup3" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=4, name="u-boot" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=5, name="kernel_a" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=6, name="kernel_b" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=7, name="rootfs" #
Which I expected ...
U-Boot environment variable:
U-Boot# print dfu_alt_info dfu_alt_info=SPL part 0 1;SPL.backup1 part 0 2;SPL.backup2 part 0 3;SPL.backup3 part 0 4;u-boot part 0 5;kernel_a part 0 7;kernel_b part 0 8;rootfs part 0 10 U-Boot#
Is this a bug or a feature?
bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
-- Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
Message: 3 Date: Tue, 25 Jun 2013 10:55:14 +0200 From: Heiko Schocher hs@denx.de Subject: Re: [U-Boot] dfu: using dfu-util -l shows different output To: Lukasz Majewski l.majewski@samsung.com Cc: Marek Vasut marex@denx.de, "u-boot@lists.denx.de" u-boot@lists.denx.de, Kyungmin Park <kyungmin.park@samsung.com
,
Pantelis Antoniou <panto@antoniou-consulting.com>, "Egli,Samuel" samuel.egli@siemens.com Message-ID: 51C95AF2.6030201@denx.de Content-Type: text/plain; charset=ISO-8859-1
Hello Lukasz,
Am 25.06.2013 10:44, schrieb Lukasz Majewski:
Hi Heiko,
Hello Pantelis,
Am 25.06.2013 10:16, schrieb Pantelis Antoniou:
Heiko,
I don't think the gadget is initialized before you issue a dfu call.
So that makes sense.
?
I call from the host "dfu-util -l" so the gadget on the board should do the answer ... or?
The gadget is not initialized here (so the dfu-util -l shows no output).
After transfer it shows information about proper alt settings.
This is correct behaviour, but I had discussion about this with Tom and we agreed, that it would be nice to have "dfu-util -l" exporting from very beginning the alt setting information.
Yes, I vote for this too. Connecting to a board, I first would do a "dfu-util -l" to look, what is possible to update here ...
Frankly, I had too much other work to implement it.
However, I think, that it would be a very useful feature (e.g. to get alt settings layout at HOST to facilitate automated flashing).
Hmm... I digged into the code, but not really found a place where I have to start. Can you give me a hint where to start? So maybe, I can do it?
Thanks!
bye, Heiko
Let's wait until Tom wakes up and have an authoritative answer.
Ok!
bye, Heiko
Regards
-- Pantelis
On Jun 25, 2013, at 11:08 AM, Heiko Schocher wrote:
Hello,
using "dfu-util -l" shows different output connecting to an am335x based board and using dfu_nand.c with current u-boot:
after resetting the board I get:
# dfu-util -l dfu-util 0.5
(C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc. (C) 2010-2011 Tormod Volden (DfuSe support) This program is Free Software and has ABSOLUTELY NO WARRANTY
dfu-util does currently only support DFU version 1.0
Found Runtime: [0525:bd00] devnum=0, cfg=2, intf=0, alt=0, name="Device Firmware Upgrade" #
after a dfu transfer I see:
# dfu-util -l dfu-util 0.5
(C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc. (C) 2010-2011 Tormod Volden (DfuSe support) This program is Free Software and has ABSOLUTELY NO WARRANTY
dfu-util does currently only support DFU version 1.0
Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=0, name="SPL" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=1, name="SPL.backup1" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=2, name="SPL.backup2" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=3, name="SPL.backup3" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=4, name="u-boot" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=5, name="kernel_a" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=6, name="kernel_b" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=7, name="rootfs" #
Which I expected ...
U-Boot environment variable:
U-Boot# print dfu_alt_info dfu_alt_info=SPL part 0 1;SPL.backup1 part 0 2;SPL.backup2 part 0 3;SPL.backup3 part 0 4;u-boot part 0 5;kernel_a part 0 7;kernel_b part 0 8;rootfs part 0 10 U-Boot#
Is this a bug or a feature?
bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Message: 4 Date: Tue, 25 Jun 2013 11:42:53 +0200 From: Sascha Silbe t-uboot@infra-silbe.de Subject: Re: [U-Boot] [PATCH] OpenRD: relocate environment to 640kB To: Albert ARIBAUD albert.u.boot@aribaud.net Cc: Tom Rini trini@ti.com, u-boot@lists.denx.de Message-ID: toeppvail0i.fsf@twin.sascha.silbe.org Content-Type: text/plain; charset="us-ascii"
Hello Albert, hello Tom,
Albert ARIBAUD albert.u.boot@aribaud.net writes:
[Move environment to account for increase in U-Boot size]
This patch is for 2013.10, not 2013.07, but I prefer raising the issue as early as possible.
If there is no way to make things smoother, then I think the 2013.10 release notes should contain a red, blinking, paragraph about this. I would *hate* it if people were not warned and given a method to port their current environment setting over.
Possibly even, the 2013.07 could have a warning about the change to come, so that people have a better chance yet to prepare for the change.
The situation has gotten better recently and U-Boot fits into the previous partition size of 384KiB again. So it isn't broken on OpenRD anymore and the above would seem like a good approach.
Where are the U-Boot Release Notes located? Who is responsible for editing them?
Sascha
Hi All,
Can anyone please provide me poinet on this.
Regards, Krishna
On Wed, Jun 26, 2013 at 12:54 PM, krishna dwivedi < krishna.dwivedi01@gmail.com> wrote:
Hi All,
I am trying to build U-boot:2013-04.But running into this error: mips64-nlm-elf-ld: arch/mips/cpu/mips64/start.o: relocation (null) against `board_init_f' can not be used when making a shared object; recompile with -fPIC arch/mips/cpu/mips64/start.o: could not read symbols: Bad value. Can ayone please provide me pointer what could be issue here.
Regards, krishna
On Wed, Jun 26, 2013 at 11:52 AM, krishna dwivedi < krishna.dwivedi01@gmail.com> wrote:
Hi All,
Hope everyone is doing great:)
I am trying to build U-boot:2013-04.But running into this error: mips64-nlm-elf-ld: arch/mips/cpu/mips64/start.o: relocation (null) against `board_init_f' can not be used when making a shared object; recompile with -fPIC arch/mips/cpu/mips64/start.o: could not read symbols: Bad value.
Initially,In file arch/mips/config.mk,I commented the flag: #LDFLAGS_FINAL += -pie This error resolved.But after relocation of u-boot code,we need this flag.So i need to uncomment this flag.and again i am running into this error agian.
Anyone faced this issue earlier.Anyone please provide pointers to resolve this.
Thanks in advance!!
Regards, Krishna
On Tue, Jun 25, 2013 at 3:30 PM, u-boot-request@lists.denx.de wrote:
Send U-Boot mailing list submissions to u-boot@lists.denx.de
To subscribe or unsubscribe via the World Wide Web, visit http://lists.denx.de/mailman/listinfo/u-boot or, via email, send a message with subject or body 'help' to u-boot-request@lists.denx.de
You can reach the person managing the list at u-boot-owner@lists.denx.de
When replying, please edit your Subject line so it is more specific than "Re: Contents of U-Boot digest..."
Today's Topics:
- Re: [PATCH v2 6/7] ARM: extend non-secure switch to also go into HYP mode (Andre Przywara)
- Re: dfu: using dfu-util -l shows different output (Lukasz Majewski)
- Re: dfu: using dfu-util -l shows different output (Heiko Schocher)
- Re: [PATCH] OpenRD: relocate environment to 640kB (Sascha Silbe)
Message: 1 Date: Tue, 25 Jun 2013 10:27:30 +0200 From: Andre Przywara andre.przywara@linaro.org Subject: Re: [U-Boot] [PATCH v2 6/7] ARM: extend non-secure switch to also go into HYP mode To: Nikolay Nikolaev nicknickolaev@gmail.com Cc: geoff.levand@linaro.org, u-boot@lists.denx.de, trini@ti.com, kvmarm@lists.cs.columbia.edu Message-ID: 51C95472.9030000@linaro.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 06/21/2013 04:38 PM, Nikolay Nikolaev wrote:
Hello,
On Thu, Jun 13, 2013 at 2:01 PM, Andre Przywara <andre.przywara@linaro.org mailto:andre.przywara@linaro.org> wrote:
For the KVM and XEN hypervisors to be usable, we need to enter the kernel in HYP mode. Now that we already are in non-secure state, HYP mode switching is within short reach. While doing the non-secure switch, we have to enable the HVC instruction and setup the HYP mode HVBAR (while still secure). The actual switch is done by dropping back from a HYP mode handler without actually leaving HYP mode, so we introduce a new handler routine in our new secure exception vector table. In the assembly switching routine we save and restore the banked LR and SP registers around the hypercall to do the actual HYP mode switch. The C routine first checks whether we are in HYP mode already and also whether the virtualization extensions are available. It also checks whether the HYP mode switch was finally successful. The bootm command part only adds and adjusts some error reporting. Signed-off-by: Andre Przywara <andre.przywara@linaro.org <mailto:andre.przywara@linaro.org>> --- arch/arm/cpu/armv7/nonsec_virt.S | 31++++++++++++++++++++++++++++---
arch/arm/include/asm/armv7.h | 7 +++++-- arch/arm/lib/bootm.c | 14 ++++++++++---- arch/arm/lib/virt-v7.c | 27 ++++++++++++++++++++++----- 4 files changed, 65 insertions(+), 14 deletions(-) diff --git a/arch/arm/cpu/armv7/nonsec_virt.S b/arch/arm/cpu/armv7/nonsec_virt.S index 919f6e9..950da6f 100644 --- a/arch/arm/cpu/armv7/nonsec_virt.S +++ b/arch/arm/cpu/armv7/nonsec_virt.S @@ -1,5 +1,5 @@ /* - * code for switching cores into non-secure state + * code for switching cores into non-secure state and into HYPmode
* * Copyright (c) 2013 Andre Przywara <andre.przywara@linaro.org <mailto:andre.przywara@linaro.org>> * @@ -26,14 +26,14 @@ #include <asm/gic.h> #include <asm/armv7.h> -/* the vector table for secure state */ +/* the vector table for secure state and HYP mode */ _secure_vectors: .word 0 /* reset */ .word 0 /* undef */ adr pc, _secure_monitor .word 0 .word 0 - .word 0 + adr pc, _hyp_trap .word 0 .word 0 .word 0 /* pad */ @@ -50,10 +50,23 @@ _secure_monitor: bic r1, r1, #0x4e @ clear IRQ, FIQ, EA, nET bits orr r1, r1, #0x31 @ enable NS, AW,FW
bits + mrc p15, 0, r0, c0, c1, 1 @ read ID_PFR1 + and r0, r0, #CPUID_ARM_VIRT_MASK @ mask virtualization bits + cmp r0, #(1 << CPUID_ARM_VIRT_SHIFT) + orreq r1, r1, #0x100 @ allow HVCinstruction
+ mcr p15, 0, r1, c1, c1, 0 @ write SCR (with NS bit set) + mrceq p15, 0, r0, c12, c0, 1 @ get MVBAR value + mcreq p15, 4, r0, c12, c0, 0 @ write HVBAR + movs pc, lr @ return to non-secure SVC +_hyp_trap: + .byte 0x00, 0xe3, 0x0e, 0xe1 @ mrs lr, elr_hyp + mov pc, lr @ do no switch modes, but + @ return to caller + /* * Secondary CPUs start here and call the code for the core specific parts * of the non-secure and HYP mode transition. The GIC distributor specific @@ -69,6 +82,7 @@ _smp_pen: mcr p15, 0, r1, c12, c0, 0 @ set VBAR bl _nonsec_init + bl _hyp_initIf I get it right, _nonsec_init stores the GICC address. Adding _hyp_init here overwrites r3. In effect the following lines do something on the stack (sp).
Eek. Good catch. Thanks for spotting. The fix will be included in the next round. Which kind of hints that acknowledging the wakeup IPI is not really necessary, as it was suspected earlier already.
ldr r1, [r3, #0x0c] @ read GICDacknowledge
str r1, [r3, #0x10] @ write GICD EOIcan you add these 0x0c and 0x10 constants to gic.h.
Sure. And I will fix the wrong comments on the way ;-)
Thanks for the review! Andre
@@ -145,3 +159,14 @@ _nonsec_init: str r1, [r2] @ allow private interrupts bx lr + +.globl _hyp_init +_hyp_init: + mov r2, lr + mov r3, sp @ save SVC copy of LR and SP + isb + .byte 0x70, 0x00, 0x40, 0xe1 @ hvc #0 + mov sp, r3 + mov lr, r2 @ fix HYP mode banked LR and SP + + bx lr diff --git a/arch/arm/include/asm/armv7.hb/arch/arm/include/asm/armv7.h
index 04545b9..8c3a85e 100644 --- a/arch/arm/include/asm/armv7.h +++ b/arch/arm/include/asm/armv7.h @@ -89,15 +89,18 @@ void v7_outer_cache_inval_range(u32 start, u32end);
#ifdef CONFIG_ARMV7_VIRT -#define HYP_ERR_NO_SEC_EXT 2 +#define HYP_ERR_ALREADY_HYP_MODE 1 +#define HYP_ERR_NO_VIRT_EXT 2 #define HYP_ERR_NO_GIC_ADDRESS 3 #define HYP_ERR_GIC_ADDRESS_ABOVE_4GB 4 +#define HYP_ERR_NOT_HYP_MODE 5 -int armv7_switch_nonsec(void); +int armv7_switch_hyp(void); /* defined in cpu/armv7/nonsec_virt.S */ void _nonsec_init(void); void _smp_pen(void); +void _hyp_init(void); #endif /* CONFIG_ARMV7_VIRT */ #endif /* ! __ASSEMBLY__ */ diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c index 8251a89..7edd84d 100644 --- a/arch/arm/lib/bootm.c +++ b/arch/arm/lib/bootm.c @@ -227,12 +227,15 @@ static void boot_prep_linux(bootm_headers_t *images) hang(); } #ifdef CONFIG_ARMV7_VIRT - switch (armv7_switch_nonsec()) { + switch (armv7_switch_hyp()) { case 0: - debug("entered non-secure state\n"); + debug("entered HYP mode\n"); break; - case HYP_ERR_NO_SEC_EXT: - printf("HYP mode: Security extensions not implemented.\n"); + case HYP_ERR_ALREADY_HYP_MODE: + debug("CPU already in HYP mode\n"); + break; + case HYP_ERR_NO_VIRT_EXT: + printf("HYP mode: Virtualization extensions not implemented.\n"); break; case HYP_ERR_NO_GIC_ADDRESS: printf("HYP mode: could not determine GICaddress.\n");
@@ -240,6 +243,9 @@ static void boot_prep_linux(bootm_headers_t*images)
case HYP_ERR_GIC_ADDRESS_ABOVE_4GB: printf("HYP mode: PERIPHBASE is above 4 GB, cannot access this.\n"); break; + case HYP_ERR_NOT_HYP_MODE: + printf("HYP mode: switch not successful.\n"); + break; } #endif } diff --git a/arch/arm/lib/virt-v7.c b/arch/arm/lib/virt-v7.c index 6946e4d..1e206b9 100644 --- a/arch/arm/lib/virt-v7.c +++ b/arch/arm/lib/virt-v7.c @@ -3,6 +3,7 @@ * Andre Przywara, Linaro * * Routines to transition ARMv7 processors from secure into non-secure state + * and from non-secure SVC into HYP mode * needed to enable ARMv7 virtualization for current hypervisors * * See file CREDITS for list of people who contributed to this @@ -29,6 +30,14 @@ #include <asm/gic.h> #include <asm/io.h> +static unsigned int read_cpsr(void) +{ + unsigned int reg; + + asm volatile ("mrs %0, cpsr\n" : "=r" (reg)); + return reg; +} + static unsigned int read_id_pfr1(void) { unsigned int reg; @@ -110,16 +119,20 @@ static void kick_secondary_cpus(char*gicdptr)
writel(1U << 24, &gicdptr[GICD_SGIR]); } -int armv7_switch_nonsec(void) +int armv7_switch_hyp(void) { unsigned int reg, ret; char *gicdptr; unsigned itlinesnr, i; - /* check whether the CPU supports the security extensions*/
+ /* check whether we are in HYP mode already */ + if ((read_cpsr() & 0x1f) == 0x1a) + return HYP_ERR_ALREADY_HYP_MODE; + + /* check whether the CPU supports the virtualization extensions */ reg = read_id_pfr1(); - if ((reg & 0xF0) == 0) - return HYP_ERR_NO_SEC_EXT; + if ((reg & CPUID_ARM_VIRT_MASK) != 1 <<CPUID_ARM_VIRT_SHIFT)
+ return HYP_ERR_NO_VIRT_EXT; set_generic_timer_frequency(); @@ -147,8 +160,12 @@ int armv7_switch_nonsec(void) kick_secondary_cpus(gicdptr); - /* call the non-sec switching code on this CPU also */ + /* call the HYP switching code on this CPU also */ _nonsec_init(); + _hyp_init(); + + if ((read_cpsr() & 0x1F) != 0x1a) + return HYP_ERR_NOT_HYP_MODE; return 0; } -- 1.7.12.1 _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu <mailto:kvmarm@lists.cs.columbia.edu> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarmregards, Nikolay Nikolaev
Message: 2 Date: Tue, 25 Jun 2013 10:44:38 +0200 From: Lukasz Majewski l.majewski@samsung.com Subject: Re: [U-Boot] dfu: using dfu-util -l shows different output To: Heiko Schocher hs@denx.de Cc: Marek Vasut marex@denx.de, "u-boot@lists.denx.de" u-boot@lists.denx.de, Kyungmin Park <kyungmin.park@samsung.com
,
Pantelis Antoniou <panto@antoniou-consulting.com>, "Egli,Samuel" samuel.egli@siemens.com Message-ID: 20130625104438.2538a880@amdc308.digital.local Content-Type: text/plain; charset=US-ASCII
Hi Heiko,
Hello Pantelis,
Am 25.06.2013 10:16, schrieb Pantelis Antoniou:
Heiko,
I don't think the gadget is initialized before you issue a dfu call.
So that makes sense.
?
I call from the host "dfu-util -l" so the gadget on the board should do the answer ... or?
The gadget is not initialized here (so the dfu-util -l shows no output).
After transfer it shows information about proper alt settings.
This is correct behaviour, but I had discussion about this with Tom and we agreed, that it would be nice to have "dfu-util -l" exporting from very beginning the alt setting information.
Frankly, I had too much other work to implement it.
However, I think, that it would be a very useful feature (e.g. to get alt settings layout at HOST to facilitate automated flashing).
Let's wait until Tom wakes up and have an authoritative answer.
Ok!
bye, Heiko
Regards
-- Pantelis
On Jun 25, 2013, at 11:08 AM, Heiko Schocher wrote:
Hello,
using "dfu-util -l" shows different output connecting to an am335x based board and using dfu_nand.c with current u-boot:
after resetting the board I get:
# dfu-util -l dfu-util 0.5
(C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc. (C) 2010-2011 Tormod Volden (DfuSe support) This program is Free Software and has ABSOLUTELY NO WARRANTY
dfu-util does currently only support DFU version 1.0
Found Runtime: [0525:bd00] devnum=0, cfg=2, intf=0, alt=0, name="Device Firmware Upgrade" #
after a dfu transfer I see:
# dfu-util -l dfu-util 0.5
(C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc. (C) 2010-2011 Tormod Volden (DfuSe support) This program is Free Software and has ABSOLUTELY NO WARRANTY
dfu-util does currently only support DFU version 1.0
Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=0, name="SPL" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=1, name="SPL.backup1" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=2, name="SPL.backup2" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=3, name="SPL.backup3" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=4, name="u-boot" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=5, name="kernel_a" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=6, name="kernel_b" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=7, name="rootfs" #
Which I expected ...
U-Boot environment variable:
U-Boot# print dfu_alt_info dfu_alt_info=SPL part 0 1;SPL.backup1 part 0 2;SPL.backup2 part 0 3;SPL.backup3 part 0 4;u-boot part 0 5;kernel_a part 0 7;kernel_b part 0 8;rootfs part 0 10 U-Boot#
Is this a bug or a feature?
bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
-- Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
Message: 3 Date: Tue, 25 Jun 2013 10:55:14 +0200 From: Heiko Schocher hs@denx.de Subject: Re: [U-Boot] dfu: using dfu-util -l shows different output To: Lukasz Majewski l.majewski@samsung.com Cc: Marek Vasut marex@denx.de, "u-boot@lists.denx.de" u-boot@lists.denx.de, Kyungmin Park <kyungmin.park@samsung.com
,
Pantelis Antoniou <panto@antoniou-consulting.com>, "Egli,Samuel" samuel.egli@siemens.com Message-ID: 51C95AF2.6030201@denx.de Content-Type: text/plain; charset=ISO-8859-1
Hello Lukasz,
Am 25.06.2013 10:44, schrieb Lukasz Majewski:
Hi Heiko,
Hello Pantelis,
Am 25.06.2013 10:16, schrieb Pantelis Antoniou:
Heiko,
I don't think the gadget is initialized before you issue a dfu call.
So that makes sense.
?
I call from the host "dfu-util -l" so the gadget on the board should do the answer ... or?
The gadget is not initialized here (so the dfu-util -l shows no output).
After transfer it shows information about proper alt settings.
This is correct behaviour, but I had discussion about this with Tom and we agreed, that it would be nice to have "dfu-util -l" exporting from very beginning the alt setting information.
Yes, I vote for this too. Connecting to a board, I first would do a "dfu-util -l" to look, what is possible to update here ...
Frankly, I had too much other work to implement it.
However, I think, that it would be a very useful feature (e.g. to get alt settings layout at HOST to facilitate automated flashing).
Hmm... I digged into the code, but not really found a place where I have to start. Can you give me a hint where to start? So maybe, I can do it?
Thanks!
bye, Heiko
Let's wait until Tom wakes up and have an authoritative answer.
Ok!
bye, Heiko
Regards
-- Pantelis
On Jun 25, 2013, at 11:08 AM, Heiko Schocher wrote:
> Hello, > > using "dfu-util -l" shows different output connecting to > an am335x based board and using dfu_nand.c with current > u-boot: > > after resetting the board I get: > > # dfu-util -l > dfu-util 0.5 > > (C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc. > (C) 2010-2011 Tormod Volden (DfuSe support) > This program is Free Software and has ABSOLUTELY NO WARRANTY > > dfu-util does currently only support DFU version 1.0 > > Found Runtime: [0525:bd00] devnum=0, cfg=2, intf=0, alt=0, > name="Device Firmware Upgrade" # > > after a dfu transfer I see: > > # dfu-util -l > dfu-util 0.5 > > (C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc. > (C) 2010-2011 Tormod Volden (DfuSe support) > This program is Free Software and has ABSOLUTELY NO WARRANTY > > dfu-util does currently only support DFU version 1.0 > > Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=0, name="SPL" > Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=1, > name="SPL.backup1" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, > alt=2, name="SPL.backup2" Found DFU: [0525:bd00] devnum=0, cfg=2, > intf=0, alt=3, name="SPL.backup3" Found DFU: [0525:bd00] devnum=0, > cfg=2, intf=0, alt=4, name="u-boot" Found DFU: [0525:bd00] > devnum=0, cfg=2, intf=0, alt=5, name="kernel_a" Found DFU: > [0525:bd00] devnum=0, cfg=2, intf=0, alt=6, name="kernel_b" Found > DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=7, name="rootfs" # > > Which I expected ... > > U-Boot environment variable: > > U-Boot# print dfu_alt_info > dfu_alt_info=SPL part 0 1;SPL.backup1 part 0 2;SPL.backup2 part 0 > 3;SPL.backup3 part 0 4;u-boot part 0 5;kernel_a part 0 7;kernel_b > part 0 8;rootfs part 0 10 U-Boot# > > Is this a bug or a feature? > > bye, > Heiko > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev > Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 > Groebenzell, Germany
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Message: 4 Date: Tue, 25 Jun 2013 11:42:53 +0200 From: Sascha Silbe t-uboot@infra-silbe.de Subject: Re: [U-Boot] [PATCH] OpenRD: relocate environment to 640kB To: Albert ARIBAUD albert.u.boot@aribaud.net Cc: Tom Rini trini@ti.com, u-boot@lists.denx.de Message-ID: toeppvail0i.fsf@twin.sascha.silbe.org Content-Type: text/plain; charset="us-ascii"
Hello Albert, hello Tom,
Albert ARIBAUD albert.u.boot@aribaud.net writes:
[Move environment to account for increase in U-Boot size]
This patch is for 2013.10, not 2013.07, but I prefer raising the issue as early as possible.
If there is no way to make things smoother, then I think the 2013.10 release notes should contain a red, blinking, paragraph about this. I would *hate* it if people were not warned and given a method to port their current environment setting over.
Possibly even, the 2013.07 could have a warning about the change to come, so that people have a better chance yet to prepare for the change.
The situation has gotten better recently and U-Boot fits into the previous partition size of 384KiB again. So it isn't broken on OpenRD anymore and the above would seem like a good approach.
Where are the U-Boot Release Notes located? Who is responsible for editing them?
Sascha
Dear krishna dwivedi,
please read the following articles. Please really, really do: http://catb.org/esr/faqs/smart-questions.html#bespecific http://www.netmeister.org/news/learn2quote.html
I asked you before NOT to hi-jack existing mail threads, to chose a descriptive Subject: and NOT to quote tons of unretated stuff, yet you do it again. Please STOP doing this!!
In message CAKAK--=53JrKgngqQdbPFMKdVxO7hd3=KaU8EZAejxE1fh_2xQ@mail.gmail.com you wrote:
I am trying to build U-boot:2013-04.But running into this error: mips64-nlm-elf-ld: arch/mips/cpu/mips64/start.o: relocation (null) against `board_init_f' can not be used when making a shared object; recompile with -fPIC arch/mips/cpu/mips64/start.o: could not read symbols: Bad value.
You fail to mention which board configuration you are trying to build.
Today's Topics:
- Re: [PATCH v2 6/7] ARM: extend non-secure switch to also go into HYP mode (Andre Przywara)
- Re: dfu: using dfu-util -l shows different output (Lukasz Majewski)
- Re: dfu: using dfu-util -l shows different output (Heiko Schocher)
- Re: [PATCH] OpenRD: relocate environment to 640kB (Sascha Silbe)
This is totally unrelated, do NOT quote such stuff!
Best regards,
Wolfgang Denk
2013/6/26 krishna dwivedi krishna.dwivedi01@gmail.com:
Hi All,
Hope everyone is doing great:)
I am trying to build U-boot:2013-04.But running into this error: mips64-nlm-elf-ld: arch/mips/cpu/mips64/start.o: relocation (null) against `board_init_f' can not be used when making a shared object; recompile with -fPIC arch/mips/cpu/mips64/start.o: could not read symbols: Bad value.
Initially,In file arch/mips/config.mk,I commented the flag: #LDFLAGS_FINAL += -pie This error resolved.But after relocation of u-boot code,we need this flag.So i need to uncomment this flag.and again i am running into this error agian.
Anyone faced this issue earlier.Anyone please provide pointers to resolve this.
try other toolchains!
Searching for mips64-nlm-elf reveals some mailing threads where other users complaining about linker errors. Also the gcc and binutils of that toolchain are rather old.
The reference toolchain for U-Boot is ELDK-5.3 [1] which has been extensively tested with PIE and automatic relocation.
[1] http://www.denx.de/wiki/ELDK-5
-- Best regards, Daniel
participants (3)
-
Daniel Schwierzeck -
krishna dwivedi -
Wolfgang Denk