Re: [U-Boot] is u-boot config arndale working?
On 2/10/14, Guillaume Gardet wrote: > Hi, > > > Le 10/02/2014 10:22, Mj Embd a écrit : >> Hi, >> >> Compiled Head and flashed u-boot.bin for arndale config. No display on >> terminal in uboot. >> Switched to linaro git (u-boot-linaro-stable.git) and u-boot log is >> showing up. >> >> Something wrong? >> > > You need to copy BL1 image, arndale-spl.bin and u-boot-dtb.bin to the right > offsets on your SD card. > BL1 at offset 1 SPL at offset 17 Uboot.bin at 49 The only difference is I used u-boot.bin. Should it make a difference? > Here, I have 2014.01 booting fine on arndale. > > > Guillaume > > -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] is u-boot config arndale working?
Hi, Compiled Head and flashed u-boot.bin for arndale config. No display on terminal in uboot. Switched to linaro git (u-boot-linaro-stable.git) and u-boot log is showing up. Something wrong? -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot execution sequence
a) step 1 - compile and build the bin / etf b) step 2 - create an asm - objdump -DS c) find the lds file d) locate uboot.map start from __start. (keep an arm manual handy) & begin. :) On 1/23/14, JYOTI DUBEY wrote: > Can anyone tell how to understand the flow of u-boot source code? I am > working on ARM processor and the board used is Nitrogen6X. > -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v10 1/6] core support of arm64
When "64-bit ARMv9" was announced ? On Thu, Sep 26, 2013 at 4:46 AM, Scott Wood wrote: > On Tue, 2013-09-17 at 16:37 +0800, FengHua wrote: > > > > > > > -原始邮件- > > > 发件人: "Scott Wood" > > > 发送时间: 2013年9月17日 星期二 > > > 收件人: feng...@phytium.com.cn > > > 抄送: u-boot@lists.denx.de, tr...@ti.com, albert.u.b...@aribaud.net, > w...@denx.de, b45...@freescale.com > > > 主题: Re: [PATCH v10 1/6] core support of arm64 > > > > > > On Mon, 2013-09-16 at 16:08 +0800, feng...@phytium.com.cn wrote: > > > > From: David Feng > > > > > > > > Signed-off-by: David Feng > > > > --- > > > > > > You've still got CONFIG_ARMV8 in places that should be CONFIG_ARM64 > > > > I am hesitate to use CONFIG_ARM64 instead of CONFIG _ARMV8. > > I am not sure whether all the CONFIG_ARMV8 could be replaced with > CONFIG_ARM64 > > or CONFIG_ARMV8 and CONFIG_ARMV64 are both needed. > > I will take this into account in the next. > > If it inherently relates to being 64-bit (including ABI issues), use > CONFIG_ARM64. If it's something that is new in ARMv8 but isn't > specifically due to 64-bitness (e.g. cache stuff, if it's different from > ARMv7), and could reasonably be different in a 64-bit ARMv9, then use > CONFIG_ARMV8. > > -Scott > > > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How do ARM platform initialize DDR?
Hi York, I was thinking about your problem and this could be a solution mpc85xx uses a family of ddr controllers. I believe they would be migrated to LayerScape, Freescale has also i.mx4/5/6 series and coming i.mx8, that series uses/might use another ddr controller Option1 As you suggested which looks a worthy option. ddr/fsl/contoller1/ --- for 85xx ddr/fsl/contoller2/ --- for I.mx in your board config file, you might want to use CONFIG_DDR_CONTROLLER_MPC85xx or CONFIG_DDR_CONTROLLER_IMX PS: I see no direct relation between ddr controller and core, also freescale is going core agnostic so I think the ddr controller be moved from cpu folder to driver/ddr folder. -Regards mj On Fri, Sep 20, 2013 at 3:19 AM, York Sun wrote: > On 09/19/2013 02:33 PM, Tom Rini wrote: > > On 09/19/2013 05:08 PM, York Sun wrote: > >> On 09/19/2013 01:57 PM, Tom Rini wrote: > >>> On Tue, Sep 17, 2013 at 08:59:24AM -0700, York Sun wrote: > >>> > Albert, > > Pardon me if this is a dumb question. I have been working on > powerpc platforms in the past. Now we (the developers I work > with) are exploring ARM cores. I am searching how memory is > initialized and found different solutions. Some platforms have > memory ready before u-boot even starts, some simply write to a > set of registers. I understand many platforms don't share the > IP of DDR controller. I am wondering if there is generic DDR > driver used by many ARM platforms, like the one we have for > powerpc/mpc85xx SoCs. > >>> > >>> Thinking back, as a rule of thumb, PowerPC has SPD I2C data > >>> available, usually. That's not the rule for ARM. One of a few > >>> choices happen: 1) ROM sets up DDR. 2) U-Boot/SPL sets up the DDR > >>> controller. > >>> > > > >> So for ARM platforms, the majority don't have the flexibility of > >> using different DIMMs and/or clocks? > > > > It's a different world. Again, thinking back to the PowerPC boards > > I've seen, they had "regular" DDR sockets. Most ARM boards don't. > > You can design your board with whatever, and I know in prototyping > > folks make do swapping chips in and out (and if you look at the omap > > code, you can see where we have code to calculate the timing values > > and print them, or use provided hard-coded values). > > Understood. We may have boards with DIMM slots. I do see value of a > fully functional DDR driver here. > > > > >>> The problem is that the DDR controller is usually > >>> vendor-specific. Perhaps the flip-side here is that there's not > >>> so much a generic DDR driver for mpc85xx but simply one vendor > >>> for mpc85xx. Taking arch/powerpc/cpu/mpc85xx/ddr-gen3.c as what > >>> you're talking about, > >>> arch/arm/cpu/armv7/omap-common/emif-common.c would be an > >>> ARM-world example (the 'EMIF' is found on a large variety of TI > >>> parts, not just "omap" ones). > > > >> Does it make sense to share the Freescale DDR driver across ARM > >> and Powerpc? Or does it make more sense to selectively copy the > >> mpc8xxx DDR driver to Freescale ARM subfolder to start with. If the > >> similarity sustains then we merge them into common driver. If not, > >> we maintain two separated drivers. > > > >> For those who is not familiar with, Freescale is extending products > >> to ARM cores. I am expecting peripherals stay relatively close, so > >> many driver can be reused. > > > > I've been wondering when this would start to be visible. If we are > > able to share the DDR controller code between mpc85xx and the ARM > > stuff you're talking about, we'll have to sort out someplace within > > drivers/ to place it, to avoid #include nightmares I suspect. Other > > drivers should be easier to share at least :) > > > > I did a quick and dirty hack yesterday to move DDR driver to > drivers/ddr/fsl. I had to change many #include . > > York > > > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/8] ARM: add secure monitor handler to switch to non-secure state
On Fri, Sep 20, 2013 at 6:12 AM, Christoffer Dall < christoffer.d...@linaro.org> wrote: > On Fri, Sep 20, 2013 at 03:20:15AM +0530, Mj Embd wrote: > > Just checking, is the mcr p15,0,r1,c1,c1,0 in sync with the following > text > > . I could be wrong here, just checking > > In the future, if you can comment specifically inline on the lines of > code you are targeting, it is easier for other people to address your > concerns. > > > > > B1.5.1 Arm Arch Ref Manual > > > >- > > > >To avoid security holes, software must not: > > - > > > > — Change from Secure to Non-secure state by using an MSR or CPS > > instruction > > to switch from Monitor > > The important part here is that we don't change from S to NS by > modifying the SCR, because monitor mode is always in secure mode, so the > change only happens on the exception return. > > So yes, it's safe. > > -Christoffer > Ok. Good Discussion. Thanks, PS: Gmail auto wraps the previous msg in 3 dots, so sometimes I miss inlining. Thanks for pointing out. > > > > > mode to some other mode while SCR.NS is 1. > >- > > > > — Use an MCR instruction that writes SCR.NS to change from Secure > to > > Non-secure state. This means ARM recommends that software does not > alter > > SCR.NS in any mode except Monitor mode. ARM deprecates changing > SCR.NS > > in any other mode. > > > > > > > > On Thu, Sep 19, 2013 at 9:36 PM, Andre Przywara > > wrote: > > > > > A prerequisite for using virtualization is to be in HYP mode, which > > > requires the CPU to be in non-secure state first. > > > Add a new file in arch/arm/cpu/armv7 to hold a monitor handler routine > > > which switches the CPU to non-secure state by setting the NS and > > > associated bits. > > > According to the ARM architecture reference manual this should not be > > > done in SVC mode, so we have to setup a SMC handler for this. > > > We create a new vector table to avoid interference with other boards. > > > The MVBAR register will be programmed later just before the smc call. > > > > > > Signed-off-by: Andre Przywara > > > --- > > > arch/arm/cpu/armv7/Makefile | 4 +++ > > > arch/arm/cpu/armv7/nonsec_virt.S | 54 > > > > > > 2 files changed, 58 insertions(+) > > > create mode 100644 arch/arm/cpu/armv7/nonsec_virt.S > > > > > > Changes: > > > v3..v4: clarify comments, w/s fixes > > > v4..v5: remove unneeded padding in the exception table > > > > > > diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile > > > index b723e22..3466c7a 100644 > > > --- a/arch/arm/cpu/armv7/Makefile > > > +++ b/arch/arm/cpu/armv7/Makefile > > > @@ -20,6 +20,10 @@ ifneq > > > > ($(CONFIG_AM43XX)$(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CON > > > SOBJS += lowlevel_init.o > > > endif > > > > > > +ifneq ($(CONFIG_ARMV7_NONSEC),) > > > +SOBJS += nonsec_virt.o > > > +endif > > > + > > > SRCS := $(START:.o=.S) $(COBJS:.o=.c) > > > OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) > > > START := $(addprefix $(obj),$(START)) > > > diff --git a/arch/arm/cpu/armv7/nonsec_virt.S > > > b/arch/arm/cpu/armv7/nonsec_virt.S > > > new file mode 100644 > > > index 000..c21bca3 > > > --- /dev/null > > > +++ b/arch/arm/cpu/armv7/nonsec_virt.S > > > @@ -0,0 +1,54 @@ > > > +/* > > > + * code for switching cores into non-secure state > > > + * > > > + * Copyright (c) 2013 Andre Przywara > > > + * > > > + * See file CREDITS for list of people who contributed to this > > > + * project. > > > + * > > > + * This program is free software; you can redistribute it and/or > > > + * modify it under the terms of the GNU General Public License as > > > + * published by the Free Software Foundation; either version 2 of > > > + * the License, or (at your option) any later version. > > > + * > > > + * This program is distributed in the hope that it will be useful, > > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See > the > > > + * GNU General Public License for more details. > > > + * > > > + * You should have receiv
Re: [U-Boot] [PATCH v5 3/8] ARM: add assembly routine to switch to non-secure state
On Fri, Sep 20, 2013 at 4:05 AM, Peter Maydell wrote: > On 20 September 2013 06:55, Mj Embd wrote: > > Hello Andre, > > I need a bit clarification here, if you read the next line after the line > > you have quoted. It clearly says that you can use a MCR to change from > > Secure to NS in Monitor Mode > > No, it's not saying that, because Monitor mode is always Secure: > this is exactly why an MCR to change SCR.NS is OK only in > Monitor mode -- it doesn't change from Secure to Non-Secure. > Only when you do an exception-return to leave Monitor mode > will you drop into the NonSecure world. > > > "Use an MCR instruction that writes SCR.NS to change from Secure to > > Non-secure state. This means ARM recommends that software does not alter > > SCR.NS in any mode except Monitor mode. ARM deprecates changing SCR.NS in > > any other mode." > > The text says "don't change from Secure to NonSecure by flipping > SCR.NS". It then lays out the corollary: the only time you then can > change SCR.NS is when it won't switch from Secure to NonSecure, > which is when you're in Monitor mode. > > [MJ] Ok got your point. Then what would be the steps to return from Monitor to Hyp mode? > -- PMM > -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/8] ARM: add assembly routine to switch to non-secure state
Hello Andre, I need a bit clarification here, if you read the next line after the line you have quoted. It clearly says that you can use a MCR to change from Secure to NS in Monitor Mode "Use an MCR instruction that writes SCR.NS to change from Secure to Non-secure state. This means ARM recommends that software does not alter SCR.NS in any mode except Monitor mode. ARM deprecates changing SCR.NS in any other mode." On Fri, Sep 20, 2013 at 3:09 AM, Mj Embd wrote: > > > > On Fri, Sep 20, 2013 at 3:01 AM, Andre Przywara > wrote: > >> On 09/19/2013 10:38 PM, Mj Embd wrote: >> >>> Hello Christoffer, >>> >>> I agree with both of you points. >>> >>> What I found different in 2 approaches is that in your approach >>> S->Monitor->NS->Hyp using svc and hvc >>> >>> While the other approach is setting the M bits directly in cpsr >>> >>> Xen uses the following >>> >>> cpsid aif, #0x16 /* Enter Monitor Mode*/ >>> >>> ... >>> mrs r0, cpsr /* Copy the CPSR */ >>> add r0, r0, #0x4 /* 0x16 (Monitor) -> 0x1a (Hyp) */ >>> msr spsr_cxsf, r0 /* into the SPSR */ >>> movs pc, r3 /* Exception-return into Hyp mode */ >>> >>> The second one is a bit simpler as it does not involve fault handlers. >>> >> >> The ARM ARM recommends _not_ to do this: >> Read more at the ARMv7-A Architecture Reference Manual, section B1.5.1: >> Security states/Changing from Secure to Non-secure state: >> >> "To avoid security holes, software must not: >> --Change from Secure to Non-secure state by using an MSR or CPS >> instruction to switch from Monitor mode to some other mode while SCR.NS is >> 1. >> ..." >> >> >> Good one, As per this statement from Secure Monitor to Hyp Mode, HVC > should be used. But Secure Supervisor to Secure Monitor does not set NS=1 > so first part cpsid aif, #0x16 is valid ? > Or there is some other statement in the manual which I am not aware of ? > >> >>> I was just suggesting that the best approach to be used ... >>> >> >> Looks like this is what we do ;-) >> >> Regards, >> Andre. >> >> >> >>> On 9/20/13, Christoffer Dall wrote: >>> >>>> On Fri, Sep 20, 2013 at 01:27:48AM +0530, Mj Embd wrote: >>>> >>>>> two quick points >>>>> (a) xen already has a mode_switch code, so AFAIK xen might not use it >>>>> (as suggested by comment in another patch in this patch set) >>>>> >>>> >>>> For KVM the boot procedure for Hyp mode is quite clearly defined: the >>>> kernel must be booted in Hyp mode. >>>> >>>> I was under the impression that Xen wanted to use the same paradigm and >>>> rely on bootloaders to switch to Hyp mode and thereby get rid of the >>>> code in Xen. >>>> >>>> (b) There are 2 methods of switching from Secure to Hyp mode >>>>> one you have proposed another implemented in xen. I was suggesting >>>>> take the best approach >>>>> >>>>> >>>> Can you please be more specific? Not everyone here knows the Xen >>>> low-level mode switch details by heart. As far as I know, there is only >>>> one architecturally defined proper mode to switch from secure mode to >>>> non-secure mode, and the state that needs to be configured for Hyp-mode >>>> and NS-mode is well defined. Obviously two implementation can do things >>>> differently (different order, different programminge environment, etc.) >>>> but that doesn't mean one is better than the other. >>>> >>>> I think it would be more productive if you can simply look at this code >>>> and if you think some things are done more efficiently in Xen, please >>>> comment on that, which would be very helpful. I'm afraid there's no >>>> magic way to apply a block of Xen code into U-Boot wihtout manual >>>> adjustment anyway, or the other way around for that matter. >>>> >>>> -Christoffer >>>> >>>> >>> >>> >> > > > -- > -mj > -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/8] ARM: add secure monitor handler to switch to non-secure state
Just checking, is the mcr p15,0,r1,c1,c1,0 in sync with the following text . I could be wrong here, just checking B1.5.1 Arm Arch Ref Manual - To avoid security holes, software must not: - — Change from Secure to Non-secure state by using an MSR or CPS instruction to switch from Monitor mode to some other mode while SCR.NS is 1. - — Use an MCR instruction that writes SCR.NS to change from Secure to Non-secure state. This means ARM recommends that software does not alter SCR.NS in any mode except Monitor mode. ARM deprecates changing SCR.NS in any other mode. On Thu, Sep 19, 2013 at 9:36 PM, Andre Przywara wrote: > A prerequisite for using virtualization is to be in HYP mode, which > requires the CPU to be in non-secure state first. > Add a new file in arch/arm/cpu/armv7 to hold a monitor handler routine > which switches the CPU to non-secure state by setting the NS and > associated bits. > According to the ARM architecture reference manual this should not be > done in SVC mode, so we have to setup a SMC handler for this. > We create a new vector table to avoid interference with other boards. > The MVBAR register will be programmed later just before the smc call. > > Signed-off-by: Andre Przywara > --- > arch/arm/cpu/armv7/Makefile | 4 +++ > arch/arm/cpu/armv7/nonsec_virt.S | 54 > > 2 files changed, 58 insertions(+) > create mode 100644 arch/arm/cpu/armv7/nonsec_virt.S > > Changes: > v3..v4: clarify comments, w/s fixes > v4..v5: remove unneeded padding in the exception table > > diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile > index b723e22..3466c7a 100644 > --- a/arch/arm/cpu/armv7/Makefile > +++ b/arch/arm/cpu/armv7/Makefile > @@ -20,6 +20,10 @@ ifneq > ($(CONFIG_AM43XX)$(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CON > SOBJS += lowlevel_init.o > endif > > +ifneq ($(CONFIG_ARMV7_NONSEC),) > +SOBJS += nonsec_virt.o > +endif > + > SRCS := $(START:.o=.S) $(COBJS:.o=.c) > OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) > START := $(addprefix $(obj),$(START)) > diff --git a/arch/arm/cpu/armv7/nonsec_virt.S > b/arch/arm/cpu/armv7/nonsec_virt.S > new file mode 100644 > index 000..c21bca3 > --- /dev/null > +++ b/arch/arm/cpu/armv7/nonsec_virt.S > @@ -0,0 +1,54 @@ > +/* > + * code for switching cores into non-secure state > + * > + * Copyright (c) 2013 Andre Przywara > + * > + * See file CREDITS for list of people who contributed to this > + * project. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation; either version 2 of > + * the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, > + * MA 02111-1307 USA > + */ > + > +#include > + > +/* the vector table for secure state */ > +_monitor_vectors: > + .word 0 /* reset */ > + .word 0 /* undef */ > + adr pc, _secure_monitor > + .word 0 > + .word 0 > + .word 0 > + .word 0 > + .word 0 > + > +/* > + * secure monitor handler > + * U-boot calls this "software interrupt" in start.S > + * This is executed on a "smc" instruction, we use a "smc #0" to switch > + * to non-secure state. > + * We use only r0 and r1 here, due to constraints in the caller. > + */ > + .align 5 > +_secure_monitor: > + mrc p15, 0, r1, c1, c1, 0 @ read SCR > + bic r1, r1, #0x4e @ clear IRQ, FIQ, EA, nET > bits > + orr r1, r1, #0x31 @ enable NS, AW, FW bits > + > + mcr p15, 0, r1, c1, c1, 0 @ write SCR (with NS bit > set) > + > + movspc, lr @ return to non-secure SVC > + > -- > 1.7.12.1 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/8] ARM: add assembly routine to switch to non-secure state
On Fri, Sep 20, 2013 at 3:01 AM, Andre Przywara wrote: > On 09/19/2013 10:38 PM, Mj Embd wrote: > >> Hello Christoffer, >> >> I agree with both of you points. >> >> What I found different in 2 approaches is that in your approach >> S->Monitor->NS->Hyp using svc and hvc >> >> While the other approach is setting the M bits directly in cpsr >> >> Xen uses the following >> >> cpsid aif, #0x16 /* Enter Monitor Mode*/ >> >> ... >> mrs r0, cpsr /* Copy the CPSR */ >> add r0, r0, #0x4 /* 0x16 (Monitor) -> 0x1a (Hyp) */ >> msr spsr_cxsf, r0 /* into the SPSR */ >> movs pc, r3 /* Exception-return into Hyp mode */ >> >> The second one is a bit simpler as it does not involve fault handlers. >> > > The ARM ARM recommends _not_ to do this: > Read more at the ARMv7-A Architecture Reference Manual, section B1.5.1: > Security states/Changing from Secure to Non-secure state: > > "To avoid security holes, software must not: > --Change from Secure to Non-secure state by using an MSR or CPS > instruction to switch from Monitor mode to some other mode while SCR.NS is > 1. > ..." > > > Good one, As per this statement from Secure Monitor to Hyp Mode, HVC should be used. But Secure Supervisor to Secure Monitor does not set NS=1 so first part cpsid aif, #0x16 is valid ? Or there is some other statement in the manual which I am not aware of ? > >> I was just suggesting that the best approach to be used ... >> > > Looks like this is what we do ;-) > > Regards, > Andre. > > > >> On 9/20/13, Christoffer Dall wrote: >> >>> On Fri, Sep 20, 2013 at 01:27:48AM +0530, Mj Embd wrote: >>> >>>> two quick points >>>> (a) xen already has a mode_switch code, so AFAIK xen might not use it >>>> (as suggested by comment in another patch in this patch set) >>>> >>> >>> For KVM the boot procedure for Hyp mode is quite clearly defined: the >>> kernel must be booted in Hyp mode. >>> >>> I was under the impression that Xen wanted to use the same paradigm and >>> rely on bootloaders to switch to Hyp mode and thereby get rid of the >>> code in Xen. >>> >>> (b) There are 2 methods of switching from Secure to Hyp mode >>>> one you have proposed another implemented in xen. I was suggesting >>>> take the best approach >>>> >>>> >>> Can you please be more specific? Not everyone here knows the Xen >>> low-level mode switch details by heart. As far as I know, there is only >>> one architecturally defined proper mode to switch from secure mode to >>> non-secure mode, and the state that needs to be configured for Hyp-mode >>> and NS-mode is well defined. Obviously two implementation can do things >>> differently (different order, different programminge environment, etc.) >>> but that doesn't mean one is better than the other. >>> >>> I think it would be more productive if you can simply look at this code >>> and if you think some things are done more efficiently in Xen, please >>> comment on that, which would be very helpful. I'm afraid there's no >>> magic way to apply a block of Xen code into U-Boot wihtout manual >>> adjustment anyway, or the other way around for that matter. >>> >>> -Christoffer >>> >>> >> >> > -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/8] ARM: add assembly routine to switch to non-secure state
Hello Christoffer, I agree with both of you points. What I found different in 2 approaches is that in your approach S->Monitor->NS->Hyp using svc and hvc While the other approach is setting the M bits directly in cpsr Xen uses the following cpsid aif, #0x16 /* Enter Monitor Mode*/ ... mrs r0, cpsr /* Copy the CPSR */ add r0, r0, #0x4 /* 0x16 (Monitor) -> 0x1a (Hyp) */ msr spsr_cxsf, r0 /* into the SPSR */ movs pc, r3 /* Exception-return into Hyp mode */ The second one is a bit simpler as it does not involve fault handlers. I was just suggesting that the best approach to be used ... Best Regards, mj On 9/20/13, Christoffer Dall wrote: > On Fri, Sep 20, 2013 at 01:27:48AM +0530, Mj Embd wrote: >> two quick points >> (a) xen already has a mode_switch code, so AFAIK xen might not use it >> (as suggested by comment in another patch in this patch set) > > For KVM the boot procedure for Hyp mode is quite clearly defined: the > kernel must be booted in Hyp mode. > > I was under the impression that Xen wanted to use the same paradigm and > rely on bootloaders to switch to Hyp mode and thereby get rid of the > code in Xen. > >> (b) There are 2 methods of switching from Secure to Hyp mode >> one you have proposed another implemented in xen. I was suggesting >> take the best approach >> > > Can you please be more specific? Not everyone here knows the Xen > low-level mode switch details by heart. As far as I know, there is only > one architecturally defined proper mode to switch from secure mode to > non-secure mode, and the state that needs to be configured for Hyp-mode > and NS-mode is well defined. Obviously two implementation can do things > differently (different order, different programminge environment, etc.) > but that doesn't mean one is better than the other. > > I think it would be more productive if you can simply look at this code > and if you think some things are done more efficiently in Xen, please > comment on that, which would be very helpful. I'm afraid there's no > magic way to apply a block of Xen code into U-Boot wihtout manual > adjustment anyway, or the other way around for that matter. > > -Christoffer > -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/8] ARM: add assembly routine to switch to non-secure state
two quick points (a) xen already has a mode_switch code, so AFAIK xen might not use it (as suggested by comment in another patch in this patch set) (b) There are 2 methods of switching from Secure to Hyp mode one you have proposed another implemented in xen. I was suggesting take the best approach On 9/20/13, Christoffer Dall wrote: > On Thu, Sep 19, 2013 at 10:00:03PM +0530, Mj Embd wrote: >> Hi Andre, >> >> There is another approach taken in xen. (xen/arch/arm/mode_switch.S) >> Which do you think is the better approach >> > Hi there, > > I'm not sure I completely understand your question. Do you think this > patch series should be changed to take something from Xen? If so, can > you please clarify why? > > For the record, this patch series has been reviewed and tested quite a > lot for U-Boot and we would very much like to get this merged and avoid > further churn, unless there's a compelling technical reason to change > it. > > Thanks, > -Christoffer > -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/8] ARM: add assembly routine to switch to non-secure state
Hi Andre, There is another approach taken in xen. (xen/arch/arm/mode_switch.S) Which do you think is the better approach Regards -mj On 9/19/13, Andre Przywara wrote: > While actually switching to non-secure state is one thing, another > part of this process is to make sure that we still have full access > to the interrupt controller (GIC). > The GIC is fully aware of secure vs. non-secure state, some > registers are banked, others may be configured to be accessible from > secure state only. > To be as generic as possible, we get the GIC memory mapped address > based on the PERIPHBASE value in the CBAR register. Since this > register is not architecturally defined, we check the MIDR before to > be from an A15 or A7. > For CPUs not having the CBAR or boards with wrong information herein > we allow providing the base address as a configuration variable. > > Now that we know the GIC address, we: > a) allow private interrupts to be delivered to the core >(GICD_IGROUPR0 = 0x) > b) enable the CPU interface (GICC_CTLR[0] = 1) > c) set the priority filter to allow non-secure interrupts >(GICC_PMR = 0xFF) > > Also we allow access to all coprocessor interfaces from non-secure > state by writing the appropriate bits in the NSACR register. > > The generic timer base frequency register is only accessible from > secure state, so we have to program it now. Actually this should be > done from primary firmware before, but some boards seems to omit > this, so if needed we do this here with a board specific value. > The Versatile Express board does not need this, so we remove the > frequency from the configuration file here. > > After having switched to non-secure state, we also enable the > non-secure GIC CPU interface, since this register is banked. > > Since we need to call this routine also directly from the smp_pen > later (where we don't have any stack), we can only use caller saved > registers r0-r3 and r12 to not mess with the compiler. > > Signed-off-by: Andre Przywara > --- > arch/arm/cpu/armv7/nonsec_virt.S| 86 > + > arch/arm/include/asm/armv7.h| 21 + > arch/arm/include/asm/gic.h | 17 > include/configs/vexpress_ca15_tc2.h | 2 - > 4 files changed, 124 insertions(+), 2 deletions(-) > create mode 100644 arch/arm/include/asm/gic.h > > Changes: > v3..v4: clear reserved bits in CBAR > v4..v5: none > > diff --git a/arch/arm/cpu/armv7/nonsec_virt.S > b/arch/arm/cpu/armv7/nonsec_virt.S > index c21bca3..3dd60b7 100644 > --- a/arch/arm/cpu/armv7/nonsec_virt.S > +++ b/arch/arm/cpu/armv7/nonsec_virt.S > @@ -23,6 +23,11 @@ > */ > > #include > +#include > +#include > +#include > + > +.arch_extension sec > > /* the vector table for secure state */ > _monitor_vectors: > @@ -52,3 +57,84 @@ _secure_monitor: > > movspc, lr @ return to non-secure SVC > > +/* > + * Switch a core to non-secure state. > + * > + * 1. initialize the GIC per-core interface > + * 2. allow coprocessor access in non-secure modes > + * 3. switch the cpu mode (by calling "smc #0") > + * > + * Called from smp_pen by secondary cores and directly by the BSP. > + * Do not assume that the stack is available and only use registers > + * r0-r3 and r12. > + * > + * PERIPHBASE is used to get the GIC address. This could be 40 bits long, > + * though, but we check this in C before calling this function. > + */ > +ENTRY(_nonsec_init) > +#ifdef CONFIG_ARM_GIC_BASE_ADDRESS > + ldr r2, =CONFIG_ARM_GIC_BASE_ADDRESS > +#else > + mrc p15, 4, r2, c15, c0, 0 @ read CBAR > + bfc r2, #0, #15 @ clear reserved bits > +#endif > + add r3, r2, #GIC_DIST_OFFSET@ GIC dist i/f offset > + mvn r1, #0 @ all bits to 1 > + str r1, [r3, #GICD_IGROUPRn]@ allow private interrupts > + > + mrc p15, 0, r0, c0, c0, 0 @ read MIDR > + ldr r1, =MIDR_PRIMARY_PART_MASK > + and r0, r0, r1 @ mask out variant and revision > + > + ldr r1, =MIDR_CORTEX_A7_R0P0 & MIDR_PRIMARY_PART_MASK > + cmp r0, r1 @ check for Cortex-A7 > + > + ldr r1, =MIDR_CORTEX_A15_R0P0 & MIDR_PRIMARY_PART_MASK > + cmpne r0, r1 @ check for Cortex-A15 > + > + movne r1, #GIC_CPU_OFFSET_A9 @ GIC CPU offset for A9 > + moveq r1, #GIC_CPU_OFFSET_A15 @ GIC CPU offset for A15/A7 > + add r3, r2, r1 @ r3 = GIC CPU i/f addr > + > + mov r1, #1 @ set GICC_CTLR[enable] > + str r1, [r3, #GICC_CTLR]@ and clear all other bits > + mov r1, #0xff > + str r1, [r3, #GICC_PMR] @ set priority mask register > + > + movwr1, #0x3fff > + movtr1, #0x0006 > + mcr p15, 0, r1, c1, c1, 2 @ NSACR = all copros t
Re: [U-Boot] [PATCH 01/12 V3] EXYNOS5: Create a common board file
Hi @Samsung, Great that you have starting posting 5420 patches, one basic question (a) What is the booting procedure for the secondary cores (b) What is the booting procedure for the Little Secondary cores... Would you be pushing the patches for these as well On 9/19/13, Simon Glass wrote: > Hi Rajeshwari, > > On Wed, Sep 11, 2013 at 4:01 AM, Rajeshwari S Shinde < > rajeshwar...@samsung.com> wrote: > >> Create a common board.c file for all functions which are common across >> all EXYNOS5 platforms. >> >> exynos_init function is provided for platform cpecific code. >> > > specific > > >> >> Signed-off-by: Rajeshwari S Shinde >> > > Acked-by: Simon Glass > > >> --- >> Changes in V2: >> - None >> Changes in V3: >> - None >> arch/arm/include/asm/arch-exynos/board.h | 17 ++ >> board/samsung/common/Makefile| 4 + >> board/samsung/common/board.c | 312 >> +++ >> board/samsung/smdk5250/exynos5-dt.c | 269 >> +- >> board/samsung/smdk5250/smdk5250.c| 182 +- >> include/configs/exynos5250-dt.h | 2 + >> 6 files changed, 342 insertions(+), 444 deletions(-) >> create mode 100644 arch/arm/include/asm/arch-exynos/board.h >> create mode 100644 board/samsung/common/board.c >> >> > -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Exynos 5250 Query] Smp Boot
Thanks for replying Simon. Comments inline On 9/18/13, Simon Glass wrote: > Hi MJ, > > On Wed, Sep 18, 2013 at 12:41 AM, MJ embd wrote: >> Hi Simon/All, >> >> Any comments >> >> On 9/17/13, Simon Glass wrote: >>> Hi, >>> >>> You could try to cc whoever wrote the code. You can use git blame to >>> find >>> out. >>> >>> But it sounds like you are on the right track. I may be able to help, >>> will >>> email tomorrow if so. >>> >>> Regards, >>> Simon >>> On Sep 16, 2013 8:26 PM, "MJ embd" wrote: >>> >>>> Reminder, Please can anyone respond >>>> >>>> On 9/16/13, MJ embd wrote: >>>> > Hi, >>>> > >>>> > I was trying to understand the booting (till linux) on samsung exynos >>>> > 5250. As this is my first on ARM Cortex. I have a few questions, so >>>> > following is a step by step understanding and [Q] mentions the >>>> > question I am asking >>>> > >>>> > [1] At POR (Power on Reset) the Internal Boot rom code executes, and >>>> > checks the boot location and if it finds sd card, it copies 14k from >>>> > the sd card (which is u-boot-spl.bin) into iRAM. >>>> > [2] the internal boot rom branches pc to the entry point of spl at >>>> > __start (0x2023400) >>>> > [3] First instruction at __start is b reset. >>>> > [4] this takes the route reset | cpu_init_crit | low_level_init | >>>> first_cpu >>>> > >>>> > [Q 1] At this point what is the state of secondary core, is it held >>>> > in >>>> reset >>>> > ? >>>> > As per document, "" > > I think the secondary core is powered down or in reset. > >>>> > "the secondary CPUs (CPU1, CPU2, and CPU3) execute a WFI instruction, >>>> > which is actually a loop that checks the value of SYS_FLAGS >>>> > register." > > Which document are you referring to here? > [MJ] http://www.google.co.in/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CC0QFjAA&url=http%3A%2F%2Fwww.linux-arm.org%2Fpub%2FLinuxPlatform%2FRealViewLink%2FBooting_ARM_Linux_SMP_on_MPCore.doc&ei=62c6Uv6XK4eFrAe1goHQDA&usg=AFQjCNG3zOT9-LZ52Ps1oKOKAME7OJveeg&sig2=DfPKT7G0eWT_8Tcbwjj2pw >>>> > >>>> > I couldnt find the SYS_FLAGS register in Cortex A15 manual, can some >>>> > one >>>> > point. > > This is probably a flag in the IRAM, rather than an A15 register. > >>>> > >>>> > [Q 2] The secondary core until the point the boot core calls >>>> > smp_kick_secondary is just waiting in WFI. > > I don't see smp_kick_secondary() in U-Boot. Where is that? > [MJ] I am referring to the patch https://git.linaro.org/gitweb?p=people/ronynandy/u-boot-arndale.git;a=commit;h=affeaad51746944e8c356091b12ff9c9c6183c4a >>>> > [5] the smp_kick_secondary does the following >>>> > (a) at the address SYSFLAGS_ADDR (0x202) which is not in spl but >>>> > above it, it write the b reset instruction and >>>> > (b) Issues a SGI to the secondary core >>>> > >>>> > [Q 3] Does this mean that secondary core is listening at address >>>> > 0x202, I couldnt find that in any document? > > That's your answer on SYS_FLAGS I guess. > > That is the start of IRAM so it is quite likely that the secondary > core is sitting in a loop waiting for the value to change. > >>>> > >>>> > [6] Supposedly it does and it starts executing the reset function, >>>> > secondary core would end up in enter_smp_pen. >>>> > [Q 4] I dont understand what is trying to achieve here, Can some one >>>> > explain. >>>> > >>>> > >>>> > I am planning to pen down the complete boot sequence, all help >>>> appreciated. > > I'm missing the code you are referring to perhaps, but I think the > idea is something like this: > > 1. Boot primary core > 2. Primary code sets up a 'pen' for the secondary cores in IRAM, > starts them up to run in that pen > 3. Secondary cores watch a value in IRAM which tells them when to > leave their pen and where to jump to > [MJ] what is actually a SMP "pen" [Q5] There is one more doubt on the .word irq handler in uboot spl. As per the code here "https://git.linaro.org/gitweb?p=people/ronynandy/u-boot-arndale.git;a=blob;f=arch/arm/cpu/armv7/start.S;h=7df97c5a3a663a88c01e68ffcfb7b91e4bbcc6b8;hb=affeaad51746944e8c356091b12ff9c9c6183c4a"; If my secondary core gets an interrupt in WFE state or before that It would IMO would get multiple prefetch aborts. This thing is adding to my confusion (in the absence of any document, which i am not able to find as of now) > Regards, > Simon > -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Understanding uboot child makefiles
Thanks, after a long google I figured it out. Will write a post about it on my blog. On 9/19/13, Simon Glass wrote: > Hi MJ, > > On Mon, Sep 16, 2013 at 8:23 PM, MJ embd wrote: > >> PS: Last message was sent without body, please ignore >> >> 0 down vote favorite >> >> >> I am trying to understand a second level makefile of uboot (this >> makefile was in a sub directory) >> >> a) What is the difference between $(COBJS:.o=.c) and COBJS := >> test_main.o >> > > $(COBJS:.o=.c) means to evaluate $(COBJS) but replace every .o with .c > > COBJS := test_main.omeans that COBJS is assigned the value > test_main.o > > > >> b) What is the meaning of $(call cmd_link_o_target, $(OBJS)). What is >> the cmd_link_o_target and what is the call statement doing >> > > This is linking the object files together with a partial link (ld -r). See > config.mk for the definition. > > >> c) Does this line creating 2 targets ? >> >> ALL := $(obj).depend $(LIB) >> > > It defines variable ALL to be those two things (the depend file and the > library). So that > > all:$(ALL) > > means that we need to build the depend file and the library. > > >> ===Makefile=== >> >> include $(TOPDIR)/config.mk >> >> LIB = $(obj)libtest.o >> >> SOBJS := test.o >> >> COBJS := test_main.o >> COBJS += diagnostic.o >> >> >> SRCS:= $(SOBJS:.o=.S) $(COBJS:.o=.c) >> OBJS:= $(addprefix $(obj),$(COBJS) $(SOBJS)) >> >> ALL := $(obj).depend $(LIB) >> >> all:$(ALL) >> >> $(LIB): $(OBJS) >> $(call cmd_link_o_target, $(OBJS)) >> >> # >> >> # defines $(obj).depend target >> include $(SRCTREE)/rules.mk >> >> sinclude $(obj).depend >> >> # >> >> > This might help a bit: > > http://www.gnu.org/software/make/manual/make.html > > Regards, > Simon > -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Exynos 5250 Query] Smp Boot
Hi Simon/All, Any comments On 9/17/13, Simon Glass wrote: > Hi, > > You could try to cc whoever wrote the code. You can use git blame to find > out. > > But it sounds like you are on the right track. I may be able to help, will > email tomorrow if so. > > Regards, > Simon > On Sep 16, 2013 8:26 PM, "MJ embd" wrote: > >> Reminder, Please can anyone respond >> >> On 9/16/13, MJ embd wrote: >> > Hi, >> > >> > I was trying to understand the booting (till linux) on samsung exynos >> > 5250. As this is my first on ARM Cortex. I have a few questions, so >> > following is a step by step understanding and [Q] mentions the >> > question I am asking >> > >> > [1] At POR (Power on Reset) the Internal Boot rom code executes, and >> > checks the boot location and if it finds sd card, it copies 14k from >> > the sd card (which is u-boot-spl.bin) into iRAM. >> > [2] the internal boot rom branches pc to the entry point of spl at >> > __start (0x2023400) >> > [3] First instruction at __start is b reset. >> > [4] this takes the route reset | cpu_init_crit | low_level_init | >> first_cpu >> > >> > [Q 1] At this point what is the state of secondary core, is it held in >> reset >> > ? >> > As per document, "" >> > "the secondary CPUs (CPU1, CPU2, and CPU3) execute a WFI instruction, >> > which is actually a loop that checks the value of SYS_FLAGS register." >> > >> > I couldnt find the SYS_FLAGS register in Cortex A15 manual, can some >> > one >> > point. >> > >> > [Q 2] The secondary core until the point the boot core calls >> > smp_kick_secondary is just waiting in WFI. >> > [5] the smp_kick_secondary does the following >> > (a) at the address SYSFLAGS_ADDR (0x202) which is not in spl but >> > above it, it write the b reset instruction and >> > (b) Issues a SGI to the secondary core >> > >> > [Q 3] Does this mean that secondary core is listening at address >> > 0x202, I couldnt find that in any document? >> > >> > [6] Supposedly it does and it starts executing the reset function, >> > secondary core would end up in enter_smp_pen. >> > [Q 4] I dont understand what is trying to achieve here, Can some one >> > explain. >> > >> > >> > I am planning to pen down the complete boot sequence, all help >> appreciated. >> > >> > Thanks in advance. >> > mj >> > >> >> >> -- >> -mj >> ___ >> U-Boot mailing list >> U-Boot@lists.denx.de >> http://lists.denx.de/mailman/listinfo/u-boot >> > -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 0/5] powerpc: Add support 2 stage boot loader for corenet platform
Trivial Question, Which part of the SPL code uses HEAP? On 9/16/13, Prabhakar Kushwaha wrote: > > Signed-off-by: Prabhakar Kushwaha > --- > > Add support of 2 stage NAND boot loader in cornet platforms using SPL > framework. > This will be helpful for those SoC which has less internal SRAM(128K). > > here, PBL initialise the internal SRAM and copy SPL(96K) in SRAM. > SPL further initialise DDR using SPD and environment variables and copy > u-boot(512 KB) from NAND flash to DDR. > Finally SPL transer control to u-boot for futher booting. > > SPL has following features: > - Executes within 128K > - SPL size 96K > - No relocation required > > Run time view of SPL framework > == > --- > Area| Address | > --- > GD, BD | 0xFFFE (1K) | > --- > HEAP| 0xFFFE0400 (26K) grow downwards | > --- > STACK | 0xFFFE8000 (5K) grow upwards | > --- > U-boot SPL | 0xfffe8000 – 0xfffc (96K) | > --- > > 96K + 5K + 26K + 1K = 128K > --- > This patch set contains:- > > [RFC 1/5] powerpc:Add support of SPL non-relocation > > [RFC 2/5] powerpc/SPL:Allow Parsing of LAW table in both SPL & non SPL > > [RFC 3/5] common/env: Point default envirenoment for GD > > [RFC 4/5] SPL:Defines function required to env read for IFC & env_nand > > [RFC 5/5] B4860QDS: Add support of 2 stage NAND boot loader > -- > 1.7.9.5 > > > -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] HACK: enable HYP mode on OMAP5
Few quick comments
1) wouldnt it be better to create a .S file and move big chunk of
inline assembly there
2) can the multiple occurences of .word be substituted with something else?
On 9/17/13, Alexander Tarasikov wrote:
> ---
> arch/arm/lib/bootm.c | 89
> ++--
> 1 file changed, 87 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
> index eefb456..63395c3 100644
> --- a/arch/arm/lib/bootm.c
> +++ b/arch/arm/lib/bootm.c
> @@ -8,6 +8,9 @@
> * Marius Groeger
> *
> * Copyright (C) 2001 Erik Mouw (j.a.k.m...@its.tudelft.nl)
> + * HYP entry (C) 2012 Ian Molton
> + *and Clemens Fischer
> + * (C) 2013 Alexander Tarasikov
> *
> * SPDX-License-Identifier: GPL-2.0+
> */
> @@ -26,6 +29,89 @@ DECLARE_GLOBAL_DATA_PTR;
>
> static struct tag *params;
>
> +/*
> + * function called by cpu 1 after wakeup
> + */
> +extern void __hyp_init_sec(void);
> +
> +asm (
> + ".pushsection .text\n"
> + ".global __hyp_init_sec\n"
> + "__hyp_init_sec:\n"
> + "ldr r12, =0x102\n"
> + "adr r0, hyp_init_cont\n"
> + "dsb\n"
> + "isb\n"
> + "dmb\n"
> + "smc #0\n"
> + "hyp_init_cont: ldr r1, =0x48281800\n" // AUX_CORE_BOOT_0
> + "mov r2, #0\n"
> + "str r2, [r1, #4]\n"
> + "dsb\n"
> + "isb\n"
> + "dmb\n"
> + "wait: wfe\n"
> + "ldr r2, [r1, #4]\n"
> + "cmp r2, #0\n"
> + "movne pc, r2\n"
> + "b wait\n"
> + ".popsection\n"
> +);
> +
> +/*
> + * Enable HYP mode on the OMAP5 CPU
> + *
> + * FIXME: this needs to test to make sure its running on an OMAP5
> + *
> + * We wake up CPU1 at __hyp_init_sec which allows us to put it into HYP
> + * mode.
> + *
> + * CPU1 then clears AUX_CORE_BOOT_0 and enters WFE, until the kernel wakes
> it.
> + *
> + * In order to avoid CPU1 continuing execution on just about any event, we
> + * wait for AUX_CORE_BOOT_0 to contain a non-zero address, at which point
> + * we continue execution at that address.
> + *
> + */
> +
> +static void hyp_enable(void) {
> + /*Wake up CPU1 and enable HYP on CPU0. */
> + asm(
> + "ldr r1, =0x48281800\n" // AUX_CORE_BOOT_1
> + "ldr r2, =__hyp_init_sec\n"
> + "str r2, [r1, #4]\n"
> + "mov r2, #0x20\n"
> + "str r2, [r1]\n"// AUX_CORE_BOOT_0
> + "isb\n"
> + "dmb\n"
> + "dsb\n"
> + "sev\n" // Wake CPU1
> + "adr r1, hyp_stack\n"
> + "stm r1, {r4-r14}\n" //save registers on the temporary stack
> + "ldr r12, =0x102\n" //start hypervisor SMC code
> + "adr r0, hyp_ena_cont\n" //address after SMC instruction
> + "dsb\n"
> + "isb\n"
> + "dmb\n"
> + "smc #0\n" // CPU0 -> HYP mode
> + "hyp_stack:\n"
> + ".word 0x0\n"
> + ".word 0x0\n"
> + ".word 0x0\n"
> + ".word 0x0\n"
> + ".word 0x0\n"
> + ".word 0x0\n"
> + ".word 0x0\n"
> + ".word 0x0\n"
> + ".word 0x0\n"
> + ".word 0x0\n"
> + ".word 0x0\n"
> + "hyp_ena_cont: adr r1,hyp_stack\n"
> + "ldm r1, {r4-r14}\n"
> + :::"r0", "r1", "r2", "r3", "cc", "memory"
> + );
> +};
> +
> static ulong get_sp(void)
> {
> ulong ret;
> @@ -144,7 +230,6 @@ static void setup_initrd_tag(bd_t *bd, ulong
> initrd_start, ulong initrd_end)
>
> params->u.initrd.start = initrd_start;
> params->u.initrd.size = initrd_end - initrd_start;
> -
> params = tag_next (params);
> }
>
> @@ -185,7 +270,6 @@ __weak void setup_board_tags(struct tag **in_params) {}
> static void boot_prep_linux(bootm_headers_t *images)
> {
> char *commandline = getenv("bootargs");
> -
> if (IMAGE_ENABLE_OF_LIBFDT && images->ft_len) {
> #ifdef CONFIG_OF_LIBFDT
> debug("using: FDT\n");
> @@ -246,6 +330,7 @@ static void boot_jump_linux(bootm_headers_t *images, int
> flag)
> else
> r2 = gd->bd->bi_boot_params;
>
> + hyp_enable();
> if (!fake)
> kernel_entry(0, machid, r2);
> }
> --
> 1.8.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
--
-mj
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How do ARM platform initialize DDR?
yes, I am using uboot for arndale board. The code is written by samsung only and it is not static. The best option would be to have an eth / serial driver kind of arch which all soc vendors can share. But ddr is scattered, in absence of that, your point seems valid for fsl specific. -mj On 9/17/13, York Sun wrote: > Dear MJ, > > Thanks for your reply. > > I don't see the file in my copy. Probably it is not merged yet? > Anyway, you just confirmed what I found so far. Do you use static > setting in dmc_init_ddr3.c? I mean does it adapt to different DDR speeds > and modules (if applicable)? > > In my mind, I am thinking to restructure arch/powerpc/cpu/mpc8xxx/ddr/ > to driver/ddr/fsl/ so the same driver can be shared as far as the DDR IP > is the same (or similar). > > York > > > On 09/17/2013 09:34 AM, MJ embd wrote: >> Hi York, >> >> There is no generic driver. AFAIK. Having worked on both mpc85xx and ARM >> >> I can tell you about samsung 5250. There are 2 uboots (one spl and other >> main). >> In case of sd/mmc boot the internal rom copies the spl uboot to iRAM >> and the spl boot loader initialises the DDR3. >> >> you can check for board/samsung/smdk5250/dmc_init_ddr3.c >> >> -Regards >> mj >> >> On 9/17/13, York Sun wrote: >>> Albert, >>> >>> Pardon me if this is a dumb question. I have been working on powerpc >>> platforms in the past. Now we (the developers I work with) are exploring >>> ARM cores. I am searching how memory is initialized and found different >>> solutions. Some platforms have memory ready before u-boot even starts, >>> some simply write to a set of registers. I understand many platforms >>> don't share the IP of DDR controller. I am wondering if there is generic >>> DDR driver used by many ARM platforms, like the one we have for >>> powerpc/mpc85xx SoCs. >>> >>> Regards, >>> >>> York >>> >>> ___ >>> U-Boot mailing list >>> U-Boot@lists.denx.de >>> http://lists.denx.de/mailman/listinfo/u-boot >>> >> >> > > > -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How do ARM platform initialize DDR?
Hi York, There is no generic driver. AFAIK. Having worked on both mpc85xx and ARM I can tell you about samsung 5250. There are 2 uboots (one spl and other main). In case of sd/mmc boot the internal rom copies the spl uboot to iRAM and the spl boot loader initialises the DDR3. you can check for board/samsung/smdk5250/dmc_init_ddr3.c -Regards mj On 9/17/13, York Sun wrote: > Albert, > > Pardon me if this is a dumb question. I have been working on powerpc > platforms in the past. Now we (the developers I work with) are exploring > ARM cores. I am searching how memory is initialized and found different > solutions. Some platforms have memory ready before u-boot even starts, > some simply write to a set of registers. I understand many platforms > don't share the IP of DDR controller. I am wondering if there is generic > DDR driver used by many ARM platforms, like the one we have for > powerpc/mpc85xx SoCs. > > Regards, > > York > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Understanding uboot child Makefiles
-- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Exynos 5250 Query] Smp Boot
Reminder, Please can anyone respond On 9/16/13, MJ embd wrote: > Hi, > > I was trying to understand the booting (till linux) on samsung exynos > 5250. As this is my first on ARM Cortex. I have a few questions, so > following is a step by step understanding and [Q] mentions the > question I am asking > > [1] At POR (Power on Reset) the Internal Boot rom code executes, and > checks the boot location and if it finds sd card, it copies 14k from > the sd card (which is u-boot-spl.bin) into iRAM. > [2] the internal boot rom branches pc to the entry point of spl at > __start (0x2023400) > [3] First instruction at __start is b reset. > [4] this takes the route reset | cpu_init_crit | low_level_init | first_cpu > > [Q 1] At this point what is the state of secondary core, is it held in reset > ? > As per document, "" > "the secondary CPUs (CPU1, CPU2, and CPU3) execute a WFI instruction, > which is actually a loop that checks the value of SYS_FLAGS register." > > I couldnt find the SYS_FLAGS register in Cortex A15 manual, can some one > point. > > [Q 2] The secondary core until the point the boot core calls > smp_kick_secondary is just waiting in WFI. > [5] the smp_kick_secondary does the following > (a) at the address SYSFLAGS_ADDR (0x202) which is not in spl but > above it, it write the b reset instruction and > (b) Issues a SGI to the secondary core > > [Q 3] Does this mean that secondary core is listening at address > 0x202, I couldnt find that in any document? > > [6] Supposedly it does and it starts executing the reset function, > secondary core would end up in enter_smp_pen. > [Q 4] I dont understand what is trying to achieve here, Can some one > explain. > > > I am planning to pen down the complete boot sequence, all help appreciated. > > Thanks in advance. > mj > -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Understanding uboot child makefiles
PS: Last message was sent without body, please ignore 0 down vote favorite I am trying to understand a second level makefile of uboot (this makefile was in a sub directory) a) What is the difference between $(COBJS:.o=.c) and COBJS := test_main.o b) What is the meaning of $(call cmd_link_o_target, $(OBJS)). What is the cmd_link_o_target and what is the call statement doing c) Does this line creating 2 targets ? ALL := $(obj).depend $(LIB) ===Makefile=== include $(TOPDIR)/config.mk LIB = $(obj)libtest.o SOBJS := test.o COBJS := test_main.o COBJS += diagnostic.o SRCS:= $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS:= $(addprefix $(obj),$(COBJS) $(SOBJS)) ALL := $(obj).depend $(LIB) all:$(ALL) $(LIB): $(OBJS) $(call cmd_link_o_target, $(OBJS)) # # defines $(obj).depend target include $(SRCTREE)/rules.mk sinclude $(obj).depend # -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Exynos 5250 Query] Smp Boot
Hi, I was trying to understand the booting (till linux) on samsung exynos 5250. As this is my first on ARM Cortex. I have a few questions, so following is a step by step understanding and [Q] mentions the question I am asking [1] At POR (Power on Reset) the Internal Boot rom code executes, and checks the boot location and if it finds sd card, it copies 14k from the sd card (which is u-boot-spl.bin) into iRAM. [2] the internal boot rom branches pc to the entry point of spl at __start (0x2023400) [3] First instruction at __start is b reset. [4] this takes the route reset | cpu_init_crit | low_level_init | first_cpu [Q 1] At this point what is the state of secondary core, is it held in reset ? As per document, "" "the secondary CPUs (CPU1, CPU2, and CPU3) execute a WFI instruction, which is actually a loop that checks the value of SYS_FLAGS register." I couldnt find the SYS_FLAGS register in Cortex A15 manual, can some one point. [Q 2] The secondary core until the point the boot core calls smp_kick_secondary is just waiting in WFI. [5] the smp_kick_secondary does the following (a) at the address SYSFLAGS_ADDR (0x202) which is not in spl but above it, it write the b reset instruction and (b) Issues a SGI to the secondary core [Q 3] Does this mean that secondary core is listening at address 0x202, I couldnt find that in any document? [6] Supposedly it does and it starts executing the reset function, secondary core would end up in enter_smp_pen. [Q 4] I dont understand what is trying to achieve here, Can some one explain. I am planning to pen down the complete boot sequence, all help appreciated. Thanks in advance. mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
