[U-Boot] u-boot sunxi fel plan for v2015.04

[Siarhei Siamashka]

On Fri, 13 Feb 2015 07:17:20 -0700
Simon Glass <sjg at chromium.org> wrote:

> +Albert, Tom
> 
> HI Hans,
> 
> On 13 February 2015 at 01:19, Hans de Goede <hdegoede at redhat.com> wrote:
> > Hi Siarhei and Simon,
> >
> > I'm wondering what the plan is wrt sunxi FEL booting for u-boot
> > v2015.04 I know that you both have been working on this, and I
> > think that for v2015.04 Simon's latest set probably is the best
> > way forward for now, we're going to need parts of that set
> > anyways for the more complete solution Siarhei has.
> >
> > we could replace the patch adding all the #ifdef's to start.S
> > with code saving / restoring PCR15 and friends, that would be
> > more cleaner.
> >
> > So I see 2 ways forwards for v2014.05
> >
> > 1) Go with Simon's latest set as is.
> > 2) Take the first patches from Simon's set and replace the
> > on adding he #ifdef's to start.S with one saving / restoring
> > the necessary regs
> >
> > I've a slight preference for 2. Siarhei, can you perhaps prepare
> > a patch-set for 2 for merging for v2014.05 ?
> 
> Sounds good to me. My last patch could be replaced or updated with
> something more suitable for your needs.

I'm totally lost regarding who has to ACK your last patch, what is
blocking it and which tree it should be merged from.

But the patch fixes the CONFIG_SPL_FEL option and this looks fine for
me. Just a few adjustment could be made to improve it:

1. Don't enable the generation of the u-boot-sunxi-with-spl.bin
   file when CONFIG_SPL_FEL=y (because this results in a
   non-workable junk file, which may just confuse the users)

2. Replace the 'lr' range check with just #ifdef CONFIG_SPL_FEL
   The runtime detection does not quite fit in this patch because
   it relies on #ifdef CONFIG_SPL_FEL in other places anyway.
   And this particular method of runtime detection is not compatible
   with my follow up patch.

3. Maybe set the stack pointer to the end of the 0x2000-0x5D00 area
   instead of 0x8000 (because that's how CONFIG_SPL_FEL implicitly
   behaved earlier by just keeping the 'sp' value set by the BROM).
   But I'm not really insisting on this change and using 0x8000 for
   the stack could be also fine (or even better than what we had
   before).

   Here is a set of shell commands to retrieve the initial 'sp' value,
   that is initialized by the BROM when executing code via FEL:

       # str sp, [pc]
       fel fill 0x2000 1 0x00
       fel fill 0x2001 1 0xd0
       fel fill 0x2002 1 0x8f
       fel fill 0x2003 1 0xe5

       # bx lr
       fel fill 0x2004 1 0x1e
       fel fill 0x2005 1 0xff
       fel fill 0x2006 1 0x2f
       fel fill 0x2007 1 0xe1

       fel exe 0x2000
       fel hex 0x2008 4

   And we get the following results on different Allwinner SoC variants:

       A10  : initial sp = 0x5DF8
       A13  : initial sp = 0x5DF8
       A20  : initial sp = 0x5E08
       A31s : initial sp = 0x5E08

With these adjustments done (at least 1 and 2), you can have my ACK.
But I have no objections to even taking the patch as as-is.

> That can provide a basis for Siarhei's bigger adjustments (e.g.
> perhaps getting rid of CONFIG_SPL_FEL).

That's not a much bigger adjustment. Basically, just a rather minor
tweak in the code, which makes the decision whether to load the main
u-boot binary from the SD card or return to the FEL BROM code. And
also save/restore of the system registers, because we are not allowed
to add a runtime check to skip setting them in 'start.S' in the first
place. After this minor u-boot tweak, the CONFIG_SPL_FEL option is not
needed anymore. All the complexity is hidden in the 'fel' tool and is
not really visible in the u-boot code (the fact that the 'spl' command
of the 'fel' tool smuggles the SPL binary in pieces over USB and
reassembles it in memory before executing).

-- 
Best regards,
Siarhei Siamashka