Hi Michal, On Tue, 24 Sep 2013 12:38:38 +0200, Michal Simek <mon...@monstr.eu> wrote:
> Hi Albert, > > On 09/23/2013 04:37 PM, Albert ARIBAUD wrote: > > Hi Michal, > > > > On Mon, 23 Sep 2013 16:19:52 +0200, Michal Simek <mon...@monstr.eu> > > wrote: > > > >> On 09/23/2013 02:31 PM, Albert ARIBAUD wrote: > >>> Hi Michal, > >>> > >>> On Thu, 22 Aug 2013 14:52:02 +0200, Michal Simek > >>> <michal.si...@xilinx.com> wrote: > >>> > >>>> Zynq lowlevel_init() was implemented in C but stack > >>>> pointer is setup after function call in _main(). > >>>> Move architecture setup to arch_cpu_init() which is call > >>>> as the first function in board_init_f() which > >>>> already have correct stack pointer. > >>>> > >>>> Reported-by: Sven Schwermer <sven.schwer...@tuhh.de> > >>>> Signed-off-by: Michal Simek <michal.si...@xilinx.com> > >>>> --- > >>>> I can't see any problem to call zynq setup a little > >>>> bit later. There is already expectation that u-boot > >>>> runs from DDR. > >>>> Moving lowlevel_init from C to ASM is possible but > >>>> I will have to introduce new macros with hardcoded > >>>> values. Using structures is much nicer. > >>>> > >>>> --- > >>>> arch/arm/cpu/armv7/zynq/cpu.c | 6 ++++++ > >>>> 1 file changed, 6 insertions(+) > >>>> > >>>> diff --git a/arch/arm/cpu/armv7/zynq/cpu.c > >>>> b/arch/arm/cpu/armv7/zynq/cpu.c > >>>> index 4367d1a..8846f30 100644 > >>>> --- a/arch/arm/cpu/armv7/zynq/cpu.c > >>>> +++ b/arch/arm/cpu/armv7/zynq/cpu.c > >>>> @@ -11,6 +11,10 @@ > >>>> > >>>> void lowlevel_init(void) > >>>> { > >>>> +} > >>> > >>> I'd rather you deleted lowlevel_init() as a C function with this > >>> name should not exist. > >> > >> Ok. Do you want me to create almost empty low_level.S or just use > >> arch/arm/cpu/arvm7/lowlevel_init.S and define empty s_init()? > > > > Urgh. I realize removing the C function would give you more work than > > simply keeping it empty until the whole s_init() mess is cleaned up. :( > > > > I'll take your change as-is, sorry for the noise. > > In connection to this topic we have recently found one issue > regarding to neon instruction which u-boot uses. > > We have this code to enable them in asm and adding this to lowlevel_init.S > is straight way how to do so. > mov r0, r0 > mrc p15, 0, r1, c1, c0, 2 > orr r1, r1, #(0xf << 20) > mcr p15, 0, r1, c1, c0, 2 > > fmrx r1, FPEXC > orr r1,r1, #(1<<30) > fmxr FPEXC, r1 > > Is it ok to create zynq asm specific lowlevel function > or doing this through s_init() or you have nice a clean way how > this should be solved when you are saying that s_init() is mess. Sorry for responding slowly. I suspect when you say neon instruction that U-Boot uses, you mean neon instructions that GCC is allowed to emit while building U-Boot, right? So we're talking about neon insns in C code only, not asm, correct? If this is correct, then does something prevent you from enabling neon instructions as early as possible, in e.g. the lowlevel_init routine? > Thanks, > Michal Amicalement, -- Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot